文脈エンジニアリング（Context Engineering）とは｜RAGやAIエージェントが思い通りに動かない人のための新常識

本記事には広告（PR）が含まれています。

「同じChatGPTを使っているのに、なぜか自分の出力だけ精度が低い」
「AIエージェントが途中で迷子になって、長いタスクが完走しない」

そう感じたことはないでしょうか。

実はこれ、モデルの性能のせいでも、プロンプトの書き方のせいでもありません。コンテキスト（文脈）の設計が原因であることが、ここ数年で世界的に明らかになってきました。

この問題に名前を与えたのが文脈エンジニアリング（Context Engineering）という考え方です。Anthropicが2025年9月に公式エンジニアリングブログで体系化し、Shopify CEOのTobi Lütke氏やAndrej Karpathy氏も支持を表明したことで、AI業界に一気に広がりました。

この記事では、文脈エンジニアリングの全体像を、専門知識ゼロでも追える順序で解説します。データエンジニアやデータ分析に関わる方が、自分の業務でどう活かせるかまでイメージできるところまでお連れします。

---

Ｗｉｎスクール	【初心者向け】 ・20～30代におすすめ ・データ分析・AIに特化 公式サイトで無料登録する

文脈エンジニアリングとは何か

よくある誤解：「プロンプトを上手く書けばいい」

AIに何かを頼んで思った結果が出ないとき、多くの人は「プロンプトの書き方が悪かったかな」と考えます。確かにそれも一因ではあります。

でも、本当の原因はもっと手前にあることが多いのです。

たとえば「明日空いてる？」というメールへの返信をAIに任せるとします。

• ユーザーの依頼文だけをAIに渡す → 「ご連絡ありがとうございます。明日は空いています。何時頃をご希望でしょうか？」という、当たり障りのない答えが返ってくる
• 同じ依頼文と一緒に「相手の連絡先」「カレンダーの空き状況」「過去のメール履歴」「招待を送るツール」も渡す → 「Jimさん、明日はちょっと埋まってて、木曜の午前なら空いてるけどどうかな？招待送ったので確認してみて」という、人間的で実用的な答えになる

違いは、AIの賢さではありません。AIの目の前にどんな情報が並んでいたかです。

これがPhilipp Schmid氏（元Google DeepMind、現Hugging Face）が2025年6月に公開した記事で示した、文脈エンジニアリングの核心的な気づきです。

ひとことで言うと

文脈エンジニアリング（Context Engineering）とは、こんな技術です。

AIが上手く答えるために必要な「情報・ツール・形式」を、適切なタイミングで動的に組み立てて渡す設計

「文脈」と聞くと国語の授業を思い出すかもしれませんが、ここでの文脈はもっと広い意味です。AIが応答を生成する直前に「目の前に並んでいるもの全部」を指します。具体的には次の要素が含まれます。

• ユーザーからの依頼文（プロンプト）
• システムから渡される基本ルール
• これまでの会話履歴
• 過去から蓄積された記憶
• 外部から取ってきた情報（社内ドキュメント、データベース、Web検索結果）
• 使えるツールの定義
• 出力してほしい形式の指定

これらをタスクごとに動的に組み立てるのが、文脈エンジニアリングの仕事です。

プロンプトエンジニアリングとは何が違うのか

ここで多くの方が気になるのが、「これって結局プロンプトエンジニアリングと何が違うの？」という点だと思います。

簡単に言えば、範囲が違うだけです。

• プロンプトエンジニアリング：1回のメッセージにどう書くかを工夫する
• 文脈エンジニアリング：そのメッセージの前後で、何を準備し、何を覚えさせ、何を取り出させるかを設計する

プロンプトエンジニアリングは、文脈エンジニアリングという大きな枠の中の一部分として位置づけ直されたとイメージしてください。プロンプトの工夫がいらなくなったわけではなく、それだけでは足りない局面が増えてきた、というだけの話です。

なぜ今この概念が広がっているのか

きっかけは、AIエージェントの普及です。

ChatGPTのような単発の質問応答であれば、プロンプトの工夫だけでもかなり戦えました。しかし2024〜2025年にかけて、ClaudeやGemini、ChatGPTのエージェントモードが普及し、「複数のツールを使って数十分〜数時間かけてタスクを完遂する」用途が急増しました。

この用途では、コンテキストウィンドウ（AIが一度に処理できるトークン数）の使い方が成果を直接左右します。「ただ詰め込む」のではなく「賢く組み立てる」必要が出てきたのです。

そこで、

