エグゼクティブ・サマリー
Treasure AIの「Open Catalog Access」は、企業のデータ活用を次のレベルへ引き上げます。この機能により、CDPのデータに対し、主要な分析・AIプラットフォームがサポートするオープンテーブルフォーマット「Apache Iceberg」経由で直接アクセスが可能です。
顧客データをわざわざ別のシステムにコピーする必要はありません。Snowflake、Databricks、BigQueryといった主要なデータエンジンから、管理されたIceberg RESTカタログを通じて、ガバナンスが効いたCDPのテーブルに直接つなぐことができます。アクセス権限やセキュリティ、データガバナンスを一元管理したまま、安全な「読み取り専用アクセス」を提供します。
これにより、企業はデータのサイロ化(分断)を解消し、既存の分析環境や機械学習、データアクティベーションの基盤全体で、信頼できる顧客データをシームレスに活用できるようになります。基盤データのコントロールを手放すことなく、また特定のベンダーに縛られることもなく、複数エンジンにまたがる高度な分析、AIモデルのトレーニング、そして外部システムへの「Customer 360(顧客の全体像)」インサイトの拡張が可能になります。
本日、CDPの新しい機能である「Open Catalog Access」を発表できることを大変嬉しく思います。この機能により、CDPデータをApache Icebergテーブルとして公開し、データを別のウェアハウスにコピー(複製)することなく、Snowflake、Databricks、BigQueryから直接クエリを実行できるようになります。

