以前、Claude 5 モデルの最新世代に最適なプロンプトを与える方法と、それらと反復的に作業して構築したいものを見つける方法について書きました。
しかし、Claude にメッセージを送信するとき、プロンプトはそれが取得するコンテキストのほんの一部に過ぎません。コンテキストの大部分は、システムプロンプト、スキル、CLAUDE.md ファイル、メモリ、その他のソースから組み立てられます。私たちはこれを コンテキストエンジニアリング と呼んでおり、Claude Code を使用する際や独自のエージェントを構築する際に、生成される結果に大きな影響を与えます。
プロンプトとは異なり、コンテキストは多くのリクエストで一般的に使用されるため、それほど具体的にすることはできません。では、ユーザーのプロンプトが何かわからない場合に、Claude 向けの汎用的なプロンプトやガイダンスはどのように構築すればよいのでしょうか？
これは、Claude 自身の能力が進化するにつれて、驚くほど難しくなることがあります。最近では、最新世代の Claude モデルにプロンプトを与える方法に大きな飛躍が見られました。Claude Opus 5 や Claude Fable 5 のようなモデル向けに、Claude Code のシステムプロンプトの 80% 以上を削除しましたが、コード評価では測定可能な損失はありませんでした。
この新しいクラスのモデルにプロンプトを与えることについて私たちが学んだこと、そしてそれをコンテキストエンジニアリングの更新に活用する方法をご紹介します。これらのベストプラクティスは claude doctor に組み込んであります。Claude Code で /doctor コマンドを使用して、スキルと CLAUDE.md ファイルを適正化してください。
Claude を解き放つ
全体的に、私たちは Claude Code を過度に制約していたことがわかりました。それはシステムプロンプトだけでなく、CLAUDE.md ファイルやスキルにおいても同様です。
例えば、Claude Code の社内利用のトランスクリプトを読むと、システムプロンプト、スキル、ユーザーリクエストが互いに競合し、「適宜ドキュメントを残す」、「コメントを追加しない」といった相反するメッセージが 1 つのリクエストに複数含まれていることがわかります。
一般的に、Claude はユーザーの意図を解釈して正しい答えにたどり着くことができますが、これらの重複し競合するメッセージについて、行動を決定する前に慎重に考える必要があります。
かつては最悪のシナリオを回避するためにこれらの制約が必要でしたが、その後、それらの多くを削除し、代わりにモデルが周囲のコンテキストと判断力を使用できるようにしても問題ないことがわかりました。
さらに、Claude Code には現在、より多くのツールが搭載されています。Claude はかつて、メモリ、情報、ガイダンスのソースとして CLAUDE.md に依存していました。現在では、メモリ、アーティファクト、スキルがあり、Claude はこれらを使用して、セッション間でコンテキストをロードおよび共有する新しい方法を作成できます。
その頃と今
以前はベストプラクティスとされていたものの、神話と化していたコンテキストエンジニアリングの手法がいくつかあります。その中には以下のようなものがあります。
**
その頃：Claude にルールを与える
今：Claude に判断力を与える
**
Claude Code を初めてリリースしたときは、ファイルの削除などの最悪のシナリオを Claude が確実に回避できるようにする必要がありました。そのため、常に正しいとは限らない非常に強いガイダンスを与えていました。例えば、システムプロンプトではかつて次のように言っていました。
コード内：デフォルトでコメントを書かない。複数段落の docstring や複数行のコメントブロックは決して書かない — 最大 1 行の短い行。ユーザーが依頼しない限り、計画、決定、分析のドキュメントは作成しない — 中間ファイルではなく、会話のコンテキストから作業する。
しかし、特定のプロンプトのサブセットでは、このガイダンスは間違っていることになります。ドキュメントの場合、ユーザー自身の好みがあるかもしれませんし、非常に複雑なコードの特定の部分には複数行のコメントブロックが必要な場合もあります。
とはいえ、古いモデルにこれらのガードレールがないと、Claude が書くコメントは多くの場合で不正確になり、このトレードオフを受け入れなければなりませんでした。しかし、新しいモデルはより優れた判断力を持ち、明確なルールがなくてもこれらの決定を適切に処理できます。
新しいシステムプロンプトでは、次のように言っています。周囲のコードと同じように読めるコードを書く：そのコメント密度、命名、イディオムに合わせる。
**
その頃：Claude に例を与える
今：インターフェースを設計する
**
ツール使用の最も重要なルールは、Claude に使用方法の例を与えることでした。最新のモデルでは、例を与えると、かえって特定の探索空間に制約されてしまうことがわかりました。
例を使用する代わりに、ツール、スクリプト、ファイルの設計について考えてみてください。Claude がどのようなパラメータを持ち、それらをどのように表現力豊かにできるでしょうか？
例えば、Todo ツールの例では、ステータスを pending、in_progress、completed の列挙としてリストするだけで、Claude に使用方法のヒントを与えられます。1 つのアイテムを in_progress に保つという指示は、要求された動作を定義するのに役立ちます。
**
その頃：すべてを最初に詰め込む
今：プログレッシブディスクロージャーを使用する
**
Claude Code はコーディングに焦点を当てていたため、システムプロンプトにはコードレビューと検証の方法に関する詳細な情報が含まれていました。これらは常に必要というわけではありませんでしたが、必要な場合には極めて重要な情報でした。
その後、Claude Code はプログレッシブディスクロージャー（適切なタイミングで適切なコンテキストをロードすること）を非常に得意とするようになりました。例えば、検証とコードレビューを独自のスキルに移し、Claude Code が選択的に呼び出せるようにしました。
しかし、プログレッシブディスクロージャーはスキルのためだけではありません。ツールにも使用しています。一部のツールは「遅延ロード」であり、エージェントは使用する前に ToolSearch を使用して完全な定義を検索する必要があります。これにより、必要になるまでコンテキストを占有しない、より多くのツール（Task ツールなど）を保持できます。
同じことが、自身の CLAUDE.md ファイルや Skill.md ファイルにも適用できます。よくある誤解は、Claude が他の方法では見つけられないからといって、遭遇する可能性のあるすべての既知のプラクティスのための中央リポジトリにしたいというものです。代わりに、適切なタイミングでロードできるファイルのツリーを検討してください。
**
その頃：繰り返し言う
今：シンプルなツールの説明
**
初期の Claude モデルは、指示を繰り返す必要があったり、コンテキストウィンドウの先頭よりも末尾の指示に従う可能性が高かったりすることがありました。そのため、システムプロンプトには、メインのシステムプロンプト内のツールへの参照と、ツールの説明内の指示の両方が含まれることがありました。
これらの繰り返しの例を削除し、ツールの使用方法の指示をシステムプロンプトではなくツールの説明に配置できることがわかりました。
**
その頃：CLAUDE.md ファイル内のメモリ
今：自動メモリ
**
以前は、# ホットキーを使用して自動的に CLAUDE.md に書き込むことで、Claude のメモリに保存するようユーザーに推奨していました。現在では、Claude は作業に関連するメモリやあなたに関連するメモリを自動的に保存します。
**
その頃：シンプルな仕様
今：リッチな参照
**
プランモードでは、Claude Code は計画を含むマークダウンファイルに大きく依存していました。これらのファイルを計画として保存することで、Claude は必要なときにそれらを参照できました。もう 1 つの同様のベストプラクティスは、より長いプロジェクトにわたって作業する際に Claude が参照できるように、コードベースに仕様を保存することでした。
しかし、Claude はますます複雑な参照を処理できることがわかりました。シンプルなマークダウンファイルの代わりに、Claude は新しいアーティファクト機能によって作成された HTML アーティファクトを参照できます。
また、コードの形式で Claude に参照を与えることもできます。仕様は、詳細なテストスイートや、Claude が移植する可能性のある別のコードベースの関数である場合もあります。
ルーブリックは、参照の別の形式です。ルーブリックを使用すると、動的ワークフロー を利用して、特定の分野におけるあなたの好み（良い API 設計とはどのようなものかなど）を Claude に試行・検証させることができます。
これを自身のコンテキストに適用する
これらすべてをまとめると、コンテキストを組み立てる際にどのようになるでしょうか？
システムプロンプト
システムプロンプトは、プロダクトコンテキストに強く結びついています。それは Claude に、どのプロダクトで動作しているか、何をしているかを伝えます。Claude Code では、これを変更することはおそらくないでしょう。しかし、独自のエージェントハーネスを構築している場合は、ここに多くの時間を費やすべきです。
CLAUDE.md
CLAUDE.md は軽量に保ち、リポジトリの目的を簡単に説明してください。ただし、ほとんどのトークンはコードベース内の注意点に費やしてください。例えば、コードを整理して、型を 1 つのモノリシックファイルにのみ保持し、他の場所には置かないようにする場合などです。ファイルシステムやリポジトリを見れば Claude が当然知っているべき「明らかな」ことは記述しないでください。
詳細についてはプログレッシブディスクロージャーを使用してください。例えば、作業の検証方法に関するいくつかの独自の指示がある場合は、検証スキルを作成し、CLAUDE.md からそれを参照してください。
スキル
スキルは、Claude が必要なときに情報を見つけられるようにする軽量なガイドと考えてください。非常に重要な領域を除いて、過度に制約しないようにしてください。
長いスキルの場合は、可能な限りプログレッシブディスクロージャーを使用してください。複数のファイルに分割し、それらを分離してください。
スキルは、あなた自身、チーム、またはプロダクトに固有の特定の意見、知識、またはベストプラクティスをエンコードする場合に最適です。
参照
ファイルを @ メンションして、参照として含めることができます。参照により、Claude は現在の計画に関する詳細情報を参照できます。
これは、仕様ファイル、モックアップ、またはコードベース全体の場合もあります。一般的には、コード内のファイルを優先する必要があります。コードは、Claude が非常によく知っている言語で明確で忠実度の高い指示を提供するためです。例えば、デザインの HTML モックアップは、デザインの説明やスクリーンショットよりも一般的に優れた結果を生み出します。
簡素化してみる
システムプロンプト、スキル、CLAUDE.md ファイル全体で、私たちが行ったように簡素化が必要かもしれません。私たちは claude doctor という新しいコマンドをリリースしました。これにより、この作業を自動的に行うことができます。より高度なモデルに特化したプロンプティングの詳細については、Fable フィールドガイド をご覧ください。
