Databricks Data+AI Summit 2026が6/15開幕｜「発表を待ってデータ基盤のRFPを書くべきか」の判断軸

結論：要件の8割はベンダー非依存。「発表待ち」を理由にRFPを止める必要はない

Databricksの年次イベント 「Data + AI Summit」が2026年6月15〜18日、サンフランシスコ（モスコーニ・センター）で開催 される。同社発表によれば現地参加3万人超を見込み、800超のブレイクアウトセッション でデータエンジニアリング・ガバナンス・エージェント・AIを扱う。基調講演には共同創業者のAli Ghodsi氏らに加え、MicrosoftのSatya Nadella氏（事前収録）、OpenAIのGreg Brockman氏 が登壇予定で、Lakebase・Genie・Agent Bricks・Lakeflow・Unity Catalogといった製品群とエージェント型アーキテクチャが主題になるとみられる。

6月1〜4日のSnowflake Summit（既報の解説）と合わせ、データ基盤2強の年次発表が今月で出揃う。基盤更改を検討中の企業が迷うのは「発表を待ってRFPを書くべきか」だ。結論は、待つのは製品選定の比較表だけでよく、RFPの本体（自社要件の定義）は今日から書き始めるべき、である。エージェント対応のような新機能は両社とも出してくるが、自社のデータ整備・権限設計・移行制約はイベントで何が発表されても変わらないからだ。

押さえるべき1点：イベント発表で変わるのは「どの製品を選ぶか」の比較材料であって、「自社が何を必要とするか」ではない。発表待ちを理由に要件定義を止めると、選定だけが新機能の印象に引きずられる。

2強の年次イベント：何が出揃うのか

両社に共通する方向は明確で、データ基盤を「人がBIで見る」場所から「AIエージェントが分析・実行する」場所へ 進化させる競争になっている。つまりどちらを選ぶにせよ、エージェントに任せられる権限管理・データ系譜・監査の整備が利用側の前提になる。4製品の費用・運用負荷の基礎比較はDWH 4強選定ガイドを参照してほしい。

「待つ/待たない」の判断軸

待たなくてよいもの（今日から進める）

1. データの棚卸しと整備方針：どのシステムのどのデータを集約するか、正本はどれか、品質基準は何か。どの製品でも必要で、ここが基盤更改の工数の大半を占める
2. 権限・ガバナンス要件：誰が（将来はどのエージェントが）何に触れてよいか。AI前提の基盤ほど先に決める必要がある（味の素のAI-Readyデータ基盤事例参照）
3. RFPの要件本体：「Unity Catalog対応」のような製品機能名でなく、「列レベルの系譜追跡ができること」のような能力要件で書く。こう書いておけば発表後も書き直しが要らない

待ってよいもの（6/18以降に確定する)

• 製品比較表と価格交渉：両社の新発表・価格体系を反映してから確定する
• エージェント連携の具体機能の評価：発表直後の新機能は成熟度の見極めが必要で、GA（一般提供）時期と前提条件を確認してから採点する

チェックの勘所：RFPに特定製品の機能名を書いた瞬間、比較は形式化する。能力要件で書き、製品名は選定フェーズの比較表だけに登場させるのが、発表ラッシュ期に最も安全なRFPの書き方だ。

プレビュー記事としての読み方

この記事は会期前のプレビューであり、正式発表の評価記事ではない。したがって、製品優劣や新機能の採用判断をここで確定するのではなく、発表後に評価すべき観点を先に固めるための記事として読むべきである。

RFPで先に固めるべきなのは、自社のデータ源、更新頻度、権限、監査、移行制約、既存クラウド契約である。イベント発表で変わるのは製品機能と価格であり、自社の制約条件は変わらない。発表待ちで止めるべき作業と、今日から進めるべき作業を分けることが、この記事の実務上の価値である。

よくある質問（FAQ）

