コンテキストエンジニアリングとは何か・「何を書くか」より「何を見せ続けるか」

プロンプトエンジニアリングの記事では、1回の指示に潜む曖昧さを潰す技術を見てきました。コンテキストエンジニアリングは、その延長線上でもっと難しい話になったものだろうと思うかもしれませんが、実際には位置づけが逆です。AIエージェントの研究者Andrej Karpathy氏は、コンテキストエンジニアリングを「次の一手のために、コンテキストウィンドウをちょうど良い情報で満たす、繊細な技芸と科学」と表現しており、Anthropicも2025年9月にこの概念を「プロンプトエンジニアリングの自然な発展形」として体系立てて説明しています。プロンプトの書き方は、この大きな枠組みの中のごく一部でしかありません。

プロンプトエンジニアリングの延長ではなく、それを包み込む上位の考え方

コンテキストエンジニアリングと聞くと、プロンプトエンジニアリングをさらに複雑にした上級編のようなものを想像するかもしれませんが、実際の力点の置き方はむしろ逆です。本番で動いているAIエージェントがそのとき参照しているのは、開発者が最初に書いた指示文だけではありません。これまでの会話履歴、ツールを実行した結果、読み込んだファイルの中身、途中で発生したエラーメッセージまで、次の一手を判断するために今まさにウィンドウに詰め込まれている情報全部です。良いプロンプトを書くことは、この巨大な情報全体の中のごく一部を占めているにすぎません。

# あるコーディングエージェントの、ある時点でのコンテキストウィンドウの中身(イメージ)
[1] システムプロンプト(エージェントの基本的な振る舞いの指示)
[2] プロジェクト固有のルールファイル(CLAUDE.mdなど)
[3] これまでの会話履歴(ユーザーの指示とエージェントの応答)
[4] 直前に実行したツールの結果(ファイル読み込み・コマンド実行の出力)
[5] 今回のユーザーの新しい指示

# プロンプトエンジニアリングが扱うのは主に[5]の書き方
# コンテキストエンジニアリングは[1]〜[5]全体の設計を扱う

🎯 読み解きポイント：話し方の練習ではなく、会議室に持ち込む資料そのものの取捨選択

プロンプトエンジニアリングが「会議でどう発言するか」の話し方の練習だとすると、コンテキストエンジニアリングは「その会議室にそもそも何の資料を持ち込むか」を決める仕事です。話し方がどれだけ上手くても、机の上に無関係な資料や古い議事録が山積みになっていれば、肝心の資料に気づいてもらえません。コンテキストエンジニアリングは、発言の練習よりも先に、机の上に何を置き、何を置かないかを決める作業だと考えると位置づけが掴みやすくなります。

「コンテキストロット」という、満杯になる前から始まる劣化現象

コンテキストウィンドウは、上限まで使い切って初めて性能が落ち始めるものだろうと思うかもしれませんが、実際にはもっと早い段階から劣化が始まります。これは「コンテキストロット(context rot)」と呼ばれる現象で、会話が長くなるにつれて、古い会話履歴・失敗した試行錯誤の跡・ツールの出力といったノイズが蓄積し、重要な情報が埋もれていくことで起こります。Chromaが2025年に18のフロンティアモデルを対象に行った調査では、コンテキストが伸びるあらゆる段階で性能劣化が確認されています。これはプロンプトエンジニアリングの記事で見た「Lost in the Middle」と同じ根っこの現象で、同調査では重要な情報が会話の中盤に埋もれることで精度が30%以上落ちるケースも報告されています。

# コンパクション(要約による圧縮)のイメージ
会話が長くなり、コンテキストウィンドウの残量が少なくなってきた

  → 古い会話履歴を、重要な決定事項・現在のタスク状態・
    次にやることだけを残した要約に置き換える
  → コンテキストウィンドウの使用量が一気に下がる
  → 圧縮された状態で作業を継続する

# 例: Claude Codeはコンテキスト使用量が95%に達すると自動でコンパクションを行う

🎯 読み解きポイント：机が書類で埋まる前に、要点だけメモに起こして束ねる

作業机の上に、これまでのメモや資料がどんどん積み上がっていく様子を想像してください。机が完全に埋まりきってから片付けを始めるのではなく、書類が積み上がってきた時点で、重要な決定事項だけを1枚のメモにまとめ直し、元の書類は片付けてしまう方が、机の上を常に使いやすい状態に保てます。コンパクションはこの「書類が積み上がってきた段階で、要点だけのメモに束ね直す」という片付け方を、会話履歴に対して行う仕組みです。

よくあるはまりポイント：「とりあえず全部見せておけば安全」という判断が精度を下げる

AIに判断を誤ってほしくないなら、関連しそうな情報は多めに全部コンテキストに入れておく方が安全だろうと思うかもしれませんが、これは実際には逆効果になりがちです。無関係な情報や、探索の過程で出た試行錯誤の跡までそのまま残しておくと、ノイズが本来伝えたい指示と競合し、コンテキストロットを早めてしまいます。実務でよく使われる対策は、ファイルを大量に読み込むような探索作業を専用のサブエージェントに任せ、そのサブエージェント自身のコンテキストウィンドウの中で試行錯誤を完結させ、親のエージェントにはファイルパスや行範囲といった「精製された結果」だけを返す、という設計です。探索の過程そのものは親のコンテキストに残さないようにすることで、ノイズの蓄積を防ぎます。

あわせて知っておきたい用語

コンテキストロット(context rot): 会話や作業が長くなるにつれ、ノイズの蓄積によって出力品質が徐々に劣化する現象。上限に達する前から始まる
コンパクション: 会話履歴の一部を、重要な情報だけを残した要約に置き換えて圧縮する技術。Claude Codeは容量95%で自動的に行う
サブエージェントによるコンテキスト分離: 探索や試行錯誤を専用のサブエージェントに任せ、その過程を親のコンテキストに残さず、精製された結果だけを受け取る設計

💡 ワンポイントアドバイス：フェーズの切れ目でコンパクションを能動的に行う

コンテキストロットは劣化に気づいてから対処するのでは遅く、明らかな劣化に気づく前に手を打つのが基本です。調査から実装へ切り替わるタイミングや、1つの機能の作業が終わって次の機能に移るタイミングなど、作業のフェーズが変わる節目は、コンパクションを能動的に行う良いきっかけになります。

「何を見せ続けるか」という視点が掴めたら、AIに繰り返し作業をさせる「ループエンジニアリング」も見てみると理解が深まります。(シリーズ一覧・プロンプトエンジニアリング・ループエンジニアリング・グラフエンジニアリング)