• 2025年6月：Philipp Schmid氏が「The New Skill in AI is Not Prompting, It’s Context Engineering」を公開
• 2025年9月：Anthropicが公式エンジニアリングブログで「Effective Context Engineering for AI Agents」を公開
• 2025年〜2026年：LangChain、LlamaIndexなどが体系化記事を相次いで発表

という流れで、文脈エンジニアリングは業界共通の語彙として定着していきました。

---

なぜプロンプトだけでは限界が来るのか

「コンテキストウィンドウは無限じゃない」

「最近のモデルはコンテキストウィンドウが100万トークンもあるから、必要そうな情報を全部入れてしまえばいいのでは？」

そう思った方もいるかもしれません。実はこれが落とし穴です。

Anthropicは公式ブログで、こう書いています。

人間の作業記憶に限界があるのと同じく、LLMもまた「注意予算（attention budget）」を持っている。

100万トークン入るからといって、100万トークン分まで同じ精度で扱えるわけではないのです。

専門的な背景：トークンが増えると性能はゆるやかに落ちる

なぜそうなるのか、理由を簡単に説明します。

AIモデルの内部では、入力されたトークンが他のすべてのトークンと関係性を計算する仕組みになっています。トークン数が n のとき、関係性は n × n、つまりトークンが2倍になれば計算量は4倍になります。

その上、AIモデルはトレーニング時に経験した文章長に合わせて「どこに注意を向けるか」のパターンを学習しています。学習時より長い入力が来ると、注意の分配精度が徐々に落ちていきます。

これをAnthropicは Context Rot（文脈の腐敗） と呼んでいます。

コンテキストウィンドウのトークン数が増えるにつれ、その中から情報を正確に想起する能力は低下する。

つまり、コンテキストウィンドウは「ハードな上限」ではなく「性能がゆるやかに落ちる坂」だと考えてください。

結論：詰め込めばいいわけではない

ここから出てくる結論はシンプルです。

これが、「プロンプトだけでは限界が来る」理由でもあり、文脈エンジニアリングが必要とされる理由でもあります。

---

文脈エンジニアリングを支える4つの基本動作

ここからは、より実装に近い話に入ります。LangChain公式ブログが提唱した、Write／Select／Compress／Isolate の4つの動作を順番に見ていきます。

これは「コンテキストをどう設計するか」のフレームワークとして、業界で広く使われるようになりました。

Write（書く）：必要な情報を保管しておく

まず、AIが後で参照できるように、必要な情報を適切な場所に書き込んでおきます。

• 長期記憶：ユーザーの好み、過去プロジェクトの判断、組織の規約など、セッションをまたいで保持する情報
• 短期記憶（Scratchpad）：いまのタスクの途中経過、計算結果、TODOリストなど、今だけ必要な情報

データを扱う仕事をしている方なら、すぐピンとくるかもしれません。これはステートストアやメタデータレイヤーの設計とほぼ同じ発想です。

Select（選ぶ）：必要なときに必要な情報を取り出す

書き溜めた情報や外部データから、いま必要なものだけを的確に選び出します。

• 社内ドキュメントから関連箇所を検索する（RAG）
• 過去の会話メモリから関連する部分を引き出す
• 状況に応じて使うツールをAI自身に選ばせる

これも、インデックス設計とクエリ最適化の世界です。データエンジニアが普段やっていることと、本質的には変わりません。

Compress（圧縮する）：情報を凝縮する

文脈に渡す情報量を、本質を保ったまま減らします。

• 長い対話履歴を要約する
• 関連性の低い情報を捨てる

これはETL/ELT における集約や不要列の剪定と同じ発想です。「下流が必要とする粒度に変換して渡す」というデータエンジニアリングの基本動作が、そのまま使えます。

Isolate（分離する）：責務を切り分ける

ひとつの巨大なAIにすべてを任せず、役割ごとにエージェントを分けます。

• 顧客分析担当
• データ検索担当
• 回答生成担当

それぞれが独立した文脈空間を持ち、互いに干渉しません。これはマイクロサービスアーキテクチャの発想と同じです。

4つの動作のまとめ

動作	やること	普段のデータ業務に例えると
Write	情報を保管する	テーブル設計、メタデータ管理
Select	必要なものを取り出す	インデックス、クエリ最適化
Compress	情報を凝縮する	集約処理、不要列の削除
Isolate	責務を切り分ける	マイクロサービス分割

驚くほど、データエンジニアリングと同じ発想だと感じませんか？これが、後ほど詳しく説明する「データエンジニアと文脈エンジニアリングの相性の良さ」の正体です。

---

RAGはこれからこう変わる：「事前に詰める」から「必要なときに取りに行く」へ

