What is context engineering?

It refers to designing what information an AI receives in its context window — selecting the right content, timing, and volume to improve output quality.

How does it differ from prompt engineering?

Prompt engineering optimizes the instruction text itself. Context engineering is broader — it designs the full information environment the AI operates in, including documents, past decisions, and tool outputs.

- How does it relate to spec-driven development? -

Spec-driven development defines "What" to build. Context engineering also addresses "Why" — encompassing design rationale and decision history alongside specifications.

How can I get started with context engineering?

Start by auditing what context you currently provide, separate static from dynamic information, and begin recording the rationale behind design decisions. ADR is one effective method for structuring this.

コンテキストエンジニアリングとは何か

AIコーディングツールを使っていて、「プロンプトの書き方を工夫しても、なかなかAIが思い通りに動いてくれない」と感じることはないでしょうか。

プロンプトの質を高めることはもちろん大切です。しかし2025年後半から2026年にかけて、AI開発の現場では「プロンプトの改善だけでは限界がある」という認識が急速に広まりました。その流れの中で注目されているのが、コンテキストエンジニアリングという考え方です。

この記事では、コンテキストエンジニアリングとは何か、他のアプローチとの違い、そしてなぜ今この概念が重要視されているのかを、はじめての方にもわかりやすく解説します。

コンテキストエンジニアリングとは

コンテキストエンジニアリングとは、AIが次のステップで最適な出力を生成するために、コンテキストウィンドウに「適切な情報を、適切なタイミングで、適切な量だけ」詰めることを指します。

この概念が広く知られるきっかけとなったのは、2025年6月のAndrej Karpathy氏（元Tesla AI責任者・OpenAI共同創業者）のポストです。彼はコンテキストエンジニアリングを「コンテキストウィンドウに適切な情報を詰める繊細な技術と科学」と表現し、プロンプトエンジニアリングに代わる用語としての採用を支持しました。この発言を契機に議論が活発化し、2025年後半から2026年初頭にかけて、AIコーディングにおける中心的な概念として定着しつつあります。

コンテキストに含まれるものは、タスクの説明や指示文だけではありません。Few-shotの例示、RAGで取得した関連データ、ツールの定義、過去の対話履歴、プロジェクトの設計方針など、AIの判断に影響を与えるすべての入力情報がコンテキストです。少なすぎればAIは文脈を理解できず、多すぎればノイズで推論精度が低下する。このバランスを設計すること自体が、ひとつの専門領域として認識されるようになりました。

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

プロンプトエンジニアリングは、AIへの「指示文の書き方」を最適化するアプローチです。明確な指示を書く、例を示す、ステップバイステップで考えさせるなど、1回のリクエストで最良の応答を引き出すテクニックに焦点を当てます。

一方、コンテキストエンジニアリングはより広い視点を持ちます。プロンプトそのものだけでなく、AIが参照するすべての情報（ドキュメント、過去の意思決定、プロジェクトの制約、外部ツールの出力など）をどう構成し、いつ・どれだけ提供するかを設計します。

たとえて言えば、プロンプトエンジニアリングが 「舞台上の台本」 を磨くことだとすれば、コンテキストエンジニアリングは 「舞台装置、照明、小道具、音響」 をすべて含めた舞台全体を設計することです。どれだけ優れた台本も、空の舞台では力を発揮しにくい。逆にシンプルな台本でも、周到に設計された舞台の上では驚くほどの成果を出せます。

設計書ドリブン開発との違い

2025年後半にはSpec（仕様）を先に書いてからAIにコードを生成させる設計書ドリブン開発 （Specドリブン、設計駆動開発とも）も注目を集めました。GitHub Spec KitやAWS Kiroなどのツールが登場し、「仕様→計画→タスク分割→実装」という構造化されたワークフローを提供しています。

設計書ドリブン開発は、AIに「何を作るか（What）」を明確に伝えることに長けています。要件定義を仕様書として形式化し、AIエージェントが正確な実装を行うためのガイドとして機能します。

