こんにちは！日々のCI/CDパイプラインの実行を眺めながら、「またテストが落ちた……」「なんだか最近、ビルドがやけに遅い気がするな……」と、なんとなくモヤモヤしていませんか？
チームの開発規模が大きくなるにつれて、CI（継続的インテグレーション）の待ち時間はチーム全体の生産性をジワジワと蝕む「目に見えない巨大なコスト」になります。
「感覚」で「最近遅いよね」と嘆くのは、今日で終わりにしましょう。今回は、GitHub Actionsの実行データをごっそり収集し、Grafanaで美しく可視化する「データドリブンなCI/CD改善の仕組み」を一緒に作っていきます。
これをマスターすれば、パイプラインのどこがボトルネックになっているのかが丸裸になり、自信を持って高速化のメスを入れることができるようになりますよ。さあ、始めましょう！
—
1. なぜ「CI/CDの可視化」が必要なのか？
GitHub Actionsの標準UIでも、個別のワークフローが何分かかったかは確認できますよね。では、なぜわざわざGrafanaを使うのでしょうか？
理由はシンプルです。「トレンド」と「相関関係」が見えないからです。
- 「先週と比べて、今日のビルド時間はどう変化している？」
- 「どのテストスイートが、どの曜日・どの時間帯に遅延している？」
- 「キャッシュのヒット率は本当に機能している？」
これらを一目で把握し、チームで共有するための「コックピット」がGrafanaのダッシュボードです。データに基づいた改善は、開発体験を劇的に向上させます。
—
2. 全体像のアーキテクチャ
今回構築する仕組みの全体像はこうです。
1. データ収集（Exporter）: GitHubのAPIを叩いて、ワークフローの実行時間や成否を取得するプログラム（または既存のExporter）を動かします。
2. 時系列データベース（Prometheus）: 収集したデータを時系列データとして蓄積します。
3. 可視化（Grafana）: Prometheusのデータを元に、イケてるダッシュボードを描画します。
今回は、最も手軽で確実な方法として、GitHub公式のメトリクスやWebhook、あるいはAPIを定期ポーリングしてPrometheus形式でメトリクスを公開するオープンソースのツール（例: `github-actions-exporter` や自製スクリプト）を活用するアプローチを想定して解説します。
—
3. ステップ1：GitHub APIからメトリクスを収穫する
まずは、GitHub Actionsのデータを手に入れます。GitHubは強力なREST API / GraphQL APIを提供しており、これを使うことでワークフローの実行履歴（ステータス、開始時間、終了時間、ジョブ名など）をすべて取得できます。
手軽に始めるために、Pythonを使った簡単なコレクター（Prometheusクライアント利用）の概念コードを見てみましょう。これを定期実行するか、常駐のExporterとして動かします。
metrics_collector.py
import time
import requests
from prometheus_client import start_http_server, Gauge
Prometheusメトリクスの定義
ワークフローの実行時間を記録するゲージ
WORKFLOW_DURATION = Gauge(
‘github_workflow_duration_seconds’,
‘Workflow execution time in seconds’,
[‘repository’, ‘workflow_name’, ‘status’]
)
GITHUB_TOKEN = “your_ghp_token_here”
REPO = “your-org/your-repo”
def fetch_workflow_runs():
url = f”https://api.github.com/repos/{REPO}/actions/runs”
headers = {“Authorization”: f”Bearer {GITHUB_TOKEN}”}
response = requests.get(url, headers=headers)
if response.status_code != 200:
print(f”Failed to fetch: {response.status_code}”)
return
runs = response.json().get(“workflow_runs”, [])
for run in runs:
name = run[“name”]
status = run[“conclusion”] or run[“status”]
# 簡易的にdurationを計算する例（実際はcreated_atとupdated_atの差分など）
# Prometheusにメトリクスをセット
# WORKFLOW_DURATION.labels(repository=REPO, workflow_name=name, status=status).set(duration)
if __name__ == ‘__main__’:
# Prometheusのメトリクス公開サーバーをポート8000で起動
start_http_server(8000)
print(“Metrics exporter started on port 8000…”)
while True:
fetch_workflow_runs()
time.sleep(60) # 1分ごとにポーリング
—
4. ステップ2：Prometheusでデータをスクレイピングする
先ほどのエクスポーターが動いたら、次はPrometheusに「このデータを定期的に見に行ってね」と伝えます。`prometheus.yml`にスクレイピングの設定を追加しましょう。
prometheus.yml
global:
scrape_interval: 60s
scrape_configs:
- job_name: ‘github-actions’
static_configs:
# 先ほどのPythonスクリプトやエクスポーターが動いているホストを指定
- targets: [‘localhost:8000’]
これで、GitHub Actionsの状態が時系列データとしてPrometheusの海に溜まり始めました。「データを貯める」という最初の難関はこれでクリアです！
—
5. ステップ3：Grafanaで「極上のダッシュボード」を作る
さあ、いよいよクライマックスです。Grafanaを起動し、データソースとしてPrometheusを追加したら、ダッシュボードを作りましょう。
初心者でも絶対に作るべき、「ボトルネック発見 3大パネル」をご紹介します。
① ワークフロー実行時間の推移（タイムシリーズ）
- PromQLクエリ例:
sum(github_workflow_duration_seconds) by (workflow_name)
- 見どころ: 「どのワークフローが重いのか」が一発で分かります。特定のPRから急にビルド時間が跳ね上がっているポイントがあれば、それがボトルネックです。
② ジョブごとの成功率（円グラフ or 統計パネル）
- PromQLクエリ例:
sum(github_workflow_duration_seconds{status=”success”}) / sum(github_workflow_duration_seconds) 100
- 見どころ: チームのCIの「健康状態」を示します。これが90%を下回っているなら、不安定なテスト（フレキーテスト）が潜んでいる証拠です。
③ 「最遅」工程ランキング（棒グラフ）
- 見どころ: 「テスト」「ビルド」「Dockerイメージのプッシュ」のうち、どこが一番時間を食っているのかをランキング形式にします。ここを最適化（キャッシュの導入や並列化）するのが、エンジニアの腕の見せ所です。
—
6. データドリブンな改善をチームに定着させるコツ
ダッシュボードが完成したら、ぜひチームの定例ミーティングやSlackにこのGrafanaのグラフを貼ってみてください。
「今週、テスト工程の時間が先週比で20%増えていますね。何が変わったか見てみましょうか」
こんな会話が自然と生まれ、感覚ではなくファクト（事実）に基づいた高速化のチケットを切ることができるようになります。
まとめ
今回は、GitHub Actionsの実行データをPrometheusとGrafanaを使って可視化し、CI/CDのボトルネックをデータドリブンに暴く方法を解説しました。
- GitHub APIからデータを集め、
- Prometheusで蓄積し、
- Grafanaでチームのコックピットとして可視化する。
これを一度セットアップしてしまえば、あなたのチームのCI/CDパイプラインは劇的に洗練され、日々の開発ストレスがスーッと消えていくのを実感できるはずです。
これをマスターすれば、毎日の作業が本当に楽になりますよ。ぜひ、次のスプリントの空き時間に試してみてくださいね！