Anthropic Claude、Claude Codeのシステムプロンプトを80%削減。「ルールを増やす」定石に一石

Anthropic Claudeは、最新モデル向けにClaude Codeのシステムプロンプトを80%以上削減したにもかかわらず、社内のコーディング評価では測定可能な性能低下はなかったと報告した。7月24日の変更は、Claude Opus 5やClaude Fable 5を含む高度なモデルに適用される。これは、AIエージェントに関する広く浸透した前提を覆すものだ。より詳細な指示が、必ずしもより信頼できる振る舞いを生むわけではない。

Anthropicによれば、従来のClaude Codeでは、不適切なコメント、不要なドキュメント、安全でないファイル操作を防ぐために明示的なルールが必要だった。こうした保護策は、システムプロンプト、プロジェクト指示、スキル、ツール説明、メモリ、個々のユーザー要求にまたがって蓄積された。その結果、コンテキストには重複または矛盾する指示が含まれ得る状態になっていた。

Claude 5のコンテキストエンジニアリングは、現在では異なる前提から始まる。Anthropicは、能力の高いモデルに判断の余地を与え、より明確なインターフェースを設計し、専門的な指示は必要なときだけ読み込むことをチームに求めている。主な争点はもはやAnthropicと他のモデル提供者の競争ではない。規範的なプロンプティングと、選択的なコンテキストの対立である。

この違いはClaude Codeにとどまらず重要だ。開発者は、リポジトリを読み、ツールを呼び出し、ファイルを編集し、コードをレビューし、長時間のセッションを通じて状態を維持するエージェントを構築している。恒久的な指示はすべて、タスク、現在のファイル、ツール結果、ユーザーの意図と注意を奪い合う。

ただし、同社の証拠は依然として限定的だ。Anthropicは、「測定可能な性能低下はない」という主張の根拠となる評価スイート、ベースラインスコア、タスク分布、モデル別の結果を公開していない。80%の削減は大きいが、実務上どこまで通用するかは独立した検証を待つ必要がある。

Anthropic Claudeが、かつて不可欠に見えたルールを削除

今回の直接的な変更は、コンテキストウィンドウの拡大ではない。恒久的な指示レイヤーを大幅に小さくしたことだ。

Anthropicはコンテキストエンジニアリングを、ユーザーの直近のプロンプト以外でモデルが受け取るあらゆる要素の組み立てと説明している。そこには、システム指示、プロジェクトファイル、スキル、メモリ、ツール定義、会話履歴、取得された参照情報が含まれる。

システムプロンプトは、会話を通じてエージェントを形作る初期指示セットだ。振る舞い、ツール利用、応答スタイル、セキュリティ境界、実行環境に関する前提を定義できる。

Anthropicのコンテキストエンジニアリングに関するガイダンスによると、同社はOpus 5とFable 5向けのClaude Codeシステムプロンプトを80%以上削除したという。その後のコーディング評価でも、測定可能な性能低下は見られなかったとしている。

この発表は、指示が不要になったという意味ではない。むしろ、恒久的なルールと、別の場所に置くべき情報を切り分けている。セキュリティ境界、権限、ツールの契約、明示的なユーザー要件には、引き続き明確な表現が必要だ。

変わったのは、そのガイダンスを置く標準的な場所である。Anthropicは以前、詳細なコーディング、レビュー、ドキュメント作成、検証の振る舞いをメインプロンプトに組み込んでいた。そうした指示は、特定のタスクで不要な場合でもモデルに常に付随していた。

古いルールの一部は、限定的な失敗モードを制御しようとするものでもあった。Anthropicは、求められない限り複数段落のdocstringや計画文書を避けるようClaudeに指示していた以前のルールを例に挙げている。このルールは不要な出力を減らした一方で、複雑なコードにおける有用なドキュメントも抑制していた。

置き換えられた指示は、より短く、より文脈依存だ。Claudeは周囲のコードにあるコメント密度、命名、慣用表現に合わせるべきとされる。普遍的な出力パターンを一つ規定する代わりに、関連する基準をどこで見つけるべきかをモデルに示している。

