LLMフォレンジックの限界｜動くのに誤るSQL結合

AIエージェントに調査対象の端末データを渡し、「誰といつやり取りしたか」を自動で洗い出させる——インシデント対応の現場で現実味を帯びてきた話です。しかし査読を経た新しい研究は、そこに厄介な落とし穴があることを示しました。LLMが書いたSQLは「エラーなく実行できるのに、結合の仕方が間違っている」ことがあるという指摘です。しかも設計資料のないアプリのデータベースほど、その傾向が強く出ます。

結果だけ見れば表が出てきて、それらしい件数が並ぶ。だから気づけない。これは証拠として扱う場面では致命的です。

この記事でわかること

  • LLMエージェントが「未文書化のアプリDB」を調べるとき、どこで精度が落ちるのか
  • スキーマが整ったDBと乱れたDBで、結果がどれほど変わるか（実測値）
  • 観測された4つの失敗パターンと、情シスが検証工程に組み込むべきこと

どんな研究か

Jeel Piyushkumar Khatiwala氏らによる論文「Structural Inference in Undocumented Mobile Databases: A Reproducible Benchmark for Evaluating Agentic Reasoning in Digital Forensics」（2026年8月21日 arXiv公開、arXiv:2608.21470）です。一言でいえば、設計仕様が公開されていないスマホアプリのデータベースを、LLMエージェントがどこまで正しく「読み解けるか」を再現可能な形で測ったベンチマーク研究です。

arXiv版はプレプリント（著者版）ですが、論文のコメント欄には第50回IEEE COMPSAC（2026年7月・マドリード）での発表論文と記載されています。とはいえ後述のとおり検証範囲は限定的で、この1本を一般化しすぎるのは禁物です。

「未文書化DBの構造推論」とは何ですか

スマホアプリの多くは、端末内にSQLite形式のデータベースを持ち、そこにメッセージ・連絡先・送受信の記録などを保存しています。フォレンジック調査では、この生データから「このメッセージは誰から誰へ送られたか」を復元します。

ところが、標準的なOS機能のDBは仕様が知られている一方、個別アプリのDBはテーブル名も列名も設計意図も公開されていません。列名が略語だったり、IDが一時的に振り直されたりします。そこで調査員は経験からテーブル同士のつながり（結合＝JOIN）を推測する。この推測作業をLLMに任せられるか、というのが本研究のテーマです。

実験の設定と結果

比較されたのは対照的な2つのSQLiteデータベースです。

  • Android標準のSMSデータベース（mmssms.db）：スキーマが規則的で、識別子が素直に引き継がれる
  • Snapchatのデータベース（main.db）：スキーマが不規則で、識別子が一時的（消える・変わる）

調査質問は12問で、G1「基本的な検索」4問、G2「絞り込み・文脈依存」4問、G3「多段の依存関係をたどる高度な推論」4問の3層構成。専門家が書いたSQLを正解として、LLMが導いた関係の構造的な正しさを測っています。使用モデルはGPT-4.1の1構成のみ、温度0.0・top_p 1.0、入出力とも4,096トークン、1問につき1回だけ実行（再試行やサンプリングなし）という決定論的なプロトコルです。

スキーマが乱れた途端に崩れる

論文で報告された主な数値を並べます。F1は正確さと網羅性を合わせた指標で、1.00が満点、0.00は正解と一致しなかったことを意味します。

観点 Android SMS（mmssms.db） Snapchat（main.db）
基本的な検索でのF1 Q1・Q3・Q4・Q5・Q9で1.00に到達 Q1でPrecision 0.40 / Recall 0.67 / F1 0.50
0.00だった質問 （該当の報告なし） Q3・Q5・Q9・Q10・Q12
Q7のスコア Precision 0.82 / Recall 1.00 / F1 0.90 Precision 0.60 / Recall 1.00 / F1 0.75
実行の一貫性（基本検索） 4/4 2/4
実行の一貫性（絞り込み） 3/4 3/4
実行の一貫性（高度な推論） 2/4 1/4

規則的なSMSのDBでは満点が並ぶのに、Snapchatでは5問がスコア0.00。著者らの言葉を借りれば、構造推論は「スキーマの曖昧さが増すにつれて急激に劣化する」のです。

本当に怖いのは「エラーが出ないこと」

この研究の核心は、精度が落ちるという事実そのものより、落ち方が見えにくいことにあります。論文が特定した失敗は、SQLの構文エラーやスキーマエラーではありません。クエリは正常に実行され、結果も返ってくる。それでいて関係の解釈が専門家の正解とずれている、というタイプの失敗です。

