コンテキストエンジニアリングとは？4つの失敗パターン

コンテキストエンジニアリングとは何か

コンテキストエンジニアリング（context engineering）とは、AIモデルがタスクをうまくこなすために必要なものすべてを、モデルが動き出す前に決め、組み立て、届ける実践です。対象になるのは、システムプロンプト、添付するドキュメント、モデルがあなたについて記憶していること、呼び出せるツール、そして会話にすでに入っている内容です。プロンプトエンジニアリングが調整するのは一つの文です。コンテキストエンジニアリングが調整するのは入力スタック全体です。

出回っている定義のうち最も引き締まっているのはAnthropicのものです。「LLMの推論中に、最適なトークン（情報）の集合をキュレーションし維持するための戦略群」。彼らが示す指針は暗記する価値があります。正しくできているかどうかの判定基準を兼ねているからです。すなわち "the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome"（望ましい結果が得られる可能性を最大化する、可能な限り小さな高シグナルのトークン集合）を見つけること。（Anthropic, 2025）

新しいコンサルタントにブリーフィングする場面を思い浮かべてください。悪いブリーフは一行のメールです。良いブリーフには、会社の背景、関連する経緯、必要になるファイル、関係者は誰か、成功とはどういう状態か、そしてスコープ外は何かが入っています。優秀なコンサルタントを雇っても、ブリーフが悪ければ成果物は平凡になります。AIでも同じです。

定義に入っていないものにも注目してください。それは「巧妙さ」です。魔法の言い回しも、良いモデルを引き出す秘密の呪文もありません。この仕事は呪文よりも編集に近いものです。会話が始まる前に、何をその部屋へ入れるかを決めること。そして同じくらい重要なのは、何を入れないかを決めることです。

---

名前を与えたツイート

2025年6月19日、ShopifyのCEOであるTobi Lütkeが、X上で「プロンプトエンジニアリング」より「コンテキストエンジニアリング」という言葉のほうが好みだと投稿しました。彼はそれを "the art of providing all the context for the task to be plausibly solvable by the LLM"（LLMがそのタスクを無理なく解けるように、必要なコンテキストをすべて用意する技芸）と説明しています。その6日後、AI界で最も信頼される論者の一人であるAndrej Karpathyがこの言葉を広く後押ししました。彼の定義はより鋭いものです。"context engineering is the delicate art and science of filling the context window with just the right information for the next step"（コンテキストエンジニアリングとは、次の一手のためにちょうど適切な情報でコンテキストウィンドウを満たす、繊細な技芸であり科学である）。（Karpathy, 2025）

言葉そのものは新しくありませんでした。自律コーディングエージェントDevinを開発するCognitionのWalden Yanは、その1週間前の6月12日に「Don't Build Multi-Agents」を公開し、コンテキストエンジニアリングを "effectively the #1 job of engineers building AI agents"（AIエージェントを作るエンジニアにとって事実上の最重要業務）と呼んでいます。ただし、ラベルが主流に乗ったのはLütkeとKarpathyの投稿でした。その翌月、Gartnerは「Lead the Shift to Context Engineering as Prompt Engineering Fades」と題したレポートを公開し、要約行にこう書きます。「Context engineering is in, and prompt engineering is out（コンテキストエンジニアリングが主役で、プロンプトエンジニアリングは退場）」。あわせて示された予測はこうです。2028年までに、AIアプリケーションを構築するために使われるソフトウェアツールの80パーセントにコンテキストエンジニアリング機能が組み込まれ、エージェント型AIの精度を少なくとも30パーセント改善する。（Gartner, 2025）

起きたのはリブランドではありません。訂正です。AIコミュニティは、「プロンプトエンジニアリング」と呼ばれてきたスキルが最初からもっと大きな何かの一部でしかなく、しかもその部分はもう面白い場所ではなくなった、と静かに認めたのです。プロンプトは部品の一つです。コンテキストは部屋全体です。

これが重要なのは、ナレッジワーカーが2年間、違うものを学んできたからです。プロンプトのテンプレートを暗記し、「究極のプロンプト」のスレッドを集め、プロンプトを呪文のように扱ってきました。その努力は無駄ではありませんが、もう十分ではありません。問うべきは、どう言い回すかではありません。問うべきは、リクエストの隣に何を置くかです。

