【2026年7月】Claude 5コンテキスト新ルール×CLAUDE.md実践

先週、手元のリポジトリでOpus 5に切り替えた直後、CLAUDE.mdに残していた「実装後は必ずテストを実行し、結果を確認してから完了とすること」という一文が、逆に無駄なツール呼び出しを増やしているのに気づいた。Opus 4.8時代に「言われないと確認しない」モデルの癖を矯正するために書いた一文が、自分から検証するようになったOpus 5には二重の指示になっていた。Anthropicの公式ブログはこの現象を名指しで説明しており、読んだ瞬間に「自分のCLAUDE.mdは前提が古い」と分かった。この記事は、その書き直し作業をそのまま持ち帰れる形にしたものだ。

Claude 5世代で何が変わったのか — Anthropic公式ブログの要点

公式ブログ「The new rules of context engineering for Claude 5 generation models」（Anthropic、Thariq Shihipar、2026年7月24日公開）が挙げている変更点を整理すると、以下の5つに集約できる。

1. 制約より判断（judgement）：あらゆる場面をルールで縛るより、Claudeに判断させたほうが結果が良い。Anthropicは新しいモデル向けにClaude Codeのシステムプロンプトを80%以上削減したと明言している
2. CLAUDE.mdは軽量に：リポジトリの目的を簡潔に書き、ファイルシステムを見れば分かる情報は書かない。トークンは「コードベースの落とし穴」に使う
3. ツール設計は例示より構造：ツールの使い方を大量の使用例で縛ると、かえってClaudeの探索範囲を狭める。パラメータ設計そのものを表現力豊かにする方が効く
4. スキルはプログレッシブディスクロージャー：長い手順書は分割し、必要な時だけ読ませる。詳細な検証手順・コードレビュー手順は本体から切り出して別スキル化する
5. メモリの自動化：Claudeは作業に関連する内容を自動的に記憶するようになったため、CLAUDE.mdを手動メモ帳として運用する比重は下がる

いずれも「情報を減らせ」ではなく「情報の質を上げろ」という話である点に注意したい。CLAUDE.mdを空にするのではなく、矛盾する指示・自明な情報・旧世代向けの矯正指示を削り、コードベース固有の「知らないと事故る話」に集中させる、という編集作業になる。

なぜ「必ず検証して」という指示が逆効果になったのか

Anthropicのプロンプティングガイド（Prompting Claude Opus 5）は、この点をかなり踏み込んで書いている。要約すると次のとおりだ。

Claude Opus 5 verifies its own work without being told to. If your prompt contains explicit verification instructions (…), remove them: instructions like these cause over-verification on Claude Opus 5, and removing them reduces wasted tokens with no loss in quality.（Opus 5は指示なしに自分の作業を検証する。明示的な検証指示が含まれている場合は削除すること。過剰検証を招き、品質を落とさずに無駄なトークンを削減できる）

同じロジックは「double-check your answer」「re-verify before responding」といった自己再チェック指示、レガシーなハーネスの検証ステップにも当てはまる。逆に、レビュー系プロンプトで「重大な問題だけ報告して」「保守的に判断して」と書くと、Opus 5はその指示を文字どおり守って報告を絞り込みすぎる場合がある、ともドキュメントは注意している。全件報告させて、後工程でフィルタする設計に変えるのが無難だ。

CLAUDE.md書き換え実践①：検証・再確認指示を消す

まず着手すべきはここ。CLAUDE.mdの中から「必ず」「再確認」「ダブルチェック」「サブエージェントで検証」を含む行を洗い出し、以下のように削る。

❌ Before（Opus 4.8以前を前提にした矯正指示）
- 実装が終わったら、必ず最終確認としてテストを実行し、結果を報告すること
- 複雑な変更はサブエージェントに検証させてから完了とすること
- 回答する前に、必ずもう一度自分の答えを見直すこと

