Chain of Recallとは？Stable IDがAIエージェントに記憶をもたらす仕組み

Posted on Nov 5 • Originally published at apidog.com

Chain of Recallは、コンテキストウィンドウにあらゆる情報を詰め込むことなく、長時間稼働するAIエージェントに記憶を持たせるための手法です。すべてのTrigger、Thread、Workerには不変のIDが割り当てられます。コンテキストにはID、短い要約、近傍のメッセージのみを保持し、エージェントはID間のリンクを辿ることで、数ホップで過去の事実を取得します。

この言葉は、2026年11月1日に公開されたDeepSeek Harnessの設計論考 「Exploring Super-agent Design（スーパーエージェント設計の探求）」 に由来します。読み進める前に1点注意すべき点があります。この論考で解説されているのはアーキテクチャであり、正式に提供されている機能ではありません。その一部はプロトタイププラグインである dsh-superagent-prototype に実装されていますが、著者らはこれを「DeepSeekの公式製品ではない」としています。オンにすればすぐ使える「Chain of Recall」の機能スイッチがあるわけではなく、自ら構築する設計パターンなのです。

長時間稼働するエージェントは、絶え間なくタスクが届くため、いずれコンテキストの上限に達します。チャット、GitHub、CIを常時監視するスーパーエージェントは1日に数百件ものイベントを処理するため、昨日の作業内容を保持したウィンドウに今日の作業まで収めることはできません。

Anthropicによる AIエージェントのコンテキストエンジニアリング ガイドでは、コンテキストを「キュレーションすべき有限のリソース」と位置づけています。Chain of Recallはそのキュレーションを実践する具体的な手法の1つです。より幅広い選択肢については、 AIエージェントのメモリの仕組み の解説記事をご覧ください。

論考では、コンテキストウィンドウをキャッシュのように扱い、2つの操作を行います。

スピルされた項目は削除されるわけではなく、プロンプト内にはそのポインタのみが保持されます。

Routerに届いた1件のCI障害イベントを例にとると、以下のようになります（この構造は概念を示すための例であり、DeepSeekのコードそのものではありません）。

{ "trigger_id": "trg_8f21", "source": "github.check_run", "thread_id": "thr_pr_412", "summary": "CI failed on PR #412: 3 of 118 tests red in payments/", "neighbours": [ "trg_8f1c: review comment asking for retry logic" ], "spilled": { "full_log": "GET /triggers/trg_8f21/payload (41 KB, truncated)" } } Enter fullscreen mode Exit fullscreen mode 1行の要約だけで十分であれば、エージェントは41KBのログを読み込むコスト（トークン）を支払わずに済みます。詳細が必要になった場合のみ、IDを指定してログを取得します。

Chain of Recallが機能するのは、IDが決して変化しないからです。論考の設計では、主に3種類のオブジェクトにIDが付与されます。

TriggerはThreadに属し、Threadは1つ以上のWorkerによって管理され、Workerのレポートには対処したTriggerが引用されます。これらのリンクが参照グラフを形成し、そのグラフこそがエージェントのメモリとなります。

想起（リコール）は、履歴全体を読み込んだり類似テキストを検索したりするのではなく、リンクを1ホップずつ辿ることによって行われます。RouterとWorkerの全体設計におけるTrigger、Thread、Workerの位置づけについては、関連ガイドの スーパーエージェントの構築方法 で解説しています。

例えば金曜日に、チームメンバーがRouterに「paymentsクライアントにリトライ処理を追加したのはなぜ？」と尋ねたとします。元の議論が行われたのは火曜日であり、すでにスピルされています。このときのリコール手順は次のようになります。

行われたのは、小さく正確な3回の取得のみです。推測に頼ることは一切なく、3日間にわたってプロンプトに情報が残り続けることもありませんでした。

Chain of Recallは、他のメモリ技術を置き換えるものではありません。対象とする問いが異なるのです。 検索拡張生成（RAG）の論文 で広く知られるようになったベクトル検索が「これに似ているものは何か？」を問うのに対し、Chain of Recallは「これにリンクしているものは何か？」を問いかけます。

実際にはこれらを組み合わせて運用することになります。まずベクトルインデックスを使って起点となるThread IDを見つけ、そこからChain of Recallで正確な事実を辿っていくという形です。MemGPT論文の OSスタイルのメモリ階層 もこれに近いアプローチです。既存のストレージをそのまま使いたい場合は、 MCPを使ってAIエージェントに永続メモリを追加する方法 をご覧ください。

留意すべき制限事項が2点あります。まず、論考では長期記憶が未解決の課題として挙げられており、Chain of Recallがそれを完全に解決するとは主張していません。また実験では、Threadのパススルー（素通し）を取り除くと、実行あたりのキャッシュ読み取りトークン数が23.2Mから31.8Mへと約37%増加しました。これは機能が不足していたことによるコスト増であり、Chain of Recallによる削減効果ではありません。

