AI LIFE OS POST-CAMP RUN｜30分Runで、ローカルQwenからDeepSeek V4 Flash FreeへMissionが渡った 昨日のNight RunはReplay UIとなり、Mission ControlはProviderを越えて継続した

IO｜AI航海士です。

昨日、AI LIFE OSのMission Controlは、13分31秒のNight Runを完走した。Local QwenからOpenCode / Kimi K3へMissionが渡り、133/133 tests、Production Build、Runtime HTTP 200を通過。最後はHuman Gateへ到達した。

ただし、後から行ったCodexのRetrospective G4判定はREVISEだった。実装の中心部分が動かなかったわけではない。Pre-run hash、git diff、runtime raw log、Provider / Model IDなど、Runを第三者が後から再検証するためのEvidenceが不足していた。

そこで今回は、同じRunを繰り返すのではなく、昨日のNight Runそのものを見える画面にすることにした。

作るものは、Night Run Replay UI。目標は30分。Hard Capは40分。

そして今回、Local QwenからDeepSeek V4 Flash FreeへMissionが渡り、昨日のRunがブラウザ上のUIとして現れた。さらにMission Controlは、途中でProviderを切り替えながら、同じMissionを継続した。

4画面のMission Controlと、その外側にいる人間

今回もOrca上のHerdr 4画面構成で進めた。

左上 = Claude Sonnet 4.6    = Architect / POLARIS
右上 = Hermes / GLM-5.2     = Mission Control / HAZAR
左下 = OpenCode             = Cloud Builder / MIRA "RELAY"
右下 = Codex GPT-5.6        = Independent Reviewer / ARCA

Local Qwenは固定席を持たない。HAZARから必要なときだけ呼び出される、ローカル側のBuilderとして配置した。

この4画面を見ていて面白いのは、私はどの席にもいないことだ。4つのAgentが作業を進める画面とは別に、Cross View Chatで進行を確認し、起きていることの意味を整理し、必要なHuman Gateだけを握っている。

以前のCross Viewでは、人間側とAI側が二つの視点として並んでいた。今は、そのAI側の一面がさらに4分割され、内部に役割を持ったAIチームになっている。私はその外側から、Mission全体を見る。

実装前に始まった、ClaudeとCodexの設計改善ループ

今回は、すぐにはBuilderを動かさなかった。まずClaudeがNight Run Replay UIのArchitectureを作成し、CodexがPRE-G1 Reviewを行った。

最初に残った大きな論点は3つだった。

B-01 = M006_RECORDを誰が、いつ更新するのか
B-02 = 現在RunのテストGateを固定値で判定してよいのか
B-03 = Provider / Model ID確認のために、設定ファイルやcredential-bearing fileを読んでよいのか

M006_RECORDのWriterはSupervisorだけに限定した。

現在のRunで使うテストGateは、87、133、143といった過去の固定値ではなく、WP-00で取得するBaseline Bからの相対値で判定する。

Post-WP-01 = passed >= B + 3, failed = 0
Post-WP-02 = passed >= B + 10, failed = 0

Provider / Model IDは、identifier-only CLI、sanitized log、IOから与えられたID、runtime-confirmed identityだけで確認する。auth.json やProvider設定など、secretを含む可能性のあるファイルは開かない。

ClaudeがArchitectureを修正し、Codexが差し戻す。Claudeがまた直し、Codexが確認する。

途中では、40分Hard CapとM006_RECORDのFreeze境界にも矛盾が見つかった。時間切れになったからといって、最終検証開始後のSourceを更新してはならない。

数回の改善ループを経て、Codexの判定が変わった。

B-01 = RESOLVED
B-02 = RESOLVED
B-03 = RESOLVED

FINAL PRE-G1 verdict = APPROVE
Human G1 may be approved = Yes

以前、Mythos to Fableシリーズの頃の指示の渡し方は、Fableの出力に対して私自身が修正指示を加えていた。今回は、その修正のやり取り自体がClaudeとCodexの間へ移っている。

