AI LIFE OS Summer Intensive Training Camp Day 2 後半戦｜AIチームは、止まりながらMissionを完遂した 夜間自律運転を作るAIチームが、差し戻し、再検証、モデル交代、Human Gateを越え、ついにMISSION-003を閉じた

IO｜AI航海士です。

Day 2の前半、Night Run Supervisorは形になり始めていた。Claudeが設計し、HermesがMissionを制御し、Builderが実装し、Codexが差し戻す。

そこで見えてきたのは、複数のAIへ仕事を分担するだけでは、AIチームは成立しないということだった。

モデルは止まる。

無料枠は尽きる。時間枠は終わる。APIにはレート制限がある。長い出力は途中で切れる。使えていたモデルが突然使えなくなることもある。

それでも、Missionそのものを止めない。

Day 2後半戦で起きたのは、AIが止まらない世界ではなかった。

AIが止まっても、別のAIが続きを受け取り、Missionを前へ進める開発体制が成立し始めた夜だった。

#Now Listening…

Codexは、テストが通ってもGateを開けなかった

最初のG4レビューで、Codexは実装を差し戻した。

Builderが作ったNight Run Supervisorには、テストもあり、機能も動いていた。しかしCodexが問題にしたのは、テスト件数ではなかった。

実際のGit repositoryやworktreeを使わず、mockされた挙動だけで検証を通過できる可能性が残っていた。つまり、テストが成功したことと、現実の運用で正しく動くことの間に、まだ隙間があった。

CodexのVerdictは明確だった。

G4 REVISE — RETURN TO BUILDER

ここから、Focused Revisionが始まった。

Builderは、実際の一時Git repositoryとGit worktreeを作成する統合テストを追加した。branch、HEAD、dirty state、証拠ファイルの扱いまで、実環境に近い形で検証する。

修正後の統合テストは42件すべて通過した。

Real temporary Git repository/worktree integration:
42 passed

それでも、CodexはまだGateを開かなかった。

186件通っても、1件の失敗を無視しなかった

Fresh G3 Re-Verificationでは、Failure-modeを含む全体のテストが実行された。結果は、

186 passed
1 failed

失敗したのは、Mission一覧へ mission-003 の executing 状態が表示されないというCLIテストだった。

Builder側の実装ミスなのか。それとも、Mission Control側のregistry fixtureに存在する既存問題なのか。

ここでGemini 3.5 Flash LiteによるVerifierは、単純に「既知問題だから無視」とは判断しなかった。Builder worktreeと、修正前のbase HEADを比較し、同じテストを双方で実行した。

結果、base HEADでも同じ失敗が再現した。

Regression classification:
Pre-existing baseline / Mission Control registry fixture issue

Builderが変更できないMission Control領域の問題であり、今回の実装によるRegressionではない。そのため、この1件は非ブロッキングとして整理された。

G3は再検証を通過した。

G3 RE-VERIFICATION PASSED — READY FOR G4 RE-REVIEW

だが、Codexは再び差し戻した。

テストが通るだけでは、正しく検証したことにならない

二度目のG4で、Codexはさらに深い問題を見つけた。

一つは、runtime boundの扱いだった。Night Run Supervisorは、設定された時間内で処理を終了する必要がある。しかし残り時間が1秒未満になった場合でも、内部処理へ1秒を与えてしまう可能性があった。わずかな切り上げでも、厳密なruntime boundではない。

もう一つは、Builderが変更してよいrun directoryの範囲だった。現在実行中のrunだけではなく、過去のrunや無関係なrun evidenceまで、変更検知の除外対象になっていた。

テストは通っていた。しかし、そのテスト自体が欠陥を許していた。

Codexは、テスト結果ではなく、テストが何を証明しているかを見ていた。

The raw counts are reproducible,
but the claim that every mandatory correction was verified
is not supported.

二度目のVerdictも、

G4 REVISE — RETURN TO BUILDER

だった。ここでSecond Focused Revisionが始まった。