Q. 発表直後の新機能を要件に入れてよいか？ A. 原則として「GA済み・自社リージョンで利用可能・価格が公表済み」の3条件を満たすものだけを必須要件にする。発表段階の機能は加点要素に留め、それ前提のアーキテクチャを組まないこと。イベント発表からGAまで数カ月〜1年かかることは珍しくない。

Q. SnowflakeとDatabricksのどちらが優位か？ A. 一般論の優劣では決まらない。分析中心・SQL人材主体ならSnowflake、データエンジニアリング・ML内製が厚いならDatabricksが馴染みやすいという傾向はあるが、既存クラウド・データ量・人材・費用モデルで結論は変わる。両社の6月発表が出揃った時点で、自社要件に対する採点で比較すべきだ。

Q. 2強以外（BigQuery・Redshift等）は検討から外してよいか？ A. 外すべきではない。既にGoogle CloudやAWSに基盤が寄っている企業では、同一クラウド内の選択肢が運用・費用で勝つケースが多い。2強のイベントは「業界の方向」を読む材料とし、選定は自社の制約条件から行うのが正しい。

発注・更改判断に落とすための確認観点

システム開発や基盤更改の記事を読むときは、ニュースそのものよりも自社の要件に変換できるかが重要である。確認すべきは、対象システム、利用部門、業務影響、現行保守の期限、データ移行の難易度、権限・ログ・監査要件、移行中の業務継続方法である。

特にRFPや要件定義では、製品名やベンダー名を先に書くと比較が歪む。先に書くべきなのは、処理量、可用性、権限、監査、移行制約、運用体制である。ニュースをきっかけに検討を始める場合でも、発注書には自社の制約条件を具体化して入れる必要がある。

GXOへ相談する前に整理しておくと早い情報

相談前には、現行システムの概要、利用人数、主要業務、連携先、保守期限、障害履歴、困っている改修、予算感、希望時期をまとめる。詳細な仕様書がなくても、画面・帳票・データの棚卸しから要件を復元できる。

90日で要件定義へ進めるロードマップ

最初の30日は、現行業務と現行システムの棚卸しに使う。画面、帳票、データ、連携、利用者、例外処理、障害履歴を整理し、どの業務が止まると事業影響が大きいかを確認する。古いシステムほど仕様書よりも現場の運用が正になっているため、担当者ヒアリングも必要である。

31日目から60日目は、刷新・更改の目的を決める。保守期限への対応だけなのか、業務改善、データ活用、AI導入、セキュリティ強化まで含めるのかで、要件は大きく変わる。ここで目的を広げすぎると失敗するため、必須要件と将来要件を分ける。

61日目から90日目は、RFPまたは要件定義書に落とす。機能一覧だけでなく、権限、ログ、監査、非機能、移行、テスト、保守、運用体制を含める。ニュースを見て急いで製品選定に入るより、この90日を使って発注側の物差しを整える方が、失敗コストは小さい。

よくある失敗パターン

第一の失敗は、ニュースをきっかけに製品選定から始めることだ。製品名を先に決めると、要件定義が後付けになり、現行業務の例外や移行制約が漏れる。まず現行業務、データ、権限、帳票、連携、非機能を整理する必要がある。

第二の失敗は、移行を軽く見ることだ。新システムを作るより、現行データを正しく移し、業務を止めずに切り替え、利用者を教育する方が難しいことが多い。移行方式、並行稼働、切り戻し、移行後の照合を要件に入れない発注は危険である。

第三の失敗は、保守運用を見積もりから外すことだ。システムは公開して終わりではない。権限変更、法改正、障害、脆弱性、データ増加、連携先変更に対応する体制が必要になる。初期開発費だけで比較すると、運用で破綻する。

成果物として残すべきもの

発注前には、業務フロー、機能一覧、権限マトリクス、帳票一覧、データ一覧、連携一覧、非機能要件、移行方針、受入テスト方針を残す。完璧な仕様書でなくても、これらがあるだけで見積もりの精度とベンダー比較の質は大きく上がる。

