Claude Codeのシステムプロンプトを80％削減——Opus 5がそれでも72％増加した理由

はじめに

Anthropicは先ごろ、Claude Codeが最新モデルにコンテキストを提供する方法に大きな変革を加えたと発表しました。

Claude Opus 5、Claude Fable 5、その他の上位Claude 5モデルに対し、同社は以前のモデルを正しく動作させるために使われていたシステムプロンプトの内容の80%以上を削除したと述べています。またAnthropicは、この簡略化によってコード評価に測定可能な性能低下は見られなかったとも述べています。

一見すると単純な話に思えます。すなわち、強力なモデルほど細かいルールは少なくて済む、と。

ところが、独立系開発者の陳誠（@chenchengpro）氏が、Claude Codeが複数のモデルバージョンに対して生成した出力コンテキストをキャプチャし、驚くべき推移を報告しました。

Opus 4.8からOpus 5にかけて、測定されたプロンプトの内容は約72%増加しています。

一見すると、Anthropicの「80%以上削除」という主張と開発者の「72%増加」という結果は矛盾しているように思えます。

しかし、そうではありません。

この2つの数字は異なる基準を用いており、Claude Codeの変革プロセスの異なる側面を説明しています。Anthropicが述べているのは、旧来の高度に規定されたプロンプトアーキテクチャからの脱却です。一方、開発者が比較しているのは、Opus 5と、特定のキャプチャ設定におけるOpus 4.8で使用された例外的にコンパクトなプロンプトです。

Claude Codeは確かに大量の古い命令フレームワークを削除しました。その後Opus 5は、モデルの自律性が高まるにつれて顕在化する行動を制御するための、規模の小さい新たなターゲットを絞った制約を獲得しました。

Anthropicが古いプロンプト内容の80%以上を削除

Anthropicの公式説明は、多くのエージェント開発者が認識している問題から始まります。それは、命令が積み重なっていくことです。

初期のモデルがあるエラーを繰り返すたびに、プロダクトチームはルールを追加しました。不要なコメントを書けばコメントルールを。不要な計画ドキュメントを作成すればドキュメントルールを。ツールを誤用すればツール使用例を。作業成果の検証を怠れば、さらに検証命令を追加しました。

時が経つにつれ、システムプロンプトは、ある時点で発生した問題にその都度対処するために寄せ集められた従業員マニュアルのようになり始めました。

このアプローチは初期のモデルには役立ちましたが、新たな問題も引き起こしました。

命令の重複が摩擦を生む

Claude Codeが受け取るのは単一のプロンプトだけではありません。その作業コンテキストには以下が含まれる可能性があります。

• プロダクトシステムプロンプト
• ツール定義
• CLAUDE.mdファイル
• ルール
• スキル
• メモリ
• ユーザー指示
• コードリポジトリファイル
• コマンドとツールの出力

複数のレイヤーの命令が重複したり、互いに微妙に矛盾したりする場合、モデルはどの命令を優先すべきか判断するために推論のリソースを費やさなければなりません。

例えば、あるレイヤーは適宜ドキュメントを追加するよう指示し、別のレイヤーは明示的に要求されない限りコメントやドキュメントを作成しないよう指示するかもしれません。そしてプロジェクトファイルには、同じ動作をカバーする3つ目のルールが追加されている可能性もあります。

モデルは最終的に正しい結果を導き出せるかもしれませんが、コーディングタスクが始まる前から、コンテキストは不必要な作業を強いられているのです。

モデルの更新により、局所的な判断への依存が可能に

Anthropicは、コメントとドキュメントに関する明確な例を示しています。

旧バージョンのClaude Codeは、品質の低いコメントや不要な計画ファイルを防ぐために、厳格で詳細な制限を使用していました。一方、更新された指示ははるかに簡潔です。周囲のプロジェクトのスタイル（命名習慣、イディオム、コメント密度を含む）に合わせてコードを記述するよう指示しています。

この変更により、判断の根拠がグローバルなルールから局所的な証拠へと移行しました。

