Context Engineeringとは？AIエージェントに正しい文脈を渡す技術
Context Engineering（コンテキストエンジニアリング）とは、AIエージェントがタスクを解けるように、指示、履歴、外部データ、ツール、制約、出力形式を適切な順序と粒度で設計する技術です。AI CRMでは、顧客・案件・商品・見積・承認ルールを必要な範囲で渡す設計を指します。
Context Engineeringとは？AIエージェントに正しい文脈を渡す技術
Context Engineering（コンテキストエンジニアリング）とは、AIエージェントがタスクを解けるように、指示・履歴・外部データ・ツール・制約・出力形式といった文脈を、必要な範囲と粒度で組み立て、更新し、検証する設計の営みです。うまいプロンプトを一文書くことではなく、モデルが次の一手を出すために「何を、いつ、どの根拠で渡すか」を扱います。
「プロンプトをどれだけ工夫しても、AIの回答が安定しない」。「社内データをつないだのに、期待した営業判断をしてくれない」。この詰まりは、指示文の書き方をさらに磨いても抜けません。AIに足りないのは巧みな言い回しではなく、渡している文脈そのものの設計だからです。
2025年半ば以降、AIエージェントの議論の重心は「どのモデルを使うか」から「モデルに何をどう渡すか」へ動きました。その移動を一語で言い表したのがContext Engineeringです。営業・CRM・RevOpsの現場に引き寄せると、これは「AIが読める営業文脈をどう用意するか」という問いになります。
Executive Summary
- 論点の結論: Context Engineeringは、プロンプト術の延長ではなく、AIエージェントに渡す情報環境そのものを設計・更新・検証する実務として再定義されつつある。プロンプト作成はその一部でしかない。
- なぜ今か: コンテキストウィンドウ（AIが一度に読める入力量）を広げても、入力が長くなるほど精度が不均一に落ちる「context rot（文脈の劣化）」が実測で示された（Chroma, 2025）。詰め込めば賢くなるという前提が崩れた。
- 何が語られているか: Tobi LütkeとAndrej Karpathyの発信を起点に用語が広まり、Anthropicは curate（取捨選択）と maintain（維持）を軸に、Manusはキャッシュ・ファイル外部化・失敗履歴の保持を軸に、実装知見を公開している。
- CRM・営業・RevOpsへの示唆: 営業AIの品質は、顧客・案件・見積・承認ルール・過去対応という業務文脈を、タスクごとに過不足なく、根拠つきで渡せるかで決まる。文脈は多いほどよいのではなく、絞って検証できることが要点になる。
- 実装の要点: どの業務にどの文脈を渡すかを定義し、鮮度と権限を管理し、AIが何を根拠に答えたかを監査できる形にする。この設計を欠くと、AIは古い条件を自信満々に再利用する。
1. なぜ今、Context Engineeringが重要になったのか
きっかけは、一件のX投稿でした。Shopify CEOのTobi Lütke（トビ・リュトケ）が2025年6月に「prompt engineeringよりcontext engineeringという言葉が好きだ。中核スキルをよりよく表している——タスクをLLMが解けるだけの文脈をすべて用意する技術だ」と投稿し（@tobi, 2025）、数日後にAndrej Karpathy（アンドレイ・カルパシー）が「実運用のLLMアプリでは、context engineeringとは、次の一手に必要な情報だけでコンテキストウィンドウを満たす繊細な技術と科学だ」と応じました（@karpathy, 2025）。
用語が広まった背景には、実務側の手応えの変化があります。モデルはすでに十分賢いのに、業務に載せると失敗する。その失敗の多くが、モデルの知能ではなく、渡している文脈に起因していた——という感触です。
決定的だったのは、長い文脈が万能ではないと数値で示されたことです。Chromaの技術報告「Context Rot」（2025年）は、GPT-4.1・Claude 4・Gemini 2.5・Qwen3など18のモデルを対象に、入力が長くなるほど性能が不均一に劣化することを示しました。10,000トークン目を100トークン目と同じ精度で扱えるという前提は、実際には成り立たないという指摘です（Chroma, 2025）。
つまり、コンテキストウィンドウが広がったから安心して詰め込める、という話ではなくなった。何を入れ、何を入れないかの判断が、そのまま品質を左右するようになったのです。
2. Xと海外ブログで何が議論されているか
先端の発信を横断すると、論者はそれぞれ違う入口から語りながら、同じ一点に収束しています。エージェントの実力は、モデル単体ではなく、文脈の設計に強く左右される、という問題意識です。個別の投稿を市場全体の結論として扱わず、複数の発信に共通する論点として見ていきます。
- プロンプトは部分集合になった、という位置づけ: Philipp Schmidは「The New Skill in AI is Not Prompting, It's Context Engineering」（2025年6月30日）で、context engineeringを「適切な情報とツールを、適切な形式で、適切なタイミングで渡す動的なシステムを設計する営み」と定義し、静的な一文であるプロンプトとの違いを整理しています（Schmid, 2025）。
- curateとmaintainという設計動詞: Anthropicは「Effective context engineering for AI agents」（2025年9月29日）で、限られたコンテキストを「推論のあいだ最適なトークン集合に保つ」こととして定義し、長い会話を要約して再開するコンパクション、エージェントが文脈の外にノートを書き出す構造化ノートなどを紹介しています（Anthropic, 2025）。
- 本番運用からの実装知: Manusの Yichao "Peak" Ji は「Context Engineering for AI Agents: Lessons from Building Manus」（2025年7月18日）で、KVキャッシュのヒット率を最重要指標に置くこと、ツールを消さずマスクすること、ファイルシステムを外部メモリとして使うこと、失敗の履歴をあえて残すことなどを、実運用の教訓として挙げています（Ji, 2025）。
- 文脈は壊れる、という前提: Drew Breunig は「How Long Contexts Fail」（2025年6月22日）で、文脈が長くなると起きる失敗を、汚染・注意散漫・混乱・衝突の4類型に整理しました（Breunig, 2025）。Simon Willison もこの流れを追い、文脈を意図的に管理する必要性を論じています（Willison, 2025）。
論者の温度差はあります。それでも、プロンプトを磨く段階から、文脈を組み立てて壊れ方まで設計する段階へ、実務の関心が移ったことは共通しています。営業現場に置き換えれば、「AIに何を頼むか」より「AIに何を見せているか」を先に疑う、という順序の入れ替えです。
3. 技術的背景
3.1 文脈はなぜ壊れるのか
Breunig の整理をCRM実務の言葉に置き換えると、輪郭がはっきりします。
- 汚染（poisoning）: 誤った情報が一度文脈に入り、以後くり返し参照される。失効した価格をAIが「正しい前提」として使い続ける状態です。
- 注意散漫（distraction）: 文脈が長くなりすぎ、モデルが過去の履歴に引きずられて新しい判断を作れなくなる。
- 混乱（confusion）: 不要な情報やツールが多すぎて、関係のないものを根拠に低品質な回答を出す。
- 衝突（clash）: 文脈内の情報どうしが矛盾し、推論が破綻する。古い契約条件と新しい条件が同居している状態です。
Chromaの実測は、この直感に裏づけを与えます。距離の近い妨害情報（distractor）があるほど、また文脈が長いほど、単純なタスクでも精度が落ちる。長く入れれば入れるほど安全、という感覚は誤りだったわけです（Chroma, 2025）。
3.2 文脈を構成する要素
context engineeringが扱うのは、プロンプト一行ではありません。実運用では、次のような層が同時に文脈へ流れ込みます。
- システム指示（役割・制約・禁止事項）
- 直近の会話・作業履歴
- RAG（外部データを検索して回答に使う手法）で引いてきた文書
- 長期記憶（過去のやり取りや学習した業務文脈）
- ツール定義とその出力
- 出力フォーマットの指定
この層のどれを、どのタイミングで、どこまで載せるか。その取捨選択こそがcontext engineeringの実務です。すべてを常に渡すのではなく、いまのタスクに要るものだけを渡す。要素を並べただけでは足りず、「載せない」判断まで含めて初めて設計になります。
3.3 curate と maintain、二つの動き
Anthropicの整理が有用なのは、文脈設計を静的な準備ではなく、走りながら維持する営みとして描いた点です（Anthropic, 2025）。curateは、その瞬間に最適なトークン集合を選ぶ動き。maintainは、会話や作業が進むほど膨らむ文脈を、要約・外部化・整理で保ち続ける動き。
Manusがファイルシステムを外部メモリとして使い、大きな観測結果を文脈の外へ逃がすのも、この maintain の一形態です（Ji, 2025）。文脈は一度組めば終わりではなく、劣化を前提に手を入れ続ける対象だ、という前提がここにあります。
4. CRM・営業・RevOpsへの示唆
では、この論点は営業データを扱う現場で何を意味するのか。答えは素朴で、AIに渡す文脈は業務タスクごとに違う、という一点に尽きます。
見積対応でAIに要るのは、商品マスタ・価格表・過去見積・代理店条件・承認ルールです。問い合わせ分類なら、問い合わせ種別・過去対応・担当部門・緊急度の判断基準。営業レポートなら、指標定義・期間・担当者・チャネル・コンバージョン定義。同じ「顧客情報を渡す」でも、タスクが変われば必要な断面はまるで違います。
ここでchapter 3の失敗類型が効いてきます。営業文脈を無造作に全部渡すと、汚染（失効価格の再利用）、注意散漫（関係ない過去案件への固執）、衝突（新旧契約条件の混在）がそのまま起きる。文脈を絞ることは、品質と安全の両方の条件になります。
渡す関係の設計はコンテキストグラフとは？、指標定義をそろえる層はセマンティックレイヤーとは？、セッションをまたいで文脈を持ち越す部分はAgent Memoryとは？が扱う領域です。context engineeringは、これらを「いつ・どの粒度で使うか」に束ねる上位の設計だと捉えると、位置関係が整理しやすくなります。
RevOpsの観点で外せないのは、AIが何を根拠に答えたかを後から追えることです。参照した文脈が特定できなければ、人間レビューは形式だけになり、レポートの数字も再現できません。AIネイティブなCRMの全体像はAIネイティブCRMとは？、エージェントが営業を横断的に支える構図はAgentic CRMとは？で扱っています。
5. パートナー営業への応用
代理店・パートナーチャネルは、文脈設計の難しさが増幅される領域です。顧客接点がメーカーのCRMだけに閉じないからです。メーカー、一次代理店、二次代理店、エンド顧客、商品、見積、問い合わせ、契約条件が、複数の主体とシステムに分散します。
ここで効くのが文脈の分離です。ある代理店に関する情報を、別の代理店対応の文脈へ混ぜてはならない場面があります。価格条件や契約条件は特に、誰のための文脈かを区別できなければ、そのまま情報漏えいや誤提示につながります。「A代理店は短納期を重視する」「B社は商品Aを導入済み」といった手がかりは、権限の範囲内でのみ文脈へ載せるべきものです。
具体的な流れで考えると輪郭が出ます。代理店から見積依頼が届いたとき、AIは依頼文から顧客名・商品名・数量・希望納期を抽出し、その代理店・顧客に紐づく過去案件・過去見積・対応傾向だけを文脈へ集め、見積ドラフトと回答根拠を組み立てる。全社の情報を渡すのではなく、この案件に必要な断面だけを渡す。問い合わせ・見積からCRMへ文脈を還流する流れはSalesforceの活動履歴を自動化する方法でも扱っています。context engineeringは、その入口で「何を見せるか」を決める部分だと考えると、実装の順番が見えてきます。
6. 実装時の設計要件
自社でAIエージェントに営業文脈を渡すとき、最初から「何でも渡す」設計にすると、古い文脈や関係のない履歴まで混ざり、AIが誤った前提で答えるリスクが上がります。出発点は、どの業務判断を支援させるかを一つ決めることです。問い合わせ対応、見積対応、アカウント要約など、成果に近い業務から逆算して、渡す文脈を絞り込みます。
読者が自社で検討するときの観点を挙げます。
- 対象業務と文脈の対応づけ: タスクごとに、必要な情報・ツール・制約・出力形式を定義する。「見積対応にはこの5種類だけ」という粒度まで落とす。
- 参照するデータの範囲: 業務判断に必要で、鮮度と権限を管理できる情報に絞る。全文脈を毎回渡す設計を避ける。
- 鮮度と更新: 失効価格・終了商品・古い担当者情報を更新・削除する仕組みを持つ。載せない・忘れる設計を、載せる設計と同じ重みで扱う。
- 参照権限と分離: 顧客・代理店・価格・契約条件の文脈を、誰の対応で参照してよいかを制御する。代理店ごとの文脈分離を設計に組み込む。
- CRM双方向連携: AIが参照する文脈と、人間レビューを経た結果の還流を、CRM/SFAと二重管理にしない。活動履歴・案件・見積として書き戻す。
- 根拠と監査: AIがどの文脈を根拠に下書きを作ったかを残す。見積・価格・契約条件は誤回答リスクが高く、回答根拠の表示・人間レビュー・承認・監査ログをセットにする。
この6つのうち、初期設計で外せないのは対象業務と文脈の対応づけ、参照権限と分離、根拠と監査の3点です。鮮度やCRM連携は運用で厚くできますが、この3点を後回しにすると、AIが「誰の、いつの、何を根拠にした回答か」を説明できないまま走り出します。統制の考え方はエンタープライズAIエージェントとは？、レビューの必要性はAI見積に人間レビューが必要な理由で詳しく述べています。
7. 導入時の注意点
- 多いほどよい、ではない: 文脈を増やせば賢くなるわけではありません。長くなるほど精度は不均一に落ちます（Chroma, 2025）。渡して意味のある文脈に絞ることが品質の条件です。
- プロンプト改善で止めない: 回答が安定しないとき、まず疑うのは指示文ではなく、渡している文脈の中身と鮮度です。汚染・衝突が起きていないかを見ます。
- 壊れ方を前提に運用する: 文脈は一度組んで終わりではなく、劣化します。要約・外部化・整理を続ける運用を前提にします。
- ベンチマークを鵜呑みにしない: 公開されている削減率や精度改善の数値は条件依存です。自社データ・自社の問いで再現するかは、小さなPoCで確かめてください。
よくある質問（FAQ）
Context Engineeringとは何ですか？
Context Engineeringとは、AIエージェントがタスクを解けるように、指示・履歴・外部データ・ツール・制約・出力形式といった文脈を、必要な範囲と粒度で組み立て、更新し、検証する設計の営みです。単発のプロンプトではなく、AIに渡す情報環境全体を扱います。
Prompt Engineeringとの違いは何ですか？
Prompt Engineeringは指示文を改善する技術で、いまも有効です。Context Engineeringは、その指示文に加えて、CRMデータ・検索結果・記憶・ツール・権限・出力形式まで含めて動的に設計する点が異なります。近年の議論では、プロンプト作成はcontext engineeringの一部と位置づけられています。
コンテキストは多いほど精度が上がりますか？
上がりません。Chromaの技術報告（2025年）は、入力が長くなるほど性能が不均一に劣化することを示しています。不要な情報や古い情報が混ざると判断がぶれるため、タスクに必要な文脈を根拠つきで渡すことが重要です。
AI CRMでContext Engineeringはなぜ重要ですか？
顧客・案件・商品・見積・承認ルールといった業務文脈がなければ、AIは実務に使える判断をしにくいからです。加えて、どの文脈を根拠にしたかを残せることが、人間レビューと監査、そしてレポートの再現性を支えます。
参考文献・一次情報
- Tobi Lütke（Shopify CEO）X投稿 2025-06-19 https://x.com/tobi/status/1935533422589399127
- Andrej Karpathy X投稿 2025-06-25 https://x.com/karpathy/status/1937902205765607626
- Philipp Schmid「The New Skill in AI is Not Prompting, It's Context Engineering」2025-06-30 https://www.philschmid.de/context-engineering
- Anthropic「Effective context engineering for AI agents」2025-09-29 https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- Yichao "Peak" Ji（Manus）「Context Engineering for AI Agents: Lessons from Building Manus」2025-07-18 https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus
- Drew Breunig「How Long Contexts Fail」2025-06-22 https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html
- Chroma Research「Context Rot: How Increasing Input Tokens Impacts LLM Performance」2025 https://research.trychroma.com/context-rot
- Simon Willison「Context engineering」2025-06-27 https://simonwillison.net/2025/Jun/27/context-engineering/
※本文中の性能劣化・トークン・精度に関する記述は各出典の検証条件下での結果であり、モデルやデータが変われば再現性は異なります。自社データでの検証を前提にご参照ください。
Hiwayで営業文脈をAIが読める形にする
Hiwayは、代理店や顧客からの問い合わせ・見積依頼をAIが一次処理し、人間レビューを経た結果をCRMへ還流するAIネイティブCRMです。タスクに必要な文脈だけをAIに渡し、回答根拠の表示・人間レビュー・承認・監査ログを組み込むことで、AIに任せきりにしない営業文脈を蓄積できます。
単なる代理店管理CRMではなく、AIが安全に読み解ける営業文脈（System of Context）をどう設計するか。Context Engineeringは、その入口で「何を、いつ、どの根拠で渡すか」を決める中核の考え方です。