AIエージェントの精度が落ちる本当の理由 — コンテキストエンジニアリングで「文脈」を設計する

公開: 2026年8月13日約11分で読めます

AIエージェントを業務で使い込んでいくと、どこかで必ずぶつかる壁がある。

会話が長くなると精度が落ちる。昨日の続きをやらせると前提がずれる。毎回、指示を一から書き直している。

こういう問題に対して「プロンプトを圧縮しよう」「要約を挟もう」「トークンを節約しよう」という対策がよく語られる。間違いではない。ただ、それだけだと同じ壁に何度もぶつかる。

なぜか。会話の中に散らばった情報は、セッションが切れれば消える。要約すれば要約者の判断で何かが落ちる。圧縮しても問題は形を変えて再発する。「プロンプトをどう書くか」だけでは、構造的に解決できない問題があるからだ。

2026年、この問題に名前がついた。コンテキストエンジニアリングという考え方だ。

コンテキストエンジニアリングとは何か

コンテキストエンジニアリング（Context Engineering）は、AIに渡す「文脈」を設計する技術を指す。プロンプトエンジニアリングが「何を指示するか」に注目していたのに対して、コンテキストエンジニアリングは「AIが仕事をするために必要な情報を、どこに置き、どう参照させ、どう更新するか」を設計する。

たとえばこういう状況を想像してほしい。新しく入った社員に仕事を頼むとき、毎回「うちの会社の理念はこうで、このクライアントの特徴はこうで、先月こういう方針を決めて...」と1時間かけて説明するだろうか。普通は業務マニュアルがあり、案件ごとの引き継ぎ資料があり、過去の議事録がファイリングされている。必要なときに参照すればいい状態を、あらかじめ作っておく。

AIエージェントも同じだ。「全部プロンプトに書く」のは、毎回1時間の口頭説明をしているのに等しい。コンテキストエンジニアリングは、その口頭説明を「参照可能な仕組み」に変える考え方になる。

なぜプロンプト改善だけでは足りないのか

プロンプトの改善が無意味だとは思わない。ただ、プロンプトだけで対処しようとすると3つの壁に当たる。

1つ目は、コンテキストウィンドウの物理的な限界だ。AIが一度に処理できる情報量には上限がある。Claude、GPT、Geminiのいずれも、窓の大きさは年々広がっているが、詰め込めば詰め込むほど注意が分散して精度は下がる。大量の情報を渡せることと、それを正確に使えることは違う。

2つ目は、セッションの断絶だ。AIエージェントとの会話は、基本的に1セッションごとに独立している。昨日までの経緯、先月の方針決定、過去に試して失敗したアプローチ。これらは会話が終わればすべて消える。次のセッションで「前回のつづき」を頼んでも、AIは何も覚えていない。

3つ目は、暗黙知の欠如だ。「うちのクライアントには柔らかい文体で書く」「数値レポートは必ずソース突合する」「この案件では以前この方針を棄却した理由がある」。人間が当然のように持っている文脈を、AIは何も知らない。毎回ゼロから説明するか、説明を省いて期待外れの結果を受け取るかの二択になる。

この3つは、プロンプトの書き方をいくら磨いても解消しない。情報の「置き場所」と「引き出し方」を設計しないかぎり、構造的に残り続ける問題だ。

文脈を外に出す — 3つの階層

私がやっているのは、プロンプトを短くすることではなく、文脈の置き場所を階層化することだ。具体的には3つに分けている。

第1層: 業務ルール（SOP）

1つ目は、業務の手順や判断基準だ。SOP（Standard Operating Procedure、標準作業手順書）として会話の外に切り出す。

「広告レポートはこの手順で作る」「数値を出すときは元データとの突合を必ず入れる」「医療広告ガイドラインに抵触する表現は使わない」。こういったルールを、エージェントが毎回自動で参照するファイルとして外に置いておく。

会話の中で「前も言ったけど」と繰り返す必要がなくなる。ルールに変更があれば、ファイルを更新するだけで全セッションに反映される。

第2層: 再利用可能な能力（Skill）

2つ目は、特定の業務で繰り返し使う手順や知識のまとまりだ。「SEO監査の手順」「記事の校正基準」「競合分析のフレームワーク」。こういったものをスキルとして独立させ、必要なタスクのときだけ呼び出す。

