コンテキストエンジニアリング：プロンプトエンジニアリングが死んだ理由（そしてナレッジワーカーにとっての代替）

プロンプトエンジニアリングを殺したツイート

2025年6月19日、ShopifyのCEOであるTobi LütkeはXに「プロンプトエンジニアリング」よりも「コンテキストエンジニアリング」という用語を好むと投稿しました。「LLMによって妥当に解決可能となるように、タスクのためのすべてのコンテキストを提供する技術」と説明しました。6日後、AI界で最も尊敬される声の1人であるAndrej Karpathyがこの用語を増幅しました。彼の定義はより鋭いものでした。「コンテキストエンジニアリングは、次のステップのためにちょうど適切な情報でコンテキストウィンドウを満たす繊細な技術と科学」（Karpathy, 2025）

このフレーズ自体は新しくありませんでした。自律コーディングエージェントDevinを作ったCognitionのWalden Yanは、年の初めからこれについて書いていました。しかし、2025年6月がラベルが主流になった時でした。2025年半ばまでに、Gartnerはアナリストブリーフィングにシンプルなラインで焼き込みました。「コンテキストエンジニアリングは入り、プロンプトエンジニアリングは出る」（Gartner, 2025）

起きたのはリブランドではありませんでした。訂正でした。AIコミュニティは、「プロンプトエンジニアリング」と呼ばれるスキルが常により大きなものの一部だったこと、そしてそのサブセットがもはや興味深い部分ではないことを静かに認めました。プロンプトは1つのコンポーネントです。コンテキストは部屋全体です。

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

---

コンテキストエンジニアリングが実際に意味すること

最もシンプルな定義：コンテキストエンジニアリングは、モデルが実行する前に、AIモデルがタスクをうまく行うために必要なすべてを決定し、組み立て、提供する実践です。

新しいコンサルタントにブリーフィングするようなものだと考えてください。悪いブリーフは1行のメールです。良いブリーフには、会社の背景、関連する履歴、必要なファイル、ステークホルダー、成功の姿、スコープ外のものが含まれます。優秀なコンサルタントを雇い、悪いブリーフを与えると、平凡な成果物が得られます。AIについても同じです。

コンサルタントの類推はAddy Osmaniのもので、彼のエッセイ「Context Engineering: Bringing Engineering Discipline to Prompts」から来ており、シフトに関する最もクリーンな書き物の1つです。彼のポイントは、プロンプトエンジニアリングが1行のメールを最適化したということです。コンテキストエンジニアリングは、ブリーフィングパッケージ全体を最適化します。

実用的には、これは多くの範囲をカバーします。システムプロンプト（モデルが誰か）、検索レイヤー（見られるドキュメント）、永続的なメモリ（あなたについて覚えていること）、ツール使用（取れるアクション）、添付（このセッションにロードしたファイル）、会話履歴（すでに言われたこと）。これらすべてがレバーです。すべてのレバーが出力に影響します。

このバンドルに新しい名前が付けられた理由は、もはや1つのレバーだけを最適化して素晴らしい結果を得られないからです。スタック全体を考える必要があります。

---

プロンプトエンジニアリングは間違っていなかった。不完全だっただけ

これを、古いものがすべて間違っている世代交代として扱いたくなります。それは怠惰なフレーミングです。プロンプトエンジニアリング技術はまだ機能します。思考の連鎖、少数ショット例、役割割り当て、明示的な出力形式、すべてがまだ針を動かします。

変わったのは天井です。2023年、十分にうまく表現されたプロンプトは、基盤モデルが曖昧さに簡単に混乱するため、応答の品質を2倍にできました。適切な文構造で、GPT-3.5をまごついたインターンから一貫したアナリストに変えられました。そのギャップは本物で、プロンプトエンジニアリングはそれを利用しました。

2026年のフロンティアモデルは手取り足取りの指導を必要としません。Claude、GPT-5、Gemini 2.5は曖昧なリクエストを合理的にうまく理解します。表現の限界リターンは低下しました。しかし、関連するソース素材、スコープされたメモリ、キュレーションされた例を提供することの限界リターンは急激に上昇しました。レバレッジは移動しました。

