コンテキストエンジニアリングとは｜AIエージェントの精度を左右する「情報の渡し方」の設計

コンテキストエンジニアリングとは、LLM に渡すトークン——システムプロンプト、ツール定義、対話履歴、実行時に取得するデータなど——の構成を、狙った出力が出るように設計する取り組みである。

同じモデルでも、渡す情報の作り方ひとつで結果は大きく変わる。AIエージェントを試したものの「デモでは賢いのに、本番のタスクになると急に頼りなくなる」と感じたことがあるなら、原因はモデルそのものだけでなく、与えている文脈の設計にあることも多い。本記事では、コンテキストエンジニアリングが何を指すのか、なぜモデル選びだけでは決まらず文脈の渡し方も効いてくるのか、そして実務でどう設計していくかを整理する。

コンテキストエンジニアリングとは — プロンプトエンジニアリングとの違い

Anthropic は、context（コンテキスト）を「LLM からサンプリングする際に含まれるトークンの集合」と定義し、そのトークンの有用性をモデルの制約のなかで最適化することがエンジニアリングの課題だと整理している。プロンプトエンジニアリングが主に指示文・例示・システムプロンプトの書き方や整理を扱うのに対し、コンテキストエンジニアリングは「どんな文脈の構成なら狙った挙動が出るか」を問い、推論時に入るシステム指示・ツール・履歴・外部データといった文脈状態全体の取捨選択と維持までを対象にする。

背景にあるのは、エージェントの動き方そのものの変化である。Anthropic はエージェントを「ツールを自律的に使ってループを回す LLM」と位置づける。ループのなかでシステムプロンプト、ツールの説明、過去のやり取り、実行時に取り込んだデータが、すべて同じ有限のコンテキストを取り合う。だからこそ、何をどれだけ載せるかという配分の設計が、単発プロンプトの時代より重くのしかかる。Anthropic の指針も「情報量を保ちつつ、できるだけ引き締める（informative, yet tight）」という方向に集約されている。

具体例で考えるとわかりやすい。リポジトリ全体を丸ごと渡されたコーディングエージェントは、関係のないファイルにも気を取られ、的外れな修正をしてしまうことがある。一方、変更対象のファイルとテストの実行方法だけを渡せば、同じモデルでも狙った範囲に集中できる。必要な情報を残しつつ高シグナルな文脈に絞るほど、モデルは狙った範囲に集中しやすい。コンテキストエンジニアリングは、この「何を見せ、何を見せないか」を意図的に決める作業だと言える。同じことが、調査・要約・問い合わせ対応など、文脈を組み立てて動かすあらゆるエージェントに当てはまる。

なぜ「渡し方」が成果を左右するのか

渡し方の設計がどれだけ効くかを示す材料として、AIエージェントの「スキル」を大規模に検証した研究がわかりやすい。UC Santa Barbara、MIT CSAIL、MIT-IBM Watson AI Lab のチームは、公開リポジトリから集めた約34,000件（34,198件）のスキルを使い、現実条件に近づけたときの効き目を測った。スキルとは、手順・参照資料・補助スクリプトなどをまとめた再利用可能な知識のかたまりだ。エージェントがスキルの説明や本文を読み込めば、その情報はコンテキストの一部として働く。ただし、スキルに含まれるファイルすべてが常にLLMへ渡るわけではない。必要な部分を検索・読み込み・実行する設計まで含めて、スキルをどう使うかが決まる。

査読前のプレプリントだが、結果ははっきりしている。研究者の言葉を借りれば「fragile（脆い）」。SkillsBench というベンチマークのタスク通過率で見ると、同じ Claude Opus 4.6 でも、タスクに最適なスキルを強制的に読み込ませた上限条件では55.4%だったのに対し、人手でキュレーションしたタスク別スキルを除いた約34,000件から自分で検索させる現実寄りの条件では38.4%まで落ちた。スキルを一切使わない素の状態が35.4%なので、現実条件のスコアはそこへ肉薄する。効果が消えるわけではないが、最適化された見せ方から離れるほど利益は大きく縮む。ただし、この55.4%から38.4%への差を「情報の渡し方だけ」の効果とみなすことはできない。38.4%の条件は、専用スキルを除いた実世界のスキル群から、エージェント自身が候補を検索し、選び、読み込み、タスクに適応する設定だからだ。差には、何を渡すかだけでなく、検索の精度・候補の選択・スキル内容の解釈・汎用スキルを個別タスクへ適応する難しさも含まれる。なお、これは論文が評価した Claude Opus 4.6（および Claude Code v2.1.19）での結果で、Claude Opus 4.8 など、2026年6月時点の新しい Claude モデルの成績をそのまま示すものではない。それでも、同じ Claude Opus 4.6 と Claude Code の組み合わせで、与える知識の条件によって成績が大きく動いた点は重要だ。コンテキスト設計は、モデル単体の性能とは別に、エージェント全体の成果を左右しうる。

