確証バイアスを避けるためにAIには逆の視点でも確認する

概要

自分の中に仮説がある状態でAIに相談すると、質問文の前提とAIの応答が同じ方向に寄ることがある。最初から反対側の立場で聞くと、その偏りを確認しやすい。

基本形は次のようになる。

この考えに反対する立場から、問題点と成立しない条件を挙げて。
そのうえで、この考えが成立する条件と確認すべき事実を分けて。

反対意見をそのまま結論として扱う必要はない。判断前に、弱い前提・未確認の事実・別の解釈を洗い出すために使う。

AIへの質問には、質問者の前提が入り込みやすい。

たとえば「このライブラリを採用してよいか」と聞くと、採用する方向の文脈がすでに入っている。AIはその文脈に沿って、利点や採用理由を整理しやすい。

これは人間側だけの問題ではない。人間には、自分の仮説を支持する情報を優先的に集めやすい確証バイアスがある。AI側にも、ユーザーの前提に沿って応答しやすい性質がある。

逆の視点は、判断材料を増やすために使う。

AIの応答は質問文の影響を受ける。LLMを対象にした研究では、質問文による応答の変化や、ユーザーの信念に合う応答を返しやすい挙動が扱われている。最初の質問が片側に寄っている場合、返ってくる材料も同じ方向に寄る可能性がある。

逆の視点を明示すると、次の情報を拾いやすくなる。

この確認は低コストで実行できる。最終判断をAIに任せる必要もないため、普段の質問に1行足すだけで試しやすい。

まず反対側から問題点を出し、その後に成立条件と確認事項へ戻す。

この考えに反対する立場から、問題点と成立しない条件を挙げて。
そのうえで、この考えが成立する条件と確認すべき事実を分けて。

結論から聞くより、先に材料を並べさせる方が扱いやすい。AIの結論が正しいかではなく、判断に使う材料が不足していないかを見るためである。

ライブラリやツールを選ぶときは、採用理由だけでなく、採用しない条件も聞く。

このライブラリを採用したい。採用する理由と、採用しない方がよい理由を両方挙げて。

設計に自信があるときほど、壊れやすい前提を聞く。

この設計で進めたい。うまくいく前提と、壊れやすい前提を分けて指摘して。

記事や説明文では、読者が引っかかりそうな点を聞く。

この記事の主張を確認したい。納得できる点と、反論されそうな点を両方挙げて。

楽観的な見積もりになっている可能性を確認する。

このタスクは今日中に終わると思っている。遅れるとしたら、どこが原因になりそうか挙げて。

逆の視点を聞いただけでは、単に不安材料が増えることもある。その場合は、最後に確認項目へ落とす。

今の反論のうち、事実確認で判断できるものだけを残して。

確認に使う一次情報、実データ、検証方法を分けて挙げて。

この形にすると、AIの反論をそのまま受け入れるのではなく、次に確認する対象へ変換できる。

逆の視点は、否定的になるために聞くものではない。判断材料を増やすために聞く。

少なくとも次の点は分けて扱う。

特に技術選定や設計判断では、AIの回答を根拠そのものにしない方がよい。AIは確認漏れを見つける補助として使い、最終的な判断は一次情報・検証結果・プロジェクトの制約で行う。

毎回、長いプロンプトを書く必要はない。いつもの質問の最後に、次のどれかを足すだけでよい。

迷う場合は、次の形で足す。

この案の良い点、悪い点、確認すべき事実を分けて挙げて。

AIに逆の視点を聞くのは、AIに正解を決めさせるためではない。ユーザーの質問やAIの応答が片側に寄っていないかを確認するためである。

ユーザーの仮説は質問文に入り込みやすい。AI側にも、その前提に沿って応答しやすい性質がある。AIとの対話では、人間側の確証バイアスとAI側の迎合的な応答が組み合わさることもある。

判断前に「反対側の理由」「成立する条件」「確認すべき事実」を分けて聞くと、この組み合わせによる偏りに気付きやすい。

普段の質問に1行足すだけで実行できるため、技術選定、設計レビュー、文章レビュー、見積もり確認のような場面で試しやすい。