インテリジェントエージェント工学の8つのレベル

作者：バシム・エレダス

翻訳：宝玉

AIのプログラミング能力は、私たちの制御能力を超えつつあります。だからこそ、SWE-benchのスコアを必死に伸ばそうとする努力は、エンジニアリングリーダー層が本当に関心を持つ生産性指標と同期していないのです。Anthropicのチームはわずか10日でCoworkをリリースしましたが、同じモデルを使っているもう一つのチームは、概念実証（POC）すら完成させられませんでした。違いは、あるチームは能力と実践のギャップを埋めたのに対し、もう一つはまだそこに到達していないことです。

このギャップは一夜にして消えるものではなく、段階的に縮小していきます。全部で8つの段階です。この記事を読んでいる多くの人は、すでに最初のいくつかの段階を超えているかもしれませんが、あなたは次の段階に早く到達したいはずです。なぜなら、段階を一つ上がるごとに生産性が大きく向上し、モデルの能力向上はこれらの利益をさらに拡大させるからです。

もう一つ重要な理由は、多人数協働の効果です。あなたのアウトプットは、あなたが思っているよりもチームメイトのレベルに依存しています。仮にあなたがレベル7のエキスパートだとしましょう。夜寝る前に、バックエンドのインテリジェンスエージェントがあなたのPRをいくつも事前に準備してくれているかもしれません。でも、もしあなたのコードリポジトリのマージには同僚の承認が必要で、その同僚がレベル2のままで、手動でPRをレビューしているとしたら、あなたのスループットは停滞します。だから、チームメイトのレベルアップを手伝うことは、自分にとっても有益なのです。

多くのチームや個人と、AI支援によるプログラミングの実践について交流した結果、私が観察した段階進行のパス（順序は絶対的ではありません）を以下に示します。

【AIエンジニアリングの8段階】

第1・2段階：タブ補完とインテリジェントIDE

この2つの段階は、ざっと触れるだけにします。記録のために書いておきます。気軽に飛ばして読んでください。

タブ補完はすべての始まりです。GitHub Copilotがこのムーブメントの火付け役となりました。タブキーを押すだけでコードが自動補完される仕組みです。多くの人はこの段階をすでに忘れているかもしれませんし、新人は最初から飛ばしていることもあります。これは経験豊富な開発者に向いています。彼らはまずコードの骨格を作り、その後AIに詳細を埋めさせるのです。

CursorのようなAI専用IDEは、チャットとコードリポジトリをつなぎ、ファイル間の編集を格段に楽にします。ただし、やはり最大の制約は「コンテキスト」です。モデルは見えている範囲内でしか処理できません。正しいコンテキストを見ていなかったり、逆に不要な情報を多く取り込みすぎたりすると、イライラさせられます。

この段階にいる多くの人は、選んだプログラミングインテリジェンスエージェントの「計画モード」を試しています。大まかなアイデアを構造化されたステップに落とし込み、それをLLMに渡して反復的に改善しながら実行させるやり方です。これは効果的で、コントロールを保つ合理的な方法です。ただし、後の段階ではこの計画依存は次第に減っていきます。

第3段階：コンテキストエンジニアリング

いよいよ面白い部分です。コンテキストエンジニアリング（Context Engineering）は2025年のホットワードです。なぜ注目されるのか？それは、モデルが合理的な数の指示に確実に従い、適切なコンテキストとともに動作できるようになったからです。雑多なコンテキストや不十分な情報はどちらも問題です。重要なのは、各トークンの情報密度を高めることです。「各トークンは自分の位置を提示文の中で戦っている」—これが当時の信条でした。

同じ情報をより少ないトークンで伝えること、すなわち情報密度を高めることが王道です（出典：humanlayer/12-factor-agents）。

実践面では、コンテキストエンジニアリングは想像以上に広範です。システムのプロンプトやルールファイル（.cursorrules、CLAUDE.md）を含む。ツールの記述方法も含む。モデルがどのツールを呼び出すかを決めるための記述も含む。対話履歴の管理や、長時間のやりとりで迷子にならない工夫も必要です。選択肢が多すぎるとモデルが混乱するため、適切なツールだけを選び出す工夫も重要です。