さらに、検索で得た汎用スキルを足した条件が無スキル条件を下回る組み合わせも観測された。最も厳しい検索条件では、Kimi K2.5＋Terminus-2 でスキルあり19.8%・なし21.8%、Qwen3.5-397B-A17B＋Qwen-Code でスキルあり19.7%・なし20.5%と、与えたほうがわずかに下回った。ただし、これはモデル単体の能力差を直接証明する比較ではない。各モデルは異なるエージェントハーネスと組み合わされており、検索・選択・ツール利用まで含むエンドツーエンドの結果だ。少なくともこの条件では、関連性や品質が十分でない取得スキルが、追加情報ではなくノイズとして働きうることを示している。

これは特定の製品の優劣というより、少なくともスキルの検索・選択をエージェントに任せる場面で、文脈の選び方が成績を大きく左右しうることを示している。詳しい数値や条件はClaude Code と OpenAI Codex のスキル機能比較でも扱っている。ここで押さえておきたいのは、同じモデルでも与える文脈の作り方しだいで結果が動く——それが第三者の研究のベンチマークで報告されている点である。

もうひとつ見落としやすいのが、長く詰め込めば賢くなるわけではない、という性質だ。Chroma が「context rot」と呼ぶ現象として、入力トークンが増えるほど、必要な情報の利用精度が非一様に落ちる場合があると報告されている。履歴やドキュメントを大量に流し込むと、かえって肝心の情報が埋もれかねない。コンテキストは増やす対象ではなく、配分する対象だと捉えたほうが実態に近い。

コンテキスト設計でおさえる要素

本番のエージェントで効いてくる設計のポイントは、おおむね次の領域に分かれる。それぞれが有限のコンテキストの取り合いに関わる。どれも独立しているようで、実際は連動する。検索を絞れば圧縮の負担が減り、記憶を整理すれば毎回渡す情報が軽くなる、というように互いに効き合う。

システムプロンプトの設計

役割・制約・出力形式・守ってほしい手順を、過不足なく書く。盛りすぎると指示が衝突し、薄すぎると暴走する。Anthropic の言う「情報量を保ちつつ引き締める」は、まずここに効く。プロジェクト固有のルール（テストは必ず走らせる、外部送信はしない等）は、曖昧な精神論ではなく具体的な条件として置く。たとえば「変更は要求された範囲だけに留める」「未確認の事項は推測せず確認を求める」のように、満たしたかどうか判定できる形で書くと、挙動が安定しやすい。ただし、外部送信の禁止や削除の禁止といった安全要件は、プロンプトだけでは強制できない。権限設定やネットワーク制御、実行前のフックなど、モデルの判断に依存しない仕組みと組み合わせる。

検索（retrieval）

必要な情報だけを、必要なときに取り出す仕組み。社内ドキュメントや過去ログを丸ごと渡すのではなく、タスクに関係する断片だけを引き当てて渡す。代表的な手段が RAG（検索拡張生成）で、外部知識をベクトル検索やキーワード検索などで取得してから生成させる。仕組みと作り方はローカルRAGの入門記事で具体的に追える。ただし検索は万能ではない。無関係な断片を引いたり、古い情報を混ぜたりすると、そのまま誤答につながる。検索が外れたときに何が起きるかはRAGのハルシネーション対策で詳しく扱っている。取り出す件数も設計対象だ。関連度の低い候補まで多めに渡すと、次に述べる選択の失敗を招きやすい。

圧縮（compression）

対話が長くなると履歴がコンテキストを圧迫する。そこで、過去のやり取りを要約したり、不要になったツール結果を削ったりして、限られた枠を空ける。要約してから渡すか、生のまま削るかで挙動は変わる。長時間動くエージェントほど、この圧縮の設計が安定性を左右する。たとえば、解決済みのサブタスクのログは要約一行に畳み、未解決の論点だけ原文で残す、といった切り分けが効く。

記憶（memory）

