R&Dデータをレイクハウスに置くべき理由と、エージェントにそれが必要な理由

セットアップ

Daimler TruckとVolvo Groupの合弁会社であるcellcentricでは、大型アプリケーション向けの水素燃料電池システムを開発・製造しています。私たちの業務は、R&D、エンジニアリング、そしてデータに大きく依存しています。チームが直面する疑問が、単一のソースシステム内に収まることはほとんどありません。製品の階層、製造履歴、手直し、ラボでのエビデンス、テストのテレメトリ、そしてドメイン知識など、多岐にわたる領域を横断します。

これこそが、R&Dにおける産業用AIの最大の課題です。エージェントが実用的であるためには、エンジニアが回答を信頼するのに必要な、ガバナンスの効いたコンテキスト（データの出所、その意味、網羅性、注意すべき制限事項、ユーザーに閲覧権限があるかどうかなど）に基づいて推論できなければなりません。これをAI対応のコンテキストに変換するには、モデルの選定よりも前に、まずデータエンジニアリングから始める必要があります。

だからこそ、私たちは過去4年間をかけて、AzureとDatabricks上にデータ基盤を構築してきました。Unity Catalogは最初からアーキテクチャの一部でした。Lakehouse Federationによって、オンプレミスのSQLソースをレイクハウスパターンに組み込むことができました。Delta Sharingは、組織の境界を越えたデータ共有に役立ちました。Databricks Asset Bundlesは、パイプラインとデータプロダクトの本番環境へのデプロイパスを提供してくれました。その結果生まれたのがData Hubです。これは、データとAIのためのガバナンスが効いたコンテキストレイヤーであり、従業員向けのユーザーインターフェースと、エージェント向けのMCPサーバーを備えています。

Data Hubは最初、データプロダクトのプラットフォームとしてスタートしました。振り返ってみると、その基盤があったからこそ、AIプラットフォームとしても機能しているのです。

Fuel Cell Passport

この基盤を説明するのに最もわかりやすいのが、1つのデータプロダクトであるFuel Cell Passportです。これは、SAP S/4HANA、製造および手直し用の2つのMESシステム、ラボのデータベース、IoTテレメトリプラットフォームを含む、5つのエンタープライズソースシステムを統合したものです。システムから原材料のバッチに至るまでの7つの階層レベルをモデル化し、毎日更新され、状態ベースの時系列モデルを使用しているため、チームは特定の時点の構成に関する質問と、手直しの全履歴に関する質問の両方に回答できます。毎日のデータ品質チェックにより、エンジニアリング、品質、製造の調査をサポートするのに十分なデータが揃っているかどうかが監視されます。この名称は製品パスポートのトレーサビリティとライフサイクルの概念を反映していますが、Fuel Cell Passportは社内のエンジニアリングデータプロダクトであり、EUのデジタル製品パスポート（DPP）のような規制遵守のための成果物ではありません（ただし、同じトレーサビリティ基盤があれば、そうした規制への対応も可能です）。

これは、ソースの統合、ドメインのモデル化、アクセスの管理、データの再利用性の確保といった、従来のレイクハウスの成功事例のように聞こえるかもしれません。しかしAIにとって、構造的なポイントは「付随するコンテキスト」、つまりモデル化されたデータの周囲にあるガバナンスの効いたプロダクト層にあります。

品質指標としてのコンテキスト

Unity Catalogは、テーブル、列、オーナーシップ、リネージ、分類、権限といった、ガバナンスの効いた構造を提供します。Data Hubは、その周囲にプロダクトレイヤーを追加します。データプロダクトは、オーナーシップ、ライフサイクルステート、ドメイン割り当て、リンクされた管理対象アセット、そしてそのプロダクトの目的や使用方法を説明するコンテキストエントリーを組み合わせたものです。

この違いはAIにとって重要です。エージェントが必要とするのは、スキーマのメタデータやドキュメントだけではありません。データプロダクトがどのようなビジネス上の疑問をサポートしているか、重要なテーブルがどのように関連しているか、どのような注意点があるか、そしてどのアセットを一緒に使用すべきかを理解する必要があります。私たちは、プロジェクトのコンテキストがまだ新鮮な開発プロセス中に作成された詳細なMarkdown形式のカタログエントリーを含め、その豊かなコンテキストをデータプロダクトレイヤーに永続化しています。