文脈エンジニアリングを語る上で、RAG（Retrieval-Augmented Generation）の話題は避けて通れません。社内Q&AボットやAI検索の多くがRAGで作られているからです。

ただ、Anthropicが2025年9月のブログで提示した方向性は、これまでのRAGとは少し違います。

これまでのRAG（事前検索型）の弱み

これまでのRAGは、こんな手順でした。

1. ユーザーが質問する
2. 関連しそうなドキュメントをベクトル検索で取ってくる
3. 取ってきたドキュメントをまとめてプロンプトに入れる
4. AIが答える

シンプルで効果的ですが、こんな悩みもありませんか。

• 検索結果に関係ない文書が混ざる（ノイズ）
• ベクトルDBの更新が追いつかず、情報が古い
• 取ってきた文書を全部入れるとコンテキストが膨らみ、肝心な情報の精度が落ちる

Just-in-time Retrieval：必要になったその瞬間に取りに行く

Anthropicが推奨しているのは、もう一段階進んだ方式です。

データそのものをあらかじめロードしておくのではなく、ファイルパスやクエリといった軽量な参照だけを持っておき、必要になった瞬間にツール経由で取りに行く。

たとえばこんなイメージです。

• 「いつかの会議メモはこのフォルダの下にある」という情報だけ持っておく
• 質問されたら、AIがファイル名・更新日・サイズなどから当たりをつけ、必要なファイルだけ開く
• 全文を読まなくても、最初の数行だけで判断できる場合は途中でやめる

これは人間がしている動作にとても近いです。あなたも本棚にある本を全部丸暗記しているわけではなく、「あの件はあの本の3章にあったな」という索引だけ覚えていて、必要なときに開きますよね。

Progressive Disclosure：探索しながら段階的に理解を組み立てる

これに付随する重要な考え方が Progressive Disclosure（段階的な情報開示） です。

AIエージェントは、最初から完全な情報を持つ必要はありません。

• ファイル名から内容を推測する
• ディレクトリ構造から重要度を判断する
• タイムスタンプから新しさを察する

たとえば tests/test_utils.py と src/core_logic/test_utils.py は、同じファイル名でも意味が違います。AIエージェントはそうしたヒントから順に意味を組み立てていきます。

これは、データエンジニアにとってはおなじみの発想のはずです。テーブル名、カラム名、命名規則、メタデータ——それらは人間が読むためだけのものではなく、AIが文脈を理解するための重要なシグナルでもあるのです。

実装の選択肢：ハイブリッドが現実解

実務では、すべてをJust-in-timeにする必要はありません。次のような使い分けが現実的です。

• 事前に渡しておく方が良いもの：プロジェクトの基本ルール、用語集、頻繁に使うスキーマ定義
• 必要なときに取りに行く方が良いもの：個別のファイル内容、最新の外部データ、探索中に見つかるもの

Claude Code（Anthropic製のコーディングAI）が良い例です。ワークスペース直下の CLAUDE.md は最初から読み込まれ、個別ファイルは glob や grep で必要なときに参照します。

---

長いタスクを完走させる3つの実装テクニック

「数時間にわたるリサーチ」「大規模なリファクタリング」のような長期タスクでは、コンテキストウィンドウは必ず溢れます。これにどう対処するか。Anthropic公式は3つの実装テクニックを紹介しています。

テクニック1：Compaction（コンパクション）─ 履歴を要約して引き継ぐ

会話履歴がコンテキストウィンドウの上限に近づいたら、その内容を要約して、新しいウィンドウを「要約から始める」方式です。

Claude Codeでは、過去のメッセージをモデル自身に渡して要約させ、

• 残すもの：アーキテクチャ上の決定、未解決のバグ、実装上の重要な詳細
• 捨てるもの：冗長なツール出力、中間メッセージ

を分けて整理します。直近5つのアクセスファイルも引き継ぎ、ユーザーが「あれ、リセットされた？」と感じないように配慮されています。

テクニック2：Note-taking（ノートテイキング）─ 外部メモに書き出す

エージェントが定期的にメモをコンテキスト外（ファイル）に書き出し、必要なときに読み戻すパターンです。

身近な例で言うと、Claude CodeのTODOリスト機能や、ユーザーがプロジェクトに置いておく NOTES.md ファイルがこれに当たります。

Anthropicが紹介している面白い事例があります。ClaudeにポケモンRPGをプレイさせたところ、エージェントは自発的に以下のようなメモを取り続けました。

ここ1,234ステップ、Route 1でポケモンを訓練している。ピカチュウは目標レベル10に対し、すでに8レベル獲得した。