⭕ After（Opus 5向け・判断を委ねる）
- テストの実行要否・実行タイミングはあなたの判断に任せる
- サブエージェントは「独立した大きな調査・実装」だけに使い、自分の作業の検証目的では使わない

これは「品質チェックをやめる」という意味ではない。品質を担保する層を、CLAUDE.mdの文章指示から、CIやフック（PreToolUse/PostToolUseによる強制）に移す、という役割分担の話だ。「必ず守らせたい」ものはCLAUDE.mdではなく技術的な強制（hooks・permissions）で縛り、CLAUDE.mdは判断材料の提供に徹する、という本サイトのCLAUDE.md設計・運用ガイドの原則がOpus 5でより重要になった、と捉えるとよい。

CLAUDE.md書き換え実践②：コードスタイル指示を「例示」から「原則」に

ツール設計と同じ理屈が、コードスタイルの指示にも当てはまる。公式ガイドが挙げている例をそのまま引用する。

❌ Before（禁止事項の羅列）
- 複数段落のdocstringは書かないこと
- 関数名はcamelCaseを使うこと。例: getUserData, fetchOrderList
- コメントは最小限にすること

⭕ After（周囲のコードに合わせる原則）
- 周囲のコードと同じ書き方に合わせて書く。コメントの密度、命名規則、イディオムをファイル単位で揃えること

個別ルールを列挙するほど、既存コードの実態とズレた時に矛盾が発生する。「周囲に合わせる」という原則1文の方が、リポジトリ内の混在したスタイルにも自然に追従する。ツールのパラメータ設計についても同様で、公式ブログは「使用例を大量に与えるとClaudeの探索範囲をかえって狭める」と述べており、examplesの束より、パラメータ自体の表現力（enumのヒント等）を上げる設計を推奨している。

CLAUDE.md書き換え実践③：応答の長さとスコープを制御する

Opus 5はデフォルトの応答が長くなり、作業前に「何をするか」を宣言し、作業中の進捗報告も増える。ユーザー向けプロダクトでこれを絞りたい場合、公式ガイドはトーン指示を明示することを推奨している。CLAUDE.mdやシステムプロンプトに以下のようなブロックを追加する形だ。

<response_style>
出力は要点を優先し、埋め草的な前置き・重複する要約・定型文は書かない。
ツール呼び出しの前に一文で「これから何をするか」を述べる。
作業中の更新は、重要な発見や方針転換があった時だけにする。
完了時は最初の一文で「何が起きたか」を述べ、詳細はその後に続ける。
</response_style>

<scope_control>
依頼された範囲を、意図された規模で仕上げる。
判断が分かれる場合だけ確認を挟み、それ以外は自分の判断で進めてよい。
依頼が誤っていそうな場合や、より良い方法がある場合は一文で指摘したうえで、依頼どおりの作業を続ける。
</scope_control>

Anthropicのガイドも同種の指示例を挙げており、「〜するな」という禁止形より、期待する振る舞いを具体的に描写する指示の方が効くと注記している。ファイルに書き出す成果物（レポート・Markdown）についても同様に、水増しせず「タスクに必要な分量に合わせる」という一文を添える運用が推奨されている。

SKILL.mdの書き方も変わる — プログレッシブディスクロージャー

公式ブログは、スキルを「Claudeが必要な時に情報を見つけるための軽量なガイド」と位置づけている。長大な手順書を1ファイルに詰め込むのではなく、詳細な検証・レビュー手順は別スキルに切り出し、CLAUDE.mdやSKILL.md本体からは「必要な時に参照する」形にする。Claude CodeのSKILL.mdはこの設計をそのまま実装できる。frontmatterのdisable-model-invocation: trueで意図しない自動起動を止め、context: forkを使えばスキル本文を指定したサブエージェントに注入して実行できる。本体は薄く保ち、チーム固有の知見・判断基準だけを書く——という方針は、本サイトのSkills作成ガイドで解説した設計と完全に一致する。Claude 5世代では、この分割をやるかどうかより「本体に検証ロジックを固定で書き込んでいないか」を優先的に見直すべきだ。