これにより、データ品質に対する考え方が変わりました。網羅性や新しさも依然として重要ですが、それだけでは不十分です。AI対応データにとって、コンテキストの網羅率（context coverage）は最優先の品質指標となっています。

私たちのマーケットプレイスでは、すべてのデータプロダクトにコンテキスト網羅率のバッジが表示されます。これにより、テーブルの説明が存在するかどうか、またプロダクトに紐づくテーブル全体で列レベルのドキュメントがどの程度存在しているかが示されます。このバッジによって指標が可視化され、具体的なアクションにつなげやすくなりました。エンジニアは、データが消費されるプロダクトの画面上でギャップを直接確認できるため、網羅率が向上しました。

この指標は、すべての意味的な曖昧さが解決されたことを主張するものではありません。不足しているコンテキストを早期に発見して修正できるようにするための、実用的な代替指標です。これまで、バッジの導入によってドキュメント作成が「事後の片付け作業」から「開発プロセスの一環としてエンジニアが確認、測定、改善できるもの」へと変わったため、コンテキストの網羅率が向上しました。

現在、27個のデータプロダクトが公開されており、そのすべてに充実したMarkdownドキュメントが用意されています。公開されたプロダクトの列コメントの網羅率は平均90%に達しており、そのほとんどはデータエンジニアリング作業中にAIの支援を受けて作成され、マージ前にエンジニアによってレビューされています。カタログエントリーは、開発ワークフロー、ドメインに関する決定、テーブル間の関係、注意点、プロダクトの推奨される利用方法をまとめた詳細なMarkdown形式のサマリーであり、さらなるコンテキストレイヤーを追加します。

重要な変化は、ドキュメント作成がエンジニアリングワークフローの一部となり、その後、データに基づいて推論を行う次の人間やエージェントが利用できる構造化されたプロダクトコンテキストとして活用されるようになることです。

人間にはUIを、エージェントにはMCPを

Data Hubは、その基盤を利用可能な形にするレイヤーです。人間のユーザーにとって、それはマーケットプレイスでありワークベンチです。従業員はデータプロダクトを検索し、オーナーやライフサイクルステータスを確認し、リンクされたダッシュボードやアプリを開き、Unity Catalogで管理されたデータにクエリを実行し、チャットインターフェースを使用して自然言語でデータを探索できます。AIクライアントに対しては、同じコンテキストがMCPを通じて公開されます。MCPに対応したコーディングエージェントやアシスタントであれば、Data Hubが使用しているものと同じUnity Catalogのメタデータやデータプロダクトのコンテキストにアクセスできます。

ガバナンスモデル

このアーキテクチャは、意図的に1つの運用モデルを中心に構築されています。ID情報が引き継がれ、データアクセスは管理された状態に保たれます。モデルやツールの呼び出しは観測可能であり、トレースと評価が改善へとフィードバックされます。

これが機能するのは、最初からプラットフォームにガバナンスが組み込まれて設計されているからです。本番環境のオーナーシップ、デプロイ、および利用は、それぞれ独立して管理されています。エンジニアは、レビュー済みのコードと管理されたデプロイパスを通じて、パイプラインやプロダクト定義を変更します。エージェントを含む利用者は、本番環境への書き込み権限を持つIDを付与されません。彼らは、認証されたユーザーのIDを使用して、Data Hub、ダッシュボード、Genie、SQLツール、またはMCPを介してデータにアクセスし、Unity Catalogが最終的な認可の判断を下します。

この区別こそが、エージェントアクセスのガバナンスを可能にするものです。エージェントはユーザーが見ているものと同じプロダクトコンテキストに基づいて推論し、ユーザーに代わってツールを呼び出すことができますが、本番環境の書き込み担当者になったり、共有のバックエンド資格情報を使用してUnity Catalogをバイパスしたりすることはできません。ユーザーがテーブル、マスクされた列、または管理されたビューへのアクセス権を持っていない場合、そのユーザーの代わりに動作するエージェントにも同じ制限が適用されます。この運用モデルにより、プラットフォームの周囲にセキュリティの緩い第2のアクセス経路を作ることなく、エージェントにデータアクセスを許可することができます。

