はじめに
趣味として、GitHub の Pull Request / Review を集計してチームの開発サイクルを俯瞰できるダッシュボード DevPulse を作りました。
この記事では 「何ができて、何が嬉しいか」 を中心に紹介します（実装の深掘りは最小限）。
対象読者
- GitHub API を使ったダッシュボードを作ってみたい
- チームのPR/レビュー活動を可視化したい
- 「忘れ去られたPR」がないか知りたい
- GraphQL に興味がある
この記事で扱わないこと（別記事に分離済み）
Nuxt の useFetch をどう安全に便利に運用するか（キャッシュキーやリアクティビティ設計）は以下の記事をご参照ください。
本プロジェクトの技術構成一覧
- Nuxt 4 + SPAモード: ダッシュボードとして操作性重視
- Nitro（BFF）: GitHub Token をブラウザに出さずに安全に通信
- GitHub GraphQL API: 必要なデータを効率的に取得
- Zod バリデーション: API入力をサーバで厳格に検証
- キャッシュ (SWR,useFetch): 外部API呼び出し回数を抑えて安定運用
DevPulseで今できること
アプリはサイドバーから、以下の3画面にアクセスできます。
- PRInsight: チーム/期間ごとの「トップコントリビューター」とトレンド可視化
- Review Checklist: 過去のPRレビューコメントを一覧化して“よくある指摘”を見返す
- Stale PR Alert: 滞留しているPR（一定日数動きがない等）を洗い出す
機能1：PRInsight（PR一覧）
何が見える？
- トップコントリビューター（PR作成数 / レビュー数）
- チーム月次トレンド（PR作成とレビュー数の推移）
何が嬉しい？
-
チームの“回ってる感”を定量で掴める
- PR作成が多いのか、レビューが偏っているのか、ざっくり一目で把握できます。
-
期間を広げるとトレンドが見える
- 期間は「1ヶ月 / 3ヶ月（トレンド表示） / 6ヶ月（トレンド表示）」を用意していて、短期の状態と中期の推移を切り替えられます。
- 気になったPRはリンクから詳細を確認できる
フィルタ
- チーム: 共通のチーム定義からリポジトリ集合を一発で切り替え
-
対象月:
YYYY-MM（月単位） - 期間: 1 / 3 / 6 ヶ月
感想
この機能は思ってたことがそのまま実装できているので満足です。
順位の左にある横向き矢印をクリックするとそのユーザーの作成したPRとレビューしたPRがヌルっと出てきて詳細が見れるのも幸せです。
機能2：Review Checklist（レビューコメント一覧）
何が見える？
- 過去のPRレビューコメントを一覧で表示
- 「全コメント数」と「フィルタ後の表示件数」を併記
何が嬉しい？
-
頻出する指摘の“型”を見返せる
- 例: 命名、責務分離、境界条件、テスト観点など、チーム内のレビュー観点を再利用できます。
-
ノイズを減らして実用的にできる
- 除外ワード（スペース区切り）や「PR作成者のコメント除外」により、レビュー観点の抽出に寄せられます。
フィルタ
- チーム / 対象月 / 期間（1,3,6ヶ月）
- 除外ワード（半角スペース区切り）
- PR作成者のコメントを除外（チェックボックス）
感想
最初は頻出ワードでグルーピングしカウント。フレーズのみを表示できたら便利だろうなと思って開発進めましたが、
機械的なグルーピングではいろんな言い回しに対応できず断念。
代わりにコメント全文を載せるようにしました。
これはこれで文脈がわかるのでアリだと思い落ち着きました。
機能3：Stale PR Alert（滞留PRの検知）
何が見える？
- 作成から一定日数経過したまま動きのないPR
- レビュー依頼が滞留しているPR
何が嬉しい？
-
「放置されがちなPR」を定期的に棚卸しできる
- 個人の気合いではなく、ルール（閾値）で拾うのがポイントです。
-
対象範囲を柔軟に絞れる
- リポジトリ（複数可）、作成日下限、滞留日数を指定できます。
フィルタ
- チーム（チーム定義からリポジトリを切替）
- オーナー（組織名など）
- リポジトリ（カンマ区切りで複数指定可）
- 作成日下限（初期値は「今日から3ヶ月前」）
- 滞留とみなす日数（例: 14日など）
感想
・Approveまでもらったがリリースの時期を見計らっている
・緊急のものではないから後回しになっちゃってる
などなど、PRは忘れられるものです。
せっかくの取り組みにしっかりとお日様の光を浴びさせたい思いで追加機能です。
滞留理由も出すことで、どのフェーズなのかわかりやすくなりました。
この機能も結構満足のいく仕上がりで楽しさを感じております。
GitHub API に GraphQL を採用した理由（メリット）
DevPulse は GitHub の GraphQL API を使ってデータを取得しています。
を利用するメリットとしては以下があります。
- 1 回のクエリで完結: PR とレビュー情報を同時に取得
- 過不足ないデータ取得: 欲しいデータだけ指定できる
- API リクエスト数の削減: 大幅にリクエスト数を削減
参考（公式）
1回のクエリで「PR + レビュー情報」まで取れる
- REST だと「PR一覧 → 各PRのレビュー → …」になりやすく、リクエストが増えがちです
- GraphQL だと 必要な形をクエリで定義 して、まとめて取得できます
Over-fetching / Under-fetching を避けやすい
- 必要なフィールドだけ 取るので、転送量と処理が無駄に膨らみにくい
- ダッシュボード側（集計・表示）に合わせたデータ形状に寄せられます
Rate Limit の節約につながる
リクエスト数が減るので、GitHub API の Rate Limit 消費を抑えやすい です。
（加えて、フロント/サーバそれぞれでキャッシュも使っています）
感想
これは便利ですね。REST APIしか触ったことなかったですがこんな世界があるんですね。
ただ、クエリを書くとこはなんともべた書き感がありオシャレじゃない気がする。（私のサーチ不足？）
おわりに（今後の実装予定）
- ホームに「好きな指標をパネル配置」できるダッシュボード
- 開発メトリクスの可視化
- Review Response Time
- Merge Lead Time
- リリース単位の追跡
- PRでの手戻り・修正率の分析
- 知識分布マップ
好きに作ると気分転換になっていいですね！！
みなさんのチームでは、PRの滞留やレビューの偏りをどう把握していますか？
誰かのヒントになれば喜ばしいかぎりです。