はじめに

2026年6月15日~18日サンフランシスコ・バーチャルにて開催されるDatabricks社主催の年間最大規模のカンファレンスイベント、「Databricks Data＋AI Summit 2026」（DAIS）が開催されました。
本記事はDAIS2026 How to Solve the Context Gap: Engineering Reliable AI Agents で発表された、信頼できるAIエージェントを構築・スケールさせるための「コンテキスト設計（Context Engineering）」のベストプラクティスに関するセッションレポートになります。

登壇者はDatabricksのForward Deployment Engineer（FDE）チームから、Pradeep Ravi 氏（AI FDE チームマネージャー） と Bader Slimani 氏 の2名。メディア・エンタメ、グローバルエネルギー、人材ソリューションなど多業界での実装経験をもとに、現場で効くコンテキスト管理の知見が共有されました。

本記事はDatabricks公式発表を元にした非公式の日本語要約であり、すべての著作権・知的財産権はDatabricksに帰属します。

忙しい方用（3行まとめ）

「コンテキストは長ければ強い」は誤り：コンテキストウィンドウは数千→1,000万トークンに拡大したが、長くするほど性能は劣化する（＝Context Gap）。
解くべきは「何を・どの形式で・いつ渡すか」：指示／ツール定義／ツール結果／会話履歴という“コンテキストの種類”ごとに最適化する。Tool Search・Progressive Disclosure・Compaction などが具体策。
スケールの鍵は「外部メモリ＋決定論的設計」：エピソード/セマンティックメモリ、Lakebase、Genie Ontology、Unity Catalogガバナンスで本番運用へ。「モデルはもはやボトルネックではない。ボトルネックはモデルを取り巻くハーネス（設計）」。

この記事のポイント（誰向け・何が持ち帰れるか）

誰向け：RAG／AIエージェントを本番運用しようとしているエンジニア・データ基盤担当者
新しさ：「長いコンテキスト＝高性能」という前提への明確な反証と、それを乗り越える具体テクニック群
持ち帰れる示唆：コンテキストを「量」ではなく「種類×設計」で捉え直す視点と、Databricks製品（Lakebase / Genie Ontology / Agent Bricks / Unity AI Gateway）への実装マッピング

背景：なぜ「Context Gap」が生まれるのか

LLMが一度に扱えるトークン量の上限が コンテキストウィンドウ です。これは年々拡大してきました。

時期	コンテキストウィンドウの規模
2020年代初頭	数千トークン
現在	100万〜1,000万トークン

しかしセッション冒頭で投げかけられた問いはこうです。

「コンテキストを長く詰め込むほど、本当に性能は上がるのか？」→ 答えはNo。

Needle in a Haystack（干し草の中の針）が示すこと

長文の中に埋め込んだ情報を取り出せるかを試す古典的テスト「Needle in a Haystack」では、近年のモデルは高精度を達成しています。

ところが、曖昧な質問ペアやディストラクター（注意をそらすノイズ）を加えると、精度は急激に劣化します。しかもこれは特定モデルだけでなく、最先端モデルを含む全モデルファミリーで共通して起こる現象です。劣化のスピードに差はあれど、

「性能はコンテキスト長全体にわたって一様ではない」

という原則は変わりません。これがContext Gapの本質です。

【前半／Bader氏】コンテキストの“種類別”最適化 7つの実践

エージェントのコンテキストウィンドウを埋める要素は、かつては「システムプロンプト＋ユーザー入力」だけでした。しかし現在のツール装備エージェントでは、以下が積み重なります。

システム指示（instructions）
ツール／MCP定義
ツール呼び出し結果
（外部）メモリ
増え続ける会話履歴

これらを種類ごとに最適化するのが本セッションの骨子です。

① 指示（Instructions）：広すぎず・狭すぎず

広すぎる：曖昧で情報不足。モデルが文脈を補えず挙動が定まらない。
狭すぎる：if-else的にエッジケースを全部ハードコード。汎化できなくなる。
ちょうど良い：方向づけに足る具体性は持たせつつ、推論の余地を残す。全エッジケースの列挙ではなく、厳選した代表例（canonical examples）を少数提示。

鉄則：「最小から始めて、計測し、少しずつ足す」。
補助ツールとして MLflow のプロンプト最適化（GEPAアルゴリズム） が紹介されました。

