ZenkenAI
公開: 更新:

Claude 5世代のコンテキストエンジニアリング新ルール｜Opus 4系から何を変えるか

Claude Claude Code Opus 5 Fable 5 コンテキストエンジニアリング
目次 23項目
OpenAIの活用事例に当社Zenkenが掲載されました

結論から言うと、 Claude 5世代のモデルでは「AIに細かいルールを与える」書き方をやめ、「判断に任せて、判断材料を渡す」書き方に切り替えるのが正解 です。Anthropicは2026年7月24日、Claude Codeのシステムプロンプトを 80%以上削除しても、社内のコーディング評価で計測可能な性能低下はなかった と公表しました。対象はClaude Opus 5やClaude Fable 5といった新世代モデルです。

つまり、Opus 4系の時代に「言うことを聞かせるため」に積み上げてきた禁止事項や作法の指示は、いま多くが不要になっているどころか、 かえって足を引っ張っている可能性がある ということです。この記事では、何がどう変わったのか、そしてOpus 4系向けに書いた指示をどう直せばよいのかを、順番に整理します。

そもそもコンテキストエンジニアリングとは

AIに何かを頼むとき、AIが受け取っている情報は、あなたが打ち込んだ依頼文（プロンプト）だけではありません。実際には次のようなものが毎回いっしょに渡っています。

要素中身身近な例
システムプロンプト製品側があらかじめ仕込んでいる前提「あなたはコーディング支援ツールです」
指示ファイルプロジェクト共通のルールを書いたファイルClaude Codeの CLAUDE.md
スキル特定の作業手順をまとめた説明書「校閲のやり方」「検証のやり方」
メモリ過去のやり取りから引き継いだ情報「この人は結論から書くのを好む」
参照資料作業のよりどころになる素材仕様書、モックアップ、テストコード

この 「毎回渡っている前提情報の設計」がコンテキストエンジニアリング です。プロンプトは1回きりの依頼なので具体的に書けますが、コンテキストは「相手が何を頼んでくるかわからない状態」で用意するため、書き方が難しくなります。今回Anthropicが公開したのは、まさにこの部分の新しい作法です。

なお、AIが一度に扱える情報量そのものについては ChatGPTのコンテキストウィンドウ解説 も参考になります。考え方はClaudeでも同じです。

何が起きたのか：システムプロンプトの8割削除

Anthropicが公表した内容の中心は、次の一点に集約されます。

Claude Opus 5やClaude Fable 5のようなモデル向けに、Claude Codeのシステムプロンプトを80%以上削除した。コーディング評価に計測可能な低下はなかった。

同社はこれを 「Unhobbling（足かせを外す）」 と表現しています。なぜ足かせだったのか。社内でのClaude Codeの利用ログを読んだところ、1回のリクエストの中で指示どうしが衝突していたからです。たとえばシステムプロンプトには「必要に応じてドキュメントを残せ」とあるのに、別の場所に「コメントを絶対に追加するな」と書かれている、といった具合です。

Claudeはユーザーの意図を汲んで正解にたどり着けますが、 矛盾した指示が重なっているほど「結局どうすべきか」を考える手間が増えます 。この手間は本来、目の前の課題を考えることに使われるべきものです。

かつては、こうした強い制約がないと最悪のケース（意図しないファイル削除など）を防げませんでした。しかし新世代モデルは周囲の文脈と自分の判断で適切に振る舞えるようになったため、多くの制約を消せるようになった、というのが今回の要旨です。

Claude Code自体の使い方は クロードコードとは｜読み方・料金・使い方 で解説しています。

従来とこれから：6つの変化

Anthropicは「かつてのベストプラクティスが、いまや神話（myth）になっているもの」として6組の対比を挙げています。まず全体像です。

従来（Opus 4系までの定石）これから（Claude 5世代）
ルールを与える判断に任せる
例を見せるインターフェース（道具）を設計する
必要な情報は先に全部渡す段階的開示（必要なときに読み込ませる）
大事なことは繰り返し書くツールの説明文をシンプルにする
CLAUDE.mdにメモを保存する自動メモリに任せる
シンプルな仕様書を置くリッチな参照資料を渡す

以下、1つずつ見ていきます。

1. ルールを与える → 判断に任せる

Claude Codeの初期は、ファイル削除のような最悪ケースを避けるため、常に正しいとは限らない強い指示を書いていました。実際に使われていた旧システムプロンプトはこうです。

