分析API

ほとんどの分析統合は同じように始まります。製品チームがアプリケーション内でデータを必要とします。誰かがiFrameでダッシュボードを組み込みます。それがリリースされます。おおむね機能します。ユーザーは製品を離れることなくチャートを見ることができます。

その後、最初のカスタマイズ要求が届きます。ある顧客は、ダッシュボードを自社のブランドに完全に一致させたいと考えます。別の顧客は、ユーザーがアプリケーション内で現在行っていることに応じて反応するフィルターを必要とします。誰かが、ユーザーがレポートをナビゲートする代わりに自然言語で質問できるかどうかを尋ねます。そしてエンジニアリングチームは、iFrameが基盤ではなく、その場しのぎの回避策であったことに気づき始めます。

分析APIは、適切に構築された組み込み分析体験の土台となるものです。それは、分析が製品のネイティブな一部として振る舞うことを可能にするものであり、アプリケーションのコンテキストに反応し、ユーザーの権限を尊重し、AIが生成したインサイトを提供し、メンテナンスの負担にならずに数千のテナントにわたってスケールします。

このガイドでは、分析APIとは何か、どのように機能するか、そしてそれらを回避するのではなく、それらの上に構築するときに何が変わるのかを説明します。

分析APIとは？

分析APIは、アプリケーションが分析機能にプログラム的にアクセスし、組み込み、やり取りできるようにする一連のエンドポイントとプロトコルです。ユーザーを外部のダッシュボードツールに誘導する代わりに、アプリケーションがAPIコールを行ってデータを取得し、可視化をロードし、フィルターを適用し、インサイトを返します。これらすべてが製品インターフェース内で行われます。

分析APIは、分析をユーザーがナビゲートする目的地ではなく、アプリケーションが呼び出す機能にします。

製品およびエンジニアリングチームにとって、この転換は具体的な意味を持ちます。APIを通じて実行される分析は、ユーザーのアクションによってトリガーされ、特定のコンテキストにスコープされ、現在のユーザーの権限によってフィルタリングされ、AIシステムに接続されます。これらすべては、ユーザーが製品を使い続ける以外に何もする必要なく行われます。

従来の組み込みダッシュボードとの違いは、表面的なものではなくアーキテクチャ的なものです。iFrameは、外部ツールのUIを製品内にロードします。分析APIは、分析をアプリケーションのロジックに統合します。つまり、インターフェース、データアクセスモデル、および動作を制御するのは分析ベンダーではなく、あなたです。

分析APIの仕組み

分析APIは、アプリケーションからのリクエストを受け取り、分析エンジンを通じて処理し、構造化された結果を返します。リクエストは、「このユーザーのこのメトリクスを取得する」というシンプルなものから、「このデータセットに対してこのクエリを実行し、これらのフィルターを適用し、結果をチャートコンポーネントとして返す」という複雑なものまでさまざまです。

リクエストフロー

機能的なレベルでは、すべての分析APIのやり取りは同じパターンに従います。

• アプリケーションがリクエストを送信します — クエリ、ダッシュボードのロード指示、フィルターパラメータ、または自然言語の質問
• APIがリクエストを処理します — ユーザーを認証し、データアクセスルールを適用し、クエリを実行する
• 分析エンジンがデータを取得します — 接続されたデータベース、ウェアハウス、またはAPIから
• 結果がアプリケーションに返されます — 構造化データ、レンダリングされたコンポーネント、またはAIが生成したインサイトとして
• アプリケーションが出力をレンダリングします — 独自のUIコンポーネントまたは分析SDKを使用して

これを静的なダッシュボードの埋め込みと異なるものにしているのは、すべてのステップがアプリケーションのコンテキストによって統制されるという点です。ユーザーのアイデンティティ、そのロール、そのテナント、現在のワークフロー状態 — そのすべてがAPIを通じて渡され、何が返されるかを形作ります。分析は、単に製品の傍らに存在するのではなく、製品に反応するものになります。

中核となるAPI機能

• データクエリエンドポイント — メトリクスとディメンションに基づいて生データまたは集計データを取得する
• ダッシュボードおよび可視化エンドポイント — アプリケーション内でチャートを動的にロードまたは生成する
• フィルタリングとドリルダウン — ユーザーコンテキスト、パラメータ、およびインタラクションをプログラム的に適用する
• 認証とアクセス制御 — データが返される前に権限を適用する
• リアルタイムおよびキャッシュされたデータの処理 — ライブクエリまたはパフォーマンスのために最適化されたレスポンスをサポートする
• AIおよび会話型エンドポイント — 自然言語をクエリに変換し、構造化されたインサイトを返す

分析API対従来のBIツール