比較を並べます。

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

---

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

コンテキストエンジニアリングを意図的に行うには、何をエンジニアリングしているかを知る必要があります。すべての現代のAIインタラクションは、あなたがそれについて考えるかどうかにかかわらず、6つのレイヤーから引き出します。スキルは、どれを調整するかを知ることです。

よくエンジニアリングされたコンテキストは、6つすべてを意図的に使用します。よくないコンテキストは、すべてを1つのレイヤー（通常は添付、多くの場合は会話履歴）にダンプし、モデルがそれを整理することを願います。

ほとんどのナレッジワーカーが犯すミスは、AIがコンテキスト組立装置であるのにチャットインターフェースとして扱うことです。チャットは先端です。氷山は、入力する前に供給するものです。

パーソナル情報アーキテクチャがAIの有用性をどう形作るかの関連する角度については、パーソナルコンテキスト管理：あなたとAIの間の欠けているレイヤーをご覧ください。

---

大きなコンテキストウィンドウがこれを悪化させた理由

2023年、100Kトークンのコンテキストウィンドウはエキゾチックでした。2026年までに、1Mトークンウィンドウが一般的です。戦争と平和のフルテキストを1つのプロンプトにドロップできます。自然な仮定は、コンテキストエンジニアリングが容易になっているということです。より多くのスペース、より少ないトリアージ、そうでしょ？

間違いです。より難しくなりました。

ここでの基本論文はLiu et al. (2024)「Lost in the Middle: How Language Models Use Long Contexts」で、TACLで公開されました。研究者は、モデルが長いコンテキスト内のどこに置かれているかによって特定の情報を見つけて使用できるかをテストしました。発見は不快でした。パフォーマンスはU字型です。モデルはコンテキストの最初と最後の情報に最も注意を払います。中間の情報は体系的に過小評価され、時には完全に無視されます（Liu et al., 2024）。

50ページのドキュメントの中間に重要な指示を置くと、モデルはそれを見なかったかのように動作する可能性があります。それはプロンプトで解決できるバグではありません。

その後、2025年にChromaは「Context Rot: How Increasing Input Tokens Impacts LLM Performance」を公開しました。GPT-4.1、Claude Opus 4、Gemini 2.5を含む18のフロンティアモデルをテストしました。結果はすべてのモデルで一貫していました。パフォーマンスは入力が大きくなるにつれて低下し、コンテキストウィンドウが満杯になる前に起きました。200Kトークンウィンドウは、50Kトークンで深刻な腐敗を示す可能性があります。モデルは技術的にすべてを「見た」のです。見なかったかのように動作しました。

これがより多くのコンテキストがより良いコンテキストではない理由です。これが、ウィンドウが許しても、Google Drive全体をプロンプトにダンプしても機能しない理由です。エンジニアリング規律は、含めるものだけでなく、除外するものを知ることです。

これが1Mトークン時代の隠れたコストです。ウィンドウは、モデルがそれを使用する能力よりも速く成長しました。そして、それは「何を省くべきか？」をスタックで最も価値のある質問に変えました。

---

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

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

記事でパッセージをハイライトするたびに、あなたはキュレーションしています。「これが重要だ。残りは背景」と言っています。PDFに注釈を付け、論文にブックマークし、引用を保存するとき、同じことをしています。テキストでいっぱいの世界に対してシグナルとノイズのフィルターを構築しています。

最近までの問題は、このキュレーションが閉じ込められていたことです。ハイライトは1つのアプリにありました。Kindleのノートは別のアプリにありました。ウェブリサーチはブラウザ履歴にありました。AIをブリーフィングするために座ったとき、コンテキストウィンドウに効率的に何も引き込めませんでした。すべてを再読するか、生のソースを貼り付けて最善を願うことになりました。