（抜粋）In code: default to writing no comments. Never write multi-paragraph docstrings or multi-line comment blocks — one short line max.（コードには原則コメントを書かない。複数段落のドキュメント文字列や複数行のコメントブロックは絶対に書かず、短い1行までにする）

原文ではこの後に、依頼がない限り計画書や分析メモのような中間ファイルを作らない、という指示も続いていました。

しかしこの指示は、一部の依頼に対しては明確に間違いです。ユーザー側に別の好みがあるかもしれませんし、極端に複雑な箇所には複数行の説明が必要なこともあります。旧モデルではコメントの質が安定しなかったため、このトレードオフを飲むしかありませんでした。

新しいシステムプロンプトでは、これが1行に置き換わっています。

Write code that reads like the surrounding code: match its comment density, naming, and idiom.（周囲のコードと同じように読めるコードを書く。コメントの密度・命名・言い回しを合わせる）

禁止事項の列挙をやめ、「何に合わせればよいか」という判断基準だけを渡している のがポイントです。これは文章作成でも同じで、「箇条書き禁止」「絵文字禁止」と並べるより、「既存の社内文書のトーンに合わせて」と伝えるほうが、いまのモデルには効きます。

2. 例を見せる → インターフェースを設計する

これまで、ツールの使い方を教える最重要ルールは「例を見せること」でした。ところが新世代モデルでは、 例を出すことがかえって探索範囲を狭めてしまう ことがわかっています。

代わりに推奨されるのは、ツールやスクリプト、ファイルの設計そのものを見直すことです。「どんな項目（パラメータ）を渡せるようにするか」「その項目名だけで意図が伝わるか」を考えます。Anthropicが挙げているのはTodoツールの例で、状態を pending / in_progress / completed という選択肢に限定するだけで、Claudeは使い方を察します。そのうえで「 in_progress は常に1つだけ」と書けば、望む振る舞いが定義できます。

非エンジニアの実務に置き換えるなら、 入力フォームの項目名を整えるほうが、記入例を10個並べるより効く という話です。

3. 全部先に渡す → 段階的開示

Claude Codeはコーディング特化だったため、システムプロンプトにコードレビューや検証の詳しい手順が書かれていました。常に必要なわけではありませんが、必要なときには決定的に重要な情報です。

現在は、Claudeが 段階的開示（progressive disclosure） 、つまり「必要なタイミングで必要な情報を読み込む」動作が得意になりました。そこでAnthropicは、検証とコードレビューをそれぞれ独立したスキルに切り出し、Claudeが必要に応じて呼び出す形に変えています。

段階的開示はスキルだけの話ではありません。一部のツールは「遅延読み込み」になっており、Claudeが ToolSearch で定義を検索してから使う仕組みです。これにより、 使わないうちはコンテキストを消費しないまま、ツールの数を増やせます 。

そして、ここが多くの人に効く指摘です。

CLAUDE.mdやスキルのファイルを「起こりうるすべての作法を集めた中央リポジトリ」にすべきだ、という考えはよくある神話である。

すべてを1つのファイルに詰め込まないと見つけてもらえない、というのは思い込みです。 適切なタイミングで読み込まれるファイルのツリー（木構造）にする ほうが、いまは有利です。

4. 繰り返す → ツールの説明文をシンプルに

以前のモデルは、同じ指示を繰り返さないと守らないことがあり、コンテキストの終わりに近い指示ほど従いやすい傾向もありました。そのためAnthropicは、ツールに関する注意をシステムプロンプト側とツールの説明文側の両方に書いていました。

いまは、この重複を消し、 使い方の説明はツールの説明文だけに置く 形に整理できています。

5. CLAUDE.mdにメモ → 自動メモリ

かつては # ホットキーでCLAUDE.mdに情報を書き足す運用が推奨されていました。現在のClaudeは、作業やユーザーに関連する内容を 自動的にメモリへ保存 します。手作業でメモを積み上げる必要性は薄れています。

6. シンプルな仕様書 → リッチな参照資料

Claude Codeのプランモードは、Markdownの計画ファイルに強く依存してきました。仕様をコードベース内に置いて長期プロジェクトで参照させるのも定番でした。

しかしClaudeは、より複雑な参照資料を扱えるようになっています。Anthropicが挙げている選択肢は次のとおりです。

