AIの回答を一次情報で検証する手順
AIに調べものを頼むと、たいていそれらしい答えが返ってきます。問題は、その「それらしさ」が正しさと比例しないことです。自信満々に書かれたバージョン番号が存在しなかったり、料金プランが去年の内容だったり。私はAIを日常的に使っていますが、返ってきた回答をそのまま「分かったこと」として扱うことはしていません。AIは当たりを探すための道具で、確定は一次情報でやる。この役割分担が、自分の中ではかなり固まってきました。
この記事は、その検証をどういう手順で回しているか、どこまでやれば十分とみなすか、という運用メモです。
検証の手順
やっていることは単純で、だいたい次の5ステップです。
- 回答を「主張」に分解する — AIの文章は、検証できる事実（バージョン、料金、日付、仕様）と、検証のしようがない一般論が混ざっています。まず事実の部分だけを取り出します。ここで主張が曖昧なままなら、その時点で「使えない回答」です
- 主張ごとに一次情報の置き場を決める — 「ドキュメントのあのページを見れば分かるはず」という当たりを付けます。当たりが付かない主張は、裏取りのしようがないので保留にします
- 実際に開いて照合する — 一次情報を開き、回答の文面と突き合わせます。ここで大事なのは「書いてあるか」だけでなく「書いてあることが回答と同じ意味か」まで見ること。条件付きの記述が、回答では無条件に化けていることがよくあります
- 食い違いを記録する — 一致しなかった点は、どちらが正しいかその場で決めず、まず「食い違っている」という事実を残します
- 使うかどうかを決める — 検証できた部分だけを使う。できなかった部分は「未確認」と明示するか、まるごと出さないか。グレーなまま本文に混ぜないのが自分のルールです
もうひとつ、地味ですが効いている習慣があります。検証した内容には「いつ・どこで確認したか」をメモに残すことです。料金や仕様は後から変わるので、「確認済み」という結論だけが残っていると、数か月後にその結論をまだ信じてよいのか判断できません。確認した日付と一次情報の場所が残っていれば、再確認も差分を見るだけで済みます。
ポイントは、手順1の分解を省略しないこと。文章のまま検証しようとすると、流暢さに引っ張られて「だいたい合ってそう」で通してしまいます。主張の単位まで落とすと、合っている／合っていないがはっきりします。
「一次情報」として数えているもの
裏取りの相手は、原則として一次情報です。自分が数えているのはこのあたりです。
- 公式ドキュメント・マニュアル（製品やサービスの提供元が公開しているもの）
- 仕様書・標準規格そのもの（RFCや公式の仕様ページなど）
- 提供元による一次発表（リリースノート、公式ブログ、プレスリリース）
- 実物のデータ（実際の画面表示、自分の環境での実行結果、実ファイルの中身）
逆に、まとめサイトや他人の解説記事は一次情報に入れていません。あれは「誰かの解釈」であって、AIの回答と同じく検証対象の側です。検索上位の記事同士が同じ誤りをコピーし合っていることもあるので、複数記事が一致しても裏取りにはなりません。
AIが間違いやすいパターン
何度も見てきた、間違いの出やすい型があります。
| パターン | なぜ起きるか（推測含む） | 見抜き方 |
|---|---|---|
| バージョン番号や提供時期が古い／実在しない | 学習データの時点と現行がずれる。もっともらしい番号を作ってしまうことも | 公式のリリースノートやバージョンヒストリーで現行を確認する |
| 料金・プラン・無料枠の数字が違う | 料金改定が頻繁で、古い料金表が世の中に大量に残っている | 料金は必ず公式の料金ページで見る。日付つきの情報源以外は疑う |
| 存在しない機能・設定項目が書かれている | 似た製品の機能と混ざる、要望ベースで「あるはず」と補完される | 公式ドキュメント内でその単語自体を検索し、ヒットしないなら無いとみなす |
| 日付や曜日の取り違え | 計算や換算が挟まる箇所でずれる | カレンダーや実ツールで機械的に確認する。頭の中の検算で済ませない |
| 条件が落ちて断定になっている | 「〜の場合に限り」が要約の過程で削られる | 一次情報側で前提条件・例外の文を探して読む |
とくに厄介なのは最後のパターンで、主張の骨格は合っているのに条件だけ抜けているため、分解と照合をしないと素通りします。
重要な判断では、もう一段やる
普段の調べものは上記の手順で十分ですが、お金が絡む話、安全に関わる話、取り返しのつかない決定では、もう一段だけ追加しています。別の情報源や、別のAIモデルの見解とも突き合わせる、いわゆる disagreement check です。普段から複数のAIに役割を持たせて使い分けているからこそできるやり方で、使い分け自体についてはAIコーディングエージェントの使い分けメモに書きました。
このとき見るのは、一致した点ではなく不一致点の方です。複数のモデルが同じことを言っていても、それは同じようなデータで育った結果かもしれず、安心材料としては弱い。逆に食い違っている点は、どこかに思い込みや古い情報が混ざっているサインなので、そこを一次情報で決着させます。一致より不一致の方が、検証の材料として価値が高いというのが今の実感です。
全部は検証しない、という落としどころ
正直なところ、AIの回答すべてを一次情報で確認していたら、AIを使う意味が半分なくなります。なので実際には、検証のコストと外したときの影響で線を引いています。
- そのまま使う：間違っていても実害がないもの（言い回しの参考、アイデア出し、たたき台の文章）。そもそも事実として使う前提がない
- 主張を分解して照合する：記事や資料に書く内容、他人に渡す情報、手順として実行する操作
- disagreement check までやる：お金・安全・不可逆な決定に関わるもの
なお、「記事や資料に書く内容」の検証を自分のブログの公開前チェックに落としたものが、AIに書かせた記事の品質チェック：出典・捏造・定型文を見抜くです。
線引きの基準は「その情報で自分や他人が行動するか」。行動の根拠になる情報だけ、検証のコストを払う価値があります。
それでも最後に残るのは、「検証できなかったものは、できなかったと分かる形で出す」という当たり前のことです。未確認と書くのは格好悪く見えますが、根拠のない断言の方がずっと始末が悪い。AIの回答は便利で、今後も使い続けます。その前提で、信じる部分と疑う部分を最初から分けておく。この記事の手順は、そのための自分なりの型です。