はじめに
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の導入検討から活用定着まで、課題に応じた支援メニューをご紹介しています。
「何から着手すべきか相談したい」という段階でも、お気軽にご覧ください。