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

LLMのコンテキストウィンドウに「何を・どの順番で・どれだけ渡すか」を設計・最適化するエンジニアリング手法です。2025年6月にShopify CEOのTobi LütkeとAndrej Karpathyが提唱し、プロンプトエンジニアリングの上位概念として注目されています。

プロンプトエンジニアリングとどう違いますか？

プロンプトエンジニアリングが「どう聞くか（How to ask）」を最適化するのに対し、コンテキストエンジニアリングは「何を渡すか（What to provide）」を設計します。プロンプトはコンテキストエンジニアリングの構成要素の一つに過ぎません。

コンテキストエンジニアリングは難しいですか？

基本概念はシンプルですが、実践は奥が深いです。Anthropicの研究では、コンテキストが増えるほどモデルの正確さが95%から60%に落ちる「コンテキストロット」問題があります。何を入れるかと同じくらい、何を省くかが重要です。

プロンプトエンジニアリングの勉強は無駄になりますか？

なりません。プロンプトエンジニアリングはコンテキストエンジニアリングの中核要素です。ただし、AIエージェントや複雑なLLMアプリを作るには、プロンプト以外の情報設計（RAG、メモリ、ツール定義等）の知識が不可欠になっています。

AI Tools 2026年6月14日 18分で読める

コンテキストエンジニアリング入門｜プロンプトエンジニアリングを置き換えるAIの新常識【2026年版】

#コンテキストエンジニアリング #プロンプトエンジニアリング #LLM #AIエージェント #Claude #AI活用

「プロンプトを磨いても磨いても、AIが思い通りに動かない」。Qiitaでこんな告白記事がバズった。著者のRepKuririnは「まだ『プロンプトエンジニアリング』で消耗してるの？」と問いかけ、問題はプロンプトの言葉選びではなく「LLMに渡す情報環境全体の設計」にあると指摘した（Qiita, 2025-07-02）。

その答えが「コンテキストエンジニアリング」だ。

2025年6月、ShopifyのCEO Tobi Lütkeが「プロンプトエンジニアリングよりコンテキストエンジニアリングという言葉の方が好きだ」と投稿し、1.9百万インプレッションを獲得した（X, 2025-06-19）。それを受けて元OpenAIのAndrej Karpathyも同月、「すべての本番LLMアプリにおいて、コンテキストエンジニアリングはコンテキストウィンドウを正確な情報で満たす繊細な技術だ」と追認した（X, 2025-06-25）。

Gartnerは同年7月に「コンテキストエンジニアリングの時代が来た。プロンプトエンジニアリングの時代は終わった」と宣言し、「プロンプトエンジニア」の求人は2024年から2025年にかけて約40%減少した。

この記事はこんな人におすすめ

プロンプトを工夫しても限界を感じているエンジニア・開発者
LLMアプリやAIエージェントを本番運用しようとしている人
「コンテキストエンジニアリング」という言葉を聞いたが、何が違うのか知りたい人
RAG・メモリ・ツール定義をどう組み合わせるか悩んでいる人

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

コンテキストエンジニアリングとは、LLMのコンテキストウィンドウに「何を・どの順番で・どれだけ渡すか」を設計・最適化するエンジニアリング手法だ。

Anthropicはこれを「LLM推論時に最適なトークンセットをキュレーション・維持するための戦略群」と定義している（Anthropic Engineering Blog, 2025-09-29）。

Karpathyのメタファーが鋭い。「LLMはCPU、コンテキストウィンドウはRAMだ」。どれだけ高性能なCPUでも、RAMに入っているデータが正確でなければ計算は失敗する。コンテキストエンジニアリングは、そのRAMに何を載せるかを設計する技術だ。

さらにKarpathyはこう続けた（X, 2025-06-25）。

「情報が少なすぎたり、形式が間違っていれば、LLMは最適なパフォーマンスを発揮できない。多すぎたり無関係な情報があれば、コストが上がり、性能が落ちる。これをうまくやるのは本当に難しい。」