特に「メモを取れ」と指示されたわけでもないのに、自然と進捗管理を始めた、というのがポイントです。

データエンジニアの目線で言えば、これはステートマシンの永続化やワークフローエンジンのチェックポイントと同じ考え方です。

テクニック3：Sub-agent（サブエージェント）─ 深掘り専門に外注する

巨大なタスクを単一エージェントで抱え込まず、小タスクをサブエージェントに任せます。

サブエージェントは数万トークンを使って思いきり探索しますが、メインエージェントには 1,000〜2,000トークン程度に凝縮した要約だけを返します。

メインエージェントは全体の方針と統合に集中し、詳細な探索はサブエージェントの中に閉じ込める。マルチエージェント研究システムでは、この方式が単一エージェントを大きく上回る成績を出したと報告されています。

3つの使い分け

シーン	向いている手法
自然な会話を長く続けたい	Compaction
開発タスクで進捗を管理したい	Note-taking
リサーチ・分析で並列に深掘りしたい	Sub-agent

実務ではこれらを組み合わせます。Claude Code自体が、CLAUDE.mdによる事前ロード、Compaction、TODOリスト、Sub-agent呼び出しを併用しています。

---

データエンジニアの仕事と、どう繋がるのか

ここまで読んでいただいて、こう感じている方も多いのではないでしょうか。

「これ、自分が普段やってる仕事と発想が似てるな」

その直感は正しいです。文脈エンジニアリングで使われている考え方は、データエンジニアリングの実務知見とほぼ同じ筋肉を使います。

共通する5つの発想

データエンジニアリングの実務	文脈エンジニアリングでの対応
ストレージ設計（DWH、データレイク）	長期記憶設計（Memory Tool、Vector DB）
インデックス設計とクエリ最適化	Just-in-time Retrieval、ツール選択
メタデータ管理（Data Catalog、Lineage）	Progressive Disclosure、命名規則をシグナル化
ETL/ELTでの集約・剪定	Compaction、要約処理
データ品質・ガバナンス	コンテキスト品質、責任範囲の分離

「データを蓄え、必要なときに必要な分だけ取り出し、加工して下流に届ける」というデータエンジニアリングの基本姿勢が、そのまま文脈エンジニアリングに使えます。

dbtのドキュメントとテストはAI時代の資産になる

dbtを使っている方なら、modelやcolumnのdescriptionを書く文化があると思います。これらは人間のためだけのものではありません。

• dbt docs の記述 → AIがテーブルの意味を理解する材料になる
• unique not_null テスト → データ品質保証 → AIが幻覚（ハルシネーション）を起こすリスクが下がる
• dbt source freshness → 古いデータをAIに渡さずに済む

つまり、dbtを丁寧に整備することは、そのままAIエージェントの精度を上げる作業でもあるのです。

BigQueryやSnowflakeに眠る知識を、AIに供給する

事業会社のデータ基盤には、何年もかけて積み上げられたドメイン知識があります。

• 商品マスタの属性体系
• 顧客セグメントの定義
• KPIの計算ロジック
• 過去のキャンペーン結果

これらは、AIが自社固有の判断をするために最も重要な「文脈」になります。データ基盤側でクエリ可能で、メタデータが整っているか——ここがデータエンジニアの腕の見せどころになります。

「Garbage In, Garbage Out」がAI時代に再来する

データの世界で半世紀以上言われてきた「Garbage In, Garbage Out（質の悪いデータからは質の悪い結果しか出ない）」。これがAIエージェント時代に再び重みを増しています。

AIがどれだけ賢くても、供給されるデータが汚れていれば出力も汚れます。データの品質・整合性・鮮度を担保する仕事は、AIエージェントの天井を決める仕事でもあるのです。

「AIに仕事を奪われる」のではありません。「AIに質の高い仕事をさせるのは、データに責任を持つ人の仕事」という時代になりました。

---

MCP（Model Context Protocol）とは何か、なぜ重要か

文脈エンジニアリングを実装する上で、もうひとつ知っておきたいのが MCP（Model Context Protocol） です。Anthropicが2024年末に提唱し、2025〜2026年で急速に普及しました。

MCPをひとことで言うと

AIモデルが外部ツールやデータソースに繋がるための、業界標準のプロトコル

エージェント世界の「USB-C」のような位置付けです。各サービス提供側がMCPサーバーを実装し、AIクライアント側はそれを統一的に呼び出せるようになります。

MCPには大きく2種類の提供物があります。

• Tools（ツール）：AIが呼び出せる関数（例：「SQLを実行する」「Issueを作成する」）
• Resources（リソース）：AIが読み取れるデータ（例：ファイルの内容、データベースのスキーマ）

