AI による大規模開発では、未確定な状態を一件ずつ閉じる

by

AI コーディングエージェントへ一件の不具合修正を任せる場合、管理する状態は比較的少ない。対象を調査し、原因を特定し、コードを変更し、テスト結果と差分を確認する。途中で追加の問題が見つからなければ、依頼から確認までを一つの作業として追跡できる。人間が把握しなければならないのも、主として「何を直したか」と「直ったことを何で確認したか」で済む。

開発が数十件、数百件の変更へ広がると、この前提が崩れる。ある変更はコードまで完成しているが実環境では未確認であり、別の変更はその結果を前提として待機し、さらに別の調査では予定になかった問題が見つかる。仕様の回答待ち、権限不足、既存データとの互換性確認、外部サービスでの検証など、コードを書くだけでは解消できない状態も混ざる。変更件数が増えるだけでなく、それぞれが異なる確定度を持ったまま相互に依存するようになる。

このとき、AI がどれだけ長く作業できるかだけを改善しても、中～大規模開発を安定して任せられるとは限らない。未確認の変更を含んだ状態から後続作業を始めれば、後で前提が崩れたときに、その変更を利用した作業まで再検証しなければならない。AI の実装速度が上がれば、確定していない変更を作る速度も同時に上がる。長期開発で必要になるのは、生成した変更を増やすことではなく、途中成果をどこまで後続作業の前提として利用してよいかを判定する仕組みである。

本稿では、後続作業の前提としてまだ利用できない途中成果を「未確定な状態」と呼ぶ。未確定とは、誤っているという意味ではない。コードが存在していても、必要なテストが終わっていない、実環境でしか確認できない条件が残っている、仕様判断が確定していない、といった理由によって、その成果を確定済みの前提として扱えない状態を指す。反対に「確定」とは完全無欠であることではなく、あらかじめ定めた完了条件について必要な検証が終わり、後続作業に影響する未確認事項が残っていない状態である。適用範囲や既知の留保がある場合は、それ自体が明示されている必要がある。

この定義から、タスクの意味も変わる。タスクは作業量を数える単位でも、AI へ一回で渡せる文章量の単位でもない。未確定な状態について、何を成立させるのか、どこまで変更してよいのか、何を確認すれば終了なのかを定め、その結果を後続作業が利用できる確定状態へ変えるための単位である。

AI に中～大規模開発を任せる能力とは、大きな仕事を一度に処理させる能力ではない。開発中に生じる未確定な状態を、判断可能で検証可能な単位へ変換し、一件ずつ確定状態へ移し、その結果を次の作業へ渡し続ける能力である。この見方を採ると、タスク分割、進行中作業の制限、状態の記録、テスト、Git、停止条件といった個別の運用を、「未確定な状態をどう閉じるか」という一つの問題として説明できる。

1. 中～大規模開発で増えるのは、作業量より未確定な状態である

小さな修正と中～大規模開発の違いは、変更するコードの行数だけでは決まらない。一件の不具合修正でも、原因を追うために複数のファイルを読み、既存テストを確認し、新しいテストを追加し、実際にプログラムを動かすことがある。SWE-bench は実在する GitHub の課題を基に、リポジトリ内のコードと実行環境を扱いながら問題を解決する能力を評価している[1]。つまり、一件の課題であっても、作業そのものは複数の場所と工程へ広がり得る。

中～大規模開発では、その広がりが時間方向にも連結する。ある変更で追加した API を次の変更が利用し、その API を前提として画面側を実装し、さらに後続の試験で最初の設計上の問題が見つかる、といった関係が生じる。前段階の成果が後段階の入力になるため、一件の変更を単独で正しく実装するだけでは足りない。前段階をどの時点で「確定した」とみなすかが、後続作業の正しさに直接影響する。

SWE-EVO は、単発の課題ではなく、複数段階にわたってコードベースを発展させる長期的な変更を評価している。そこでは、多数のファイルを変更しながら既存機能との整合を維持し、前段階の変更を踏まえて後続の変更を続けなければならない。単発課題と比べて成績が大きく低下することも報告されている[2]。長期化によって増えるのは入力すべきコード量だけではなく、以前の変更を正しい前提として保持し続ける必要である。

AI が成功できるタスクの長さを、人間が同じ作業を完了するために要する時間と対応付けた研究でも、作業時間が長くなるほど成功率が低下する関係が調べられている[3]。この結果から、長い作業そのものが失敗原因だと断定することはできない。しかし、作業時間が伸びれば、途中の観測結果に応じて計画を修正し、前に行った変更との整合を保ち、失敗した場合には原因となった地点まで戻る機会も増える。長期作業では、一回の推論能力だけでなく、途中状態を維持して次の判断へ接続する能力が必要になる。

実際の開発者と AI エージェントの協働を観察した研究でも、問題全体を一度に解かせる進め方より、課題を段階的に進め、途中の出力を確認しながら反復した参加者の方が成功しやすかった[4]。この観察だけから特定のタスク管理方式を導くことはできないが、少なくとも開始時点で仕事全体を指示したことと、実行中に得られた結果を後続判断へ反映できることは別の条件だと分かる。

たとえば認証方式を変更する開発を考える。第一段階で新しい認証情報を保存できるようにし、第二段階でログイン処理を切り替え、第三段階で既存セッションとの互換性を確認するとする。第一段階のコードが完成し、単体テストも通ったとしても、既存データを読み込んだときの挙動が未確認なら、その成果にはまだ利用条件が残っている。

この状態で第二段階を開始すると、後続のログイン処理は「新しい認証情報は既存データでも正しく扱える」という未確認の前提へ依存する。第三段階で互換性問題が見つかれば、第一段階だけを直せば済むとは限らない。第二段階で追加した処理が誤った前提を組み込んでいれば、そこも再検証しなければならない。未確定な成果を一件先へ渡しただけでも、その成果を利用する変更が増えるほど修正範囲は後方へ拡大する。

状態 その時点で確認できていること 残っている条件 後続作業が前提にした場合の危険
実装済み 要求を満たすためのコード変更は存在している。 期待する挙動が成立するか、既存機能を壊していないかは別途確認する必要がある。 実装上の誤りや不足した条件を、後続作業が正しい仕様として利用する可能性がある。
ローカル検証済み 開発環境で再現できる入力と期待結果については確認が終わっている。 外部サービス、権限、ネットワーク、本番相当の設定など、ローカル環境では再現できない条件が残る場合がある。 環境固有の問題が後から判明し、その成果を利用した変更まで再確認する必要が生じる。
仕様判断待ち 技術的に実現可能な選択肢と、それぞれの影響までは確認できている。 どの挙動を正式な仕様として採用するかが決まっていない。 AI が一案を選んで続行すると、実装方法ではなく外部仕様や業務上の判断まで暗黙に決定することになる。
確定済み 定めた完了条件に対応する検証が終わり、その結果を確認できる。 後続作業に影響する未確認事項は残っていない。適用範囲や既知の留保がある場合は、それ自体が明示されている。 明示された条件の範囲で、後続作業が確定済みの前提として利用できる。

この表で区別しているのは、作業工程の名称ではなく、後続作業がどこまで前提としてよいかである。「実装済み」と「ローカル検証済み」は、どちらもコードが存在する点では同じだが、確認済みの範囲が異なる。「仕様判断待ち」はコード量とは無関係であり、実装候補が完成していても確定できない場合がある。中～大規模開発では、この異なる確定度を一つの「進行中」へまとめると、依存する側が何を信頼してよいか分からなくなる。

長いプロンプトは、この問題を直接解決しない。開始時点で仕様、禁止事項、作業手順を詳しく記述することはできるが、その後にテストで発見された不具合、既存データとの矛盾、追加で必要になった権限、外部サービスの実際の挙動までは事前に確定できない。実行によって新しい事実が得られる以上、開始時の指示とは別に、現在どこまで確定したかを書き換え続ける必要がある。

ここには二段階の増加がある。最初に、開発規模が広がることで未確定な途中成果の数が増える。次に、その途中成果を別の作業が利用することで依存関係が増え、一件の未確定状態が複数の後続変更へ影響するようになる。作業量が二倍になったから管理負荷も二倍になるとは限らない。未確定な状態同士が接続されるほど、後から一つの前提を修正したときに確認し直す範囲も広がる。

中～大規模開発で管理すべきなのは、この未確定状態と依存関係である。AI がコードを生成する速度だけを高めても、確定していない変更が同じ速度で蓄積すれば、プロジェクトとして利用できる成果は増えない。後続作業へ渡す前に、どの条件まで成立したかを判定できる境界を作る必要がある。次に決めるべきなのは、仕事をどこまで細かくするかではなく、どの位置なら一件の成果を独立して確定できるかである。この考えは AI コーディングだけに突然現れたものではなく、作業量より不確実性と意思決定を管理するという上流工程の問題と連続している。まず、その共通構造と、AI が加わることで変わる部分を切り分ける。

2. 上流工程の不確実性管理は、AI 開発の未確定状態へつながる

本稿で扱う「未確定な状態」は、AI コーディングだけに固有の問題として考え始めたものではない。既稿「上流工程を管理する三層・反復型マネジメント」では、要求や解決方法がまだ固まっていない上流工程へ、作業量、工数、期限、進捗率を中心とする管理をそのまま持ち込むと、管理表は細かくなっても、何が分かっていないのか、誰の判断を待っているのか、どの前提が後続を止めているのかが見えなくなることを扱った[5]。そこで管理対象を、作業の消化量ではなく、不確実性、意思決定、依存関係、後続工程への着手可能性へ移した。

この問題設定は、第 1 章で見た中～大規模な AI 開発とよく似ている。上流工程では、調査を始める前に作業総量を完全には決められない。現場を調べれば新しい制約や関係者が見つかり、選択肢を比較すれば当初の問題設定そのものが変わることがある。AI コーディングでも、実装を始めた後に既存データとの非互換、外部サービス固有の挙動、権限不足、隠れた API 依存、仕様同士の矛盾が見つかる。どちらも、最初に作った作業一覧を消化すれば終わる仕事ではなく、行動によって新しい事実が得られ、その事実が次の行動条件を書き換える。

既稿では、上流工程の目的を「未知をゼロにすること」には置かなかった。完全な情報を集め終えるまで待つのではなく、残る未知を把握し、次の行動や判断を選べるところまで状態を変えることを重視した[5]。本稿の「確定」も同じ考え方を引き継いでいる。確定とは、コードや仕様について将来の不具合が一切存在しないと証明することではない。現在の完了条件に必要な検証が終わり、後続作業の前提を壊す未確認事項が残っていないと判定できる状態へ移すことである。

ただし、上流工程の「判断可能な状態」と、AI コーディングの「確定状態」は同じ言葉へ置き換えれば済むものではない。上流工程では、調査結果や選択肢が判断者へ渡せる状態になれば、その検討は次の意思決定へ進める。コードでは、判断が済んでいても実装、テスト、既存機能との整合、実環境での確認が残る場合がある。人間が方針を決めたことと、その方針がソフトウェアとして成立したことの間に、実装と検証という追加の状態遷移が存在する。

