2026年4月版 Claude Code 環境変数チートシート ─ 劣化対策からOpus 4.7対応まで

Last updated at 2026-04-17Posted at 2026-04-17

はじめに

Claude Code は、環境変数 1 行で挙動が大きく変わるツールです。

たとえば CLAUDE_CODE_EFFORT_LEVEL=xhigh や task_budget を指定するだけで、3 月ごろから話題になった「急に頭が悪くなった」体感が、筆者の環境では目に見えて改善しました。一方で、設定を間違えると思考トークンが跳ねて、月末の請求を見てため息をつくこともあります。

なお CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING は Opus 4.6 / Sonnet 4.6 専用の変数で、Opus 4.7 では無効です。公式ドキュメントでも「Opus 4.7 always uses adaptive reasoning」と明記されており、4.7 環境で設定しても挙動は変わりません。Opus 4.7 で思考量を制御したい場合は CLAUDE_CODE_EFFORT_LEVEL=xhigh|max や task_budget を使います。

公式ドキュメントや Changelog、ブログ記事に散らばった環境変数を、2026 年 4 月時点の Claude Code v2.1.x（Opus 4.7 GA 直後）を想定した保存版としてまとめました。

この記事で触れる内容は次のとおりです。

主要環境変数の早見表
シーン別の推奨プロファイル（コスト / 品質 / 長時間エージェント / 監視）
「max と high どちらを選ぶか」を決める判断フロー
チーム運用で悩みがちな .claude/settings.json と .claude/settings.local.json の書き分け
設定したのに効かない、よくあるハマりどころ

環境変数の解釈は CLI のバージョン、プラン（Pro / Max / Team）、利用チャネル（Anthropic API / Bedrock / Vertex AI）によって差があります。本記事は筆者が 2026-04-17 時点で Claude Code v2.1.111+ と Opus 4.7 を使って確認した範囲の情報です（xhigh effort や /ultrareview は v2.1.111 で追加）。公式挙動と異なる場合は、公式ドキュメントと Changelog を優先してください。

主要環境変数の早見表

まずは、2026 年 4 月時点で押さえておきたい変数を 1 つの表にまとめます。

変数名	取りうる値	役割	Opus 4.7 での扱い	備考
`CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING`	`0` / `1`	Adaptive Thinking（思考量自動調整）を無効化	4.7 では無効（常に adaptive reasoning）	Opus 4.6 / Sonnet 4.6 専用。3 月劣化騒動の処方箋として 4.6 系で推奨
`CLAUDE_CODE_EFFORT_LEVEL`	4.7: `low` / `medium` / `high` / `xhigh` / `max`（5段階） 4.6 / Sonnet 4.6: `low` / `medium` / `high` / `max`（4段階、xhigh なし）	思考量（effort）のデフォルト	`xhigh` が 4.7 で追加（5段階）	4.6 系で `xhigh` 指定時は `high` にフォールバック（エラーではない）
`ANTHROPIC_API_KEY`	`sk-ant-...`	Anthropic API の API キー	共通	Anthropic 直接契約で利用
`ANTHROPIC_AUTH_TOKEN`	任意のトークン	OAuth または代替認証トークン	共通	ブラウザログイン連携や社内プロキシで利用する場面あり
`ANTHROPIC_MODEL`	`claude-opus-4-7` 等	デフォルトモデルを固定	共通	セッション内で `/model` で切替可能
`CLAUDE_CODE_SUBAGENT_MODEL`	任意のモデル ID	サブエージェントが既定で使うモデル	共通	親と分離してコスト最適化できる
`CLAUDE_CODE_MAX_OUTPUT_TOKENS`	数値（例: `32000`）	1 ターンの最大出力トークン	4.7 は 128K まで対応	-
`DISABLE_TELEMETRY`	`0` / `1`	使用状況テレメトリ送信を無効化	共通	社内規程で外部送信を禁じるケース向け
`DISABLE_COST_WARNINGS`	`0` / `1`	コスト上限の警告ダイアログを抑止	共通	Routines や自動化で邪魔になる場合のみ
`HTTPS_PROXY` / `HTTP_PROXY`	`http://host:port`	API 通信を通すプロキシ	共通	社内ネットワーク越え
`NO_PROXY`	カンマ区切りドメイン	プロキシ除外ドメイン	共通	`localhost,127.0.0.1` は入れておくと安全
`CLAUDE_CODE_USE_BEDROCK`	`0` / `1`	Amazon Bedrock 経由に切替	共通	`AWS_REGION` 等 AWS 認証も合わせて必要
`CLAUDE_CODE_USE_VERTEX`	`0` / `1`	Google Cloud Vertex AI 経由に切替	共通	`ANTHROPIC_VERTEX_PROJECT_ID` 等の指定が必要
`ANTHROPIC_VERTEX_PROJECT_ID`	GCP プロジェクト ID	Vertex AI のプロジェクト指定	共通	`CLAUDE_CODE_USE_VERTEX=1` と併用
`AWS_REGION`	`us-west-2` 等	Bedrock のリージョン	4.7 は提供リージョンが限定	-

