コンテキストエンジニアリングとは？ | GEO用語集

コンテキストエンジニアリングとは、LLMが回答を生成するときに目にするどの情報を、どの順序で、どの形式で提示するかを意図的に設計する実践です。これは単一のプロンプトを磨き上げるプロンプトエンジニアリングを包含し、さらにコンテキストウィンドウに入るすべてのもの（システムプロンプト、取得したドキュメント、会話履歴、ユーザーメタデータ、ツールスキーマなど）にまで拡張されます。Simon Willison、Tobi Lütke、Andrej Karpathyが2025年にこの用語を公に使い始め、2026年にはLLMプロダクトエンジニアリングにおける標準的な語彙となりました。

なぜ重要なのか

本番環境におけるLLMプロダクトの失敗のほとんどは、「モデルが悪い」ではなく「モデルに間違ったコンテキストを与えた」ことに起因します。100万トークンのコンテキストウィンドウがあっても、情報をランダムに詰め込むとパフォーマンスが低下します。これはよく文書化された「ロスト・イン・ザ・ミドル」効果です。コンテキストエンジニアリングは、合成された入力（RAG、メモリ、ツール、履歴）を設計変数として扱い、同じモデルでもより優れたコンテキスト構築によって2〜10倍優れたパフォーマンスを発揮できます。

コンテキストを構成するもの

システムプロンプト: 固定の指示。役割、制約、トーン、目標。

ユーザープロンプト: 今回のターンでのユーザーの入力。

会話履歴: 過去のターン。

RAGの結果: ベクトルDBからの関連ドキュメントとチャンク。

ツール定義: 呼び出し可能な関数の名前、説明、スキーマ。

ツール呼び出しの結果: 以前のツール呼び出しから返されたデータ。

ユーザーメタデータ: 言語、タイムゾーン、サブスクリプションプラン、行動履歴。

コンスティテューション / ガードレール: 安全ルール、禁止トピック、出力フィルター。

これらすべてが、LLMに渡される単一のコンテキストウィンドウへと統合されます。

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

観点	プロンプトエンジニアリング	コンテキストエンジニアリング
単位	単一のプロンプト文	コンテキストウィンドウ全体
関心事	「どう尋ねるか？」	「何を見せるべきか？」
レベル	戦術的（文レベル）	システム的（パイプラインレベル）
例	「ステップ・バイ・ステップで考えよう」を追加	RAGチャンクの数、順序、要約を決定

プロンプトエンジニアリングは良い文を書く技術であり、コンテキストエンジニアリングはそれらの文が存在する入力構造全体を設計する技術です。

核となる原則

必要なものだけを含める: コンテキストが長いほど「ロスト・イン・ザ・ミドル」が増え、コストも高くなります。無関係な情報は容赦なく削ぎ落としましょう。

意図的に順序づける: LLMは冒頭と末尾をより重視します。最も重要な指示とデータを端に置きましょう。

構造化されたタグ付け: 外部ドキュメントを<source>…</source>で、例を<example>…</example>で囲み、各部分の役割をモデルが理解できるようにします。

動的な選択: リクエストの種類が異なれば、異なるツールリスト、RAGの結果、システムプロンプトがふさわしくなります。画一的なやり方はトークンを浪費します。

要約と圧縮: 長い履歴を要約してトークンを節約します。Claudeのartifactsのような機能がその代表例です。

エージェントループを管理する: 複数ステップの推論では、ステップ間でコンテキストをクリーンにして再構築します。

実践上の課題

トークン予算: コンテキストウィンドウは無料ではありません。100万トークンを埋めると、コストとレイテンシーが爆発的に増えます。

関連性のランク付け: 取得するRAGチャンクの数と、どれだけリランキングするかを決めます。

メモリ戦略: 長期記憶はベクトルDBで、短期記憶は要約によって扱います。

デバッグ: 出力品質が低下したとき、コンテキストのどの部分が原因かを突き止めます。ロギングと再現性が不可欠です。

GEOへの示唆

AI検索エンジン自体がコンテキストエンジニアリングのパイプラインです。「コンテキストにうまく収まる」ように構造化されたコンテンツは、より多く引用されます。具体的には、① 各セクションが独立して要約可能であること、② 最初の文が核心となる回答を担うこと、③ メタデータと情報源が明示されていることです。これがブロガーにとっての「コンテキストエンジニアリングに優しいライティング」です。

Sources: