AIエージェントの出力に来歴を残す設計｜コミットDAGと知識グラフで根拠を追える状態にする

AIエージェントを並列に増やすと、速さと引き換えに来歴——その出力がどこから来たのか——が失われます。誰が、どの根拠で、どの試行の続きとしてそれを出したのか。1体のうちは会話を遡れば分かります。並列になると会話は分断され、実行が終われば消えます。16体を同時に走らせた、1,000体まで積めた、11日で移植が終わった、という速さの話題の裏で、本当のボトルネックは次のモデル呼び出しではなく、記憶と評価をどこに置くかに移っています。

エージェントの実装手段そのものを俯瞰したい場合は、先に AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 を読むと、本記事が扱う「実行の設計ではなく記憶の設計」という切り口の位置づけがつかみやすくなります。

1. なぜエージェントを増やすほど「出力の根拠」が追えなくなるのか

単体のエージェントは、実は記憶に困りません。コンテキストウィンドウが会話ログ・中間結果・判断理由をすべて抱えていて、人間はそれを上から読めば経緯を再構成できます。記憶は「置き場所を設計するもの」ではなく「勝手にそこにあるもの」でした。

並列化はこの前提を静かに壊します。16体のワーカーがそれぞれ新しいコンテキストで走ると、記憶は16個に分裂します。しかも各ワーカーの文脈は実行終了とともに消えるため、オーケストレーターの手元には最終的な要約テキストしか残りません。「ワーカー7がなぜその結論に至ったか」は、要約に書かれていなければ復元不能です。ここで多くの実装が採る回避策——全ワーカーの記録をオーケストレーターに集める——は、並列化で節約したはずのコンテキストを再び1箇所に積み上げることになり、本末転倒になります。

・何が起きるか：出力は速く大量に出るのに、個々の根拠が辿れない
・何が失われるか：どの試行の続きなのかという系譜と、どの出典が主張を支えるのかという裏付け
・なぜ深刻か：検証できない出力は、量が増えるほど負債になる。誤りの発見が遅れ、修正の起点も特定できない

この問題設定は、エージェントの実行をどう組むかという議論とは層が違います。処理をノードとエッジで並列化する設計については エージェントをグラフとして設計する｜Claude Code動的ワークフローで多段処理を並列化する考え方、それをOSSでどう書くかは エージェントの処理をグラフとして設計するOSS｜Apache Burrで状態機械・分岐・ループを組む実装ガイド が扱っています。あちらは1回の実行の中の形、本記事は実行をまたいで何が残るかを扱います。

2. 記憶の置き場所は4層ある——会話ログ・成果物・コミットDAG・知識グラフ

記憶の置き場所は、永続性と答えられる問いの範囲で4つに整理できます。上の層が下の層を置き換えるのではなく、答える質問が違うため積み重なります。

多くの実装は左端の会話ログに全てを載せたまま並列化します。その結果、ワーカーの発見は要約という不可逆な圧縮を通ってしか外に出られません。設計として素直なのは、会話より先に成果物を保存し、代替案を生かしたいならコミットDAGを、関係と永続性が要るなら知識グラフを足す順序です。記憶を層に分けるという発想自体は製品側にも現れており、Claude Managed Agents「Memory」と「Dreaming」完全解説｜2層記憶アーキテクチャ で扱った2層構成も、短期の作業文脈と長期の知識を別の置き場所に分ける設計として読めます。

・何ができるか：実行が終わっても残る記憶に、後から問い合わせられる
・何を解決するか：並列ワーカーの発見が要約でしか外に出られない、という情報の目詰まり
・何を代替するか：「全ワーカーの記録をオーケストレーターに集める」という、並列化の利点を打ち消す運用

永続層は、どの実行パターンを採っていても効きます。Anthropic の「Building Effective Agents」（2024年12月19日）が定義した5つのワークフローパターン——プロンプトチェーン（各呼び出しが前段の出力を処理する固定手順）、ルーティング（入力を分類して専門処理へ振る）、並列化（同時実行して結果を集約）、オーケストレーター・ワーカー（中央のモデルが動的に分解・委譲・統合）、評価者・最適化者（一方が生成し他方が評価するループ）——に対して、永続層が果たす役割は次のように整理できます。

