AI エージェントに開発チームのサイクルタイム分析を任せてみた

こんにちは。クラウドサインで開発をしている林（@rinyu_tech）です。

チームの開発サイクルタイム分析の負荷を下げるために、AI エージェントと各種サービスを組み合わせて自動化した話を紹介します。

• 背景
• 課題提起
• 取り組んだ結果
  • もし手動で分析を実施した場合
  • AI エージェントを用いた分析の場合
• 接続したデータソース
• AI が行う分析フロー
  • 分析フローの全体像
  • カスタムコマンドのプロンプト
  • サービス間の横断分析
  • 長期滞留 PR の原因調査
    • 季節要因の自動判定
    • それ以外の要因を深掘り
  • 事実と考察の分離
• 2 ヶ月の運用で分かったこと
  • データの信頼性は AI では解決できない
  • レトロの議論が変わった
• まとめ

背景

私たちのチームでは価値提供速度の向上活動に取り組んでいます。開発プロセスのボトルネックを特定して改善するために、サイクルタイムを可視化する基盤を整えました。JIRA¹ のユーザーストーリーや実装タスク、GitHub² プルリクエスト（以下 PR）を Tableau³ ダッシュボードで一覧できます。

そして、チームの状態を見える化するだけでなく、そこから得られるインサイトをもとに改善サイクルを回していきたいと考え、月次でサイクルタイムを分析するフローを作ることにしました。

課題提起

問題は分析の手間でした。もし CSV をダウンロードしてスプレッドシートで集計して考察を書くような運用になってしまったら、手間を想像しただけで嫌になりました。スプリント中は開発タスクに集中する必要があるので、分析に時間をかけすぎると本末転倒です。価値提供速度を上げたいのに分析で時間を使っていては意味がありません。

また JIRA だけではステータス更新漏れで正確な着手日がわからず、GitHub だけではチケット全体の流れが見えないという問題もあります。複数のダッシュボードを行き来しながら手作業で突合するのは負担が大きく、継続的にやっていくのは難しいと感じていました。

分析の負荷をできるだけ下げて、チームの開発活動に自然と組み込める形にしたい。そこで AI エージェントと各種サービスを連携させた自動化に取り組みました。

取り組んだ結果

先に結果をご紹介します。

もし手動で分析を実施した場合

1. Tableau ダッシュボードを開き、フィルタを設定
2. CSV をダウンロード
3. Google スプレッドシートで集計・グラフ作成
4. 気になるストーリーを JIRA で個別確認
5. GitHub で PR の詳細を調査
6. 考察を手作業で記述

所要時間： 数時間。

AI エージェントを用いた分析の場合

1. カスタムコマンド⁴を 1 つ実行
2. AI が自動でデータ取得 → 分析 → 考察 → esa⁵ にレポート投稿
3. レポートをレビューして必要に応じてブラッシュアップ

所要時間： 10〜20 分。

接続したデータソース

今回の仕組みでは、以下の 4 つのデータソースを Claude Code⁶ に MCP⁷ や CLI⁸ で接続しています。

データソース	接続方法	役割
Tableau	Tableau MCP	集計済みのサイクルタイムデータを取得。全体傾向の把握に使う
JIRA	CLI	チケットの詳細情報、changelog、関連タスクの作成日を取得
GitHub	CLI	コミット履歴、レビュー履歴、変更規模を取得。もっとも正確な着手日がわかる
esa	社内構築した MCP サーバー	過去レポートの参照と、新しいレポートの投稿

この構成のポイントは、各ツールの強みを活かして弱みを補い合っているところです。

Tableau は大量データの集計に向いている一方社内全体で共用するダッシュボードという性質上、チーム固有の分析には柔軟性が足りない場合もありました。JIRA CLI や GitHub CLI は正確なデータを取れる反面、大量のチケットを一度に取得するのには向きません。

そこで、全体傾向は Tableau で高速に把握して、気になるところだけ JIRA・GitHub で詳細を取るという使い分けをしています。Tableau の数値に違和感があれば、他のデータソースでの検証も可能です。

AI が行う分析フロー

ここからが今回の仕組みの核心です。AI に分析を任せると言っても、ただ「分析して」と投げているわけではありません。

分析フローの全体像

全データに対して JIRA の詳細や Git の情報を取得するのは、目的が不明確なまま大量の API を呼ぶことになり非効率です。まず俯瞰して「ここが気になる」というポイントを絞ってから、そこに必要なデータだけを取りにいく。人間がやっている分析の思考プロセスと同じ流れを、AI にもやらせています。

カスタムコマンドのプロンプト

この流れをカスタムコマンドのプロンプトとして定義しています。実際のプロンプトにはデータソースのフィールド名や MCP・CLI の呼び出し例なども含まれていますが、骨格は以下の 4 フェーズです。

## 情報収集
- 過去の分析レポートを参照し、前回の課題や施策効果を確認
- Tableau MCP で JIRA サイクルタイムデータを取得
- 各ストーリーの分割先タスクを JIRA CLI で特定し、関連タスク作成日を着手日として取得
- Tableau MCP で GitHub PR サイクルタイムを取得

## 分析・計算
- ストーリー・PR・タスクのサイクルタイム統計値を算出
- 時系列比較分析（トレンド、季節性の考慮、変化率）
- 長期滞留 PR の原因調査
  - 季節要因（年末年始・GW 等）の自動判定
  - 休暇以外の要因は GitHub CLI で変更規模やレビュー履歴を取得して深掘り

