コンテキストエンジニアリングとは AIに渡す文脈の設計

コンテキストエンジニアリングとは、AIに渡す情報(コンテキスト)全体をどう組み立てるかを設計する考え方です
プロンプトの言い回しを磨くプロンプトエンジニアリングの先にある、いま急速に広まっているテーマなんです

AIに仕事を頼んで、指示じたいは悪くないはずなのに答えがズレる
そんなとき、原因は聞き方よりAIに渡している情報そのものの側にあることが多いです

この記事では、コンテキストエンジニアリングとは何かを、プロンプトエンジニアリングとの違い・具体的な構成要素まで初心者向けにまとめます
読み終えるころには、次の3つがつかめているはずです

• コンテキストエンジニアリングの意味:AIに何を渡すかの設計だと分かる
• プロンプトとの違い:どちらが上位で、なぜ置き換えではないのか
• 6つの構成要素:コンテキストに積むものを1つずつ噛み砕く

コンテキストエンジニアリングとは?まず全体像

結論から言うと、コンテキストエンジニアリングとは、AIが一度に読み込む情報のかたまり(コンテキスト)に、何をどう積むかを設計する技術です
単発の指示文だけでなく、AIが答えを作るために参照する材料をぜんぶひっくるめて整える、という捉え方なんです

AI(正確にはLLM=大規模言語モデル、文章を予測して作るAIの中身)は、渡された材料をもとに次の一手を組み立てます
だから材料が薄かったり、ノイズだらけだったりすると、聞き方をどれだけ工夫しても答えが決まりきらないんです

ここで前提になるのがコンテキストウィンドウという言葉です
下のメモにまとめておきます

Claudeの開発元である Anthropic は、コンテキストエンジニアリングをプロンプトエンジニアリングの自然な発展形と位置づけています
プロンプトを捨てる話ではなく、プロンプトも材料のひとつとして、コンテキスト全体を面倒みる、という広げ方なんです

もう少し身近にたとえると、新しく入ったメンバーに仕事を任せる場面に近いです
どれだけ優秀な人でも、必要な資料や過去の経緯を渡さなければ良い動きはできません
コンテキストエンジニアリングは、AIに対してこの「引き継ぎ資料の準備」を丁寧にやる作業だと考えると、とっつきやすいはずです

ここまでの話を1枚の図にすると、こんなイメージになります
窓というひとつの器を、性格の違う6種類の情報が分け合っている、という構図で見てもらえると分かりやすいはずです

なぜいま生まれた言葉なのか

コンテキストエンジニアリングは、2025年に一気に広まった比較的あたらしい言葉です
ざっくりした流れをおさえておくと、単なるバズワードではなく背景のある概念だと分かります

• 提唱:Shopify CEO の Tobi Lütke 氏が2025年6月ごろ、「LLM がタスクを解けるだけの文脈をぜんぶ渡す技術」として言い出したのが起点とされます(正確な日付は諸説あり、ここでは断定しません)
• 拡散:AI研究者の Andrej Karpathy 氏が同じ時期に賛同し、言葉として一気に広まりました(命名者というより後押し役の立場です)
• 体系化:Anthropic が2025年9月に「Effective context engineering for AI agents」で整理し、実務の枠組みとして定着させました

背景にあるのは、AIの使い方が単発の質問から自分で何ステップも作業するエージェントへ移ってきたことです
1往復で終わって、必要な前提もその場で書き添えられる用事なら、うまい聞き方でだいたい足ります

ところが、AIが道具を使って何度も往復しながら進むようになると、途中でどんな情報を持たせ続けるかが結果を左右します
この「持たせ続ける材料の設計」に名前がついたのが、コンテキストエンジニアリングなんです

プロンプトエンジニアリングとの違い

ここが多くの人のつまずきどころなので、プロンプトエンジニアリングとの違いを表で整理します
ポイントは、片方がもう片方を置き換えるのではなく、プロンプトはコンテキストの一部という包含の関係だという点です

観点	プロンプトエンジニアリング	コンテキストエンジニアリング
主な対象	1回の指示文の言い回し	窓に積む情報の全体
中心の問い	どう聞くか	何を渡すか
扱う単位	文・段落	指示・知識・履歴・状態のまとまり
効きやすい場面	単発の質問や生成(前提が短く済む場合)	長く動くエージェント作業
両者の関係	コンテキストの一部(部分集合)	プロンプトを内側に含む上位の設計

