コンテキスト エンジニアリングの 80% はエージェント検索 — レオニー・モニガッティ / Elastic (AI Engineer Europe)

コンテキスト エンジニアリング (LLM のコンテキストウィンドウに何を入れるかを決める技術) の話題は、 ここ 1 年で急速に立ち上がった。 Leonie はこのテーマを 「80% はエージェント検索」 と切り取って、 1 時間のライブワークショップで体系化していく。 固定 RAG → エージェント RAG → 多ソース対応 → 専用ツール群、 という設計の進化を、 失敗パターンと対処法のセットで具体的に示す回。

語るのは レオニー・モニガッティ (Leonie Monigatti) — Elastic (Elasticsearch を運営する企業) の Developer Advocate。 元 Weaviate (ベクトルデータベース企業) で同じく Developer Advocate を務めた経歴を持ち、 Elasticsearch Labs に 「Search tools for context engineering」 「Database retrieval tools for context engineering」 「Agent Journey Map」 など、 業界で参照される一連のテクニカルブログを寄稿している。 検索ベースのエージェント構築という横断テーマで開発者向け教育を担当する立ち位置。

話は 「過去 3 年の歴史」 で始まる。 RAG は当初、 ユーザーメッセージをそのまま検索クエリにして DB から取得 → コンテキストに足す、 という固定パイプライン。 これが 「実際に必要かに関係なく毎回検索する」 「マルチホップが必要なときに 1 回しか引けない」 という限界に当たり、 検索が 「ツール」 として独立する。 エージェントが状況を見て呼ぶか呼ばないかを判断する、 というのが現在のエージェント検索。 ここまでが地ならし。

本題は 「エージェント検索が現場で壊れる 3 つのパターン」。 (1) エージェントがツールを呼ばない (= 自分のパラメトリック知識で答えられると判断する)、 (2) 違うツールを呼ぶ (例: Web 検索を呼んでほしくないのにそれを呼ぶ)、 (3) ツール呼びはするがパラメータが間違う。 これに対する処方箋として、 ツール記述の書き方 (中心目的 → パラメータ → トリガー条件 → 他ツールとの関係)、 システムプロンプトでの強化、 そして Anthropic Skills 系の 進歩的開示 (skill loading) を Elasticsearch ESQL の実例で示す。

着眼点

「エージェントは物を数えるのが苦手で有名」 から始まる集計外部化の話 (34:07)

AI Engineer Europe 自体のスケジュールデータを Elasticsearch に入れて、 「4 月 8 日のセッションは何回ある?」 を ESQL で集計させるデモ。 「LLM はカウントが苦手で有名なので、 検索ツール側で aggregation を実行させて結果だけ返す」 という設計が示される。 27 セッション、 という具体的な数字を ESQL の COUNT で正しく返した瞬間、 「カウントを LLM にやらせない、 検索ツールに外注する」 という整理が一気に腑に落ちる。 デモの題材がこのワークショップの開催スケジュールそのもの、 という入れ子構造も気が利いている。

3 つの失敗モード × ツール記述の処方箋 (10:00 - 12:30)

「ツールを呼ばない」 「間違ったツールを呼ぶ」 「パラメータを生成できない」 という 3 つの失敗を整理した上で、 ツール記述に何を書くかの段階的レシピを示す。 一文の最小限から始めて、 (1) 中心目的、 (2) パラメータ説明、 (3) トリガー条件 (このツールを 「いつ使う / 使わない」)、 (4) 他ツールとの関係 (「先にこのスキルを呼んでから」 「このツールの前に確認を取る」)、 という順で厚くする。 完璧なツール記述でも直らないなら、 システムプロンプトで重ねて指示する。 「Web 検索ツールを呼ばないようにエージェントを訓練するのが最も難しかった」 という同僚の証言が、 Leonie の整理の説得力を支える。

「低い床と高い天井」 = エージェントツール設計の良し悪し基準 (47:11)

講演後半で示される実用的な指針。 低い床 (low floor) = エージェントが間違わずに使える、 ミスが少ない、 効率的、 ツールを何度も実行する必要がない。 高い天井 (high ceiling) = 予期しない複雑なクエリでもエージェントがその場で対応できる、 専用の限定的ツールだけで突破できなかった部分を捌ける。 セマンティック検索ツールが床の例、 シェルツールや汎用クエリ実行ツールが天井の例、 というふうに具体例で示す。 推奨の進め方 = 「エージェントの動作がまだわからないなら汎用ツールから始めて、 ログを取って、 4-5 回ツール呼びが連発するパターンを見つけたら専用ツールに切り出す」 という運用ルール。 ユーザーエクスペリエンス論の用語が、 そのままエージェントツール設計に流用されているのが面白い。

「Elasticsearch ESQL スキルロード」 で進歩的開示を実演 (29:43 - 33:00)

Anthropic の Skills 設計と同じ進歩的開示 (progressive disclosure) を、 Elasticsearch クライアントで実装する具体例。 ツールの本体は汎用検索だが、 ツール記述に 「先に Elasticsearch ESQL スキルをロードしてから使え」 と書き、 LLM ミドルウェアでスキル本体を必要に応じてコンテキストに注入する。 ESQL の構文ルール (二重引用符、 ワイルドカードパターン等) を Skill ファイルに書いておくことで、 エージェントが正しい ESQL を生成できるようになる、 という流れを実演で見せる。 同会場で Sam (Mistral) や Luke (ElevenLabs) が 「ローンチ時には Anthropic Skills 同梱予定」 と言及しており、 Skills が業界の共通基盤として広がりつつある現状が、 別企業 (Elastic) の実装という形で確認できる回。

動画の構成

• (00:00) 自己紹介、 ワークショップの目的
• (01:20) コンテキスト エンジニアリングとは何か — コンテキストソースからウィンドウへの選択技術
• (02:12) 「コンテキスト エンジニアリングの 80% はエージェント検索」
• (02:24) 過去 3 年の歴史 — 固定 RAG の登場と限界
• (03:46) エージェント RAG への移行 — 検索が 「ツール」 として独立
• (04:23) コンテキストソースの拡大 — ローカルファイル、 ワーキングメモリ (スクラッチパッド)、 DB
• (08:04) 「適切な検索を行うのは非常に難しい」 — 検索手法のバリエーション
• (08:55) ベクトル / キーワード、 dense / sparse / multi-vector embeddings
• (09:00) エージェント検索が現場で壊れる 3 つのパターン
• (10:00) 失敗 1: ツールを呼ばない、 失敗 2: 違うツールを呼ぶ、 失敗 3: パラメータが間違う
• (11:00) ツール記述の段階的レシピ — 中心目的 → パラメータ → トリガー → 関係
• (11:50) システムプロンプトで強化
• (12:00) パラメータ複雑性への対処
• (29:43) 進歩的開示 (progressive disclosure) と Skills
• (30:30) Elasticsearch ESQL スキルロードの実演
• (32:00) ESQL 集計の実演 — 「4 月 8 日のセッションは何回?」 → 27
• (34:07) 「エージェントは物を数えるのが苦手」 — 集計を検索ツールに外注する設計
• (45:30) 「低い床と高い天井」 のツール設計指針
• (47:11) 推奨運用 — 汎用ツールから始めてログから専用ツールに切り出す
• (48:50) Q&A — 必要なツールスタックはモデル次第か

出典

Agentic Search for Context Engineering — Leonie Monigatti, Elastic (AI Engineer)