今では「コンテキストエンジニアリング」という言葉はあまり聞かなくなりました。むしろ、ノイズの多いコンテキストや混乱したシナリオでも推論できるモデル（より大きなコンテキストウィンドウも有効）が重視されています。ただし、コンテキストの消費は依然として重要です。以下のシナリオでは特にボトルネックになり得ます。

・小さなモデルはコンテキストに敏感。音声アプリは一般的に小さなモデルを使い、コンテキストサイズも遅延に関係します。

・トークン消費が激しい。PlaywrightのMCPや画像入力は、あっという間にトークンを消費し、Claude Codeでは想定より早く「圧縮会話」状態に入る。

・複数ツールを接続したインテリジェントエージェントは、ツール定義の解析に多くのトークンを費やし、実作業よりも多く消費する。

大局的には、コンテキストエンジニアリングは消えたわけではなく、進化しています。焦点は、ノイズの多いコンテキストをフィルタリングすることから、適切なタイミングで適切なコンテキストを提供することへと移っています。この変化が第4段階への道を開きました。

第4段階：複合エンジニアリング

コンテキストエンジニアリングは、その時点の会話に焦点を当てていましたが、複合エンジニアリング（Compounding Engineering、Kieran Klaassen提唱）は、その後のすべての会話に適用されます。これは私や多くの人にとって大きな転換点となりました。つまり、「感覚的にプログラミングする」だけではなく、計画・委任・評価・蓄積のサイクルを回すことの重要性です。

具体的には、タスクを計画し、LLMに十分なコンテキストを提供して成功させ、委任し、結果を評価し、学習したことを蓄積します。何が効果的だったか、何が問題だったか、次回はどうすれば良いかを記録していくのです。

この「蓄積」の部分が魔法です。LLMはステートレスです。昨日、あなたが明示的に除外した依存関係を再び持ち込むこともあります。これを防ぐには、ルールファイル（CLAUDE.mdなど）を更新し、経験を次の会話に反映させる必要があります。ただし、ルールに詮索しすぎると逆効果になることもあります（指示が多すぎると「何もしない」状態になるため）。より良い方法は、LLMが自ら有用なコンテキストを見つけやすい環境を作ることです。例えば、常に更新されるdocs/フォルダを管理するなどです（第7段階で詳述します）。

複合エンジニアリングを実践している人は、LLMに与えるコンテキストに非常に敏感です。エラーが出たとき、まず「コンテキストに何か欠けているのでは？」と考え、モデルの能力不足を疑うよりも先に、コンテキストの問題を疑います。この直感こそが、第5段階から第8段階への道を開きます。

第5段階：MCPとスキル

第3・4段階はコンテキストの問題を解決しましたが、第5段階は能力の問題です。MCP（Model Context Protocol）やカスタムスキルにより、LLMはデータベースやAPI、CIパイプライン、デザインシステム、ブラウザテスト用のPlaywright、通知用のSlackなどにアクセスできるようになります。モデルは単にコードリポジトリを考えるだけでなく、直接操作も可能です。

MCPやスキルについての良質な資料はすでに多くありますので、詳細は割愛します。例を挙げると、私たちのチームではPRレビュー用のスキルを共有し、改善を重ねています。PRの性質に応じてサブインテリジェントを起動したり、データベース連携の安全性をチェックしたり、複雑度分析を行って冗長や過剰な工夫をマークしたり、プロンプトの健全性を確認したりしています。これらはすべて、PRの自動化と品質向上を目的としています。

なぜここにこれほど投資するのか？それは、インテリジェントエージェントが大量のPRを生成し始めると、人間のレビューがボトルネックになり、品質管理の壁となるからです。Latent Spaceは、「コードレビューは死んだ」と断言しています。代わりに、自動化された一貫性のあるスキル駆動のレビューが主流になりつつあります。

MCPの例では、Braintrust MCPを使って、LLMが評価ログを参照し、直接修正を行う仕組みを導入しています。DeepWiki MCPは、オープンソースリポジトリのドキュメントにアクセスできるようにしています。