この転換は、本稿の中心的な緊張を生む。詳細なルールは、その振る舞いが可視化され検証できるため、より安全に見えることがある。しかし、リポジトリ、ユーザー要求、またはタスクに例外が必要な場合、厳格な指示は誤りになり得る。

Claude Codeは、複数の重なり合うチャネルからも指示を受け取る。ユーザーが適切なドキュメントを求める一方で、グローバルルールがコメントを抑制しているかもしれない。あるスキルが検証を要求し、別のファイルがエージェントに余計な作業を最小化するよう指示する場合もある。

モデルは、実際のエンジニアリング上の問題に取り組む前に、こうした競合を解決しなければならない。したがって、テキストを増やすことは、単に有用な知識を追加するのではなく、新たな推論タスクを生み出す。

Anthropicはこの問題に対し、診断的な対応も追加している。同社によると、/doctorコマンドは、ユーザーがスキルやCLAUDE.mdファイルを適切な規模に調整するのに役立つ。これらのファイルは、リポジトリの慣例や繰り返し使われる指示を含む、永続的なプロジェクトコンテキストを提供する。

実務的なメッセージは、「プロンプトを削除せよ」よりも狭い。チームは、どの情報が本当にすべての要求に適用されるのかを特定すべきだ。それ以外の情報には、より正確なトリガー、配置場所、提供メカニズムが必要になる。

Claude 5のコンテキストエンジニアリングが選択的コンテキストを重視する理由

Anthropicは、モデルの判断力が向上すれば、恒久的な行動マイクロマネジメントの価値は下がると見込んでいる。

旧来のアプローチには理由があった。初期のコーディングモデルは、過剰なコメントを生成したり、不要な計画ファイルを作成したり、ツールを誤って扱ったり、例に過度に文字通り従ったりすることが多かった。詳細な指示は、取り得る振る舞いを狭めていた。

その制限にはトレードオフがあった。よくある失敗を一つ防ぐことが、異例のタスクに対する正しい応答を妨げる可能性がある。長いコメントの禁止は通常の編集では有効かもしれないが、複雑なアルゴリズムやセキュリティに敏感なコードに関する作業を損なうおそれがある。

Claude 5のコンテキストエンジニアリングは、その判断をタスクのより近くへ移す。モデルはユーザーの要求を受け取り、周辺コードを調べ、ローカルの慣例を適用する。AnthropicはこれをClaudeの「unhobbling」と呼ぶ。つまり、本来の目的を終えた制約をシステムから取り除くことだ。

この言葉を無制限の自律性と誤解すべきではない。Claude Codeは依然としてハーネスの内部で動作する。ハーネスとは、ツール、権限、コンテキスト、実行を管理する周辺ソフトウェアのことだ。Anthropicは、そのハーネス内の一つのレイヤーを簡素化している。

同社は複数の「以前と現在」の変更を示している。ルールは判断に、ツール例は表現力のあるインターフェースに、事前の指示は段階的開示に、反復は簡潔なツール説明に置き換わる。

段階的開示とは、すべてを初期コンテキストに置くのではなく、タスクで必要になったときに詳細情報を読み込むことを意味する。Claude Codeは現在、コードレビューや検証といった領域に専用スキルを使っている。

このアプローチは、継続的な注意コストを課すことなくアクセスを維持する。レビュー手順は詳細なまま残せるが、Claudeがレビューを実行するときに読み込まれる。通常のファイル編集で、手順全体を抱える必要はない。

Claude Codeはツールにも同じ原則を適用する。一部のツールでは遅延読み込みが使われ、最初は軽量な説明だけが公開される。完全なスキーマは、エージェントが検索を通じてそのツールを選択した後にのみ表示される。

Anthropicのコンテキストウィンドウガイドは、この区別が重要な理由を示している。プロジェクト指示、メモリ、スキル説明、ファイル、応答、隠れたランタイムコンテンツはすべて、同じ作業コンテキストを占有する。

