社内データ分析エージェントの構築方法について

大規模なデータおよび分析組織では、データやインサイトへのアクセスを真にセルフサービス化することによく苦労します。業界はこの問題の解決を試みて数十年間取り組んできましたが、その成果はあまり芳しくありませんでした。しかし現在、AI がそれを可能にする信頼性の高い手段を提供しています。 GitHub のスケールにおいて、数十もの製品チームに対して専用の分析サポートを提供することは困難であり、そのため多くのチームは自らの力でこの問題に取り組まざるを得ません。製品やエンジニアリングチームが意思決定に活用できる貴重な製品テレメトリデータは多く存在しますが、どのデータモデルを使用し、どの粒度で、どのようなフィルターを適用するかを見極め、クエリを作成して結果を検証することは、データアナリストのサポートなしには常に困難でした。 そこで登場したのが Qubot です。これは GitHub Copilot を活用した当社の内部分析エージェントです。Qubot により、Hubber（GitHub の従業員をこう呼んでいます）は、GitHub データウェアハウス内の任意のデータモデルについて自然言語で質問し、数秒以内に回答を得ることができます。 Qubot はレポート作成ツールやダッシュボードの代替品ではありません。むしろ、「この機能において最も高いリテンション率を示すユーザーコホートはどれか？」や「先週この指標を最も大きく改善した製品は何ですか？」といった探索的な質問に答えるために設計されています。Qubot の維持コストはゼロであり、 unfamiliar なデータセットについてもチームが迅速に適応できるよう支援します。 本ブログ記事では、Qubot をどのように構築したか、その変遷、そして私たちが得た教訓について解説します。 Qubot の仕組み アーキテクチャには3つの主要コンポーネントがあります：ユーザーインターフェース、コンテキストレイヤー、クエリエンジンです。 ![image](https://github.blog/wp-content/uploads/2026/06/architecture.png?resize=1024%2C753) ユーザーインターフェース Qubot は Slack、VS Code、Copilot CLI を通じてアクセス可能です。Slack でのインターフェースには設定が不要であり、Hubbers の間で最も好まれるコラボレーションツールとなっています。誰かが Qubot の Slack チャンネルに質問を投稿すると、github.com で実行される Copilot Cloud Agent として Qubot インスタンスが起動します。回答は直接 Slack に提供され、ユーザーは結果を他の人と共有できるほか、スレッド内で反復して質問を発展させたり洗練したりすることもできます。すべての結果は、プルリクエスト内のマークダウン形式のレポートとして保存され、ユーザーはこれを参照してクエリの微調整を行ったり、ダッシュボードで使用したりすることができます。 Qubot はまた、ワークフローにより密接に統合された体験を望むユーザー向けに VS Code と Copilot CLI でも利用可能です。Qubot は単一のコマンドでプラグインとしてインストールでき、ユーザーが設定した他のカスタムエージェント、スキル、ツールと同様に、VS Code や Copilot CLI のあらゆるエージェントセッションで使用可能になります。 コンテキストレイヤー 当社のデータウェアハウスには、キュレーションの異なる段階にあるデータが含まれています：生イベント（ブロンズ）、適合済み事実と次元（シルバー）、特定のビジネスユースケースのために設計されたキュレーション済みのデータセット（ゴールド）です。コンテキストレイヤーは連合型で構築されており、データのタイプに合わせた知識が提供されます。 ブロンズデータについては、製品チームから提供されたテレメトリコンテキストがあり、スキーマ情報やメタデータが含まれています。 シルバーデータについては、データおよび分析チームが維持するクエリの例、利用ガイダンス、必須フィルターなどが用意されています。 ゴールドデータについては、各データセットを所有するチームから提供されるビジネスルールや指標定義があります。 また、ETLパイプラインを活用して、追加のシグナルと派生メタデータを体系的にコンテキスト層に付加しています。このコンテキストは、GitHub MCP Server を介してランタイム時に読み込まれ、コンテキスト層から取得されます。 コンテキストエージェント コンテキスト層には、複数のリポジトリにわたって永続化された新しい知識が絶えず追加されています。GitHub ではドキュメントに主に Markdown を使用しているため、複数の異なるツールとのインターフェースは不要です。 私たちは、コンテキストエージェントを通じて連合型のコンテキスト貢献を簡素化しました。チームは標準化されたテンプレートを利用するか、関連するコンテキストを含むリポジトリを参照することで貢献できます。その後、エージェントはこの情報を取り込み、整理し、Qubot における評価に基づき効果的であることが証明されている構造化形式に変換します。 評価フレームワーク コンテキスト層またはエージェント構成に対するすべての変更は、リリース前に評価されます。新しい知識でコンテキスト層を拡張したい場合は、プルリクエストを開くことができます。新しいコンテキストは、オフライン評価フレームワークを通じて処理され、回答の精度、適切な回答を見つけるまでのレイテンシ（応答遅延）が測定され、ユーザーに到達する前の回帰（性能低下）が検出されます。 構造化されたテストケース全体で Qubot を評価するためのベンチマークフレームワークには、3 つのコンポーネントがあります： テストケース：正解、真値 SQL、メタデータ（ドメイン、難易度）が既知のプロンプトから構成される厳選されたデータセット。 自動実行オーケストレーション：GitHub CLI の gh agent-task create コマンドを使用して各テストケースをエージェントタスクとして起動し、複数の並列試行を実行し、完了をポーリングして詳細な JSON 結果を保存するスクリプト。 統計集約：保存された結果を読み取り、各テストケースごとのメトリクス（完了率、精度、期間の平均/最小/最大）を計算するレポート作成スクリプト。 エンドツーエンドの流れは以下の通りです：テストケースの定義 → 各ケースで Qubot を N 回実行 → 結果の収集 → 統計の集約 → 構成の比較。 クエリエンジン Qubot は、GitHub の分析ワークロードの大部分を支える 2 つのクエリエンジンである Kusto と Trino に、MCP サーバーを介して接続します。Trino の MCP サーバーについては独自の実装を開発しましたが、Kusto に対しては Fabric RTI MCP Server のローカル版を展開しました。Kusto は高速であり、直近のイベントデータに関する探索的な質問に最適です。一方、Trino は複雑な結合処理やより深い歴史的解析を扱います。 ユーザーがどちらを使用すべきかを知ることを強制するのではなく、Qubot はデフォルトで Kusto を使用し、質問の内容が必要とする場合に自動的に Trino に切り替えます。 何が変わり、何を学んだか Qubot は GitHub で広く採用され、数百人の熱心なユーザーが数千回のクエリを実行しています。データおよび分析に関する Slack チャンネルで Hubbers が質問する数は劇的に減少しました。これは、彼らがより自律的にデータを探索できるようになり、複雑な質問の場合のみ支援を求めるようになったためです。また、これまでデータウェアハウスに手を伸ばすことを躊躇していた Hubbers もも、意思決定に必要なデータにアクセスできるようになりました。Slack、Copilot CLI、VS Code といった複数のインターフェースを提供している理由の一つは、Hubbers が非常に技術的である一方で、参入障壁がなく設定不要なオプションも提供したかったからです。 私たちはすぐに、コンテキスト層が Copilot の推論能力を強化し、専門的な分析エージェントを作成する上で鍵となることを発見しました。実験の結果、構造化され適切にキュレーションされたコンテキストは、Qubot をより正確にするだけでなく、正しい回答を返す速度を 3 倍に高めることがわかりました。これはデータモデリングの手法において、この種のアーティファクトが後回しではなく第一級市民として扱われるべきであることを意味するため、分析エンジニアリング分野に深い影響を与えます。 Qubot は、ハブ・アンド・スポーク型の実行における稀な成功例です。データおよび分析チームからの負担を軽減し、プロダクトチームは自らのサーフェスのテレメトリを所有し、ビジネスチームは自社のゴールドデータの定義を所有するという体制を実現しました。Qubot は、GitHub 全体で活用できる単一のツールに分散した知識を集約する重力のような役割を果たし、各ドメインに限定された複数のツールを作成するのではなく、パートナーチームが Qubot に貢献するためのインセンティブを提供しました。 謝辞 Qubot エンジニアリングチーム：Weijie Tan, Tobias Tschuemperlin, Vamsi Anamaneni 特別感謝：Yaswanth Anantharaju 「内部データ分析エージェントの構築方法」という記事は、The GitHub Blog で最初に公開されました。

社内データ分析エージェントの構築方法について

背景や根拠まで確認しますか？

調べる

選ぶ

サイト