1. はじめに
先日、以下の内容についてTwitter（現X）にポストしました。
「技術的に不可能です」と回答した要件に「でもGeminiは出来るって言ってるからやりましょう」とPMに言われる実績を解除しました
— 名前迷子 (@maigo_name) 2026年9月3日
私の調査結果と、監督者がAIを使って得た調査結果が異なり、後者を基に作業が進みそうになった事例です。 ポストには書きませんでしたが、確認すると、このAIの回答は事実と異なっていました。 本記事で扱いたいのは、私の判断が正しかったということではありません。AIを利用した調査結果を、利用者がどのように確認・評価すればよかったのか、という点です。
ありがたいことに、このポストには多くの反応をいただきました。その中に、相手が提示したAIの情報をどう確認すればよいのだろう、という趣旨の声がいくつかありました。
この記事は、まだAIの操作に自信がない人や、最近AIを使い始めて、そのアウトプットのすごさに触れた人に参考になればと思っています。
ここ1年ほど、ソフトウェア開発でのAI活用や使い方の共有が非常に活発になりました。その過程でAIの間違いを経験してきた人の中には、「出てきた情報は確認が必要」という感覚が身に付いている人もいると思います。一方、最近の自然で精度の高い回答からAIを使い始めた人は、同じ回答を見ても、想定する間違いの程度が異なるかもしれません。
冷静に考える時間があれば、確認方法を思いついたり、相手とのコミュニケーションで解決できたりする場合もあると思います。それでも、目の前で「AIはできると言っている」と言われると、どこから確かめればよいのか戸惑う人もいるのではないでしょうか。
そこで本記事では、私がソフトウェア開発でAIを使う中で普段行っている確認方法を紹介します。自分でAIに聞いて得た回答にも、第三者がAIを使って持ってきた回答にも使える方法です。
2. 結論
AIの回答は、次の流れで確認すると整理しやすくなります。
要件と前提をそろえる
↓
別のAIにレビューさせる
↓
根拠を提示させる
↓
一次情報や動作検証で裏を取る
| 確認方法 | 目的 |
|---|---|
| 別のモデル・AIによるレビュー | 誤りや見落としの候補を洗い出す |
| 判断根拠の提示 | 主張を検証できる状態にする |
| 自分で裏取り | 実際に要件を満たせるか判断する |
別のAIが同意したことも、AIが出典を挙げたことも、それだけでは正しさの証明にはなりません。公式情報や実際の動作と照らし合わせ、根拠を確認します。
3. ハルシネーション（コンファブレーション）とは何か
ハルシネーション（Hallucination、幻覚）は、AIが事実と異なる内容や、根拠のない内容をもっともらしく生成してしまうことを指します。
米国の標準技術研究所であるNISTは、この現象を「Confabulation（コンファブレーション、作話）」と呼び、一般にはハルシネーションや捏造とも呼ばれると説明しています。
「ハルシネーション」は広く使われ、読者にも伝わりやすい言葉です。一方、「コンファブレーション」は、AIが知覚して幻を見ているかのような印象を避け、誤った内容をもっともらしく組み立てる現象として捉えやすい言葉だと思います。
この記事では一般的な呼び方に合わせて「ハルシネーション」を主に使いますが、意図的な嘘を意味するものではありません。確認したいのはAIの意図ではなく、出力と事実の差です。
技術的な相談では、次のような形で現れます。
- 存在しないAPIや設定項目を提示する
- 対応していない機能を「使える」と説明する
- 異なるバージョンの仕様を混ぜる
- 実在しないドキュメントやURLを出典として挙げる
手順やサンプルコードまで付いていると、すでに実現方法が確立しているように見えます。しかし、説明の具体性と正しさは別のものです。
4. 3つの確認方法の前に、要件と前提をそろえる
AIの回答を確認する前に、AIへ伝えた内容と実際の要件が一致しているかを確認します。
AIのいう「できる」が、次のような前提に立っているかもしれません。
- 利用できない外部サービスを使う
- 自動化が必要な処理を手作業で補う
- 対象環境にはない権限や機能を使う
- 必須条件の一部を省略する
これらはハルシネーションではなく、質問時の情報不足や前提の食い違いによって起きる場合もあります。
第三者がAIに聞いた結果であれば、「できると言っていた」という結論だけでなく、AIに入力した内容と返ってきた回答を可能な範囲で共有してもらいます。その上で、必須要件、環境、制約、成功条件をそろえます。
たとえば、次のように伝えればよいと思います。
こちらでも確認したいので、AIに聞いた内容と回答、出典のリンクを見せてもらえますか。
5. 別のモデル・AIに相互レビューさせる
まず、元の回答に誤りや見落としがないか、別のモデルやAIにレビューさせます。たとえば、Claudeで得た回答を、ChatGPTやCodexなど別のAIプロダクトにも確認させます。
レビューとは、回答を採用する前に、誤りや見落としがないかを点検することです。単に「合っていますか」と聞くのではなく、確認する観点も渡します。
以下の要件と実現案をレビューしてください。 ・実在しないAPI、機能、設定項目はないか ・要件を満たしていない箇所はないか ・必要な前提条件が省略されていないか ・一次情報や動作検証で確認すべき箇所はどこか 確認できた事実と推測を区別し、 不明な点は不明としてください。
可能であれば、モデルの切り替えだけでなく、別のAIプロダクトを使うのがおすすめです。AIごとに回答の傾向や得意不得意が異なるため、異なる観点や見落としが出てくる可能性があります。多様なモデルを組み合わせて推論を改善した研究例もあります。
ReConcile: Round-Table Conference Improves Reasoning via Consensus among Diverse LLMs
別のプロダクトを使えない場合でも、モデルを変更したり、新しいセッションを開いたりする意味はあります。同じセッションでは、直前までの質問や回答がコンテキスト、つまり会話の前提情報として残ります。AIはその流れとの一貫性を保とうとして、最初の結論から離れにくくなる場合があります。会話で示された利用者の考えに合わせてしまう傾向も報告されています。
Anthropic: How people ask Claude for personal guidance
私はまず、新しいセッションで同じ要件だけを渡し、元の回答を見せずに独立した回答を出してもらいます。その後に元の回答も渡し、違いと確認すべき点を挙げてもらいます。
ただし、別のAIプロダクトが同じ結論を出しても、正しいとは限りません。複数のAIが似た情報を学習し、同じ誤りをする可能性もあります。相互レビューの役割は多数決ではなく、異なる回答や根拠から確認すべき点を増やすことです。
6. 判断の根拠になったものを提示させる
次に、「できる」と判断した根拠をAIに提示させます。
「この要件を実現できる」という回答を支える資料を示してください。 ・公式ドキュメントのURLと該当箇所 ・どの記述が、どの要件を満たす根拠になるか ・対象バージョン、必要な権限、利用条件 ・資料に書かれた事実と、そこからの推測 確認できていない箇所は、未確認としてください。
ここで欲しいのは長い説明ではなく、こちらがたどって確認できる情報です。
URLが付いていても、そのページが存在するか、該当する記述が本当にあるか、今回の条件に当てはまるかを確認します。実在する公式ドキュメントでも、AIの主張を裏付けているとは限りません。
7. 自分で裏取りする
最後は、提示された情報を自分で確かめます。
一次情報を確認する
公式ドキュメント、仕様書、リリースノートなど、機能やサービスの提供者が公開した情報を読みます。機能の有無だけでなく、対象バージョン、権限、制限事項も確認します。
類似事例を探す
似た要件の実現例があれば、実装や検証の手掛かりになります。ただし、環境やバージョン、運用条件が異なる場合もあるため、今回と共通する条件と異なる条件を確認します。
最小構成で動作検証する
実際に試せるなら、判断を左右する部分を小さく検証します。
たとえば、「このAPIで必要な情報を取得できるか」「この権限で必要な操作が通るか」を確認します。検証前に成功条件を決め、環境、手順、期待する結果、実際の結果を残します。
コードが実行できたことと、要件を満たしたことは同じではありません。また、一度の失敗だけで技術的に不可能とも限りません。検証で確認できた範囲を明確にします。
8. 架空の例で確認の流れをたどる
ここまでの方法を、架空の例に当てはめてみます。技術的な回答で起こりやすく、主張を分解しやすい「APIで必要なデータを取得できる」という回答を例にします。
別のAIにレビューさせて、APIの存在、利用条件、取得できる項目を確認点として洗い出します。次に元のAIへ公式ドキュメントの提示を求め、最後に自分で資料と実際の応答を確認します。
確認内容を分解すると、次のような形になります。
| AIの主張 | 確認方法 | 結果 | 次の対応 |
|---|---|---|---|
| 必要なAPIが存在する | 公式ドキュメントを確認 | 確認済み | 次の条件を確認する |
| 現在の環境で利用できる | 対象バージョンと権限を確認 | 未確認 | 追加調査する |
| そのAPIで要件を満たせる | 最小構成で動作検証 | 不成立 | 別の方法を検討する |
根拠が見つからない段階では誤りと断定せず、「未確認」として扱います。仕様や動作検証によって要件を満たせないと確認できた時点で、「不成立」と判断します。
最初の主張が正しくても、最後の主張まで正しいとは限りません。「何を確認できたのか」を分けることが大切です。
確認の深さは影響度で決める
すべての回答を同じ深さで調べる必要はありません。判断が外れたときの影響に応じて、確認の範囲を変えます。
| 判断の影響 | 確認の目安 |
|---|---|
| 低い | 別のAIによるレビューと、提示された出典の確認 |
| 工数や納期に影響する | 公式情報で対象条件まで確認 |
| 大きな費用や本番変更を伴う | 公式情報、最小構成での動作検証、関係者による根拠の確認 |
9. 判断の根拠を比較する
情報の正確さを高めるには、提案ごとに判断を支える根拠を並べ、比較することが大切です。
AIが提案した方法に、私が知らない解決策が含まれている可能性はありますし、私自身の判断にも見落としはあり得ます。発言したのが人かAIかではなく、それぞれがどの条件と情報から結論を出したのかを確認します。
人による発言や提案にも、何らかの根拠があるはずです。自身の経験が根拠なら、どのような環境や条件で経験したのかを確認できます。過去に調べた内容が根拠なら、公式ドキュメントや類似事例を改めてたどれます。必要であれば、最小構成で動作を確認できます。
これは、ここまで紹介したAIの回答に対する確認方法と同じです。「できる」「できない」の両方について前提と根拠を提示し、その根拠を比較します。
たとえば、次のように進められます。
その方法で要件を満たせるなら採用したいです。まず、成立に必要な機能の公式仕様と、今回の条件で動くことを確認しましょう。未確認であれば、実装の見積もりや約束に入る前に、小さく検証したいです。
AIの提案は、調査を始めるきっかけになります。人間の経験や過去の調査も、判断を始める重要な材料です。それぞれの根拠を同じ条件で確認することで、実装を進めるための判断材料を増やせます。
10. まとめ
AIの回答を業務上の判断に使うなら、回答を受け取った後の確認までを一つの作業として考えます。
- 別のモデル・AIにレビューさせ、疑問点を洗い出す
- 判断を支える資料を提示させ、主張と根拠を対応させる
- 一次情報、類似事例、動作検証で自分でも裏を取る
毎回すべてを同じ深さで調べる必要はありません。それでも、実現可否や工数、納期を左右する回答には、その影響に見合う確認が必要です。
「AIができると言っている」と言われたときに確認したいのは、どのAIが答えたかだけではありません。
どの条件で、何を根拠に、どこまで確認して「できる」と言っているのか。
自分が得た回答にも、相手が提示した回答にも、同じように確認できます。どこから確かめればよいか迷ったときに、この記事が手掛かりになればうれしいです。