GLM-5.2は、二度目の修正を5分56秒で閉じた

Builder席ではGLM-5.2 Coding Planが稼働していた。今回の修正範囲は狭い。

GLM-5.2は、CodexのBlocking findingだけへ集中した。結果は、

Focused tests: 11/11 passed
Full suite: 186 passed
1 baseline fixture test deselected

そして、作業時間は5分56秒だった。

SECOND REVISION COMPLETE — READY FOR G3 RE-VERIFICATION

ここで見えてきたのは、モデルの能力比較ではなかった。

長い設計を考えるモデル。Missionを制御するモデル。狭い修正を高速で閉じるモデル。証拠の弱さを見抜くモデル。

AIチームは、全員が同じ能力を持つ必要はない。むしろ役割を固定し、Artifactを介して仕事を渡せる方が重要だった。

DeepSeekが止まり、GeminiがMission Controlを引き継いだ

Day 2のMission Controlは、当初DeepSeek V4 Flash Freeが担当していた。DeepSeekは長時間、Missionの状態を読み続け、G3検証、Gate更新、Artifact整理を進めていた。

しかし、やがてHTTP 429が発生した。

Rate limit exceeded

DeepSeekは停止した。

通常の単一エージェント運用なら、ここで作業全体が止まる。しかしMISSION-003では、状態は会話の中だけに存在していなかった。

architecture.md
state.json
registry/missions.json
revision-task-packet.md
g3-verification-result.md
g4-review-result.md
Builder worktree

Missionの状態はArtifactとGit worktreeに残っていた。

そこでHermesのProviderをGoogle AI Studioへ切り替え、Gemini 3.5 Flash LiteをMission Control席へ投入した。Gemini APIには無料枠があった。

ただし、Geminiにも癖があった。

そこで運転方法を変えた。

長いセッション        → Fresh Sessionへ切り替える
複数Artifactの一括更新 → 1ファイルずつ処理する
検証と永続化          → 別工程へ分ける
全テスト一括          → Focused test、Full suite、State更新へ分割する

Geminiは、一度にすべてを完了させるモデルとしては扱わなかった。1工程ずつ読み、実行し、停止する。TPM制限に当たったら待つ。再開時には同じ処理を再実行せず、まず結果が残っているか確認する。

止まる → 状態確認 → 未実行部分だけ再開

このRunbookによって、Geminiは無料枠のままVerifierとMission Controlを継続した。

モデルを変えるのではなく、仕事の形を変える

今回、大きな発見があった。

モデルが処理できないとき、すぐに強いモデルへ交換する必要はない。まず、仕事の形を変えられる。

Geminiが長いwrite_fileを完了できなければ、Artifactを1つずつ書かせる。TPMへ到達するなら、検証を段階化する。長い会話履歴が重いなら、Fresh Sessionを作り、必要なArtifactだけを読み直す。

これは、クラウドモデルだけの話ではない。ローカルLLMも同じだと思う。

ローカルにはAPI Quotaがない代わりに、

といった別の制約がある。

重要なのは、最も強いモデルを選ぶことではない。

そのモデルが完走できる粒度へ、Missionを再構成すること。

Night Run Supervisorの役割は、単なるモデル選択ではなくなってきた。

モデルの能力だけでなく、利用可能な時間、Quota、Context、出力長まで含めて、Missionを成立させる。これが、Supervisorの本体なのかもしれない。

三度目のG4で、コードは通った。しかし航海日誌が違っていた

Second Fresh G3では、修正内容を対象に再検証が実施された。

Unit and quota tests:               36 passed
Real-repository integration tests:  48 passed
Full Mission-003 suite:            118 / 118 passed
Static checks:                      PASSED
Main workspace integrity:           INTACT
Cache cleanup:                      VERIFIED

三度目のG4へ進んだ。Codexは、実装に新しいBlocking defectがないことを確認した。それでも、Verdictは再びREVISEだった。

原因はコードではなかった。

state.json と registry/missions.json の状態が一致していなかった。