システムはClaudeに「コメントは常に望ましくない」と伝える代わりに、リポジトリ内の既存のコードがどのように意図を伝えているかを確認するよう求めています。

これが、プロンプトの簡略化の背後にある、より広範なパターンです。

旧来の方法：
発生しうる様々なエラーを記述し、事前に禁止する。

新しい方法：
プロダクトの役割、ツール、境界、関連する証拠を提供し、
モデルがそれらの制約内で自ら判断できるようにする。

Anthropicは、古いシステムプロンプトの80%以上を削除しても、コード評価の結果に測定可能な低下は見られなかったと報告しています。

この結果は、命令が重要でなくなったことを意味するわけではありません。効果的な命令が変化したことを意味しています。

コンテキストエンジニアリングの新しいルール

Anthropicの再設計は、いくつかの「過去と現在」の対比で要約できます。

これらの変化は、Anthropicの内部システムプロンプトにのみ当てはまるものではありません。開発者がCLAUDE.md、スキル、ツール、カスタムエージェントフレームワークをどのように維持すべきかにも影響を与えます。

CLAUDE.mdをプロジェクト固有の事実に集中させる

CLAUDE.mdファイルは、Claude Codeセッションの開始時に読み込まれます。そのため、Claudeがリポジトリについて継続的に把握しておく必要がある情報を配置するのに適しています。

適切な内容の例：

• コードからは推測できないアーキテクチャ上の決定。
• 必要なビルドおよびテストコマンド。
• リポジトリ固有の規約。
• 重要なディレクトリと所有権の境界。
• プロジェクトで必要とされる、または禁止されているライブラリ。
• 明白ではないセキュリティやデプロイの制約。

あまり役に立たない内容の例：

• Claudeが既に知っている一般的なアドバイス。
• たまにしか使わない冗長な操作手順。
• パッケージファイルやソースコードから直接確認できる事実。
• ツール、スキル、ユーザープロンプトで繰り返されている同じ命令。
• リクエストのたびにコンテキストを消費する大きな例。

Claude Codeの現在のドキュメントでは、CLAUDE.mdは簡潔に保ち、手続き型またはリファレンス集約型の資料は、オンデマンドで読み込まれるスキルファイルに移すことを推奨しています。

集中管理されたファイルは、以下のようになるかもしれません。

# プロジェクトガイド

- すべてのパッケージ管理コマンドはpnpmを使用する。
- コード変更の報告が完了する前に、`pnpm test`と`pnpm lint`を実行する。
- 公開APIは`packages/sdk`以下に定義する。破壊的変更は避けること。
- データベースマイグレーションには、対応するロールバックファイルを含めること。
- `src/generated`以下の生成ファイルは直接編集しないこと。

一般的なソフトウェアエンジニアリングの振る舞いを詳細に説明する必要はありません。

長い手順はスキルに移行する

スキルは、再利用可能な命令をSKILL.mdファイルにパッケージ化します。そのスキルが使用されるときにのみ完全な内容が読み込まれるため、無関係なタスクのたびにコンテキストを消費することはありません。

これにより、スキルは以下のようなワークフローに適したものになります。

• プルリクエストレビュー。
• リリース準備。
• セキュリティチェック。
• フロントエンド検証。
• データベースマイグレーション。
• インシデント調査。
• ドキュメント公開。

最小限のレビュースキルは、次のように構成できます。

description: プルリクエストの正確性、リグレッション、欠落しているテストをレビューする。

プルリクエストレビュー

1. 完全な差分と影響を受けるテストを読む
2. スタイルの好みではなく、具体的な欠陥を優先的に特定する
3. 最小限の関連テストスイートを実行する
4. 公開動作や互換性が変更されていないか確認する
5. 重要度に応じて発見事項を報告し、ファイル参照を添付する

この手順はレビュー作業の開始時にのみ利用可能ですが、Claude に変数名の変更だけを依頼する場合に負荷をかけることはありません。

これは段階的な開示です：重要なポイントで適切なコンテキストを提供します。

重複指示の削除

通常、各指示は1つの権威ある場所にのみ存在すべきです。

