純正 cookbook を Anthropic 自身の5分類で仕分けたら、真の Orchestrator-Workers は1本だけだった

前回、Anthropic の業種特化エージェント製品を clone して読み、「本当の意味でパイプラインと呼べるのは Claude for Legal の managed-agent cookbook だけだ」と書いた。今回はその cookbook の中に入る。5本それぞれを Anthropic 自身の分類で仕分けて、実際にどんな手順で動くのかを追っていく。

分類の物差しは「Building Effective Agents」の5パターンだ。Prompt Chaining、Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer。これは以前 自分のプロダクトを分類したときにも使った地図で、トポロジー（データフローの形）の軸になる。

先に結論——orchestrator で包んである、は Orchestrator-Workers ではない

仕分けてみて一番面白かったのはここだった。5本の cookbook は全部、見た目が同じだ。権限を持たない orchestrator が、leaf のサブエージェント群を callable_agents で呼ぶ。形だけ見れば全部 Orchestrator-Workers に見える。

だが Anthropic の定義では、Orchestrator-Workers は「サブタスクの数や内容が事前に決まらず、orchestrator が動的に分解する」ものを指す。固定の段を順に呼ぶだけなら、それは見た目が階層でも実体は Prompt Chaining だ。

この物差しで中を見ると、こうなった。

cookbook	分類	動的分解があるか
diligence-grid	Orchestrator-Workers ＋ Parallelization ＋ 入口に Routing	あり（文書数ぶん leaf が増える）
reg-monitor	Prompt Chaining	なし（固定3段）
docket-watcher	Prompt Chaining	なし（固定段 × matter 数のループ）
launch-radar	Prompt Chaining（分類段あり）	なし
renewal-watcher	Prompt Chaining	なし

真の Orchestrator-Workers は diligence-grid 1本だけ。残り4本は、orchestrator というハーネスを着た Prompt Chaining だった。では1本ずつ、手順を追う。

1. diligence-grid — 唯一の真パイプライン（Orchestrator-Workers ＋ Parallelization）

M&A のデューデリで、データルーム（VDR）の大量契約書を1枚の表に起こす。これだけが入口に Routing を持ち、内部で動的 fan-out をする。

入口の Routing は2モード。steering イベントで分岐する。

• watch モード：VDR をある時刻以降の新着だけ見張り、デリ請求リストのカテゴリで分類、優先カテゴリ（重要契約・訴訟・知財）を flag。中身は読まない。
• grid モード：文書群を列スキーマで一括抽出する。本体はこちら。

grid モードの手順を追う。

1. 列スキーマを読み込む（既定は M&A デューデリの標準列セット）。
2. いきなり全件に投げない。 まず 3〜5 件で sample 実行し、列の選択肢が足りているか・逐語列がぶれていないかを見てスキーマを直す。200件を未検証スキーマで走らせると、捨てる羽目になる表に予算を溶かす、と明記されている。
3. ここで動的 fan-out。文書1つにつき extractor を1インスタンス立てる。インスタンス数は文書数で決まる＝事前に分からない。これが「真の Orchestrator-Workers ＋ Parallelization の sectioning」たるゆえん。各 extractor はセルごとに「値・状態（answered / not_present / unclear / needs_review）・逐語引用・位置」を返す。引用の無いセルは捏造したセル、というのが鉄の掟。
4. normalizer が表全体を横断して整合性を検査する。選択肢外の値、フォーマット不一致、ありえない値（99年契約・$0 上限・1900年以前の日付）、そして「195件が consent_required なのに5件だけ freely_assignable」のような怪しい少数派クラスタを flag する。直さない。flag だけ返す。
5. grid-writer——Write 権限を持つ唯一の leaf——が、値の CSV・証拠（引用＋位置）の CSV・サマリの3点を吐く。

normalizer が「評価するが直さず flag を返すだけ、ループバックしない」のがポイントで、これは Evaluator-Optimizer の半分（評価はするが最適化ループにしない）になっている。後でまた触れる。

2. reg-monitor — 規制ウォッチャー（Prompt Chaining）

