コンテキストエンジニアリングとは？CLAUDE.mdの実例で解説

「コンテキストエンジニアリング」という言葉、ここ数か月でやたら見かけるようになった気がします。

プロンプトエンジニアリングと何が違うのか、正直あいまいなまま流していた人も多いはず。

私自身、Claude Codeを毎日使う中で「プロンプトを工夫する」段階から「渡す情報そのものを設計する」段階に頭が切り替わった瞬間がありました。

この記事では定義とプロンプトエンジニアリングとの違いを整理したうえで、実際に運用しているCLAUDE.mdとrulesファイルの設計例まで踏み込んで解説します。

コンテキストエンジニアリングとは？定義とプロンプトとの違い

コンテキストエンジニアリングとは、AIに答えを出させるために必要な情報を、必要な範囲・順序・形式で設計する技術です。

プロンプトエンジニアリングが「言葉の選び方」に焦点を当てるのに対し、コンテキストエンジニアリングは「渡す情報そのもの」を扱う点が違います。

両者は対立する概念ではなく、コンテキスト設計という大きな枠組みの中にプロンプトの工夫が含まれる、と捉えるとわかりやすいです。

一言でいうと「AIに渡す情報の設計」

コンテキストエンジニアリングを一言で説明すると、AIが正しく判断するために必要な情報だけを揃える作業です。

人間の新人に仕事を任せる場面を思い浮かべてください。

指示の言い回しをどれだけ工夫しても、必要な資料や過去の経緯を渡さなければ的外れな成果物が返ってきます。

AIも同じで、システムプロンプト・会話履歴・外部データをどう組み合わせるかが結果の質を左右します。

プロンプトエンジニアリングとの違いを比較表で整理

両者の違いを整理すると、次の表のようになります。扱う対象と目的がそもそも異なるとわかると混同しにくくなります。

コンテキストエンジニアリングを学べる本

体系的に学びたい人には書籍もおすすめです。

代表的なのは「Context Engineering for Multi-Agent Systems」で、Packt Publishing刊行ながらO'Reillyのプラットフォームでも読め、RAGやエージェント開発の原理から実践までを扱っています。

現状は英語文献が中心で、日本語の解説書はまだ少なく、技術評論社などから今後の刊行が期待される段階です。

まずはこの記事のような実践記事とあわせて、公式ドキュメントや一次情報を読み進めるのが近道です。

なぜ今「コンテキストエンジニアリング」が注目されているのか

コンテキストエンジニアリングが急速に広まった背景には、AIの使い方が「1問1答」から「長時間タスクを任せるエージェント」に移り変わったことがあります。

この変化を放置すると、プロンプトをどれだけ磨いてもAIの回答がずれていく現象に悩まされ続けることになります。

登場のきっかけ｜Karpathy氏とLütke氏の発言

この言葉が一気に広まったきっかけは、2025年6月のSNS投稿です。

まずShopify CEOのTobi Lütke氏がXで「プロンプトエンジニアリングよりコンテキストエンジニアリングという言葉が好きだ」と投稿し、その約1週間後にAI研究者のAndrej Karpathy氏が「コンテキストウィンドウに次の一手に必要な情報だけを詰め込む繊細な技術」と賛同する投稿をしたことで、開発者コミュニティで急速に広まりました。

ただし、渡す情報を設計するという考え方自体は、それ以前から実務の現場で自然と行われていたものです。

言葉が後から追いついてきた、というのが実態に近いです。

プロンプトの工夫だけでは通用しなくなった理由

単発の質問であれば、プロンプトの言い回しを工夫するだけで十分に精度が上がります。

ところがClaude CodeのようにAIが複数ファイルを横断して作業する場面では、プロンプト単体の工夫はすぐ限界に達します。

過去のやり取り・プロジェクトのルール・実行結果といった大量の情報を、AIが混乱しない形で渡し続ける必要があるからです。

AIエージェント時代に起きる「コンテキストの肥大化」問題

タスクが長くなるほど、会話履歴やツールの実行結果は際限なく積み上がっていきます。