例えば：

• プロダクトレベルの動作はシステムプロンプトに
• プロジェクトレベルの事実は CLAUDE.md に
• 再利用可能な手順はスキルに
• ツール固有の要件はツール定義に
• 確定的な実行はフック、権限、テスト、またはスクリプトに

各階層で同じルールを繰り返しても効果は高まらず、むしろコンテキストサイズが増加し、表現の差異が生まれ、その後のメンテナンスが困難になります。

別の指示を追加する前に、自問してください：

1. これは既に他の場所で表現されているか？
2. Claude はコードベースからそれを推論できるか？
3. これは事実か、手順か、それともハードな実行要件か？
4. 毎回のリクエストで読み込む必要があるか？
5. テストやフックは、テキストによる説明よりも確実にそのルールを実行できるか？

より良いツールの設計、より多くの例示の代わりに

初期のプロンプトエンジニアリングガイドラインは、多くのツール使用例を提供することを推奨していました。

Anthropic は、例示が高度なモデルをデモンストレーションのパスに従わせる可能性があると考えています。モデルは現在のタスクにより適したパラメータやツールの組み合わせを選択する代わりに、サンプルを模倣するかもしれません。

適切に設計されたツールは、そのインターフェースを通じて使用方法を明確に伝えるべきです：

• 明確なパラメータ名
• 正確な説明
• 明示的なオプションフィールド
• 有用な列挙値
• 予測可能な出力
• 実行可能なエラーメッセージ

例えば、以下のような列挙値：

{
"status": "pending | in_progress | completed"
}

長い段落よりも、有効な状態遷移ルールを直接的に伝えます。

いくつかの固定された例を含めること。

フォーマットや境界動作が曖昧になる可能性がある場合、例は依然として有用です。この変更は「例を決して使わない」という意味ではなく、「例を適切に設計されたインターフェースの代わりに使わない」という意味です。

実行可能な参照の提供

新しいモデルClaudeモデルは、より豊富な参照に基づいて直接作業できます。

開発者は各要件を文章で説明する代わりに、以下を提供できます：

• 既存のコード
• テストケース
• 失敗するコマンド
• HTMLプロトタイプ
• スクリーンショット
• パターン
• デザイン成果物
• ベンチマークスクリプト
• サンプル入力と期待される出力

実行可能なテストは、「実装が正しくあるべきだ」という数段落の説明よりも、成功基準を明確に定義できます。

これにより、コンテキストエンジニアリングは大規模な操作マニュアルの作成から、より良い作業環境の設計へと移行します。

独立したキャプチャが72%のリバウンドを発見

Anthropicが80%削減を発表した後、開発者チェン・チェンは、Claude Codeが実際に複数のOpusモデルに送信している内容をテストしたと報告しました。

彼はCLIをローカルサーバーにリダイレクトし、送信リクエストの内容を記録しました。彼が公開した文字数は以下の通りです：

Opus 4.7：15,225 文字
Opus 4.8：4,467 文字
Opus 5：7,694 文字

これらの数字は3つの異なる比較を示しています：

したがって、今回キャプチャされたOpus 5のプロンプトはOpus 4.8よりはるかに長いものの、Opus 4.7の約半分の長さでした。

これらは文字数であり、トークン数ではありません。また、これらはあくまで1回キャプチャされたClaude Codeの設定を表すものであり、すべてのリクエストの一般的な仕様ではありません。

Claude Codeはツール、設定、機能、製品状態に応じてコンテキストを動的に構成できます。正確な送信内容はバージョンや環境によって変化する可能性があります。

80%と72%の両方の数字が正しい可能性がある理由

異なるベースラインを区別すれば、この明らかな矛盾は解消します。

Anthropicの数字が示すのはアーキテクチャの整理

Anthropicは、旧来の指示密集型設計と比較して、高度なClaude 5モデルが使用するシステムプロンプトの80%以上を削除したと述べています。

この数字は、より新しいコンテキストエンジニアリングアーキテクチャへの移行中に削除されたレガシープロンプトの量に関するものです。

