コンテキストエンジニアリングとは｜プロンプトの次に来る設計の基本

「良いプロンプトを書く」だけでは、複数ステップで動くAIエージェントの品質を安定させにくくなってきました。エージェントは1回のやり取りで終わらず、ツールの実行結果や過去の履歴をどんどん抱えていきます。そこで重要になるのが、モデルに渡すコンテキスト全体をどう設計するか、という視点です。この記事では、プロンプトエンジニアリングの発展形として語られる「コンテキストエンジニアリング」の考え方を、実務で使える形に整理します。

プロンプトから、コンテキストへ#

プロンプトエンジニアリングは「どう書くか」に焦点がありました。コンテキストエンジニアリングはもう一段広く、システム指示・ツール定義・外部データ・過去のメッセージ履歴まで含めた、モデルが読む情報の状態全体を対象にします。エージェントが何ターンも動く間、絶えず増えていくデータの中から関連する情報だけを残し続ける、反復的な作業だと考えると分かりやすいです。

前提となる「コンテキストの劣化」#

コンテキストエンジニアリングが必要になる根っこには、context rot(コンテキストの劣化)という現象があります。渡すトークンが増えるほど、モデルが情報を正確に思い出す力は下がっていきます。これはモデルの手抜きではなく、すべてのトークンが互いに関係を計算し合うアーキテクチャ上の制約から来るものです。

ここから導かれる原則はシンプルです。多く詰め込むほど良いのではなく、望ましい振る舞いを引き出す、情報量の多い最小限のトークン群を探す。これがコンテキストエンジニアリングの目標になります。

何を、どの順で渡すか#

渡す情報は、おおまかに次の順で構成すると整理しやすくなります。

例示について補足すると、想定される例外を延々と並べるより、代表的なパターンを少数そろえるほうが効きます。良い例は、長い説明文に勝る見本になります。

必要なときに取りに行く#

コンテキストを軽く保つ有効な考え方が、都度取得(just-in-time)です。関連データを最初から全部プロンプトに載せるのではなく、ファイルパス・検索クエリ・URLといった軽い参照だけを持たせ、実行時にツール経由で必要な分だけ読み込ませます。ファイルの階層構造や命名規則そのものが、エージェントにとっての手がかりになります。RAGで外部知識を渡す設計とも地続きの発想です。

長時間動くエージェントの手法#

タスクが長く続き、コンテキストの上限が見えてくると、次のような手法で文脈を絞り続けます。

どれを使うかはタスクの性質で決まります。対話の継続性が大事なら圧縮、反復的な開発ならメモ、複雑な分析の分担ならサブエージェント、という使い分けが目安です。

実務での始め方#

考え方は、最小のコンテキストから始め、観測された失敗モードに応じて段階的に足していくことです。先に作り込むのではなく、実際の失敗を見てから必要な要素を加えます。相談役の上位モデルに方針だけ委ねるといった構成も、コンテキスト設計の一つの形です。

よくある質問#

まとめ#

コンテキストエンジニアリングは、特定のモデルや流行に依存しない、息の長い設計スキルです。プロンプトの書き方を磨くのと並行して、モデルに何を見せるかを設計する視点を持っておくと、エージェントの品質を安定させやすくなります。まずは手元のエージェントのコンテキストを一度書き出し、削れる情報がないかを見直すところから始めてみてください。