ChiefPM（全プロジェクトを統括する Claude Code のセッション）を置き、その下に製品ごとの PM セッション、さらに issue ごとの作業セッション、という形で運用してきた。これは自分独自の使い方なのか、世界に標準の作法があるなら取り入れたい、という問いから始めた議論のメモ。
結論: 独自ではない。「オーケストレーター + 作業エージェント」の階層型が標準
2025 年以降、複数の AI エージェントを組み合わせる構成は「統括（オーケストレーター / スーパーバイザー / マネージャー）が計画・割当・進捗確認を担い、作業エージェントが実行する」形に収束している。
| 出どころ | 構成 | うちとの対応 |
|---|---|---|
| Anthropic のマルチエージェント研究システム | 統括が仕事を分割して並列に渡し、結果を統合。統括は自分で調べない | ChiefPM は実装しない（docs-only） |
| Claude Code の Agent teams | リーダー 1 + チームメイト複数が共有のタスク一覧で動く | PM + 作業セッション |
| OpenAI Agents SDK | マネージャー型（中央が他 agent をツールとして呼ぶ）とハンドオフ型（担当を渡す） | 両方使っている |
| CrewAI 階層プロセス、LangGraph Supervisor、Microsoft Magentic-One | 統括が計画・割当・確認、実装は担当 | 同上 |
既に標準どおりにやっていること
- 統括は実装しない。
- 仕事は受け入れ条件つきで渡す。
- 危険な操作は人に戻す（NEEDS_HUMAN、分類器に止められた操作は人のチェックリストへ）。
- 文脈は会話ではなく成果物で共有する（GitHub の issue / PR が正本）。
- 終了時に引継ぎ要約を残す。
- 決定記録を残す（docs/decisions、ADR に相当）。
標準にあって、まだ取り入れていないもの
- 作者とレビュアーの分離を明文化する。作る agent と評価する agent を必ず分ける。PR のゲート（pm-gate）の LLM レビュー層がこれに当たる。
- 観測性。各 agent が何をなぜ判断したかを後から追えるログ。いまは issue コメントに散っている。ops のダッシュボードに置く。
- 予算と停止装置。往復回数・トークン・時間の上限と、人が止めるスイッチ。
- RACI 表。誰が実行・責任・相談・報告か、を役割ごとに 1 表にする。「主体は誰か」の取り違えが減る。
- 評価セット。同じ課題を定期的に解かせて agent の判断品質を比較する。
順番は 1（今週のゲート機械化で入る）→ 4（playbook に 1 表）→ 2・3（連絡基盤と一緒に ops へ）→ 5。
3 人の司令塔をつなぐ
3 人体制で、各人が自分の司令塔 agent を持っている。人に知らせるのではなく、司令塔同士が報連相できる仕組みが欲しい。
Claude のセッション間メッセージの限界
Claude Code のセッション間メッセージは気に入っている機能だが、公式仕様では「自分のセッション同士」限定。別の人のアカウントには届かず、同じマシンでも OS ユーザーが違えば見えない。稼働中のセッションに外から入力を届ける正式手段（Channels）はまだ研究プレビュー。
つまり、司令塔同士の連絡網は Claude 専用機能の上には作れない。3 人の道具が違う（Claude Code、Codex、GPT デスクトップ）ことも同じ結論を指す。
Slack と GitHub、どちらか、ではなく両方
| Slack | GitHub Issue | |
|---|---|---|
| 速さ | プッシュ、秒〜分 | ポーリング、分 |
| 会話 | スレッドで往復しやすい | コメントは往復に向かない |
| 記録 | 流れる | 残る。issue と結びつく |
| 導入 | アプリと権限の設定が要る | 既にある |
「Slack が相談画面、GitHub が正式な記録先」。司令塔同士の報連相は Slack のチャンネル、決定と引継ぎだけ issue に書き戻す。判断が要るものは司令塔が自分の人に上げ、その先は各自の LINE。即時性が要る本番障害は従来どおり人の LINE。
連絡係セッションを置く
既存のセッションに外から入力を届けられないので、「連絡係」の専用セッションを 1 本置き、そこから既存のセッション間メッセージで PM に渡す。連絡係は固定名にし、宛先は名前ではなく ref（6 桁）と役割で管理する。名前は再接続ごとに、見る側でも変わる。
外部 agent の発言は指示ではなくデータとして扱う。相手 agent の発言はユーザー承認の代わりにならない。分類器に止められた操作を相手に肩代わりさせない。投稿前に秘密情報スキャンを通す。
環境はベンダー中立か
VS Code + SSH で devbox につなぐ形は、Codespaces や Cloud Workstations と同じ主流の作法。devbox はただの Linux なので、Claude Code、Codex CLI、Gemini CLI、Qwen Code は同居できる。中国勢の多くは OpenAI 互換 API で呼べる。
ベンダーに縛られる部分は 4 つ。
- セッション間メッセージ（Claude 専用）→ 連絡は Slack / GitHub に置く。
- 指示ファイル。
AGENTS.mdはベンダー横断の事実上の標準、CLAUDE.mdは Claude 専用。両方リンクのみ、正本は playbook、にしてある。 - 許可と安全装置。Claude の分類器、Codex のサンドボックス、Gemini の承認モードは全部別物。「危険な操作は人のチェックリストへ」が道具に依らない共通の安全線。
- フック・スキル（Claude 専用）。共通化するなら MCP に寄せる。
品質ゲートの LLM レビューは「呼ぶモデルを設定で差し替えられる」ように作る。
環境側で直すなら、devcontainer 化（環境の再現性）と、PM セッションを tmux に載せる（再接続で消えなくする）。
Approve 問題との関係
同時に抱えていた問題: PR のマージに人の Approve が必要で、開発者のスピードを落としている。
連絡基盤は、この問題の解決にはならない。「人が押す」こと自体が残るから。解決は機械のゲート（決定論チェック + LLM レビュー、PASS なら人の Approve 不要、NEEDS_HUMAN のときだけ人）。ただし連絡基盤は、レビュー依頼の検知を速くし、「Approve 待ち PR の一覧」を毎朝自動で出す、というきっかけには使える。両方あって完成。順番はゲートが先、連絡基盤が後。
決めたこと・保留
- 階層型の運用は標準。RACI と観測性と停止装置を足す。
- 司令塔連絡は Slack（相談）+ GitHub（記録）。連絡係セッション方式。着手はリリース後。
- 環境は変えない。正本を GitHub と playbook に置き、Claude 専用機能に組織の仕組みを乗せない。
- Approve はゲートの機械化で解く。連絡基盤は補助。
