【エキスパート座談会 #1】生成AI活用の現在地：作業の自動化から「仕組みづくり」へ / 開発者向けブログ・イベント

こんにちは。
GMOインターネットグループエキスパートの石丸です。

GMOインターネットグループでは、特定の専門分野における第一人者を「エキスパート」として認定し、エキスパートによる情報発信やイベントの開催といった技術広報活動への支援を行っています。エキスパートはグループ内におけるコミュニティの活性化はもちろん、業界全体の発展に貢献する取り組みを行っており、活動費用として年間で最大100万円が支給されます。

そんなエキスパートの活動の一つに、隔週で行われている「エキスパート定例」があります。これまでは、互いの活動報告や連携、所属会社での取組などを共有しあったりしてきたのですが、今年度から新たにメンバーが持ち回りでディスカッションのテーマ決め・ファシリテーションを行う形で実施をしています。

今回は、わたくし石丸が担当として「実務における生成AI活用の現在地」をテーマに開催。生成AIを業務で使うこと自体は当たり前になりましたが、専門領域が違えば、現場で起きていることも違うはずです。領域の違うメンバーが集まる場なので、それぞれの実務でAIをどう使っているのかをヒアリングしました。

今回集まったのは、Webアプリケーション開発、次世代IoTシステム、AI for DevOps、Web / 3D / XR、デザイン組織マネジメント、映像制作の6領域です。職種も担当プロダクトも、扱っている素材すら違う6人だったこともあり、さまざまな意見が集まりました。

参加メンバー

氏名	所属	領域
石丸智輝	GMOインターネット株式会社	Webアプリケーション開発
黒瀧悠太	GMOペパボ株式会社	次世代IoTシステム
武田大佑	GMOペパボ株式会社	AI for DevOps
羽賀流登	GMOグローバルサイン・ホールディングス株式会社	Web / 3D / XR（AR / VR）
山林茜	GMOペパボ株式会社	デザイン組織マネジメント
加藤優真	GMOインターネット株式会社	映像制作

全員がClaudeをメインツールとして活用

まずはじめに、実務で活用している生成AIツールについてヒアリングしました。

石丸

私は開発でClaude Codeを使っています。単発で指示を出すというより、設計・開発・テスト・レビュー・レビュー指摘の修正までを自動で回すハーネスを組んでおいて、コマンドを1つ叩けばそれが走るようにしています。コードレビューはDevinとGitHub Copilotを併用していましたが、Devin Reviewが有料化されたタイミングでGitHub Copilotに寄せました。

黒瀧

私もClaude Codeがメインで、CodexやCursorも一部使っています。開発・コーディングが中心ですが、それ以外にもClaudeをGoogleカレンダーやNotion、Slackとつなぐ仕組みを作っています。開発していると「これってどういう議論で決まったんだっけ？」という疑問が出てきますよね。そこでSlackやNotionを検索して答えてくれるようにしています。

武田

実装はClaude CodeとCodexです。他の方と少し違うところを挙げるなら、テストコードを書くこともAIに任せています。あとは調べ方が変わりました。以前はまずインターネット検索をしていましたが、世の中のテックブログや「使ってみた」事例を探すときは、Claude Codeに投げて網羅的に集めてもらうようになりました。

羽賀

Claudeがメインで、GitHub Copilotも使っています。私はゲームエンジンを使った業務が中心なので、少し毛色が違うかもしれません。MCPに対応しているエンジンを使っているので、Claudeから対話でエンジンそのものを操作できるようにしています。

山林

私もClaudeがメインです。デザイナーですが、自分でコードを書く場面がかなり増えました。

加藤

私はClaudeとGeminiの併用です。動画の処理や、AIに映像を「見せて」判断させる用途ではGeminiが優秀だと感じています。生成系はAdobe Firefly、音楽はSuno、ナレーションはElevenLabs、それからHiggsfieldというさまざまなモデルを横断して使えるプラットフォームを使っています。

専門分野はさまざまですが、全メンバーがClaudeをメインツールとして活用しているという結果となりました。