すべてのOpus 5リクエストが文字数ベースですべてのOpus 4.8リクエストより80%短いと主張しているわけではありません。

開発者の数字は2つの隣接するキャプチャの比較

72%という数字は、記録されたOpus 5リクエストと、開発者がキャプチャした異常に小さいOpus 4.8リクエストを比較したものです。

Opus 4.8は3つのモデル比較の中で最低点だったようです。一方Opus 5は

対象を絞ったガイダンスを追加しつつ、全体の長さは旧バージョンのOpus 4.7パスよりはるかに短いままです。

したがって、両方の主張は共存できます：

旧プロンプトアーキテクチャ → 高度なモデルプロンプト：
全体として大幅に削減。

Opus 4.8 キャプチャ → Opus 5 キャプチャ：
最小測定バージョンからの部分的な増加。

Claude Code は異なるプロンプトパスを維持しているようだ

開発者の調査では、Claude Code の実装に2つのプロンプトパスが含まれていることも報告されています。

ルーティング関数は、古いモデル識別子に対してより詳細なレガシープロンプトを選択し、新しいモデルに対しては簡略化されたプロンプトを選択します。

報告されたロジックによると、旧バージョンのOpus、Sonnet、Haiku、Claude 3シリーズなどのモデルは詳細なプロンプトパスにあり、Opus 4.8、Opus 5、Fable 5、その他の新しいモデルはより短いアーキテクチャを使用します。

このルーティングの詳細はサードパーティの調査によるものであり、Anthropic の公式アーキテクチャドキュメントではありません。

しかし、これはAnthropicの公開説明と一致しています：より強力なモデルは規範的な枠組みが少なくても動作可能であり、古いモデルは新しいモデルがコンテキストから推論できる明示的な制約を依然として必要とする可能性があるということです。

Opus 5 に新たな対象を絞ったガイダンスが必要な理由

Claude Opus 5 は、長期的な自律作業において初期のOpusモデルよりも強力です。

この能力は、大規模なタスクでは有用だが、小規模なタスクではコストが高くついたり注意を散漫にさせたりする行動を導入する。

Anthropic公式のOpus 5プロンプトガイドでは、調整が必要となる可能性のある以下の点が強調されている：

• 回答の長さと冗長性
• ユーザー向けの進捗更新
• 文書成果物の長さ
• タスクの範囲
• 過剰な検証
• サブエージェントへの委任
• 自己修正

報告された開発者の差異分析によると、成果物の作成と修正対応を中心に、大量の新しいコンテンツが出現している。

正確な非公開テキストは公式の公開仕様と見なすべきではないが、これらのカテゴリはAnthropicが公開したOpus 5ガイドラインと非常に一致している。

進捗更新が頻繁になりすぎる可能性

長時間の移行やリポジトリ全体の調査では、進捗報告は有用である。

小さな変更では、頻繁な説明はレイテンシとトークン消費を増加させるだけで、コードは改善されない。

有用なエージェント戦略では、これら2つのケースを区別する必要がある：

長時間かつマルチステージの作業では進捗を報告する。その際、更新がユーザーの状況把握や意思決定に役立つ場合に限る。
ルーティンのツール呼び出しのたびに説明しない。

目標は無言になることではなく、バランスの取れたコミュニケーションである。

高性能モデルはタスク範囲を過度に拡大する可能性

高度なコーディングエージェントは、リクエストされた変更を完了する一方で、関連する問題に気づくことがある。

この積極性が価値を持つ場合もある。一方で、単純なリクエストが、ユーザーから承認されていない大規模なリファクタリングに発展することもある。

Opus 5では、モデルの能力が高いからこそ、タスクの境界がより重要になる。

追加の作業を見つけるのが得意だからだ。

明確なリクエストは次のように表現できる：

報告された問題と、直接影響を受けるテストのみを修正する。
関連のないモジュールをリファクタリングしたり、パブリックAPIを拡張しない。

境界条件は、各実装ステップを指定することなく、「完了」の意味を定義する。

サブエージェントはコストを増加させる可能性