IDはAzure ADから始まり、OAuth 2.0トークン交換（Databricksがエージェントガバナンスアーキテクチャで説明している「代理（on-behalf-of）トークン受け渡しパターン」）を使用して、Data Hubを経由してDatabricksに流れます。UIを介してテーブルにクエリを実行するユーザー、SQLツールを呼び出すエージェント、管理されたツール呼び出しとして起動されるGenieワークスペースはすべて、同じ権限境界内で動作します。ユーザーが元のデータにアクセスできない場合、そのユーザーの代わりに動作するエージェントもアクセスできません。これこそが、Data Hubを並行する別のガバナンスシステムにすることなく、有用なものにするアクセスモデルです。

AI側では、Databricks Model Serving上でカスタムエージェントを実行し、Foundation Model APIを介してClaudeを使用し、適した場所でGenieワークスペースを管理されたツールとして呼び出しています。MCPアーキテクチャは設計上ハイブリッドです。Databricksが管理するMCPは、Genieツールの呼び出しといったDatabricksの機能への管理されたアクセスを提供し、独自のMCPは、Unity Catalogのメタデータ、データプロダクトオブジェクト、カタログのMarkdownといった、より豊かなコンテキストレイヤーに加えて、エージェントがその上で呼び出すビジネス固有のツールを提供します。エージェントにはその両方が必要です。

観測可能性と評価

オブザーバビリティ（可観測性）は、アーキテクチャが運用可能になる場所です。現在、Unity AI Gatewayは私たちの環境における基盤モデルのトラフィックをルーティングしています。モデルクライアントを少し変更するだけで、Data Hubのモデル呼び出しは、使用状況トラッキングと推論テーブルが有効化された単一のガバナンスおよびオブザーバビリティレイヤーを経由するようになります。リクエストとレスポンスはUnity CatalogのDeltaテーブルに保存されるため、ビジネスデータに対してすでに使用しているものと同じSQLパターンで分析できます。

MLflowのトレース機能は、次のレベルの可視性をもたらします。私たちはエージェントアダプター全体でトレースを標準化しているため、モデル呼び出し、ツール呼び出し、中間ステップ、最終回答といった各インタラクションを、構造化された実行パスとして検査できます。これらのトレースに加えて、決定論的な正確性とSQLグラウンディング（根拠付け）のスコアラー、キャッシュを考慮したコストスコアラー、そしてドメイン専門家と整合させたLLM判定スコアラーを備えた、継続的な評価フレームワークを実行しています。その目的は、エージェントの変更をテストすることにとどまりません。コンテキストレイヤー自体も評価する必要があります。マークダウンがパイプラインやテーブル定義から乖離したり、システムプロンプトが進化したり、ツールの仕様が変更されたり、ドメインの前提条件が古くなったりするためです。トレースと評価（evals）を行うことで、本番環境の動作に影響を与える前に、エージェント、ツール、そしてそれが依存するコンテキストをまとめてテストできます。

これにより、従業員がどのようなデータプロダクトが存在するかを発見し、基盤となるデータと同じアクセス制御に従いながら、自然言語でそれらと対話できる、ガバナンスの効いた単一の入り口が初めて実現しました。

開発ループ内における同じパターン

この同じパターンは、私たちの構築方法も変えました。

私たちのエンジニアリングワークフローには、開発ループ内にエージェントが組み込まれるようになりました。具体的なコーディングツール自体よりも、そのパターンが重要です。エンジニアは、Databricksの機能や独自のコンテキストレイヤーMCPに接続された、AI支援型の開発環境で作業します。エンジニアがデータプロダクトに取り組む際、エージェントは関連するUnity Catalogのメタデータを検査し、既存のプロダクトドキュメントを読み、周辺のプロジェクトコンテキストを理解した上で、パイプライン、テスト、テーブルの説明、マークダウンのカタログエントリの骨組み作成（スキャフォールディング）を支援します。エンジニアは引き続きレビューとマージの責任を負いますが、コンテキストが最も豊富な段階でエージェントがサポートしてくれます。

