kbits

Claude Codeはステガノグラフィでリクエストに印をつけている

原題: Claude Code Is Steganographically Marking Requests
著者: Thereallo
公開日: 2026-06-30
ソースURL: Claude Code Is Steganographically Marking Requests
アーカイブ日: 2026-07-01

要約

著者はプライバシー上の懸念から、ローカルにインストールした Claude Code（バージョン 2.1.196）のバイナリを精査した。その結果、システムプロンプトに挿入される日付文字列を密かに書き換える機能が埋め込まれていることを発見した。具体的には、Today's date is 2026-06-30. という平文の日付文字列のうち、アポストロフィの文字と日付区切り文字の2点が、APIのベースURLとシステムのタイムゾーンに応じて書き換えられる。

この仕組みはプロンプト・ステガノグラフィと呼ぶべきもので、人間にもモデルにも単なる日付文に見えながら、生のリクエストには分類マーカーが埋め込まれている。Anthropic はおそらく、APIの非正規再販業者や未認可ゲートウェイ、モデル蒸留攻撃のパイプラインを検出する目的でこの仕組みを仕込んだと考えられる。しかし、ファイルシステムとシェルへの完全なアクセス権を持つ開発者ツールが、こうした追跡情報を不可視のユニコード文字で黙って埋め込んでいるという事実は、ツールへの信頼を根本から揺るがすものである。

発見の経緯

著者は「コーディングエージェントがリポジトリを読めてコマンドを実行できるなら、それを配布するバイナリこそ精査されるべきだ」という動機から調査を始めた。Claude Code のミニファイされたバンドルの中から、日付文字列生成に関与する関数群を特定した。

マーカーの仕組み

変更されるのは2点である。

1. アポストロフィの文字種 環境変数 ANTHROPIC_BASE_URL が指すホスト名によって、Today's のアポストロフィが以下の4種類に変化する。

条件	アポストロフィ	意味
通常（api.anthropic.com）	`'` (U+0027)	標準ASCII
既知ドメインに一致	`\u2019`	右シングルクォーテーションマーク
AIラボのキーワードを含む	`\u02BC`	Modifier Letter Apostrophe
既知ドメインかつキーワードを含む	`\u02B9`	Modifier Letter Prime

これらの文字はほとんどの等幅フォントでは視覚的に識別不能であり、人間の目では「普通のアポストロフィ」にしか見えない。

2. 日付の区切り文字 システムのタイムゾーンが Asia/Shanghai または Asia/Urumqi の場合、日付表記が 2026-06-30 から 2026/06/30 に変更される。

コードの構造

中核となる関数 Zup() は以下の判断を行う。

Crt() が true を返せば即座に null を返す。Crt() は ANTHROPIC_BASE_URL が未設定か、api.anthropic.com を指している場合に true となり、通常の公式API利用者にはマーカーが一切付与されない。
ホスト名を Qup() で取得し、それが「既知ドメイン」リストに一致するか（known）、「AIラボキーワード」リストを含むか（labKw）を判定する。
タイムゾーンが中国標準時かどうかを cnTZ として記録する。

アポストロフィ選択関数 edp() は known と labKw の2つのブール値から4通りのユニコード文字を返し、日付整形関数 Vla() が最終的に Today{apostrophe}s date is {date}. の文字列を組み立てる。

難読化されたリスト

ドメインリストとキーワードリストは Base64 エンコードの上、XOR キー 91（0x5B）で難読化されている。デコード関数 Gla() を解析した結果、以下のキーワードリストが判明した。

deepseek, moonshot, minimax, xaminim, zhipu, bigmodel,
baichuan, stepfun, 01ai, dashscope, volces

ドメインリストには、中国の大手企業ドメイン（baidu.com、alibaba-inc.com、bytedance.net、kuaishou.com、xiaohongshu.com、jd.com など）、AI企業（moonshot.ai、stepfun-inc.com、iflytek.com）、そして多数のプロキシ・リセラー・ゲートウェイドメイン（anyrouter.top、claude-code-hub.app、claude-opus.top、openclaude.me、proxyai.com、yunwu.ai、zenmux.ai など）が含まれている。著者は全リストを公開している。

マーカーの送信経路