---

プロンプトエンジニアリングは本当に死んだのか

短く答えるなら、職種としては死に、技術としては死んでいません。

これを、古いものはすべて間違いだという世代交代の物語として扱いたくなります。それは怠けた見立てです。思考の連鎖（chain-of-thought）、少数例（few-shot）の提示、役割の指定、出力フォーマットの明示は、いまも効果があり、うまく設計されたコンテキストの内側にちゃんと登場します。

変わったのは天井です。2023年当時、うまく言い回されたプロンプトは応答の品質を2倍にできました。当時のモデルは曖昧さにすぐ混乱したからです。適切な文の組み立て方ひとつで、GPT-3.5をおぼつかないインターンから筋の通ったアナリストへ変えられました。その差は本物で、プロンプトエンジニアリングはそこを突いていました。

2026年のフロンティアモデルに手取り足取りは要りません。Claude Opus 5、GPT-5.6、Gemini 3.1 Proは、曖昧な依頼でもそれなりにうまく扱います。言い回しの限界リターンは下がりました。一方で、関連する一次資料、範囲を絞った記憶、選び抜かれた例を与えることの限界リターンは大きく上がりました。レバレッジの位置が動いたのです。

比較を並べてみます。

最後の行に注目してください。プロンプトエンジニアリングは、間違っていたから終わったのではありません。ボトルネックが別の場所へ移ったから終わったのです。

---

コンテキストエンジニアリングも死んだのか

短く答えるなら、ラベルは薄れつつあり、実践は薄れていません。

反発は一つのジャンルを成すほど確かなものです。Joe Reisは2026年3月に「Gartner Declares 2026 The Year of Context™」を公開し、コンテキストエンジニアを "data engineer, ontologist, librarian, corporate anthropologist, and therapist"（データエンジニア、オントロジスト、司書、企業人類学者、そしてセラピスト）の混合物で、実際の仕事は "updating a YAML file"（YAMLファイルの更新）だと茶化しました。冗談を取り除くと、立っている反論は3つ残り、そのうち2つには本当のことが含まれています。

「モデルが吸収してしまう」。エージェントのハーネスが圧縮、検索、記憶を自動で処理するようになったのだから、人間がコンテキストを考える必要はもうない、という主張です。ここには確かに中身があります。自動圧縮とジャストインタイム検索は、手作業の一カテゴリを本当に消しました。しかし自動化は作業を消したのではなく、移しただけです。メモリファイルに何を書くか、検索器がどのソースに触れてよいか、エージェントに何を無視させるかは、いまも誰かが決めています。配管は自動化されました。判断はされていません。

「もともと良い入力を指す流行語にすぎなかった」。半分は当たっています。入力を吟味することは新しい発想ではありませんし、コンテキスト関連製品を売るベンダーによって、この言葉はほとんど何でも指すところまで引き伸ばされました。とはいえ、名前が付くと人はそれを真面目に扱うようになります。2023年にAIへの入力を体系的に点検していた人はいませんでした。いまでは多くのチームがやっていて、その理由は、名前が実践に輪郭を与えたからです。

「コンテキストロットがある以上、エンジニアリングでは抜け出せない」。これは逆です。入力が増えるほどモデルが劣化するという事実こそ、意図的なコンテキスト設計を支持する論拠であって、否定する論拠ではありません。コンテキストは多いほど良いのなら、キュレーションは無意味で、全部放り込めば済むはずです。

2026年半ば時点での率直な見立てはこうです。この言葉は誇大宣伝のピークを過ぎ、独立した職種としての「コンテキストエンジニア」はまだ標準ではなく萌芽段階にあります。Adobeはその名称そのままの職を募集していますが、多くの企業では既存のAI、データ、プラットフォームエンジニアリングの職務の内側にこの仕事が収まっています。その下にある実践は、かつてないほど定着しています。ラベルのほうは「レスポンシブデザイン」がたどった道と同じように、まっとうな仕事の定義に吸収されて背景に溶けていくでしょう。

---

コンテキストの6つのレイヤー

コンテキストエンジニアリングを意識的に行うには、自分が何を設計しているのかを知る必要があります。現代のAIとのやり取りはすべて、意識するかどうかにかかわらず、6つのレイヤーから材料を引いています。スキルとは、どれを調整すべきかを見極めることです。