② ツール／MCP定義：名前・説明・スキーマが命

ツールを使う理由は、決定論的で厳密な処理をコードにオフロードするため。計算は計算ツールに任せ、モデルに丸投げしない。Web検索や外部DB読み取りなど、ライブ／外部コンテキストへの拡張にも有効。MCPはこれらを標準化し再利用可能にする仕組み。

ポイントは、ツールの名前・説明・入力スキーマを丁寧に設計すること。これがモデルの「何を・いつ使うか」の判断材料になります。

③ ツール定義はまとめる：注意の競合を避ける

query / get_data / run のように似た役割のツールを乱立させると、モデルの注意（attention）が競合します。

→ 明確な名前・説明・入力スキーマを持つ単一の集約ツールにまとめた方が、モデルは速く正確に選べます。namespaceで明確に分離された少数の良設計ツールを優先しましょう。

④ ツール結果（Returns）：ハルシネーションの主因を断つ

ツール結果はエージェントの幻覚・エラーの大きな発生源。特にマルチエージェント構成で顕著です（参考論文：From Spark to Fire）。会話の10ターン目で、過去のツール結果の誤りが「事実」として扱われてしまう問題が起こります。

実践策：

生の出力（例：20万トークンの巨大ダンプ）をそのまま返さない
暗号のようなエラーメッセージをそのまま戻さない
要約・整形し、型付け・検証してからコンテキストに戻す
エラー時は「列名が不正なので修正して再試行せよ」といったactionableなヒントを返す

⑤ Progressive Disclosure（段階的開示）：会話履歴の肥大化を抑える

急増する会話履歴を抑える鍵が「段階的開示」。

Skills（skills.md形式）：単なるmarkdownだけでなくフォルダ・スクリプトも含み、トークン量は膨らみがち。しかし動的にロードされる。まずフロントマター（最小70トークン程度）だけ読み込み、必要と判断された時だけフル展開。→ 数十のSkillを「1つフル展開する分のコスト」で発見でき、数千トークンの節約に。
Tool Search：全ツールから今のタスクに最も関連するものをモデルに検索させ、全ロードを避ける。
Genie Space Search：裏側でどのGenie Spaceをロードすべきか先に判断し、全Space同時ロードを回避。

⑥ Programmable Scratchpad（プログラム可能なスクラッチパッド）

Anthropicの「Programmatic Tool Calling」に相当する概念。複数ツールを「呼ぶ→テキスト直列化→戻す→次を呼ぶ」と繰り返すのは非効率。

→ モデルにPythonカーネルを与え、ツールの組み合わせ・整形・検証をコード上で行い、最終結果だけをコンテキストに戻す。直列化の往復を削減できます。Databricks内部研究では Memex（Code as Actionファミリー） として紹介。フロンティアモデル・OSSモデル双方で精度が時に2倍、コストは削減という結果が示されました。

⑦ Compaction & マルチエージェント：会話履歴に「何を残すか」

10〜15ターンも進むと、過去の生ツールダンプや冗長なリトライは不要。一方で、過去の意思決定・実装詳細は後のターンで必要になることも。

Compaction：コンテキスト上限に近づいたら要約して再初期化（コーディングツールで見かける挙動）。ただし万能ではなくアルゴリズム依存。重要な決定は手動で新コンテキストに再投入する判断も必要。
マルチエージェント：namespace分離した別エージェント／サブエージェントを空のコンテキストから開始。並列性・速度の利点があるが、複雑性という代償も。単一エージェントで限界に達した時だけ採用。

デモ：Tool Search vs フルカタログ

顧客サクセス向けエージェント（顧客情報取得・解約・更新などのツール群）で比較。

すべてのエージェントの基本は Agent Loop（システム/ユーザーメッセージの配列をループでモデルに渡し、最終回答かツール呼び出しかを判断する）。

観点	フルカタログ投入	Tool Search
精度（数十ツール時）	良好	良好
平均ツール呼び出し回数	基準	+1回（検索分）
トークン使用量	多い	大幅に少ない
数百ツールに拡大時	レイテンシ倍増・トークン急増・精度低下	精度維持・トークン抑制