管理上の観点 上流工程で現れる状態 AI コーディングで現れる状態 共通する判定軸
管理対象 不明な事実、未決定の方針、関係者間の解釈差、残存リスクを扱う。 未検証の差分、仕様矛盾、環境依存条件、既存機能との互換性を扱う。 作業をどれだけ消化したかではなく、次へ渡せない条件が何かを見る。
終了条件 次の判断や工程へ進めるだけの情報と合意がそろったかを確認する。 完了条件に対応する変更と検証がそろい、後続作業が前提として利用できるかを確認する。 成果物が存在することではなく、後続へ渡せる状態になったことを終了の基準にする。
依存関係 情報、判断、権限、資源、制度、相互調整の依存によって次の検討が止まる。 先行 API、データ構造、権限、検証環境、仕様判断、共有資源への依存によって次の実装や検証が止まる。 時間順序ではなく、何が確定すれば何を開始できるかを追う。
状態管理 探索中、判断材料準備済み、判断待ち、決定済み、後続反映済みなどを区別する。 調査中、実装中、ローカル検証済み、実環境検証待ち、仕様判断待ち、完了などを区別する。 進捗率ではなく、現在状態と次の遷移条件を記録する。
計画変更 新しい事実や判断によって、問い、依存関係、移行条件を更新する。 実装や検証で得た事実によって、タスク境界、完了条件、依存関係を更新する。 開始時の計画へ現実を合わせず、現実から得た情報を計画へ戻す。

依存関係についても、既稿との連続性がある。上流工程では、先行調査の結果を必要とする情報依存、方針決定を待つ判断依存、権限者の承認を必要とする権限依存、同じ専門家や環境を取り合う資源依存、法令や契約に左右される制度依存、複数の検討を往復させる相互調整を区別した[5]。AI コーディングでも、「前のタスクが終わるまで待つ」という一本の順序だけでは足りない。API の入出力が確定しなければ呼び出し側を書けない、仕様判断が終わらなければ期待結果を固定できない、本番相当の権限がなければ検証できない、共有環境が一つしかなければ並列試験できない、といった異なる停止理由がある。

この区別は、後の並列化にも関係する。二つの作業が別々の担当者や別々の作業空間へ割り当てられていても、同じ判断、同じ API 契約、同じ検証環境へ依存していれば、論理的には独立していない。上流工程で「どの成果がどの判断を可能にするか」を追ったのと同じように、AI 開発でも「どの確定状態がどの後続タスクを開始可能にするか」を追う必要がある。

既稿では、検討単位に問い、入力、活動、成果、判断者、終了条件、前提、未解決事項、後続、状態を持たせた[5]。これは本稿で後に定義するタスクとよく似ている。ただし、その項目をそのまま AI コーディングへ移植することが目的ではない。上流工程の検討単位は、何を明らかにし、誰が判断し、その判断をどこへ反映するかを閉じるための単位である。AI コーディングのタスクは、要求された挙動を実装し、必要な証拠をそろえ、後続作業が利用できる状態まで閉じるための単位になる。

状態を外部へ戻す考え方にも連続性がある。既稿の三層・反復型マネジメントでは、調査や会議で得た事実と決定を、その場の記録だけへ残さず、検討の依存関係やフェーズの移行条件へ戻す[5]。本稿では、この考えを AI 開発の現在状態へ進め、複数の記録が食い違った場合に参照する一つの正本を定める。AI 開発で会話の外に現在状態を残す必要があるのも、同じ理由である。セッションで得た情報を会話の履歴に閉じ込めず、次の実行主体が現在値として利用できる形へ戻さなければならない。

一方、AI が加わることで新しく強くなる問題もある。上流工程で未決定の条件が残れば、会議や資料が止まり、判断待ちとして表面化することが多い。AI コーディングエージェントは、条件が曖昧でも技術的にもっともらしい案を選んで実装を続けられる場合がある。その差分が局所的なテストを通れば、未決定だった前提が「既に実装されている挙動」として後続タスクへ渡る可能性がある。AI の実行能力は、調査や実装によって不確実性を減らす一方で、未確定な判断を成果物へ固定し、それを広い範囲へ伝播させる速度も上げる。

ここが、既稿の上流工程管理から本稿へ進む理由である。上流工程では、不確実性を判断可能な状態へ変え、その判断を後続へ反映することが管理の中心だった。AI コーディングでは、それに加えて、判断を実装へ変え、実装を検証し、後続が前提として利用できる確定状態まで閉じる必要がある。管理対象は作業量から状態へ移ったままだが、状態遷移の途中にコード生成と検証が加わり、しかもその生成速度が人間中心の開発より大きくなり得る。

この連続性を踏まえると、本稿のタスクは単なる作業分解ではない。上流工程で一つの検討を「次の判断が可能になる状態」まで進めたのと同じように、AI 開発では一つの変更を「次の実装が確定済みの前提として利用できる状態」まで進める。その境界を、コード量ではなく観察可能な結果から定義する必要がある。

3. タスクとは、未確定状態を確定状態へ変える単位である

未確定状態を管理するには、最初に「どこまでを一件として確定させるか」を決めなければならない。前章で見た上流工程の検討単位を AI コーディングへ具体化すると、この境界は「何を調べるか」だけでなく、「どの変更と検証まで終われば後続へ渡せるか」まで含む。「認証機能を完成させる」「管理画面を作る」といった要求は、開発目標としては理解できるが、そのまま一つのタスクにすると完了条件が分散する。認証機能であれば、ログイン、セッション管理、権限判定、既存利用者との互換性、失敗時の処理が別々の条件を持つ。ログインだけ実装済み、権限判定は検証済み、既存セッションとの互換性は未確認という状態でも、全体は一つの「進行中」に押し込まれる。これでは後続作業が、認証機能のどの部分までを確定済みの前提として利用してよいか判断できない。

この曖昧さは、要求を細かく分解すれば自動的に消えるわけではない。「関数を一つ追加する」「変数名を変更する」「データベースへ列を一つ追加する」といった実装操作まで一件ずつに分けると、今度は単独では正否を判定できない途中状態が増える。たとえば、ある利用者向け挙動を成立させるために三つの関数を同時に変更する必要があり、最初の二つだけでは期待する挙動を再現できないなら、その二件は後続作業が利用できる確定状態ではない。タスク数だけが増え、開始、引き継ぎ、状態更新、再確認の対象が増える。

分割の基準になるのは、変更量ではなく、成果を単独で観察して確定できるかである。たとえば「権限を持たない利用者が管理 API を呼び出した場合は 403 を返し、対象データを変更しない」という単位なら、入力条件、HTTP 応答、保存状態という三つの観察対象を一件として定義できる。内部では認証処理、権限判定、例外処理、テストなど複数のファイルを変更するかもしれない。それでも、与える入力と期待する結果が一つの意味ある挙動へ収束し、その結果を独立して検証できるなら、一件のタスクとして閉じられる。

反対に、「管理 API の権限判定関数を追加する」だけでは、タスクとして十分とは限らない。その関数が存在しても、実際の API から呼ばれていなければ利用者から見た挙動は変わらない。403 を返していても、その前にデータ更新が実行されていれば要求は満たしていない。実装操作を完了条件にすると、「コードを書いた」という事実と「要求された状態が成立した」という判断が分離する。タスク境界は、内部で何を変更するかではなく、変更後に何を観察できるかへ置いた方が安定する。

既稿「未整理の条件を、判断できる形に変える」では、実務で与えられる不完全な入力を、状態を定義し、制約を分け、断定できる範囲を制御し、後から検算可能な形へ構造化することを扱った[6]。開発タスクでは、この考えを開始条件、変更範囲、完了条件、停止条件へ具体化できる。「権限周りを直す」という要求を、そのまま AI へ渡すのではなく、どの状態から開始し、どの範囲を変更でき、どの観察結果を満たせば終了し、どの条件に達したら現在の判断範囲を越えるのかへ分解する。要求を短くするのではなく、要求を判定可能な構造へ変える。

この変換には少なくとも四つの境界がある。開始時点で何が成立していなければならないかという前提、目的達成のためにどこまで変更してよいかという範囲、何を観察すれば成立したと判定できるかという完了条件、現在ある仕様や権限だけでは決められない場合にどこで停止するかという判断境界である。これらが一件の中で対応していれば、実装方法そのものは途中で変わってもよい。最初に想定した関数ではなく共通処理を修正する方が適切だと分かっても、完了条件と変更可能範囲が維持されていれば、タスクの意味は変わらない。

Codex の公式な Best practices でも、作業を依頼するときに目的、関連する文脈、制約、完了条件を明示することが推奨されている[7]。この構成が有効なのは、プロンプトを詳しくするほど AI が賢くなるからではない。目的と完了条件を実装手段から切り離しておけば、調査によって内部の実装方針が変わっても、「何を成立させる仕事なのか」を固定できるからである。変更方法には探索の余地を残しながら、終了判定には外部から確認できる基準を持たせられる。

粒度 状態の特徴 直接生じる問題 管理上の判断
大きすぎる要求 複数の成果、依存関係、検証条件が一件に含まれ、それぞれの確定度が異なる。 一部だけ成立した状態を「進行中」としか表せず、後続作業が何を前提にできるか判断できない。 後続作業が単独で利用できる確定成果ごとに境界を分ける。
検証可能なタスク 開始条件、変更可能範囲、期待結果、検証方法を一件として対応付けられる。 未確定状態から確定状態までの経路を一つの単位として追跡できる。 結果を検証し、確定した時点で後続作業の前提として渡す。
細かすぎる作業 単独では期待する挙動を成立させない実装操作だけが独立する。 検証不能な中間状態と、その状態を記録、引き継ぎ、再確認する作業が増える。 同じ観察可能な完了条件を成立させる変更は一件へまとめる。

この基準を使うと、タスクの大きさをコード量だけで決める必要がなくなる。十数ファイルへ変更が及んでも、一つの外部挙動を成立させるために不可分であり、同じ検証によって成否を判定できるなら、一件として扱う理由がある。反対に、一行の設定変更でも、その結果が外部サービスや別環境で確認されるまで成立を判断できないなら、「一行だから小さいタスク」とは言えない。作業量と確定可能性は別の尺度である。

この違いは、後続作業への影響で見るとさらに明確になる。大きすぎるタスクでは、どの部分が確定しているか分からないため、後続作業は全体の完了を待つか、未確認部分を含んだまま先へ進むしかない。細かすぎるタスクでは、単独では利用できない中間成果を大量に管理することになる。検証可能な単位に置けば、一件を閉じるたびに「ここまでは前提としてよい」という新しい確定点ができる。

タスクとは、小さな仕事の名前ではない。未確定な開発状態について、開始条件と判断範囲を定め、観察可能な結果を検証し、後続作業が利用できる確定状態へ変える単位である。この定義を置くと、タスク分割の目的も変わる。AI が一度に処理できる文章量へ仕事を縮めることではなく、開発全体の途中に、誤った前提をそれ以上広げないための確定点を作ることが目的になる。

4. 確定した現在状態は、AI の会話の外へ残す

4.1 文脈と現在状態は同じものではない

検証可能なタスクへ分割しても、その状態を会話の中だけに置けば長期開発は安定しない。あるセッションで「実装中」と記録されたタスクが、その後の別セッションでテストまで終わった場合、最初の会話は履歴としては正しいが、現在状態としては古い。過去に何を調べ、何を考え、どの時点まで進んでいたかという記録と、いま何が成立しているかという現在値は別の情報である。

この違いは、作業を再開するときに表面化する。昨日の会話では「既存セッションとの互換性は未確認」とされていても、その後に別の担当者が実環境で確認を終えているかもしれない。反対に、過去の会話では「テスト成功」と書かれていても、その後の変更によって前提となるコードが変わっていれば、現在も同じ結果が成立するとは限らない。会話を時系列に読み直すだけでは、どの記録が最新で、どの判断が後から更新されたのかを再構成しなければならない。