誰も官報を隅々まで読まない。フィードを読んで、重要度の閾値で選別し、読む価値のあるダイジェストだけを出す。手順は固定の3段。

1. 設定を読む（watchlist と materiality threshold は cold-start で学習済み）。
2. feed-reader が各フィードを取得し、閾値で filter。
3. 「常に material」指定のものは、その場で policy-diff を回し、gap サマリをダイジェストに同梱する。
4. digest-writer が 🔴 material / 🟡 review-worthy / 📝 FYI の3段でダイジェストを書く。

この read → 判定 → write の固定段は、reg-monitor だけでなく launch-radar・renewal-watcher にも共通する「Prompt Chaining の素の形」だ。

read → filter → write。分岐も動的分解もない。きれいな Prompt Chaining だ。エッジケースの materiality 判定はしない（閾値で振り分け、際どいものは review-worthy 送り）と割り切っている。

3. docket-watcher — 訴訟期日の見張り（Prompt Chaining × matter ループ）

裁判所の docket は、こちらが見ていなくても動く。新しい filing が時計を回し始める。これを matter ごとに見張る。形は Prompt Chaining だが、それを active な matter の数だけ回すループになっている。

1. 設定と _log.yaml（稼働中 matter の id・管轄・docket 識別子・最終チェック時刻・未了の deliverable）を読む。
2. docket-reader が、各 matter の最終チェック以降の新エントリを Trellis（州裁）/ CourtListener・PACER（連邦）から取得。filing 日・種別・タイトル・filer・エントリ番号・リンクを拾う。
3. deadline-mapper が filing 種別を候補の期限ルールに対応づける。連邦規則は素直だが州実務はばらつき、standing order が local rule を上書きし、判事ごとの個別管理命令もある。算出した期限は全部「人間の検証が要る lead」として flag。
4. 各 matter の history.md と未了 deliverable に突合。posture 変化（却下決定・期日設定・discovery 締切・公判日の移動）と、内部締切を過ぎた deliverable を surface。
5. tracker-writer が docket-report-<date>.md と、機械可読の deadlines.yaml（docketing システムが取り込める形）を書き、各 matter の history.md に日付つきで何を取ったか追記。

「算出した期限を勝手にカレンダー登録しない（期日徒過は malpractice だから人間が court の実ルールで検証してから）」「自分の filing 分類を信用しない（ラベルでなく中身を読め）」「静かな docket を綺麗な docket と見なさない（書記官は遅れて登録する）」という三つの「やらないこと」が、この種の監視エージェントの良い見本になっている。

4. launch-radar — リリース法務の前哨（Prompt Chaining ＋ 分類段）

プロダクト法務は、出荷2日前に未レビューの launch が降ってくると詰む。launch トラッカー（Jira / Linear）を見張って、レビューが要りそうなものを前もって拾う。手順は Prompt Chaining だが、中央に分類段がある。

1. 設定（トラッカーの場所・calibration table・エスカレーション先）を読む。
2. tracker-reader が、target 日が30日以内のチケットを取得。
3. risk-classifier が、各チケットのタイトル/説明に対して軽量版の is-this-a-problem を回す。ここで効くのが トリガーキーワード表 で、プライバシー系（"under 13"→ COPPA、"teen/minor"→ 年齢適合設計、"health"→ HIPAA）と AI ガバナンス系（"AI/ML/LLM"、"fine-tun/train/embeddings"、AI ベンダー名）を拾う。AI 系に当たったら「⚠️ AI component detected — AI ガバナンスのトリアージが先」と付ける。
4. filter：「通常レビューが要る」「通常ブロックする」パターン、またはキーワードに当たったものだけを残す。
5. memo-writer が、要レビュー / レビュー済み(FYI) / 問題なさそう、の3段でリストを出す。

分類段（risk-classifier）はあるが、分類結果で別の処理系に振り分ける Routing ではなく、1本の下流に流す。だから本質は Prompt Chaining だ。launch をブロックしない・PM に直接 ping しない（法務チャンネルに出すだけ）という抑制も効いている。

