記事一覧に戻る
AIエージェントナレッジグラフClaude CodeAnthropic論文解説テクノロジー

グラフエンジニアリング：Karpathyのループが1000倍に育つまで｜autoresearch → AgentHub → Anthropicの実装を読む

目次

本記事は、公開情報をもとに独立して編纂された技術ノート “Graph Engineering — The Karpathy Loop, Improved 1000x by Itself: The Anthropic Playbook”（Agentic Software Engineering Practice 2026、2026年7月編纂）の全内容を日本語で解説したものです。

出典と免責について（原文の明示）：この文書は Anthropic の Knowledge Graph Construction Cookbook と、Andrej Karpathy の公開講義・発表資料に基づいて編纂された、学習用の独立した統合ノートです。Andrej Karpathy、Anthropic、Sequoia Capital、Bun、その他本文中で言及されるいかなる組織とも提携しておらず、承認も受けていません。

読みやすさのために段落構成と表現は日本語向けに整えていますが、内容・図・表・コードは一切省略していません。

この記事の要点（60秒）

Karpathy は 630 行のコードで autoresearch を作り、エージェントに 2 日間で約 700 回の ML 実験を回させ、20 個の有用な最適化を自律的に発見させました。彼はさらに「単一の博士学生を模倣するのではなく、研究コミュニティを模倣する」ことを目標に掲げ、コミット DAG でエージェント群が協調する AgentHub を作りました。Anthropic は独立に、その本番版とも言える基盤を出荷しています——単一プロンプトから最大 1,000 個の並列サブエージェントを起動する Dynamic Workflows と、学習済み NLP パイプラインを構造化出力プロンプトで置き換える Knowledge Graph Cookbook です。

本記事は、この「ループ → グラフ」への進化を地図として描き、Day 1 から Month 2 までの段階的な構築手順まで示します。

図1：マルチエージェントシステムのためのナレッジグラフ・スキーマ

中央の AGENT ノードが、有向エッジを通じて型付きの実体（typed entities）に接続します。追加のプロパティとキーワードが各実体を拡張し、より豊かなグラフ探索を可能にします。

graph LR
    T1["Title : Description"] --> FP["First Person<br/>(例: name, role,<br/>category (employee), math)"]
    T2["Title Description"] --> OA["Object Above<br/>(例: machine, collaboration)"]
    FP --> TOOLS["Tools"]
    OA --> TOOLS
    TOOLS --> AGENT["AGENT"]

    EPE["Extra Person Entity<br/>(Employee, Person,<br/>other entities)"] --> EPK["Extra Person Keyword"]
    EPA["Extra Property / Attribute<br/>(Provider, Age,<br/>Length, Area)"] --> EPK
    EPK --> AGENT

    AG["Agency / Group"] --> AGENT
    T3["Title Description"] --> TB["Text Button<br/>(例: contract details,<br/>sum by any terms)"]
    TB --> AGENT
    T4["Title : Description"] --> OB["Object Below<br/>(例: metric, tool list,<br/>sum by any terms)"]
    OB --> AGENT

索引語（Index Terms）：グラフエンジニアリング、ナレッジグラフ、マルチエージェントシステム、エージェントスウォーム、エージェンティックエンジニアリング、Dynamic Workflows、構造化出力。

I. はじめに

Karpathy の autoresearch の README は、意図的に誇張された「未来からの歴史記述」でこう始まります。

「かつてフロンティアAI研究は、食事・睡眠・その他の娯楽の合間に肉製コンピュータによって行われ、たまに『グループミーティング』という儀式の中で音波インターコネクトを使って同期していた。その時代はとうに過ぎ去った。研究はいまや完全に、自律的なAIエージェント群の領域である。」 — Karpathy, autoresearch README

Karpathy の一連の仕事は、抽象度における3つの変化として読めます。2025年初頭、バイブコーディング（vibe coding）は「床を下げた」ことを表現しました。2026年までに、エージェンティックエンジニアリングはより高い専門的水準を表現するようになりました——エンジニアはセキュリティ、正しさ、アーキテクチャ、センス、検証に責任を持ち続けたまま、実装作業をより多くエージェントに委譲する、という水準です。

autoresearch は、この同じ移行を ML 実験の領域に押し込みます。リポジトリは小さなシングルGPU学習セットアップを露出させ、エージェントに「一度に一つの変更」を行うよう求めます。中核コードはおよそ630行で、拡張実行では2日間で約700回の実験が走り、約20個の有用な最適化が保持されたと報告されています。

次のアーキテクチャ的ステップは協調（collaboration）です。Karpathy は、autoresearch は SETI@home のスタイルで「エージェントにとって非同期かつ大規模に協調的（asynchronously massively collaborative for agents）」になるべきであり、目標は1人の博士学生ではなく研究コミュニティを模倣することだと書きました。AgentHub はその層のスケッチです。ベアな Git リポジトリ、SQLite データベース、HTTP サービス、薄い CLI、そしてメッセージボードを組み合わせています。

Anthropic のインフラ資料は、並行する進化を記述しています。2024年の “Building Effective Agents” ガイドは、単純で組み合わせ可能なパターンを優先するよう勧めます。2026年の Dynamic Workflows 資料はその考えを拡張し、オーケストレーションを生成された JavaScript に移し、新鮮なコンテキストを持つサブエージェントを並列に起動します。Anthropic の Knowledge Graph Construction Cookbook はさらに、非構造化文書がどのように型付き実体と関係に変換され、正準ノードへ解決され、グラフとして組み立てられ、直列化された部分グラフを通じてクエリされるかを示します。

重要な統合的洞察は、各アーキテクチャがそれぞれ異なるボトルネックを外部化している、という点です。

  • ループ（loop）は、反復と評価を外部化する。
  • チェーン（chain）は、タスクの順序を外部化する。
  • スウォーム（swarm）は、並列探索と役割の専門化を外部化する。
  • DAGは、実験の系譜（lineage）を外部化する。
  • ナレッジグラフは、共有された事実、来歴（provenance）、セッションをまたぐ記憶を外部化する。

Karpathy はこう要約しています。

「エージェントのスウォームを立ち上げ、彼らに協調して小さなモデルをチューニングさせ、最も有望なアイデアを段階的に大きなスケールへと昇格させる。そして人間はオプションとして、その縁（edges）で貢献する。」

図解：5つのアーキテクチャが外部化するもの（本記事による整理）