うまく設計されたコンテキストは、6つすべてを意図的に使います。設計の甘いコンテキストは、すべてを1つのレイヤー（たいていは添付ファイル、しばしば会話履歴）に流し込み、あとはモデルが仕分けてくれることを期待します。

多くのナレッジワーカーが犯す間違いは、AIをチャットのインターフェースとして扱うことです。実際にはコンテキストの組み立て装置なのに。答えを決めるものの大半は、あなたが入力を始めた時点ですでに終わっています。

パーソナルな情報アーキテクチャがAIの有用性をどう左右するかという関連する切り口は、パーソナルコンテキスト管理をご覧ください。

---

コンテキストウィンドウの拡大が、事態を良くせず悪くした理由

2023年には10万トークンのコンテキストウィンドウは珍しいものでした。2026年には100万トークンが当たり前の基準線です。GPT-5.6でおよそ1,050,000、Gemini 3.6 Flashで1,048,576、Claude Opus 5で1,000,000。Llama 4 Scoutは1,000万をうたっています。戦争と平和の全文を、一つのプロンプトに何度も入れられる計算です。だとすればコンテキストエンジニアリングは楽になっていくはずだ、と考えたくなります。場所が増えれば選別は減る、そうでしょうか。

違います。難しくなりました。

ここでの基礎文献はLiu et al. (2024)「Lost in the Middle: How Language Models Use Long Contexts」で、TACLに掲載されました。研究者たちは、長いコンテキストのどこに置かれたかによって、モデルが特定の情報を見つけて使えるかどうかを検証しました。結果は居心地の悪いものでした。性能はU字を描きます。モデルはコンテキストのいちばん最初と、いちばん最後の情報に最も注意を払います。中間の情報は体系的に軽く扱われ、ときには完全に無視されます。（Liu et al., 2024）

50ページの文書の真ん中に重要な指示を置くと、モデルはそれを見なかったかのように振る舞うことがあります。これはプロンプトの工夫で回避できる種類の不具合ではありません。

そして2025年7月、ChromaがKelly Hong、Anton Troynikov、Jeff Huberによる「Context Rot: How Increasing Input Tokens Impacts LLM Performance」を公開します。GPT-4.1、Claude 4、Gemini 2.5、Qwen3を含む18のフロンティアモデルを検証したものです。結果はどのモデルでも一貫していました。入力が増えるにつれて性能が劣化し、しかもコンテキストウィンドウが満杯になるはるか手前で起きるのです。モデルはコンテキストを均等には使いません。精度はおよそ10,000トークンから100,000トークンの間で数十パーセントポイント落ちました。100万トークンのモデルでいえば、ウィンドウの最初の10分の1です。

決定的なのは、この閾値がウィンドウに対する割合ではなく、絶対的なトークン数に連動している点です。DatabricksはLlama 3.1 405Bで正答率がおよそ32,000トークン付近から落ち始め、小さいモデルではもっと早いと計測しました。大きなウィンドウを買っても、この数字は動きません。100万トークンのウィンドウは、使える100万トークンを買うことではなく、問題を悪化させる余地を余計に買うことです。MetaはLlama 4 Scoutの1,000万トークン全域でほぼ完璧な干し草の山の中の針（needle-in-a-haystack）検索性能を公表していますが、埋め込まれた事実を1つ見つけることと、コーパス全体にわたって推論することは別物であり、その長さで推論の質が保たれることを示した公開ベンチマークはありません。

Anthropicは、対処法が自ずと見える形で原因を説明しています。コンテキストは "a finite resource with diminishing marginal returns"（限界収益が逓減する有限の資源）であり、モデルは "attention budget"（注意の予算）のうえで動いていて、"every new token introduced depletes this budget by some amount"（新しいトークンが1つ入るたびに、その予算はいくらか目減りする）。アーキテクチャがその理由を説明します。トランスフォーマーはn個のトークンに対してn²の対関係を計算しなければならないため、入力が増えるほど注意は薄まっていきます。（Anthropic, 2025）

これが100万トークン時代の隠れたコストです。ウィンドウは、モデルがそれを使いこなす能力よりも速く広がりました。そしてそれは、「何を入れずにおくか」をスタック全体で最も価値のある問いに変えたのです。この問題のアーキテクチャ版、とりわけ長いコンテキストではなく検索に手を伸ばすべき場面については、Context Rot、RAG、ロングコンテキストをご覧ください。