Claude Code は CLAUDE.md や自動記憶を使い、プロジェクトに関する情報を後続のセッションへ持ち込める[8]。この仕組みは、命名規則、テスト方法、設計上の前提、リポジトリ固有の作法のように、複数の作業へ繰り返し適用する情報を保持する用途に向いている。一方、ある変更が実装中なのか、実環境検証待ちなのか、仕様判断待ちなのかという情報は、作業の進行によって継続的に変わる。長期間維持する文脈と、頻繁に更新される現在状態を同じ記憶機構へ載せると、古い情報が正しい前提として残る可能性が生じる。

現在状態を複数の会話、課題管理システム、メモ、作業報告へ同時に持つ場合も同じ問題が起きる。たとえばテストが完了したとき、会話だけを更新すれば課題管理システムが古くなり、課題管理システムだけを更新すれば次の AI が古い作業報告を読む可能性がある。情報源が二つなら二つを同期し、三つなら三つを同期し続けなければならない。更新先が増えるほど、どこか一つだけ古い状態が残る経路も増える。

そこで、現在状態を最終的に判定する場所を一つ決める。専用ファイルでも、課題管理システムでも、データベースでもよい。必要なのは特定の形式ではなく、複数の記録が食い違ったときに、どこを正式な現在値として読むかが決まっていることである。ほかの会話や報告は説明や履歴として残せるが、次に何を実行できるかを決める際には一つの正本へ戻る。

正本には、少なくともタスクの識別子、現在状態、依存関係、完了条件、残っている確認事項、検証結果を保持する。たとえば「ローカル検証済み」という状態だけでなく、「旧クライアントとの互換性を実環境で確認する」という残条件まで記録しておけば、次の担当者は過去の会話から未完了部分を推測する必要がない。過去の会話は調査経路を理解する材料として利用し、現在どこまで確定しているかは正本から取得する。

この分離によって、作業再開に必要な情報量も変わる。前の AI が何を考え、どの順番でファイルを読み、どの仮説を一度捨てたかまで再現する必要はない。現在状態、残条件、関連する差分と検証結果が残っていれば、次の AI は「いま確定している地点」から作業を始められる。長期開発で引き継ぐべきなのは、前の担当者の内部状態そのものではなく、プロジェクト側で確定した外部状態である。

4.2 進捗率より、状態と残っている条件を残す

現在状態を記録するとき、70% や 90% といった進捗率は一見分かりやすい。しかし、90% が「コードの大部分を書いた」という意味なのか、「実装と自動テストは終わり、実環境確認だけが残っている」という意味なのかでは、次に取るべき行動が異なる。前者なら実装を続ける必要があり、後者ならコードを追加するより検証環境への反映を待つ方が先になる。

割合が状態を表しにくいのは、ソフトウェア開発の作業が均質ではないからである。実装に数時間、テストに数分しかかからないタスクもあれば、コード変更は小さくても外部サービス側の反映を一日待たなければ確認できないタスクもある。さらに、最後の確認で仕様矛盾が見つかれば、「90%」とされたタスクが実装段階へ戻ることもある。作業時間やコード量を一つの連続した割合へ変換しても、何が確定し、何が残っているかは分からない。

これは上流工程で進捗率を状態管理へ置き換えた理由と同じである。既稿では、探索中、判断材料準備済み、判断待ち、決定済み、後続反映済みといった状態を分け、次へ進む条件を管理した[5]。AI コーディングでは状態名が実装と検証に合わせて変わるが、百分率の代わりに「次の状態へ移るために何が足りないか」を記録するという管理原理は共通する。

未着手、調査中、実装中、ローカル検証済み、実環境検証待ち、仕様判断待ち、完了といった離散的な状態を使うと、現在位置を次の操作へ直接接続できる。「実装中」なら完了条件へ向けて変更を収束させ、「実環境検証待ち」なら必要な環境が利用可能になるまでコードを増やさず、「仕様判断待ち」なら人間の判断結果を待つ。同じ未完了でも、AI が継続できる状態と、外部条件を待つ状態を区別できる。

状態 その時点で確定していること 残っている条件 次の操作
未着手 要求が登録され、作業対象として識別できる。 依存関係、開始条件、既存仕様の確認が残っている。 先行タスクが確定しているかを確認し、調査を開始できるか判断する。
調査中 対象となる仕様、既存実装、影響範囲を確認している。 現在のタスク境界で完了条件まで到達できるかが未確定である。 そのまま実装へ進むか、要求を分割し直すか、判断を人間へ戻すかを決める。
実装中 開始条件を満たし、定義した変更範囲で作業を進められる。 完了条件を成立させる変更と、その検証が残っている。 現在の目的へ変更を収束させ、途中で見つかった別問題を混入させない。
ローカル検証済み 開発環境で再現できる完了条件について、必要な検証が成功している。 外部サービス、権限、本番相当設定など、ローカルでは確認できない条件が残る場合がある。 外部確認が必要かを判定し、不要なら完了判定へ進む。
実環境検証待ち 実装とローカルで可能な検証は終わっている。 実際の外部サービス、権限、設定、データとの組み合わせが未確認である。 必要な環境で残条件を確認し、それまでは完了へ進めない。
仕様判断待ち 技術的な選択肢と、それぞれの影響までは整理できている。 どの挙動、互換性、データ処理、権限を正式な方針とするかが未確定である。 人間が判断し、その結果を正本と関連仕様へ反映してから再開する。
完了 定義した完了条件に対応する必要な検証が終わり、後続作業へ影響する未確認事項が残っていない。 現在のタスクについて新たに確定しなければならない条件はない。 その成果を確定済みの前提として、依存する後続タスクを開始できる。

状態だけでも次の操作はかなり限定できるが、実務では残っている完了条件まで記録した方がよい。同じ「実環境検証待ち」でも、「旧クライアントでログインできることを確認する」場合と、「本番相当の権限で外部 API へ接続できることを確認する」場合では、必要な環境も担当者も異なる。状態が工程の位置を示し、残条件がその位置から抜けるための条件を示す。

この組み合わせは AI が次の作業を選ぶ場合にも使える。90% という数字だけでは、そのタスクを続ければよいのか、人間の作業を待つべきなのか判断できない。「実環境検証待ち」であり、残条件に「本番相当環境で管理者権限による確認が必要」と記録されていれば、AI はコードを追加して数字を 100% に近づけるのではなく、そのタスクを待機させ、依存しない別の作業へ移れる。状態管理は人間向けの進捗表示ではなく、次に実行可能な作業を選別するための入力になる。

4.3 識別子は要求、変更、検証を時間方向に結ぶ

正本によって現在値を一つにしても、それだけでは要求と実際の成果物を時間方向に追跡できない。開発が長くなると、「認証処理の修正」「認証処理の追加対応」のように似た名前の作業が増え、同じ機能へ複数回変更を加えることもある。タイトルや日時だけで対応を取ろうとすると、どの要求によってどの差分が生まれ、どのテスト結果がその変更を検証したのかを後から再構成しなければならない。

そこで、各タスクへ一意の識別子を割り当て、要求、コミット、Pull Request、検証記録、状態更新へ同じ識別子を通す。たとえば認証方式の移行について一件の識別子があれば、正本から完了条件を読み、Git の履歴から実際の変更を確認し、検証記録からどの条件まで確認したのかをたどれる。識別子そのものに意味を持たせる必要はなく、異なる成果物が同じ一件に属していることを確実に示せればよい。

この対応が必要なのは、一件のタスクが一つのセッションで終わるとは限らないからである。初日に調査し、翌日に実装し、別の担当者がレビューし、数日後に実環境で検証する場合でも、同じ識別子があれば、それらを一件の状態遷移として結び付けられる。会話単位で履歴を管理すると担当者やセッションが変わるたびに境界が切れるが、タスク単位の識別子なら実行主体が変わっても同じ仕事を追跡できる。

一度割り当てた識別子は、作業が中止されても別の意味へ再利用しない方がよい。過去のコミットやレビューに残った識別子を別の要求へ割り当てれば、一つの検索結果に異なる二つの仕事が混在する。障害調査でその識別子をたどったとき、どちらの変更が現在の挙動へ影響したのか判別できなくなる。中止、重複、対象外になったタスクも削除して空きを作るのではなく、その状態と理由を残すことで、「なぜ実装されなかったのか」まで履歴として保持できる。

正本と識別子は役割が異なる。正本は「いま何が確定しているか」を示し、識別子は「その状態がどの要求、変更、検証を経て成立したか」を結ぶ。前者だけでは現在値から過去をたどれず、後者だけでは過去の記録から現在値を一意に決められない。両方を組み合わせることで、AI の会話履歴や内部記憶を引き継がなくても、プロジェクト側に残された情報から同じ仕事を再開できる。

ここまでで、未確定状態を確定するための単位と、その現在位置を外部へ保持する仕組みがそろう。しかし、現在のタスクが分かることと、そのタスクの中で AI が何を自分で決めてよいかは別である。次に必要になるのは、実装方法として委任できる判断と、プロジェクト側へ戻さなければならない判断を分けることである。

5. AI に与える実装の自由と、判断する権限は分ける

AI がコードを自律的に変更するには、実装方法をある程度選べなければならない。対象関数の内部を書き換えるか、共通処理へ寄せるか、既存の補助関数を再利用するかまで人間が逐一指定すれば、AI は実装者というより手順実行器になる。一方で、「どう実装するか」を選べることと、「どの仕様を正式とするか」「どのデータを捨てるか」「互換性を壊してよいか」を選べることは別である。後者には、コードだけからは決まらないプロジェクト上の判断が含まれる。

たとえば、重複した利用者レコードによって一意制約を追加できない場合を考える。AI は重複を検出する処理、移行用のプログラム、制約追加後のテストを実装できる。しかし、二つのレコードのうちどちらを正式なデータとして残すかは、更新日時だけで決めてよいとは限らない。契約情報、外部システムとの対応関係、監査上の保存義務が関係するなら、技術的に処理できることと、プロジェクトとして決定してよいことが分かれる。

この境界を曖昧にしたまま「問題を解決せよ」とだけ指示すると、AI は与えられた目的を達成するために、技術的に成立する経路を探索する。重複データを一方削除すれば制約を追加できるなら、それは局所的には合理的な解決策になり得る。しかし、削除してよいという方針まで与えられていなければ、その合理性は実装上の合理性に限られる。目的達成の最短経路が、データ保全、外部互換性、運用上の約束と一致する保証はない。

既稿「AI に任せる前に、人間が残すべき判断」では、AI を使う前に、人間側が問いの切り方、判断軸、優先順位、任せない領域を持つ必要があることを扱った[9]。中～大規模開発では、この判断を抽象的な方針のまま置くのではなく、一件のタスクについて何を成立させるか、どこまで変更してよいか、何をしてはいけないか、どの条件で完了とするか、どこで人間へ戻すかへ具体化できる。

既稿「Devin と Claude Code の違いは、作業の任せ方にある」でも、製品機能の多少より、どの大きさの仕事を渡し、途中で生じる曖昧さをどこまで AI に処理させ、どこから人間が引き受けるかという作業構造を中心に整理した[10]。一件のタスクへこの境界を埋め込めば、担当する AI やセッションが変わっても、「どこまで自分で決めてよいか」を同じ条件から再現できる。