大きなコンテキスト容量は、選択の問題を解消しない。モデルはより多くのトークンを受け入れられても、無関係、古い、または矛盾する情報を受け取る可能性がある。容量が答えるのは何が収まるかであり、何に注意を向けるべきかではない。

選択的コンテキストは、チームがリポジトリ知識をどう整理すべきかも変える。単一のCLAUDE.mdファイルを、あらゆるエンジニアリング上の好みを記した百科事典にすべきではない。Anthropicは、エージェントが適切なときに読み込める参照情報のツリーを推奨している。

この設計は、優れたソフトウェアアーキテクチャに似ている。安定したインターフェースは小さく保たれ、専門的な振る舞いは明示的な境界の背後に置かれる。エージェントは、すべての実装詳細を起動時に受け取ることなく、何が存在するかを学べる。

このモデルでは、ツール定義が特に重要になる。Anthropicは、例がモデルを既に示されたパターンへ誘導することで、探索を制約し得ると主張する。明確なパラメーターと状態定義は、一つの経路を指定することなく意図を伝えられる。

同社のTodoの例では、pending、in progress、completedといった列挙された状態を使う。アクティブな項目を一つだけ許可する制約は、有効なシステム状態を記述する。モデルは、そのインターフェース内で行動を選択できる。

これは、エージェントの信頼性がどこに宿るかという点で意味のある変化だ。従来、プロンプト作成者は主に文章を通じて信頼性をエンコードしようとしてきた。Anthropicは現在、インターフェース設計、コンテキストのルーティング、権限、モデルの判断により大きな責任を割り当てている。

本当の争点は、規範的プロンプティングとモデルの判断力

80%の削減は、観測されたエージェントの失敗すべてに、別の恒久的な指示を追加すべきだという信念に異議を唱える。

AIエージェントのチームは、しばしばミスに対してルールを追加する。エージェントがテストを省けば、プロンプトにテスト要件が加わる。無関係なファイルを編集すれば、別の段落でスコープを狭める。説明が過剰なら、冗長性を制限する指示が続く。

このプロセスはラチェットを生み出す。追加は削除よりも安全に感じられるため、指示は蓄積していく。古いルールが現行のモデル、ツール、ワークフローでなお改善をもたらすかを定期的に検証するチームは少ない。

Anthropic Claudeは現在、このラチェットが品質を下げ得ると主張している。問題はトークン消費だけではない。相反する指示は、モデルに優先順位の推定、例外の解釈、古い保護策と現在のユーザー意図の調整を強いる。

規範的プロンプティングは、チームが監査できるため、依然として魅力的だ。セキュリティレビュー担当者は明示的な禁止事項を見つけられる。プロダクトマネージャーはフォーマット規則を指し示せる。開発者は、要求に含まれたテキストを再現できる。

モデルの判断は柔軟性をもたらすが、予測は難しい。最小限のコメントを好むという一般的な方針があっても、複雑な関数にはドキュメントが必要だとClaudeに認識させられる。同じ裁量が、タスクごとに一貫しない選択を生む可能性もある。

したがって、Anthropicの主張の最も強い形は、モデルの能力に依存する。能力の低いモデルでは、依然として詳細な例、繰り返しの警告、狭いルールが必要かもしれない。複数モデルを混在させた導入では、すべてのエージェントが簡潔なガイダンスを等しく適切に解釈できると仮定できない。

これは、複数世代のモデルをサポートするチームに圧力をかける。Opus 5やFable 5向けに最適化した指示は、より古いモデルや小規模モデルには振る舞いの仕様が不足する可能性がある。古いモデル向けに書かれたプロンプトは、最新モデルを過度に制約するかもしれない。

バージョン管理されたコンテキストは、運用上の要件になる。チームは、どのルールが各モデルに適用されるか、評価がどう変化したか、共有指示がいつ価値を追加しなくなったかを把握する必要がある。さもなければ、簡素化は別の未検証の慣例になる。

この変更は、長期的な資産としてプロンプトテンプレートを販売する企業にも圧力をかける。長いテンプレートには有用な専門知識がエンコードされているかもしれないが、長さはもはや完全性の信頼できる代理指標ではない。その価値は、関連性、ルーティング、測定可能な結果に左右される。

