AIにリリース順序を判定させる：依存関係/Dry-Run実績/リスクで複数PRを並べる

「PR が10本溜まりました。どれから出しましょう?」を AI に判断させたい。しかし「とりあえず古い順」「とりあえず小さい順」では事故が起きます。

依存関係・Dry-Run 実績・リスク・タイミングの4軸で5分類のステータスを割り当て、AIに優先順位を判定させる仕組みを作りました。本記事はその情報スキーマと判定ロジックの公開です。

問題：複数 PR の優先順位は人間でも難しい

個人開発でも、PR が並行することは多いものです。

• バグ修正PR
• 新機能PR（バグ修正に依存）
• リファクタリングPR
• 緊急設定変更PR

これらをどの順序でリリースするか。判断軸が複数あり、頭でやると毎回30分溶けます。

1
ユーザー: PR 5本溜まった、どれから出す?
2
AI: ええと… 番号順でいいんじゃないですか?

このやり取りは無意味。AI に判断させるには、判定材料を構造化する必要があります。

5分類のステータス設計

各 PR を以下の5分類に割り当てます。

判定材料スキーマ

各 PR について、以下の情報を取得します。

1. 依存関係

• PR 本文に Depends on #NNN の記載があるか
• 依存先 PR が target ブランチに反映されているか

1
# AIが実行するコマンド例
2
gh pr view 138 --json body | jq -r '.body' | grep -E 'Depends on #'
3
git log pre --grep="(#117)" --oneline  # 依存先が pre に存在するか

2. Dry-Run 実績

• Pre 環境で動いているか（最低24h）
• 期待値どおりの動作ログが出ているか

1
ssh pre "journalctl --since '24 hours ago' | grep -c 'expected_pattern'"

3. リスク評価

• 変更行数（+100/-20 程度なら低、+500 以上は中以上）
• 変更ファイル数（1〜2 は低、5以上は中）
• 影響範囲（共通モジュールか単体機能か）

4. タイミング

• 平日昼の発火を伴うジョブか（業務影響）
• 月初・月末などのクリティカル時刻か
• 16:00 JST 発火の場合、その日中の本番投入は避ける

判定ロジック（AI 用プロンプト）

これらの情報を AI に渡し、5分類を判定させます。

1
## 入力情報
2
- PR#157: 変更50行、2ファイル、依存なし、Pre実績24h（誤検知ゼロ）
3
- PR#159: 変更30行、1ファイル、PR#157に依存、Pre実績未取得
4
- PR#160: 変更500行、10ファイル、リファクタ、Pre Dry-Run中（4/24発火予定）
5
- PR#161: 変更20行、1ファイル、設定変更のみ
6
- PR#162: 変更100行、3ファイル、依存PR#160
7

8
## 判定ルール
9
- 依存先が target に反映されていなければ → 見送り
10
- Pre で24h以上 Dry-Run 実績あり、誤検知ゼロ → 即リリース可
11
- 単純設定変更、依存なし → 限定変更
12
- Pre Dry-Run 中で効果観測前 → 待機推奨
13
- 大規模変更や影響範囲大 → 注意
14

15
## 出力フォーマット
2 collapsed lines
16
| PR | ステータス | 順序 | 理由 |
17
|----|----------|-----|------|

判定結果例

実際にこの仕組みで判定させた結果。

これで「まず #157 → #161 を出して、#159 は #157 が pre に行ってから、#160 は明日、#162 は #160 の次」という順序が一目でわかります。

順序判定の落とし穴

落とし穴1: cherry-pick の順序逆転

#157 → #159 の順で cherry-pick が必須なのに、逆順でやると衝突します。

1
PR#157: ファイル A の関数 foo を追加
2
PR#159: ファイル A の関数 foo を呼び出す
3

4
逆順だと:
5
1. PR#159 を cherry-pick → foo 未定義エラー

判定ルールに「依存先 PR が target に未反映なら、必ずそれを先に cherry-pick」を含めます。

落とし穴2: 平日昼の発火タイミング

データ処理パイプラインは決まった時刻に発火します。

1
16:00 JST 発火のジョブ:
2
- 16:00 直前に main 反映 → そのジョブは新コードで発火
3
- 16:00 直後に main 反映 → 翌日まで待機
4

5
→ 「直前リリース」は避ける（ロールバック不可になりやすい）

判定ルール:「ジョブ発火時刻の30分前〜直後はリリース禁止」

落とし穴3: pre 経由必須ルール

1
ルール: pre 未反映 → main 直行は禁止
2
理由: Dry-Run 検証なしの本番投入はリスク高

例外: 単純な設定変更（限定変更）のみ pre スキップ可。

skill 化：cherry-pick 計画立案を自動化

これらの判定ロジックを cherry-pick-planner という skill として実装しました。

1
ユーザー: 今日リリースできるPRを判定して
2
↓
3
skill 起動
4
↓
5
- gh pr list で open PR を取得
6
- 各 PR の依存・Pre実績・リスクを評価
7
- 5分類で判定
8
- 順序を提示

これで毎朝「今日出せる PR」が自動でリストアップされます。

教訓：判定材料の構造化が肝

「優先順位を判断する」を AI に頼むには、

• 判定材料を構造化（依存・実績・リスク・タイミング）
• 判定ルールを明文化（5分類・ルール表）
• 判定結果のフォーマットを統一（テーブル形式）

の3点セットが必要です。曖昧なまま「どれから?」と聞くと、AI は曖昧な答えしか返しません。

まとめ

• 複数 PR の優先順位判定を、依存・実績・リスク・タイミングの4軸で構造化
• 5分類ステータス（即リリース可 / 限定変更 / 待機推奨 / 見送り / 注意）
• 落とし穴: 順序逆転、発火タイミング、pre スキップ
• skill 化することで毎朝の判定を自動化

判定材料を構造化すれば、AIは熟練したリリースマネージャー並みの判断ができます。これは1人開発のスループットを大きく上げる仕組みです。