本稿は、2026/02/24に開催された「JEDAI Meetup! 2026年2月」の内容をまとめたものです。
https://jedai.connpass.com/event/383582/
「JEDAI Meetup!」は、Databricksユーザーグループによるミートアップであり、現地とオンラインのハイブリッド形式で開催されました。参加者同士のカジュアルな情報交換の場も設けられ、AIエージェントの運用、Open Semantic Interchange (OSI) の仕様、そしてDatabricks Declarative Pipeline (DCP) について、DATUM STUDIO 亀井友裕氏、星野玲央奈氏、Databricks 桑野 章弘氏の各氏を中心に議論が交わされました。
Databricksを活用したAIエージェント運用の実際
作成は容易、運用は「獣道」
AIエージェントの作成は、Databricksが提供するAI DevKitやAgent Bricksといったツールの登場により、かつてないほど容易になりました。実際に、会場では約半数の参加者がAIエージェントの作成経験を持つことが示されました。しかし、AIエージェントの「運用」となると状況は一変します。運用経験を持つ参加者はわずか1名程度に留まり、そのハードルの高さが浮き彫りになりました。運用フェーズはまだ整備されておらず、「獣道」のように手探りで行われているのが現状です。
運用タスクを支える4つの柱
AIエージェントの安定稼働と品質維持のためには、以下の4つの主要な運用タスクが不可欠です。
1. バージョン管理とデプロイメント
このタスクでは、エージェントのバージョン管理とデプロイが行われます。プロンプト、基盤モデル、ツールの方針、エージェントのコンポーネント差し替えに関するバージョンを適切に管理し、新しいツールへの切り替えや更新時に最新版をサービングエンドポイントで公開し、APIで利用可能にすることが目的です。外部ツールからのエージェント呼び出しや、モデルにエラーが発生した際の以前の安定バージョンへのロールバック、新しいバージョンのエージェントを試す際（例: ABテスト）に活用されます。
2. ロギングとトレーシング
エージェントの活動を詳細に記録し、可視化することを目的とするのがロギングとトレーシングです。エージェントへのリクエスト、ツールの呼び出し、応答が時系列で記録され、可視化されます。これにより、モニタリングで発生した問題の原因探索や、トレース内容を観察することでユーザー体験を深掘りし、改善機会を発見するのに役立ちます。
3. オンライン評価と「Judges」
リアルタイムでのエージェントの評価と監視に焦点を当てるのがオンライン評価です。リクエストデータのトレースをリアルタイムで評価・監視し、アプリケーションのドリフト（エージェントの振る舞いやユーザーからの問いの分布の変化）に気づかないリスクを軽減することが目的です。ユーザーからのリクエストに対する応答の質を逐一評価し（例: 質問と応答がうまくいったか、いかなかったか）、改善機会の発見や、特定のユーザー層からの質問にエージェントが適切に回答できていないなどの弱点となるユースケースの特定に繋げられます。
4. オフライン評価とベンチマーク
事前に定義された評価用データセットを用いた評価がオフライン評価です。事前に定義した評価用データセットを用いて、エージェント更新前後の品質変化を確認することが目的です。特定の振る舞いを確実にクリアするかを事前に定義したデータセットで確認するベンチマーク評価や、新しいモデルに更新する前に評価用データセットを与えてうまくいくか評価する際に活用されます。また、新しいバージョンが古いものより性能が劣化していないか、といった弱点となるユースケースの特定にも役立てられます。
AIエージェント運用の「あるべき姿」を人間が定義する重要性
Databricksは運用に役立つ機能を提供しますが、運用のあるべき姿は人間が決定する必要があると強く述べられています。運用を開始するためには、以下の前提条件を検討しなければなりません。
- どのメトリクスを集計するのか？このメトリクスでどのような失敗パターンを補足できるか？どのような失敗を避けたいか？
- LLM Judgesによる評価観点の決定。どの観点での品質を重視するのか（例: 社内エージェントなら安全性よりもハルシネーション対策を重視するなど）。
- 評価データの整備。どんな振る舞いを「良い」とするのか？どのようなユースケースを想定しているのか？
これらの問いは「理想のAIエージェントの姿」を決めなければ回答できません。そして、理想を決めないと、運用の前提条件が固まらず、運用自体を始めることができません。つまり、運用は「理想の姿」を定義することからスタートします。
理想のエージェントを定めるための3つのアプローチ
1. エージェントで何を解決したかったのかを問い続ける
このエージェントの役割と範囲を明確にすることが目的です。例えば、「Excelの使い方」に関する質問をこのエージェントで解決すべきか否かを問い続けます。解決すべきならExcelツールをエージェントに組み込み、解決しないなら「このエージェントでは答えられません」と回答するようにプロンプトに指示する形です。エージェント運用チームや開発チームと密に連携し、エージェントに何をさせたいのかを話し合う必要があります。
2. 利用ユーザーから直接フィードバックを集める
ユーザーの生の声は改善に不可欠です。アプリケーションUIに「Good/Bad」ボタンや自然言語でのフィードバック入力機構を組み込む方法や、社内ユーザーであれば日々の対話の中でカジュアルなフィードバックを受け入れることも有効です。ただし、「Good/Bad」ボタンのようなフィードバックは、熱意のあるユーザーにしか利用されにくい「おまけ的要素」になりがちな点には注意が必要です。
3. ユーザーのトレースを観察する
ユーザーの潜在的な不満や意図を読み取り、改善機会を見つけることが重要です。トレースログを観察し、ユーザーが不安や不満を抱いている箇所を推測します。例えば、同じ質問を複数回繰り返している場合、初回の回答が不十分だった可能性が考えられます。また、ユーザーから同様の質問が複数回あったか、表現を変えて質問しているかなどを分析します。ユーザーグループで、質問の長さやドメインの違いなどを比較し、なぜそのような違いがあるのかを分析することも有効です。共通しにくい問題に向き合う必要があるものの、ユーザー体験を改善するために粘り強く運用に取り組むことが重要となります。
データに「意味」をもたらすセマンティックレイヤーと宣言的パイプライン
データの意味の不一致という根源的な問題
会議で「今月の売上」を尋ねた際、部門ごとに異なる報告があるという具体的な問題が提起されました。経理部門は9,800万円、マーケティング部門は1億1,000万円、営業部門は1億500万円と、数値が食い違う状況です。この根本的な原因は、「売上」という言葉の定義が揃っていないことに起因します。部門ごとに平均控除、税抜き、受注ベース、税込み、手入力などの算出基準が異なることで、データの「意味（セマンティック）」にずれが生じていたのです。
セマンティックレイヤーによる「意味」の統一
この「セマンティックレイヤー」は、データのセマンティック（意味）を統一するソリューションとして注目されています。Databricks公式ドキュメントでは、「複雑なデータモデルとビジネスユーザー間のギャップを埋めるビジネスフレンドリーなインターフェース」と定義されています。技術的なデータ構造を、なじみのあるビジネス用語や概念に変換することで、データアナリストやビジネスユーザーが深い技術的専門知識を必要とせずに、データにアクセスし、分析し、洞察を導き出すことを可能にします。「売上高」や「アクティブユーザー」といったビジネス用語を定義し、データと関連付ける役割を担うことで、データの解釈のずれを解消します。
セマンティックレイヤーはNetflix (MetricView)、Snowflake (Semantic Layer)、AtScaleなど、多くのプレイヤーによって提供され、実装形態も多様です。2010年代後半からのデータファブリック、データメッシュ、オープンテーブルフォーマットの普及により、データの「所在」に関する問題は解消されつつあります。しかし、現在の課題として、データの「意味」（セマンティック）は、依然として様々なツールやプレイヤーにバラバラに散らばっている点が挙げられます。
標準化の動き：Open Semantic Interchange (OSI)
データの「意味」がバラバラという問題を解決するため、ベンダーに依存しないセマンティック標準化を目指す委員会として「Open Semantic Interchange (OSI)」が発足しました。Databricksも発表の約1ヶ月前にOSIへの参加をアナウンスし、同時にOSI V1仕様が公開されました。OSI V1仕様はApache 2.0ライセンスで公開され、YAML形式で記述されます。現時点での対応方言は標準SQLおよびDatabricks SQLです。代表的なスキーマフィールドとしてai_contextがあり、AIツールのための特別なフィールドとして同義語、義務、AI向けの説明、使用例などを書き込むことができます。例えば、「売上」という言葉に対して「返品控除後の純額で売上分析に使用してください」という指示や、「Eveniumの売上高」「ネットセールス」といった類義語を定義し、このモデルを使用する際には「先月の地域別売上を出して」といった質問で使用するよう指示できるなど、AIがセマンティックレイヤーを活用する上でのガイドラインを提供するものです。
Databricks Declarative Pipeline (DCP) でデータエンジニアリングの「辛さ」を解消
データエンジニアリングには、ぐちゃぐちゃなデータを価値あるデータに変えるプロセスや、それが会社の意思決定に貢献する喜びといった楽しい側面があります。しかしその一方で、パイプラインの停止、上流のデータ形式の急な変更、手動での依存関係管理の煩雑さ、バッチ処理とストリーミング処理でロジックを大きく変える必要があることなど、「辛い側面」も存在します。依存関係管理、日々のパーティション管理、チェックポイント管理、データ品質チェック、ガバナンス管理、データディスカバリー、バックフィル、バージョン管理、インフラ管理など、多くの作業がデータ活用という中心的な「やりたいこと」に集中する時間を奪っていました。
Databricks Declarative Pipeline (DCP) は、これらの課題を解決するために宣言的パイプラインを導入します。これにより、ETL管理、インフラ管理、データへの信頼性確保、バッチ・ストリーミング処理の簡素化をまとめて実現します。これまで手動で管理していた更新や整合性管理など、本番パイプライン横断の作業を一括で処理してくれるのがDCPです。
DCPが提供する5つのメリット
-
バッチとストリーミングの統一構文: 異なる構文やロジックが必要だったバッチ処理とストリーミング処理を、
@dlt.tableなどのデコレーターとspark.read/spark.readStreamの切り替えだけで、同じロジックで記述できるようになります。 -
データ品質チェック:
@dlt.expectなどのデコレーターや宣言的な記述により、データバリデーションを自動化できます。期待値に合わないデータは自動的にドロップしたり、別の場所へ書き出したりできるため、手動でのフィルタリングが不要になり、「質の高いデータが欲しい」という意図を宣言的に記述するだけで実現できます。 -
ファンアウト: 1つの入力データから複数の出力テーブルにデータを書き出す際に、複数の
@dlt.tableデコレーターを付けるだけで、シンプルに記述できます。 - 遅延データのウォーターマーク管理: ストリーミング処理における複雑なウォーターマーク管理ロジックを宣言的に記述するだけで、DCPがマネージドで実行してくれます。
-
CDC (Change Data Capture) 管理: CDCから流れてくるデータの管理は非常に面倒でしたが、
APPLY CHANGES INTO構文や「オートCDC」のようなマネージド機能により、CDC関連の実装が非常に簡単になります。
DCPの利用は、Databricks Pipeline Editorを活用することで、コードファイルの管理、タブ切り替え、データフローの可視化を行いながらDCPの実装を進められます。ETLパイプラインの作成はすぐに開始でき、Databricks WorkflowsのタスクとしてDCPを組み込むことも可能です。
まとめ
AIエージェントのあるべき姿は、人間が決める必要がある。理想を決めないと、定義できない。