Analytics API
ほとんどの分析統合は同じように始まります。プロダクトチームはアプリケーション内にデータを必要としています。誰かがiFrameを使ってダッシュボードを埋め込みます。発送できます。それはほとんどうまくいく。ユーザーは製品から離れることなくチャートを確認できます。
そして最初のカスタマイズ依頼が入ってきます。顧客はダッシュボードが自分のブランドに完全に合致することを望んでいます。もう一つは、ユーザーが現在アプリケーションで何をしているかに反応するフィルターが必要です。誰かが、ユーザーがレポートを操作する代わりに自然言語で質問できるかどうかを尋ねています。そしてエンジニアリングチームは、iFrameが基盤ではなく回避策であることに気づき始めます。
分析APIは、適切に構築された組み込み分析体験の下にあるものです。これにより、分析機能が製品のネイティブな一部のように機能し、アプリケーションのコンテキストに対応し、ユーザーの権限を尊重し、AI生成の洞察を提供し、数千のテナントにスケールしながらメンテナンスの負担にならずに対応できるのです。
このガイドでは、分析APIとは何か、どのように機能し、それらを利用せずに構築したときに何が変わるかを説明します。
アナリティクスAPIとは何ですか?
アナリティクスAPIとは、アプリケーションが分析機能にアクセスし、組み込み、プログラム的に操作できるようにするエンドポイントとプロトコルのセットです。外部ダッシュボードツールに誘導する代わりに、API呼び出しを行い、データ取得、可視化の読み込み、フィルターの適用、インサイトを返すなど、すべて製品インターフェース内で行われます。
分析APIは分析をユーザーが移動する目的地ではなく、アプリケーションが呼び出す関数にします。
製品およびエンジニアリングチームにとって、この変化は具体的な意味を持ちます。APIを通る分析は、ユーザーの操作によってトリガーされ、特定のコンテキストに限定され、現在のユーザーの権限でフィルタリングされ、AIシステムと連携できます。これらはすべて、ユーザーが製品を使い続ける以外に何もする必要はなく、
従来の組み込みダッシュボードとの対比は外観ではなく建築的な側面にあります。iFrameは外部ツールのUIを製品内に読み込みます。分析APIは分析をアプリケーションのロジックに統合します。つまり、インターフェースやデータアクセスモデル、挙動をあなたがコントロールするのであって、分析ベンダーではありません。
Analytics APIの仕組み
分析APIはアプリケーションからのリクエストを受け取り、分析エンジンで処理し、構造化された結果を返します。リクエストは「このユーザーに対してこの指標を教えてください」といった単純なものから、「このデータセットに対してこのクエリを実行し、これらのフィルターを適用し、結果をチャートコンポーネントとして返す」といった複雑なものまであります。
リクエストフロー
機能レベルでは、すべての分析APIのやり取りは同じパターンに従います。
- アプリケーションはクエリ、ダッシュボードのロード命令、フィルターパラメータ、自然言語の質問など、リクエストを送信します
- APIはリクエストを処理し、ユーザーの認証、データアクセスルールの強制、クエリの実行を行います
- 分析エンジンは、接続されたデータベース、倉庫、APIからデータを取得します
- その結果は構造化データ、レンダリングされたコンポーネント、またはAI生成の洞察としてアプリケーションに戻されます
- アプリケーションは出力をレンダリングします — 自社のUIコンポーネントや分析SDKを使って