カスタムエージェントを構築する開発者も同様の判断に直面する。Anthropicのシステムプロンプトに関するドキュメントは、完全なClaude Codeプリセット、最小限のデフォルト、完全にカスタムな指示を区別している。

完全版プリセットは、人間が作業を見守り、方向づけるコーディングエージェントに適している。異なるアイデンティティ、インターフェース、または権限モデルを持つエージェントには、カスタムプロンプトのほうが適する。Anthropicは、カスタムビルダーが安全性に関するガイダンスを削除する場合、その代替を用意しなければならないと警告している。

この警告は、新たなプレイブックの境界線を示している。行動に関するノイズを取り除くことは、権限を弱めることと同義ではない。簡潔なエージェントであっても、破壊的操作、機密データ、外部コミュニケーション、無監視での実行について明示的な制限が必要だ。

チームは、削除する前に指示を分類すべきである。スタイル上の好みは、多くの場合リポジトリの慣習に委ねられる。検証ワークフローはスキルにできる。権限の境界は、単なる丁寧な一文ではなく、強制可能なソフトウェアに属する。

この分割は、業界をコンテキスト・アーキテクチャへと向かわせる。重要な作業は、何をグローバルに残すか、何をパスごとに読み込むか、何をタスクごとに有効化するか、そして何をモデルとは独立してソフトウェアが強制するかを決めることになる。

エンジニアリング組織にとって、このアーキテクチャは組織の記憶にもなる。リポジトリの慣習、意思決定、技術リファレンスには、明確な所有者と取得経路が必要だ。検索可能なエンジニアリング・ナレッジベースは、永続的な事実と一時的なエージェント指示を分ける助けになる。

この競争で勝つのは、あらゆる場面で「短いプロンプト」を使う側ではない。安全性、タスク忠実性、再現可能な性能を維持しながら、必要最小限のコンテキストを提供できるシステムである。

Claude Code System Promptの成果には、なお独立した検証が必要

Anthropicの主要な成果は注目に値するが、公開されている証拠だけでは、すべてのチームが同じ80%を削減できるとは示されていない。

同社によれば、Claude Codeのシステムプロンプト削減は、コーディング評価で測定可能な性能低下を引き起こさなかった。この表現には、いくつかの重要な未解決の疑問が残る。

Anthropicは、この比較に用いた評価タスクを公表していない。評価スイートがコード生成、デバッグ、リポジトリ探索、テスト、ドキュメント作成、ツール利用、あるいは長時間の自律作業のどれを重視したのか、読者には分からない。

同社はベースラインスコアや信頼区間も公表していない。「測定可能な低下なし」は、結果が完全に同一だったこと、統計的に有意でない差だったこと、あるいは選択したベンチマークでは検出できないほど小さな変化だったことを意味し得る。

この主張は、高度なモデル向けに設定されたAnthropic社内のClaude Code構成に関するものだ。ユーザーが自らのCLAUDE.mdファイル、スキル、カスタムエージェントプロンプトの80%を、影響なしに削除できることを示すものではない。

これらのファイルには、組織固有の要件が含まれることが多い。例としては、ビルドコマンド、規制対象のワークフロー、レビュー基準、依存関係ポリシー、デプロイ制限、そして近傍のコードからベースモデルが推論できない慣習がある。

リポジトリには、一貫しないパターンが含まれている場合もある。周囲のコードに合わせるようClaudeに指示する方法は、周囲が望ましい標準を表している場合には有効だ。しかし、古い慣習と新しい慣習が共存していれば、技術的負債を再生産しかねない。

段階的開示には、それ自体の失敗モードがある。エージェントは、いつ専門的なスキルやリファレンスが必要かを認識しなければならない。ルーティングに失敗すれば、正しい情報が存在していても、アクティブなコンテキストには届かない。

遅延読み込みされるツールも、同様の依存関係を生む。軽量な説明は初期コンテキストを節約するが、エージェントが正しい能力を発見できるだけの具体性が必要だ。名前の悪いツールは、実質的に見えない存在になり得る。