graph TD
    L["ループ<br/>Loop"] -->|外部化| L1["反復と評価"]
    C["チェーン<br/>Chain"] -->|外部化| C1["タスクの順序"]
    S["スウォーム<br/>Swarm"] -->|外部化| S1["並列探索と<br/>役割の専門化"]
    D["DAG"] -->|外部化| D1["実験の系譜"]
    K["ナレッジグラフ<br/>Knowledge Graph"] -->|外部化| K1["共有された事実<br/>来歴・セッション横断記憶"]

A. このノートの対象読者

このノートは、すでに LLM を呼び出す方法を知っていて、その周りにどれだけのシステムアーキテクチャを置くべきかを判断する必要があるエンジニアに向けたものです。読者は Python、Git、JSON スキーマ、および基本的なグラフ用語に慣れていることが想定されています。

B. 本ノートの3つの貢献

この統合は3つの貢献をします。

第一に、Karpathy の autoresearch から AgentHub への進化を、Anthropic のワークフロー基盤の上にマッピングします。このマッピングが示すのは、ループ、オーケストレーションスクリプト、evaluator-optimizer ワークフロー、コミット DAG が無関係な製品カテゴリではなく、制御と状態の「置き場所」が異なるだけだということです。

第二に、ナレッジグラフを共有メモリ層として扱います。これにより、マルチエージェントシステムは、すべてのワーカーの会話ログをオーケストレータのコンテキストにコピーすることなくスケールできます。主張（claims）、ソース、成果物（artifacts）、評価、バージョンが、永続的なグラフオブジェクトになります。

第三に、段階的な構築パスを提供します。パスは1つの計測されたループから始まり、ツールと計画を追加し、専門化が有用な場合にのみ複数のワーカーを導入し、成果物を永続化し、型付きグラフを構築し、最終的に並列作業をスウォームへとスケールさせます。

II. Karpathyのループ：autoresearch

A. 最小の自律的研究組織

autoresearch は、狭いが重要な設計上の選択から始まります。エージェントは、実行可能な「研究ハーネス」の内側に置かれるということです。このハーネスは、可変な学習プログラム、固定された評価指標、時間予算、Git履歴、そして指示を露出させます。

3つのファイルが中核です。

  1. prepare.py — 固定されたデータ準備と評価ユーティリティ。エージェントは変更しない。
  2. train.py — モデル、オプティマイザ、ハイパーパラメータ、学習ループ。エージェントが編集する実験面。
  3. program.md — 研究プロセス、制約、指標、ロギング規則、自律性ポリシーを記述する。

エージェントが回すループは次のとおりです。

LOOP FOREVER:
  1. 現在の train.py と直近の履歴を読む。
  2. 動機づけられた変更を1つ提案する（program.md に従って）。
  3. 候補となる変更をコミットする。
  4. 学習を約5分間走らせる。
  5. val_bpb とピークメモリを計測する。
  6. クラッシュした場合: 調査し、機械的な問題なら修正、そうでなければ revert。
  7. val_bpb が改善した場合: コミットを保持する。
     そうでない場合: 直前の保持済みコミットへ reset する。
  8. 結果を記録し、人間に尋ねることなく継続する。

B. 「プログラムをプログラムする」

最も転用可能なアイデアは、program.md は「プログラムをプログラムすること（programming the program）」であるという点です。

  • Software 1.0 では、開発者が明示的な命令を書く。
  • Software 2.0 では、開発者がデータと学習を通じて振る舞いを形作る。
  • Software 3.0 では、Karpathy が論じるように、コンテキストとプロンプトがプログラマブルなインタフェースになる。

autoresearch はさらにもう一層を加えます。自然言語による指示が、自律的な「組織」を構成（configure）するという層です。

有用な program.md は、次を確立します：可変ファイルと保護ファイル、指標とその改善方向、実験予算、実行コマンド、出力パース方法、クラッシュ処理、commit / revert の規則、ロギング、人間へのエスカレーションポリシー、そして打ち切り基準（exhaustion criteria）。

C. 報告された結果と、その意味

提供された概要レポートは、2日間で約700回の実験と20個の保持された最適化を報告しています。その中には、QK正規化のスケーリング、値埋め込み（value-embedding）の正則化、AdamW のパラメータチューニングに関する変更が含まれます。夜通し走らせたエージェントのレポートには、バッチサイズ変更、深さの変更、埋め込み学習率、RoPE の基底周波数、標的を絞った weight decay、初期化スケール、warmdown 設定による累積的な改善が示されています。

アーキテクチャ上の教訓は、個々の最適化のどれよりも信頼できます。人間の研究者は通常、仮説、失敗した試み、パラメータ間の相互作用をワーキングメモリの中に抱えています。autoresearch はこれらを機械可読な履歴に変換します。すべての実験が、親状態、コードdiff、指標、そして保持か破棄かの判断を持ちます。ループは狭い最適解を探索し、以前の系統を再訪し、失敗の後も継続できます。

このリポジトリは 86,000 を超える GitHub スター と 12,500 のフォークを集めています。リポジトリの人気は科学的な性能指標ではありません。むしろ、このパターンが理解しやすく再現しやすいことの証拠として解釈するのが適切です——コードが小さく、指標が可視で、実験ループが読める（legible）ということです。

D. なぜこのループは機能するのか

4つの条件が、autoresearch を自律エージェントと異例なほど相性良くしています。

  1. 出力が検証可能である。 学習は計測可能な検証結果を生む。
  2. 行動が可逆である。 git reset が最後に保持された状態へ戻す。
  3. ホライズンが短い。 5分間の実行が頻繁なフィードバックを生む。
  4. 環境が有界である。 リポジトリが行動空間を狭める。

これらは再利用可能なテンプレートを形作ります。

def ratchet_loop(inspect, propose, apply, evaluate,
                 keep, revert, better, baseline):
    history, current = [], baseline
    while True:
        state = inspect()
        change = propose(state)
        commit = apply(change)
        try:
            score = evaluate()
        except Exception as exc:
            revert(commit)
            history.append(Trial(commit, change,
                                 None, "crash",
                                 str(exc)))
            continue
        if better(score, current):
            keep(commit); current = score
            history.append(Trial(commit, change,
                                 score, "kept",
                                 ""))
        else:
            revert(commit)
            history.append(Trial(commit, change,
                                 score,
                                 "reverted", ""))

Karpathy は再帰的なモデル改善を「ラスボス戦（the final boss battle）」と呼び、フロンティアの研究所はこれを追求するだろうと述べています。

III. ループからスウォームへ：AgentHub

A. 人間のためではなく、エージェントのためのGitHub

AgentHub は自らをエージェントファーストの協調プラットフォーム——ベアな Git リポジトリ＋スウォーム用のメッセージボード——と説明します。中心的なスローガンはこうです。

