「御社のプロダクトの中で、自分たちの数字を見られるようにしてほしい」— ある程度のフェーズに入った SaaS では、ジャンルを問わず繰り返し発生する要望です。営業ツール、マーケティングツール、HR テック、勤怠管理、店舗管理、業務系 SaaS — どのプロダクトでも、顧客に対して顧客自身の数字を見せる必要が、ある段階で出てきます。

最初は CSV エクスポートで凌ぎ、次に PDF レポートが要望され、やがて画面内のダッシュボードを期待される、という段階的な拡張になりがちです。本業のロードマップの隣にダッシュボード機能のタスクが残り続けると、限られたエンジニアリングリソースが分析機能側に流れ続ける構図になります。

この記事は、自社プロダクトに分析機能を提供する方法を整理するためのものです。選択肢は大きく 3 種類あり、それぞれが向く場面が異なります。3 つ目の選択肢である埋め込み型（Codatum の Signed Embed）について、業界横断のシナリオを 15 個並べて整理します。

内製と外部 BI の限界

内製でフルスクラッチを選ぶ場合、Recharts や D3 などのチャートライブラリで開発を始めるケースが多くなります。集計・フィルター・ピボット・エクスポートなどの要望は段階的に追加されるため、開発期間は当初の見積もりを超えやすい性質があります。本業のロードマップが進まないというトレードオフが、ここで発生します。

外部 BI の埋め込みリンクで対応する場合、Looker Studio や Metabase の埋め込み URL を画面の隅に置くやり方になります。実装は数日で終わりますが、別タブで開かれた瞬間に顧客側の認識が「別のサービス」に切り替わってしまいます。フォント・配色・認証の分離、SQL エディタの可視化などが原因で、自社プロダクトのブランド体験から切り離されます。

この二つの選択肢のトレードオフを避けようとして、検討が止まったままになるケースもよく見ます。

第三の選択肢 — 埋め込み型

埋め込み型は、自社プロダクトの中に分析機能を iframe として組み込む方式です。Codatum の Signed Embed がこれに該当します。

3 方式を「何を自社が持ち、何を任せるか」の軸で並べると、それぞれの違いが分かりやすくなります。

埋め込み型では、ホストアプリ側からは「分析パネルが組み込まれている」状態に見え、Codatum 側は SQL を BigQuery / Snowflake / Redshift などに投げて結果を返す役割を担います。顧客アカウントを Codatum 側で発行する必要もなく、ユーザー管理は自社のまま完結します。

「分析機能」と一言で言っても、内製で抱え込む場合に発生する判断点は広範囲に渡ります。

• 可視化 — 10 種類以上のチャート、軸 / 凡例 / 色配分、ツールチップ、ドリルダウン

• 操作 — ソート / 検索、フィルタ条件指定、ピボット集計、クロスフィルタ

• データ接続と集計 — DWH 接続（BigQuery / Snowflake / Redshift）、大量データのスクロール、キャッシュ / TTL 制御、集計関数（SUM / AVG / COUNT）

• テナント分離と権限 — テナント間データ分離、認証セッションとの連携、テナント別設定、監査ログ

• UX と国際化 — レスポンシブ、ダーク / ライト切替、ロケール（i18n）、通貨 / 日付フォーマット

• 配信と公開管理 — CSV / PDF エクスポート、URL 共有 / パーマリンク、バージョン管理、SOC 2 / コンプラ対応

埋め込み型を選ぶと、この 6 領域分の判断点が一塊で Codatum に任される構図になります。自社で必要なのは「何を見せるか」を SQL とチャート定義で決めるところまでで、その下のレイヤー（チャート種類の追加、ダーク / ライト切替、エクスポート、監査ログなど）は Codatum 側で完結します。

シナリオ・ギャラリー — 15 の業界横断パターン

B2B SaaS — 顧客に "自社の数字" を返す

1. 顧客向け活動量レポート（営業・マーケティング・HR テック）

営業ツールを使う採用企業が、自社チームの送付数 / 返信率 / 承諾率を画面内で確認するケースです。SaaS の利用フィーが価値に見合うかを顧客自身が判断するための画面として置かれ、月次サマリと KPI タイルの組み合わせが基本構成になります。

2. アカウント別 health ダッシュボード

顧客企業の管理者が、自社アカウントの利用状況や効果を確認するケースです。誰がアクティブで、機能ごとの利用率はどうか、というデータを見ます。CS が顧客と一緒に閲覧しながら使い込みの提案を行う場面でも使われます。

3. API 利用状況の透明化

API を提供している SaaS で、顧客が自分の API コール数 / レート / エラー率 / レイテンシを確認するケースです。エラーの原因切り分けが顧客側で完結することで、サポート工数が減る効果があります。

4. リセラー / OEM パートナー向けの再販実績

自社製品を再販するパートナー会社が、自分の販売実績を確認するケースです。OEM ブランド色（パートナーのロゴ・カラー）に着替えて出すケースも多く、テナント分離とテーマ切り替えの両方が要件になります。

B2C — 個人ユーザーに "自分のデータ" を返す

