Claude 5コンテキストエンジニアリング｜8割削減の事例と直し方【2026】

01Claude 5世代のコンテキストエンジニアリングとは？

コンテキストエンジニアリングとは、モデルに渡す文脈をどう組み立てるかの設計を指します。システムプロンプト、スキル、CLAUDE.md、メモリ、ツール定義といった要素を、何をどの順で、どれだけの量で渡すかを決める作業です。Claude Codeを使う場合も、自分でエージェントを組む場合も、出力の品質はここで大きく変わります。

Claude 5世代で反転したのは、その最適な形です。Anthropicの技術スタッフであるThariq Shihipar氏は2026年7月24日、Claude Opus 5とClaude Fable 5に向けてClaude Codeのシステムプロンプトを8割以上削除し、社内のコーディング評価に測定できる損失は出なかったと公開しました。同氏はこれを「Claudeの足かせを外す（unhobbling）」と表現しています。

背景にあるのは、旧世代の挙動を抑え込むために置かれたガードレールが、新しいモデルでは邪魔になっていたという発見です。指示同士が矛盾する、細かく決めすぎたルールが例外的な場面で誤動作する、そしてルールの分量がモデル自身の判断を押し出してしまう。この3つが起きていたと説明されています。モデルが賢くなった結果、指示書は資産ではなく負債に変わったわけです。新しいモデルの解説はClaude Opus 5の仕様と料金でまとめています。

02Anthropicが削ったシステムプロンプトの中身

削られたのは、モデルの振る舞いを細かく縛る禁止事項です。公開されている実例では、次の指示が削除対象になりました。

禁止事項を並べる代わりに、判断の基準を1つ与える形に変わっています。前者は「コメントを書くな」という固定のルールなので、コメントが必要なコードベースでも守ってしまいます。後者は周囲を見て決めるよう促すだけなので、どちらの現場でも破綻しません。ルールを減らしたのに結果が悪くならなかったのは、判断材料のほうを渡したからです。

あわせて、コードレビューや検証の手順書は、常時読み込まれるシステムプロンプトから、必要なときだけ読み込むスキルへ移されました。文脈は最初に全部渡すのではなく、必要になった時点で段階的に開示する設計に変わっています。

03これまでの書き方と今の書き方は何が違う？

公式は6つの観点で「以前」と「現在」を対比しています。自分の設定ファイルを開きながら読むと、どこが古い書き方のまま残っているかが分かります。

共通しているのは、モデルに「言葉で説明する」のをやめて、「材料と判断基準を渡す」方向へ寄せている点です。とくに最後の1行は制作会社にとって影響が大きい変化で、デザインや実装の仕様を長文で書くより、HTMLのモックアップやテストを置くほうが精度が上がるとされています。

04アウトプットにどんな差が出ると想定されるか

公式が示しているのは「8割削っても評価が落ちなかった」という結果であり、削れば品質が上がると保証されたわけではありません。以下は公開された設計変更から導いた想定で、編集部が数値で測定した結果ではない点を先に明記します。

逆の見方をすると、旧世代向けに書いた分厚い指示書を持ち込んだままだと、新しいモデルの性能を自分で抑え込むことになります。モデルを新しくしたのに手応えが変わらないと感じる場合、原因はモデルではなく指示書の側にある可能性があります。

05CLAUDE.mdはどう書き直せばよい？

公式の指針は明快で、「CLAUDE.mdは軽く保ち、リポジトリが何のためのものかを簡潔に書く。そしてトークンの大半は、コードベースの中にある落とし穴に使う」というものです。ファイル構成やディレクトリの説明など、モデルが自分で見れば分かることを書く価値は下がりました。

残すもの・消すものの仕分け

手を動かす順番としては、既存のCLAUDE.mdを開いて、各行を次の基準で分けるところから始めます。

【残す】ファイルを見ても分からないこと
  - 本番DBはSupabase。ローカルのdocker-composeとはスキーマが別
  - /legacy 配下は触らない。旧システムが参照している
  - 画像は WebP のみ。PNGを置くとビルドが落ちる

