Delta SharingからOpenSharingへ：変更点と今後の展望

Delta Sharingは、何千もの組織がファイルをコピーすることなく、クラウドやプラットフォームをまたいでライブデータを交換するための方法でした。2026年6月、DatabricksとLinux Foundationは、Delta Sharingがテーブルだけでなく、AIチームが現在依存している広範なアセット（エージェントスキル、AIモデル、非構造化データなど）を共有するためのオープンでベンダーニュートラルなプロトコルであるOpenSharingへと進化したことを発表しました。すでにDelta Sharingでデータを共有している場合や、データとAIアセットの両方でパートナーとどのようにコラボレーションするかを検討している場合、この記事では、OpenSharingの実際の姿、内部での変更点、そしてプロジェクトの今後の方向性について解説します。

簡単なまとめ：Delta Sharingが解決したこと

DatabricksがData + AI Summit 2021でDelta Sharingを発表した際、それが取り組んだ核心的な課題は、説明は簡単でありながら解決するのは難しいものでした。すなわち、組織は、ファイルの書き出し、壊れやすいETLジョブの構築、すべての受信者に同じプラットフォームを強制することなく、パートナー、顧客、その他のチームとライブデータを共有したいと考えていたのです。Delta Sharingは、Delta LakeとParquetをベースにしたオープンプロトコルとしてLinux Foundationに寄贈され、プロバイダーがテーブルへのアクセス権を付与し、受信者がApache Spark、Power BI、Tableau、pandasなどのツールからリアルタイムで直接クエリを実行できるようにしました。

このオープンでコピー不要のモデルは多くの支持を集めました。Databricksによれば、Delta Sharingは、Amadeus、Atlassian、LSEG、SAP、Stripe、The Trade Deskなどの組織によって、クロスクラウドおよびクロスプラットフォームのコラボレーションのための安全なデータ共有として最も広く採用されているオープンプロトコルへと成長しました（Databricksプレスリリース）。2026年6月にDatabricksがOpenSharingを発表した時点で、Delta Sharingのデータ受信者は28,000を超えており、共有の約3分の1はDatabricks間の共有にとどまらず、オープンコネクタを介してプラットフォームをまたいで行われていました（Databricksブログ）。

なぜDelta Sharingの進化が必要だったのか

共有の対象はすでにテーブルを遥かに超えて拡大していました。Databricks間の共有を通じて、チームはエージェントが登場する何年も前から、ビュー、非構造化ファイルのボリューム、ノートブック、登録済みMLモデルを交換していたため、構造化データだけがすべてではありませんでした。エージェントが変えたのは、移動させる必要のあるアセットの種類と、それが移動すべき範囲です。エージェントのスキル、エージェント自体、そしてそれらが実行されるセマンティックコンテキストのすべてにおいて、共有ですでに実証されているような、ガバナンスの効いたコピー不要のアクセスが必要とされていました。また、企業は、プラットフォームを越え、Databricks間接続の枠を超えてそのアクセスが届くことを望んでいましたが、従来のオープンプロトコルは依然としてテーブルを中心に据えていたため、これら的新しいアセットは、オープンなクロスプラットフォーム共有が実際に提供できる範囲の外にありました。

同時に、企業からは2つの関連する要望が寄せられ続けました。それは、Apache Icebergなどのフォーマットとのより幅広い相互運用性と、オンプレミスやプライベートクラウドに存在するデータを、まず移行することなく、同じガバナンスの効いた共有モデルに取り込む方法です。これら両方の課題に対処することは、機能を追加するだけでなく、Delta Sharingのスコープを再定義することを意味していました。

OpenSharingとは何か

2026年6月10日、DatabricksとLinux Foundationは共同で、Delta Sharingの次の進化形としてOpenSharingを発表しました（Databricksプレスリリース、Linux Foundationプレスリリース）。OpenSharingは2つの異なるレイヤーで動作するため、正確な理解が重要です：

1. オープンソースのプロトコルおよび仕様：Databricksによって寄贈され、現在はLinux Foundation AI & Data Foundationの下でプロジェクトとして開発されています。この仕様はApache 2.0ライセンスで提供され、GitHub上で公開されているため、どのベンダーやコミュニティメンバーもDatabricksから完全に独立して実装できます（GitHub, OpenSharing）。
2. Databricks OpenSharing：Databricksプラットフォーム内における、Unity Catalog、Databricks Marketplace、Clean Roomsと統合された同プロトコルのエンタープライズ実装です。

オープンエコシステムはプロトコル自体にとどまりません。同じくLinux Foundationのガバナンス下にあるApache 2.0プロジェクトであるオープンソースのUnity Catalogは、これらのアセットに対してベンダーニュートラルなカタログとガバナンス層を提供するため、チームはこれをオープン共有サーバーと組み合わせて、Databricksの外部でガバナンスの効いた共有を完全に実行できます（GitHub, Unity Catalog）。

