エージェントは「作る」から「配る」フェーズへ
homulaは、エンタープライズ企業向けにAIエージェントの戦略策定・PoC・実装・運用・内製化までを一気通貫で支援するAIインテグレーターです。日々の現場で最近強く感じるのは、企業の関心が「エージェントをどう作るか」から「作ったエージェントの能力をどう配り、使い回すか」へ移りつつあるということです。
ある調査では、企業は平均して12ものAIエージェントを運用しているのに、その半数は他のシステムやエージェントとつながらず単独で動いている、と報告されています（Belitsoft, 2026）。部門ごとに似たエージェントが乱立し、せっかく作り込んだスキルやデータが組織の壁・プラットフォームの壁を越えられない——これは多くの日本企業でも起きている「サイロ化」の典型です。
そこに2026年6月10日、Databricksの年次イベント Data + AI Summit で発表されたのが OpenSharing です。「エージェントのスキルをメールで送り合う」時代を終わらせる、という挑発的な触れ込みで報じられました（The New Stack）。本記事では、この標準が企業のエージェント戦略に何をもたらすのかを、ガバナンスと内製化の観点から読み解きます。
OpenSharingとは何か——Delta Sharingの「agentic版」
OpenSharingは、エージェントスキル・AIモデル・非構造データを、コピーせず（ゼロコピー）に組織やプラットフォームを越えて共有する、オープンでベンダー中立なプロトコルです。DatabricksとLinux Foundationが共同で立ち上げ、Linux Foundation配下のプロジェクトとして運営されます（Linux Foundation、Databricks ニュースルーム）。
その出自は、Databricksが2021年にオープンソース化した Delta Sharing にあります。Delta Sharingは「構造化テーブルを、ファイルをコピーして送らずに安全に共有する」という限定的だが重要な問題を解き、いまや数千社が使うゼロコピー・データ共有のデファクト標準になりました（Databricks, 2021）。
OpenSharingは、その同じREST・ゼロコピー設計を、agentic時代に企業が実際にやり取りし始めた資産へ拡張したものです。
| 観点 | Delta Sharing（2021〜） | OpenSharing（2026〜） |
|---|---|---|
| 共有対象 | 構造化テーブル（データ） | エージェントスキル / AIモデル / 非構造データ + 既存のテーブル |
| 方式 | ゼロコピー・REST | ゼロコピー・REST（同設計を継承） |
| 互換性 | — | Delta Sharingのスーパーセット。既存クライアントはそのまま動作 |
| 接続先 | Delta系エコシステム | Apache Iceberg の IRC クライアント対応を追加。オンプレ/プライベートクラウドも対象 |
| 位置づけ | データ共有標準 | エージェント能力の交換レイヤー標準 |
ポイントは「スーパーセット」であること。既存のDelta Sharingクライアントは引き続き動作し、そこにエージェントスキル・モデル成果物・非構造データという新しい共有可能アセットが加わります。データ共有の延長線上で、エージェントの「能力」そのものを配れるようになる、という設計思想です。
なぜ「ゼロコピー」と「ガバナンス」が効くのか
OpenSharingが企業にとって重要なのは、技術的な目新しさよりも、「共有」と「統制」を両立させる点にあります。
- データを動かさずに能力を渡せる：ゼロコピーなので、共有元はデータやモデルの実体を相手環境に複製しません。これは、データの所在を国内・自社管理下に留めたい日本企業のデータ主権・残留性（レジデンシー）の要件と相性が良い設計です。
- 共有しても統制を手放さない：DatabricksによるOpenSharingの実装は、Unity Catalogによるガバナンスと監査ログの上に成り立つとされています。誰に・何を・どの範囲で共有したかを追跡できる前提が組み込まれています（Databricks Blog）。
- セマンティクスごと渡せる：たとえば自然言語でデータに問い合わせる Genie のエージェントを、その背後にある意味定義（セマンティックコンテキスト）・業務指標・再利用可能なAIロジックごと、取引先や顧客に共有できる、と説明されています。
裏を返せば、これまでエージェントの能力共有は「プロプライエタリなマーケットプレイス（事実上のアプリストア）に縛られる」か「成果物をファイルで手渡しする」かの二択になりがちでした。OpenSharingが Delta Sharing のように普及すれば、特定のクラウドやAIプラットフォームが、ソフトウェア流通におけるアプリストアのようにエージェント能力の交換レイヤーを独占する事態を避けられる——これが標準化の戦略的な狙いです。
MCPとは「層」が違う——補完関係として捉える
ここで混同しやすいのが、homulaが日頃から扱うMCP（Model Context Protocol）との関係です。両者は競合ではなく、役割の異なるレイヤーだと整理すると見通しが良くなります。
MCP＝実行時にエージェントをツール・データに「接続」する層。OpenSharing＝スキルやモデル・データという資産を組織やプラットフォームを越えて「流通」させる層。 自社のエージェントが日々ツールを呼び出すのがMCP、そのエージェントが使うスキルやモデルを取引先・グループ会社と配り合うのがOpenSharing、というイメージです。
実務では両方が必要になります。エージェントが実行時に200以上の社内外ツールへつながる土台（MCP）があり、そのうえで作り込んだスキルやナレッジを、サイロを越えて再利用・配布できる標準（OpenSharing）が乗る。2026年は、この「接続」と「流通」の二層がそれぞれ標準化へ向かう年だと言えます。
homulaの観点——「配れる前提」で設計し、統制を後付けにしない
OpenSharingのような交換標準が整うと、エージェント導入の勝ち筋は「単発の便利ツールを部門ごとに作る」ことから、「再利用・共有を前提に、統制とセットで設計する」ことへ移ります。homulaが現場で重視しているのは、まさにこの順序です。
- 接続は構築ゼロで：homulaのプラットフォーム Agens は、MCPを活用して200以上のツールと構築ゼロで接続します。まず「つながる土台」を最短で用意し、スキルの作り込みに集中できる状態を作ります。
- 共有の前に統制を：能力が組織を越えて流通する時代ほど、「誰が・何を・どこまで」を縛る仕組みが先に要ります。Agens Control は承認フロー・DLP・5年分の監査ログ・RBACを提供し、共有・実行のたびに統制が効く状態を担保します。
- 内製化まで一気通貫で：戦略策定 → PoC（最短5日）→ 実装 → 運用 → 内製化を支援し、AIエージェント・ブートキャンプでは業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で完結させます。「作って終わり」ではなく「配って・統制して・回す」ところまでを射程に入れます。
エージェントスキルのパッケージング自体については、以前の記事「業務ナレッジをSKILL.mdに変換する」も参考になります。OpenSharingは、そうして作ったスキルを「組織の外まで届ける」次の一手を標準化する動き、と位置づけられます。
まとめ——標準は便利だが、統制は自分で設計する
OpenSharingは、エージェントスキル・モデル・非構造データをゼロコピーで組織横断共有する、オープンな交換レイヤーの標準です。Delta Sharingの普及実績を背景に、agentic時代の流通基盤になる可能性があります。一方で、標準が用意するのは「安全に配れる配管」であって、「何を・誰に・どこまで配ってよいか」という判断と統制は、依然として各社が自分で設計する領域です。
日本企業にとっての示唆は明確です。エージェントは今後ますます「作る」より「配って使い回す」フェーズに入ります。だからこそ、接続（MCP）と流通（OpenSharing）の標準が整いつつある今のうちに、共有を前提にした統制——承認・監査・権限設計——を土台として持っておくことが、サイロ化を防ぎ、投資を回収する近道になります。
エージェントの能力を「安全に配れる」状態は、接続とガバナンスの土台から始まります。自社の現状に合わせた設計を、まずは無料相談で整理してみませんか。