参照資料の形使いどころ
HTMLアーティファクト画面や資料の見た目そのものを渡す
コードそのもの移植したい他システムの関数など、動く実体を渡す
テストスイート「これが通れば正解」という形で仕様を定義する
ルーブリック（評価基準）「良いAPI設計とは何か」など、好みの基準を検証させる

とくにルーブリックは、検証役のエージェントを立ち上げて基準に沿って点検させる、という使い方が想定されています。

適用のしかた：4つの置き場所

Anthropicは、コンテキストを組み立てるときの置き場所ごとに指針を示しています。

置き場所指針
システムプロンプト製品の文脈と直結する内容だけ。Claude Codeの利用者は通常触らないが、自作エージェントならここに時間をかける
CLAUDE.md軽量に保つ。リポジトリの目的は簡潔に、トークンの大半は「落とし穴」の説明に使う
スキル情報を見つけるための軽いガイド。過剰に縛らない。長いものは複数ファイルに分割する
参照資料@ メンションでファイルを渡す。説明文よりコードなど「実体」を優先する

CLAUDE.mdについては、 「ファイル構成を見ればわかる自明なこと」を書かない のが重要です。書くべきは、たとえば「型定義は1つのファイルに集約していて、他の場所には置かない」といった、外から見てもわからない事情のほうです。検証手順が独特なら、CLAUDE.mdに全部書くのではなく検証スキルを作り、CLAUDE.mdからはそれを参照します。

参照資料については、 「デザインの説明文やスクリーンショットより、HTMLのモックアップのほうが良い結果になることが多い」 と説明されています。Claudeがよく知っている言語で書かれた、忠実度の高い指示になるからです。

Opus 4系を使ってきた人がやるべきこと

ここからは実際の手順です。上から順にこなせば、既存の設定を安全に移行できます。

ステップ0：まず /doctor を実行する

Anthropicは、この見直しを自動で手伝う claude doctor を提供しています。Claude Codeの入力欄で /doctor と入力すると実行できます（ターミナルから起動する場合は claude doctor です）。シェルのコマンドではなく、Claude Codeの中で使うスラッシュコマンドである点に注意してください。

スキルやCLAUDE.mdの分量を適正化する提案が得られます。ここを起点にすると、手作業の範囲がぐっと減ります。

ステップ1：CLAUDE.mdを「削る／残す」で仕分ける

いま書いてある行を、次の基準で仕分けます。

判定対象となる記述例
削るファイルを見ればわかること「このリポジトリはReactで書かれています」
削る一般的な作法の押しつけ「変数名はわかりやすくすること」
削る細かい禁止事項の羅列「コメントは1行まで」「絵文字を使うな」
言い換える禁止形で書いた作法「〜するな」→「〜に合わせて」
残す外から見てわからない自社固有の事情「型定義は types.ts のみに置く」
残す安全・法務・セキュリティにかかわる制約「本番DBへの書き込みは禁止」「顧客名を外部に出さない」
切り出す特定作業のときだけ必要な長い手順リリース手順、検証手順、レビュー観点

判断に迷ったら、 「これはClaudeが自分で調べればわかることか？」 と問うてください。答えがイエスなら削ってかまいません。

ステップ2：長いスキルを分割する

1ファイルに全部書いたスキルがあるなら、目的ごとに分けます。入口のファイルには「どんなときに、どのファイルを読むか」だけを書き、詳細は別ファイルに逃がします。これが段階的開示の実装です。

ステップ3：例を減らし、道具の名前を整える

ツールや社内スクリプトを自作している場合、使用例を並べる前に、パラメータ名と選択肢を見直します。名前だけで意味が通るなら、例は不要になります。

ステップ4：仕様書を「実体」に置き換える

仕様のMarkdownを渡している箇所を、可能な範囲でテストコード、既存の実装、HTMLモックアップに置き換えます。「文章で説明した仕様」より「動く実体」のほうが、伝達の精度が上がります。

ステップ5：削ってから効果を測る

いちばん大事なのはここです。Anthropicの8割削除は、評価環境で性能低下がないことを確認したうえでの判断でした。 自分の環境でも、削る前と後で同じ作業を投げて結果を比べる のが安全です。

おすすめの進め方は、1回に1カテゴリだけ削ることです。たとえば「コメントに関する指示だけ削って1週間使う」。何か問題が出たら、その部分だけ戻せます。

