AI for DevOps の記事一覧

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