また、複数人がそれぞれ独自のスキルを作り始めたら、それらを共有レジストリにまとめるのも良いでしょう。Blockの良い記事によると、彼らは100以上のスキルを持つ内部スキルマーケットを構築し、特定の役割やチーム向けのスキルセットを策定しています。スキルやコードは、プルリクエストやレビュー、バージョン管理と同じ扱いです。

さらに、LLMはCLIツールの利用も増えています（Google Workspace CLIや、もうすぐリリース予定のBraintrust CLIなど）。理由はトークン効率です。MCPサーバーは毎ラウンド、ツール定義をコンテキストに注入しますが、CLIは特定のコマンドだけを実行し、その出力だけがコンテキストに入るためです。私はagent-browserを使うことが多く、Playwright MCPよりも効率的です。

ここで一旦立ち止まります。第3・4段階は、その後のすべての土台です。LLMは特定のことには非常に得意ですが、他のことは苦手です。これらの境界を直感的に理解し、それを土台に自動化を積み重ねる必要があります。もしコンテキストがノイズだらけだったり、プロンプトが不十分だったり、ツールの記述が曖昧だったりすると、第6・7・8段階は逆に問題を拡大します。

第6段階：Harness Engineering（ハーネスエンジニアリング）

ロケットの本格的な打ち上げが始まります。

コンテキストエンジニアリングは「モデルが何を見るか」に焦点を当てていましたが、Harness Engineeringは「環境全体をどう構築するか」に焦点を当てます。ツールやインフラ、フィードバックループを整備し、インテリジェントエージェントがあなたの介入なしに信頼して動作できる環境を作るのです。単なるエディタだけではなく、完全なフィードバックループを提供します。

OpenAIのCodexツールチェーンは、観測性システムの一例です。インテリジェントエージェントが自分の出力を照会・関連付け・推論できる仕組みです（出典：OpenAI）。

OpenAIのCodexチームは、Chrome DevToolsや観測性ツール、ブラウザナビゲーションをインテリジェントエージェントのランタイムに統合し、スクリーンショットを撮ったりUIフローを操作したり、ログを照会したり、修正結果を検証したりできるようにしました。プロンプトを与えるだけで、バグの再現や動画記録、修正の実行も可能です。アプリを操作して検証し、PRを提出し、レビューに応答し、マージまで自動化します。判断が必要なときだけ人間が介入します。インテリジェントエージェントはコードを書くだけでなく、その効果を見て改善し続けるのです。

私たちのチームは、技術的な故障診断の音声・チャットインテリジェントエージェントを開発しており、「converse」というCLIツールを作りました。これにより、どんなLLMも私たちのバックエンドと対話でき、逐次会話を行えます。コードを修正したら、converseを使って本番環境でテストし、改善を繰り返します。時には数時間連続で自己改善ループを回すこともあります。結果が検証可能な場合は特に強力です。会話はこのフローに従い、必要に応じてツールを呼び出します（例：有人サポートに切り替えるなど）。

これらを支える核心概念はBackpressure（バックプレッシャー）です。自動化されたフィードバックメカニズム（型システム、テスト、リンター、プリコミットフック）を用いて、インテリジェントエージェントが人間の介入なしに誤りを発見・修正できる仕組みです。自主性を持たせたいなら、バックプレッシャーは必須です。さもなければ、ただのゴミ生産機になってしまいます。この考え方は安全性にも通じます。VercelのCTOは、インテリジェントエージェントや生成されるコード、あなたの秘密鍵は信頼できる領域に分離すべきだと指摘しています。ログに埋め込まれたプロンプトインジェクション攻撃により、エージェントがあなたの資格情報を盗む危険性があるからです。安全な境界線はバックプレッシャーです。これにより、インテリジェントエージェントの暴走を制御し、「何をすべきか」だけでなく「何をしてはいけないか」も制御できます。

この理念をより明確にする二つの原則：

・スループットを優先し、完璧さを求めない設計を。完璧を求めると、同じバグに何度もハマり、修正が上書きされるだけです。小さな非阻害的エラーは許容し、最終的な品質チェックを行うのが良いでしょう。人間の同僚にも同じことをしています。

・指示よりも制約を優先。段階的なプロンプト（「まずAをやる、次にB、最後にC」）は時代遅れです。私の経験では、境界を定義する方がリストを列挙するよりも効果的です。なぜなら、インテリジェントエージェントはリストに固執し、それ以外を無視しがちだからです。より良いプロンプトは、「これが望む結果です。すべてのテストに合格するまで続けてください」といったものです。