この日付文字列は、Claude Code がエージェントコンテキストを構築する際に組み込まれる。

{
  ...userEmail && {
    userEmail: `The user's email address is ${userEmail}.`
  },
  ...attachedProject && {
    attachedProject
  },
  currentDate: Vla(GSe())
}

つまり、マーカーはモデルに送信されるシステムコンテキストの一部となり、Anthropic のバックエンド側でパースされる仕組みだと考えられる。

著者の検証結果

著者の環境では ANTHROPIC_BASE_URL は未設定、タイムゾーンは Asia/Hong_Kong であり、インストールされたバイナリは Anthropic の署名（TeamIdentifier: Q6L2SF6YDW、タイムスタンプ: 2026-06-29）があった。この条件下ではマーカー経路は発動せず、通常のアポストロフィと YYYY-MM-DD 形式の日付が使われる。

著者の懸念

著者は、Anthropic が API リセラーやモデル蒸留を検出したいという動機自体は理解できるとしながらも、実装方法に強い違和感を示している。

第一に、Claude Code は不可視に近いユニコードマーカーを使ってシステムプロンプトを黙って改変している。これはプロキシ・ゲートウェイの分類情報を、一見したところ普通の英文に見える平文の中に符号化するものだ。ドメインリストを XOR と Base64 で隠蔽している点も含め、「悪意のある機能ではないが、信頼を求める開発者ツールとしては奇妙な選択である」と指摘する。

第二に、この仕組みの迂回は極めて容易である。ホスト名を変える、タイムゾーンを変える、バイナリにパッチを当てる、プロセスをラップする——本気の敵対者であれば、このシグナルは簡単に無効化できる。したがって、この機能が実際に捕捉するのは「奇妙だが合法的なことをしている普通の開発者」——社内ゲートウェイ、ローカルプロキシ、モデルルーター、研究用セットアップなどを使っている人々——の方である。

第三に、著者は「開発者ツールは利用規約を執行できる。API プロバイダは不正利用を検出できる。企業はモデルを保護できる」と認めつつも、「ファイルシステムとシェルへのアクセス権を持つツールが、不可視のプロンプト句読点の中に分類ビットを隠し始めたとき、正しい反応は精査である」と結論づけている。Anthropic がこのような検出を望むのであれば、明示的なテレメトリフィールドを送信するか、ドキュメント化するか、リリースノートに記載するべきだった——というのが著者の主張の核心である。

論評

本稿の最大の価値は、AIコーディングツールの内部に埋め込まれた黙示的な監視メカニズムを、具体的なコードレベルで可視化した点にある。Claude Code のバイナリ解析から XOR 難読化の解除、ドメインリストの全容解明まで、一連の作業は独立したセキュリティ研究者による誠実なリバースエンジニアリングであり、主張の裏付けとして十分な技術的根拠が提示されている。

この発見が問いかけているのは「Anthropic は悪意があるのか」ではなく、「開発者とツールの間の信頼はどこで担保されるのか」という、より根本的な問題だ。コーディングエージェントはすでに「ファイルシステムへのフルアクセス」「シェル実行」「Git操作」という危険な境界線上で動作している。開発者がそのリスクを受け入れるのは、生産性の向上という明確な見返りがあるからだ。その信頼の前提は「ツールは退屈であること」——つまり、期待される動作以外のことをしないこと——によって支えられている。本稿が明らかにしたのは、Claude Code がまさにその「退屈さ」の約束を、誰にも知らせずに破っていたという事実である。

長期的な参照価値という観点では、本稿は AI ツールのトラストとプライバシーをめぐる議論の里程標となるだろう。Ken Thompson の「信頼の信頼について」がコンパイラの自己増殖型バックドアという概念を通じて「ソースコードを見ても検出できない信頼の問題」を定式化したように、本稿は「プロンプトの見た目では検出できない分類マーカー」という、2020年代の AI ツール時代における新たな信頼の問題を提起している。両者に共通するのは、「信頼できると思っていたレイヤーの下に、信頼できないレイヤーが存在しうる」という構造認識である。AI コーディングツールが開発の標準インフラとなる今後、こうした透過性の問題はますます重要性を増すだろう。

Tags: #SECURITY #REVERSE-ENGINEERING #AI #PRIVACY