データ系のMCPサーバーが続々登場

2026年5月時点で、データエンジニア向けに使えるMCPサーバーが揃ってきました。

• BigQuery MCP：スキーマ参照、クエリ実行
• Snowflake MCP：オブジェクト一覧、SQL実行
• Supabase / Neon / Postgres MCP：トランザクションDB接続
• dbt MCP：model一覧、ドキュメント参照、test実行
• Linear / Notion / GitHub MCP：プロジェクト管理連携

これらを使えば、「Claude Codeで作業しながら、自社データウェアハウスのスキーマを聞く」といったことが、追加のコードなしでできるようになります。

自社向けMCPサーバーを書くのもデータエンジニアの仕事に

商用MCPサーバーで足りない場合は、自社で書きます。社内のメタデータ管理ツール、独自のデータマート定義、KPI計算ロジックを持つ社内サービス——これらをMCPサーバーとして公開する仕事は、これからデータエンジニアの守備範囲に入っていくでしょう。

実装スキル自体は、APIサーバー実装、認証認可、レートリミット、スキーマ設計という、データエンジニアやバックエンドエンジニアの本業の延長線上にあります。

---

「文脈認識AI」と「文脈エンジニアリング」は別物

「文脈エンジン」「文脈AI」で検索すると、似て非なる2つの話題が混ざって出てきます。整理しておきます。

• 文脈認識AI（context-aware AI）：AI側の理解能力の話。チャットボットの会話文脈の追跡、代名詞の解決、長文読解能力など
• 文脈エンジニアリング（context engineering）：人間側の設計の話。AIに何をどう渡すかを設計する技術

両者は車の両輪です。AIの文脈認識能力が上がるほど、エンジニアリング側で渡せる情報の幅が広がる。設計が洗練されるほど、AIの能力が活きる。両方に注目しておくと、AI関連のニュースが立体的に理解できます。

---

明日から始められる5ステップ

「概念はわかった。でも何から始めればいい？」という方向けに、すぐに始められる5ステップを紹介します。

---

よくある質問

Q. プロンプトエンジニアリングはもう不要なの？

不要にはなりません。文脈エンジニアリングの中の「システムプロンプト設計」「Few-shot例の選定」「出力フォーマット指定」は、依然としてプロンプトの工夫が活きる領域です。プロンプトエンジニアリングは、文脈エンジニアリングという大きな枠の一部分として位置づけ直されたとイメージしてください。

Q. RAGとContext Engineeringの違いは？

RAGは文脈エンジニアリングの一手段です。文脈エンジニアリングはRAGに加えて、メモリ管理、ツール定義、Compaction、サブエージェントなど、より広い領域をカバーします。

Q. 小さなチームでも始められる？

むしろ小さなチームの方が始めやすいです。CLAUDE.md を書くだけでも効果は実感できます。MCPやマルチエージェントといった大掛かりな仕組みは、必要になったタイミングで導入すれば十分です。

Q. 何から学べばいい？

一次ソースを直接読むのが最短です。Anthropicのエンジニアリングブログ、Phil Schmid氏のブログ、LangChainの公式ブログは無料で読めます。日本語の解説記事と組み合わせると理解が深まります。

Q. 「Context Engineer」という職種はあるの？

2026年5月時点で独立した職種としては定着していませんが、AIエージェント開発を主業務とする企業では、データエンジニアやバックエンドエンジニアの職務に文脈設計が含まれるケースが増えています。今後数年で、専門職として定着する可能性は十分あります。

---

まとめ：文脈をデザインできる人がAI時代を動かす

文脈エンジニアリング（Context Engineering）は、プロンプトエンジニアリングの自然な進化です。AIエージェント時代に「思い通りに動かない」を減らすための、新しい必須スキルになりつつあります。

本記事のポイントを最後にもう一度まとめます。

「データを制する者がAI時代を制する」と言われた時代から、「文脈をデザインできる者がAI時代を動かす」時代へ。データに向き合ってきた経験は、新しい技術領域でそのまま武器になります。

この記事と一緒に読みたい

• データエンジニアのスキルセット
• dbt（Data Build Tool）とは

参考にした一次ソース

• Anthropic公式エンジニアリングブログ「Effective Context Engineering for AI Agents」（2025年9月）
• Philipp Schmid氏「The New Skill in AI is Not Prompting, It’s Context Engineering」（2025年6月）
• LangChain公式ブログ「Context Engineering for Agents」

Ｗｉｎスクール	【初心者向け】 ・20～30代におすすめ ・データ分析・AIに特化 公式サイトで無料登録する