GitHub is for humans. AgentHub is for agents. （GitHubは人間のためのもの。AgentHubはエージェントのためのもの。）

エージェントによる研究は、人間の Git 前提を反転させます。数千のエージェントが同時に探索できます。ほとんどの結果は決してマージされないかもしれません。失敗した実験でも有用な証拠を含み得ます。主要な操作はもはや「これを main にマージする」ではありません。それは「探索グラフを辿る（traverse the search graph）」です。

AgentHub は収束のための抽象化を取り除きます：必須の main ブランチなし、プルリクエストなし、マージキューなし、そして「ひとつの葉（leaf）が正準である」という前提もなし。

B. 最小限のアーキテクチャ

ソースリポジトリはコンパクトな実装を記述しています：1つのGoサーバーバイナリ、1つのSQLiteデータベース、ディスク上の1つのベアGitリポジトリ、エージェントごとに1つのAPIキー、レート制限とバンドルサイズ制限、そして薄い ah コマンドラインインタフェース。

この設計は意図的にメカニズム（mechanism）とカルチャー（culture）を分離しています。AgentHub は、エージェントが検証損失を最適化しているのか、テストを修正しているのか、脆弱性を探しているのか、API を設計しているのかを知りません。エージェントが何を投稿し、結果をどう記述し、どの実験を試みるかは、プロンプトとプロジェクト指示が定義します。

C. グラフインタフェースとしてのCLI

ah push              # HEADコミットをhubへpush
ah fetch <hash>      # 任意のコミットをfetch
ah log [-agent X]    # 直近のコミットを表示
ah children <hash>   # この上に何が試されたか？
ah leaves            # フロンティア: 子を持たないもの
ah lineage <hash>    # ルートまでの祖先パス
ah diff <hash-a> <hash-b>  # 任意の2コミットを比較

これらのコマンドは、協調の単位が変わったことを符号化しています。children は「ある結果の上にどんなアイデアが試されたか」を問います。leaves は未探索のフロンティアを明らかにします。lineage は、ある結果を生んだ経路を再構成します。

D. DAGこそがグラフである

鍵となる洞察は文字どおりです：the DAG is the graph（DAGこそがグラフである）。コミットがノード。親リンクが有向エッジ。

autoresearch の場合、1つのコミットノードは次を担い得ます：親コミット、それを作成したエージェント、仮説、コードdiff、指標、実行時間、メモリ使用量、環境、保持/破棄のステータス、ディスカッション投稿へのリンク、関連実験へのリンク。

グラフ探索は、従来のブランチモデルでは扱いにくい問いに答えられます。

  • メモリ制限の下で、最良の指標を持つ保持済み結果はどれか？
  • バッチサイズ変更から派生した実験はどれか？
  • どのエージェントが独立に同じ最適化を再発見したか？
  • 評価が付いていない葉はどれか？
  • 急速に改善したのち停滞した系統はどれか？
graph LR
    R["root commit"] --> A["実験A<br/>batch size 変更<br/>val_bpb ↓ / kept"]
    R --> B["実験B<br/>depth 変更<br/>val_bpb ↑ / reverted"]
    A --> C["実験C<br/>RoPE base 変更<br/>kept"]
    A --> D["実験D<br/>weight decay<br/>crash / reverted"]
    C --> E["実験E<br/>warmdown 設定<br/>kept ← leaf"]
    C --> F["実験F<br/>未評価 ← leaf"]
    B --> G["実験G<br/>init scale<br/>kept ← leaf"]

図解（本記事による整理）：コミットDAG。leaves は未探索フロンティア（E・F・G）を、lineage は E → C → A → root の経路を返す。

E. 共有コンテキストなしの協調

メッセージボードが社会的な層（social layer）を提供します。エージェントは仮説、失敗、要約、調整メモを投稿できます。破棄された変更でも、「あるアイデアはある条件下で失敗する」ことを他のエージェントに教え得ます。ディスカッション投稿は、その理由を記述し、実験の系譜を引用し、別の分岐点を提案できます。

このシステムはコンテキストのコピーを削減します。エージェントは過去のすべての会話ログを必要としません。関連する系統をクエリし、いくつかの要約を読み、コミットを取得して継続できます。これがグラフに接地したコンテキスト構築（graph-grounded context construction）の始まりです——履歴全体を再生するのではなく、現在の判断に必要な接続された状態だけを取得するということです。

F. AgentHubは「スケッチ」である

リポジトリは明示的に警告しています。

「Work in progress. Just a sketch. Thinking…」（作業中。ただのスケッチ。考え中……）

欠けている重要な関心事には、次が含まれます：分散ストレージ、リポジトリのコンパクション、エージェント間の信頼、悪意あるバンドル、実験の再現性、意味的な重複検出、計算資源のスケジューリング、長期的なグラフのインデクシング。

この限界は、むしろアーキテクチャ上の教訓を強めます。このリポジトリは、エージェントが多数になったときにどの従来型抽象化が最初に破綻するかを特定しています——単一の main ブランチ、人間のペースに合わせたレビュー、会話ログベースの記憶、そしてマージ中心の協調です。

IV. Anthropicの基盤：5つのパターンから1,000エージェントへ

A. 5つのワークフローパターン

Anthropic の2024年のガイダンスは、最も単純で組み合わせ可能なパターンから始めることを推奨しています。

  • Prompt Chaining（プロンプト連鎖）。 1つのモデル呼び出しが、次のための成果物を生む。固定されたシーケンス。
  • Routing（ルーティング）。 分類器が入力を、専門化されたプロンプト・モデル・ツールセットへ振り分ける。
  • Parallelization（並列化）。 独立した呼び出しを並行実行する。セクショニングまたは投票。
  • Orchestrator-Workers（オーケストレータ＝ワーカー）。 中央のモデルが動的に分解し、割り当て、統合する。
  • Evaluator-Optimizer（評価者＝最適化者）。 一方の役割が生成し、もう一方が基準に照らして評価する、をループさせる。

B. Dynamic Workflows

開発者が静的なファンアウト・スクリプトを書く代わりに、Claude が今回のタスク向けの JavaScript オーケストレーションプログラムを書きます。

const files = await tools.glob("src/**/*.ts");
const audits = await gather(
  files.map((file) =>
    spawn("auditor", {
      file,
      instructions:
        "Inspect for race conditions. Return JSON."
    })
  ),
  { concurrency: 16 }
);
const suspicious = audits.filter(
  (r) => r.confidence >= 0.70
);
const reviews = await gather(
  suspicious.map((r) =>
    spawn("reviewer", {
      report: r,
      instructions:
        "Try to refute this finding."
    })
  ),
  { concurrency: 16 }
);
return await spawn("synthesizer", {
  audits,
  reviews,
  instructions: "Produce one cited report."
});