Anthropicによると、Opus 5は以前のモデルよりもサブエージェントを使用する傾向が強い。

作業が真に独立しており、並列処理に十分な規模である場合、委任は価値がある。タスクが少数のツール呼び出しで直接完了できる場合、委任は非効率である。

公式ガイドラインは、明確な条件または確実な制限を設けることを推奨している。

実用的な指示は次のとおり：

サブエージェントは、大規模で独立したワークフローのみに使用する。
自分で直接完了できる作業を繰り返したり検証したりするためにサブエージェントを作成しない。
同時に動作するエージェントの数を少なく保つ。

これにより、有用な機能を無効にせずに、コストと時間を制御できる。

繰り返しの自己修正は無駄を生む可能性

Opus 5は、自身の多くのエラーを発見し修正するように設計されている。

「すべてを再確認」「もう一度検証」「別のエージェントで再検証」を繰り返し要求するプロンプトは、モデルの本能的な行動と重なる。

Anthropicは、冗長な検証命令を削除することで、品質を低下させずに無駄なトークン消費を削減できると述べている。

検証は依然として重要だが、具体的な証拠に基づくべきである：

• 関連するテストを実行する
• プロジェクトをコンパイルする
• レンダリングされたページを確認する
• 出力を仕様と比較する
• 最終的な差分を確認する

非効率的なパターンは、客観的なチェックが既に合格しているにもかかわらず、追加の抽象的な熟考を要求することである。

開発者は今どのように調整すべきか

公式ガイドラインと独立したテストは、同じ実践的な教訓を指している：コンテキストは機能を中心に整理されるべきであり、懸念のために積み上げられるべきではない。

1. コンテキストスタック全体をレビューする

Claudeに影響を与える可能性のあるすべての要素をチェックする：

• CLAUDE.md
• ルール
• スキル
• ツールの説明
• フック
• MCPサーバー指示
• ユーザープロンプト
• エージェントフレームワーク内のカスタムシステムプロンプト

重複、競合、時代遅れ、および広範すぎる指示を探す。

1. 非自明なプロジェクトルールのみを CLAUDE.md に保持する

Claudeがソースファイル、パッケージマニフェスト、または標準仕様から直接取得できる情報は削除する。

それ以外では見えない意思決定内容を保持する。

1. フローをスキルに移行する

説明が固定された事実ではなく、繰り返し可能なシーケンスを記述している場合、それをスキルに変換する。

これにより、デフォルトのコンテキストサイズが縮小され、ワークフローが再利用可能になる。

1. ツールの説明はツール内に配置する

システムプロンプト、CLAUDE.md、および毎回のユーザーリクエストでツールのパラメータルールを繰り返さない。

ツールには、明確に表現されたアーキテクチャと正確な説明を提供する。

1. 長々しい説明の代わりにテストと参照を使用する

可能な限り、成功を定義する実際の成果物を提供する。

失敗したテスト、プロトタイプ、アーキテクチャ、または期待される出力は、「結果がどうあるべきか」を説明する長文よりも正確である。

1. Opus 5の積極的な行動に境界を設定する

小規模なタスクでは、以下を明確にする：

• 許可される範囲
• サブエージェントが適切かどうか
• どの程度の進捗説明が有用か
• 必要な検証
• エージェントがいつ停止すべきか

巨大な汎用マニュアルを復元して対応しない。

1. Claude Codeの診断ツールを実行する

Anthropicは、現時点でのベストプラクティスはClaude Codeのドクターワークフローに組み込まれていると述べている。

シェルで次のコマンドを実行する：

claude doctor

Claude Code内で、次を実行する：

/doctor

診断では、インストール、設定、MCPサーバー、コンテキスト使用状況を確認できる。現在のバージョンでは、大きすぎる、または無効なコンテキスト設定の特定にも役立つ可能性がある。

プロジェクトのガイダンスを盲目的に削除するのではなく、その提案をレビューすべきである。

コンテキストのビフォーアフター例

過負荷な設定

# CLAUDE.md

