内部データ分析エージェントの構築方法

大規模なデータ分析組織では、データとインサイトへのアクセスを真にセルフサービス化することが難しい場合がよくあります。業界は数十年にわたってこの問題に取り組んできましたが、あまり成功しておらず、今や AI がその実現可能な方法を提供しています。GitHub の規模では、数十のプロダクトチームに専任の分析サポートを提供することは困難であり、多くのチームが自分たちでこの問題を解決する必要があります。価値あるプロダクトテレメトリは意思決定に利用できますが、適切なデータモデル、粒度、フィルターを特定し、クエリを作成して結果を検証することは、データアナリストのサポートなしでは常に困難でした。

そこで登場したのが Qubot です。これは GitHub Copilot を搭載した社内分析エージェントで、Hubber（GitHub 従業員の呼称）がデータウェアハウスの任意のデータモデルについて自然言語で質問し、数秒以内に回答を得ることを可能にします。Qubot はレポートツールやダッシュボードの代替ではなく、「この機能のユーザーコホートで最もリテンションが高いのはどれか？」や「先週、この指標の変動に最も貢献したプロダクトはどれか？」のような探索的な質問を想定しています。メンテナンスコストはゼロで、チームが不慣れなデータセットに迅速に習熟するのに役立ちます。

このブログ記事では、Qubot の構築方法、その後の変化、そして学んだ教訓について説明します。

Qubot の仕組み

アーキテクチャは、ユーザーインターフェース、コンテキストレイヤー、クエリエンジンの3つの主要コンポーネントで構成されています。

ユーザーインターフェース

Qubot は Slack、VS Code、Copilot CLI からアクセス可能です。Slack インターフェースは設定不要で、Hubber の好むコラボレーションツールです。誰かが Qubot の Slack チャンネルに質問を投稿すると、Qubot インスタンスが Copilot Cloud Agent として github.com 上に生成され、回答が直接 Slack に返されます。ユーザーは結果を共有できるほか、スレッド内で質問を反復して洗練させることができます。すべての結果はプルリクエスト内のマークダウンレポートとして保存され、ユーザーはそれを参照してクエリを微調整したり、ダッシュボードで使用したりできます。

Qubot は VS Code と Copilot CLI でも利用可能で、ワークフローにより統合されたエクスペリエンスを求めるユーザー向けです。Qubot は1つのコマンドでプラグインとしてインストールでき、VS Code や Copilot CLI のエージェントセッションで他のカスタムエージェントやスキル、ツールとともに利用可能になります。

コンテキストレイヤー

データウェアハウスには、キュレーションの段階が異なるデータが含まれています：生イベント（ブロンズ）、適合されたファクトとディメンション（シルバー）、特定のビジネスユースケース向けに設計されたキュレーションデータセット（ゴールド）です。コンテキストレイヤーはフェデレーション方式で構築され、データタイプに応じた知識が提供されます。

• ブロンズデータには、プロダクトチームが提供するスキーマ情報とメタデータを含むテレメトリコンテキストがあります。
• シルバーデータには、クエリの例、使用ガイダンス、必須フィルターなどがあり、データおよび分析チームが保守します。
• ゴールドデータには、ビジネスルールとメトリクス定義があり、それらのデータセットを所有するチームが提供します。

また、ETL パイプラインを活用して、追加のシグナルや派生メタデータでコンテキストレイヤーを体系的に強化しています。コンテキストは実行時に GitHub MCP Server を介してコンテキストレイヤーから取得されます。

コンテキストエージェント

コンテキストレイヤーは、複数のリポジトリに永続化された新しい知識で常に強化されています。GitHub では主にドキュメントにマークダウンを使用しているため、複数の異なるツールとのインターフェースは不要です。標準化されたテンプレートや関連コンテキストを含むリポジトリを参照することで、チームがコンテキストを提供できるよう、コンテキストエージェントを通じてフェデレーションでのコンテキスト提供を合理化しました。エージェントはこの情報を取り込み、整理し、Qubot の評価で効果的であると証明された構造化フォーマットに正規化します。

評価フレームワーク

コンテキストレイヤーやエージェント設定への変更はすべて、リリース前に評価されます。誰かがコンテキストレイヤーに新しい知識を追加したい場合、プルリクエストを開くことができます。新しいコンテキストはオフライン評価フレームワークを通過し、応答の正確性、正しい回答を見つけるまでのレイテンシが測定され、ユーザーに届く前に回帰をキャッチします。

Qubot を構造化テストケースで評価するベンチマーキングフレームワークは3つのコンポーネントで構成されています：

• テストケース：既知の正解、グラウンドトゥルース SQL、メタデータ（ドメイン、難易度）を含むプロンプトのキュレーションデータセット。
• 自動実行オーケストレーション：各テストケースを GitHub CLI の gh agent-task create でエージェントタスクとして起動し、複数の並行トライアルを実行し、完了をポーリングし、詳細な JSON 結果を保存するスクリプト。
• 統計集計：保存された結果を読み取り、テストケースごとの完了率、正確性、所要時間（平均/最小/最大）を計算するレポートスクリプト。

エンドツーエンドのフローは次のとおり：テストケースを定義 → Qubot をケースごとに N 回実行 → 結果を収集 → 統計を集計 → 設定を比較。

クエリエンジン

Qubot は MCP サーバーを介して、GitHub のほとんどの分析ワークロードを支える2つのクエリエンジン、Kusto と Trino に接続します。Trino MCP サーバーはカスタム実装を開発し、Kusto には Fabric RTI MCP Server のローカルバージョンをデプロイしました。Kusto は高速で、最近のイベントデータに対する探索的な質問に適しています。Trino は複雑な結合やより深い履歴分析を処理します。Qubot はデフォルトで Kusto を使用し、質問が必要とする場合に自動的に Trino に切り替えるため、ユーザーはどちらを使用すべきか知る必要がありません。

変化と学び

Qubot は GitHub で広く採用され、数百の熱心なユーザーが数千のクエリを実行しています。Hubber がデータおよび分析 Slack チャンネルで質問する数は劇的に減少しました。なぜなら、彼らはより自律的にデータを探索でき、複雑な質問の場合にのみ連絡を取るようになったからです。また、これまでデータウェアハウスに触れることのなかった Hubber も、意思決定に必要なデータにアクセスできるようになりました。これが、Slack、Copilot CLI、VS Code など複数のインターフェースを提供する理由の1つです。Hubber は非常に技術的ですが、参入障壁がなく、設定不要のオプションを提供したかったのです。

コンテキストレイヤーが Copilot の推論能力を強化し、エキスパート分析エージェントを作成する鍵であることがすぐにわかりました。実験では、構造化され、適切にキュレーションされたコンテキストが Qubot の正確性を高めるだけでなく、正しい回答を返す速度を3倍向上させることが判明しました。これは分析エンジニアリングの分野に深い影響を与え、この種のアーティファクトをデータモデリングの第一級市民にし、後付けではなくなります。

Qubot は、成功したハブアンドスポーク実行の稀な例です。データおよび分析チームの負担を軽減し、プロダクトチームは自身のサーフェスのテレメトリを、ビジネスチームはゴールドデータの定義を所有します。Qubot は重力のように、この分散した知識をすべて GitHub 全体に利益をもたらす単一のツールに集中させ、パートナーチームが各自のドメインに限定された複数のツールを作成するのではなく、Qubot に貢献するインセンティブを提供しました。

謝辞

Qubot エンジニアリングチーム：Weijie Tan、Tobias Tschuemperlin、Vamsi Anamaneni

特別感謝：Yaswanth Anantharaju