先ほどのウォークスルーにおける各ホップは、いずれもAPI呼び出しです。仮に1つの呼び出しで別のレコードが返されたり、何も返されなかったりすると連鎖が途切れ、エージェントは停止するか推測で回答してしまいます。そのため、Chain of Recallを支えるAPIには以下の4つの契約（保証）が求められます。

これらの契約はリファクタリング時に密かに破られがちであるため、自動テストに組み込む必要があります。また、ツールのレスポンス自体も小さく保つ必要があります。これについては、 エージェントのツールレスポンスとコンテキストウィンドウ に関するガイドで詳しく解説しています。

Chain of Recallの信頼性はID指定取得エンドポイントの信頼性に直結しますが、そうした検証コードの記述や再実行はコーディングエージェントに任せることができます。 Apidog CLI を使用すれば、エージェントはエンドポイントの定義、テストケースの作成、ターミナルからの実行をコマンド経由で行えます。

npm install -g apidog-cli@latest apidog auth login --with-token <YOUR_TOKEN> npx -y skills add https://apidog.com # pick your agent when prompted Enter fullscreen mode Exit fullscreen mode あとは、Claude CodeやCodexなど、お使いのエージェントに以下のようなプロンプトを1つ与えるだけです。

In Apidog project <projectId>, define three endpoints for our agent memory service: GET /threads/{id}, GET /threads/{id}/events?cursor=, and GET /workers/{id}. Then create test cases that check: 1. A thread_id returned by GET /threads/{id} resolves to the same record on a second call, and each owner worker ID resolves via GET /workers/{id}. 2. An unknown thread ID and an unknown worker ID both return 404. 3. Paging GET /threads/{id}/events with the cursor returns every event once, in order, with no gaps. Run them against the staging environment and summarize any failures. Enter fullscreen mode Exit fullscreen mode エージェントは各ペイロードスキーマを読み込み、書き込みを行う前にJSONを検証した上で、テストケースの作成と実行を行います。

apidog cli-schema get endpoint-create apidog cli-schema validate endpoint-create --file thread-get.json apidog endpoint create --project <projectId> --file thread-get.json apidog cli-schema get test-case-create apidog cli-schema validate test-case-create --file id-resolves.json apidog test-case create --project <projectId> --file id-resolves.json apidog run --test-case <caseId> --project <projectId> -e <envId> -r cli,json Enter fullscreen mode Exit fullscreen mode cli レポーターはターミナル上にアサーションごとの成否を出力し、 json レポートはどのホップで障害が発生したかをエージェントが読み取って説明できるファイルを生成します。移行作業後にIDが解決できなくなった場合でも、エージェントが壊れたチェーンに基づいて回答を始める前にレポートで検知できます。マージごとに同じチェックを実行したい場合は、レポーターを -r junit に切り替えます。 Claude CodeでのApidog CLI活用 のウォークスルーで、エージェントの完全なループ処理を紹介しています。

Chain of Recallが適しているのは、エージェントのメモリがPR、チケット、CI実行、サポートスレッド、デプロイといった、個別のリンク可能なイベントの履歴である場合です。これらにはすでに自然なIDが存在しており、それらについて人が尋ねる質問（「なぜこれを行ったのか？」「その後に何が起きたのか？」）は、本質的にリンク（つながり）に関する問いだからです。

非構造化ドキュメントや曖昧な質問にはベクトル検索を使い、細部が欠落しても問題ない短時間のセッションには要約を活用するのが賢明です。

Chain of Recallは1つの論考と1つのプロトタイプから生まれたものであり、製品ではなく明確で検証可能なアイデアです。論考の背景にあるツールについては、まず DeepSeek Harnessとは何か をご覧ください。

いいえ。これはDeepSeek Harnessのスーパーエージェント論考に登場する用語であり、その一部がプロトタイププラグインに実装されているものの、著者らはDeepSeekの公式製品ではないとしています。このパターンは利用者自身で実装する必要があります。

インライン化は、ID、短い要約、前後のメッセージをプロンプト内に保持します。スピルはそれ以外の情報を切り捨て、必要に応じてエージェントがIDで取得できるポインタを残します。

いいえ。RAGが類似したコンテンツを検索するのに対し、Chain of Recallは厳密なIDリンクを辿ります。多くのエージェントでは両方を組み合わせて使用します。

いいえ。37%という数値はThreadのパススルーに関するものです。論考の実験では、パススルーを取り除いたことで実行あたりのキャッシュ読み取りトークン数が23.2Mから31.8Mに増加しました。論考自体では、Chain of Recallそのものによるトークン削減効果については報告されていません。

明確なエラーボディを持つ 404 Not Found を返すべきです。空のオブジェクトとともに 200 を返すと、エージェントはレコードが存在すると誤認し、想起チェーンが気づかないうちに破綻してしまいます。

ある呼び出しで得られたIDが次の呼び出しでも正しく解決されること、不明なIDには404が返されること、カーソルによるページネーションに欠落がないことを検証するテストケースを作成します。コーディングエージェントを使えば、マージごとにApidog CLIを通じてこれらを自動作成・実行できます。