tengu_heron_brookとは — Claude Codeのプロンプトを書き換えるフラグ

tengu_heron_brookは、サーバーから配信されるGrowthBookのフィーチャーフラグの名前です。v2.1.150から、この値がClaude Codeのシステムプロンプトへセクションとして書き込まれると報告されました。取得はDISABLE_GROWTHBOOK=1などの環境変数で止められますが、止めると失う機能もあります。

Claude Code v2.1.150のリリースノートには「内部基盤の改善のみ(ユーザー向けの変更なし)」としか書かれていません。公開の翌日に上がったGitHub Issue #62061が、このバージョンで新たに有効になった仕組みを報告しました。

Anthropicはこれをシステムプロンプトの品質実験だと説明し、オプトアウト用の環境変数も案内しました。ただしリリースノートにこの挙動への言及はありません。以下では、報告の中身、Anthropicの回答、自分の環境で実際に影響を受けるかどうかの切り分けを、環境変数リファレンスとCLIリファレンスの記述と突き合わせて見ていきます。

報告された書き込みの経路

issueの報告者は、v2.1.150のバイナリにnAAという関数(minify後の名称)が追加されたと主張しています。この関数は2つのネットワーク経由のデータソースから任意の文字列を読み取り、システムプロンプトのセクションとして登録するというものです。

該当スロット自体は以前から存在し、ant_model_overrideというスタブが常にnullを返していたと報告は述べています。v2.1.150が、そこに実際のロジックが入った最初のバージョンだったという主張です。issueにはarea:securityのラベルが付いています。

GrowthBookはこの一件以前から、Claude Codeの挙動をアカウント単位で変える経路として使われてきました。Remote Controlのアイドル切断を調べた別の報告でも、GrowthBookが配信するタイマー値がアカウントごとに違うことが原因の一部でした。フィーチャーフラグ経由の値配信は目新しい仕組みではありません。今回問題になったのは、配信対象がシステムプロンプトの内容そのものに広がった点です。

発表から回答までの一日

changelogの日付とissueの時刻を並べると、報告から回答、クローズまでが一日のうちに終わっています。issueの本文は、過去の関連報告として実験的機能の透明性を求めるissueと、無許可のサーバー側フィーチャーフラグ配信を指摘するissueの2件を挙げており、同種の懸念は今回で3件目です。

Anthropicの回答 — システムプロンプト実験のための機構

回答の趣旨は、システムプロンプトの変更を全ユーザーへ展開する前に品質への影響を評価する実験がある、というものです。品質の後退を検知・防止する目的だとしています。

オプトアウトの方法としてCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1とDISABLE_GROWTHBOOK=1が挙げられました。どちらも公式の環境変数リファレンスに実在し、フィーチャーフラグの取得を止めます。

export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
export DISABLE_GROWTHBOOK=1

セキュリティ面の回答は、信頼できないプロキシ経由でClaude Codeを使わないことを勧める内容でした。管理下にないプロキシは、bootstrapリクエストに限らずどのAPIリクエストでもシステムプロンプトを書き換えられるため、攻撃面は同じだという説明です。

別のコメントは、この説明が論点をずらしていると反論しています。問題はネットワーク経路ではなく、エージェントのコンテキストウィンドウがサーバー制御の内容の書き込み先になっていること自体だという主張です。クライアント側に何が注入されたかを示すログが残らず、利用者が事後に内容を確かめる手段がありません。

Anthropicが「品質実験」と呼ぶ枠組みと、外部から見て「監査できない書き換え」に映る構造は、同じ挙動の両面です。どちらの見方でも、書き込まれた文字列が公開されないという点は変わりません。

自分の環境は影響を受けるのか

環境変数リファレンスの「Features that need feature-flag fetching」節は、フラグの取得を止める条件を列挙しています。ここから、利用環境ごとの状況が読み取れます。

報告者の環境はAnthropic APIに直結したOpusモデルで、表の1行目に当たります。

止める方法として、公式ドキュメントが挙げる環境変数は2つにとどまりません。次の4つのいずれかを設定したセッションでも、フラグの取得はスキップされます。

• DISABLE_GROWTHBOOK
• DISABLE_TELEMETRY
• DO_NOT_TRACK
• CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC

データ利用のページは、DISABLE_TELEMETRYとCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICがフラグの評価も止めると書き、DISABLE_ERROR_REPORTINGには同じ効果がないと明記しています。テレメトリを切る目的で既に設定している環境では、フラグの取得も止まっていることになります。

設定値には落とし穴があります。CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICは、0やfalseを入れても通信の無効化が続きます。リファレンスはこれを、ほとんどのオン・オフ変数と違う点として太字で注意しています。再び許可するには変数自体を未設定にします。DISABLE_GROWTHBOOKは逆で、0やfalseなら取得が続きます。

キャッシュは環境変数で消えない

報告者は、無防備な状態で一度でも起動していれば、ディスクにキャッシュされた値がその後も読み込まれると指摘しています。環境変数が止めるのは新しい取得だけ、という見方です。

公式のchangelogには、フラグのキャッシュがディスクに残ることを前提にした修正が2件あります。

• v2.1.70: 起動初期に読んだフラグがディスクキャッシュを更新せず、古い値が複数セッションにわたって残る問題の修正
• v2.1.214: 不正な形式のフラグ値が、キャッシュ済みのフラグを消してしまう問題の修正