---

コンテキストが失敗する4つのパターン

コンテキスト汚染（context pollution）は、入っているべきでない材料によって劣化したコンテキストを指す総称です。便利な言葉ではありますが、診断としては役に立ちません。汚染されているとわかっても、何を取り除けばよいかはわからないからです。最も有用な切り分けは、2025年6月22日に「How Long Contexts Fail」を公開したDrew Breunigによるものです。彼はコンテキスト汚染を4つの異なる失敗モードに分けました。この分類が定着したのは、それぞれ対処法が違うからです。

これらの背後にある事例は具体的です。ポイズニングについて、BreunigはポケモンをプレイするGemini 2.5のエージェントを挙げます。ゲームの状態を幻覚し、それを自分のゴール欄に書き込み、その後長いあいだ実現不可能な目標を追い続けました。ディストラクションについては、前節の土台になっているのと同じDatabricksの結果を引いています。ウィンドウがその何倍もあるモデルで、正答率がおよそ32,000トークン付近から滑り始める、という話です。

最も行動につながる証拠があるのはコンフュージョンです。Breunigのまとめによれば、Berkeley Function-Calling Leaderboardでは "every model performs worse when provided with more than one tool"（どのモデルも、ツールを2つ以上与えられると性能が落ちる）のであり、リクエストと何の関係もないツールを呼ぶこともあります。GeoEngineのベンチマークでは、量子化されたLlama 3.1 8Bが、46個のツールを与えられるとタスクに失敗し、19個なら成功しました。同じモデル、同じタスク、選択肢が少ないだけです。

クラッシュについては、Breunigは同じ情報を一度に渡さず複数のメッセージに分散させる「シャード化された（sharded）」プロンプトに関するMicrosoftとSalesforceの研究を引いています。性能は平均39パーセント低下し、o3は該当タスクで98.1から64.1へ落ちました。

腹に入れておく価値のあるパターンはこれです。4つのうち3つは、コンテキストを足すと悪化します。良くなるのは1つ、本当に事実が欠けている場合だけです。この非対称こそが、キュレーションを支持する論拠のすべてです。

---

研究が示すこと：読むべき文献

ここでは4つの文書が重みのほとんどを担っています。これだけ読んでおけば、ネット上でこの話題を議論しているほぼ全員より先に行けます。軸になるのは、2025年7月17日に投稿された「A Survey of Context Engineering for Large Language Models」（arXiv:2507.13334）です。166ページにわたり、1,411本の論文を引きながら整理しており、この分野にとって地図に最も近い存在です。

このサーベイの立て方は、コンテキストエンジニアリングが "transcends simple prompt design to encompass the systematic optimization of information payloads for LLMs"（単純なプロンプト設計を超えて、LLMに渡す情報ペイロードの体系的な最適化までを含む）というものです。分野を、基礎コンポーネント（コンテキストの検索と生成、コンテキスト処理、コンテキスト管理）と、その上に築かれるシステム実装（RAG、記憶システム、ツール統合型推論、マルチエージェントアーキテクチャ）に分けています。RAGがコンテキストエンジニアリングに対してどの位置にあるのか疑問に思ったことがあるなら、答えはこれです。検索は、より大きな学問領域の内側にある一つの機械にすぎません。

最も興味深い発見は、著者たちが "a defining priority for future research"（今後の研究における決定的な優先課題）と位置づけたギャップです。良質なコンテキストエンジニアリングで補強されたモデルは "demonstrate remarkable proficiency in understanding complex contexts"（複雑なコンテキストの理解において目覚ましい能力を示す）一方で、"exhibit pronounced limitations in generating equally sophisticated, long-form outputs"（同じだけ洗練された長文の出力を生成することには顕著な限界を見せる）というのです。平たくいえば、私たちはモデルに情報を与えることは格段にうまくなったのに、長くて質の高い成果物を返させることはうまくなっていません。AIが見事な要約を書いた直後に凡庸な3,000語の草稿を出すのを見たことがある人なら、これを体感で知っているはずです。

