「私の考えを厳しく検討して」という依頼は、よいプロンプトに見えます。
しかし実際には、丁寧な注意点を三つ挙げ、慎重に考えていることを褒めたうえで、最初から自分が望んでいた案を勧めるだけになりがちです。
原因は構造にあります。モデルはすでに、あなたの問題設定、好みの答え、場合によっては批判してほしい主張まで読んでいます。「批判的になって」と付け加えても、その誘導は消えません。
役立つ反対意見を得るには、モデルに与える情報と、その順序を変える必要があります。
以下の5つは、そのための実践的な手法です。どの方法を使っても、チャットボットが独立した専門家になるわけではありません。それぞれ、特定の失敗を見つけやすくするものです。
パターン1：自分の好みを伏せる
どちらを好んでいるか伝えると、同意を招きます。手がかりを外してください。
弱いプロンプト：
チームで使うツールをAからBへ移行したいと考えています。
この計画の弱点を検討するのを手伝ってください。
モデルには、どの結論が利用者に喜ばれるか分かっています。
より強いプロンプト：
10人のチームが二つの選択肢を比較しています。
選択肢A
- [current facts]
- [costs]
- [constraints]
選択肢B
- [current facts]
- [costs]
- [constraints]
どちらも推奨しないでください。
各選択肢について、次の点を特定してください：
1. 失敗する可能性が最も高い理由、
2. 最も重要な不足情報、
3. その選択肢の方が優れていると判断できる条件。
「現在使っているシステム」や「新しい代替製品」といった表現も避けます。わずかな呼び方の違いにも、評価が含まれるからです。
役立つ場面
- ベンダーの選定。
- 採用か外注かの判断。
- 内製か購入かの判断。
- 現在の手順を維持するか、変更するかの判断。
- すでに自分の本命が決まっている選択。
この方法で解決しないこと
どの事実を提示するかは、自分で選んでいます。好みを伏せて比較しても、省いた情報による偏りは残ります。
パターン2：擁護役と批判役を分ける
一度に回答させると、一つの主張、一つの注意点、無難な結論という折衷案になりがちです。
互いに両立しない役割を、別々に実行させます。
回答A：
選択肢Aについて、根拠にもとづく最も強い主張を組み立ててください。
選択肢Bには触れないでください。
すべての前提を明示し、根拠が不足している箇所を特定してください。
回答Bは、新しいチャットで作ります。
選択肢Bについて、根拠にもとづく最も強い主張を組み立ててください。
選択肢Aには触れないでください。
すべての前提を明示し、根拠が不足している箇所を特定してください。
回答C：
次の二つの主張を比較してください。
文章の巧みさや長さを評価しないでください。
次の項目を挙げてください：
- 提示された事実に裏づけられた主張、
- 外部で確認する必要がある主張、
- 両立しない前提、
- 最大の不確実性を減らせる実験を一つ。
[paste both arguments]
チャットを分けると、それまでの会話に回答が引きずられにくくなります。ただし、本当の意味で独立した回答になるわけではありません。どちらも似た学習パターンを使う可能性があります。それでも、二つ目の役割が一つ目の言い回しに反応するだけになるのは防げます。
パターン3：主張より先に根拠を求める
説得力のある主張を先に求めると、モデルはその主張に都合のよい内容を生成し、後から裏づけを付けることがあります。
順序を逆にします。
意見をまとめる前に、根拠を整理した表を作ってください。
判断基準ごとに、次の項目を記録してください：
- 提示された事実、
- 必要な一次情報源、
- 推定値とその前提、
- 不明な点、
- 各選択肢を反証できる根拠。
私が表を確認し、修正版を返すまで、何も推奨しないでください。
内容を確認した後、修正済みの表だけを渡して分析を依頼します。
すぐに推奨案を求めるより時間はかかります。しかし、重要な判断では、その遅さに意味があります。
役立つ中止基準
最大の不確実性によって結論が逆転する可能性があるなら、最終的な推奨案を求めないでください。試験を設計する、実測値を集める、または不足情報を管理している人に確認します。
パターン4：厳しく見る対象を一つに絞る
「悪魔の代弁者になって」では曖昧です。どの種類の失敗を探すか、具体的に指定してください。
例：
この計画を、運用上の失敗だけに絞って検討してください。
戦略そのものは妥当だと仮定してください。
責任者、監視、ロールバック、保守が欠けている箇所を探してください。
この提案を、影響を受ける従業員の視点だけから検討してください。
示されている利点のうち、従業員ではなく経営側にとっての利点を特定してください。
会社が確認できない、または守れない約束を指摘してください。
このデータの流れを、プライバシー上のリスクだけに絞って検討してください。
データの種類、送信先、保存場所、アクセスできる人をすべて挙げてください。
法的な結論は出さないでください。
対象を絞った厳しい検討は、攻撃的な口調を求めるより役立ちます。「容赦なく正直に」と言えば口調は変わりますが、確認対象を定めれば検討範囲が変わります。
重要度に応じて、観点の異なる確認を複数回行います。どのリスクが現実的か自分で判断するまでは、それぞれの指摘を分けておきます。
パターン5：独立した二つ目の回答を得る
同じ中立的な説明を、次のいずれかに渡します。
- 履歴のない新しい会話。
- 別系統のモデル。
- 自分の好む答えをまだ見ていない人。
次に、意見の相違を比較します。
二人のレビュアーが、同じ意思決定を分析しました。
レビュアー1：
[paste]
レビュアー2：
[paste]
意見の相違一覧を作ってください：
- 論点、
- 各レビュアーの主張、
- それぞれが依拠する根拠、
- 不足している根拠、
- 問題を解決できる責任者。
自信の強さや文章の質で、どちらが正しいか決めないでください。
二つのモデルが一致しても、確認が取れたことにはなりません。モデル同士が、情報源、慣習、盲点を共有している可能性があるからです。役に立つのは、意見の相違一覧と、そこから分かる収集すべき根拠です。
実践例：請求書処理の自動化
当初の計画が、次の内容だったとします。
AIエージェントで仕入先の請求書を読み取り、会計ソフトへ入力し、支払い処理へ回すべきだ。
漠然と弱点を尋ねると、精度や人間による監視について、予想どおりの注意点が返ってくるかもしれません。
代わりに、5つのパターンを使います。
1. 選択肢を中立的にする
- 選択肢A：手入力を続け、チェックリストを改善する。
- 選択肢B：決められた規則による抽出と、人による確認を組み合わせる。
- 選択肢C：抽出、入力、回付を行うエージェントを使う。
- 選択肢D：計画を延期し、まず仕入先の書式を標準化する。
2. 各案を別々に擁護する
それぞれの選択肢について、最も強い主張と前提を明示します。
3. 根拠を整理した表を作る
次の情報を集めます。
- 1か月当たりの請求書件数。
- 現在の処理時間。
- 修正が必要になる割合。
- 標準書式の割合。
- 二重請求や不正請求の金額と頻度。
- 外部連携に必要な権限。
- 例外処理の責任者。
4. 観点を絞って厳しく確認する
- 財務統制。
- 障害時の運用復旧。
- 仕入先情報のプライバシー。
- 従業員の業務手順。
5. 独立した回答を比較する
あるレビュアーは、人件費の削減に注目するかもしれません。別のレビュアーは、現在の手順に信頼できる発注書との照合がなく、自動化は時期尚早だと気づくかもしれません。
最も役立つ結論は、AIへの賛否を強めることではなく、判断を明確にするための2週間の測定かもしれません。
反対意見が形だけになる三つのパターン
モデルがもっともらしくない異論を作る
すべての反論に妥当性があるとは限りません。どの前提や根拠に異議を唱えているのか、明示するよう求めてください。
モデルが無理に賛否を釣り合わせる
すべての選択肢が互角とは限りません。一方だけに、はるかに強い根拠がある場合もあります。長所と短所を同数挙げるよう求めず、判断を左右する論点を求めてください。
モデルが自信満々に何でも否定する
プロンプト次第では、モデルはあらゆる案に反対します。反対意見も、生成された回答であることに変わりはありません。同調的な回答と同じように確認が必要です。
AIアシスタントの迎合性や、利用者の好みを示す情報が回答へ影響することは、研究でも報告されています（Anthropicによる迎合性の研究）。対策は魔法の言葉ではありません。好みを示す手がかりを減らし、根拠を見えるようにする手順です。
そのまま使える反対意見の確認手順
重要な意思決定には、次のプロンプトを使えます。
フェーズ1：問題設定
問題を実質的に異なる三つの方法で捉え直してください。
まだ解決しないでください。
フェーズ2：根拠
提示された事実、検証可能な事実、推定、推論、価値観を分けてください。
判断を逆転させる可能性のある根拠を挙げてください。
フェーズ3：各案の主張
それぞれの選択肢について、最も強い主張を別々に組み立ててください。
前提と失敗する条件を示してください。
フェーズ4：観点別の確認
運用、影響を受ける人、セキュリティとプライバシー、費用の観点から、それぞれ対象を絞って検討してください。
フェーズ5：意思決定の支援
意見の相違一覧を作り、現実に試せる最小の実験を提案してください。
最終判断は下さないでください。
この手順が防ごうとしている失敗は、AIを思考パートナーにするときの4つの落とし穴で説明しています。より一般的な流れについては、AIをよりよい意思決定に使う方法を参照してください。
誠実に認めるべき限界
AIに反対意見を生成させることはできます。しかし、自分が間違っているとAIに確実に判断させることはできません。
モデルは、同じ誤った前提を別の角度から繰り返すかもしれません。古い情報源を引用する可能性もあります。単に役割名を変えただけなのに、独立した回答のように聞こえることもあります。
反対意見は、前提、不足している関係者、集めるべき根拠を探すために使ってください。最終判断は、状況を理解し、その結果を引き受ける人が下します。