【消す】読めば分かること
  - ディレクトリ構成の一覧
  - 使用ライブラリの列挙
  - 「型を正しく書く」「読みやすいコードを書く」等の一般論

【移す】長い手順書はスキルへ
  - デプロイ手順、レビュー観点、QAチェックリスト

目安として、残すのは「新しく入ったメンバーが半日ハマるであろう落とし穴」です。それ以外は消すか、スキルに移して必要なときだけ読ませます。長い手順を常時読ませる設計は、いまは推奨されていません。

スキルは制約しすぎない

公式はスキルを「必要なときにClaudeが情報を見つけるための軽い案内」と位置づけ、とくに重要な領域を除いて過剰に制約しないよう促しています。長いスキルは1枚に詰め込まず、複数ファイルに分けて段階的に開示する形が推奨されました。チーム固有の判断や好みを書く場所としては、CLAUDE.mdよりスキルのほうが適しています。

06サイト制作・LP制作での指示の書き換え方

制作の現場で最も差が出るのは、デザイン仕様の渡し方です。「余白は広めに」「上品な印象で」といった説明文をやめ、判断できる材料そのものを渡す形に切り替えます。公式が挙げているのも、説明文よりHTMLのモックアップを使う、テストを仕様として使う、検証用のルーブリックを渡すという3つでした。

指示テンプレートの書き換え例

旧来の書き方と、Claude 5世代向けの書き方を並べると違いが分かります。

【これまで】禁止事項を並べる
- 派手な色を使わないでください
- 余白を詰めすぎないでください
- フォントサイズは大きくしすぎないでください
- 影は控えめにしてください

【これから】判断基準と見本を渡す
このLPは design/reference.html と同じトーンで実装してください。
色・余白・フォントサイズは reference.html の値をそのまま使い、
新しい値を足す場合だけ、なぜ必要かを1行で書いてください。

禁止事項の列挙は、案件ごとに書き換えが必要なうえ、書き漏らした項目は守られません。参照するファイルを1つ指定すれば、そのファイルが基準として機能し続けます。制作会社のように案件が並行して走る環境では、この差が運用の手間に直結します。

コーディング規約はコードで置く

コーディング規約も、文章でまとめるより実物を1本置くほうが確実です。共通パーツのHTMLとCSSを1ファイルにまとめて置き、CLAUDE.mdからは「新規セクションは components.html の書き方に合わせる」と1行で参照します。規約の文章量が減り、実装との食い違いも起きにくくなります。

07自作ツール・エージェントのツール設計の直し方

社内の効率化ツールやエージェントを自分で組んでいる場合、直す場所はシステムプロンプトではなくツール定義です。公式は、ツールの使い方はシステムプロンプトで繰り返さずツールの説明に置くこと、そして使用例を並べるより引数の設計で意図を伝えることを推奨しています。

引数の設計で意図を伝える

たとえばステータスを扱うツールなら、自由文字列で受け取って説明文で補うのではなく、列挙型にして選択肢そのものを仕様にします。

{
  "name": "update_ticket",
  "description": "社内チケットの状態を更新する。完了にする場合は必ず resolution も渡すこと。",
  "input_schema": {
    "type": "object",
    "properties": {
      "ticket_id": { "type": "string" },
      "status": { "type": "string", "enum": ["open", "in_progress", "blocked", "done"] },
      "resolution": { "type": "string", "description": "status が done のときの対応内容" }
    },
    "required": ["ticket_id", "status"]
  }
}

選択肢を列挙型で示せば、取りうる値の説明も、想定外の値が来たときの対処も不要になります。使い方の注意はツールの説明に1回だけ書き、システムプロンプト側には書かない。これが繰り返しを消すという指針の実装形です。ツール連携の基礎はMCPの仕組みと使い方で整理しています。

仕様はテストで渡す

期待する挙動を文章で説明する代わりに、テストを先に書いて渡す方法も公式が挙げています。定期実行のバッチや社内APIのように入出力が決まっている処理では、テストがそのまま仕様書になり、完成の判定もモデル自身が行えます。仕様書と実装がずれる問題も同時に消えます。