一方にはG3 PASSEDと記録されている。もう一方には、以前のG4 REVISEとG3 supersededが残っている。

実装は正しい。テストも通っている。しかし航海日誌が事実と違う。

CodexはGateを開けなかった。

生真面目すぎる。だが、監査役としては正しい。

コードは通った。
テストも通った。
しかし記録が違うなら、Missionは完了していない。

Mission ControlはGovernance recordを修正した。

Second Fresh G3をPASSEDへ。
G4をpending final confirmationへ。
G5をpendingへ。Builder verifiedをtrueへ。
Second Revisionをlaunched / completedへ。

そしてCodexへ、実装レビューを繰り返さない、Governanceだけの最終確認を依頼した。

ついにVerdictが変わった。

G4 APPROVE — READY FOR G5 HUMAN GATE

最後に判断するのは、人間だった

G4を通過した後、最後に残ったのはG5 Human Gateだった。ここはAIが自動で進んではいけない。

Night Run Supervisor MVPを受け入れるか。残存リスクを許容するか。commitとmergeへ進むか。

IOがG5を承認した。

G5 APPROVED

ただし、すぐにはcommitしなかった。まずcommit対象を確認した。

実装commitへ含めるのは、

night-supervisor本体
config
dispatch
quota
report
supervisor
verify
README
各種unit test
real Git repository integration test

合計19ファイル。Mission Control側の証拠、Gate記録、state、registryは含めなかった。実装と監査証跡を分離した。

Builder commitは、

050b09067bc8fa91dada852af6a822c793ff3b40

mainへのmerge後のHEADは、

f7e1b5d530595a54b05f4e1502173798ac65d37b

だった。

その後、Mission Controlの証拠、G3、G4、G5、merge SHA、revision historyを別のclosure commitへまとめた。Closure commitは、

100b148cd57b094787b5a1b767266dc27e19afa1

最終状態は、

G3 Passed
G4 Approved
G5 Approved
Merged
Completed
Closed

そしてmainのworking treeはcleanになった。

MISSION-003 CLOSED — READY FOR WORKTREE CLEANUP DECISION

Night Run Supervisor MVPは、正式に閉じられた。

止まらないAIではなく、止まっても続くMission

Day 2で作ろうとしていたのは、夜間に自律実行するSupervisorだった。しかし実際の開発そのものが、そのSupervisorの必要性を証明していた。

DeepSeekが止まった。Grokの無料枠が終わった。GLM-5.2にも時間枠があった。GeminiはTPMと出力制限へ何度も到達した。Codexは三度も差し戻した。

それでも、Missionは落ちなかった。

理由は、知能が一つのセッションへ閉じていなかったからだ。

これが、Day 2後半戦で成立したものだった。

AI開発を長時間続けるために必要なのは、無制限のAPIでも、絶対に止まらないモデルでもない。止まることを前提に設計する。どこまで進んだかを外へ残す。次のAIが受け取れる形へ変換する。そして最後の判断だけは、人間が行う。

Night Run Supervisorは、AIチームによって実装された。同時に、AIチーム自身がNight Run Supervisorの最初の実証になった。

Day 2を終えて

Day 1では、複数のAIが一つのMission Controlになれるかを試した。Day 2では、そのAIチームが、

モデル停止
Quota枯渇
Provider切り替え
Builder交代
独立検証
Review差し戻し
Focused Revision
Governance修正
Human Gate
commit
merge
closure

まで、ひとつのMissionとして走り切った。

AI LIFE OS Summer Intensive Training Campは、単なる複数AIの同時起動ではなくなった。

AIの停止を前提に、人間の判断を残しながら、Missionを継続する開発システムへ変わり始めている。

Day 3では、この仕組みを実案件へ接続する。次は、仕組みを作るMissionではない。このMission Controlを使って、本物の成果物を完成させる日になる。

#AI #AILIFEOS #NightRunSupervisor #HumanGate #開発合宿 #AI航海士