cherry-pick前の3値判定：GO/NO-GO/CONDITIONALで「待ち続ける運用麻痺」を抜ける

stage1 → stage2 → main のような段階デプロイで cherry-pick を繰り返していると、ある日こうなります。

着手前チェック3件のうち、2件が「未完」になっています。どうしますか?

ここで「全部OKになるまで待ちます」と答えると、運用が永遠に止まります。なぜなら別の作業がさらに前提条件を増やすので、チェックリストはどんどん長くなるからです。

本記事は、cherry-pick 前 precondition を GO / NO-GO / CONDITIONAL の3値判定に変える運用ルールの記録です。これは GitFlow に限らず、Feature Flag、blue-green、Canary など 段階デプロイ全般に応用できる意思決定パターンです。

事の発端：「前提条件3件中2件が未完」

ある日、stage1（pre 環境）への cherry-pick 作業中、Claude Code が事前チェックリストを出してきました。

1
着手前チェック:
2
  [✓] PR #266 develop マージ完了
3
  [✗] PR #297 main マージ完了: 未完
4
  [✗] PR #266 Day1 観察: FAIL（KPI 集計異常）

最初の反応は「2件 NG なら待ちだな」でした。しかし、**この2件はそれぞれ別の意味で「待っても解決しない」**ことに気づきました。

Case A: #297 main マージ完了 → 待っていれば終わる

これは別 PR の進行待ちです。順番に処理すれば、いずれ完了します。

Case B: #266 Day1 FAIL → 待っても自然回復しない

こちらは failed。原因を調査してパッチを当てない限り、永遠に green にならない項目です。「待つ」という選択肢が成立しません。

つまり、2件の NG は意味が違うのに、チェックリスト上は同じ [✗] で並んでいました。これが運用麻痺の正体です。

2値判定が破綻するパターン

「全項目OK」を待つ運用は、以下の状況で破綻します。

1. 「ブロッカー」と「リスク」の混同

ブロッカー: 解消しないと物理的に作業できない（依存先のコード未マージなど）
リスク: 作業はできるが、失敗確率が上がる（前 PR の観察期間が短い、など）

これを同じ [✗] で扱うと、リスクをブロッカーに昇格させてしまい、待ちが永遠に発生します。

2. 待っている間に増える前提条件

A の完了を待っている間に、別作業 B が走り、B が新しい前提条件 C を増やします。チェックリストは時間とともに長くなるので、「全項目OK」は構造的に到達不能です。

3. リスク許容度の言語化されていない暗黙判断

実際の現場では、ベテランが暗黙に「これは無視していい」と判断して進めています。しかしその判断基準は言語化されていないので、Claude Code に委譲しようとすると「全部 OK 待ち」モードになり、結果として人間より遅くなります。

3値判定：GO / NO-GO / CONDITIONAL

そこで、precondition の評価軸を 3つの状態 に分けました。

GO（実行可）

すべての絶対的依存（コードマージ、必須デプロイ）が完了。実行して問題ない。

NO-GO（実行不可）

絶対的依存が未完。物理的に進めない。待ち or 依存タスクを先に潰す。

CONDITIONAL（観察付き実行）

絶対依存は揃っているが、リスク項目が残っている。実行はするが、観察ゲートを設けて即座にロールバック可能にする。

状態	絶対依存	リスク項目	行動
GO	OK	OK	通常実行
NO-GO	NG	-	待ち or 依存解消
CONDITIONAL	OK	NG（許容可能）	実行 + 観察強化

CONDITIONAL の判定基準：リスク許容度 × 復帰コスト

CONDITIONAL を乱発すると意味がないので、判定式を決めました。

1
CONDITIONAL 可否 = リスク影響範囲(小) × 復帰コスト(低) × 観察可能性(高)

3つすべてが揃わないと CONDITIONAL にできません。

リスク影響範囲（小）

