2026-10-03 から 2026-10-07 にかけて公開した五本の記事は、いずれも Claude Code の環境変数ドキュメントに増えた項目を一つずつ扱っている。単独で読むと、六つの無関係なスイッチの追加に見える。五本を同じ机に並べると、追加のほぼ全部が同じ方向を向いていることが分かる。Claude Code が外部へ何かを渡す地点、その地点ごとに置かれた制御だという方向である。本稿はこの筋を一本引き、公式が変数単位で並べているものを、実務で設定し直すときの境界単位と依存順に組み替える。中心に置く主張は、どの構成記事一本にも書いていない。五本を突き合わせて初めて言える。
中心主張：追加は「機能」ではなく「境界の制御」に寄っている
この週に増えた変数を、新機能の追加としてではなく、Claude Code がデータを外部に渡す境界への制御として読むと、六つのうち五つが四つの境界（API とゲートウェイ、部分プロセス、MCP、web）に収まる。例外は一つだけで、それは画面描画の設定である。したがって実務では、ドキュメントの並び順（変数単位）ではなく、境界単位で、かつ依存順で設定を組むべきである。依存順とは、ゲートウェイの縁では輸送層をスキーマ層より先に確認すること、封じ込めの既定を機能トグルより先に決めることを指す。
並べ直し：変数単位から境界単位へ
構成記事を公開日順ではなく、各変数が触れる相手で並べ直すと次のようになる。
- API とゲートウェイの縁（外向き）：gzip 圧縮の停止（2026-10-07 公開、https://note.com/docsfirst/n/n27be75e41ba2）と、構造化出力フィールドの送出停止（2026-10-04 公開、https://note.com/docsfirst/n/n95e2fe8b84e3）。
- 部分プロセスの縁（外向き）：子プロセスの環境からの認証情報スクラブ（2026-10-05 公開、https://note.com/docsfirst/n/nddbd8e2cd0f8）。
- MCP の縁（内向き）：ツール応答のトークン上限（2026-10-06 公開、https://note.com/docsfirst/n/ne8fc2251f29f）。
- web の縁（外向き）：WebFetch の遮断（2026-10-03 公開、https://note.com/docsfirst/n/n2b3fff20dc88）。
- 境界ではない例外：全画面描画（2026-10-04 公開、https://note.com/docsfirst/n/n95e2fe8b84e3）。
ここで一つ、構成記事のどれにも書かれていない区別が見える。境界制御の四つのうち三つは Claude Code が外へ出す側を絞る設定であり、MCP の上限だけが外から戻ってくる側を絞る設定である。各記事はそれぞれ一つの変数を紹介しただけなので、この外向きと内向きの別は単独では現れない。設定を見直すとき、外向きの遮断（送らない）と内向きの上限（受けすぎない）は目的が違うので、同じ机に並べても別の節で扱うのが筋である。
ゲートウェイの縁には二層ある：輸送が先、スキーマが後
二つのゲートウェイ関連変数は、別々の記事（2026-10-04 と 2026-10-07）で三日離れて紹介された。別物として読むと二つの小さなスイッチだが、同じゲートウェイ構成の下では両方が同じ経路に効く。
turn off gzip compression of Claude API, telemetry, and artifact publish request bodies
これはリクエストボディの gzip 圧縮を止める設定である（出典 [1]）。圧縮は HTTP ボディの層、つまり輸送に近い。
stop Claude Code from sending the structured-output output_config.format field
こちらは構造化出力の output_config.format フィールドの送出を止める設定である（出典 [1]）。これはリクエストのスキーマに属する。
ここから依存順が導ける。ゲートウェイがボディを解凍できなければ、その先のスキーマ検証には届かない。つまり圧縮が原因の失敗は、スキーマが原因の失敗より手前で起きる。症状の見分け方として、HTTP 層でのボディ解析エラーや 400 がゲートウェイ側で出るなら、まず圧縮を疑う。リクエスト自体は通るのに構造化出力や未知フィールドでエラーになるなら、output_config.format を疑う。両方を同時に切り替えると、どちらが効いたかの信号を失う。だから両方が候補のときは、輸送層（gzip 停止）を先に当てて経路が通ることを確認し、その上でスキーマ層（output_config.format 停止）を判断する。これは変数が占める層からの推論であり、公式がこの順序を明示しているわけではない。
封じ込めは既定に寄せる：部分プロセスと MCP
部分プロセスの縁は、子プロセスへ渡る環境変数を絞る設定である。
strip credentials from the environments of the subprocesses Claude Code starts
Claude Code が起動する子プロセスの環境から認証情報を取り除く設定である（出典 [1]）。これは外向きの封じ込めで、既定で有効にし、スクラブを外す側（子プロセスが本当に秘密情報を要るとき）を要正当化の例外として扱うのが筋である。
MCP の縁はこれと向きが逆で、外から戻ってくる側の上限である。ツール応答のトークン上限は 2026-10-07 時点で既定 25000 トークンであり、応答が黙って切り詰められているように見えたときに最初に確認する値になる。封じ込めの既定（スクラブ）と受け取りの上限（25000）は、どちらも Claude Code の外周を狭める方向だが、送らないことと受けすぎないことは別の操作なので、別個に点検する。
外向きの遮断：WebFetch
web の縁は、任意 URL への取得を止める遮断弁である。
CLAUDE_CODE_DISABLE_WEB_FETCH Set to 1 to turn off the WebFetch tool
1 を設定すると WebFetch ツールを無効化する（出典 [1]）。これは外向きの egress 遮断であり、他の外向き制御（gzip、output_config.format、部分プロセスのスクラブ）と同じ机で、同じタイミングに決めるべき設定である。構成記事では独立した一本として紹介されたが、外向きという共通軸で見ると、単独で後回しにする種類の設定ではない。
例外は一つ：fullscreen
残る一つ、全画面描画の有効化（2026-10-04 公開、https://note.com/docsfirst/n/n95e2fe8b84e3）は、2026-10-07 時点で research preview として提供される表示設定であり、外部との境界ではなくローカルの描画に属する。これは境界制御の仲間ではない。例外が一つあることは、残り五つが同じ方向（境界制御）に寄っているという観察を弱めない。設定を見直すときの思考の箱としても、この一つを他の五つと同じ箱に入れないほうがよい。
明日からの設定：境界ごと、依存順
- 環境変数を、ドキュメントの並び順やアルファベット順ではなく、触れる相手（API とゲートウェイ、部分プロセス、MCP、web）で束ね直す。
- ゲートウェイの下では、圧縮の停止を先に当てて経路が通ることを確認し、通ってから output_config.format の停止を判断する。両方を同時に切り替えない。
- 症状の切り分け：HTTP 層のボディ解析エラーや 400 は圧縮を先に疑う。リクエストは通るのに構造化出力でエラーなら output_config.format を疑う。
- 部分プロセスの縁は認証情報スクラブを既定とし、スクラブを外す構成を要正当化の例外として扱う。
- MCP の上限（2026-10-07 時点で既定 25000 トークン）を、応答が切り詰められて見えたときの最初の確認先として覚えておく。
- WebFetch の遮断は、他の外向き制御と同じタイミングで決める。単独で後回しにしない。
- 全画面描画は境界制御ではないので、他の五つと同じ点検の箱に入れない。