プロンプトより先に整えるもの。Context Engineering入門

コンテキストエンジニアリングとは、AIに答えさせるたびに、渡す情報(指示・知識・これまでのやり取り)を選び直す作業のことです。プロンプトエンジニアリングが言葉選びを一度整える作業なのに対し、コンテキストエンジニアリングは会話やタスクが進むごとに、何を渡し何を渡さないかを選び直す継続的な設計です。情報を増やすほど答えが良くなるわけではなく、厳選された少ない情報のほうが正確な答えを引き出します。

要点(TL;DR)

• コンテキストエンジニアリング = 推論のたびに、AIへ渡す情報を選び直す作業
• プロンプトエンジニアリングは言葉選びを一度整える作業。コンテキストエンジニアリングは、会話が進むたびに渡す情報を選び直す継続作業
• AIに渡す情報は4つに分かれる。指示・ツールと知識・履歴・出力の型
• 情報を増やすほど答えが良くなるわけではない。渡す情報が多いほどAIの注意が散り、答えが粗くなる
• 経営者が最初にやることは、プロンプトを書き直すことではなく、AIに何を読ませているかを書き出すこと

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

コンテキストエンジニアリングとは、AIに一つの答えを出させるたびに、モデルへ渡す情報の集合を、その時点で最も効くように選び整える作業です。Anthropicはこれを「推論時にモデルへ渡す最適なトークン(情報)の集合を、選び保つための戦略群」と定義し、プロンプトエンジニアリングの自然な延長にあるものとして位置づけています。

言葉を工夫することと、渡す情報を選ぶことは、別の作業です。同じ質問文でも、渡す情報が違えば答えは変わります。AIに聞いても的外れな答えが返ってくるとき、多くの経営者はプロンプトの言い回しを直そうとします。しかし実際に効いているのは、言い回しよりも、AIが参照できる情報の質と量です。ここを分けて考えないと、「AIは賢くなったのに、うちの業務には使えない」という誤解から抜け出せません。

整える対象は、4つに分けられる

AIに渡す情報は、大きく4つに分かれます。指示(何をしてほしいか、守るべき条件)、ツールと知識(検索・社内資料・外部サービスなど、参照し実行できるもの)、履歴(これまでの会話や作業でわかった状態)、出力の型(どう返してほしいか)です。Anthropicも、エージェントを長く動かすには、指示・ツール・外部データ・会話履歴を含む「文脈全体の状態」を管理する必要があると述べています。

この4つのうち、経営者が最初に投資すべきはツールと知識です。指示は書き直せば済みますが、AIが参照できる自社の判断や資料がなければ、指示をどれだけ練っても一般論しか返ってきません。日々の業務で使う判断基準・過去のやり取り・禁止事項を編纂したナレッジDBが、この層の実体です。AIエージェントとは何かで扱った「記憶」の話と、ここは同じ土台を指しています。

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

プロンプトエンジニアリングとコンテキストエンジニアリングは、対象とする範囲と作業の頻度が違います。LangChainのHarrison Chaseは、コンテキストエンジニアリングを「LLMがタスクを遂行できるよう、正しい情報とツールを正しい形式で渡す、動的なシステムを構築すること」と定義し、プロンプトエンジニアリングはその一部だと位置づけています。プロンプトは一度作れば使い回せますが、渡す情報は毎回組み替える必要があります。

具体的な違いを整理すると、次のようになります。

プロンプトを工夫しても答えが安定しない場合、原因はほとんど言い回しではありません。AIが毎回何を読んで答えているかを見ていない、という点にあります。言葉を磨く前に、渡している情報そのものを疑うのが正しい順序です。

「情報を増やす」ほど、答えが粗くなる理由

AIに渡す情報を増やすほど、答えが良くなるわけではありません。Anthropicは、コンテキストウィンドウに入るトークン数が増えるほど、モデルが文脈から正確に情報を取り出す力は下がると指摘しています。これはモデルの手抜きではなく、トークン同士の関係がトークン数の2乗で増えていく構造上の限界です。情報を詰め込むほど、モデルの注意はどこに何が書いてあるかの特定に奪われ、肝心な判断に回す分が減ります。

