半年以上、秘書エージェント1体＋部門エージェント十数体という構成でAI組織を回してきました。先日、マルチエージェント開発組織の設計・運用をまとめたZenn Book「AI開発チームの作り方と育て方」（hampen2929さん・2026年9月公開）を読んで、正直ヒヤッとしました。私が手探りで辿り着いた設計と、体系化された設計論のズレがどこにあるのか が気になったからです。
この記事は本の要約ではありません。本が提案する設計要素を1つずつ、私の実運用（ルーティング・承認フロー・タスク台帳）と突き合わせて、一致した点・外れた点・本の方が進んでいた点 を検証した記録です。
前提：両者の構成
まず土台を揃えます。
本の構成（執筆時点で確認できた範囲）: 全12章立てで、「一人で開発チームを持つ」という発想から出発し、チーム構築の前に業務設計を行う順序を提示、その上で役割設計・コミュニケーション設計、複数エージェントを束ねる「オーケストレーション」、自律度を段階的に上げる運用、学びを組織ルールへ変換する仕組みを扱っています。実装パートはTypeScript製タスク管理アプリを題材に、Codexとレビュー用のCI（Claude）を組み合わせた最小構成で進める形式です。
私の構成（Claude Code + Markdown + シェルスクリプト、特別なフレームワークは不使用）:
- 秘書エージェントが窓口となり、依頼の性質を見てルーティングする
- 部門エージェント（CTO/CMO/CFO/CS…）は担当領域ごとにペルソナファイルを持つ
- 内部作業は自動実行、外部に影響する実行（メール・SNS投稿・決済・本番デプロイ）は承認キューを経由
- 進行中タスクはMarkdown台帳（タスク一覧＋詳細メモ＋引き継ぎメモ）で管理
半年運用した実感で言うと、両者はかなり似た結論にたどり着いています。ただし同じ結論でも、そこに至る強制力の掛け方が違いました。以下、要素ごとに見ていきます。
比較表：設計要素ごとの一致度
| 設計要素 | 本の提案 | 私の実運用 | 一致度 |
|---|---|---|---|
| 役割設計 | エージェントごとに担当と完了条件を明文化 | ペルソナファイルで担当・禁止事項を定義 | 高（考え方は同一） |
| オーケストレーション | 調整役を明示的に位置づける | 秘書エージェントが単一窓口として全依頼を受ける | 高（実装は違うが機能は同じ） |
| 自律度の段階的上昇 | 信頼を積みながら権限を広げる | 内部=自動 / 外部=承認、の二値でスタート | 中（私は最初から二値。段階の刻みが粗い） |
| 検収・レビュー | 実走例ではCodex＋Claudeのレビュー用CIを併走 | 人間承認が最終ゲート、機械レビューは重要案件のみ | 中（機械レビューの常設度で差） |
| 学びの組織ルール化 | 学びをルールへ変換する仕組みを明示 | 台帳の修正事項をペルソナ・規約ファイルへ都度反映 | 高（やっていることはほぼ同じ） |
| 人間とAIの混成チーム | 混成チーム構成を前提に設計 | 人間は最終承認者として1名のみ関与 | 低（本はチーム前提、私は個人運用前提） |
一番差が出たのは「自律度の段階的上昇」でした。私の運用は内部作業=自動／外部作業=承認という二値のスイッチしかなく、その中間の刻みがありません。本の設計論には「信頼を積みながら少しずつ権限を広げる」発想があり、これは私の運用に欠けている視点でした。
深掘り1：役割設計 — ペルソナファイルという解
本が言う「役割設計」を、私は各エージェントのペルソナファイルという形で実装しています。以前、全エージェントの応答トーンがバラバラで、技術的な質問にカジュアルな返答が来たり、雑談にやたらフォーマルな応答が来たりすることがありました。そこで各エージェントに「話し方・一人称・語尾・専門分野・対応方針」を明文化したペルソナ定義を約50行で持たせたところ、応答トーンが安定し、依頼側から「前と違う人みたい」という違和感を言われなくなりました。
本が「役割と完了条件を明文化する」と書いている内容と、私がペルソナファイルでやっていたことは、粒度こそ違いますが方向性は同じです。「誰として話すか」を決めることは、人間の対応マニュアルと本質的に同じというのが実運用の実感で、これは本の主張とも重なります。
深掘り2：オーケストレーション — 単一窓口という選択
本はオーケストレーション（複数エージェントの調整役）を独立した機能として位置づけています。私の場合、これを秘書エージェント1体に集約しました。依頼は必ず秘書を経由し、秘書が担当部門へ振り分けます。
窓口を1つに絞る効果を実感したのは、外部ツールとの連携を整理したときです。以前はSlack通知やカレンダー参照のたびに手作業でコピペしていて、外部サービスとの連携が完全に断絶していました。MCP（Model Context Protocol）でSlack・カレンダー・GitHubへのアクセスをツールとして登録し、秘書エージェント経由で呼び出せるようにしたところ、手動連携にかかっていた1日あたり約45分の工数が消えました。窓口が1つだと、こうしたツール定義も一箇所に集約できるので管理コストが下がります。
一方で本は「調整役」を独立機能として捉えています。窓口を将来複数に分けるシナリオ（部門ごとの副オーケストレーター等）は、私が確認できた本の紹介文からは判断できなかったので、以下は本の主張ではなく私自身の発展的な推測です——単一窓口の私の設計は、エージェント数が十数体程度の規模だから成立している可能性が高く、この先エージェント数が増えたときに同じ設計で耐えられるかは検証課題として残りました。
深掘り3：検収・レビュー — 機械レビューを常設するかどうか
本の実装パートの実走例では、既設のClaudeレビューCIを使った最小構成で検収の質を担保しています（本が一般に「機械レビューの常設」を設計上の推奨事項として明記しているところまでは、私が確認できた紹介文の範囲では読み取れませんでした）。私の運用では、人間承認が最終ゲートである点は共通していますが、機械によるレビューは「重要度が高い実装」に限定していて、常設のCIにはしていません。
これで困った実例があります。新機能の設計書を一人で書いていたとき、レビューしてくれる相手が社内にいませんでした。そこでClaude Codeに「経験20年のシニアアーキテクトとして、この設計の問題点を指摘して」と依頼し、非機能要件（スケーラビリティ・障害耐性）の観点も指定してレビューを依頼したところ、5件の改善提案のうち2件は実際に本番運用で問題になりうる重大な設計漏れでした。この経験から「AIを壁打ち相手にする」効果は確信していたのですが、それを毎回のフローに常設するところまでは踏み込めていませんでした。本を読んで、ここは常設化の余地があると感じています。
深掘り4：学びの組織ルール化 — 台帳からペルソナへの反映
本はここを明示的な仕組みとして扱っています。私の場合、仕組み化というよりは運用習慣に近い形で、似たことをやっていました。セッションが途切れると前回の文脈を毎回説明し直す必要があったため、セッション終了時に引き継ぎメモ（進行中タスク・保留事項・次のアクション・決定事項）を自動生成する仕組みを作りました。これにより、次回セッションでの文脈復元がおよそ5秒で完了するようになり、「前回どこまでやったっけ」のやり取りがなくなりました。
この引き継ぎメモに書いた「次からはこうする」という一行が、そのまま各エージェントのペルソナファイルや規約ファイルの追記になっていくのが、私の運用における「学びの組織ルール化」です。本のように独立した仕組みとして名前が付いていたわけではありませんが、やっていること自体は近いというのが検証結果です。
実務チェックリスト：自分の運用と突き合わせるときの5項目
- 窓口は1つか複数か — エージェント数が増えたときにボトルネックにならないか
- 自律度は二値か段階か — 私の個人運用では「内部/外部」の二値で運用初期を乗り切れたが、可逆性・機密性・費用・本番影響が絡む場合はこの限りではなく、規模が増えたら中間段階を検討する
- 機械レビューは常設か都度か — 重要度で絞るなら、その判定基準を明文化しておく
- 学びの反映先は決まっているか — 引き継ぎメモの一行がどのファイルに落ちるか、経路を固定する
- 人間の関与は何人・どの権限か — 混成チーム前提の設計を個人運用に持ち込むときはここを最初に決める
ルーティングの実装例（匿名化・抜粋）
依頼キーワードから担当エージェントを引くルーティング表と、それを読む簡易ディスパッチャです。実際の部門名・エージェント名は伏せていますが、構造はそのまま使っています。
# routing.yaml — 秘書エージェントが参照するルーティング表（抜粋）
routes:
- keywords: ["経理", "請求書", "資金繰り"]
agent: finance-agent
permission: draft # 参考情報。承認キューへ回す判定はroute_task.shの外側で行う
- keywords: ["設計", "実装", "バグ", "リファクタ"]
agent: dev-agent
permission: execute # 参考情報。実際の実行判定は別ステップ
- keywords: ["広告", "SNS投稿", "記事"]
agent: marketing-agent
permission: draft
default:
agent: secretary-agent
permission: read_only
# route_task.sh — キーワード一致で「担当エージェント名」だけを決定する簡易ディスパッチャ
# 前提: mikefarah/yq v4系（env()/strenv()を使用。事前に `yq --version` で確認すること）
# 注意: この関数はagentの検索のみを行う。permissionの読み取り・承認キューへの
# 振り分けは別実装（呼び出し側）の責務であり、このコードだけでは権限制御は完成しない。
route_task() {
local task_keyword="$1"
local matched
# シェル変数をyq式に直接埋め込まず、env()経由で渡す（式インジェクション対策）。
# env()は値をYAML型として解釈するため、"true"/"12"等の入力がbool/数値化されて
# 文字列キーワードと不一致になる。文字列として比較するにはstrenv()を使う。
matched=$(TASK_KEYWORD="$task_keyword" yq -r \
'.routes[] | select(.keywords[] == strenv(TASK_KEYWORD)) | .agent' routing.yaml 2>/dev/null)
local yq_status=$?
if [[ $yq_status -ne 0 ]]; then
echo "route_task: yq実行エラー(routing.yamlの構文/パスを確認)" >&2
return 1
fi
# 同じキーワードが複数routeにマッチした場合、matchedは複数行になる。
# ここでは先頭1件に限定する（設定側での重複は別途エラーとして検出すべき）。
matched=$(echo "$matched" | head -n1)
echo "${matched:-secretary-agent}"
}
一致するキーワードがなければ秘書エージェント自身が引き取り、目的・参照パス・成果物・権限・品質基準の5点をまとめてから部門エージェントへ委譲します。この5点セットを固定してから委譲の精度が安定したので、ルーティング表を作るときはキーワードの一致条件より先に、この5点セットのフォーマットを決めておくことをおすすめします。
まとめ
- 役割設計・オーケストレーション・学びの組織ルール化は、本の設計論と私の実運用がほぼ同じ結論に着地していた
- 一番のズレは「自律度の段階的上昇」。私の運用は内部/外部の二値スイッチで止まっていて、中間段階の設計が手薄だった
- 検収・レビューは、本の実走例が既設のClaudeレビューCIを使っているのに対し、私は重要案件限定。常設化は今後の検討課題
- 人間の関与人数（混成チーム前提 vs 個人運用前提）という前提差が、他の要素の比較に効いてくる
結局のところ、体系化された設計書と自分の実運用を突き合わせてみると、「同じ答えに辿り着いていた部分」より「答えの刻み方が粗かった部分」の方が発見として大きかったです。特に自律度を二値でなく段階で設計するところは、次に着手したいと思っています。自分の運用を仕組み化している方は、一度こういう突き合わせをやってみると、当たり前になっていた設計判断が言語化される感覚があるのでおすすめです。
この記事の要点だけ持ち帰るなら、自律度を二値のスイッチで止めず段階で設計する、という1点だけ覚えておけば十分です。自分の環境で見直すときのメモ代わりに ストック しておくと、必要になったときにすぐ引けます。