AIエージェント工学の8つのレベル

AI のプログラミング能力は、私たちがそれを操る能力を超えつつあります。そのため、SWE-bench のスコアを上げようと必死に努力する多くの試みが、エンジニアリングのリーダー層が本当に気にしている生産性の指標と同期していないのです。Anthropic チームは 10 日で Cowork をリリースしましたが、同じモデルを使いながら POC（概念検証）さえ完成できないチームもあります——その違いは、あるチームが能力と実践の間のギャップを埋めた一方で、もう一方はまだ埋められていない点にあります。

このギャップは一晩で消えるものではなく、段階的に縮小されていきます。合計 8 つのレベルがあります。この記事を読んでいる多くの人々はすでに最初の数レベルを超えているかもしれませんが、あなたは次のレベルに達することを楽しみにしているはずです——なぜなら、1 レベル上がるごとに生産性は劇的に向上し、モデル能力の向上がその恩恵をさらに増幅させるからです。

あなたが気にすべきもう一つの理由は、複数人での協働効果です。あなたの生産性は想像以上にチームメイトのレベルに依存しています。あなたが 7 レベルの達人であっても、寝ている間にバックグラウンドで AI エージェントが複数の PR を作成してくれたとしても、コードリポジトリのマージには同僚の承認が必要で、その同僚がまだ 2 レベルで手動で PR をレビューしている場合、あなたのスループットはそこで止まってしまいます。つまり、チームメイトをレベルアップさせることは、自分自身のためにもなるのです。

多くのチームや個人と AI 支援プログラミングの実践について話し合った結果、私が観察したレベルの進化パス（順序は絶対的に厳密ではありません）は以下の通りです：

第 1 レベルと第 2 レベル：Tab 補完と AI エージェント IDE

この 2 つのレベルは、記録として残すために素早く通り過ぎます。自由に読み飛ばしてください。

Tab 補完はすべての始まりです。GitHub Copilot がこの運動の幕開けを告げました——Tab キーを押すだけでコードが自動補完されます。多くの人はすでにこの段階を忘れてしまっているかもしれませんが、新規参入者は最初からこれをスキップしている可能性さえあります。これは経験豊富な開発者にとって特に適しており、彼らはまずコードの骨格を組み立ててから、AI に詳細を埋め込ませます。

Cursor を代表とする AI 専用 IDE が状況を大きく変えました。これらはチャットとコードベースを接続し、ファイル横断での編集をはるかに容易にします。しかし、天井（限界）は常にコンテキストにあります。モデルが処理できるのは、それが見ている内容だけです。そして最もイライラするのは、正しいコンテキストを見ていないか、あるいは無関係なコンテキストを大量に見てしまっている点です。

このレベルにいる多くの人々は、選択したプログラミングエージェントのプランニングモードも試しています：大まかなアイデアを構造化された段階的な計画に変換し、LLM に提示してその計画を反復的に洗練させ、その後実行トリガーを発動します。この段階では効果は良好で、コントロールを保つ合理的な方法です。しかし、後のレベルでは、プランニングモードへの依存が徐々に減っていくことがわかります。

ここからが面白い部分です。コンテキストエンジニアリング（Context Engineering）は 2025 年の年間流行語となりました。これは、モデルがついに適切な量の指示を信頼して従うようになり、ちょうどよいコンテキストと組み合わせられるようになったからこそ概念として成立したのです。ノイズの多いコンテキストも、不十分なコンテキストと同じくらい悪いため、核心となる作業は各トークンの情報密度を高めることにあります。「各トークンは、プロンプト内での自分の位置のために戦わなければならない」——これが当時の信条でした。

同じ情報でも、より少ないトークンで——情報密度こそが王道です（出典：humanlayer/12-factor-agents）

実際には、コンテキストエンジニアリングがカバーする範囲は、多くの人々が認識しているよりも広範です。これにはシステムプロンプトやルールファイル（.cursorrules など）が含まれます。

現在ではもうあまり「コンテキストエンジニアリング」という言葉は聞かなくなりました。天秤は、よりノイズの多いコンテキストに耐え、より混乱したシナリオでも推論できるモデルへと傾いています（より大きなコンテキストウィンドウも役立ちます）。しかし、コンテキストの消費量がいまだに重要であることに注意してください。以下のシナリオでは依然としてボトルネックとなる可能性があります：