項目 定める境界 AI に残す自由 境界がない場合に起きること
目的 変更後に成立させる利用者側またはシステム側の状態を定める。 目的を満たす内部実装の選択は AI に委ねられる。 指定された編集操作そのものが目的になり、調査でより適切な方法が見つかっても変更できなくなる。
変更範囲 目的達成のために調査または変更してよい機能、データ、設定、文書の範囲を定める。 範囲内でどのファイルや内部構造を変更するかは実装判断として選べる。 局所的な目的達成のために、共通処理、公開 API、別機能の仕様まで変更する可能性が生じる。
禁止事項 技術的には可能でも、そのタスクでは採用しない手段を定める。 禁止されていない代替手段の探索は継続できる。 既存互換性、データ保全、権限制約が、実装上の簡単さや最短経路に負ける。
完了条件 第三者が何を観察すれば要求が成立したと判定できるかを定める。 条件を満たすための実装手順やテスト構成は途中で変更できる。 コードを書いたことやテストを一部通したことが、そのまま完了判定へ置き換わる。
停止条件 現在ある仕様、権限、判断軸だけでは結論を出せず、新しいプロジェクト判断が必要になる地点を定める。 停止条件に触れない局所的な実装判断は連続して処理できる。 AI が仕様やデータ方針まで暗黙に決めるか、反対に実装上の細部まで毎回人間へ確認することになる。

この表で分けているのは、細かな指示の数ではなく、判断の種類である。目的、変更範囲、禁止事項、完了条件、停止条件が先に定まっていれば、その内側では AI に実装上の探索余地を残せる。反対に、この境界を与えずに手順だけを細かく指定すると、AI は安全になるとは限らない。想定外の構造が見つかったとき、手順から外れてよいのか、目的を優先して範囲を広げてよいのかを判断できなくなる。

5.1 大きな変更は、コードを書く前に境界を検査する

一件として定義したタスクでも、実際のコードベースを調査すると境界が崩れることがある。たとえば「認証済み利用者の識別方法を変更する」という要求を、認証モジュールだけの変更だと想定して開始したとする。調査の結果、その識別子がセッション、監査ログ、権限判定、公開 API、外部連携、既存データにも保存されていると分かれば、当初の変更範囲では要求を閉じられない。

この状態で実装を先に始めると、二つの失敗経路が生じる。一つは、当初の範囲を守るために必要な変更を省き、表面的には動くが一部だけ古い識別方法が残ることである。もう一つは、目的達成を優先して AI が変更範囲を自発的に広げ、公開 API やデータ形式まで書き換えることである。前者では完了条件を満たせず、後者ではタスクに与えられた判断権限を越える。どちらも、コードを書く技術だけでは解消できない。

影響範囲が広い変更では、実装前に調査と計画を挟み、参照する仕様、変更候補、既存互換性、必要な検証、不明点、戻し方を確認する価値がある。Claude Code の Plan mode は、変更を実行する前にコードベースを読み取り、計画を提示し、その内容を確認してから実装へ移るための仕組みとして提供されている[11]。ここで利用したいのは特定製品の操作方法ではなく、変更前に「このタスクは現在の境界のまま閉じられるか」を検査する工程である。

計画で確認する対象は、編集順序だけではない。たとえば「既存クライアントとの互換性を維持する」が完了条件に含まれているのに、調査すると新しい識別子を返すには API の応答形式を変える必要があると分かった場合、問題はどのファイルを先に編集するかではない。完了条件と実際のコード構造が両立していない。ここで互換性を壊して実装を続ければ、AI は実装手段ではなく要求そのものを変更したことになる。

計画段階でこの矛盾を見つければ、コード変更を増やす前にタスクを分け直せる。既存 API を維持したまま内部識別子だけ移行する案を調べる、新しい API 版を別タスクとして設計する、互換性を捨てる判断を人間へ戻す、といった分岐を選べる。実装後に同じ問題を発見した場合と比べ、未確定な差分や再検証対象を増やさずに済む。

データ移行では、この境界がさらに明確になる。旧形式から新形式への変換規則、退避先、失敗時の復旧方法が決まっていれば、変換処理の作成、試験データでの実行、件数や整合性の確認は実装として委任できる。一方、重複した既存レコードのどちらを残すか、失われた項目を何から補完するか、法令や契約上どの期間まで旧データを保持するかが未決定なら、その先には新しい方針が必要になる。

同じ「データ移行」という一件の中でも、変換アルゴリズムを選ぶことと、どの情報を正として残すかを決めることでは判断主体が異なる。前者は既に定められた目的と制約の中で最適な実装を探す問題であり、後者はプロジェクトが新しい意味を決定する問題である。AI に実装を任せる範囲を広げても、この二つを同じ自由度として扱う必要はない。

AI の自律性を「人間へ質問しないこと」と定義すると、停止は能力不足に見える。しかし、停止すべき地点を持たない AI は、未決定の仕様へ遭遇したときに推測で進むか、すべての不明点を局所的な実装判断へ変換するしかない。どちらも、未確定なプロジェクト判断を確定済みであるかのようにコードへ埋め込む原因になる。

実装の自由と判断権限を分ければ、別の設計ができる。既に定められた目的、変更範囲、禁止事項、完了条件の内側では AI に連続して調査と実装を任せる。一方、その条件同士が両立しない、新しい仕様を選ばなければ進めない、データや互換性について新しい方針が必要になる、といった地点では停止する。停止条件は自律性を狭めるためのものではなく、境界の内側を安心して広く委任するための条件になる。

ここまでで、一件のタスクについて AI がどこまで自分で進めてよいかを定義できる。しかし、中～大規模開発では一件だけを処理するわけではない。複数の AI が同時に変更を作れるようになると、次に制約になるのは生成できる件数ではなく、それらの変更を互いに影響させず、確定状態まで検証できる件数である。

6. 並列度は、AI の実行能力ではなく検証能力で決まる

AI コーディングエージェントは、複数の調査や実装を短時間で並行して進められる。人間が一件ずつコードを書く場合と比べれば、着手できる作業数そのものは大きく増やせる。そのため、三つのエージェントへ三件の変更を割り当てれば、開発全体も三倍近く進むように見える。しかし、生成された三件がそのまま三件の確定済み成果になるわけではない。

実装された変更を後続作業の前提へ昇格させるには、それぞれについて要求との対応、テスト結果、既存機能への影響、差分の妥当性を確認しなければならない。さらに複数の変更が同じ API、データ構造、設定、共通処理へ触れていれば、個別の正しさだけでは足りない。統合した状態でも同じ前提が成立するかを確認する必要がある。AI が増やせるのは主として変更を作る側の並列度であり、受け入れ可能な状態まで確定する工程には別の上限がある。

既稿「この物量の文章を、一体誰が検証できるのか」では、AI は大量の文章をまとめて生成できても、その内容を検証する側は個々の主張を根拠へ戻って確認しなければならないという非対称性を扱った[12]。コードでも構造は似ている。十件の変更を同時に生成することはできても、「十件とも要求を満たしている」「互いの前提を壊していない」「既存機能への回帰がない」という三種類の確認まで、一つの生成処理のようにまとめて済ませることはできない。

ここで開発速度を「AI が作った差分の量」で測ると、並列化の効果を過大評価する。プロジェクトが実際に利用できるのは、生成された差分ではなく、完了条件まで検証され、後続作業が確定済みの前提として利用できる成果である。生成速度が検証速度を超えると、開発が速くなる代わりに、未確認の差分が作業空間や Pull Request に積み上がる。後から一件ずつ確認する必要がある以上、それは完成品の在庫ではなく、検証を待つ未確定状態の在庫である。

6.1 未確定変更を増やすと、変更間の関係まで検証対象になる

並列化による負荷は、変更件数だけでは決まらない。たとえばタスク A が API の入力形式を変更し、タスク B がその API を呼び出す処理を変更し、タスク C が同じデータを保存する構造を変更するとする。A、B、C を別々の作業空間で実装し、それぞれの単体テストが成功しても、三件を統合した状態で正しく動くとは限らない。

A が新しい入力項目を必須にした一方で、B が古い入力形式を送っていれば、A と B は単独では成功しても接続した時点で失敗する。C が保存形式を変更し、A が旧形式を前提に検証していれば、A と C の組み合わせで初めて不整合が表面化する。三件が同じ概念を別々の表現へ変更していれば、Git 上の競合が一行も発生しなくても、システム全体では矛盾する。

この場合、確認対象は A、B、C の三件だけではない。A と B の接続、A と C のデータ対応、B と C の前提、さらに三件を統合した状態まで確認する必要が生じる。変更が論理的に依存しているほど、検証対象は個々の差分から差分間の関係へ広がる。並列化によって増えるのは作業数だけではなく、「どの変更がどの前提に依存しているか」という組み合わせである。

障害が起きたときの原因切り分けも難しくなる。A、B、C を順番に確定していれば、B を導入した時点で障害が発生した場合、A までは確定済みとして残し、B の変更を中心に調べられる。三件を未確定のまま同時に統合した場合には、A 単独の問題なのか、B 単独なのか、A と B の組み合わせなのか、C を含めたことで初めて起きたのかを切り分けなければならない。確定点を持たない並列化は、失敗時に戻る位置まで曖昧にする。

Kanban Guide は、開始したが終了していない作業を進行中作業（WIP）として明示的に扱い、その数を制御し、作業項目がどの条件で状態を進むかを定める考え方を採用している[13]。これは AI 固有の方法ではない。しかし、人間だけで開発する場合より着手能力を急激に増やせる AI コーディングエージェントでは、「開始できるから開始する」という判断が未確定状態を急速に増やすため、着手量と完了量を分けて考える意味が大きくなる。

制御対象になるのは、タスク一覧に登録されている総数ではない。未着手の百件は、まだコードベースへ新しい不確実性を持ち込んでいない。影響するのは、調査や実装を開始し、現在のコードや仕様について新しい前提を持ちながら、まだ確定していない作業である。進行中の変更が増えるほど、後続作業が参照してよい前提と、まだ変わる可能性のある前提を区別する必要が増える。

読み取り中心の調査は、この制約を受けにくい。別々のエージェントが認証処理、データ保存、外部 API の仕様を調べても、調査中には共有コードを変更しないなら、結果を後から比較して統合できる。反対に、同じ公開 API や共通データモデルへ複数の実装が同時に変更を加える場合、各変更が正しくても、互いが前提としている現在状態そのものがずれる可能性がある。

この差から、並列化の判断基準も「何件のエージェントが空いているか」ではなくなる。別々に進めた成果を、それぞれ独立した完了条件で確定できるかを見る必要がある。独立して確定できるなら並列化は待ち時間を減らす。統合するまで正否を判定できないなら、並列化は実装時間を短縮しても、その後に統合と再検証という別の未確定作業を作る。

6.2 作業空間を分けても、論理的な依存関係は消えない

複数の実装を並行する場合、最低限必要になるのが作業中の差分を物理的に分けることである。同じ作業ディレクトリで二つのエージェントが同時にファイルを書き換えれば、一方がまだ検証していない変更を他方が読み込み、どちらのタスクによる差分なのか分からなくなる。テスト結果も複数タスクの変更を含んだ状態で得られれば、一件の完了条件に対応する証拠として使いにくい。

Git の worktree 機能は、一つのリポジトリに複数の作業ツリーを持たせ、異なるブランチや作業状態を別々のディレクトリで扱える[14]。Codex も、チャットごとに管理された Worktree を利用して、複数の作業を分離された環境で進める仕組みを提供している[15]。この分離によって、少なくとも一方の未コミット変更が他方の作業ディレクトリへ直接混入することは避けられる。

ただし、作業空間の分離が保証するのは差分の物理的な隔離であって、タスクの論理的な独立ではない。たとえば一方の作業ツリーで利用者テーブルの列名を変更し、もう一方で旧列名を前提に新しい検索機能を追加した場合、両方ともそれぞれの作業空間ではテストに成功する可能性がある。Git の行単位の競合がなくても、統合したコードでは新しい検索機能が存在しない列を参照する。