だから、AIに渡す情報は「多いほど良い」ではなく、希少な資源として扱うのが正しい向き合い方です。関係のある資料を全部貼り付けるのではなく、その一回の判断に必要な、密度の高い情報だけを厳選して渡す。散らかった社内資料をそのまま渡すより、判断基準・禁止事項・過去のやり取りを編纂したナレッジDBから必要な部分だけを渡すほうが、同じモデルでも答えの質は上がります。社内資料をAIに読ませる設計そのものの限界は、RAGの限界と設計で扱っています。

日本の1人社長・マイクロチームでは、何が違うのか

大企業のコンテキスト設計と、1人社長・マイクロチームのそれは、抱える難しさが違います。大企業では、渡すべき情報が部署ごとに分散し、まず「誰が何を知っているか」を集める段階に時間がかかります。1人社長やマイクロチームでは、判断のほとんどが経営者一人の頭の中にあります。集める相手が少ないぶん、渡すべき情報を洗い出すところまでは早く着手できます。

一方で、その情報が個人の頭の中にしかなく、書き出されていないという固有の壁があります。忙しい経営者ほど、AIに何を渡すかを整理する時間を後回しにしがちです。結果として、AIには言い回しの良いプロンプトだけが渡り、判断の根拠になる情報は渡らない、という状態が続きます。予算をかけて高性能なモデルに切り替えても、渡す情報が空のままでは、答えの質は変わりません。小さな会社にとってのコンテキストエンジニアリングは、システムを組む話である前に、頭の中にある判断をいったん書き出す作業です。

何から、整え始めればいいのか

最初にやることは、プロンプトを書き直すことではありません。今、AIに何を渡しているかを書き出すことです。具体的には、まず一つの業務を選び、その業務でAIに答えさせるとき、指示文以外に何を読ませているか(社内資料・過去のやり取り・何も渡していない、のどれか)を確認します。次に、その中で答えの質に直結している情報と、なくても困らない情報を仕分けます。

仕分けが終われば、渡す情報を絞り込みます。関係資料を全部貼るのではなく、その判断に必要な部分だけに削る。ここで初めて、指示文の言い回しを整えます。順序を逆にして言い回しから始めると、渡す情報が空のまま言葉だけを磨くことになり、時間をかけても答えは変わりません。渡すべき情報をどこに溜めておくかという設計は、1人社長のナレッジDB設計で具体的に扱います。

自社のどの業務から始めるべきか、今使っているツールにどう組み込むかは、業務の中身によって変わります。今の運用を見せていただければ、渡すべき情報の洗い出しから一緒に整理できます。

よくある質問(FAQ)

Q. コンテキストエンジニアリングとは何ですか? A. 推論のたびにAIへ渡す情報(指示・知識・これまでのやり取り)を、目的に対して最も効くように選び整える作業です。プロンプトの言葉選びだけでなく、何を参照させ、何を渡さないかまで含みます。

Q. プロンプトエンジニアリングと何が違うのですか? A. プロンプトエンジニアリングは言葉選びを一度整える作業、コンテキストエンジニアリングは会話やタスクが進むたびに渡す情報を選び直す継続的な作業です。対象がプロンプト単体から、システム全体に渡す情報へ広がります。

Q. 情報を増やせば増やすほど、AIの回答は良くなりますか? A. なりません。渡す情報が増えるほどAIの注意が散り、肝心な部分を取りこぼす現象が起きます。厳選された少ない情報のほうが、雑多な大量の情報より正確な答えを引き出します。

Q. 小さな会社でもコンテキストエンジニアリングは必要ですか? A. 必要です。大きな仕組みを組む必要はなく、AIに毎回何を読ませているかを書き出し、削れるものを削るだけで始められます。判断が一人に集まっている小さな会社ほど、整理の効果が出やすい構造です。

---

出典・参考

• Anthropic「Effective context engineering for AI agents」: コンテキストエンジニアリングを「推論時にモデルへ渡す最適なトークン集合を選び、保つための戦略群」と定義し、プロンプトエンジニアリングの自然な延長と位置づける。トークン数が増えるほど文脈から正確に想起する力が下がる現象を、トークン同士のn²の関係から説明 — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• LangChain(Harrison Chase)「The rise of context engineering」(2025-06-23): コンテキストエンジニアリングを「LLMがタスクを遂行できるよう、正しい情報とツールを正しい形式で渡す動的なシステムを構築すること」と定義し、プロンプトエンジニアリングをその一部として位置づける — https://www.langchain.com/blog/the-rise-of-context-engineering

監修: Kazuya Hibara(Automate & Augment 代表) — 業務フロー再設計とAIエージェント運用を専門とする。