結論：同じモデルでも、コンテキストへの入力を絞る設計の方が、低コスト・低レイテンシ・高精度（特に複雑タスク・超長文脈で顕著）。

前半の核心メッセージ

「Office QAのようなエンタープライズタスクのベンチマークでは、もはやモデルがボトルネックではない。ボトルネックはモデルを取り巻くハーネス（harness）と、コンテキスト管理である。」

だからこそ Meta Harness や Genie Ontology の発表が重要になる、と後半へ橋渡しされました。

【後半／Pradeep氏】信頼できるエージェントを“スケール”させる

思考実験：「記憶のない人間」

記憶がなければ、あらゆる意思決定をゼロから行うことになり、良い判断はできません。これはエージェントも同じ。設計時に特に注意すべきは2点。

(1) Planning（計画）：巨大プロンプトを投げない

複雑タスクを原子レベル（関数・コード単位）に分解し、各ステップにValidation Gate（検証ゲート）を設ける。1ステップ解けたら次へ進む、という決定論的な進め方にする。

例：リサーチエージェントに巨大プロンプトで「新規性のある研究をして」と頼むとハルシネーションになりがち。代わりにステップ分解してplan.mdに記録し、各ステップを検証する。これがコンテキスト節約にもなる。

(2) Memory（外部メモリ化）：1人用でなくN人用に

スケールにはコンテキストの外部化が必須。人間の記憶になぞらえた2種類：

エピソードメモリ（episodic）：日々の出来事の記録（タイムスタンプ付き）。意思決定時の「例」になる。
セマンティックメモリ（semantic）：学習した「ルール」。
意思決定には- 意思決定には「ルール（semantic）＋例（episodic）」の両方が必要。

個人 vs 組織の使い分けも重要。給与情報を全社に開示したくないように、Unity Catalogで細粒度のアクセス制御を行う。個人データは個人に、組織共通データは全社に。

メモリスケールの実験結果

軽量RAGフレームワーク Memaline で10ドメイン（10 Genie Space）を検証。

人手キュレーションのベースライン精度：5%
メモリを段階的に増やすと精度は70%まで到達
さらに推論ステップ数は20→5に減少 → モデル依存度が下がり、より安価なモデルへの差し替え余地が生まれる

メモリが多いほど推論能力・知能が上がり、かつ安いモデルでも回せるようになる。

Lakebase：ステートフルエージェントの高速バックエンド

Databricksのマネージド Postgres。ストレージとコンピュートを分離したユニークなアーキテクチャにより：

書き込みレイテンシ 5分の1
Scale to Zero：不使用時はゼロにスケールしコスト削減、問い合わせが来たら即スケールアップ

また、コンテキストの課題はエージェントだけでなくクラシカルなML（レコメンド・不正検知・パーソナライズ）にも存在。Feature Serving エンドポイントがリアルタイムにコンテキストを供給します。

Evaluation（評価）：システムでなく「関数単位」で

評価はシステム全体でなく、原子的アクション（関数）単位で行う
MLflow Tracing でコードを計装し、問題箇所をツール呼び出し/メモリ/コンポーネントのどこかまで特定できる可観測性を持つ
LLM-as-a-Judge は有効だが、明確なルーブリックで「測り方」を教え込む必要がある
CI/CD：プロンプトの小変更でも、ゴールデンデータで回帰テスト一式を回し、リグレッション/統合影響を検知
Length-Accuracy Pareto View：長い応答がJudgeを「正しい」と誤認させるのを見抜く手法

「ゼロから作らない」：Databricksマネージドサービスの活用

Agent Bricks Knowledge Assistant：RAGエージェントのGo-toソリューション。コンテキストエンジニアリング/継続学習が組み込み済み。人間は適切な指示と設定をするだけ。
TAO：強化学習による自動最適化。報酬機構＋複数Judge＋フィードバックループで継続学習。グラフではAgent Bricksが継続的計画で自己ベストを更新（77%→80%）。
エージェントからの学習：ドキュメント化されたコンテキストは取り込めるが、個人の頭の中の暗黙知はインタラクションで取り込む。例：生成SQLに対しSMEが「Databricks SQL互換にして」とフィードバック→修正版を生成し、エピソード/セマンティックメモリを構築。

Genie Ontology：スキーマブラインドネスの解消