Harness Engineeringのもう一つの側面は、インテリジェントエージェントがあなたなしでもコードリポジトリを自在にナビゲートできる状態を作ることです。OpenAIは、AGENTS.mdを約100行に抑え、他の構造化ドキュメントへのリンクとし、ドキュメントの鮮度をCIに組み込んでいます。これにより、臨時のアップデートに頼る必要がなくなります。

これらを整備したら、次に自然に浮かぶ疑問は、「もしインテリジェントエージェントが自分の仕事を検証し、リポジトリ内を自在にナビゲートし、あなたの介入なしに誤りを修正できるなら、なぜあなたは椅子に座っている必要があるのか？」です。

念のため注意喚起します。第3〜5段階を超えた段階は、まだ一部の人にはSFのように映るかもしれません（でも、まずは保存しておき、後で見返すと良いでしょう）。

第7段階：バックグラウンドインテリジェントエージェント

辛口コメント：計画モードは消えつつある。

Claude Codeの創始者Boris Chernyは、今でも80％のタスクが計画モードから始まると述べています。しかし、新モデルの登場とともに、計画後の一発成功率は上昇しています。私は、近い将来、計画は独立した人間の介入ステップとしての役割をほぼ失い、モデルが自ら計画を立てるのが当たり前になると考えています。これは、計画自体が重要でなくなるわけではなく、モデルが十分に賢くなり、自律的に計画できるようになるからです。ただし、前提条件があります。第3〜6段階の作業をきちんと行っている場合に限ります。コンテキストがクリーンで、制約が明確で、ツールの記述が完璧で、フィードバックループが閉じているなら、モデルはあなたの監査なしに信頼できる計画を立てられるのです。そうでなければ、やはりあなたが計画を監督し続ける必要があります。

要は、計画は一つの実践として消えるわけではなく、形を変えるだけです。初心者にとっては、やはり第1・2段階の計画モードが入り口です。しかし、第7段階の複雑な機能では、「計画」はもはや詳細なステップのリストではなく、コードベースの探索やワークツリーでのプロトタイピング、解決策の空間を探る探索行為に近づきます。そして、ますます多くの場合、これらの探索はバックグラウンドのインテリジェントエージェントに任せることになります。

これは非常に重要です。なぜなら、信頼できる計画と実行を自動化できるなら、あなたは他の作業をしながら非同期に進められるからです。従来の「複数のタブを切り替えながら作業する」状態から、「仕事があなたの知らないうちに進んでいる」状態へと変わるのです。

Ralphループは、よく使われる入門パターンです。自主的なインテリジェントエージェントのループを何度も回し、PRDのすべての項目を完了させるまで続けるものです。各イテレーションごとに新しいコンテキストのインスタンスを起動します。私の経験では、Ralphループをうまく回すのは難しく、PRDの記述が不十分だったり曖昧だったりすると、最終的に逆効果になることもあります。ちょっと投げっぱなしの感じです。

複数のRalphループを並行して動かすことも可能ですが、起動するループが増えるほど、時間の大半は調整やスケジューリングに費やされます。あなたはもうコードを書いているわけではなく、むしろ中間管理者の役割です。エージェントのスケジューリングを自動化し、意図に集中できる環境を整える必要があります。

Dispatchは、3つのモデルを並列に起動し、5つのワーカーに仕事を振り分ける仕組みです。会話はシンプルに保たれ、エージェントは仕事をこなします。

私が最近よく使っているのはDispatchです。これは私の作ったClaude Codeのスキルで、会話を指揮センターに変えます。クリーンな会話を維持しつつ、ワーカーは隔離されたコンテキストで重い作業を行います。スケジューラーは計画・委任・追跡を担当し、メインのコンテキストは調整に使います。ワーカーが詰まったときは黙って失敗せず、明確な質問を投げかけます。