静的ダッシュボードの埋め込みと異なるのは、すべてのステップがアプリケーションのコンテキストによって制御される点です。ユーザーのアイデンティティ、役割、テナント、現在のワークフローの状態など、すべてがAPIを通じて渡され、返される内容を形作ります。分析は製品と一緒に提供されるだけでなく、製品に反応するようになります。
コアAPI機能
- データクエリエンドポイント — メトリクスや次元に基づいて生データまたは集約データを取得
- ダッシュボードと可視化エンドポイント — アプリケーション内で動的にチャートを読み込みまたは生成
- フィルタリングとドリルダウン — ユーザーのコンテキスト、パラメータ、インタラクションをプログラム的に適用する
- 認証とアクセス制御 — データが返却される前に権限を強制する
- リアルタイムかつキャッシュされたデータ処理 — ライブクエリやパフォーマンス最適化された応答をサポートします
- AIと会話型エンドポイント — 自然言語をクエリに翻訳し、構造化された洞察を返す
Analytics APIと従来のBIツールの比較
従来のBIツールは、データチームやアナリストがダッシュボードやレポートを通じてデータを探索するために設計されています。分析APIは、そのモデルをアプリケーション内で組み込み分析が実行されるものへとシフトし、別個の目的地としてではなく、製品体験の一部として要求・処理・提供されます。
実際のギャップは、プロダクトチームが従来のBIが設計されていなかったことをしようとする場合に現れます。リアルタイムのユーザーコンテキストへの対応、クエリレベルでのテナントレベルのデータ隔離の強制、AIシステムとの統合、あるいはプロダクトチームのエンジニアが作ったかのような見た目と動作をする体験を構築することです。
| 伝統的なBI | Analytics API | なぜ重要なのか | |
|---|---|---|---|
| アクセスモデル | 外部ダッシュボード | アプリ内埋め込み | ユーザーはデータを探すために製品を離れることはありません |
| 相互作用 | 手動探検 | プログラムアクセス | 分析はユーザーだけでなくワークフローによってもトリガーされます |
| UIコントロール | 固定された、ツール定義 | 完全にカスタマイズ可能です | 製品の設計システムに完全に一致しています |
| 統合 | iFrameまたはボルトオン | ネイティブSDK + API | カスタマイズやインタラクションの深みに上限はありません |
| データ配信 | 事前構築されたレポート | オンデマンドクエリ | 現在のユーザーコンテキストに基づくリアルタイム結果 |
| 自動化 | 狹 | API駆動 | アラート、トリガー、AI駆動アクションのパワー |
その表で最も重要な行は最後の行です。従来のBIツールはAIの利用を想定して設計されておらず、人間のアナリスト向けに設計されていました。一方、分析APIはプログラムアクセス向けに構成されており、AIシステムがクエリし、結果を解釈し、分析体験の他の部分を支える同じ層を通じて洞察を生成できます。これが会話型分析を可能にするアーキテクチャです。
分析APIの種類
分析APIは単一のインターフェースではありません。完全な分析層には、データ取得から可視化、AIとのやり取りまで、体験の特定の部分を扱う複数のAPIタイプが含まれます。プラットフォームの評価や独自の分析アーキテクチャ設計において、どのタイプが重要かを理解することが重要です。