とくに最後の行が実用的です。「ベンダーXが事案Yに関わる部品を供給した」という主張を検証するとき、評価者は自由記述で「根拠が薄い」と言う代わりに、（ベンダーX －供給→ 部品Z）と（部品Z －関与→ 事案Y）というエッジの有無を確認し、どのエッジが欠けているかを構造化して返せます。「もっと調べて」より「この2本の出典付きエッジが必要」のほうが、次の一手が決まります。

3. コミットDAGで「作業の来歴」を残す——agenthubが外に出した設計

作業の系譜を残す仕組みとして分かりやすい実例が、Andrej Karpathy が2026年3月に公開した agenthub です。「人間のためのGitHubに対して、エージェントのためのagenthub」を掲げ、mainブランチもプルリクエストもマージも持たない設計を採りました。

フォークに残るREADMEによれば、実装は極めて小さく、1つのGoバイナリ（agenthub-server）・1つのSQLiteデータベース・ディスク上の1つのbare Gitリポジトリで構成されます。エージェントは git bundle でコードを push し、サーバーが検証して bare リポジトリに展開する。任意のコミットを fetch でき、DAGを辿って子・葉・系譜を調べ、任意の2コミットを diff できる。加えてチャンネル・投稿・スレッド返信を持つメッセージボードがあり、エージェントは結果・仮説・失敗・調整メモを自由に書き込みます。認証はエージェントごとのAPIキーで、レート制限とバンドルサイズ上限を持ちます。

この設計が面白いのは、人間のGitが前提にしている「収束」を全部外している点です。数千のエージェントが同時に探索する状況では、大半の結果は決してマージされません。それでも失敗した実験には証拠としての価値があります。だから主要な操作は「これをmainに取り込む」ではなく「探索グラフを辿る」になります。CLI（ah）のコマンド構成にその思想がそのまま出ています。

ah push                    # HEADコミットをハブへ送る
ah children <hash>         # この結果の上で何が試されたか
ah leaves                  # 子を持たない＝未探索のフロンティア
ah lineage <hash>          # ルートまでの祖先経路
ah diff <hash-a> <hash-b>  # 任意の2コミットを比較

children は「この結果の先で何が試されたか」を、leaves は「まだ誰も進んでいない枝はどこか」を、lineage は「この成果はどの経路から生まれたか」を答えます。従来のブランチモデルでは書きにくかった問い——メモリ制約下で最良の指標を出した採択結果はどれか、バッチサイズ変更の子孫にあたる実験群はどれか、複数のエージェントが独立に再発見した最適化はどれか——が、DAGの走査として自然に表現できます。

DAGが有効に働くには、その手前で1回の変更を巻き戻せる単位に切る必要があります。同じ作者の姉妹プロジェクト autoresearch が採った「1回に1つの変更を提案し、コミットし、評価し、改善していれば残す／していなければ直前の採択状態へ戻す」というラチェット構造は、そのまま設計条件として読み替えられます。

・出力が検証できる：測れる指標があること。測れないものを自律に任せない
・操作が巻き戻せる：失敗した試行が状態を壊さないこと
・試行の周期が短い：フィードバックが頻繁に返ること
・環境が閉じている：エージェントが取りうる行動の範囲が絞られていること

この4条件が揃って初めて、履歴を残すことに意味が生まれます。逆に、検証できない出力を巻き戻せない環境で走らせれば、DAGは失敗の記録を大量に貯めるだけの装置になります。記憶の設計は、可逆性の設計とセットです。

4. 一次ソースを当たると見えること——消えたリポジトリと止まった実験場

ここまでの設計思想は参照する価値があります。ただし、それをいま自分の基盤として採用できるかは別の問題です。当サイトで一次ソースを実測したところ、二次的な解説記事では触れられていない事実がいくつか出てきました（2026年7月27日時点）。