この肥大化を放置すると、AIは古い情報と新しい情報の優先順位をつけられなくなり、指示を忘れたかのような挙動を見せ始めます。

この優先順位付けの破綻こそが、コンテキストエンジニアリングという発想が必要になる核心部分です。

コンテキストエンジニアリングを導入する3つのメリット

コンテキスト設計を意識するだけで、AIとのやり取りには具体的な変化が生まれます。特に効果を実感しやすいのは次の3点です。

• 出力の安定性が上がる：渡す情報の優先順位を設計しておくことで、AIが古い指示と新しい指示を混同しにくくなります
• 長時間タスク・エージェント運用でのブレを抑えられる：Claude Codeのように複数ファイルを横断して作業する場面ほど、コンテキスト設計の有無が結果の一貫性を左右します
• コンテキスト腐敗を未然に防げる：後述する「情報を詰め込みすぎて精度が落ちる状態」を、設計段階で回避できます

コンテキストを構成する5つの要素

AIに渡すコンテキストは、大きく分けて5つの要素で構成されます。それぞれの役割を理解すると、どこを増やしどこを削るべきかの判断がつきやすくなります。

システムプロンプトと会話履歴

システムプロンプトはAIの役割や制約を固定する土台です。

会話履歴は直前までのやり取りを保持する部分で、ここが長くなりすぎると重要な指示が埋もれてしまいます。

土台と履歴のバランスがコンテキスト設計の出発点になります。

RAG・ツール情報・状態メモリ

RAGは外部ドキュメントを検索して必要な部分だけを差し込む仕組みです。

ツール情報はAIが実行できる操作の一覧、状態メモリは作業の進捗を保持する仕組みを指します。

この3つは「必要なときに必要な分だけ」渡すのが鉄則で、常時全部を渡すとかえって精度が落ちます。

情報が多すぎると起きる「コンテキスト腐敗」

コンテキスト腐敗とは、情報を詰め込みすぎた結果、AIが古い指示と新しい指示を混同したり、無関係な情報に引っ張られたりする状態です。

「念のため」で情報を足し続けると、いずれこの状態に陥ります。渡す情報は多いほど良いわけではありません。

CLAUDE.mdと.claude/rulesで実践するコンテキスト設計【実例】

ここからは私が実際に運用しているコンテキスト設計を紹介します。

Claude CodeにはCLAUDE.mdという、プロジェクトの前提知識を常時読み込ませるファイルの仕組みがあります。

これをどう設計するかが、まさにコンテキストエンジニアリングの実践そのものです。

CLAUDE.mdに書くべきこと・書かないこと

CLAUDE.mdには、プロジェクト全体で必ず守ってほしいルールだけを書きます。

ディレクトリ構成・依存管理の方針・テストの実行方法といった、どの作業でも共通して参照する情報が対象です。

逆に、特定のディレクトリでしか使わない細かい規約をここに書くと、無関係な作業のたびにAIへ余計な情報を読み込ませることになります。

rulesファイルをpaths指定で自動ロードする仕組み

そこで使っているのが.claude/rules/配下のルールファイルです。

各ファイルにfrontmatterでpathsを指定しておくと、該当ファイルを操作するときだけそのルールが自動で読み込まれます。

全部を常時読み込ませるのではなく、必要なタイミングで必要な分だけ渡す設計です。

---
paths:
  - "python/wp_manager/**"
---
# WordPress管理スクリプト ルール
（wp_manager配下を操作するときだけ自動で読み込まれる）

実際にこのブログを運営しているリポジトリでは、.claude/rules/配下は現在6本のファイルに分割されています。

秘密情報の取り扱いルールのような「常に守るべきもの」だけは常時ロードにし、残り5本はディレクトリごとにpathsで範囲を絞って自動ロードする構成です。

全部を常時読み込ませないという判断そのものが、渡す情報を設計するという発想の実践です。

コンテキストを肥大化させて失敗した経験

正直に書くと、最初はCLAUDE.mdに何でも詰め込んでいました。プロジェクトの全ルールを1ファイルにまとめていた時期があります。

