ビジネスの質問に誰も答えられない理由 — WorkOS ガレット・ガロウ

ビジネスの質問に誰も答えられない理由：WorkOS が「Studio」で実現したデータ民主化の実践

多くの企業では、マーケティングやサポートチームが「なぜ売れているのか」「顧客はなぜブロックされたのか」といったビジネス上の疑問を抱えても、エンジニアやデータ分析チームへの問い合わせという非効率なループに陥りがちです。WorkOS の製品責任者であるガレット・ガロウ氏は、このボトルネックを打破するため、LLM エージェントが自律的にデータを分析し、即座に再利用可能なダッシュボード（ウィジェット）を生成する「Studio」という仕組みを導入しました。

これは単なるチャットボットの活用ではなく、自然言語で指示を出すだけで社内データソースに直接アクセスし、実行可能なコードを構築・運用する新しい DX の形を示すものです。

従来の非効率なループと Studio の登場

一般的なエンタープライズ環境では、ビジネスチームがデータに基づいた意思決定を行う際、以下のようなプロセスを経ることになります。まず、誰かが「このコンテンツが新規顧客獲得にどう寄与しているか知りたい」と質問します。しかし、SQL を書けるのは限られたエンジニアやデータアナリストだけであるため、彼らに問い合わせる必要があります。

「質問を説明し、文脈を示して待つ。答えが得られても『もっと深い分析が必要』となり、またやり取りを繰り返す。Slack でのやり取りは非構造化でスケーラブルではない」

この「質問→エンジニアへの依頼→待機→確認→再依頼」という往復運動は、意思決定のスピードを著しく低下させます。WorkOS はこの課題に対し、Studio という自律型ワークスペースを導入しました。これは、技術的な知識がなくても、自然言語で質問するだけで LLM エージェントが直接データにアクセスし、分析結果を可視化できる場所です。

自然言語から即座に動くダッシュボードへ

Studio の核心は、LLM エージェント（LangChain と Claude Opus を基盤）が、Snowflake や Linear、Notion といった社内ツールと連携して自動的にクエリを実行し、結果に基づいてダッシュボードを生成する点にあります。

例えば、「どのブログ記事やドキュメントが最も多くの新規チーム登録につながっているか」という質問に対して、Studio は以下のように動作します。

1. リソースの特定: Snowflake や Linear などの接続済みデータソースを確認し、必要なテーブルを特定します。
2. クエリの実行: エージェントがコンテキストを理解した上で SQL を生成・実行し、データを取得します。
3. ウィジェットの生成: 単なる回答だけでなく、チームメンバーと共有できる「再利用可能なウィジェット」をコードとして生成します。

「一度生成されたウィジェットは、LLM が毎回実行するのではなく、静的な JavaScript コードとして動作します。これにより、コスト効率と信頼性が担保されます。」

実際に Studio で生成されたウィジェットは、UI と API、そして背後で動くクエリをすべて含んだ「実行可能なサンドボックス」です。ユーザーは「この列を追加して」「カテゴリフィルターをつけて」と指示するだけで、リアルタイムにデータが更新されるダッシュボードを即座に手に入れることができます。

信頼性を支えるアーキテクチャとガバナンス

LLM をビジネスツールとして使う際最大の懸念は「ハルシネーション（嘘）」や「誤ったクエリ」です。WorkOS はこれを防ぐために、以下の3 つの層を設けています。

1. コンテキストの注入（ガイダンス層）

データベースには複雑な結合ルールや、社内の用語定義が存在します。例えば、「顧客エンティティとユーザーの関係は 4 つのテーブルを跨ぐ必要がある」などの文脈は、LLM が自動的に推測できるものではありません。

Studio はランタイムでこれらのコンテキスト（スキーマ情報、結合ルール、ステータスフィルタなど）を注入する「ガイダンス層」を持っています。これにより、LLM は社内の複雑なデータ構造を正しく理解し、効果的なクエリを生成できます。

2. シーケンシングと検証プロセス

新しい質問が来ると、エージェントは即座に実行するのではなく、以下のチェックリストに従って段階的にアプローチします。

• ツール接続の確認
• 文脈の不足確認（必要なら質問を返す）
• ツールの選択とコンテキスト注入
• クエリの実行と結果検証

特に重要なのが「実行前の検証」です。LLM が SQL を生成した後、実際に Snowflake で実行してデータが返ってくるかを確認します。「有効な SQL だが結果がゼロ」というケースを防ぎ、信頼性の高いデータを基盤に据えます。

3. 「一次情報源」への依存

製品に関する知識については、LLM のトレーニングデータ（古い情報）を信じるのではなく、「ドキュメントやデータベースなどの一次情報源を検索せよ」と指示しています。WorkOS の製品は急速に変化するため、モデルの知識に頼らず、常に最新の実データを参照するよう設計されています。

自律的な意思決定への道

この仕組みにより、サポートチームは顧客が Radar（セキュリティプロダクト）でブロックされた理由を、エンジニアへの問い合わせなしに自らのウィジェットで検索できるようになりました。また、マーケティングチームも、コンテンツの効果を即座に可視化し、戦略を修正できます。

「プラットフォームチームやデータチームがすべてのダッシュボードを作る必要はありません。質問が頻繁に来るようであれば、ビジネスチーム自身がそれを構築・共有すればよいのです。」

Studio は、LLM を単なるチャットツールとして使うのではなく、「実行可能なコードとツールを生成・運用するインフラ」として統合した事例です。データ分析の民主化と意思決定スピードの劇的な向上は、今後の社内 DX における標準的なパターンとなる可能性を秘めています。

まとめ

WorkOS の Studio は、LLM エージェントが自律的にデータを理解し、信頼性の高いコードを生成・運用することで、組織内の「質問への回答待ち」を解消しました。これは、AI が人間の代わりに思考するだけでなく、人間が AI を使って即座に行動できる環境を整えるための重要な一歩です。