AIの出力を出荷前に検証する：AIの正確性をチェックする3つのプロンプト

使用するAIの回答はすべてどこかに反映されます。設定、マイグレーション、チームメイトが信頼するドキュメントなどです。未検証のまま出荷すれば、その誤りも出荷されることになります — しかもあなたの名義で。この記事は、AIの出力を出荷前に検証するために私が使っている実践的なルーチンです。AIの正確性をチェックするためのコピー＆ペーストできる3つのプロンプトを紹介し、それぞれが1つの役割を果たし、数分で完了するチェックを構成します。

最初の2つ — ハルシネーション検出とAIファクトチェックプロンプト — は、このシリーズの前回（下記リンク、各々に独自のテスト実行あり）からのものです。3つ目 — リスクに応じた検証チェックリストの作成 — はここで新しく紹介するもので、以降で触れる罠付きの例でテスト済みです。

AIの出力を検証するには実際に何が必要か？

順を追った3つの手順で、それぞれ異なる質問に答えます：

1. 一掃 — ここにどんな主張があり、どれが捏造に見えるか？ 回答全体を広く浅く調べる。
2. ストレステスト — この意思決定を変える可能性のある主張は実際に正しいか？ 重要な主張に絞って深く調べる。
3. チェックリスト — リスクの大きさを考慮すると、この文章に必要な完全なチェックセットは何か？ 「いくつかチェックした」から「正しいものをチェックした」へ変えるステップ。

ほとんどの人はステップ1の直感的な版で止まってしまいます。本番環境に到達する失敗の多くは、ステップ2と3に潜んでいます。

プロンプト1：回答からハルシネーションを一掃する

要約版：

Audit the text below for hallucinations.
List every factual claim as a numbered line; label each
VERIFIABLE, SUSPECT, or FABRICATION-PATTERN (named
source/study/number with no citation).
End with the 3 claims most likely to be wrong, ranked.
Text: [PASTE THE AI ANSWER]

Enter fullscreen mode Exit fullscreen mode

パート1のテスト実行では、このパターンがサンプル回答に仕込まれた3つのエラーをすべて検出しました — 捏造されたStanfordの研究も含まれます。トレードオフは、ラベルを返すだけで判定は返さず、テキストが長くなるとフラグの数が増えることです。

プロンプト2：これから行動しようとしている主張をストレステストする

短縮版：

Stress-test this claim. Do not assume it is true.
State what evidence would prove it wrong, the 2-3 conditions
it silently depends on, and the likeliest confounder.
Verdict: SUPPORTED / UNCLEAR / DOUBTFUL, one line why,
plus the single fastest check a human should run.
Claim: [PASTE ONE CLAIM]

Enter fullscreen mode Exit fullscreen mode

意図的に敵対的な設計になっており、主張に同意を促すのではなく、主張に対する反証を構築します。パート2のテスト実行では、このファクトチェックプロンプトにより「ORMを使うとSQLインジェクションを防げる」というコードレビュー界隈の俗説が、DOUBTFUL判定と、それを破る正確な抜け道付きで検証されました。

プロンプト3：リスクに応じた検証チェックリストを作成する

新しく追加した完全版 — これは、テキストにどれだけのチェックが必要かを決めるステップです：

Build a verification checklist for the AI-generated text below.
1. State the stakes: LOW / MEDIUM / HIGH, and why in one line.
2. List 3 checks for LOW stakes, 6-8 for MEDIUM or HIGH — each
   check names what to verify and the fastest way to verify it.
3. Order checks so the most damaging-if-wrong claim comes first.
4. End with the one claim that invalidates everything if wrong.
Text: [PASTE]

Enter fullscreen mode Exit fullscreen mode

ポイントは被害順序付けです。最も危険な主張から始まるチェックリストなら、たとえ最初のチェックしか実行しなくても、正しいチェックをしたことになります。

チェックリストプロンプトは本当に重要なものを捉えられるのか？

4文のそれらしいAI風アップグレードアドバイス — 「PostgreSQL 12を16へインプレースでpg_upgradeでアップグレード、ダウンタイムは1分未満、pg_dumpallでバックアップ、後にANALYZEを実行、拡張機能は自動的にアップグレードされるので手動の手順は不要」 — を入力し、最後の主張を仕込んだ罠としました。流暢で安心感があり、誤りです。一度のパス、Claude Sonnet、新規コンテキストで実行した結果は以下の通りです：

• リスク: HIGH、理由も適切 — 本番データベースでこれに従うと、バックアップウィンドウが閉じた後にサイレントなデータアクセス障害が発生するリスクがあります。
• 仕込んだ罠がチェック#1にランク付け — 包括的な主張として誤りと判定し、最速のチェック方法も明記（SELECT * FROM pg_extension; の実行後、各拡張機能の互換性ノートを確認）。
• 同じ主張が無効化要因として指定 — 実行の最後の行：「これを頼りにすれば、ロールバックが不可能になった後に機能が壊れていることに気付くことなく『アップグレードが成功したと信じて完了』できる。」
• 仕込まれていなかったカバレッジ：「1分未満のダウンタイム」が暗黙に--linkモードに依存していること、復元テストをしていないバックアップはバックアップではないこと、12→16への複数バージョンジャンプ自体が検証を必要とすること、テキストにロールバック計画が一切ないこと — 被害順序付けされた8つのチェック。

最後の箇点こそがチェックリストステップの本当の意義です。存在する文を監査するだけでなく、テキストが言及すべきだったのにしていなかったチェックを浮き彫りにします。

無料のチェックリストプロンプトはどこで止まるのか？

同じ実行で明らかになった3つの壁：

• 事実優先のカバレッジ。 チェックはテキストに存在する主張を中心に回ります。論理的エラー、エッジケース、コンプライアンス上の露出は、テキストがたまたまそれらをほのめかした場合にのみ表面化します — 「誰がこれで訴えてくる可能性があるか？」と聞かれたことはありません。
• 直感によるリスク判断。 1行でのLOW/MEDIUM/HIGHは雰囲気チェックです。今回は正しかったですが、より微妙な入力で同じ判断ができる保証はありません。
• 構造のばらつき。 チェック数、深さ、表現は実行ごとに変わります — 1回限りの使用なら問題ありませんが、日常的に頼るルーチンとしては弱いです。

ルーチン版では、完全なプロンプトを有料製品として維持しています：PromptBaseのAI Verification Checklist Builder。1行の推測ではなくリスク評価表からチェックリストのサイズを決め、事実だけでなく論理・エッジケース・法的レビューまでチェックを拡張し、毎回同じ方法で終了します — 他のすべてを無効化する可能性のある重要な主張で。

3つのプロンプトはどのように連携するのか？

構成ルールは簡潔です：

3つすべてに共通するルール：モデルの監査は地図であり、領土ではありません。すべての判定とチェックリスト項目は、最終的に人間がチェックを実行して終わります — grep、ドキュメントページ、テスト復元。プロンプトは検証を置き換えるものではなく、検証に費やす数分が実際に害を及ぼす可能性のある主張に集中することを保証するものです。

AI支援で執筆。本記事のチェックリストテスト実行は、記述通りに実施 — 1回のパス、Claude Sonnet、新規コンテキスト — され、忠実に報告されました。以前のプロンプトのテスト実行は各記事に記録されています。再現する場合：入力は上記に引用済み。

完全版のチェックリストは上記のセクションでリンクされています。ボトルネックがプロンプト自体ではなく出力である場合、Optimizer: Diagnose & Rewriteも維持しています。このシリーズの前回：AIハルシネーションの検出およびChatGPTのファクトチェック。