📚 全体地図を見る
AIエージェントを5層に分解すると、製品評価ができるようになる
0. はじめる前に
B1で、エージェントのことを「LLMというエンジンを載せた自動車1台まるごと」と書きました。あそこでは5つの層を 概念だけ でスケッチしました。目標受け入れ、状態追跡、ツール使用、ループ、適応。自動車1台という比喩は感覚をつかむにはよいのですが、実際にエージェントを 分解して評価 しなければいけない段階に入ってくると、この比喩だけでは足りません。「この車がいい車なのか」を自動車1台という言葉では判断できないからです。
今回は、この5つの層を 実際の技術要素 に落としこみます。Tool use、state management、planning、reflection、multi-agent。名前が少し違うのは、技術ドキュメントで実際にこう呼ばれているからで、製品を分解するときにこの用語で入っていくほうがずっと早いからです。B1の5層を、技術者の語彙に翻訳したものだと考えていただくといいです。
この記事を読み終えると、こんなことができるようになります。
- Claude Code・Cursor・Devin・Auto-GPTを同じ基準で比較できる
- 誰かが「AIエージェントのソリューションを売ります」と来たときに、10個の質問で本当のレベルを測れる
- なぜAuto-GPTが2023年に失敗して、Claude Codeが2024〜2025年に実用化されたのかを構造で説明できる
B1を「待合室」とするなら、この記事は 「整備工場」 です。車をリフトに上げて、下に潜ってパーツを1つずつ外してみる作業です。少し長いですが、いっしょに潜ってみましょう。
1. B1の復習 — エージェントはエンジンではなく自動車
1段落で通り抜けます。B1でつかんだ感覚はこれでした。LLMの1回呼び出しは応答マシン、LLMをシステムの中に組み込むとエージェントになる。システムというのは、目標を受け取る窓口、これまでやったことを見るメーター、外に働きかける手足、失敗したらもう一度まわすループ、結果を見て次の行動を変える適応回路。この5つがかみ合って、ようやく自動車1台になる、という話でした。
これを技術者の語彙に置き換えると、こうなります。目標受け入れはプロンプト層なので単独で切り出すより他の層に溶かしこみ、状態は state management、手足は tool use、ループは autonomous loop、適応は reflection + planning。そしてもう1つ、複雑な作業を複数のエージェントで分担する multi-agent 層がつきます。この5つを、これから1つずつ整備工場のリフトに上げていきます。
2. Tool useを本当に分解すると
Tool useを遠くから眺めると「LLMが道具を使う」という1行ですが、近くに寄って分解すると JSONの往復5回 です。これをファストフード店のカウンター比喩で描いてみます。
ファストフード店に注文カウンターがあります。お客さん(LLM)はカウンターの向こうの厨房(外部ツール)に直接は入れません。お客さんができるのは 注文票 を書くことだけです。注文票には決まった様式があります。バーガーの種類、サイド、ドリンクの欄がきっちり分かれています。お客さんが自由な文章で「お肉をちょっと焼いてください」と書いたら厨房は読み取れません。カウンターはその 様式どおりに書かれた注文票だけ を厨房に渡します。厨房は注文を受けて料理を作り、トレーに載せて カウンターに戻します。カウンターはそのトレーをまたお客さんに見せて、お客さんはそれを受け取って「次に何を頼もうか」を考えます。
この全体がtool useです。LLMがお客さん、注文票の様式がJSON schema、カウンターがagent harness、厨房が実際の関数やAPI。場面ごとに分解していきます。
(1) ツール定義 — 注文票の様式を組む段階
エージェントを作る人が、LLMに「きみはこういうツールを使える」と前もって教えます。Anthropicのtool use公式ドキュメントを見ると、こういう形をしています。
{
"name": "get_weather",
"description": "特定の都市の現在の天気を取得します。現地時刻基準。",
"input_schema": {
"type": "object",
"properties": {
"city": {"type": "string", "description": "都市名(日本語または英語)"},
"unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
},
"required": ["city"]
}
}
この定義がプロンプトの一部としてモデルに注入されます。モデルはここから3つの情報を読みます。名前(このツールを呼ぶときに使う識別子)、説明(いつ使うべきか)、入力スキーマ(どんなパラメータを入れるか)。説明が雑だとLLMが見当違いの状況でこのツールを呼んだり、逆にこのツールが必要な状況で呼ばなかったりします。ツール定義がエージェント品質の半分、という言い方はここから出てきます。
(2) モデルの判断 — 次トークン予測がJSONを吐く地点
ここがいちばん不思議な地点です。LLMはもともと「次の単語の確率」マシンだとF1・F4で学んでいましたよね。それなのに、どうしてきれいなJSONが出てくるのか。
答えは少し拍子抜けです。JSONもただのトークンの連なり だからです。{ というトークンの次に " が来る確率が高く、その次に n a m e のようなトークンが来る確率が高く、その次にまた " が来る確率が高く。このパターンを何千万回も訓練されたモデルは、JSONを「自然な次トークンの流れ」として認識します。構造化された出力ではなく、構造のように見えるテキスト なのです。
ただこのままにしておくと、たまに変なJSONが出ます。かっこが閉じなかったり、キーが重複したり。そこで現代のエージェントフレームワークは constrained decoding という仕組みを使います。モデルがトークンを選ぶときに、「いまこの位置に来てもいいトークン」をスキーマに基づいて制限します。たとえば {"name": まで出ていたら、次には必ず文字列トークンが来るようにする、という具合です。こうすると、JSON形式が100%有効になります。代わりにモデルが出したかったトークンを出せなくすることになるので、品質が少し落ちる可能性もあります。このトレードオフを、各フレームワークが違うやり方で解いています。
Anthropicはここに tool_use という専用の出力タイプを作って、モデルがツールを呼びたいときに一般のテキストではなくこのタイプを吐くように別途訓練しました。OpenAIの function calling も同じアイデアです。GoogleのGeminiはまた少し違うフォーマットです。骨組みは同じでも、JSONのフィールド名や呼び出し方がAPIごとに違うので、フレームワークを乗り換えるときにこの部分を揃える必要があります。ここで LangChainのようなフレームワークがやってくれていること の大きな部分が、まさに3つのproviderのフォーマット差を隠してくれる、というところです。
(3) Harnessの実行 — カウンターが厨房に渡す段階
モデルが {"name": "get_weather", "input": {"city": "Tokyo"}} のようなJSONを吐いたら、これをagent harnessが受け取ります。Harnessはコードです。Pythonでも、TypeScriptでも。HarnessはこのJSONを読んで、あらかじめ登録しておいた get_weather 関数を探し出し、city="Tokyo" で実際に呼びます。ネットワークを叩こうが、DBを照会しようが、実際の行動はここで起きます。
大事なのは、LLMが直接関数を実行しているわけではない ということです。LLMは「この関数をこう呼んでください」と 依頼 するだけで、実際の実行はharnessがやります。この分離のおかげで、LLMが危険なことをやらないように止められます。Harnessが間で「この関数は許可、この関数は確認が必要、この関数は禁止」とフィルタできるからです。エージェントの安全性のかなりの部分が、このカウンター層で設計されます。
(4) 結果の再注入 — トレーがまたお客さんに渡る段階
関数が実行されて結果(例: {"temp": 14, "condition": "cloudy"})が出ると、harnessはこの結果をまたLLMの次の呼び出しに貼りつけます。このときに「さっきあなたが呼んだget_weatherの結果はこれですよ」という文脈でプロンプトに挟みます。Anthropic APIでは tool_result ブロック、OpenAIでは role: tool メッセージです。
LLMはこの結果を読んで 次の判断 をします。「東京は14度、曇りです」とユーザーに答えてもいいし、あるいは「曇りだから傘情報も探してみよう」と別のツールを呼んでもいい。この選択がエージェントの知能の正体です。
(5) 往復の繰り返し — 1回では終わらない
単純な質問なら往復1回で終わります。でも、実際の作業はほとんど 何回も往復 します。たとえば「うちのブログ最近3本を要約して」と言うと、最低でもこういう順番になります。1回目: ブログ一覧APIを呼ぶ。2回目: 各記事の本文を1本ずつ取ってくる(あるいは並列で)。3回目: 各本文を読んで要約文を生成する。この3回が裏で自動的にまわります。
この往復の積み重ねがcontext windowを食う というのが大事な点です。ツール呼び出し1回ごとに、リクエストのJSON + 結果のJSONがプロンプトに積まれていきます。長くなると、数万トークンがあっという間に埋まります。M2で扱ったlong-contextの話がこことつながります。エージェントのコンテキスト管理がなぜ難しいかが、tool useの往復構造から直接出てきます。
まとめると、tool useは JSONスキーマ + 往復実行 + 結果の再注入 です。これを知って見ると、エージェントが「道具を使う」という1文が、実際には5段階の往復装置なんだということが見えてきます。
3. State — 「これまでやったこと」をどこに置くか
状態管理はエージェントの 記憶の倉庫 の設計です。B1で「LLMには記憶がなくて、状態は外で管理する」と話しましたね。その「外」が具体的にどこなのか、整備工場のリフトに上げてみます。
3種類の保管場所
エージェントの状態は、たいてい3か所に分かれています。
(1) セッションコンテキスト(conversation history)。 いまの対話の中のメッセージたち。LLMを呼び出すたびに、これがまるごとプロンプトに貼りつきます。いちばん速くて、いちばん高い。100万トークンのコンテキストが可能だといっても、毎回100万トークンを貼りつけたら呼び出しコストが爆発します。ですので現代のエージェントは、セッションコンテキストを 要約して圧縮 したり、大事じゃないものを切り捨てる ロジックがついています。
(2) Workspaceディレクトリ。 作業中に作るファイルたち。エージェントが生成したコード、メモ、ログ、中間成果物がここに積まれていきます。Claude Codeは現在の作業ディレクトリをworkspaceとして使います。Devinは専用の仮想コンピュータの中にworkspaceを立てます。Cursorは開いているプロジェクトフォルダがworkspaceです。このworkspaceがあるかないか が、エージェントの作業規模を決めます。Workspaceがないエージェントは、一度の対話を超えた作業ができません。
(3) Scratchpadファイル。 エージェントが自分の考えを整理するために書くメモ帳。有名な例がClaude Codeの TODO.md パターンです。エージェントが複雑な作業を受けとると、まず「やるべきことリスト」をTODO.mdに書きます。それから1つずつチェックしながら進めます。途中で新しい仕事が出てきたら、TODO.mdに追加します。このファイルが、エージェントの短期プランを外に出した装置なのです。LLM本体に記憶がないので、「いま何をしていたっけ?」をファイルに外注したわけです。
この3つの保管場所の組み合わせを memory architecture と呼びます。B1の「状態追跡」層が、実際にはこの3保管場所の設計問題だったわけです。
Scratchpadの秘密
Scratchpadの話を、もう1段落だけ続けさせてください。なぜTODO.mdのようなファイルがエージェント性能を大きく引き上げるのか、ひと目では直感に結びつかないところがあります。短く言うと、計画を書く行為そのものが推論を引き上げます。
LLMは「Chain of Thought」という訓練のおかげで、中間の思考をテキストで吐き出すと 性能が上がります。2022年のGoogleのCoT論文がこれを見せました。同じ問題でも、「すぐ答えて」より「ステップごとに考えて」のほうが、正答率がずっと高い。ScratchpadにTODOを書くのは、このChain of Thoughtを ファイルに外部化した ものです。LLMが毎回の呼び出しで「いまのTODO状態」を読みながら、自然と前の推論の流れを引き継ぎます。
Beforeの状態を想像してみてください。Scratchpadがないエージェントは、各呼び出しが島のように切れています。「いま3ステップ中の2ステップ目だけど、次に何をすればいいんだっけ?」を毎回ゼロから再構成します。コンテキストが長い場合、前のほうが薄くなっていって、途中で脱線します。Afterはこうです。Scratchpadがあれば、エージェントがTODO.mdを最初の行で読んで、「ああ2ステップ目まで終わったんだな、3ステップ目に進めばいいな」をすぐに復元します。脱線率が目に見えて下がって、長い作業を最後までやりきる比率が上がります。
このBefore/Afterの差が実際に観察されるので、AnthropicがClaude CodeにTODO.mdパターンを「推奨ワークフロー」として埋め込みました。Cursorも最近のバージョンで似たようなplanning scratchpadを導入しています。State管理の核のコツを1つだけ持ち帰っていただくなら、これです。「エージェントに外部のノート帳を渡せ」。
4. Planning — 複雑な目標を細かく割る技法
エージェントが「このバグ直して」のような1文を受け取って、複数ステップに分解する能力、これがplanningです。Planningには歴史的にいくつかのパターンが出てきました。3つだけ見ていきます。
ReAct — 思考 → 行動 → 観察のサイクル
2022年にPrincetonとGoogleが出した「ReAct: Synergizing Reasoning and Acting in Language Models」論文が名前の由来です。Reasoning + Acting の略です。
構造はシンプルです。LLMが毎ステップで3つを出力します。Thought(いまの状況分析)、Action(どのツールを呼ぶか)、Observation(結果を見て何を学んだか)。そしてこの3行が繰り返されます。
たとえばこんな感じ。
Thought: ユーザーがバグ原因を聞いてきたから、まずログを見たほうがいい。
Action: read_file("logs/error.log")
Observation: "TypeError: undefined is not a function" エラーが3回繰り返されている。
Thought: undefinedエラーだから関数呼び出しのほうを見よう。スタックトレースのファイルを開こう。
Action: read_file("src/parser.ts")
Observation: 27行目で `data.parse()` を呼んでいるけれど、dataがnullでありうる。
Thought: nullチェックを追加すれば解決しそう。
Action: edit_file("src/parser.ts", ...)
Observation: 修正完了。テストを走らせよう。
ReActの強みは 思考を明示的に書く ところです。ただツールだけ呼ぶエージェントは、なぜそのツールを呼んだかを書きません。ReActはThoughtを義務的に書きます。これだけでも、LLMの推論品質が有意に上がるというのが論文の発見でした。さっきのscratchpadの話と同じ文脈です。思考を書くと、より良く思考するようになります。
Claude Code、Cursor、Devinは内部的にReActパターンを基本ベースに使っています。それぞれ微妙なバリエーションはありますが、「Thought → Action → Observationの繰り返し」 という骨組みは共通です。
Plan-and-Execute — まず全体計画、次に実行
ReActは 1ステップずつ考えながら進む 方式です。長所は柔軟さ、短所は大きな絵を取り逃がしやすいところです。毎ステップで近視眼的に「いま何をしようか」だけを選んでいると、10ステップ先の目標を見失ってしまうこともあります。
Plan-and-Executeは逆の方向です。まず 全体計画 を立てて、それから計画どおりに実行します。2023年にLangChainがこのパターンをフレームワークとして定型化しました。
構造はこうです。最初のステップで Planner というLLM呼び出しが「この作業を終えるには次の10ステップが必要だ」を出力します。その次に Executor というLLM呼び出しが、1ステップ目から1つずつ実行します。各ステップが終わるたびにチェックして次に進みます。計画になかった状況が出てきたら、Plannerに戻って計画を立て直します。
長所は 大きな絵を見失わない ところです。10ステップの計画が立っているので、途中で脱線しても「いま自分がどのステップか」を計画書で復元できます。短所は 硬さ です。計画が間違っていたときに直すコストが大きく、短い作業にはオーバーヘッドが重い。
Devinがこのパターンを強く使います。DevinのUIを見ると、画面の片側に「Plan」という領域があって、10〜30ステップのチェックリストがリアルタイムで動いています。これがPlan-and-Executeの視覚的な実装です。
Hierarchical — 上位エージェントが下位エージェントに任せる
3つ目のパターンが 階層分解 です。上位エージェントは大きな作業を受け取って、サブタスクに分けて、各サブタスクを下位エージェントに渡します。下位エージェントが終わると、結果を上位に報告します。
たとえば「うちのブログ記事10本を分析してレビューレポートを書いて」という作業があるとします。階層分解はこうです。上位エージェントは「記事10本分析 → 共通パターン抽出 → レポート作成」の3つの大きな作業に分けます。最初の作業は 10個の下位エージェントを並列に 立てて、それぞれ1本ずつ分析させます。10個がすべて終わったら、結果をまとめて2つ目の作業に移ります。
このパターンの長所は 並列化 です。10本を順番にやると10倍の時間がかかりますが、並列にやれば1本分の時間で終わります。トークンコストは増えますが、総所要時間は短くなります。
Claude CodeのTask tool、LangGraphのsubgraph、AutoGenのgroup chatがこの階層分解を実装した例です。2025年以降、エージェント設計の主流がどんどんhierarchicalのほうに傾いています。作業の複雑度が上がるほど、1つのエージェントで全部やるのは限界がはっきりしてくるからです。
3つのパターンの選び方
実務ではこんなふうに混ぜます。小さな作業(5ステップ以内)には ReAct、複雑だけど予測可能な作業(翻訳、リファクタリング)には Plan-and-Execute、並列化が可能な大きな作業には Hierarchical。1つの製品の中に3パターンが全部混ざっていることもあります。Claude Codeは基本ループがReActで、複雑な作業ではTask toolでsubagentを立てるhierarchicalが乗っかります。
5. Reflection — 「いま出した答えは合っているのか」の確認ループ
Planningが「次に何をしようか」なら、reflectionは 「いま自分がやったことは合っているのか」 です。人にたとえれば、自己レビューにあたります。
Self-Critiqueパターン
いちばんシンプルなreflectionが self-critique です。LLMが答えを出したあとに、同じLLMが自分の答えを批判する 2回目の呼び出しをします。プロンプトはこんな感じ。「きみはいまこういう答えを出した。この答えに問題はないか、見逃していないか、間違っていないかを検討してみて。」
驚くのは、これが実際に機能するということです。同じモデルが同じ問題を2回見ることになるのですが、2回目のときは すでに答えがある状態で検討するタスク なので、性格が変わります。最初は白紙から答えを作るのに必死で見逃していたことを、2回目には「できあがった答えを監視する」立場でつかまえます。OpenAIのo1のような推論モデルは、内部的にこのself-critiqueを何百回もまわすことを、訓練段階で学習させられています。
Verification Loop
もう少し洗練された形が verification loop です。エージェントが作業を終えて「完了」と宣言する前に、検証ステップ を強制的に通します。
コーディングエージェントの場合、典型的なverificationはこれです。コードを直した? → テストを走らせて → テストは通った? → 通ったら完了、失敗したらまた直して。このループがreflectionです。単なる「自分が書いたコードは合っていると思う」という自己確信ではなく、外部のシグナル(テスト結果) で検証するわけです。
いいエージェントはverificationが 複数層 で設計されています。Type check、unit test、integration test、lint、manual review。各層を通過しないと次に進めません。Claude Codeがコードを修正したあとに自動で npm test や pytest を走らせるのは、このverification loopを踏むためです。
Retry Trigger
Reflectionは「失敗を検出したらretry」と対になって動かないと意味がありません。検出だけして直さなかったら、ただログを残すだけになってしまいます。Retry triggerは、検証が失敗したときに自動でもう一度試す仕組みです。
ここに設計のポイントがあります。無限retryは危険 です。同じやり方で10回retryしたら10回失敗してお金だけ飛びます。いいretryは 違うやり方で試します。最初の失敗のあとにLLMに「さっきはこうやったら失敗したよ、別のアプローチを試してみて」と、失敗原因を含めてプロンプトをもう一度飛ばします。これがB1の「適応(adaptation)」層の正体です。Reflectionが失敗を検出して、retryが違うやり方でまたまわります。
このreflection層が、次回のM5 Evaluation にそのままつながります。Evaluationはエージェントを 外から 評価するフレームワークで、reflectionはエージェントが 内で 自己検証する仕組みです。どちらも同じ根っこから出発しています。「答えが合っているかをどうやって知るか」という問いです。
6. Multi-Agent — 複数のエージェントで役割分担
最後の層がmulti-agentです。B1にはなかった層です。B1は「1台の車」の話でしたが、現実には 複数の車が協業する 構造もよく使われます。
なぜ複数のエージェントに分けるのか
1つのエージェントに全部の役割をやらせると、プロンプトが肥大化 します。「きみは企画者であり開発者でありテスターでありレビュアーだ」と書くと、LLMが毎瞬間「いま自分の役割は何だっけ?」を確認しなおさなければいけません。これが品質を下げます。
逆にエージェントを役割ごとに分けると、各エージェントの システムプロンプトが明確 になります。企画者エージェントは企画だけ、開発者エージェントは開発だけ、レビュアーエージェントはレビューだけ。それぞれが自分の仕事に集中してちゃんとやれます。Claude Codeでsubagentを立てるときに「このsubagentはファイル検索だけをやる役割」のような狭いプロンプトを渡すのは、このためです。
代表的な実装
Claude subagent. AnthropicのTask toolがこの概念をフレームワークに埋め込みました。上位エージェントが「この作業をするsubagentを立てて」と要請すると、別のコンテキストで下位エージェントがまわります。下位エージェントが終わると、結果だけが上位に戻ってきます。コンテキストが隔離されるのが核です。下位エージェントの中間思考が上位のコンテキストを汚染しません。
CrewAI. 2024年に出てきたフレームワークです。複数のエージェントに「役割、目標、ツール」を指定して、チームに束ねて働かせます。たとえば「リサーチャー、ライター、エディター」の3エージェントを作って「このテーマでブログ記事を書いて」と指示すると、3人が自分の役割どおりに協業します。UXが直感的なので、プロトタイプに人気があります。
LangGraph. LangChainが作ったmulti-agentフレームワークです。エージェント間のフローを グラフ で定義します。どの条件でどのエージェントに渡すかを、ノードとエッジで描きます。もう少しエンジニアリング寄りのアプローチで、プロダクションに向いています。Auto-GPTが直線ループで死んだという教訓を受けて、「条件分岐ができるグラフ」に進化したものです。
どこで効いて、どこでオーバーエンジニアリングか
Multi-agentは両刃の剣です。効くのは 役割がはっきり分かれる作業 です。記事執筆(リサーチ → ドラフト → 編集)、コードレビュー(提案 → 批評 → 反映)、複雑な研究(探索 → 合成 → 報告)のようなものです。
オーバーエンジニアリングになる場合も多いです。単純な作業をわざわざ3つのエージェントに分けると、エージェント間のコミュニケーションオーバーヘッド が作業そのものより大きくなります。1つのエージェントが他のエージェントに「これが必要です」と伝えるメッセージを生成するのにトークンがかかって、受け取るエージェントがそれを解釈するのにまたトークンがかかります。単純な作業は1つのエージェントが最後までやるほうがずっと速いです。
現実のコツを1つ。最初は必ずsingle-agentから始めてください。Single-agentで詰まる地点がはっきりしたときに、その地点だけsubagentに切り分けてください。最初からmulti-agent構造を設計すると、複雑さだけ増えて実際の品質は上がらないケースが多いです。これはAnthropicのエンジニアが公開ブログで繰り返し強調するポイントでもあります。
7. 実際のエージェント製品を5層で分解してみる
ここから代表4製品を、この5層で分解してみます。まずは1行サマリーの表から。
| 製品 | Tool use | State | Planning | Reflection | Multi-agent |
|---|---|---|---|---|---|
| Claude Code | 強 | 強 (workspace + TODO) | 強 (ReAct + Task) | 強 (test-driven) | 中 (subagent可) |
| Cursor | 強 | 中 (プロジェクトインデックス) | 中 (Composer planning) | 中 (lint/type check) | 弱 |
| Devin | 強 | 強 (専用VM) | 強 (Plan-Execute) | 強 | 強 |
| Auto-GPT | 中 (不安定) | 弱 (ファイルベース) | 弱 (直線ループ) | 弱 (ほぼなし) | なし |
1製品ずつ肉づけしていきます。
Claude Code
Tool useはとても精巧です。Read、Edit、Write、Bash、Grep、Glob、Task のような基本ツールがあって、MCPで数十個がさらに追加されます。JSON schemaが厳密に定義されていて、permissionシステムで危険な行動をフィルタします。
Stateはworkspace(現在のディレクトリ) + セッション履歴 + CLAUDE.md という長期記憶ファイル + TODO.md scratchpad の4層の組み合わせです。CLAUDE.mdがプロジェクトごとのルールをLLMの外に置いて再注入されるので、セッションが切れてもプロジェクトの文脈が消えません。
PlanningはReActが基本で、複雑な作業ではTask toolでsubagentを立ててhierarchical分解が乗ります。「この仕事は自分ではできなさそうだ」と自分で判断してsubagentを立てる様子を見ていると、「こいつ本当に知能があるな」と感じる瞬間があります。
Reflectionはtest-drivenです。コード修正後に自動でテストを走らせて、失敗したらまた直すループが基本です。Lint、type checkもチェック段階に入ります。
Multi-agentはsubagentパターンがありますが、Devinのように完全に独立したエージェントチーム構造ではありません。中くらいの水準です。
Cursor
Tool useは強いです。ファイル編集、ターミナル、検索のような基本ツールがエディタに直接統合されています。
Stateはプロジェクトインデックス(ファイル埋め込み)とセッション履歴が中心です。Claude CodeのCLAUDE.mdに対応する長期記憶装置は .cursorrules ファイルですが、運用の深さはClaude Codeほどではありません。
PlanningはComposerに簡単なplanningが入っています。複雑な作業を受け取ると、複数のファイルを順番に編集する計画を立てます。ただし、hierarchical分解や明示的なPlan-and-Executeは弱いです。
Reflectionは編集結果をlint、type checkで検証する機能はありますが、test-drivenループがClaude Codeほど強制されているわけではありません。Cursorは開発者が直接見ながら使う製品なので、reflectionの一部を開発者に任せる設計です。
Multi-agentはほとんどありません。複数エージェントの協業構造はCursorの主眼ではありません。
Devin (Cognition)
Tool useは自前のVM環境の中でブラウザ、エディタ、ターミナルを全部ツールとして使います。視覚的に「Devinがブラウザを開くのが見える」のが大きな差別化ポイントです。
Stateは 専用の仮想マシン を作業ごとに立てます。このVMがworkspaceであり、長期記憶の保管場所でもあります。作業が数日にわたってもVMが生きているので、状態が保たれます。
PlanningはPlan-and-Executeが強いです。UIに10〜30ステップの計画が見えて、リアルタイムでチェックが入っていきます。
Reflectionはステップごとに検証ステップが入ります。コード修正後にテスト、UI変更後にスクリーンショット比較、といった具合に。
Multi-agentは内部で複数のエージェントが協業する構造です。企画、実行、レビューが分かれていると知られています。
短所は 高い ことです。VMを作業ごとに立てるので、トークンコストの上にインフラコストが乗って、サブスクリプションが高くなります。品質は高いですが、コスト対効果の合理性はユーザーによって評価が分かれます。
Auto-GPT (2023年の初期失敗ケース)
Auto-GPTは2023年3月に公開されて、GitHubで数十万スターを獲得しました。完全自律エージェント という概念を大衆に初めて見せたプロジェクトです。ただ実際に使った人のほとんどは「なんかうまくいかない」という印象を受けました。なぜそうだったかを、5層で診断してみます。
Tool useは 不安定 でした。当時はGPT-4のfunction callingが出る前だったので、LLM出力を正規表現でパースしてツールを呼んでいました。パース失敗が多くて、見当違いの関数を呼ぶことが頻繁にありました。
Stateは 浅かった です。ローカルファイルに簡単に記録はしていましたが、workspaceの概念がはっきりしていませんでした。セッションが長くなると、エージェントが「自分が何をしたのか」をよく取り違えました。
Planningは 直線ループ でした。ReActのように1ステップずつまわりながら「次に何をしようか」だけを選んでいました。Plan-and-Executeもhierarchicalもありませんでした。そのため、大きな作業を渡すと5分以内に脱線して見当違いの方向に進みました。
Reflectionはほぼ ありません でした。Verification loopもretry triggerもちゃんとなくて、エージェントが「いま自分は正しい方向に進んでいるか?」をチェックする仕組みが貧弱でした。
Multi-agentは 完全にありませんでした。1つのエージェントで全部やろうとしていました。
この5層がすべて貧弱だったので、失敗は当然でした。ただしAuto-GPTは 概念実証 としてはものすごい役割を果たしました。2023年以降のすべてのエージェントフレームワークが「Auto-GPTがなぜうまくいかなかったか」を教訓にして、各層を補強する方向に進化しました。Claude CodeもDevinもLangGraphも、みんなAuto-GPTの失敗の上に立っています。
8. なぜAuto-GPTは失敗して、Claude Codeは成功したのか
同じ問いを逆から見ます。Auto-GPTが2023年に失敗したことが、2025年のClaude Codeにどんな教訓を残したのか。5層を比較すると 5層すべて で差が出てきます。
Tool useの安定性。 Auto-GPTは正規表現パース、Claude CodeはAnthropic APIのtool_use専用タイプ。フォーマットエラー率が桁違いです。構造化されたfunction callingが標準になったことが、エージェント実用化の静かな革命でした。
Stateの深さ。 Auto-GPTはファイルメモ、Claude Codeはworkspace + CLAUDE.md + TODO scratchpad + セッションコンテキストの4層。記憶の耐久性が違って、長期作業の脱線率が違います。
Planningの構造化。 Auto-GPTは直線ReAct、Claude CodeはReAct + subagent + task decompositionの組み合わせ。作業の複雑度に合わせて、planningの深さが適応的に変わります。
Reflectionの存在。 Auto-GPTはほぼなし、Claude Codeはtest-drivenループ + lint + type check。「いま出した答えが合っているか」を外部シグナルで検証し続けます。
Toolの安全性。 Auto-GPTは権限管理がほぼなかったので、危険なコマンドもそのまま実行しました。Claude CodeはPermissionシステムで、ファイル削除やforce pushのようなものはユーザー確認を取ります。これがエージェントのプロダクション導入を可能にした要素です。
まとめると、Auto-GPTは 5層のどれも十分に深くありませんでした。Claude Codeは5層すべてを丁寧に設計しました。同じ基本アイデア(LLM + ツール + ループ)の上で、各層のエンジニアリング品質が実用化の分岐点だったわけです。モデルがGPT-3.5からClaude 4.7に上がったのも当然大きな影響ですが、harness設計の成熟 がそれと同等かそれ以上の比重を占めます。この話がM4につながります。
毎週月曜日、AIトレンドニュースレター配信中
会員登録すると、毎週月曜日に「今週のAI・バイブコーディング最新情報」をお届けします。
バナー広告なし・本当に役立つ情報だけを厳選するクリーンなAI専門メディアです。
9. エージェント製品を評価するときに聞くべき10の質問
会長がエージェント製品を導入したり評価したりするときに、すぐに使えるチェックリストです。B1の5つの質問をもう少し具体化した10個です。各質問が、上で扱った5層のどこに当たるかも示しておきます。
1. Tool use — このエージェントは私のツールを使えるか?
→ MCPのような拡張プロトコルをサポートしているのか、それともbuilt-inツールだけなのか。自分の環境に合うツールを追加できる道があるか。
2. Tool use — ツール呼び出しの失敗率はどれくらいか?
→ ベンダーに直接聞いてみてください。10%を超えるならプロダクションに使うのは危険です。ちゃんと作ったエージェントは1〜2%以下です。
3. State — セッションを再開したときに前の文脈が保たれるか?
→ わざとセッションを切って数日後にまた開いてみてください。「前回は何をしていたか」をエージェントが覚えているかが、state品質の直接の証拠です。
4. State — ScratchpadやTODOのようなノート帳があるか?
→ エージェントが自分の計画をファイルに書くかを見てください。あれば長い作業の脱線率が低いです。
5. Planning — 複雑な作業を受け取ったときに、まず計画を見せてくれるか?
→ 10ステップの作業をさせてみてください。すぐ1ステップ目を始めるエージェントより、先に計画を見せて確認を取るエージェントのほうが信頼できます。
6. Planning — 中間結果が見えるか?
→ エージェントが動いているあいだ、内部状態がリアルタイムで見えるか。ブラックボックスで結果だけ吐くエージェントは、失敗原因の追跡が難しいです。
7. Reflection — 失敗したらもう一度試すか?
→ わざと失敗ケースを投げて観察してください。すぐ「失敗しました」と吐いて終わるなら、エージェントと呼ぶには足りません。
8. Reflection — Verificationは何でやっているか?
→ テスト、lint、外部APIの結果、スクリーンショット比較のうち、何がverificationシグナルとして使われているか。自己確信だけで「完了」を宣言するエージェントは危険です。
9. Multi-agent — Subagentを立てられるか?
→ 常に必要なわけではありませんが、複雑な作業にsubagentオプションがあると、拡張性があります。
10. 全体 — このエージェントのharnessは誰が設計したのか?
→ B1でも聞いた質問です。エージェント設計の経験があるチームなのか、それともただのAPI wrapperレベルなのか。答えで「OpenAI/Anthropic APIにプロンプトをくっつけました」くらいだと、数か月後に競争力が弱くなります。
この10個を投げれば、ほとんどの「エージェント」製品がどのレベルなのかが、すぐに見えてきます。特に2番(ツール失敗率)、4番(scratchpad)、8番(verificationシグナル)がいちばん鋭い質問です。この3つは、設計が本当に深いチーム だけが答えられます。
10. エージェントはなぜharnessなしには生きられないのか — M4予告
5層を全部分解してみると、見えてくるものがあります。この5層すべてが LLMの外側で 動いています。Tool useのJSON往復、stateの保管場所管理、planningの計画策定、reflectionの検証ループ、multi-agentのオーケストレーション。これらはLLM本体がやっているのではなく、LLMを取り巻くコード がやっています。
この「取り巻くコード全体」が harness です。B1でも触れましたが、今回を経てもっとはっきりしました。エージェントの品質は、モデルがどれだけ良いかよりも、harnessがどれだけ精巧か で決まります。同じClaude Sonnet 4.7を使っても、Claude CodeとAuto-GPTはまったく違う結果を出します。差はharnessにあります。
次回のM4では、このharnessを直接分解します。ツール定義をどう書くか、permissionシステムをどう設計するか、コンテキストをどう圧縮するか、sandboxと隔離をどうするか。エージェント製品評価の質問10番(「このharnessは誰が設計したか」)に直接答えられるようになります。エージェントを 自分で作る 方や 競合製品を分解してみたい 方にとっては、M4がいちばん実戦向きの回になるはずです。
閉じのひとこと
エージェントはtool use・state・planning・reflection・multi-agentという5層で構成されたシステムで、Claude CodeとAuto-GPTの運命を分けたのも、結局はこの5層それぞれのエンジニアリングの深さでした。この5層をチェックリストとして持っていれば、どんなエージェント製品もフェアに評価できます。次回はこの5層を支える harnessそのものの設計原理 に入っていきます。
次に読むなら
- M4 — Harnessがagentをagentにする仕組み [準備中]
- M5 — Evaluationがagent品質を数値にする仕組み [準備中]
シリーズの最初から: F1 — LLMとは何か ・ B1 — AgentがLLMと分かれる瞬間 ・ M2 — Long-contextとMemory
FAQ
Q1. Tool useとfunction callingは同じ言葉ですか?
ほぼ同じ言葉です。OpenAIが2023年に function calling という名前でAPIに先に導入して、Anthropicが似た機能を tool use という名前で出しました。概念は同じです。「LLMがJSONでツール呼び出しを要請して、外部コードが実行後に結果をLLMに返す往復構造」です。最近は tool use のほうがより一般的な用語として定着しつつあります。「function」がプログラミング関数に限定された印象なのに対して、「tool」は検索、計算、API呼び出し、さらには別のエージェント呼び出しまで包括する上位概念だからです。
Q2. ReActとChain of Thoughtはどう違いますか?
Chain of Thought(CoT)は LLMが答えを出す前に中間の思考を書くよう誘導する プロンプト技法です。「ステップごとに考えてみて」と指示すると、モデルが思考を書きながら問題を解きます。ReActはCoTに ツール使用(Acting) を結合したものです。CoTが「思考だけ」をするなら、ReActは「思考して、ツールを呼んで、結果を見て、また思考」を繰り返します。エージェント環境ではCoTだけでは足りなくて、ReActが必要です。外の世界とのやり取りがなければ、エージェントとは呼べないからです。
Q3. Multi-agentを初めて導入するなら、どのフレームワークがいいですか?
用途によって変わります。すばやくプロトタイプを作りたいならCrewAI。役割指定が直感的で、ドキュメントがしっかりしています。プロダクション水準のエンジニアリングが必要ならLangGraph。グラフベースなので、条件分岐、エラーハンドリング、デバッグがきれいです。Claudeエコシステムにすでにいるなら、ClaudeのTask tool。別のフレームワークなしでsubagentを立てられて、コンテキスト隔離が自動です。最初は必ずsingle-agentから始めて、single-agentで詰まるポイントがはっきりしてきたら、必要な部分だけmulti-agentに拡張するのが賢いです。最初からmulti-agent構造を設計すると、複雑さが品質より早く増えてしまいます。
- ◀ 前の編: M2. Long-contextとMemoryが分かれる地点
- 今の編: M3. エージェント深化 — 5層に分解する (13/20)
- ▶ 次の編: M4. Harnessがagentをagentにする仕組み
ニュースレターのご案内
こうしてエージェント製品を分解して評価するような深化編を、毎週月曜日の朝にメールでお届けしています。受け取ってみたい方は ニュースレター登録(無料・30秒) からどうぞ。
シリーズ案内
– F1〜F6: LLM基礎編
– B1: AgentがLLMと分かれる瞬間
– B2〜B6: Agent深化基礎編
– M1: Retrieval Layer
– M2: Long-contextとMemory
– M3: Agent深化 — 5層に分解する(この記事)
– M4: Harness Engineering [次]
– M5: Evaluation
– M6: Context Management
– (以下20編まで)
著者: バイブコーディング テイラー(Lovable公式アンバサダー)
運営: テイラーの隠れ家(shuntailor.net)
Agent製品評価の感覚の位置にある編です。前後編のリンクは記事下部のマップ上の現在地ボックスで確認してください。
Agentを5層に分解すれば、Claude Code·Cursor·Devin·Auto-GPTがなぜ違う結果を出したかが正確に見えます。10項目評価チェックリスト。
ソースリスト
- テイラー知識百科事典 — AIのしくみ地図カテゴリ（本シリーズ20編全編）
- AIのしくみ地図 エントリーマップ — 全体構造 + 3つの読み方
- “Attention Is All You Need” (Vaswani et al., 2017)
- Anthropic · OpenAI · Google 公式ドキュメント
- mathbullet (YouTube) / Jay Alammar “Illustrated Transformer” / 3Blue1Brown — 易しい解説のリファレンス
著者: バイブコーディング テイラー (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ「AIのしくみ地図」20編は、ウィキの蓄積と公式論文・公式ドキュメントを根拠に整理した体系的学習カリキュラムです。