規律としてのコンテキストエンジニアリングには、まさにここに大きなギャップがあります。企業は内部ナレッジベースとRAGパイプラインを構築することで解決しました。しかし、個々のナレッジワーカーにはエンジニアリングチームがいません。彼らは同じ問題（ソース素材が多すぎ、シグナルが少なすぎ）を持ち、インフラは何もありません。

これが、ハイライトを永続的にキャプチャする読書ツールが静かにAIインフラになった理由です。Glaspのウェブハイライターはまさにこれを解決するために存在します。読書を構造化され、検索可能なコンテキストに変えます。ブログ記事で段落をハイライトすると、そのハイライトは、後で任意のAIに渡せるコンテキストの一部になり、トピック、ソース、日付でフィルタリングできます。

同じ原則が長文読書にも適用されます。Kindleハイライトは、あなたにとって何が重要かについて生成した最高品質のシグナルであり、議論の余地があります。ハイライトするのに十分な時間、注意を払いました。それは高価なフィルターであり、ハイライトが閉じたシステムに置かれると無駄になります。

キュレーションされた読書がダンプされたドキュメントを上回る理由の広い取り扱いについては、情報過多の隠れたコスト：脳が第二のレイヤーを必要とする理由をご覧ください。

---

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

コンテキストエンジニアリングに関するほとんどの文書は開発者を対象としています。プロダクションAIシステムを構築することについてです。コーディングエージェントのシステムプロンプトを形作る方法、検索のためにドキュメントをチャンク化する方法、ツール呼び出しを配線する方法。ソフトウェアを出荷するなら役立ちます。コンサルタント、研究者、ライター、アナリスト、より良いAI出力を得ようとする学生には、あまり役立ちません。

しかし、同じ規律が適用されます。手動で実行するだけです。

非公式にシステムプロンプトを設計する。設定するすべてのカスタムGPT、すべてのClaudeプロジェクト、すべてのclaude.mdスタイルの命令ファイルがシステムプロンプトです。「あなたは私のリサーチアシスタントです。再生可能エネルギー政策に取り組んでいます。懐疑的な要約を好みます」と書くとき、システムプロンプト設計をしています。意図的に行いましょう。

メモリを管理する。ChatGPTのメモリ機能とClaudeのプロジェクトは、どちらも会話間で持続する事実をピン留めできます。ほとんどの人はこれを無視する（そして連続性を失う）か、すべてをそこにダンプする（そしてノイズを作る）かです。正しい動きは、履歴書をキュレーションするようにメモリをキュレーションすることです。モデルに毎回使ってほしいものだけ。

手動で検索を行う。適切な記事をチャットに貼り付けることは手動RAGです。質問は「適切な記事」がどこから来るかです。ブラウザ履歴を必死にスクロールしているなら、検索システムはありません。すでに興味深いとフラグを立てたパッセージのライブラリから来ているなら、あります。

意図的に添付をロードする。誘惑は本全体をアップロードすることです。より良い動きは、実際にハイライトした40ページをアップロードすることです。上流でフィルタリングすることでコンテキスト腐敗をバイパスしています。

会話履歴を管理する。長いスレッドは時間とともに悪化します。古いメッセージがコンテキストを役に立たず支配するためです。新しいブリーフで新しいタスクのために新しいスレッドを開始することは、メガスレッドを継続するよりも優れていることがよくあります。

これにはエンジニアリングスキルは必要ありません。良い研究者と良いジャーナリストがすでに持っている同じスキルが必要です。何を含めるか、何をカットするか、どこから引き出すかを知ることです。

---

あなたのハイライトはあなたの競争的コンテキスト

過小評価されている部分がここにあります。

ほとんどの人はノートとハイライトを記憶の補助として扱います。いつか戻ってくるもの。そのフレーミングは2010年には意味がありました。戻ってくることが使う唯一の方法だったからです。2026年には時代遅れです。

あなたのハイライトは今やAIに渡せるフィードです。フラグを立てたすべてのパッセージ、保存したすべての引用、行ったすべての注釈が、コンテキストの一部です。そしてあなたは注意を払って生成したので、ウェブからランダムにスクレイピングしたものよりも高シグナルです。