この2件の修正から、フラグの値がセッションをまたいでディスクに保持されることが読み取れます。

オプトアウトと引き換えになる機能

取得を止めると、フラグ経由で有効になる機能が使えなくなります。環境変数リファレンスが挙げる項目は次のとおりです。

• /auto-mode-setupによるauto modeの環境エントリの下書き
• Remote Control(CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICかDISABLE_GROWTHBOOKで止めた場合)
• 手元のマシンを越えたセッション間メッセージング(同じマシン内は動作します)
• claude importコマンドと/import
• /skill-doctorとそのレポート
• claude.aiアカウントで有効にしたスキルとプラグインの、ターミナルへの同期
• advisorツール
• artifactへのコメントの読み書き
• 他の組織が公開したartifactの読み取り
• Claude-drafted feedback

ほかにも、貼り付けた長文を「貼り付けられたテキスト」として扱う挙動や、入力スキーマがAPIに拒否されるMCPツールの除外、Windowsでの既定のPowerShellツールなど、挙動の既定値が変わる項目が並びます。

監査証跡の欠如を避けるために環境変数を設定すれば、これらの機能を手放します。逆に機能を使い続けるなら、書き込まれる内容を見られない状態を受け入れます。どちらを選ぶかは、扱うリポジトリの機密度とRemote Controlなどへの依存度で決まります。

会話の途中でプロンプトは書き換わるのか

もう一つの切り分けは、システムプロンプトがいつ組み立てられるかです。CLIリファレンスによれば、Claude Codeは会話の最初のリクエストでシステムプロンプトを組み立て、そのセッションに記録します。以降のリクエストは、会話が圧縮(コンパクト)されるまで、この記録を毎回そのまま送ります。--resumeや--continueで会話に戻った場合も同じです。

この記録の動作は、--system-prompt-snapshotフラグで切り替わります。v2.1.289でclaude --helpを実行すると、次のように出力されます。

--system-prompt-snapshot <on|off>     Record the system prompt once per
                                      conversation and reuse it verbatim on
                                      every request and resume. on (the
                                      default): the prompt is rendered on the
                                      conversation's first request — a
                                      --system-prompt or
                                      --append-system-prompt included — sent,
                                      and recorded; every later request and
                                      resume sends the record as-is, even when
                                      a later launch passes different text,
                                      until the conversation is compacted.
                                      off: never record; the prompt is
                                      rendered fresh every request (for
                                      iterating on prompt text). No effect
                                      where system-prompt recording is not
                                      yet enabled. (choices: "on", "off")

既定はonです。offにすると毎回組み立て直すので、--append-system-promptの文面を試行錯誤するときに使います。cloud sessions以外で--bareを付けて起動した場合は、--system-prompt-snapshot onを渡さない限り記録されません。v2.1.268より前は、フラグを取得しないセッションでプロンプトを毎回組み立て直していました。Bedrock、Google Cloud's Agent Platform、Foundry経由もこれに含まれ、このフラグは効きませんでした。

公式ページ同士には食い違いがあります。CLIリファレンスは--system-prompt-snapshotに「v2.1.257以降が必要」と書いています。一方、changelogで--system-prompt-snapshot offの追加が載っているのはv2.1.267の項です。どちらの番号を基準にするかで、手元のバージョンで使えるかの判断が変わります。CLIリファレンスには、v2.1.265より前はシステムプロンプト系のフラグを1つでも渡すと、onを明示しない限り記録も止まっていたという記述もあります。

CLIリファレンスのこの節は、サーバー側のフラグ由来の文字列が記録の対象に含まれるかどうかには触れていません。記録の仕組みが示しているのは、利用者が渡したテキストを含むプロンプト全体が、一度組み立てられたあとは会話の中で固定されるという点までです。

システムプロンプトを変える他の経路との違い

Claude Codeには、利用者自身が起動時にシステムプロンプトを変える経路もあります。--append-system-promptや--system-promptフラグです。append-system-promptとsystem-promptの違いで扱っているように、こちらは起動コマンドに書いた文字列がそのまま反映されます。

攻撃者が外部コンテンツに指示を埋め込む一般的な意味でのプロンプトインジェクションとは、脅威モデルが異なります。今回の論点は、通知や同意なしに、配信する側が内容を差し込める点です。Coworkで議論される、信頼境界の外から来る攻撃とも別の話になります。

利用者側の記録手段について、スレッドの後半では2つの案が出ました。環境変数の設定漏れをセッション開始時に知らせるSessionStartフックと、HTTPSプロキシでリクエストを記録する方法です。前者は設定状態を、後者は送られた内容そのものを残します。どちらもAnthropic公式の機能ではなく、スレッド上での提案にとどまります。

まとめ

tengu_heron_brookは、Anthropicがシステムプロンプトの品質実験のためと説明した仕組みです。実際にどの文字列が配信され、どの範囲のユーザーが対象になったかは、スレッドの中で示されませんでした。

判断の軸は、トレーサビリティの要件と機能の喪失です。Anthropic API直結でシステムプロンプトの再現性を求める環境だけが、機能を失ってでも取得を止めるかどうかを考えることになります。v2.1.150の変更内容はv2.1.150のリリースノートで確認できます。