環境変数名は公式ドキュメントの表記に合わせています。Claude Code は開発ペースが速く、マイナーバージョンで新変数が増えることが多いので、自分の環境で動かない場合は claude --help や claude doctor で最新仕様を確認してください。

Adaptive Thinking と Effort のざっくり整理

Adaptive Thinking は「タスクに応じて思考量を自動調整する仕組み」です。2026-02-05 にデフォルト有効化され、2026-03-04 にデフォルトの effort が high から medium に下がったことで、体感として劣化を感じたユーザーが多かったと報じられています（VentureBeat / Fortune ほか）。

Anthropic の Claude Code 開発責任者 Boris Cherny 氏も「Adaptive Thinking が一部のターンで推論トークンをゼロに割り当てていた」と認めており、モデルごとに処方箋が分かれます。

Opus 4.6 / Sonnet 4.6 を使っている場合（DISABLE_ADAPTIVE_THINKING が有効に効く）:

export CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1
export CLAUDE_CODE_EFFORT_LEVEL=max   # あるいは high（4.6 系に xhigh はない）

Opus 4.7 を使っている場合（4.7 は常に adaptive reasoning で、DISABLE_ADAPTIVE_THINKING は効かない）:

# 4.7 では DISABLE_ADAPTIVE_THINKING は設定しても無視される
export CLAUDE_CODE_EFFORT_LEVEL=xhigh   # または max。task_budget による明示指定も可
export ANTHROPIC_MODEL=claude-opus-4-7

筆者の環境では、4.7 系では xhigh + 明示的な task_budget 指定で、体感の劣化はほぼ解消しました。コストと相談のうえで high や medium に下げる選択もあるため、後半の「使用シナリオ別」を参考にしてください。

使用シナリオ別の推奨プロファイル

1. コスト重視（ライトユーザー / 個人プロジェクト）

「毎日使うけれど、請求額は月数千円で抑えたい」向けです。

export CLAUDE_CODE_EFFORT_LEVEL=medium
# Opus 4.7 は常に adaptive reasoning。DISABLE_ADAPTIVE_THINKING は設定しない
export CLAUDE_CODE_MAX_OUTPUT_TOKENS=16000
# プロンプトキャッシュは Claude Code デフォルトで有効。意識して再利用する

medium は「思考が薄いターン」が混ざりやすいものの、軽い質問応答なら十分
キャッシュヒット率を上げるため、CLAUDE.md はなるべく短く（筆者の運用では 200 行以内）
大掛かりなタスクのときだけ /effort xhigh のように都度昇格

2. 品質重視（本番コード / 重要ドキュメント）

レビューに耐えるコードを一発で出したいシーン向けです。

export CLAUDE_CODE_EFFORT_LEVEL=xhigh           # 4.7 から追加
export ANTHROPIC_MODEL=claude-opus-4-7
export CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000
# 4.7 は常に adaptive reasoning なので DISABLE_ADAPTIVE_THINKING は不要
# 特定タスクで思考量を固定したい場合は task_budget を明示指定する

xhigh は max の約 6 割のコストで、筆者の体感では 9 割以上の成功率
重要な設計レビューでは /ultrareview（v2.1.111 で追加）と組み合わせるのも相性が良い
画像を扱う場合、Opus 4.7 で最大 3.75MP まで解像度が上がっているので、スクリーンショットを読み込ませる用途にも向きます

3. 長時間エージェント（Routines / /loop）

Routines や /loop で無人運用するシーン向けです。