これが競争的に何を意味するかを考えてください。2人のナレッジワーカーが同じAIモデルを使います。1人は3年間の構造化された読書とハイライトを持っています。もう1人は3年間の再訪しなかったブラウザタブを持っています。AIに同じ質問をすると、1人目は自分のキュレーションされたコーパスを提供できます。2人目は、モデルの一般的なトレーニングデータと、貼り付けるために思い出せるものに詰まります。ギャップはプロンプティングギャップではありません。コンテキストギャップです。

これが、Glaspが自身を位置付ける方法でシフトしてきた理由です。元のピッチはソーシャルウェブハイライターでした。ハイライトし、他の人がハイライトしたものを見て、リーダーアイデンティティを構築する。すべてまだ本当です。しかし、より深い価値は今や、すべてのハイライトが使用される準備ができたコンテキストトークンであることです。あなたの読書履歴は、1段落ずつ、パーソナルRAGコーパスに複利されます。

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

これが読書とAIの関係をどう反転させるかについては、読書をあなたの代わりにしないAI読書アシスタントをご覧ください。

---

任意のAIタスクのためのコンテキストをエンジニアリングするシンプルなフレームワーク

理論は十分です。次にチャットを開くときに実行できる具体的なワークフローです。

ステップ1：入力する前に仕事を定義する。1文。完了はどう見えますか？「懐疑的なCOO向けに、週4日労働制への反対の3つの主要な議論を要約する500語のメモを下書き」。それは仕事です。「この記事を手伝って」はそうではありません。

ステップ2：ソースを集め、それからカット。タスクに実際に関係する素材を引き出します。トピックのハイライトがあれば、完全な記事からではなく、そこから始めます。メモリが設定されていれば、すでに有用な背景が含まれているかを確認します。ゆるく関連するだけのものは省きます。コンテキスト腐敗は本物です。

ステップ3：役割とルールを設定する。タスクの前に、モデルに誰で、どのルールが適用されるかを伝えます。「あなたは懐疑的なCOO向けに編集しています。ジャーゴンなし。ヘッジなし。形容詞の前に数字」。これはシステムプロンプトレイヤーです。10秒かかり、後続のすべてのトーンを変えます。

ステップ4：タスクとバンドルを順番に供給する。最も重要なコンテキストを最初に、タスクを最後に置きます。Lost in the Middle効果のため、最も鋭い素材と指示を最初と最後に置きたいです。中間は沼地です。

ステップ5：表現ではなくコンテキストで反復する。出力が悪い場合、プロンプトを12通りに書き直す衝動に抵抗します。代わりにこう尋ねます：適切な素材を与えましたか？忘れたパッセージはありましたか？誤解を招くソースはありましたか？入力を調整し、再実行し、品質の飛躍を見守ります。

これを数十回行うと反射的になります。「これをどうプロンプトするか？」と尋ねるのをやめ、「答える前にモデルが何を見る必要があるか？」と尋ね始めます。そのシフトが規律全体です。

---

よくある質問

プロンプトエンジニアリングは本当に死んでいますか？

フレーズは引退しています。フレーズの下の技術はまだ機能します。思考の連鎖、少数ショット例、明確な出力形式はすべてまだ役立ちます。死んだのは、良い表現だけで素晴らしい出力を得られるというアイデアです。2026年には、表現はマイナーなレバーです。コンテキスト組立がメジャーなものです。「プロンプトエンジニアリングは死んだ」と言うとき、これが意味するものです。

コンテキストエンジニアリングをするには技術的である必要がありますか？

いいえ。エンジニアリングのメタファーは一部の人を混乱させますが、偶然ではなく意図的に作業を行うことを意味するだけです。ブリーフを準備するコンサルタント、記事をリサーチするジャーナリスト、エッセイのためにソース素材を整理する学生、これらはすべて変装したコンテキストエンジニアリングです。コアスキルはキュレーションと判断です。技術的なバージョンは、システムプロンプト、RAGパイプライン、メモリストアに適用された同じスキルです。

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