小規模モデルは文脈に対してより敏感です。音声アプリケーションでは通常、より小さなモデルが使用され、文脈のサイズは最初のトークン遅延とも関連しており、応答速度に影響を与えます。

トークンを大量に消費する要因です。Playwright などの MCP（Model Context Protocol：モデル・コンテキスト・プロトコル）や画像入力を使用すると、トークンが急速に消費され、Claude Code 内で予想よりも早く「セッション圧縮」状態に陥ってしまいます。

数十のツールを接続したエージェントでは、モデルが実際の作業を行う時間よりも、ツール定義を解析する時間に多くのトークンを費やすことになります。

よりマクロな視点での要点は、文脈エンジニアリングが消えたわけではなく、進化しているということです。重心は「悪い文脈をフィルタリングすること」から「正しい文脈を適切なタイミングで提供すること」へと移っています。この転換こそが、第 4 レベルへの道を開くものです。

文脈エンジニアリングは現在のセッションの改善に寄与しますが、複合エンジニアリング（Compounding Engineering：キエラン・クラッセンによって提唱された概念）は、その後のすべてのセッションを改善するものです。この理念は私や多くの人にとって転換点となりました——「勘でプログラミングすること」が単なるプロトタイピング以上の意味を持つことを認識させたのです。

これは「計画、委任、評価、蓄積」という循環です。タスクを計画し、LLM が成功するために十分な文脈を提供します。タスクを委任します。成果物を評価します。そして最も重要なステップ——学んだことを蓄積すること：何が有効で、何が問題を起こしたか、次はどのようなパターンに従うべきかを記録します。

複合循環：計画、委任、評価、蓄積——各ラウンドが次のラウンドをより良くする

魔力は「蓄積」のステップにあります。LLM は状態を持たない（無状態）です。もし昨日、あなたが明確に削除した依存関係を再導入してしまった場合、明日も同じことを繰り返すでしょう——除非你告诉它不要。

複合エンジニアリングを実践している人々は、LLM に提供される文脈に対して非常に敏感です。LLM がエラーを起こした際、彼らの直感的な反応は「モデルが悪い」ではなく、「文脈に何か不足していないか」を考えることです。まさにこの直感が、第 5 レベルから第 8 レベルへの実現を可能にしています。

第 3 レベルと第 4 レベルは文脈の問題を解決しますが、第 5 レベルは能力の問題を解決します。MCP とカスタムスキルにより、LLM はデータベース、API、CI パイプライン、デザインシステム、ブラウザテスト用の Playwright、通知用の Slack などにアクセスできるようになります。モデルはもはや単にコードベースについて考えるだけでなく、直接操作を行うことができるようになります。

MCP やスキルに関する優れた資料は既に多く存在するため、それらが何であるかについては詳細を繰り返しません。しかし、私がこれらを使用している例をいくつか挙げます。私たちのチームでは、PR 審査用のスキルを共有し、全員で継続的に改善しています（現在も進行中）。このスキルは PR の性質に応じて条件付きでサブエージェントを開始します。1 つはデータベースとの統合セキュリティをチェックする役割を持ち、もう 1 つは複雑度分析を行い、冗長性や過剰設計をマークする役割を持ち、さらに別の 1 つはプロンプトの健全性をチェックして、チームの標準フォーマットに従っているかを確認する役割を持ちます。また、linter と Ruff も実行します。

なぜ PR 審査スキルにこれほど多くのリソースを投入するのか？それは、エージェントがバッチ処理で PR を生成し始めると、人手によるレビューが品質のゲートではなくボトルネックとなるからです。Latent Space は説得力のある論点を提示しました——私たちがよく知るコードレビューはすでに死んだのだと。その代わりとなるのは、自動化され、一貫性があり、スキル駆動型のレビューです。

MCP に関しては、Braintrust MCP を使用して LLM が評価ログをクエリし、直接修正を行えるようにしています。また、DeepWiki MCP を使用することで、エージェントがドキュメントを手動で文脈に読み込むことなく、あらゆるオープンソースリポジトリのドキュメントにアクセスできるようにしています。