1. データクエリAPI
データクエリAPIは、定義された指標や次元に基づいて生データまたは集計データを取得します。それが基盤であり、他のすべての分析APIタイプは最終的にデータクエリAPIに依存して必要なものを得ています。
- バックエンドの分析ロジックとデータセット間のカスタムクエリを推進します
- プログラム的に集約、グルーピング、フィルター、ソートを適用してください
- 可視化やAIレイヤーが消費できる構造化データを返します
いつ使うべきか:アプリケーションがチャート、表、ダッシュボード、AI生成の要約、自動レポートパイプラインなど、あらゆる目的でデータを取得する必要があるときに。
2. 可視化API
可視化APIは、アプリケーション内でデータの提示方法を制御します。APIの応答やアプリケーションの設定に基づいてチャート、ダッシュボード、ビジュアルコンポーネントをレンダリングします。
- データクエリ結果から動的にチャートやダッシュボードを生成する
- レイアウト、フォーマット、表示ロジックをアプリケーションコードで制御します
- 設計システムのフロントエンドコンポーネントにデータ出力を接続します
いつ使うべきか:分析レンダリング層をアプリケーションのロジック(ユーザーロール、現在のコンテキスト、テナント設定)で駆動したい場合で、ダッシュボードテンプレートにハードコードされるのではなく。
3.組み込み型分析ツールAPI
組み込み型分析APIは、データ検索や可視化だけでなく、製品内の分析層全体を含む完全な分析体験を提供します。データアクセス、レンダリング、ホワイトラベル制御、マルチテナンシー、セキュリティを統合したインターフェースです。
- 完全にブランド化された製品内分析体験をパワーアップ
- クエリレベルでのマルチテナントデータ分離の強制
- 色、フォント、UIの挙動を横断したホワイトラベル展開のサポート
- データアクセス、ビジネスルール、プレゼンテーション間のロジックを一貫性維持する
いつ使うべきか:分析がコアプロダクト機能であり、自分のチームが作ったかのように見え、動作する必要がある場合。
4. 会話型分析API
会話型分析APIこそがアーキテクチャが本当に新しい部分です。自然言語の入力を構造化クエリに変換し、それらのクエリをあなたのデータに対して実行し、結果をテキスト、指標、またはビジュアル出力として返すため、ユーザーはナビゲーションではなく会話を通じて分析とやり取りできます。
- 自然言語の質問をデータクエリに変換する
- KPIの要約、文脈的な説明、ビジュアルアウトプットを返します
- フォローアップ質問と反復分析のサポート
- 製品内でチャットベースの分析体験を有効にしましょう
この点については次のセクションで詳しく説明します。なぜなら、会話型APIのガバナンスやコスト管理の側面はしばしば見落とされがちであり、本番環境での展開において非常に重要だからです。
会話型分析APIとは何か、そしてガバナンスとは実際に何を意味するのか?
会話型分析APIは、ユーザーやAIシステムが自然言語を通じてデータとやり取りできるようにします。ユーザーが質問をします。APIはそれを構造化クエリに変換します。クエリはあなたのデータインフラストラクチャに対して実行されます。その結果はテキスト、チャート、要約、または推奨として製品内で戻ってきて、ダッシュボードのナビゲーションは不要です。
変化は、分析がナビゲーションではなく会話を通じてアクセス可能になることです。ユーザーはどのダッシュボードを見ればいいかを知る必要はありません。彼らは知りたいことを尋ねます。
基本的な流れはシンプルです。しかし、より単純でない点は、会話型分析の多くの説明が省略している点ですが、マルチテナントのSaaS製品で安全に動作するためには何が真実でなければならないのかということです。
多くのベンダーが対処しないガバナンスの問題
AIがユーザーが制御できない自然言語入力に基づいて動的にクエリを生成すると、静的ダッシュボードにはなかった3つのリスクが浮かび上がります。
- テナント間でのデータ漏洩。AIレイヤーがクエリを実行する前にユーザーのテナントコンテキストにスコープ化されていなければ、会社Aのユーザーが会社Bに属するデータを受け取る可能性があります。これは仮定ではなく、本番環境のAI導入で実際に起こった失敗モードです。
- 制御されていないトークンコスト。LLM搭載の会話型分析は、トークン使用が管理されなければ、かなりの予測不可能なAPIコストを生み出します。複雑で多段階の質問をするユーザーは、標準的なダッシュボード負荷よりも桁違いに多くのLLM呼び出しを生成します。コントロールがないと、これはサプライズ請求書として表示されます。
- データガバナンスの方針と矛盾する回答。あなたのセマンティックレイヤーの外で動作するAIモデルは、技術的には整合性があるが事実に反する回答を生成することがあります。例えば、存在しない指標を要約したり、組み合わせるべきでない次元を組み合わせたり、製品のキーワード定義と矛盾する結果を提示したりします。
本番環境に対応した会話型分析APIは、これら3つすべてに対応します。
- テナントスコーピングは執行前に行われ、実行後ではありません。AIレイヤーによって生成されるすべてのクエリは、ユーザーのテナントコンテキストを非任意のパラメータとして保持します。
- トークンの使用は管理され予測可能です。コスト露出はプラットフォームレベルで制限されており、ユーザーの行動によって変動することはありません。
- AIはセマンティックレイヤー内で動作します。メトリクスの定義、承認された寸法、ガバナンスルールはAIがクエリできるものに組み込まれており、自然言語入力によって迂回されることはありません。
会話型分析デモと会話型分析の導入の違いは、これらのコントロールが存在するかどうかにあります。既存の分析層にAIを組み込むプラットフォームは、通常ガバナンスを後回しに扱います。APIファーストで構築されたプラットフォームは、AIが同じガバナンスされたデータ層の一つの消費者であり、構造的にガバナンスを処理します。
分析APIアーキテクチャの主要構成要素
分析APIは単独で動作するわけではありません。各コンポーネントが特定の責任を担う層状アーキテクチャの上に位置しています。プラットフォームを評価する際にレイヤーを理解することは重要です。なぜなら、どのレイヤーにギャップがあると本番環境で問題になるからです。