主要な仕様：同時実行サブエージェントは最大16、1ワークフローあたりのハードキャップは1,000、各サブエージェントには新鮮なコンテキスト、中間状態はスクリプト変数に保持、トリガーは “workflow” という語または ultracode モード。

Bun ランタイムの移植事例：約75万行の Zig から Rust への移植を11日間で、テスト通過率99.8%。

C. ナレッジグラフの構築

Anthropic の Cookbook は、古典的な NLP パイプラインを、モデル呼び出しと構造化スキーマで置き換えます。

  1. 抽出（Extraction / Haiku）。 スキーマ制約付きの呼び出しが、型付き実体と S-P-O（主語-述語-目的語）関係を抽出する。
  2. 解決（Resolution / Sonnet）。 候補を型と文脈でクラスタリング。“Edwin Aldrin” → “Buzz Aldrin”。
  3. 組み立て（Assembly）。 NetworkX の MultiDiGraph。ノードは type、source、count を持つ。エッジは predicate、provenance を持つ。
  4. クエリ（Querying / Sonnet）。 部分グラフをトリプルとして直列化。Claude はエッジ単位の引用付きで推論する。
class Entity(BaseModel):
    name: str
    type: EntityType
    description: str

class Relation(BaseModel):
    source: str
    predicate: str
    target: str

def extract(text, client) -> ExtractedGraph:
    response = client.messages.parse(
        model="claude-haiku-4-5",
        messages=[{"role": "user",
                   "content":
        PROMPT.format(text=text)}],
        output_format=ExtractedGraph,
    )
    return response.parsed_output

Pydantic スキーマが唯一の「訓練データ」です。学習済みの NER と関係分類器が、文書ごとに1つの構造化出力プロンプトへと畳み込まれます。

graph LR
    DOC["非構造化文書"] --> EX["1. 抽出<br/>Haiku<br/>スキーマ制約付き"]
    EX --> SF["表層形<br/>(surface forms)"]
    SF --> RES["2. 解決<br/>Sonnet<br/>型・文脈でクラスタリング"]
    RES --> CAN["正準ノード<br/>(canonical entities)<br/>+ aliases / 根拠 / 確信度"]
    CAN --> ASM["3. 組み立て<br/>NetworkX MultiDiGraph<br/>ノード: type/source/count<br/>エッジ: predicate/provenance"]
    ASM --> QRY["4. クエリ<br/>Sonnet<br/>部分グラフをトリプル直列化"]
    QRY --> ANS["エッジ単位の引用付き回答"]

図解（本記事による整理）：Knowledge Graph Construction Cookbook の4段階パイプライン。

D. 推論タスクとしての実体解決（Entity Resolution）

抽出が作るのは表層形（surface forms）であって、綺麗なグラフではありません。同一の人物や組織が、略称、別名、旧名、綴りの揺れ、部分名の下に現れ得ます。単純な文字列類似度は、ラベルが大きく異なるケース（“Edwin Aldrin” 対 “Buzz Aldrin” — 文字の重なりはゼロ）を取りこぼし、また同姓同名の別人を誤って統合し得ます。

Cookbook は説明文（descriptions）を文脈的証拠として使います。候補を実体の型でグループ化し、より強いモデルに正準クラスタを提案させます。スケール時には、安価なブロッキング信号でモデルによる裁定の前に候補集合を絞り込むべきです。

解決は加算的（additive）かつ検査可能（inspectable）であるべきです。正準実体は、その別名、ソース文書、解決の根拠、確信度、そしてその統合を作成した実行（run）を保持すべきです。そうすれば、誤った統合はパイプライン全体を再構築することなく巻き戻せます。

E. グラフの組み立てとクエリ

プロパティグラフ形式で、最小限だが有用な来歴（provenance）を保存します。

G = nx.MultiDiGraph()

def add_entity(entity, source_doc):
    G.add_node(entity.canonical_id,
        name=entity.name,
        entity_type=entity.type,
        description=entity.description,
        source_docs={source_doc},
        aliases=set(entity.aliases))

def add_relation(relation, source_doc):
    G.add_edge(relation.source_id,
        relation.target_id,
        predicate=relation.predicate,
        source_doc=source_doc,
        confidence=relation.confidence)

マルチホップのクエリで、グラフ全体をモデルに投げ込んではいけません。アプリケーションは開始実体を特定し、有界な近傍を辿り、エッジを型や日付でフィルタし、結果を直列化します。回答はエッジ識別子を引用できます。ある記述が裏付けを欠く場合、評価者は欠落している、あるいは矛盾しているエッジを特定できます。

表I：Anthropicの各ワークフローパターンにおけるグラフの役割

パターングラフの役割どう役立つか
Augmented LLM検索ソースマルチホップな問いのためのグラフ探索
Prompt Chaining検証ストア現在のグラフに照らして実体を確認
Routing分類器の入力実体の型と次数（degree）がクエリを振り分ける
Parallelization共有サーフェスワーカーが重複しない発見を公開する
Orchestrator-Workers共有メモリワーカーがグラフを読み書きし、オーケストレータのコンテキストは汚れないまま
Evaluator-Optimizer接地層（grounding layer）評価者がグラフのエッジに照らして主張を検証

F.「あなたがワークフローを作る」から「Claudeがワークフローを作る」へ

2024年のガイドは、エンジニアが単純なワークフローを作るべきだと言いました。2026年の機能は、Claude がその場でワークフローを作れると言います。これは抽象化の境界を変えますが、エンジニアリング上の責任を取り除きはしません。

人間は依然として次を定義します：目的、スコープに含まれるファイル、出力契約（output contract）、権限、検証ポリシー、並行度とトークン予算、ロールバック規則、そして統合に必要な証拠。

V. 共有メモリとしてのグラフ

グラフには3つの役割があります。

役割1：共有メモリ（Shared memory）

ワーカーは発見を構造化されたグラフ更新として書き込みます。統合者（synthesizer）はグラフを辿ることで、どのワーカーもすべてのソース文書を見ていなくても発見を結合できます。

@dataclass
class GraphUpdate:
    nodes: list[dict]
    edges: list[dict]
    run_id: str
    agent_id: str