export CLAUDE_CODE_EFFORT_LEVEL=max
export ANTHROPIC_MODEL=claude-opus-4-7
export CLAUDE_CODE_SUBAGENT_MODEL=claude-opus-4-7
export CLAUDE_CODE_MAX_OUTPUT_TOKENS=128000
# 1M コンテキストを活用。プロンプトキャッシュは 1 時間モードがおすすめ
# 4.7 は adaptive reasoning 固定。思考量を絞りたいターンは task_budget で制御

max + 1M コンテキストで「朝までに 50 記事生成」のような長時間タスクが現実的に
サブエージェントに軽量モデルを割り当てるならここで分離 (CLAUDE_CODE_SUBAGENT_MODEL)
コスト警告が邪魔なら DISABLE_COST_WARNINGS=1。ただし事故時の気付きが遅れるため、監視と併用が無難

Routines にはプランごとに日次の実行回数上限が設けられています（Pro / Max / Team / Enterprise で異なる）。正確な数値は時期により変わるため、Anthropic 公式のプランページで最新値を確認してください。max で回しきるとコストも跳ねやすいので、最初は xhigh で様子を見て、必要なジョブだけ max に上げるのが無難です。

4. 開発サーバ監視（Monitors / 常駐）

Background Monitors や push 通知と組み合わせ、ログ監視に使うシーン向けです。

export CLAUDE_CODE_EFFORT_LEVEL=low
export CLAUDE_CODE_MAX_OUTPUT_TOKENS=4000
export DISABLE_TELEMETRY=1                      # 常駐のノイズ抑制
# 4.7 は adaptive reasoning 固定。低 effort でも軽い判断は自動調整される

監視用途では low で十分なケースが多く、判断が必要になったら /effort xhigh に一時昇格する流儀
Monitors 起動時の環境変数は、プラグインの manifest から継承されるため、プロファイル用の .envrc を別に切ると安心

判断フロー: いつ max / xhigh / high を使うか

「どの effort を使うべきか」を一枚絵で決めたいときの目安です。まず「Opus 4.7 を使うか否か」で分岐し、そのあとタスク複雑度や用途で effort を決めます。

この図は「迷ったらどこから始めるか」の目安です。たとえば筆者（Opus 4.7 利用）の場合、普段の記事執筆は xhigh、監視用途は low、月初の戦略レビューだけ max と切り替えています。

チーム運用: settings.json を書き分ける

Claude Code の設定は、公式ドキュメントに従うと Managed > CLI args > Local > Project > User の優先順位で解決されます（上ほど強い）。具体的には次のとおりです（v2.1 系）。

Managed: 組織ポリシー（Team / Enterprise のクラウド配布 / Managed settings）
CLI args: claude コマンドに渡した引数
Local: {project}/.claude/settings.local.json
Project: {project}/.claude/settings.json
User: ~/.claude/settings.json

環境変数（シェルから export したもの）は、settings.json の env ブロックと衝突したときの扱いがバージョンやチャネルで異なるため、チーム運用で確実に効かせたい値は settings.json 側で固定するのが安全です。

チームで共通化したいものと、個人でしか設定したくないものをどう切るかが運用の肝です。筆者は次のように分けています。

設定項目	置き場所	理由
`CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1`（4.6 系利用時のみ）	`.claude/settings.json`	チーム全員で品質を揃えたい。4.7 では無効なので設定不要
`CLAUDE_CODE_EFFORT_LEVEL=xhigh`	`.claude/settings.json`	同上。ベースラインとして共有
`ANTHROPIC_MODEL=claude-opus-4-7`	`.claude/settings.json`	バージョンずれを防ぐ
`ANTHROPIC_API_KEY`	`.claude/settings.local.json` or `.envrc`	個人のシークレット
`CLAUDE_CODE_USE_BEDROCK`, `AWS_REGION`	`.claude/settings.local.json`	人によって AWS アカウントが違うため
`DISABLE_COST_WARNINGS`	`.claude/settings.local.json`	個人の好み

settings.json の例:

{
  "env": {
    "CLAUDE_CODE_EFFORT_LEVEL": "xhigh",
    "ANTHROPIC_MODEL": "claude-opus-4-7",
    "CLAUDE_CODE_MAX_OUTPUT_TOKENS": "64000"
  },
  "permissions": {
    "allow": ["Bash(git status:*)", "Bash(git diff:*)"]
  }
}

CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING は Opus 4.7 では無効なので、4.7 を使う想定のチーム設定からは外しています。4.6 / Sonnet 4.6 を併用するチームだけ追加してください。

settings.local.json は Git 管理から外すのが基本です。.gitignore に .claude/settings.local.json を必ず入れておきましょう。

