編集 | 雲昭
OpenAIとMicrosoftは誤ったAgentの理念を宣伝している！OpenAIのSwarmは「誤った道」を進んでいる！
先週末、Devinの共同創設者であるWalden Yanが投稿した内容が業界の注目と議論を呼び、驚きを誘いました。
Walden Yanは投稿でまず、含みを持たせて述べました：
多くの人がエージェントを構築する際に同じ過ちを犯しているのを目にするので、私たちが普段使っている原則をいくつか共有します。
その後、ブログ記事でOpenAIとMicrosoftを名指しし、両社が提供するSwarmとAutoGenというオープンソースライブラリが誤ったエージェント構築の理念を積極的に推進しており、特に両社が推奨するマルチエージェントアーキテクチャの構築方法が間違っていると明確に指摘しました！
Yanは記事の冒頭で率直に批判しました：
「（現在市場に出回っている）マルチエージェントフレームワークは、期待を下回る性能です。私たちの試行錯誤の経験に基づき、エージェント構築の原則をいくつか共有し、一見魅力的に見える構想が、なぜ実際にはひどい結果になるのかを説明したいと思います。」
この記事は、Devinの視点から、業界におけるエージェント構築の現状を明らかにしています。マルチエージェントはクールに見えますが、2年以上経っても、基本的なパターン以外では、いまだに手探りの状態です。
エージェント構築において、私たちはまだ「原始的なHTML + CSS」時代にいます！本当の生産レベルの環境は、まったく別の話です！
Yanはブログ記事でその理由を説明し、現在の大規模モデルエージェントには安定した長文コンテキスト協調対話能力がなく、そのためメインエージェントとサブエージェントの並列作業は根本的に不可能であると指摘し、「共有コンテキスト原則」と「行動は意思決定を意味する」という2つの核となる原則の重要性を提案しました。
さらに、Yanはいくつかの強力な証拠を挙げました。例えば、Claude Codeはサブタスク能力を持つエージェントですが、メインエージェントとサブエージェントを並列で実行することはありません。サブエージェントは通常「質問に答える」だけで、コードを書くことには関与しません。
これは、OpenAIやMicrosoftに「喧嘩を売っている」わけではなく、皆さんに多くの真実を提供していると言えるでしょう。
前置きはこれくらいにして、早速原文をお届けします。
背景説明
Devinは、ChatGPT登場以来、最も早く世に出たAIプログラミングエージェントと言えるでしょう。最近、Devinチームは、実際には市場に出回っているマルチエージェントフレームワークの性能が期待をはるかに下回っていることを発見しました。
多くの開発者は、複雑なタスクを複数の並行作業を行うサブエージェントに分解することで効率を高めるマルチエージェント（Multi-Agent）アーキテクチャに自然と惹かれます。しかし、この一見効率的なアーキテクチャは、実際には非常に脆弱であり、コンテキストの共有不足や意思決定の衝突によってシステム全体が失敗しやすいのです。
Yanは述べました：「私たちの試行錯誤の経験に基づき、エージェント構築の原則をいくつか共有し、一見魅力的に見える構想が、なぜ実際にはひどい結果になるのかを説明したいと思います。」
OpenAIとMicrosoftが誤った理念を唱えている
現在のエージェントはまだ
「HTML + CSS」のつぎはぎ時代にある
「マルチエージェントフレームワークの性能は期待をはるかに下回っています。私たちの試行錯誤の経験に基づき、エージェント構築の原則をいくつか共有し、一見魅力的に見える構想が、なぜ実際にはひどい結果になるのかを説明したいと思います。」
この記事では、以下の2つの核となる原則を段階的に導き出します：
コンテキストの共有
行動は意思決定を意味する
なぜ「原則」に注目するのか？
HTMLは1993年にリリースされました。2013年、FacebookはReactを発表しました。2025年までに、Reactとその子孫はウェブサイトとアプリの開発方法をほぼ支配しています。なぜでしょうか？ Reactは単なるコーディングの足場ではなく、哲学だからです。Reactを採用すれば、レスポンシブでモジュラーな構築パラダイムを受け入れることになります。これは、初期のウェブ開発者にとっては自明ではありませんでした。
今日、大規模モデルに基づくAIエージェントの構築分野では、私たちはまだ「原始的なHTML + CSS」時代にいます。つまり、良い体験を作り出すために、さまざまなコンポーネントをどのように組み合わせればよいのか、まだ手探りしている段階です。これまでのところ、最も基本的なパターン以外には、真の業界標準となるエージェント構築方法はまだありません。
さらに悪いことに、OpenAIのSwarmやMicrosoftのAutogenのようなライブラリは、私たちが間違っていると考えるアーキテクチャ、つまりマルチエージェントアーキテクチャを積極的に推進しています。なぜこれが「誤った道」なのかを説明します。
もちろん、初心者の方には基本的な構造を構築するのに役立つリソースがたくさんありますが、真剣な生産レベルのアプリケーションを構築するのは、まったく別の話です。
長期間稼働するエージェントの構築
なぜコンテキストエンジニアリングが必要なのか
信頼性から始めましょう。エージェントが長期間稼働し、一貫した対話と行動を維持する必要がある場合、誤りの段階的な蓄積を防ぐための何らかのメカニズムを採用する必要があります。さもなければシステムはすぐに崩壊します。これらすべての核となるのが、私たちが「コンテキストエンジニアリング」と呼ぶものです。
2025年までに、大規模モデルは非常に賢くなっています。しかし、最も賢い人でさえ、コンテキストがなければ効率的にタスクを完了することはできません。
「プロンプトエンジニアリング」という用語は、もともとタスクプロンプトを手動で設計することを指しました。一方、「コンテキストエンジニアリング」はその発展版であり、動的システムにおいてコンテキストを自動的に構築することに重点を置いています。これはAIエージェントを構築する上で最も重要なエンジニアリングタスクです。
一般的なアーキテクチャの例：
メインエージェントがタスクを複数の部分に分解する
サブエージェントにそれぞれ実行を割り当てる
最後に、各サブタスクの結果を統合する
この方法は、並行コンポーネントを持つタスクには魅力的に見えますが、実際には非常に脆弱です。
たとえば、「Flappy Birdゲームのクローンを構築する」というタスクがあるとします。これを2つのサブタスクに分解します：
サブタスク1：背景と緑色のパイプを作成する；
サブタスク2：上下に飛べる鳥を作成する。
しかし、サブエージェント1は間違ってスーパーマリオ風の背景を作成し、サブエージェント2が作成した鳥はゲームアセットのスタイルに合致しないだけでなく、動作もおかしいです。最終的にメインエージェントがこれら「ちぐはぐな」結果を無理やり組み合わせると、ほぼ壊滅的な事態になります。
これはでっち上げではなく、現実世界のタスクはしばしば詳細と曖昧さに満ちています。そして、「元のタスクコンテキストもサブエージェントに送れば解決する」と思うかもしれませんが、それだけでは不十分です。なぜなら、実際のシステムは複数のラウンドの対話やツール呼び出しが混在しており、どんな些細な詳細でもタスクの理解に影響を与える可能性があるからです。
原則1：コンテキストを共有する、メッセージだけでなく、完全なエージェントの軌跡（trace）を。
システムを再設計し、各サブエージェントが前のエージェントのコンテキストの軌跡をすべて持つようにします。
しかし、問題はまだ終わっていません。同じタスクを与えた場合、今回は完全に一貫性のないスタイルで背景と鳥が作成される可能性があります。なぜでしょうか？サブエージェント間では互いの作業過程が見えないため、互いに矛盾する暗黙の前提を想定してしまうからです。
原則2：行動は意思決定を意味し、意思決定の一貫性の欠如は誤った結果につながる。
強調したいのは、原則1と原則2が極めて重要であり、ほとんど破られるべきではないということです。
これらの原則に違反するいかなるアーキテクチャも、デフォルトで排除されるべきです。
これでは制約が多すぎると感じるかもしれませんが、実際には探求すべきアーキテクチャ設計の空間はまだたくさんあります。例えば、最も単純な方法の一つである線形単一スレッドエージェントです。
利点はコンテキストが連続していることです。問題は、タスクが膨大でコンテキストウィンドウが溢れると、問題が発生することです。
改善策はあるでしょうか？もちろんありますが、より複雑になります。
正直なところ、シンプルなアーキテクチャで十分ですが、本当に長期的なタスクを処理する必要があり、努力を惜しまない人にとっては、さらに良いものが作れます。この問題を解決する方法はたくさんありますが、今日はより強力な長期間エージェントを構築する一つの方法だけを紹介します。
私たちは、履歴コンテキストを「圧縮」し、重要なイベント、意思決定、情報に精製するために、専用のLLMモデルを導入します。これは非常に困難な作業であり、何が本当に重要な情報であるかを理解し、精製に長けたシステムを構築する必要があります。
時には、この作業のために小さなモデルをファインチューニングする必要さえあります。Cognitionでは、このような作業を行いました。
その利点は、より長期間にわたってコンテキストの一貫性を保つことができることです。最終的には限界に達しますが、これは大きな前進です。
原則の実際の応用：
2つの優れたエージェント設計
エージェント構築者として、システム内のすべての行動が、既存の意思決定のコンテキストに基づいて実行されることを保証すべきです。
理想的な状態は、すべての動作が互いに可視であることです。しかし、コンテキストウィンドウとリソースの制約により、これは常に可能ではありません。そのため、「信頼性 vs システムの複雑さ」の間でトレードオフを行う必要があります。
以下にいくつかの実際の例を示します：
Claude Codeのサブエージェント設計
2025年6月現在、Claude Codeはサブタスク能力を持つエージェントです。しかし、メインエージェントとサブエージェントを並行して実行することはありません。サブエージェントは通常「質問に答える」ためにのみ使用され、コードを書くことには関与しません。
なぜでしょうか？サブエージェントにはメインエージェントのコンテキストが不足しているため、複雑なタスクをこなすことができません。複数のサブエージェントを実行すると、互いに矛盾する答えが得られる可能性が高いでしょう。
この設計の利点は、サブエージェントのクエリがメインエージェントの履歴を汚染せず、メインエージェントがより長いコンテキストの軌跡を保持できることです。
Claude Codeの設計者は、意図的にシンプルで信頼性の高い設計を選択しました。
編集適用モデル (Edit Apply Model)
2024年、多くのモデルはコードの変更が苦手でした。そこで「編集適用モデル (Edit-Apply Model)」という手法が流行しました：
大規模モデルが「Markdown形式」の変更説明を生成する
小規模モデルがその説明に基づいて、コードファイル全体を書き換える
これは、大規模モデルが直接コード差分を出力するよりも信頼性がありましたが、問題もありました。小規模モデルが説明中の曖昧さを誤解し、誤った変更をしてしまう可能性があったのです。
2025年までに、より多くのシステムが「変更決定 + 変更適用」を単一のステップに統合し、単一のモデルで完結させることを選択し、全体の信頼性を高めました。
現在、マルチエージェントはコミュニケーションと協調に長けていない
あなたはこう思うかもしれません。「複数の意思決定者同士が『交流』し、人間のようにコミュニケーションを取り、合意に達することはできないだろうか？」
理論上は良いことですが、現在のAI大規模モデルエージェントは、安定した長文コンテキスト協調対話能力を持っていません。人間の効率的なコミュニケーションは、複雑なメタ認知と言語スキルに依存しており、これは現在のエージェントが得意とするものではありません。
マルチエージェントの概念は、ChatGPTの時代にはすでに流行していました。しかし、2025年現在、このようなシステムは依然として非常に脆弱です。意思決定が分散され、コンテキストの共有が困難であり、フォールトトレランスが低いのです。
将来的に単一エージェントの能力が向上すれば、エージェント間の効率的な協調は「付随的に実現する」と信じています。それが並列処理と効率の大いなる突破口となるでしょう。
より汎用的な理論へ向かって
これらの「コンテキストエンジニアリング」に関する原則は、将来のエージェント構築における標準的な方法論の一部となる可能性があります。
Cognition社内では、これらの原則をツールやフレームワークに継続的に実装しており、試行錯誤と改良を重ねています。もちろん、私たちの理論も完璧ではありませんし、分野は発展途上であり、私たちも柔軟性と謙虚さを保つ必要があります。
社員：「社長、情報漏洩やめてくださいよ」
ネットユーザー：「もっとください！」
この記事は、多くのエージェント構築者たちの共感を呼びました。「やはりこの問題に直面しているのは私だけではなかったのか！」
Devinの同僚でさえ、この口が軽い社長に「ねえ、社長、情報漏洩やめてくださいよ！」と注意せずにはいられませんでした。
また、記事で述べられているいくつかの見解は議論の余地があると考えるネットユーザーもいました。例えば、記事で議論されているマスターとスレーブのエージェント並列処理の欠点について、あるネットユーザーは次のように述べています。
これらの欠点は、コード編集の領域にのみ当てはまる可能性があります。タスクが明確な入力と出力を持っていれば、副作用がなく、限られたコンテキストの転送のみが必要な場合、それらの実行を調整できるはずです。これは、データパイプラインの構築や関数型プログラミングと同じ原理です。
別のネットユーザーもこの見解を支持しました。
「これはドメイン固有でサブエージェント固有になるでしょう。しかし、簡単な方法は、まず完全なコンテキストウィンドウを渡し、サブエージェントが終了したときに主要な部分が何であるかを特定することです。」
コンテキスト圧縮のためのタスク固有のシステムプロンプトを構築するために。完全なプロンプトと圧縮されたプロンプトを使用するエージェントでA/Bテストを実行します。違いが見つかった場合は、完全なプロンプトを使用したエージェントに、何が異なる部分を実行させたのかを尋ねることができます。そして、これらの違いを圧縮されたプロンプトに統合します。これはAIを広範に活用することで自動化できます。
最終的に、A/Bバージョンは一致するはずです。これにより、システムプロンプトとモデルを使用してコンテキストを圧縮し続けるか、このコンテキスト圧縮ツールからサンプルを収集してモデルをファインチューニングし、速度を上げて費用を節約することができます。
このネットユーザーはまた、次のように述べています。「o3のようなモデルを使用する場合、そのモデルはなぜ特定のタスクを完了できるのか、あるいはできないのかについて非常に優れた推論を行います。どうすれば改善できるかについて彼らにアイデアを尋ねるだけで、大きな進歩を遂げることができます。」
あるネットユーザーは、Claude Researchで実際にテストしてみました。スクリーンショットには、プログラミング以外のタスクで、大規模モデルが5つの並行して実行されるエージェントを「ホールド」できることが示されています！
「Claude Researchを試してみたところ、非プログラミングタスクでは5つの（サブタスクを）同時に実行します。結論も当然です。ハイブリッドアーキテクチャこそが正解です。」
この点について、Yanはやや懐疑的であり、次のように説明しました。
「並列読み取り（readonly）ファイルは確かに大きな問題ではありませんが、それは実際には、メインエージェントが統合するために複数の情報源を収集する従来のツールにすぎないのではないかと私は疑っています。」
その他に、ネットユーザーの議論には2つの相違点がありました。1つ目は、LLMによる要約抽出（trace distillation）は信頼できるか、という点です。
ネットユーザーのEddyLeeKhane氏は否定的な見方を示し、履歴コンテキストの圧縮は「幻覚」や重要な点の誤判断を引き起こしやすく、かえってコンテキストを破壊すると主張しました。
もちろん、多くのコメント者は、これを長期間のタスクへの拡張に有効な方法と見なしています。
ただし、編集者によると、履歴の圧縮が「強力なコンテキスト保持」よりも効果的かどうかについては、まだ統一された答えがなく、具体的なモデルの性能やトレース設計に依存するとのことです。
2つ目は、シングルスレッドのエージェントが性能を過度に制限するか、という点です。
ネットユーザーのAdam Butler氏は、「シングルスレッドは並行処理能力を制限するため、将来的にはo3やさらに高速なモデルに依存しなければ実用的ではないだろう」と疑問を呈しました。これはYan氏の論文の見解でもあります。つまり、現在のシングルエージェントの性能はまだ十分ではなく、安定していません。
さて、現在のエージェント構築技術には、まだ長い道のりがあると言わざるを得ません。しかし、まさにそれゆえに、私たちは前例のないイノベーションの機会を見ています。例えば、AnthropicのMCPは、エージェントとツールの間の呼び出し問題を解決しています。また、GoogleのA2Aプロトコルや、Devinが今日言及した「コンテキストエンジニアリング」も、新たな希望ではないでしょうか？
これについて、皆さんの意見はどうでしょうか？コメント欄でご自由にどうぞ。
参考リンク：
https://cognition.ai/blog/dont-build-multi-agents#principles-of-context-engineering
——おすすめ記事——
勇敢な者はGoogleに真っ向から立ち向かう！広告に頼らず、SEOやデータ追跡もなし。3年で有料ユーザー5万人を突破し、収益化を実現！ネットユーザー：「支持する！これは別のインターネットだ！」
o3 proの実体験！コンテキスト供給が途切れるまで与えた！達人：「o3 proは会話ができない、神はコンテキストを欲する、認知能力はGemini、Claudeを次元破壊する」