コンテキストエンジニアリング - Claude Codeのシステムプロンプト80%超を削除。性能低下なしとAnthropic anchor left anchor right

Jul 26 2026 AIニュース

Claude Codeのシステムプロンプト80%超を削除。性能低下なしとAnthropic

anchor left anchor right

コンテキストエンジニアリング の考え方は、Claude 5世代モデルの登場で「指示を足す」から「判断に任せる」へと大きく舵を切りました。

📖 この記事で分かること

  • Anthropicが指示の8割超を削った経緯と結果
  • 「過剰制約」から判断委譲への設計転換の中身
  • CLAUDE.mdとスキルの新しい書き方の指針
  • 既存の設定ファイルを見直す具体的な手順

💡 知っておきたい用語

  • システムプロンプト: AIに毎回渡す「仕事の前提説明書」。新人に渡す業務マニュアルに近い立ち位置です。
  • CLAUDE.md: リポジトリごとに置く申し送りメモ。「このコードベースの癖」を書き残すノートです。
  • 段階的開示: 最初に全部渡さず、必要になった時点で情報を取りに行かせる設計の考え方です。

最終更新日: 2026年7月26日

▶ 公式ページ

コンテキストエンジニアリング - Claude Codeのシステムプロンプト80%超を削除。性能低下なしとAnthropic

Anthropicが自社の指示文を8割超削った

この記事のポイント

  • Anthropicが2026年7月24日、Claude 5世代モデル向けのコンテキスト設計指針を公開しました。
  • Claude Codeのシステムプロンプトの80%超を削除しても、社内コーディング評価で測定可能な性能低下はなし。
  • 対象はClaude Opus 5・Claude Fable 5など(2026年7月時点)。診断コマンド claude doctor で自分の設定を点検できます。

Anthropicは2026年7月24日、公式ブログで「Claude 5世代モデルにおけるコンテキストエンジニアリングの新しいルール」を公開しました。執筆はMember of Technical Staffの Thariq Shihipar 氏です。

記事の中核は数字ひとつに集約されています。Claude Opus 5 や Claude Fable 5 といった Claude 5 世代モデル向けに、同社は Claude Code のシステムプロンプトの80%超を削除しました。それでも社内のコーディング評価では、測定可能な性能低下は確認されなかったとしています。

削減の理由は性能改善のためではありません。同社は自分たちが Claude Code を「過剰に制約していた(overconstraining)」と認識したと述べています。しかもそれはシステムプロンプトだけの話ではなく、CLAUDE.md ファイルでもスキルでも同様に起きていた、という自己評価です。

「ルールを与える」から「判断に任せる」へ

今回の指針は、旧来のアプローチと新しいアプローチを対比する形で提示されています。公式が挙げた対比は次のとおりです。

これまでのアプローチ Claude 5世代でのアプローチ
明示的なルールを与える Claudeの判断に任せる
ツールの使用例を書く ツールのインターフェース自体を良く設計する
文脈を最初に全部入れる 段階的開示を使う
指示を繰り返す シンプルなツール説明にする
CLAUDE.mdに記憶を保存する auto-memory機能を使う
単純なMarkdown仕様 リッチな参照(HTML・コード・ルーブリック)を渡す

一貫しているのは、指示の総量を増やす方向から、モデルが自力で判断・探索できる環境を整える方向への転換です。使用例を列挙する代わりにツールの設計そのものを直す、という項目はその典型で、プロンプトで補っていた不足をインターフェース側の課題として扱い直しています。

同じ発想が「文脈を最初に全部入れる」の否定にも表れています。前もって全部渡すのではなく、必要になった時点で取りに行かせる。この段階的開示は、モデルの文脈長が伸びた環境ほど効いてくる考え方です。

CLAUDE.md・スキル・参照の書き換え方

具体的な推奨として、公式は用途ごとに書き方を分けています。

システムプロンプトは、プロダクトの文脈と運用上のゴールを記述するものと位置づけられました。Claudeを使って開発する側のユーザーは、基本的にここに手を入れない前提です。

CLAUDE.md については明確な配分の指示があります。軽量に保ち、リポジトリが何のためのものかは簡潔に書く。そのうえで「トークンの大半はコードベース内の落とし穴(gotchas)に使え」としています。一般論を書き並べるのではなく、そのリポジトリ固有の引っかかりどころに紙面を割け、という配分です。

スキルは、過剰に制約する指示ではなく「必要なときにClaudeが情報を見つけられるようにする軽量なガイド」として作ることが推奨されています。

参照(リファレンス)では、コードベースの仕様を優先する方針が示されました。「デザインの説明やスクリーンショットより、HTMLモックアップの方が一般に良い結果を生む」という記述があります。伝えたい対象がコードで表現できるなら、散文で説明するよりコードそのものを渡したほうが精度が出る、という判断です。