.envrc / direnv / 1Password との連携

個人シークレットや案件別の環境変数は、direnv の .envrc でプロジェクトごとに切り替えるのが現実的です。

# .envrc
export ANTHROPIC_API_KEY="$(op read 'op://Personal/Anthropic/api_key')"
export CLAUDE_CODE_EFFORT_LEVEL=xhigh
export CLAUDE_CODE_USE_BEDROCK=0

1Password CLI (op) と組み合わせれば、平文でキーを置かずに済みます。社内で共通のプロキシやリージョンを使う案件では、.envrc.example をリポジトリに置いて、各自 .envrc にコピーして使う運用が分かりやすいと思います。

settings.json の env ブロックは、Claude Code 起動時に子プロセスに渡されます。セッション中にシェルを再起動しても、Claude Code から見た環境変数は settings.json の値が効く点は覚えておくと便利です。

よくあるハマり

1. `CLAUDE_CODE_EFFORT_LEVEL=max` にしたのに、効いていない気がする

settings.json の env と、シェルの export が食い違っていないか確認してください。優先順位的には、シェル側の環境変数が最後に勝ちます。
セッション内で /effort を実行した履歴があると、そのセッションの間はコマンド値が優先されます。/effort max を改めて叩くと、明示的にリセットできます。

2. `xhigh` を指定したのに反映されない気がする

xhigh は Opus 4.7 専用の新 effort（5段階）です。Opus 4.6 / Sonnet 4.6 は 4 段階（max / high / medium / low）で xhigh は存在しません。
4.6 系で xhigh を指定した場合はエラーにはならず、high にフォールバックします。体感的に「思ったより思考していない」ときは、モデルが 4.6 系になっていないか /model で確認してください。
claude --version で v2.1.111+ か、/model で claude-opus-4-7 を選んでいるかも合わせて確認しましょう。

3. Bedrock / Vertex に切り替えたら遅くなった

筆者の環境では、Bedrock の us-west-2 は Anthropic 直の API と比べてレイテンシが高めでした。リージョンを切り替えるだけで改善することがあります。
CLAUDE_CODE_USE_BEDROCK=1 を解除したうえで、ANTHROPIC_API_KEY を正しく渡しているか再確認しましょう。

4. `DISABLE_TELEMETRY=1` を設定したのに、テレメトリが送られているように見える

Claude Code 本体のテレメトリは止まりますが、プラグイン側が独自に送信している場合があります。怪しいときは、.claude/plugins/ の各プラグイン設定を見てください。

5. Routines から起動したときだけ、環境変数が反映されない

Routines はクラウドインフラ側で実行されるため、ローカルの .envrc や export は届きません。
代わりに、Routines ダッシュボード上の「Environment variables」欄で明示的に設定する必要があります。ここを忘れると、Opus 4.7 でも medium の adaptive reasoning デフォルトで動いてしまうため、「急に品質が落ちた気がする」原因になりがちです。

まとめ

2026 年 4 月時点の Claude Code は、環境変数ひとつで品質もコストも大きく振れるツールに成長しました。3 月の劣化騒動を経て、コミュニティでは「4.6 系なら CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 を入れる」「4.7 系なら CLAUDE_CODE_EFFORT_LEVEL=xhigh を軸に task_budget を明示する」という処方箋が定着しつつあります。

一方で、Opus 4.7 の xhigh や 1M コンテキスト、Routines のような新要素と組み合わせるときは、プロジェクトの性質ごとにプロファイルを作っておくと事故が減ります。

この記事を踏まえて、筆者がおすすめしたい最小セットは次のとおりです。

Opus 4.7 を使う場合: 個人の .envrc で CLAUDE_CODE_EFFORT_LEVEL=xhigh と ANTHROPIC_MODEL=claude-opus-4-7 を入れる（DISABLE_ADAPTIVE_THINKING は不要）
Opus 4.6 / Sonnet 4.6 を使う場合: CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 と CLAUDE_CODE_EFFORT_LEVEL=high（または max）を入れる
チーム共有の .claude/settings.json に、モデルと effort のベースラインを置く
長時間エージェントやコスト重視のタスクは、専用プロファイル（別 .envrc）で切り替える

環境変数は、設定しすぎると逆に運用が重くなります。「どの変数がなぜ必要か」をチームで共有しておくと、半年後の自分にも優しいセットアップになります。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up