「プロンプトエンジニアリングはもう古い」という煽りを見かけますが、そこは冷静に受け止めたいところです
実務では指示文の作り込みはいまも必要で、コンテキストという大きな器の中でプロンプトが担う役割が明確になった、と捉えるのが無理のない理解なんです

言い換えると、聞き方(プロンプト)を磨くのは点の改善、渡す材料ぜんぶ(コンテキスト)を設計するのは面の改善です
点をいくら磨いても面が崩れていると結果は安定しないので、両方を行き来する感覚が実用的です

たとえば「この関数のバグを直して」と頼む場面を考えます
プロンプトの工夫は、頼み方を「エラー内容も添えて原因から説明して」と具体的にすること
コンテキストの設計は、そもそも該当のコードやエラーログ・関連する仕様まで一式を渡しておくことです
後者が抜けていると、聞き方をどれだけ整えても的外れな答えになりがちなんです

コンテキストに積む6つの構成要素

では、コンテキストには具体的に何が入るのか?
代表的なものを6つの構成要素に分けて、1つずつ噛み砕きます

• システムプロンプト:AIの役割やルールを決める土台の指示、「あなたは○○の担当です」のような前提
• ツール定義と実行結果:AIが使える道具(検索・ファイル読み書きなど)の説明と、実際に動かした結果
• RAG(外部知識の検索):手元の資料やデータベースから関連情報を引っぱってきて渡す仕組み
• メモリ:過去のやり取りやユーザーの好みを覚えておいて、あとで再利用する情報
• 会話履歴:ここまでの往復のログ、いま何を話しているかの流れ
• エージェント状態:いま何の作業の途中か、次に何をする予定かという進行の記録

この6つが、同じひとつのコンテキストウィンドウ(限られた窓)を分け合います
だからこそ、何を厚く積んで何を削るかの配分の判断が、コンテキストエンジニアリングの中身になるわけです

6つのうち、初心者がイメージしにくいのはツール定義と実行結果・エージェント状態あたりでしょうか?
前者は「AIが検索や電卓を使えるように渡す取扱説明書とその使用結果」、後者は「作業のしおり(いまどこまで進んだか)」だと思うと近いです

言葉の説明だけだとイメージしにくいので、実際にどんな中身が窓に載るのかをミニ例で並べてみます
同じ「情報」でも、要素ごとに質がぜんぜん違うのが伝わるはずです

こう並べると、6要素は「知識(RAG)」「記憶(メモリ)」「いまの流れ(会話履歴)」のように役割が分かれていると分かります
ぜんぶ同じ袋に放り込むのではなく、種類ごとに何をどれだけ載せるかを考えるのが、コンテキスト設計の勘どころなんです

RAG(外部知識の検索)とは

初めて聞く方向けに、RAGだけ少し補足します
RAG(Retrieval-Augmented Generation)とは、AIが答える前に関連資料を検索し、それを取り込んでから答えを作る仕組みです

AIの中身が最初から知っていることには限りがあり、社内マニュアルや最新の情報までは覚えていません
そこで、外から必要な資料を引っぱって窓に載せてあげると、AIはその場で参照しながら答えられます

身近な例だと、手元のPDFを読ませて質問に答えてもらう使い方がRAGの発想に近いです
言葉としてのRAGや周辺用語はAI用語集にもまとめているので、あわせてどうぞ

メモリと会話履歴の違い

メモリと会話履歴は似ていますが、役割が少し違います
会話履歴は「いまのやり取りの流れ」、メモリは「別の機会にも持ち越したい情報」というイメージです

会話が長引くと履歴が増えて窓を食いつぶすので、要約して圧縮するのもコンテキスト設計の一部です
全部を抱え込むより、要るものだけ残す引き算のほうが、じっさいには効いてきます

コンテキストは多いほどいいわけではない

ここまで読むと「とにかく情報を積めば安心」と思えますが、そこは落とし穴です
窓には上限があるうえ、関係ない情報が混ざると、AIがどこを見ればいいか迷って精度が落ちます

Anthropic も、コンテキストで大事なのは量ではなくその一手にとって過不足のない情報だと強調しています
だから実務では、足す設計と同じくらい、要らないものを削る・要約する設計が効いてきます

具体的には、窓に情報を詰め込みすぎると次のような実害が出ます
どれも「たくさん渡したのに、かえって精度が落ちた」という形で表れるのがやっかいなところです