チーム内で複数のメンバーがそれぞれ同じ種類のスキルを個別に作成し始めたら、それを統合して共有レジストリとして整備する時期です。Block（致以慰问）には素晴らしい記事があります：彼らは内部のスキルマーケットを構築し、100 以上のスキルを保有するとともに、特定の役割やチーム向けにスキルパッケージを企画しています。スキルとコードは同等の扱いを受け、プルリクエスト、レビュー、バージョン履歴が適用されます。

もう一つ注目すべきトレンドとして、LLM が MCP（Model Context Protocol）ではなく CLI ツールをより多く利用するようになっています（しかもほぼすべての企業が独自のものをリリースしており、Google Workspace CLI や Braintrust も近日中に登場します）。その理由はトークン効率です。MCP サーバーは各ラウンドでツール定義全体をコンテキストに注入しますが、智能体（エージェント）がそれらを使用しているかどうかに関わらずです。一方、CLI では逆に、智能体が特定の命令を実行し、関連する出力のみがコンテキストウィンドウに入ります。私は agent-browser を多用しています。

続ける前に一息つきましょう。第 3 級から第 5 級は、その後のすべての基盤となります。LLM はある分野では驚くほど得意で、別の分野では驚くほど不得意です。これらの境界に対する直感を養ってから、その上にさらに自動化を積み上げる必要があります。もしコンテキストがノイズに満ちていたり、プロンプトが不十分または不正確だったり、ツールの説明が曖昧であったりすれば、第 6 級から第 8 級ではそれらの問題が単に増幅されるだけです。

第 6 級：Harness Engineering（ハルネスエンジニアリング）

コンテキストエンジニアリングはモデルが何を見るかに焦点を当てますが、Harness Engineering は智能体が人間の介入なしで確実に動作できるようにするための環境全体——ツール、インフラストラクチャ、フィードバックループ——の構築に焦点を当てます。智能体にはエディタだけでなく、完全なフィードバックループを提供します。

OpenAI の Codex ツールチェーン——智能体が自身の出力を照会、関連付け、推論できるようにする完全な観測性システム（出典：OpenAI）

OpenAI の Codex チームは、Chrome DevTools、観測性ツール、ブラウザナビゲーションを智能体ランタイムに統合し、スクリーンショットの取得、UI フローの駆動、ログの照会、自身の修正結果の検証を可能にしました。プロンプトを与えるだけで、智能体はバグを再現し、動画を記録し、修復を実行します。その後、アプリケーションを操作して検証し、PR を提出し、レビューフィードバックに応答し、マージを行います——判断が必要な場合のみ人間にエスカレートします。智能体は単にコードを書くだけでなく、コードがどのような効果を生むかを確認し、人間のように反復して改善していきます。

私のチームが行っているのは技術トラブルシューティングのための音声およびチャット智能体の開発ですが、私は converse というものを作成しました。

これらを支える核となる概念はバックプレッシャー（Backpressure）メカニズムです——これは自動的なフィードバック機構（型システム、テスト、リンター、pre-commit フックなど）であり、人間の介入なしに智能体がエラーを発見し修正できるようにします。自律性を求めるなら必ずバックプレッシャーが必要で、そうでなければ得られるのはゴミ生産機に過ぎません。この考え方はセキュリティ領域にも拡張されます。Vercel の CTO は、智能体、それらが生成するコード、そしてあなたの鍵は異なる信頼ドメインにあるべきだと指摘しています。なぜなら、ログファイルに埋め込まれたプロンプト注入攻撃が、すべてのものが同じセキュリティコンテキストを共有している場合、智能体に認証情報を盗ませる可能性があるからです。セキュリティ境界こそがバックプレッシャーであり、それは智能体が制御不能になった際に「何をしてはいけないか」を制約するものであり、「何をすべきか」だけを定めるものではありません。

完璧さよりもスループットのために設計します。すべての提出で完璧さを要求すると、智能体は同じバグに執着し、互いの修正を上書きし合います。より良いアプローチは、小さな非ブロッキングなエラーを許容し、リリース前に最終的な品質チェックを行うことです。人間の同僚に対しても私たちはそうしています。

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

エンジニアリングの另一半は、エージェントがあなたなしでコードリポジトリ内で自由にナビゲートできるようにすることです。OpenAI のアプローチは、AGENTS.md ファイルを作成することです。

これらすべてを構築した後に自然と浮かぶ疑問があります：もしエージェントが自分の作業を検証でき、リポジトリ内を自在に移動でき、あなたなしでエラーを修正できるなら、なぜあなたはまだ椅子に座っている必要があるのでしょうか？

