使い方（推奨ペース）
所要時間: 合計2時間（読むだけなら1時間、棚卸しも含めて2時間）
| フェーズ | 内容 | 時間 |
|---|
| Part 1 | Building Effective Agents 要約を読む | 25分 |
| Part 2 | Multi-agent Research System の失敗談を読む | 20分 |
| Part 3 | 5つのCoordination Patternsを読む | 15分 |
| Part 4 | 自分のプロジェクトにラベル貼り（ここが本番） | 50分 |
| Part 5 | 理解度チェック5問を自問自答 | 10分 |
重要: Part 1〜3を読むだけで終わらせない。Part 4をやらないと頭に残らない。紙かテキストエディタでラベル貼りすること。
Part 1 — Building Effective Agents（土台）
元記事: anthropic.com/engineering/building-effective-agents
これが全ての基礎。今回の5パターン記事はこの続編に過ぎない。
3つの大原則（これだけは暗記）
1. Simplicity（シンプルさ）
複雑さは「明らかに効果がある時だけ」追加しろ
cherimiでの意味: 新しいエージェントを作る時、まず単一LLM呼び出しで十分か考える。動画指示書生成も、本当に3層エージェント必要か？単発プロンプトで済むならそっちが勝ち。
2. Transparency（透明性）
エージェントの計画ステップを明示的に見せろ
cherimiでの意味: /scheduleのdaily-insightが何を考えて何を選んだか、ログに残ってるか？残ってないなら落ちた時に原因追えない。
3. ACI: Agent-Computer Interface（ツール設計）
ツールのドキュメントを丁寧に書き、テストせよ
cherimiでの意味: MCP・サブエージェントに渡すツールの説明文が雑だと、エージェントは間違った道に行く。tool descriptionを軽視しない。
7つの構成要素（単純→複雑の順）
1. Augmented LLM（土台）
ツール・検索・メモリを持ったLLM。全ての起点。
cherimiの例: Claude Code CLI そのもの。毎日使ってるあれ。
2. Prompt Chaining（直列）
タスクを固定ステップに分け、前の出力を次の入力にする。
- 使う時: ステップが予測可能、精度のためにレイテンシ犠牲OK
- 例: コピー生成→翻訳
- cherimiの例: 動画指示書生成（商品情報取得→競合リサーチ→コピー提案→HTML生成）はこのパターン。
video-brief skill がまさにこれ。
3. Routing（振り分け）
入力を分類して専門処理に渡す。
- 使う時: 入力カテゴリが明確で、カテゴリごとに別処理が良い時
- 例: カスタマーサポートを返金／技術／一般に振り分け
- cherimiの例: LINE CRMセグメント配信、sns-analytics（X / TikTok / Instagramで別処理）
4. Parallelization（並列）
複数LLMが同時に働き、出力をまとめる。Sectioning（分担）とVoting（多数決）の2種類。
- 使う時: 分割可能で速度上げたい、または複数視点で確度上げたい時
- 例: 複数プロンプトでコードの脆弱性レビュー
- cherimiの例: 動画指示書のリサーチ段階、月次レポート（X / TikTok / IGを並列生成）
- 活かせてないvideo-briefが直列になってるなら、並列化で3倍速くなる余地あり
5. Orchestrator-Workers（オケストレータ）
中央LLMがタスクを動的に分解し、ワーカーに振り、結果を統合。
- 使う時: サブタスクが事前予測できない複雑タスク
- cherimiの例: /schedule 3層（daily / weekly / meta）、agent-redesign v4の4ジョブ構成
- 習熟hatanoさんが一番使ってるパターン
6. Evaluator-Optimizer（評価-最適化ループ）
1つのLLMが生成、別のLLMが評価・フィードバック、反復で改善。
- 使う時: 評価基準が明確で、反復で明らかに良くなる時
- cherimiの例: Meta広告1日3回自動チェック、レポートの売上¥0チェック
- 活かせてない動画指示書も「生成→品質評価→修正」ループに乗せれば質が上がる
7. Agents（完全自律）
LLMが自分で計画・ツール選択・実行を続ける。
- cherimiの例: Claude Code CLI で「この品番の動画作って」と丸投げするのがこれ。
Part 1 の核心: 単純なパターンから始めて、必要になった時だけ複雑化せよ。いきなりOrchestratorで組むな、Chainingで十分なことが多い。
Part 2 — Multi-Agent Research System（実戦の失敗談）
元記事: anthropic.com/engineering/multi-agent-research-system
Anthropic自身が本番で運用したマルチエージェント系の生々しい話。理論より実装の教訓が詰まってる。
アーキテクチャ
Lead Agent（司令塔）→ 複数Subagents並列 → 結果統合 → CitationAgent（出典付与）→ 返却。典型的なOrchestrator-Workers。
プロンプトエンジニアリングの教訓（8つ）
- メンタルモデルを作れ — Consoleでエージェント挙動をシミュレートして観察。脳内モデルと実挙動はズレる。
- タスク委譲は詳細に書け — 目的・出力形式・ツールガイダンス・境界を全部書く。雑に渡すと重複／抜けが出る。
- スケーリングルールを埋め込め — 単純なら1エージェント、複雑なら10+。weekly-deepが毎週同じ深さで掘ってるなら無駄。
- ツール設計を最優先 — 説明が悪いと「完全に間違った道に送り込まれる」
- モデル自身に改善させろ — Claudeに失敗ログ見せて「なぜ失敗するか」聞く。
- 検索戦略：広く→狭く — 競合リサーチがいきなりピンポイントから始まると取りこぼす。
- Extended thinkingを活用 — 計画・適応のスクラッチパッドとして使う。
- 並列実行 — 3-5サブエージェント同時起動で最大90%時間短縮
本番で起きた失敗と対処
失敗1: エラーの積み重ね
長いチェーンで途中失敗すると最初からやり直し→金と時間の無駄。
対処: チェックポイントから再開できる仕組み
cherimiでの意味: 動画生成パイプが10カット目で落ちたら1カット目からやり直してない？中間成果物を残せ。
失敗2: 非決定性のデバッグ地獄
同じ入力でも毎回挙動が違う→再現できない。
対処: 本番トレーシング（判断構造だけログ）
cherimiでの意味: /scheduleが壊れた時、再現不可で詰んだはず。最初から構造ログを仕込むのが正解。
失敗3: デプロイで既存会話が切れる
新バージョンデプロイすると進行中のエージェントが死ぬ。
対処: Rainbow deployment（新旧並行稼働）
Anthropicが言う「マルチエージェント使うな」のサイン
- エージェント間で同じコンテキストを共有する必要がある
- 作業に真に並列化できる部分がない（大半のコーディングタスクはこれ）
- リアルタイム協調が必要
- トークン予算が厳しい（マルチエージェントは通常チャットの~15倍トークン使う）
- タスクの価値が計算コストに見合わない
hatanoさんへの示唆: 15倍トークンを使ってまでマルチエージェント化する価値あるタスクか、毎回問え。
Part 3 — 5 Coordination Patterns（最新の整理）
1. Generator-Verifier
定義: 生成役と検証役のペア
例: コード生成→テスト実行
失敗: 検証基準が曖昧だと「品質管理してる雰囲気」だけになる
cherimi適用候補:
- レポート送信前チェック（既にやってる）を自動化
- 動画の訴求一致チェック（テロップ「白」なのに映像が黒を検出）
2. Orchestrator-Subagent
定義: 親が子にタスクを振り、子は終わったら消える
失敗: 親がボトルネック、情報が親経由で劣化
cherimi適用: /schedule、agent-redesign v4、動画指示書生成。習熟既に使ってる中心パターン
3. Agent Teams
定義: 子エージェントが永続化し、経験を貯める
失敗: 作業が独立してないと衝突
cherimi適用候補:
- daily-insightに前日の分析結果を持たせる（今ゼロから毎回分析してない？）
- 品番別のメモリ化（この品番は過去こう売れた、等）
4. Message Bus
定義: イベント駆動、順序なし、各エージェントが種類で拾う
失敗: デバッグ地獄、ログなしだと詰む
cherimi適用候補:
- 経理エージェント（メール着信・Dropbox更新・シート変更がそれぞれトリガー）← 新規設計ならこれ
- Meta広告の異常検知（異常→担当エージェントに流す）
5. Shared State
定義: 共有ストレージで読み書き、中央司令なし
失敗: 収束せず無限ループ、トークン燃え尽き
cherimi適用: 不要現時点ではあまり必要ない。他4つを使いこなす方が先
進化ガイドライン: 迷ったらOrchestrator-Subagentから始めろ。本番では複数パターンの組み合わせになる（全体はOrchestrator、特定部分だけShared State、など）。
Part 4 — cherimiプロジェクト棚卸しテーブル
ここが本番。以下の表を読みながら「同意する／しない」を考えるだけでOK。
| プロジェクト | 現在のパターン | 状態 | 改善余地 |
|---|
| /schedule 3層（daily/weekly/meta） | Orchestrator-Subagent | GH Actions移行中 | Agent Teams化で前日分析を記憶 |
| agent-redesign v4 | Orchestrator-Subagent | 設計確定 | ジョブ間独立性見直し、並列化余地 |
| 動画指示書生成（video-brief） | Prompt Chaining | 稼働中 | Parallelization化で3倍速 |
| NORM動画パイプライン | Prompt Chaining | 設計段階 | Generator-Verifierで訴求一致チェック |
| 動画生成（moviepy+PIL） | 単発スクリプト | 稼働中 | 中間成果物保存でチェックポイント再開 |
| レポート生成 | Chaining + 手動Verifier | 稼働中 | 検証を別プロンプト化（自己検証はバイアス） |
| Meta広告自動化 | Evaluator-Optimizer | 稼働中 | 異常時にMessage Busで分岐 |
| 経理エージェント | 未実装 | 新規設計中 | Message Busで最初から設計 |
| LINE CRMセグメント配信 | Routing | EF連携待ち | 分類精度をGenerator-Verifierで |
| LINE WORKS管理画面Bot | Prompt Chaining | 未デプロイ | — |
| sns-analytics | Routing + Parallelization | 稼働中 | — |
このテーブルから見える、hatanoさんの傾向
強み
- 習熟Orchestrator-Subagentは既に習熟（/schedule、v4）
- 習熟Prompt Chainingも自然に使えてる
- 習熟Routingも無意識に実装できてる
弱い（使えてない）パターン
- Parallelization: チェーンの中を並列化する発想が足りない。リサーチ系で大きな時短余地
- Generator-Verifier: 手動チェックはあるが自動化してない。動画品質・レポート検証で最も効く
- Message Bus: 経理エージェント新規設計の絶好の練習題
- Agent Teams: 永続メモリの発想がない。daily-insightに履歴持たせるだけで大化け
触らなくていい
- Shared Stateは今は忘れていい。他4つで足りる
Part 5 — 理解度チェック（自問自答5問）
答えられたらこのノートは役目を終える。答えられない問は該当Partに戻る。
- Prompt Chaining と Orchestrator-Workers の違いを、cherimiのプロジェクトを例に説明できるか？（ヒント: 動画指示書 vs /schedule）
- マルチエージェント化すべきでないサインを3つ挙げられるか？（ヒント: Part 2末尾）
- 自分のどのプロジェクトにGenerator-Verifierを入れると一番効くか、即答できるか？（答え: 動画の訴求一致チェック）
- 経理エージェントをMessage Busで設計するメリットを1分で説明できるか？（ヒント: 新しいトリガー追加時のコスト）
- Anthropicが推奨する「迷ったらこれ」の出発パターンは何か？（答え: Orchestrator-Subagent）
次のアクション（読み終わったら1つだけやる）
全部やろうとしない。1つだけ選ぶ。
Aコース — 最小30分
「このノートを読んだ」で終わり。ラベル貼りが頭に残ってるうちは十分。
Bコース — 2時間 最優先推奨
動画指示書生成（video-brief skill）を見に行って、Parallelization化できる部分を特定する。Claudeに「この処理の中で並列化できる箇所を列挙して」と聞けば即出る。
Cコース — 半日
経理エージェントの設計書をMessage Bus前提で書き直す。トリガー一覧・イベントスキーマ・担当エージェント割り当てを定義。
Dコース — 週末
daily-insightにAgent Teams的な永続メモリを付ける。前日の分析結果をJSON保存し、今日の分析時にコンテキストに注入するだけ。分析の質が段違いになる。
最優先: Bコース。一番コスパが高く、即実務に効く。Dコースは効果デカいが実装コスト高い。
SNS断ちルール（次の1ヶ月）
- Twitter/XのAIエージェント関連アカウントをミュート
- 「LangGraph」「CrewAI」「AutoGen」系の記事を開かない（Claude Code使ってるhatanoさんには不要）
- 「○○が革命的」系のタイトルは原則スキップ
- 新情報を見たら、必ず「これは既存の7パターン/5パターンのどれか？」と自問する
- 該当しない新概念が出てきた時だけ、時間を使って読む
このルールの目的: 情報消費の罪悪感を消して、手を動かす時間を増やす。