チャットボットが昨日の話を また忘れてしまう理由 : Context Engineering

原文出典 "How to Master Context Engineering" — Digital Bricks https://www.digitalbricks.ai/blog-posts/how-to-master-context-engineering

日本の読者向けに整えて掲載しました。

プロンプトさえちゃんと書ければ全部うまくいくと思っていました。ところが、ある瞬間からチャットボットの返答が怪しくなりはじめます。5分前にはっきり伝えた内容を忘れ、コーディングアシスタントは自分たちのプロジェクト構造を取りこぼし、RAGで作った社内ボットは2つのドキュメントを同時に参照できない。

これは「プロンプトが甘いから」ではない、というのが核心です。AIアプリが複雑になるほど、一行のプロンプトは氷山の一角になります。本当の鍵は、そのモデルが何を見ているか、何を覚えているかをシステムの次元で設計するところにあります。コンテキストエンジニアリング(Context Engineering) が、まさにその話です。

この記事ではコンテキストエンジニアリングとは何か、プロンプトエンジニアリングとどう違うのか、実戦ではどんな形で現れるか(RAG・エージェント・コーディングアシスタント)、そして何より ― コンテキストが崩れる4つの代表パターンとその対処法を一緒に見ていきます。

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

一言で言えば、「モデルが答えを作る前に、何を見せるかをシステムの次元で設計する仕事」 です。プロンプト一行を整えるのではなく、モデルの周りに生きた情報の生態系のようなものを作ることです。

ここで言うコンテキストは、思っているよりずっと広いんです。ユーザーが今投げた質問だけがコンテキストではありません。モデルが答えを作る直前までに受け取ったすべてが、コンテキストです。

• システム指示: 「あなたは親切なカスタマーサポート担当です」のようなロール・ルール設定

• 現在の質問 + 対話履歴: 5分前に何の話をしたか

• 長期メモリ・ユーザーの好み: この人が普段どんな話し方を好むか

• 外部から取り込んだ資料: 社内ウィキ、ポリシー文書、DB検索結果

• 使える道具のリスト: 「カレンダー確認」「メール送信」などの道具

• 出力形式の枠: JSONスキーマ、メールテンプレートのような決まった構造

• リアルタイムデータ: いま呼び出したAPIが返した株価や天気など

問題は、モデルが認識できるコンテキストの量が無限ではないということです。だからコンテキストエンジニアリングは、事実上選別と圧縮の技術です。何を今見せ、何を要約し、何をいったん脇に置くか。短い対話には短期メモリ、古い事実には長期メモリ、時間の経った内容には要約 ― そんなふうに層をなして組まなければいけません。

これがうまく組まれると、AIはようやく「人のように覚えている」感覚を与えてくれます。昨日話したことを引き出し、ユーザーの好みを反映し、会社の文書を参照し、リアルタイム情報まで見ながら答えを作る。そこではじめて単発のQ&Aではなく、「一緒に仕事をする」体験になります。

プロンプトエンジニアリングとはどう違うのか

ChatGPTに「メールの返信を丁寧に書いて」と頼むのはプロンプトエンジニアリングです。ところが会社のカスタマーサポート・チャットボットを作るとき、このチャットボットが以前の対話を覚え、ユーザーのアカウント情報を引き出し、関連製品の文書を参照し、対話全体でトーンも保たなければならないとしたら、その瞬間からコンテキストエンジニアリングの領域です。

違いを短くまとめるとこうなります。

• プロンプトエンジニアリング: モデルに 何を依頼するか を設計

• コンテキストエンジニアリング: モデルに 何を渡すか をシステムで設計

Andrej Karpathyの表現を借りると分かりやすいです。

「人々はプロンプトを、日常でLLMに投げる短い作業指示だと思いがちです。ところが産業に耐えうるLLMアプリは、コンテキストエンジニアリング ― 次の一歩にぴったり合う情報でコンテキストウィンドウを満たす繊細な技術 ― の上で動いています。」

良いプロンプトは依然として必要です。ただ、そのプロンプトが空白の中ではなく、よく整理された背景情報の上で機能しているかどうか ― そこが差を作ります。

実戦ではどんな形で現れるか

実際の製品では、コンテキストエンジニアリングが3つの形で現れます。

RAG: モデルに「オープンブック試験」を受けさせる方法

最も馴染みのあるパターンが RAG です。難しそうに見えますが、アイデア自体は単純です。ユーザーが何かを尋ねると、関連資料を外部のナレッジベースから取ってきてモデルに一緒に見せます。すると、モデルは学習時に見ていない情報にも答えられるようになるんです。

以前は社内ポリシーに答えさせるためにモデルを社内文書でファインチューニングする必要がありました。RAG はこれをひっくり返します。モデルはそのままにしておき、その都度必要な情報を検索してコンテキストに差し込む。モデルにオープンブック試験を受けさせると捉えていただくと、理解が早いです。

メリットは明快です。モデルの誤りが減り、社内の事実に紐づいた答えが返ってきます。だから社内Q&Aボット、カスタマーサポートボット、パーソナルアシスタントなど、会社の資料が核となるほぼすべてのケースでRAGが最初の一歩として入ります。

