コンテキストエンジニアリングとは — プロンプト設計を超えた次の実践技術
2025年6月、Andrej Karpathy（元OpenAI、元Tesla AIリード）がXに投稿した一文が話題になった。「コンテキストエンジニアリングとは、次のステップのために文脈ウィンドウを適切な情報で埋める、繊細な技術と科学だ」。翌週、Shopify CEOのTobi Lütkeも同じ概念をXで取り上げ、Gartnerが「プロンプトエンジニアリングの時代は終わり、コンテキストエンジニアリングが始まった」と宣言した。
プロンプトエンジニアリングは「AIに何を言うか」を磨く技術だ。コンテキストエンジニアリングはその一段上にある。「AIがどんな情報と文脈の中で考えるか」を設計する技術だ。同じGPT-4やClaudeを使っていても、コンテキストの設計によって出力の精度が劇的に変わる。Bayer（製薬大手）の事例では、この設計の有無で正確率が8.3%から78.3%に改善した（差: 70ポイント）。
この記事では、コンテキストエンジニアリングの本質と、ビジネス現場での実践方法を解説する。
プロンプトエンジニアリングとの違いを理解する
多くの人は「プロンプトをうまく書けば、AIが賢くなる」と考えている。これは部分的には正しい。しかし、プロンプトだけを磨き続けるアプローチには構造的な限界がある。
プロンプトエンジニアリングとコンテキストエンジニアリングの違いを一言で言えば、「前提の違い」だ。プロンプトエンジニアリングは、文脈ウィンドウ（コンテキストウィンドウ）を所与のものとして受け取り、その中で最善のプロンプトを書こうとする。コンテキストエンジニアリングは、文脈ウィンドウ全体を設計の対象として扱う。
文脈ウィンドウの中に入るのは、プロンプトだけではない。システムプロンプト（AIの役割・制約定義）、過去の会話履歴、外部ドキュメントから取得した情報、利用可能なツールの定義、具体的な処理例（few-shot examples）、ユーザーに関する記憶情報——これら全てがモデルの「思考の土台」となる。コンテキストエンジニアリングは、この土台全体を意図的に設計する行為だ。
図1: コンテキストウィンドウ全体を設計対象にするのがコンテキストエンジニアリング
精度差を生む5つの設計変数
Anthropicのエンジニアリングブログ（2025年7月）は、コンテキストエンジニアリングを「LLMの推論時に提供するトークンの戦略的なキュレーション」と定義している。この「キュレーション」の質が、同じモデルで全く異なる結果をもたらす。
変数1: システムプロンプトの構造化
「あなたは優秀なアシスタントです」という一文から始まるシステムプロンプトは、コンテキストエンジニアリングとは言えない。効果的なシステムプロンプトは、背景（どんな企業・業務のAIか）、指示（何をどのように処理するか）、ツール活用の指針（いつどのツールを使うか）、制約（やってはいけないこと）を構造的に記述する。
Lat91では、AIエージェントのシステムプロンプトを設計するとき、「AIがこのプロンプトだけ読んで業務を理解できるか」を基準に評価している。業務担当者が退職した後でも、AIが適切に動き続けるだけの文脈が込められているかどうかだ。
変数2: 取得情報の質（RAG設計）
RAG（Retrieval-Augmented Generation）はコンテキストエンジニアリングの中核だ。ただし「関連ドキュメントを検索して埋め込む」だけでは不十分だ。何をどのように取得するかの設計が成果を左右する。
Databricks AI/BIの事例は示唆に富む。SQLを自動生成するシステムで、メトリクス定義とサンプルSQLをコンテキストに追加したところ、生成精度が53%から100%に改善した。取得する情報の「種類」と「粒度」の設計が、精度の天と地を分けた例だ。
変数3: ツール定義の最小化
AIエージェントにツールを与えすぎると、どれを使うべきか迷い、判断ミスが増える。Anthropicの分析では、エージェントに与えるツール数が増えるほど、ツール選択のエラー率が上昇する傾向が確認されている。コンテキストエンジニアリングの観点では、「使えるツールを多く与える」より「必要最小限のツールを明確に定義する」方が成果が高い。
変数4: 具体例の効果（few-shot）
「どう書くべきか」を言葉で説明するより、「こう書いた例」を見せる方がAIには効く。few-shot例はコンテキストエンジニアリングの強力な武器だ。Anthropicは「few-shot例は千の指示より雄弁だ」と表現している。
注意すべきは、few-shot例の質だ。「良い例だけ」を見せると、AIは例のない状況で判断を誤ることがある。「良い例と、その逆の悪い例」を組み合わせることで、判断の幅が広がる。
変数5: メモリ設計（コンテキストロットの回避）
会話が長くなるにつれて、AIの情報想起精度が下がる現象を「コンテキストロット（context rot）」と呼ぶ。Anthropicが観察した現象で、大量の情報がコンテキストウィンドウに積み重なると、前半に出てきた重要情報をモデルが正確に参照できなくなる。
解決策は、「何を残し、何を要約し、何を外部メモリに移すか」の設計だ。長期記憶（過去の会話・ユーザー好み）と短期記憶（現在のタスク文脈）を分離し、必要なタイミングで引き出す構造が有効だ。
実際にどれだけ変わるのか: 業種別データ
抽象的な説明だけでは実感しにくい。研究データと実企業の事例を示す。
製薬大手Bayerが薬物安全性監視（ファーマコビジランス）システムでGPT-4を活用した実験では、スキーマ情報だけを与えた状態では正確率8.3%だった。ビジネス文脈のドキュメント（業務定義・判断基準）を追加すると、同じモデルで78.3%まで改善した。改善幅は70ポイントで、モデルを変えたのではなく、コンテキストを変えただけだ。
SnowflakeのCortex Analyst（BI自動化スイート）では、GPT-4に意味論的モデル（セマンティックレイヤー）なしで質問に答えさせると約45%の精度だった。意味論的モデルを加えると90%超になった（出典: Snowflake社発表、2025年）。
LinkedInのカスタマーサービスAIは、RAGと知識グラフを組み合わせたコンテキスト設計を導入した結果、精度が78%改善し、問題解決時間が40時間から15時間に短縮した（63%削減）。
研究機関の集計では、適切なコンテキストアーキテクチャを持つ組織は、そうでない組織と比較して「50%高速な応答時間」「40%高い出力品質」を実現しているとされる（出典: Atlan社ベンチマーク、2026年）。
日本企業が見落としているコンテキスト設計の問題
Lat91が企業のAI活用を支援する中で、日本企業に最も多く見られる課題がある。それは「プロンプトを書いたら終わり」という認識だ。
正確に言うと、こういう状況が多い。ChatGPTを社内で使い始め、担当者がプロンプトを工夫して一定の成果を出す。その「良いプロンプト」をドキュメントに記録し、組織に展開しようとする。しかし他の社員が使うと同じ結果が出ない。「AIが難しい」という結論になり、活用が停滞する。
この問題の本質はプロンプトではなく、コンテキストだ。担当者が成果を出せたのは、その人が業務の文脈・制約・過去事例を暗黙知として持っていたからだ。プロンプトはその暗黙知と組み合わさって機能していた。コンテキストなきプロンプトは、宙に浮いた指示書だ。
組織でAIを展開するとき、担当者の暗黙知をシステムプロンプトや取得ドキュメントとして明文化するプロセスが、コンテキストエンジニアリングの実践だ。
今週から試せる3つのアクション
コンテキストエンジニアリングは大規模なシステム投資がなくても始められる。まず3つの小さな実験から試してほしい。
アクション1: システムプロンプトの構造化（所要時間: 30分）
現在使っているAIツール（ChatGPT、Claude等）で、以下の4項目をシステムプロンプトに追加する。「あなたは〇〇会社の〇〇業務を担当するAIです（背景）」「あなたの役割は〜です（役割）」「〜の形式で回答してください（フォーマット）」「〜については回答しないでください（制約）」。この構造化だけで、多くの場合、出力の安定性が改善する。
アクション2: few-shot例の追加（所要時間: 1時間）
最も効果が高かった過去の出力例を3件選び、プロンプトの後半に「以下はよい回答の例です」として追加する。特に業務固有のフォーマットや判断基準がある場合、例示が最も効率的な情報伝達方法だ。
アクション3: コンテキスト分離の実験（所要時間: 2時間）
一つのプロンプトで全てを解決しようとするのをやめ、「分類」「取得」「生成」を3つのAI呼び出しに分ける。例えば、「まず問い合わせを分類する → 分類に応じたドキュメントを取得する → 取得情報を元に返信を生成する」という3ステップだ。コンテキストを意図的に分離することで、各ステップの精度が上がる。
コンテキストエンジニアリングを支えるツール
実装を支援するツールエコシステムも2026年時点でかなり成熟している。
エージェントオーケストレーション（複数AI判断の連携）にはLangChain/LangGraph、OpenAI Agents SDKが広く使われている。文書検索・取得（RAG）はLlamaIndex（5,500以上のデータソース統合に対応）が標準的だ。長期メモリにはMem0やZepが専門プラットフォームとして存在する。企業向けのコンテキスト管理プラットフォームはAtlanが代表格で、2025年10月にはVCのTheory VCが「コンテキストプラットフォーム」を新たなソフトウェアカテゴリとして定義した。
図2: コンテキストエンジニアリングを支えるツールエコシステム
「うまくいかない」ケースに共通する設計ミス
コンテキストエンジニアリングが話題になるにつれ、「試したがうまくいかなかった」という声も増えている。失敗パターンを見ると、共通の設計ミスがある。
最も多いのは「詰め込みすぎ」だ。「情報が多いほどAIが賢くなる」という思い込みから、コンテキストに大量のドキュメントを投入する。しかしコンテキストロットの観点から言えば、関係のない情報は「ノイズ」になる。関連性の低い情報がコンテキストの大部分を占めると、モデルの精度はむしろ下がる。「何を入れるか」と同じくらい、「何を入れないか」が重要だ。
次に多いのは「一度設計したら終わり」だ。業務は変わる。規則も変わる。コンテキストは生き物であり、定期的な見直しが必要だ。システムプロンプトやRAGのドキュメントが6ヶ月前のままになっているケースを、Lat91はよく見かける。
まとめ
- コンテキストエンジニアリングは「プロンプト」ではなく「文脈ウィンドウ全体」を設計する技術
- 同じモデルでも、コンテキスト設計の質で精度が劇的に変わる（Bayer: 8.3% → 78.3%）
- 5つの設計変数: システムプロンプト、RAG、ツール定義、few-shot例、メモリ管理
- 今週から3つのアクション: システムプロンプトの構造化、few-shot例の追加、コンテキスト分離実験
- 「うまくいかない」の多くは詰め込みすぎと設計後の放置が原因
AIを使っていて「なんとなく精度が低い」「安定しない」と感じている方は、プロンプトを変えるより先に、コンテキスト全体を見直すことを勧める。そこに原因がある可能性が高い。
Lat91では、AIエージェントの設計・導入から運用まで、一気通貫でサポートしています。
コンテキストエンジニアリングを含め、「自社業務に合ったAI設計」を最短距離で実現したい方は、まずは無料相談からどうぞ。