「コードを書くことは、ほとんどない」

次に聞いたのは、すでにAIに置き換わった、あるいは劇的に効率化した業務です。

石丸

コードを書くことはほとんどないです。私はチームのマネージャーとして数年前は自分で実装するよりコードレビューの作業のほうが多かったのですが、今はそのコードレビューもAIに置き換わりました。レビューにかけていた時間が大幅に減ったおかげで、その分を開発に回せるようになりました。プルリクエストの数は、コーディングエージェントがなかった頃と比べて10倍以上です。

黒瀧

私もレビューとコーディングは置き換わりました。今は自動マージの仕組みも作っています。すべてを無条件に自動化するのではなく、まずリスク評価をして、影響が大きくないものにラベルを付ける。そのラベルに応じてレビューもマージも自動で進むようにしています。

武田

さきほど挙げたテストコードと調査に加えて、図を描く作業が変わりました。データモデリングや設計をするときに図を描く機会が多いのですが、ざっくり口で説明してAIにたたき台を作らせて、それを人間が見て直す。この往復で進めるようになったので、図を描くこと自体もAIに任せた形です。

コーディング以外の領域でも、置き換わりは進んでいた

羽賀

ゲームエンジンの操作が変わりました。これまではUI上でパラメータを1つずつ変えていましたが、「このパラメータをいじったらどうなるんだっけ」というのが今までは怖かったんですよ。壊れるかもしれないし、戻すのも手間なので。それがMCP経由で操作できるようになったので、気軽に試せるようになりました。3Dモデルの生成も同じで、手でモデリングしていたものが大幅に速くなっています。

もう一つ、羽賀さんが挙げたのは「できなかったことができるようになった」という変化でした。

羽賀

技術的にはできるのに、素材がないからできない、ということが結構あったんです。たとえば「この形の炎が出ているものを作りたい」というときに、手元に素材がなければアセットを購入していました。それが今は自分たちで画像を生成して、すぐ作れるようになりました。

加藤

映像でも、任せる範囲が広がっています。SNS向けの短尺の縦型動画のように、1本ずつ作り込むよりも本数が求められるものは、AIを軸に作るようになりました。AIアバターやクローン音声は、もう任せられるクオリティです。構成や企画もAIと一緒に考えていて、HiggsfieldがMCPに対応しているので、Claudeで企画を壁打ちしてGOサインを出すだけで生成が走り、ファイルがローカルにダウンロードされるところまで通ります。アイデアは人間、実働部分はAIという分担ですね。これまで1週間かかっていたものが、生成の待ち時間プラスアルファくらいでできるようになりました。動画生成そのものには時間がかかりますが、その間は別の作業に回せるので、体感がまったく違います。

山林

UIデザインでは、これまでFigmaでプロトタイプを作ってから実装していましたが、今はFigmaを使わずに直接コードでプロトタイプを作って検証・議論することが多くなりました。全体のフローを俯瞰したいときはFigmaやFigJamを使いますが、既存サービスの管理画面のようなものは直接コードで再現しています。これまでエンジニアに依頼していた簡易的な開発も、Claude Codeを使って自分で実装することが増えました。グラフィックデザインはまだ完全には置き換わっていませんが、ゼロから自分で考えることは最近なくなってきて、一度AIが生成したものをブラッシュアップする使い方をしています。

AIが動く仕組みを、人間が作る

ここまでの話に共通しているのが、仕組みづくりです。ハーネスや自動マージのように、一連の工程がまとまって流れる形を作って、それを回している。組んでいる仕組みは、人によってさまざまでした。

羽賀

ライブラリの調査やアップデート情報のキャッチアップもAIに置き換わりました。毎朝、自動でWeb検索を回してアップデート内容を調べ、個人のメディアに投稿するワークフローを組んでいます。これで取りこぼしがなくなりました。

山林

マネジメントの側でも同じことをしています。担当しているチームがたくさんあって、それぞれに横断的にデザイナーが関わっているので、状況を追うのが大変なんです。各チームのSlackチャンネルで何が起きているかを効率よく把握するために、Claudeが毎日SlackのDMで送ってくれるようにしています。すでに型があるものはAIに任せやすいので、SkillsやClaude Designを使って、デザイナー以外も対応できるようにもしています。

加藤

私もSkillを作って縦型動画を制作しています。動画以外にも、YouTubeチャンネルのレポーティングや機材管理のツールもAIで作って運用しています。

武田

社内では、自律実行に取り組んでいます。人間がプロンプトを打ったり指示を出したりする部分も、AIが判断して自律的に動くようにしていきたいと考えています。

作っているものは違っても、進め方は同じでした。仕組みに落としやすいかどうかを左右するのが、型があるかどうかです。型が定まっていれば渡しやすく、まだ定まっていないところは人の手が残ります。

型ができると、誰がやるかも変わります。デザイナーが自分で実装し、デザイナー以外がデザインを作るようになる。そしてその型や仕組みを設計しているのは、AIではなく人間です。

人間にしかできない領域はどこか

最後に、生成AIを使うなかで「ここだけはまだ人間にしかできない」と感じる領域を聞きました。

まず挙がったのは、上流の判断でした。

石丸

ハーネスの設計や改善です。もちろんAIも活用していますが、完全に任せることはできていません。アプリケーション開発の設計でもAIを使っていますが、大規模なシステムになるほど、人間が深く介在しないと意図しない方向に進んでしまうことがあります。

武田

AIが動くベースとなる部分を作るところです。そのベースの評価軸・判断軸をどう置けばいいか、AIが不安定になる部分をどう扱うか。それを判断して実装に落とし込むのは、人間しかできないと思っています。

黒瀧

意思決定です。作りたいものを作って検証してリリースすることは、たしかに早くなりました。ただ、開発が早すぎて、プロダクトをマネージする人のアイデアが枯渇してしまうんです。だから、その先を考えるようなAIを作りたいと思っています。競合を調査して案を出す、未来から逆算してプロダクトの要件を作る。そういう意思決定には、人間が必要だと感じています。

一方、クリエイターのメンバーからは、仕上がりの品質を挙げる声もありました。

加藤

さきほど山林さんが話していたグラフィックデザインの件と近いのですが、クオリティが求められて、人間がしっかり見るものはまだAIに任せられないですね。大きなスクリーンで流れるようなものは、人間がメインで作っています。そういう場合は部分的にAIを使うイメージです。

判断の質と、仕上がりの品質。答えは違いますが、どちらも良し悪しを機械的に判定できない部分でした。

黒瀧さんの「アイデアが枯渇する」という話は、ボトルネックの位置が変わってきたということでもあります。先日公開された対談記事「AI TALK」ではプルリクエストが増えてリリースフローが詰まる話が出ていましたが、今はその位置が、「何を作るか」という一段上の段階にまで移ってきています。人間にしか任せられない場所が、そのまま一番の詰まりどころになりつつあります。

まとめ

今回の座談会で分かったのは、作業を1つずつ自動化するだけでなく、AIが動く仕組みそのものを作る段階に入っていることでした。ハーネス、自動マージ、自律実行、ワークフロー、Skills。6人とも呼び方は違いますが、自分の業務に合わせてAIが動く土台を組んでいます。

どこまでを型にして仕組みに落とせるかを見極めるには、その領域を深く知っている必要があります。専門性の使いどころが、手を動かすことから仕組みを設計することに移ってきているのだと思います。

ブログの著者欄

石丸智輝

GMOインターネット株式会社

Webアプリケーションエンジニア。2016年GMOアドマーケティング株式会社に入社。現在はGMOインターネット株式会社所属。入社以降、広告配信サービスの開発を担当し、現在は開発に携わりながら開発チームや組織のマネジメントも担当。 GMOインターネットグループを横断した技術同人誌の制作や技術ブログでの情報発信の活動を通して、グループの垣根を超えたアウトプットや社内コミュニティの醸成に取り組む。 2024年4月よりGMOインターネットグループのエキスパートとして活動を開始。