API の意味変更でも同じことが起きる。一方の変更で「空文字列は無効」と仕様を変え、別の作業では従来どおり空文字列を送るクライアント処理を追加した場合、編集対象のファイルが完全に分かれていても二件は独立していない。ファイルが違うこと、ブランチが違うこと、Git が自動マージできることは、完了条件を別々に確定できることとは一致しない。

作業 並列化しやすさ 独立性を確認する条件 並列化した場合に残る確認
読み取り中心の調査 高い 共有コードやデータを変更せず、それぞれの調査結果を単独で記録できる。 調査結果同士が矛盾していないかを比較し、実装へ採用する前提を確定する。
異なる領域に閉じた実装 条件付きで高い 変更対象だけでなく、参照する API、データ、設定、完了条件にも依存関係がない。 個別検証後、統合状態で共通の回帰テストが成立することを確認する。
共通 API やデータモデルの変更 低い 一方の変更結果を他方が前提として利用しないことを確認できなければ独立とは扱えない。 呼び出し側、保存側、移行処理を含め、統合後の前提を再検証する必要がある。
同じ障害原因を別々に修正 低い 複数案を比較する実験として意図的に分ける場合を除き、同じ完了条件を競合して変更する。 どちらを採用するかを判断し、不採用側の差分を混入させずに一案だけを確定する必要がある。

この表で「異なる領域に閉じた実装」を無条件に高いとはしていない。画面側とサーバー側のようにファイル配置が離れていても、同じ API 契約を前提にするなら論理的には依存している。反対に、同じリポジトリ内でも、互いに参照しない独立した変換処理であり、別々の入力と期待結果によって完了を判定できるなら、並列に確定できる可能性は高い。見るべき境界はディレクトリではなく、完了判定に必要な前提の共有範囲である。

作業空間を分離する価値は、それでも大きい。差分が一件ごとに分かれていれば、個別テストをその変更だけの状態で実行でき、レビュー対象も一件へ限定できる。問題が見つかった場合も、その作業ツリーやブランチを破棄して別の確定済み状態へ戻しやすい。物理的な隔離は論理依存を消さないが、独立性を検証し、失敗時の影響を一件へ閉じ込めるための前提になる。

並列度の上限を決めるのは、AI が同時に起動できる数ではない。それぞれの変更について、どの前提から始まり、何を変更し、どの完了条件を満たし、どの証拠によって確定したかを独立して説明できる数である。依存する変更を十件同時に作っても、一括統合しなければ正否を判断できないなら、確定という観点では一つの大きな未完了作業を十個の作業空間へ分散しただけである。

AI によって生成速度が上がるほど、この制約は前面に出る。実装側の処理能力だけを増やせば、未確定な変更の流入量が検証側の処理能力を超える。すると Pull Request、ブランチ、作業空間には差分が増えていても、後続作業が安全に利用できる確定点は増えない。開発全体の速度を決めるのは、作り始められる件数ではなく、検証を通過して閉じられる件数である。

この観点から見ると、進行中作業を制限することは AI の能力を使い切らない消極策ではない。未確定状態の増加速度を、プロジェクトが確定できる速度へ合わせる制御である。並列化するなら、独立して検証できる調査や変更を選び、依存関係を持つ変更は確定点を挟みながら進める。その方が、AI の生成能力を未確認の差分の山へ変えるのではなく、後続作業が利用できる成果へ変換できる。

ただし、未確定状態の数を抑えても、一件のタスク内で AI が禁止された操作を実行したり、成果物が要求外の変更を含んだりすれば、その成果は確定できない。次に分ける必要があるのは、AI に「守るよう伝える」情報と、実際に操作を止める制約、そして生成後の成果を受け入れるための検査である。

7. 「守れ」という指示、実行制約、成果物の検査は別の層である

AI に「本番環境を変更しない」「指定範囲外を触らない」「既存動作を壊さない」と書けば、その条件は実装時の判断材料になる。しかし、文章として条件を与えたことと、その条件に反する操作が実行不能になったことは別である。自然言語の指示は、状況に応じて意味を解釈し、複数の条件を組み合わせて判断する用途には向いている。一方で、禁止対象が明確で、違反した場合の影響が大きい操作まで、毎回モデルの解釈だけに委ねる必要はない。

たとえば「本番データを変更しない」という一文を与えた状態で、AI が利用する実行環境に本番データベースへの書き込み権限まで存在しているとする。通常は指示どおりに動いたとしても、障害調査の途中で「再現のために一件だけ更新する必要がある」と判断する可能性は残る。ここで起きているのは、指示を忘れたかどうかという問題だけではない。禁止事項の判定と、その判定に違反した場合の実行権限が、同じモデル判断の中に置かれている。

反対に、本番環境への書き込み権限そのものを与えなければ、AI がどのような理由付けをしても、その経路から本番データを変更することはできない。自然言語で「してはいけない」と伝える制御から、実行環境側で「できない」状態を作る制御へ移したことになる。禁止条件が明確で、例外を認める必要がない操作では、この違いがそのまま事故時の影響範囲の違いになる。

ただし、すべての条件を権限で遮断できるわけではない。「既存動作を壊さない」は、どの変更が回帰を起こすかを事前に列挙できない。「指定範囲外を変更しない」も、共通処理を修正しなければ目的を達成できない場合には、機械的にファイル単位で禁止すると必要な実装まで妨げる。条件によって、判断させるべきもの、実行時に止めるべきもの、変更後に検査すべきものが異なる。

この違いを無視してすべてを一つの指示文へ集めると、性質の異なる制約が同じ重さで扱われる。「変数名は既存規約に合わせる」と「本番データを削除しない」が同じ文章の箇条書きとして並び、どちらも最終的にはモデルが解釈して守る条件になる。前者は文脈を読んだ柔軟な判断に向くが、後者は違反した時点で取り返しがつかない場合がある。同じ表現形式に置けることと、同じ制御方法で扱うべきことは一致しない。

プロジェクト全体で繰り返し使う規約、現在の一件だけに必要な条件、危険な操作を止める制約、生成後の成果物を検査する仕組みは、それぞれ別の制御点へ置いた方がよい。Codex では AGENTS.md にリポジトリ固有の継続的な指示を置ける[16]。Claude Code では Hooks によってツール実行前後へ処理を挿入でき、PreToolUse では条件に応じて実行を止めることもできる[17]。Codex の Rules も、特定のコマンドを許可、確認必須、禁止へ分類できる[18]。これらは同じ種類の機能ではなく、異なる制御点を持てることの具体例である。

制御点 置くもの 何を防ぐか この層だけでは防げないこと
恒常的なプロジェクト指示 命名規則、テスト方法、設計上の慣例など、複数のタスクへ継続して適用する情報を置く。 毎回同じ前提を説明し直す必要を減らし、実装判断をプロジェクトの通常ルールへ寄せる。 指示に反する操作を技術的に不可能にはできず、誤解や優先順位の衝突も残る。
個別タスク定義 現在の一件について、目的、変更範囲、禁止事項、完了条件、停止条件を置く。 恒常規約だけでは決まらない今回固有の判断境界を明示し、範囲外への拡張を抑える。 禁止事項が記載されていても、それに反するコマンドや権限が実行可能なら技術的な遮断にはならない。
機械的な実行制約 本番環境への書き込み、危険なコマンド、秘密情報へのアクセスなど、明確に許容しない操作を置く。 モデルが別の判断をしても、重大な操作がそのまま実行される経路を減らす。 許可された操作だけを使って生じる論理バグや回帰、要求外の変更までは検出できない。
成果物の検査 テスト、CI、静的検査、Git の差分確認、必要なレビューなどを置く。 実行前には分からなかった回帰、範囲外変更、要求との不一致を受入前に検出する。 既に外部へ実行された破壊的操作を事後検査だけで取り消せるとは限らない。

四つの層は、同じルールを重複して書くためにあるのではない。一つの条件を、性質に応じて複数の地点から支える場合がある。たとえば「本番環境を変更しない」という条件なら、個別タスクにも禁止事項として記載し、本番用の認証情報を実行環境へ渡さず、必要であれば危険な接続コマンドを実行制約で遮断する。タスク定義は AI に判断境界を知らせ、権限構成はその境界を越えた操作が実行される経路を閉じる。それぞれ役割が違う。

「指定範囲外を変更しない」は別の配置になる。タスク定義では、対象となる機能や変更可能な領域を示す。しかし、実装前にはどのファイルまで変更が必要か完全には分からないため、ファイル単位で機械的に禁止すると必要な共通処理まで修正できなくなることがある。そこで実装中は定義された目的と範囲を判断基準として使い、終了時には Git の差分を確認して、目的と関係のない変更が混入していないかを検査する。

「既存動作を壊さない」はさらに成果物検査へ比重が移る。AI が変更前にすべての回帰経路を予測することはできず、アクセス権で「回帰を起こす変更だけ」を禁止することもできない。そこで既存テスト、対象機能の回帰テスト、静的検査などを実行し、変更後の状態を観察する。ここでは禁止事項を守る意思より、実際に既存挙動が維持されているという証拠の方が完了判定に近い。

この違いは、制約をどこまで機械化するかを決める基準にもなる。判定条件が明確で、違反した瞬間の影響が大きく、正常な作業で例外を認める必要が少ないものは、実行制約へ移しやすい。本番への直接書き込み、特定の破壊的コマンド、秘密情報への不要なアクセスなどが該当する。一方、「既存の設計意図を損なわない」「必要以上に複雑にしない」のような条件は、コード全体の文脈と変更目的を読まなければ判定できない。これを単純な禁止規則へ変換すると、正しい改善まで拒否する可能性がある。

成果物検査にも限界がある。テストが成功したからといって、変更範囲が適切だったことや、仕様判断を勝手に変更していないことまで自動的に証明されるわけではない。テストは定義された入力と期待結果について挙動を確認するが、不要なリファクタリングが大量に混入しているかどうかは Git の差分の方が確認しやすい。静的検査は一定の規則違反を検出できても、公開 API の意味を変えてよいかという判断はできない。検査にも、それぞれ観察できる範囲がある。

このため、一件のタスクを安全に閉じるには、「指示を与えたから守られる」「テストが通ったから正しい」と一つの制御点へ完了判断を集約しない方がよい。実装中の判断には文脈とタスク定義を使い、取り返しのつきにくい操作は実行環境側で制限し、生成された差分はテストや変更内容の確認によって受入可能か判定する。どの制御も万能ではないため、異なる失敗経路を異なる地点で止める。

AI を統制することは、一つの巨大な指示文へルールを集めることではない。情報として理解させる条件、現在の一件で判断してよい範囲、モデルの判断にかかわらず止める操作、生成後に証拠で確認する条件を分離し、それぞれ失敗したときの影響に合った場所へ配置することである。この構造を持てば、AI の裁量を全面的に奪わなくても、裁量を残す部分と機械的に閉じる部分を分けられる。

ここまでで、AI が変更を作る前と作っている途中の制御は整理できる。しかし、禁止された操作をしなかったことだけでは、タスクが完了したとは言えない。目的どおりの変更が存在し、必要な検証を通過し、後続作業が前提として利用できる状態まで確定したかを別に判定する必要がある。次に必要になるのは、「AI が実装を終えた」という報告と、「プロジェクトとして完了した」という状態を分けることである。

8. 完了とは、コードが存在することではなく、状態が証拠で確定したことである

