コンテキストエンジニアリングとは？プロンプトとの違いと実装手順
- 対象は指示文（プロンプト）の書き方
- 主に1回の入出力の品質を高める
- 役割指定・例示・出力形式の指定が中心
- 単発のチャット利用に向く
- 対象はLLMに渡す情報全体
- 複数ターン・長時間タスクの品質を保つ
- ツール定義・記憶・検索結果・履歴を管理
- AIエージェントの業務実装に向く
- 1. 書き出す（Write）作業メモや中間結果をコンテキスト外に保存する
- 2. 選ぶ（Select）タスクに必要な情報・ツールだけを検索して取り込む
- 3. 圧縮する（Compress）長くなった履歴やツール出力を要約し、トークンを節約する
- 4. 分離する（Isolate）サブエージェントに作業を分け、それぞれのコンテキストを独立させる
コンテキストエンジニアリングは、生成AIを業務で使うときの品質を左右する設計領域です。プロンプトの書き方を工夫するだけでなく、LLMに「何を、どの順で、どれだけ」渡すかを設計します。AIエージェントやRAGを使った社内システムが増えるなか、AX推進の実務者が押さえておきたい考え方と、実装の手順を整理します。
コンテキストエンジニアリングとは？
コンテキストエンジニアリングとは、LLMが応答を生成する時点で参照する情報全体を設計し、管理する技術です。
LLMは学習済みの知識に加えて、1回の推論で入力される情報（コンテキストウィンドウ）をもとに出力を決めます。この入力には、ユーザーの質問だけでなく次のものも含まれます。
- システムプロンプト
- 会話履歴
- RAGで検索した社内文書
- ツールの実行結果
- 過去のやり取りから抽出した記憶（メモリ）
これらを目的に合わせて選び、整理し、適切な量に絞って渡すのがコンテキストエンジニアリングです。
言葉が広まった背景は？
2025年半ば、AIエージェント開発の実務者のあいだで「プロンプトより文脈設計が重要」という認識が広がり、この呼び名が定着しました。
2025年6月ごろ、ShopifyのCEOであるTobi Lütke氏や、OpenAIの元研究者Andrej Karpathy氏がSNSで「プロンプトエンジニアリングよりもコンテキストエンジニアリングという呼び方がふさわしい」という趣旨の発言をし、注目を集めました。その後、LangChainが「The rise of “context engineering”」（2025年6月）を、Anthropicが「Effective context engineering for AI agents」（2025年9月）を公開しました。開発者向けの設計論として体系化が進んでいます。
なぜAX推進で重要なのか？
業務で使うAIの精度は、モデルの性能よりも渡す社内情報の質と量で決まることが多いからです。
汎用のチャットボットであれば、プロンプトを工夫するだけでも一定の成果が出ます。しかし、社内規程に沿った回答、顧客ごとの履歴をふまえた対応、複数システムをまたぐ業務処理などでは、「LLMが知らない社内の文脈」をどう渡すかが成否を分けます。現場では「モデルを最新版に替えたのに精度が上がらない」という相談をよく受けます。原因をたどると、検索で取得した文書が古い、関係の薄い情報が大量に混ざっている、といったコンテキスト側の問題であることが少なくありません。
プロンプトエンジニアリングとの違いは？
プロンプトエンジニアリングは「指示文」を最適化し、コンテキストエンジニアリングは「入力情報全体の流れ」を設計します。
設計対象の範囲はどう違うのか？
設計の対象が、1回の指示文から、システム全体の情報供給の仕組みへと広がるのが最大の違いです。
| 観点 | プロンプトエンジニアリング | コンテキストエンジニアリング |
|---|---|---|
| 主な対象 | 指示文・例示（few-shot）・出力形式 | 指示文＋検索結果・履歴・ツール・メモリ |
| 設計の単位 | 1回の問い合わせ | 複数ターン・複数ステップの処理全体 |
| 主な担い手 | 利用者・プロンプト作成者 | 開発者・データ整備担当・業務設計者 |
| 典型的な用途 | 文章作成、要約、単発の質問応答 | RAG、AIエージェント、業務システム連携 |
| 改善の手段 | 言い回し・構造の調整 | 情報の選別・圧縮・分離・取得タイミングの設計 |
| 失敗の典型 | 指示が曖昧で意図とずれる | 情報過多・不足・古い情報による誤回答 |
両者は対立する概念なのか？
対立ではなく包含関係で、プロンプトエンジニアリングはコンテキストエンジニアリングの一部と考えるのが実務的です。
システムプロンプトの書き方は、今も重要な設計要素です。ただし、AIエージェントのように何ステップも自律的に動く仕組みでは、指示文が全体の入力に占める割合は小さくなります。ツールの実行結果や中間生成物が、ステップを重ねるごとに積み上がっていくためです。社内で役割を分ける場合は、「プロンプトは業務部門が書き、コンテキストの供給経路は開発・データ部門が設計する」という分担にすると議論がかみ合いやすい、というのが筆者の実感です。
コンテキストを構成する要素は？
コンテキストは、固定的に与える「静的要素」と、処理のたびに変わる「動的要素」の2つに大別できます。
| 区分 | 要素 | 具体例 | 設計上の注意 |
|---|---|---|---|
| 静的 | システムプロンプト | 役割、口調、禁止事項、判断基準 | 抽象的すぎても細かすぎても機能しにくい |
| 静的 | ツール定義 | API・関数の説明、引数の仕様 | 機能が重複するツールはLLMが選び間違えやすい |
| 静的 | 例示（few-shot） | 望ましい入出力の例 | 例外ケースを網羅しようとせず、典型例を厳選する |
| 動的 | 検索結果（RAG） | 社内規程、マニュアル、FAQ | 鮮度・権限・関連度の管理が必要 |
| 動的 | 会話履歴 | 直近のやり取り | 長くなったら要約や切り捨てが必要 |
| 動的 | ツール実行結果 | DBの照会結果、Web検索結果 | 出力が大きい場合は整形・要約してから渡す |
| 動的 | メモリ | ユーザーの嗜好、過去の決定事項 | 何を保存し、いつ呼び出すかのルール化が必要 |
静的なコンテキストはどう設計するか？
静的要素は、業務ルールと判断基準を「LLMが迷わない粒度」で書き、毎回同じ形で渡すのが基本です。
Anthropicは前述の記事で、システムプロンプトについて「適切な高度（right altitude）」で書くことを推奨しています。条件分岐をすべてif文のように書き込むと、想定外のケースに弱くなります。逆に「丁寧に対応すること」のような抽象的な指示だけでは、判断の根拠になりません。業務マニュアルをそのまま貼り付けるのではなく、判断に必要な原則と代表的な例に絞ってから書き直す作業が、実務では最も効果が出やすい部分です。
動的なコンテキストはどう扱うか？
動的要素は「必要なときに、必要な分だけ」取得する設計にして、量が膨らみ続けないようにすることが重要です。
コンテキストウィンドウの上限が大きくなっても、情報が増えるほどLLMが重要な部分を見落としやすくなることが知られています。Chromaの調査レポート「Context Rot」（2025年7月）では、入力が長くなるにつれて複数のモデルで性能が低下する傾向が報告されています。「上限まで入るから全部入れる」のではなく、関連度の高い情報を優先して少量に絞るほうが安定します。
実装の手順と設計のポイントは？
実装は「業務と失敗パターンの定義」から始め、情報源の整備、供給設計、評価の順に進めるのが確実です。
実装はどの順番で進めるか？
いきなりツールを選ばず、対象業務と「何を間違えると困るか」を先に定義するのが最初の一歩です。
- 対象業務とゴールを定義する：誰が、どの判断に、AIの出力を使うのかを決めます。
- 失敗パターンを洗い出す：古い規程の参照、権限外の情報の表示、根拠のない断定など、許容できない誤りを列挙します。
- 情報源を棚卸しする：必要な文書・データの所在、更新頻度、アクセス権限を一覧にします。
- 静的コンテキストを設計する：システムプロンプト、ツール定義、例示を作ります。
- 動的コンテキストの供給経路を設計する：検索方式、履歴の要約ルール、メモリの保存・呼び出し条件を決めます。
- 評価セットを作る：実際の問い合わせから代表的な質問と期待される回答を集め、自動・人手で採点できるようにします。
- 小さく運用して改善する：ログを確認し、どのコンテキストが誤りの原因になったかを特定して直します。
ツールやデータの接続方法としては、Anthropicが2024年11月に公開したMCP（Model Context Protocol）が広く採用されています。OpenAIやMicrosoft、Googleの製品でも対応が進んでおり、社内システムとAIエージェントをつなぐ標準的な選択肢の一つになっています。
設計で押さえるべき4つの型は？
LangChainが整理した「書き出す・選ぶ・圧縮する・分離する」の4つの型で考えると、設計の抜け漏れを防げます。
| 型 | 内容 | 実装例 |
|---|---|---|
| 書き出す（Write） | コンテキストの外に情報を保存する | 作業メモをファイルに残す、長期メモリに保存する |
| 選ぶ（Select） | 必要な情報だけを取り込む | RAGで関連文書を検索する、使うツールを絞り込む |
| 圧縮する（Compress） | 情報量を減らして要点を残す | 長い会話履歴を要約する、ツール出力を整形する |
| 分離する（Isolate） | 処理ごとにコンテキストを分ける | サブエージェントに調査を任せ、結果だけを受け取る |
すべてを最初から実装する必要はありません。多くの社内RAGでは、まず「選ぶ」の精度、つまり検索品質を上げるだけで大きく改善します。AIエージェントで長い作業をさせる場合に、「圧縮する」と「分離する」が効いてきます。
評価と改善はどう回すか？
精度の問題を「モデル」「プロンプト」「取得した情報」のどこで起きたかに切り分けて記録することが改善の近道です。
誤回答が出たときにプロンプトだけを直し続けると、別のケースで品質が下がる「もぐらたたき」に陥りがちです。ログには最終的な回答だけでなく、「そのときLLMに何が渡されていたか」を残しておく必要があります。そうしておけば、検索漏れなのか、古い文書の混入なのか、指示の不備なのかを判断できます。評価セットは最初から数百件を集めなくても構いません。現場の担当者と一緒に、よくある質問と間違えると困る質問を数十件集めるところから始めるのが現実的です。
企業導入でつまずきやすい点は？
つまずきの多くは技術ではなく、社内データの整備不足と、評価・運用体制の不在から生じます。
「全部入れれば賢くなる」という誤解
情報を多く渡すほど精度が上がると考えがちですが、実際には関係の薄い情報がノイズになり誤答を招きます。
PoC（概念実証）の段階では文書数が少ないため、うまく動いて見えることがよくあります。本番データを投入して文書が一気に増えると、検索結果に似た古い版の資料が混ざり、精度が落ちるケースは珍しくありません。対策としては、次のようなものが有効です。
- 文書の版管理
- 廃止済み文書の除外
- メタデータ（部署・有効期限・対象者）の付与
権限とガバナンスの設計漏れ
コンテキストに入った情報は回答に出る可能性があるため、閲覧権限の制御を供給経路に組み込む必要があります。
社内文書をまとめて検索対象にすると、本来その社員が閲覧できない人事情報や契約情報が回答に含まれるリスクがあります。検索の段階で利用者の権限に応じて文書を絞り込む設計にしておくことが前提です。あわせて、「どの情報が渡され、何が出力されたか」を監査ログに残しておくと、問題が起きたときの説明責任を果たしやすくなります。DXの時代に整えたデータ基盤やアクセス管理の仕組みを、生成AI向けにも再利用できるかを最初に確認しておくと、手戻りを減らせます。
担当者が不在で改善が止まる
コンテキストは業務の変化に合わせて劣化するため、継続的に手入れする担当と仕組みを置くことが欠かせません。
規程の改定、商品の追加、組織変更などがあるたびに、渡すべき情報は変わります。リリース後に開発チームが離れると、誰も評価セットを更新せず、精度が少しずつ下がっていくことがあります。筆者の見聞きする範囲では、業務部門側に「コンテキストの持ち主」を置き、情報源の更新と評価の確認を定例業務に組み込んでいる組織ほど、AI活用が定着している印象です。コンテキストエンジニアリングは一度設計して終わる技術ではありません。AXを進める組織の運用能力そのものだと捉えるのがよいでしょう。
参考・出典
- Anthropic「Effective context engineering for AI agents」（2025年9月）
- LangChain「The rise of “context engineering”」（2025年6月）
- Chroma「Context Rot: How Increasing Input Tokens Impacts LLM Performance」（2025年7月）
- Anthropic「Introducing the Model Context Protocol」（2024年11月）
