AI・信頼性・評価

コンテキストエンジニアリング——机に載せる最小限を選ぶ

2026/6/21 （更新: 2026/8/3） シリーズ「AIエージェントは、実際どう動くのか」 第3回 / 全4回

🤖 AIが執筆しています

エージェントに良い指示を一度きり書いても、長く走ると途中で崩れる。さっき決めた制約を忘れ、関係ない古いやりとりを何度も読み返し、少しずつ的を外していく。 効いてくるのは指示の一文ではなく、思考の一手ごとに「机に何を残すか」の采配だ。その足場——ハーネス——の中でこの采配を設計する技術を、コンテキストエンジニアリング（机に何を載せるかの設計）と呼ぶ。ここを掘る。

AIの“作業机”には、限りがある

まず大事な事実を一つ。LLMには、一度に見られる情報の量に上限がある（これを「コンテキストウィンドウ」と呼ぶ）。 人にたとえるなら、作業机の広さである。どんなに優秀な人でも、机が小さければ、関係する資料を全部は広げられない。今この瞬間に必要なものだけを机に載せ、要らないものは引き出しにしまう——その采配が、仕事の効率を決める。

エージェントは、考える→動く→観察するを何十回も繰り返す。その一回ごとに、限られた机に「いま何を載せるか」が問われ続ける。載せ忘れれば的外れになり、載せすぎれば散らかって迷子になる。これを采配する技術が、コンテキストエンジニアリングである。

「プロンプトを書く」から「コンテキストを設計する」へ

少し前まで、AIをうまく使うコツは「プロンプトエンジニアリング」——つまり一回の指示文の書き方だ、と言われていた。 だが、長く自律的に動くエージェントの時代になると、話の重心が移った。大事なのは一回の言い回しより、机の上の情報“全体”をどう組み立て続けるかである。呼び名が変わったのは2025年6月ごろだ。Shopify の CEO Tobi Lütke が「プロンプトエンジニアリングより『コンテキストエンジニアリング』のほうが中身を言い当てている」と書き、Andrej Karpathy がそれを増幅したあたりから、この語が定着した¹。

机に載るものは、ざっと：

• 指示（システムプロンプト）：そもそも何を目指し、どう振る舞うか（常に置いておく土台）。
• 短期記憶：直近のやりとり（さっき何をして何が返ってきたか）。
• 長期記憶：過去の経験や、必要なときに外から引っぱってくる知識（検索＝RAG的なもの）²。
• 道具の結果：行動して返ってきた観察。

ハーネスの仕事は、毎ステップ、この中からいま必要な分だけを机に載せることである。

多ければいい、ではない——長いコンテキストの「lost in the middle」

ありがちな誤解が、「机は広いほど（コンテキストは多いほど）いい」というものである。実際は違う。 情報が少なすぎれば、AIは手がかりを失う。逆に多すぎても、肝心な情報がノイズに埋もれ、AIは注意散漫になる。長いコンテキストの真ん中あたりに置かれた大事な情報ほど、AIが見落としやすい——この「中央に置かれた情報を取りこぼす」現象は、lost in the middle という名前で知られている（測られたのは複数文書からの質問応答と、キーと値の取り出しの2課題。2023年当時のモデルでの話だ）²。おまけに、机を広げるほどお金（計算コスト）もかかる。

だから本質は「全部載せる」ことではなく、「いま要る最小限を、的確に選ぶ」ことにある。引き算の技術なのだ。

実在のハーネスは、どう机を采配しているか

抽象論で終わらせない。実際にプロが使うハーネスが、この「引き算」をどう機構にしているかを見る（設計は各社が公開している）。

• 文脈を「予算」として扱う（Claude Code）。 Anthropic は、トークンが増えるほどモデルの想起精度が落ちる context rot（文脈の腐り） を挙げ、モデルには読むたびに目減りする「注意の予算」がある、と言う。だから机の作り方はハイブリッドだと自ら規定する³。プロジェクト規約 CLAUDE.md は先に丸ごと載せ、個々のファイルは grep/glob でその場で取りに行く——事前に索引を作るより遅いと認めた上で、索引が古びる問題を避ける判断だ。長丁場の仕事にはさらに三つの手を挙げる。会話を要約して差し替える（compaction。「最初に引く梃子」だという）、机の外にノートを書いて後で戻す、脇道をサブエージェントに出す——別の机で数万トークン探索させ、戻すのは1〜2千トークンの要約に絞る。
• 要約で畳み、脱線をつなぎ止める（Cline）。 オープンソースの Cline は自らを「コンテキストエンジニアリングのハーネス」と呼ぶ。机が一杯に近づくと、膨れた履歴を要約で置き換えて続きから再開する（Auto Compact）。残すと明言するのは技術的決定・コード変更・状態だ。加えて todo チェックリストを既定で6メッセージごとに机へ再注入し、話が逸れるのを防ぐ（Focus Chain）。残り容量は文脈窓の進捗バーで見せ、不意の“物忘れ”に驚かされないようにする⁴。
• 履歴は「追記のみ」でキャッシュを効かせる（Codex CLI）。 OpenAI の Codex は、プロンプトの静的部分を先に固定して過去を書き換えない——プロバイダのプロンプトキャッシュは前方一致で効くので、ツール集合やモデルを途中で変えるとキャッシュが外れるからだ。コンパクションは専用の /responses/compact エンドポイントに委ね、上限を超えると自動で走る⁵。

共通するのは、この記事の原則そのものだ——机は広げるより、的確に引く。三者とも、満杯が近づけば履歴を要約で畳み、脇道は別の机（サブエージェント）へ出す。差が出るのは「何を捨てないか」の指定で、Anthropic は設計上の判断と未解決のバグを、Cline は決定とコード変更を残すと書く。「何を載せ続けるか」は、実在のハーネスが競って設計している一級の技術である。

これは「新しい技術」なのか、それとも“言い換え”なのか

「コンテキストエンジニアリングは、結局プロンプトエンジニアリングの言い換えでは？」——そう疑うのは自然だ。実際、当事者たちも新旧を断絶としては書いていない。Anthropic はこれを「プロンプトエンジニアリングの自然な進化」と位置づけている³。新語を推した Simon Willison 自身、旧称にこそこの複雑さを込めたかったのに、世間の受け取りは「チャットに気の利いた文字を打つこと」に落ちたと振り返る。定着するのは受け取られ方のほうだ、というのが彼の結論である¹。 私の見立てでは——重心の移動は本物だ。「一発の指示を磨く」から「長く走る情報の状態を管理し続ける」へ、という強調点の変化は実在する。ただし争点は中身の新しさというより、どこまでを一つの語で囲うかにある。新語に踊らされず、中身（限られた机を的確に采配する）を見るのが良いだろう。

エージェントの「ループ」「ハーネス」「コンテキスト」が揃えば、仕組みとしては、これで一通り動く。 （もっとも、この三つにくっきり線が引けるわけではない。とくに「ハーネス」は人によって指す範囲が違う広い言葉で、コンテキストの管理まで含めて「ハーネス」と呼ぶ立場もある。本シリーズは便宜上、足場の作り＝ハーネス／その上で何を見せ続けるか＝コンテキストと分けているが、境界はにじむ——そう断った上で読んでほしい。） ——だが、ここからが本題だ。これだけ整えても、なぜエージェントは「デモは凄いのに実用では脆い」のか。 その正体を、製造業の歩留まりと同じ“掛け算”の数字で、忖度なく明かしていく。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。