06 | AIの仕事をどう収束させるか

2026年8月16日2026年8月17日

一つの仕事を閉じ、複数の仕事を関係・検証・再評価で収束させる

AI Work Governance｜基礎 6/6 — 仕事を収束させる

ここまでの記事では、AIとの仕事を会話の外へ残し、正しい情報の読み方、依頼から実作業への変換、権限と品質確認を扱ってきました。

一つの仕事なら、対象を決め、変更し、結果を確認して閉じることができます。ところがIssueやPull Requestが複数同時に動き始めると、問題が変わります。

Aを先に進めるべきか
BとCは並行できるか
Dは本当に後続を止めているか
どの作業を終えると複数の仕事が動くか
人間の判断を待っているのはどこか
古い前提をまだ信じていないか

このとき必要になるのが、一つ一つを終わらせることだけでなく、仕事の集まり全体を収束させることです。

単体では閉じる。複数では関係を見て収束させる。実行したら確認し、状態が変わったら判断も更新する。

まず、一つの仕事を閉じる

解きたい問題・得たい結果
      ↓
Issue
      ↓
必要なら設計判断
      ↓
具体的な変更
      ↓
結果の確認・レビュー
      ↓
目的を満たしたか確認

Issueは「何を解く仕事なのか」を残す

何が問題か
何を達成したいか
どこまでが対象か
何をもって終わりと判断するか

AIの一回の会話が終わっても、仕事そのものは残ります。

Pull Requestは具体的な変更を確認する

Issue
  = 何を解く仕事か

Pull Request
  = 実際に何を変え、何で確認したか

この二つを混ぜると、「Pull RequestがマージされたからIssueの目的も達成したはず」という誤解が起きます。マージは変更が統合されたことを意味します。目的まで達成したかは別に確認します。

設計判断は、必要なときだけ分ける

何を作るべきか曖昧
権限や責務の境界が変わる
複数の実装へ影響する
戻すコストが高い
複数の正当な選択肢がある
実装前に人間の判断を固定する価値が高い

必要な複雑性は入れる。不要な工程は増やさない。

工程を増やすこと自体が統治ではありません。

途中で必要なのは「何度も回すこと」ではなく、結果を見ること

期待した状態
      ↓
実行する
      ↓
実際の状態を確認する
      ↓
差があるか比べる
      ↓
原因に関係する範囲だけ直す
      ↓
もう一度確認する

AIが「直しました」と言った
        ≠
期待した状態になった

レビュー結果が出た
        ≠
人間が受け入れた
        ≠
変更してよい権限を得た
        ≠
マージしてよい

作る、確認する、受け入れる、実際に変更する、という責務を分けます。

タスクが複数になると、一覧だけでは足りない

何が何を待っているか
どの変更が後続を止めているか
どれは並行して進められるか
どの判断を人間へ返す必要があるか
何を進めると複数の仕事が動くか

ここで見るべきなのはタスクの番号だけではありません。仕事同士の関係と、現在の状態です。

Issue A ──先に必要──> Issue B
    │
    └──関連──> Pull Request C

Issue D ──人間判断待ち
Issue E ──独立して進行可能

関係が見えると、次に検討すべき候補を絞りやすくなります。ただし、関係図が自動的に答えを決めるわけではありません。

目的が違えば、次の一手も変わる

今回の目的	注目しやすい仕事
早く統合可能な変更を増やしたい	独立して準備ができているPull Request
後続作業を解放したい	複数の仕事を止めている共通の前提
手戻りを減らしたい	複数作業に共通する未確定の設計判断
リスクを下げたい	レビュー・検証・根拠の不足
並列に進めたい	互いに干渉しない仕事
人間判断を減らしたい	まとめて判断できる論点

「優先順位は常に一つ」という前提を置かないことが重要です。今の目的に対し、どの状態変化が最も次の仕事を動かすかを考えます。

「重要」と「今実行できる」と「やってよい」は別

重要である
      ≠
今実行できる
      ≠
今回実行してよい

重要なIssueでも、前提が未完了なら今は実行できません。実行可能なPull Requestでも、人間承認が必要なら勝手にマージできません。AIの提案が操作権限になるわけでもありません。

状態が変わったら、古い計画をそのまま使わない

Aが完了
  ↓
Bの待機理由が消える
  ↓
CとDの前提も変わる

現在状態を確認する
      ↓
次の候補を考える
      ↓
許可された作業を実行する
      ↓
結果を確認する
      ↓
変化した範囲の現在情報を取り直す
      ↓
必要なら次の候補を更新する

毎回リポジトリ全体をゼロから読む必要はありません。状態が変わった場所と、その影響を受ける範囲を見直すことが重要です。

正しく止まることも、収束の一部

人間の判断が必要
必要な根拠が足りない
操作権限がない
関係を確定できない
外部の作業を待っている
今回の対象範囲の外

このとき、勝手に先へ進むより、なぜ止まっているかを明示して人間へ返す方が正しい場合があります。

詳細な収束管理は、どこまで必要か

AI-WGを具体化する内部検証では、複数の仕事の関係、待機状態、次に実行できる候補を細かく追跡する方式も試してきました。

関係を広く見つけやすい
待機状態を一覧化しやすい
人間が仕事全体を見渡しやすい

一方、2026年8月の限定的な内部比較では、詳細な方式を使わなくても、高性能な大規模言語モデル（LLM）の直接推論で主要な作業候補をかなり拾えました。

詳細な方式は構造を広く見せる一方で、読み込みやツール呼び出しも増えました。固有の方式が次手の正しさを明確に改善する、という優位はまだ確立していません。

仕事同士の関係を見えるようにする
      ＋
現在状態を確認する
      ＋
最低限守るべき権限と根拠を固定する
      ＋
高性能なLLMに推論させる

どこまでを仕組みとして固定し、どこまでをLLMの推論へ任せるのが最小十分かは、引き続き検証対象です。

一枚で見る、仕事を収束させる流れ

人間の目的
      ↓
一つ一つの仕事を定義する
      ↓
仕事同士の関係を確認する
      ↓
現在状態と妨げを確認する
      ↓
次に検討する候補を絞る
      ↓
権限を確認する
      ↓
許可された作業を実行する
      ↓
結果を確認する
      ↓
状態が変わった範囲を再評価する
      ↓
完了 / 待機 / 人間判断 / 次の候補