従来のBIツールは、データチームやアナリストがダッシュボードやレポートを通じてデータを探索するために設計されています。分析APIは、そのモデルを、組み込み分析がアプリケーション内で実行されるモデルへと転換します。つまり、分析は、別個の目的地としてではなく、製品体験の一部としてリクエストされ、処理され、提供されます。

実際的なギャップは、製品チームが従来のBIが設計されていなかったことを行おうとするときに現れます。リアルタイムのユーザーコンテキストに反応すること、クエリレベルでのテナント単位のデータ分離を強制すること、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が同じ統制されたデータレイヤーの1つの消費者であるプラットフォームは、ガバナンスを構造的に処理します。

Reveal AIがガバナンスをどのように処理するかをご覧ください。

分析APIアーキテクチャの主要な構成要素

分析APIは単独では動作しません。各コンポーネントが特定の責任を処理する階層化されたアーキテクチャの上に位置します。レイヤーを理解することは、プラットフォームを評価するときに重要です。なぜなら、いずれかのレイヤーのギャップは本番での問題になるからです。

APIレイヤー

APIレイヤーは、アプリケーションが呼び出すエンドポイント — クエリ、ダッシュボード、フィルター、およびAIインタラクションのため — を公開します。それは、製品とその下にあるすべてのものとの間のインターフェースです。適切に設計されたAPIレイヤーは、基盤となるデータインフラの複雑さを抽象化するため、アプリケーションコードはユースケース全体でクリーンで一貫したものになります。

セマンティックレイヤー

セマンティックレイヤーは、メトリクスとディメンションが何を意味するかを定義し、それらの定義をすべてのクエリにわたって一貫して強制します。それがなければ、あるダッシュボードの「収益」は、別のダッシュボードの「収益」とは異なる意味になり得ます。なぜなら、異なるクエリが異なるロジックで異なるテーブルにヒットするからです。セマンティックレイヤーはそれを防ぎます。それはビジネスロジックの単一の信頼できる情報源であり、AIが生成したクエリを信頼できるものにするものです — なぜなら、AIはセマンティックレイヤーが承認した定義のみを扱えるからです。

AIレイヤー

AIレイヤーは、自然言語入力を、APIレイヤーが実行できる構造化されたクエリに変換します。適切に設計されたシステムでは、AIレイヤーはセマンティックレイヤーをバイパスせず、その上で動作します。これが会話型分析を統制可能にするものです。AIは、セマンティックレイヤーが定義するメトリクスとディメンションのみを使用して、ユーザーがアクセスを許可されているデータにスコープして質問できます。

セキュリティレイヤー

セキュリティレイヤーは、誰がどのデータにアクセスできるかを制御し、UIレベルではなくクエリレベルで強制します。これには、トークンまたはOAuthベースの認証、ロールベースのアクセス制御、およびテナントレベルのデータ分離が含まれます。決定的な違い：UIレイヤーで強制されるセキュリティ（要素の表示または非表示）は回避され得ます。クエリレイヤーで強制されるセキュリティは回避され得ません — ユーザーが見ることを許可されていないデータをクエリが返すことはありません。 Revealのセキュリティアーキテクチャをご覧ください

デプロイメントレイヤー

デプロイメントレイヤーは、分析がどこでどのように実行されるか — クラウド、ハイブリッド、またはオンプレミス — を決定します。規制産業のSaaS企業、またはデータレジデンシー要件を持つエンタープライズ顧客を抱える企業にとって、デプロイメントの柔軟性は機能要求ではなく契約要件です。クラウドデプロイメントのみをサポートする分析APIアーキテクチャは、エンタープライズ市場の相当な部分にとって不適格要因となります。

SaaS製品における分析APIのユースケース

分析APIの抽象的なメリット — 製品の傍らにではなく、製品の一部としての分析 — は、従来のBIアプローチではできない、それらが可能にする具体的な事柄に目を向けると具体的になります。

顧客向け製品分析

SaaSチームは、分析APIを使用して、ダッシュボード、メトリクス、およびセルフサービスの探索をアプリケーションに直接組み込みます。すべての顧客が、製品を離れることなく、自身のデータをリアルタイムで見ることができます — そしてエンジニアリングチームがカスタムの分析レイヤーをゼロから構築する必要もありません。APIがデータアクセスを処理し、SDKがレンダリングを処理し、製品チームが体験を制御します。

大規模なマルチテナント分析

分析APIは、共有プラットフォーム上の数百または数千の顧客にわたって安全なデータ分離を可能にします。各APIコールは、どのデータが返されるかをスコープするテナントコンテキストを持ちます — つまり、新しい顧客を追加しても新しい環境を立ち上げる必要はなく、既存のアーキテクチャ内でプロビジョニングするだけです。これが、ビジネスとともにスケールする分析と、新しいエンタープライズ契約を締結するたびにインフラ作業を必要とする分析との違いです。