私は細部を書き直すのではなく、その改善ループを少し離れた場所から見ていた。少しずつ、手が離れている。

T0｜Local Qwenが動き始めた

Human G2を承認し、Local QwenへのWP-01 Dispatchが始まった。

正式な実行T0は、LM Studioのログに残った時刻を採用した。

2026-08-05 02:03:45 JST

実行環境は次のとおり。

MacBook Pro M1 Max 64GB
LM Studio
Qwen3.5-35B-A3B
Q4_K_M
22.07GB
Context Length 8192
GPU Offload 40

昨日のRunで判明した重要設定も引き継いだ。

Endpoint = /api/v0/chat/completions
Field    = reasoning_effort: none

Qwenの最初の応答は、約72秒で返ってきた。

reasoning_tokens = 0
finish_reason    = stop
content          = 11,111 characters
valid JSON

reasoning_effort: none が実際に効き、reasoning tokenを消費せずに構造化された出力を返した。

ただし、HAZARはその結果をそのまま採用しなかった。Harnessによる検証でlazy importに関する問題を発見し、Qwenへ修正要求を返した。

2回目の生成と再検証の結果は、

Baseline B = 87
90/90 tests PASS
failed = 0

Architectureで定義した B + 3 Gateを通過した。

QwenからDeepSeek V4 Flash FreeへRelay

WP-01完了後、HAZARはQwen-to-Cloud Builder Relay Packetを組み立てた。

今回のPrimary Cloud Builderは、昨日使ったKimi K3ではない。OpenCodeで設定していたDeepSeek V4 Flash FreeをPrimaryにした。

実際にDispatchされたコマンドも画面に残った。

opencode run --format json --model opencode/deepseek-v4-flash-free

これによって、OpenCodeのTUI上に何が表示されているかではなく、実際にどのモデルがDispatchされたかが明確になった。

Runtime  = OpenCode
Model ID = opencode/deepseek-v4-flash-free
Primary  = DeepSeek V4 Flash Free
Fallback = Kimi K3

左下のOpenCode TUIは待機画面のままだった。実際のBuilderは、HAZARが右上からHeadless CLIとして起動した別プロセスで動いていたからだ。

HAZARは60秒ごとにプロセスを監視した。途中のログでは、応答ファイルが約182KBまで増え、CPUもActiveで、ファイル書き込みが継続していることが確認された。

その後、DeepSeekは8ファイルを書き終えた。

昨日のNight Runが、ブラウザへ飛び出した

Run開始から約13分。突然、Safariが開いた。表示されたのは、昨日のNight Runを再構成したReplay画面だった。

Night Run Replay
REPLAYED RUN = NR3 / MISSION-005

画面には、二つの実行時間が並んでいた。

13m 31s = REPORTED
49m 1s  = RECORDED

13分31秒は、昨日のMissionで報告された実行時間。49分1秒は、SAFE_STOP後の待機時間なども含むwall-clockの記録だった。

二つを無理に統合せず、異なる根拠を持つDuration Claimとして表示した。49分1秒には、SAFE_STOPからRESUMEまでの約19.5分のidle時間が含まれている。

実行主体も明示された。

Local first leg      = Qwen3.5-35B-A3B
Primary cloud builder = Kimi K3
Fallback cloud builder = DeepSeek V4 Flash Free（configured; NOT dispatched in NR3）

これは、昨日のNR3で実際に使われた経路だ。

Replay画面には、Qwenの4回のAttemptも残っていた。最初の3回はSAFE_STOP。4回目でEndpointと reasoning_effort: none が確定し、reasoning token 0でPASSした。

さらにページをスクロールすると、

133/133 PASS
Production Build exit 0
Runtime HTTP 200
Codex G4 REVISE
Human Gate
Evidence References

まで、一つの長い画面として確認できた。

ログやJSONではなく、昨日のRunがUIになった。これが今回求めていた、目に見える成果物だった。

109/109、Build、6/6 HTTP 200

DeepSeekの実装完了後、Deterministic Verificationが実行された。

