はじめに
これまでの記事で、AIエージェントの実力はHarness、Loop、Evaluationという仕組みの組み合わせで決まる、という話をしてきました。
今回はもう一つ、地味なようでいて実は結果を大きく左右するテーマ、Context Engineeringを取り上げます。
AIがどれだけ賢くても、判断材料になる情報が適切に渡されていなければ、見当違いの答えを出してしまいます。逆に、必要な情報を必要なタイミングで渡せていれば、モデル自体を変えなくても出力の質がぐっと上がることがあります。今回は、この「何を見せるか」の設計について整理してみます。
1. Context Engineeringとは何か
Context Engineeringとは、AIが判断を下すために必要な情報を、どのタイミングで、どんな形で提供するかを設計することです。
プロンプトエンジニアリングと混同されがちですが、少し役割が違います。プロンプトは「何を指示するか」であるのに対し、Contextは「その指示を実行するために、どんな情報が手元にあるか」という土台の部分にあたります。
同じ指示を出しても、参照できる情報が違えば、AIの出力は大きく変わります。Context Engineeringは、この「参照できる情報」そのものを設計する仕事です。
2. なぜコンテキストが重要なのか
AIエージェントに複雑なタスクを任せるとき、必要な知識がすべてモデルの内部に入っているわけではありません。
社内の仕様、プロジェクト固有のルール、過去のやり取り、最新のドキュメント。こうした情報は、モデルの学習データには含まれていません。適切なコンテキストとして渡してあげないと、AIは推測や一般論で埋め合わせるしかなく、結果として的外れな出力になりがちです。
逆に言えば、モデル自体を変更しなくても、渡すコンテキストの質を上げるだけで、出力の精度が目に見えて改善することがあります。これがContext Engineeringが注目される理由です。
3. 「とにかく大量に渡す」は正解ではない
コンテキストと聞くと、情報をできるだけたくさん渡したほうがいい、と考えてしまいがちです。しかし実際には、それほど単純な話ではありません。
情報量が多すぎると、AIが本当に重要な部分を見失ってしまうことがあります。関係のない情報が混ざっていると、判断の精度がかえって落ちることも珍しくありません。いわゆるコンテキスト汚染と呼ばれる状態です。
大切なのは、その時点のタスクにとって本当に必要な情報だけを、適切な粒度で渡すことです。量よりも、選び方の質が問われる領域だと感じています。
4. コンテキストの種類
ひとくちにコンテキストと言っても、性質の異なるいくつかの種類があります。
まず静的な情報です。プロジェクトの仕様書、コーディングルール、ドキュメントなど、頻繁には変わらない情報がここに含まれます。
次に動的な情報です。現在のタスクの状態、直近の実行結果、エラーログなど、そのときどきで変化する情報です。
さらに履歴情報です。これまでのやり取りや過去の実行結果の積み重ねで、セッションをまたいで参照したいものが含まれます。
そして外部情報です。検索結果やAPIのレスポンスなど、リアルタイムに取得する必要がある情報です。
これらをひとまとめに扱うのではなく、性質ごとに分けて管理すると、必要なときに必要な種類の情報だけを取り出しやすくなります。
5. Retrievalという考え方
コンテキストとして渡す情報量には限りがあるため、必要な情報をその都度取り出してくる仕組みが重要になります。これがRetrievalです。
すべての情報を常に渡すのではなく、そのタスクに関連しそうな情報だけを検索し、必要な分だけをコンテキストに含める。この考え方があるおかげで、限られた枠の中で、より的確な判断材料をAIに渡せるようになります。
Retrievalの精度が低いと、関係のない情報ばかりが混ざってしまい、逆に精度が高すぎて絞り込みすぎると、必要な情報が漏れてしまうこともあります。このバランスの取り方も、Context Engineeringの重要な部分です。
6. コンテキストウィンドウという制約
コンテキストには物理的な上限、いわゆるコンテキストウィンドウがあります。この枠の中に収まる範囲でしか、情報を渡すことはできません。
長期的なタスクになるほど、蓄積される情報量は増えていきます。すべてをそのままウィンドウに詰め込もうとすると、あっという間に上限に達してしまいます。
そこで重要になるのが、情報を要約する、古い情報を圧縮する、重要度の低い情報を落とす、といった工夫です。これは後述するMemoryの設計とも関わってくる部分です。
7. リポジトリを例に考える
具体的なイメージを持つために、ソフトウェア開発を例に考えてみます。
コーディングエージェントに何かを依頼するとき、必要になりそうなコンテキストは次のようなものです。
Repository
├── README
├── Architecture
├── Coding Rules
├── Source Code
├── Tests
└── Previous Errors
READMEはプロジェクトの全体像を、Architectureは構造上の前提を、Coding Rulesはチームの規約を伝えます。Source Codeは実際に変更すべき対象そのものであり、Testsは期待される振る舞いを示しています。Previous Errorsは、過去に何が失敗したのかという文脈です。
これらすべてを毎回丸ごと渡す必要はありません。今回のタスクに関連する部分だけを、適切なタイミングで渡せるように設計しておくことが、Context Engineeringの実践的な部分になります。
8. MemoryとContextの違い
似た言葉として、Memoryとの違いがよく話題になります。
Memoryは、情報をどう保存し、どう引き出すかという仕組み全体を指します。一方でContextは、その中から実際にAIへ渡される、今この瞬間の判断材料を指します。
イメージとしては、Memoryが図書館のような蓄積された知識の倉庫だとすると、Contextはそこから今回のタスクのために借りてきた、手元に置く本のようなものです。Memoryの設計が優れていても、Contextとしての渡し方が雑であれば、AIはうまく活用できません。この2つは別々のようでいて、セットで考える必要がある領域です。
9. コンテキスト設計の実践的なポイント
実際に設計するとき、意識しておきたいポイントをいくつか挙げます。
まず、タスクの種類ごとに必要なコンテキストを整理しておくことです。すべてのタスクに同じ情報を渡すのではなく、タスクの性質に応じて渡す情報を変える発想が有効です。
次に、情報の鮮度を意識することです。古い情報がそのまま残っていると、AIが誤った前提で判断してしまうことがあります。
そして、情報の優先順位をつけることです。すべてを平等に扱うのではなく、重要な情報ほど目立つ位置や早いタイミングで渡すようにすると、AIがそれを見落としにくくなります。
10. まとめ
Context Engineeringは、AIに何を見せるかを設計する仕事です。プロンプトをどれだけ工夫しても、判断材料そのものが不十分であったり、逆に情報過多であったりすれば、出力の質は安定しません。
静的な情報と動的な情報を整理し、Retrievalによって必要な情報だけを取り出し、コンテキストウィンドウという制約の中で優先順位をつけて渡していく。この積み重ねが、AIエージェントの判断精度を大きく左右します。
モデルを交換しても、Harnessを整えても、コンテキストの設計が雑なままでは、AIは本来の実力を発揮できません。地味に見えて、実は成果に直結する領域だと感じています。
次回は、AIが実際に行動するための手段、Tool Engineeringについて掘り下げていきます。
関連記事
- AIエージェントで本当に重要なのはLLMではない？Harness EngineeringとLoop Engineeringから考える次世代AI開発（全体像）
- Harness Engineeringとは何か？AIエージェントの性能を決める「実行環境」の設計
- Loop Engineeringとは何か？AIエージェントを「失敗から改善するシステム」に変える方法
- AIエージェントの評価（Evaluation）設計入門
- AIエージェントのTool Engineering入門（次回予定）
Tags
AI AIエージェント ContextEngineering LLM AgenticAI