• 古い情報の混入:更新前の仕様と最新版を両方渡すと、AIがどちらを正として答えればいいか迷う
• トークンの浪費:使わない資料まで窓の席を占めるぶん、肝心のやり取りに割ける余白が減っていく
• 精度の低下:関係の薄い情報が増えるほど、AIが要点を見失って答えがぼやけやすくなる

だから上限ギリギリまで詰めるより、その一手に要らない資料は思い切って外すほうが、結果的に答えが安定します
足し算より引き算のほうが効く場面は、じっさいに手を動かすとよく出くわします

「agent failures = context failures」という見方

コンテキストエンジニアリングを語るとき、よく引かれる整理があります
それがagent failures = context failuresという見方です

これは、エージェント(自分で作業するAI)の失敗の多くは、モデルの頭が悪いからではなくコンテキストの失敗が原因だ、という捉え方です
渡すべき情報が抜けていた、古い情報が混ざっていた、ノイズが多すぎた、といった材料側のほころびが結果を崩す、というわけなんです

この見方の便利なところは、AIがコケたときに直す先が具体的になる点です
「なんか賢くしてほしい」ではなく、「どの材料が足りなかったか」を点検すればいい、と切り分けられます

Claude Code の CLAUDE.md はコンテキストエンジニアリングの実例

抽象的な話が続いたので、私が日常的に触れている実例を挙げます
それが、AI開発ツールのClaude Codeで使うCLAUDE.mdというファイルです

CLAUDE.md は、プロジェクトの決まりごとをまとめておく設定ファイルで、AIが作業を始めるときに読み込みます
私はここに、使う言葉づかいのルールや、触ってほしくないファイル、フォルダの構成などを書いておくんです
ただし CLAUDE.md はAIへのお願いを書く場所で、アクセスを止める仕組みではありません
本当に触らせたくないファイルは、権限の設定側(settings.json の permissions.deny)で止めておくのが安全です

これはまさにコンテキストエンジニアリングそのもので、毎回おなじ前提を打ち直す代わりに、AIが読み込むコンテキストを先に整えておく、という発想です
先ほどの6要素で言えば、システムプロンプトやメモリに近い役割を、1枚のファイルで担わせている感じです

私の場合、CLAUDE.md を整えるほどに、指示が短くても意図どおり動いてくれるようになりました
逆に、ここが薄いと同じ説明を何度も繰り返すことになり、それこそ先ほどの「context failures」を自分で作ってしまいます

具体的には、CLAUDE.md を用意する前は「ですます調で、句点は控えめに」と毎回説明していたことが、いまは一言も添えずに文体がそろいます
渡す前提を一度ファイルに固定するだけで、往復のたびに積もっていた手間がまとめて消えた感覚です

CLAUDE.md をはじめとした設定ファイルの種類はClaude Code 設定ファイル早見表に、ツール全体の仕組みはClaude Code 拡張機構入門にまとめています
コンテキストの設計を手を動かして体感したい方は、そのあたりから触ってみるのがおすすめです

まとめ 次はハーネスエンジニアリングへ

コンテキストエンジニアリングとは、AIに渡すコンテキストウィンドウ全体に何を積むかを設計する技術でした
プロンプトを置き換えるものではなく、プロンプトを内側に含む上位の設計だと押さえておくと迷いません

• コンテキスト=AIが一度に読み込む材料のかたまり、窓には上限がある
• 積む要素は システムプロンプト・ツール・RAG・メモリ・会話履歴・状態 の6つ
• AIの失敗はcontext failuresとして捉えると直す先が具体的になる
• CLAUDE.md は身近なコンテキストエンジニアリングの実例

ここまでで「何を渡すか」の設計は見えてきました
すると次に気になるのが、そのコンテキストを実際に出し入れしたり、道具を動かしたりするAIの周りの仕組みぜんぶです

そこを扱うのが、次回のハーネスエンジニアリングです
コンテキストを含めてAIを取り囲むソフトウェア基盤の話に進みます

連載「AIの○○エンジニアリング」の記事一覧

• 総まとめ(ハブ):AIの○○エンジニアリング4種
• #1 プロンプトエンジニアリング(前回)
• #2 コンテキストエンジニアリング(この記事)
• #3 ハーネスエンジニアリング(次回)
• #4 ループエンジニアリング