Grafana Cloud に GitHub App 認証で GitHub データソースを接続し、PR を可視化する

個人の GitHub アカウントと Grafana Cloud だけで、リポジトリの Pull Request を Grafana から検索できるようにしてみました。認証には Personal Access Token ではなく GitHub App を使います。GitHub App は読み取り専用かつリポジトリ単位でスコープを絞れるため、PAT よりも権限を絞り込みやすいのが理由です。

作業は、Integration と Data source のどちらを使うかの判断から始まり、GitHub App の作成とインストール、Grafana 側でのデータソース追加と認証設定、最後に PR をクエリするところまで、6 つのステップで進みます。

前提

• 個人の GitHub アカウント（Free で構いません）
• Grafana Cloud のスタック（データソースを追加できる権限）
• GitHub.com を対象とすること（GitHub Enterprise Server は対象外です）

GitHub data source プラグインは Grafana 11.6.7 以降に依存します。Grafana Cloud であればこの条件は満たされています。

1. なぜ Integration ではなく Data source を選ぶのか

Grafana で GitHub を扱う入口は 2 つあり、これが最初の分かれ道になります。Connections で github を検索すると、Integration の GitHub と Data source の GitHub が両方表示されます。

この 2 つは取得できるデータの性格が違います。Integration は Grafana Alloy 経由で、リポジトリのスター数やフォーク数、API レート残量といった統計を Prometheus 系列として継続的に収集する仕組みです。一方 Data source は GitHub API をクエリ時に直接叩き、コミットや Pull Request、Issue といった個別レコードをその場で取得します。

今回やりたいのは「直近 7 日間でマージされた PR」のような PR 単位の問い合わせです。統計の定点観測ではなく、その場で条件を指定して PR を引きたいので、Data source プラグインを選びます。

2. GitHub App を作成する

GitHub の Settings → Developer settings → GitHub Apps を開き、New GitHub App をクリックします。

GitHub App name と Homepage URL は必須です。Homepage URL は実在する URL であれば何でも構わないので、今回は Grafana Cloud のスタック URL（https://hidetaka.grafana.net/）を入れました。App 名は Grafana-Cloud-personal としています。

Webhook は今回使いません。データソースは GitHub からデータを読み取るだけで、イベント通知を受け取る必要がないためです。Active のチェックを外しておけば、Webhook URL の入力も不要になります。

Permissions では Repository permissions を読み取り専用で付与します。Metadata は必須（mandatory）で、それ以外に Pull requests など必要なものを Read-only で選びます。今回の構成では 9 つを選択し、Metadata と合わせて 10 個の権限になりました。インストール範囲は Only on this account を選び、自分のアカウント内に閉じます。第三者のアカウントにインストールできる必要はないからです。

権限をもう少し絞り込みたい場合、GitHub data source の公式ドキュメントでは Metadata・Contents・Issues・Pull requests・Packages・Repository security advisories・Projects の Read-only が必要と案内されています（Configure the GitHub data source）。使うクエリタイプに応じてここを調整するとよさそうです。

登録が完了すると、秘密鍵の生成を促すメッセージが表示されます。

Generate a private key をクリックすると .pem ファイルがダウンロードされます。この秘密鍵は後で Grafana に貼り付けるので、App ID とあわせて控えておきます。

3. App をインストールして Installation ID を得る

作成した App の Install App から、自分のアカウントに対して Install します。

インストール対象リポジトリは All repositories か Only select repositories を選べます。今回は All repositories を選びました。特定リポジトリだけを見たい場合は Only select repositories で絞り込めます。付与される権限が読み取り専用であることも、この確認画面で再度確認できます。

インストール後、アカウントの Installed GitHub Apps から対象 App の権限一覧を確認できます。actions・checks・code quality・commit statuses・deployments・issues・merge queues・metadata・pull requests・security events に対する Read アクセスが付与されています。

