Claude APIの構造化出力でハルシネーションを防ぐ理由。AIの嘘を排除する開発手法

プロンプトに「推測するな」と書けばAIの嘘が止まる。そう思っていた時期が僕にもあった。

検証に使ったのは126件の実データだ。プロンプトによる指示は無力だと分かった。AIはデータ欠損を勝手に補完し、存在しない実績から精巧な嘘のレポートを錬成する。

AIのハルシネーションを防ぐ手段はプロンプトの調整ではない。構造化出力で型を強制的に縛り、出力された根拠をコード側で再検証するゲートを挟むことだ。AIの嘘を構造的に排除する開発手法を解説する。

プロンプト指示を通過するAIの嘘と構造化出力による防壁

AIシステムを本番運用する現場で、プロンプトに「推測するな」と指示してもAIがハルシネーションを起こす構造的欠陥が報告されている。

あるデータパイプラインの検証事例では、収集したデータセットの件数は126件に及んだ。特定フィールドの非存在と「偽」の値を混同した結果、AIは無関係なテキストを根拠にして誤った条件タグを付与した。

自動レポート運用では、テスト用データが混入したままAIに渡されるトラブルが発生した。異常な数値が混入した回数は7回に及んだ。AIが誤認して分析した売上は128,500円、フォロワー増加数は25人という固定値だ。AIはこの架空の数値から広告費として3,000円を提示した。

問題の本質は「データ取得失敗」と「実績が0」の区別がコード側で定義されておらず、AIが空欄を埋めようと辻褄の合う文章を生成した点にある。

しんたろー：
プロンプトに「嘘をつくな」と書いても、AIはデータに空欄があると親切心で埋めにいく。人間側がコードの型で物理的に退路を断つしかないと感じる。

このハルシネーション対策として、Claude APIの構造化出力を活用し、型チェックと根拠の検証を組み合わせる設計が有効だ。

AIからの出力フォーマットとしてスキーマを定義し、返却オブジェクト内に「決定の根拠となった原文」の抽出を必須化する。コード側でその根拠の中に指定した単語が含まれるかを検証し、チェックを通過しない出力はデータベースへ書き込まずエラーログへ回す。検知用にチェックされたキーワードの数は7個だった。

データベース基盤のSnowflake Cortex等でも、AI_COMPLETE関数のパラメータで「RESPONSE_FORMAT」にオブジェクト型を明示指定し、JSON構造を強制する手法が導入されている。

AIの生成結果を信用せず、型定義されたオブジェクトとしてコード側で検証するアーキテクチャが標準パターンとなりつつある。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

あわせて読みたい【2026年版】AI活用1人SaaS開発の完全ロードマップ｜5ステップで始める個人開発 →

プロンプトで祈るのをやめてコードで物理的に絞め殺す

プロンプトに「推測するな」「分からない場合は unknown と出力せよ」と書いても、LLMは確率的に最もらしいテキストを生成し続ける。AIにとって空欄を埋めるインセンティブは、自然言語の命令よりも強力だ。

プロンプトによる指示は努力目標であり、制約として機能しない。AIの出力をシステムに取り込む際、ハルシネーションを防ぐ手段はコードによる物理的なゲートキーパーを構築することにある。

しんたろー：
プロンプトの調整だけでハルシネーションを抑え込もうとしていた時期は、AIのつく巧妙な嘘に毎週のように振り回されていた。でも「AIは嘘をつく前提」で受け取り側のコードにバリデーションを仕込んでからは、夜ぐっすり眠れるようになった。AIを信じないコードを書くのが一番の近道だ。

AIシステムにおける致命的なバグは、例外が発生してプログラムが停止することではない。誤った推論結果が正常なデータのフリをして下流システムに流れ込むことだ。

外部APIからデータを取得する際、取得失敗をプログラム側で捕捉せず、安易に「数値の0」や「空の配列」に変換してAIへ渡してしまうケースがある。下流のAIは、その「0」を実績値として解釈する。売上実績が「0円」なのか、通信エラーで「取得できなかった」のかをAIは区別できない。結果として、存在しない前提に基づいた論理的に正しい悪手を提案してくる。

僕自身、1人SaaSのThreadPostを開発する中で、このデータ漏洩のような論理バグに何度も遭遇した。外部サービスのAPIレスポンスが空だった時、それを単なる空値としてAIに入力すると、AIは文脈を補完するために嘘の分析を展開する。

型定義のレベルで状態を厳密に分ける必要がある。データが存在しない場合はunavailableという明示的なステータスオブジェクトを返し、プロンプト側でも「データが存在しない」と明記する設計が必須だ。

技術的な解決策として強力なのが、Claude APIの構造化出力機能や、データベース側でサポートされているRESPONSE_FORMATの指定だ。出力全体の型をJSONオブジェクトとして強制定義した上で、判定フィールドとは別にevidence（根拠）という文字列キーを必須にする。

判定結果が「特定のステータス」であるにもかかわらず、evidenceの文字列の中に指定した検索ワードが含まれていない場合、コード側で即座にエラーとして弾く。弾いた出力はメインのデータベースには書き込まず、検知用のログテーブルへ隔離する。

僕が日常的に使っているClaude Codeでの開発でも、AIエージェントにコードの自動生成やリファクタリングを任せる際はこの二段構えの検証パイプラインを徹底している。AIが生成したコードや分析結果をそのまま実行・保存せず、受け側のコードで型チェックと根拠の存在確認を実行する。このバリデーション層を1枚挟むだけで、AIを組み込んだプロダクトの運用安定性は変わる。

