AI生成文に秘密情報を隠す研究｜検知の限界

LLMが書いた「ごく普通の文章」の中に、秘密のデータを埋め込んで送る技術があります。2026年8月1日にarXivで公開された査読前の論文「TI-StegoAlign」は、この生成型テキストステガノグラフィで長年の弱点だった「受信側でうまく取り出せない」問題を解消し、秘密情報の復元率100%を報告しました。情シスにとっての意味はひとつです。社外に出ていくAIの出力テキストそのものが、キーワード検知では見つけられない情報持ち出しの経路になりうるということです。

ただし、これは「明日から被害が出る」類の話ではありません。何が新しくなり、どこからが過剰反応なのかを切り分けておきます。

この記事でわかること

  • 生成型テキストステガノグラフィとは何か、従来何ができていなかったのか
  • 「トークン化のズレ」という地味だが致命的な問題と、その解消が意味すること
  • 検知（ステガナリシス）は現状どこまで通用するのか、報告された数字
  • 情シスが今のうちに押さえておくべき論点と、過剰反応しないための線引き

どんな研究か

生成型テキストステガノグラフィとは、暗号文のような「明らかに怪しい文字列」を作らず、意味の通る自然な文章を生成しながら、その単語選択の中に秘密情報のビットを埋め込む技術です。受け取った側は同じモデルと手順を使って、文章から元のビット列を復元します。

暗号化との違いが要点です。暗号文は「暗号文だ」と一目でわかるので、通信の存在自体は隠せません。ステガノグラフィは通信していること自体を隠すため、監視する側から見ると「業務に関係のある、ごく普通のメールや要約や商品レビュー」にしか見えません。

今回の論文（華東師範大学などの研究グループ、Jiuan Zhou氏ほか）は、この技術を新たに発明したものではなく、実際の通信で成立させるための「詰め」の部分を扱っています。

何が新しく分かったのか

送信側では成功、受信側では失敗する — 「トークン化のズレ」

LLMは文章を「トークン」という単位に分割して扱います。送信側はトークンの並びとして秘密情報を埋め込みますが、受信側が受け取るのは、トークンではなく表面に現れた文字列だけです。受信側はそれをもう一度自分でトークンに分割し直します。

このとき、トークンの区切り位置が送信側と1か所でもズレると、そこから先の復号がまとめて狂います。論文によれば、ズレが起きたケースの45.3%で、最初の誤りの後にさらに3ビット以上の誤りが連鎖していました。

やっかいなのは、従来の研究の多くが送信側のトークンを基準に「復元できた」と評価していた点です。送信側の帳簿では成功、受信側の実態では失敗という評価のギャップが放置されていた、というのがこの論文の出発点です。設定値の台帳上は対策済みなのに実機では効いていなかった、という現場でおなじみの構図とよく似ています。

後追いの修正ではなく、生成の方針そのものを変えた

従来手法は、出力を作ってから怪しい箇所を弾く・検証するという「後処理」で対応していました。今回の手法は、再分割されても区切りが変わりにくい単語を、そもそも選ぶようにモデル側を追加学習させています（ベースのモデルは凍結し、LoRAという軽量な追加部品だけを更新する方式）。受信側で復元できるかどうかを含めて、文章の自然さ・意味の忠実さ・検知されにくさの4点を同時に評価しながら学習させる構成です。

報告された主な結果は次のとおりです。評価にはLlama-3.1-8Bなどを用い、ニュース記事・映画レビュー・ツイートの3ドメインで、延べ約31万件の送信を試験しています。

指標 本手法 従来手法の最良 意味
受信側でのビット復元率 100% 100%（同等） 取りこぼしなく復元できる
文章の不自然さ（正規化パープレキシティ偏差） 0.429 0.547 21.6%改善。より自然な文章になる
検知器の平均正解率（ステガナリシス） 60.61% 64.68% 低いほど見つかりにくい

検知はどこまで通用するのか

結論から言えば、文章を見て「隠されているか」を当てる検知器は、現状ほとんど頼りになりません。上の表の検知器正解率60.61%という数字は、専用に訓練された検知器ですら「当てずっぽう（50%）よりわずかに良い」水準にとどまることを示しています。従来手法に対する64.68%も似た水準で、そもそもこの土俵での検知は苦戦しているのが実情です。

そしてDLPやメールフィルタが得意とする「キーワード・正規表現・ファイル形式」による検知は、原理的にこの経路を素通りします。マイナンバーの桁数パターンも、機密ラベルも、顧客名も、文面には一切現れないからです。現れるのは、ごく自然な業務文章だけです。

なぜ情シスに関係するのか

