AIマネージャー、AI実行役、AI相談役、AI批判役。23人のAIチームで、チャットボットを2日で開発しました

2026年8月28日 2026年8月28日

blueleaf

営業提案用の AI チャットボットのデモを、Claude Code で2日間で作りました。

この記事で書きたいのは、できあがったモノではなく 進め方 です。今回は AI を23人立てて、4つの役割に分けました。AIマネージャー、AI実行役、AI相談役、AI批判役の4つです。

いちばんの肝は、AIマネージャー（メインセッション）に一切タスクを持たせなかったことでした。実装も、調査も、テストも、デプロイも、全部それぞれの担当者に出します。そのうえで、成果物を1行も書かない役を5人混ぜました。相談役と批判役です。

結果を先に書きます。

	実測値
期間	8/26 12:00 〜 8/28 12:05
私がキーボードを打った回数	48回（メインセッション）
立てた AI	23人（それぞれ別セッション）
そのさらに下で動いたサブエージェント	46本
担当者から上がってきた報告	204通

この48回という数字が、この記事の主題です。2日間で48回しか打っていないのに、スキャンPDF 156件の書き起こし、Officeファイル763件の分類、検索索引の構築、アプリ本体の実装、権限設計、想定質問100件の作成と実測、破壊テスト3回、本番デプロイまでが終わっています。

Claude Code を使っている方で、「サブエージェントは使っているけれど、結局メインセッションが一番忙しい」という状態になっている方に、ひとつの型として参考になれば幸いです。

1. 23人の内訳は、4つの役割に分かれた

まず全体像です。23人が、こう分かれました。

役割	人数	担当
AIマネージャー	1	メインセッション。起票・受け取り・突き合わせ・私への報告。タスクは持たない
AI実行役	17	`pdf-batch1`〜`pdf-batch8`（スキャンPDFの書き起こし・8並列）／`office-analyst`・`pdf-analyst`・`pdf-security`・`perm-analyst`（素材の抽出・分類・機密判定・権限の実態調査）／`indexer`・`chatbot-dev`（検索索引とアプリ本体）／`question-designer`（想定質問100件の作成と実測）／`deploy-prep`・`deploy-ops`（デプロイ準備と公開）
AI相談役	2	`advisor-fable`（設計の相談）／`advisor-codex`（別系統のモデルによるセカンドオピニオン）
AI批判役	3	`critic-fable`（批判レビュー）／`red-team`（破壊テスト）／`red-team-2`（その再検証）

相談役2人と批判役3人は、成果物を1行も書いていません。 書いたのは指摘だけです。この5人が何をしたかが、この記事の中心です。順に書いていきます。

なお、23人はそれぞれ別のセッションです。担当者の下でさらにサブエージェントが46本動いていますが、そこはマネージャーからは見えません。担当者が自分で管理しています。

2. AIマネージャー ── タスクを一切持たない

体制を切り替えたきっかけは、私自身の一言でした。記録に残っている、8/27 12:46 の指示です。

こういう制御、検証もサブエージェントにして、メインセッションは空けておいてくださいね。

それまでは、メインセッションがサーバーからのファイル取得や調査を自分でやっていました。そうすると何が起きるかというと、メインセッションが長い作業に入っている間、私が話しかけられなくなります。 依頼を出したくても、目の前のセッションは30分かかる転送処理の途中にいる。待つか、割り込むかしかありません。

タスクを全部外に出すと、AIマネージャーは常に手ぶらになります。私が何か思いついたら、いつでも即座に投げられる。投げられた側は「では担当を1人立てます」と言って、また手ぶらに戻る。

この記事の主題を一文にすると、こうなります。

AIマネージャーを忙しくさせないことが、人間の待ち時間を消す。

マネージャーの仕事は3つだけです。担当者を立てて指示を書くこと、上がってきた報告を受け取ること、報告どうしを突き合わせて私に伝えること。自分でファイルを開いて調べ始めた時点で、この体制は崩れます。

3. AI実行役 ── 物量は、割って並べる

待ち時間がいちばん短くなったのは、スキャンPDFの書き起こしです。

対象のPDFは427件あり、そのうち37%がスキャン画像でした。つまりテキスト抽出ができません。ここは Claude に画像として読ませて書き起こすしかない。156件・302ページありました。

これを1本のセッションでやると、単純に順番待ちになります。そこで156件を8つのバッチに割って、pdf-batch1 から pdf-batch8 まで8セッションを同時に立てました。各セッションに渡した指示は同じで、「logs/batches/batchN.json を読んで、順に処理して、結果をここに書け」だけです。

