Amazon Redshift zero-ETL 統合を活⽤した 軽量なマルチプロダクトデータ可視化基盤 AWS Summit Japan 2026 Tori Hara (@toricls) CTO, Kaminashi Manabu Sakai (@manabusakai) Software Engineer, Kaminashi 株式会社カミナシ 

⾃⼰紹介 経歴 ERP パッケージベンダー R&D チームにてソフトウェアエンジニアとして 設計‧開発に従事。その後クラウドを前提とした⼩さな CIer 企業での設 計‧開発‧運⽤業務を経て、2018年 Amazon Web Services ⼊社。AWS コンテナサービス群プロダクトチームでのサービス改良、および同サー ビス群を中⼼とした技術領域における顧客への技術⽀援や普及活動を リードした。 2022年4⽉ カミナシに⼊社し、2022年7⽉ 執⾏役員 CTO、2023年4⽉に 取締役 CTOに就任。 株式会社カミナシ Chief Technology Officer 原 トリ 

⾃⼰紹介 経歴 2022 年に株式会社カミナシに⼊社。「カミナシ レポート」の開発を経 て、共通認証基盤への ID 統合を推進。現在は CTO 室にて、組織スケール に向けた仕組みづくりに取り組む。 BtoB SaaS には 3 社 13 年以上の経験を持ち、プロダクト‧組織‧⼈の成 ⻑を横断的に⽀えてきた。 株式会社カミナシ Software Engineer 坂井 学 

アジェンダ 1. <第1部> なぜ Amazon Redshift zero-ETL だったか 2. <第2部> Zero-ETL 統合を活⽤したデータ基盤構築の具体 a. 全体概要 b. Zero-ETL 統合活⽤のポイント c. データ基盤公開後の社内でのデータ利活⽤ 3. まとめ 

第 1 部 なぜ Amazon Redshift zero-ETL だったか 

⾼速なマルチプロダクト化 2023年〜2025年、カミナシに起きた重要な変化 2023年 プロダクト x 1 2024年 プロダクト x 3 2025年 プロダクト x 5 

● 強いオーナーシップを可能にする、プロダクトごとの独⽴チーム ○ 単⼀のチームに Eng/PM/PD が同居 (「サービスチーム」と呼んでいます) ○ 兼務は悪 (特に、リソース不⾜をごまかす IC 兼務) ○ 独⽴したロードマップ ○ 1チームで完結できる意思決定 ⾼速かつサステナブルなマルチプロダクト化を可能にした、カミナシの原理原則 ● プロダクトごとに、独⽴したシステムを持つ ○ 共有リソースの排除 ■ 単⼀チームがアプリからインフラまでをすべて独⽴所有し、運⽤ ○ 各プロダクトは、他プロダクトを API 経由で「利⽤」 ■ 例えば、各プロダクトは認証認可プロダクトを「利⽤」する 

● 各プロダクトが個別に社内⽤のデータ可視化ソリューションを運⽤ ○ プロダクトデータを必要とする社内ステークホルダーの認知負荷 ○ アクセス管理の分散 ○ そもそも可視化ソリューションを⽤意できているチームとそうでない チームが存在 (チームそれぞれの優先順位の違い) ⾼速なマルチプロダクト化に伴って「データ領域」に⽣まれた課題 分かってはいたけれど、やっぱり不便 ● 効果的な利⽤状況分析には複数プロダクトデータの統合が必須 ○ e.g. 「社名」は「カミナシ ID管理」が持っている ○ プロダクトごとにデータを抜いてきてヨッコラショしないと... 

● 各プロダクトが個別に社内⽤のデータ可視化ソリューションを運⽤ ○ プロダクトデータを必要とする社内ステークホルダーの認知負荷 ○ アクセス管理の分散 ○ そもそも可視化ソリューションを⽤意できているチームとそうでない チームが存在 (チームそれぞれの優先順位の違い) ⾼速なマルチプロダクト化に伴って「データ領域」に⽣まれた課題 分かってはいたけれど、やっぱり不便 ● 効果的な利⽤状況分析には複数プロダクトデータの統合が必須 ○ e.g. 「社名」は「カミナシ ID管理」が持っている ○ プロダクトごとにデータを抜いてきてヨッコラショしないと... ➡ 「軽量なデータ基盤」 の検討へ 

