この動画は、Cognition社（Devinを開発した企業）の論文を基に、インテリジェントエージェント向けのコンテキスト工学技術について解説したものである。長期実行型エージェントの信頼性を確保するための設計原則として「コンテキストの共有」と「行動が暗黙的決定を含む」という2つの核心的概念を提示し、並列処理の落とし穴から単一スレッド型アプローチ、さらにはコンテキスト圧縮を用いた最適化手法まで、段階的にエージェント アーキテクチャの進化を論じている。
インテリジェントエージェントにおけるコンテキスト工学の重要性
皆さん、今日は最も興味深いトピックの一つについてお話しします。それは、エージェントに知性を組み込む方法と、知性戦略について議論することです。問題解決をどのように構築するか、採用できる異なるアプローチについて考え、それに関していくつかのことを検討していきます。
いつものように、いいねを残してくださった皆さん、チャンネル登録してくださった皆さんに感謝いたします。このAIチャンネルを支援してくださっているチャンネルメンバーの皆さんには特別な感謝を申し上げます。メンバーの方々は、WhatsApp統合、PDF文書読み取り、MCP統合などを教えるインテリジェントエージェントの独占動画にアクセスでき、さらに先行公開動画も視聴できることを覚えておいてください。
今日の動画は、Cognition社のこの論文についてです。Devinを開発したあの会社を覚えていますか。去年始めの頃に登場した、プログラミング自動化について語ったスタートアップです。彼らの非常に良い論文があるので、一緒に読んでいきましょう。エージェント アーキテクチャと、インテリジェントシステムを構築する際に考慮すべき事項について述べています。
コンテキスト工学の基本原則
最初に彼らが述べているのは、コンテキスト工学の原則についてです。これは重要なポイントですね。エージェントを構築する際の意思決定を支配する原則とは何でしょうか。
彼らは2つの原則について語っています。第一はコンテキストの共有、第二は行動が暗黙的決定を含むということです。コンテキストと私たちが取る行動に何が起こっているかの例をいくつか示し、エージェントが正しい道筋にいるか、正しいことを考えているかを確認していきます。
これは長期実行エージェントの構築理論です。ここで明確にしておきたいのは、長期実行エージェントとは、複数の段階を持ち、決定を下したりタスクを実行したりするために複数のやり取りが必要なエージェントのことです。したがって、それほど単純ではなく、よく書かれたプロンプト一つでこのような状況を解決できるものではありません。
信頼性の確保と複合エラーの防止
まず信頼性から始めましょう。エージェントが長期間にわたって本当に信頼できる必要があり、一貫した会話を維持する必要がある場合、複合エラーの可能性を抑制するために取るべき特定の措置があります。つまり、最初の小さなエラーが最終的に巨大なエラーになってしまうという問題です。注意を怠ると、物事は急速に崩壊してしまいます。
信頼性の核心にあるのはコンテキスト工学です。これは非常に興味深いことですね。多くの人がプロンプト工学について語ってきました。これは、タスクのプロンプトテキストをうまく書くことに焦点を当てたものです。しかし、コンテキスト工学は、タスク全体にわたる複数のプロンプトの連鎖のようなもので、もう少し広範囲なものです。
2025年、つまり今年、利用可能なモデルは極めて知的になるでしょう。しかし、最も知的な人間でさえ、求められることのコンテキストなしには効果的に仕事を遂行できません。私たちの最後の2つの動画では、ツールの使用とそれがシステムに知性を組み込む際の重要性について話しました。まさに、エージェントが迷子にならず、長期的なタスクを実行できるようにするためです。
プロンプト工学からコンテキスト工学への進化
プロンプト工学という用語は、LLMチャットボット用の理想的な形式でタスクを書くために必要な努力のために作られました。しかし、コンテキスト工学は次のレベルです。これは動的システムでそれを自動的に行うことであり、より多くのニュアンスが必要で、効果的にAIエージェントを作成するエンジニアの第一の任務です。
一般的なエージェントの例を取り上げましょう。このエージェントは、まず作業を複数の部分に分割します。もしあなたが人間を使うことに慣れているなら、彼らが最初に行うタスクは、実際に始める前にやることのリストを作ることだということを知っているでしょう。これが最初のことです。作業を複数の部分に分割すること。
2番目は、これらの部分で作業するサブエージェントを開始することです。10個のことがあるとして、タスク1、2、3を並列化できるかもしれません。すべてを行って待つ必要はありません。3番目は、最終的にこれらの結果を組み合わせることです。
並列処理アーキテクチャの問題点
これは最初のエージェントです。タスクがあり、初期エージェントがタスクを複数の部分に分割し、サブタスクがサブエージェント1に送られ、もう一つのサブタスクがサブエージェント2に送られます。それぞれが結果を出し、私たちはここで結果の組み合わせを行い、このタスクで行った応答を送信します。
彼らが述べているのは、これは魅力的なアーキテクチャだということです。特に、複数の並列コンポーネントを持つタスクドメインで作業している場合は。しかし、これは非常に脆弱で、主な障害点は次の通りです。
あなたのタスクがFlappy Birdのクローンを構築することだとしましょう。あのゲームですね。それは、サブタスク1「緑のパイプと衝突ボックスを持つモバイルゲームシナリオを構築する」と、サブタスク2「上下に動かせる鳥を構築する」に分割されます。
ところが、サブエージェント1は実際にサブタスクを誤解し、Super Mario Brosのようなシナリオの構築を始めました。サブエージェント2はあなたのために鳥を構築しましたが、それはゲームの機能のようには見えず、Flappy Birdのように動きません。したがって、最終エージェントは、これら2つのコミュニケーション失敗を組み合わせるという望ましくないタスクを抱えることになります。
興味深いですね。完璧であるはずだった並列タスクが時間を節約するはずだったのに、実際には1つのステップでエラーの合計を作り出してしまいました。
コンテキスト共有の重要性
これは作為的に見えるかもしれませんが、現実世界のタスクの大部分には、誤って伝達される可能性のある多くの微妙なレイヤーがあります。そして、この誤ったコミュニケーションの部分は最も一般的なことです。プロンプトに時間を投資し、テストし、応答が望んだ通りに出ているかを確認することは非常に重要です。
モデルの知性が問題である場合もありますが、エージェントとのコミュニケーションが問題である場合もあります。簡単な解決策は、元のタスクをサブエージェントのコンテキストとしてコピーすることだと思うかもしれません。そうすれば、サブタスクを誤解することはないでしょう。
しかし、彼らが言うのは次のことです。実際の本番システムでは、会話はおそらくマルチターンであり、エージェントはタスクの構成方法を決定するためにいくつかのツール呼び出しを行う必要があった可能性があり、詳細がタスクの解釈に影響を与える可能性があります。
ここから第一原則が生まれます。コンテキストを共有し、エージェントの完全な軌跡を共有すること。個別のメッセージだけではありません。この個別のメッセージの問題は、まさにマルチターンの問題のためです。エージェントとの多くのやり取りがあり、その2、3、4回のやり取りの間に、1つのメッセージや一部だけを共有した場合を想像してください。エージェントの完全な軌跡を残さなければなりません。
改良されたアーキテクチャ
これにより、エージェントのバージョン2になります。今度は、各エージェントが前のエージェントのコンテキストを持つことを保証します。ここに2番目のアイデアがあります。タスクがあり、サブタスクに分割し、ここに会話と取られるアクションの緑のボックスがあります。
サブタスク1がサブエージェントに送られ、このコンテキストを保持します。上で何が起こったかを知っています。サブエージェント1は、行っているタスク1のコンテキストも作成します。サブエージェント2も同様です。サブエージェント2は前の会話（緑色）を持ち、行っているサブタスクの情報を生成し始めます。
最終結果は、結果を組み合わせるエージェントです。このエージェントは、最初に渡された指示、サブエージェント1のコンテキスト、サブエージェント2のコンテキストを受け取り、最終的にここに紫のボックスがあり、これが前に起こったすべてを組み合わせます。
依然として残る課題
言い換えると、何が起こったかというと、この前のエージェントとの違いは、最後のエージェントが結果を組み合わせたとき、彼は以前に何が起こっていたかを知らず、最初に何が起こっていたかも知らなかったということです。なぜなら、この情報が前に渡されなかったからです。彼は2つの断片だけを受け取り、何であるかもよく分からずに組み合わせを作らなければなりませんでした。
ここで彼らが述べるコメントは、残念ながら、まだ完全に問題から解放されていないということです。同じFlappy Birdクローンタスクをエージェントに割り当てると、今度は完全に異なる視覚スタイルの鳥と背景になってしまう可能性があります。なぜなら、サブエージェント1とサブエージェント2は互いが何をしているかを見ることができず、そのため彼らの作業が一貫性を欠いてしまうからです。
ここで彼は、3番目は1番目と2番目が何をしたかを見ることができるが、1番目と2番目は互いが何をしているかを知らないことについて話しています。サブエージェント1によって取られた行動とサブエージェント2によって取られた行動は、事前に規定されていない矛盾する仮定に基づいていました。
ここで第二原則が登場します。行動は暗黙的決定を生成し、矛盾する決定は悪い結果を生成するということです。なぜなら、ここで明確になったのは、一方がキャラクターを作成し、他方が風景を作成しているからです。キャラクターと風景は非常によく整合していなければなりません。
単一スレッドアプローチ
彼らは述べています。第一と第二の原則は非常に重要で、それらを破ることはめったに価値がないので、デフォルトでそれらを満たさないエージェント アーキテクチャを破棄すべきです。これは制限的だと思うかもしれませんが、実際にはエージェントのために探索できる異なるアーキテクチャの幅広いスペクトラムがまだ存在します。
ここで3番目の解決策に到達します。原則に従う最も簡単な方法は、単一の線形スレッドエージェントのみを使用することです。この解決策は悪く見えるかもしれませんが、彼らはシンプルで信頼できると言っています。
タスクを取り、エージェントに渡し、エージェントが複数の小さなタスクに分割し、会話と取るべきアクションを保存し、サブエージェント1に渡します。興味深いことに、並列化していません。サブエージェント1は受け取った緑の情報を取り、行っているサブタスクもここに記録し、このすべてのコンテキストをサブエージェント2に渡し、同じことを行います。
緑、薄い青を取り、今度は濃い青を取り、エージェント3に渡し、最終的に組み合わされた結果を作ります。つまり、すべての前のステップと作業の組み合わせが完成したエージェントの結果になります。
興味深いですね。タスクを並列化することが可能だからといって、並列化するわけではありません。なぜなら、それが価値があるかどうかわからないからです。2つのことを決める必要があります。1つは並列化が可能かどうか、2つ目は並列化する価値があるかどうかです。なぜなら、行っていることによっては、並列化してもまったく変わらない場合もあれば、価値がない場合もあるからです。
コンテキストオーバーフローの問題
彼らがここで述べているのは、ここではコンテキストが連続しているということです。しかし、非常に大きなタスクで、コンテキストウィンドウがオーバーフローし始めるほど多くのサブパーツがある場合に問題が発生する可能性があります。今度は最適化問題について話しています。これは彼らが書いていない3番目の項目です。
タスクが非常に長い場合、ここでタスクの詳細を蓄積し、前に渡し続けると、このコンテキストオーバーフローの問題に陥ります。これは、あまりにも多くの情報があり、コンテキストウィンドウがそんなに多くのテキストで過負荷になる場合です。
彼らは次のようにコメントしています。正直に言うと、シンプルなアーキテクチャはあなたを非常に遠くまで連れて行くことができますが、本当に長いタスクを持ち、努力を惜しまない人にとっては、さらに良くすることが可能です。
コンテキスト圧縮による最適化
これを解決する方法はいくつかありますが、今日は1つだけ紹介します。これが、長くて信頼できるが、機能させるのが困難なタスクの最終解決策です。
あなたのエージェントが複数のステップに分割し、会話のコンテキストを受け取り、サブエージェント1に渡します。サブエージェント1は次のことを行います。受け取ったこのコンテキストをコンテキスト圧縮し、その大きな四角が小さな四角になり、重要な瞬間と決定のみが残ります。それを前に渡し、タスクを実行し、そのコンテキストも作成し、前に送ります。
次は同じことを行います。前のタスクの重要な瞬間と決定のみで作業し、サブエージェント3まで続きます。理解しましたね。これにより、エージェントが情報に迷子にならなくなります。なぜなら、コンテキストウィンドウをより多く使用し、より多くの情報があるほど、エージェントはより迷子になり、この情報を迅速かつ軽く要約できれば、彼らが理解できない大量のテキストに迷子にならずに、同じ量の情報でより効率的になることができるからです。
これは金に値しますね。彼らはここでコメントしています。この世界では、主な目標が行動と会話の履歴を重要な詳細、イベント、決定に圧縮することである新しいLLMモデルを導入します。これはメタ知識で作業するエージェントだと言えるでしょう。このバックボーンは実際に起こる必要があるすべての知識であり、この人はメタ知識です。彼はここのバックボーンで起こっている知識を最適化するのに役立ちます。
実装の困難さと専門化
彼らはコメントしています。これを正しく行うのは困難で、どの情報が最終的に重要になるかを発見し、それをうまく行うシステムを作成するために投資する必要があります。ここで彼は、ドメインに応じて、より小さなモデルを調整することを検討することもできると言っています。これは私たちがCognitionで行ったことです。
重要な瞬間と決定を見つけるこの問題の専門家モデルを作るのは非常に興味深いですね。得られる利益は、より長いコンテキストで効果的なエージェントですが、それでも限界に達するでしょう。熱心な読者には、任意に長いコンテキストをより良く管理する方法を考えることをお勧めします。
ここで興味深いのは、「任意に長い」ということです。なぜなら、長いコンテキストで作業しているだけでなく、そのコンテキストがどれほど長くなるかわからないからです。これは最終的に非常に深いウサギの穴になります。
実世界での応用例
原則について話すと、エージェントクリエーターであれば、エージェントの各行動がシステムの他の部分によって取られたすべての関連決定のコンテキストによって情報を得ることを確認してください。これは非常に興味深いです。彼がエージェントが取る行動に与える重要性を見てください。
何かをしなければならないときはいつでも、関連するすべての重要な単語、エージェントの行動、コンテキスト、すべての決定のコンテキストを知っている必要があります。そして、どんな決定でもありません。関連する決定です。
言い換えると、特定のエージェントに渡しているものが重要でない場合、彼が知ることが重要でないなら、決定されたすべてを渡すことにそれほど気を使う必要はありません。これも邪魔になるからです。理想的には、各行動が他のすべてを見ることです。残念ながら、これは実用的な制約と妥協のために常に可能ではなく、目指す信頼性レベルを達成するためにどのレベルの複雑さを引き受ける意思があるかを決定する必要があります。
この決定は重要な決定です。競合する意思決定を避けるためにエージェントを設計することを考える際に、検討すべき現実世界の例をいくつか示します。
Claude Codeの例
興味深い例があります。2025年6月のClaude Codeのサブエージェントです。Claude Codeは、サブタスクを生成するエージェントの例です。私は既にこれについて動画を作りました。しかし、サブタスクエージェントと並行して作業することは決してありません。サブタスクエージェントは通常、コードを書くのではなく、質問に答えることだけを担当しています。
興味深いですね。なぜなら、サブタスクエージェントは、明確に定義された質問に答える以外のことをするために必要なメインエージェントのコンテキストを持っていないからです。複数の並列サブエージェントを実行すると、矛盾する回答を与える可能性があり、これまでの例で見た信頼性の問題が生じます。
エージェントに多くのことをさせずに、小さなステップで進めるこのアイデアを見ましたか。これは基本的です。すべてをエージェントが一つのウィンドウで行わなければならないことを書くメガプロンプトの話は忘れてください。それは機能しません。
この場合にサブエージェントを持つことの利点は、サブエージェントのすべての調査作業がメインエージェントの履歴に残る必要がないため、コンテキストから外れる前により長い軌跡が可能になることです。Claude Codeの設計者は意図的にシンプルなアプローチを採用しました。シンプルなものが機能するからです。
コード編集の進化
2024年、多くのモデルはコード編集が本当に苦手でした。コーディングエージェント、IDEビルダー、アプリケーションビルダーなど、Devin自身も含めて一般的な実践は、編集および適用モデルを使用することでした。
主なアイデアは、望ましい変更のMarkdown説明を与えられた小さなモデルにファイル全体を書き直させる方が、大きなモデルに正しくフォーマットされた差分を生成させるよりも信頼できるということでした。
ここで彼は次のことを言っています。変更したい大きなファイルがあり、真ん中の一行だけを変更したいとします。当時は、真ん中の行を正確に当てようとするよりも、ファイル全体を書き直す方が価値がありました。
そのため、ビルダーは大きなモデルにコード編集のMarkdown説明を生成させ、その後、これらのMarkdown説明を実際にファイルを書き直す小さなモデルに与えていました。しかし、これらのシステムは依然として非常に欠陥がありました。多くの場合、例えば、小さなモデルが大きなモデルの指示を誤解し、指示の小さな曖昧さのために間違った編集を行っていました。
彼がコメントしているのは次のことです。今日、意思決定と編集の適用は、単一のモデルによって単一のアクションでより頻繁に行われています。これは、常に誰かに複数のタスクを委任する代わりに、一部のことが本来あるべき姿に戻ったことを認識させるためです。ここでは、2つのタスクが再び1つになった例です。
マルチエージェントシステムの課題
マルチエージェントについて具体的に話すと、システムで並列処理を本当に排除したい場合、意思決定者同士を会話させ、物事を解決させることを考えることができます。これは、私たちが話していなかったステップです。
私たちが議論した解決策は並列処理を排除することでしたが、並列処理を維持する意図がある場合、彼らの間で会話が必要です。これは私たち人間が意見が合わないときに行うことです。エンジニアAのコードがエンジニアBとのマージコンフリクトを引き起こした場合、正しいプロトコルは違いを議論し、合意に達することです。
しかし、今日のエージェントは、単一のエージェントで得られるよりもはるかに高い信頼性を持つ長いコンテキストのこの積極的な議論スタイルに従事することができません。人間は私たちの最も重要な知識を互いに伝達することに非常に効率的ですが、この効率性には自明でない知性が必要です。
彼が言っていることがいかに重要かを見てください。競合を解決するために2つのエージェント間で会話を行うことは可能ですが、これを行うためにAIを使用すると、人間が最終解決策に到達する理解力と積極性ほど積極的ではありません。そのため、彼らはこのような状況を避け、シリアルで行うことを好みます。
ChatGPTのリリースから間もなく、人々は目標を達成するために互いに相互作用する複数のエージェントのアイデアを探求してきました。エージェント同士の協力の長期的可能性については楽観的ですが、2025年において複数のエージェントを協力して実行することは脆弱なシステムにしか結果しないことは明らかです。
興味深いですね。彼はこれが将来の約束だが、今はまだその時ではないと言っています。意思決定が非常に分散し、コンテキストがエージェント間で十分完全に共有できません。現在、私はエージェント間のコンテキスト受け渡しのこの困難な問題を解決しようと努力している人を見ていません。
個人的には、これは私たちがエージェントをシングルスレッドにするときに無料で来ると思います。その日が来ると、これははるかに大きな並列処理と効率性をアンロックするでしょう。この観点からの並列処理は、どうやらあまり興味深くないようです。
より一般的な理論に向けて
最後に、より一般的な理論に向けてです。コンテキスト工学に関するこれらの観察は、いつか私たちがエージェント構築の標準原則と考えるかもしれないものの始まりに過ぎません。ここで議論されていない多くの他の課題と技術があります。
Cognitionでは、エージェントの構築は、私たちが考え、内部ツールと構造を構築する基本的なフロンティアです。私たちは、これらのアイデアを適用する方法として繰り返し再学習するこれらの原則の周りに構築します。しかし、私たちの理論はおそらく完璧ではなく、分野が進歩するにつれて物事が変わることを期待しています。したがって、ある程度の柔軟性と謙虚さも必要です。
どう思いますか。あなたが作業しているエージェントで、このタスクの分割ができ、各瞬間にすべてが起こったことの要約を作り、将来のエージェントが混乱しないようにこの情報を要約するコンテキスト圧縮を行うエージェントを作成できると既に想像できますか。
あなたが既にこのレベルにいて、私たちが話していることを人工知能システムで視覚化できているなら、あなたは既に非常に高度なレベルにいることを確信できます。そして、もしあなたが既にこの種の方法論を使用しているなら、それについてどう思うかコメントしてください。
まだ試していないなら、実験してからここに戻ってコメントしてください。うまくいったか、見つけた制限事項について知りたいので、自分のエージェントを作成している人にとって知ることが重要で、共有する価値があることを教えてください。
このようなビデオを見続けるためにチャンネルをサポートしたい場合は、メンバーになってください。メンバーはインテリジェントエージェントの独占ビデオと先行公開ビデオにアクセスできます。それでは、いいねを残してください。ありがとうございました。
コメント