コンテキストエンジニアリングとは何か——プロンプトの次に来る、AIの「情報環境」を設計する技術

「良いプロンプトを書く」だけでは限界がある

AIを使っていて、こんな経験をしたことはないでしょうか。「丁寧に指示を書いたつもりなのに、的外れな答えが返ってくる」「単純な質問なら上手くいくのに、複雑なタスクを頼むと途端に精度が落ちる」「昨日うまくいったプロンプトが、今日は同じように動かない」。

こうした壁に当たったとき、多くのエンジニアはプロンプトの書き方を改善しようとします。しかし2025〜2026年にかけて、エンジニアコミュニティの間で「問題はプロンプトの書き方ではなく、AIに渡す情報の設計そのものにある」という認識が急速に広まっています。その考え方を体系化したのが、コンテキストエンジニアリング（Context Engineering）です。

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

コンテキストエンジニアリングという言葉が急速に注目を集めたのは2025年6月のことです。Shopify CEOのTobi Lutke氏がX（旧Twitter）に「プロンプトエンジニアリングよりコンテキストエンジニアリングという言葉の方が好きだ。LLMがタスクを合理的に解決できるように、あらゆる文脈を提供する技術をより的確に表している」と投稿し、それをLinux生みの親として知られるAndrej Karpathyが引用する形で賛同を示したことで、一気に拡散しました。

Anthropicのエンジニアリングチームはこれを「次のステップに必要な情報でコンテキストウィンドウを埋める繊細なアートでありサイエンス」と表現しています。

プロンプトエンジニアリングが「AIに何をさせるか（What）」という指示の書き方を最適化することに焦点を当てているのに対し、コンテキストエンジニアリングは「AIが何を知っている状態でタスクに臨むか（What & How）」という情報供給の設計問題を扱います。

コンテキストウィンドウという「器」を理解する

コンテキストエンジニアリングを理解するには、まずLLMの「コンテキストウィンドウ」という概念を押さえる必要があります。

LLMはあなたとの会話を記憶しているように見えますが、実際には「今このリクエストで渡されたテキスト全体」しか見えていません。その入力可能な最大範囲がコンテキストウィンドウです。単位はトークン（日本語ではおよそ1文字1〜2トークン）で表され、たとえばClaude Sonnet 4.6は約20万トークン、GPT-4oは約12.8万トークンを受け付けます。

重要なのは、このウィンドウの中に「プロンプト（指示）」だけが入るわけではないということです。実際のLLMアプリケーションでは、このウィンドウには以下のような多様な情報が詰め込まれます。

コンテキストエンジニアリングとは、この「器」の中に何を・どの順序で・どれだけ詰め込むかを意図的に設計することです。

プロンプトエンジニアリングとの本質的な違い

「結局プロンプトをうまく書くことと同じでは？」と感じる方もいるかもしれません。しかし両者には明確な違いがあります。

プロンプトエンジニアリングは主に「一回のやりとり」を前提としています。ユーザーが書く指示文を工夫して、より良い回答を引き出す技術です。Few-shotでサンプルを見せる、Chain-of-Thoughtで「ステップバイステップで考えて」と促す、役割を与えるといったテクニックはすべてプロンプトの書き方の工夫です。

一方でコンテキストエンジニアリングは「AIエージェントが複数のステップを経て複雑なタスクをこなす」ような場面で特に重要になります。複数のツールを呼び出しながら段階的に作業を進めるエージェントでは、各ステップで何の情報をコンテキストに残すか・捨てるかという設計が、最終的な出力品質を大きく左右します。

また、コンテキストウィンドウには上限があります。長い会話履歴や大量の外部ドキュメントを全部詰め込もうとすると、重要な情報が埋もれたり、トークンコストが跳ね上がったりします。「何を入れるか」だけでなく「何を入れないか」という取捨選択の設計もコンテキストエンジニアリングの核心です。

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

実際のLLMアプリケーションでコンテキストウィンドウに含まれる情報は、大きく次の5種類に整理できます。

1. システムプロンプト（Instructions）

AIに与える役割・目的・制約・応答スタイルを定義します。「あなたは〇〇のエキスパートです」という設定や「日本語で回答してください」という制約がこれにあたります。変わることのない固定情報であり、コンテキストの骨格を担います。

2. ツール定義（Tools）

AIが呼び出せる関数やAPIの仕様を宣言します。「このAIはWeb検索ができる」「このAIはデータベースに書き込める」という能力の定義です。ツールが多すぎると、AIがどのツールを使うべきか迷い精度が落ちるため、関連するツールだけに絞ることが重要です。