Databricksの共同創設者兼CTOであるMatei Zahariaはこの動きについて、「Delta Sharingは、業界がベンダーロックインよりもオープンを選択することを証明しました。OpenSharingはその原則を完全なAIスタックに拡張しつつ、クロスプラットフォームのエコシステムをIcebergの受信者やオンプレミスのプロバイダーにまで広げます」と述べています（Databricksプレスリリース）。Linux FoundationのCEOであるJim Zemlinは、目標が「組織がプラットフォームやエコシステムを越えてAIアセットを安全かつ相互運用可能に交換できるようにする、共通のベンダーニュートラルなフレームワーク」であると付け加えています（Linux Foundationプレスリリース）。

最初にはっきりさせておくべき点として、既存のDelta Sharingのクライアントと統合はOpenSharingと互換性を維持しています。これはプロトコルからの離脱ではなく進化であり、delta-io/delta-sharingリポジトリは新しいOpenSharing-IO/OpenSharing GitHub組織と並行して存続し続けます。

図：Delta SharingがOpenSharingへと進化。OpenSharingはGitHub上のオープンプロトコル層とDatabricksのエンタープライズ実装層として機能し、Iceberg REST Catalogのクライアントやオンプレミス・プライベートクラウドストレージへと新たな領域を広げます。

技術的な変更点

より幅広いアセットモデル。 Databricks間の共有がより多くの種類のアセットをカバーするように成長していた一方で、元のオープンなDelta Sharingプロトコルはテーブルを中心に据えていました。OpenSharingはそのより幅広いモデルをオープン仕様自体に組み込み、テーブルにとどまらず、ボリューム（任意の形式のファイルディレクトリ）、エージェントスキル、AIモデルなどの新しいアセットタイプへと共有を拡張するShare → Schema → Asset階層を導入しています（GitHub, OpenSharing）。これにより、プロバイダーは基盤となるテーブルと、その上に構築されたAIアセットの両方を含むデータ製品をパッケージ化し、単一のプロトコルを通じて全体を共有できるようになります。

図：OpenSharingのアセット階層。現時点ではテーブル、ボリューム、エージェントスキル、モデルが指定されたアセットタイプです。エージェント、ページ、用語集の各タイプは、現在も議論中のコミュニティ提案としてリストされています。

Iceberg REST Catalogのサポート。 OpenSharingは、Apache Iceberg REST Catalog（IRC）互換クライアントのサポートを追加しているため、プロバイダーはDelta Sharingネイティブのクライアントだけでなく、任意のIceberg互換エンジンにデータを共有できます。Databricksは、これをIcebergツールを採用している組織にオープン共有のリーチを広げるものとして説明しています（Databricks製品ページ）。

オンプレミスおよびプライベートクラウドへのリーチ。 Databricksストレージエコシステムを通じて、ストレージベンダーはUnity Catalogに直接接続するOpenSharingサーバーを実行できるため、オンプレミスやプライベートクラウドにあるデータを最初に移行することなく、ガバナンスを適用して共有できます（Databricksブログ）。MinIOのAIStor統合は一般提供（GA）されており、2026年後半に向けてプレビュー中または提供が予定されている追加のストレージパートナーも控えています。

コピー不要の資格情報のベンディングがモデルとして継続。 プロバイダーはデータを移動して共有することはありません。共有サーバーが一時的なスコープ付き資格情報を発行し、サーバー自体はデータパスの外側に配置されます。これはDelta Sharingの動作原理と一貫しています（GitHub, OpenSharing）。

新しい共有機能。 プロトコルの変更に加え、DatabricksはOpenSharingの上にいくつかの機能を導入しました：

• SecureConnect（一般提供）：新しい受信者ごとにファイアウォールやネットワークルールを構成する必要性をなくす、Databricks管理のプロキシ（Databricksブログ）。
• グローバル分散（プライベートプレビュー）：地域やクラウドをまたいで共有データを受信者の近くにレプリケートし、レイテンシを削減してエグレスコストをより予測しやすくする機能。
• Genie Agent Sharing（ベータ版）。提供者がクォータや公開する基盤ロジックを制御しながら、外部パートナーと会話形式の自然言語によるデータへのアクセスを共有できるようにします。
• Lakebase table and change data feed sharing（パブリックプレビュー）。別個のETLステップなしでライブの運用データを共有できます。

ガバナンスがLinux Foundationへ移行。 OpenSharingはLinux Foundation AI & Data Foundationに寄贈され、現在はインキュベーション段階に進む前の新規プロジェクトのエントリーポイントであるサンドボックス段階にあります（GitHub, OpenSharing および opensharing.io）。仕様の変更は一方的に決定されるのではなく、パブリックな提案およびレビュープロセスを経て行われます。これは、Delta LakeやDelta SharingがLinux Foundationプロジェクトとしてすでに従っていたガバナンスパターンと同じです。

すでにDelta Sharingをご利用の場合の意味