コンパクションは状況をさらに複雑にする。Claude Codeは、コンテキストが埋まると長い会話を要約する。Anthropicのドキュメントによれば、その後に一部のプロジェクト指示やメモリは再読み込みされる一方、パススコープのルールは別の一致するファイルが読み込まれるまで待機する場合がある。

したがって、重要な情報は1回のセッション中に永続層と一時層の間を移動し得る。コンテキスト変更をテストするチームは、単発のコーディングプロンプトだけでなく、コンパクション境界をまたぐ長いタスクも含めるべきだ。

プロンプトキャッシュもアーキテクチャに影響する。これは安定したリクエスト接頭辞を再利用し、繰り返しの計算を減らす。Anthropicによれば、Claude Codeはキャッシュ一致を維持するため、静的コンテンツを先に、動的メッセージを後に配置している。

同社のプロンプトキャッシュに関する教訓は、セッション途中でツールやモデルを変更すると、キャッシュ済みの接頭辞が無効になる可能性を警告している。したがって、選択的コンテキストは関連性と安定性のバランスを取る必要がある。

Claude Codeの遅延読み込み戦略は、この緊張関係の一部に対処する。軽量なツールスタブを安定させたまま、完全なスキーマは後から読み込める。このアプローチは、基本ツールセットを絶えず変更せずにコンテキストを節約する。

それでも、より小さなシステムプロンプトが総コンテキスト使用量の削減を自動的に保証するわけではない。エージェントは、より多くのリファレンスを読んだり、より多くのスキルを呼び出したり、指示の発見に追加のターンを費やしたりして補うかもしれない。

また、プロンプト削減が一貫した挙動を保証するわけでもない。繰り返しのガイダンスを取り除くことで、広範なコーディング評価では見落とされるまれな障害が露呈する可能性がある。セキュリティに敏感なチームや規制対象のチームは、平均的なタスクスコアだけでなく、テールリスクをテストすべきだ。

適切な対応は、統制された評価である。チームは、代表的なリポジトリ、固定タスク、反復実行、明確に定義した失敗カテゴリーを横断して、旧構成と削減後の構成を比較できる。

有用な指標には、タスク完了率、意図しないファイル変更、テストカバレッジ、レビューでの指摘、ツールエラー、ユーザー修正、総コンテキスト消費量が含まれる。チームは、エージェントが実際にどの指示を読み込んだかも記録すべきだ。

自律性が高まるほど、立証責任も重くなる。各編集を監督する開発者なら、判断ミスをすぐに発見できる。プルリクエストを作成したり本番システムを変更したりする無監視エージェントには、より厳格な制御と深い評価が必要となる。

Anthropicの結果は、プロンプト負債が存在するという証拠として扱うのが最善だ。これは普遍的な削除目標ではなく、同社も自社モデルとハーネスの外部でこの知見を独立検証していない。

小さなプロンプトは、より多くの責任をエージェント・アーキテクチャへ移す

コンテキストの簡素化は複雑さを取り除かない。複雑さをルーティング、ツール、メモリ、評価、権限へと移し替える。

この移し替えこそ、今回の発表がもたらす最も重要なビジネス上の帰結である。プロンプトをエージェント製品そのものとして扱ってきたチームは、モデルを取り巻くシステム全体を検討する必要がある。

信頼できるエージェントには、関連知識を特定する方法が必要だ。明確な名前、表現力のあるパラメータ、制約された状態を持つツールも必要である。さらに、永続的な好みと一時的なセッション詳細を分離するメモリも必要だ。

また、実行を観測可能にする必要がある。開発者は、エージェントがどのファイルを読み、どのスキルを呼び出し、どのツールを選択し、どの指示が判断に影響したのかを確認できなければならない。

Claude 5のコンテキストエンジニアリングは、メインプロンプトが明示的な手順をあまり担わなくなるため、こうした能力の価値を高める。ルーティング層が失敗すれば、モデルがフォールバックとして利用できる冗長なガイダンスも少なくなる。