念のため言っておきますが、まだ最初の数段階にいる方々には、以下の内容がSF（科学小説）のように聞こえるかもしれません（大丈夫です。ブックマークして、後で見直してください）。

Claude Code の生みの親である Boris Cherny 氏は現在もタスクの 80% を計画モードから開始しています。しかし、新しいモデルが世代ごとにリリースされるにつれて、計画を経た後の一発成功率は着実に上昇しています。私は、計画モードが独立した人間の介入ステップとして徐々に消えていく臨界点に近づいていると考えています。それは計画自体が重要ではないからではなく、モデル自身が十分に賢くなって計画を立てられるようになったからです。ただし、重要な前提条件があります：第 3 段階から第 6 段階までの作業が整っている場合のみです。コンテキストがクリーンで、制約が明確であり、ツール記述が完備しており、フィードバックループが閉じられている場合、モデルはあなたのレビューなしでも確実に計画を立てることができます。これらの準備が不十分な場合は、依然として計画を監視し続ける必要があります。

はっきりさせておくと、計画という一般的な実践が消滅するわけではありませんが、その形態は変化します。初心者にとっては、計画モードは依然として正しい入り口です（第 1 段階および第 2 段階で述べた通り）。しかし、第 7 段階の複雑な機能においては、「計画」とは分步されたアウトラインを書くことではなく、むしろ探索のように見えます：コードベースを調査し、worktree でプロトタイプ実験を行い、解決策の空間を探る。そして、ますます多くの場合、これらの探索をバックグラウンドエージェントが代行しています。

これは重要です。なぜなら、これこそがバックグラウンドエージェントの可能性を開く鍵だからです。もしエージェントがあなたの承認なしで信頼できる計画を生成して実行できるのであれば、あなたが他のことをしている間に非同期で動作させることができます。これは重要な転換点です——「複数のタブを同時に切り替えている」状態から、「あなたなしで作業が進んでいる」状態へと移行します。

Ralph ループは人気のある入門方法です：自主的なエージェントが、PRD（製品要件定義書）のすべての項目が完了するまでプログラミング CLI を繰り返し実行し、各反復ごとに完全に新しいコンテキストを持つ新しいインスタンスを起動します。私の経験では、Ralph ループをうまく回すのは容易ではなく、PRD 内の不十分または不正確な記述は最終的に裏目に出ます。これは少し「放り出して見守らない」スタイルが強すぎます。

複数の Ralph ループを並列実行することもできますが、エージェントを起動すればするほど、あなたが時間を費やしている場所が見えてきます：それらの調整、作業順序の割り当て、出力の確認、進捗の推進です。あなたはもうコードを書いていません——あなたは中間管理職になっています。スケジューリングを処理し、あなた自身が意図に集中できるようにするには、オーケストレーションエージェントが必要です。

Dispatch は 3 つのモデルを跨いで 5 つのワーカーを並列起動します——あなたのセッションは簡潔に保たれ、エージェントが作業を行います。

私が最近頻繁に使用しているツールは Dispatch です。これは私が作成した Claude Code のスキルで、あなたのセッションを指揮センターに変換します。あなたはクリーンなセッションに残り、ワーカーは隔離されたコンテキスト内で重労働を完了します。スケジューラーが計画、委任、追跡を担当し、メインのコンテキストウィンドウはオーケストレーションのために確保されます。ワーカーが行き詰まった場合、黙って失敗するのではなく、明確化のための質問を投げかけます。

Dispatch はローカル環境で動作するため、開発との密接な連携を重視する迅速な開発シナリオに最適です。フィードバックが速く、デバッグが容易で、インフラストラクチャのコストもかかりません。一方、Ramp の Inspect は補完的なソリューションであり、より長時間実行され、自律性の高いワークに適しています。各エージェントセッションは、完全な開発環境を備えたクラウド上のサンドボックス VM で起動されます。ある PM が UI のバグを発見し Slack でタグ付けすると、Inspect はあなたがラップトップを閉じた瞬間に引き継いで処理を開始します。その代償として、インフラストラクチャ、スナップショット、セキュリティにおける運用の複雑さがかかりますが、ローカルエージェントでは到底及ばない規模と再現性が得られます。私は両方（ローカルとクラウドバックグラウンドエージェント）を併用することを推奨します。

