自律的なAIエンジニア導入のために
はじめに
2021年6月29日に初期のGitHub Copilotが登場しました。あれからおよそ4年、当初はコード上のコメントを実行可能なコードに変換する程度でしたが、Chatやコーディング機能が付き、テストやデバッグを含むエージェント機能が付き、DevinやGemini Code Assist agentsのようにSDLC全体にわたり自律的に動く 「AIエンジニア」 ともいえるSWEエージェントも登場しています。現時点では100点満点のものではありませんが、近年の進化も踏まえると数年もあれば完成度が高いものが登場するでしょう。
しかし、ブログの記事やカンファレンス等に参加したり、実際に仕事や個人で自分で使った限りにDevinを含む「SWEエージェント」レベルのエージェントの導入は恐らくレガシーシステムの面倒を見ているようなエンタープライズの現場には、効果が高いものの導入が困難です。2030年とかに十分に成熟したエージェントやそれを前提とした開発手法が確立されて、その時点から導入を検討しても前提が適切ではないため、導入が困難だったり、効果が限定的だったりすると思います。
こうした現在、大量のエンジニアを投入して人海戦術で回ってるような現場は、SWEエージェントと相性も良いはずですが導入の難しい現場でもあると思うので、来るべきAI時代に向けて「えんたーぷらいず」は何を見据えて改善を進める必要があるのかを、個人的な整理のためにまとめて見たいと思います。
TL;DR
- ルンバを入れると部屋がきれいになる
- 部屋を片付けないとルンバは動かない
AIによるコーディング支援の分類
「うちはもうAIを開発現場に導入してるよ！」 、こういわれる会社は既に多いんじゃないかと思います。とはいえ、社内にChatGPTやClaudeを導入してチャットアプリに質問しながら開発したり、Cursorの無料版やGitHub Copilotを導入してる企業、ClineやCursor Agentを活用してる企業、Devinのようなより包括的なツールを導入してる企業、MCPなどをガンガン使っている企業、色々と実情はあり、その効果や導入難易度は大きく異なります。
というわけで、私見ですがまずはコーディング支援の分類をしてみます。本当はCodeRabbitのようにレビュー特化とか色々あるのですが、今回はコーディングを中心の分類。
| 自律性 | 分類 | 概要 | 例 | 開発主体 | 生産性支援タイプ |
|---|---|---|---|---|---|
| レベル0 | チャットアプリ | ChatGPTなどを直接使うケース。導入はガバナンス整理が出来れば簡単 | ChatGPT, Gemini, Claude | 人間主体 | スケールアップ |
| レベル1 | コパイロット | IDEやエディタに組み込まれたChatやコード生成。人間主体のぺアプロ | 無料枠のCursor, GitHub Copilot | 人間主体 | スケールアップ |
| レベル2 | コーディングエージェント | Cursor AgentやClineのようにAI主体で自律的にコーディングやデバッグを行う。AI主体のぺアプロ | Cursor Agent, Cline | AI主体 | スケールアップ |
| レベル3 | SWEエージェント | DevinのようにSlackやPR、Kanbanなどを通して自律して開発を進めていく。人間は作業支持者 | Devin, CodeAssist Agent | AI主体 | スケールアウト |
レベルはあくまでAIがどこまで自律的に動くかの指標であってコーディング性能とかではないのでご注意ください。また、便宜上の分類なので当然製品レベルで見たら分類しきれないものあるんですが、結構この範囲に収まる気はしています。
個人的な印象としてレベル0とレベル1で手間暇が違うので、実際の作業速度はともかく体験としてはかなり良くなります。また、近年の流れとしてレベル1以上の製品の多くは 「コンテキストの取り込み」 を重要視している点があるでしょう。
実はDORAによる「生成AIで開発生産性全体はむしろ下がる」というレポートもあったりします。参照した記事の中でも言及されていますが、品質が悪くて手戻り等が発生するためです。
Cloud Nextのセッションでは、それはAIが多くの人間よりもコーディング自体が仮に上手くても、社内のコーディングルールや、システム全体の設計、ドキュメント、などなど多くのコンテキストがかけており、それを補う必要がある、ということを言っていました。コードは書ける新入社員みたいなものですね。
そのため実際に多くのレベル1以上の専用ツールはリポジトリをRAG化したり、ドキュメントを参照したり、MCPで外部の情報を収集する、という点に力を入れています。なので、それがやりづらいレベル0の状態では便利さは感じれますが、本格的な実用にはまだ少し遠いかな、という気もします。
レベル2は日本で去年末くらい人気のClineに代表されるエージェントです。私もこれを良く使います。
最大の特徴は、レベル1はまさに副操縦士として人間のコーディングを支えてくれるのに対し、レベル2では人間がAIに指示を出して悩んだ部分をサポートしながら開発を行います。主体がAIになっているわけですね。
このあたりで少し導入が難しくなります。もちろん、AIが生成するコードの品質という点もありますが、結構利用者であるエンジニアのマインドチェンジというか慣れが必要です。今は「品質悪すぎ。貸せ！ 俺がやる！！」って時もそれなりにあるのですが、ここは将来的には改善するとして、今の時点でもコーディング速度自体は私よりかは全然早いので典型的なコードを書く時には特に重宝しています。
レベル3もAIエージェントと一般には分類されるものですが、ここでは 「SWEエージェント」 とあえて呼びます。
というのも実際に導入してみるとその体験が大きく異なるからです。
例えClineのような自律的なエージェントであっても、レベル2までのツールは 「エンジニアの生産性をスケールアップさせる」 という側面が強いです。一方で、Devinのようなレベル3は 「Devinという同僚、部下が増える」 という感覚が違いです。
AIとのインタラクションもVS Codeのような開発ツールではなく、Slackのようなチャットツール、Pull Request、Gemini Code Assist(preview)のようにKanbanボード、など開発者が通常使うコミュニケーションツールがそのまま使えます。また、依頼ベースで進むのでDevinは非同期で自律的に動きます。Clineであってもどうしてもエディタに張り付いての作業になりますが、Devinであれば依頼した後は他の作業や自宅に帰って寝ていても大丈夫です。まさにSWEエージェントを一人雇っている感覚。**「エンジニアのスケールアウト」**ですね。
まさかITおじさんのネタがこんなにも早く現実になるとは...
レベル1, 2, 3と分類しましたが、これはあくまで用途の違いです。通常の開発現場ではエンジニアがレベル2を使いつつ、高度な部分はレベル1のマニュアル操作＋AI支援で実施。作業ボリュームはあるけど難易度が低い部分はレベル3でSWEエージェントを大量投入して物量と戦う、みたいな方向で使い分けるものです。
レベル3: SWEエージェント導入のためにやるべきこと
アーリーマジョリティで良い
さて、こうしたAIによるコーディング支援ツールはSNSやQiitaやZennのようなエンジニアコミュニティでは盛んな話題であり、実際に多くの企業が導入しているでしょう。
そんな中でもレガシーコードをメンテナンスしているような大企業というか エンタープライズ系の企業 はファーストペンギンになるのを嫌いますし、現状のAIツールでは品質やガバナンスに不安があるため導入せずに静観してる場合も多いのでは？ そうした企業の中の人の慟哭も聞こえそうですが、これはある意味正しいです。
やはり、今の時点では成熟度が低いのは事実ですし、大企業レベルになると抱えてるスタッフの数も多いでしょうから、月額数千円という費用も総額が馬鹿になりません。それだけの投資をして「効果は予測できない」というのは中々勇気もいる事です。なにより、別にコアビジネス領域で無いならばイノベーターやアーリーアダプターになる必要は無くて、アーリーマジョリティで十分に競争力を維持出来る、という判断もあると思います。
ただし、仮に2030年頃にSWEエージェントが成熟し、それを前提とした開発手法が確立されてアーリーアダプター達が大きな成果を上げたとしても、それを 「見てから動いたら」 もう遅くて、そこから5年~10年は掛かるでしょう。なぜなら、SWEエージェントの導入とは単純にツールを買って入れれば良いという分けではないからです。
後述する通り、導入や効果的な利用にはいくつかの前提を変える必要があります。それは組織や人だったり文化や習慣だったりと、めんどくさいものです。大きな組織でこれらを変えるのは非常に時間が掛かります。なので、良い感じのツールやプラクティスが出来たらすぐに導入出来るように、**「AIツール導入以外のところ」**を今から頑張りましょう。
AI導入のためのガバナンス体制を構築する
AIを安全かつ効果的に導入するためには、まずガバナンス体制の構築が不可欠です。今時点でAI自体を導入してない場合は、AIガバナンスの整備がされてないケースもあります。
ソフトウェア開発以外にもAIは非常に有用なのでこれはきちんと整えましょう。逆に、整えずにとりあえず導入するのは目の行き届く十分に小さな組織で無い限り危険です。
経産省が出したガイドラインもありますし、こうした整備をして安心して使える状態にしておくことが必要です。
また、AIを忌避することも過信することも無く正しく知って評価することが重要です。
AIを使うとなんでも学習されるとか思わずに、オープンウェイトモデルとクローズドモデルの違いや、誰が管理するインフラにデプロイされているか、その場合の契約はどうなっているのか？ これをリスクと効果のバランスを見て判断する必要があります。
AI導入の第一歩として、まずは自社に適したガバナンス体制の構築から始めましょう。
AIによるコード生成を支えるテスト環境を整備する
AIが生成するコードの品質を担保し、その能力を最大限に引き出すためには、テスト環境の整備が鍵となります。
人間がテストしても良いですし、AIにテスト自体を書かせてその結果を人間がレビューしても良いかもしれません。
ただ、いずれにしてもテストデータが整備されていたり、コンテナ等でテスト環境を簡単に作成できたり、そうした準備がないとAIによる高速なコード生成の恩恵を十分に享受できません。
別に品質保証だけなら自動テストが一切なくて手動でテストをしてもかまわないのですが、AIが1日で作った改修を人間が1か月テストしてたら生産性の改善はかなり限定的ですよね？ 人がボトルネックになり過ぎないように自動テストが出来る環境にしておく必要があります。
また良いテストやテストケースは仕様理解のためのドキュメントとしても有用です。こうしたコンテキストの注入はAIが書くコードの品質を上げるのにも役に立つでしょう。AIによるコード生成のメリットを最大限に活かすため、テスト環境の整備を進めましょう。
AIと連携可能なCI/CDパイプラインを構築する
AIによる開発プロセスをスムーズに連携させ、継続的な価値提供を実現するためには、CI/CDパイプラインの構築が重要です。上記のテストの話とも関連しますが、適切なCI/CDパイプラインが無ければ効果的にAIを使うのは難しいです。
例えばGUIのWebコンソールからのみデプロイ出来る仕組みだとしましょう。AIでもPlaywright MCPやOperatorのような仕組みを使えば対応できる部分はあるでしょうが、スクリプトでやった方が早くて確実です。頻繁にデプロイをして頻繁にテストをすることが重要ですね。
また、静的コードスキャンや脆弱性スキャンのような仕組みなど、デプロイのためのクオリティゲートをしっかりと定義し、実装する事でAIが書いたコードであっても人間が書いたコードと同様に安心してリリースすることが出来ます。AIとの連携を視野に入れたCI/CDパイプラインを構築し、開発プロセスの自動化と効率化を目指しましょう。
AIが活用しやすいIaC（Infrastructure as Code）を推進する
AIがインフラ構成を理解し、自律的に操作できるようにするためには、IaCの推進が効果的です。MCPやOperatorを使えばExcelやWorldの手順書をベースにインフラを理解したり構築することはできるでしょう。
しかしながら、やはりテキストベースの作業の方が強いのでTerraformやDockerfileを使ったIaCはますます重要になります。
Terraformからシステム構成図を描いたりも今でも限定的ながらできますし、人間がやってきた時以上に上記に記載したようなテストやCI/CDのような開発のプラクティスをインフラに適用する意義が大きくなっています。
特にクラウドやk8sをインフラとして採用していれば、AIによるIacの支援をオンプレミス以上に受けることが出来ます。AIによるインフラ管理の自動化を見据え、IaCの導入と徹底を進めましょう。
AIによる運用高度化のための可観測性（Observability）環境を強化する
AIがシステムの健全性を監視し、問題発生時に迅速な対応を支援できるようにするためには、可観測性環境の強化が求められます。Day 0や Day 1だけではなく、運用保守といったDay2においてもAIがサポートをしてくれます。
GCPのCloud InvestigationsやDynatraceのDavis AIをはじめとして、予兆検知やトラブルシューティングをサポートしてくれるAIはLLM以前から存在し、LLMでも大きな効果を発揮します。
これは逆に言えば、アプリケーションの振る舞いをコンテキストとしてAIに食わせることで分析の効果を上げる事が出来るということです。
個人的には障害分析とか性能テストで性能が出ないときの対応とかやるのですが、こうした作業は 「どこをどうみるか」 という点が重要で、アプリケーションコードとインフラやミドルのそれぞれの知識が要求されがちです。そして、AIはそれをやることが出来ます。なので、そこを分析させるための情報を集めるのがまず重要でしょう。
それは、OpenTelemteryのようなプロトコルを使ってAPMなどに情報をためたり、従来はプロファイラを使っていたような情報はもちろん、ログの標準化のような仕組みも重要です。AIによる運用業務の高度化を目指し、可観測性環境の整備・強化に取り組みましょう。
AIの学習データとなる暗黙知を形式知化する
AIが組織の知識を学習し、より精度の高いサポートを提供できるようにするためには、これまで暗黙知とされてきた情報を形式知化することが重要です。AIに限らず新人は新しい現場に入っても分からないことだらけです。ドキュメントが無ければ、自分で学ぶことが出来ず、経験と口頭伝承に頼る必要があります。将来のAIもDevinのKnowledgeのように「経験から学ぶ」という事も出来るでしょうが、やはり適切なドキュメントの整備はオンボーディングの速度を上げます。
このあたりはDevin WikiやKnowledge、チャットツールやメールに対してのエージェント系ツールなど諸々含めてAI自体がドキュメンテーションのサポートをしてくれる部分も多いので、先行してそうしたツールから導入の検討をしないといけないかもしれません。AIの能力を最大限に引き出すため、組織内の暗黙知を積極的にドキュメント化し、AIの学習データとして活用できる状態を目指しましょう。
まとめ
自分の触ってみた所感から、DevinのようなSWEエージェントを特に大企業で導入するために重要と感じたことをまとめてみました。
正直に言えば、「当たり前のことを当たり前にやる」 以上では無いと思っています。これらは従来からのベストプラクティスです。ただ、こうしたベストプラクティスを適切に導入していくことで、SWEエージェントを効果的に導入することができ、従来以上の大きな成果を上げれるでしょう。
この辺はルンバは部屋を自動で綺麗にしてくれるけど、ルンバを動かすにはそもそもある程度部屋を片付けないといけない、という話と似ていますね。
AIの導入自体は今は静観してアーリーマジョリティを目指すのは悪い戦略では無いと思いますが、同時に今からそこを目指してAI導入以外の準備を進めないとレイトマジョリティすら怪しくて、導入に必要な5年や十年を待たずとして、結果的には生産性の圧倒的な違いからビジネスで負けるというシナリオもあり得ると思います。
今回上げた話は、どんなAIツールが出ても大きくは変わらないでしょうし、日々のSDLCもAIに関係なく改善してくれます。こうした改善をするには時間もお金も掛かるので、来るべきX Dayに備えて今から準備をするのが良いと思います。
それではHappy Hacking!
Discussion