これは、Treasure AIのアーキテクチャにおいて非常に重要なマイルストーンです。その理由をお話ししましょう。
誰もが目指す「一元化」。しかし現実の企業データは「分断」されている
ここ数年、データ業界の常識は「すべてを1か所に集約する」ことでした。Snowflake、Databricks、BigQueryといったデータウェアハウスが、企業の「真実の源泉(System of Record)」となったのには正当な理由があります。データを一元化すれば、ガバナンスが効き、分断が解消され、大規模な分析が可能になるからです。
これを実際にやり遂げている企業もあります。しかし、ほとんどの大企業にとって、その理想は絵に描いた餅になりがちです。それはテクノロジーの問題ではなく、企業のデータはそもそも本質的に分断される運命にあるからです。部門が違えば、目的が異なり、使うシステムも変わります。マーケティング部門が定義する「顧客」は、財務部門が定義する「顧客」と同じではありません。それぞれのシステムは自分の領域内では「正しい」のですが、それ単体で全体像を語れるシステムは存在しないのです。こうした組織にとって本当に現実的なアプローチとは、無理やりすべてを1つのウェアハウスに詰め込むことではありません。「分断されていること」を前提として受け入れ、その上に相互連携(インターオペラビリティ)の仕組みを構築することです。
CDPはその典型的な例と言えます。CDPは顧客のアイデンティティを統合し、ターゲット層(オーディエンス)を作り、エンゲージメントを高めるために存在しています。しかし、CDPチーム「以外」のメンバー、特に他の事業部の担当者がそのデータを使おうとした途端に壁にぶつかります。CDPチームにお伺いを立てなければ、どんな顧客データがあるのかもわからず、アクセス権ももらえないからです。その結果、どうなるでしょうか? ガバナンスの効いた統一カタログからデータを読み取る代わりに、各チームが自分たち専用のデータ抽出プログラムを個別に作ってしまうのです。
もちろん、すべての顧客データを1つのウェアハウスにまとめられるなら、そうすべきです(そのために「コンポーザブルCDP (Composable CDP)」という選択肢があります)。しかし、それが難しい場合や、インフラの運用を自社で抱えたくない場合、無理に統合するのは正解ではありません。データが今ある場所にカタログと権限管理のレイヤーを被せること。そして、AIエージェントや分析パイプライン、データサイエンスチームが、普段自分たちが使っている環境から、許可された顧客データだけを見つけてアクセスできるようにすること。それこそが、私たちが導き出した解決策です。
私たちが開発したもの
「Open Catalog Access」は、Treasure AIのCDPのデータを、管理されたRESTカタログを通じてApache Icebergテーブルとして公開する機能です。裏側では以下のような仕組みが動いています。
- S3バケット: Icebergのテーブルデータを保存します。お客様ごとに完全に隔離されたAWS環境に、Treasure AIがプロビジョニングし、管理します。
- AWS Glue HMSカタログ: Icebergのメタデータ管理(メタストア)として機能します。
- IAMリーダーロール: 外部のクエリエンジンがアクセスするための、範囲が限定された「読み取り専用」の権限です。
これは「毎晩1回、CSVファイルを出力する」ような古い仕組みではありません。オープンなプロトコルを通じたリアルタイムなIcebergテーブルへのアクセスであり、お客様側で設定・承認するAWS IAMトラストポリシーによって強固に保護されています。
※CDPはあくまで「データの書き込み元」であり、外部エンジンは「読み取り専用」として機能します。
サポート対象の連携先
| データエンジン | 連携手法 | ステータス |
|---|---|---|
| Databricks | Glue HMSの外部カタログ機能を利用した、Unity Catalogフェデレーション | 一般提供 (GA) |
| Snowflake | Glue Iceberg RESTエンドポイントを利用した、カタログリンクデータベース | 一般提供 (GA) |
| BigQuery | BigQuery Omni (AWS Glue) を利用した、フェデレーションデータセット | 実験的提供 (Experimental) |
| その他のIceberg互換エンジン | Iceberg RESTカタログAPIへの直接接続 | 一般提供 (GA) |
すべての連携は、安全性を考慮して「読み取り専用」に設計されています。Iceberg REST APIや、カタログが発行する認証情報(Snowflakeの場合)、または限定的なAWS IAMロール(Databricks、BigQueryの場合)により、外部エンジンは元のデータを書き換えるリスクなく、必要な情報だけを安全に読み取ることができます。
なぜ「Apache Iceberg」を選んだのか?
Apache Icebergを採用した最大の理由は、それがレイクハウスアーキテクチャにおけるオープンテーブルフォーマットの事実上の標準(デファクトスタンダード)だからです。どこかのベンダーの独自規格でも、使い捨ての専用コネクタでもありません。主要なデータ基盤やAIプラットフォームのすべてが標準でサポートしている、オープンな仕様なのです。これにより、以下のメリットが生まれます。
- ロックインされない、高いポータビリティ: データは広く普及しているオープンなIcebergフォーマットで保存されます。仮に将来Treasure AIの利用を停止したとしても、データが独自のシステムや形式に縛られて取り出せなくなることはありません。
- 面倒なETL開発が不要: リバースETLツールを導入したり、お客様側でデータ連携のパイプラインを開発したりする必要はありません。テーブルの公開は、Treasure Workflow内で「INSERT INTO」や「CREATE TABLE AS SELECT」といった1つのSQLジョブを実行するだけで完了します。裏側のインフラはすべてTreasure AIが運用します。
- 常に最新のCDPデータを反映: ワークフローが実行されるたびにテーブルが更新されるため、カタログには常にCDP側の最新データが反映されます。連携のための専用パイプラインをメンテナンスする手間はかかりません。
想定されるユースケース
1. 複数エンジンをまたいだデータ分析
例えば、データサイエンスチームは機械学習にDatabricksを使い、マーケティングチームはTreasure AIでターゲット顧客を抽出し、BIチームはレポート作成にSnowflakeを使っているとします。「Open Catalog Access」があれば、これら3つのチームがデータをコピー・移動させることなく、同じCDPデータにアクセスできます。マーケティングの施策実行も、AIモデルの学習も、経営ダッシュボードの作成も、すべて1つのデータソースから完結します。
2. AIモデルのトレーニング
パーソナライズ化、解約予測、購買傾向の分析といったAIモデルにおいて、顧客データは最も価値の高い(シグナルの強い)学習データです。CDPデータをIceberg経由で公開すれば、機械学習パイプラインはわざわざデータを抽出(エクスポート)することなく、直接カタログから読み込めます。データはすでに統合・クレンジングされ、名寄せ(アイデンティティ解決)も終わっているため、機械学習エンジニアを悩ませる「データの前処理」という一番面倒な作業はすでに完了しているのです。
3. 外部システムへの「Customer 360」の提供
データメッシュやデータプロダクト指向のアーキテクチャを採用している企業にとって、CDPのデータは公開できるデータプロダクトの中でも最高レベルの価値を持ちます。「Open Catalog Access」を使えば、CDPデータを他のデータプロダクトと同じように、データベースやテーブルレベルの閲覧権限を設定した「管理されたテーブル」として公開でき、各チームが使い慣れたツールから簡単に見つけて利用できるようになります。
セキュリティの仕組み
データへのアクセスは、以下の3つのレイヤーで厳密に管理されます。
- AWS IAMトラストポリシー: Snowflake、Databricks、BigQueryなど、連携先ごとに特定の外部IDにアクセス範囲を限定します。
- データベース単位のアクセス制御: Icebergカタログ側の権限設定により、「どの連携先が、どのデータベースを見られるか」を制御します。そこから先の「自社内の誰がそのテーブルを見られるか」は、DatabricksのUnity CatalogやSnowflakeのロールなど、お客様が普段お使いのプラットフォーム側の権限管理に委ねられます。
- 安全な「読み取り専用」設計: 発行されるIAMロールは読み取り専用です。外部エンジンは検索(クエリ)するだけであり、データの書き込み・更新は引き続きCDP側で一元管理されます。
これらの設定は、「Iceberg Catalog Management API」を通じてREST経由で安全かつ簡単に管理できます。
単なる「データの開放」ではなく、「オープンスタンダード」である理由
企業内に散らばるデータ分断問題に対し、業界が出した答えは「一元化を諦めること」ではありませんでした。「一元化するだけでは不十分で、一カ所に集められないデータ同士をうまく連携(インターオペラビリティ)させる仕組みが必要だ」という現実的なアプローチへのシフトです。
データガバナンスのあり方も大きく変わってきています。権限管理を自社のシステム内に囲い込むベンダーもまだ存在しますが、業界全体のトレンドは「権限管理をオープンなカタログ層に持たせる」方向へと動いています。Apache Polaris、Databricks Unity Catalog、AWS Lake Formationなどがその代表例です。「Open Catalog Access」もこの流れに沿っており、まずはデータベース単位のアクセス制御からスタートし、権限を特定のエンジンに縛り付けないアプローチをとっています。「まとめられるものは中央にまとめ、どうしても必要な部分で柔軟に連携させる」という考え方です。
Treasure AIのアプローチが他と決定的に違うのは、以下の点です。
「Open Catalog Access」は、CDPを置き換えるものではなく、CDPの可能性を「拡張」する機能です。
Treasure AIのCDPの魅力は、インフラの運用負担ゼロ(ゼロオプス)、分かりやすい料金体系、そして導入後すぐに使えるスピード感にあります。「Open Catalog Access」は、その上に「Icebergによるオープンなアクセス」を追加するものです。つまり、「運用の手軽さ」と「データの自由な活用」のどちらかを選ぶ必要はありません。 両方手に入るのです。
| アプローチ | データの保存場所 | 外部エンジンからのアクセス方法 |
|---|---|---|
| Treasure AIのCDPのみ | Treasure AI | Treasure AIのREST API経由のみ |
|
Treasure AIのCDP + Open Catalog Access |
Treasure AI | Treasure AI REST API + Icebergカタログ |
| コンポーザブルCDP | お客様環境のウェアハウス | お客様のウェアハウスへ直接アクセス |
これが、Treasure AIが考える「オープンスタンダードを取り入れた管理されたCDP」の理想形です。インフラ管理の煩わしさからは解放され、データは本来あるべき場所に安全に保管されたまま。そして、社内の分析ツールやAIエージェント、担当者は、追加のシステム構築なしで、必要な顧客インテリジェンスにいつでも自由にアクセスできるのです。
ご利用を開始するには
「Open Catalog Access」は、Treasure AIのCDPをご契約中のすべてのアカウントで本日よりご利用いただけます。設定を有効にするには、担当のカスタマーサクセスまたはサポートチームまでご連絡ください。
ご利用開始までのステップ:
- APIでリソースを準備: S3バケット、Glueカタログ、IAMロールを作成します(最初の一度だけです)。
- 連携先の設定: Databricks、Snowflake、BigQueryなどの各ツールの設定ガイドに従って接続します。
- アクセス権の管理: Permission Management APIを使って、誰がどのデータベースを見られるかを設定します。
- 公開とデータの活用: Treasure WorkflowにAPIを1つ追加するだけで、指定したテーブルがカタログに公開され、接続先のツールから自動的に見えるようになります。
詳しいAPIの仕様や設定手順については、公式ドキュメントをご覧ください。
本機能がもたらす未来
現代のデータ活用基盤は、単一の巨大なシステムではなく、複数のツールが連携する「エコシステム」です。これからの時代を勝ち抜くのは、自社に蓄積された顧客の知見(インテリジェンス)を、特定のシステムに縛り付けることなく、ビジネスが求めるスピードで「一番必要な場所」へ自在に届けられる企業です。
「Open Catalog Access」が目指すのは、単に「CDPのデータを外から見られるようにする」ことだけではありません。顧客データを、オープンな標準規格でアクセスでき、最新のガバナンスで保護され、組織内の誰もが安全に利用できる「データエコシステムの主役(第一級市民)」として本来あるべき姿へと解放することです。
皆さまがこの機能を活用して、どのような新しい価値を生み出すのか、私たちも楽しみにしています。
「Open Catalog Access」が本日よりご利用可能になりました。ご利用を開始するにはドキュメントをご覧いただくか、カスタマーサクセス担当者までお問い合わせください。
よくあるご質問 (FAQ)
Q. この機能はComposable CDPでも使えますか?
A. 「Open Catalog Access」はTreasure AIのCDP向けの機能です。Composable CDPをご利用の場合、データはすでにお客様ご自身のウェアハウス(SnowflakeやBigQueryなど)にあるため、外部エンジンからはすでに直接アクセス可能な状態です。
Q. 外部のツールからデータを誤って書き換えてしまう心配はありませんか?
A. ご安心ください。連携先のツール(Snowflake、Databricks、BigQueryなど)には「読み取り専用」の権限しか付与されません。データを直接修正することはできず、データの書き込みや更新はすべてCDP側で行われます。
Q. AWSの利用料金は上がりますか?
A. データの保存先となるIceberg S3バケットやGlueカタログはTreasure AI側のAWSアカウントに構築されるため、データの保存にかかる料金はTreasure AIの契約に含まれています。お客様側で発生するのは、外部エンジン(Snowflakeなど)から「データを検索(クエリ)した際のコンピューティング料金」です。また、ご利用の環境によってはAWSのデータ転送料金(S3エグレス料金)が発生する場合があります。詳細なコストの見積もりについては、担当のカスタマーサクセスまでご相談ください。
Q. Iceberg側に見えるデータは、どのくらいの頻度で最新化されますか?
A. お客様が設定しているCDPのデータ処理パイプラインのスケジュールに連動します。外部からクエリを実行したタイミングで、「CDP側で公開処理が終わっている最新のデータ」を参照します。(将来的には、常に最新の状態が反映されるリアルタイムな更新への対応も予定しています)。
Q. データガバナンスや個人情報(PII)の取り扱いはどうなりますか?
A. 本機能でのアクセス制御は、行や列の細かい単位ではなく「データベース単位」で行われます。データは外部のエンジンから直接読み取られるため、連携先のSnowflakeやDatabricks側で行うデータのキャッシュやビューの作成については、お客様社内のデータ取り扱いルールに則って適切に管理・運用をお願いいたします。
Q. AtlanやCollibraのような既存のデータカタログツールと連携できますか?
A. 「Open Catalog Access」はデータにアクセスするための機能であり、メタデータを管理するカタログそのものではありません。そのため、現状ではサードパーティ製のデータカタログツールへ自動的に情報を連携する機能は持っていません。もし既存のカタログツールに登録したい場合は、他のAWSアカウントにあるIcebergデータを読み込ませるのと同様の設定が必要です。より密接なカタログ連携については、今後の開発ロードマップに組み込まれています。
Q. もしTreasure AIを解約した場合、データはどうなりますか?
A. Icebergテーブルへのアクセス権は、Treasure AIのご契約期間中のみ有効です。解約時のデータのエクスポートや引き継ぎ方法については、システム上の自動設定ではなくご契約内容に基づく対応となりますので、担当営業までご相談ください。
Q. どのリージョン(地域)で利用できますか?
A. 米国(us01)、ヨーロッパ(eu01)、日本(ap01)、韓国(ap02)の、すべてのTreasure AI環境でご利用いただけます。それぞれのリージョンごとに専用のAPIエンドポイントが用意されています。
Treasure Data, Inc.
米国本社CEO&共同創業者
学部課程在学中の2006年、人工知能(AI)開発大手のプリファード・ネットワークス(東京・千代田)の前身であるプリファード・インフラストラクチャーの最高技術責任者(CTO)に就任。 2011年に米シリコンバレーにて芳川裕誠(現取締役会⻑)、古橋貞之(現チーフアーキテクト)とともにトレジャーデータを創業。同社最高技術責任者(CTO)を経て、21年6月より現職。