このレベルには、意外にも強力なパターンがあります：異なるモデルに異なる役割を割り当てることです。最高のエンジニアリングチームはクローン人間で構成されているわけではありません。メンバーはそれぞれ異なる思考様式、異なる訓練背景、異なる強みを持っています。同じ論理が LLM にも当てはまります。これらのモデルは異なる後学習を経ており、明確な性格の違いがあります。私は Opus を実装作業に、Gemini を探索的研究に、Codex をレビュー担当に割り当てるのが常です。その総合的な成果は、どの単一モデルが独立して働くよりも強力になります。これはコードにおける集合知と理解することもできます。

極めて重要なのは、実行者と審査者を分離することです。この教訓を私は何度も痛感しました：同じモデルインスタンスが実装と自己評価の両方を行う場合、バイアスが生じます。問題は無視され、すべてのタスクが完了したと報告されます——実際にはそうではありません。これは悪意によるものではなく、あなたが自分の試験に採点しないのと同じ理由です。別のモデル（またはレビュー専用プロンプトを持つ異なるインスタンス）に審査を任せてください。信号の質は劇的に向上します。

バックグラウンドエージェントは、CI と AI の融合への扉も開きます。一度エージェントが無人で実行可能になれば、既存のインフラストラクチャからトリガーできるようになります。ドキュメントロボットはマージのたびにドキュメントを再生成し、CLAUDE.md を更新するための PR を提出します。

まだ誰もこのレベルを完全に掌握していませんが、少数の人々がその方向へ進んでいます。これが現在のフロンティアです。

第 7 レベルでは、LLM をオーケストレーションして、中心輻射型（スター型）のモードで作業用 LLM にタスクを配信します。第 8 レベルはこのボトルネックを除去します。エージェント同士が直接調整し——タスクを引き受け、発見を共有し、依存関係をマーキングし、競合を解決する——すべてが単一のオーケストレーターを経由することなく行われます。

Claude Code の実験的機能「Agent Teams」は初期の実装例です：複数のインスタンスが共有コードベース上で並列して動作し、チームメンバーは各自のコンテキストウィンドウ内で実行され、直接相互通信します。Anthropic は 16 の並列エージェントを用いてゼロから Linux をコンパイル可能な C コンパイラを構築しました。Cursor は数百の並行エージェントを数週間稼働させ、ゼロからブラウザを構築し、自社のコードベースを Solid から React へ移行しました。

しかしよく見ると問題が見えてきます。Cursor が階層構造がないことに気づいたとき、エージェントは臆病になり、原地で回転して進展がありませんでした。Anthropic のエージェントは既存機能を次々と破壊し、回帰を防ぐ CI パイプラインを追加したことで改善されました。このレベルで実験しているすべての人が同じことを言います：マルチエージェントの調整は非常に難しい問題であり、まだ最適な解は見つかっていません。

率直に言って、モデルはまだ大多数のタスクにおけるこのような自律性の程度には準備ができていないと思います。たとえ知能があっても、コンパイラやブラウザの構築といった「月面着陸」級のプロジェクト以外では、依然として遅く、トークン消費も多すぎて経済的に成立しません（印象的ですが、成熟したとは到底言えません）。私たちの多くにとって日常的な作業においては、第 7 レベルこそが真のレバレッジポイントです。第 8 レベルが最終的に主流になることを意外に思いませんが、今は第 7 レベルに注力します（Cursor のような例外を除く——突破そのものが彼らのビジネスモデルですから）。

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

一旦你能熟练地编排智能体团队而没有太多摩擦，交互界面就没理由只停留在文本上了。语音对语音（也许是思维对思维？）与编程智能体的交互——对话式的 Claude Code，而不仅仅是语音转文字输入——是自然的下一步。看着你的应用，大声描述一连串改动，然后看着它们在你面前发生。

有一群人在追逐完美的一次性生成：说出你想要什么，AI 一步到位地完美呈现。问题在于这个前提假设我们人类确切地知道自己想要什么。但我们不知道。从来都不知道。软件开发一直是迭代式的，我认为它永远会是。只不过它会变得容易得多，远远超越纯文本交互，而且快得多。

所以：你在哪个等级？你在做什么来达到下一个？