Dispatchはローカルで動作し、素早い開発やフィードバックに最適です。RampのInspectは、より長時間・自律的な作業に適しています。各エージェントセッションはクラウドのサンドボックスVM上で動き、完全な開発環境を持ちます。UIバグを見つけたPMがSlackで報告すると、Inspectが自動的に対応します。コストはインフラやスナップショット、セキュリティにかかりますが、その分スケールと再現性は圧倒的です。私は両方を併用することを推奨します。

この段階で意外なパターンもあります。異なるモデルを使い分けるのです。最良のエンジニアリングチームは、クローンの集まりではありません。メンバーそれぞれに得意分野や背景、強みがあります。同じことがLLMにも言えます。異なる後訓練を経たモデルは、性格や得意分野が異なり、Opusは実装、Geminiは探索、Codexはレビューといった役割分担が可能です。群知能のように見えますが、コードにおいてはこれが非常に効果的です。

また、実装者と評価者を分離することも重要です。これを怠ると、偏った結果になりやすいです。例えば、同じモデルが実装と自己評価を兼ねると、バイアスが入り、問題を見逃すことがあります。別のモデルや、評価用のプロンプトを用意した別インスタンスに評価させるのが良いです。これにより、信頼性が格段に向上します。

さらに、CIとAIの連携も進んでいます。インテリジェントエージェントが自律的に動き出せると、既存のインフラからトリガーを引くことも可能です。例えば、ドキュメントロボットがマージ後に自動的にドキュメントを更新したり、安全性のための自動レビューや依存関係のアップグレードも自動化できます。良いコンテキストとルール、ツール、フィードバックループがあれば、すべてが自律的に動き出すのです。

第8段階：自律型インテリジェントチーム

現時点では、誰も本当にこのレベルを完全に掌握しているわけではありません。これは最先端です。

第7段階では、LLMを調整しながらタスクを分配する仕組みでしたが、第8段階では、その制約を取り払います。エージェント同士が直接協調し、タスクを引き受け合い、発見を共有し、依存関係や衝突を解決します。すべてのやりとりは中央の調整者を経由しません。

Claude Codeの実験的なAgent Teams機能は、その一例です。複数のインスタンスが共有コードベース上で並行作業し、相互に直接通信します。Anthropicは16の並列インスタンスでLinuxのCコンパイラをゼロから構築しました。Cursorは数百のインスタンスを数週間動かし、SolidからReactへのコード移行やブラウザの自作などを実現しています。

しかし、問題もあります。階層構造がないと、エージェントは臆病になり、進展しません。Anthropicのエージェントは、回帰を防ぐCIパイプラインを導入しないと、既存の機能を壊し続けました。このレベルの実験を行う人たちは皆、同じことを言います。多エージェントの協調は非常に難しく、最適解はまだ見つかっていません。

正直なところ、モデルは多くのタスクにおいてこの自律性に十分に対応できているとは思えません。特に、コンパイラやブラウザの構築以外の、月面着陸レベルの大規模プロジェクトには、遅すぎるしトークンも多く消費します。経済的にも割に合いません（印象的ですが、成熟には程遠いです）。私たちの多くの日常作業には、第7段階が最も実用的なレバレッジです。第8段階が最終的に主流になる可能性はありますが、今は第7段階に集中しています（特にCursorのようなケースは例外です）。

【未定義の第？段階】

避けられない「次は何か？」という問いです。

もし、あなたがスマートなエージェントチームの調整をスムーズにできるなら、インターフェースはテキストだけにとどまらなくなるでしょう。音声対音声（あるいは思考対思考？）や、対話式のClaude Codeとのやりとりが自然な次のステップです。あなたのアプリケーションを見ながら、大声で一連の変更を指示し、それが目の前で実現していくのを見たいのです。

一部の人は、「一発で完璧に生成する」ことを追求しています。何を望むかを伝えれば、AIが一発で完璧に実現する、という前提です。しかし、これは私たち人間が何を望むかを正確に知っている、という仮定に基づいています。実際には、私たちは決して完全に理解していません。ソフトウェア開発は常に反復的ですし、これからもそうあり続けるでしょう。違いは、より簡単に、そして従来よりもはるかに高速に進められるようになることです。

では、あなたはどの段階にいますか？次の段階に進むために何をしていますか？

あなたはどの段階ですか？

あなたは通常、AIを使ってどのようにプログラミングタスクを始めますか？