agenthub の公式リポジトリは、現在アクセスできません。 github.com/karpathy/agenthub は HTTP 404 を返し、Karpathy 氏の公開リポジトリ一覧（作成日降順）にも存在しません。公開直後に取得されたフォーク（ottogin/agenthub・140スター・2026年3月11日作成）が実質的な参照先になっており、本記事のアーキテクチャ記述もこのフォークのREADMEに基づいています。設計の出典として引用する場合、リンク先が失われている点は明示すべきです。なお同READMEは自ら「Work in progress. Just a sketch. Thinking…（作りかけ。ただのスケッチ）」と断っており、作者自身が完成品として提示していません。

姉妹プロジェクトの autoresearch は、4か月間更新が止まっています。 スター92,101・フォーク13,153（2026年7月27日実測）という数字だけを見ると活発なプロジェクトに見えますが、最終 push は 2026年3月26日。作成が3月6日なので、公開から3週間で更新が止まった計算になります。さらに LICENSE ファイルがありません。ライセンス未指定のリポジトリは既定で全ての権利が留保されるため、業務コードへの取り込みや再配布を前提にするなら、この点は着手前に確認が要ります。

転用すべきは実装ではなくアーキテクチャの条件です。変更を小さく区切ること、操作を巻き戻せること、評価を測定可能にすること、履歴を永続化すること。これらは基盤が何であっても成り立ちます。

5. 知識グラフで「事実の来歴」を残す——Anthropic公式Cookbookの実装を読む

作業の系譜に対して、事実の裏付けを担うのが知識グラフです。ここは推測で語る必要がありません。Anthropic が公式に公開している claude-cookbooks（MITライセンス・50,207スター）に、capabilities/knowledge_graph/ として動くノートブックが置かれています。実際の guide.ipynb を読むと、構成は次の5段でした。

注目すべきはモデルの割り当てです。ノートブックは EXTRACTION_MODEL = "claude-haiku-4-5"、SYNTHESIS_MODEL = "claude-sonnet-4-6" と定義しており、大量に回る抽出には安価で高速なモデルを、判断を要する解決・要約・照会には強いモデルを充てています。文書数に比例して膨らむのは抽出のコストなので、この割り当てはコスト構造に直接効きます。

もう一点は、古典的なNLPパイプラインが1つの構造化出力プロンプトに畳まれていることです。従来なら固有表現認識器と関係分類器を個別に学習させる工程が、Pydanticスキーマ（Entity / Relation / ExtractedGraph）を output_format に渡す1回の呼び出しに置き換わっています。スキーマが実質的に唯一の「教師データ」になる、という構図です。

照会も素直です。serialize_subgraph(center, hops=2) が示すとおり、グラフ全体をモデルに流し込むのではなく、起点の実体から2ホップだけ辿って直列化します。ここは重要な設計判断で、グラフを持つと今度は「グラフ丸ごとをコンテキストに積む」という新種のコンテキスト肥大が起きがちです。各ワーカーに渡すのはタスク固有の部分グラフに限る、という原則を実装が体現しています。

実装にあたって決めておくと後が楽なのが、書き込みが常に満たすべき不変条件です。ここを緩めると、グラフは育つほど信用できなくなります。

・すべての主張は出典を持つか、推論であることが明示されている
・すべての成果物はそれを生んだ実行と版を持つ
・すべての評価はどの基準で判定したかを特定できる
・置き換えられた古いオブジェクトも参照可能なまま残る（削除ではなく supersede）

ノードの型は実体・主張・出典・成果物・実行記録・評価・タスク・コミット・指標あたり、エッジの型は「言及する」「支持する」「矛盾する」「由来する」「produced」「評価した」「置き換えた」「依存する」「親である」「解決先」あたりから始めれば足ります。重要なのは種類の多さではなく、すべてのエッジに出典と実行IDが付いていることです。

エージェントの記憶層そのものを製品として比較検討したい場合は、BrainAPIとは｜エージェントが自分でナレッジグラフを描くAIメモリ層をmem0・cogneeと比較 が mem0・cognee・supermemory などの選択肢を整理しています。本記事は製品選定ではなく、どの層に何を置くかという設計判断を扱っています。

6. エンティティ解決は推論タスク——誤マージが下流の全走査を汚染する