編集前に必ずリポジトリを確認する。
常にクリーンなコードを書く。
すべての変更をテストする。
不要なコメントは絶対に追加しない。
不要なファイルは絶対に追加しない。
以下の例に厳密に従ってテストツールを使用する...

[レビュー、リリース、テスト、ツールの説明に関する数ページ]

このファイルには、汎用的な期待、繰り返し可能なフロー、およびタスクごとに適用範囲が異なるツールドキュメントが含まれている。

焦点を絞った設定

# CLAUDE.md

- pnpmを使用する；このリポジトリはnpmやyarnをサポートしていない。
- `packages/sdk` ではパブリックAPIの互換性が必要。
- コード変更完了前に `pnpm test` と `pnpm lint` を実行する。
- リリース手順は `/release-check` スキルにある。
- セキュリティレビュー手順は `/security-review` スキルにある。

小さなファイルはプロジェクト固有の情報を保持し、条件付きフローをスキルに委任する。

これこそがプロンプト削減の実際の意味である：永続的な指示を減らし、構造化されたコンテキストを増やす。

測定結果は何も証明しない

レポート内の文字数は有用だが、過剰に解釈すべきではない。

それらは以下を証明しない：

• すべてのOpus 5リクエストが常に正確に7,694文字を含むこと
• システムプロンプトの長さが直接コーディング品質を予測すること
• 短いプロンプトが自動的に優れていること
• Anthropicの80%というデータが偽であること
• Opus 5がセッションごとにOpus 4.8より72%多い総コンテキストを必要とすること
• キャプチャされたテキストが製品使用におけるすべての動的指示を含んでいること

プロンプトの長さは変数の1つに過ぎない。

指示の品質、コンテキストの順序、プロンプトキャッシュ、ツール設計、スキル、リポジトリの証拠、モデル能力がすべて結果に影響する。

簡潔なプロンプトは曖昧になる可能性があり、長いプロンプトは正確になる可能性がある。目標は最小の文字数ではなく、モデルが必要な情報と境界を確実に提供する最小のコンテキストである。

エージェント構築者へのより大きな教訓

モデルが向上するにつれて、指示設計はマイクロマネジメントからガバナンスへと移行する。

古いエージェントは、各ステップの実行方法に関する詳細な説明を必要とすることが多かった。より強力なエージェントは、ツールと証拠からより多くの方法を発見できる。

これによって人間の役割がなくなるわけではない。人間の取り組みが最も価値を発揮する場所が変わるのだ。

エージェント構築者は、期待される行動を列挙することに費やす時間を減らし、以下の定義により多くの時間を費やすべきである：

• 利用可能なツール
• 権限の境界
• 事実のソース
• 成功基準
• 範囲制限
• コスト管理
• エスカレーションパス
• 確実性チェック

モデルは、各アクションに対するアドバイスを減らす一方で、何ができるか、何を証明すべきか、いつ停止すべきかについて、より明確な権限を必要とする。

よくある質問

Anthropicは本当にClaude Codeのシステムプロンプトを80%以上削除したのか？

Anthropicは公式に、Claude Opus 5やClaude Fable 5などの高度なモデル向けにシステムプロンプトの80%以上を削除したと述べている。

同社はまた、この変更によってコード評価に測定可能な損失が生じていないと述べている。

なぜキャプチャされたOpus 5のプロンプトはOpus 4.8よりも72%長いのか？

72%という数値はOpus 4.8を基準としている。開発者のキャプチャでは、Opus 4.8のプロンプトは異常にコンパクトで4,467文字であったのに対し、Opus 5は追加のターゲット指示を受けて7,694文字と測定された。

15,225、4,467、7,694という数値はAnthropicの公式データか？

いいえ。これらのデータは、Claude Code CLIをローカルサーバーにリダイレクトし、送信リクエストを確認した独立した開発者によって報告されたものである。Anthropicはこれらの文字数を固定または標準の合計として公表していない。

Opus 5のプロンプトはそれでもOpus 4.7のプロンプトより短いのか？