もう一つ全文を読む価値があるのが、2025年9月29日に公開されたAnthropicの「Effective context engineering for AI agents」です。いま多くのツールが使っている実務語彙は、この文書から広まりました。

• ジャストインタイム検索（just-in-time retrieval）：すべてを事前に読み込むのではなく、軽量な識別子（ファイルパス、クエリ、リンク）だけをコンテキストに置き、実データは実行時に読み込む。
• 圧縮（compaction）：会話がウィンドウの上限に近づいたら要約し、新しいウィンドウを初期化する。難しさはすべて取捨選択にあるとAnthropicは指摘する。"overly aggressive compaction"（過度に攻めた圧縮）は、あとになって初めて重要さが判明する微妙な文脈を落としてしまうからだ。
• 構造化されたノート取り（structured note-taking）：エージェントに、コンテキストウィンドウの外にある永続的な記憶へノートを書かせ、必要になったら読み戻させる。
• サブエージェント構成（sub-agent architectures）：きれいなコンテキストウィンドウを持つ専門エージェントに絞ったタスクを渡し、統括役のエージェントが結果を統合する。

この4つの技法は自律エージェント向けに設計されたものです。しかし4つとも、人がチャット画面で手作業でやれる等価物を持っています。それが次の2つの節の主題です。これらの発想が日々のエージェント運用ツールにどう現れているかは、スキル、サブエージェント、フックをご覧ください。

---

誰も名付けなかったスキル：キュレーション

コンテキストロットが問題なら、キュレーションが解決策です。そしてキュレーションは、多くのナレッジワーカーがすでに実践しているスキルでもあります。ただ、そう呼んでいないだけです。

記事の一節をハイライトするたび、あなたはキュレーションをしています。「ここが大事だ。残りは背景だ」と言っているわけです。PDFに注釈を入れる、論文をブックマークする、引用を保存する。どれも同じことです。テキストであふれた世界に対して、信号と雑音のフィルターを組み立てているのです。

最近まで問題だったのは、そのキュレーションが閉じ込められていたことでした。ハイライトはあるアプリの中に、Kindleのメモは別のアプリの中に、ウェブでの調べ物はブラウザの履歴の中にありました。いざAIにブリーフィングしようとしても、それらをコンテキストウィンドウへ効率よく引き込む手段がありません。結局すべてを読み直すか、もっと悪ければ、生の資料を貼り付けて幸運を祈ることになります。

学問領域としてのコンテキストエンジニアリングには、まさにここに大きな空白があります。企業は社内ナレッジベースとRAGパイプラインを作って解決しました。しかし個人のナレッジワーカーにエンジニアリングチームはいません。抱えている問題は同じ（資料が多すぎて、信号が足りない）なのに、インフラだけがないのです。

だからこそ、ハイライトを永続的に残す読書ツールが、静かにAIインフラになりました。Glaspのウェブハイライターは、まさにこれを解くために存在します。あなたの読書を、構造化され、取り出せるコンテキストへ変えるのです。ブログ記事の段落をハイライトすると、そのハイライトは、後からどんなAIにも渡せるコンテキストの一片になります。トピックでも、出典でも、日付でも絞り込めます。

同じ原理は長文の読書にも当てはまります。Kindleのハイライトは、あなたにとって何が重要かについて、これまで生み出してきたなかでおそらく最も質の高い信号です。ハイライトするだけの時間、注意を向けたのですから。それはコストのかかったフィルターであり、閉じたシステムの中に置かれたままなら無駄になります。

---

個人のためのコンテキストエンジニアリング（エンジニアだけのものではない）

コンテキストエンジニアリングに関する文章の多くは開発者に向けて書かれています。プロダクションのAIシステムを作る話です。コーディングエージェントのシステムプロンプトをどう形づくるか、検索のためにドキュメントをどう分割するか、ツール呼び出しをどう配線するか。ソフトウェアを出荷する人には有用です。より良いAI出力を得たいコンサルタント、研究者、ライター、アナリスト、学生には、あまり役に立ちません。

けれども、同じ規律は当てはまります。ただ、手作業で回すだけです。

あなたは、非公式にシステムプロンプトを設計しています。 作成したカスタムGPT、Claudeのプロジェクト、claude.mdのような指示ファイルは、どれもシステムプロンプトです。「あなたは私のリサーチアシスタントです。私は再生可能エネルギー政策を扱っています。要約は懐疑的なトーンでお願いします」と書くとき、あなたはシステムプロンプトを設計しています。意識してやりましょう。