自分の設定が適正サイズかを確かめる手段として、診断コマンド claude doctor が案内されています。スキルやCLAUDE.mdの適正サイズ化(rightsize)に使えるとされていますが、具体的な判定基準や出力形式は今回の記事では明示されていません。

運用中のプロジェクトに何が起きるか

影響を受けるのは、Claude Codeを本格的に運用してきたチームほど大きくなります。長く使うほどCLAUDE.mdは肥大し、失敗するたびに禁止事項を足していくのが自然な運用だからです。今回の指針は、その積み上げが Claude 5 世代では逆に働きうると示唆しています。

一方で、削減が常に正解という話ではありません。公式が「測定可能な性能低下がなかった」と述べているのは、あくまで同社の社内コーディング評価における結果です。プロジェクト固有の制約(コーディング規約や社内ルールの遵守など)が評価対象に含まれていたかどうかは、今回の記事からは分かりません。自分たちの現場で同じ削減率が安全かは、実際に試して確認する領域として残ります。

現実的な進め方は、いきなり8割削るのではなく、CLAUDE.mdを「リポジトリの説明」と「落とし穴」に仕分けし、前者を圧縮して後者に寄せる作業から始めることです。

編集部の見方

編集部は、この発表で今すぐ効くのは新モデルへの乗り換えではなく、手元のCLAUDE.mdとスキルの棚卸しだと見ています。

  • 根拠1: システムプロンプトの80%超を削っても測定可能な性能低下がなかったという結果は、指示の量と出力品質が比例しないことを、モデルの提供元自身のデータで示しています。
  • 根拠2: 過剰制約していたと認めているのは、モデルの挙動を最もよく知るAnthropic自身です。一般の利用者が積み上げた設定ファイルが、それより整理されている可能性は高くありません。
  • 根拠3: claude doctor という点検手段が同時に案内されているため、棚卸しの着手コストが低く抑えられています。

この見方が変わる条件は、対象モデルの世代です。今回の指針はClaude 5世代モデルを前提にしています。旧世代のモデルを併用している環境では、削った指示が実際に効いていた可能性が残るため、一律の削減は当てはまりません。世代混在で運用しているなら、削減はモデルごとに切り分けて検証する必要があります。


よくある質問

Q: 今使っているCLAUDE.mdをすぐに削るべきですか?

A: 一括削除は推奨されません。公式が示しているのは配分の指針で、リポジトリの説明を簡潔にし、トークンの大半を落とし穴の記述に充てる形です。まず仕分けから始め、削除の影響は実際の作業で確認するのが安全です。

Q: システムプロンプトは自分で書き換えていいのですか?

A: 今回の指針では、システムプロンプトはプロダクトの文脈と運用上のゴールを記述するものとされ、Claudeを使って開発するユーザー側は基本的に手を入れない前提が示されています。調整の主戦場はCLAUDE.mdとスキル、そしてツールの設計側です。

Q: 旧世代のモデルでも同じことが言えますか?

A: 今回の記事はClaude 5世代モデルを対象としています。旧世代モデルに同じ削減が当てはまるかどうかは、記事内では言及されていません。


まとめ

Anthropicは2026年7月24日、Claude 5世代モデル向けのコンテキスト設計指針を公開し、Claude Codeのシステムプロンプトの80%超を削除しても社内評価で測定可能な性能低下がなかったと明らかにしました。指示を足して制御する設計から、モデルが判断・探索できる環境を整える設計への転換が軸になっています。CLAUDE.mdは落とし穴の記述に、参照はコードやHTMLモックアップに寄せるのが新しい配分です。運用が長いプロジェクトほど、設定ファイルの棚卸しで得られる余地は大きくなります。


【用語解説】

  • コンテキストエンジニアリング: モデルに渡す情報の中身・量・渡すタイミングを設計する取り組み。プロンプトの文面だけでなく、参照資料やツール設計まで含みます。
  • 落とし穴(gotchas): そのコードベース特有の、知らないと踏み抜く仕様や制約。一般的な作法ではなく、固有の引っかかりどころを指します。
  • auto-memory: 記憶を手動でファイルに書き残す代わりに、必要な情報を自動で保持・参照する仕組み。

引用元:


この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。

anchor left anchor right
KOJI TANEMURA

15 年以上の開発経験を持つソフトウェアエンジニア / テクノロジーライター。AI エージェントの実務活用を研究し、現場や経営者向けセミナーでその知見を発信。本メディア tech-noisy.com では、一次情報に基づく最新ニュース・解説記事を執筆。また、音楽生成 AI による DJ パフォーマンスを企業イベントで行うなど、テクノロジーと表現の融合も探求している。