[市場動向]

2026年9月14日(月)日川 佳三（IT Leaders編集部）

シェアする

リスト

　三井住友カードは、クレジットカードの決済ビジネスを中心に手がける。同社は現在、オンプレミスのデータ基盤を、クラウド型のデータ基盤であるSnowflakeへと移行している。マーケティング本部だけでも約500の業務があり、これを一つずつ移行している最中である。

　オンプレミスのデータ基盤は、基幹系など全データを1カ所に集約する集中管理型の構成である。これに対してクラウド側は、Vクーポン、Vポイント、マーチャントポータルといったサービスごとにアカウントを分けてデータを分散管理している。

写真1：三井住友カード マーケティング本部 AI・データ戦略トライブ シニアデータマネージャーの小林史和氏
拡大画像表示

　同社マーケティング本部 AI・データ戦略トライブ シニアデータマネージャーの小林史和氏（写真1）は、クラウドへのデータの移行を難しくしている原因を、「まだ大半の業務がオンプレミス側で動いている」と説明する。

　これに対して同社は、業務のクラウド側への移行を進めるとともに、機密情報の安全管理にも取り組んでいる。機密情報は現状、オンプレミス側でマスキングしたデータをクラウドに持っていっている。今後は、クラウド側でも、クエリー実行時に参照者の権限に応じて値を自動的に伏せ字化するダイナミックマスキング機能や、機密情報を検出して保護するDLP（データ漏洩防止）機能などを使う。

　小林氏は、こうした移行を後押しする材料として、「オンプレミス基盤のワークロードをベースに試算したところ、Snowflakeでの実行コストはオンプレミス比で5分の1程度になる」と説明する。この試算を一つの拠り所に、移行を進めている。

　社内に散在するデータの資産化にも取り組んでいる。小林氏は「エンジニアやアナリストが日常的に使っているデータは、日常使いであるがゆえに価値を感じにくいが、確実に価値がある」と指摘する。まず、Snowflake上のデータウェアハウス（DWH）をデータカタログ製品「COMETA」（primeNumberが提供）でカタログ化する。また、データマートのうち複数部門をまたがって使えるものを「データプロダクト」として認定し、マーケットプレース機能を使って社内向けに公開、データプロダクトオーナー（DPO）も任命する。

　メタデータのAI活用にも取り組んでいる。大きく、SQLの自動生成による効率化、データカタログを使った分析プロセスのオープン化、BIをコードで管理するコンポーザブル化に取り組んでいる。

　オンプレミス基盤のテーブル構成などのメタデータをドキュメントとして整備し、Gemini Notebookに読み込ませることで、利用者が自然言語で「欲しいデータ」を伝えるだけでSQL文を自動生成できるようにした。

　データ分析を民主化する取り組みでは、アナリストが持つノウハウを「用語集」と「クエリー集」という形でデータカタログ「COMETA」に蓄積し、誰でも参照できるようにした。データの抽出や分析にAIを活用することで、経験の浅い担当者でも一定水準の分析ができるようになる。

　業務ロジックやデータの定義を、ダッシュボードのGUI操作ではなくコードとして管理する「BI as Code」にも取り組んでいる。データパイプラインをコード化し、これを読み込むBI製品の試行運用を始めている。

dbt中心の設計で、数字のブレとAIの誤りを同時に防ぐ

写真2：三井住友カード マーケティング本部 AI・データチャプター シニアマネージャーの折島晋司氏
拡大画像表示

　講演の後半では、マーケティング本部 AI・データチャプター シニアマネージャーの折島晋司氏（写真2）が登壇し、メタデータ管理を支えるデータ基盤の設計思想を説明した。三井住友カードは社内にエンジニア文化がない状態から社員を育成し、現在は社員とベンダーが一体となったチームでデータ基盤を内製している。

　データ基盤の中核を担うのが、データベースに溜まった生データを、分析しやすい形に加工する処理に特化した「dbt」というツールである。

　設計の核となる考え方はシンプルである。売上やアクティブユーザー数といった指標の計算方法も、テーブルの加工処理と同様にdbtのコードで定義しておく。これをSnowflakeとLightdash（ダッシュボードを表示するツール）が参照するという一方向の流れを作っている。

　ダッシュボードツールのLightdashは、dbt側で定義した内容をそのまま読み込む以外の使い方ができない。折島氏は「Lightdashが単独では機能せず、dbtの定義をそのまま読み込む以外の使い方ができないという制約こそ、メタデータを緊密に管理できる利点になっている」と指摘する。ダッシュボード側が独自に集計ロジックを持ててしまうと、作成者によって売上やアクティブユーザー数の数え方がずれ、「部署によって数字が合わない」といった事態が起こる。dbt側だけにロジックを一元化すれば、この食い違いは起こらない。

　ロジックの一元化はAIにも有効である。LLMが自律的にデータを参照して回答を生成する場合でも、同じdbtの定義を参照させることで、事実と異なる回答（ハルシネーション）を防ぎ、社内の定義に沿った正確な回答を導けると折島氏は指摘する。

　三井住友カードは今後の展開として、LLMによるメタデータの自動生成や、人間を介さずAIがデータ資産を自律的に生み出す仕組みまでを見据える。折島氏はさらに、その先の課題としてオントロジー（知識を関係性として体系化する仕組み）への対応を挙げる。折島氏は「オントロジーは、高度なAIエージェントには不可欠になっていく」と説明する。

　例えば、「ユーザーはメールアドレスを持ち、ユーザーIDとして利用できる」といった業務上の知識を、AIが正しく参照できる状態にする取り組みである。AIにシステム構築などを任せる場面では、こうした知識にアクセスできるかどうかで成果物の精度が大きく変わる。

　ただし、全社のオントロジーを一気に整備するには、相応のコストがかかる。そこで三井住友カードは、まずは今取り組んでいるdbtでの意味付けを徹底する。このうえで、より精度の高い分析が求められる特定の領域が出てきた段階でオントロジーの導入に着手する。