def publish(update, graph, validator):
    validator.check_schema(update.nodes,
        update.edges)
    validator.check_provenance(
        update.nodes, update.edges, update.run_id)
    with graph.transaction() as tx:
        tx.upsert_versioned_nodes(update.nodes)
        tx.add_edges(update.edges)
        tx.link_run(update.run_id, update.agent_id,
                    update.nodes, update.edges)
        tx.commit()

役割2：接地層（Grounding layer）

評価者が、証拠に照らして主張を検証します。次の主張を考えてみます：「ベンダーXは、インシデントYに関与した部品を供給した」。

グラフに接地した評価者は、(Vendor X, supplied, Component Z) と (Component Z, involved_in, Incident Y) というエッジの存在を確認できます。エッジが欠けている場合、評価者は構造化されたフィードバックを返します。

{
  "decision": "revise",
  "claim": "Vendor X supplied the component in Y",
  "reason": "No supported path from Vendor X to Y",
  "required_evidence": [
    "A source-backed supplied relation",
    "A source-backed involved_in relation"
  ]
}

これは自由形式の批評よりも、はるかに行動に移しやすいものです。

役割3：永続的なワールドモデル（Persistent world model）

「エージェントは忘れるが、グラフは忘れない（the agent forgets, the graph does not）」——このフレーズが区別を捉えています。

永続性が可能にするもの：長期にわたる調査、セッションをまたぐ計画立案、文書の逐次的な取り込み、矛盾の追跡、時間的事実（temporal facts）、バージョン管理された決定、監査証跡、異なるモデル間の引き継ぎ、そして失敗した実行からの復旧。

A. コミットDAGとナレッジグラフは相補的である

AgentHub のコミット DAG は作業の系譜（work lineage）を表します。ナレッジグラフはドメイン知識（domain knowledge）を表します。この2つを一体化すべきではありません。

コミットDAGが答える問い：何が変わったか？ どの実験が親か？ どのエージェントがその変更を生んだか？ どの系統がまだ生きているか？

ナレッジグラフが答える問い：どの実体が存在するか？ それらはどう関係しているか？ どのソースがその関係を支持するか？ どの主張が衝突しているか？

本番プラットフォームは、この2つを接続します。

(agent_run_183)
    -produced->     (claim_441)
    -modified->     (commit_a81f)
    -evaluated_by-> (evaluation_92)

(claim_441)
    -about->        (entity_autoresearch)
    -supported_by-> (source_readme)
    -supersedes->   (claim_238)

B. グラフからのコンテキスト構築

グラフが、新しい形の「コンテキストの投げ込み（context dumping）」になってはいけません。各ワーカーには、タスク固有の部分グラフが必要です。

コンテキストビルダーは次を行えます：

  1. タスク内で言及された実体を解決する
  2. 許可されたエッジ型に沿って1〜2ホップ展開する
  3. 現在の成果物バージョンを含める
  4. 最近の検証済み主張を優先する
  5. 矛盾と不確実性を含める
  6. トークン予算の範囲内で直列化する
  7. 引用のために安定したエッジ識別子を添付する

VI. 実践的な構築パス：ループからグラフへ

A. Day 1：Karpathyのループを作る

出力を評価できる既存の LLM 呼び出しを1つ取ります。そこに次を追加します：保存された初稿、明示的な基準を持つ評価者、改訂ステップ、停止規則。すべての成果物を保存すること。

def reflective_task(task, gen, eval, max_rounds=3):
    versions = [gen(task)]
    for _ in range(max_rounds):
        review = eval(task, versions[-1])
        if review["decision"] == "approve":
            return {"result": versions[-1],
                    "versions": versions}
        versions.append(gen(task,
            prior=versions[-1],
            instructions=review["changes"]))
    return {"result": versions[-1],
            "status": "iteration_limit"}

B. Day 2：ツールを追加する

計測された失敗に対処するツールを1つ追加します。コード実行、Web検索、データベースアクセス、あるいはファイル操作。各ツールには型付きスキーマ、権限、結果の確認が必要です。

C. Week 1：計画を追加する

計画は、タスクの経路が変動する場合にのみ使います。実行前に JSON の計画を要求します。

{
  "objective": "Construct verified knowledge graph",
  "steps": [
    {"id": "s1", "action": "extract",
     "input": "documents", "depends_on": [],
     "success": "Each doc returns ExtractedGraph"},
    {"id": "s2", "action": "resolve_entities",
     "input": "s1.entities", "depends_on": ["s1"],
     "success": "Every surface form maps to one ID"},
    {"id": "s3", "action": "assemble_graph",
     "input": ["s1.relations", "s2.mapping"],
     "depends_on": ["s1", "s2"],
     "success": "All endpoints resolve to nodes"}
  ]
}

実行前に依存関係を検証します。再計画の際も、成功した作業は保存します。リトライ回数と総コストに上限を設けます。

D. Week 2：マルチエージェント化する

ジェネレータとクリティック（生成役と批評役）から始めます。ソフトウェア向けの有用な構成には次が含まれます：プランナー、実装者、テスト作成者、レビュアー、セキュリティレビュアー、統合者。

すべての引き渡し（handoff）は成果物契約（artifact contract）であるべきです。レビュアーは「良さそうです」ではなく、基準レベルの欠陥を返します。複数のコーディングエージェントが同一リポジトリを変更する場合は、worktree 分離を使います。

E. Month 1：グラフに接続する

バージョン管理されたJSONまたはリレーショナルテーブルから始めます。保存するもの：実体、主張、ソース、関係、成果物、エージェント実行、評価、バージョン、別名、未解決の問い。

Haiku による実体抽出と Sonnet による解決を追加します。すべてのエッジに来歴（provenance）を添付します。

F. Month 2：スウォームへスケールする

「恥ずかしいほど並列（embarrassingly parallel）」なワークロードを1つ選びます。たとえば：1つの欠陥クラスについて全ファイルを監査する、数千の文書から実体を抽出する、独立したモジュール群のテストを生成する、候補となる設定を比較する、独立した仮説を調査する。

ファンアウトの前に reducer（集約方法）を定義します。そして次を設定します：並行度の上限、総ワーカー数の上限、トークン予算、ワーカーごとのタイムアウト、リトライポリシー、証拠契約（evidence contract）、重複排除ポリシー、最終評価ゲート。

G. 参照用の本番アーキテクチャ

実践的なアーキテクチャは5つのプレーン（plane）を分離します。

  • コントロールプレーン。 目的を受け取り、計画を作り、予算を配分し、ワークフローを開始し、いつ止めるかを決める。
  • 実行プレーン。 ツール、テスト、学習ジョブ、コード変更、サブエージェントを隔離環境で実行する。
  • 成果物プレーン。 計画、下書き、コード変更、レポート、指標、評価を不変（immutable）なバージョンとして保存する。
  • グラフプレーン。 実体、主張、関係、来歴、実験の系譜、タスク依存関係を保存する。
  • 評価プレーン。 決定的チェック、モデル評価者、統計的スコアラー、人間によるレビューを実行する。

