今まで見えなかったものをAIの力で見る - Cybozu Inside Out

こんにちは、フロントエンドエンジニアのおぐえもん（@oguemon_com）です。

19世紀後半、エレベーターの安全性と速度が大きく高まり、人々はフロア間を労せず短時間で移動できるようになりました。これは単に利用者のフロア移動が楽になったという話で終わらず、果てしない高層階にも現実的な労力と時間で到達可能になったことが、結果として摩天楼の誕生に繋がりました。つまりエレベーターが新たな可能性を切り拓いたわけです。

生成AIによって今の仕事を省力化・高速化する話がよくあります。しかし、それだけでなく、生成AIによって今まで難しかったことが新たにできるようになる可能性に私はロマンを感じています。

私のチームにおける生成AI活用は、既存業務の代替だけなく「生成AIのおかげで新たにできそうなこと」にも着目しています。今回はそんな活用の事例の中でも、「今まで見えなかったものを見る」方向での事例を3つ紹介します。

① 日々の放置タスクを見る

私のチームは日々10〜15件程度のPull Request（PR）が生成されています。これだけの数があると、実は放置されているものを見過ごすことが少なくありません。日々の朝会でGitHub Projectのカンバンをチェックしているものの、現状に至ってからの経過時間まではすぐに分かりません。

そこで、1日2回、今あるPRを「放置されている順」に一覧して対応を促すSlack Botを用意しました。

ひとつのPRの情報を切り取ると次のようになります。ここに人力なら意外と手間な情報が詰め込まれています。

1. 🔴 〇〇を△△する #1234
    - by oguemon ｜ ±98 ｜ 最終コメから1.5h ｜ ⚽ 作者の対応待ち

「🔴」は、放置度合いを示すマークです。後述の放置時間数に応じて色分けされています。全てを緑🟢（4時間未満）で捌くのが目標です。
タイトルは、PRへのリンクになっています。これにより、PRにすぐ駆けつけられます。また、文字色の違いが二行目の各種情報との視覚的な区別に寄与しています。
±98は、単なる変更行数でなく、本体ファイルに絞った変更行数です。lockファイルやテストファイルは計算から除いています。注視すべき差分が実は少ないPRが早く拾われることを狙っています。
最終コメから1.5hは、最後の人間のアクションからの経過時間です。
- AIやCIによるコメントを除外して「人間が放置している時間」を出しています。
- ステータスによって起点（PR作成／最終コメント／Approve）を変えています。
- 夜間や土日祝はカウント外にしており、営業時間ベースで計算しています。
⚽ 作者の対応待ちは、誰に対応の責務（ボール）があるかを示します。最後の人間コメントを見て判断しています。

このBotのおかげで、あるPRの相対的な放置っぷりや正味の差分量など、今まで目に見えなかった情報が一気に可視化されました。

このBotは、次の3つを組み合わせて動いており、実は動作自体に生成AIは関与していません。

GitHub Actions
GitHub CLI (ghコマンド)
Slackbot

しかし、この実現には生成AIの存在が不可欠でした。

従来も、こうしたものは知恵と時間があれば作れました。しかし、現場には「できること」が「やること」に必ずしも直結しない現実があります。当時の私は1〜3の全てに疎く、何ができるか・どれだけ時間がかかるか分かりませんでした。そしてそもそもこれが本当に効果的か分からない…。そんなものは、他にもやることがたくさんある中で、限られた労働時間を何に使うか吟味する時に、選択肢から外れてしまうのが常でした。

生成AIは、技術スタックに関わらず高速かつ非同期的に提案や実装、テストまでの一連の開発を一挙に引き受けてくれるので、こうした課題を鮮やかに解決し、今まで優先順が落ちていたアイデアに挑戦の機会を与えてくれました。私が開発に際してやったことは、基本仕様を書き殴ったことと、生成AIが作ったものに対してUIと実装の調整を加えたことの2つだけ。生成AIによる検討や実装が多少甘くても、最も大変な工程である序盤の調査と根本的な実装が行われるだけで非常に大きな労力減でした。

このように、「手間暇かければできるができていない」ことが今までよりも少ない時間と行動力で実現可能になるのは、生成AIの素晴らしい魅力です。

② 週のタスク消化の傾向を見る

私のチームでは1週間の開発の終わりに「ふりかえり」の場を設けています。

そこには、その週のタスク消化の顛末をふりかえる時間もあります。ここでの話題のキッカケとして、その週に完了したタスクの所要時間や進行上の傾向などを生成AIに調査・分析したものを使っています。

やり方は簡単で、あると良さそうな情報をまとめたSkillを用意して、それを使って会の直前に生成AIを叩くだけです。

コツは、次の3点です。

機械的な情報取得処理は叩くコマンドを明示する
- 適切なコマンドを探す労力を削減
目的を生成AIに伝えて取るべき情報を提案してもらう
- 新たな知見をくれる
Skillをこまめに調整して常に磨く
- 使いながら不足を補う

3が意外と重要です。初期は「土曜日と日曜日は完了タスクがありませんでした」（←休みだから当たり前だろ！）みたいに、意外な観点で想定外のことを言ってくるので、最初から完璧を目指さず都度不足を補う姿勢が求められます。また、見ているメトリクスが目的と合ってないな…と思った時も、Skillの一文を変えて大胆に変えていきます。

それまでは、その週に完了したタスクをみんなで眺めて話題を探ってました。生成AIによる「叩き台」の登場により、話題をゼロから探る時間が省けた点と、話題に今まで以上に客観的な根拠が伴った点が良いところです。

もし生成AIがなければ、何らかの計測ツールを導入して監視するか、誰かに事前にタスクの一覧を読んで分析してもらう必要がありました。こうした労力なしに手軽に集計と分析ができるのは、まさに生成AIがもたらした新たな価値です。

③ 半年間の行動の変化を見る

今度はより大きな期間に対する利用です。

私は一部のチームメンバーのマネージャーもしています。半期毎の面談に先立ち、メンバーの活動や変化の一側面を捉えるための試みとして、上半期（当社では1〜6月）のPull Request上での動きを生成AIに集計・分析してもらいました。

これはそう頻繁にやるものでもないので、Skillにするまでもなくプロンプトを磨いて利用しました。

次のプロンプトは試行錯誤中に投げていたプロンプトの一つです。自分のことは自分が一番知っているはずという前提に立って自分自身の動きを分析してもらい、どれだけ妥当と考えられるか検証してから利用しました。

PRを集計して、人事的観点で評価して。

* 対象者は、oguemon
* 期間は、2026-01-31〜2026-06-30
* 対象PRは、次の通り
   * 対象者がAssigneeのPR
   * 対象者がレビューコメントしたPR
* 主な観点は、次の指標の期間中の変化
   * AssigneeになっているPRの個数
   * 同PRの規模（pnpm-lock.yamlなど機械的に生成される差分は除く）
   * 同PRの生成からマージまでの時間（日本の土日祝を除いて評価）
   * 同PR本文の説明やインラインコメントにおける補足の内容
   * 同PRに対して受けたレビューコメントの内容
   * 対象者が他のPRに対して投稿したレビューコメントの内容

ここでのポイントは、「人間がやるなら途方もないことをとにかくやってもらう」ということです。

例えば、「いくつのPRを作ったか」なんてものはPR一覧画面を見るだけで分かります。そんな単純な指標だけでなく、