［開発者向け］GitHubが社内データ分析エージェント「Qubot」を公開——Slack・VS Code・CLIから自然言語でデータ分析

2026-06-20

はじめに

　GitHubは2026年6月19日、社内向けに開発したデータ分析エージェント「Qubot」の構築過程を公式ブログで公開しました。Qubotは、GitHub Copilotを基盤に、社員が自然言語でデータウェアハウスに問い合わせできる仕組みです。本稿では、その仕組みと開発を通じて得られた知見について解説します。

参考記事

タイトル: How we built an internal data analytics agent
著者: Matteo Vasirani, Cynthia Joseph
発行元: GitHub Blog
発行日: 2026年6月19日
URL: https://github.blog/ai-and-ml/github-copilot/how-we-built-an-internal-data-analytics-agent/

要点

Qubotは GitHub Copilot を基盤とした社内データ分析エージェントであり、Slack・VS Code・Copilot CLIの3つのインターフェースから自然言語でデータウェアハウスに問い合わせできる
データ基盤を生データ(bronze)、整形済みデータ(silver)、業務用途向けデータ(gold)の3層に分け、各層の担当チームが分散的にコンテキスト情報を提供する「コンテキストレイヤー」を構築している
クエリエンジンとして Kusto と Trino をMCPサーバー経由で使い分け、探索的な質問にはKusto、複雑な結合や履歴分析にはTrinoを自動的に選択する仕組みを持つ
構造化されたコンテキスト情報を整備することで、回答精度の向上に加えて応答速度が3倍になったと報告されている
評価フレームワークにより、コンテキストレイヤーやエージェント設定への変更はすべて本番反映前にオフラインで精度・速度・回帰の有無を検証している

詳細解説

Qubotとは何か

　Qubotは、GitHubの社員(同社では「Hubber」と呼ばれます)が、社内のデータウェアハウスに対して自然言語で質問し、数秒で回答を得られるエージェントです。GitHubによれば、Qubotはダッシュボードやレポーティングツールの代替ではなく、「このチームの中で最も継続率が高いユーザー層は?」といった探索的な問いに答えるためのツールと位置づけられています。

　大規模なデータ組織では、すべてのプロダクトチームに専任のデータアナリストを配置することは難しく、どのデータモデル・粒度・フィルタを使うべきかの判断や、クエリの作成・検証を現場のチームだけで行うのは従来から難しい課題でした。データセルフサービス化はこれまで業界全体で長く模索されてきたテーマであり、自然言語によるデータ分析エージェントはその一つの解として近年注目されています。

3つのインターフェース

　Qubotは Slack、VS Code、Copilot CLIの3つの経路から利用できます。Slackでは設定不要で、専用チャンネルに質問を投稿するとCopilot Cloud Agentとしてインスタンスが起動し、回答がスレッド内で返されます。結果はプルリクエスト内にMarkdownレポートとしても保存され、後からクエリを調整したりダッシュボードに転用したりできる仕組みです。VS CodeやCopilot CLIでは、ワンコマンドでプラグインとして導入でき、他のエージェントやツールと並行して利用できます。

　複数のインターフェースを用意した理由について、GitHubは「Hubberは技術的なスキルを持つ人が多いが、設定不要で参入障壁のない選択肢も提供したかった」と説明しています。Slack中心の手軽な利用と、開発環境に統合された利用の両方をカバーする設計だと言えます。

コンテキストレイヤーの設計

　Qubotのアーキテクチャは、ユーザーインターフェース、コンテキストレイヤー、クエリエンジンの3層で構成されています。中でも特徴的なのがコンテキストレイヤーで、データウェアハウス内のデータをbronze(生イベント)、silver(整形済みのファクト・ディメンション)、gold(業務用途向けに整備されたデータセット)の3段階に分け、それぞれの段階に応じて異なる種類のコンテキスト情報を紐づけています。

　具体的には、bronzeデータにはプロダクトチームが提供するスキーマ情報、silverデータにはデータ・分析チームが管理するクエリ例や利用ガイダンス、goldデータには各データセットの担当チームが定めるビジネスルールや指標定義が割り当てられます。コンテキストはGitHub MCP Server経由でランタイムに読み込まれる構成です。

　このような分散型のコンテキスト管理は、いわゆる「ハブ・アンド・スポーク」型の運用モデルに相当します。一極集中でデータ分析チームがすべてを管理するのではなく、各チームが自分たちの領域の知識を持ち寄ることで、特定のチームに作業が偏らない体制を実現していると考えられます。

　なお、コンテキスト情報の追加・更新は「コンテキストエージェント」と呼ばれる仕組みを通じて行われ、標準テンプレートやリポジトリ参照によって提供された情報を取り込み、構造化された形式に整理する役割を担っています。コンテキストエンジニアリングという考え方自体は、Copilotの回答精度を高める技術としても過去に取り上げていますが、Qubotではそれを社内データ分析という領域に応用した形と言えそうです。

評価フレームワークによる品質担保

　コンテキストレイヤーやエージェント設定への変更は、すべて本番環境に反映される前にオフラインの評価フレームワークを通過する仕組みになっています。GitHubによれば、この評価は既知の正解・正しいSQL・ドメインや難易度などのメタデータを含むテストケース群をもとに、GitHub CLIのgh agent-task createコマンドで並列実行し、完了率・精度・所要時間といった指標を自動集計するというものです。

　評価結果として、構造化され十分に整備されたコンテキストは、回答精度の向上だけでなく応答速度を3倍に高めたとGitHubは報告しています。継続的な評価の仕組みを組み込むことで、コンテキストの追加が品質低下につながらないようにする工夫だと考えられます。

クエリエンジンの使い分け

　Qubotは KustoとTrinoという2つのクエリエンジンに、MCPサーバーを介して接続しています。Kustoは直近のイベントデータに対する探索的な質問に適しており、Trinoは複雑な結合処理や深い履歴分析を得意とします。GitHubはTrino向けに独自のMCPサーバー実装を開発した一方、Kustoについては Microsoft Fabric RTIのMCP Serverをローカルに展開して利用しているとのことです。

　ユーザーがどちらのエンジンを使うべきか判断する必要はなく、Qubotがデフォルトでまず Kustoを使用し、質問の内容に応じて自動的にTrinoへ切り替える設計になっています。MCPサーバーを通じて複数のクエリエンジンを抽象化する発想は、GitHub公式のMCPサーバー活用に関する解説でも紹介したアプローチと近い性質を持つと言えるでしょう。

　なお、社内データ基盤に対する自然言語エージェントという取り組み自体は、GitHub以外の企業でも同様の事例があります。データを段階的に整理しコンテキストとして与えるという設計思想は、社内データ分析エージェントを構築する際の一つの共通パターンになりつつあるのかもしれません。

まとめ

　Qubotは、社内のデータウェアハウスに対する自然言語での問い合わせを実現するエージェントとして、GitHub社内で広く活用されているとのことです。構造化されたコンテキストレイヤーの整備が回答精度と速度の両方に寄与した点は、社内データ活用を検討する企業にとっても参考になる事例だと思います。MCPサーバーの活用については過去記事でも整理していますので、あわせてご覧いただければと思います。