最終更新:2026年10月17日
コンテキストエンジニアリングとは、AIに「何を言うか」ではなく、AIに「何を見せるか」を設計する考え方です。ここでのコンテキスト(context)は文脈のことで、AIが答えを作るときに参照できる情報のすべて、つまり指示文だけでなく、渡した資料、それまでの会話、使える道具、覚えている記憶まで含めて指します。プロンプトエンジニアリング(AIへの指示文の書き方を工夫する技術)の発展形として、2025年の夏ごろから広く使われるようになった言葉です。結論から言えば、AIの答えの質は指示文の巧さより、AIが答える瞬間に何を見ているかで決まります。この記事では、定義と中身の一覧、プロンプトエンジニアリングとの違い、言葉の由来、なぜ必要なのか、非エンジニアのマーケターが日常のChatGPTやClaudeでどう実践するかまで書いていきます。
コンテキストエンジニアリングとは?意味とコンテキストの中身一覧
コンテキストエンジニアリングは、AIが答えを出す瞬間に参照する情報の集まりを、選び、並べ、保つ仕事です。Anthropic(アンソロピック)は2025年9月の技術記事で、これを「LLMの推論時に、最適なトークン(情報)の集合を選び維持する戦略の総体」と定義しました(Anthropic「Effective context engineering for AI agents」)。
LLM(大規模言語モデル)は、ChatGPTやClaudeの中身にあたる、文章を扱うAIの本体です。トークンは、AIが文章を数えるときの単位で、英語なら単語の一部から一語ほどの長さです。AIが一度に見られる情報量の上限はコンテキストウィンドウと呼ばれ、Anthropicの開発者向けドキュメントはこれを人の「作業記憶(working memory)」にたとえています。指示、やりとりの全文、添付した文書や画像、道具の定義、AI自身の出力まで、すべてがこの窓の中に数えられます(Anthropic開発者ドキュメント)。
その窓の中に何が入っているのか。フィル・シュミット(Phil Schmid)が2025年6月に整理した7つの要素を、マーケターの日常の操作に置き直したのが次の表です(シュミットの解説記事)。
| 要素 | 中身 | 日常のChatGPT・Claudeでの対応物 |
|---|---|---|
| 指示(システムプロンプト) | AIの役割、守ってほしいルール、禁止事項 | プロジェクトの指示欄、アカウント全体に効く指示 |
| 依頼文(ユーザープロンプト) | いま頼みたいこと | 毎回打ち込む文章 |
| 資料(検索・添付された情報) | 商品資料、過去記事、調査データなど、答えの材料 | ファイルの添付、プロジェクトへのアップロード |
| 履歴(状態) | その会話でここまでにやりとりした内容 | 同じチャットを続けること |
| 記憶(長期メモリ) | 会話が変わっても覚えている情報 | メモリ機能 |
| 道具(ツール) | 検索、計算、外部サービスへの接続など、AIが呼び出せる機能 | ウェブ検索のオン・オフ、つないだ外部アプリ |
| 出力の形式 | 表で返す、文字数、見出しの有無など | 「表にして」「300字で」の一言 |
7つのうち、「依頼文」はたった1行です。残りの6つは、依頼文を打つ前に決まっているか、打ったあとに積み重なっていくもの。AIの答えを左右しているのは、ほとんどの場合この6つのほうです。
プロンプトエンジニアリングとの違い──何を言うかと、何を見せるか
プロンプトエンジニアリングは「AIへの指示文をどう書くか」の技術で、コンテキストエンジニアリングは「AIが見る情報の全体をどう組むか」の設計です。前者は後者の一部にあたり、どちらかが不要になるという関係ではありません。
| 観点 | プロンプトエンジニアリング | コンテキストエンジニアリング |
|---|---|---|
| 問い | 何と言うか | 何を見せるか |
| 対象 | 1本の指示文 | 指示・資料・履歴・道具・記憶・出力形式のすべて |
| タイミング | 書いたときに決まる(静的) | 答えるたびに組み立て直す(動的) |
| うまくいかないときの直し方 | 言い回しを変える、例を足す | 渡す資料を替える、要らない情報を外す、会話を切り替える |
定義した人たちの言い分はそろっています。Anthropicは、プロンプトエンジニアリングを「LLMへの指示を書いて整理する手法」、コンテキストエンジニアリングを「その自然な発展」と位置づけました。LangChain(ラングチェーン)のハリソン・チェイス(Harrison Chase)は、プロンプトエンジニアリングはコンテキストエンジニアリングの部分集合で、違いは「動的な入力データを扱うかどうか」だと書いています(LangChain「The rise of context engineering」)。誰も「プロンプトの書き方は要らなくなった」とは言っていません。言い方の工夫は残り、その外側に見せるものを選ぶ仕事が足された、という関係です。
近くにある言葉との関係も一言で。RAG(検索拡張生成)は、AIが答える前に外部の文書を検索して渡す手法で、「資料」の要素を自動で用意する方法の一つです(原典は2020年のパトリック・ルイス(Patrick Lewis)らの論文)。ファインチューニングは、自前の例でモデルそのものを追加学習させることで、答えるたびに渡す情報を設計するコンテキストエンジニアリングとは層が違います(OpenAIのガイド)。AIエージェントやMCPのような言葉は自律動作や接続の話で、何を見せるかの設計は、その上に乗る別の層です。
コンテキストエンジニアリングの由来──誰が言い始めたのか
この言葉を広めたのは、2025年6月のShopify(ショッピファイ)CEOトビ・リュトケ(Tobi Lütke)の投稿と、その6日後のAI研究者アンドレイ・カーパシー(Andrej Karpathy)の投稿です。ただ、それより前から使っていた開発者がいるので、「誰が最初に作った言葉か」は一人に絞れません。
| 時期 | 誰が | 何を言ったか |
|---|---|---|
| 2025年4月末(文書の存在を確認) | デックス・ホーシー(Dex Horthy)「12-factor agents」 | AIエージェント設計の原則集。第3原則の中に「すべてはコンテキストエンジニアリングだ」の一文がある(GitHubの原文) |
| 2025年6月12日 | ウォルデン・ヤン(Walden Yan)、Cognition | ブログ記事で、AIエージェントを作るエンジニアの「事実上いちばん大事な仕事」と書く(Cognitionのブログ) |
| 2025年6月19日(日本時間) | トビ・リュトケ、Shopify | 「プロンプトエンジニアリングより、この言葉のほうが好きだ」。タスクがLLMにもっともらしく解ける状態になるよう、必要な文脈をすべて与える技術、と定義(リュトケの投稿) |
| 2025年6月23日 | ハリソン・チェイス、LangChain | 「適切な情報と道具を、適切な形式で渡す動的なシステムを作ること」と定義(LangChainのブログ) |
| 2025年6月25日 | アンドレイ・カーパシー | リュトケに「+1」と賛同。次の一手に必要な情報だけでコンテキストウィンドウを満たす「繊細な技芸と科学」が仕事だと書く。詰めすぎや無関係な情報はコストを上げ性能を下げる、とも(カーパシーの投稿) |
「◯◯が提唱した」と一人の名前で語られることもありますが、原文を追うと、カーパシーの投稿はリュトケへの賛同の形をとっていて、リュトケの前にも開発者の文書に同じ言葉が出てきます。この記事では「2025年6月に、リュトケとカーパシーの投稿で広まった」と書くにとどめます。
なぜ必要なのか──窓は大きくなっても、詰め込むほど精度は落ちる
コンテキストエンジニアリングが必要なのは、AIが一度に見られる量に上限があるからだけではありません。上限の中でも、情報が増えるほど答えの精度が落ちるという性質があり、「全部渡せばよい」が成り立たないからです。
窓そのものは、大きくなりました。2026年10月時点で、Anthropic(Claude)の主なモデルは100万トークン(英語で約55万語に相当)、OpenAIのGPT-6系は105万トークン、GoogleのGemini 4 Argonは100万トークンのコンテキストウィンドウを持ちます(Anthropicのモデル一覧、OpenAIのモデル一覧、Googleのモデル一覧)。
それでも、Anthropicの公式ドキュメントには「コンテキストが多いほど自動的に良くなるわけではない」と明記され、トークンが増えると精度と想起(必要な情報を思い出す力)が落ちる現象を、コンテキスト・ロット(context rot)と呼んでいます。
裏づけもあります。2023年の論文「Lost in the Middle」は、答えに必要な情報が入力の先頭か末尾にあるときに精度が最も高く、中央にあると大きく落ちるU字型の結果を示しました(論文(arXiv))。Chroma(クロマ)の2025年7月の研究も、18のLLMで入力が長くなるほど信頼性が下がると報告しています(Chromaの研究ページ)。
だから開発者の間では、「何を入れ、何を外し、いつ要約するか」の手法が整理されてきました。Anthropicの技術記事が挙げる手法を、個人の使い方に置き直すと次のようになります。
| 手法 | 原綴り | 何をするか | 個人の使い方に置き直すと |
|---|---|---|---|
| コンパクション | compaction | 窓がいっぱいに近づいたら、それまでの内容を要約して新しい窓で続ける。いちばん軽いのは、古い道具の実行結果を消すこと | 長くなった会話を要約させ、新しいチャットに貼って続ける |
| 構造化されたメモ取り | structured note-taking | 窓の外のファイルにメモを書き、あとで読み戻す | 決まったルールや進み具合を、指示欄や自分のメモに書いておく |
| サブエージェント構成 | sub-agent architectures | 専門の担当AIがきれいな窓で作業し、要約だけを返す | 調査用と執筆用のチャットを分け、結論だけを持ち込む |
| ジャストインタイム取得 | just-in-time retrieval | 資料の場所だけを持ち、必要になったときに読み込む | 全部添付せず、その場で使う資料だけを渡す |
LangChainは同じ手法群を、書く・選ぶ・圧縮する・隔離するの4つに分け、失敗の型も4つに整理しています(LangChainの解説記事(Context Engineering for Agents))。間違いが混ざる「汚染」、量に引きずられる「散漫」、不要な情報に迷う「混乱」、矛盾する情報がぶつかる「衝突」。長い会話で急にAIの答えがおかしくなったと感じたら、だいたいこのどれかが起きています。
実務でどう使うか──非エンジニアの「プロジェクト・指示・資料添付」がそれにあたる
マーケターにとってのコンテキストエンジニアリングは、プログラムを書く話ではありません。ChatGPTやClaudeのプロジェクト機能、指示の設定、資料の添付、メモリの使い分けで、AIが見るものを自分で整えることです。各社がこれらの機能をこの名前で呼んでいるわけではありませんが、考え方は同じで、その個人版だと言えます。
| 機能(2026年10月時点) | Claude | ChatGPT | 整えているコンテキスト |
|---|---|---|---|
| プロジェクト | チャット履歴とナレッジ(アップロードした資料)を持つ独立した作業スペース。専用の指示を設定できる。有料プランでは資料が窓の上限に近づくとRAGモードに切り替わり、容量を最大10倍に広げる。無料プランでも最大5件(Claudeヘルプ) | ファイル・指示・コンテキストをまとめる専用スペース。一部のプランでは、プロジェクト限定のメモリも選べる(OpenAI Academy) | 指示+資料+履歴 |
| 指示 | アカウント全体に効く「Claudeの指示」と、そのプロジェクトのチャットだけに効く「プロジェクト指示」の二段(Claudeヘルプ) | プロジェクト内の指示(OpenAI Academyの説明による) | 指示 |
| メモリ | プロジェクトごとに独立したメモリを持つ(Claudeヘルプ) | 一部のプランでプロジェクト限定のメモリ(同) | 記憶 |
使い方は三つに絞れます。一つ目は、毎回打っていた前提を指示欄に移すこと。文体、禁止事項、読者像のように毎回同じものは、依頼文ではなく指示の層に置くと、会話が長くなっても抜けません。二つ目は、資料を「全部」ではなく「その判断に要るものだけ」渡すこと。無関係な情報は精度を下げます。三つ目は、話題が変わったら会話を切り替えること。前の話題の履歴が次の答えに混ざる「汚染」を防げます。
ぼく自身の観察でも、同じAIでも指示の解像度で出てくる案は変わります。以前、化粧品のコピーをAIに頼む場面を記事に書いたとき、年代と商品のカテゴリーだけを渡した場合と、誰に(暮らしの状況まで)、何を(押し出す価値)、何を避けるか(競合の調子や使わない表現)を渡した場合では、返ってくる案が別物でした。この差を生んだのはAIの性能ではなく、渡した文脈です。だからいまは、書かせる前に文体ガイドと過去記事を先に読ませる運用にしています。このあたりの経緯はAIを使いこなすマーケターが生き残る理由に書きました。
「誰に・何を・何を避けるか」という骨格は、コンセプトの型(誰に・何を・どう)と同じで、AIに渡す文脈の中心も結局はここです。文体や禁止事項を文書にしておくのはトンマナシートの作り方そのものですし、答えを出させるより反論させる使い方はAIを思考の壁打ち相手にする方法に書きました。新しい名前の中身は、マーケターがすでに持っている道具で、ほとんど間に合います。
コンテキストエンジニアリングに関するよくある質問
コンテキストエンジニアリングとは簡単に言うと何ですか?
AIに「何を言うか」ではなく、AIに「何を見せるか」を設計することです。指示文だけでなく、渡す資料、それまでの会話、使える道具、記憶まで含めて、AIが答える瞬間に参照する情報の集まりを選び、整え、保つ仕事を指します。
プロンプトエンジニアリングとの違いは何ですか?
プロンプトエンジニアリングは1本の指示文をどう書くかの技術で、コンテキストエンジニアリングはAIが見る情報の全体をどう組むかの設計です。前者は後者の一部にあたります。Anthropicは「自然な発展」、LangChainは「部分集合」と表現していて、どちらも「プロンプトの書き方が不要になる」とは言っていません。
コンテキストエンジニアリングはエンジニアでなくてもできますか?
できます。ChatGPTやClaudeのプロジェクト機能に資料を入れ、文体や禁止事項を指示欄に書き、話題が変わったら会話を切り替える。この操作は、AIが見るものを自分で整えることそのもので、考え方は開発者の手法と同じです。
資料を全部渡せば、AIの答えは良くなりますか?
なりません。Anthropicの公式ドキュメントは「コンテキストが多いほど自動的に良くなるわけではない」と明記し、情報が増えると精度と想起が落ちる現象をコンテキスト・ロットと呼んでいます。その判断に要る資料だけを選んで渡すほうが、答えは良くなります。
おわりに──コンテキストエンジニアリングは、AIを賢くする技術ではなく、自分の目を棚卸しする仕事
AIに何を見せるかを選ぶには、自分がふだん何を見て判断しているのかを、知っていなければなりません。どの資料を信じ、何を避け、どの言い回しを好むのか。この言葉が開発者の間で生まれたのは事実ですが、その中身は、マーケターが発注書や企画書で「相手に何を見せるか」を決めてきた仕事と同じです。
AIに文体ガイドや過去記事を先に読ませる運用は、AIのためというより、自分が何を基準に書いているかを、いちど文書にする作業です。見せるものを選ぶ手間は、そのまま自分の判断材料の棚卸しになります。
AIの答えが浅いのではない。AIに見せた世界が浅いだけ。
次にAIの答えに物足りなさを感じたら、言い回しを直す前に、何を見せていなかったかを一つ数えてほしいと思います。その一つが、あなたの判断の材料です。