● データ基盤の利⽤が、各プロダクトのプロダクション性能に影響を与えない (あるいは無視できるレベルの影響で収まる) ○ 分析⽤途にありがちな重いクエリを⼼配せずにみんなが眠れる ○ 分析クエリを直接プロダクトのデータベースに流さない ● ステークホルダーが、マルチプロダクトデータに安全にアクセスできる ○ 1箇所からアクセスできる ○ 柔軟なアクセスコントロールが可能である ⽬指したのは、「軽量な」データ基盤 ⽬指したゴール ● 各サービスチームとデータ基盤チームの明確な責任分界点、責任共有モデル ○ 何がサービスチームの責任で、何がデータ基盤チームの責任かを 明確にできるアーキテクチャ 

● 未来のデータ基盤⼈材にとって障壁にならないこと ○ (未来に⼊社してくれるであろう) 優秀なデータ基盤⼈材に、変な負債を渡したくない ○ 拡張可能性と、そして必要なら捨てやすくもあることが重要 ● 重厚な専任データ基盤チームなしで運⽤できること ○ 明確なデータ基盤⼈材不在のカミナシで、⾃らの⾸を締めない範囲に ○ とにかく「薄いデータ基盤」であることが重要 ⽬指したのは、「軽量な」データ基盤 制約 ● データソースとなる各プロダクトのサービスチームへの負荷を最⼩限に ○ 「データ基盤を作るので ETL 書きまくってください」を避ける 

● 全プロダクトが AWS でワークロードを動かしている ○ Amazon Aurora MySQL & Amazon Aurora PostgreSQL が中⼼ ● AWS IAM Identity Center でのアクセスコントロールの型が出来上がっている ○ GitHub + Terraform Cloud での管理 (*) ● (そして何より) 社内の多くの⼈が、セントラルなデータ環境の必要性を痛感している ○ 各プロダクトのサービスチーム ■ データ可視化環境を⾃前で維持する負担 ■ ⾃前のデータ可視化環境がなく、依頼を受けるたびにクエリを書いてデータを抜き... とい うコストやスピード感の⽋如 ○ データが必要なステークホルダーたち ■ プロダクトごとに異なるデータ可視化環境、あるいは都度依頼するオーバーヘッド ■ 各プロダクトからもらったデータを⾃分で繋ぐ⼿間 ■ そもそもデータを⼿元に持ってくる恐怖 補⾜) ゴールとは別にあったアドバンテージ カミナシ社がすでにもっていた重要なアドバンテージ (*) https://kaminashi-developer.hatenablog.jp/entry/2025/08/19/5-cool-things-about-kaminashi-eng 

机上検討で⽣き残った Amazon Redshift + zero-ETL を検証し、 選定 

ゼロ ETL 統合はフルマネージドソリューションで、複数の運⽤ソースとトランザクション ソースから Amazon Redshift でトランザクションデータと運⽤データが利⽤できます。こ のソリューションを使⽤して、ソースから Amazon Redshift データウェアハウスへの統 合を設定できます。抽出、変換、ロード (ETL) パイプラインを管理する必要はありませ ん。データソースから Amazon Redshift クラスターまたは Redshift Serverless 名前空間 にデータレプリケーションの作成と管理を⾃動化することにより、お客様に代わって ETL が処理されます。レポートやダッシュボードなどの分析ワークロードには Amazon Redshift を使⽤して、ソースデータの更新とクエリを継続できます。 ちなみに、そもそも Amazon Redshift zero-ETL 統合とは https://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/zero-etl-using.html 

第 2 部 Zero-ETL 統合を活⽤したデータ基盤 

第 1 部の振り返り ● カミナシはマルチプロダクト化を進めており、現在 5 つのプロダクトが存在する ● RDB は Aurora MySQL と Aurora PostgreSQL を使っている ● サービスチームごとにデータ可視化の⼿段が異なっていた 「サービスチームによるオーナーシップと、データエンジニアリングによる基盤提供」 という責任共有モデルを⽬指している。 

Zero-ETL 統合を活⽤したデータ集約の全体像 Amazon Aurora zero-ETL 統合 AWS Organizations のプロダクトごとの AWS アカウン トからデータ基盤の Amazon Redshift へデータ集約。 ETL パイプラインを必要とせず、数ステップでセット アップが完了 Provisioned クラスターの採⽤ ニアリアルタイム性を実現するため、Serverless では なく Provisioned を採⽤ Amazon Athena による Federated Query Amazon Athena を SQL インターフェースとし、複数 データベースに対してクエリ実⾏が可能 