エージェント: コンテキストを自ら埋めていくモデル

RAGが資料をコンテキストに入れるものだとしたら、エージェントはもう一歩先に行きます。モデルが自分で道具を選んで呼び、その結果をまた自分のコンテキストに埋めながら作業を進めるんです。コンテキストが静的な文の塊から生きた作業台に変わります。

たとえば「テスラの株価を教えて、関連ニュースも要約して」と頼んだとしましょう。よくできたエージェントは、(1)「最新データが必要だな」と判断 →(2)株価APIを呼び出し →(3)ニュース検索ツールを呼び出し →(4)2つをまとめて整理、こんなふうに動きます。各ステップの結果がコンテキストに積み上がり、それを見て次の行動を決めるわけです。 観察 → 行動 → コンテキスト更新 → また観察 のループです。

最近は一つのエージェントが全部やるのではなく、複数のエージェントが役割を分担して仕事をする方式も増えています。一方が文書要約、もう一方がDB検索、別のエージェントが2つの結果を合わせるという具合に。ただし、複数のエージェントがコンテキストをうまく受け渡せないと、互いに混乱して無限ループに陥りやすいという落とし穴があります。だからこそコンテキストエンジニアリングがより重要になってきます。

コーディングアシスタント: いちばん難しいケース

GitHub Copilot、Cursor、Windsurfのようなコーディングアシスタントは、実はコンテキストエンジニアリングの最上級に近いんです。コードベースは普通、大きすぎて、互いに絡み合っていて、ファイル1つを変更するだけで他のファイル数十個に影響が及びます。

「process_data 関数が空の値も処理できるようにリファクタリングして」 ― この一行のリクエストをうまく処理するには、アシスタントが知っておくべきことが多いんです。この関数がどこから呼ばれているか、どんな型を受け取って返すか、プロジェクトのコーディングスタイルは何か、最近どんなコミットがあったか。これらすべてをコンテキストとして埋めてあげるのが、コーディングアシスタントの本業です。ある意味、コードベースの上で動かすRAGと言ってもいいくらいです。

同じツールでもプロジェクトで長く使うほど良くなっていく感覚があるのは、当然のことながらコンテキストがどんどん厚くなっていくからです。

コンテキストが崩れる4つのパターン

ここで自然に浮かんでくる質問が一つありますよね。「じゃあエージェントが理解できるコンテキストを、いっそ100万トークンまで広げれば全部解決するんじゃないか?」

最近の研究は、まったく逆のことを言っています。AI研究者のDrew Breunigは「長いコンテキストがより良い答えを作るわけではない」と釘を刺しました。むしろコンテキストが増えすぎると、モデルが 汚染されたり、気が散ったり、混乱したり、自分の言葉とぶつかったり する新しい形で崩れはじめます。

1. コンテキスト汚染: 偽の情報が真実のように刺さるとき

会話の途中でモデルが一度でも事実でないものを「事実」としてコンテキストに刺してしまうと、その後は偽の事実を基準にして推論を続けます。小さな幻覚一つが流れ全体を壊してしまうわけです。

DeepMindのGeminiエージェントがポケモンをプレイした事例が代表的です。キャラクターは無事なのに「気絶した」と誤認識した瞬間、その情報がエージェントの目標リストに刺さりました。それ以降、エージェントのすべての行動が壊れてしまいました。

対処法は隔離(Quarantine)です。 モデルが自分が知っていると主張するものをそのまま受け取らず、一度検証してから長期メモリに移すんです。怪しい部分は別セッションや別のエージェントで処理して、一つの流れのエラーが他の流れを汚染しないように防ぐのがポイントです。ノートを何冊か別々に使うのと似ています。一冊がぐちゃぐちゃでも、残りは無事です。

2. コンテキスト散逸: 自分の記録に気を取られるモデル

コンテキストが大きくなりすぎると、モデルは学習時に身につけた知識よりも その場に積み上がった記録 に引っ張られはじめます。結局、新しい答えを作るよりも、過去にとった行動を同じように繰り返すことに陥るんです。

先ほどのGeminiエージェントも、コンテキストが10万トークンを超えると新しい計画が出せず、過去の行動を繰り返しました。Databricksの計測によれば、4050億パラメータのLlama 3.1でさえ3万2千トークン付近から精度が落ちはじめるそうです。100万トークンを受け取れることと、100万トークンを 使いこなせる ことは、別の話です。

対処法は要約と剪定です。 対話が長くなったら原文の記録をそのまま引きずらず、要点だけ取り出した要約版に差し替えるんです。長い会議のあとにアクションアイテムを数行にまとめるのと同じです。モデルが仕事に集中できるよう、机の上を時々片付けてあげるようなものです。

3. コンテキスト混乱: 道具が増えるほど選び間違える

モデルに「こんな道具もある、あんな道具もある」と山ほど教えると、肝心な道具をうまく選べなくなります。UCバークレーの関数呼び出しリーダーボードでも同じ結果が出ました。道具を1つだけ与えたときよりも、複数与えたときのほうがほとんどのモデルがより悪い結果を出したのです。