毎回プロンプトに全部載せなくて済むし、スキルの品質を個別に改善できる。「この監査手順にチェック項目を追加したい」と思ったら、そのスキルファイルだけを直せばいい。

第3層: プロジェクトの状態と判断履歴（Memory）

3つ目は、プロジェクトの状態や過去の判断の記録だ。「この案件で先週こういう方針を決めた」「この施策は3月に検討して、コスト面で棄却した。理由はこれ」。こういう情報を外部のファイルに記録しておく。

会話が消えても、判断の根拠は残る。同じ提案を二度検討する無駄がなくなるし、半年前の意思決定をたどることもできる。

この3層に分けると、エージェントに渡すプロンプトは「今やるべきこと」と「必要最小限の参照指示」だけで済む。文脈の劣化が起きにくくなり、セッションをまたいでも判断がブレにくくなる。

実際にどう動いているか

うちの環境では、SOPにあたるルールファイルが約40本、スキルが150本以上、プロジェクトの決定履歴メモリが数十本ある。エージェントはタスクを受け取ると、まず該当するルールとスキルを自分で引っ張ってきて、過去の判断履歴を参照してから作業に入る。

たとえば「クライアントの広告レポートを作って」と頼むと、エージェントは広告監査スキルとクライアント固有の設定ファイル（目標CPA、注力地域、過去のパフォーマンス傾向）を読み、先月の判断ログを確認してからレポートを書き始める。私が毎回「前回はこうだったから」と説明する必要がない。

別の例として、記事を書くときは校正スキルが呼ばれる。「AI臭い文章になっていないか」を機械的にチェックする手順が入っているので、書いた文章が一定の基準を通過してから初稿として出てくる。手順が外に出ているから、チェック基準のアップデートはスキルファイルだけ修正すれば反映される。

副産物として、判断の証跡が残る。なぜこの施策を採用し、なぜあの提案を棄却したかが外部ファイルに記録されている。「あのとき何て決めたっけ」と会話ログを遡る作業がなくなる。

よくある失敗パターン

コンテキストエンジニアリングの概念を知っていても、実装段階でよく起きる失敗がある。

一番多いのは「全部をプロンプトに詰め込む」パターンだ。プロジェクト概要、業務ルール、過去の経緯、クライアント情報...全部をテンプレートとしてプロンプトの冒頭に貼り付ける。トークン上限に達する前に、AIの注意がどこに向くか分からなくなる。情報量に比例して精度が上がるわけではない。

次に多いのが「要約に依存する」パターン。長い会話を要約して次のセッションに持ち越す方法は一見合理的に見えるが、何を要約し何を削るかは要約する側の判断に委ねられる。3回要約を繰り返すと、細かいが重要な条件が消えていることがある。

3つ目は「ルールの属人化」だ。プロンプトに業務ルールを書いているが、それが特定の人しか知らないメモ帳やチャットの会話ログにしかない。エージェントが増えても、担当者が変わっても、同じ品質を保てる構造になっていない。

いずれも、情報を「会話の中」か「個人のメモ」に閉じ込めているのが原因だ。文脈を構造化して外に出す、というステップが抜けている。

「どこに置くか」は道具の性質で決まる

最近、文脈の置き場所にも選択肢が増えている。ローカルのファイルに置く方法に加えて、リモートサーバー上にスキルを集約する方法（MCP = Model Context Protocolという共通規格を使う）や、パッケージ規格で配布する方法が出てきた。

ここでも「全部リモートに寄せればいい」という話ではない。道具の性質による棲み分けがある。

画像生成、データ変換、外部API呼び出しのような「処理を実行する」タイプは、リモートサーバー上のtool（関数呼び出し）として動かしやすい。一方で、ライティングのトーン規約、監査チェックリスト、判断基準のような「AIの振る舞いを変える」タイプは、AIのコンテキストに直接読み込ませる必要がある。ローカルのファイルとして手元に置く方が自然に効く。

これはオフィスの業務でも同じだ。計算処理や書類生成はクラウドツールに任せるが、接客の心構えや判断基準は自分の手帳に書いてある。何でもクラウドに載せればいいわけでも、何でも手元に置けばいいわけでもない。道具の性質に合わせて置き場所を選ぶ。これもコンテキストエンジニアリングの一部だ。