生成AIに企画書や提案書を作らせても、「営業としては魅力的だが、顧客には響かない」「集客は増えそうだが、現場が回らない」「機能は優れているが、採算が合わない」といった見落としが起こります。こうした問題を減らす方法として注目されているのが、複数の役割を与えたAIに、異なる立場から同じ案を検討させる「マルチエージェント討議」です。
たとえば法人営業の提案書なら、顧客の業務責任者、IT管理者、財務責任者、購買担当者などの役割を置き、それぞれの承認条件や反対理由から提案を評価させます。マーケティング施策なら、新規顧客、既存顧客、ブランド担当、現場担当、収益管理の視点を分けることで、「魅力的か」だけでなく、「実行できるか」「利益が残るか」まで確認できます。
ただし、AIの人数を増やし、自由に議論させれば品質が上がるわけではありません。同じような役割を並べると、同じ意見の言い換えが増え、議論が長引くだけになることもあります。重要なのは、肩書を付けることではなく、それぞれに異なる評価基準、確認事項、反対条件を持たせることです。
本記事では、営業、マーケティング、商品企画、市場調査などの現場業務を例に、マルチエージェント討議が向いている仕事と、単独の生成AIで十分な仕事を整理します。そのうえで、論者の選び方、3〜5人から始める基本構成、独立レビューから統合までの進め方、議論が失敗するパターン、人間が最終判断すべきポイントを解説します。
高度なAIシステムを開発するための話ではありません。普段使っている生成AIに役割と手順を設定し、提案や企画の抜け漏れを減らすための、現場社員向けの実践ガイドです。
目次
AIに「多角的に考えて」と頼んでも、抜け漏れがなくならない理由
生成AIに企画書や提案書を読ませて、「多角的に検討してください」と頼んだことはないでしょうか。
するとAIは、顧客視点、現場視点、収益性、リスクなど、さまざまな観点から整った回答を返してくれます。一見すると、十分に検討されているように見えます。
ところが、そのまま仕事を進めると、後から思わぬ問題が出てきます。
マーケティング担当者が魅力的だと判断したキャンペーンを、店舗や営業の現場は「対応しきれない」と考えるかもしれません。商品企画が有望だと考えた新機能も、顧客には必要性が伝わらず、開発部門からは実現が難しいと指摘されることがあります。業務改善案によって作業時間が減っても、新しい入力や確認が増え、現場全体ではかえって負担が大きくなる場合もあります。
AIがまったく考えていなかったわけではありません。
問題は、顧客、現場、営業、財務、法務といった異なる立場を、一つの回答の中で同時に処理させていたことです。それぞれが何を重視し、どの条件なら反対するのかが明確でなければ、AIは複数の観点を並べたあと、無難な結論にまとめてしまいます。
人間の会議でも同じです。
参加者全員に「幅広い視点から意見を出してください」と呼びかけるだけでは、重要な論点が必ず出るとは限りません。現場の実行責任者、予算を管理する人、実際に使う顧客、計画を止められる法務やセキュリティ担当者では、見ているものが違います。
そこで使えるのが、複数の役割を持つAIに、同じ案を別々の基準で評価させる方法です。本記事では、これを「マルチエージェント討議」と呼びます。
たとえば、新しいキャンペーン案を検討するなら、対象となる顧客、現場担当者、ブランド担当者、収益管理担当者に役割を分けます。新商品なら、顧客、営業、開発、財務の立場から独立して評価させます。その後、別のAIに意見の一致点、対立点、未確認事項を整理させ、人間が最終判断します。
重要なのは、AIの人数を増やすことではありません。異なる判断基準を、混ぜずに検討させることです。
マルチエージェント討議が価値を出しやすいのは、複数の専門観点や利害関係者の視点を同時に扱う必要がある仕事です。一方で、役割を増やせば常に品質が上がるわけではなく、単純な仕事では一人のAIで十分な場合もあります。
本記事では、営業、マーケティング、商品企画、市場調査などの現場業務を例に、マルチエージェント討議が向いている仕事、論者の選び方、基本的な進め方、失敗を防ぐ方法を解説します。
一人のAIに、さらに長く考えさせるのではありません。
企画や提案を承認する人、実際に使う人、実行する人、場合によっては止める人。それぞれの判断基準を分けて与えることが、生成AIから「それらしい回答」ではなく、実務で使える検討結果を引き出す第一歩です。
第1章 マルチエージェント討議とは何か
マルチエージェント討議とは、一つの案や成果物を、異なる役割を持つ複数のAIに検討させる方法です。
たとえば営業提案書をレビューする場合、単独のAIに「多角的に評価してください」と頼むのではなく、次のように役割を分けます。
- 顧客の業務責任者として、現場の課題が解決されるかを評価する
- IT管理者として、既存システムとの接続や運用負荷を確認する
- 財務責任者として、費用対効果と投資回収を検証する
- 購買担当者として、価格や契約条件を確認する
- 統合者として、各担当者の意見を整理する
それぞれが同じ提案書を読んでいても、重視する内容や反対する理由は異なります。マルチエージェント討議の目的は、この違いを意図的に作ることです。
研究上は、複数のAIに異なる役割、専門性、評価基準、利用できる情報などを与え、意見の提示、批評、反証、審査を行わせる方法が、広くマルチエージェント討議と呼ばれています。ただし、これは一つの決まった手法ではありません。誰が何を見るのか、どの順番で意見を出すのか、誰が結論をまとめるのかによって、結果は大きく変わります。
AI同士を自由に会話させることが目的ではない
「討議」と聞くと、複数のAIがチャット上で意見を戦わせ、最後に合意する様子を想像するかもしれません。
しかし、実務では全員を最初から自由に会話させる方法は、必ずしも効果的ではありません。
最初の一人が強い意見を出すと、後のAIがその意見に影響されます。同じ基盤モデルを使っていれば、役割を変えても似た結論を出すことがあります。議論を長く続けると、同じ内容の言い換えが増えたり、本来の目的から話がずれたりすることもあります。
そのため、実務では次の順番が基本になります。
- 各役割が、他の意見を見ずに独立して評価する
- 統合者が、一致点と対立点を整理する
- 意見が分かれた重要な論点だけを再検討する
- 統合案と未解決事項をまとめる
- 人間が最終的に採用、修正、保留を決める
最初に独立した回答を出させることで、それぞれの役割が持つ本来の違いを残せます。その後も、結論だけをぶつけるのではなく、前提、不足情報、反対理由を確認させることが重要です。
マルチエージェント討議は、全員で合意するための会議というより、企画や提案に含まれる争点を、人間が判断しやすい形に分解するためのレビュー工程と考えた方が分かりやすいでしょう。
単独の生成AIの上位版ではない
ここで注意したいのは、マルチエージェント討議が、単独の生成AIより常に優れているわけではないことです。
たとえば、次の仕事で複数の役割を設定する必要はほとんどありません。
- 会議録を要約する
- メールの文面を整える
- 長い文章を短くする
- 決められた項目で情報を分類する
- 文体や表記を統一する
こうした仕事では、目的も評価基準も比較的明確です。単独のAIに適切な指示を与えれば、十分な結果を得られます。複数のAIを使っても、処理時間や出力量が増えるだけになりやすいでしょう。
研究でも、単純なマルチエージェント討議が、多数決や複数案からよい回答を選ぶ方法を安定して上回るわけではないことが示されています。効果を生むのは、AIの人数そのものではなく、異なる初期仮説、評価基準、根拠資料、反証の仕組みです。
反対に、次のような仕事では、役割を分ける意味があります。
- 複数部署から承認を得なければならない
- 顧客、現場、会社で利害が異なる
- 売上、利益、実行負荷など複数の指標を同時に満たす必要がある
- 一つの見落としが差し戻しや損失につながる
- 正解を出すことより、問題点を発見することが重要である
マルチエージェント討議は、一人のAIをさらに賢くする魔法ではありません。
一つの回答の中に混ぜていた判断基準を分離し、それぞれの立場から独立して確認させる方法です。したがって、導入時に最初に考えるべきなのは「AIを何人使うか」ではなく、「この成果物を、誰が、どのような理由で評価し、場合によっては止めるのか」です。
第2章 どんな仕事で使うべきか
マルチエージェント討議は、どんな仕事にも使えばよいわけではありません。
会議録の要約、メールの下書き、文章の短縮、表記の統一といった仕事であれば、通常は一人のAIで十分です。複数の役割を設定しても、同じ内容を繰り返したり、処理が長くなったりするだけになりやすいでしょう。
では、どのような仕事で使う価値があるのでしょうか。
もっとも分かりやすい判断基準は、「この案を、異なる理由で止められる人が複数いるか」です。
「複数の視点があるか」だけでは判断しない
多くの仕事には、複数の視点があります。
記事であれば、書き手、読者、編集者の視点があります。営業資料であれば、顧客、営業、競合の視点があります。商品企画であれば、顧客、開発、販売の視点があります。
しかし、複数の視点があるだけで、必ずマルチエージェント討議が必要になるわけではありません。
たとえば、ブログ記事のタイトル案を考えるだけなら、一人のAIに複数案を出させ、そこから選べば十分です。顧客視点や編集者視点を設定してもよいですが、独立した複数のAIに分けるほどではありません。
一方で、新商品の企画書を経営会議に出す場合は事情が違います。
顧客が欲しいと感じても、開発部門が実現できなければ進みません。開発できても、財務部門が採算に合わないと判断すれば止まります。法務や品質管理が重大なリスクを見つける可能性もあります。
このように、同じ企画に対して、異なる立場がそれぞれ別の基準で承認、反対、差し戻しを行える仕事は、マルチエージェント討議と相性がよいと言えます。
実務上は、「視点が何個あるか」ではなく、次の三つを確認すると判断しやすくなります。
- 誰が最終的に承認するのか
- 誰が実際に使い、実行するのか
- 誰がどのような理由で止められるのか
複数の独立した承認基準や拒否理由があるほど、役割を分ける価値が高くなります。
マルチエージェント討議が向いている仕事
代表的なのは、複数の評価軸を同時に満たす必要がある仕事です。
たとえば、法人営業の提案書では、顧客の課題に合っているだけでは足りません。導入できるか、運用できるか、予算に収まるか、セキュリティ上の問題がないか、契約条件に問題がないかまで確認する必要があります。
マーケティング施策も同じです。
顧客に魅力的に見えても、現場が対応できなければ実施できません。売上が増えても、値引きや広告費によって利益が残らなければ成功とは言えません。ブランドや法務の基準に反すれば、公開前に止まります。
商品企画では、顧客の欲しさ、営業の売りやすさ、開発の実現可能性、製造や運用の負荷、収益性を同時に考える必要があります。
このほか、次のような仕事も向いています。
- 新規事業の企画書や事業計画
- 市場調査や競合分析
- 業務改善案や新しい業務フロー
- システム導入企画や要件定義
- プロジェクト計画やリスクレビュー
- キャンペーン、広告、LPの事前審査
- 社外に公開する記事やホワイトペーパー
- 顧客向けの重要な説明資料
共通しているのは、単に「よい案を作る」だけでなく、複数の立場から問題点を発見し、実行前に差し戻しの理由を減らすことが重要な仕事である点です。
単独のAIで十分な仕事
反対に、正解や合格基準が比較的明確で、一つの観点で処理できる仕事では、複数の役割を置く必要はありません。
たとえば、次のような仕事です。
- 会議録を要約する
- メールや案内文の下書きを作る
- 長い文章を短くする
- 箇条書きを表に変換する
- 指定された基準で情報を分類する
- 誤字脱字や表記揺れを確認する
- 一つの文書から必要な情報を抜き出す
- 定型的な翻訳や言い換えを行う
こうした仕事では、一人のAIに目的、入力資料、出力形式、合格基準を明確に伝える方が効率的です。
研究でも、単純な質問や定型処理では、複数のAIに討議させるより、単独のAIに複数案を出させて選ぶ方法や、一度作った回答を自己批評させる方法で十分な場合が多いとされています。
迷ったときは、三つの質問で判断する
実務では、次の三つを確認してください。
一つ目は、評価基準が複数あるかです。
売上だけでなく、利益、顧客満足、現場負荷、法務リスクなど、同時に確認すべき基準が複数あるかを見ます。
二つ目は、立場によって結論が変わるかです。
企画担当は賛成しても、現場担当は反対する。顧客には魅力的でも、財務には受け入れられない。このように、立場によって判断が分かれる仕事かを確認します。
三つ目は、見落とした場合の影響が大きいかです。
後から少し直せば済む仕事なのか、差し戻し、追加費用、顧客からの信頼低下につながる仕事なのかを考えます。
この三つのうち二つ以上に当てはまるなら、マルチエージェント討議を試す価値があります。
ただし、最初から大人数にする必要はありません。まず一人のAIでレビューし、それでも観点不足や反証不足が残る場合に、必要な役割だけを追加するのが基本です。
マルチエージェント討議を使うかどうかは、仕事の重要度や難しさだけでは決まりません。
その成果物を評価する基準がいくつあり、誰がどの理由で賛成または反対するのか。その構造が、使いどころを決めます。
第3章 論者は「肩書」ではなく「判断基準」で選ぶ
マルチエージェント討議を試すとき、多くの人が最初に考えるのは、「どんな専門家を参加させるか」ではないでしょうか。
たとえば、新規事業を検討するために、次のような役割を設定したとします。
- 戦略コンサルタント
- マーケティングの専門家
- AIコンサルタント
- 起業家
- 大企業の経営者
一見すると、多角的な議論ができそうです。
しかし、実際に動かしてみると、全員が似たようなことを言い始める場合があります。「顧客ニーズを確認すべきです」「競合との差別化が必要です」「収益モデルを明確にしましょう」といった、もっともではあるものの、一般的な意見が並びます。
原因は、肩書は違っても、何を評価し、どのような場合に反対するのかが分かれていないからです。
有名な肩書を付けても、別の仕事を始めるとは限らない
AIに「あなたは一流の経営コンサルタントです」と伝えても、それだけで回答の質が上がるとは限りません。
重要なのは、その役割が何を守り、どの基準で成果物を評価するかです。
たとえば「財務責任者」という肩書だけを与えるのではなく、次のように指定します。
初年度費用、継続費用、投資回収期間、契約解除時の損失、計画が失敗した場合の損失上限を確認してください。回収の前提が弱い場合は、条件付き反対としてください。
「現場担当者」であれば、次のようにします。
実際にこの業務を毎日行う担当者として、作業手順、入力の手間、例外処理、繁忙時の負荷、トラブルからの復旧方法を確認してください。現場で継続できない場合は反対してください。
このように設定すると、財務責任者はお金の観点から、現場担当者は実行可能性の観点から、明確に異なる仕事を始めます。
研究でも、単に人物や職業のラベルを付けるだけでは、安定した性能向上につながらないことが示されています。一方で、役割ごとに評価基準やルーブリックを分けた場合は、異なる視点を持たせる効果が出やすくなります。
成果物から逆算して、必要な論者を選ぶ
論者を決めるときは、専門家の一覧から選ぶのではなく、まず成果物を決めます。
提案書なのか、キャンペーン案なのか、新商品企画なのか、業務改善案なのか。その成果物が実際に使われるまでの流れを考え、関係者を逆算します。
基本となるのは、次の役割です。
成果物の責任者
その案によって何を達成するのかを判断します。売上を増やすのか、顧客満足を上げるのか、業務時間を減らすのか。目的から外れた議論を戻す役割です。
利用者・顧客
実際にその商品、サービス、仕組みを使う立場です。提供する側が気づきにくい使いにくさや、導入への心理的な抵抗を確認します。
実行者・現場担当者
企画を実際に動かす人です。必要な人員、手順、教育、例外対応、繁忙時の負荷などを確認します。
拒否権を持つ人
財務、法務、IT、情報セキュリティ、購買、品質管理など、条件が満たされなければ計画を止められる立場です。
反証担当者
計画の前提が崩れる条件、見落としている代替案、想定外の費用、失敗シナリオを探します。
統合者
各論者の意見を整理し、何を採用し、何を修正し、何を保留するかをまとめます。
この順番で考えると、「なんとなく詳しそうな人」を増やすのではなく、成果物に対して異なる責任を持つ役割を選べます。論者を追加する基準は、新しい肩書が増えるかではなく、独立した承認条件や反対理由が増えるかどうかです。
役割ごとに「反対条件」を決める
論者を設定するとき、特に重要なのが反対条件です。
AIに「問題点を探してください」と頼むだけでは、軽微な表現上の問題と、計画を止める重大な問題が同じように並んでしまいます。
そこで、役割ごとに「どの条件なら反対するか」を決めます。
たとえば、マーケティングキャンペーンを評価する場合は、次のように設定できます。
- 顧客役：内容が理解できず、行動する理由がなければ反対
- 現場役：ピーク時の対応が困難なら反対
- 財務役：追加売上より値引きや運用費が大きければ反対
- ブランド役：既存のブランドイメージを損なう可能性があれば反対
- 統合者：重大な反対条件が解消されていなければ採用しない
反対条件があることで、それぞれの役割は単なる感想ではなく、承認審査を行うようになります。
同時に、承認条件も決めておくと、指摘だけで終わりません。「何が分かれば賛成に変わるか」を出させることで、次に調べるべき情報や修正内容が明確になります。
最初は3人か5人で始める
役割を考え始めると、営業、顧客、開発、財務、法務、現場、経営者など、多くの論者を入れたくなります。
しかし、人数が多いほどよいわけではありません。
論者が増えると、同じ指摘の重複が増え、意見を統合する負荷も大きくなります。全員を一つの会話に参加させると、早い段階で多数派に引っ張られ、少数意見が消えることもあります。
最初に試すなら、3人構成が扱いやすいでしょう。
- 成果物の責任者
- もっとも重要な反対者
- 統合者
もう少し複雑な仕事であれば、5人構成にします。
- 意思決定者
- 利用者
- 実行者
- 拒否権を持つ人
- 統合者
調査結果でも、3人は簡易レビューの開始点として扱いやすく、4〜5人は複数の承認視点を含む実務の中心構成とされています。7人以上になると、明確な役割分担や議題の分割がなければ、冗長化と統合負荷が増えやすくなります。
大切なのは、関係者をすべて再現することではありません。
その成果物を成功させる人、実際に使う人、実行する人、止められる人。この中から、結論を変える可能性が高い役割だけを選びます。
マルチエージェント討議の品質を決めるのは、論者の豪華さではありません。それぞれが別の評価基準と反対条件を持ち、他の論者とは異なる理由で判断できるかどうかです。
第4章 実務で使える基本の進め方
論者を決めたら、次は討議の進め方です。
ここでありがちなのが、最初から全員に同じチャットで話し合わせる方法です。しかし、これでは先に出た意見に後の論者が引っ張られやすくなります。結果として、役割を分けたはずなのに、全員が同じような結論に寄ってしまいます。
実務で使いやすいのは、次の流れです。
- 成果物と合格基準を渡す
- 各論者が独立して評価する
- 統合者が争点を整理する
- 必要な論点だけ再検討する
- 人間が最終判断する
重要なのは、討議から始めないことです。まず、それぞれの役割が他の意見を見ずに評価し、その後で違いを比較します。
ステップ1 成果物と合格基準を渡す
最初に、評価してほしい成果物を渡します。
たとえば、次のような資料です。
- 提案書
- キャンペーン企画書
- 商品コンセプト
- 市場調査レポート
- 業務改善案
- プロジェクト計画書
成果物だけでなく、判断に必要な前提も一緒に渡します。
たとえばマーケティング施策であれば、対象顧客、予算、実施期間、過去の実績、現場の人員、ブランド上の制約などです。営業提案であれば、顧客の課題、商談履歴、競合情報、見積、導入条件を含めます。
入力資料が不足していると、論者は足りない情報を推測で補います。役割を増やしても、新しい事実が生まれるわけではありません。不明な点は推測せず、「確認事項」として出すように指示します。
加えて、何をもって合格とするのかを決めます。
悪い指示は、次のようなものです。
この企画書を評価し、よりよくしてください。
これでは、表現の修正、アイデアの追加、事業性の判断が混ざります。
代わりに、次のように合格基準を示します。
顧客にとっての価値、現場での実行可能性、収益性の三点を評価してください。各項目を「問題なし」「要修正」「重大な懸念」に分類し、重大な懸念がある場合は、その条件と必要な追加情報を示してください。
評価軸と出力形式を先に固定すると、論者同士の違いを比較しやすくなります。
ステップ2 各論者に独立して評価させる
次に、各論者が独立して成果物を評価します。
この段階では、他の論者の回答を見せません。先に出た意見への同調を防ぎ、それぞれが本来の判断基準で考えられるようにするためです。
各論者の出力形式は揃えておきます。
たとえば、次の項目です。
- 総合判断
- 評価できる点
- 問題点
- 不足している情報
- 反対または差し戻しの条件
- 承認するために必要な修正
- 確信度
確信度を出させるのは、不足情報が多い指摘と、明確な問題を区別するためです。
また、指摘の重要度も分けます。
- 赤信号：実行や承認を止める問題
- 黄信号：修正または追加確認が必要
- 青信号：現状で問題なし
こうしておくと、誤字や表現上の改善と、採算性や法務上の重大な懸念が同列に並ぶのを防げます。
独立した初期回答を先に確保することは、同調や少数意見の消失を防ぐうえで重要です。最初から全員に他者の意見を見せるより、まず別々に判断させ、その後で根拠や前提を比較する方が、役割ごとの差が残りやすくなります。
ステップ3 統合者に争点を整理させる
各論者の評価が出たら、統合者に渡します。
統合者の仕事は、意見を短く要約することではありません。どこで判断が一致し、どこで対立し、何がまだ分からないのかを整理することです。
出力は、次のように分けます。
全員が一致している点
複数の論者が共通して問題視している点です。優先して修正する候補になります。
意見が分かれている点
たとえば、顧客役は魅力的だと評価しているが、現場役は実行が難しいと判断している、といった対立です。
単独の論者だけが指摘した重大な問題
少数意見であっても、法務、セキュリティ、財務などが重大な懸念を出している場合は残します。多数派と違うからという理由で消してはいけません。
追加確認が必要な点
入力資料が足りず、現段階では判断できない事項です。
人間が判断すべき点
予算配分、リスク許容度、顧客への約束、社外公開など、AIだけで決めるべきではない項目です。
統合者には、無理に一つの結論へまとめないよう指示します。意見が割れている場合は、未解決のまま残すことも正しい出力です。
ステップ4 必要な論点だけ再検討する
統合結果が出た後に、初めて論者同士の再検討を行います。
ただし、すべての問題を議論し直す必要はありません。全員が一致している修正点は、そのまま反映できます。再検討するのは、結論を左右する対立点だけです。
たとえば、次のような論点です。
- 顧客には魅力的だが、現場負荷が高い
- 売上増加は期待できるが、利益が残らない
- 導入効果は大きいが、IT部門の運用負荷が読めない
- 新機能への需要はあるが、開発期間が長すぎる
- 短期的には有効だが、ブランドへの悪影響が懸念される
再検討では、相手の結論を単に否定させるのではなく、次の点を出させます。
- 相手の判断で見落とされている前提
- どの条件が変われば賛成できるか
- 追加で必要なデータ
- 両立できる代替案
- それでも残る懸念
討議は通常1〜2回で十分です。議論を長くすると、新しい論点が増えるより、同じ説明の言い換えや本題からのずれが増えやすくなります。独立評価、相互批評、改訂、統合という短い流れを基本にし、未解決点だけを限定して扱います。
ステップ5 人間が採否を決める
最後に、人間が結論を出します。
AIの統合者には、最終案だけでなく、判断材料をまとめさせます。
- そのまま採用できる内容
- 修正すれば採用できる内容
- 追加調査が必要な内容
- 見送るべき内容
- 未解決の反対意見
- 人間が選ぶ必要がある選択肢
最終的な出力を一つの文章だけにすると、AIがどの意見を捨てたのか分からなくなります。採用されなかった重要な反対意見や、判断できなかった点も残しておくべきです。
特に、次のような項目は人間が最終判断します。
- 価格や予算
- 契約条件
- 法務上の解釈
- セキュリティ上の例外
- 顧客への約束
- 社外への公開
- 採用や投資の決定
- 実施によって影響を受ける現場への配慮
マルチエージェント討議の目的は、人間の代わりに結論を出すことではありません。
どの立場が何を懸念し、どこで判断が分かれ、何を確認すれば前に進めるのかを可視化することです。AIが討議し、人間が責任を持って決める。この役割分担が、実務ではもっとも使いやすい形です。
ここまでの手順は、普段使っている生成AIの一つのチャットでも実践できます。次の実践編では、資料を貼り付けるだけで試せる二つのプロンプトを紹介します。
実践編 そのまま使えるマルチエージェント討議のプロンプト例
ここでは、普段使っている生成AIのチャットに貼り付けて使えるプロンプトを二つ紹介します。
複数のチャットや専用のエージェントを用意しなくても、一つのチャットの中で役割ごとの独立評価と統合を順番に実行できます。
ポイントは、各論者に肩書だけを与えるのではなく、確認事項、反対条件、承認条件を設定することです。また、最初から自由に議論させず、各論者が独立して評価した後に、対立点だけを再検討させます。
プロンプト例1 法人営業の提案書を、顧客の稟議目線でレビューする
次のプロンプトの後ろに、提案書、商談メモ、見積書などを貼り付けます。
あなたは、法人営業の提案書を顧客企業の稟議目線で審査する
マルチエージェント・レビューチームです。
目的は、提案書の文章をきれいにすることではありません。
顧客社内で提案が差し戻される理由、追加確認が必要な事項、
提案書に不足している説明を、提出前に発見することです。
以下の6つの役割で評価してください。
【論者1：顧客企業の業務責任者】
目的：
現場の課題が解決され、期待する業務成果が得られるかを判断する。
確認事項：
・顧客の課題が具体的に定義されているか
・導入後に業務がどう変わるか
・誰が、いつ、どのように利用するか
・効果を測るKPIが明確か
反対条件：
・導入効果が抽象的
・現場の運用像が分からない
・利用部門の負担が増える
・顧客の課題と提案内容がつながっていない
【論者2：顧客企業のIT管理者】
目的：
既存環境に導入でき、継続的に運用できるかを判断する。
確認事項：
・既存システムとの連携
・認証と権限管理
・導入作業と運用体制
・障害時の対応
・データの入出力方法
反対条件：
・システム構成や責任分界が不明
・運用負荷が過大
・障害対応や問い合わせ先が不明
・連携要件が確認されていない
【論者3：顧客企業の財務責任者】
目的：
費用に対して十分な効果があり、投資判断が可能かを評価する。
確認事項：
・初年度費用
・継続費用
・追加費用
・投資回収期間
・効果試算の前提
・導入に失敗した場合の損失
反対条件：
・費用の全体像が分からない
・効果試算の根拠が弱い
・投資回収の前提が楽観的
・解約や撤退時の費用が不明
【論者4：顧客企業の購買・法務担当者】
目的：
価格、契約、責任分界に重大な問題がないかを確認する。
確認事項：
・見積項目の比較可能性
・契約期間と解約条件
・責任範囲
・データの取り扱い
・再委託
・損害発生時の対応
反対条件：
・価格や契約条件が曖昧
・責任分界が不明
・標準契約からの差分が大きい
・確認すべき条項が未記載
法的判断は確定せず、人間の法務担当者が確認すべき事項として出してください。
【論者5：営業責任者】
目的：
顧客が社内説明しやすく、競合と比較して選びやすい提案になっているかを評価する。
確認事項：
・顧客にとっての選定理由
・競合や現状維持との差
・提案の説得順序
・想定される反論
・次のアクション
反対条件：
・自社製品の説明が中心
・顧客固有の提案になっていない
・競合との差が曖昧
・顧客が社内説明に使える材料がない
【論者6：統合者】
目的：
各論者の意見を平均化せず、提案を止める問題と修正方法を整理する。
進め方は次の順番を厳守してください。
STEP 1：
論者1から5が、互いの意見を参照せず、独立して評価する。
各論者は次の形式で回答する。
・総合判断：承認／条件付き承認／差し戻し
・評価できる点
・赤信号：承認を止める問題
・黄信号：修正または確認が必要な問題
・不足情報
・承認に必要な修正
・確信度：高／中／低
STEP 2：
統合者が、各論者の評価を次の項目に整理する。
・複数の論者が共通して指摘した問題
・意見が分かれた問題
・一人だけが指摘した重大な問題
・不足している情報
・人間が判断すべき問題
STEP 3：
結論を左右する対立点だけを、関係する論者に1回再検討させる。
単なる意見の繰り返しは禁止する。
新しい根拠、判断が変わる条件、必要な追加情報のいずれかを出す。
STEP 4：
最終的に、以下の「提案書審査メモ」を作成する。
1. 総合判定
2. 最優先で修正する3項目
3. 顧客の役職別に想定される質問
4. 追加すべき資料
5. 次回商談で確認する事項
6. 修正しなくてよい点
7. 人間の法務・財務・技術担当者が確認すべき事項
資料に書かれていない情報を推測で補わないでください。
不明な点は「不足情報」として明示してください。
【顧客情報】
ここに顧客の業種、規模、課題、商談状況を記載
【提案書】
ここに提案書を貼り付け
【関連資料】
ここに商談メモ、見積、導入計画などを貼り付けこのプロンプトの目的は、「提案書をもっと魅力的にすること」だけではありません。顧客企業の中で、誰がどの理由で提案を止める可能性があるのかを、商談前に洗い出すことです。
論者が多すぎる場合は、案件に合わせて減らします。システムを伴わない小規模な提案なら、IT管理者や法務担当者を外し、業務責任者、財務責任者、営業責任者、統合者の四役でも構いません。
プロンプト例2 企画案を顧客・現場・収益の三方向から検証する
こちらは、マーケティングキャンペーン、新商品、サービス改善、業務施策など、幅広い企画に使えるプロンプトです。
あなたは、企画案を実施前に検証するマルチエージェント・レビューチームです。
目的は、企画を無理に改善したり、全員を賛成させたりすることではありません。
顧客価値、現場での実行可能性、収益性の間にある対立を明らかにし、
実施、修正、追加検証、見送りの判断材料を作ることです。
以下の5つの役割で評価してください。
【論者1：対象顧客】
目的：
この企画に魅力を感じ、実際に行動する理由があるかを評価する。
確認事項：
・自分に関係がある企画だと理解できるか
・現在の行動や代替手段を変えるほどの価値があるか
・利用や購入までの手間が大きくないか
・不安や誤解が生じないか
・一度利用した後も継続する理由があるか
反対条件：
・誰向けの企画か分からない
・価値が抽象的
・行動する理由が弱い
・利用までの手間や不安が大きい
実際の顧客調査を行ったふりはせず、検証すべき顧客仮説として回答してください。
【論者2：現場の実行責任者】
目的：
この企画を日常業務の中で継続的に実行できるかを評価する。
確認事項：
・必要な人員
・準備期間
・作業手順
・教育の必要性
・繁忙時の負荷
・問い合わせや例外対応
・既存業務への影響
反対条件：
・誰が実行するか決まっていない
・繁忙時に運用できない
・例外対応が想定されていない
・必要な工数や教育が見積もられていない
【論者3：営業・マーケティング責任者】
目的：
対象者に企画の価値を伝え、実際の行動につなげられるかを評価する。
確認事項：
・対象者が明確か
・訴求内容が分かりやすいか
・他の選択肢との差があるか
・利用や購入までの導線があるか
・成果を測定できるか
反対条件：
・対象者が広すぎる
・訴求が一般的
・認知後の行動導線がない
・成果指標が設定されていない
【論者4：収益管理責任者】
目的：
売上だけでなく、費用と現場負荷を含めて採算が成立するかを評価する。
確認事項：
・期待売上
・粗利益
・値引き
・広告費
・運用費
・追加人件費
・回収期間
・中止した場合の損失
反対条件：
・売上だけで効果を評価している
・費用の見落としがある
・期待件数の根拠が弱い
・実施するほど利益が減る可能性がある
【論者5：統合者】
目的：
各論者の意見を整理し、実施条件と検証課題を明らかにする。
以下の順番で進めてください。
STEP 1：
論者1から4が、互いの回答を見ずに独立して評価する。
各論者は次の形式で回答する。
・判断：賛成／条件付き賛成／反対／判断不能
・期待できる効果
・重大な懸念
・不足している情報
・判断が変わる条件
・実施前に行うべき検証
・確信度：高／中／低
STEP 2：
統合者が次の項目を整理する。
・四つの立場が一致している点
・顧客価値と現場負荷が対立している点
・顧客価値と収益性が対立している点
・実施前に確認しなければならない仮説
・一人だけが指摘した重大なリスク
・人間が決めるべき事項
STEP 3：
結論に影響する対立点だけを1回再検討する。
再検討では、妥協案を無理に作らず、
どの条件なら両立できるか、両立できない場合は何を優先すべきかを示す。
STEP 4：
次の形式で最終報告を作成する。
1. 総合判定
・実施
・修正して実施
・小規模テスト
・追加調査
・見送り
のいずれかを選ぶ
2. 判定理由
3. 最優先の修正事項
4. 未検証の仮説
5. 小規模テストの設計
・対象
・期間
・実施内容
・測定指標
・成功条件
・中止条件
6. 三つの実施案
・顧客価値を優先する案
・現場負荷を抑える案
・収益性を優先する案
7. 人間が最終判断すべき事項
資料にない顧客反応、費用、実績を作らないでください。
不明な事項は推測せず、「未確認」と表示してください。
【企画の目的】
ここに目的を記載
【対象者】
ここに対象となる顧客や利用者を記載
【企画案】
ここに企画内容を貼り付け
【制約】
予算、期間、人員、ブランド基準、法務条件などを記載
【参考資料】
過去の実績、顧客調査、売上データなどを貼り付けこのプロンプトでは、AIに企画の採否を任せるのではなく、「何を確認すれば判断できるか」を出させます。
特に顧客役の回答は、実際の顧客の声ではありません。顧客インタビュー、アンケート、広告テスト、試作品の利用テストなどで確認する仮説として扱います。
また、財務役の判断に必要な数字が不足している場合は、無理に収益性を判定させません。「どの数字が必要か」を出させたうえで、人間が実績や試算を追加します。
プロンプトは、一度作って終わりではない
最初から完璧なプロンプトを作る必要はありません。
実際に使い、上司や関係部署から新しい指摘を受けたら、その内容を対応する論者の確認事項や反対条件へ追加します。
たとえば、提案書を提出するたびに顧客から運用体制を質問されるなら、IT管理者の確認事項に「導入後の問い合わせ窓口と障害時の対応」を追加します。
キャンペーン実施後に現場の問い合わせ対応が問題になるなら、現場責任者の反対条件に「問い合わせ件数の想定と対応体制がない場合」を追加します。
こうしてプロンプトを更新することで、AIは一般的な専門家ではなく、その会社やチームで実際に起きた失敗を先回りして確認するレビュー役に近づいていきます。
二つのプロンプトは、そのまま使うだけでなく、成果物や関係者に合わせて役割を入れ替えられます。次章では、営業、マーケティング、商品企画、市場調査を例に、業務ごとの論者構成と使い方を見ていきます。
第5章 職種別・マルチエージェント討議の使い方
ここまで、マルチエージェント討議に向く仕事、論者の選び方、基本的な進め方を説明してきました。
ここからは、営業、マーケティング、商品企画、市場調査・競合分析の四つを例に、実際の業務へ落とし込みます。
どの仕事でも共通するのは、AIにゼロから答えを作らせるのではなく、担当者が作った案を複数の立場から検証させることです。
AIに任せるのは、最終決定ではありません。見落としている論点、反対される理由、追加で確認すべき情報を洗い出す工程です。
営業：提案書を顧客の稟議目線でレビューする
営業担当者が提案書を作ると、どうしても自社の商品やサービスを説明する内容が中心になります。
しかし、顧客企業の中では、提案内容そのものとは別の理由で稟議が止まります。
業務部門は、現場の課題が本当に解決するのかを見ます。IT部門は、既存システムとの接続や導入後の運用を気にします。財務部門は、投資回収の根拠を確認します。購買部門は、価格の妥当性や他社との比較可能性を見ます。
そこで、提案書を次の役割に分けて評価させます。
- 顧客企業の業務責任者
- IT管理者
- 情報セキュリティ責任者
- 財務責任者
- 購買・法務担当者
- 営業責任者
- 統合者
ただし、毎回すべての役割を入れる必要はありません。
提案金額が小さく、システム連携もない場合は、業務責任者、財務責任者、営業責任者、統合者の四役でも十分です。反対に、大規模なシステム導入提案では、IT、セキュリティ、法務、購買まで分けた方がよいでしょう。
入力資料として渡すのは、提案書だけではありません。
- 顧客の課題と要望
- これまでの商談メモ
- 顧客の意思決定者と関係者
- 見積書
- 導入スケジュール
- 運用体制
- セキュリティ回答
- 競合との違い
- 投資効果の試算
これらが不足している場合は、AIに推測させず、確認質問として出させます。
各論者には、提案書の感想ではなく、次の内容を回答させます。
あなたの立場から、この提案を承認できるか判断してください。承認を妨げる重大な問題、追加で確認したい情報、条件を満たせば承認できる事項を分けて示してください。
統合後の成果物は、修正版の提案書だけにしない方が実用的です。
- 稟議を止める可能性がある問題
- 顧客の役職別に想定される質問
- 追加すべき説明資料
- 次回の商談で確認する事項
- 提案書の修正優先順位
まで含めた「提案書審査メモ」を作ります。
提案書レビューは、同じ成果物を業務、IT、セキュリティ、財務、法務、購買が異なる条件で審査するため、マルチエージェント討議との相性がよい業務です。
ただし、AIが顧客企業の実際の社内事情を知っているわけではありません。出てきた指摘は、顧客の反応を断定するものではなく、商談で確認すべき仮説として扱います。
マーケティング：魅力だけでなく、実行後の副作用まで確認する
マーケティング施策の検討では、「顧客に響くか」が中心になりがちです。
しかし、実際の施策では、それ以外の条件も成否を左右します。
キャンペーンによって注文が増えても、現場が対応できなければ顧客体験は悪化します。値引きによって売上が伸びても、利益が減る可能性があります。短期的な反応がよくても、既存顧客やブランドイメージに悪影響が出る場合もあります。
キャンペーン案やLPを評価するなら、次の役割が考えられます。
- 対象となる新規顧客
- 既存顧客
- マーケティング責任者
- 営業または店舗などの現場担当者
- ブランド・法務担当者
- 収益管理担当者
- 統合者
新規顧客には、内容が理解でき、行動したくなるかを確認させます。既存顧客には、不公平感やブランドへの違和感がないかを見てもらいます。
現場担当者には、問い合わせ、注文、来店が増えた場合に対応できるかを評価させます。収益管理担当者は、売上ではなく、広告費、値引き、運用費を差し引いて利益が残るかを確認します。
入力資料として必要なのは、次のような情報です。
- キャンペーンの目的
- 対象顧客
- 広告やLPの草案
- オファーの内容
- 予算と期間
- 過去の施策実績
- 対応可能な人員や在庫
- ブランドガイド
- 法務上の制約
- 測定する指標
各論者には、単に「よい点、悪い点」を挙げさせるのではなく、施策を実施した後に何が起こるかを考えさせます。
たとえば現場担当者には、次のように指示します。
キャンペーンによって反応が想定以上に増えた場合を考えてください。問い合わせ対応、在庫、待ち時間、クレーム、通常業務への影響を確認し、現場で対応できない条件を示してください。
統合者には、施策案を一つにまとめさせるだけでなく、次の三案を作らせると実用的です。
- 効果を優先する案
- 現場負荷を抑える案
- 利益率を優先する案
そのうえで、それぞれの期待効果、必要な準備、中止条件を整理させます。
マーケティングキャンペーンの審査では、顧客への訴求、ブランド・法務上の適切さ、現場の実行可能性を別々に評価し、最後に統合する設計が実務に適しています。
AIが作った顧客役は、実際の顧客調査の代わりにはなりません。顧客役の評価は、アンケート、インタビュー、テスト配信で確認する仮説として使います。
商品企画：顧客の「欲しい」と会社の「作れる」を分けて評価する
商品企画では、顧客価値、実現可能性、売りやすさ、収益性が同時に求められます。
ところが、一人のAIに商品コンセプトを評価させると、これらの基準が混ざりやすくなります。「顧客にとって魅力的で、実現可能性も高く、収益にも貢献する」といった、都合のよい結論にまとまることがあります。
そこで、次の役割に分けて評価します。
- 新規顧客
- 既存顧客
- 商品企画責任者
- 営業・販売担当者
- 開発・製造・運用担当者
- 財務担当者
- 品質管理または法務担当者
- 統合者
新規顧客には、現在の代替手段から乗り換えるほどの魅力があるかを確認させます。既存顧客には、現在の商品との違いや、既存機能への悪影響を評価させます。
営業担当者は、誰に、どの課題を起点として説明するのかを見ます。開発・製造担当者は、必要な技術、人員、期間、運用体制を評価します。財務担当者は、開発費や提供コストに対して、価格と販売数量の前提が妥当かを確認します。
入力資料としては、次の内容を渡します。
- 商品コンセプト
- 想定顧客と課題
- 現在使われている代替手段
- 競合商品
- 予定価格
- 販売方法
- 開発期間と費用
- 既存商品との関係
- 検証済みの顧客データ
- 未検証の仮説
特に、「確認できた事実」と「担当者が置いた仮説」を分けておくことが重要です。
反証担当者を置く場合は、単に否定的な意見を出させるのではなく、企画が成立しなくなる具体的な条件を探させます。
顧客が購入しない条件、営業が販売できない条件、開発が予定どおり進まない条件、想定より利益が出ない条件を挙げてください。各条件について、事前に確認する方法も示してください。
統合後は、全員の意見を平均して一つの曖昧な商品案にするのではなく、次のように整理します。
- 現状のまま継続できる要素
- 修正が必要な要素
- 顧客検証が必要な仮説
- 技術検証が必要な事項
- 採算が成立する条件
- 中止または延期を判断する条件
商品企画では、顧客、営業、開発、財務などが別の評価基準を持つため、並列評価後に優先順位を組み直す方法が適しています。
重要なのは、AIによる顧客評価を市場の事実として扱わないことです。AIが指摘した購入理由や懸念は、顧客インタビュー、プロトタイプテスト、PoCで検証します。
市場調査・競合分析：自社に都合のよい結論を防ぐ
市場調査や競合分析では、多くの情報を集めるだけでなく、数字や結論の前提を確認する必要があります。
たとえば、市場規模を大きく見せるために、対象顧客の範囲を広げすぎているかもしれません。競合との比較では、自社が優れている項目だけを選んでいる可能性があります。市場が成長していても、自社の営業体制や販売経路では獲得できないこともあります。
こうした偏りを防ぐために、次の役割を置きます。
- 市場調査担当者
- 営業担当者
- 業界担当者
- 財務担当者
- 反証担当者
- 統合者
市場調査担当者は、出典、調査方法、市場の定義を確認します。営業担当者は、実際に販売できる顧客層かを見ます。業界担当者は、規制、商習慣、技術変化など数字だけでは分からない条件を確認します。
財務担当者は、市場規模ではなく、自社が獲得できる売上と利益に変換できるかを評価します。反証担当者は、市場規模を小さくする前提や、競合以外の代替手段を探します。
入力資料には、次の内容を含めます。
- 調査の目的
- 市場の定義
- 対象地域と期間
- 利用した情報源
- 市場規模の計算方法
- 採用した仮定
- 競合の選定基準
- 顧客インタビューや営業実績
- 不明な点と推定値
各論者には、結論ではなく、その結論を支えている前提を評価させます。
たとえば、反証担当者には次のように指示します。
この市場規模と成長予測が過大である可能性を検討してください。市場の定義、重複計上、対象顧客の支払能力、導入率、競合以外の代替手段、自社の販売能力を確認し、数字が崩れる条件を示してください。
統合者には、最終的な市場規模を一つの数字に決めさせるのではなく、前提による幅を示させます。
- 楽観的な場合
- 基準となる場合
- 保守的な場合
加えて、どの前提が結論にもっとも大きな影響を与えるのかを整理させます。
市場調査や競合分析は、調査担当、営業、財務、反証担当などによって、出典、仮定、販売可能性を別々に確認することで、都合のよい結論を防ぎやすくなります。
ただし、複数のAIが同じ情報を読んでも、元の情報が誤っていれば正しい結論にはなりません。重要な市場データ、競合情報、計算結果は、人間が一次情報まで確認する必要があります。
共通するのは「答えを増やす」のではなく「判断の違いを見つける」こと
四つの業務では論者の構成が異なりますが、基本的な使い方は同じです。
まず、担当者が成果物を作ります。次に、利用者、実行者、拒否権者などの立場から独立して評価させます。その後、統合者が意見の一致点、対立点、不足情報を整理し、人間が修正や追加調査を決めます。
マルチエージェント討議の価値は、回答の数を増やすことではありません。
同じ成果物を見ても、立場によって何が問題になり、どの条件で判断が変わるのかを明らかにすることです。
その違いが出なければ、役割を増やす意味はありません。反対に、見落としていた承認条件や実行上の制約が見つかるなら、AIを分けて評価させる価値があります。
第6章 よくある失敗と直し方
マルチエージェント討議は、役割を増やせば自動的に質が上がる仕組みではありません。
設計が曖昧なまま進めると、全員が同じ意見を述べたり、議論が長引いたり、誤った前提を互いに補強したりします。一人のAIを使う場合より、かえって判断しにくくなることもあります。
ここでは、実務で起こりやすい失敗と、その直し方を紹介します。
全員が同じような意見を出す
もっとも多いのが、役割を分けたはずなのに、全員が同じような指摘をするケースです。
たとえば、顧客、営業、マーケティング、経営者という役割を置いたにもかかわらず、全員が「顧客ニーズを明確にすべき」「競合との差別化が必要」と回答します。
これは、役割名だけが違い、評価基準が分かれていないことが原因です。
「顧客として評価してください」ではなく、次のように具体化します。
導入前に感じる不安、現在の代替手段から乗り換える理由、利用開始までの手間、期待した効果が得られなかった場合の不満を評価してください。
営業担当者であれば、売りやすさ、商談で説明しにくい点、競合に負ける条件を見ます。財務担当者であれば、費用、回収期間、失敗時の損失を見ます。
それぞれの確認事項と反対条件が重ならないように設定すると、回答にも違いが出やすくなります。
また、最初の評価は独立して行わせます。他の論者の回答を先に見せると、その意見に引っ張られやすくなるからです。
肩書を演じるだけで、具体的な審査をしない
「あなたは法務担当者です」「あなたは経営コンサルタントです」と指定しても、一般的な助言しか出ないことがあります。
これは、役割が仕事ではなく、人物設定にとどまっている状態です。
たとえば法務担当者なら、次のように審査対象を明確にします。
責任分界、個人情報の取り扱い、損害賠償、契約解除、再委託、データの保存場所を確認してください。不明な点は推測せず、確認事項として列挙してください。
役割設定には、少なくとも次の内容を含めます。
- 何を守る役割か
- 何を確認するか
- どの条件なら反対するか
- 何が分かれば承認できるか
- どの形式で結果を出すか
研究でも、肩書や人物像だけを付けるより、評価基準やルーブリックを役割ごとに分けた方が、実質的な違いが生まれやすいことが示されています。
同じ内容を言い換え続ける
討議を続けても、新しい論点が増えず、同じ主張の言い換えだけが続くことがあります。
たとえば、現場担当者が「運用負荷が高い」と述べ、企画担当者が「運用負荷への配慮が必要」と返し、統合者が「運用負荷を考慮すべき」とまとめるような状態です。
この場合、討議を続けても品質は上がりません。
再検討では、単なる賛成や反対を禁止し、次のいずれかを出すように指示します。
- 新しい根拠
- 見落とされている前提
- 判断を変える条件
- 追加で必要な情報
- 実行可能な代替案
新しい情報が出なければ、その論点の討議は終了します。
通常は、独立評価の後に1回、必要であれば追加でもう1回程度で十分です。長い討議では、本題からのずれ、同調、重複が増えやすいことが研究でも指摘されています。
誤った前提を全員で補強する
複数のAIが同意していると、結論の信頼性が高いように見えます。
しかし、全員が同じ誤った情報や仮定を使っていれば、人数が増えても正しくはなりません。むしろ、互いの回答によって誤りに自信を持つ危険があります。
たとえば、「この顧客層は価格を重視している」という未確認の仮説を全員に渡せば、顧客役も営業役も財務役も、その前提に沿って議論を進めます。
これを防ぐには、入力資料を次の三つに分けます。
- 確認できている事実
- 担当者が置いた仮説
- 現時点で不明なこと
AIには、事実と仮説を混同せず、根拠がない事項は「未確認」と表示させます。
重要な数字、顧客情報、競合情報、法務上の判断については、元の資料まで人間が確認する必要があります。複数のAIが賛成したことは、事実確認の代わりにはなりません。
多数派の意見で、重要な少数意見が消える
五人の論者のうち、四人が賛成し、一人だけが反対したとします。
このとき、単純な多数決では賛成になります。しかし、反対した一人がセキュリティ担当者で、重大な情報漏えいリスクを指摘しているなら、その意見を無視することはできません。
マルチエージェント討議では、意見の数と重要性を分けて考えます。
統合者には、次の項目を必ず残させます。
- 多数派の結論
- 少数意見
- 少数意見の根拠
- 実行を止める重大な懸念
- 追加確認によって解消できるか
特に、法務、セキュリティ、財務、品質管理など、拒否権を持つ役割の反対意見は、多数決で消さないようにします。
研究でも、長い討議や早すぎる合意形成によって少数意見が失われ、専門的な判断が平均化される問題が確認されています。
無難な折衷案にまとまる
統合者に「全員の意見をまとめてください」と頼むと、対立する意見の中間を取った案が出やすくなります。
たとえば、顧客役は大幅な値下げを求め、財務役は値下げに反対しているとします。統合者が機械的に中間を取れば、小幅な値下げ案になります。
しかし、それが顧客にも財務にも意味のある案とは限りません。
統合者の仕事は、意見を平均化することではありません。評価基準ごとに、どの案を採用するかを判断することです。
次のように出力させます。
- 採用する指摘
- 採用しない指摘と理由
- 条件付きで採用する指摘
- 両立できない論点
- 人間が選ぶべき選択肢
必要であれば、一つの折衷案ではなく、複数の案を作ります。
- 顧客獲得を優先する案
- 利益率を優先する案
- 現場負荷を抑える案
それぞれの利点と代償を示したうえで、人間が選ぶ方が実務的です。
入力資料が足りないまま討議を始める
役割や進行をどれだけ工夫しても、判断材料が不足していれば、よい結論にはなりません。
顧客情報がないまま顧客役を置けば、一般的な顧客像を演じるだけになります。費用情報がないまま財務役を置けば、「費用対効果を確認すべき」という指摘で終わります。
不足情報が多いときは、無理に討議を完了させず、まず確認事項を出させます。
統合者の最終出力に、次の区分を設けます。
- 現在の情報で判断できること
- 仮説としてのみ言えること
- 追加資料がなければ判断できないこと
- 誰に確認すべきか
情報不足をAIの推測で埋めないことが重要です。
役割を増やしすぎる
論者が増えるほど、多面的な検討ができるように見えます。
しかし、人数が増えると、重複した指摘、文章量、処理時間、統合の手間も増えます。結論に影響しない役割まで加えると、重要な問題が大量の意見に埋もれてしまいます。
論者を追加する際は、次の問いを使います。
この役割は、現在の論者とは異なる理由で、結論を変えたり計画を止めたりできるか。
答えが「いいえ」であれば、追加する必要はありません。
最初は3人から5人で始め、実際に不足した視点だけを後から加えます。マルチエージェント討議は、大人数の会議を再現することが目的ではありません。
異なる判断基準を持つ、必要最小限の役割を揃えることが目的です。
失敗を防ぐ基本は、役割を具体化し、最初の回答を独立させ、討議を短く区切り、少数意見と未確認事項を残すことです。
そして、AI同士が合意したことを、そのまま正解と考えないことです。
マルチエージェント討議から得たいのは、全員一致の結論ではありません。人間が決める前に、見落としていた反対理由や判断条件を表に出すことです。
第7章 明日から試すための最小構成
マルチエージェント討議を試すために、新しいシステムを導入する必要はありません。
まずは、普段使っている生成AIで、繰り返し発生する一つの仕事を選びます。最初から重要な経営判断や高額な投資案件に使うのではなく、結果を人間が確認でき、失敗しても修正できる仕事から始めるのが安全です。
最初に選ぶ仕事
試しやすいのは、次のような仕事です。
- 複数の部署や上司から修正を受ける
- 提出後に同じような差し戻しが起こる
- 評価する人によって意見が分かれる
- 毎週または毎月、似た成果物を作っている
- 最終的には人間が確認してから使う
たとえば、営業提案書、キャンペーン企画、新商品コンセプト、市場調査レポート、業務改善案などです。
反対に、年に一度しか扱わない特殊な案件や、正解が分からないまま結果を検証できない仕事は、最初の対象には向きません。
マルチエージェント討議は、単独AIでの処理を置き換えることから始めるのではなく、単独AIでは不足した観点を補う形で導入するのが基本です。
まずは3人で試す
最初の構成は、3人で十分です。
- 成果物の責任者
- もっとも重要な反対者
- 統合者
たとえばキャンペーン企画なら、マーケティング責任者、現場担当者、統合者です。
商品企画なら、商品企画責任者、顧客または開発担当者、統合者にします。営業提案書なら、営業責任者、顧客側の主要な審査者、統合者です。
どの反対者を選ぶか迷ったら、過去にもっとも頻繁に差し戻しを行った立場を選びます。
財務から何度も指摘されているなら、財務担当者を置きます。現場から「実行できない」と言われることが多いなら、現場担当者を置きます。顧客に価値が伝わらないことが問題なら、顧客役を置きます。
3人構成は、役割の違いを確認しながら、出力量と統合の負荷を抑えられる開始点です。複雑な案件でも、まず3人または5人で試し、必要な役割だけを追加する方法が推奨されます。
一回目は短く終わらせる
最初の実験では、次の範囲にとどめます。
- 三つの役割を設定する
- 各論者が独立して一度評価する
- 統合者が一致点、対立点、不足情報を整理する
- 重要な対立点だけ一度再検討する
- 人間が結果を確認する
何度も議論させたり、全員一致を目指したりする必要はありません。
成果物の品質を上げることだけでなく、これまで見落としていた論点が見つかったかを確認します。
効果は「回答が立派か」ではなく、仕事が変わったかで測る
マルチエージェント討議の出力は、長く、詳しくなりやすい傾向があります。しかし、文章量が増えたことは効果ではありません。
導入後は、次の変化を確認します。
- 差し戻しの回数が減ったか
- 提出前に重大な問題を発見できたか
- 上司や他部署からの指摘を先回りできたか
- 追加調査が必要な箇所を早く特定できたか
- レビューにかかる人間の時間が減ったか
- 採用しなかった反対意見にも意味があったか
効果がなければ、論者を増やす前に役割設定を見直します。
各論者の指摘が似ているなら、評価基準が重複しています。一般論しか出ないなら、入力資料が不足しています。指摘は多いが判断しにくいなら、重要度や反対条件が定義されていません。
それでも単独AIとの差が出ない場合は、その仕事ではマルチエージェント討議を使わない方がよいでしょう。
人間が決める範囲を先に固定する
討議を始める前に、AIに決めさせない事項を明確にします。
たとえば、次のような判断です。
- 予算や価格の最終承認
- 契約条件の受諾
- 法令や社内規程の解釈
- セキュリティ上の例外
- 顧客への約束
- 社外への公開や送信
- 採用、投資、購買の最終判断
- 現場に大きな負荷をかける施策の実施
AIには、これらを自動的に確定させるのではなく、選択肢、懸念、判断に必要な情報を整理させます。
特に、論者の意見が分かれた場合や、判断材料が不足している場合は、無理に結論を出させません。高リスクの業務では、AI同士の合意より、人間が争点と根拠を確認できることの方が重要です。
最初の成功条件を小さくする
最初から「最高の企画を作る」「意思決定を自動化する」といった目標を置くと、効果を判断できません。
最初は、次のような小さな成功条件で十分です。
- これまで見落としていた問題が一つ見つかる
- 差し戻されやすい論点を提出前に確認できる
- 次に調べるべきことが明確になる
- 上司や関係部署への確認質問を準備できる
- 採用しない案の理由を説明できる
この程度でも、企画や提案の手戻りが減れば、十分な価値があります。
慣れてきたら、5人構成に増やしたり、役割設定をひな形として保存したりします。ただし、毎回同じ論者を使う必要はありません。
提案書、キャンペーン、商品企画では、成果物を止める人が違います。仕事ごとに、必要な判断基準だけを選び直します。
まとめ AIの人数ではなく、判断基準を増やす
マルチエージェント討議は、一人のAIよりも高度な答えを自動的に出してくれる方法ではありません。
効果が出るのは、一つの成果物に対して、顧客、現場、財務、法務などが異なる基準で判断する仕事です。単純な要約や文章作成では、一人のAIで十分です。
実務で使う際は、専門家らしい肩書を並べるのではなく、成果物を承認する人、利用する人、実行する人、止められる人から役割を選びます。そして、それぞれに確認事項、承認条件、反対条件を設定します。
進め方も、最初から自由に話し合わせるのではありません。各論者が独立して評価し、統合者が争点を整理し、必要な論点だけを短く再検討します。最終的な判断は人間が行います。
一人のAIに「もっと多角的に考えて」と頼むだけでは、観点は一つの回答の中に混ざってしまいます。
企画や提案を承認する人、使う人、実行する人、止める人。それぞれの判断基準を分けて与えることで、AIは初めて、異なる立場から同じ成果物を検討し始めます。
大切なのは、AIの人数を増やすことではありません。
人間が決める前に、見落としていた反対理由と判断条件を増やすことです。