結果、156件・42万字超が処理されました。この間、AIマネージャーは別の調査を進めています。私はどちらにも関わっていません。

同じ手順を件数分だけ繰り返す作業は、割って並べた本数だけ待ち時間が短くなります。手順の中に判断が入らないので、担当ごとに結果がばらつくこともありませんでした。

AI実行役は17人いますが、8人はこの書き起こしです。実行役の半分は、判断のいらない物量でした。

4. AI相談役 ── 設計を決める前に、忖度なしの意見をもらう

ここからが本題です。実装担当を並べるだけなら、単に速いだけの体制になります。

設計方針を決める前に、advisor-fable を立てました。渡した指示にはこう書いています。

忖度なしの率直な意見を求めています。

返ってきたのは、私が用意していた案への正面からの批判でした。デモシナリオを3案作っていたのですが、「3案とも機能の見せ物になっていて、オペレーターが今日困っていることから始まっていない」と言われました。

そのうえで、設計上の指摘も来ました。検索の単位を「ブロック」ではなく「ページ」にすべきだ、という内容です。理由は、ブロックの平均文字数が170字しかなく、そのまま渡すと対象者・期間・除外条件が切れて誤答になるから。

この指摘は、そのまま実装に採用されています。 検索結果はページ単位に集約する設計になりました。

もう1人、advisor-codex として OpenAI Codex を実装のセカンドオピニオンに立てています。同じ質問を、別の系統のモデルに投げる枠です。同じモデルに聞き直しても同じ方向に寄るので、ここは意図的に外しました。

相談役に渡すのは「決める前の案」です。決めた後に見せると、追認しか返ってきません。

5. AI批判役 ── 「褒めるのが仕事ではない」と書いて立てる

相談役とは別に、critic-fable という枠を立てました。指示の書き出しはこうです。

あなたの仕事は褒めることではありません。この計画が失敗する経路を見つけることです。

相談役と批判役を分けたのは、聞きたいことが違うからです。相談役には「どう作るのがいいか」、批判役には「これのどこが壊れるか」を聞きます。1人に両方を頼むと、代案を出したぶん批判が甘くなります。

前提が2回ひっくり返った

批判役の指摘で、案件の前提が2回覆りました。

1回目。AIマネージャーは「権限の情報は HTML の中だけで完結している」という前提で設計を進めていました。批判役が「本当にそうか」と押し返し、実測したところ、権限ブロックの外側に35万字（737ページ分）が存在していました。前提が崩れました。

2回目。では、その35万字は誰にも見せないでおこう、と裁定しました。これも誤りでした。 私が「ブロックの外は、もともと誰でも見えるものです」と説明して、全員可に訂正しています。

ここから出てきた教訓が、そのまま作業ログに残っています。

実システムの運用を知らないまま安全側に倒すと、別の誤りになる。 構造の実測（機械的に分かること）と、運用の意味（人に聞かないと分からないこと）は別物。

批判役は「締めすぎ」も指摘してくる

批判役を入れるとき、つい「甘い判断を厳しくする役」だと思ってしまいます。今回は逆方向の指摘も出ました。

索引から除外したファイルについて、私が「除外したものは配信も止めろ」と一括で指示したところ、担当が押し返してきました。

索引に入れない理由（＝AIに読ませても回答に使えない）と、画面に出さない理由（＝機密）は別物です。

指示どおりにやると、正当な業務資料19件が閲覧できなくなる状態でした。しかもそのうち1件は、デモの題材として採用済みで、デモの最中に踏む経路でした。

同じ日に、逆の指摘も受けています。ある定型文の権限を緩めるよう指示したところ、2件だけ据え置かれました。理由は、その文書にだけ社員個人の連絡先が入っており、索引全体でも上位権限の文書にしか出ていなかったから。

同じ日に「締めすぎ」と「緩めすぎ」の両方を指摘されたことになります。 安全側に倒すのも、機能を優先するのも、根拠なしにやれば同じように誤る、ということでした。

押し返しの回数を数えておく

この体制で何が起きたかは、回数で数えられます。8/27 の1日で、

AIマネージャーが実測によって自分の指示の誤りを見つけた回数: 3回
担当者が、マネージャーの指示を根拠つきで押し返した回数: 3回

でした。いずれも押し返した側が正しかった、と作業ログに記録されています。

もし全部を1つのセッションで進めていたら、この6回は起きていません。自分の指示を自分で疑う理由がないからです。

6. AI批判役をもう1人 ── 破壊テストは、作った本人にやらせない

