はじめに
2026年に入ってから、Xのエンジニア界隈でこの言葉を何度も見るようになった。
「プロンプトエンジニアリングはもう古い。これからはコンテキストエンジニアリングだ」
きっかけは明確だ。2025年6月25日、Andrej Karpathy が X 上で context engineering という概念に言及し、同じ月に Shopify CEO の Tobi Lütke もその重要性を公開で支持したことで、業界全体に一気に広まった。
ただ、こういう「○○はもう古い」系のフレーズは、毎年のように登場しては消えていく。本当にプロンプトエンジニアリングは終わったのか？コンテキストエンジニアリングとは何なのか？——今回はこれを冷静に整理して考えてみたい。
コンテキストエンジニアリングとは何か
まず定義から。
コンテキストエンジニアリングとは、LLMが推論時に参照する 情報全体（コンテキストウィンドウ）に、何を・どの順番で・どれだけ渡すかを設計する技術 だ。
プロンプトエンジニアリングとの違いを整理すると、こうなる。
| プロンプトエンジニアリング | コンテキストエンジニアリング | |
|---|---|---|
| 対象 | 指示文（プロンプト）の書き方 | 入力情報全体の設計 |
| スコープ | 基本的に1回の問いかけ | 会話履歴・RAG・ツール・メモリまで含む |
| 問い | 「どう聞くか（How to ask）」 | 「何を渡すか（What to provide）」 |
| 主戦場 | 単発のチャット | AIエージェント・本番システム |
重要なのは、両者は対立概念ではないということだ。Sakana AI の秋葉拓哉氏は「1往復の会話だとプロンプトエンジニアリングとコンテキストエンジニアリングはほぼ同じものになる」と語っている。つまり、コンテキストエンジニアリングはプロンプトエンジニアリングを包含する上位概念と捉えるのが正確だ。
なぜ今、これが重要なのか——「Context Rot」という落とし穴
「コンテキストウィンドウが100万トークンになったんだから、全部詰め込めばいいのでは？」
直感的にはそう思える。だが、ここに大きな罠がある。
2025年7月に Chroma Research が発表した研究は、AIコミュニティに衝撃を与えた。GPT-4.1・Claude 4・Gemini 2.5を含む18の最先端モデルを評価した結果、すべてのモデルで入力トークン数が増えるほど性能が劣化することが実証されたのだ。
短いプロンプトで95%だった精度が、長いコンテキストでは60〜70%まで低下
この現象は 「Context Rot（コンテキストの腐敗）」 と名付けられた。情報がウィンドウに収まっていても、必要な情報が大量のノイズに埋もれて出力精度が落ちる——これが本番システムでの最大の失敗要因になっている。
つまり、コンテキストエンジニアリングの核心は 「足し算」ではなく「引き算」 なのだ。Anthropic も2025年9月に「良いコンテキストエンジニアリングとは、望ましい結果の可能性を最大化する最小限の高シグナルなトークンセットを見つけること」という原則を公開している。
「効果」は数字でも示されている
これが単なるバズワードでない証拠に、定量的な成果も出ている。
LangChain の実験では、モデルを一切変更せず、ハーネス（コンテキスト設計）だけを改善することで、ベンチマーク Terminal Bench 2.0 のスコアが 52.8% → 66.5% へ、13.7ポイント向上した。
同じモデルでも、渡す情報の設計次第でここまで差が出る。これがコンテキストエンジニアリングが「本物のスキル」と言われる理由だ。
自分なりの考察：「古くなった」のではなく「統合された」
ここからは個人的な意見だ。
「プロンプトエンジニアリングはもう古い」という言い方は、半分正しく、半分ミスリードだと思っている。
正しい部分
「Act as a...」「Think step by step」のような 魔法の呪文的テクニックは、確かにコモディティ化した。モデルが賢くなり、多少雑に聞いても意図を汲んでくれるようになったからだ。実際 LinkedIn上の「Prompt Engineer」という肩書きの求人は2024〜2025年で大きく減少したというデータもある。
ミスリードな部分
しかし「プロンプトを設計する力」が不要になったわけではない。それは コンテキストエンジニアリングという大きな枠組みの一部として吸収されただけだ。
実際、現場のClaude CodeやCursorを使った開発では——
- CLAUDE.md に技術スタックや禁止事項を書く（永続コンテキストの設計）
- RAGで渡す情報を厳選する（ノイズの排除）
- ツールを必要な分だけ段階的に開示する（Progressive Disclosure）
こうした 「AIに見せる世界そのものを設計する」作業が、エンジニアの新しい日常になりつつある。
現場で今すぐ意識できる3つのこと
考察だけで終わると実用性がないので、自分が意識していることを3つ挙げておく。
1. 「入れない勇気」を持つ
全部渡せばいいわけではない。Context Rotを避けるため、本当に必要な情報だけをキュレーションする。
2. CLAUDE.md / システムプロンプトに恒久ルールを集約する
「毎回同じ指示を書く」のは設計ミス。守ってほしい制約はセッションをまたいで効く場所に置く。
3. ツールを盛りすぎない
100以上のツールを事前ロードするとハルシネーションの原因になる。必要なものだけを段階的に。
まとめ
| 問い | 自分の結論 |
|---|---|
| プロンプトエンジニアリングは死んだ？ | ❌ 上位概念に統合された |
| コンテキストは多いほど良い？ | ❌ Context Rotで劣化する |
| コンテキスト設計で性能は変わる？ | ✅ 実験で13.7pt向上の実績あり |
| これは一過性のバズワード？ | ❌ 本番システムの中核技術 |
「○○はもう古い」というフレーズに振り回されず、その背後にある本質的な変化を捉えることが大事だと思っている。今回で言えば、それは「AIに何を見せるかを設計する責任が、エンジニアに移ってきている」ということだ。
プロンプトの呪文を磨く時代から、AIが見る世界そのものを設計する時代へ。
あなたの現場ではどんなコンテキスト設計の工夫をしていますか？ぜひコメントで教えてください 🙏
参考になったらLGTMもらえると励みになります！
参考情報
- Andrej Karpathy 氏 X投稿（2025年6月25日）
- Tobi Lütke 氏（Shopify CEO）X投稿（2025年6月19日）
- Chroma Research「Context Rot」研究（2025年7月）
- LangChain「Agent = Model + Harness」ベンチマーク実験（2026年3月）
- Anthropic「Effective context engineering for AI agents」（2025年9月）
- 日経クロステック「LLMをAIエージェントに進化させるコンテキストエンジニアリング」（2026年2月）