この分離が、「1つのチャットログがデータベースであり、ワークフローエンジンであり、監査ログでもある」状態を防ぎます。

graph TD
    CP["コントロールプレーン<br/>目的受領・計画・予算配分<br/>ワークフロー開始・停止判断"]
    EP["実行プレーン<br/>ツール・テスト・学習ジョブ<br/>コード変更・サブエージェント<br/>(隔離環境)"]
    AP["成果物プレーン<br/>計画・下書き・コード変更<br/>レポート・指標・評価<br/>(不変バージョン)"]
    GP["グラフプレーン<br/>実体・主張・関係・来歴<br/>実験系譜・タスク依存"]
    VP["評価プレーン<br/>決定的チェック・モデル評価者<br/>統計スコアラー・人間レビュー"]

    CP --> EP
    EP --> AP
    AP --> VP
    VP --> CP
    EP --> GP
    GP --> CP
    AP --> GP
    VP --> GP

図解（本記事による整理）：5つのプレーンの分離。

表II：実装のタイムライン

段階時間複雑さ完了基準（Exit Criterion）
内省ループ（Reflective loop）Day 1低計測された品質向上
ツール利用（Tool use）Day 2低既知の誤りクラスをツールが削減
計画（Planning）Week 1中変動するタスクが完了する
マルチエージェントWeek 2中役割分割が単一エージェントを上回る
永続グラフMonth 1高セッション横断のクエリが機能する
スウォームワークフローMonth 2高実時間の短縮、品質低下なし

VII. 評価と品質

A. 評価のフィードバックループ

評価ハーネスは、autoresearch と同じ形をしています。

現在の抽出プロンプトとスコア履歴を読む
 -> プロンプトまたはスキーマの変更を1つ提案する
 -> ゴールドセットに対して抽出を実行する
 -> precision, recall, F1, コスト, レイテンシを計算する
 -> 改善した場合: 変更を保持する
 -> 悪化した場合: 変更を revert する

これが「グラフ版 autoresearch」です。最適化されている成果物は train.py ではありません。それは抽出プロンプト、オントロジー、解決ポリシー、あるいはクエリのシリアライザです。

B. 抽出と解決の指標

ゴールドセットを作ります。実体の precision、recall、F1、スキーマ妥当な応答率、コスト、レイテンシを計測します。

解決については：圧縮率（生の表層形の数 ÷ 正準実体の数）、ペアワイズの precision と recall、誤統合率（false merge rate）、統合漏れ率（missed merge rate）、手動レビュー率。

高い圧縮率が自動的に良いわけではありません——過剰な統合（over-merging）は、連結してはいるが偽であるグラフを作ります。

C. クエリの評価

マルチホップの回答は、回答とパスの両方に対して評価すべきです。妥当な回答は次を満たさなければなりません：質問中の実体を正しく解決する、関連する部分グラフを取得する、裏付けのあるエッジを使う、時間とソースの制約を尊重する、事実と推論を区別する、使用したエッジを引用する、欠けている証拠を特定する。

敵対的なケースを作ります：紛らわしい別名、矛盾する日付、切断されたパス。

D. 本番環境でのモニタリング

孤立したスコアではなく、トレンドを追跡します。文書種別ごとの抽出率、スキーマ失敗率、解決の圧縮率、連結成分の変化、クエリレイテンシ、部分グラフのサイズ、引用エッジの妥当性、トークンコスト、陳腐化した実体の数、グラフ更新の失敗、エージェントのリトライ率。

孤立ノードの急増は、解決のリグレッションを示唆し得ます。急減は、過剰統合を示唆し得ます。

表III：レイヤ別の評価指標

レイヤ指標よくある誤読
抽出（Extraction）実体/関係のF1高いprecisionが、実体の取りこぼしを隠す
解決（Resolution）ペアワイズprecision/recall圧縮率だけでは過剰統合に報酬を与えてしまう
グラフ（Graph）連結成分、密度「1つの連結成分」が常に望ましいとは限らない
クエリ（Query）正確性、引用パス流暢な回答が、無関係なエッジを引用し得る
ワークフロー（Workflow）タスク成功率、コストエージェントを増やすと、価値なしに活動量だけ増え得る
運用（Operations）復旧、訂正平均成功率が、破滅的なケースを隠す

表IV：どのアーキテクチャレベルを使うべきか

状況まずこれから理由
単純で低リスクな質問ゼロショットレイテンシが最小
出力を検証できるループ反復フィードバックが成果物を改善する
安定したシーケンスチェーン予測可能でテスト可能な段階
明確なカテゴリがあるルーターポリシーとモデルを分離できる
独立した処理単位並列実時間を短縮する
分解の仕方が変動するオーケストレータ＝ワーカー動的な専門化
代替案を残す必要があるコミットDAG実験のブランチを保存する
事実がセッションを越えて残る必要があるナレッジグラフ永続的な共有メモリ
非常に大きな並列作業Dynamic Workflowファンアウトとファンインを自動化

VIII. 意思決定フレームワーク

A. 6つの選択質問

  1. 成功を検証できるか？ できないなら、自律性から始めてはいけない。テスト、ルーブリック、ソース要件、あるいは人間の判断を定義すること。
  2. ステップは安定しているか？ Yes ならチェーンを使う。No なら計画立案かオーケストレータを検討する。
  3. サブタスクは独立しているか？ Yes なら並列化する。No なら依存関係を明示的にモデル化し、並行書き込みを制限する。
  4. 代替となる系統を残しておく必要があるか？ Yes なら、すべての結果を1つのブランチに押し込むのではなく DAG を使う。
  5. 事実は実行（run）を越えて生き残る必要があるか？ Yes なら成果物とグラフ状態を永続化する。会話ログの要約に頼らないこと。
  6. 組織はそのコストとレイテンシを負担できるか？ ワーカーを増やす前に予算を設定すること。

B. 複雑性の予算（Complexity Budget）

すべての実行が、次を宣言すべきです：モデル呼び出しの上限、サブエージェントの上限、同時実行ワーカーの上限、ツール呼び出しの上限、実時間の上限、トークンの上限、金銭的コストの上限、リトライの上限、グラフ書き込みの上限、そして最終確定に必要な証拠の下限。