5. 家計簿 / 個人ファイナンス

家計管理アプリで、ユーザーが自分の収支推移を確認するケースです。総収入・総支出・カテゴリーランキング・収支推移の組み合わせで構成され、BI 用語（メジャー / ディメンション）を表に出さず、エンドユーザーが直感で読める表現にする必要があります。

6. フィットネス・学習進捗の可視化

トレーニングアプリ、語学アプリ、資格学習アプリで、ユーザーが自分の活動量や進捗を確認するケースです。週ごとの推移グラフと、自然文サマリ（前週比 / 目標達成までの残り）の組み合わせで構成することが多くなります。

7. 投資・運用ポートフォリオ

証券アプリ、暗号資産取引所、家計管理アプリで、保有銘柄・評価額・配当履歴・税金計算をまとめて表示するケースです。複数口座を横断する集計、複数通貨の換算、損益通算といった要件が出てきます。

Enterprise / 社内ポータル系

8. 情シスのセキュリティ・ライセンスダッシュボード

社内 IT 管理者が、SSO 利用率 / MFA 設定率 / ライセンス利用 / リソース配分を確認するケースです。部署別・役職別の利用率も併せて見ることが多く、社内ポータルの一画面として組み込まれます。

9. HR 分析

人事担当者が、部署別 / 役職別の在籍状況・離職傾向・研修受講率・人事評価分布を確認するケースです。センシティブな情報を扱うため、誰が何を見られるかの権限分離が要件として強くなります。

10. コンプライアンス監査ログ

「誰が、いつ、何にアクセスしたか」を時系列で集計し、SOC 2 / ISO 27001 の監査エビデンスとして提示するケースです。コンプラ担当者・監査人向けに、必要な集計だけを切り出して見せる形になります。

Vertical / niche 系

11. チェーン店本部の店舗別売上比較

小売チェーンの本部が、店舗 × 商品カテゴリ × 時期の売上を比較するケースです。店長は自分の店舗、エリアマネージャーは担当エリア、本部は全店舗、という階層的なテナント分離が要件になります。

12. 医療 SaaS の患者向けレポート

処方履歴・検査結果・リハビリ進捗を、患者本人が確認するケースです。HIPAA / 医療情報ガイドラインの規制対応が前提になり、データの分離・暗号化・監査ログが必須要件になります。

13. 教育 SaaS の保護者向け学習進捗

学習塾・通信教育・公教育系のアプリで、保護者が自分の子どもの学習進捗（科目別の理解度、課題の進行、テスト結果）を確認するケースです。子どもごとのデータ分離が要件になります。

14. 不動産 SaaS のオーナー向け運用レポート

賃貸管理 SaaS で、物件オーナーが家賃収入 / 空室率 / 修繕履歴 / 収支見込みを確認するケースです。所有物件ごと・年次・月次の集計切り替えが要件になります。

15. 製造業 IoT の現場ダッシュボード

工場のライン管理者が、機械別の稼働率 / 異常検知 / 生産量を現場で確認するケースです。リアルタイム性と、現場での視認性（色だけで状態が判別できる表現）が要件になります。

15 シナリオの構造

業種は違っても、共通する 4 つの軸で整理できます。

軸	例
誰が見るか	顧客企業 / 個人ユーザー / 社内担当者 / 規制対応者
誰のデータか	自社の / 顧客企業の / 個人本人の / 担当部署の
何の数字か	活動量 / 利用状況 / 進捗 / 経営指標
どこで分離するか	顧客企業ごと / 個人ユーザーごと / 部署ごと

共通する要件は「自社プロダクトの中で、対象者にとって意味のあるデータだけが見える」という設計の部分にあります。

テナント分離は構造で担保される

15 のシナリオの大半に共通する要件が、テナント分離です。Signed Embed では、サーバー側で「この顧客の ID は固定値」と宣言したパラメータが署名付きトークンに焼き込まれます。フロント側からは上書きできない状態になるため、フロント JS の改変による他社データへのアクセスは原理的に発生しません。

採用判断の目安

埋め込み型が向く条件:

• 顧客（または社内ユーザー）に分析機能を提供する想定がある

• DWH（BigQuery / Snowflake / Redshift / Databricks など）に分析データが集まっている、または集める計画がある

• 自社プロダクトのブランド・認証は分離させない方針がある

• レポートの種類・要望が継続的に追加される見込みがある

向かない条件:

• 一度作れば数年いじらない、定型 1 種類のシンプルなグラフで足りる

• データ量が小さく、アプリ DB の集計で完結する（DWH を持たない）

• 数十人の社内利用に閉じていて、顧客には見せない

主機能のダッシュボードは内製、追加レポート系は埋め込み、というハイブリッド構成の事例も多くあります。

次の一歩

PoC 規模であれば、エンジニア 1 名で週末に動作確認ができ、本番組み込みは数週間程度が目安になります。Vue / React の公式ラッパーが用意されているため、既存のフロントスタックへの統合工数は限定的です。

15 シナリオに似たケースの実装相談、マルチテナント運用設計の相談、PoC のサンプル構成の提供については、選定相談の窓口で対応しています。