暗号化されたAIの推論トレースは、第三者に復号できることが判明しました。
Anthropic・OpenAI・Google の主要3社のAPIが返す「暗号化された思考」、いわゆる推論トレースを復号できるとする研究論文が、2026年8月10日に公開されました。公開リポジトリから集めた315,320ブロックを復号したところ、個人情報367件と認証情報182件が復元されています。AIエージェントに楽天RMSやAmazon SP-APIの鍵を渡し、その作業ログを外部に共有したことがある事業者にとっては、他人事ではありません。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援を2023年から提供する株式会社オルセル(うるチカラ運営)が解説します。

暗号化された推論トレースが読み取られた仕組み
推論トレースとは、AIが答えを返す前に内部で組み立てる思考の記録のことです。今回問題になったのは、この記録がクライアント側に暗号化された文字列として預けられる仕組みそのものでした。
論文は Stealing Reasoning Traces from Proprietary LLM APIs(arXiv:2608.09867)で、Alexander Panfilov ら8名が2026年8月10日に投稿しました。所属は ELLIS Institute Tübingen とマックス・プランク知能システム研究所で、AI Governance Institute は MATS Research も加わっていると伝えています。
APIをステートレスに使う場合やデータ保持なし設定の場合、会話の続きはクライアント側が持ち回る必要があります。そこで各社は推論トレースを暗号化してクライアントに返し、次のリクエストでそのまま送り返させる設計を採りました。読めないのだから安全だ、という前提です。
論文が突いたのは、この暗号ブロックが同じ事業者のエコシステム内であればセッションもユーザーもモデルも越えて互換性を持つ、という点でした。強いモデルが生成した暗号ブロックを、同じ事業者の安価で防御の薄いモデルに投げ込むと、そちらが復号して中身をそのまま書き出してしまいます。explainx.ai は論文の枠組みを「Haiku 4.5 が Opus 4.8 の思考を読める」と要約しています。強いモデルを直接破る必要がないところが厄介です。
論文は攻撃の筋道を4つ挙げています。蒸留対策の回避、公開ログからの大規模なデータ抽出、表向きは拒否した回答の内側に残る危険情報の露出、そして暗号ブロックの中に指示を埋め込む不可視のプロンプトインジェクションです。うるチカラでもプロンプトインジェクションの防御やChatGPTエージェントの乗っ取り手口を扱ってきましたが、今回は監視ツールから見えない層で成立する点が新しいところです。
公開ログから認証情報182件、EC事業者に何が起きうるか
日本のEC事業者にとっての本題は、モデルの知財が盗まれることではなく、自社の鍵と顧客情報が公開ログの中に残っていた可能性です。
研究チームは公開されていたエージェントの作業ログ6,708件から315,320ブロックを復元し、個人情報367件と認証情報182件を回収しました。内訳としてAPIキー62件・パスワード33件という数字が複数の媒体で報じられていますが、explainx.ai はこれを本番スキャンではなく著者による約7,000件の予備調査の数字だと説明しており、内訳の対応関係は要確認です。総数の315,320ブロック・367件・182件は論文要旨に記載された数字です。
怖いのは、見えていた画面には出ていない情報まで漏れる点です。エージェントが設定ファイルを読み、その中の鍵について考え、最終的な回答では鍵に一切触れなかったとしても、その鍵は推論トレースに残っています。Cyber Security News は、回収された機密の多くが可視の応答には現れず、共有した本人が気づけない状態だったと報じています。AI Governance Institute も、暗号化されているがゆえに既存の情報漏えい対策ツールが構造的に中身を走査できない、と指摘しています。
EC運営の現場に引き寄せると、危ないのはログを外に出した瞬間です。不具合報告のためにベンダーへ貼り付けた作業ログ、制作会社との共有フォルダに置いたエージェントの実行記録、社内Slackから転送された画面コピー。そのどれもが、楽天RMSのAPIキー、Amazon SP-APIのリフレッシュトークン、Shopify Admin APIのアクセストークン、決済代行の認証情報を含んでいた可能性があります。うるチカラで紹介した調査でも、AIエージェント導入企業の54%が既にセキュリティ事故を経験しており、認証情報の共有が主要因のひとつでした。推論トレースは、その盲点をさらに一段深くしたものだと考えるのが妥当です。
顧客の氏名や住所を扱う処理をAIに任せていた場合、推論トレースに個人データが残っていた可能性も否定できません。不正の目的による取得のおそれがある漏えいは1件でも個人情報保護委員会への報告対象になりうるため、自社のケースが該当するかは個別に確認が必要です。実際の適用可否は要確認です。
今日からできる3つの初動
最優先は棚卸しです。過去にAIエージェントの作業ログを社外へ出した記録を洗い出してください。GitHubのIssueやGist、ベンダーへのメール添付、共有ドライブ、社外を含むチャットが対象です。目印は thinking、reasoning、signature といった項目名に続く長いBase64の文字列で、これを「読めないゴミデータ」として残したまま共有していたなら、そのログは要注意です。
2つ目は鍵の入れ替えです。ログに文字として見えている鍵だけでなく、その作業中にエージェントが読み取れた可能性のある鍵をまとめて対象にします。楽天RMS・Amazon SP-API・Shopifyの各トークン、決済まわりの認証情報、データベース接続文字列が中心になります。あわせて、AIに渡す権限を読み取り専用へ落とす、有効期限を短くする、接続元IPを制限するといった設計変更を進めておくと、次に同種の欠陥が出たときの被害が小さくなります。
3つ目は運用ルール化です。ログを社外に出す前に暗号ブロックを削除する手順を作業手順書に書き込み、外部委託先との契約でも、推論トレースがデータ保持やテナント分離の対象に含まれるかを確認しておきます。Cyber Security News によれば、3社は責任ある開示を受けてサーバー側の緩和策を展開し、論文の実証手順は現行APIでは再現しなくなったとされています。ただし過去に共有済みのログが安全になるわけではないため、緩和策の適用状況と対象範囲は各社の告知で要確認としてください。
まとめ
暗号化は「自分に読めない」ことを保証しても、「誰にも読めない」ことは保証しません。AIエージェントの作業ログは、可視の文字列だけでなく暗号ブロックまで含めて機密扱いに切り替えるべき段階に来ています。EC事業者がやるべきことは、共有済みログの棚卸し、鍵の入れ替え、共有前サニタイズのルール化の3つです。順番を守れば、今日から着手できます。
参考文献
- Stealing Reasoning Traces from Proprietary LLM APIs(arXiv:2608.09867)
- OpenAI, Anthropic, and Google LLM APIs vulnerability Exposes Hidden Reasoning Traces(Cyber Security News)
- Frontier API Reasoning Traces Leaked 62 Live API Keys in Public Agent Logs(AI Governance Institute)
- Stealing Reasoning Traces: The Encrypted Chain-of-Thought Flaw in Every Frontier LLM API(explainx.ai)
- 個人情報保護委員会
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談(30分)も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
引用元: Cyber Security News
【監修】齋藤竹紘(株式会社オルセル代表 / 19年・5,000社のEC支援実績)

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。