そのタイミングが重要なのです。事後に作成されたドキュメントは、プロジェクトのコンテキストがすでに先に進んでしまっているため、不完全になりがちです。開発中に作成されるドキュメントは、後でデータを役立たせるための理由、定義、注意事項を捉えることができます。そして、一度レビューされてコミットされれば、次のワークフローのコンテキストになります。

多くのR&Dやプロセス開発のワークフローにおいて、かつてはシステム横断的なデータ統合、KPI定義、パイプラインの骨組み作成に数週間かかっていたものが、今では数日でリリースできるようになりました。この改善は、単一の自動化率の数値として現れるというよりも、調査依頼から利用可能なデータプロダクトができるまでの時間の短縮として現れます。ドメイン専門家とデータエンジニアの間の手動での引き継ぎが減り、ソースシステム統合の繰り返しが減り、KPI定義への合意が迅速化され、コンテキストがまだ新鮮なうちに注意事項を早期にレビューできるようになります。一部のカテゴリ、特に慎重なドメインレビューを必要とする複雑なマルチソース調査は、依然として大きな作業を伴いますが、それでも大幅にスピードアップしています。永続的なメリットは累積的です。各プロダクトがレビュー済みのビジネスコンテキストをプラットフォームに追加するため、次の調査はドメインの多くがすでに説明された状態から開始できます。

Databricksは現在、このパターンの要素を製品化しています。Unity AI Gateway Coding CLIであるucodeは、コーディングツールをAI Gateway経由でルーティングし、MCPサーバーを開発者ワークフローに組み込みます。Genie Codeは、エージェント型のコーディングとデータ作業をDatabricksのインターフェースに直接もたらします。

今後の展望

私たちにとっての次の波は、テーブル自体だけでなく、データを取り巻く運用コンテキストをエージェントに認識させることです。品質や製造の調査において、エージェントはトレンドを取得し、プロダクトに付随するデータ品質チェックを検査し、同じ時間枠の関連するマシンアラームログを取り込める必要があります。そうすることで、エンジニアが期待するような注意事項を含んだ回答を提供できます。例えば、「トレンドはこの方向を示していますが、完全性にフラグが立てられており、稼働コンテキストが異常であったため、このスライスには注意が必要です」といった具合です。

同じ考え方が、定常業務にも当てはまります。現在、プロセスの知識はランブック、Wikiページ、ローカルプロンプト、スクリプト、チームの慣習、および文書化されていない習慣に分散しています。Skills Marketplaceは、その知識にデータプロダクトと同じプラットフォームとしての扱い（所有権、レビュー、バージョン管理、ライフサイクル状態、そしてエージェントが承認された作業方法を見つけるための一元化された場所）を提供します。この文脈において、「スキル」とは、私たちの環境で定常タスクをどのように実行すべきかをエージェントに指示する、手順、承認されたツール、テンプレート、ガードレール、評価チェックをパッケージ化したものです。具体的には、関連するデータプロダクトとともにマーケットプレイスに配置され、コードのようにバージョン管理やレビューが行われ、名前で呼び出されることで、エージェントが毎回同じ承認されたパスをたどるようになります。スキルは、リモートリポジトリ内のドメイン固有のDatabricks Asset Bundleの骨組み作成を支援したり、エンジニアがIoTデバイスを登録して、整理されていないマシンログをブロンズパイプラインに変換するのをガイドしたりします。

これこそが、Data Hubのより広範な方向性です。レイクハウスの基盤から同じ教訓を得て、まずコンテキストを管理し、それをエージェントがクエリするデータと、エージェントが支援する作業の両方に適用することです。

まとめ

だからこそ、R&Dデータはレイクハウスに属するべきなのです。産業用AIには、ガバナンスの効いたコンテキスト（データ、意味、権限、トレース、およびフィードバックループが1つのアーキテクチャに統合されていること）が必要です。

cellcentricにとって、産業用AIを実用的なものにするとは、実績のあるレイクハウスの基盤の上で、エージェントにそのコンテキストを提供することを意味します。Unity Catalog、データプロダクト、アイデンティティ、オブザーバビリティ、およびエージェントワークフローが連携することで、人間とエージェントがR&Dデータについて安全に推論できるようになります。これは私たちにとって、単なるベストプラクティスにとどまりません。これこそが、私たちが次世代のデータ駆動型エンジニアリングを形作る方法なのです。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事