hotice AI Enablement 用の独立教材（社内リファレンス）。業界の共通語彙（Anthropic 5パターン等）を、hotice が実際に使う Claude Code の実装（5モデル体制・Workflowテンプレ）にマッピングして解説します。各図はインラインSVG、数値は出典・確度ラベル付き。画面ではスクロール、印刷/PDF は 1スライド=1ページ（16:9）。
「1回のチャットで1つ」から、複数エージェントを束ねて回し、評価で効かせるまで。組み方・モデルルーティング・評価の観点を、図で。
3部構成。Part A で「束ね方（組み方＋どのモデルに何をやらせるか）」、Part B で「効かせ方（評価の観点＋品質ゲートのルーティング）」、Part C で「大規模に回す（loop・多段Workflow・予算スケール）」を扱います。各パターンに いつ使う／落とし穴 を必ず添えました。
Anthropic の5パターンを共通語彙に、fan-out / orchestrator-worker / pipeline / judge panel などの組み方と、5モデル体制のルーティングを図で。
「作って終わり」にしない。評価の観点、LLM-as-judge の設計、生成→評価→分岐（採用/差し戻し/人間）のゲート・ルーティングを図で。
1コンテキストに収まらない全件処理。loop-until-dry・多段Workflow・予算スケールと、全部入りの大規模harnessを図で。
マルチエージェントは強力だが高価。単発チャット比 約15倍のトークンを使う。だから「高価値」か「1つの頭に収まらない規模」のときだけ元が取れる。単純作業はむしろ束ねない。
単発チャット比のトークン消費（Anthropic 実測）。コストは常に品質とセットで見る。
マルチエージェント失敗の原因がタスク仕様・設計の不備（MAST 分析）。モデル能力でなく設計が成否を決める。
1ファイル編集・既知パス確認・1コマンドは束ねない（main直処理）。必要なときだけ複雑化する。
Anthropic「Building Effective Agents」が整理した5つ。単体でなく組み合わせて使うのが実務。まずこの語彙を揃える。
パターンより先に「何のために束ねるか」を決める。目的が決まれば使う組み方は自ずと絞れる。
独立した調査/生成が3単位以上。
→ fan-out（並列）・multi-modal sweep・loop-until-dry
対外的・不可逆な判断。
→ judge panel・adversarial verify（生成≠検証）
移行・横断スイープ・全件棚卸し。
→ pipeline・orchestrator-worker・loop
いつ：独立した調査/作業が3単位以上（広告6媒体・競合3〜5社）。司令塔が配り、ワーカーが同時に走り、最後に統合。
model 指定を省略すると全ワーカーが司令塔（Fable）課金で走る＝最頻の浪費。② 集約ロジックが雑だと多数決バイアス。③ 読み取りは並列・書き込みは直列（複数が同一ファイルに書くと成果が消える＝1ファイル=1エージェント）。いつ：着手前にサブタスクを列挙できない（入力依存）。司令塔が動的に分解してワーカーへ委譲。新規クライアント実態把握・深掘りリサーチ。
いつ：前段の出力が次段の入力になる直列処理（議事録ETL・記事量産・広告レポート）。各段の下に検証ゲートを吊るす。
N案を視点別のjudgeが並列採点→勝者に接ぎ木。正解が1つでない評価（多案比較・コピー選定）。小型judgeパネルは単一judgeより高精度で安い。
生成→別エージェントに反証させる→refuted除外→収束。不可逆・対外的に痛い判断（納品・契約・経理）。生成≠検証が肝。
いくつあるか不明だが全部欲しい（Slack横断・棚卸し）。K回連続で新発見ゼロなら終了。終了条件は必須。
情報が異種システムに散在（Notion+Slack+Drive+契約docx+管理画面）。ソース別に並列探索し、一次ソースを優先。
「どのモデルに何をやらせるか」が実務差になる。司令塔＝賢いモデル、ワーカー＝安いモデル、機械照合＝最安、が基本の割り当て。
| モデル | 役割 | effort基点 | API価格（入/出 /MTok） |
|---|---|---|---|
| Fable | 司令塔：計画/統合/採否/不可逆判断＋文章系＋長時間自律 | high（難所のみxhigh） | $10 / $50（最も希少） |
| Opus | 難所の重い推論＋Fable生成物の判定役（生成≠検証） | high | $5 / $25 |
| Sonnet | 主力ワーカー：Web/Xリサーチ・探索・grep・検証 | medium（検証段high） | $3 / $15 |
| Haiku | 機械照合：突合・検算・文字数・リンク存在・一次選別 | low | $1 / $5 |
| Codex | 明確に切れる実装・冪等スクリプト・独立レビュー委譲 | — | $5 / $30 |
1〜2コールで済む探索は束ねず main 直処理。3コール以上や生データが嵩むときだけ fan-out。
model未指定のfan-out＝全部Fable課金。② サイレント劣化＝安いモデルは「もっともらしく間違う」だけでダッシュボードに出ない → サンプル監査が必須。束ねて量を出すほど、「作って終わり」では品質が担保できない。自己採点は甘い。生成したエージェント自身のチェックは通りやすい——だから生成と検証は分ける。
同じモデル/文脈での自己チェックは通りやすい。別モデル・別プロンプトの目を入れる（＝adversarial verify）。
多くの組織がマルチステップ・エージェントを試すが、本番到達は一部に留まる。差は評価・自動化で効かせられるか。
「評価の観点」をスキルに埋め込めば、誰がやっても同じ品質で回る。属人的な目視だけに頼らない。
「良い/悪い」でなく、観点に分解して見る。曖昧な段階評価より Yes/No の二値の方が再現性が高い（Hamel Husain）。まず人手で100+トレースを読む（Error Analysis First）。
事実・計算は合っているか
出典に即しているか（幻覚なし）
抜け・欠落はないか
スキーマ・文字数・構造を守るか
PII・有害・投入不可を含まないか
正しいツール/引数を選べたか
1人の審査員はバイアス（冗長さ選好・位置バイアス）に弱い。視点の違う複数の小型judgeで多数決にすると、単一の大型judgeより精度が高く安い（PoLL）。
安い機械チェックを先に、高コストなLLM judgeは疑わしいものだけ。合否で分岐し、重大なものは人間へエスカレーション。
生成物を別エージェントに「反証してみて」と投げ、覆せたものを落として収束させる。不可逆・対外的に痛い判断の最終ゲート。
評価を"一発判定"で終わらせず、再実行しても壊れない仕組みにする。テンプレ化・eval set・CIの閾値ゲート・人手ラベルとの定期キャリブレーション。
judge-panel＝rubric別に採点→勝者＋良い点を接ぎ木。verify-sweep＝懐疑3体の多数決でPASS/要修正。schema出力固定・model明示。
固定データセット×較正済みgraderでスコア化。集計スコアが閾値以上でmerge可（CIゲート）。冪等な処理はスクリプト化。
judgeの判定と人手ラベルのズレを定量監査し、judgeプロンプトを調整するループ。judgeも継続的にサンプル監査。
評価 列で決める」設計になっている。これを全スキルの標準ゲートに引き上げる＝非属人化の完成形。全件処理・移行・監査・横断スイープ——人1人でも1コンテキストでも扱いきれない規模を、loop と多段Workflowで回し切る。ただし人間のレビュー容量が真のボトルネックになる。
worktree隔離で並列実装→テスト→PR。1ファイル=1体で書き込み衝突を防ぐ。
多レンズで探索→重複除去→検証。見つからなくなるまで繰り返す。
Slack横断・ドライブ棚卸し等。枯れるまで探索し、取りこぼしを潰す。
いつ：いくつあるか不明だが全部欲しい（監査・棚卸し）。発見がN回連続でゼロになるまで探索を続け、pass ledger（パス番号・使ったレンズ・新規件数）で収束を機械判定。
いつ：高リスク・不可逆な大仕事。理解→設計→実装→レビューを段で流し、各フェーズの間で人が結果を読んで次を決める（＝人がループに残る）。各段自体が fan-out / pipeline。
台数は予算逆算で決める（総予算 ÷ 1体あたり消費）。だが増やすほど効くわけではない——人間のレビュー容量が本当の律速になる。
これまでの組み方の合成。worktree隔離の並列 → 重複除去（ledger）→ 多視点verify → 統合→人レビューを、枯れるまで loop で回す。
| 知見・数値 | 出典 | 確度 |
|---|---|---|
| エージェント5パターン／multi-agent ≈15×トークン／orchestrator-worker +90.2% | Anthropic「Building Effective Agents」「Multi-agent research system」 | 公式 |
| 失敗の 41–42% はタスク仕様/設計の不備 | MAST（arXiv:2503.13657） | 論文 |
| サブエージェントへのモデル委譲・Claude Code の Haiku 使い分け | Simon Willison（@simonw・syndication確認） | X実務者 |
| 二値 > Likert／Error Analysis First（人手100+トレース） | Hamel Husain・Aakash Gupta（X） | X実務者 |
| 小型judgeパネルが単一judgeより高精度・安い（PoLL） | Panel-of-LLMs 論文 | 論文 |
| judge自体の脆弱性（deceptive judge）／align evals | Salesforce（論文）／LangChain（公式発表） | 論文・公式 |
| 5モデル体制・ルーティング・Workflowテンプレ・adversarial verify 41%除外 | 内部リファレンス（workflow-patterns.md / model-routing-pricing.md / *.js） | 内部 |
| CI閾値・runtime vs post-hoc・コスト%等の具体数値 | 技術ブログ引用 | 未検証（目安） |
※ 未検証の数値は資料化時に一次ソースで裏取りを。価格・ベンチは時点で変動します。