本動画では、AIエージェントが失敗する根本的な理由とその解決策について、Anthropicの最新の知見を基に実践的な視点から解説している。多くの開発者が陥る汎用エージェントの罠――記憶喪失状態でツールを持ち歩くだけの存在――を指摘し、真の解決策はモデルの性能向上ではなく「ドメインメモリ」という永続的な構造化された作業表現にあることを明らかにする。初期化エージェントとコーディングエージェントという2つのエージェントパターンを用いて、どのようにメモリの所有権を管理し、長期実行可能なエージェントを構築するかを具体的に説明する。エージェントの魔法はモデルの賢さではなく、メモリとハーネスの設計にあるという核心的な洞察を提供し、これをコーディング以外の領域にも応用可能な汎用パターンとして提示している。
はじめに
これからエージェントについて話します。そしてメモリについても話します。Anthropicが黄金の知恵を提供してくれました。私がエージェントの構築者としての要点をお伝えします。そして5、6分で理解していただき、エージェントについて語る人々の90%以上よりも多くのことを知って帰っていただけます。
正直なところ、Twitterで誰かがエージェントについて自慢しているのを見るたびに、彼らが何を話しているのか分かっていないことがすぐに明らかになります。なぜなら彼らは汎用エージェントについて話しているからです。もしあなたが汎用エージェントを構築したことがあるなら、それがツールベルトを持って歩き回る記憶喪失者になりがちだということを知っているでしょう。
基本的に、超物忘れの激しい小さなエージェントなのです。大きな目標を与えることはできます。そして、もしかしたら一回の躁的な爆発ですべてをやって失敗するかもしれません。あるいは、ぶらぶらと歩き回って部分的な進歩を遂げて成功したと言うかもしれません。しかし、どちらも満足のいくものではありません。Anthropicはこれに直接向き合いました。私も向き合ってきました。実際にどう機能するのかをお伝えしたいと思います。
ドメインメモリへの移行
鍵は、汎用エージェントからステートフル表現としてのドメインメモリへ移行することです。これについて詳しく説明していきます。複雑に聞こえるかもしれませんが、実際にはそうではありません。基本的には、本当に強力なコーディングモデルから始めることができます。Opus 4.5を使ってもいいし、Gemini 3を使ってもいいし、ChatGPT 5.1を使ってもいいでしょう。そして、Claude agent SDKのような汎用エージェントハーネスの内部でそれを開始できます。
他にもSDKはあります。そしてそれはコンテキスト圧縮機能を持っています。ツールセットも持っています。計画と実行の機能も持っています。そして理論上は、エージェントがあり、ツールがあり、このハーネスの中にある、これで継続するのに十分なはずだと思うでしょう。しかし実際には、そうではないことが分かっています。Anthropicがそうではないと認めていることに誰も驚いていません。
真剣にエージェントを構築している人で、本当にそのように機能すると考えている人はいません。ドメインメモリは橋の反対側にあります。ドメインメモリは、エージェントを真剣に考え始めたときに到達するものです。ドメインメモリは、ベクターデータベースがあって、そこから物を取り出すというものではありません。そうではなく、作業の永続的な構造化された表現なのです。
私がステートフルと言ったことを覚えていますか。エージェントがもはや記憶喪失者ではないこと、エージェントがもはや忘れないことを確実にすることに真剣なのです。エージェントとメモリについて話すと言ったことを覚えていますか。ここがメモリの本質が起こる場所です。特定のドメインには、永続的な目標のセット、明示的な将来のリスト、要件、制約が必要です。
ステートの管理
状態が必要です。何が合格しているのか、何が失敗しているのか、以前に何が試されたのか、何が壊れたのか、何が元に戻されたのか。足場が必要です。どうやって実行するのか、どうやってテストするのか、どうやってシステムを拡張するのか。これはさまざまな形で現れます。JSONブロブのように見えることもあります。大きなコード化されたリストのようなもので、たくさんの機能があり、それらはすべて最初は失敗とマークされていて、エージェントがやることは、そのJSONブロブの機能リストに戻って、ユニットテストに合格したときだけ何かを変更できるということです。
クラウドのプログレステキストファイルのように見えることもあります。各エージェントの実行が何をしたかを記録します。エージェントはそれを読み返すことができます。これらは明白に聞こえますよね。約束しますが、汎用エージェントを構築しているほとんどの人は、この程度の具体性で考えていません。メモリを管理しなければならない問題として考えていないのです。
実際、私がここで数分でお伝えしたいAnthropicのブログ投稿の話は、長期間エージェントを実行する鍵は、ドメインメモリファクトリーを構築することだということです。彼らは2つのエージェントパターンをまとめましたが、それは人格についてではありません。役割についてでもありません。誰がメモリを所有するかについてなのです。
初期化エージェントがあり、ユーザープロンプトを詳細な機能リストに拡張します。構造化されたJSONがあり、機能について話すとしましょう。ちょうど私が説明したように、おそらくすべての機能は最初はユニットテストに合格していないので失敗しているかもしれません。プログレスログなどを設定するかもしれません。ユーザープロンプトからドメインメモリをブートストラップし、ベストプラクティスのエンゲージメントルールを設定します。
技術者でない方は、初期化エージェントが舞台を設定していると考えることができます。舞台監督です。舞台を構築しており、コーディングエージェントはその設定の中の俳優です。その後のすべての実行で、コーディングエージェントが入ってきて、記憶がありません。ただの記憶喪失者です。ちなみに、考えてみれば、初期化エージェントは今説明したことをするのにメモリは必要ありませんでした。
エージェントの役割分担
必要だったのは、プロンプトを人工物のセットに変換することだけでした。それがコーディングエージェントが入ってきて役割を果たすための足場、舞台として機能します。そしてコーディングエージェントは進捗を読みます。コーディングエージェントはGitから以前のコミットの履歴を取得します。コーディングエージェントは機能リストを読み、今回の実行で取り組む単一の失敗している機能を選択します。
そしてそれを実装します。エンドツーエンドでテストします。機能のステータスを失敗または合格のいずれかとして更新します。プログレスノートを書きます。Gitにコミットして消えます。これ以上メモリはありません。消えたのです。なぜなら、長時間実行されるメモリはこれらのLLMでは機能しないからです。これらのLLMには役割を演じるための設定、舞台で堂々と振る舞うための設定が必要なので、私たちはメモリの足場を構築しているのです。
シェイクスピアを引用すると、エージェントは今や、一貫したメモリ状態を別の状態に変換するポリシーに過ぎません。魔法はメモリにあります。魔法はハーネスにあります。魔法は人格レイヤーにはありません。そしてハーネスというのは、エージェントの周りにあるすべてのものを表す派手な言葉ですよね。それが設定です。それが私が説明していることです。
より深い教訓は、ドメインメモリがなければ、エージェントは意味のある意味で長時間実行できないということです。そしてそれがAnthropicが発見していることです。私たちは皆、なんとなくそれを知っていましたが、少なくとも彼らはそれを書き記しています。そして私は本当に感謝しています。コアとなる長期的な失敗モードは、モデルが愚かすぎるということではありませんでした。
真の問題は何か
すべてのセッションが、私たちが世界のどこにいるのかについての根拠のある感覚なしに始まるということでした。そして彼らがそれを解決するためにやっていることは、モデルをより賢くすることではありません。彼らがそれを解決するためにやっていることは、モデルにその生きた文脈の感覚を与えることです。私たちはそれをインスタンス化すると言うでしょう。そしてそれが初期化エージェントと呼ばれる理由です。状態を初期化するので、コーディングエージェントは後続のすべての実行で自分がどこにいるかを知ることができます。
共有機能リストがなければ、考えてみてください。すべての実行が完了の独自の定義を再導出します。永続的なプログレスログがなければ、すべての実行が何が起こったかを間違って推測します。安定したテストハーネスやテストパス、成功したソフトウェアアプリケーションとは何か、成功したユニットテストや機能テストとは何かがなければ、誰もが何が機能するかについて異なる感覚を発見します。
そしてこれが、ツールを使ってLLMをループさせると、無関係なインターンの無限のシーケンスが得られるだけの理由です。それは単に機能しないのです。ちなみに、ここにプロンプティングへの示唆があると思うなら、それは正しいです。私たちがプロンプティングで行うことの多くは、その初期化エージェントになることです。私たちはコンテキストを設定しています。
エージェントが成功した活動を設定できるように、構造を設定しています。だから、チャットでエンターキーを押してLLMが目を覚ますと、それは自分がどこにいるかを知り、タスクが何であるかを知っているのです。プロンプティングについて考える素晴らしい方法です。プロンプティングとは、エージェントが役割を果たせるように舞台を設定することなのです。
ドメインメモリの重要性
だからドメインメモリは、エージェントをオートコンプリートのようにではなく、規律ある技術者のように振る舞わせます。そして、Anthropicが説明しているようなハーネス、または他の多くの企業が構築しているハーネスを手に入れたら、すべてのコーディングセッションは、実際にエージェントがどこにいるかをチェックすることから始まります。以前のコミットログを読み、プログレスファイルを読み、機能リストを読み、取り組むべきものを選択します。
これはまさに、共有コードベースで優秀な人間がどのように振る舞うかです。方向を定め、テストし、変更します。ハーネスは、現在のコンテキストウィンドウにたまたまあるものではなく、永続的なドメインメモリにエージェントのアクションを結びつけることで、その規律をエージェントに主張するか、焼き込みます。つまり、一般化は概念としての汎用エージェントから、ドメイン固有のメモリスキーマを持つ汎用ハーネスパターンへと一段上のレイヤーに移動するということです。
これは本当に派手な言い回しですが、重要な言い回しです。なぜなら、これはコーダーだけのものではないということを意味するからです。設定があり、コンテキストがあり、そのコンテキストでタスクを実行できるエージェントがあるという同じパターンを使用できます。そしてそれをコーディング以外にも適用できます。ツールを使って何かを成し遂げる必要があり、実際には持っていないのに効果的に長期記憶を持つ必要があるワークフローに適用できます。
したがって、Anthropicの研究は、多くのTwitterの誇大宣伝よりもはるかに正直に感じられるエージェントのフレーミングを暗黙的に示唆しています。比較的汎用的なエージェントハーネスパターンを持つことができます。初期化エージェントを使用できます。足場を構築できます。メモリを読み取り、小さなテスト可能な進歩を遂げ、メモリを更新する反復ワーカーを持つことができます。ちなみに、それはコードである必要はありません。しかし、スキーマと儀式がドメイン固有である場合にのみ、それを持つことができます。
コーディング以外への応用
これがコーディングでうまくいっている理由の一部は、私たち全員が合意した儀式とスキーマがあり、それがここでより簡単にしているということだと思います。開発に携わっている場合は、テストを取得し、プログレスログを取得し、feature list.json JSONを取得することがすべて非常に理にかなっていることを理解しているでしょう。技術的でない分野では、それらのいくつかを発明し、それらのいくつかについて合意する必要があります。
研究では、仮説のバックログ、実験レジストリ、証拠ログ、意思決定ジャーナルのように見えるかもしれません。オペレーションでは、ランブック、インシデントタイムライン、チケットキュー、SLAのように見えるかもしれません。だから汎用エージェントは実際にはメタパターンに過ぎません。同じハーネス構造をインスタンス化しますが、特定のスペースで実際にするために、オペレーションエージェントや研究エージェントにするために、適切なドメインメモリオブジェクトを設計する必要があります。
私がお伝えしているのは、汎用エージェントの魔法のパターンは、コンテキストについてドメイン固有であることにあるということです。これは、会社にエージェントを投入すればうまくいくという考えを殺します。それは常に幻想でしたが、ここでそれを捨てる良い証拠があると本当に思います。ドメインメモリの議論を受け入れるなら、多くのベンダーの主張をすぐに却下できます。
作業やテストに関する意見のあるスキーマがない企業向けのユニバーサルエージェントは、暴れてゴミ箱に行く機能です。モデルをSlackに接続してエージェントと呼ぶことはできると思います。そう言えるでしょう。しかし、ほとんどの場合、それは問題につながります。なぜなら、彼らは私が話したような、機能するためのクリーンなコンテキストやスキーマや良い構造的なものを一切持っていないからです。
それは、Slackにメッセージを送信するためのAPIフックやWebフックを持つエージェントが欲しいと言うこととは異なります。ちなみに、それは常に起こっています。しかし、エージェントに汎用化されたコンテキストダンプを与えて、それが機能すると期待しようとしている場合、それはうまくいかないでしょう。
設計原則
困難な作業は、エージェントのドメイン固有のタスクのためにメモリを定義する人工物とプロセスを設計することです。コーディングだけでなく、他のタスクや分野のためのJSON、ログ、テストハーネス。だから、これを見てエージェントに関するこの会話全体から設計原則を引き出すとしたら、私はいくつかを提案します。構築する真剣なエージェントについて、目標を外部化したいでしょう。
Xを実行するというものを、機械可読なバックログに変えてください。過去の失敗基準を持つもの。本当に具体的にしてください。進歩をアトミックにしたいでしょう。観察可能にしたいでしょう。エージェントに1つのアイテムを選択させたいでしょう。それに取り組み、共有状態を更新させたいでしょう。
だから進歩は、テストして増やすことができるものである必要があります。キャンプ場を見つけたときよりもきれいにして去る習慣を強制したいでしょう。すべての実行を、人間と機械が読める文書を使って、クリーンなテストに合格した状態で終了したいでしょう。起動の儀式を標準化したいでしょう。すべての実行で、エージェントは全く同じプロトコルで再接地する必要があります。
メモリを読む。基本的なチェックを実行する。それから、そしてその時だけ行動する。テストをメモリの近くに保ちたいでしょう。合格、失敗、真偽を、ドメインが良い状態にあるかどうかの真実の源として扱います。言い換えれば、テスト結果をメモリに結びつけていない場合、困ったことになるでしょう。ちなみに、ここでの戦略的な意味は、堀がより賢いAIエージェントではないということです。ほとんどの人はそう思っていますが、堀は実際にはあなたが組み立てたドメイン、メモリ、そしてハーネスです。それは多くの作業です。
モデルは良くなり、モデルは交換可能になります。すぐに商品化されないのは、作業のために定義するスキーマ、LLM呼び出しを永続的な進歩に変えるハーネス、エージェントを正直に保つテストループです。ある意味、汎用エージェントの幻想は、よく設計されたドメインメモリで競争上の差別化を構築するために使用できる、素晴らしいクリーンで再利用可能なハーネスパターンを誰からも隠しています。
結論
今、本当に有用なエージェントを設計するチャンスがあります。そして、このビデオの全体的な目的は、そこから謎を取り除くことでした。エージェントの謎はメモリです。そしてこれが解決方法です。
コメント