Claude Codeのサーバー側プロンプトインジェクション — tengu_heron_brookの正体
v2.1.150で有効化されたtengu_heron_brookフィーチャーフラグがシステムプロンプトを書き換える仕組みと、Anthropicの説明、オプトアウトの限界を一次情報からまとめます。
Claude Code v2.1.150のリリースノートには「内部基盤の改善のみ(ユーザー向けの変更なし)」としか書かれていません。公開の翌日、GitHub Issue #62061がこのバージョンで新たに有効化された仕組みを報告しました。サーバーから配信されるフィーチャーフラグの値を、そのままシステムプロンプトへ書き込む機能です。Anthropicはこれをシステムプロンプトの品質実験だと説明し、オプトアウト用の環境変数も存在します。ただしリリースノートにこの挙動への言及はありませんでした。
tengu_heron_brookが書き込む仕組み
issue報告によると、v2.1.150のバイナリにはnAAという関数(minify後のソースでの名称)が追加されています。この関数は2つのネットワーク経由のデータソースから任意の文字列を読み取り、システムプロンプトのセクションとしてそのまま登録します。
| データソース | 内容 | 挙動 |
|---|---|---|
Bootstrap API(GET /api/claude_cli/bootstrap) | 内容client_dataフィールド。スキーマ検証はz.record(z.unknown())(任意のJSONオブジェクトを許容)にとどまる | 挙動値をディスクにキャッシュ |
GrowthBookフィーチャーフラグtengu_heron_brook | 内容60秒ごとにバックグラウンドで再取得 | 挙動値をディスクにキャッシュ |
この値はanti_verbosity・thinking_guidance・action_cautionなど、Claude Codeが標準搭載するシステムプロンプトのセクションと同格で登録されます。シェル操作の権限を持つエージェントの指示内容が、通知も同意確認もなく書き換わる経路です。
該当スロット自体は以前から存在していました。ant_model_overrideという名前のスタブで、それまでは常にnullを返していたといいます。v2.1.150は、このスロットに実際のロジックが入った最初のバージョンだったとissueは指摘しています。issueにはarea:securityのラベルが付いています。
GrowthBookはこの一件以前から、Claude Codeの挙動をアカウント単位で変える経路として使われてきました。Remote Controlのアイドル切断を調べた別の報告でも、GrowthBookが配信するタイマー値がアカウントごとに違うことが原因の一部になっていたと指摘されています。フィーチャーフラグ経由の値配信そのものは目新しい仕組みではなく、今回問題になったのは配信対象がシステムプロンプトの内容そのものに広がった点です。
issueの本文は、過去の関連報告として2件のissue番号を挙げています。実験的機能の透明性を求める報告と、無許可のサーバー側フィーチャーフラグ配信を指摘する報告です。同種の懸念が今回で3件目だったことになります。issue自体は7日間新しい動きがなかったことを理由に、2026年7月29日にGitHub Actionsのbotが自動でロックしています。
誰でも同じ結果を確認できる検証手順
この報告の特徴は、バイナリの逆コンパイルではなく文字列抽出だけで再現できる点です。報告者はnpm packでLinux版パッケージを取得し、stringsコマンドで実行ファイル内の文字列を展開しています。
npm pack @anthropic-ai/claude-code-linux-x64@2.1.150 --pack-destination /tmp
tar xzf /tmp/anthropic-ai-claude-code-linux-x64-2.1.150.tgz
strings package/claude | grep -oP 'function nAA\(\)\{[^}]+\}'
strings package/claude | grep -oP '.{0,60}heron_brook.{0,60}'1つ目のコマンドはnAA関数がclientDataCacheとGrowthBookから値を読み取る実装を、2つ目のコマンドはその値がシステムプロンプト構築用の配列に登録されている箇所を、それぞれ抽出します。同じ手順をv2.1.149のパッケージに対して実行すると、heron_brookという文字列自体が存在せず、ant_model_overrideは常にnullを返す実装のままだったといいます。
issueの報告環境は、Anthropic APIに直結したOpusモデル、OSはLinuxでした。この構成は後述する「通常のAPI直結セッション」に当たり、フィーチャーフラグ取得が既定で有効な範囲です。Bedrock・Vertex・Foundry経由の利用であれば、ホスト側が追加の設定をしない限り同じ現象は基本的に起きない計算になります。
Anthropicの回答 — システムプロンプト実験のための機構
報告から数時間後、Anthropic側のアカウントがコメントで経緯を説明しています。システムプロンプトの変更を全ユーザーへ展開する前に、品質への影響を評価するための実験だということです。品質の後退を検知・防止する目的だとしています。
オプトアウトの方法としてCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1とDISABLE_GROWTHBOOK=1の2つが挙げられました。どちらも公式の環境変数リファレンスに実在し、フィーチャーフラグの取得そのものを止めます。
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
export DISABLE_GROWTHBOOK=1セキュリティ面については、信頼できないプロキシ経由でClaude Codeを使わないことを推奨する、という立場も示されました。管理下にないプロキシは、bootstrapリクエストに限らずどのAPIリクエストでもシステムプロンプトを書き換えられるため、攻撃面としては同じだという説明です。
別のコメントは、この説明が論点をずらしていると反論しています。プロキシ経由の攻撃面が変わらないのは事実だとしても、今回問題になっているのはネットワーク経路の話ではありません。エージェントのコンテキストウィンドウが、サーバー制御のコンテンツへの書き込み対象になっている点そのものだという主張です。クライアント側には何が注入されたかを示すログが一切残らないため、利用者が事後に内容を確認する手段がありません。Anthropicが「品質実験」と呼ぶ枠組みと、外部から見て「監査できない書き換え」に映る構造は、同じ挙動の両面と言えます。
オプトアウトが効かない範囲
公式の環境変数リファレンスを見ると、フィーチャーフラグ取得を止める効果は挙動全体の一部にとどまることが分かります。
| 利用環境 | フィーチャーフラグ取得 | 追加対応 |
|---|---|---|
| 通常のAPI直結セッション | フィーチャーフラグ取得既定で有効 | 追加対応環境変数2つでオプトアウト可能 |
| Bedrock / Vertex / Foundry経由 | フィーチャーフラグ取得既定でスキップ(ホストがCLAUDE_CODE_PROVIDER_MANAGED_BY_HOSTを設定しない限り) | 追加対応基本的に不要 |
| Claude apps gateway経由 | フィーチャーフラグ取得取得しない | 追加対応不要 |
| オプトアウト前に一度でも起動したセッション | フィーチャーフラグ取得ディスクにキャッシュ済みの値を再利用 | 追加対応オプトアウト後も古いキャッシュ値は読み込まれ続ける |
オプトアウトには副作用もあります。公式の環境変数リファレンスは、フィーチャーフラグの取得を止めた状態で使えなくなる機能を具体的に列挙しています。
- AGENTS.mdをプロジェクト指示として読み込む機能(CLAUDE.mdのみになる)
- Pro・Max・Teamプランでauto modeを既定で起動する機能
- VS Code拡張が起動時のパーミッションモードを設定ファイルから読む機能
- Remote Control
- 手元のマシンを越えたセッション間メッセージング
claude importコマンドと/import/skill-doctorとそのレポート- advisorツール
- artifactへのコメントの読み書き
つまりオプトアウトは、システムプロンプトへの書き込みを止めるだけでなく、Claude Codeの機能面にも及びます。監査証跡の欠如を避けるために環境変数を設定すると、これらの機能を手放すことになる、というトレードオフです。
システムプロンプトを変える他の経路との違い
Claude Codeにはシステムプロンプトを変更する経路がもう一つあります。起動時に--append-system-promptや--system-promptフラグを渡す方法で、こちらは利用者自身が明示的に指定する変更です。append-system-promptとsystem-promptの違いで扱っているように、この経路は起動コマンドに書いた文字列がそのまま反映されるため、何が入っているかは常に利用者の手元にあります。
今回のissueが指摘したのは、利用者が何も指定していなくても、サーバー側の判断だけでシステムプロンプトのセクションが差し替わる経路です。攻撃者が外部コンテンツに指示を埋め込む一般的な意味でのプロンプトインジェクションとは脅威モデルが異なります。通知や同意なしにオペレーター自身が内容を差し込める点が論点でした。Coworkで議論される、信頼境界の外側から来る攻撃とも別の話です。
2つの経路の一番の違いは、確認手段の有無にあります。--append-system-promptや--system-promptは渡した文字列がそのままシステムプロンプトに入ります。何を渡したかは、利用者の手元のコマンド履歴や設定ファイルに残ります。一方でtengu_heron_brookの値はネットワーク経由で配信されディスクにキャッシュされるだけで、利用者が中身を直接確認する公式な手段は用意されていません。この報告はHacker NewsやRedditでも取り上げられ、Claude Codeのissueトラッカーの外でも話題になりました。
まとめ
tengu_heron_brookはマルウェアでも第三者による侵入でもなく、Anthropicが認めた品質実験の仕組みです。ただし、リリースノートの「内部基盤の改善のみ」という一文だけでは、システムプロンプトが動的に書き換わるという挙動そのものは伝わりません。監査証跡や通知の仕組みがないことが、issueで指摘された核心でした。
一方で、tengu_heron_brookに実際どのような文字列が設定されていたか、対象になったユーザーの範囲がどこまでだったかは、issueのスレッド内では明らかになっていません。Anthropicは実験の目的を説明しましたが、注入された具体的な文言そのものは公式には公開されないままです。
エンタープライズやコンプライアンス要件のある環境でトレーサビリティを重視する場合、v2.1.150のリリースノートだけでなく、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICとDISABLE_GROWTHBOOKの挙動、そしてキャッシュが残る点を把握しておく価値があります。