記憶は実務上、セッション内で完結する短期記憶と、セッションをまたいで残す長期記憶に分けて考えることが多い。短期記憶は直近のやり取りや作業中の状態を保ち、長期記憶はユーザーの好みや過去の判断、学習した手順を残す。何を覚え、何を捨て、いつ呼び戻すかの設計が、エージェントの一貫性を決める。近年は、記憶の保存・取得・更新・要約・破棄そのものをエージェントが扱う操作として設計する研究も進んでいる。実務では、毎回渡す常設の文脈（プロジェクトの規約など）と、必要なときだけ引く長期記憶を分けておくと、コンテキストの圧迫を抑えやすい。なお、長期記憶にユーザーの情報を残す場合は、何を保存し・いつ消し・誰がアクセスできるかという扱いを別途決めておく。

順序と取捨選択

同じ情報でも、どこに置くかで効き方が変わる。長い資料は前半に置いて質問や実行指示を最後に回す、関係の薄い候補は最初から渡さない、といった調整が効く。ただし最適な配置はモデルや入力の形で変わるため、検証して決める。前述の研究が示したのも、候補が多いほど選び損ねる、という取捨選択の難しさだった。増やすより、削って整える発想が要る。迷ったら、候補数を減らす案も評価対象に入れ、成功率や再試行回数で比べてみるとよい。減らしたほうが安定することは珍しくない。

よくある失敗パターン

実務で起きやすい崩れ方は、だいたい次のいくつかに当てはまる。

• 詰め込みすぎ：関連しそうな資料を片端から載せ、肝心の情報が薄まる。長さは安心材料にならない。対処は、タスクに直接効く情報だけに絞り、入れた分だけ何かを削る習慣をつけること。
• ノイズの混入：無関係な候補が混ざると、エージェントが誤った情報を拾ったり、関係の薄い手順に引っ張られたりして迷走しやすい。候補の段階で関連度の低いものを落とし、渡す前にフィルタをかける。
• 古い情報・矛盾：更新されていない手順や、互いに食い違う指示が同居し、出力が揺れる。情報源に日付や版を持たせ、古いものは渡さない仕組みにする。
• 履歴の肥大：長い対話をそのまま持ち回り、必要な情報が埋もれる（context rot）。区切りごとに要約へ畳み、不要になったやり取りは落とす。
• 検索の的外れ：取得の設計が甘く、それらしいが無関係な断片を渡してしまう。取得結果を関連度で並べ替え、件数を絞ってから使う。

実務での進め方

コンテキストの設計は、頭の中だけで正解にたどり着くものではない。小さく渡して計測し、結果を見て広げる、という回し方が現実的だ。

具体的には、まず最小限の文脈で動かし、同じタスクで「文脈あり／なし」や「検索あり／なし」を比べる。見る指標は、成功率、やり直しの回数、消費トークン、そして人手で直したレビュー工数。ベンチマーク上の数字と自社タスクでの成果は別物なので、判断は手元の計測に置く。評価の仕組みそのものをどう組むかは本番エージェントの評価設計が参考になる。

たとえば社内文書を参照するエージェントなら、最初は最も関連する数件だけを渡して成功率を測り、取りこぼしが出たときにだけ件数や要約の粒度を上げていく。いきなり全文書を載せると、精度もコストも悪化しやすい。小さく始めれば、どの追加が効いたのかも後から切り分けられる。計測の土台ができてはじめて、どの情報を足し、どれを削るかを根拠をもって決められる。

効き目はタスクの性質にも左右される。手順が定まっていて参照すべき情報がはっきりしている作業ほど、渡し方の改善は素直に成果へつながる。逆に、必要な情報がそもそも手元にない、あるいはタスク自体が曖昧なままだと、文脈をいくら整えても伸びにくい。その場合は、情報源を用意する、タスクを小さく切り分ける、といった前段からまず手を入れたほうがよい。

手法・ツールとどうつながるか

コンテキストエンジニアリングは単独の技術ではなく、エージェント運用の各所に顔を出す。点で覚えるより、つながりで捉えたほうが設計しやすい。実際の動きは、検索で集めた情報を圧縮し、必要なものを記憶に残し、システムプロンプトの制約のもとで使う——という流れが一周する形になる。どれか一つだけ整えても、別のところで崩れれば全体の精度は上がらない。