すると関係のない作業をしているときにも大量の前提情報が読み込まれ、指示への反応が鈍くなったり、無関係なルールを引っ張り出してきたりする場面が増えました。

ルールをトピック別に分割し、paths指定で必要なときだけ読み込む形に変えてから、AIの反応の的確さが明らかに変わりました。

渡す情報を減らしたのに精度が上がる、という逆説を身をもって味わいました。

「CLAUDE.mdは短ければ短いほど良い」とよくいわれますが、私の実感は少し違います。

短さそのものより、どう分割してどのタイミングで読み込ませるかという粒度設計のほうが効いていました。

コンテキストエンジニアリングのやり方｜今日からできる具体例

大がかりな仕組みを作らなくても、コンテキストエンジニアリングの考え方は今日から取り入れられます。

ポイントは「渡す量」ではなく「渡す設計」を意識することです。

必要な情報だけを渡す設計のコツ

まず、今の会話やタスクに直接関係する情報だけを渡す意識を持ちます。過去のやり取りを丸ごとコピペするのではなく、結論だけを要約して渡す。

ファイル全体ではなく、該当箇所だけを抜粋する。この一手間だけで、AIの回答の的確さは大きく変わります。

情報を構造化してタイムリーに更新するコツ

情報は箇条書きや見出しで構造化し、古くなった内容はこまめに更新します。

私の場合、ルールファイルを機能別に分けたことで、更新すべき箇所がすぐ特定できるようになりました。

1つの巨大なファイルを都度読み直す手間がなくなったのは、地味に大きな効果です。

コンテキストエンジニアリングに関するよくある質問

Q1. コンテキストエンジニアリングとプロンプトエンジニアリングはどちらを先に学ぶべきですか？
プロンプトエンジニアリングを先に学ぶのが自然です。指示の出し方に慣れたうえで、渡す情報の設計に意識を広げると理解しやすくなります。

Q2. コンテキストエンジニアリングはいつから使われている言葉ですか？
2025年半ばごろから、AI開発者のSNS投稿をきっかけに急速に広まった言葉です。概念自体はそれ以前から存在していました。

Q3. 具体例を教えてください。
Claude CodeのCLAUDE.mdやrulesファイルはその代表例です。プロジェクトのルールを分割し、必要なときだけ自動で読み込ませる設計そのものがコンテキストエンジニアリングにあたります。

Q4. コンテキストが多いほどAIの精度は上がりますか？
上がりません。無関係な情報が増えるとAIは優先順位を見失い、かえって精度が落ちます。渡す情報は量より設計が重要です。

Q5. 個人開発でもコンテキストエンジニアリングは必要ですか？
必要です。ルールファイルを1つに詰め込むほど反応が鈍くなる現象は、個人開発の小規模プロジェクトでも同じように起こります。

Q6. ハーネスエンジニアリングとの違いは何ですか？
コンテキストエンジニアリングが「渡す情報の設計」を指すのに対し、ハーネスエンジニアリングはAIが自走できる作業環境そのものの設計を指します。

渡す情報を整えた先に、AIを動かす仕組み全体の設計があるとイメージするとわかりやすいです。

まとめ｜コンテキスト設計がAI活用の質を決める

コンテキストエンジニアリングは、プロンプトの言い回しではなく、AIに渡す情報そのものを設計する技術です。

ただし情報を減らせば減らすほど良いわけでもなく、過不足のないバランスを見極めることが本質です。今回の内容を振り返ります。

• 定義：AIが正しく判断するために必要な情報を、必要な範囲だけ設計すること
• プロンプトエンジニアリングとの違い：対象が「言い回し」か「情報全体」かの違い
• 失敗パターン：情報を詰め込みすぎるコンテキスト腐敗
• 実践のコツ：ルールを分割し、必要なときだけ読み込ませる設計

CLAUDE.mdを1ファイルに詰め込んでいた頃の自分に伝えたいのは、情報を足すより減らして整理するほうが結果につながる、という一点です。

まずは今使っているプロンプトや指示書を見直し、本当に毎回必要な情報かどうかを問い直すところから始めてみてください。