抽出が生むのは綺麗なグラフではなく、表層形の集合です。同じ人物や組織が、略称・別名・旧名・表記ゆれ・部分名で何度も現れます。ここを機械的な文字列類似度で片付けようとすると、両方向に失敗します。

・取りこぼし：文字列がまったく重ならない同一実体（英語圏の例では “Edwin Aldrin” と “Buzz Aldrin” に共通文字がほぼ無い）
・誤結合：同姓同名の別人を、名前が一致するというだけで1つに潰してしまう

公式Cookbookが採るのは、説明文を文脈上の証拠として使い、実体型ごとに候補をまとめてから、強いモデルに正規クラスタを提案させるという方法です。つまり解決を文字列処理ではなく推論タスクとして扱っています。規模が大きい場合は、安価な絞り込み（ブロッキング）で候補集合を狭めてからモデルの判断に渡すのが現実的です。

そして、この工程で最も警戒すべきは誤マージです。取りこぼしは「繋がらない」だけで済みますが、誤マージは違います。2人の人物が1つのノードに潰れると、その下流の走査はすべて両者の所属・案件・日付・行動を混ぜて返すようになり、汚染がグラフ全体に広がります。しかも出力は一見すると流暢で整合的なので、気づきにくい。

・何ができるか：表層形の揺れを吸収しつつ、統合の判断を後から検証・取り消しできる
・何を解決するか：文字列類似度では届かない同一性判定と、静かに広がる誤マージ汚染
・何を代替するか：固有表現認識器と関係分類器を個別に学習・保守する古典的NLPパイプライン

7. 層ごとに評価指標は違う——よくある誤読と、グラフを使わない判断

来歴を残す仕組みを入れたら、次はそれが機能しているかを測る番です。ここで厄介なのは、層ごとに見るべき指標が違い、しかもそれぞれに典型的な誤読があることです。

評価そのものを仕組み化する動きも進んでいます。エージェントの構成要素を定量的に採点する枠組みについては Microsoft Waza｜Agent Skillsの品質を測るGo製評価フレームワークを解説 が参考になります。ここでの論点は、採点を回すこと自体より何を測っているつもりなのかを取り違えないことです。

とくに解決の圧縮率（表層形の数 ÷ 正規実体の数）は罠です。圧縮率が高いほど整理が進んだように見えますが、過剰統合すれば圧縮率はいくらでも上がります。連結していて、かつ誤ったグラフができあがる。適合率と再現率を分けて見る必要があるのはこのためです。

本番では単発のスコアより傾向を追うほうが実用的です。文書種別ごとの抽出率、スキーマ違反率、解決の圧縮率、連結成分数の変化、照会レイテンシ、部分グラフのサイズ、引用エッジの妥当性、トークンコスト、更新失敗率。孤立ノードの急増は解決の劣化を、急減は過剰統合を示唆します。

マルチエージェント構成では、さらに実行そのものに上限を宣言しておくことが評価とセットになります。モデル呼び出し数、サブエージェント数、同時実行数、ツール呼び出し数、実時間、トークン、金額、再試行回数、グラフ書き込み数、そして「最終化に必要な最小限の証拠」。上限に達したときの振る舞いも決めておきます——現時点で最良の成果物、完了した作業、未解決の論点、そして停止した理由を返す。ここで最もやってはいけないのは、部分的な失敗を流暢な最終回答の裏に隠すことです。読み手が失敗に気づけない出力は、間違っているより質が悪くなります。

そして最後に、使わない判断も設計のうちです。エージェントがいるという理由だけで知識グラフを導入すべきではありません。次のいずれかに当てはまるなら、グラフは抽出誤りというコストだけを増やします。

・タスクが互いに独立していて、実行をまたぐ状態が要らない
・答えが単一の文書で完結する
・関係が固定的で単純、リレーショナルなテーブルで全ての問い合わせに答えられる
・出典の追跡が求められていない
・抽出誤りの害が、走査で得られる価値を上回る