サブエージェント運用の変更点 — 委譲基準とspawn数の制御

Anthropicのプロンプティングガイドは、Opus 5が「サブエージェントに委譲しやすくなった」と明言している。うまく使えば書き手・検証役のペアパターンが機能するが、小さいタスクにまで委譲すると、コストと時間が跳ね上がる副作用がある。対策として推奨されているのが「委譲していい場面を明示する」と「spawn数に上限を設ける」の2つだ。後者はClaude Code側に実装がある。

設定例（settings.json）
{
  "env": {
    "CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS": "5",
    "CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION": "40"
  }
}

Claude Codeはデフォルトで同時実行20体・セッション合計200体のサブエージェントまで許可しており、超えるとConcurrent subagent limit reached / Subagent spawn limit reachedのエラーで止まる（Claude CodeのCLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTHを設定しない限り、サブエージェントは自分の子サブエージェントを持てない）。小さいコードベースやコスト管理を優先する場合は、これらの環境変数で上限を絞るのが、公式ガイドの言う「決定的な上限を設ける」の具体的な実装になる。もう一段細かく制御したい場合は、サブエージェント定義のfrontmatterにeffortフィールド（low / medium / high / xhigh / max）を指定して、そのサブエージェントが起動している間だけセッションのeffort設定を上書きできる。

---
name: code-reviewer
description: 差分のバグを高精度・高再現率で洗い出す。検証目的では起動しない
tools: Read, Grep, Glob
model: sonnet
effort: medium
---

「どのサブエージェントを誰が呼べるか」も、CLAUDE.mdの文章指示ではなくtoolsフィールドのAgent(agent_type)許可リスト、またはpermissions.denyで技術的に絞れる。委譲の判断はモデルに任せつつ、コストと暴走の上限だけを運用側が握る、という役割分担がOpus 5時代のサブエージェント設計の基本形になる。詳しい並列運用パターンはサブエージェント並列開発入門を参照してほしい。

MCPとの関係 — Tool Searchも同じ思想の実装

公式ブログが挙げる「ツール定義のdeferred loading」は、Claude Codeでは既にMCP Tool Searchとして実装されている。Claude Codeの公式ドキュメントによれば、Tool Searchはデフォルトで有効で、セッション開始時にはツール名とサーバーの説明文だけが読み込まれ、実際にClaudeが使うツールの完全な定義だけがToolSearchツール経由でオンデマンド読み込みされる。MCPサーバーを増やしても、コンテキスト消費は「実際に使われたツールの分」にほぼ限定される。

Tool Searchの制御（環境変数 ENABLE_TOOL_SEARCH）
(unset) : 全MCPツールをdeferred・オンデマンド読み込み（デフォルト）
true    : 常にdeferredを強制
auto    : コンテキストウィンドウの10%に収まる分だけ先読み、残りはdeferred
false   : Tool Searchを無効化し、全ツール定義を最初から読み込む

逆に、毎ターン確実に使う少数のツールは、MCPサーバー設定側でalwaysLoad: trueを指定すれば、Tool Searchの検索を待たずに常時ロードできる。CLAUDE.mdが「リポジトリの落とし穴だけ書いて残りは省く」、SKILL.mdが「必要な時だけ読ませる」、MCPのTool Searchが「使うツールだけ定義を読み込む」——3つとも同じプログレッシブディスクロージャーの原則をレイヤーごとに実装したものだと理解すると、公式ブログの主張が一枚の設計図としてつながる。

Opus 5のthinking／effort仕様とCLAUDE.mdへの影響

コンテキストエンジニアリングの書き換えとあわせて、Opus 5のAPI仕様変更もCLAUDE.md・設定ファイルの前提に直接効いてくる。Anthropic公式ドキュメント（What’s new in Claude Opus 5 / Prompting Claude Opus 5）で確認できる要点は以下のとおり。

