プロンプトを磨いても精度が上がらないのは、なぜ？
ミドリ： タツヤさん、最近ちょっと悩んでることがあって。社内のAIアシスタントに同じ質問をしても、日によって答えの質がバラバラなんですよ。プロンプトはかなり作り込んだはずなんですけど……。
タツヤ(nodding)： それ、今いちばん多い相談だね。結論から言うと、プロンプトの問題じゃなくてコンテキストの問題であることがほとんどなんだ。
ミドリ(confused)： コンテキスト……文脈、ですよね。プロンプトとは違うんですか？
タツヤ： 違う。プロンプトは「何を言うか」。コンテキストは「何を渡すか」。2026年に入ってから、業界の関心はプロンプトエンジニアリングからコンテキストエンジニアリングへはっきり移ってるんだ。
ミドリ： 名前は聞いたことあります。ただ、正直バズワードだと思ってました。
タツヤ： 気持ちはわかる。でもこれは実務の手触りがある概念だよ。今日は定義から、うちで実際にやってる設計手順まで一気に話そうか。
コンテキストエンジニアリングとは何か
ミドリ： まず定義からお願いします。
タツヤ： よく引かれる定義はこれ。「望ましい結果の可能性を最大化する、最小限の高シグナルなトークンの集合を見つけること」。
ミドリ(thinking)： 最小限……多ければいいわけじゃないんですか？
タツヤ： そこが最大の誤解。「関連しそうな資料を全部投げ込めば賢くなる」と思われがちだけど、実際は逆に働くことが多い。
ミドリ： どうしてですか？
タツヤ： たとえ話をしよう。新人に「この件よろしく」と言いながら、キャビネットの書類を全部机に積み上げたらどうなる？
ミドリ(smiling)： ……固まりますね。どれを見ればいいかわからなくて。
タツヤ： LLMも同じ。判断材料が増えるほど、どれが重要かの信号が薄まるんだ。だからコンテキストエンジニアリングは「足す技術」じゃなく、引き算の技術として設計する。
対象になるのは4つの層
ミドリ： 具体的に「コンテキスト」って、どこまでを指すんですか？
タツヤ： ざっくり4層で考えるとわかりやすい。
| 層 | 中身 | 典型的な事故 |
|---|---|---|
| システム指示 | 役割・禁止事項・出力形式 | 指示が長すぎて後半が無視される |
| ツール定義 | AIが呼べる関数・API | ツールが多すぎて選択を誤る |
| 外部データ | 検索結果・社内文書・DB | 関連度の低い文書が上位に混入 |
| 会話履歴 | 過去のやり取り | 古い前提が残り続けて誤答を誘発 |
ミドリ： プロンプトって、この表だと「システム指示」の一部でしかないんですね。
タツヤ(nodding)： そう。だからプロンプトだけ磨いても、残り3層が汚れていれば精度は頭打ちになる。回答のブレは、たいてい会話履歴か外部データの層で起きている。
なぜ2026年になって注目されたのか
ミドリ： 概念自体は前からありそうですけど、なぜ今なんですか？
タツヤ： 理由は3つある。
- コンテキスト長が伸びた — 数十万トークンを渡せるようになり、「入れようと思えば全部入る」状況が生まれた。制約が消えた結果、設計が必要になった
- エージェント化が進んだ — 1回の応答で終わらず、AIが何十ステップも動くようになった。ステップごとにコンテキストが膨らみ、放置すると自壊する
- 課金がトークン単位 — 無駄な情報を渡すことが、そのまま毎回のコストになる
ミドリ： 長く入れられるようになったからこそ、逆に選ぶ必要が出てきた、と。
タツヤ： そういうこと。「入れられる」と「入れるべき」は別問題なんだ。
実務での設計手順
ミドリ： うちでやるとしたら、どこから手を付けますか？
タツヤ： 5ステップで進めるといい。
ステップ1：出力の合格条件を先に書く
タツヤ： いきなりコンテキストをいじらない。まず「何が出たら合格か」を文章で書く。
- 見積書なら「品目・数量・単価・小計・消費税・合計がすべて埋まっている」
- 議事録なら「決定事項と担当者と期限が箇条書きで揃っている」
ミドリ： 合格条件がないと、改善したかどうかも判断できないですもんね。
タツヤ： そう。ここを飛ばすと、以降の作業が全部「なんとなく良くなった気がする」で終わる。
ステップ2：今渡している情報を全部書き出す
タツヤ： 次に棚卸し。システム指示、ツール、検索でヒットした文書、会話履歴──実際にモデルに届いているものをログに出して目視する。
ミドリ(surprised)： ログに出すんですか？
タツヤ： これをやると9割の現場で驚きがある。「消したはずの旧テンプレートがまだ入っていた」「検索が毎回20件返していて、うち有用なのは2件だった」みたいな発見が普通に出てくる。
ステップ3：削って壊れる境界を探す
タツヤ： ここが本番。渡す情報を減らしていって、合格条件を割った瞬間が最小構成だ。
ミドリ： 足すんじゃなくて、減らしながら探すんですね。
タツヤ： 足す方向で探すと、いつまでも「もっと入れれば良くなるかも」から抜けられない。減らす方向なら必ず終わりが来る。
ステップ4：残す情報に優先順位の構造を与える
タツヤ： 同じ情報でも、置き方で効き方が変わる。うちで守ってるルールはこれ。
- 絶対に守らせたい制約は冒頭と末尾の両方に置く — 中盤は相対的に効きが弱い
- 参照資料には出典ラベルを付ける(
[社内規程 2026年4月版]のように) - 古い会話履歴は要約に置き換える — 生ログのまま持ち回らない
- ツールは10個以内に絞る — 多いほど選択ミスが増える
ミドリ： 履歴を要約に置き換えるの、地味に効きそうですね。
タツヤ： 長時間動くエージェントだと、これをやるかどうかで安定性が全然違うよ。
ステップ5：検証は「反証」で設計する
ミドリ： 最後は評価ですか？
タツヤ(nodding)： そう。ただし大事なコツがある。検証は「うまくいった例を確認する」んじゃなくて「壊れる例を探しに行く」設計にすること。
ミドリ： 肯定じゃなく反証、ですか。
タツヤ： うまくいったケースだけ見ていると、確証バイアスが増幅して「よくできている」という結論しか出てこない。あえて例外的な入力、矛盾する資料、情報が欠けたケースを投げて、どこで崩れるかを測る。
長く動くエージェントほど設計が要る
ミドリ： さっき「長時間タスクで前提が崩れる」と言っていましたよね。あれはどういう現象なんですか？
タツヤ： エージェントが何十ステップも動くと、ステップごとにコンテキストが増えていく。検索結果、ツールの実行結果、途中の思考。放っておくと最初の指示が埋もれるんだ。
ミドリ(thinking)： 最初に言ったことを忘れる感じですか。
タツヤ： 「忘れる」というより、相対的な重みが薄まる。10行の指示に対して2万行の作業ログが積み上がったら、指示は全体の0.05%でしかない。
ミドリ： それは効かなくなりますね……。
タツヤ： だから長時間タスクでは、3つの仕掛けを入れる。
- 定期的な要約と圧縮 — 一定ステップごとに、それまでの経緯を要約に置き換える。生ログは捨てる
- 指示の再注入 — 重要な制約を、節目ごとにもう一度渡す
- 作業メモの外出し — 進捗や決定事項をファイルなど外部に書き出し、必要な時だけ読み戻す
ミドリ： 3つ目は、人間でいうノートですね。
タツヤ(nodding)： まさにそう。全部を頭に入れておくのをやめて、書いて参照する。人間が長い会議でメモを取るのと同じ発想だよ。
「渡さないもの」を決める勇気
ミドリ： でも、削って必要な情報が抜けたら怖くないですか？
タツヤ： 怖い。だから削った時に何が壊れるかを実際に見るんだ。これがステップ3の「境界を探す」作業だね。
ミドリ： 想像で判断しないということですか。
タツヤ(thinking)： そう。実務でいちばん多いのは、「念のため入れておいた情報」が精度を下げているケース。念のためは、たいてい根拠がない。1回外して測れば、必要かどうかは30分でわかる。
よくある失敗パターン
ミドリ： 逆に「これはダメ」という典型ってありますか？
タツヤ： 4つ挙げておくね。
- 社内文書を丸ごと全部読ませる — 検索精度が低いまま量で殴ると、ノイズが増えて精度が下がる
- システム指示に禁止事項を書き足し続ける — 事故のたびに追記して1万字を超えると、もはやどれも守られない
- 会話履歴を無制限に保持する — 3時間前に否定した案が、なぜか復活してくる
- 出典を渡さない — 根拠が示せない回答は、業務では使えない
ミドリ(thinking)： 「事故るたびに禁止事項を足す」、めちゃくちゃ心当たりがあります……。
タツヤ： みんなやるんだよ。だから四半期に一度、システム指示を棚卸しして削る日を決めておくといい。
期待できる効果
ミドリ： これ、やるとどのくらい変わるものなんですか？
タツヤ： 目安として、うちや支援先で見えている傾向はこんな感じ。
| 施策 | 典型的な効果 |
|---|---|
| 検索の返却件数を20件→上位3〜5件に絞る | 誤答の減少、応答時間の短縮 |
| 会話履歴を要約に置換 | 長時間タスクでの前提崩れが大幅に減少 |
| ツール数を絞る | ツール選択ミスの減少 |
| 冗長なシステム指示の削除 | 毎回の入力トークンが減り、コストも低下 |
ミドリ： 精度とコストが同時に良くなるんですね。
タツヤ： ここが面白いところで、コンテキストエンジニアリングは精度改善とコスト削減が同じ方向を向く数少ない施策なんだ。普通はトレードオフになるところが、両立する。
脱エンジニアの視点で考えると、「AIに何を渡さないかを決められるか」が分岐点になります。 モデルを乗り換えるのは誰でもできるけれど、自社の業務で「この判断にはこの3つで足りる」と言い切れるのは、業務を知っている人だけだからね。
ミドリ： それ、エンジニアじゃなくてもできる仕事ですね。
タツヤ： むしろ業務担当者のほうが向いてる。技術じゃなくて業務理解が効く領域なんだ。
プロンプトエンジニアリングは不要になるのか
ミドリ： じゃあ、プロンプトの工夫はもう要らないんですか？
タツヤ(thinking)： 要る。ただし役割が変わる。
- プロンプト = 出力の形と態度を決める(何を言うか)
- コンテキスト = 判断材料を決める(何を渡すか)
ミドリ： 両方いるけど、優先順位が変わったということですか。
タツヤ： そう。今の実感だと、出力品質の大半はコンテキスト側で決まる。プロンプトを10回書き直すより、渡している資料を1回見直すほうが効くケースが圧倒的に多いよ。
まとめ
タツヤ： 今日のポイントを整理しよう。
- コンテキストエンジニアリングは「望む結果を出す最小限の高シグナル情報を選ぶ技術」。足す技術ではなく引く技術
- 対象はシステム指示・ツール定義・外部データ・会話履歴の4層。プロンプトはその一部でしかない
- 手順は「合格条件を書く → 棚卸し → 削って境界を探す → 構造を与える → 反証で検証」の5ステップ
- 検証は肯定の確認ではなく反証の試みとして設計する
- 精度改善とコスト削減が同じ方向を向く、珍しく費用対効果の高い施策
ミドリ(smiling)： 「渡しすぎていないか」を疑うところから始めればいいんですね。すぐできそうです。
タツヤ： そう。しかも一度型ができれば、AIを乗り換えても資産として残る。モデルは変わるけど、業務の判断材料の設計は変わらないからね。
次のアクション
ミドリ： 明日から動くとしたら、何からやりますか？
タツヤ： 3つだけ手を動かしてみてほしい。
- いま社内AIに渡している情報をすべてログに出して、紙に書き出す — 半日で終わる。ここで9割の現場が「余計なもの」を発見する
- 合格条件を1業務ぶんだけ文章化する — 「何が出たら合格か」を5行で書く。判断基準がないと改善が測れない
- 検索の返却件数を上位3〜5件に絞って比較する — 削る方向のA/Bを1回試すと、量が効かないことが体感できる
タツヤ： Shimanto AI Solutionsでは、この領域の支援をしているよ。
- コンテキスト棚卸しワークショップ — 現行のAI利用で何が渡されているかを可視化し、削減候補を洗い出す
- 合格条件と評価セットの設計 — 反証ベースの検証データを業務単位で整備し、改善を数値で追えるようにする
- 社内文書の検索精度チューニング — RAG構成の見直しから、出典表示・要約置換の実装まで伴走
ミドリ： どれも「新しいツールを買う」話じゃないのがいいですね。
タツヤ： そこが本質だよ。今あるAIのまま、渡し方を変えるだけで結果が変わる。まずはそこからで十分。
参考にした情報
執筆時点(2026年8月)に確認した資料です。数値や仕様は変わるため、最新は各出典をご確認ください。
- コンテキストエンジニアリング完全ガイド2026｜Anthropic提唱・AIエージェント運用の新標準 — 株式会社renue
- AIエージェント開発特集 9社のアーキテクチャ・技術選定と本番運用のリアル — Findy Tools