「プロンプトをどう直しても、AIの回答が良くならない」という経験をしたことがあるなら、おそらく問題の場所を間違えている。
プロンプトの改善で解決するのは、問いのたて方が悪いケースだ。しかし実際に起きている問題の大半は、AIが「知るべき情報を持っていない」ことから来る。自社の過去事例、製品の仕様、顧客の状況、社内ポリシー——これらをAIが知らない状態で質問しても、汎用的な回答しか返ってこない。プロンプトをどれだけ磨いても変わらない。
この問題に正面から向き合う概念が「コンテキストエンジニアリング」だ。2025年中頃に登場し、AIエンジニアリングの世界では急速に標準語彙になってきた。この記事では、コンテキストエンジニアリングが何で、プロンプト設計と何が違い、実際のビジネスでどう使えるかを解説する。
「プロンプトを直しても改善しない」現象の正体
あるカスタマーサポートチームが生成AIツールを導入した。狙いは問い合わせ回答の自動化だ。最初の数週間は試行錯誤が続いた。「もっと丁寧に答えて」「専門用語を使わないで」「3行以内にまとめて」——プロンプトの指示を変えるたびに、文体や長さは変わった。しかし肝心の「正しい答え」が返ってこない問題は解決しなかった。
理由は単純だった。AIは自社の製品仕様を知らなかった。返品ポリシーも知らなかった。顧客ごとの過去のやり取り履歴も持っていなかった。「丁寧に」「短く」という指示に従っても、知らない情報は答えられない。
これがプロンプトエンジニアリングの限界だ。プロンプトは「AIへの質問の仕方」を制御する。しかし「AIが何を知っているか」は制御しない。コンテキストエンジニアリングはこの「AIが何を知るか」を設計する技術だ。
コンテキストエンジニアリングとは何か：定義と出所
「コンテキストエンジニアリング」という言葉が広まったのは2025年6月頃だ。テスラのAI責任者を務めたAnthropicのAndrej Karpathy（現在は独立した研究者）が次のように表現した。
「コンテキストエンジニアリングとは、次のステップに必要な情報だけをコンテキストウィンドウに詰め込む、繊細な技術と科学だ」（Andrej Karpathy, X, 2025年6月）
6日後、Shopifyのトビー・ルッツェCEOも同じ概念を支持する投稿をした。DjangoのコクリエイターであるSimon Willisonは、この言葉が定着する理由を的確に説明している。
「コンテキストエンジニアリングは定着する。なぜならこの言葉の自然な意味が、実際に意味することに近いから。LLMから良い結果を得るために、適切なコンテキストを慎重に構築するという行為を指す言葉として、これほど的確なものはない」（Simon Willison, 2025年6月）
「プロンプトエンジニアリング」という言葉は、ChatGPTに長い指示文を書くことだという誤解を生んだ。コンテキストエンジニアリングは、そのイメージを一新する。
プロンプト設計との違いを図解で理解する
図1：プロンプト設計とコンテキストエンジニアリングの関係
Anthropicのエンジニアリングブログには、この本質がこう書かれている。「目標は、期待する結果の確率を最大化する、最小限の高品質トークンセットを特定することだ」。少ない情報で最大の結果を出す——これがコンテキストエンジニアリングの核心だ。
リアルな成果：マイクロソフト・リンクトイン・ファイブシグマの事例
理論より実績を見た方が理解が早い。コンテキストエンジニアリングを実装した企業の具体的な成果を紹介する。
マイクロソフト（開発生産性）
社内開発者向けにAIコーディングアシスタントを展開した際、コードベース全体のアーキテクチャ図、チームの設計指針、過去のプロジェクト履歴をコンテキストとして渡す仕組みを構築した。単なるコード補完ツールではなく、組織のコンテキストを知るアシスタントに変えた結果、完了タスクが26%増加、エラーが65%減少、新しい開発者のオンボーディング期間が55%短縮した。
LinkedIn（カスタマーサポート）
サポートチームが問い合わせに答える際、関連するサポートチケット履歴・製品ポリシー・過去の解決事例を知識グラフで接続したRAGシステムを構築した。問い合わせごとに関連情報が自動的に引き出される設計にした結果、1件あたりの解決時間が28.6%短縮した。
Five Sigma（保険）
保険金請求の審査AIに、契約ポリシー、請求履歴、規制要件、顧客プロフィールを同時に渡すコンテキスト設計を実装した。単に「請求書を見てください」ではなく、「この顧客の契約内容と過去履歴を知った上で審査してください」という情報環境を作った。処理エラーが80%減少、審査精度が95%超、アジャスターの生産性が25%向上した。
3事例に共通するのは、AIに渡す情報の設計が変わったことだ。プロンプトの言葉遣いではなく、AIが参照できる情報の範囲と質を変えた。
コンテキストが壊れるとき：よくある5つのミス
コンテキストエンジニアリングの概念を知ると、「とにかく情報を渡せばいい」という誤解が生まれやすい。しかしそれも間違いだ。
1. コンテキストの詰め込みすぎ（Context Rot）
ChromaのResearch（2026年）では、18種類のフロンティアモデル全てについて、入力トークン数が増えるほどパフォーマンスが低下することが確認された。これを「コンテキスト腐敗（Context Rot）」と呼ぶ。無関係な情報を大量に渡すと、モデルが本当に重要な情報を見失う。「情報は多い方がいい」は誤りだ。
2. 古い情報をそのまま渡す
6ヶ月前のポリシー文書、更新された製品仕様の古いバージョン——これらをコンテキストに含めると、AIは古い情報に基づいて判断する。鮮度管理は人間が意識的に行わないと、コンテキストは時間とともに劣化する。
3. 会話履歴をそのまま全部渡す
長い会話の全履歴をコンテキストに含めると、モデルが中間部分の情報を見落としやすくなることが研究で示されている（LLMの「中間健忘」と呼ばれる現象）。長い会話は要約・圧縮してから渡す方が精度が上がる。
4. エラーの自己増幅ループ
AIが間違えた判断をした場合、その修正プロセスがコンテキストに蓄積される。次の判断でそのノイズが参照され、さらに間違える——という自己強化のエラーループが起きる。定期的なコンテキストのリセット設計が必要だ。
5. 業界固有の知識を省略する
汎用的な知識だけでAIが動く時代は終わった。製造業なら製品仕様と検査基準、金融なら規制要件と商品設計、医療なら診療プロトコルと患者固有情報——業界のコンテキストなしに動くAIは、業界に詳しくない新入社員と同じだ。
月曜から試せる：社内データをAIに読ませる3ステップ
コンテキストエンジニアリングは、高度なエンジニアリングなしでも部分的に始められる。最初のステップを3つ示す。
図2：コンテキストエンジニアリング入門：3ステップ
STEP 3の「試して計測する」を工具なしで始める最も手軽な方法がある。ClaudeやChatGPTとの会話で、システムプロンプト（最初に渡す指示文）に自社の製品情報や対応ポリシーをそのままテキストで貼り付けてみる。これだけでも、何も渡さない場合と回答品質の差が確認できる。
Lat91では自社業務の自動化を10体のAIエージェントチームで行っているが、最初の試行錯誤で最も時間を費やしたのがコンテキスト設計だった。「どんな指示を書くか」ではなく「何を知らせるか」を変えるたびに、回答品質が段違いに変わる体験を繰り返した。プロンプトの言葉遣いより、コンテキストの範囲を変える方が効果が大きいケースが圧倒的に多かった。
「これは大企業向けの話では？」という反論
RAG（Retrieval-Augmented Generation）という言葉が出てくると、「ベクトルデータベースが必要」「エンジニアがいないと無理」という印象を持つ人が多い。それは確かにコンテキストエンジニアリングの1形態だ。ただし出発点ではない。
前述のSTEP 3で書いたように、最初は「APIを叩かず、プロンプトに情報を貼り付ける」だけでもコンテキストエンジニアリングの効果を体験できる。件数が増えてきたり、リアルタイムで最新情報を引き出したいニーズが出てきた段階で、RAGやベクトルデータベースを検討する。技術は目的に合わせて段階的に使えばいい。
日本のSMEのAI活用率は16%（楽天調べ、2025年）で、「活用できていない」企業の40%は「何に使えばいいかわからない」と答えている。コンテキストエンジニアリングの観点を持つと、この問いへの答えが変わる。「AIに何をさせるか」より先に「AIに何を知らせるか」を考えると、業務との接点が見つかりやすい。
2028年、コンテキストは競争優位になる
AIモデル自体の性能差は、今後2〜3年で縮まっていく。Claude 4、GPT-5、Gemini 2.5——これらの回答品質の差は、同じコンテキストを渡した場合はそれほど大きくない。つまり差がつく部分は、AIに渡すコンテキスト設計の良し悪しに移っていく。
自社の業務知識、顧客履歴、過去の判断記録をどれだけ組織的に整備し、AIが参照できる形にしているか——これがAI活用の実力差になる時代が近づいている。RAGシステムやベクトルデータベースへの投資が単なるコストではなく、競争優位の源泉になるというのはそういう意味だ。
今は「試してみる」段階で十分だ。ただし「いつかやる」と先送りし続けると、組織の知識がAIに渡せる形で蓄積されないまま時間が過ぎる。コンテキストの設計は、AIより先に「自社が何を知っているか」の整理から始まる。
まとめ
- プロンプトを直しても改善しない場合、問題はAIが「知るべき情報を持っていないこと」にある
- コンテキストエンジニアリングはAIに何を知らせるかを設計する技術で、プロンプト設計を包含する上位概念だ
- マイクロソフト（エラー65%減）、リンクトイン（解決時間28.6%減）、Five Sigma（エラー80%減）は、コンテキスト設計を変えることで実現した
- コンテキストは「多ければよい」ではなく、質と鮮度の管理が必要だ（Context Rot）
- 最初の一歩は今日から始められる：AIに自社資料を渡して試すことから
Lat91では、自社の業務データをAIエージェントが参照できる形に整備するところから、システム構築まで一緒に設計しています。
「まずどこから始めればいいかわからない」という方は、無料相談でお気軽にどうぞ。自社のコンテキストを棚卸しするところから一緒に考えます。