Anthropicのauto-memory機能は、この変化を示している。Claude Codeは、作業をまたいで関連性があると判断した情報を保存できる。これにより、手作業で管理するメモリストアとしてCLAUDE.mdを使う圧力が減る。

ただし、自動化されたメモリはガバナンス上の疑問をもたらす。チームは、何が保存されたのか、それが正確なままか、矛盾するメモリをどう解決するかを知る必要がある。メインプロンプトが簡潔でも、古いコンテキストはエージェントを誤導し得る。

リッチなリファレンスも、別のアーキテクチャ上の変化を生む。Anthropicによれば、Claudeは単純なMarkdownプランだけに頼るのではなく、より複雑なアーティファクトを扱える。これにより、エージェントが設計と実装の間に調査できる対象が広がる。

その利点は発見可能性に依存する。詳細なアーティファクトも、エージェントがその存在を知り、いつ参照すべきかを理解して初めて役に立つ。リファレンスツリーには、情報量のある名前、簡潔なインデックス、タスク固有の入口が必要だ。

ツール設計はプロンプティングの一形態になる。列挙型は有効な状態を伝える。必須パラメータは必要な情報を示す。権限境界は、モデルが文章をどう解釈するかにかかわらず、無効な操作を防ぐ。

このアプローチは、自然言語による警告よりもソフトウェア制御のほうが強制しやすいため、エンタープライズの購入者に訴求するはずだ。権限システムは操作をブロックできる。プロンプトは、モデルに実行しないよう求めることしかできない。

しかし、インターフェース設計には、段落をもう1つ追加するより多くのエンジニアリング作業が必要だ。チームはワークフローをモデル化し、ツールエラーを処理し、状態を可視化し、モデルや製品の変化に応じて互換性を維持しなければならない。

したがって、この80%削減は、単純なデモと本番エージェントの差を広げる可能性がある。デモは制約を減らすことで見栄えがよくなる場合がある。本番システムは、必要に応じて削除したプロンプト上の挙動をより強いアーキテクチャで置き換えなければならない。

この影響は、ソフトウェア開発以外でAIを利用するナレッジワーカーにも及ぶ。調査、オペレーション、分析エージェントも、同じコンテキストの問題に直面する。大きな指示文書には、目的、好み、参照資料、一度限りの手順が混在しがちだ。

これらのカテゴリーを分離すれば、検索性と保守性を向上できる。安定したアイデンティティと安全ルールはグローバルに残す。ドメインリファレンスは関連時に読み込む。タスク手順は呼び出し可能なワークフローにする。一時的な事実はアクティブなセッション内に留める。

これは、すべてのワークフローに精巧なプラットフォームが必要だという意味ではない。その原則は、短いプロジェクトインデックス、狭くスコープしたリファレンスファイル、反復的な作業に基づくテストセットから始められる。

重要なのは、コンテキストを未分化なテキストの塊として扱うことをやめることだ。各要素には、読み込む理由、定義されたスコープ、所有者、その価値をテストする方法があるべきだ。

Anthropicの動きは、競合するコーディングエージェントベンダーにも間接的な圧力をかける。ユーザーは今後、ベンチマークスコアだけでなく、各製品が指示、メモリ、ツール、コンパクション、コンテキストの可視性をどう管理するかも比較するようになる。

生の能力が高いモデルでも、雑然としたハーネス内では性能を発揮できない場合がある。より小さなモデルでも、ツールとタスク境界が狭ければ有用性を維持できる。エージェント競争は、システムの競争になりつつある。

新たに生まれる優位性は、コンテキストを検査可能にする製品に属する。ユーザーは、何がモデルに入力され、何が隠されたままか、何がコンパクションをまたいで残り、実行間で何が変化したのかを理解する必要がある。

Anthropicはその方向性を明確にした。より優れたモデルは、普遍的な行動ルールをより少なく担い、周囲のシステムが必要な瞬間に正確な情報を供給すべきだという考え方である。

80%削減後に注目すべきこと