あなたは、記憶を管理しています。 ChatGPTのメモリ機能もClaudeのプロジェクトも、会話をまたいで残る事実を固定できます。多くの人はこれを無視して連続性を失うか、何もかも放り込んで雑音を作るかのどちらかです。正しいやり方は、職務経歴書を整えるように記憶を整えることです。毎回モデルに使ってほしいものだけを残します。

あなたは、手作業で検索をしています。 適切な記事をチャットに貼り付けるのは、手動のRAGです。問題は、その「適切な記事」がどこから来るかです。ブラウザ履歴を必死にスクロールして探しているなら、あなたに検索の仕組みはありません。すでに面白いと印を付けた文章の書庫から来るなら、それがあるということです。

あなたは、意図をもって添付を読み込ませています。 誘惑は本を丸ごとアップロードすることです。より良い一手は、実際にハイライトした40ページをアップロードすることです。上流で選別することで、コンテキストロットを迂回しているわけです。

そしてAnthropicの実務書にある4つのエージェント技法には、それぞれ手作業版があります。

多くの人が取りこぼしているのは圧縮です。長いスレッドが時間とともに悪くなるのは、古いメッセージが役に立たない形でコンテキストを占めるからで、これはまさに前の表にあったディストラクションの失敗モードです。新しいサブタスクには、きれいなブリーフを添えて新しいスレッドを立てるほうが、巨大スレッドを続けるより結果が良いのが普通です。

ここにエンジニアリングの技能は要りません。要るのは、優れた研究者や優れたジャーナリストがすでに持っているスキルです。何を入れ、何を切り、どこから引いてくるかを知っていることです。

---

あなたのハイライトが、あなたの競争的コンテキストになる

過小評価されている部分の話をします。

多くの人はノートやハイライトを、記憶の補助として扱います。いつか読み返すためのもの、というわけです。その捉え方は2010年には筋が通っていました。読み返すことが、それらを使う唯一の方法だったからです。2026年には時代遅れです。

あなたのハイライトは、いまやAIに手渡せるフィードです。印を付けたすべての一節、保存したすべての引用、書き込んだすべての注釈が、コンテキストの一片です。しかもそれは、あなたが注意を払ったからこそ生まれたもので、ウェブから無作為に集めたどんなものより信号が濃いのです。

これが競争のうえで何を意味するか考えてみてください。2人のナレッジワーカーが同じAIモデルを使います。片方には3年分の構造化された読書とハイライトがあります。もう片方には3年分の、二度と開かなかったブラウザタブがあります。同じ質問をAIに投げたとき、前者は自分でキュレーションしたコーパスを渡せます。後者は、モデルの一般的な学習データと、たまたま思い出して貼り付けられた分だけで戦うことになります。この差はプロンプトの差ではありません。コンテキストの差です。

だからこそ、Glaspは自らの位置づけを少しずつ変えてきました。当初の触れ込みはソーシャルウェブハイライターでした。気になったところをハイライトし、他の人が何をハイライトしたかを見て、読み手としてのアイデンティティを育てる。それはいまも全部そのとおりです。けれども、より深い価値はいま、すべてのハイライトが使われるのを待っているコンテキストのトークンだという点にあります。あなたの読書履歴は、一段落ずつ、あなた個人のRAGコーパスへと積み上がっていきます。

これをGlaspのAIチャットと組み合わせると、ワークフローはエンジニアが自社向けに構築しているものへ近づきます。読みながらハイライトする。あとから質問すると、AIは一般的なウェブの索引からではなく、あなたが実際に気にかけたものから引いてきます。それがコンテキストエンジニアリングです。ただし、そのコンテキストはあなた自身の書庫です。

読書とAIの関係がこれでどう反転するかは、AI読書アシスタントをご覧ください。

---

どんなAIタスクにも使えるシンプルなフレームワーク

理論はここまでです。次にチャットを開いたときに実行できる、具体的な手順を示します。

ステップ1：打ち込む前に、仕事を定義する。 一文で。「完了」とはどういう状態ですか。「週4日勤務制に反対する主要な3つの論点を要約した500語のメモを、懐疑的なCOO向けに書く」。これは仕事です。「この記事を手伝って」は仕事ではありません。