「Less is More」という研究はもっと具体的です。Llama 3.1 8Bモデルに46個の道具を全部見せたら丸ごと失敗したのに、同じモデルに関連度の高い19個だけに絞って見せたらうまくいった、という話です。コンテキストウィンドウに全部入っているのにそうなのです。問題は長さではなく「関係のない選択肢が多い」ことでした。

対処法はツール・ロードアウト管理(Tool Loadout Management)です。 ゲーマーが任務ごとに武器を選んで持っていくように、ユーザーの質問を見たうえで、それに合う道具2〜3個だけを絞ってモデルに教えるんです。興味深いことに、道具の説明をベクトルDBに入れてRAGで選んでもらう方法がよく効くそうです。結局、コンテキストエンジニアリングの原理をそれ自体に再び適用したわけです。

4. コンテキスト衝突: 自分の言葉とぶつかるモデル

最後がいちばん深刻な問題です。ユーザーが情報を一度に全部渡さず、複数ターンに分けて少しずつ投げると、モデルは情報が出揃う前に怪しい推測の答えを先に出してしまいます。そしてその粗い推測がまたコンテキストに残ります。あとで本当の情報が入ってきても、モデルは自分が前に言ったことと新しい情報のあいだで混乱しはじめます。

Microsoft・Salesforceの合同研究がまさにこれを測っていて、同じ情報を一度に渡すのに比べて複数ターンに分けて渡すと、平均で39%パフォーマンスが落ちました。 あるモデルは98%から64%まで下落しました。情報量は同じなのに、ただ「段階的に流れ込んだ」というだけで、です。

対処法は2つあります。

剪定: 間違った中間推測がコンテキストに残っているなら、次のターンを作るときにその部分を切り落とします。新しい情報が古い推測と争わないよう、先に片付けておくわけです。

オフロード: モデルが頭の中で回す中間思考を、別に作った「メモ帳」に移す方式です。AnthropicがClaudeに付けた think ツールが代表的ですね。最終的な答えを作るコンテキストからはそのメモ帳を外してしまうので、答えを出すときには「ごちゃごちゃした途中の計算」なしできれいな状態で作業します。Anthropicは、この方法だけで特定のエージェント作業で最大54%パフォーマンスが上がったと報告しています。

まとめ

ここまで見ると、コンテキストエンジニアリングが大ごとに見えるかもしれませんが、最初から全部揃えて始める必要はありません。小さく始めても十分に効きます。

• 社内チャットボットに「社内ウィキ検索」を一段だけ付けてみる(基本のRAG)

• 直近の対話を数ターンだけ覚える、小さなメモリバッファを付けてみる

• 動いているプロンプトの前に「このユーザーに関する一行サマリー」だけ差し込んでみる

そのあとは、「うちのAIには、自分の仕事をうまくやるためのコンテキストがすべて入っているか?」という問いを投げ続けるわけです。答えが「いいえ」なら、この記事が次の一歩をどこに踏み出すか教えてくれる地図だと思ってください。

良いモデル + 良いプロンプトの時代から、良いモデル + 良いコンテキストの時代へ移っています。ユーザーから見るとその差は「AIが本当に一緒に仕事してくれるな」 vs 「また忘れてる」くらい大きく感じられるんです。次のプロジェクトでは、モデルよりもコンテキストを先に整えてみることをおすすめします。

会議はコンテキストの最大の空白です

この記事の流れで、もう一つだけ付け加えさせてください。外部資料をモデルにうまく渡すことがコンテキストエンジニアリングの出発点だ、と言いましたが、実は多くの会社でいちばん重要な文脈はどこにもデジタル化されていません。

Notionにまとめられた文書、Slackに残ったメッセージ、Jiraのチケット ― これらは会社の文脈の10%くらいでしかありません。残りの90%は会議で出た決定、「なぜそう決めたか」の理由、誰かがふと漏らした懸念 ― つまり口頭で交わされたすべてです。そしてこの90%は会議が終わった瞬間に消えていきます。AIエージェントがどんなに優れたRAGで社内ウィキを検索しても、この場所には入っていけません。

Tiro が埋めようとしているのが、まさにその場所です。会議の音声を受け取って、AIエージェントがそのまま読める形(LLM-Ready Data)に変換しておく仕事をします。そしてそれを終わりではなく出発点にして、API・MCP・CLI・Skillという4つの道筋でエージェントがそのデータに触れられるようにしています。

興味深いのは、この記事で扱ったコンテキスト崩壊のパターンがTiroの設計にもそのまま反映されている点です。コンテキスト混乱を防ぐためにMCPは Progressive Disclosure のパターンでトークンを段階的に使わせ(リスト → 要約 → 全文の順)、コンテキスト散逸を防ぐために大きな議事録はCLIでディスクに落として、メインのコンテキストにはレシートだけを残します。この記事で扱った原理が実際の製品設計に移されたときにどんな形になるか気になる方は、Tiroがビジネス文脈を記憶する方法 でさらに詳しく扱っています。

会社の会議データをAIエージェントとつないでみたい方は、下のリンクから始めてみてください。

はじめる