「プロンプトエンジニアリング」という言葉が広まったのはここ数年のことですが、Claude Codeのようなagentic（自律的にタスクを進める）ツールを日常的に使うようになると、この言葉だけでは語りきれない領域があることに気づきます。本記事では、単発の指示文の工夫から、プロジェクト全体の文脈設計へと重心が移ってきていると感じる理由を整理します。
プロンプトエンジニアリングが扱ってきたもの
従来のプロンプトエンジニアリングは、基本的に「1回の指示文をどう書くか」という話でした。役割を与える、出力形式を指定する、例を示す（Few-shot）。これらはチャットボット的な使い方、つまり1問1答に近いやり取りでは非常に効果的でした。
Claude Codeでも、もちろん1回の指示の質は今でも重要です。曖昧な依頼より具体的な依頼の方が、必要な手戻りは少なくなります。しかしagenticなツールの場合、1回の指示文だけでは説明しきれない情報量を、ツールが自律的に「読みに行く」という性質があります。
なぜ「コンテキストの質」が重要になるのか
Claude Codeは、指示を実行する前にファイルを読んだり、CLAUDE.mdを参照したり、過去の会話履歴を踏まえたりします。つまり、1回のプロンプトの巧拙だけでなく、Claude Codeが参照できる情報の整備状況そのものが、最終的な出力の質を左右します。
これは筆者が様々なプロジェクトでClaude Codeを使ってきた中で、繰り返し実感してきたことです。同じ「テストを追加して」という指示でも、プロジェクトにテストのスタイルガイドがCLAUDE.mdに書かれているプロジェクトと、何も書かれていないプロジェクトとでは、出てくる結果の安定度がまったく違います。前者はプロジェクトの慣習に沿ったテストが一発で出てくることが多く、後者は「とりあえず動くテスト」止まりになりがちです。
つまり、いくらプロンプトを工夫しても、土台となるコンテキストが整っていなければ、その効果には天井があるということです。
プロンプトエンジニアリングが「1回の指示の質」を扱うのに対し、コンテキストエンジニアリングは「Claude Codeが参照する情報全体の設計」を扱います。CLAUDE.md、プロジェクト構造、ドキュメント、過去の会話の要約方針まで含めた、より広い概念だと捉えるとわかりやすいと思います。
コンテキスト設計が含むもの
コンテキストエンジニアリングという言葉で筆者がイメージしているのは、おおよそ次のような要素です。
| 要素 | 具体例 |
|---|---|
| プロジェクト固有のルール | CLAUDE.mdに書く禁止事項・コーディング規約・ビルドコマンド |
| ディレクトリ構造の設計 | Claudeが「どこに何があるか」を推測しやすい構成にする |
| ドキュメントの整備 | 設計の背景・意思決定の理由を残しておく |
| セッション内の情報管理 | /compactのタイミング、サブエージェントへの委譲方針 |
| 階層的な設定 | グローバル・プロジェクト・サブディレクトリのCLAUDE.mdの使い分け |
これらはどれも「1回の指示文」ではなく、プロジェクトという単位での設計判断です。プロンプトエンジニアリングが「会話のスキル」だとすれば、コンテキストエンジニアリングは「プロジェクト運用のスキル」に近いと考えています。
CLAUDE.mdは「最初のコンテキスト設計書」
その中でも特に重要なのが、やはりCLAUDE.mdです。Claude Codeは会話の開始時にCLAUDE.mdを読み込むため、ここに書かれた内容は、その後の全てのやり取りに影響を与える「土台」になります。
筆者がCLAUDE.mdを設計するときに意識しているのは、「Claudeがコードを読めばわかることは書かない」という線引きです。コードから読み取れない暗黙のルール、過去にハマった落とし穴、チームの合意事項。こうした「コードの外にある情報」こそ、コンテキストとして明示的に設計する価値があります。
# 良いCLAUDE.mdの書き方の例
## 含めるべきもの
- Claudeが推測できないビルド・テストコマンド
- デフォルトと異なるコードスタイルのルール
- リポジトリ固有の禁止事項
## 含めなくてよいもの
- コードを読めば自明な説明
- 一般的なベストプラクティス（「綺麗なコードを書く」等）CLAUDE.mdが長すぎると、かえって重要なルールが埋もれてしまうという問題も起きます。これは「とにかく情報を詰め込めばいい」という話ではなく、何を載せて何を載せないかを取捨選択する、まさに設計の作業です。
コンテキストは多ければ多いほど良いわけではありません。Claude Codeのコンテキストウィンドウには限りがあり、関係のない情報が増えるほど、肝心な指示が埋もれて精度が落ちることがあります。コンテキスト設計とは「何を与えるか」と同じくらい「何を与えないか」の設計でもあります。
プロンプトとコンテキスト、両方が必要
誤解のないように補足すると、プロンプトエンジニアリングが不要になったわけではありません。むしろコンテキストという土台が整っているからこそ、その上で出す個別の指示の質がより重要になる、という関係に近いと感じています。土台がしっかりしているプロジェクトでは、簡潔な指示でも意図が正確に伝わりやすくなります。
実践コースのLesson 9: コンテキスト管理を最適化するでは、/compactの使い方やサブエージェントへの委譲など、セッション単位でのコンテキスト管理を扱っています。一方で、プロジェクト全体の土台づくりという意味では、入門コースのLesson 4: CLAUDE.mdでプロジェクトの記憶を作るがその出発点になります。
まとめ
単発の指示の工夫から、プロジェクト全体の文脈設計へ。これは「プロンプトエンジニアリングが廃れた」という話ではなく、agenticなツールが普及したことで、扱うべき設計対象が広がったということだと捉えています。CLAUDE.mdの設計、ドキュメントの整備、セッション内のコンテキスト管理。これらすべてを含めた「コンテキストエンジニアリング」という視点を持つことが、これからのAIコーディングツールとの付き合い方において、ますます重要になっていくはずです。