6月25日、Redisが「Context engineering vs prompt engineering: the difference」と題した記事を公開した。この記事では、プロダクション環境のAIエージェントにおいてプロンプトエンジニアリングではなくコンテキストエンジニアリングが本質的な課題解決につながる理由について詳しく紹介されている。以下に、その内容を紹介する。
「プロンプトを直す」という反射が罠になる
記事の冒頭で示される例が鋭い。カスタマーサポートエージェントが「返金は完了しています」と答える。確認番号まで提示する。だが実際には20分前に返金がバウンスバックしていた。エージェントが参照したデータストアは夜間にしか同期されないものだった。
チームの次の行動は「システムプロンプトを修正する」だ。「回答前に必ず最新のトランザクション状態を確認すること」と書き加える。次のチケットで、同じ失敗が起きる。プロンプトは問題の所在ではなかったからだ。
この「出力がおかしいのでプロンプトを書き直す」という反射こそが、多くのチームが陥る罠だと記事は指摘する。失敗の原因はプロンプトの周囲にある。エージェントが答えを出す瞬間に参照しているデータや履歴の側に。
プロンプトエンジニアリングとコンテキストエンジニアリングの違い
記事は両者の定義を明確に分ける。
プロンプトエンジニアリングは、モデルに渡すもの（システムメッセージ、例示、フォーマット指示）を書く技術だ。単一のモデル呼び出しをうまく操作する。それ自体は今も価値があるが、スコープが限られている。
コンテキストエンジニアリングはより広い概念で、LLM推論中のトークン（文脈情報）を管理・整備するための戦略の総体だ。コンテキストウィンドウに入るプロンプト以外のすべて、つまり取得した文書、メモリ、ツールの出力、ユーザーの状態などを扱う。
記事の定式化は明快だ：「プロンプトエンジニアリングはモデルにどう指示するかの問題。コンテキストエンジニアリングはモデルが答えるときに何を知っているかの問題。」プロンプトはコンテキストの一部に過ぎず、逆は成立しない。
なぜプロンプトはスケールしないか
単一ターン・完結型のタスクではプロンプト最適化が効いた。しかしマルチステップのエージェントはその前提を崩す。
記事が挙げるプロダクションでの典型的な失敗パターンは以下の3つだ。
- ツールセットの肥大化：エージェントに渡すツールが多すぎると、選択肢が広くなりすぎて誤った選択が増える
- メモリの欠如：モデルはコンテキストウィンドウの外を覚えていない。会話や複数ステップにまたがる処理では、プロンプト単体では対処できない
- 壊れたリトリーバル（検索・取得）：どれだけ完璧なプロンプトを書いても、取得パイプラインが壊れていれば補えない
「I want to cancel my subscription」は処理できても「please end my plan」でつまずくような感度の問題は、言い回しの問題ではなくコンテキストの構造の問題だと記事は述べる。
コンテキストはランタイムで組み立てられる
エージェントのコンテキストウィンドウは3つの要素から成る。
- Instructions：システムプロンプト、few-shotの例、ツールの説明など
- Knowledge：RAG（検索拡張生成）で取得した文書など、モデルが学習時に持っていない情報
- Tools：外部のAPI、関数、MCP（Model Context Protocol）サーバーの定義
重要なのは、これらは設計時ではなくランタイム（実行時）に組み立てられる点だ。モデルが呼ばれる直前に、コードが関連文書を取得し、メモリの適切なスライスをロードし、必要なツールをアタッチし、収まらない情報を刈り込む。この「組み立てステップ」がベクターデータベース、API、メモリストアなどのライブソースに触れる部分であり、プロンプトには物理的にできない仕事だ。
ステールなデータはインフラ問題である
記事が「インフラの問題」と明言する点は重要だ。エージェントが自信を持って答えた情報が3日前のものだった、あるいは完了済みのワークフローを再実行した、という失敗はデータの鮮度と断片化から来る。
多くのデータスタックは人間向けのバッチ処理（夜間同期、日次リフレッシュ）を前提に作られている。エージェントはそれより新鮮なデータを必要とする。古い在庫データに基づいて購買判断を下すエージェントはビジネスリスクそのものだ。
また、顧客情報、ポリシー、製品データは異なるシステムに分散している。これらを数千の同時ユーザーに対して一貫性を保ちながら高速にウィンドウへ集約することは、並行処理・一貫性・耐久性の問題であり、プロンプトもモデルも解決できない。
コンテキストエンジンという概念
記事はこの組み立てレイヤーを「コンテキストエンジン」と呼ぶ。Redisは自社製品Redis Irisをその実装として位置づけており、以下を一つのプラットフォームに統合している。
- Context Retriever：クエリをベクター埋め込みに変換し、類似チャンクをモデルに渡す
- LangCache：セマンティックキャッシング（完全一致でなく意味的類似度でキャッシュヒット判定）。ある評価ではAPIコールを最大68.8%削減したと報告されている
- Agent Memory：短期・長期メモリの管理と、何を長期記憶へ昇格させるかの統合ルール
- Redis Data Integration：オペレーショナルデータの鮮度維持
記事が指摘するのは、メモリとリトリーバルを同一レイヤーに置くことで、デュアルライト問題（2つのストアが徐々にずれていく問題）を回避できる点だ。「名前は覚えているがアカウント残高を捏造するエージェント」という失敗は、プロンプトではなくアーキテクチャで防ぐものだ。
「コンテキストエンジニア」という役割の出現
記事の締めくくりで、現場の実務が変化していると述べる。チームが問いかける言葉が変わった。「どう言葉を選ぶか」ではなく「各ステップでモデルが何を知っている必要があるか」へ。
リトリーバルパイプライン、メモリシステム、ツール設計、評価を横断するこの仕事は、プロンプト執筆よりシステムエンジニアリングに近い。記事はこれを「コンテキストエンジニア」という新しい役割として定義する。
「デモでは動くのにプロダクションで壊れる」エージェントの次の修正箇所は、おそらくプロンプトではない、というのが記事の結論だ。
詳細はContext engineering vs prompt engineering: the differenceを参照していただきたい。
