Iceberg Summit 2026のパネルディスカッション「Bridging Open Source Innovation with Customer Value: A Product Perspective」をまとめます。
Bridging Open Source Innovation with Customer Value: A Product Perspective - YouTube
- 登壇者
- 自己紹介とプロダクトにおける Iceberg の位置づけ
- なぜ Iceberg なのか、なぜオープンソースなのか
- Iceberg が「正しい選択」だと確信した瞬間
- エンタープライズ顧客が本当に求めているもの
- スケール時の運用課題と隠れた指標
- 顧客との対話の変化と「Iceberg を意識させない」理想
- オープンソースコミュニティとの関わりと還元
- OSS化か独自実装かの判断軸
- 過小評価されている、今後期待する機能
- まとめ
登壇者
モデレーターは Apache Iceberg PMC メンバーであり、Microsoft Fabric の Iceberg 連携にコントリビューターとして携わる Kevin Liu 氏が務めました。OSS コントリビューターでありコミュニティの一員でもある立場から、各社のプロダクト責任者に問いを投げかけます。
- Christian Romming 氏（Etleap・Founder & CEO）。マネージドなデータパイプラインを約10年提供し、数年前に製品全体を Apache Iceberg 中心に再設計しました。
- James Rowland-Jones 氏（Snowflake・Director of Product Management）。JRJ の愛称で知られ、Iceberg と Polaris を含む Lakehouse エコシステムを統括しています。
- Jason Reid 氏（Databricks・Director of Product Management）。ストレージとカタログを担当し、Netflix 時代に Ryan Blue 氏らと Iceberg の黎明期に関わりました。
- Keith Chapman 氏（Dremio・Senior Director of Engineering）。カタログ領域と、Iceberg・Polaris まわりの OSS コントリビューションを率いています。
- Yuval Yogev 氏（Ryft・Co-founder & CTO）。人だけでなく AI やエージェントが扱える自律型データレイクを構築しています。
自己紹介とプロダクトにおける Iceberg の位置づけ
モデレーターの Kevin Liu 氏は冒頭で、各社の事業内容と、自社プロダクトにおいて Apache Iceberg がどこに位置づけられているかを順に問いました。
Ryft の Yuval Yogev 氏は、Iceberg は同社のすべての中心にあると述べました。Ryft が構築するのは自律型のデータレイクで、当初は人間を対象にしていたものが、現在は AI やエージェントも対象に広がっています。狙いは、大量の人員やリソースを割かなくても、ペタバイト規模の Iceberg データレイクを運用できるようにすることにあります。
Dremio の Keith Chapman 氏は、同社が長年 Iceberg と取り組んできたと振り返り、Iceberg は後から付け足したものではなく、ネイティブに作り込んだものだと強調しました。担当するカタログ領域に加え、Iceberg と Polaris まわりの OSS コントリビューションも率いています。
Databricks の Jason Reid 氏は、ストレージとカタログを担当する立場から、Iceberg がテーブルフォーマットとしての第一級プロダクトであるだけでなく、カタログ API の設計や UDF・ビューの扱い、エコシステム全体での相互運用の考え方にまで関わっていると説明しました。
Snowflake の James Rowland-Jones 氏は、同社が「妥協なき相互運用性（interoperability without compromise）」を信条とし、顧客が自分のデータに対する裁量を持てるようにすることを重視していると語りました。担当する Lakehouse エコシステムは Iceberg と Polaris を軸にしています。
Etleap の Christian Romming 氏は、約10年にわたりデータの取り込みやモデリングを担うマネージドパイプラインを提供してきたと述べ、数年前に製品全体を Iceberg 中心に再設計したと説明しました。
5社とも Iceberg を後付けではなく前提として扱う点で一致していました。
なぜ Iceberg なのか、なぜオープンソースなのか
モデレーターの Kevin Liu 氏は、各社がなぜ Iceberg を、そしてオープンソースを選ぶのか、コミュニティに惹かれる理由を問いかけました。
Dremio の Keith Chapman 氏は、かつてデータが各ベンダー独自のフォーマットでサイロ化していた点を指摘しました。専用フォーマットは特定エンジンへの依存を生み、データのコピーが増え、結局は自分のデータにアクセスするために費用を払う構造だったと述べています。Iceberg が解いたのはこの問題で、仕様に従えばどのエンジンからも1コピーのデータを操作でき、ユースケースごとに最適なエンジンを選べるようになった点を強調しました。
Databricks の Jason Reid 氏は、Netflix 時代に Ryan Blue 氏らと初期から関わった立場から、自身の役割はコミットよりもユースケースを持ち込むことだったと振り返り、SQL をファイル上で動かそうとした課題が Iceberg V1 につながったと語りました。
Snowflake の James Rowland-Jones 氏は、オープンソースの恩恵を受けるだけでなく、貢献し還元する姿勢を重視すると述べ、妥協なき相互運用性の実現には投資が要ると指摘しました。
Etleap の Christian Romming 氏は、レイクとウェアハウスの世界がようやく統合されつつあると評し、各社が仕様を着実に実装してきた点に敬意を示しました。データプラットフォームを何度も作る中で常に欠けていたものが Iceberg で埋まったと述べ、これこそ投資すべき対象だと結論づけています。
Iceberg が「正しい選択」だと確信した瞬間
Kevin Liu氏は、各社の歴史のなかで「これは正しい選択だ」と確信した転機があったかを問いかけました。
Ryftの Yuval Yogev氏は、Netflix や Apple のような巨大企業が Iceberg を使っているという事実だけでは確信に至らなかったと振り返ります。ペタバイト規模を扱う大企業の事例が、はたして一般の組織に当てはまるのかが見えなかったためです。転機になったのは、さまざまな業種の小規模スタートアップや、これほど早く採用するとは思えなかった組織が動き出したのを目にしたときでした。そこで Iceberg が一部の大企業向けの解ではなく、次世代データプラットフォームの標準だと理解したと述べています。
Dremioの Keith Chapman氏は、オープン性と相互運用性こそが決め手だと指摘します。当初は痛点の解消から始まったものが、いまやオープンな Lakehouse へ移行するという戦略的な方向性へと変わり、その中心に Iceberg のテーブルフォーマットが据えられていると説明しました。
Snowflakeの James Rowland-Jones氏は、データベースの構成要素を分解して組み替える「unbundling（database inside out）」という発想に触れたことが、個人的な気づきの瞬間だったと語ります。さらに Iceberg 単体ではなく、Iceberg REST カタログ仕様をはじめとする周辺プロジェクトの広がりに価値を見いだしており、Snowflake が Polaris を Apache に寄贈し Apache Polaris として立ち上げたこと、そして直近でトップレベルプロジェクトへ昇格したことが、この技術とコミュニティが定着していくという継続的な裏付けになっていると述べました。
Databricksの Jason Reid氏にとっては、より個人的な転機でした。1月の寒い日に Ryan Blue氏から Netflix を離れて Iceberg を軸にした会社を始めると電話を受けた瞬間が、人生を決定づけたと振り返っています。
エンタープライズ顧客が本当に求めているもの
モデレーターの Kevin Liu 氏は、OSS コントリビューターの立場では顧客のユースケースから一歩離れがちだと述べ、顧客に近いベンダーから見たエンタープライズの要望を引き出しました。
Ryft の Yuval Yogev 氏は、ストリーミングと削除処理への要求を最も顕著な例として挙げました。ゲーム会社のイベント取り込みや金融機関のように、顧客は V3 や V4 の完成を待てず、いますぐデータをストリーミングしたいと考えています。そこで Etleap の Christian Romming 氏との議論を通じ、現状の削除機能から引き出せるものを最大限活用し、ペタバイト規模のストリーミングを破綻なく実現する暫定的なブリッジ解をコミュニティとともに見いだしたと振り返りました。最終的な解は V4 を待つことになりますが、エンタープライズの圧力とコミュニティの正しさのバランスが取れた例だと評価しています。
Databricks の Jason Reid 氏も、低レイテンシな取り込みに加え、deletion vector や row ID、ブランチ・タグといった機能をハイパースケーラーとウェアハウスのベンダーが一貫して実装する相互運用性の重要性を指摘しました。
Dremio の Keith Chapman 氏は、読み書きの相互運用は十分に機能する一方、相互運用ガバナンスが課題だと述べました。行マスキングや列フィルタリングといったきめ細かなアクセス制御は各社が独自実装を持つものの、それを使うと特定エンジンにロックインされてしまいます。標準化されたばかりの UDF 仕様や、現在策定中の FGAC（fine-grained access control）仕様を通じ、ガバナンスを伴う真の相互運用を目指す動きが進んでいます。
Snowflake の James Rowland-Jones 氏は、性能と直接アクセスか、柔軟性と選択肢かという二者択一は誤った対立だと指摘しました。Iceberg REST がエンジン非依存の仕様であり、secure vended credentials のような実装に支えられること、そして複数プラットフォームをまたぐ責務の委譲が、効率を保ちつつ直接アクセスの原則を守る鍵になると論じています。
スケール時の運用課題と隠れた指標
Kevin Liu氏は、Iceberg を本番のエンタープライズ規模で運用する際の痛点と、顧客が気にする指標について各社に尋ねました。
Ryft の Yuval Yogev氏は、速度とコストは以前から変わらず存在し続ける指標だとしたうえで、より見えにくい指標が重要になっていると指摘しました。レイクハウスを10倍に拡張したときに、チームや人員、リソースも10倍にしなければならないのかという問いです。さらに、数百のデータエージェントが同時に読み書きする将来を見据えると、メタデータが最適化されているかを大勢のデータエンジニアが監視し続ける形は現実的ではなく、メタデータ管理を削減する取り組みや適切な仕様設計でこれを抑えられるべきだと述べました。
Dremio の Keith Chapman氏は、Iceberg を使い始めた顧客が見落としがちなテーブルメンテナンスの存在を挙げました。利用できるかという段階は越え、いまはどう使いこなすかが論点になっているものの、システムの中核を理解しないまま進めて不具合に直面する例が多いといいます。カタログとエンジンを束ねた Apache Polaris のようなプロジェクトが、その溝を埋めると述べました。
Databricks の Jason Reid氏は、単一の仕様に対して4〜5種類の言語実装と多数のエンジンが存在し、それらが一つのデータセットを協調して更新する複雑さを課題に挙げました。マネージドプラットフォーム、顧客のコード、OSS、Python ライブラリが入り混じるため、問題の切り分けが難しいというわけです。
Snowflake の James Rowland-Jones氏は、外部からの書き込みを現状はポーリングで検知している点に触れ、イベントベースの通知へ移ることで運用をより能動的にでき、スケーラビリティの改善につながると述べました。これらの運用面の改善には Iceberg V4 のメタデータ刷新も寄与すると見ています。
顧客との対話の変化と「Iceberg を意識させない」理想
モデレーターのKevin Liu氏は、Iceberg の普及曲線が初期採用者の段階を越えた今、顧客との会話がどう変わったかを各社に尋ねました。
Snowflakeの James Rowland-Jones氏は、以前はストレージバケットで動かせばコストが下がるといった運用的・戦術的な問いが多かったのに対し、今はデータを1コピーで持つことを前提に、オープンなフォーマットだからこそ得られる追加価値やAIで何ができるかという価値ベースの問いに変わってきたと述べました。Dremioの Keith Chapman氏も、データが1コピーに集約された結果、顧客の関心は「Iceberg は自分に使えるか」から「いかに早くデータから洞察を得られるか」へ移り、データの可用性から洞察までの時間短縮が新たな焦点になっていると指摘しています。
Databricksの Jason Reid氏は、Ryan Blue氏が講演でよく示す「本来ユーザーはテーブルフォーマットを意識すべきではない」という考えに触れました。Postgres を使うときにディスク上のビット配置を気にせず SQL を書いて信頼するのと同じ状態が理想だが、Iceberg はこの1〜2年で近づいたものの、まだ Iceberg の仕組みを理解しないと効果的に使えない場面が残っていると率直に評価しています。
Kevin Liu氏は、従来のマネージドなデータベースサービスとは異なり、自分のオブジェクトストレージに1コピーだけ置いて持ち運べる点をパラダイムの転換として補足し、顧客の使い方にはまだ適応の過程があるとまとめました。
オープンソースコミュニティとの関わりと還元
Kevin Liu氏は、自身がオープンソースコントリビューターである立場から、顧客と接する各社がコミュニティとどう向き合い、何を還元しているのかを問いました。
Dremioの Keith Chapman氏は、顧客が求めるのはオープンなレイクハウスであり、その本質はオープンなガバナンスとインターオペラブルなガバナンスにあると整理しました。社内では実装済みでも特定エンジンに閉じてしまう機能、たとえばUDF（ユーザー定義関数）やFGAC（行・列レベルのきめ細かなアクセス制御）の仕様を、顧客の痛点を起点にコミュニティへ持ち込み標準化していると述べています。同氏は、Iceberg-GoやIceberg-Pythonをはじめ、Icebergを起点に新たなApacheプロジェクトが派生している点にも触れ、コミュニティの広がりを評価しました。
Snowflakeの James Rowland-Jones氏は、関わり方を段階的に説明しました。他者の提案やコミットをレビューして動向を把握する段階、自社エンジニアが特別なチームに属さずともPRを出すよう奨励される貢献の段階、そしてSQLやPythonからの利用を含めて実装でも先導する段階という形です。エコシステムは双方向であり、受け取る分だけ与える必要があるという姿勢を示しました。
Databricksの Jason Reid氏は、自社プラットフォーム上で顧客がやりたいことはすべてIceberg上で動かねばならず、顧客起点の要望が必然的にコミュニティでの議論につながると述べています。Etleapの Christian Romming氏は、ストリーミング取り込みについて、自分たちだけの島で独自の仕組みを作るのではなく、構築したものをFlinkとIcebergに還元する方針を語りました。今作っている形が五年後も標準として動いていてほしいという考えです。
OSS化か独自実装かの判断軸
Kevin Liu氏は、商用上の利害とオープンソースへの還元が衝突しうる場面で、ある機能をOSS化するか独自実装にとどめるかをどう判断しているのかを問いました。
Ryftの Yuval Yogev氏は、トレードオフの本質を「IPを守るか秘密を明かすか」ではなく速度に置きました。スペックは誰にでも開かれているため独自機能で差別化を続けることに意味はなく、何かをデバッグしようとGoogleで検索すると既に誰かが同じ問題を解決したPRが見つかる、それがコミュニティの恩恵であり近道だと語りました。だからこそ自社の成果も早めに上流へ戻すという立場です。
Snowflakeの James Rowland-Jones氏は、Apache Iceberg に寄贈された GeoType（地理空間データ型）を例に、primitive をコミュニティで標準として整備する層と、それを実装して顧客価値を積み上げる商用の層を切り分ける考え方を示しました。型という土台がコミュニティで開かれることで新しいワークロードが解放され、その上で各社が価値を加えられるという整理です。
Dremioの Keith Chapman氏は、社内で長く持っていたUDFや OAuth 2.0 の実装を、他エンジンとの相互運用のために上流へ寄贈した事例を紹介しました。UDFを付けたテーブルが他エンジンから読めなくなる課題を、仕様としてコミュニティに上げることで解いたと述べています。
Etleapの Christian Romming氏は、コードを書くコスト自体が下がっていく中で、価値は実装ではなく標準と広範な採用へ移っていくと展望しました。Icebergコミュニティの構築に近道がなかったように、その積み重ねこそが本来の価値だという見方です。
過小評価されている、今後期待する機能
締めにあたり Kevin Liu 氏は、オープン性や相互運用性以外で、各登壇者が過小評価されていると感じる機能、あるいは今後に期待する機能を尋ねました。
Ryft の Yuval Yogev 氏が真っ先に挙げたのが Variant でした。半構造化データを格納できる新しい型で、すでに注目を集めてはいるものの、評価が追いついていないという見方です。型として読み書きできる基本的な対応にとどまらず、完全にシュレッドされた Variant、つまりフィールドごとに分解して列として格納し、リッチなメタデータを伴う読み書きが Iceberg に正式に入るのを待っている企業が控えていると指摘しました。他プラットフォームで Variant に慣れた利用者が多く、その波はまだこれからだという見立てです。
Snowflake の James Rowland-Jones 氏も Variant が V3 で最も期待される機能だと認めつつ、レーダーの下に隠れているものとして GeoType を挙げました。地理空間データを扱う型で、新しいワークロードそのものを Iceberg にもたらしたにもかかわらず、その可能性はまだ表面をなぞった段階だと述べています。さらに先を見据えて、V4 とマルチモーダル対応によるメディアレイクの実現にも期待を示しました。
Databricks の Jason Reid 氏は、Netflix 時代に Hive から Iceberg へ移行して得た信頼できるスキーマ進化を挙げ、列のリネームや削除が当たり前にできるようになったことが大きな解放だったと振り返りました。
Dremio の Keith Chapman 氏は索引機能への期待を語りました。とくにストリーミングインジェストや AI 用途で必要となる低レイテンシ、リアルタイムの更新や削除を支えるプライマリキーインデックスを挙げ、現在コミュニティで複数種類のインデックスが活発に議論されている点に注目しています。
まとめ
このパネルを貫いていたのは、オープンなフォーマットとエコシステムを育てる投資が、結果として各社の顧客価値につながるという共通認識です。実装そのものよりも標準と広範な採用に価値が移るなかで、ベンダー間の競争と協調が同時に進んでいる様子がうかがえました。「速く行きたければ一人で、遠くへ行きたければ皆で」という言葉が、Iceberg コミュニティの現在地をよく表しています。