移行チェックリスト

  • /doctor を実行し、提案内容を確認した
  • CLAUDE.mdから自明な記述と一般的な作法を削除した
  • 禁止形の指示を「合わせる基準」の書き方に言い換えた
  • 安全・法務にかかわる制約は残したことを確認した
  • 長いスキルを入口ファイルと詳細ファイルに分割した
  • システムプロンプトとツール説明文の重複を解消した
  • 手書きのメモ蓄積をやめ、自動メモリに任せる運用に変えた
  • 仕様のMarkdownをテスト・実装・モックアップに置き換えた
  • 削る前後で同じ作業を試し、結果を比較した

削ってはいけないもの

「8割削除」という数字だけが独り歩きすると危険なので、残すべきものを明確にしておきます。Anthropic自身も、スキルについて 「重要度がきわめて高い領域を除いて、過剰に縛らないこと」 という書き方をしています。裏を返せば、重要な領域は縛ってよいということです。

  • 安全にかかわる制約（破壊的な操作の禁止、本番環境の扱い）
  • 情報管理の制約（機密情報・個人情報の扱い、外部送信の可否）
  • 法務・コンプライアンス上の要件（表記義務、禁止表現）
  • 業界固有の規制や社内規程

これらは「モデルの判断力が上がったから不要」という話にはなりません。判断力の向上で不要になったのは、あくまで 成果物の作法にかかわる細かい指定 です。

非エンジニアの日常利用にどう効くか

Claude Codeを使わない人にも、この考え方はそのまま応用できます。

場面従来やりがちだったことこれから
claude.aiのプロジェクト指示禁止事項を20行並べる目的と読者、自社固有の事情を数行で書く
社内共通プロンプトの配布全部門分のルールを1枚に詰め込む共通は最小限にし、部門別の手順は別ファイルへ
資料作成の依頼「こういう構成で」と例を細かく指定過去の良い資料そのものを添付する
文体の指定「である調禁止」「体言止め禁止」と列挙「この既存文書と同じトーンで」と基準を渡す

要するに、 禁止リストを育てるのをやめて、判断材料を渡す という一点です。Claude Coworkでの指示文も同じ考え方で整理できます。3つのサービスの違いは Claude・Claude Code・Coworkの違いと使い分け にまとめています。

モデル側の前提：Claude 5世代とは

今回の話が前提にしているのは、Claude 5世代のモデルです。2026年7月時点の顔ぶれは次のとおりです。

モデル位置づけ
Fable 5最上位。提供条件はプランによって異なる
Opus 52026年7月24日に提供開始。Fable 5に迫る性能を目指した上位モデル
Sonnet 5標準の主力モデル
Haiku 4.5軽量・高速モデル（4系）

なお、これまで上位モデルの定番だったOpus 4.8は前世代にあたり、Opus 5の登場でその座を譲りました。Opus 5はClaude Maxの既定モデルとなり、Claude Proでも利用できる最上位モデルになっています。

今回のコンテキストエンジニアリングの新ルールは、こうしたClaude 5世代のモデルを前提にしたものです。旧世代のモデルを併用している場合は、モデルごとに指示の効き方が変わる点に留意してください。

各モデルの詳しい使い分けは Claudeのモデル選び方ガイド 、Fable 5の提供条件は Claude Fable 5とは を参照してください。プランごとの料金は Claude料金プラン完全ガイド にまとめています。

まとめ

  • Anthropicは、Claude Opus 5やFable 5向けにClaude Codeのシステムプロンプトを 80%以上削除 し、コーディング評価に計測可能な低下がなかったと公表した
  • 過剰な制約は、矛盾する指示を生み、モデルが本題に使うべき思考を奪う
  • 新しい定石は「ルールを与える」から 「判断に任せ、判断材料を渡す」 への転換
  • CLAUDE.mdは軽く保ち、自明なことは書かず、自社固有の落とし穴に集中する
  • 長い指示は1枚にまとめず、必要なときに読み込ませる 段階的開示 の形にする
  • 仕様は文章より、テスト・実装・モックアップという 実体 で渡すほうが精度が高い
  • ただし安全・法務・情報管理にかかわる制約は残す
  • 見直しは /doctor から始め、1カテゴリずつ削って効果を比較する

Opus 4系のころに書いたルールは、当時は正しい判断でした。それを今のモデルに合わせて手放していくことが、Claude 5世代を使いこなす最短ルートになります。

参考リンク