SQL/ID抽出タスクから考える 実践的なハルシネーション対策

生成AIを開発に活用する場面が増える一方で、LLMの出力をそのまま信じることによるリスクも大きくなっています。

本資料では、CSVからIDを抽出し、SQLのIN句に埋め込んでUPDATE文を生成するタスクで、LLMが存在しないIDを生成してしまった事例をもとに、開発現場におけるハルシネーションの脅威と対策を整理します。

特に、LLMを「照合機」ではなく「生成器」として捉え、クリティカルな処理では生成・検証・実行の責務を分けることの重要性について説明します。

主な内容：
- 開発における生成AI活用と品質面のリスク
- SQL/ID抽出タスクで発生したハルシネーション事例
- LLMが厳密な照合を苦手とする理由
- DB更新や一括処理での実務的な注意点
- dry-run、件数確認、差分確認、スクリプト化による対策
- 関連論文「Copy-Paste to Mitigate Large Language Model Hallucinations」の紹介

Transcript

1. 0 SQL/ID抽出タスクから考える 実践的なハルシネーション対策 2026-05-06 第146回NearMe技術勉強会 Kaito Asahi
2. 1 昨今は⽣成 AI により開発の速度がとても上がった • コード補完 • 全体設計 • 全体の実装計画 • 単体テスト作成 • etc…
3. 2 昨今は⽣成 AI により開発の速度がとても上がった • コード補完 • 全体設計 • 全体の実装計画 • 単体テスト作成 • etc… ここら辺の開発速度は格段に上がった
4. 3 昨今は⽣成 AI により開発の速度がとても上がった • コード補完 • 全体設計 • 全体の実装計画 • 単体テスト作成 • etc… ここら辺の開発速度は格段に上がった ⇨ これに伴って質は上がっているのか？ 🤔
5. 4 ハルシネーションの脅威 ⽣成 AI に⽣成してもらったコードや考えは本当に正しいのか？ 開発におけるハルシネーションは、単なる「間違った説明」ではなく、 実装‧DB更新‧依存関係‧運⽤判断に直接影響する。 Ex) • 存在しないID、カラム、テーブルを⽣成する • 仕様と異なるロジックをもっともらしく実装する • 存在しないライブラリや API を提案する • テストは通るが、本番データでは壊れる処理を書く ⇨ ⽣成結果を「そのまま実⾏できる成果物」として扱わないことが重要
6. 5 ハルシネーションの脅威：ケーススタディ Ex) とある id の配列を持っており、その配列を⽤いて特定の SQL を⽣成さ せたい • やりたいこと ◦ 特定の SQL の IN 句の後に指定の id 配列を埋め込んでクエリを⽣成 して欲しい
7. 6 ハルシネーションの脅威：ケーススタディ Ex) とある id の配列を持っており、その配列を⽤いて特定の SQL を⽣成さ せたい • input 例 添付した CSV にある id を用いて以下の SQL を完成させてください。 UPDATE sample_data SET column1 = “red” WHERE id IN (ここに ID を挿 入);
8. 7 ハルシネーションの脅威：ケーススタディ • 期待していた処理 ◦ CSVの対象⾏だけを選ぶ ◦ ID列を漏れなく抽出する ◦ IN句に正確に並べる ◦ UPDATE対象件数を確認する • 実際に起きたこと ◦ CSVに存在しない偽IDが混⼊ ◦ ⼀部の本来対象IDが抜ける ◦ SQL⾃体は⼀⾒もっともらしい ◦ UPDATEが完全に完了しない
9. 8 なぜ起こるのか：⼤前提 LLM というのは「照合機」ではない！！ LLMは、⼊⼒を厳密にコピー‧照合するための仕組みではなく、 ⽂脈上もっとも⾃然そうな続きを⽣成する仕組み。 1. 確率的に⽣成 → 前後のIDの並びから、それっぽいIDを補完してしまうことがある 2. ⼊⼒より内部知識‧⽂脈の⾃然さを優先することがある → 与えたCSVに忠実であることより、⾃然な出⼒を優先する場合がある 3. ⽣成結果の⾃⼰検証は保証されない → SQLが⽂法的に正しくても、ID集合が正しいとは限らない
10. 9 ハルシネーションを防ぐためには...（影響を受けないためには） クリティカルな場⾯では「直接実⾏」させない • 本番 DB の UPDATE / DELETE / INSERT • ユーザー影響のある設定変更 • 課⾦‧権限‧通知などの変更 • ⼤量データに対する⼀括処理 これらは、LLM の出⼒をそのまま実⾏せず、 必ず⼈間レビュー‧dry-run‧差分確認を挟む。 NG： LLM が出した SQL をそのまま本番 DB で実⾏する OK： LLM には⽅針やテンプレートを作らせ、 ID 抽出‧件数照合‧実⾏判断はプログラムと⼈間で⾏う
11. 10 ハルシネーションを防ぐためには...（影響を受けないためには） 出⼒結果を⼗分検証する SQL の場合は、実⾏前に最低限以下を確認する。 • CSV の ID 件数 = IN 句の ID 件数 になっているか • CSV 側 ID 集合 - SQL 側 ID 集合 が空か • SQL 側 ID 集合 - CSV 側 ID 集合 が空か • 重複 ID がないか • SELECT で UPDATE 対象件数を確認したか • トランザクション内で実⾏できるか • ロールバック⼿順があるか 「SQL が⽂法的に正しい」ことと「対象データが正しい」ことは別問題
12. 11 ハルシネーションを防ぐためには...（影響を受けないためには） SQLそのものではなく、SQLを⽣成するスクリプトを書かせる LLMに任せる： • CSVを読み込むPythonスクリプトの雛形作成 • SQLテンプレートの作成 • バリデーション観点の洗い出し LLMに任せない： • ID の最終的な値の⽣成 • 本番 DB への直接実⾏ • 検証なしの UPDATE ⽂確定 メリット： • IDはCSVから機械的に読み取るため、偽IDが混⼊しにくい • 件数‧重複‧差分をプログラムで確認できる • レビュー対象が「⻑いIDリスト」ではなく「短いスクリプト」になる
13. 12 ハルシネーションを防ぐためには...（影響を受けないためには） そもそも⽣成 AI に頼らなくても良い部分では頼らないようにする • 優先度を正しく考えて実⾏をするべき ◦ 本番 DB の更新など、作業効率よりも本番でのインシデントの⽅がク リティカルである
14. 13 ハルシネーションを防ぐためには...（影響を受けないためには） ⽤途に応じてモデル‧仕組みを分ける • 汎⽤LLM ◦ 設計相談、実装⽅針、レビュー観点の洗い出しに向く • RAG / NotebookLM ◦ 与えた資料に基づく要約‧検索に向く ◦ ただし、根拠への忠実性は別途確認が必要 • ファインチューニング ◦ 出⼒形式や社内ルールへの適応に有効 ◦ ただし、事実性を完全に保証するものではない 重要： モデル選定だけでなく、 「検証フロー」と「実⾏権限の制御」をセットで考える
15. 14 関連論⽂調査 • Copy-Paste to Mitigate Large Language Model Hallucinations （https://arxiv.org/abs/2510.00508） ◦ ⽂脈に忠実にするには「⾔い換え」より「引⽤/コピー」を増やす発 想 ◦ RAG でも LLM は与えた⽂脈を信じ切れず、内部知識に寄ることがあ る ◦ 回答中のコピー度が⾼いほど、⽂脈不忠実なハルシネーションが低い 傾向 ◦ CopyPasteLLM は少量の⾼コピー応答データで⽂脈忠実性を⾼める https://github.com/longyongchao/CopyPasteLLM
16. 15 Thank you