報告されたキャプチャにおいては、その通りである。Opus 5の7,694文字のプロンプトはOpus 4.8より長いものの、Opus 4.7の15,225文字のプロンプトよりは約49.5%短い。

CLAUDE.md には何を残すべきか？

モデルがリポジトリから確実に推論できないプロジェクト固有の事実とルールを残す。長く条件付きのフローはスキルに移し、汎用的または重複した指示は削除する。

なぜ長いワークフローはスキルにするべきなのか？

スキルの詳細は必要な時にロードされ、すべてのリクエストで占有されるわけではない。これにより段階的な開示が可能になり、無関係なセッションがデフォルトのコンテキストにレビュー、公開、デプロイのフローを持ち込むのを防ぐ。

Opus 5は旧モデルよりも厳格なプロンプトを必要とするのか？

異なるプロンプトを必要とする。Anthropicは、冗長性、進捗状況の更新、タスク範囲、過剰な検証、サブエージェント生成、自己修正を、これらの動作が不必要なコストや時間を増加させる場合に制御することを推奨している。

Claude Codeのコンテキストが大きすぎるかどうかを確認する方法は？

シェルで claude doctor を実行するか、Claude Code内で /doctor を実行する。また、自動診断ではプロジェクト固有の要件をすべて判断できないため、CLAUDE.md、スキル、ツールの説明、重複した指示を手動で確認する。

関連ツール

• Claude Code：リポジトリ探索、編集、テスト、自動化のためのAnthropicのエージェントコーディング環境。
• Claude Code Skills：再利用可能なワークフローとリファレンスを SKILL.md ファイルにパッケージ化し、必要な時にロード。
• Claude Code 設定デバッガー：指示、スキル、フック、設定、MCPサーバーが機能しない原因の診断を支援。
• Claude Opus 5 プロンプトガイド：スコープ、冗長性、進捗、サブエージェント、検証などに関する公式のモデル固有ガイダンス。

訂正内容。

• Model Context Protocol：エージェントシステムと外部ツール・データソースを接続するためのオープンスタンダード。

関連リンク

• Claude 5 モデルコンテキストエンジニアリングの新ルール：80%削減と更新されたコンテキストエンジニアリングの原理に関するAnthropicの公式説明。
• Claude Opus 5 へのプロンプト：新しいモデルのプロアクティブ性とエージェント動作を制御するための公式ガイド。
• プロンプトのベストプラクティス：指示、ツール、推論、エージェントシステム、移行に関するAnthropicの広範なリファレンス。
• スキルを使用したClaude Codeの拡張：再利用可能なオンデマンドコンテキストを作成し整理するための公式説明。
• Claude Code 機能ガイド：CLAUDE.md、スキル、フック、サブエージェント、関連コントロールをいつ使用するかを説明。
• 開発者測定投稿：レポート内のシステムプロンプト文字数の引用元となる第三者スクリーンショット。

まとめ

Anthropicの80%削減と開発者が報告した72%の逆戻りは、異なる比較を説明している。Claude Codeは、高度なモデル向けのレガシーで高度に規範的な指示を大量に削除した。キャプチャされたOpus 5のプロンプトはその後、非常にコンパクトなOpus 4.8バージョンと比較して、ターゲット指示が追加された。

報告されたOpus 5のプロンプト長は、依然としてキャプチャされたOpus 4.7のプロンプトの約半分である。追加された指示は、Anthropicが公式に指摘するOpus 5の動作と一致している。すなわち、より多くの進捗説明、より広いタスク範囲、より頻繁なサブエージェント委任、より長い成果物、繰り返しの自己修正である。

開発者にとって有用な応答は、最短のプロンプトを追求することではない。CLAUDE.md を焦点を絞ったものに保ち、条件付きワークフローをスキルに移し、重複を排除し、ツールインターフェースを改善し、実行可能なリファレンスを提供し、範囲、コスト、完了に明確な境界を設定することである。

新しいコンテキストエンジニアリングのルールは「何が何でも少なく語れ」ではなく、「属する階層において、モデルが必要とする指示のみをロードせよ」である。