予算が尽きたら、現時点で最良の成果物、完了した作業、未解決の問題、そして停止した理由を返します。流暢な最終回答の裏に、部分的な失敗を隠してはいけません。

C. グラフを使うべきでないとき

「システムにエージェントがいるから」という理由だけでナレッジグラフを導入してはいけません。

次の場合、グラフは不要かもしれません：タスクが独立している、セッションを越える状態が不要、回答が単一の文書に依存する、関係が固定的で単純、リレーショナルテーブルで全クエリに答えられる、来歴が不要、抽出誤りが探索の価値を上回る。

グラフがそのコストに見合うのは、連結クエリ、変化する関係、来歴、あるいは共有ワールドモデルが中心にある場合です。

IX. 限界（Limitations）

A. autoresearchはフロンティア研究と同じではない

Karpathy の小さなハーネスが機能するのは、リポジトリと指標が有界だからです。フロンティアの学習システムには、分散インフラ、データパイプライン、ハードウェア障害、セキュリティ制約、多数の目的関数、そして数日〜数週間を要する実験が含まれます。

1つのGPUで動くループは、エージェントが本番の学習プラットフォームを安全に自己改変できることを証明しません。正しく転用できるのはアーキテクチャです——有界な変更、計測可能な評価、可逆性、そして永続的な履歴。

B. 指標はゲームされ得る

ラチェットは、それが見ることのできる指標だけを改善します。検証損失を下げる一方で、推論コストを増やし、頑健性を損ない、評価セットへ過適合しているかもしれません。

モデル学習では、メモリ、スループット、安定性、汎化に関する制約を残すこと。ナレッジグラフでは、解決の precision やクエリレイテンシを破壊せずに抽出品質を最適化すること。

C. AgentHubは本番ソフトウェアではない

AgentHub は自らを明示的にスケッチとして提示しています。本番版には、より強力な認証、認可、隔離、不正利用防止、ストレージの耐久性、インデクシング、可観測性、再現性、コンフリクトポリシー、ガバナンスが必要です。

また、DAG は際限なく成長し得るため、剪定（pruning）、アーカイブ、要約が必要です。

D. Dynamic Workflowsは高価である

大規模なファンアウトは、トークンを急速に消費します。高 effort での1,000サブエージェント実行は、数十ドルのコストになり得ます。

さらに並列ワーカーは相関した誤り（correlated errors）を生みます。検証ウェーブが助けになるのは、レビュアーが異なるプロンプト、異なる証拠集合、あるいは異なる役割を持つ場合だけです。

E. 断片化は品質を下げ得る

一部のタスクは、1つの一貫したコンテキストを必要とします。アーキテクチャ設計、物語的な文章の執筆、密結合なリファクタリング、微妙なプロダクト判断は、隔離された単位に分割すると品質が劣化し得ます。

F. ナレッジグラフはそのコーパスを反映する

グラフの質は、そのソース、抽出プロンプト、オントロジー、解決ポリシーの質を超えません。偏ったコーパスは偏ったグラフを生みます。欠けた文書は欠けたエッジを生みます。

グラフは主張、ソース、関係を検査可能な形で保存します——しかし主張を真実に変換するわけではありません。

G. 実体解決は破滅的な誤りを起こし得る

1つの誤統合が、多数のグラフ探索を汚染し得ます。2人の人物が1つのノードに畳み込まれると、下流のすべてのクエリが彼らの雇用主、プロジェクト、日付、行動を混同し得ます。

解決は別名、証拠、確信度、そして可逆な判断を保持しなければなりません。

H. グラフは構築者の判断を増幅する

ループは、構築者が選んだ目的と評価者を増幅します。グラフは、オントロジーとソースポリシーを増幅します。

システムが誤ったものを最適化するよう指示されたり、世界を誤って表現するよう指示されたりすれば、自動化は誤りの規模を拡大します。したがってこのアーキテクチャは、仕様、品質基準、訂正メカニズムに対する意図的な人間のオーナーシップを要求します。

X. 結論

Karpathy は、コンパクトな学習プログラムを自律的な実験プロセスへと変えるループを作りました。次いで彼は非同期な協調の必要性を述べ、単一の main ブランチではなくコミット DAG を通じてエージェントが協調する AgentHub を作りました。

Anthropic のワークフローパターンは、チェーン、ルート、並列ワーカー、オーケストレータ、評価者ループのための本番向けの語彙を提供します。Dynamic Workflows は、変動するオーケストレーションを、最大1,000サブエージェントを起動する生成されたスクリプトへと移します。Knowledge Graph Construction Cookbook は、実体、関係、来歴、マルチホップクエリのための永続層を供給します。

この進化は3つのステップで述べられます。

  1. バイブコーディング（Vibe coding）：人間が意図を表現し、モデルが書く。
  2. エージェンティックエンジニアリング（Agentic engineering）：人間が仕様化し、オーケストレーションし、検証し、品質に責任を持ち続ける。
  3. グラフエンジニアリング（Graph engineering）：エージェントが、作業と知識に関する型付き・クエリ可能なグラフを通じて永続的な状態を共有する。
graph LR
    V["1. バイブコーディング<br/>人間が意図を表現<br/>モデルが書く"] --> A["2. エージェンティック<br/>エンジニアリング<br/>人間が仕様化・統率・検証<br/>品質に責任を持つ"]
    A --> G["3. グラフ<br/>エンジニアリング<br/>型付き・クエリ可能なグラフで<br/>エージェントが永続状態を共有"]

最も重要な単一の洞察は、ボトルネックがしばしば「次のモデル呼び出し」ではない、という点です。それは「記憶と評価の置き場所（the placement of memory and evaluation）」です。

ループは現在のコードとローカルな実験ログを覚えていられます。スウォームは多数の独立したコンテキストを作れます。コミット DAG は、どの作業がどの実験から派生したかを覚えています。ナレッジグラフは、どの主張がどの実体とソースに接続しているかを覚えています。これらの構造が組み合わさることで、エージェントが毎回のコンテキストウィンドウで世界をゼロから作り直すことを防ぎます。

実践的な推奨は漸進的です。1つの計測されたループを作る。失敗を可逆にする。1つの誤りクラスに対して1つのツールを追加する。経路が変動するときにだけ計画する。専門化がシグナルを増やすときにだけ役割を分割する。会話を保存する前に成果物を保存する。代替案を生かしておくべきときに DAG を使う。関係と永続性が重要なときにナレッジグラフを使う。タスクが並列であり、かつ reducer が定義されているときにのみスウォームへスケールする。