APIレイヤー
APIレイヤーは、アプリケーションが呼び出すクエリ、ダッシュボード、フィルター、AIインタラクションのエンドポイントを公開します。それはあなたの製品とその下にあるすべてのものとのインターフェースです。よく設計されたAPIレイヤーは、基盤となるデータインフラの複雑さを抽象化し、アプリケーションコードがユースケース間でクリーンかつ一貫性を保ちます。
意味層
セマンティックレイヤーはメトリクスや次元の意味を定義し、すべてのクエリで一貫してそれらの定義を強制します。これがなければ、あるダッシュボードの「収益」は別のダッシュボードの「収益」と異なる意味を持つことがあります。なぜなら、異なるクエリが異なるテーブルに異なるロジックでアクセスするからです。セマンティックレイヤーがそれを防いでいます。これはビジネスロジックの唯一の真実の源であり、AI生成のクエリを信頼できるものにしている理由です。なぜなら、AIはセマンティックレイヤーが承認した定義でしか作業できないからです。
AIレイヤー
AIレイヤーは自然言語入力を構造化クエリに変換し、APIレイヤーが実行できるようにします。よく構築されたシステムでは、AIレイヤーはセマンティック層を迂回するのではなく、その上を操作します。これが会話型分析を統治可能にしている理由です。AIはセマンティックレイヤーが定義する指標や次元、つまりユーザーがアクセス許可されたデータに基づいてしか質問できません。
セキュリティ層
セキュリティ層は、UIレベルではなくクエリレベルで誰がどのデータにアクセスできるかを制御します。これにはトークンやOAuthベースの認証、ロールベースのアクセス制御、テナントレベルのデータ分離が含まれます。重要な違いは、UIレイヤーで強制されるセキュリティ(要素の表示または隠し)は回避可能であるということです。クエリ層で強制されるセキュリティは、ユーザーが見ることを許されないデータを返すという意味ではありません。
Revealのセキュリティアーキテクチャを参照
展開層
デプロイメント層は、分析の実行方法(クラウド、ハイブリッド、オンプレミス)を決定します。規制業界のSaaS企業や、データレジデンシー要件を持つエンタープライズ顧客にとって、展開の柔軟性は機能要求ではなく契約要件です。クラウド展開のみをサポートする分析APIアーキテクチャは、企業市場の重要な部分において不適格となります。
SaaS製品におけるAnalytics APIのユースケース
分析APIの抽象的な利点、すなわち製品の一部としての分析は、従来のBIアプローチではできない具体的な機能を見ると具体的に現れます。
顧客向け製品分析
SaaSチームは分析APIを使い、ダッシュボード、指標、セルフサービスの探索を直接アプリケーションに組み込んでいます。すべての顧客は、製品を離れることなく、またエンジニアリングチームが一からカスタム分析レイヤーを構築することなく、自分のデータをリアルタイムで確認できます。APIはデータアクセスを担当し、SDKはレンダリングを担当し、プロダクトチームは体験を管理します。
大規模なマルチテナント分析
分析APIは、数百から数千の顧客間で共有プラットフォーム上で安全なデータ隔離を可能にします。各API呼び出しは、返されるデータの範囲を決めるテナントコンテキストを含んでいます。つまり、新しい顧客を追加する際に新しい環境を立ち上げる必要はなく、既存のアーキテクチャ内でプロビジョニングするだけで済みます。これは、ビジネスに合わせてスケールする分析と、新しいエンタープライズ契約を締結するたびにインフラ作業を必要とする分析の違いです。
AI駆動のインプロダクトインサイト
分析がAIシステムがプログラム的にアクセスできるAPI層を経由すれば、会話型分析が可能になります。ユーザーが質問し、AIがガバナンスされたデータ層に対してクエリを生成し、その結果が製品内でユーザーのテナントや役割に限定された回答として返ってきます。これは、製品と別途AIツールを併用することなく、自然言語クエリ、自動インサイト表出、AI生成の要約を支えるアーキテクチャです。
ワークフロー統合分析
Analytics APIはユーザー操作だけでなく、アプリケーションロジックで呼び出すことができます。これにより、分析をワークフローに組み込むことが可能になります。指標が閾値を超えたときにトリガーが発動し、プロセス完了時に自動レポートが生成され、異常が検出されるとアラートが送信されます。分析は、パフォーマンスを見直す際に見るものだけでなく、製品の機能の一部となります。
Analytics APIなしでは何が壊れるのか
チームが分析統合で直面する多くの課題は同じ根本原因に起因しています。すなわち、分析がアーキテクチャの問題ではなくUIの問題として扱われていたことです。iFrameの組み込み、スタンドアロンBIツール、カスタムダッシュボードは、ユーザーにデータを可視化する即時のニーズをすべて解決します。分析が製品のネイティブの一部として動作する根本的な問題を解決するわけではありません。
一般的な故障パターン
- UIレイヤーマルチテナンシー。クエリレベルでの隔離を強制するのではなく、UIでテナントごとにダッシュボードをフィルタリングすること。うまくいくまでは、そして失敗すると、顧客のデータが別の顧客に見える状態になる。
- iFrameのカスタマイズ上限。最初のバージョンはすぐに出荷できます。2つ目のバージョンは回避策が必要です。3回目のバージョンでは、エンジニアリングチームはiFrameを製品の一部のように振る舞わせるためのハックを増やし続けています。
- それぞれ異なる意味を持つ指標です。セマンティックレイヤーがなければ、異なるクエリは同じメトリクスを異なる方法で計算します。2つのダッシュボードで異なる収益数値が表示されています。その後、顧客のエスカレーションが続きます。
- 制御できないAIです。AI機能を分析層に加えると、データ漏洩、トークンコストの予測不可能性、製品のデータモデルと矛盾するAI反応など、露出が生まれます。
- インフラ整備が必要なスケーラビリティ。新しいエンタープライズ顧客は、分析アーキテクチャがマルチテナントスケール向けに構築されていないため、プロビジョニングプロセスが発生します。
Reveal Analytics API の実装方法
RevealはSaaS製品やISV向けのAPIファーストの分析レイヤーとして構築されており、分析はアプリケーションロジックと統合され、別システムとして隣接するのではありません。APIレイヤー、SDK、セマンティックレイヤー、AI機能は、単一アーキテクチャのつながったコンポーネントであり、連携するために別々のツールを作る必要はありません。
実際の様子は以下の通りです:
- あなたのアプリケーションはRevealのAPIを呼び出し、ダッシュボードの読み込み、データのクエリ、AIインサイトのトリガーを用いていますが、これは製品がすでに使っているのと同じ認証モデルを使っています
- SDKは、設計システムを使って製品内の分析コンポーネントをレンダリングします。iFrameや外部インターフェースの漏れがありません
- 複数テナントのデータ分離はクエリレベルで強制されており、すべてのAPI呼び出しでテナントコンテキストは非任意です
- Reveal AIガバナントされたデータ層内で動作し、自然言語クエリは実行前にユーザーのテナントと役割にスコープが割り当てられます
- トークンコストはプラットフォームレベルで管理されており、無限のLLM使用の対象ではありません
- デプロイメントはデータが必要な場所で行われます — クラウド、ハイブリッド、または完全オンプレミス
独立系薬局向けのSaaSプラットフォームScriptlyは、1週間以内にRevealの分析APIとSDKを製品に組み込んでいます。顧客は現在、Scriptlyプラットフォーム内でリアルタイムの処方動向や在庫データにアクセスでき、各薬局のブランドで独自のデータに限定され、外部ツールは体験に含まれていません。この機能は営業会話における測定可能な差別化要因となりました。スクリプトリーの物語を読む
