2026 年 5 月 28 日、Zenn で お前達にも教えよう。SnowflakeのAgent Sharingがすごくすごいことを。 が話題となり、Snowflake が Secure Data Sharing の概念を「エージェントの共有」まで拡張した Agent Sharing に注目が集まりました。これまで Snowflake の Secure Data Sharing は 「データそのものを動かさずに別アカウントから参照できる」仕組みでしたが、Agent Sharing はこれを 「分析エージェント（プロンプト + ツール + ガードレール）」のレイヤにまで広げる構造です。
これは データ提供者がデータの参照範囲を絞ったまま、特定タスクに最適化されたエージェントを配布できることを意味し、**「データ販売 / 業界横断分析 / グループ会社統合分析」といった受託案件のアーキテクチャを根底から変えます。これまで BigQuery Cross-Engine Iceberg 受託 で扱った オープンレイクハウス相互運用、Uber Eats 生成リコメンダー受託 で扱った リアルタイム ML 基盤、DBMaestro MCP 受託 で扱った 自然言語 DB パイプラインと接続して、「Agent Sharing × データ基盤受託」**を新しい主力サービスとして整理します。
なぜ「Agent Sharing」が分水嶺なのか
| 観点 | データ共有のみ（Secure Data Sharing） | エージェント共有（Agent Sharing） |
|---|---|---|
| 共有単位 | テーブル / ビュー | エージェント（プロンプト + ツール + ガード） |
| データ移動 | なし | なし |
| 利用側のスキル | SQL + ドメイン知識必須 | 自然言語で問い合わせ可能 |
| 提供側の品質保証 | スキーマ + マスキング | + プロンプト + 想定回答セット |
| アクセス制御 | RBAC + Row Access | + プロンプトレベル制約 |
| 監査 | クエリログ | + プロンプト / 応答ログ |
| 更新運用 | スキーマ変更通知 | + エージェント更新通知 |
| 収益化 | データ販売 | + エージェント従量課金 |
つまり Agent Sharing は 「データを売る / 配布する」から 「分析能力を売る / 配布する」へのビジネスモデル変化を可能にし、データ提供側が分析品質まで保証する新しい責任分界を生み出します。
受託案件で活きる 3 つの構造変化
構造 1: 「データ提供」から「分析能力提供」へ
これまで受託では 「データを CSV / API / Snowflake Share で提供」したあと、利用側の SQL スキルに依存して価値が決まっていました。Agent Sharing では 「ドメインに最適化されたエージェントをセットで提供」でき、利用側の即時価値が大きく向上します。これは DBMaestro MCP 受託 で扱った 自然言語 DB 操作を 「データ提供側が分析エージェントごと配布する」形に進化させる発想です。
構造 2: 「データ販売」から「サブスク従量課金」へ
データ販売の 「一括ライセンス課金」から、Agent Sharing では **「エージェント利用回数 × トークン課金」で 継続収益を設計できます。これは BigQuery Cross-Engine Iceberg 受託 で扱った オープンレイクハウスの 収益化レイヤを、「データの上に乗るエージェント」**まで拡張する発想です。
構造 3: 「グループ会社統合の障害」から「Agent ハブで横断分析」へ
中堅企業のグループ会社統合では **「データを集める / API を統合する」にスタックしてきました。Agent Sharing では 各社が自社データに最適化したエージェントを共有することで、「データを動かさず横断分析」が可能になります。これは Uber Eats 生成リコメンダー受託 で扱った リアルタイム ML 基盤を、「データプロダクトとしてのエージェント」**として配布する発想です。
受託で提供する「Agent Sharing 基盤」5 フェーズ
フェーズ 1: ユースケース棚卸し（2〜3 週間）
- データ提供者 / 利用者の役割整理
- 配布候補エージェントのリスト（営業分析 / 与信判定 / 在庫予測 等）
- データソース棚卸し（Snowflake テーブル / 外部 DWH / ファイル）
- 機微度区分 + アクセス制御要件
- 想定利用シナリオと品質指標
- 収益モデル仮説（一括 / サブスク / 従量）
フェーズ 2: ポリシー設計（2〜3 週間）
- エージェント定義テンプレート（プロンプト / ツール / ガード）
- Row Access + マスキング設計
- プロンプトレベルの制約（禁止表現 / 必須開示）
- 監査ログ要件（クエリ + プロンプト + 応答）
- 配布契約テンプレート（SLA / 責任分界 / 終了条件）
- 価格モデル（提供側 / 利用側双方）
フェーズ 3: 技術基盤構築（4〜6 週間）
- Snowflake Agent Sharing 環境整備
- Cortex Agents / Snowflake ML 統合
- ガードレール実装（プロンプト / 応答フィルタ）
- 監査ログ → SIEM 連携
- 利用ダッシュボード（提供側 / 利用側両方）
- 課金集計バッチ
フェーズ 4: パイロット → 配布開始（3〜4 週間）
- パイロット利用者 2〜3 社で稼働
- 1〜2 週ごとの利用レビュー
- ガードレール調整
- 提供契約締結支援
- ヘルプデスク FAQ
フェーズ 5: 月次運用 + 改善ループ（継続）
- 利用状況 + 収益レポート
- エージェント品質指標監視
- 新規エージェント追加レビュー
- 利用者拡大支援
- 半期ごとの価格モデル見直し
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| データ基盤 | Snowflake | BigQuery / Databricks |
| エージェント | Snowflake Cortex Agents | Anthropic Claude / OpenAI |
| 共有 | Snowflake Agent Sharing / Marketplace | 内製 API ゲートウェイ |
| アクセス制御 | Snowflake RBAC + Row Access | 外部 IdP + 内製 |
| ガードレール | Cortex Guard / 内製プロンプトフィルタ | Lakera Guard |
| 監査ログ | Snowflake Account Usage / Trail | + 外部 SIEM |
| 課金 | Snowflake Marketplace / Stripe | 内製課金 |
| ダッシュボード | Streamlit in Snowflake / Looker | Superset |
どの案件に必要か / 不要か
| 必要な案件 | 不要な案件 |
|---|---|
| データを外部 / グループ会社に提供している | 完全社内利用のみ |
| Snowflake が主要 DWH | Snowflake 不使用 |
| 利用者のスキル差で価値提供がブレている | 利用者のスキルが均一 |
| データ提供を継続収益化したい | 一括売り切り前提 |
| グループ会社統合の横断分析が課題 | グループ会社なし |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 配布範囲 | 対象エージェント + 利用先 | 拡大時の承認プロセス |
| データ責任分界 | 提供側 / 利用側の責任範囲 | 不正利用時の責任 |
| 品質保証 | 想定回答セット + 品質指標 | 劣化時の対応 SLA |
| 監査ログ保持 | 期間 + 暗号化 + アクセス制御 | 法令・契約要件 |
| 収益按分 | 提供側 / 受託側のレベニューシェア | 計測方法 |
| 退場時引き渡し | エージェント定義 + ガード仕様 | 自社運用継続性 |
価格モデル — Agent Sharing 受託パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 診断 / PoC | 200 万円〜（6 週間） | ユースケース棚卸し + パイロット 1 エージェント | レポート + 設計書 |
| Lite | 70 万円〜 / 月 | 配布エージェント 1〜3 個 | 月次レビュー + ガード運用 |
| Standard | 170 万円〜 / 月 | 配布エージェント 3〜10 個 | + 監査 + 利用ダッシュボード |
| Enterprise | 360 万円〜 / 月 | 10 個超 / 複数提供先 | + 専任エンジニア + 収益最適化 |
| 初期構築 | 600 万円〜（一括） | Snowflake + Cortex + ガード基盤 | 全プラン共通オプション |
顧客側 ROI 試算（データ提供企業 / グループ会社 5 社 + 外部顧客 10 社想定）
| 項目 | 既存（Secure Data Sharing のみ） | Agent Sharing 導入後 | 差分 |
|---|---|---|---|
| データ提供サポート工数 | 月 80 時間 | 月 15 時間 | -65 時間 |
| 利用者の問い合わせ件数 | 月 120 件 | 月 25 件 | -95 件 |
| 新規利用者オンボード期間 | 平均 6 週間 | 平均 1 週間 | -5 週間 |
| データ販売単価（年） | 1 社あたり 500 万円 | 1 社あたり 1,200 万円 | +700 万円 |
| 利用継続率（年次更新） | 65% | 90% | +25pt |
| 年間効果 | — | — | 約 1 億円相当の収益拡大 + 工数削減 |
時給 8,000 円換算で 年間 620 万円の工数削減 + データ提供単価倍増 + 継続率改善。Standard プラン（年額 2,040 万円）でも 3〜4 ヶ月で回収可能で、収益モデル転換のインパクトが極めて大きい領域です。
ハマりやすい 5 つの落とし穴
落とし穴 1: 「データだけ共有」のまま放置
Agent Sharing を入れずに データ共有のみで運用すると、利用者のスキル依存が続き、価値提供が安定しません。配布候補エージェントを最初に設計することが重要です。
落とし穴 2: ガードレールが緩い
利用者側に 自由にプロンプトを書ける自由度を与えすぎると、機微情報の抽出を試みられます。プロンプトレベルのフィルタ + Row Accessを必ず組み合わせます。
落とし穴 3: 品質指標を測らない
エージェント配布後の 応答品質を測らないと、「使えないエージェント」として利用者離れが発生します。想定回答セット + 自動品質モニタを初期から組み込みます。
落とし穴 4: 監査ログを片側のみ取得
提供側のクエリログだけだと、「何を聞かれて何を答えたか」が抜けます。プロンプト + 応答ログを必ず保管します。
落とし穴 5: 収益モデルを契約に書かない
「とりあえず使ってもらう」とサブスク / 従量課金の 計測方法を契約に書かないと、収益化のタイミングを逃します。配布開始時から課金モデルを契約に明記します。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1〜3 | ユースケース棚卸し + 配布候補エージェント設計 + 利用者ヒアリング |
| Week 4〜5 | ポリシー + 契約テンプレート + 価格モデル設計 |
| Week 6〜9 | Snowflake Agent Sharing + Cortex + ガード基盤構築 |
| Week 10〜11 | パイロット 2〜3 社展開 + ガード調整 |
| Week 12 | 配布開始 + ヘルプデスク FAQ |
| Week 13 | 月次運用レビュー初回 + 収益レポート |
まとめ — 「データを売る」から「分析能力を売る」へ
Snowflake Agent Sharing は、「データ共有」から 「データ + 分析エージェント共有」へとデータビジネスの構造を変える分水嶺です。受託でデータ基盤を支える立場では、ユースケース設計 + ガード + 監査 + 収益化を一体で提供する 「Agent Sharing 設計 + 配布運用代行」が新しい主力サービスになります。
弊社では 診断 / Lite / Standard / Enterprise の 4 段階で本パッケージを提供しています。「Snowflake Data Sharing は入れたが価値が出ない」「グループ会社横断分析を進めたい」「データ販売を継続収益モデルに転換したい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