各パターンは、前段階の特定の限界に対処しています——ループは単一パスの誤りに、ツールは知識のギャップに、計画は複雑さに、マルチエージェントは視点の限界に、DAGは系譜の追跡に、ナレッジグラフは永続的な共有メモリに対処します。この進化は必須ではありませんが、方向性を持っています（directional）。

Karpathy の README は、冒頭の「未来からの歴史記述」を、「空に浮かぶ計算クラスタの巨大構造物を横断して走る、自律的なAIエージェント群」というビジョンで締めくくります。近い将来のエンジニアリング作業は、それより映画的ではありませんが、より価値があります——型付きの契約を定義し、系譜を保存し、すべての変更を評価し、主張を接地させ、記憶をコンテキストウィンドウの外に置くこと。

信頼できるグラフエンジニアリングのシステムは、次の文を真にすべきです。

重要なすべての出力は、目的、計画、成果物、ソース、グラフ上のパス、評価者の判断、そして有界な実行記録へと辿ることができる。

この文が偽であるとき、エージェントを増やすことは通常不透明さを増やします。この文が真であるとき、ループ、スウォーム、DAG、ナレッジグラフは、不透明な振る舞いではなく組み合わせ可能なエンジニアリング機構になります。

ループからグラフへの道は、単純さから複雑さへの道ではありません。それは、暗黙の状態から明示的な状態へ、揮発的な記憶から永続的な記憶へ、そして推測から証拠へ、という道です。

謝辞とソースに関する注記

この文書は学習のために編纂された独立した統合ノートです。Andrej Karpathy、Anthropic、Sequoia Capital、Bun、その他本文中で言及されるいかなる組織とも提携しておらず、承認も受けていません。

参考文献

  1. A. Karpathy, “autoresearch,” GitHub repository, March 2026.
  2. A. Karpathy, “AgentHub,” GitHub repository, March 2026.
  3. A. Karpathy, “From Vibe Coding to Agentic Engineering,” Sequoia AI Ascent, April 2026.
  4. A. Karpathy, public post on collaborative agent swarms, March 8, 2026.
  5. E. Schluntz and B. Zhang, “Building Effective Agents,” Anthropic Engineering, December 2024.
  6. Anthropic, “Dynamic Workflows,” Claude Code orchestration, May 2026.
  7. Anthropic, Knowledge Graph Construction Cookbook, claude-cookbooks repository.
  8. L. Martin, G. Cemaj, M. Cohen, “Scaling Managed Agents,” Anthropic Engineering, April 2026.
  9. A. Karpathy, “Software 3.0, Agentic Engineering, and Jagged Intelligence,” summary post, April 30, 2026.
  10. Fortune, “Why everyone is talking about Karpathy’s autonomous AI research agent,” March 17, 2026.
  11. Anthropic, “Building Effective AI Agents: Architecture Patterns,” 2026.
  12. J. Sumner, Bun Zig-to-Rust port using Dynamic Workflows, May 2026.

付録

表V：本ノートで使われる用語

用語意味
Autoresearch自律的な実験リポジトリ：エージェントが train.py を編集し、評価し、保持または revert する
AgentHubエージェントファーストの協調基盤：ベアGitリポジトリ、SQLite、API、CLI、メッセージボード
DAG有向非巡回グラフ。コミットがノード、親リンクがエッジ
Agent swarm並行して探索・実装・評価するエージェント群
Dynamic Workflowsサブエージェントのタスクを起動し集約する、生成されたスクリプト
Knowledge graph実体をノード、型付き関係をエッジとし、来歴を伴うグラフ
Structured outputsPydanticスキーマに制約されたモデル応答
Provenance（来歴）ある主張がどこから来たか、どの実行がそれを生んだか
program.mdautoresearchループのための自然言語による制御仕様
Ratchet loop指標の改善のみを保持する反復プロセス
Graph groundingグラフから取得した事実によって生成を制約すること

ノード型とエッジ型

ノード型（Node types）：Entity、Claim、Source、Artifact、AgentRun、Evaluation、Task、Commit、Metric。

エッジ型（Edge types）：MENTIONS、SUPPORTS、CONTRADICTS、DERIVED_FROM、PRODUCED、EVALUATES、REVISES、SUPERSEDES、DEPENDS_ON、PARENT_OF、RESOLVED_TO。

グラフ書き込みが満たすべき4つの不変条件

すべてのグラフ書き込みは、次の4つの不変条件（invariants）を満たします。

  1. すべての主張（claim）はソースを持つか、推論であると明示されている。
  2. すべての成果物（artifact）は作成した実行（run）とバージョンを持つ。
  3. すべての評価はルーブリックを特定している。
  4. 置き換えられた（superseded）オブジェクトもアドレス可能なまま残る。

グラフ接地エージェントタスクの実用的なデフォルト手順

  1. 目的と制約を受け取る
  2. タスク内の実体をグラフに対して解決する
  3. 来歴付きの有界な部分グラフを取得する
  4. 型付きの計画を作り、依存関係を検証する
  5. 独立したステップを隔離されたワーカーに割り当てる
  6. 構造化された成果物と証拠を要求する
  7. 候補となるグラフ更新を公開する
  8. スキーマ、権限、来歴を検証する
  9. 決定的テストを実行する
  10. ルーブリックに対して評価者エージェントを走らせる
  11. 衝突を解決するか、不確実性をエスカレーションする
  12. バージョン管理された最終成果物を公開する
  13. ソース、グラフ上のパス、実行、評価にリンクする
  14. コスト、レイテンシ、失敗、未解決の問いを記録する

信頼できるシステムは、次を真にします。重要なすべての出力は、目的、計画、成果物、ソース、グラフ上のパス、評価者の判断、そして有界な実行記録へと辿ることができる。

表VI：本番運用チェックリスト

要素自問すべきこと欠けている場合の失敗
目的（Objective）そのタスクはテスト可能か？エージェントが誤ったものを最適化する
指標（Metric）改善を識別できるか？進捗なき活動
可逆性（Reversibility）更新を取り消せるか？失敗した実験が状態を破壊する
ツールスキーマ引数は型付けされているか？不正な呼び出し、サイレントエラー
成果物契約ワーカーは何を返すべきか？一貫性のない散文
来歴（Provenance）すべての主張にソースがあるか？出力が監査不能
解決ポリシー判断は可逆か？誤統合がグラフを汚染する
予算（Budget）上限は明示されているか？資源が無制限に消費される
モニタリング指標は追跡されているか？リグレッションが不可視
復旧（Recovery）状態から再開できるか？あらゆる中断がやり直しになる
記事一覧に戻る