• thinkingは既定でON：Opus 4.8ではthinking: {"type": "adaptive"}を明示しない限りthinkingなしで動いていたが、Opus 5では同じリクエストがthinking有効で走る。effortパラメータが思考の深さを制御する
• thinking無効化はeffort highまで：thinking: {"type": "disabled"}はeffort high以下でのみ有効。xhighやmaxと組み合わせると400エラーになる、Opus 4.8からの破壊的変更
• promptキャッシュの最小長が512トークンに縮小：Opus 4.8の1,024トークンから半減し、短いプロンプトでもキャッシュが効きやすくなった
• Opus 5はeffortの「引き継ぎ」が効く：Fable 5・Opus 4.8・Opus 4.7は新モデルへの切り替え初回にそのモデルのデフォルトeffortへリセットされるが、Opus 5にはこのholdがなく、以前設定したeffortレベルがそのまま引き継がれる

Claude Code側では、effortはセッションの/effortコマンドや--effortフラグ、settings.jsonのeffortLevelキー（low/medium/high/xhigh。maxはセッション限定）で設定する。CLAUDE.mdに「thinkingを使うな」「考えるな」と直接書いてある場合は、Opus 5では削除したほうがよい。公式ガイドは、thinking無効時に内部XMLタグが出力に漏れるリスクがあり、それを名指しで禁止する指示はタグ漏洩を増やす傾向があると注記している。Opus 5移行の実務全体（モデルID切り替え・max_tokensの見直し等）はClaude Opus 5をClaude Codeで使う移行実務に譲り、本記事ではCLAUDE.md側の記述にどう跳ね返るかに絞って整理した。

今日やる3つのチェックリスト

1. CLAUDE.mdをgrepする：「必ず」「再確認」「ダブルチェック」「サブエージェントで検証」を検索し、該当行を削除するか、CIやフックへの技術的強制に置き換える
2. サブエージェントの上限を明示する：委譲の判断はモデルに任せつつ、CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS・CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSIONを自分のプロジェクト規模に合わせて設定する
3. 長い手順書をSKILL.mdへ切り出す：CLAUDE.mdに残っている多段の手順・チェックリストを見つけたら、progressive disclosureの原則に沿って別スキルに移し、CLAUDE.mdは「知らないと事故る話」だけに絞る

【要注意】よくある失敗パターンと回避策

❌ 旧世代向けの矯正指示をそのまま残す
「必ず検証して」「サブエージェントでダブルチェックして」を残したままOpus 5に切り替えると、モデル自身の自己検証と指示による検証が二重にかかり、トークンと時間だけが増える。
⭕ 検証指示は削除し、技術的に強制したいものだけhooks・permissionsに移す。

❌ ツールの説明に大量の使用例を詰め込む
「こういう時はこう呼ぶ」という具体例を並べるほど、Claudeの探索範囲が狭まり、想定外の呼び出し方に対応できなくなる。
⭕ パラメータ設計そのものの表現力を上げ、enumのヒント等で意図を伝える。

❌ サブエージェントのspawn数を無制限にする
Opus 5は委譲しやすくなった分、小さいタスクにまでサブエージェントを立てて時間とコストが跳ね上がることがある。
⭕ CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS等で上限を明示し、委譲していい場面をCLAUDE.mdやサブエージェント定義に書く。

❌ CLAUDE.mdに全部書き込んで肥大化させる
ファイルシステムを見れば分かる情報や、頻度の低い手順まで書き込むと、毎セッションのトークン消費が増え、矛盾したルールが混在しやすくなる。
⭕ 「知らないと事故る落とし穴」だけをCLAUDE.mdに残し、詳細な手順はSKILL.mdへprogressive disclosureする。

FAQ

