古い計画を信じ続けず、変化した範囲を見直す
AI Work Governance｜仕事の関係 2/3 — 再評価
07「タスクのネットワークを可視化する」では、複数のIssueやPull Requestを、状態だけでなく仕事同士の関係まで含めて見る考え方を扱いました。
仕事を点、仕事同士の関係を線として表すと、「何が何を待っているか」「どの変更がどこへ影響するか」を共有しやすくなります。
ただし、この関係図には大きな弱点があります。
作った瞬間から古くなり始めることです。
最初に作った計画は、そのまま使い続けられない
たとえば、次の順序で仕事を進める計画を作ったとします。
A → B → C → D
ところがBを実装した結果、
- Cが不要になった
- 新しいIssue Eが見つかった
- Dの前提が変わった
- 別のPull Requestと競合した
- 新しいレビューが必要になった
A → B → C → D
│ ▲
├─→ E │
└──────┘
前提が変化
つまり、仕事を進める行為そのものが、仕事の構造を変えます。
最初に作った「正しい計画」を最後まで守ることが、正しいとは限りません。
完璧な計画より、再観測を重視する
最初に完璧な計画を作る
↓
最後までその通り実行する
のではなく、
現在状態を観測する
↓
判断する
↓
実行する
↓
結果を確認する
↓
関係する範囲をもう一度観測する
↓
判断を更新する
↺
重要なのは、実行したあとに結果の確認と再観測があることです。状態が変わったなら、古い判断をそのまま次の前提にしてはいけません。
「完了しました」は現在状態ではない
AIや作業実行者が「完了しました」と返したとしても、それだけで仕事の状態を更新してよいわけではありません。
実行したという報告
≠
期待した状態になったこと
たとえば「Pull Requestを修正しました」と言っていても、
- コミットがリモートへ送信されていない
- 別のブランチを変更していた
- CI（自動テスト等）が失敗している
- 古いコミットへのレビューしかない
- マージ条件を満たしていない
実行者の報告
↓
現在状態を確認
├─ 確認できた → 状態を更新
├─ 確認できない → 状態を維持・修正
└─ 判断不能 → 未確認として残す
AIの自己申告を、そのまま次のAIの前提にしない。これは作業を安全につなぐ基本条件です。
一つの状態変化が、周辺の仕事にも影響する
A ──妨げている──> B
Aが完了すれば、Bは実行候補になるかもしれません。
変更前 A: 作業中 │ └── B: 待機中 A完了後 A: 完了 B: 次の候補
さらにBがDとEの前提なら、
A ↓ B ├─→ D └─→ E
Aの変化はBだけでなく、DやEにも波及します。ここで必要なのは「全部を自動実行すること」ではありません。変化した仕事と、その影響を受ける範囲を再評価することです。
毎回すべてを読み直す必要もない
何か一件変わるたびに、リポジトリ全体を最初から読み直すのも非効率です。そこで、変化した場所から影響範囲を考えます。
重要な状態変化
↓
何が変わった？
↓
どの関係・判断に影響する？
↓
必要な情報だけ再確認
↓
影響範囲だけ再評価
考え方としては、必要な範囲だけ計算し直すということです。
状態が変わる
↓
影響する前提を無効化
↓
影響範囲を選ぶ
↓
現在情報を再確認
↓
判断を更新
├─ 重要な差分あり → もう一度評価
└─ 差分なし → ここで止める
「止まる」ことも正しい結果
人間の判断が必要 証拠が足りない 権限がない 関係を確定できない 対象範囲の外 実行能力が足りない
この場合、止まることは失敗ではありません。なぜ先へ進めないかを説明した状態で止まれることが重要です。
再評価 │ ├─ 実行できる → 作業候補 ├─ 人間判断が必要 → 人間へ返す ├─ 証拠不足 → 証拠待ち ├─ 権限不足 → 権限待ち └─ 変化なし → ここで収束
高性能なAIなら、どこまで仕組みが必要か
ここでは、高性能な大規模言語モデル（LLM）を使う場合を考えます。
現在のIssueやPull Requestを直接読ませ、現在状態から次の候補を考えさせる方法でも、複数の仕事をかなり扱えます。
2026年8月の限定的な内部比較でも、詳細な収束管理の仕組みを使わない直接推論で、主要な作業候補の多くを拾えました。
一方、毎回広い範囲を読み直せば、読み込み量、LLMへ渡す情報量、仕事の関係を組み立て直す負担、実行ごとの判断差が増えます。逆に、以前の判断を再利用しすぎると、古くなった前提や依存関係を抱えます。
だから本質的な問いは、特定の内部方式を使うかどうかではありません。どこまで以前の判断を再利用し、どこから現在状態を確認し直すのが最小十分か。ここを見極めることです。
実装検証から見えてきたこと
AI-WGを具体化する内部検証では、仕事同士の関係、待機状態、次に実行できる候補を、かなり詳細に追跡する方式も試してきました。
- 関係の見落としを減らす
- 待機中の仕事を見えるようにする
- 何を確認すべきか整理する
一方、現在の限定的な比較では、詳細な管理方式を使うことで、高性能なLLMの直接推論より明確に正しい結論へ到達できるとはまだ確認できていません。
詳しく管理するほど、読み込みや処理の量も増えます。そこで現在は、次のような軽い構成でも十分かを検証しています。
必要最小限の現在状態の観測
＋
最低限守るべき制約
＋
高性能なLLMによる推論
重要なのは、特定の内部システム名を覚えることではありません。何を仕組みとして固定し、何をLLMの推論へ任せると、少ない負担で安全に作業を続けられるかです。
重要なのは「古い判断を現在の事実にしない」こと
現在の情報
↓
観測
↓
判断
↓
実行
↓
結果確認
↓
状態が変わった？
↓
はい → 関係する範囲を再観測・再評価
仕事の関係図は、一度描いて終わる図ではありません。状態が変われば、その意味も変わります。
だから、関係図を持つことより、古い関係図や古い判断をそのまま信じないことの方が重要です。
次の記事では、再評価した仕事の関係を使って、人間やAIが「次に何をすべきか」の候補をどう絞るかを考えます。
前の記事： 07｜タスクのネットワークを可視化する（07公開後にリンク設定）
次の記事： 09｜仕事の関係から次の作業候補を絞る（公開後にリンク設定）
コメント