グラフが費用に見合うのは、連結した問い合わせ・変化する関係・出典の追跡・共有される世界像のいずれかが中心にあるときです。導入も段階的でよく、まずは versioned なJSONやリレーショナルなテーブルに実体・主張・出典・成果物・実行記録・評価を書き出すところから始められます。

段階を踏むときに大事なのは、各段に次へ進んでよい条件を決めておくことです。条件を決めずに層を積むと、効いているかどうか分からないまま複雑さだけが増えます。

順序に意味があるのは、各段が前段の限界に対処しているからです。ループは一発生成の誤りに、ツールは知識の欠落に、計画は複雑さに、役割分割は視点の偏りに、DAGは系譜の追跡に、知識グラフは持続する共有記憶に、それぞれ対応します。飛ばしても構いませんが、飛ばした段の限界は残ります。

なお並列実行の実績としてよく引かれる Bun の Zig→Rust 移植は、Bun公式ブログが一次ソースです。実際の数字は、コメントを除く 535,496行のZig（1,448ファイル）を対象に、約50の動的ワークフローと最大同時約64体のClaudeで11日間（2026年5月3日〜14日）、差分は +1,009,272行、コストは API 価格換算で約16万5,000ドル。テストについて公式は「0 tests skipped or deleted」「CIで全プラットフォームのテストスイートが通った」と記しています。二次資料では移植行数や合格率が実際と異なる形で流通しているため、数字を引用する際は公式ブログで確認する価値があります（Zig作者から品質面の批判が出ている点も併せて把握しておくとバランスが取れます）。

まとめ

エージェントの設計を「どのモデルを何体並べるか」で考えている限り、増やすほど不透明になります。転換点は、記憶と評価を会話の外に出すことです。

・会話ログは揮発する。並列化した瞬間に、根拠は要約という不可逆な圧縮でしか外に出られなくなる
・コミットDAGは作業の系譜に答える。分岐を保持し、捨てた実験も証拠として残す。agenthub の children / leaves / lineage はその語彙
・知識グラフは事実の裏付けに答える。Anthropic公式Cookbookは抽出をHaiku、解決・要約・照会をSonnetに割り当て、2ホップの部分グラフだけを直列化する
・誤マージは最も高くつく失敗。解決は追記的・可逆に設計し、別名・出典・根拠・確信度・実行IDを残す
・指標は層ごとに違う。圧縮率の高さは品質ではなく、過剰統合の兆候かもしれない
・グラフを使わない判断も設計。独立タスク・単一文書・固定的な関係なら、導入はコストだけを増やす

目指す状態は一文で書けます。重要な出力はすべて、目的・計画・成果物・出典・グラフ上の経路・評価の判断・実行記録のどれかに辿り着ける。 これが成り立たないまま人数を増やすと、不透明さだけが増えます。成り立っていれば、ループもDAGも知識グラフも、組み合わせて使える部品になります。

参照した agenthub と autoresearch は、いずれも作者自身がスケッチと位置づけ、更新も止まっています。それでも、どの慣習が最初に壊れるか——単一のmainブランチ、人間の速度のレビュー、会話ログに依存した記憶、マージ中心の協働——を先に示した点に価値があります。借りるべきは実装ではなく、この診断です。

参照ソース

・anthropics/claude-cookbooks — capabilities/knowledge_graph（MITライセンス。抽出・解決・組み立て・要約・照会・評価の実装は guide.ipynb を実読して確認。モデル割り当て・serialize_subgraph(center, hops=2)・評価スクリプト evaluation/eval_extraction.py も同ディレクトリ。2026-07-27アクセス）
・Building Effective Agents — Anthropic Engineering（2024-12-19。プロンプトチェーン／ルーティング／並列化／オーケストレーター・ワーカー／評価者・最適化者の5パターンの定義）
・karpathy/autoresearch（スター・フォーク数、最終push、ライセンス有無はGitHub APIで2026-07-27に実測）
・ottogin/agenthub（公式リポジトリ消失後に参照可能なフォーク。アーキテクチャ・CLI・「Just a sketch」の記述はこのREADMEに基づく）
・Rewriting Bun in Rust — Bun 公式ブログ（移植行数・期間・並列数・コスト・テスト結果の一次情報）