プロンプトエンジニアリングとの違い

Qiitaで「2026年の生存戦略」として注目された記事（emi_ndk, 2026-06）の表現が的を射ている。

「どう聞くか（How to ask）の時代は終わり、何を渡すか（What to provide）の時代になった。」

比較軸	プロンプトエンジニアリング	コンテキストエンジニアリング
フォーカス	指示の言葉選び	情報環境の設計
スコープ	単一リクエスト	マルチターン・エージェント全体
対象	質問文の構造	システムプロンプト・履歴・RAG・ツール全体
関係性	サブセット	スーパーセット（上位概念）

プロンプトエンジニアリングはコンテキストエンジニアリングの構成要素の一つに過ぎない。「プロンプトを廃棄する」のではなく、「プロンプトをより大きな設計の中に位置づける」概念だ。

コンテキストを構成する7つの要素

LLMが「見る」情報は1種類ではない。Anthropicのエンジニアリングブログ（2025-09-29）とZennの実践者たちの分析を統合すると、コンテキストは7つの要素で構成される。

1. システムプロンプト モデルの役割・制約・振る舞いを定義する固定情報。AIエージェントの「人格」にあたる。

2. ユーザープロンプト ユーザーからの具体的な指示。従来の「プロンプトエンジニアリング」が主に扱ってきた領域。

3. 会話履歴（短期メモリ） 過去のターンのやりとり。長くなるほど「コンテキストロット」のリスクが高まる。

4. 長期メモリ ベクトルDBや外部ファイルに保存された、セッションをまたぐ記憶。Claude CodeのCLAUDE.mdはその典型例だ。

5. 外部知識（RAG） 検索で取得したドキュメント・コードベース・データ。「RAGはコンテキストエンジニアリング1.0だった」という見方もある（Latent Space, 2025-08）。

6. ツール定義（MCP） AIが呼び出せるツールの仕様。ツールが多すぎるとモデルが混乱するため、Simon Willisonは「ツールは20個以下に絞れ」と助言している。

7. 出力フォーマット定義 期待する返答の形式（JSON構造、Markdown、コードブロック等）の指定。

この7要素を「予算」として扱う視点が実践者に広まりつつある。Cobus Greylingが述べた通りだ。「コンテキストは記録ではなく予算だ。何かを追加するたびに、それがいまだにコストに見合っているかを問え」（Substack, 2025）。

なぜ2026年に必須スキルになったのか

AIエージェントの普及が、コンテキストエンジニアリングを「あると便利」から「なければ詰む」スキルへ変えた。

コンテキストロットという現実

HackerNewsユーザーWorkaccount2が2025年6月に命名した「コンテキストロット（Context Rot）」は、今やエンジニア間の共通語だ（Simon Willison, 2025-06-18）。長くなったコンテキストが過去の失敗例や無関係な情報で「腐敗」し、出力品質が急速に劣化する現象だ。

データは厳しい。Chromaの研究では、コンテキストが増えるほどモデルの正確さは95%から60%にまで低下することが示された（Anthropic Engineering Blog, 2025-09-29）。Philipp Schmidは警告する。「モデルが1Mトークンのウィンドウを持っていても、実際のパフォーマンス劣化は256kトークン付近から始まる。APIエラーが出るまで待ってはいけない」（philschmid.de, 2025-12-04）。

本番エージェントのリアル

Manus AIのYichao “Peak” Jiは「フレームワークを4回作り直してたどり着いた教訓」として、KVキャッシュヒット率が本番AIエージェントの最重要指標だと語る（manus.im, 2025-07-18）。典型的なタスクで約50回のツール呼び出しが発生する現場では、コンテキストの能動的な管理なしに品質を維持することは不可能だ。

Microsoft AzureのSREエージェントチームも同様の結論に至っている。「100以上の細かいツールを5つの広範なツールに統合し、コンテキストエンジニアリングに集中することが、モデルのアップグレードより大きな効果をもたらした」（Microsoft Tech Community, 2026-01）。