Genie Spaceはもはやtext-to-SQL専用ではありません。Ontology が中核に。

ワークスペースの全アセット/オブジェクトを自動的に学習
Unity Catalogのビジネスセマンティクスからビジネス文脈を理解
その上にナレッジグラフを構築・インデックス化し、Genie Spaceへ入力

→ スキーマブラインドネスを解消。エージェントは扱うスキーマを最初から把握。「推測する（guessing＝コンテキスト浪費）システム」から「決定論的なシステム（正確な結果・低コスト）」へ。

Genie Spaceの決定論化を支える機能：

Business Metrics：自前の定義済み数式（その場で生成しない）
Dimensions：実行時に適用される次元
Data Modeling：テーブル間のリレーション定義
Trusted Assets：頻出する約50問の質問/SQLを資産化。再生成せず例として再利用（＝トラステッドアセットによるセマンティックメモリ構築）

本番運用のガバナンス

Guardrails：PII等の不適切コンテンツをredact。カスタムポリシーもプロンプトで定義可能
Runaway Agent対策（Unity AI Gateway）：QPM/TPM・予算上限を設定（例：あるチームに月$500の上限）
コーディングエージェントのトークン追跡：「生産性 vs 消費トークン」を常に比較。1トークンもコストである

推奨される実装シーケンス

まず組み込みから：Agent Bricks / Genie / AI Functions / ソリューションアクセラレータ。多くはこれで解決
カスタムが必要なら AI Playground でプロトタイピング：複数モデル・プロンプト・ツール・MCPを試す → 納得したらコードとしてexport → Apps にデプロイ
いきなりコーディングしない。Playgroundで遊んでから反復
既存エージェントがある場合は、Databricks Apps にデプロイしインターフェースを作るだけでテスト可能

去年（DAIS2025）との比較で見る位置づけ

DAIS2025：Agent Bricks など「エージェントをどう作るか／どうスケールさせるか」が中心。
DAIS2026（本セッション）：作れる前提で、「どうすれば信頼でき（reliable）、本番でスケールするエージェントになるか」へ論点が深化。鍵はコンテキスト設計と、それを支えるプラットフォーム（Lakebase / Genie Ontology / Meta Harness / Unity AI Gateway）。

「作る」から「信頼して本番で任せる」へ——この1年の関心の深化が、タイトル Engineering Reliable AI Agents に表れています。

まとめ（この記事の持ち帰り）

長文コンテキスト＝高性能ではない。複雑性が増すと全モデルで精度は劣化する（Context Gap）。
コンテキストは「種類（指示/ツール定義/ツール結果/会話履歴）」ごとに最適化する。Tool Search・Progressive Disclosure・Programmable Scratchpad・Compaction が具体策。
スケールには外部メモリ（エピソード/セマンティック）と決定論的設計が不可欠。Memaline実験では精度5%→70%、推論ステップ20→5。
モデルはボトルネックではない。ハーネス（設計）がボトルネック。
Databricksなら Lakebase / Genie Ontology / Agent Bricks / Unity Catalog / Unity AI Gateway で、設計・メモリ・ガバナンスを一気通貫で実装できる。
実装は組み込み → Playground → Apps の順で。いきなりコードを書かない。

最後に登壇者からの案内として、Databricksがコンテキストエンジニアリングに関する公式コースを公開したとのこと。本テーマを体系的に学びたい方はチェックを推奨します。

お知らせ

ナレッジコミュニケーションでは、Databricks Data + AI Summit 2026 開催に伴い、日本語でのウェビナーや現地レポートを公開しております！

DAIS2026 Recap イベント
現地参加が難しかった方や、主要トピックスを短時間で振り返りたい方向けに、Recapイベントを開催します。
セッションの要点整理や、日本企業での実装観点も交えてご紹介予定です。

▼ 開催概要・お申し込みはこちら

ナレッジコミュニケーション DAIS2026 特設サイト
DAIS2026で発表された注目テーマ、関連セッション、実務での活用ポイントを継続的に発信する特設ページです。
イベント情報の整理・社内共有にもご活用いただけます。

Databricks 導入支援サービスサイト
Databricksの導入検討から活用定着まで、課題に応じた支援メニューをご紹介しています。
「何から着手すべきか相談したい」という段階でも、お気軽にご覧ください。