ステップ2：資料を集め、それから削る。 タスクに本当に関係する材料を引き出します。そのトピックのハイライトがあるなら、記事全文ではなくそこから始めます。記憶を設定してあるなら、すでに有用な背景が入っていないか確認します。かすっている程度のものは外します。コンテキストロットは実在します。

ステップ3：役割とルールを決める。 タスクの前に、モデルが何者で、どのルールが適用されるかを伝えます。「あなたは懐疑的なCOO向けに編集しています。専門用語は使わない。言葉を濁さない。形容詞より先に数字を」。これがシステムプロンプトのレイヤーです。10秒で済み、そのあとに続くすべてのトーンを変えます。

ステップ4：タスクと一式を、順序を決めて渡す。 最も重要なコンテキストを先頭に、タスクを最後に置きます。Lost in the Middleの効果があるので、指示と最も鋭い材料は冒頭と末尾に置きたいところです。中間は沼です。

ステップ5：手を入れる前に、診断する。 出力が悪いとき、プロンプトを12通りに書き直したくなる衝動を抑えてください。代わりに、4つの失敗モードをチェックリストとして走らせます。誤った事実が紛れ込み、何度も戻ってきていませんか（ポイズニング）。スレッドが長く、同じことの繰り返しになっていませんか（ディストラクション）。関係するのは1つなのに、資料を3つ添付していませんか（コンフュージョン）。食い違う2つの指示を与えていませんか（クラッシュ）。それぞれ対処法が違い、どれも言い換えではありません。

これを何十回か繰り返すと、反射的にできるようになります。「これをどうプロンプトしよう」と考えるのをやめ、「答える前に、モデルは何を見ている必要があるか」と考え始めます。その切り替えこそが、この学問領域のすべてです。

---

よくある質問

コンテキストエンジニアリングを簡単にいうと何ですか

AIモデルが答える前に、何を見せるかを決めることです。そこには、与える指示、添付するドキュメント、モデルがあなたについて覚えていること、使えるツール、そしてここまでの会話が含まれます。プロンプトエンジニアリングが扱うのはリクエストの言い回しだけで、それは数ある入力のうちの一つです。

プロンプトエンジニアリングは本当に死んだのですか

言葉のほうは引退しつつあります。その下にある技術はいまも効きます。思考の連鎖、少数例の提示、明確な出力フォーマットはどれも有用なままです。死んだのは、良い言い回しだけで素晴らしい出力が得られるという考え方です。2026年において、言い回しは小さなレバーです。大きなレバーはコンテキストの組み立てです。「プロンプトエンジニアリングは死んだ」と言われるとき、意味されているのはこれです。

コンテキストエンジニアリングは死んだのですか、それとも単なる流行語ですか

この言葉は誇大宣伝のピークを過ぎ、独立した職種としての「コンテキストエンジニア」はまだ標準ではなく萌芽段階です。Adobeはその名称そのままの職を募集していますが、多くの企業ではこの仕事は既存のAI、データ、プラットフォームエンジニアリングの職務の内側にあります。実践のほうはかつてないほど定着していて、消えるのではなく通常のAI業務に吸収されつつあります。現代のエージェントツールにある自動圧縮と自動検索は手作業の一部を取り除きましたが、記憶に何を入れるか、モデルにどのソースを見せてよいかは、いまも誰かが決めています。その決定こそが仕事です。

コンテキスト汚染とは何ですか

そこにあるべきでない材料によって劣化したコンテキストを指す一般的な言葉です。Drew Breunigの分類はコンテキスト汚染を4つのモードに分けます。ポイズニング（誤りが入り込み、繰り返される）、ディストラクション（コンテキストが長くなりすぎ、モデルがそこに寄りかかる）、コンフュージョン（無関係な内容が答えを引き下げる）、クラッシュ（2つのコンテキストが互いに矛盾する）。どれに当たっているかを見極めることが大事なのは、対処法が異なるからです。

コンテキストエンジニアリングについて読むべき論文は何ですか