RAG（検索拡張生成）はコンテキストエンジニアリングの1つのレイヤーで、具体的には検索レイヤーです。必要なときにナレッジベースから関連するチャンクを引き出す機構です。コンテキストエンジニアリングは、RAGに加えて、システムプロンプト、メモリ、ツール使用、添付、会話履歴を含むより広い規律です。RAGは技術です。コンテキストエンジニアリングは実践です。

より大きなコンテキストウィンドウが最終的にこれを解決しませんか？

これまで解決していませんし、証拠はそうならないことを示唆しています。Liu et al. (2024)は、モデルが長いコンテキストの中間を無視することを示しました。Chromaの2025年の研究は、テストされた18のフロンティアモデルすべてが、ウィンドウが満たされる前に劣化することを示しました。ボトルネックはウィンドウサイズではありません。ウィンドウ内の注意配分です。ウィンドウがさらに10倍成長しても、キュレーションは価値があり続けます。

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

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

何をやめるべきですか？

プロンプトテンプレートをため込むのをやめてください。ハイライトされたパッセージで十分なときに完全なドキュメントを貼り付けるのをやめてください。システムプロンプトなしで会話を始めて、トーンがオフの理由を疑問に思うのをやめてください。チャットボックスを唯一の表面として扱うのをやめてください。チャットボックスは、はるかに長いパイプラインの最後のセンチメートルであり、そのパイプラインが品質の利益が住む場所です。

ハイライトはこれにどう適合しますか？

ハイライトは、パーソナルコンテキストの最も生で、最も安価な形です。何かをハイライトするたびに、あなた自身の将来のAIセッションからノイズを事前フィルタリングしています。ハイライトを永続的にキャプチャするツール（記事、PDF、Kindle本、YouTubeトランスクリプト全体で）は、読書を再利用可能なコンテキストに変えます。これが、読書キャプチャツールとAIツールが収束している理由です。

これはただの派手なノート取りではありませんか？

部分的には。違いは、従来のノート取りはノートを再読するあなたのために最適化されていることです。コンテキストエンジニアリングは、ノートを消費するモデルのために最適化されています。形式要件は異なります（構造、原子性、検索性がより重要）が、覚えておく価値があるものをキャプチャする根本的な実践は同じです。良いノート取り者はここで先行しています。

---

結論：新しい読み書き能力

コンピューティングのすべての時代には、アマチュアを本格的なユーザーから分ける読み書き能力がありました。1990年代にはGoogleをうまく検索することを学ぶことでした。2010年代にはNotionやAirtableのようなアプリで情報を構造化することを学ぶことでした。2026年には、AIのためにコンテキストをエンジニアリングすることを学ぶことです。

これを理解した人は、そうでない人よりもはるかに先に進みます。モデルへのより良いアクセスを持っているから（誰もが同じモデルを持っている）ではなく、すべてのタスクによりよい素材で現れるからです。彼らは何を供給するかを知っています。彼らは何を省くかを知っています。彼らはトピックに関する最良のソースがどこにあるかを知っています。数か月前にわざわざキャプチャしたからです。

これが、キュレーションが静かにAI時代の最も価値のあるメタスキルになっている理由です。保存するすべてのハイライト、注釈するすべてのパッセージ、実際に処理する読書のすべての断片が、パーソナルコンテキストエンジンへの預金です。AI生産性の未来は秘密のプロンプトを持つ人々ではありません。思慮深いライブラリを持つ人々です。

あなたはすでに読書をしています。すでに何が重要かについて意見を持っています。唯一の質問は、それが将来の自分とあなたと並んで働くAIに有用である十分長く持続するかどうかです。ツールは存在します。習慣が難しい部分です。

今日読む価値のある何かを選んでください。重要な部分をハイライトしてください。それがコンテキストエンジニアリングです。それ以外はすべて技術です。