判断表：読むだけで終わらせないための整理

この表を埋めると、記事の内容を「読んだ情報」から「社内で動かすタスク」に変えられる。特に重要なのはNGサインである。NGサインが1つでも出る場合、問題は個別ニュースではなく、社内の判断プロセスにある。

公開情報は日々更新されるため、記事本文の数値や期限をそのまま固定値として扱うのではなく、一次情報の最新版、社内の対象有無、実施記録をセットで確認する。これにより、速報記事を一過性の話題で終わらせず、監査・稟議・改善計画に使える材料へ変換できる。

いつGXOに相談すべきか

• データ基盤の更改を検討しているが、RFPに書くべき自社要件の整理 ができていない
• ベンダー各社の発表が続き、中立的な製品比較・選定の物差し が社内にない
• 基盤更改とあわせて、データ整備・権限設計・AI活用までのロードマップ を引きたい

GXOは、データ基盤構築による要件定義・製品選定の中立支援・構築実行、DX・システム開発による周辺システム連携までを一体で提供している。発表ラッシュの今こそ、要件を自社軸で固める好機だ。→ 相談はこちら

関連記事

• データ基盤は「閲覧」から「エージェントが動かす」時代へ｜Snowflake Summit 26に学ぶ権限と系譜の備え
• DWH 4強選定 中堅企業向け 2026｜Snowflake／BigQuery／Redshift／Databricksを比較
• 味の素の「AI-Readyデータ基盤」事例に学ぶ｜生成AIが進まない原因はデータ側にある

追加確認：社内展開時の合意形成

社内でこの記事を共有する場合は、単にURLを回覧するだけでは不十分である。関係部門に対して、対象有無、対応期限、必要な判断、次回会議で決めることをセットで伝える。情報共有だけで終わると、誰も担当しないまま時間が過ぎる。

また、対応を急ぐほど、後から見たときの判断根拠が重要になる。なぜ今対応するのか、なぜ今回は見送るのか、どの一次情報を見たのか、誰が承認したのかを簡単に残す。短いメモでも、監査・稟議・次回対応の引き継ぎに使える。

RFPに入れるべき非機能観点

データ基盤RFPでは、機能比較だけでなく非機能を具体化する必要がある。可用性、バックアップ、権限変更の承認、監査ログの保管期間、データ保持期間、リージョン、暗号化、障害時の復旧目標、コスト上限、利用部門への権限委譲を明記する。

AIエージェントがデータ基盤を利用する前提では、さらに「人ではない実行主体」の権限をどう扱うかが重要になる。サービスアカウント、エージェントID、ツール実行ログ、データ参照範囲、誤実行時の停止方法を要件に入れる。ここを発表後の製品機能に任せるのではなく、自社の統制要件として先に定義しておくことが、RFPを強くする。

編集部注：公開後の更新方針

本記事は速報性のある公開情報をもとに、GXOの商談領域であるシステム開発、AI導入、セキュリティ、レガシー刷新、データ基盤構築の観点へ翻訳したものである。公開後に一次情報の更新、ベンダー側の追記、制度要件の変更、悪用状況の変化が確認された場合は、本文・参考資料・CTAの導線を更新する。

読者が実務で使う場合は、記事の数値や期限を固定値として扱うのではなく、必ず一次情報と自社環境を突き合わせることが重要である。特に、契約条件、対象バージョン、制度要件、提供リージョン、価格、悪用状況は短期間で変わり得る。この記事の役割は、最新情報を自社の判断項目へ変換することであり、最終判断は一次情報と社内の対象有無確認にもとづいて行う。

参考資料

• Databricks「Databricks Announces 2026 Data + AI Summit Keynote Lineup」（2026年6月2日）

本記事は2026年6月12日時点の公開情報をもとに作成。会期中の新発表内容は本記事には含まれない（開幕後に続報予定）。登壇者・セッション構成は変更される可能性があるため、一次情報の最新版を必ず確認すること。