Installation ID は Settings → Installed GitHub Apps → Configure と進んだ先の URL 末尾の数字です（https://github.com/settings/installations/<INSTALLATION_ID>）。これで App ID・Installation ID・秘密鍵の 3 点が揃いました。

4. Grafana Cloud に GitHub データソースを追加する

Grafana の左メニューから Connections → Add new connection を開きます。

検索で GitHub の Data source を選び、プラグインの Overview から Install します。Managed by Grafana 提供で、依存は Grafana 11.6.7 以降と表示されます。

インストール済みであることは Version history で確認できます。今回の環境では 2.8.0 が入っていました。

続いて Add data source で github を検索し、Signed と表示された GitHub データソースを選びます。

5. GitHub App 認証を設定する

データソースの設定画面で Authentication Type を GitHub App に切り替えます。Personal Access Token がデフォルトで選ばれているので、ここは明示的に変更が必要です。切り替えると、App ID・Installation ID・Private Key の入力欄が現れます。

Private Key には .pem ファイルの中身をそのまま貼り付けます。ターミナルからクリップボードへ送ると改行を崩さずに済みます。

cat ~/Downloads/grafana-cloud-personal.2026-05-31.private-key.pem | pbcopy

Connection の GitHub License Type は、個人アカウントなので Free, Pro & Team を選びます。Enterprise Cloud や Enterprise Server を選ぶ必要はありません。入力が終わったら Save & test を押します。

接続に成功すると、Data source is working と表示されます。ここまでで GitHub と Grafana がつながりました。

6. PR データをクエリする

Explore で接続したデータソースを選び、Query Type に Pull Requests を指定します。Owner に対象アカウント、Repository を空にすると Owner 配下を横断できます。Query 欄には GitHub の検索構文をそのまま書けるので、is:closed is:unmerged のように条件を指定します。Time Field を ClosedAt にすると、クローズ日時で時系列に並べられます。

「直近 7 日間でマージされた PR」「マージされずにクローズされた PR」「放置されている PR」をまとめて見たかったので、条件を毎回手で組み立てるかわりに、Grafana の Assistant へ次のプロンプトで頼んでみました。

githubのprデータを収集して。直近７日間でマージされたPR / マージされずにクローズされたPR / 放置されているPRを見たい

ここで分かったのは、Assistant はデータソースの Pull Requests クエリをチャットから直接実行はしない、ということです。Assistant 自身が「クエリを直接実行するネイティブツールはない」と述べたうえで、Explore に貼るための GitHub 検索クエリをカテゴリ別に提示してくれます。AI がデータを集めてくれるわけではなく、意図を検索構文へ翻訳してくれる相棒、という役割でした。

Explore の time range を now-7d にしたうえで、提示されたクエリを貼って実行します。確認できたのは次の 2 つです。

マージされた PR は、次のクエリで取得します。

is:merged merged:>=2026-05-25

マージされずにクローズされた PR は、未マージかつクローズ済みで絞ります。

is:closed is:unmerged closed:>=2026-05-25

放置されている PR（更新が止まっている open な PR）は、is:open に最終更新日の上限を組み合わせて絞り込みます。次は考え方を示す例です（このクエリは検証画面に写っていないため、環境に合わせて調整してください）。

is:open is:pr updated:<2026-05-25

日付は Explore の time range（now-7d）と検索構文側の日付修飾子の両方で「直近 7 日間」を表現しています。time range だけでは GitHub 検索側の絞り込みに反映されないため、クエリ側にも日付を入れる点に注意が必要です。

まとめ

個人の GitHub アカウントと Grafana Cloud だけで、GitHub App 認証による読み取り専用のデータソースを作り、PR を検索構文でクエリできるようになりました。入口で Integration ではなく Data source を選ぶこと、認証で GitHub App を明示的に選ぶこと、検索の日付絞り込みはクエリ側にも書くこと。この 3 つが、つまずきやすいポイントでした。

Assistant は PR データそのものを集めてはくれませんが、見たい条件を検索クエリに落とし込む相棒としては、十分に頼りになりそうです。