Anthropicも同年9月のエンジニアリングブログで、コンテキストエンジニアリングの実践でパフォーマンスが39%改善、トークン使用量が84%削減できたと報告した（Anthropic Engineering, 2025-09-29）。

光と影：コンテキストエンジニアリングのリアル

光：実際に起きた成果

LangChainが体系化したWrite/Select/Compress/Isolateの4戦略（LangChain Blog）は、多くの現場で成果を上げている。

Write：情報をコンテキスト外のストレージに書き出す（CLAUDE.md、todo.md等）
Select：ステップごとに関連情報だけを選んで投入するRAGアプローチ
Compress：会話履歴を要約して圧縮し、トークンを節約
Isolate：サブエージェントに独立したコンテキストウィンドウを持たせる

Microsoftの研究（2025）では、コンテキストエンジニアリングを活用したコード生成で「完了タスクが26%増加、エラーが65%減少」という結果も報告されている（Microsoft Tech Community）。

影：見えにくい落とし穴

批判1: プロンプトエンジニアリングのリブランドにすぎない

RAGの共同発案者であるDouwe Kiela（Contextual AI CEO）は「人々はRAGとMCPをコンテキストエンジニアリングと呼ぶようになっただけだ」と語っている（The New Stack, 2026-01）。HackerNewsでも「プロンプトエンジニアリングのリブランドだ。これが違うと主張するのは無知か有害だ」という声があった（HN 2025-07）。

批判2: 「プロンプトジャニター」問題

開発者がコンテキストの手作業管理に追われ、本質的な開発が止まる現象を「プロンプトジャニター（prompt janitor）」と呼ぶ声もある。コンテキストの設計・最適化・デバッグが新たな生産性のボトルネックになりうる。

批判3: コンテキストロットは根本的に解決できない

HKUST の研究（LOCA-bench, arXiv:2602.07962）では、コンテキストが長くなるとフロンティアモデルを含むすべてのモデルで精度が急落することが示されている。コンテキストウィンドウを大きくしても問題は消えない。Databricksの研究によれば、Llama 3.1 405Bでは3万2000トークンを超えたあたりから正確さが落ち始める。

Shelly Palmer（技術アナリスト）のコメントが本質を突く。「プロンプトエンジニアリングを2年間教えてきたが、それはエンタープライズAIを成功させる要因の5%にすぎなかった」（shellypalmer.com, 2025-06）。コンテキストエンジニアリングが残りの95%を担えるかどうかは、まだ証明の途上だ。

この記事のまとめ

コンテキストエンジニアリング = LLMに「何を・どの順番で・どれだけ渡すか」を設計する技術
プロンプトエンジニアリングはその構成要素の一つに過ぎず、上位概念として位置づけられる
7要素：システムプロンプト、ユーザープロンプト、会話履歴、長期メモリ、RAG、ツール定義、出力フォーマット
LangChainのWrite/Select/Compress/Isolate戦略が実践の出発点
「コンテキストロット」問題はフロンティアモデルでも避けられず、何を省くかが何を入れるかと同じくらい重要
批判も根強い：RAGのリブランドとの声、「プロンプトジャニター」問題、コンテキストロットの根本的解決困難性

バイブコーディング入門｜AIに「雰囲気」で指示する開発手法の光と影 — コンテキスト設計と並ぶ、LLMへの指示設計の実践論
エージェント型コーディングの時代、開発者の役割はどう変わるか — AIエージェントが増えるほどコンテキスト管理は複雑化する
UberのAI予算が4ヶ月で消えた理由｜Claude Codeとトークン課金の罠 — コンテキストとトークン消費量の関係を予算視点で解説

本記事の情報は2026年6月14日時点のものです。AI技術は急速に変化するため、最新情報は各公式ドキュメントをご確認ください。記載の統計・データは出典元の調査方法・サンプルサイズに依存するものであり、結果を保証するものではありません。