Q. 「コンテキストエンジニアリング」とは具体的に何を指しますか？
Anthropicの定義では、モデルに何を・いつ・どれだけ読ませるかを設計する作業全般を指す。CLAUDE.md・SKILL.md・ツール定義・MCPのツール読み込み・会話履歴の扱いまで含む、プロンプト単体の工夫より広い概念として使われている。

Q. CLAUDE.mdの検証指示を全部消して大丈夫ですか？
「消す」というより「強制する層を変える」のが正確な理解。本当に守らせたい動作（特定コマンドの禁止、mainへの直pushの禁止等）はCLAUDE.mdの文章ではなくhooksやpermissions.denyで技術的に強制し、CLAUDE.mdからは冗長な検証指示だけを削るのが公式ガイドの趣旨。

Q. サブエージェントのspawn数はどこまで絞ってよいですか？
デフォルトは同時実行20体・セッション合計200体。小規模チームやコスト管理を優先するならCLAUDE_CODE_MAX_CONCURRENT_SUBAGENTSを1桁台に絞っても動作する。上限に達するとConcurrent subagent limit reachedのエラーでモデル自身が止まり、リトライしないよう指示される仕様なので、絞りすぎて処理が壊れる心配は小さい。

Q. thinkingを無効化した方がコストは下がりますか？
Opus 5の公式ガイドは「ほとんどのタスクでは、thinkingを有効にしたままlow effortにする方が、thinkingを無効化するより性能が良い」としている。thinking無効化は、ツール呼び出しがテキストに漏れる・内部タグが出力に混じるなどの副作用もあるため、まずeffortを下げる方を優先したほうがよい。

Q. MCPサーバーを増やすとコンテキストを圧迫しませんか?
Tool Searchがデフォルトで有効なため、増やしたサーバーの全ツール定義が最初から読み込まれるわけではない。セッション開始時に読み込まれるのはツール名とサーバー説明文のみで、実際に使うツールの定義だけがオンデマンドで読み込まれる。毎ターン確実に使う少数のツールだけalwaysLoad: trueで先読みさせる、という使い分けになる。

Q. Opus 4.8向けに書いたCLAUDE.mdはそのまま使えますか?
動作はするが、過剰検証・冗長な進捗報告・応答の長文化といった副作用が出やすい。本記事のBefore/Afterに沿って、検証指示の削除・コードスタイル指示の原則化・応答の長さとスコープの明示化の3点は見直すことを推奨する。

まとめ

Claude 5世代のコンテキストエンジニアリングは、「もっと細かく指示する」から「余計な指示を削って判断力を信頼する」への転換だった。CLAUDE.mdからは検証指示とスタイルの禁止事項を削り、SKILL.mdは手順を分割して必要な時だけ読ませ、サブエージェントは委譲判断をモデルに任せつつ環境変数で上限だけ握る。MCPのTool Searchはこの設計思想がすでに実装として存在していることを教えてくれる。どれも「情報を減らす」のではなく「情報の置き場所と読み込みタイミングを設計し直す」作業だ。

CLAUDE.mdやサブエージェント設計の棚卸しを社内だけで進めるのが難しい場合は、Claude Codeの個別指導・導入支援も行っている。ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。

関連記事（Claude Code 実践ガイド）

• まとめ：Claude Code 実践テクニック完全ガイド（12スキル）
• Claude Code Hooks実践ガイド｜整形・通知の自動化
• Claude Codeのコスト最適化ガイド｜トークン節約の実践
• Claude Code settings.json設定完全ガイド

あわせて読みたい

• ▸ 【2026年】Claude Opus 5をClaude Codeで使う移行実務
• ▸ AIソフトウェア工場はなぜ失敗するか｜Claude Code並列運用の3つの律速
• ▸ 【2026年最新】Claude Codeのシークレット管理｜秘密情報を守る7原則
• ▸ 【2026年最新】Claude Code×Kubernetes運用術｜実践7選
• ▸ 【2026年最新】Excel業務をClaude Codeで自動化する実践ガイド