まずは「A Survey of Context Engineering for Large Language Models」（arXiv:2507.13334）から。1,411本の論文を扱った166ページのレビューです。長いコンテキストが失敗する証拠については、TACL掲載のLiu et al. (2024)「Lost in the Middle」と、Chromaの2025年の技術レポート「Context Rot」を読んでください。実践面では、Anthropicの「Effective context engineering for AI agents」（2025年9月）が、学術文献以外で最も役に立つ文書です。

コンテキストエンジニアリングとRAGの違いは何ですか

RAG（検索拡張生成）はコンテキストエンジニアリングの1つのレイヤー、具体的には検索のレイヤーです。必要なときにナレッジベースから関連する断片を引き出す機構のことです。コンテキストエンジニアリングは、RAGに加えてシステムプロンプト、記憶、ツール利用、添付ファイル、会話履歴までを含む、より広い学問領域です。

コンテキストウィンドウが大きくなれば、いずれ解決するのではないですか

いまのところ解決していませんし、証拠はそうならないことを示しています。Liu et al. (2024) は、モデルが長いコンテキストの中間を無視することを示しました。Chromaの2025年の研究は、検証した18のフロンティアモデルすべてがウィンドウの埋まるはるか手前で劣化することを示しました。1,000万トークンをうたうウィンドウには針を見つける検索の結果はありますが、その長さで推論の質が保たれることを示した公開ベンチマークはありません。ボトルネックはウィンドウの大きさではありません。ウィンドウの内側での注意の配分です。

コンテキストエンジニアリングをするには技術的な知識が必要ですか

必要ありません。「エンジニアリング」という比喩に戸惑う人もいますが、要するに偶然任せにせず意図的にやる、というだけの意味です。ブリーフを準備するコンサルタント、記事を取材するジャーナリスト、小論文のために資料を整理する学生。どれも姿を変えたコンテキストエンジニアリングです。核になるスキルはキュレーションと判断です。

AIの「メモリ」機能とはどう関係しますか

メモリ（ChatGPTの永続的な記憶やClaudeのプロジェクトなど）は、コンテキストの1つのレイヤーです。セッションをまたいでモデルがあなたについて知っていることにあたります。コンテキストエンジニアリングはメモリを含みますが、より広い概念です。メモリは常時オンのレイヤーです。検索、添付ファイル、システムプロンプトはタスクごとのレイヤーです。優れたコンテキストエンジニアは、そのすべてを組み合わせて使います。

これは結局、凝ったノート取りではないですか

部分的にはそうです。違いは、従来のノート取りが「あなたが読み返すこと」に最適化されているのに対し、コンテキストエンジニアリングは「モデルがノートを消費すること」に最適化されている点です。求められる形式は異なります（構造、単位の細かさ、取り出しやすさの重みが増します）が、覚えておく価値のあるものを捕まえるという根っこの実践は同じです。ノート取りが得意な人は、ここで一歩リードしています。

---

結論：新しいリテラシー

コンピューティングのどの時代にも、素人と本気の使い手を分けるリテラシーがありました。2000年代にはGoogleをうまく検索できることでした。2010年代にはNotionやAirtableのようなアプリで情報を構造化できることでした。2026年には、AIのためにコンテキストを設計できることです。

これを掴んだ人は、掴まなかった人をはるかに引き離していきます。モデルへのアクセスが良いからではありません（モデルは誰にとっても同じです）。どのタスクにも、より良い材料を持って現れるからです。何を入れるべきかを知っています。何を外すべきかを知っています。あるトピックについて自分の最良の資料がどこにあるかを知っています。数か月前に、わざわざ捕まえておいたからです。

だからこそキュレーションは、静かにAI時代で最も価値のあるメタスキルになりつつあります。保存する一つひとつのハイライト、注釈を入れる一つひとつの文章、実際に噛み砕いた一つひとつの読書が、あなた個人のコンテキストエンジンへの預け入れです。AI時代の生産性の未来は、秘密のプロンプトを持つ人たちのものではありません。よく考えられた書庫を持つ人たちのものです。

あなたはすでに読んでいます。何が重要かについて、すでに意見も持っています。唯一の問いは、そのどれかが、未来のあなた自身と、あなたの隣で働くAIの役に立つほど長く残ってくれるかどうかです。道具はもうあります。難しいのは習慣のほうです。

今日、読む価値のあるものを一つ選んでください。大事なところをハイライトしてください。それがコンテキストエンジニアリングです。それ以外はすべて、技術の話です。