とはいえ、この技術がそのまま「明日の脅威」になるわけではありません。成立には送信側と受信側が同じモデル・同じ手順・同じ鍵情報を共有していることが前提で、外部の第三者が勝手に読み取れるものではありません。つまり、これは「外から破られる脆弱性」ではなく、内側の誰か（あるいは何か）が意図して使ったときに、監視をすり抜けるタイプのリスクです。

現実的に効いてくるのは次の2つの文脈です。

  • AIエージェント同士のやり取り：論文自身が想定用途として挙げているのがこちらです。複数のAIエージェントが自然言語のメッセージで連携する構成では、そのメッセージは運用者にも見えます。だからこそ、見えていても中身に気づけない経路が問題になります。当サイトでも以前、LLMエージェントの隠れ共謀：検知不能な秘密通信の研究で、エージェントがツールを使って秘密通信を自作しうるという別の研究を紹介しました。今回の論文は、その「通信が実際に成立するか」の信頼性を詰めた位置づけになります。
  • 内部不正・意図的な持ち出し：手口として一般化するにはまだ手間がかかりますが、「持ち出しの痕跡が文面に残らない」という性質は、退職前の情報持ち出しのような場面で厄介です。

関連して、複数のAIを組み合わせたときに安全性が崩れる問題はマルチエージェントAIの盲点｜連結で崩れる安全性、出力を監視する側の限界はLLMガードレールの限界：安全性トリレンマ論文を読むでも扱っています。

現場目線の所感

正直に言うと、この研究を読んで最初に浮かんだのは「うちの環境で、社外に出ていくテキストの量をそもそも把握できているだろうか」という不安でした。ファイルの持ち出しは可視化できていても、チャットやAIツールの入出力として流れていくテキストは、ログが取れていても誰も見ていないという状態が、多くの現場の実態ではないでしょうか。

もうひとつ引っかかったのは、今回の論文が突いたのが「送信側の基準で成功と数えていた」という評価の甘さだった点です。攻撃側の研究ですら、実態に合わない指標で長らく自己採点していたわけです。守る側の私たちも、資産台帳と実機の差、ポリシー適用率と実効性の差など、都合のいい基準で「できている」と数えていないかは、定期的に疑ったほうがよさそうです。ここは限られた人員では手が回りにくいところで、耳の痛い話でもあります。

情シスはどうすべきか

この段階で専用の対策製品を探すのは早すぎます。やるべきことは、文面の中身を当てにしない層で締めるという、地味な基本の再確認です。

  • 出口（egress）を絞る：どのAIサービス・どの外部宛先に業務データが出ていくかを許可制で把握する。検知が難しい以上、そもそも通れる経路を減らすほうが確実です。
  • AIエージェント間の通信を記録に残す：内容を判定できなくても、「いつ・どのエージェントが・どこへ・どれだけ」の記録があれば、事後の追跡は成立します。
  • 生成AIの業務利用ルールを、入力だけでなく出力にも広げる：多くの社内ルールは「入れてはいけないもの」に集中しがちですが、出ていく側の宛先管理が抜けやすいところです。
  • 利用者への啓発：技術で止めきれない領域だからこそ、ここが効きます。IPAの対策のしおりは、エンドユーザ向けの説明資料としてそのまま使えます。

組織全体の底上げから始めるなら、IPAの中小企業の情報セキュリティ対策ガイドラインが出発点として実用的です。AIエージェント自体の弱点整理はAIエージェントのセキュリティ 研究が示す4つの弱点も参考にしてください。

限界・留意点

  • 査読前のプレプリントです。2026年8月1日にarXivへ投稿されたもので、第三者による検証を経ていません。結果は今後変わりうるものとして読んでください。
  • 実験は特定のモデル（Llama-3.1-8Bなど）と3種類のデータセットでの結果です。あらゆるモデル・用途で同じ性能が出るとは限りません。論文自身も、評価用の設定やしきい値はドメインごとに調整が必要としています。
  • 1本の論文から「もう検知は不可能」と一般化するのは行き過ぎです。検知器側の研究も並行して進んでおり、通信量や宛先といった文面以外の手がかりを使う防御は依然として有効です。
  • 本記事は仕組みの概念的な説明にとどめており、実装手順は扱いません。

まとめ

  1. LLMが生成する自然な文章に秘密情報を埋め込む技術で、受信側での復元を不安定にしていた「トークン化のズレ」が解消され、復元率100%が報告されました（査読前）。
  2. 専用の検知器でも正解率は約60%と、当てずっぽうに毛が生えた水準です。キーワードやパターンに頼るDLP・メールフィルタは、この経路を原理的に検知できません。
  3. 外から破られる脆弱性ではなく、内側で使われたときに監視をすり抜けるリスクです。対策は文面の判定ではなく、出口の許可制・通信記録・利用ルールという基本層で締めるのが現実的です。

出典

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