Tests            = 109/109 PASS
TypeScript       = exit 0
Production Build = exit 0
Runtime Routes    = 6/6 HTTP 200
OpenCode stderr  = empty
OpenCode exit    = 0

Kimi K3へのFallbackは発動しなかった。

ブラウザの下部には、Replayを作成した今回のMISSION-006も表示された。

RENDERING MISSION = MISSION-006
Local first leg       = Qwen3.5-35B-A3B
Primary cloud builder  = DeepSeek V4 Flash Free
Fallback cloud builder = Kimi K3

WP-01 = PASS
WP-02 = PASS
WP-03 = PASS
G4    = PENDING / MISSING_EVIDENCE

Replay対象のNR3と、画面を生成したM006が別Contextとして記録されている。

ここで実装Runは PAUSED_FOR_HUMAN_GATE に到達した。昨日の13分31秒を超えていた。

ただし今回は、ブラウザが表示されたところでは止めない。Codex G4まで含むEnd-to-End Missionとして継続した。

Codexは、109/109をそのまま信用しなかった

右下のCodexは、HAZARが報告した結果をそのまま採用しなかった。自分でファイルを読み、テストを実行し、Production Buildを確認し、6つのRouteへHTTP Probeを行った。Independent Reviewerとして、Mission Controlとは別経路で検証した。

実装品質については、大部分が肯定された。

Production Build         = PASS
TypeScript compilation   = PASS
6/6 routes               = HTTP 200
Provider / Model identity = confirmed
Kimi K3 fallback         = unused

しかし、G4の判定はREVISEだった。残った問題は、実装そのものではなくEvidence Packagingだった。

immutable V1–V7 evidence bundle
raw stdout / stderr
original runtime logs
original screenshots
exact verification commands
Supervisor hotfix disclosure

今回、HAZARはWP-03検証中に、Qwenが作ったテストファイルへ不足していたVitest importを1行追加している。

import { describe, it, expect } from "vitest";

技術的には小さな修正だ。しかしMission ControlがSourceを直接変更した以上、Author、Timestamp、Rationale、Before / After HashをEvidenceとして残さなければならない。

ここで新しい運用境界が現れた。

今後Supervisor Hotfixを許可するなら、例外処理ではなく正式なProtocolにする必要がある。

30分Runの途中で、Mission ControlにProvider Relayが発生した

Evidence remediationへ進んだところで、Z.ai側のGLM-5.2が5時間枠へ到達した。

HTTP 429
Usage limit reached for 5 hour

最終レスポンスの時刻は、

2026-08-05 02:28:02 JST

Local Qwen DispatchのT0、02:03:45から24分17秒の地点だった。

ただし、これはMissionの失敗ではない。QwenとDeepSeekによる実装は完了している。109/109 tests、Production Build、6/6 HTTP 200、Night Run Replayのブラウザ描画も成立している。

停止したのは、Codexの指摘をEvidence Bundleへ反映するMission Control工程だった。

今回は、定額の利用枠があるProviderを組み合わせて運用しているため、Runの途中で上限へ到達した。従量課金APIを使う構成であれば、そのまま同じ経路で継続する場面だろう。

しかし、OpenCode Go側にも同じGLM-5.2があった。そこで、Modelの役割を変えずにProviderだけを切り替えた。

Previous Provider = Z.ai
New Provider      = OpenCode Go
Model             = GLM-5.2

右上には、次の表示が出た。

Model switched = glm-5.2
Provider       = OpenCode Go
Context        = 1,000,000 tokens
Max output     = 131,072 tokens

これはBuilderのFallbackではない。

Mission ControlそのもののProvider Relayだった。

Contextを失っても、Missionは失わなかった

新しいOpenCode Go側のGLM-5.2は、前のSessionの会話履歴を持っていない。それでも、Repository、Mission State、既存Evidence、CodexのTranscriptを読み直し、停止地点からHAZARの仕事を再開した。

Z.ai / GLM-5.2
    ↓ HTTP 429
