PMの「確認作業」はどこまでAI・gitに任せられるか 〜事実整理はAI、価値判断は人間〜

PMの仕事の多くは、実は「意思決定」そのものよりも「意思決定のための状況把握」に時間を取られています。

• 今スプリントで何が終わって、何が残っているのか
• どのPRが停滞していて、どこにリスクがあるのか
• 前回リリースから何が変わったのか、リリースノートに何を書くべきか

これらは本来、PMの本質的な価値である「判断」や「交渉」ではなく、その手前にある確認作業に過ぎません。しかし現実には、この確認作業がPMの時間の大きな割合を占めています。

近年のAIツール、特にGitHub Copilotのようなプラットフォーム統合型のAIは、この確認作業の一部を肩代わりできる可能性を持っています。本記事では、実際にどこまでのことが技術的に可能で、どこからは依然として人間の仕事として残るのかを、PM視点で整理してみます。

まず前提として、「AIがどこまでの情報を取り込めるか」を正しく理解しておく必要があります。ここを混同すると、期待値だけが先行して「AIに任せたのに思ったより浅い」という失望につながりかねません。

gitそのもの(ローカルリポジトリ)に含まれる情報は、あくまでバージョン管理システムとしてのデータに限られます。

• commit履歴(メッセージ、diff、作成者、日時)
• ブランチ・タグ、マージ履歴

一方で、PRの本文やレビューコメント、Issue、CI/Actionsの実行結果、Discussionsといった情報は、gitリポジトリの中身には含まれません。これらはGitHubというプラットフォームのデータベース側にある情報であり、GitHub APIやWeb UI経由でしか取得できません。

つまり「過去にマージされたPR」自体はマージコミットとしてgit履歴に残りますが、多くの場合、そのPRが何のために作られ、どんな議論を経て承認されたのかは、git履歴だけでは把握できず、GitHubのデータベースに保存された情報を別途参照する必要があります。もちろんConventional CommitsやIssue番号を必ずcommitメッセージに含める運用を徹底しているチームであれば、ある程度の文脈はgit履歴側にも残ります。ここでの整理は「git=文脈ゼロ、GitHub=文脈あり」という二分ではなく、あくまで運用次第で残る情報量が変わる、という程度に捉えてください。

この違いを踏まえた上で、GitHub Copilotのようなファーストパーティ製AIは、gitとGitHub両方の情報にシームレスにアクセスできる立場にあります。例えば執筆時点のCopilot Chatには、#issueや#pull-requestのような参照構文で特定のIssueやPRの文脈を会話に取り込む機能があり、Copilot coding agentのような機能は「Issue → 実装 → PR → レビュー対応」というサイクルの中でGitHub側の情報を継続的に参照します。外部ツールの場合はGitHub MCPサーバーなどを別途連携する必要があり、この点でCopilotは統合の深さという点で優位性があります。

※ただし上記のコマンド名・対応範囲はプロダクトのアップデートが速い領域であり、この記事を読むタイミングでは仕様が変わっている可能性があります。実際に使う際は公式ドキュメントで最新の挙動を確認してください。ここで伝えたいのは個々のコマンドの詳細ではなく、「ファーストパーティ製AIはgit/GitHub双方の情報に統合的にアクセスできる立場にある」という構造そのものです。

この技術的な前提を踏まえると、まず現実的に効果が見込めるのは「すでに確定した事実の整理」です。代表例がリリースノート作成です。

前回リリースタグと現在のブランチの差分(git log v1.2.0..mainやGitHubのCompare機能)を取れば、その間にマージされたPR・commitは機械的に特定できます。そのPRのタイトル・本文・ラベルをAPI経由で取得し、AIに自然文で要約させれば、リリースノートの叩き台が完成します。

ここで重要なのは、この作業が「予測」ではなく「整理」だという点です。リリースノート作成には次の4工程があります。

1. どのPRがこのリリースに入るか洗い出す
2. 各PRが何をしたのか読み解く
3. ユーザー影響のあるものとないもの(内部リファクタ等)を仕分ける
4. 非技術者にも伝わる言葉に翻訳する