AIを「賢い推論エンジン」として崇めるのをやめ、「不確定な文字列を出力する危険なコンポーネント」として扱う。システム設計の観点からAIの出力を物理的にバリデーションする実装こそが、開発者に求められるAI活用手法だ。

明日から自社システムへ組み込むべき3つの防衛策

AIを組み込んだシステムや自動化パイプラインを運用する際、開発者が明日から実践すべき設計思想は明確だ。AIの「賢さ」に頼るのをやめ、システム側の構造でAIの嘘を物理的に抑え込む側に回る。

具体的には、以下の3つの防衛策をコードとDB設計に組み込む必要がある。

1つ目は、「データ取得失敗」と「実績0」の完全な分離だ。

APIのレスポンスが空だったりエラーになった際、横着して0や空配列をAIに渡してはいけない。AIはそれを「実績が0件だった」と解釈し、データがない理由を勝手に推測して説得力のあるアドバイスを捏造する。

データが取得できなかった場合は、明確に「取得不可（unavailable）」というステータスを型として定義し、AIには「この項目はデータがないため解析不可」と明示的に伝える。また、「0円は取得失敗ではなく実績が0である」というメタデータをプロンプトに補足することで、AIによる誤った異常値判定を防止できる。

2つ目は、構造化出力（RESPONSE_FORMAT）とコード側での二段構えチェックだ。

プロンプトに「推測するな」と書くだけでは不十分だ。AIに特定の型を強制する構造化出力機能を使い、レスポンスのフィールドとして判定結果だけでなく根拠（Evidence）の文字列を必須化させる。

さらに、返ってきた根拠（Evidence）に特定のキーワードが含まれているかを、バックエンドのプログラムで正規表現や文字列検索を用いて再検証する。AIの推論をそのまま信じるのではなく、AIが提出してきた証拠をコードで物理的に精査する。

しんたろー：
僕もClaude Codeで1人SaaSのThreadPostを作ってるとき、AIの出力をそのままDBに突っこんで後からデータが崩壊しかけたことがある。AIの「分かりました！」は信じちゃダメ。受ける側のコードで型をガチガチに絞めて、エラーをログに吐かせるようになってから夜ぐっすり眠れるようになった。

3つ目は、AIの出力を直接本番データへ書き込まず、隔離ログを挟む運用だ。

AIによる自動解析やコード生成の結果は、即座に正本データベースへ保存してはならない。必ず検証用テーブルや一時ログテーブルを経由させ、バリデーションエラーが発生したデータは手動確認へ回す非同期のパイプラインを構築する。

Snowflakeなどのデータ基盤でクエリ解析や通知を自動化する場合も同じだ。AIの出力を直接後続処理へ流すのではなく、型チェックを通過した安全なデータのみを運用フローに乗せる。

AIを「推論エンジン」ではなく「検証が必要な不確定要素」として扱う。プロンプト調整に時間を費やすくらいなら、受ける側のコードに10行のバリデーションを書くほうが、プロダクトの信頼性は高まる。

あわせて読みたい【2026年版】VRAM 8GBで動かすローカルLLM構築術10選｜1人SaaS開発者の実践記録 →

よくある質問

プロンプトに「推測するな」と書いてもAIが嘘をつくのはなぜ？

AIは確率的に最もらしい続きの文章を生成する仕組みだからだ。データに空欄や不備があると、プロンプトの禁止指示よりも「文脈を埋める」というモデル本来の性質を優先する。

プロンプトのテキスト指示だけでAIを制御するのは無理がある。出力に根拠（Evidence）の引用を必須化し、その根拠が元のテキストに存在するかを受ける側のコードで検証する二段構えのガードレールを作る。

「APIの取得失敗」と「実績0円」をAIに正しく区別させる方法は？

最大の原因は、未取得とゼロをどちらも0や空文字として扱ってしまうシステム設計にある。データが取れなかった場合はunavailableといった明示的なステータスを割り当てることが鉄則だ。

プロンプト側でも「この数値は実データであり0は実績値を意味する」というメタデータを付与するとAIの誤解を防げる。開発者が型と文脈の両面でデータ欠損と実績値を明確に区別して渡す必要がある。

DBでAIの自動解析を組み込む際に最も注意すべき点は？

AIの解析結果を直接本番の正本データベースへ書き込まないことだ。必ず検証用テーブルや一時ログを挟み、型エラーが発生したデータは手動確認へ回す非同期パイプラインを作る。

モデル呼び出し時に構造化出力（JSON形式）を指定して出力を型レベルで拘束し、コード側でパースチェックを行う。不確定な生成結果をデータベースの手前で確実にブロックする設計が運用の安定化につながる。

まとめ

プロンプトに「推測するな」と書くだけじゃ、AIの嘘は止まらない。

AIの出力を鵜呑みにせず、構造化出力で型を縛り、コードで根拠を物理検証する。開発者がデータの直前で厳格なゲートキーパーになることだけが、システムを守る唯一の手段だ。

僕も個人開発でAI連携を組むときは、この検証パイプラインを真っ先に仕込んでいる。AIの「もっともらしい嘘」をコードで防ぐ堅牢な自動化ノウハウは、ThreadPostの開発プロセスでも実践中だ。

👉 ThreadPostでSNS運用を自動化する