【Data + AI Summit 2026 – セッションレポート】An Intro to Building and Scaling Agentic Apps 日本語要約|構築とスケールの要点

はじめに

2026年6月15日~18日サンフランシスコ・バーチャルにて開催されるDatabricks社主催の年間最大規模のカンファレンスイベント、「 Databricks Data+AI Summit 2026 」(DAIS)が開催されました。

本記事はDAIS2026  An Intro to Building and Scaling Agentic Apps  で発表された、セッション内容の日本語要約になります。

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

DAIS20266.jpeg

忙しい方用

  • エージェントは個人で試すだけなら簡単に作れるが、業務で使うには別の難しさがある
  • 実運用では、誰が使えるか、どのデータに触れてよいか、履歴をどう残すか、どう評価して改善するか が重要になる
  • Databricks では、Agent Bricks(構築) / Databricks Apps(配布) / Lakebase(状態管理) / MLflow(評価) を組み合わせて、業務アプリとしての運用を目指す
  • ツール接続は、自由度を広げすぎず、必要最小限の関数だけをMCP経由で安全に公開する設計がポイント
  • デモでは、会話シミュレーションやLLM Judgeを使ってエージェントの失敗を見つけ、プロンプト修正で改善する流れが示された
  • 結論として、エージェントは「賢さ」だけでなく、安全性・監査性・継続改善の仕組みまで含めて設計することが重要

1. エージェントは「作る」だけでは不十分

生成AIのエージェントは、個人で試すだけならかなり簡単に作れるようになってきました。

ただし、実際にチームや顧客向けに使おうとすると、話は一気に難しくなります。

たとえば、次のような課題があります。

  • 誰が使えるのかを制御したい
  • どのデータにアクセスしてよいかを限定したい
  • 会話履歴を残したい
  • 何が起きたかを追えるようにしたい
  • 本番環境で安定して動かしたい

このセッションでは、こうした課題に対して、Databricks上でエージェントを業務アプリとして構築・運用する考え方が紹介されました。

2. 全体像は「作る・届ける・記憶する」の3層

このセッションでは、エージェントを支える仕組みを大きく3つに分けて説明していました。

図1:Agent Bricks / Databricks Apps / Lakebase を中心とした全体構成
  • Agent Bricks
    エージェントを作るための基盤・LLMやツール、コンテキストを扱う中心部分
  • Databricks Apps
    作ったエージェントをユーザーに届けるためのアプリ層。
    単なるデモではなく、実際に使う画面やAPIを提供する。
  • Lakebase/Lakehouse
    • Lakebase
      エージェントの記憶や状態を保持するための保存層。
      管理されたPostgresとして、会話履歴やセッション情報を扱います。
    • Lakehouse
      エージェントが参照・分析する業務データの基盤。
      商品情報、注文情報、ログ、評価データなどを安全に扱う土台です。

この3つを分けて考えることで、

「ローカルで動く」だけでなく、「業務で継続利用できる」エージェントに近づける、というのが大きなポイントでした。

3. ツールは広く開けすぎない

デモでは、TechMartという架空の会社を例に、顧客サポート用のエージェントを作る流れが紹介されました。

このとき重要だったのは、エージェントに何でも自由にやらせないことです。

たとえば、商品情報や注文情報にアクセスさせることはできますが、顧客向けにそのまま広く開放するとリスクがあります。

そこで使われていたのが、Unity Catalogの関数を小さなツールとして定義し、それをMCP経由で公開する方法です。

図3:Databricks が管理する MCP server を通じて、Unity Catalog の関数を安全に公開する構成
これは簡単にいうと、

『エージェントに渡す操作を、必要最低限のものだけに絞る』という考え方です。

Text-to-SQLのように自由度が高い方法は便利ですが、

顧客向けの業務アプリでは、誤った情報を広く見にいってしまうおそれがあります。

そのため、今回のように用途ごとに機能を制限する設計が大事だと説明されていました。

4. エージェントはアプリとして届ける

エージェントを実際に使ってもらうには、単にチャット画面があるだけでは足りません。

ユーザーが日常業務の中で自然に使えるようにするには、アプリとしての形が必要です。

そこで登場するのが Databricks Apps です。

Databricks Appsは、エージェントをユーザー向けに配布するための土台として使われます。

このセッションでは、エージェントを

「裏側で動く知能」ではなく、「業務の中に組み込まれたアプリ」 として考えることが強調されていました。

図4:Databricks Apps による業務アプリとしての提供
つまり、エージェントの価値は、どれだけ賢いか よりも、安全に・安定して・どれだけ実務に組み込めるかで決まる、ということです