5. renewal-watcher — 契約更新のうっかり防止（Prompt Chaining）

更新レジストリは、誰かが読まないと意味がない。毎週それを読んで、解約期限（cancel-by）が閉じる前にチャンネルへ知らせる。

1. 設定を読んで通知先（Slack チャンネル or メール）を取る。
2. repo-reader が renewal-tracker を読み込み、Mode 2（次の90日）を回す。
3. deadline-calculator が cancel-by 窓でバケツ分け（🔴 0〜13日 / 🟠 14〜44日 / 🟡 45〜89日）。🔴 があればスケジュールに関係なく即時投稿。CLM 接続済みでレジストリが30日以上未同期なら Mode 3 で更新。
4. alert-writer が週次レポートを投稿。90日以内に何も無くても「異常なし」を出す（エージェントが走ったと分かるように）。

read → calc → write の固定段。契約を解約しない・更新可否を決めない・レジストリを書き換えない（追記はレビュー側から）と、ここでも書き込み権限と判断権限を厳しく絞っている。

5分類のうち、出てこなかったもの

仕分けると、空席もはっきりする。

• Evaluator-Optimizer（生成 → 評価 → 再生成のループ）は無い。 一番近い normalizer も「評価して flag を返すだけ」で、ループバックして直させはしない。playbook-monitor（同じ逸脱を5回承認したら playbook 更新を提案）が思想的には近いが、これも自動収束ループではない。純正は、出力を自動で叩き直す収束ループを採っていない。直すのは人間、という線を引いている。
• Parallelization の Voting（同じ処理を複数回流して多数決）も無い。 diligence-grid の fan-out は sectioning（分割）だけで、冗長投票はしない。

もう一本の軸——全部 Workflow、自律 Agent は無い

トポロジーとは直交する「自律度軸」（次の一手と停止を、コードが握るか LLM が握るか）で見ると、結論は単純だ。5本とも Workflow 側。次に何の leaf を呼ぶかは cookbook が決めており、LLM が制御フローを動的に握る「自律 Agent」は1本も無い。diligence-grid の「3〜5件で sample してスキーマを直す」だけが限定的な適応だが、それも bounded で、フローそのものは固定だ。

handoff の固定スキーマゲート（intent の enum → 渡し先の allowlist）は、実行時に Routing を一段足している、とも読める。だがそれも「決められた相手に決められた intent でしか渡せない」閉じた Routing で、自律ではない。

結論——派手さの不在こそが設計だった

5分類で仕分けると、純正の縦型製品の正体が出てくる。

• 真の Orchestrator-Workers は5本中1本（diligence-grid）だけ。それも sectioning の fan-out で、動的なのは「文書数ぶんに分ける」ところに限られる。
• 残り4本は、orchestrator というハーネスを着た Prompt Chaining。read → 判定 → write の固定段。
• Routing は入口や handoff に閉じた形で散発。Evaluator-Optimizer と Voting は不在。
• そして全部 Workflow。自律 Agent はゼロ。

派手な自律マルチエージェントを期待して開けると、肩透かしを食う。だがそれが設計の答えなのだと思う。法務という間違いの許されない領域で、Anthropic 自身が選んだのは、地味な Prompt Chaining を、役割ごとに分解した最小権限エージェントと、型付きの継ぎ目と、固定スキーマの handoff で固めることだった。

念のため補足すると、エージェント単位でツールを絞ること自体は frontmatter（tools / disallowedTools / permissionMode）で前からできる。だから「権限を絞れるか」は分かれ目ではない。cookbook が効くのは、権限を絞ることではなく、フローを複数エージェントに分解して read する段に Write を持たせないこと——injection で read 段が乗っ取られても、その段に Write が無ければ書き換えは起きない。スコープ（1つを絞る）ではなく分解（役割ごとに割る）だ。

トポロジーの派手さではなく、能力をどの段に置き、どう分解するか。縦型エージェント基盤の堅牢さは、そこで決まる——というのが、手順まで追って見えたことだった。

---

前回の記事: 「業種特化の AI ツール」だと思って開けたら、縦型エージェント基盤の設計図だった