複数AI・複数視点を設計する：エージェント化の前に決めるべき5つのこと
連載：AI時代のSE・プログラマのためのAI壁打ち実践・発展編
全5回 ｜ 第4回 / 5前回は、AIの提案をEvidence & Evaluation Cardで評価する方法を扱いました。今回は、複数のAI・役割を安全に使い分けるための設計を扱います。
はじめに：AIを増やしても設計品質が上がるとは限らない
複数のAIやエージェントを使えば、より良い判断ができそうに思えます。しかし実際には、次のような問題が起きがちです。
「3つのAIに聞いたが、似たような回答しか返ってこない」
「エージェントを増やすほど、誰が何を決めたか分からなくなる」
「統合役のAIが、他のAIの出力を勝手にまとめて決定してしまう」
これらの問題は、AIの数ではなく役割・入力・出力・評価・人間承認の設計が不足していることに原因があります。
結論：役割、入力境界、出力契約、評価、人間ゲートを決める
複数AIの価値は「人数」ではなく、以下の5つを分けることにあります。
| # | 設計項目 | 内容 |
|---|---|---|
| 1 | Role（役割） | 各AIが何を担うか |
| 2 | Input boundary（入力境界） | 各AIが参照できる情報の範囲 |
| 3 | Output contract（出力契約） | 各AIが何を出すか、何を出さないか |
| 4 | Evaluation（評価） | 出力を何で評価するか |
| 5 | Human gate（人間ゲート） | 人間が判断する地点 |
複数AIと複数視点を混同しない
「複数のAIに聞く」と「複数の視点で検討する」は別です。
| 複数AIに聞く | 複数視点で検討する | |
|---|---|---|
| やること | 同じ質問を複数モデルに投げる | 観点・立場・出力契約を分けて依頼する |
| 期待 | 多数決で信頼性が上がる | 見落とし・偏り・盲点を減らす |
| 問題点 | 同じ学習データに依存するため独立性が保証されない | 役割設計に手間がかかる |
同一モデルに同じ入力を渡して複数の出力を得ても、独立した意見とは限りません。観点と出力契約を分ける方が効果的です。
Role Orchestration Planを作る
複数視点を安全に運用するために、Role Orchestration Planを使います。
# Role Orchestration Plan
## タスク
- {例：OpsNote初期版の検索方式と機能優先順位を決める}
## 最終決定者
- 人間：{役割または担当}
## ロール一覧
| ロール | 参照可能な入力 | 出力契約 | 禁止事項 | 評価軸 |
|---|---|---|---|---|
| 要件分析 | 要件メモ | 未確定事項リスト | 設計の決定 | 要件網羅性 |
| 反証 | 案と制約 | 失敗モード表 | 感想だけの否定 | 検証可能性 |
| 実装可能性 | 設計案 | 最小実装案 | 大規模な作り直しの断定 | 実装コスト |
| 運用 | 設計案 | 監視・障害時の懸念 | SLAの保証 | 運用負荷 |
| 統合 | 各出力 | 比較表と未解決事項 | **最終採用の決定** | 追跡可能性 |
## 人間承認ゲート
- {採用・外部送信・権限変更・本番操作など}
## 停止条件
- {追加のAI回答では品質が上がらないと判断する条件}
統合役は「決定者」ではなく「比較表作成者」 とする原則が重要です。
悪い例
設計案を3つのAIに聞いて、最も多く推薦された案を採用します。
問題点：比較軸がない、入力の差がない、反証がない、根拠確認がない、最終責任が不明。
改善例：役割と統合手順を固定する
タスク:
OpsNote初期版の検索方式と機能優先順位を決める。
ロール:
1. 要件分析：要件メモをもとに、未確定事項と受け入れ条件を出す
2. 反証：設計案に対して、失敗モードと撤退条件を出す
3. 実装可能性：3週間での最小実装案を出す
4. 運用：監視、更新、障害時の懸念を出す
5. 統合：各出力の一致点・相違点・未解決事項を表にする
統合役への制約:
- 各ロールの出力を比較表にまとめる
- 最終的な採用判断は行わない
- 未解決事項を明示する
最終決定:
人間がEvidence & Evaluation Cardをもとに決める
OpsNoteで実演する
上のRole Orchestration Planを実行した場合のイメージを示します。
統合役の出力例：
論点 要件分析 反証 実装可能性 運用 初期版の検索方式 キーワード＋タグで十分か要検証 同義語で失敗するリスクあり キーワード検索は1週間で実装可能 タグの更新ルールが必要 意味検索の導入時期 必要性が確認されてから コスト対効果が未検証 2週間以上必要 埋め込みモデルの更新運用が発生 未解決事項 代表検索課題の選定基準 — — タグ管理の責任者
コピペ用テンプレート：統合役への比較表依頼
あなたは統合役です。以下の各ロールの出力を比較表にまとめてください。
制約:
- 最終的な採用判断は行わない
- 一致点、相違点、未解決事項を明示する
- 各ロールの出力を要約する際、元の意味を変えない
- 人間が次に確認すべき事項を3つ挙げる
各ロールの出力:
{各ロールの出力を貼る}
出力形式:
| 論点 | ロールA | ロールB | ロールC | ロールD | 一致/相違 |
最後に未解決事項リストを出してください。
MCP/RAG/Toolの権限境界
複数AIやエージェントを使う場合、以下の権限を分離することが重要です。
| 種別 | 例 | 注意 |
|---|---|---|
| MCP Resource（参照） | ナレッジの検索・閲覧 | 読み取り専用、秘匿情報の範囲を限定 |
| MCP Tool（実行） | 外部APIの呼び出し、データの書き込み | 人間承認を設ける |
| RAG検索 | 過去の設計判断を検索 | 古い決定を現在の正解として扱わない |
参照権限と実行権限を混同しないことが、安全な運用の基本です。
実務投入時の注意点
- 役割を増やしすぎない。同じ情報を要約し直すだけの連鎖になると、品質は上がらずトークンだけが消費される。
- AI出力同士の合意は正しさの証拠にならない。同じ学習データに基づく出力は、同じ方向に偏る可能性がある。
- 実行系エージェントに広い権限を渡さない。外部送信、DB書き込み、本番操作には必ず人間承認を設ける。
- 停止条件を決めておく。「もう1回聞いても品質が上がらない」と判断する条件を事前に決める。
チェックリスト
- 各ロールの入力範囲と出力契約を定義したか
- 統合役に「決定しない」制約を付けたか
- 人間承認が必要な操作を明示したか
- 参照権限と実行権限を分離したか
- AI出力同士の合意を正しさの証拠にしていないか
- 停止条件を決めたか
まとめ
- 複数AIの価値は人数ではない — 役割・入力・出力・評価・人間ゲートを分ける
- 統合役は決定者ではない — 比較表と未解決事項を作る役割
- 独立性は保証されない — 同一モデル・同一入力の出力は相関する
- 参照と実行を分離する — MCP Resource/Tool/人間承認の境界を明確に
次回予告
役割分担で得た成果を、次回使える知識として残さなければ、毎回同じ会話を繰り返すことになります。
次回は、壁打ち成果をRAG/MCP/AIエージェントで再利用する：会話ログを知識パッケージへ変えるを扱います。会話ログを構造化されたKnowledge Packageに変換し、安全に再利用する方法を紹介します。
この記事では、AIの回答をそのまま正解として扱うことは推奨しません。
実務利用時は、機密情報を入れないこと、出力を検証すること、必要に応じて人間が判断することを前提にしています。
連載一覧
- 基礎編：AI時代のSE・プログラマのためのAI壁打ち実践入門（全5回）
- 発展編 第1回：AIとの壁打ちを「仮説検証」に変える
- 発展編 第2回：AIをレッドチームにする
- 発展編 第3回：AIの提案を根拠と評価で選ぶ
- 発展編 第4回：複数AI・複数視点を設計する ← 今回
- 発展編 第5回：壁打ち成果をRAG/MCP/AIエージェントで再利用する
連載情報
連載名：連載：AI時代のSE・プログラマのためのAI壁打ち実践・発展編
全5回
著者: @singula00991
投稿曜日：毎日