Zero-ETL 統合のメリット  セットアップ その名の通り ETL パイプライン のプロビジョニングを必要とせ ず、数ステップでセットアップが 完了する。 クロスアカウントであってもセッ トアップ⼿順はほぼ変わらない。  ニアリアルタイム ソースデータベースの更新から数 ⼗秒以内にターゲットデータベー スに変更が反映される。 これによりタイムリーな分析が可 能となる。  運⽤ 初回のセットアップが完了すれ ば、CDC による継続的なレプリ ケーションが⾏われる。 新しいテーブルの追加やスキーマ 変更にも⾃動的に追従する。 新たに運⽤すべきものを増やさず に済む。 

Zero-ETL 統合を活⽤していくうえでのポイント Zero-ETL 統合を使っていく中で、次の観点で何を考え、課題に対してどう向き合ってきたのかをご紹 介します。 1 制約と トレードオフ 2 機密データの 取り扱いと統制 

① 制約とトレードオフ 

⼀部のデータ型が使えないという制約 Zero-ETL 統合は⼀部のデータ型をサポートしていない。 「ソース DB クラスターのテーブルにサポートされていないデータ型が含まれている場合、 そのテー ブルは同期されず 、送信先ターゲットで使用できなくなります。ソースからターゲットへのストリー ミングは継続されますが、 サポートされていないデータ型のテーブルは使用できません 。」 CREATE TYPE bug_status AS ENUM ( 'new', 'open', 'closed' ); CREATE TABLE bug ( id serial, description text, status bug_status ); PostgreSQL だと `CREATE TYPE` で定義したカス タムデータ型が該当する。 カミナシでは、データの整合性保証や可読性の向 上のために利⽤しているチームが複数あった。 

制約とトレードオフ ● ⼀部のプロダクトではカスタムデータ型を利⽤していたため、Zero-ETL 統合で該当のテーブルは同 期されなかった ○ 同期するには、テーブルのスキーマ変更を⾏う必要がある ○ ⼀⽅で、スキーマ設計が外部の仕様に影響されるのは避けたい気持ちもある ● 最終的には、カスタムデータ型を標準的なデータ型で置き換えた 今の組織フェーズにおいては⾃前で ETL パイプラインを構築するよりも、 Zero-ETL 統合の制約を受け⼊れたほうが良いと各サービスチームと合意した。 ALTER TABLE bug ALTER COLUMN status TYPE varchar USING status::text; DROP TYPE bug_status; 

② 機密データの取り扱いと統制 

機密データに対する初期⽅針「持ち込まない」 Zero-ETL 統合のデータフィルタリング機能を使うと、同期されるデータを制御できます。 カミナシでは、機密データを Amazon Redshift に持ち込まない⽅針からスタート。運⽤していく中で次 のようなメリット‧デメリットが⾒えてきました。 メリット ● Amazon Redshift に同期するデータを include / exclude で簡単に設定できる（簡易的な ETL とし て機能する） ● Zero-ETL 統合のソース側データベースで設定す るため、サービスチーム側にオーナーシップを 持ってもらえる デメリット ● データフィルタリングはテーブル単位の制御しか できず、PII が含まれるカラムのみ除外といった 細かいアクセス制御ができない ● Terraform で管理していると、データフィルタリ ングの対象テーブルを変更するたびに Zero-ETL 統合が再作成になってしまう 

⽅針転換して「持ち込んだ上で守る」へ データフィルタリング機能の利⽤をやめ、すべてのテーブルを Amazon Redshift に同期する形に切り替え。 機密データも含めて集約することで、新たなセキュリティリスクが⽣じたり、情報漏洩の危険性が増えてしまうこ とを防ぐために、次の三段構えの守り⽅に再設計した。 1. 監査ログ Amazon Redshift の標準機能で、 接続ログ、ユーザーログ、ユー ザーアクティビティログを記録。 Amazon CloudWatch Logs や Amazon S3 に出⼒してくれる。 2. RBAC きめ細かなアクセス制御を実現。 RBAC はコード管理し、GitHub の Pull request を起点に⾃動的に適⽤ される仕組みを構築（次ページ以 降で解説） 3. 実⾏クエリ通知 RBAC が効かないスーパーユーザー によるクエリ実⾏をニアリアルタ イムで検知し、実⾏クエリを Slack へ通知（次ページ以降で解説） 