失敗してもダメージが局所的か。本番ユーザーに直接見える機能なら原則 NO-GO、内部集計ジョブなら CONDITIONAL 候補。

復帰コスト（低）

失敗時の roll back が秒〜分単位で可能か。設定変更やフラグ切り替えで戻せるなら CONDITIONAL 可。スキーマ変更を伴うものは戻せないので NO-GO。

観察可能性（高）

失敗を検知できる仕組みがあるか。ログを見ないと壊れていることに気づかない作業は CONDITIONAL にしてはいけない。メトリクスダッシュボード、アラート、Slack 通知のいずれかが揃っていれば可。

冒頭ケースに当てはめる

最初のチェックリスト2件を3値判定で評価し直すと、こうなります。

1
[✗] PR #297 main マージ完了: 未完
2
  → 絶対依存ではない（stage1作業は #297 と独立）
3
  → CONDITIONAL: 観察強化して進める
4

5
[✗] PR #266 Day1 観察: FAIL
6
  → リスク項目だが、stage1での影響は局所的
7
  → 復帰コスト: フラグで即停止可能 → 低
8
  → 観察可能性: 既存ダッシュボードあり → 高
9
  → CONDITIONAL 可

結果、両方とも CONDITIONAL で進められると判定。観察強化（30分後 / 2時間後 / 翌朝の3チェックポイント追加）を条件に実行しました。

Claude Code に judgement を委譲するときの書き方

このルールを Claude Code に委譲するときは、CLAUDE.md やスキル定義に 3値判定のロジックと許容基準を明示します。

1
## cherry-pick 前 precondition 判定
2

3
各チェック項目を以下の3値で評価する:
4

5
- GO: 絶対依存もリスクも問題なし → 通常実行
6
- NO-GO: 絶対依存が未完 → 待ち
7
- CONDITIONAL: 絶対依存OK + リスク項目あり、ただし以下を全て満たす:
8
  - 影響範囲が局所的（本番ユーザー直接影響なし）
9
  - 復帰コストが低い（フラグ/設定で即停止可能）
10
  - 観察手段がある（ダッシュボード or アラート）
11

12
CONDITIONAL の場合は観察チェックポイント（30min/2h/翌朝）を明記すること。

これを書いておくと、Claude Code が「2件NGなので待ちます」ではなく、「2件NGですが両方とも CONDITIONAL に該当、観察強化案を提示します」 と返してくるようになります。

応用：他の段階デプロイにも効く

3値判定は cherry-pick 以外にも適用できます。

Feature Flag のロールアウト

GO: 全 metrics 緑
NO-GO: dependency service ダウン中
CONDITIONAL: 一部メトリクスが yellow（許容範囲）→ canary 5% で開始、観察強化

blue-green デプロイの切り替え

GO: blue 環境 health check 全通過
NO-GO: blue で critical error
CONDITIONAL: warning レベルのエラーあり → 切り替え後 30 分監視強化

ライブラリのメジャーバージョン更新

GO: 全テストパス、依存ライブラリ互換性OK
NO-GO: breaking change が未対応
CONDITIONAL: deprecation warning あり → 移行期限を Issue 化して進める

まとめ：「待つか / 進めるか」を「観察するか」で割る

段階デプロイの precondition チェックを2値（GO / 待ち）にしていると、運用は確実に詰まります。前提条件は時間とともに増えるからです。

CONDITIONAL（観察付き実行）を第3の選択肢として導入することで、

リスクを言語化 できる（影響範囲・復帰コスト・観察可能性）
AI agent に判断を委譲 できる（基準が明確なため）
「待ち続ける運用麻痺」を防げる

ポイントは、CONDITIONAL は「リスクを無視する」ことではなく、「リスクを観察で買い取る」 という発想転換です。観察コストを払うことで実行権を得ます。

AI 駆動開発で意思決定を委譲する時代には、「待つ」「進む」の2軸ではなく、「観察して進む」という第3の軸を持っておくと、運用が止まりません。