AI駆動の製品内インサイト

AIシステムがプログラム的にアクセスできるAPIレイヤーを通じて分析が実行されると、会話型分析が可能になります。ユーザーが質問し、AIが統制されたデータレイヤーに対してクエリを生成し、結果が回答として返ってきます — 製品内で、ユーザーのテナントとロールにスコープされて。これが、製品の傍らに別個のAIツールを必要とせずに、自然言語クエリ、自動化されたインサイトの表面化、およびAIが生成したサマリーを支えるアーキテクチャです。

ワークフロー統合型分析

分析APIは、ユーザーのインタラクションだけでなく、アプリケーションのロジックによって呼び出すことができます。これにより、分析をワークフローに組み込むことが可能になります。メトリクスがしきい値を超えるとトリガーが発火し、プロセスが完了すると自動レポートが生成され、異常が検出されるとアラートが送信されます。分析は、ユーザーがパフォーマンスをレビューしたいときに見るものだけでなく、製品がどのように機能するかの一部になります。

分析APIがないと何が壊れるか

チームが分析統合で遭遇する課題のほとんどは、同じ根本原因にたどり着きます。分析がアーキテクチャの問題ではなくUIの問題として扱われたのです。iFrameの埋め込み、スタンドアロンのBIツール、およびカスタム構築のダッシュボードはすべて、ユーザーにデータを見せるという当面のニーズを解決します。しかしそれらは、分析が製品のネイティブな一部として動作するという根本的な問題を解決しません。

よくある障害パターン

• UIレイヤーのマルチテナンシー。 クエリレベルで分離を強制する代わりに、UIでダッシュボードをテナントごとにフィルタリングすること。うまくいかなくなるまではうまくいきます — そして失敗するとき、それはある顧客のデータが別の顧客に見える形で失敗します。
• iFrameのカスタマイズの上限。 最初のバージョンは素早くリリースされます。2番目のバージョンには回避策が必要です。3回目のイテレーションまでに、エンジニアリングチームはiFrameを製品の一部のように振る舞わせるために増え続けるハックの山をメンテナンスしています。
• 異なる意味を持つメトリクス。 セマンティックレイヤーがなければ、異なるクエリが同じメトリクスを異なる方法で計算します。2つのダッシュボードが異なる収益の数字を示します。顧客からのエスカレーションが続きます。
• 統制できないAI。 そのために構築されていない分析レイヤーにAI機能を追加すると、エクスポージャーが生まれます。データ漏洩、トークンコストの予測不可能性、および製品のデータモデルに反するAIレスポンスです。
• インフラ作業を必要とするスケーラビリティ。 分析アーキテクチャがマルチテナントのスケールのために構築されていないため、新しいエンタープライズ顧客ごとにプロビジョニングプロセスがトリガーされます。

Revealが分析APIをどのように実装しているか

Revealは、SaaS製品およびISV向けのAPI優先の分析レイヤーとして構築されています — つまり、分析は別個のシステムとして傍らに位置するのではなく、アプリケーションのロジックに統合されます。APIレイヤー、SDK、セマンティックレイヤー、およびAI機能は、連携して機能させなければならない別個のツールではなく、単一のアーキテクチャの接続されたコンポーネントです。

実際にはこのようになります：

• アプリケーションがRevealのAPIを呼び出して、ダッシュボードのロード、データのクエリ、AIインサイトのトリガーを行います — 製品がすでに使用しているのと同じ認証モデルを使用して
• SDKが、iFrameや外部インターフェースの漏れなしに、デザインシステムを使用して製品内に分析コンポーネントをレンダリングします
• マルチテナントのデータ分離はクエリレベルで強制されます — テナントコンテキストはすべてのAPIコールで必須です
• Reveal AIは統制されたデータレイヤー内で動作します — 自然言語クエリは実行前にユーザーのテナントとロールにスコープされます
• トークンコストはプラットフォームレベルで制御されます — 無制限のLLM使用の対象にはなりません
• デプロイメントは、データが存在しなければならない場所で実行されます — クラウド、ハイブリッド、または完全なオンプレミス

独立系薬局にサービスを提供するSaaSプラットフォームであるScriptlyは、Revealの分析APIとSDKを1週間で自社製品に組み込みました。その顧客は現在、Scriptlyプラットフォーム内でリアルタイムの処方トレンドと在庫データにアクセスしています — 各薬局自身のデータにスコープされ、Scriptlyのブランドの下で、体験の中に外部ツールが一切ない状態で。この機能は、セールスの会話における測定可能な差別化要因になりました。Scriptlyのストーリーを読む