Anthropicの小規模プロンプト戦略が業界のルールになるのか、それともClaude固有の最適化にとどまるのかは、3つのシグナルが示す。

第1のシグナルは、独立した評価である。開発者は、実際のリポジトリと反復実行を通じて、以前のClaude Codeシステムプロンプトと削減後のプロンプトを統制して比較した結果を探すべきだ。

強力な証拠には、タスクレベルのスコア、平均値ではなく分布、そして安全性と意図しない変更に関する明示的なカテゴリーが含まれる。比較可能な結果は、多くの恒久ルールがプロンプト負債になっているというAnthropicの主張を補強するだろう。

一貫しない挙動の増加は、その主張を弱める。特にエージェントが継続的な人間のレビューなしに動作する場合、まれでも高コストな失敗は重要だ。最も有用な研究は、長時間セッション、ツール発見、コンパクションをテストするものになる。

第2のシグナルは、他のモデル世代が同じコンテキストをどのように扱うかだ。Anthropicの発表では、特にOpus 5とFable 5が挙げられている。チームは、Sonnetクラスのモデル、より小型のモデル、あるいは旧世代のモデルが、同程度に簡潔な指示に耐えられるかを確認する必要がある。

削減後の構成がモデルをまたいで機能するなら、選択的コンテキストは一般的なエージェント設計パターンになる。性能が大きく異なるなら、チームは各モデルファミリー向けにバージョン管理されたプロンプトとルーティングポリシーを必要とする。

その結果は、マルチモデル製品を複雑にするだろう。プロバイダーやモデルサイズの切り替えは、API識別子を変えるだけでは済まなくなる。各モデルには、判断、例示、反復、制約の異なるバランスが必要になる可能性がある。

3つ目のシグナルは、/doctor、スキル、メモリ、遅延ツールをめぐる製品の挙動だ。Anthropicによれば、/doctorは肥大化したプロジェクト指示やスキルを特定できる。その推奨内容は、同社がユーザーにどの程度積極的な簡素化を期待しているかを示すことになる。

Claude Codeが、どのルールが競合しているか、どのファイルがほとんど有効化されないか、どの指示が組み込みの挙動と重複しているかを報告するかにも注目したい。こうした診断機能があれば、プロンプトの整理は主観的な編集作業から、測定可能な保守作業へと変わる。

Anthropicがより詳細な評価情報を公開するかも見守るべきだ。現時点の主張には、タスク構成、生スコア、モデル別比較が欠けている。透明性が高まれば、この知見が各チームの環境にも適用できるかを判断しやすくなる。

開発者にとって、当面の対応は無差別に80%を削除することではない。目的ごとに指示を監査すべきだ。実行可能な安全上の制限は残し、明らかな重複は取り除き、専門的な手順は明確なトリガーの背後に移す。

そのうえで、縮小した構成を、チームが実際に行う作業で検証する。日常的な編集、曖昧な依頼、レビュー業務、リポジトリの規約、ツールの失敗、長時間のセッションを含めるべきだ。完了率とあわせて、修正率も測定する。

エンタープライズの購入担当者は、コンテキストがどのように構築・検査されるのかをベンダーに尋ねるべきだ。大きなコンテキストウィンドウだけでは不十分である。スコープ、メモリ、権限、検索、圧縮、モデル固有の挙動を制御できる仕組みが必要だ。

ナレッジワーカーも、永続的なAI指示に同じ規律を適用すべきだ。安定した好みは簡潔に保つ。参照資料は取得可能な場所に保存する。将来のすべての依頼に、過去のあらゆる学びを背負わせないようにする。

AnthropicのClaudeに関する結果が重要なのは、洗練の意味を捉え直すからだ。最も高度なエージェントは、最も長いプロンプトを持つとは限らない。モデルが今この瞬間に必要とするものを判断する、最も明確な仕組みを備えたエージェントかもしれない。

独立したテストはAnthropicの結果を再現するのか。それとも、削除されたルールがなお重要となるタスクを明らかにするのか。今後数カ月、この答えが、真剣なClaude Codeコンテキスト監査のすべてを導くはずだ。