## レポート生成
- 「結論（事実）」と「考察（推測）」を明確に書き分ける
  - 結論: データから直接読み取れる事実のみ。断定形で記述
  - 考察: 事実に基づく解釈や仮説。推測であることを明示し、根拠への参照を含める
- Active Time（作業時間）と Wait Time（待ち時間）を分離して施策を検討

## esa への投稿
- 生成したレポートを投稿

ここからは、このプロンプトに従って AI が実際に行った分析の具体例を紹介します。

サービス間の横断分析

AI がデータソースをまたいで分析することの威力が一番わかりやすい例を紹介します。

ある月のレポートで、AI が以下のような結果を出しました。

• ストーリーのサイクルタイム（中央値）: 前月比 -62％ と大幅に短縮
• PR のサイクルタイム： 前月比 +15％ と微増

一見すると矛盾しているように見えます。ストーリー全体は速くなったのに、PR だけ遅くなっています。

AI はこの矛盾に対して、Tableau ダッシュボードに集計されたストーリーポイントデータと JIRA のチケット詳細を組み合わせて分析しました。結果「ストーリー規模が平均 SP 8 から 4 に小型化されたことが主因」「PR 提出前の設計・実装フェーズで大幅に効率化された」「PR サイクルタイムの増加は別の要因」という考察を出しています。

人間が複数のダッシュボードを見比べても同じ結論に辿り着けますが、AI はこれを数分で出してくれます。

長期滞留 PR の原因調査

個人的に「これは AI に向いている仕事だ」と一番感じたのが、長期滞留 PR の原因調査です。

レビュー開始から承認（Approve）までの時間が一定の閾値を超えた PR に対して、AI が自動で以下の調査をします。

季節要因の自動判定

年末年始や GW などの休暇期間を跨いでいるかどうかを判定します。実際に 1 月の分析では、長期滞留した 13 件の PR のうち 10 件（77％）が年末年始の影響だと自動で分類されました。

それ以外の要因を深掘り

残りの 3 件については、GitHub API で変更規模やレビュー履歴を取得して原因を特定します。レビューコメントの内容から「テストパターン改善要求への対応」「モック処理に関する設計議論」「先行 PR のマージ待ち」といった具体的な原因まで出してくれました。

13 件の PR を 1 つずつ手で調べていたら半日はかかる作業です。AI なら数分で終わるうえに、毎月同じ品質で繰り返せるのが大きなメリットだと感じています。

事実と考察の分離

もう 1 つ、地味ですが大事な工夫として、AI には「結論（事実）」と「考察（推測）」を明確に書き分けるよう指示しています。

「1 月のサイクルタイム中央値は 59h（営業日ベース）」は事実として断定形で書きます。「年末年始の影響を除外すると前月と同程度であり、パフォーマンス低下ではないと推測される」は推測として明示します。

こうしておくとレトロスペクティブでの議論はデータを起点としたものになり、建設的な話し合いへつながります。

2 ヶ月の運用で分かったこと

1 月に Tableau MCP を導入して月次レポートの自動生成を始め、直近 2 回分のレポートを作成しました。まだ運用期間は短いですが、すでにいくつかの学びがあります。

データの信頼性は AI では解決できない

弊社内で作成している Tableau ダッシュボードのデータ取得条件にはまだ調整の余地があります。たとえば GitHub 側では、PR 作成時にチーム用アカウントへ自動アサインされる仕組みのせいで、レビューリクエストのタイミングが実態とずれていました。また JIRA のステータス更新タイミングにはメンバー間でばらつきがあり、着手日データの正確性にも課題があります。

AI がいくら賢くても、入力データがおかしければ出力もおかしくなります。ただし、こうした課題に対して複数のデータソースを連携していることが活きてきます。Tableau の数値に違和感があれば Git の初コミット日や JIRA の関連タスク作成日で検証できます。単一のツールでは解決できない問題を、ツール同士の組み合わせで補えるのはこの仕組みの強みです。

レトロの議論が変わった

AI が出したレポートをレトロスペクティブで共有したところ、データに基づいた議論ができるようになりました。「なんとなく速くなった気がする」ではなく「ストーリーの中央値が前月比で何パーセント短縮した」という話ができるのは大きな変化です。

実際にレトロで「長期連休や土日を含んでいるからノイズでは」という仮説が出ました。確認してみると GitHub データの Tableau ダッシュボードは土日祝と稼働時間外を除外する仕組みだったため、その仮説は棄却できました。こうしたデータに基づく仮説検証がレトロの場で自然と起きるようになったのは、レポート自動生成の効果だと感じています。

まとめ

今回の仕組みで AI が担っているのはデータ取得・集計・考察の下書きまでです。その先の施策検討やチームでの議論は人間にしかできません。ただ、分析の負荷が下がったおかげで、人間はその「考える時間」へ集中できるようになりました。

何を計測し、どう分析し、どう改善するか。この「型」を作ることに時間をかけた分、2 回目以降のレポート作成の負荷は大きく下がりました。もちろんコマンド一発で完成というわけではなく、出力されたレポートに対して「この数値の解釈は正しいか」「ここをもう少し深掘りできないか」とやり取りしながらブラッシュアップする工程は踏んでいます。ただ、そうした対話的な分析こそ AI エージェントを使う強みでもあると感じています。