AI が「実装しました。テストも成功しました」と報告しても、その文章だけではタスクの完了を第三者が判定できない。実装したという報告から分かるのは、AI が何らかの変更を行ったということだけである。どのファイルを変更したのか、どの完了条件をどのテストで確認したのか、既存機能への影響をどこまで調べたのか、ローカル環境では確認できない条件が残っていないかまでは、その一文から復元できない。

この差は、前章で分けた「指示」「実行制約」「成果物の検査」のうち、最後の検査がなぜ独立して必要なのかを示している。危険な操作を実行しなかったとしても、要求どおりのコードを書いたとは限らない。要求どおりのコードを書いたとしても、既存機能を壊していないとは限らない。対象テストと回帰テストが成功しても、外部サービスや本番相当の権限が必要な条件まで確認済みとは限らない。完了までには、異なる種類の不確定性をそれぞれ対応する証拠で閉じる必要がある。

既稿「AI の答えは、採用されたときに責任になる」では、AI が候補を生成したことと、それを人間が現実の判断として採用したことを分けている[19]。コードでも同じ境界がある。差分が生成された時点では、それはプロジェクトへ取り込む候補である。その候補について要求との対応、既存機能への影響、環境依存条件を確認し、後続作業が前提として利用してよいと判断した時点で、初めて確定済みの成果になる。

たとえば完了条件を「権限を持たない利用者が管理 API を呼び出した場合は 403 を返し、対象データを変更しない」とする。この場合、「権限エラーのテストが成功した」という報告だけでは条件全体を確認したことにならない。テストが応答コードだけを検査していれば、403 を返す前にデータ更新が実行されていても成功する可能性がある。完了条件には「403 を返す」と「データを変更しない」という二つの観察対象があるため、証拠側も両方へ対応していなければならない。

さらに、その API が実際には外部の認証基盤から渡される権限情報へ依存している場合、ローカル環境の模擬データだけで成功したことと、実際の認証基盤と結合した状態で成功することも分ける必要がある。ローカルテストで確認できた範囲は確定できるが、実環境でしか得られない権限情報との組み合わせは未確認のままである。ここで「テスト済み」を一つの状態として扱うと、何を確認したテストなのかという差が消える。

証拠 確認できること その証拠だけでは確認できないこと 完了条件との対応
Git の差分 実際に変更されたファイル、追加や削除の内容、目的と無関係な変更の混入を確認できる。 変更後の挙動が要求を満たしているかまでは分からない。 変更範囲や禁止事項を守ったかを確認する証拠になる。
対象テスト 今回の完了条件に対応する入力と期待結果が成立したかを確認できる。 今回の変更と関係のない既存機能が壊れていないかまでは分からない。 「何が成立すれば完了か」という中心条件へ直接対応する。
回帰テスト 変更前から成立していた挙動のうち、テスト対象になっている範囲が維持されているかを確認できる。 テストされていない既存挙動や外部環境固有の条件までは保証しない。 新しい要求を満たす代わりに既存の前提を壊していないことを確認する。
実環境確認 外部サービス、実際の権限、ネットワーク、設定、データとの組み合わせで要求が成立するかを確認できる。 別の入力条件や未試験の既存機能まで自動的に保証するものではない。 ローカル環境では再現できない完了条件を閉じる証拠になる。
未確認事項の記録 どの条件まで証拠があり、どこから先が未確認なのかを明示できる。 未確認の条件そのものを成立させることはできない。 完了と未完了の境界を曖昧な自己申告ではなく明示的な残条件として残す。

証拠を列挙するだけでも足りない。どの証拠がどの完了条件を支えているかを対応付ける必要がある。対象テストが百件成功していても、その百件の中に今回追加した権限制御を確認するケースが含まれていなければ、件数は完了の根拠にならない。反対に、一件のテストでも、要求された入力条件、応答、保存状態を直接確認しているなら、その完了条件に対しては強い証拠になる。証拠の量ではなく、判定対象との対応関係が必要である。

同じ理由から、「CI が成功した」という状態も単独では完了を意味しない。CI が実行しているテスト群に今回必要なケースが含まれているか、実環境でしか確認できない条件が除外されていないか、静的検査の成功を挙動確認と混同していないかを確認しなければならない。自動化された検査は再現性を高めるが、その検査が何を観察しているかという設計判断までは代替しない。

GitHub の必須レビューも、Pull Request に差分が存在することと、その差分を受け入れることを別の状態として扱う[20]。レビュー運用によっては、承認後に差分が変更された場合、以前の承認をそのまま有効とせず再確認を求めることもできる。これは「一度確認した」という履歴だけではなく、「現在存在する成果物が確認済みか」を管理する仕組みである。

この区別は AI 開発でさらに重要になる。AI はレビュー後でも短時間に追加修正を生成できるため、確認済みの差分と現在の差分が容易にずれる。ある版で対象テストとレビューが完了していても、その後に AI が別の修正を追加すれば、以前の証拠が現在の成果物まで支えているとは限らない。成果物が変われば、その変更が影響する完了条件について証拠も更新する必要がある。

そのため、タスクの状態は「実装済み」「ローカル検証済み」「実環境検証待ち」「レビュー可能」「完了」のように分けて扱える。「実装済み」は差分が存在することを示し、「ローカル検証済み」は開発環境で確認可能な条件について証拠があることを示す。「実環境検証待ち」なら、コード側の作業は終わっていても、後続作業へ無条件に渡せる状態には達していない。「完了」は、これらの途中状態をまとめた進捗率ではなく、必要な条件がすべて閉じた最終状態である。

ここでいう完了は、「考え得るすべての不具合が存在しないこと」を証明する状態ではない。そのような証明は通常のソフトウェア開発では現実的ではない。完了時に求めるのは、あらかじめ定めた完了条件について必要な証拠がそろい、既知の未確認事項が後続作業の前提を壊さないことを確認できる状態である。確認範囲を明示するからこそ、「ここから先は確定済みとして扱う」という判断が可能になる。

この定義を採れば、AI の自己申告をどこまで信用するかという問題から離れられる。「テストしました」という文章を信頼するのではなく、どのコマンドを実行し、どの結果が得られ、どの差分に対してその検証が行われたかを確認する。「問題ありません」という評価を信頼するのではなく、完了条件と観察結果を対応させる。判断主体が AI から人間へ変わっても、別の AI へ引き継いでも、同じ証拠から同じ状態判定を再現できる。

証拠による完了判定には、もう一つ効果がある。どの証拠を集めても完了条件を閉じられない場合、その原因が「まだ作業していない」のか、「現在の環境では確認できない」のか、「そもそも仕様が決まっていない」のかを分けられる。前者なら AI が作業を続けられ、環境待ちなら状態を保留でき、仕様未決定なら人間の判断が必要になる。完了条件と証拠の対応を取ることで、未完了の理由そのものが次の操作を決める情報になる。

完了とは、コードが書かれた瞬間でも、AI が終了を宣言した瞬間でもない。定めた完了条件について、現在の成果物を支える証拠がそろい、残る未確認事項が後続作業の前提を脅かさないと判断できた時点で、未確定状態から確定状態へ移る。この確定点があるからこそ、その成果を次のタスクへ安全に渡せる。

一方、必要な証拠を集めようとしても、現在ある仕様や権限だけでは完了条件そのものを決められない場合がある。どの互換性を維持するか、どのデータを正とするか、未確認の条件を残したまま採用してよいかといった判断は、テストを追加しても自動的には決まらない。次に必要になるのは、証拠不足として作業を続ける場合と、新しい判断が必要なため人間へ戻す場合を区別することである。

9. 現在あるルールだけでは確定できない地点で、人間へ判断を戻す

AI を長く自律実行させるには、「何を任せるか」だけでなく、「どの条件に達したら自分では決めずに止まるか」を定義する必要がある。既存仕様に明記された入力検査を追加するたびに人間へ確認を求めれば、AI は局所的な実装判断すら自律的に処理できない。反対に、仕様書同士が矛盾している状態で一方を勝手に正としたり、既存データをどの基準で削除するかを AI が決めたりすれば、コードの実装方法ではなく、プロジェクトがまだ決めていない方針まで AI が確定することになる。

この境界は、作業が難しいかどうかでは引けない。複雑なアルゴリズムでも、入力、期待結果、制約が既に定まっていれば、その範囲で解法を探索することは実装判断として委任できる。一方、数行の設定変更でも、「どちらの値を正式な仕様とするか」が未決定なら、その一行を変更する前に新しい判断が必要になる。実装量と判断権限は別の尺度である。

たとえば「文字数が上限を超えた場合は 400 を返す」と仕様に明記されているなら、検査をどの層へ置くか、既存の入力検証を再利用するか、新しいテストをどこへ追加するかは技術的な選択になる。しかし、仕様書には 100 文字、既存実装には 200 文字、別の利用者向け文書には 150 文字と書かれている場合、どの値を採用するかはコードから導けない。AI が多数決や最新更新日で一つを選べば、それは既存ルールの適用ではなく、新しい仕様決定である。

停止条件を判断する基準は、「現在ある規則を適用すれば結論まで到達できるか」で考えると整理しやすい。仕様、データ方針、互換性方針、権限規則、完了条件が既に確定していて、その範囲内で実装方法だけを選べばよいなら AI は継続できる。複数の規則が矛盾する、必要な規則そのものが存在しない、既存の制約を変更しなければ完了できない場合には、現在のタスクだけでは確定状態へ到達できない。

状況 AI が継続できる状態 停止して人間へ戻す状態 境界になる判断
既存仕様の入力検査 入力条件、上限値、期待する応答が一意に定まり、現在の変更範囲だけで実装できる。 仕様書、既存実装、外部仕様の間で値や挙動が矛盾している。 どの既存情報を正式な仕様として採用するか。
テスト追加 既に定めた完了条件を、そのまま入力と期待結果へ変換できる。 既存テストと新しい要求が両立せず、期待結果そのものを変更しなければならない。 既存挙動を維持するか、新しい仕様へ変更するか。
データ移行 変換規則、対象範囲、退避方法、検証方法、失敗時の復旧方法が決まっている。 重複データのどちらを残すか、欠損値を何から補完するか、不可逆な削除を許容するかが未決定である。 どのデータを正式な記録として残すか。
公開 API 既存利用者との互換性を維持したまま、入力、出力、エラー条件を変更できる。 互換性を壊さなければ要求を満たせず、新旧形式の併存期間や移行方法を決める必要がある。 既存利用者への影響をどこまで受け入れるか。
権限 既存の認可規則を、現在の実装へ正しく反映する修正である。 新しい権限区分を作る、既存利用者の権限を変更する、例外対象を追加する必要がある。 誰に何を許可するかというプロジェクト側の方針。

表の左側にある作業は、技術的な難易度だけを見れば AI が処理できる場合が多い。停止が必要になるのは、実装能力が不足したときではなく、入力として与えられた規則から一つの正当な結果を導けなくなったときである。この違いを明示しておかないと、AI は二つの極端な動きを取りやすい。一つは、不明点をすべて質問して自律性を失うこと、もう一つは、不明点をすべて局所的な推測で埋めて未決定事項をコードへ固定することである。

後者は特に長期開発で危険になる。ある AI が曖昧な仕様を推測で一つに決め、その変更がテストを通過すると、次のタスクはその実装を「既に確定した仕様」であるかのように利用する可能性がある。さらに別の AI がその挙動を前提としてコードを追加すれば、最初は一件の推測だったものが複数の変更へ伝播する。後から本来の仕様が確定した時点では、一つの行を直すのではなく、その推測を前提にした変更全体を洗い直さなければならない。