RBAC によるきめ細かいアクセス制御とコード管理 ● 機密データが含まれるデータベースは RBAC (Role-based access control) できめ細かく制御 ○ 共通 ID 管理基盤のデータベースはホワイトリスト形式で SELECT 権限を付与 ○ 列レベルセキュリティで特定のカラムだけに SELECT 権限を付与 ● アドホックなクエリ実⾏では属⼈的になってしまうため、すべての RBAC (SQL) をコード化し、Git 管理されたコードを Single Source of Truth にした。 Pull request のマージをトリガーにマイグ レーションまでを⾃動化 データエンジニアリングへの依頼という形ではなく、 各サービスチームがデータのオーナーシップを持てる体制を実現。 

スーパーユーザーの実⾏クエリ通知 スーパーユーザーには RBAC が効かないため、機密データを含むテーブルにもクエリを実⾏できる。 統制を取るためにスーパーユーザーの実⾏クエリをバッチ処理で Slack に通知するようにした。 仕組み 1. Amazon EventBridge で起動した AWS Lambda が Amazon Redshift の STL/SYS テーブルを 10 分おきに監視 2. 前回のトランザクション ID を Amazon DynamoDB に保存 し、差分レコードのみを取得 3. 内部で実⾏されるクエリをフィルタリングで除外 4. 新しいレコードがあれば Slack App の Webhook 経由でメッ セージ投稿 

データ基盤公開後の 社内でのデータ利活⽤ 

データ可視化ツールの必要性 Amazon Redshift へのデータ統合はひと通り完了したものの、データを参照する⼿段がクエリ実⾏に限 られていた。また、Amazon Athena へのアクセス権はエンジニアだけに付与しており、サービス運⽤に 関わるほかの職種のメンバーが⾃⽴的にデータを参照し、⽇々の意思決定やサービス改善に活⽤するこ とが難しい状態にあった。 この状況を解消し、次のような状態に⽬指したかった。 ● エンジニアに依頼せずとも、ほかの職種のメンバーが⾃⽴的にデータを参照できる ● データに対するオーナーシップを各サービスチームが持てる 

安易にファットな BI ツールを採⽤しない データを可視化‧分析しようとすると、世の中で有名な「あんな BI ツール」や「こんな BI ツール」を 導⼊したくなる。しかし... ● 変化が⼤きいスタートアップにおいて、“鮮度の⾼い”データセットを維持し続けられるか ○ ビジネス環境の変化に対応できず、更新されないデータセットが残り続けるリスク ○ データセットそのものが暗黙知になってしまうリスク ● 既存の BI ツールにサービスチームがオーナーシップを持てるような仕組みを組み込めるか ○ ソフトウェア開発のベストプラクティスをデータ領域にも反映できるか いきなりデータ分析を⽬的にするのではなく、まずは 「社内でプロダクトデータを必要とするメンバーからのエンジニアへの依存を薄くする」 ことを⽬指した。 

marimo で MVP の仮説検証 課題解決のため marimo (https://marimo.io/) で MVP を作り仮説検証することにした。 marimo を選んだ理由 ● 次世代の Python ノートブック ● 再現可能な Python コードとして保存できるた め⾃由度が⾼い ● ローカル開発環境での検証が容易 ● ノートブックを Git 管理して、GitHub を中⼼ に業務フローを回せる ● 社内ですでに使っているエンジニアがいた ○ Jupyter Notebook の経験を持つ⼈にとっては親 和性が⾼く、より良い代替案になる 

marimo を⽤いた社内データ可視化基盤 認証⽅式 Application Load Balancer でAmazon Cognito ユー ザープールを使⽤し、Google Workspace を IdP とし た SAML 認証で SSO させる。 社内向けであることを前提とし、ユーザー管理を既存 基盤に委ねる。 バックエンド read-only モードで起動した marimo を Amazon Elastic Container Service で実⾏。データ参照に限定 することで、状態変更や副作⽤を回避する。 

まとめ 

すべてはトレードオフ 薄く作る — ETL やパイプラインを持つことにこだわりすぎない ● これらは、作った瞬間から運⽤が発⽣する ● これらは、データソース側の進化やデータ基盤側の都合に常に影響を受ける ● 明⽰的な ETL やパイプラインがなくとも「MVP で実現したいデータ基盤」の要件を満たせるなら、 Zero-ETL は間違いなく選択肢の⼀つに⼊る 責任共有モデル — サービスチーム(プロダクトの開発‧運⽤チーム)とデータエンジニアリングチームで良 い責任共有モデルを定義し、維持することにこだわりぬく ● 適切な責任分界点を探し当てることを諦めない ● データ基盤チームがすべてを抱え込むと、「軽量な基盤」はすぐに「重い基盤」になる ● サービスチームがオーナーシップを持てる設計と⽂化こそが持続可能性の源泉