3. 外部データ（Context & Memory）

AIが本来持っていない知識を補うために、その都度注入する情報です。RAG（検索拡張生成）によって取得したドキュメントや、データベースの検索結果、ファイルの内容などがこれにあたります。「どのデータを」「どのタイミングで」「どれだけ」注入するかの設計がパフォーマンスを左右します。

4. 会話履歴（Conversation History）

直前のやり取りのログです。文脈の連続性を保つために必要ですが、無制限に積み上げると重要な情報が薄まります。長い会話では要約して圧縮する、重要なやり取りだけ残すといった工夫が必要です。

5. ユーザー指示（User Input）

今回解いてほしいタスクそのものです。プロンプトエンジニアリングが磨いてきたのは主にこの部分ですが、コンテキストエンジニアリングでは残りの4つの設計をより重視します。

実践的な設計の原則

コンテキストエンジニアリングを実際に取り入れる際に意識したい原則をまとめます。

「必要な情報だけ渡す」原則

コンテキストに詰め込む情報が多ければ良いわけではありません。AIは与えられた情報の中から推論するため、無関係な情報が多いと本当に重要な部分が見落とされます（Needle in a Haystack問題）。「このタスクに本当に必要な情報は何か」を問い直すことが出発点です。

RAGで外部ドキュメントを注入する場合、全文を渡すのではなく関連する段落だけを抽出して渡す。会話履歴は全件保持せず一定の長さを超えたら要約する。こういった「絞り込みの設計」が精度向上につながります。

「順序と構造で伝える」原則

LLMはコンテキストウィンドウの最初と最後に置かれた情報を重視する傾向があります。最も重要な指示や制約はシステムプロンプトの冒頭に置き、参照してほしい資料はユーザー指示の直前に配置するなど、情報の順序を意図的に設計します。

また、自然言語だけで書くより、Markdownの見出しや箇条書きで構造化した方が、AIが情報を正確に参照しやすくなります。「以下はユーザーのプロフィールです：」「以下がドキュメントの内容です：」のようなラベルで各情報のブロックを明示するのも有効です。

「動的に構築する」原則

コンテキストは事前に固定しておくのではなく、タスクや会話の状況に応じて動的に組み立てます。ユーザーの質問の種類によって注入するドキュメントを変える、途中のツール実行結果をコンテキストに追記する、会話が長くなったら要約を挟むといった動的なコンテキスト管理が、高品質なエージェントアプリケーションの鍵になります。

以下は動的コンテキスト構築の概念的なイメージです。

def build_context(user_query: str, conversation_history: list) -> str:
    # 1. 関連ドキュメントを検索して注入
    relevant_docs = retrieve_docs(user_query, top_k=3)

    # 2. 会話履歴が長ければ要約
    if len(conversation_history) > 20:
        history_text = summarize(conversation_history[-20:])
    else:
        history_text = format_history(conversation_history)

    # 3. コンテキストを構造化して組み立て
    context = f"""
## 参照ドキュメント
{format_docs(relevant_docs)}

## 会話履歴
{history_text}

## 現在のユーザーの質問
{user_query}
"""
    return context

なぜ今この考え方が重要なのか

コンテキストエンジニアリングが注目される背景には、AIエージェントの普及があります。単純な質問応答ではなく、複数のツールを自律的に使いながら長い作業を遂行するエージェントでは、各ステップでの情報管理が最終的な成否を分けます。

また、LLMのコンテキストウィンドウが拡大し「何でも全部入れれば良い」という誤解が広がる中、実際にはウィンドウが大きくなるほど「重要な情報をいかに際立たせるか」という設計の重要性が増しています。「長いから大丈夫」ではなく「正しく設計されているから大丈夫」という発想の転換が求められます。

プロンプトエンジニアリングのスキルは引き続き有効です。しかしそこに「コンテキスト全体を設計する視点」が加わることで、LLMアプリケーションの品質は次のステージに上がります。AI活用が「試しに使う」フェーズから「本番で信頼できる品質を保つ」フェーズへ移行しつつある今、コンテキストエンジニアリングはエンジニアが身につけるべき実践的なスキルとして急速に定着しています。

指示の書き方を磨くことは大切ですが、それより先に「AIが正しく推論できる環境を整える」という発想を持てたとき、AI活用の景色がひとつ変わるはずです。