停止条件は、この伝播を未確定な地点で止めるためにある。AI が「どちらでも実装できる」と判断したときに必要なのは、実装案を一つ選ぶことではなく、その選択が技術的な同値案なのか、プロジェクトの意味を変える判断なのかを区別することである。内部データ構造を配列にするか連想配列にするかのように、外部から観察される条件が変わらない選択なら実装判断として続行できる。公開 API の互換性やデータ保全方針が変わるなら、同じ「選択肢が複数ある」状態でも判断主体は人間側になる。

この停止は、既稿で「上位判断へ移管」として扱った状態にも対応する。現在の担当者が調査や比較を終えていても、権限やリスク受容の範囲を越えるなら、判断材料と影響をそろえて決定権を持つ主体へ渡す[5]。AI 開発でも、停止は「分からないから人間に聞く」ことではなく、現在の判断権限では確定できない状態を、必要な判断材料とともに適切な主体へ移す操作として扱える。

停止するときも、「判断できません」とだけ返せばよいわけではない。それでは人間が調査を最初からやり直すことになり、AI がそれまでに行った探索を引き継げない。停止時には、どの条件が未確定なのか、どこまで調査済みなのか、現在の作業状態に変更があるのか、選択可能な案はいくつあるのか、それぞれが互換性、データ、運用、後続タスクへどう影響するのか、何が決まれば再開できるのかを残す必要がある。

停止時に残す情報 内容 人間側で省略できる作業
停止理由 どの仕様、権限、データ方針、互換性条件が未確定で現在の判断範囲を越えたかを示す。 なぜ AI が停止したのかを会話履歴から推測する必要がなくなる。
確定済みの事実 調査で確認できた既存仕様、コードの挙動、データ状態、外部制約を示す。 人間が同じコードや資料を最初から調査し直す必要を減らせる。
現在の変更状態 未コミットの差分、検証済みの範囲、まだ破棄可能な試行変更があるかを示す。 判断後にどの状態から再開するかを確認できる。
選択肢と影響 現在確認できる案と、それぞれが互換性、データ、運用、後続作業へ与える影響を示す。 人間は技術調査ではなく、残っている方針判断そのものに集中できる。
再開条件 どの判断や情報が得られれば、現在のタスクを再び実行可能にできるかを示す。 判断後に新しい指示を一から組み立てる必要がなくなる。

たとえば公開 API の変更で、「旧形式を維持する」「新形式へ即時移行する」「一定期間だけ両形式を受け入れる」という三案まで技術的に整理できたとする。AI が止めるべきなのは、その三案を実装できないからではない。どの案を選ぶかによって既存利用者への影響と運用期間が変わり、その選択基準が現在のタスクには存在しないからである。人間は三案の実装方法を調べ直す必要はなく、どの影響を受け入れるかという判断だけを引き受ければよい。

人間が出した判断は、その場の返答だけに残さない。たとえば「旧 API を三か月維持した後に廃止する」と決めたなら、その結果は現在のタスクの完了条件だけでなく、移行条件、関連仕様、後続タスクの開始条件にも影響する。会話の中だけで決定すると、次の AI はその判断を知らずに古い仕様を再び前提にする可能性がある。人間の判断も、前章までで扱った確定状態と同じように、プロジェクト側の正本や関連文書へ戻す必要がある。

この更新によって、人間の判断は一回限りの回答から、後続作業が利用できる新しい規則へ変わる。次の AI は、人間がどの会議で何を議論し、なぜ三案のうち一つを採ったのかをすべて追体験しなくてもよい。正式に採用された条件と、その条件が適用される範囲が外部に残っていれば、それを新しい確定済みの入力として作業を再開できる。

この循環では、停止は作業の失敗ではない。AI が既に決まっている規則の範囲で調査、実装、検証を進め、その規則だけでは確定できない地点で未確定状態を保持したまま人間へ返す。人間は新しい判断だけを行い、その結果をプロジェクトの確定状態へ追加する。AI は更新された規則を入力として再開し、再び実装可能な範囲を進む。

停止条件が存在しないと、AI の自律性を高めるほど未決定事項まで自動的に確定される危険が増える。反対に、すべての判断を人間へ戻せば、AI は長い作業を任せられる存在にならない。両者の間にある実用的な境界は、AI が難しいと感じる地点ではなく、現在ある規則から新しい確定状態を導けるかどうかである。

ここまでで、中～大規模開発を継続して委任するための構造はほぼそろう。未確定状態を検証可能なタスクへ変え、現在状態を外部へ残し、実装の自由と判断権限を分け、同時に増やす未確定変更を制御し、指示と実行制約と成果物検査を分離し、証拠がそろった地点だけを完了とする。そして、そのルールだけでは完了条件を確定できない場合に人間へ戻す。次に確認するのは、これらの原理が具体的な AI 開発のタスク管理手法をどのように説明できるかである。

10. 具体的なタスク管理手法は、未確定状態を閉じる機構として読める

ここまでの議論は、特定のファイル形式、課題管理サービス、AI コーディングエージェントの製品機能を前提にしていない。必要なのは、現在状態を一つの正本へ戻せること、同時に存在する未確定変更を制御できること、一件ごとに完了条件と停止条件を持てること、そして完了条件を外部から確認できる証拠へ対応付けられることである。この条件を満たすなら、状態を保存する場所や作業空間の作り方には複数の実装があり得る。

この構造を具体的な AI 開発へ落とした一例として、Y-Y-dev 氏は Claude Code と Codex に中～大規模開発を任せるためのタスク管理方法を提示している[21]。そこでは、リポジトリ側に進捗の正本を置き、同時に進める作業を制限し、各タスクについて目的、変更範囲、禁止事項、完了条件、テスト方法、停止条件を明示する。さらに、コードを書いた時点では終了とせず、テスト、文書、差分確認、Git の記録までを一つの作業単位として閉じる。

これらを手順だけで読むと、「進捗を一か所へ書く」「同時作業を一件に近づける」「各タスクへ必要事項を記載する」「最後に Git へ残す」という個別の運用規則に見える。しかし、前章までで導いた構造へ戻すと、それぞれが異なる失敗経路を抑えるための機構として説明できる。正本は現在状態の分裂を防ぎ、進行中作業の制限は未確定変更の増加を抑え、完了条件は確定判定の基準を作り、停止条件は AI の判断権限がプロジェクト方針へ越境することを防ぐ。

具体的な運用 本稿の構造での意味 直接防ぐ失敗 残る条件
進捗の正本を一つ置く 変化する現在状態を会話や担当 AI の外へ外部化する。 複数の会話や記録が異なる現在状態を主張し、次の作業が古い前提から始まることを防ぐ。 正本に何を記録するか、誰がいつ更新するかは別途定める必要がある。
タスクを一意に識別する 要求、変更、検証結果、履歴を時間方向に同じ一件として結ぶ。 似た作業名、複数セッション、複数の差分の間で同一性を失うことを防ぐ。 識別子だけでは現在状態を示せないため、正本側の状態管理と組み合わせる必要がある。
進行中作業を制限する 同時に存在する未確定状態の数を、検証可能な範囲へ抑える。 AI の生成速度が検証速度を上回り、未確認の差分と依存関係が蓄積することを防ぐ。 独立して確定できる作業まで一律に直列化すると、利用可能な並列性を失う。
完了条件を定める 未確定状態から確定状態へ移るための判定規則を置く。 「実装した」「テストした」という作業報告が、そのまま完了判定へ置き換わることを防ぐ。 完了条件そのものが観察可能で、対応する検証方法を持っていなければ判定できない。
停止条件を定める 既存の仕様、権限、判断軸だけでは一意に確定できない地点を定義する。 AI が実装判断を越えて、仕様、互換性、データ方針を暗黙に決めることを防ぐ。 停止後に人間が判断した結果を、正本や仕様へ戻さなければ同じ未確定状態が再発する。
作業空間を分ける 並列実装時の未確定な差分を物理的に隔離する。 一方の未コミット変更が別のタスクへ混入し、どの差分を検証したのか分からなくなることを防ぐ。 共通 API やデータモデルなど、論理的な依存関係までは隔離できない。
テスト、差分、Git の履歴を残す 完了条件を、再確認できる外部証拠へ対応付ける。 AI の自己申告だけで未確定な成果を確定済みとして扱うことを防ぐ。 それぞれの証拠が何を確認でき、何を確認できないかを区別する必要がある。

この対応を見ると、具体策の価値は名称や形式にはない。進捗を保存する場所が専用ファイルである必要はなく、同じ現在状態を一意に管理できるなら課題管理システムやデータベースでも成立する。必要なのは、「どの記録が正式な現在値か」が一つに決まり、次の担当者や AI がそこから作業を再開できることである。

進行中作業を一件に制限するという運用も、数字の一件そのものを一般則にする必要はない。第 6 章で見たように、読み取り中心の調査や論理的に独立した変更なら、複数を並列に進めてもそれぞれを単独で確定できる場合がある。反対に、共通 API やデータモデルへ触れる変更は、二件であっても互いの前提を変える。制限する対象は作業数という数字ではなく、同時に存在する未確定状態と、その間に生じる依存関係である。

同じことは、タスクへ記録する項目にも言える。目的、変更範囲、禁止事項、完了条件、停止条件という項目名自体が本質なのではない。これらが必要になるのは、一件の仕事について「何を成立させるか」「どこまで AI が判断してよいか」「何を観察すれば確定できるか」「どこから先は新しい判断になるか」を分離するためである。別の管理方式でも、この四つの問いへ同じように答えられるなら、機能的には同じ構造を持てる。

具体的な方法をこの水準まで抽象化すると、手順の適用条件も見える。小規模な修正で、開始から検証までを一つのセッションで閉じられ、依存する後続作業も存在しないなら、厳密な状態管理へ大きなコストをかける必要はない。反対に、複数日にまたがり、担当する AI が変わり、外部環境の確認を待ち、別タスクがその結果へ依存する開発では、現在状態を外部化しないまま会話だけで継続することの方が管理コストを高くする。

この違いは、手法を採用するかどうかを「便利そうだから」で決める必要がないことも示している。作業が一つの会話を越えるか、未確定な成果を別作業が参照するか、複数の変更を並列に進めるか、AI だけでは決められない停止地点があるか、といった条件を見れば、どの管理機構が必要になるかを判断できる。具体策は、開発規模そのものではなく、未確定状態が時間と依存関係をまたいで残る程度に応じて選べる。

この読み方をすると、Y-Y-dev 氏の方法をそのまま一般則として複製する必要もなくなる。そこに示された運用は、AI コーディングエージェントを使った中～大規模開発で実際に生じる管理上の問題に対し、現在状態の外部化、未確定作業の制御、判断境界の明示、証拠による完了判定を具体的な形へ落とした一例として評価できる[21]。

逆に、この構造を満たしていない運用は、表面的に同じ道具を使っても同じ効果を持たない。進捗の正本を用意しても更新されなければ現在状態にはならず、識別子を振っても要求と差分が結び付かなければ追跡可能性は生まれない。作業空間を分けても論理依存を無視すれば統合時に未確定状態が再び合流する。テストを大量に実行しても、完了条件と対応していなければ「何を確認したのか」は確定しない。

手法の名前ではなく、どの未確定状態を、どの機構によって、どの証拠で閉じているかを見る。この評価軸を持てば、特定製品の機能が変わっても、別の AI コーディングエージェントへ移っても、同じ管理原理を維持できる。必要なのは特定の運用を模倣することではなく、その運用が成立させている状態遷移を別の環境でも再現することである。

