8月11日、Alexander Panfilovら8名の研究者が「Stealing Reasoning Traces from Proprietary LLM APIs」と題した論文を公開した。Anthropic・OpenAI・Googleが採用している「暗号化された推論トレース」に構造的脆弱性が存在し、暗号を「解読」しなくても内部の思考過程を丸ごと抽出できることを実証した研究だ。
攻撃の巧妙さは「暗号の強度を破る」のではなく「設計上の前提を突く」点にある。そして研究チームは理論にとどまらず、GitHubなどの公開リポジトリから実際に315,320件の推論ブロックをスクレイピングし、その中から個人識別情報367件・認証情報182件を回収している。これは現実の被害として受け止める必要がある。
背景：推論を「隠す」ための設計が標的になった
ChatGPTのo1/o3系やClaude 3.7 Sonnetなど、近年の推論特化型LLMは、回答を生成する前にチェーン・オブ・ソート（CoT：Chain-of-Thought）と呼ばれる内部推論ステップを踏む。このステップは知的財産保護や情報漏洩防止の観点からユーザーには非公開とされることが多く、各プロバイダーは推論トレースを暗号化されたテキストブロックとしてクライアントに返却する設計を採用している。
この設計で見落とされていたのが「暗号化ブロックをどこで保持するか」という問題だ。各プロバイダーの実装では、サーバーではなくクライアント側に暗号化ブロックを返却し、次のリクエスト時にそのまま渡させる方式が取られている。この「クライアントに丸投げ」するアーキテクチャが、今回の攻撃の根幹にある。
核心：暗号化ブロックは「モデルをまたいで使い回せる」
研究チームが発見した脆弱性はシンプルかつ深刻だ。暗号化された推論ブロックは、同一プロバイダーのエコシステム内であれば、異なるセッション・ユーザー・モデルをまたいで互換・交換可能である。暗号の強度の問題ではなく、ブロックが「どのコンテキストでも受け付けられてしまう」という設計レベルの欠陥だ。
この互換性を利用した攻撃手順は以下のとおりだ：
- 攻撃対象の高性能モデル（例：Claude 3.7 Sonnet）から暗号化済み推論ブロックを取得する
- 同プロバイダーの、ガード機能が弱い低性能モデルにそのブロックを注入する
- 弱いモデルに推論ブロックを平文でデコード・出力させる
高性能モデルそのものをジェイルブレイクする必要がなく、弱いモデルを「デコーダー」として悪用するという構造が巧妙だ。研究チームはこの手法をAnthropicのClaude、OpenAIのGPTシリーズ、GoogleのGeminiの3社に対して実証している。
4つの攻撃ベクター
この脆弱性から派生する攻撃は4種類に整理されている。
① 反蒸留（Anti-Distillation）機構の回避
モデルの推論トレースを外部に漏らさないための保護機構を迂回し、プロプライエタリモデルの推論過程を抽出できる。抽出した推論データをモデル蒸留（大きなモデルの知識を小さなモデルに移転する手法）の訓練データとして悪用することが可能だ。
② 大規模な個人情報・認証情報の漏洩
GitHubなどの公開リポジトリから315,320件の推論ブロックをスクレイピングし、デコードした結果、367件の個人識別情報（PII）と182件のクレデンシャル情報を回収した。開発者がセッションログを公開する際、暗号化ブロックの中身を確認しないままアップロードするケースが多いことが露呈した形だ。
③ 拒否応答の裏にある有害情報の露出
モデルの最終出力が悪意あるリクエストを安全に拒否している場合でも、推論トレース内部に危険な情報が含まれているケースがある。暗号化ブロックを復号することで、その内容が表に出る。
④ 不可視のプロンプトインジェクション
悪意あるペイロードを暗号化ブロックの中に埋め込み、エージェントの動作を汚染する攻撃が可能になる。暗号化ブロックの内容はユーザーや管理者から見えないため、検知が極めて困難だ。
提案されている対策
論文ではResponsible Disclosure（協調的脆弱性開示）の手続きを経た上で、以下の緩和策が提案されている：
- 暗号化ブロックをクライアントに返却する設計をやめ、サーバーサイドで保持する
- セッションや用途をまたいだブロックの再利用を防ぐ暗号化設計の採用
- 推論ブロックへのコンテキスト束縛（特定セッションID・ユーザーへの紐付け）
根本的な修正は「暗号化の強化」ではなく「クライアントに渡す設計そのものをやめること」にある点が重要だ。各プロバイダーが対応を完了するまでの間、開発者側でできることは限られるが、少なくともセッションログを公開リポジトリに置く際は暗号化ブロックを除外・マスクすることが急務だ。
エンジニアが今すぐ確認すべきこと
LLMをAPIとして利用し、セッションログを扱うシステムを開発しているエンジニアにとって、今回の研究は他人事ではない。暗号化ブロックを含むログをGitHubや外部サービスに公開している場合、その中身に個人情報やAPIキーが含まれている可能性がある。暗号化されているから安全、という思い込みを改め、ログの公開範囲と内容を今一度確認することを勧める。セキュリティ研究コミュニティではすでにこの論文が広く共有されており、攻撃手法の普及は時間の問題とも見られている。
詳細はStealing Reasoning Traces from Proprietary LLM APIsを参照していただきたい。