現在、共有、受信者、コネクタを設定している場合でも、それらが失われることはありません。OpenSharingは追加型の機能です。既存のテーブル、コネクタ、ワークフローは引き続き機能し、新しいアセットタイプや機能は、必要に応じて導入できます。Unity CatalogメタストアでのOpenSharingの有効化は、移行ではなく設定ステップであり、新しいアセットタイプが利用可能になった場合でも、すでに使い慣れている「共有の作成」、「受信者の作成」、「アクセスの付与」というワークフローがそのまま適用されます（Databricksドキュメント）。

プラットフォーム間でエージェントのスキルやモデルアーティファクトを移動するためのカスタム統合を維持してきたチームにとって、実用的な価値提案は、パートナーやアセットタイプごとに個別の特注パイプラインを用意するのではなく、検出、認可、アクセスのためのオープンなAPIの単一のセットを利用できるという点にあります。

今後のロードマップ

2026年6月の発表で説明された機能の一部は、現在一般提供されているものではなく、明示的に初期段階にあるものです。提供者が外部カタログにあるテーブルを直接共有できるForeign Iceberg table sharingは、発表時点でパブリックプレビューであり、一般提供はまもなく開始予定とされています。また、提供者がより長いセットアップフローではなくメールアドレスを入力するだけで共同作業者を招待できるメールベースの共有も、発表時にまもなく提供予定として記載されていました。

Databricksが提供を確約しているもの以外に、GitHub上のOpenSharingプロジェクトの公開ロードマップには、確定した機能というよりもまだオープンな設計課題であるコミュニティからの提案のセットが記載されています。これには、スコープ付きアクセスによる評価データセットおよびベンチマークの共有のサポート、プロベนス（出所）メタデータを含む合成データセットの共有、事前計算されたベクトルインデックスを共有するための提案されたアセットタイプなどが含まれます（OpenSharing ROADMAP.md）。これらはコミュニティの提案であるため、スケジュールや最終的なスコープは変更される可能性があり、確約された日付として扱うのではなく、GitHubで追跡することをお勧めします。

また、OpenSharingは、AI向けの急速に進化する幅広いオープン標準の特定のレイヤーに位置しています。DatabricksのプロダクトマネジメントディレクターであるAkram Chetibiが説明しているように、エージェント間およびエージェントとツール間の通信プロトコルは、OpenSharingが解決するものとは異なる問題を解決します。「OpenSharingは、エージェントのスキルやAIモデルなどの保存されたアセットを発見し、それらへのアクセスを認可するためのAPIを提供します」（diginomica）。両方の種類のプロトコルが連携して動作する必要があるアーキテクチャを設計する場合、この違いを理解することが重要です。

はじめに

OpenSharingを初めて使用する場合、その導入手順はDelta Sharingで機能していたものと同じです。共有したいデータを管理するUnity CatalogメタストアでOpenSharingを有効にし、公開するアセットを含む共有を作成し、受信者を作成して、その受信者にアクセス権を付与します（Databricksドキュメント）。そこから、特定の受信者がDatabricks間共有、非Databricks受信者向けのDatabricks-to-Open sharing、またはプロトコルを完全にDatabricks外で実行したい場合のセルフホスト型OpenSharingサーバーのいずれを通じて接続すべきかを決定できます。ドキュメントを読む際は、プロトコルとブランド名は「OpenSharing」と1単語で表記される一方、プラットフォームのドキュメントでは、Databricks外の受信者と共有するモードに対して小文字のフレーズ「Databricks-to-Open sharing」が使用されていることに注意してください。

詳細を確認するには：

• Databricks および Linux Foundation からの元の発表をお読みください。
• 技術的な詳細解説「Introducing OpenSharing: the Next Evolution of Delta Sharing for the Agentic Era」をご覧ください。
• GitHub でプロトコルの仕様とロードマップを探索してください。
• OpenSharingに関するDatabricksドキュメントでセットアップ手順を確認してください。
• Databricksストレージエコシステムの発表を通じて、オンプレミスおよびプライベートクラウドストレージの接続について学びましょう。

Delta Sharingは、チームがプラットフォーム間でのデータの移動について考える方法を変えました。OpenSharingは、そのオープンでゼロコピーのアプローチを、エージェント型ワールドが稼働するアセットへと拡張します。すでにDelta Sharingでデータを共有している場合、自然な次のステップは、エージェントのスキル、モデル、非構造化ファイルのセットなど、スタック内の他の何を同じ方法で共有できるかを検討することです。ワークスペース内のUnity CatalogメタストアでOpenSharingを有効にするか、GitHubのプロトコル仕様を読んでセルフホスト型の実装が独自のプラットフォームにどのように適合するかを確認してください。

OpenSharingを試してみませんか？ワークスペース内のUnity Catalogメタストアで有効にするか、GitHubのプロトコル仕様を読んでセルフホスト型の実装がプラットフォームにどのように適合するかをご確認ください。ご質問やフィードバックがありますか？Databricksのアカウントチームにご連絡いただくか、OpenSharingのGitHubリポジトリでIssueを開くか、Databricksコミュニティでのディスカッションにご参加ください。

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