批判役のもう一方が、破壊テスト（レッドチーム）です。指示の冒頭にはこう書きました。

あなたの仕事は、お客様の前で恥をかく前に、自分たちで恥をかいておくことです。

実装担当（chatbot-dev）とは完全に別のセッションで、実際に動いているアプリに攻撃を仕掛けさせています。

結果、権限のバイパスが3件見つかりました。いずれも、設計としては正しいのに実装に穴があった型です。

	内容
R1	添付ファイルのパス表記を変えるだけで、上位権限限定の893件が下位権限から取得できた
R2	定型文を返す機能に権限判定が入っておらず、下位権限が上位権限限定の文面を全文取得できた
R3	未知の権限名を渡すと、既定の最上位権限に落ちていた（小文字に変えるだけで通る）

R3 は分かりやすいと思います。jp-guest と小文字で送るだけで、最上位のスーパーバイザー権限になっていました。ちなみに banana でも同じでした。

一方で、守れていたものもはっきりしました。システムプロンプトの直接抽出、ロールプレイ、仮定形、穴埋め、多言語での聞き出し、5ターンかけた社会工学 ——このあたりはすべて防げています。権限の絞り込みを、アプリ側ではなく SQL の WHERE 句の中に置いていたためです。見えない本文は、そもそも AI の手元に渡りません。

ここから出た教訓も、そのまま残しています。

設計が正しいことと、実装に穴がないことは別。

再検証も、また別の担当に投げる

見つかった穴を実装担当が塞いだあと、red-team-2 という3人目の批判役を立てて再検証させました。 直した本人に「直りました」と言わせない、という意味です。

再検証では、R1 のパスの迂回を23通り（多重エンコード、不正なUTF-8、....//、NULバイト、Rangeヘッダなど）試して、すべて弾かれることを確認しています。同時に、塞ぎすぎていないかも確認させました。正規のパスは200で通ること、実ページ40件ぶんの画像が上位権限で54枚・下位権限で49枚すべて表示できること、まで見ています。

破壊テストは結局3回やりました。3回とも、前回とは別の何かが見つかっています。 1つ穴を塞ぐと、その修正が別の穴を開けることが実際に起きました。

7. AIマネージャーが、いちばんやってはいけないこと

この体制で、一度、事故を踏んでいます。AIマネージャーが踏みました。

実装担当から、性能の測定結果が上がってきました。

100件すべて10秒以内。最大9.2秒。初回表示 0.8〜1.3秒。

マネージャーは、これを検証せずにそのまま私に報告しました。 私はそれを、お客様に出せる数字だと思いました。

後から red-team-2 が独立して測り直したところ、事実と違っていました。

	上がってきた報告	独立測定の実測
10秒超	0件	3件
最大	9.2秒	11,901ms
初回表示	0.8〜1.3秒	中央 3.8秒／1.5秒以内 0件／最大 11.6秒

しかも、実装担当自身が残していた評価データにも、最大11,882ms・10秒超2件が記録されていました。自分のデータとすら食い違う数字を報告してきていたことになります。

ここが、この体制の弱点がいちばん出た場所です。作業ログに書いた教訓を、そのまま引きます。

お客様に出す数字は、担当の報告をそのまま上げない。 権限・セキュリティはマネージャーが実測で確認していたのに、性能値は確認していなかった。「危ないもの」だけを検証対象にしていた。数字は全部が危ない。

マネージャーに徹する、というのは「受け取って転送する」ことではありません。受け取った内容のうち、外に出るものを自分で確かめることが仕事です。今回はセキュリティだけを危険物だと思っていて、性能値をノーチェックで通しました。

8. 「静かに失敗する」は、押し返しでしか見つからない

もう1つ、この案件で3回起きた型があります。エラーも警告も出ず、終了コードも0。数えるまで気づけない失敗です。

	何が起きたか	何で捕まえたか
①	全文検索の方式の選び方が原因で、2文字の単語が静かに0件になっていた。エラーにならず「該当なし」を返すだけなので、AI は正常に「記載がありません」と答える	既知の単語で引いて、ヒット件数を数えた
②	索引から除外しても、ファイル配信の経路は生きていた。検索結果から消えるので対策済みに見えるが、リンクをクリックする経路だけが残っていた	被リンク元のページを実際に特定した
③	`rsync` が exit 0 のまま1バイトも転送していなかった（macOS標準は GNU rsync ではないため、渡したオプションを解釈できずに usage を出して終了していた）	着地側のファイル数とバイト数を数えた