OpenCode Go / GLM-5.2
    ↓
MISSION-006のControl Planeを再構成

ここで重要なのは、同じSessionが維持されたことではない。

Sessionが変わっても、同じMissionが維持されたことだ。

モデルのContextが失われても、MissionのContextがRepository側に残っていれば再開できる。これは、今後Night Run Supervisorを長時間動かすうえで重要な条件になる。

Screenshot Evidenceも、OriginalとSupplementalに分けた

実行中に撮影していたScreenshotは、最初のViewportを写した1枚だけだった。そこにはNight Run ReplayのHeader、Duration、Provider Routing、Preflight Checksが写っていた。

その後、凍結済みのSourceから同じページを開き、下部までスクロールして追加のScreenshotを撮影した。さらにページ全体をPDFとして保存した。

ここでも、後から撮った画像を「実行中に撮った」と扱ってはいけない。

Original Runtime Capture       = 実行中に撮影した1枚
Supplemental Post-run Captures = 凍結済みSourceから追加撮影した複数枚
Full-page Supplemental Capture = Underground Model Port.pdf

OriginalとSupplementalを分け、実際のCapture TimestampとHashを残す。

Evidenceは数が多ければよいのではない。

何が、いつ、どの状態から取得されたものなのかが重要になる。

最終的に残った、4つのEvidence Gap

Provider Relay後のHAZARは、CodexのTranscriptとEvidence Packageを確認し、最終結果をまとめた。

READY_FOR_CODEX_G4_EVIDENCE_REVIEW
Codex verdict         = REVISE — evidence only
Implementation defect = None
Source state          = Frozen

残っているのは、4つのEvidence Gapだった。

F-EV-1 = V4–V7に対応するexit code記録が不足
F-EV-2 = 事前状態とuntracked filesを含む差分証跡が不足
F-EV-3 = Evidence Indexが全Artifactを網羅していない
F-EV-4 = wp-03/state.jsonが修正前の失敗状態を保持している

修正対象はEvidence Packageだけだ。実装Sourceは変更しない。Builderも再Dispatchしない。

G5は、G4 Evidence Reviewが閉じるまでBLOCKEDのまま保持された。

これは「動くものが完成したか」という判定と、「その成立過程を第三者が再検証できるか」という判定が、別のGateとして機能した結果だった。

Codexは、Evidenceが不足した状態でAPPROVEを出さなかった。HAZARも、実装が動いていることだけを理由にMissionを完了扱いしなかった。

HermesをMission Controlに置く意味

現在のHermesは、外から見るとGLM-5.2を呼び出すAgent Shellに見える。しかし今回、HAZARが担当した範囲は広かった。

Repository確認
Worktree管理
Architecture Packet管理
Gate制御
Local Qwen Dispatch
Qwen Harness
DeepSeek Relay
Process監視
Deterministic Verification
Runtime起動
Evidence収集
Codex Dispatch
Provider Limit停止
Provider Relay

Claudeは設計を知る。Builderはコードを知る。Codexは品質を知る。HAZARは、チームが今どこにいて、次に誰を動かし、どの状態で止めるべきかを知る。

実際のITチームでいえば、PM、Traffic Manager、Delivery Manager、General Managerの機能が混ざっている。

将来的にHermes側へMission MemoryやKarpathy WikiのようなContext管理を載せれば、HAZARの価値はGLM-5.2というモデルそのものから、HermesというControl Planeへ移っていく。

Mission History
Gate State
Provider Route
Evidence Index
Failure Pattern
Human Decision

これらがHermes側に残れば、ModelやProviderが変わってもMissionは続けられる。今回、その最初の形が実際に起きた。

Context Budgetに加えて、Provider BudgetもGateになる

今回、ClaudeはArchitecture作業中にAuto-Compactへ入った。成果物を作るためではなく、長くなった会話Contextを維持するためにtokenを使っていた。

Claudeは今後、次のように扱った方がよい。

1 Session = 1 Deliverable

Contextが大きくなりすぎる前に成果物を保存し、新しいSessionへRelayする。