コンテキストエンジニアリングはさらに上位の概念です。設計を「コンテキストのひとつ」として内包しつつ、設計意図（なぜその仕様なのか）、過去の意思決定履歴、プロジェクト固有の制約なども含めた、AIが判断に必要とする情報全体を扱います。設計書が「What」を定義するのに対し、コンテキストエンジニアリングは「What」に加えて「Why（なぜそうするのか）」まで射程に入れているのが特徴です。

この「Why」の有無が実際に大きな差を生むことは、研究でも示されています。拙著（2026）のsqlew MCPを用いた制御実験では、CLAUDE.mdに同じ「TDDで開発すること」という指示を置いた条件で、TDDを採用した理由（Why）がADRとして記録されている場合はE2Eテストを最大25件自発的に生成したのに対し、指示だけで理由がない場合の生成数はゼロでした。

Kitayama, S. (2026). "Rediscovering Architectural Decision Records: How Persistent Design Context Improves LLM Code Generation" — https://doi.org/10.36227/techrxiv.177205025.54351571/v1

コンテキストエンジニアリングの効果

研究は、コンテキストの質がAIの出力に大きく影響することを裏付けています。

Chroma Researchの「Context Rot」研究では、18のLLMモデルを対象にした評価で、タスク複雑度が同じでも入力トークン数が増えるだけで出力品質が低下することが確認されました。また、Liu et al.（2024）は、必要な情報がコンテキストに含まれていても、周囲の情報量が多いと推論精度が下がることを報告しています。

Chroma Research. "Context Rot: How Increasing Input Tokens Impacts LLM Performance" — https://research.trychroma.com/context-rot

Liu, N. F. et al. (2024). "Lost in the Middle: How Language Models Use Long Contexts" — https://doi.org/10.1162/tacl_a_00638

つまり、「情報を持っている」ことと「情報を活用できる」ことは別の問題です。コンテキストエンジニアリングは、この問題に対して「必要な情報を、必要なタイミングで、適切な量だけ提供する」というアプローチで応えます。

Anthropicの公式テクニカルブログでも、静的なコンテキスト（CLAUDE.mdなど）と動的なコンテキスト（MCPやCLIツールでJust-in-Timeで取得する情報）のハイブリッドモデルが推奨されており、コンテキストエンジニアリングはプロンプトエンジニアリングの自然な進化形と位置づけられています。

Anthropic. (2025). "Effective Context Engineering for AI Agents" — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

具体的に何をするべきか

コンテキストエンジニアリングの考え方を実践に移すために、まず取り組めることを整理します。

コンテキストの棚卸しから始めましょう。AIに渡している情報（CLAUDE.mdやシステムプロンプト）を見直し、本当に今のタスクに必要な情報だけが含まれているか確認します。使われていない古い指示や、矛盾した記述がないかチェックしてみてください。

次に、静的コンテキストと動的コンテキストの分離を検討します。すべての情報を1つのファイルに詰め込むのではなく、常に必要な基本方針（静的）と、タスクに応じて参照すべき過去の意思決定や設計根拠（動的）を分けて管理します。

そして 「Why」の記録 を習慣にしましょう。「何をするか」だけでなく「なぜそうするか」を記録しておくことで、AIが文脈を理解したうえで判断できるようになります。前述の研究が示すように、理由付きの情報はAIの行動に質的な変化をもたらします。

コンテキストウィンドウの外に 「外部記憶」を構築し、必要な情報を適切なスコープと量で供給する仕組みを持つことが、コンテキストエンジニアリングの実践的な鍵です。そのための手法として有効なのがADR（Architecture Decision Record） で、設計上の意思決定とその根拠を構造化して記録し、AIがセッションをまたいで参照できるようにします。ADRは手動で書くこともできますし、MCPツールのsqlewを使えば記録と取得の自動化も可能です。

コンテキストエンジニアリングは、特別なツールがなくても始められます。大切なのは「AIに何を見せるか」を意識的に設計する姿勢そのものです。