最近、X やビジネスメディアで「プロンプトエンジニアリングはもう古い、これからはコンテキストエンジニアリングだ」という言葉を見かけるようになりました。
「プロンプトの書き方を覚えたばかりなのに、もう次が来たの？」と感じている方も多いかもしれません。
答えを先に言うと、プロンプトエンジニアリングの後継ではなく、それを含む上位概念 です。本記事では、両者の違いと、個人ユーザーが今日から試せる実践法までをまとめます。
前提として、本記事は プロンプトエンジニアリング基本の型5選 の内容を踏まえています。「プロンプトの型」がまだの方は先に読むと、本記事の位置付けがクリアになります。
結論 ― コンテキストエンジニアリングとは何か
コンテキストエンジニアリングとは、AI に渡す「文脈すべて」を設計する技術 です。具体的には、AI に対して 何を・どの順番で・どれだけ渡すか を考えます。
ここでいう「文脈」には、次のものが含まれます。
- 指示文（プロンプト本体）
- 参考資料・社内ドキュメント
- 過去の会話履歴
- ツール（検索・計算など）の実行結果
- ユーザーの好み・属性
つまり、これまで「プロンプト」と一括りにされてきたものを 複数の構成要素に分解し、それぞれを意識的に組み立てる のがコンテキストエンジニアリングです。
結局なにがすごいのか
3行で整理するとこうなります。
- プロンプトを磨くだけでは届かない 精度・一貫性 に到達できる
- AI エージェント 時代の 前提技術 になる
- 個人ユーザーでも カスタム指示・プロジェクト機能・メモリ で実践できる
ただし「コンテキストを渡せば全部解決」というほど単純な話ではありません。詳しくは後半の「コンテキスト設計でやってはいけない3つのこと」で触れます。
プロンプトエンジニアリングとの違い ― 一発勝負か、文脈の組み立てか
早見表
| 観点 | プロンプトエンジニアリング | コンテキストエンジニアリング |
|---|---|---|
| 対象 | 1本の指示文 | 渡す情報全体 |
| 単位 | 文字列・テンプレート | 指示・資料・記憶・ツール出力など複数要素 |
| 視点 | 戦術（その場の指示の書き方） | 戦略（情報の組み立て方） |
| 更新頻度 | 都度書き換える | 動的に組み立て直す |
| 必要なスキル | 言い回しの工夫 | 情報の取捨選択と順序設計 |
プロンプトエンジニアリングが「今この瞬間の指示文を磨く」のに対し、コンテキストエンジニアリングは「AI が判断する材料一式を組み立てる」と整理できます。
たとえ話で理解する：新人スタッフに仕事を頼むとき
社内に新人スタッフが入ってきた場面を想像してください。
- プロンプトエンジニアリング＝口頭で出す指示を磨くこと。「丁寧に資料を3部コピーして」と具体的に伝える
- コンテキストエンジニアリング＝渡す資料一式・社内ルール・過去のやりとりまで含めて環境を整えること。「これが社内ガイドライン、これが過去のメール、これが今週のスケジュール」と材料を揃える
口頭の指示がいくら上手くても、新人が 背景情報をまったく持っていなければ 良い仕事はできません。コンテキスト設計は、その背景情報を AI が活かせる形で揃える 作業に近いものです。
否定ではなく包含関係
「プロンプトエンジニアリングはもう古い」という言い方を見かけますが、これは正確ではありません。
Google DeepMind の Philipp Schmid 氏など、複数の実務家もこの考え方を発信しています。コンテキストエンジニアリングは「プロンプトを含むより広いエンジニアリング領域」として位置付けるのが一般的です（参考：Ledge.ai 記事）。
つまり、プロンプトの書き方を学んだ経験はそのまま活きます。プロンプトという1要素を磨いた上で、それ以外の文脈も意識的に組み立てる ― それがコンテキストエンジニアリングです。
なぜ今「コンテキスト」が話題になっているのか
プロンプトを磨くだけでは限界が来た
プロンプトエンジニアリングが広まり、多くの人が「役割を与える」「出力形式を指定する」などの型を使えるようになりました。
しかし複雑なタスクになると、プロンプト1本でできることには限界がある とわかってきました。社内資料を踏まえた提案、長期プロジェクトの引き継ぎ、複数ツールを連携した作業などが典型例です。
ここで必要になるのが、プロンプトに加えて 資料・過去の履歴・外部データ までを含めた文脈設計の発想です。
コンテキストウィンドウが拡大した
LLM（Large Language Model / 大規模言語モデル） が一度に扱える文字数を「コンテキストウィンドウ（context window / 文脈長）」と呼びます。
近年、このウィンドウは急速に拡大しています。たとえば Anthropic は Claude シリーズの一部モデルで 100万トークン（書籍1〜2冊分相当）までのコンテキストをベータ提供しています（Anthropic 公式ブログ）。
ウィンドウが広がった結果、「もっと多くの情報を渡せる」状態になりました。一方で、多く渡せば良いとは限らない ことも明らかになってきました。何を・どの順番で・どれだけ 渡すかが、出力品質を左右します。
AI エージェント時代の前提
AI エージェント は、自律的にツールを呼んだり、複数ステップのタスクを進めたりします。
このとき、エージェントは毎ステップごとに 「今どの情報を見るべきか」を判断 する必要があります。これはまさにコンテキストの動的な組み立てそのものです。
つまり、コンテキストエンジニアリングはエージェント開発の 前提技術 として、開発者の必修科目になりつつあります。
コンテキストを構成する5つの要素
コンテキストエンジニアリングを構成する要素は、大きく5つに整理できます。
mindmap
root((コンテキスト))
指示
ロール
タスク
出力形式
知識
RAG
参考資料
記憶
過去の会話
ユーザー情報
ツール出力
検索結果
計算結果
状態
現在のステップ
完了済みタスク
1. 指示（Instructions）
「何をしてほしいか」を伝える、いわばプロンプト本体です。プロンプトエンジニアリングの5つの型（役割・前提・形式・例示・段階思考）はすべてこの要素に含まれます。
2. 知識（Knowledge / RAG）
AI が事前に学習していない情報を、その場で外部から渡す 部分です。社内マニュアル、最新のニュース、商品データベースなどが該当します。
技術的には RAG（検索拡張生成） と呼ばれる仕組みでよく実装されます。ただし個人ユーザーレベルでは「資料を貼り付ける」「URL を共有する」だけでも同じ役割を果たします。
3. 記憶（Memory）
過去の会話履歴や、ユーザー固有の情報 を AI に持たせる部分です。ChatGPT・Claude ともにメモリ機能を搭載しており、「自分の職業」「文体の好み」などを覚えさせると、毎回ゼロから説明し直す手間が省けます。
記憶には「短期記憶」（直近の会話）と「長期記憶」（プロファイル情報）の2層があります。
4. ツール出力（Tool Outputs）
AI が外部ツール（検索エンジン、電卓、コード実行環境など）を呼び出した 結果をコンテキストに戻す 部分です。
たとえば「最新の為替レートを調べて、それをもとに価格を提案する」というタスクでは、検索ツールの結果を文脈に組み込む必要があります。これは AI エージェント の仕組みと密接に関わります。
5. 状態（State）
マルチステップのタスクで、今どの段階にあるか・何が完了済みか を保持する部分です。
「資料作成→上司レビュー→修正→提出」のような流れの中で、各ステップの結果を持ち回すための情報が状態にあたります。
個人ユーザーが今日からできるコンテキスト設計
「コンテキストエンジニアリングは開発者の話」と思われがちですが、ChatGPT や Claude を使う個人ユーザーにも そのまま応用できる 機能があります。代表的な3つを紹介します。
ChatGPT の「カスタム指示」で常時の前提を渡す
ChatGPT には、すべての会話に共通して適用される カスタム指示 という設定欄があります。
ここに、次のような情報を入れておくと毎回の会話が楽になります。
- 自分の職業・役割（例：「Web メディアの編集者です」）
- 望ましい文体（例：「ですます調で、長くても1文60字程度」）
- 普段扱うテーマ（例：「主に AI ツールの解説記事を書きます」）
これは記憶（Memory）の領域を、明示的な指示として渡すコンテキスト設計です。
Claude の「プロジェクト」機能で資料一式を保持する
Claude には プロジェクト（Projects） という機能があり、特定のテーマに関連する資料を一箇所にまとめておけます。
たとえば「ブログ運営」というプロジェクトを作り、以下を入れておくとします。
- スタイルガイド（PDF / Markdown）
- 過去記事のリスト
- ターゲット読者のペルソナ
すると、その後の会話ではこれらが 常にコンテキストに含まれた状態 で進行します。これは「知識」の要素を恒常化させる使い方です。
Google の Gemini にも「Gems」という類似機能があり、特定用途専用のアシスタントを作って文脈を恒常化できます。
メモリ機能で過去の会話を引き継ぐ
ChatGPT・Claude ともに、ユーザーの好みや過去の発言を 自動で記憶する機能 を提供しています（設定でオン/オフ切り替え可）。
「以前話した○○の続きから」のような指示でも、AI が前提を踏まえて回答するようになります。記憶の領域を、自動で動的に組み立ててもらう仕組みです。
Before / After 例 ― コンテキスト設計の有無で出力はどう変わるか
実際の差を見てみます。
Before（コンテキストなし）
取引先への謝罪メールを書いてください。
→ 一般的でやや堅すぎる文面が返ってきがちです。
After（コンテキスト設計あり）
取引先への謝罪メールを書いてください。
【背景（記憶）】
私は法人営業3年目、相手先は10年来の取引先で関係を大切にしたい。
【参考資料（知識）】
過去に送った謝罪メール3通（添付）
【今回の状況（状態）】
納期遅延 2日、原因は社内手配ミス。今後の対策も併せて伝えたい。
【出力形式（指示）】
件名・本文・想定される追加質問への回答メモ、の3パートで。
→ 出力例（抜粋）：
件名：納期遅延のお詫びと再発防止のご報告
◯◯様
平素より格別のお引き立てを賜り、誠にありがとうございます。
…（10年来の関係性に配慮した語調で続く）
【追加質問への回答メモ】
Q. 同様の遅延は今後も起きうるか？
A. 社内手配フローを△△に変更し、ダブルチェックを徹底します。
関係性に合った語調と、社内事情まで踏まえた具体的な対策案が一度に揃いやすくなります。
一発のプロンプトでここまで揃えるのは難しいでしょう。ですが カスタム指示・プロジェクト・添付資料 を組み合わせれば、毎回ゼロから書かずに近い品質を再現できます。
コンテキスト設計でやってはいけない3つのこと
コンテキストは「多ければ多いほど良い」というものではありません。注意点を3つ挙げます。
1. 情報を詰め込みすぎる（コンテキスト崩壊）
ウィンドウが拡大したからといって、関連の薄い情報まで全部渡す と、かえって精度が落ちることがあります。
これは「迷子問題（lost in the middle）」と呼ばれる現象で、重要な情報が大量のノイズに埋もれ、参照されなくなることが知られています。「コンテキスト崩壊（context collapse）」という呼び方も使われます。
「今回のタスクに本当に必要か」を都度問い直し、渡さない判断 も大切です。
2. 順序を考えない
LLM は受け取った情報を均等には扱わない傾向があります。先頭と末尾の情報を重視しやすい ことが知られています（参考：Liu et al. "Lost in the Middle" 2023）。
重要な指示・直近の質問は、コンテキストの 先頭または末尾 に置くと拾われやすくなります。中央に埋もれさせると、せっかく渡しても見落とされることがあります。
3. 古い情報を残し続ける
長いプロジェクトで何度も会話を重ねていくと、最初の前提がもう変わっている のに、メモリやプロジェクト資料がそのまま残ったままになっていることがあります。
古い前提が文脈に残ると、AI はそれを「今の事実」として扱ってしまいます。定期的に整理する か、不要な情報は明示的に削除しておきましょう。
まとめ ― プロンプトの次に身につけたい「文脈設計」の考え方
最後に要点を整理します。
- コンテキストエンジニアリング＝AI に渡す 情報全体 を設計する技術
- プロンプトエンジニアリングを 否定するものではなく、含む 考え方
- 構成要素は5つ：指示・知識・記憶・ツール出力・状態
- 個人ユーザーは ChatGPT のカスタム指示・Claude のプロジェクト・メモリ機能 から始められる
- 落とし穴は 詰め込みすぎ・順序軽視・古い情報の放置
「プロンプトの書き方を覚えた次は何を学ぶべき？」と思ったら、まずはコンテキスト設計の考え方に踏み込んでみてください。明日からの会話の質が、ひと段階上がるはずです。
次に読む
- プロンプトエンジニアリング基本の型5選 ― 本記事の前段。「指示」を磨く5つの型を Before / After で解説
- AI エージェントとは？仕組みと使い方をやさしく解説 ― コンテキスト設計が前提技術となるエージェントの全体像
- RAG（検索拡張生成）とは？ ― コンテキストの「知識」要素を支える代表的な仕組み
- MCP（Model Context Protocol）とは？ ― 「ツール出力／知識」をAIに渡す接続方法を標準化する仕組み
- ChatGPT・Claude・Gemini の違い完全比較 ― 各サービスのコンテキスト保持機能（カスタム指示／プロジェクト／Gems）の違いを比較