08/doctorコマンドで自分の設定を点検する

Anthropicは、これらの指針をClaude Codeの診断機能に組み込んだと説明しています。Claude Code内で次のコマンドを実行すると、スキルとCLAUDE.mdの分量を適正化するための点検が行えます。

claude
# セッション内で
/doctor

手を入れる順番としては、まず点検を実行し、そのうえで前の章までの仕分け（残す・消す・移す）を適用するのが進めやすい流れです。いきなり全部書き直すのではなく、1つのリポジトリで試して結果を見てから、他の案件に広げてください。

09削りすぎて失敗しないための線引き

削減は目的ではありません。公式が削ったのは、モデルの判断を縛るための制約であって、モデルが知りようのない情報ではない点が重要です。この2つを混同すると、必要な前提まで消えて事故につながります。

公式も、スキルについて「とくに重要な領域を除いて」過剰な制約を避けるよう書いています。裏を返せば、重要な領域は明示的に縛ってよいという線引きです。本番環境や課金が絡む操作の禁止事項は、削る対象ではありません。

10よくある質問

システムプロンプトを8割削れば誰でも同じ結果になりますか？

同じにはなりません。公開されているのは、AnthropicがClaude Codeという特定の製品で、自社のコーディング評価を使って測った結果です。手元の環境で削る場合は、自分たちの評価基準で前後を比べてから広げるのが安全です。

CLAUDE.mdには結局何を書けばよいですか？

リポジトリが何のためのものかを簡潔に書き、残りは落とし穴に使います。公式の表現では「gotchas」で、ファイルを読んでも分からない前提や、過去に事故が起きた箇所が該当します。ディレクトリ構成や使用ライブラリの列挙は、書く価値が下がりました。

スキルとCLAUDE.mdはどう使い分けますか？

CLAUDE.mdは常時読み込まれる軽い前提、スキルは必要なときに読み込む手順や方針、という分け方になります。デプロイ手順やレビュー観点のような長い内容はスキル側に置き、長くなる場合は複数ファイルに分けて段階的に開示します。

ツールの使用例を書くのはもうやめたほうがよいですか？

使用例を並べるより、引数の設計で意図が伝わる形にするのが推奨されています。列挙型で選択肢を示す、必須項目を明示する、といった設計です。注意事項が必要な場合は、システムプロンプトではなくツールの説明に1回だけ書きます。

この変更はClaude Opus 5だけの話ですか？

公式はClaude Opus 5とClaude Fable 5を例に挙げており、Claude 5世代のモデルに向けた指針として公開されています。旧世代のモデルを使い続ける場合は、当時の指示書のほうが噛み合う場面もあるため、モデルを切り替えるタイミングで見直すのが現実的です。

どこから手をつけるのが効率的ですか？

Claude Codeで/doctorを実行し、そのあとCLAUDE.mdを「残す・消す・移す」で仕分けるのが最短です。1リポジトリで試し、いつもの作業を1つ投げて手応えを比べてから、他の案件へ広げてください。

11まとめ：指示書を見直すかの判断基準

見直すかどうかは「いまのCLAUDE.mdが、旧世代のモデル向けに書かれたままか」で決まります。禁止事項が並んでいる、ディレクトリ構成が書いてある、同じ注意書きが複数箇所にある。この3つに当てはまるなら、モデルの判断を自分で狭めている状態です。

最初の一歩としては、いちばん使っている案件のCLAUDE.mdを開き、各行を「読めば分かることか、知りようのない前提か」で仕分けてみてください。前者を消して後者を厚くするだけで分量は半分近くまで落ちます。そのうえで、デザイン仕様を説明文からHTMLの見本へ、ツールの注意書きをツール定義へ移していくと、指示は短くなり結果は安定します。モデル側の仕様はClaude Opus 5の解説とClaude Sonnet 5の解説にまとめています。

12出典

• The new rules of context engineering for Claude 5 generation models — Anthropic（Thariq Shihipar／2026年7月24日）
• Introducing Claude Opus 5 — Anthropic（公式発表）
• Models overview — Claude Platform Docs（モデル仕様）