1〜2は事実整理そのものです。3〜4は「どう仕分けるか」「どう翻訳するか」という判断が入る工程ですが、扱っている対象はあくまで確定済みの情報なので、AIに叩き台を作らせ、PMが最終チェックする形で十分に回せます。判断そのものがなくなるわけではなく、判断の材料(確定情報)がすでに揃っている分、AIの叩き台を土台に人間の判断を上乗せしやすい、という位置づけです。

一方で、まだマージされていない内容(openなPR、マイルストーン設定されたIssue)まで含めて「次はこれが出ます」と予測させるのは話が別です。それが実際に次のリリースに間に合うか、途中でスコープアウトするかは人間の意思決定次第であり、AIは今この時点でのスナップショットしか見せられません。「予測」ではなく「今このタイミングでの進捗の可視化」と捉えるのが実態に近いでしょう。

もう一つ、PMにとって効果が大きいのが、進捗管理、特にQCD(品質・コスト・納期)における「D(Delivery/納期)」の管理です。

従来のPMの進捗確認は、基本的に申告ベースで成り立っています。朝会での口頭報告、タスク管理ツール上のステータス更新——これらはすべて、エンジニア自身が「進んでいる」「詰まっている」と自覚し、申告して初めてPMの目に触れます。逆に言えば、本人が「まだ大丈夫」と思い込んでいたり、報告するほどでもないと判断している遅延の芽は、申告ベースの管理では見えないまま進んでしまいます。

git/GitHub上の活動ログは、この申告を介さない一次情報です。

• PRが作成されてから最初のcommitまでの間隔(着手の遅れ)
• commitの頻度の急な低下(詰まっている、あるいは優先度が下がっている兆候)
• draft PRのまま長期間放置(完成の目処が立っていない)
• レビュー指摘への再pushがない(対応に迷っている可能性)

これらは、本人が「大丈夫です」と申告していても、行動ログとしては矛盾したシグナルを出していることがあります。そのギャップをAIが拾い、PMに提示できます。

ここで注意したいのは、これらのシグナルはあくまで仮説であって、結論ではないという点です。commit頻度が下がる原因は「詰まっている」以外にも、他タスクを優先している、休暇を取っている、あえて設計検討のために一旦寝かせている、レビュー待ちで本人としてはやることがない、など多岐にわたります(どの要因が多いかはチームやプロジェクトの性質によっても変わります)。AIが拾い上げたシグナルをそのまま「遅延」と断定するのではなく、「気になる兆候がある」という一次情報として受け取り、必ず本人に直接確認してから動く——このプロセスを踏むかどうかが、この後の話の分かれ目になります。

シグナルを本人確認なしに使ってしまうと、これは簡単に「詰める」ためのツールに転じます。同じデータを見ていても、目的とタイミングが違えば、まったく別のマネジメントになるということです。

「AIが開発ログを監視する」と聞くと、エンジニアは反射的に「評価に使われるのでは」という警戒心を持ちやすいものです。だからこそ、個人の評価データとしてではなくプロジェクト全体のリスク管理データとして使うこと、「誰が遅いか」ではなく「どこにボトルネックが生まれやすいか」という構造の可視化に使うこと——この運用スタンスを明示しておく必要があります。エンジニア自身も気づいていない詰まりを、PMが早めにキャッチしてサポートに回れる。これが目指すべき使い方です。

ここまで見てきた事例——リリースノートの叩き台作成、進捗の停滞検知——には共通する構造があります。それは「事実の集計・整理はAIに任せられるが、それをどう判断し、誰にどう伝えるかは人間の仕事として残る」ということです。

• リリースノートで言えば、「何がマージされたか」の整理はAI、「これをどう発表すべきか」のトーンや優先度判断はPM
• 進捗管理で言えば、「どこにリスクの兆候があるか」の検知はAI、「それをどう受け止め、どう支援するか」の判断と対話はPM

AIとgit/GitHubの組み合わせは、PMの時間を「状況把握」から「判断と対話」へとシフトさせる可能性を持っています。ただしそれは、確認作業を丸ごとAIに委譲することではなく、確認作業の中の「事実整理」部分を委譲し、PM自身は本来の価値である判断と対話に時間を使う、という再配分として捉えるべきでしょう。