• スキル：手順や参照資料をまとめて渡す仕組みで、文脈の一部。効き目が条件で変わることはスキル機能の比較記事で扱った。
• 検索・RAG：必要な情報を引いて渡す中核。RAGの作り方と検索が外れたときの対策。
• アーキテクチャ：文脈の流れをどこで組み立てるかは構造の問題でもある。エージェントのアーキテクチャ設計。
• 権限と運用：何を渡し何を渡さないかは、安全性の設計とも地続き。権限を与える前の設計ガイド。
• プロンプト設計：システムプロンプトや指示文の書き方そのものは、プロンプトガイドが踏み込んでいる。
• 観測・運用：渡し方の良し悪しを継続して見るには、LLMワークフローのオブザーバビリティ設計。
• 評価：渡し方の良し悪しは計測でしか確かめられない。評価設計が土台になる。

よくある質問

Q. プロンプトエンジニアリングと何が違うのですか？

プロンプトエンジニアリングは主に、指示文や例示、システムプロンプトの書き方や整理を扱います。コンテキストエンジニアリングは、それも含めて、システムプロンプト・ツール・履歴・取得データといった文脈全体を、どう構成すれば狙った挙動になるかを設計します。単発のやり取りより、複数ステップで動くエージェントで効いてきます。

Q. 何から始めればいいですか？

最小限の文脈で動かし、同じタスクで「文脈あり／なし」を比べるところからです。成功率・やり直し回数・消費トークン・レビュー工数を計測し、足すか削るかを数字で判断します。最初から作り込まず、計測しながら広げるのが安全です。

Q. コンテキストは長いほど有利ですか？

そうとは限りません。情報を詰め込みすぎると肝心の内容が埋もれ、かえって精度が落ちることがあります（context rot）。長い文脈に対応したモデルでも、扱える上限と、高い精度で使いこなせる量は別物です。枠が広いからといって埋める必要はありません。コンテキストは増やす対象ではなく、必要なものに配分する対象と考えるほうが実態に合います。

Q. RAG とはどういう関係ですか？

RAG（検索拡張生成）は、コンテキスト設計のうち「検索」を担う代表的な手段です。必要な情報を外部から引いて渡すことで、文脈を関連する断片に絞れます。ただし取得を誤ると誤答につながるため、検索の精度設計とセットで考えます。RAG はあくまで一部品で、システムプロンプトや記憶の設計まで含めた全体がコンテキストエンジニアリングの範囲です。

Q. どのモデルでも有効ですか？

文脈設計は多くのLLMエージェントで重要な論点です。ただし効き方はモデル・タスク・検索の品質によって変わります。少なくとも紹介した研究の条件では、Claudeより成績の低いモデルで、ノイズの多い取得スキルが無スキル時を下回る例も報告されました。一般化はせず、使うモデルとタスクで計測して確かめてください。

まとめ

コンテキストエンジニアリングは、プロンプトの言い回しから、エージェントに渡す情報フロー全体の設計へと重心を移した実践だ。同じモデルでも、何を・どの順で・どう取得し圧縮し記憶して渡すかで、成果は大きく変わる。紹介したスキル検証の研究が示したのも、少なくともスキルの検索・選択・適応を伴う条件では、理想的な見せ方から現実条件へ近づくほど効果が縮むという難しさだった。

足すより削る。詰め込むより配分する。そして、良し悪しは思い込みではなく、自社タスクでの計測で確かめる。この回し方を持てるかどうかが、デモで賢いエージェントを、本番で使えるかどうか見極める手がかりになる。

はじめの一歩は小さくてよい。いま動かしているエージェントのシステムプロンプトを見直し、渡している情報のうち本当に要るものだけに絞ってみる。それだけでも、出力の安定し方は変わってくることがある。そこからは、検索・圧縮・記憶へと少しずつ設計の手を広げていけばよい。

参考資料

• Effective context engineering for AI agents（Anthropic 公式・コンテキストエンジニアリングの定義と指針／2025年9月）
• How Well Do Agentic Skills Work in the Wild: Benchmarking LLM Skill Usage in Realistic Settings（UC Santa Barbara ほか・スキル機能の検証研究／査読前プレプリント・2026年4月）
• Memory for Autonomous LLM Agents: Mechanisms, Evaluation, and Emerging Frontiers（エージェントの記憶に関するサーベイ／arXivプレプリント・2026年3月）
• Context Rot: How Increasing Input Tokens Impacts LLM Performance（Chroma Research のテクニカルレポート・2025年7月）
• Lost in the Middle: How Language Models Use Long Contexts（TACL 2024・長文内の情報位置と性能の関係）
• Security（Claude Code 公式・権限／プロンプトインジェクション対策）

本記事は AIツール図鑑編集部 が記載時点の情報をもとに執筆。製品アップデートや研究の進展で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。