5. エージェントに記憶を持たせる

エージェントを本番で使うときには、会話履歴やセッション情報を残したい場面が多くあります。

たとえば、前回のやり取りを引き継いだり、監査用に記録を残したりする必要があります。

この役割を担うのが Lakebase です。

Lakebaseは管理されたPostgresとして動き、エージェントの状態や履歴を支えます。

図5:Lakebase による記憶・状態管理のイメージ
この仕組みがあると、
  • 会話の履歴をあとから確認できる
  • セッションごとの状態を追える
  • 本番環境を壊さずに改善を試しやすい

といったメリットがあります。

エージェントは「一度答えれば終わり」ではなく、

継続的に使われる前提で設計する必要があるため、記憶の層はとても重要です。

6. エージェントは評価して育てる

このセッションで特に実践的だったのが、評価の回し方です。

エージェントは一度作っただけでは、本当にうまく動くかどうか分かりません。

そのため、継続的に評価して改善する仕組みが必要になります。

ここで使われていたのが MLflow です。

MLflowでは、エージェントのトレースを記録したり、評価結果を見たりできます。

デモでは次の流れが紹介されました。

Conversation Simulator でテスト会話を自動生成する

↓

その会話をもとに eval dataset を作る

↓

LLM Judge で回答を評価する

↓

問題があれば プロンプトやツール設定を修正する

↓

再度評価して改善を確認する

この流れがあることで、

「なんとなく動く」ではなく、「どこが弱いかを見ながら改善できる」 ようになります。

7. デモで見えた“ありがちな失敗”

TechMartの顧客サポートエージェントのデモでは、実際に起こりそうな失敗例も紹介されました。

たとえば、

  • 廃番商品の在庫を、まだ販売中のように答えてしまう
  • メーカー保証と、自社の返品ポリシーを混同してしまう
  • 顧客に押されると、ルールを破るような返答をしてしまう

こうした失敗は、最初の数回の手動テストでは見つけにくいです。

だからこそ、評価データセットを作って継続的に試すことが大切だと説明されていました。

実際に、返品ポリシーとメーカー保証を混同してしまった回答は、プロンプトを改善することで正しい応答に直されていました。

この例からわかるのは、

エージェントの品質は“1回のデモ成功”ではなく、 継続的な改善ループで作られるということです。

図7:agent ops loop の全体像

8. 今年は「どう運用するか」が主役

今回のセッションで印象的だったのは、

エージェントを「作る」話よりも、「どう業務で運用するか」 に重点が置かれていたことです。

特に次の点が、このセッションらしいポイントでした。

  • 何でもできるエージェントではなく、制御されたエージェントが重要
  • チャット単体ではなく、アプリとして配布することが重要
  • 評価と監視を含めて、本番運用の仕組みが必要
  • ツール接続はMCPのような標準化された方法で扱う

つまり、エージェントは単なるAI機能ではなく、

業務システムの一部として設計する段階に入っている ことがよくわかるセッションでした。

9. 実務で考えるならどう見るか

自社でエージェントを導入する場合も、まず考えるべきは

何を賢くするか ではなく、 どこまで安全に任せられるか です。

最初から大きく作ろうとするより、次の順番が現実的です。

  • 対象業務を絞る
  • 使えるツールを限定する
  • 履歴とログを残す
  • 評価データを作る
  • 改善ループを回す

この順番で進めると、PoCで止まらず、実運用につなげやすくなります。

10. まとめ

このセッションでは、エージェントを単体で作るのではなく、

Agent Bricksを中心に、Databricks Apps、Lakebase、MLflowを組み合わせて業務アプリとして成立させる方法が紹介されました。

ポイントをひとことで言うと、

エージェントは“賢さ”だけでなく、“安全に使える設計”が重要 ということです。

ローカルで動くデモを超えて、

実際の業務で使えるアプリにするための考え方が、非常にわかりやすく整理されたセッションでした。

お知らせ

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

DAIS2026 Recap イベント

現地参加が難しかった方や、主要トピックスを短時間で振り返りたい方向けに、Recapイベントを開催します。

セッションの要点整理や、日本企業での実装観点も交えてご紹介予定です。

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

ナレッジコミュニケーション DAIS2026 特設サイト

DAIS2026で発表された注目テーマ、関連セッション、実務での活用ポイントを継続的に発信する特設ページです。

イベント情報の整理・社内共有にもご活用いただけます。

Databricks 導入支援サービスサイト

Databricksの導入検討から活用定着まで、課題に応じた支援メニューをご紹介しています。

「何から着手すべきか相談したい」という段階でも、お気軽にご覧ください。

この記事を書いた人

azure-recipe-user