11. 中～大規模開発を任せるとは、確定した状態を連続して積み上げることである

ここまで扱ってきた要素は、個別の運用規則として並べるより、一つの状態遷移として捉えた方が分かりやすい。最初に大きな要求を、後続作業が独立して利用できる検証単位へ分ける。その一件について開始条件、変更範囲、完了条件、停止条件を定め、現在どこまで確定しているかをプロジェクト側の正本から取得する。AI が作業を始める時点で必要なのは、過去の会話をすべて再現することではなく、現在の確定状態と、そこから閉じるべき未確定状態を特定できることである。

実装前の調査で当初の前提が崩れた場合も、そのまま開始時の指示へ押し込まない。たとえば局所的な API 修正だと考えていた変更が、既存データ、外部クライアント、権限体系まで影響すると分かれば、最初に定義したタスク境界では一件を閉じられない。ここで変更範囲を暗黙に広げると、AI は実装方法だけでなく要求そのものを変更することになる。反対に必要な変更を省けば、表面的な実装だけが完成し、後続作業へ不完全な前提を渡す。調査で得た新しい事実は、現在状態やタスク境界を更新する材料として扱う必要がある。

実行段階では、AI が作れる差分の数と、プロジェクトが確定できる差分の数を分けて考える。互いに独立した調査や変更なら並列に進められるが、共通 API やデータ構造を変更する複数の作業を同時に未確定のまま進めれば、個々の差分だけでなく変更同士の関係まで検証対象になる。作業空間を分けることで差分の混入は防げても、論理的な依存関係までは消えない。並列化の上限は、AI が同時に何件実行できるかではなく、それぞれを独立した証拠で確定できるかによって決まる。

一件の実行中に使う制御も、同じ場所へ集約しない。複数のタスクへ繰り返し適用する規約は恒常的なプロジェクト指示へ置き、現在の一件に固有の目的や変更範囲はタスク定義へ置く。本番環境への直接変更や破壊的操作のように、違反時の影響が大きく判定条件が明確なものは、可能な範囲で実行権限や機械的な制約へ移す。生成されたコードが要求を満たすかどうかは、テスト、差分確認、静的検査、必要な実環境確認によって別に判定する。AI に理解させる条件、実行を止める条件、受入時に検査する条件では、失敗の種類が異なる。

コードが生成された時点でも、一件はまだ閉じていない。完了条件が「権限を持たない利用者には 403 を返し、データを変更しない」であれば、対象テストが応答コードだけでなく保存状態まで確認している必要がある。ローカル環境では再現できない認証基盤との結合が残っていれば、その条件は未確定のままである。Git の差分は変更範囲を示し、対象テストは今回の要求を確認し、回帰テストは既存挙動への影響を確認する。それぞれ異なる問いへ答える証拠であり、一つの「テスト成功」という報告へまとめると、どこまで確定したのかが見えなくなる。

必要な証拠がそろえば、その一件を確定状態へ移し、正本と履歴を更新する。ここで初めて、後続タスクはその成果を既知の前提として利用できる。証拠が不足している場合には、何が不足しているかによって次の操作が変わる。まだテストしていないなら AI が作業を続けられる。実環境でしか確認できないなら検証待ちとして残す。仕様同士が矛盾し、どちらを正とするか決めなければ完了条件そのものを確定できないなら、人間へ判断を戻す。

人間へ戻す場合も、作業を初期状態へ戻す必要はない。AI が調査済みの事実、現在の差分、選択肢、それぞれの影響、再開に必要な判断を残せば、人間は未確定の方針だけを決められる。その判断結果を正本や関連仕様へ反映すれば、新しい規則が確定状態としてプロジェクトへ追加される。次の AI は、その判断に至った会話や思考過程を完全に追体験しなくても、更新された条件を入力として同じタスクを再開できる。

段階 扱う未確定状態 確定させるための操作 次へ進む条件
要求整理 大きな要求の中に複数の完了条件や判断が混在している。 後続作業が独立して利用できる検証単位へ分け、開始条件、変更範囲、完了条件、停止条件を定める。 一件について何を成立させれば閉じられるかを外部から判定できる。
着手 現在位置や依存関係が、会話や複数の記録へ分散している可能性がある。 正本から現在状態、依存関係、残条件を読み、開始点を確定する。 先行条件が成立し、現在の一件を開始してよいことを判断できる。
実装前確認 開始時に想定したタスク境界が、実際のコードやデータ構造と一致するか分からない。 影響範囲、互換性、必要な検証、不明点、戻し方を調べる。 現在の判断権限内で完了条件まで到達できる見通しが立つ。
実装 目的を成立させる変更がまだ存在せず、作業中に新しい事実が判明する可能性がある。 定義した範囲で変更し、別問題や新しい方針判断を現在のタスクへ暗黙に混入させない。 必要な差分がそろい、停止条件に該当していない。
検証 生成された差分が、要求、既存挙動、実環境条件を満たすか未確定である。 完了条件を対象テスト、回帰テスト、差分、必要な実環境確認へ対応付ける。 確定済みの条件と残る未確認事項を第三者が再確認できる。
判断返却 現在ある仕様や権限だけでは完了条件を一意に確定できない。 確定済みの事実、選択肢、影響、再開条件を残し、新しい方針判断だけを人間へ戻す。 判断結果が正本や関連仕様へ反映され、新しい確定済みの入力になる。
完了 一件の成果を後続作業の前提として利用してよいかがまだ確定していない。 完了条件と証拠の対応を確認し、状態と履歴を更新する。 後続作業がその成果を確定済みの前提として利用できる。

この循環で蓄積されるのは、AI の会話履歴そのものではない。各タスクについて、どの前提から始まり、どの変更が採用され、何を確認し、どの判断が確定したかというプロジェクト側の状態である。セッションが切れても、担当するモデルが変わっても、正本、識別子、Git の履歴、検証結果から現在位置を復元できれば、過去の思考過程を再生せずに続きから始められる。

この違いは、中～大規模開発で特に大きい。一件の短い修正なら、一つの会話の中に調査、実装、検証の文脈を保持できる場合がある。しかし数十件、数百件の変更を数日、数週間にわたって進めれば、同じセッションや同じモデルが最初から最後まで内部状態を保持することを前提にできない。開発の継続性を AI の記憶へ依存させれば、セッション変更や文脈の欠落がそのままプロジェクト状態の欠落になる。確定状態を外部へ残せば、AI の内部状態と開発状態を切り離せる。

AI の能力が上がっても、この構造は不要にならない。より長い時間を自律的に動き、多数のファイルを変更し、複数の作業を並列に実行できるようになれば、人間が一手ずつ操作する必要は減る。その一方で、未確認の変更を生成する能力も同じように高くなる。生成できる差分の量が増えるほど、どの成果が確定済みで、どの成果がまだ検証待ちで、どの判断だけが人間を必要としているかを外部から判定できなければ、プロジェクト側の不確実性も速く増える。

その意味で、中～大規模開発における AI の能力を、一回に処理できる仕事の大きさだけで測るのは不十分である。一件を長く実行できても、途中で生じた未確定状態を後続作業へそのまま流せば、長く動けることが長期開発の安定性にはならない。反対に、一件ごとに確定点を作り、その地点から次のタスクを始められるなら、個々のセッションが有限でも開発全体は長く継続できる。

既稿の上流工程管理から本稿までを通して見ると、管理対象の移動は一貫している。上流工程では、作業量ではなく不確実性、意思決定、依存関係、後続への着手可能性を管理した[5]。AI コーディングでは、その原理を実装と検証の領域まで延長し、未確定な差分や判断を後続へ流さず、一件ごとに証拠で閉じる。AI によって変わるのはこの原理ではなく、未確定な成果を生成し、依存関係へ流し込める速度である。

AI に中～大規模開発を任せる能力とは、大きな要求を一度に処理させる能力ではない。開発中に生じる未確定な状態を、判断可能で検証可能な単位へ変換し、証拠によって一件ずつ確定状態へ移し、その確定結果を次の仕事の入力として積み上げ続ける能力である。AI が長く働けることより、AI が途中で作ったものをプロジェクトが一件ずつ確定して引き継げることの方が、中～大規模開発を継続して任せる条件になる。

参考文献

  1. Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, Karthik Narasimhan, SWE-bench: Can Language Models Resolve Real-World GitHub Issues?（2023-10-10）. https://arxiv.org/abs/2310.06770
  2. Tue Le, Minh V. T. Thai, Dung Nguyen Manh, Huy Phan Nhat, Nghi D. Q. Bui, SWE-EVO: Benchmarking Coding Agents in Long-Horizon Software Evolution Scenarios（2025-12-20）. https://arxiv.org/abs/2512.18470
  3. Thomas Kwa et al., Measuring AI Ability to Complete Long Software Tasks（2025-03-18）. https://arxiv.org/abs/2503.14499
  4. Aayush Kumar, Yasharth Bajpai, Sumit Gulwani, Gustavo Soares, Emerson Murphy-Hill, Why AI Agents Still Need You: Findings from Developer-Agent Collaborations in the Wild（2025-06-14）. https://arxiv.org/abs/2506.12347
  5. id774, 上流工程を管理する三層・反復型マネジメント（2026-07-22）. https://blog.id774.net/entry/2026/07/22/5088/
  6. id774, 未整理の条件を、判断できる形に変える（2026-07-04）. https://blog.id774.net/entry/2026/07/04/4935/
  7. OpenAI, Best practices（2026-08-13 確認）. https://developers.openai.com/codex/learn/best-practices
  8. Anthropic, How Claude remembers your project（2026-08-13 確認）. https://code.claude.com/docs/en/memory
  9. id774, AI に任せる前に、人間が残すべき判断（2026-06-21）. https://blog.id774.net/entry/2026/06/21/4912/
  10. id774, Devin と Claude Code の違いは、作業の任せ方にある（2026-07-09）. https://blog.id774.net/entry/2026/07/09/4967/
  11. Anthropic, Choose a permission mode（2026-08-13 確認）. https://code.claude.com/docs/en/permission-modes
  12. id774, この物量の文章を、一体誰が検証できるのか（2026-07-30）. https://blog.id774.net/entry/2026/07/30/5160/
  13. John Coleman, Daniel Vacanti et al., The Kanban Guide（2025-05-01）. https://kanbanguides.org/the-kanban-guide/2025.5/
  14. Git Project, git-worktree Documentation（2026-08-13 確認）. https://git-scm.com/docs/git-worktree
  15. OpenAI, Worktrees（2026-08-13 確認）. https://developers.openai.com/codex/environments/git-worktrees
  16. OpenAI, Custom instructions with AGENTS.md（2026-08-13 確認）. https://developers.openai.com/codex/agent-configuration/agents-md
  17. Anthropic, Hooks reference（2026-08-13 確認）. https://code.claude.com/docs/en/hooks
  18. OpenAI, Rules（2026-08-13 確認）. https://developers.openai.com/codex/rules
  19. id774, AI の答えは、採用されたときに責任になる（2026-06-26）. https://blog.id774.net/entry/2026/06/26/4925/
  20. GitHub, Approving a pull request with required reviews（2026-08-13 確認）. https://docs.github.com/en/pull-requests/how-tos/review-pull-requests/approving-a-pull-request-with-required-reviews
  21. Y-Y-dev, Claude Code／Codexに中～大規模開発を任せるためのタスク管理（2026-08-02）. https://qiita.com/Y-Y-dev/items/d526fb7cdbe35a3f9384