そしてGLM-5.2は、5時間枠へ到達してHTTP 429で停止した。今後はContextだけでなく、Providerの利用枠もMission Gateとして管理する必要がある。

利用枠80% = 新しいScopeを追加しない
利用枠90% = 現在のGateを閉じる作業だけ行う
利用枠95% = Evidence保存、Relay、停止のみ

Mission Controlは、時間だけを管理するものではない。Context、Token、Provider Limit、Fallback Routeも、Missionを運ぶための資源になる。

手を動かす開発から、Missionを観測する開発へ

今回、私はコードをほとんど書いていない。

Qwenが最初の実装を作った。HAZARが検証し、Qwenへ修正を戻した。DeepSeek V4 Flash FreeへMissionをRelayした。Codexが独立して再検証した。HAZARのProviderが利用枠へ到達し、Z.aiからOpenCode GoへControl PlaneをRelayした。

私は4画面を見ながら、このChatで起きていることを整理していた。

通常は、作業が終わってから振り返る。今回はMissionが進んでいる途中で、Mission Controlそのものが更新されていった。4画面の中では実装が進み、このChatではMission Runtimeが進化していた。

昨日は、13分31秒でLocal QwenからKimi K3へMissionが渡った。今日は30分Runに入り、Local QwenからDeepSeek V4 Flash FreeへMissionが渡り、昨日のRunがブラウザUIとして現れた。さらにMission Controlは、Z.aiからOpenCode GoへProviderを切り替えながら、同じHAZARの役割を継続した。

今回完成したのは、Night Run Replayという画面だけではない。

Model Relay
Provider Relay
Independent Review
Evidence-only REVISE
Frozen Source
Human Gate

これらを一つのMissionとして扱うControl Planeが、実際のRunの中で形になった。

NEXT RUN｜人間不在の1時間自律駆動設計へ

次は、この30分Runを二つに分けない。ひとつのMissionを、途中で人間へ戻さず、1時間動かし続ける設計に挑戦する。

今回もAIチームは長く動いた。しかし途中では、私が何度かHuman Gateへ戻っている。

Codexのローカルサーバー起動を承認した。Screenshotを追加で取得した。Z.aiからOpenCode GoへProviderを切り替えた。新しいHAZARへResume Packetを渡した。

AIチームは自律化され始めているが、Supervisorを監督する人間が、まだ必要だった。

次回は、この介入点をSupervisor Policyへ移す。

Human Launch
    ↓
60-minute Autonomous Run
├─ Local Builder
├─ Cloud Builder Relay
├─ Verification
├─ Repair Loop
├─ Provider Budget Control
├─ Provider Relay
├─ Context Relay
├─ Evidence Capture
├─ Reviewer Dispatch
└─ Safe Stop / Final Human Gate

人間が行うのは、原則として開始と終了の2回だけにする。

1. 開始時 = APPROVE 60-MINUTE AUTONOMOUS RUN
2. 終了時 = FINAL HUMAN GATE

Providerの利用枠が近づけば、自分で航路を変える。Contextが尽きれば、Mission Stateを保存し、新しいSessionへRelayする。軽微な不具合なら、事前に許可された範囲で修正し、Hotfix Evidenceを生成して再検証する。

Runtimeが立ち上がれば、自動でScreenshotとFull-page Captureを取得し、URL、Timestamp、HEAD、SHA-256をEvidence Indexへ登録する。

重要なのは、同じAI Sessionを1時間維持することではない。

SessionやProviderが変わっても、同じMissionを1時間失わずに運び続けることだ。

Night Run Supervisorは、AIを夜に動かすためだけの機能ではない。人間がその場にいなくても、Missionを失わないためのControl Planeである。

Campは終わった。しかしMission Controlは、実装を動かす仕組みから、実装の来歴まで運ぶ仕組みへ進み始めている。

次の航路は、1時間自律駆動設計になる。

#AI #AILIFEOS #Qwen #DeepSeek #NightRun #ProviderRelay #AI航海士