分類は4つ。

  1. 曖昧なリンク属性の選択（ambiguous linking attribute selection）：結合キーとして似た名前の別の列を選んでしまう
  2. 結合パスの置換（join path substitution）：意図した経路とは別のテーブル経由でつないでしまう
  3. 補助テーブルの干渉（auxiliary table interference）：本筋でない付随テーブルを巻き込んで結果を歪める
  4. 構造的な過制約（structural overconstraint）：条件を付けすぎて本来含まれるべき行を落とす

いずれも「動いた＝正しい」と判断すると素通りします。3番目・4番目は件数が不自然に増減するので気づける可能性がありますが、1番目・2番目はもっともらしい表が出てくるだけで、元のデータ構造を知らない人には検知不能です。

情シスの実務にどう効くか

「うちはスマホのフォレンジックなんてやらない」と思われたかもしれません。しかしこの知見は、もっと身近な場面に効きます。

調査目的で生ログやDBをAIに読ませて集計させる作業は、すでに多くの現場で日常になりつつあります。侵害の疑いが出たときにアクセスログとユーザー台帳を突き合わせる、SaaSのエクスポートCSVから該当アカウントの操作履歴を抜き出す——構造の対応づけをAIに任せている点で、本研究が扱った問題とまったく同じ構図です。そして社内システムのログスキーマは、たいてい「未文書化」です。

実務に落とすなら、次の3点でしょう。

  • AIの出力は「仮説」として扱う。件数が返ってきたことを成功の合図にしない。少なくとも1件は元データまで遡って手で確認する。
  • スキーマの素性で警戒度を変える。仕様が公開されている標準的なログ（OSのイベントログ等）と、独自アプリ・SaaS固有のエクスポートでは、AI出力の信頼度が同じではない。
  • 結合条件を人が読める形で残させる。「どの列とどの列をつないだか」を明示させておけば、上の4パターンは後から点検できる。結果だけ受け取ると検証の手がかりが消える。

そして、社内調査の結果を懲戒や外部報告の根拠にする場合は、AIの推測をそのまま証拠として扱わないでください。手続きの基本は公的な指針に立ち返るのが確実です。デジタル・フォレンジック研究会の証拠保全ガイドライン 第10版は、保全の順序や記録の残し方を体系的にまとめています。組織としての対応フロー側は、JPCERT/CCのCSIRTマテリアル（運用フェーズ）が実務的です。手順を「知っている」と「動ける」の差を埋めるには、IPAのセキュリティインシデント対応 机上演習教材で一度通しでやってみるのが早いと思います。

現場目線の所感

正直なところ、この手の作業をAIに任せたい気持ちはよくわかります。深夜、見たこともないテーブル名が並ぶダンプを前に、列名の意味を1つずつ推理していく作業は消耗します。そこに「はい、該当は37件です」と即答してくれる相棒が現れたら、頼りたくなるのが人情です。

ただ、この研究が突きつけているのは、AIが間違えるという話ではなく、AIの間違いが人間の「確認したつもり」をすり抜けるという話だと感じます。エラーで止まってくれるなら気づけます。しかし整った表が出てきたとき、疲れている自分がそれを疑えるかというと、あまり自信がありません。

限られた人員で調査まで抱える情シスにとって、AIの活用は選択肢というより必然に近い。だからこそ「AIを使わない」ではなく、「AIの答えのどこを人が見るか」を先に決めておくことが現実的な落としどころだと思います。少なくとも、結合条件だけは自分の目で追う。それだけで防げる誤りが、この論文の4分類のうち相当部分を占めるはずです。

限界と留意点

著者自身が挙げている限界も押さえておきます。過度な一般化は避けるべきです。

  • 評価は単一モデル構成のみ。他のモデルや、複数エージェントを組み合わせた構成では結果が変わりうる。
  • 1問1回の決定論的実行のため、ばらつき（分散）は報告されていない。
  • 対象は2つのDB・12タスクに限られる。
  • 正解は専門家が定義した1つのクエリのみ。別の書き方でも妥当な回答が、不正解と判定された可能性がある。
  • 複数DBをまたぐ推論や、プロンプトの書き方による感度は評価対象外。

つまり「LLMはフォレンジックに使えない」という結論ではありません。スキーマの規則性という条件によって信頼度が大きく変わる、そこを測る土台を作った、というのが本研究の位置づけです。

まとめ

  1. LLMエージェントの構造推論は、規則的なスキーマでは高精度だが、曖昧なスキーマでは急激に劣化する（Snapchat DBでは12問中5問がスコア0.00）。
  2. 危険なのはエラーを出さずに誤ること。曖昧な結合キーの選択・結合パスの置換など4つの失敗パターンは、結果だけ見ても気づけない。
  3. 実務では、AI出力を仮説として扱い、結合条件を明示させて人が点検する運用にする。証拠性が問われる場面では公的なガイドラインの手順に立ち返る。

関連記事

出典

タイトルとURLをコピーしました