AI LIFE OS Summer Intensive Training Camp 最終夜｜HermesがClaude Codeを起動した HerdrからClaude Codeへ。 AI Organizationが初めて自分で動き始めた夜

IO｜AI航海士です。

AI LIFE OS Summer Intensive Training Campの最終夜。

いきなり1時間の無人航行へ出たわけではない。まずは短いRunを二つ実施し、AI Organizationが実案件を安全に受け渡せるかを確認することにした。

Run 001では、Herdr上のHermesがClaude CodeをBuilderとしてDispatchし、Underground Model PortへVisual Foundationを導入する。Run 002では、その基盤を再利用し、DashboardのVisual Migrationを拡張する。

二つのRunで確認するのは、単なる実装速度ではない。

本格的な1時間Runを設計する前に必要な、基本航行データを取得するための実証だった。

#Now Listening…

前半戦で、Underground Model Portは実動MVPになった

この日の前半戦では、MISSION-004としてUnderground Model Portの実動MVPを完成させた。

Underground Model Portは、ローカルAIモデルを並べるだけのカタログではない。そのモデルが、起動できるのか、実用になるのか、AI LIFE OSのどの役割へ配属できるのかを、実測とEvidenceをもとに判断するためのCompatibility Labだ。

モデルごとに、

Launch → Usable → Assignable

を確認し、HAZARのBounty、Watchtower Weekly、Model Capsule、Assignment Mapへ接続していく。

MISSION-004では、ReactとViteによる実動MVPを構築した。Dashboard、Models、Model Capsule、Assignment Map、Watchtower。Underground Model Portの主要画面が、localhost上で動き始めた。

途中では、BuilderがFableからOpusへ切り替わった。Codexのレビューでは、コンポーネント単位の回帰テストとNot Found Routeが不足しているとして差し戻しが入った。修正後、テストは87件まで増えた。

Vitest         = 87 / 87 PASS
Production build = PASS
Runtime         = PASS

G3、G4、G5を通過し、MISSION-004は正式にCLOSEDした。

Underground Model Portという成果物だけを見れば、この時点で一つのMissionは完了していた。

ただし、Training Campで本当に作ろうとしていたものは、Webアプリ一つではない。複数のAIが役割を分担し、Missionを受け渡し、検証し、Gateを通過する。そのMission Runtime自体を、実案件の中で動かしたかった。

CLOSED Missionは、Night Runを受け付けなかった

当初は、完成済みのMISSION-004を対象にNight Run Supervisorを動かそうとした。すでに完成したUMPに対して、post-merge assuranceを自動実行する構想だった。

しかし、SupervisorはそのRunを受け付けなかった。判定は、

FAIL_BY_DESIGN

MISSION-003で作ったNight Run Supervisorは、ACTIVEなMissionを、

EXECUTING → PAUSED_FOR_HUMAN_GATE

へ進めるためのものだった。すでにCLOSEDしたMissionを再検証するAssurance Engineとしては設計されていない。

これは不具合ではない。Supervisorが、自分の責任範囲を越えて動かなかったということでもある。

そこで、Supervisor本来のLifecycleに合わせ、新しいMissionを立ち上げた。

MISSION-005｜UMP Visual Migration Foundation

新しいMissionは、MISSION-005 — UMP Visual Migration Foundation。

MISSION-004で完成した機能を維持したまま、Underground Model Portへ共通Visual Layerを導入する。全面的なデザイン変更ではない。既存のRoute、seed data、schema、model verdict、business logic、87件のテストを守りながら、今後の画面移行に再利用できる基盤を作る。

役割分担はこうなった。

Claude Sonnet 4.6        = Architect
    ↓
Hermes / GLM-5.2         = Mission Control
    ↓
Claude Code / Sonnet     = Builder
    ↓
Codex / GPT-5.6          = Reviewer

Claude Sonnet 4.6がArchitectureを作り、IOがG1を承認する。HermesがArchitectureを読み、G2 Packet、Builder Task Packet、専用worktree、Supervisor設定、停止条件を準備する。Claude CodeがBuilderとして実装する。Codexが最終的なReviewを担当する。

設計、指揮、実装、監査を、それぞれ別の席へ分けた。

Herdr上のHermesが、Claude CodeをDispatchした

この夜、最も大きかったのはここだった。

これまでもClaude Codeの内部では、複数のサブエージェントが動くことがあった。ただし、それは一つの製品内部で展開される並列処理だった。

今回は違う。Herdr上のHermesがMission Controlとして、

ところまで実行した。構造としてはこうなる。

Herdr
    ↓
Hermes / GLM-5.2
    ↓
Claude Code / Sonnet
    ↓
MISSION-005 dedicated worktree

Hermes自身が実装したわけではない。別Provider、別モデル、別プロセスで動くClaude Codeへ、Builderという役割を与えて仕事を委譲した。

画面上では、HermesがClaude Code Skillを選び、Task Packetを読み込み、専用worktree内でClaude CLIを起動した。

Training Campで掲げていた、

が、初めて目に見える形になった瞬間だった。

Night 0では、4つのAIを同じMission Controlへ並べるだけでも大きな出来事だった。最終夜には、その一つが別のAIへMissionをDispatchするところまで来た。

AIを複数使っているのではない。AI同士の間に、役割と委譲関係が生まれ始めた。

Run 001｜異種モデルDispatchとVisual Foundationを確認する

最初の短いRunでは、異種モデルDispatchと共通Visual Foundationの実装を確認した。

Claude Codeへ渡した範囲は、次のとおりだった。

Design Tokens
AppShell
Header
Navigation
PageContainer
Panel
StatusBadge
Dashboard Foundation
focused tests
production build
runtime verification

既存のUMPを大きく作り替えるのではない。今後の画面で再利用できるShellとDesign Systemを先に作る。

Claude Codeが実際に変更した主な内容は、

だった。変更後の結果は、

Existing tests     = 87
New focused tests  = 17
Total tests        = 104 / 104 PASS
Production build   = PASS
Runtime            = HTTP 200

既存87件のテストを維持したまま、17件のfocused testsが追加された。AppShell、Panel、StatusBadgeなど、今後の画面移行で使う共通部品も揃った。

Run 001では、

を確認できた。

Supervisorが見つけた統合境界

Builderの実装後、Night Run Supervisorによる独立検証へ進もうとした。そのPreflightで、Supervisorは停止した。

原因は、設定ファイルに記載されたClaude Code CLI名だった。

"builder_cmd": ["claude-code", "..."],
"quota_check_cmd": ["claude-code", "--version"]

実際の実行ファイルは、

claude

だった。そのためQuota Preflightで、

QUOTA_UNAVAILABLE
No such file or directory: 'claude-code'

となった。

Supervisorはexit code 2を返し、Runディレクトリへ、

supervisor.log
morning-report.md
morning-report.json

を残してSAFE_STOPした。

存在しないCLIを使って処理を継続することも、未検証の状態を成功扱いすることもなかった。統合境界の不整合を検出し、Evidenceを残して停止した。

設定を修正した後、完成済みworktreeに対して独立確認を行った。

Tests             = 104 / 104 PASS
Production build  = PASS
Runtime           = HTTP 200
Dependency changes = none
Main changes       = none

Run 001では、異種モデルDispatchと実装が成立した。同時に、Supervisorを実運用へ投入する際には、CLI名、起動引数、既存Builder resultの再利用、途中再開、検証フェーズだけの再実行など、実行環境との接続部分をさらに詰める必要があることも分かった。

Run 002｜継続実装とVisual Foundationの再利用性を確認する

Run 001の結果を確認した後、同じMISSION-005 worktree上で、二つ目の短いRunへ進んだ。

Run 002の目的は、Run 001で作った共通部品を、次の実装でも再利用できるかを確認することだった。対象は、

Summary / KPI
Current Core Models
Assignment Map
Active HAZAR Bounties
Watchtower Evidence
responsive baseline
accessibility baseline
focused tests

だった。

Run 001で作成した、

AppShell
Panel
StatusBadge
PageContainer
Design Tokens

を再利用し、既存のDashboard情報を、より明確な運用画面として再構成する。データ、Route、schema、model verdict、business logicは変更しない。Visual Layerだけを段階的に移行する。

Run 002では、新たに16件のテストが追加された。結果は、

Tests added       = 16
Final tests        = 120 / 120 PASS
Production build   = PASS
Runtime            = HTTP 200
Dependency changes = none
Commit / merge / push = none
Main changes        = none

Run 001の104件から、Run 002終了時には120件まで増えた。Visual Foundationを作るだけでなく、それを次のWork Packageへ引き継ぎ、実際のDashboardで再利用できることも確認できた。

Run 002では、

を確認した。

二つの短いRunが完了した

最終夜に実施した二つのRunの結果を整理すると、こうなる。

Run 001
87 → 104 tests
Visual Foundation実装
Production build PASS
Runtime HTTP 200

Run 002
104 → 120 tests
Dashboard Visual Migration拡張
Production build PASS
Runtime HTTP 200

Run 001では、異種モデルDispatch、専用worktreeでの実装、共通Visual Layerの構築を確認した。
Run 002では、その基盤を使った継続実装と、テスト増分、build、runtimeを確認した。

いきなり1時間の連続Runへ入るのではなく、まず二つの短い航行試験を行ったことで、

が見えてきた。

今回の二つのRunは、1時間Runの完成形ではない。

1時間Runを設計するための実証実験だった。

実測から、1時間Runを設計する

次に必要なのは、単一の大きなTask Packetではない。複数のWork Packageを順番に処理するQueueだ。

WP1 実装 → Focused Tests
    ↓
WP2 実装 → Focused Tests
    ↓
WP3 実装 → Full Tests
    ↓
Runtime / Evidence
    ↓
PAUSED_FOR_HUMAN_GATE

各Work Packageは、独立したTask Packetを持つ。Packetには、

変更対象ファイル
許可パス
再利用する共通コンポーネント
禁止事項
focused test
timeout
repair limit
success条件

を定義する。

Work Packageが完了したら、Queue Orchestratorがexit codeとテスト結果を確認する。

Work Package完了
    ↓
exit code確認
    ↓
focused test
    ↓
PASSなら次のPacket
FAILなら修正Packet
    ↓
最大回数を超えたらSAFE_STOP

タスクの切り替えを、その都度人間が操作する必要はない。同時に、次の行動を毎回LLMへ考えさせる必要もない。判断が不要な部分は、決定論的なプログラムへ渡す。AIを呼ぶのは、実装や修正が必要な瞬間だけにする。

1時間という時間を先に埋めるのではない。今回の実測値から、1時間航行できるMissionを組み立てる。

トークン消費も、Missionの設計条件になる

今回、もう一つ確認できたのがProvider枠の問題だった。

Hermes / GLM-5.2は、長いMission履歴を持った状態で複数回呼び出され、5時間枠へ到達した。実行時間が長かったからではない。大量のContext、複数回の呼び出し、Mission ControlとBuilderのProvider共有が重なったためだった。

次の1時間Runでは、時間だけでなく、トークン消費も設計対象にする必要がある。

一つの巨大なセッションで全Work Packageを処理するのではなく、Work Packageごとに軽量な実行へ分ける。

Builder → WP-01 Packet
Builder → WP-02 Packet
Builder → WP-03 Packet

各PacketへRepository全体の説明を毎回入れる必要はない。必要なのは、

対象ファイル
前Work Packageの成果要約
再利用するコンポーネント
現在のテスト数
実装境界
成功条件

だけだ。

テストも、各Work Packageで毎回フル実行するとは限らない。

各WP        = Focused Tests
複数WP終了時 = Full Test Suite
最終WP      = Full Tests / Production Build / Runtime / Evidence / Morning Report

テスト自体はLLMトークンを消費しない。ただし、長い失敗ログを何度もAIへ読ませれば、Context消費は増える。失敗時には、関連部分だけを抽出して修正Packetへ渡す。

Mission Designには、作業量だけでなくContext Budgetも必要になる。

ローカルBuilder候補、Qwen3.5-35B-A3B

次の1時間Runでは、すべてのWork Packageをクラウド側のモデルへ集中させる必要はない。変更範囲が明確で、Task Packetとテスト条件が固定されたWork Packageであれば、ローカルLLMをBuilderとして配属できる可能性がある。

その候補の一つが、Qwen3.5-35B-A3Bだ。

現時点では、AION-COREのM1 Max 64GB環境へ導入し、実測する候補である。重要なのは、単にコードを出力できるかではない。Underground Model Portで使ってきた判定は、

Launch → Usable → Assignable

だ。

Qwen3.5-35B-A3Bを実案件Builder候補として評価するなら、確認すべき項目はさらに具体的になる。

コードを書けるだけでは、Assignableとは言えない。Missionの境界を守り、検証を通過し、人間へ戻すところまで実行できて初めて、AI LIFE OSのBuilder席へ配属できる。

Underground Model Portでモデルを捕獲し、検証し、配属する。次のNight Runは、その考え方をモデル情報の管理だけでなく、実際のAI Organization運用へ接続する機会にもなる。

クラウドモデルだけに依存しない航路を作れるのか。Qwen3.5-35B-A3Bが、その一部を担えるのか。それも、次の実証項目になる。

次の1時間Runで検証すること

今回の二つの短いRunで、基礎データは得られた。次回は、そのデータを使って1時間規模のRunを設計する。

Work Package Queue

複数のTask Packetを、人間の介入なしで順番に実行できるか。

Builder Assignment

各Work Packageの難易度や性質に応じて、適切なBuilderを割り当てられるか。ローカルLLMについては、LAUNCH / USABLE検証を通過した場合に限り、限定的なWork Packageへの配属候補とする。

Non-Interactive Execution

途中で承認待ちにならず、最初のHuman Gateだけで発進できるか。

Token Budget

Providerごとに消費量を管理し、上限へ近づいた場合にSAFE_STOPできるか。

Resume / Reuse

完了済みのBuilder resultを再利用し、途中からRunを再開できるか。

Deterministic Verification

focused test、full test、build、runtimeをLLMから切り離して実行できるか。

Final Human Gate

すべてのWork Packageと検証が終了したあと、

PAUSED_FOR_HUMAN_GATE

で停止できるか。

次回の目標は、ただ60分間AIを動かすことではない。意味のあるWork Packageを連結し、Missionを継続しながら、最後にHuman Gateへ戻ってくることだ。

Training Campで生まれたもの

Night 0では、4つのAIを同じ画面へ並べた。Day 1では、Architect、Mission Control、Builder、Reviewerの役割を分け、Mission Runtimeを一周させた。その後、AIがAIを動かすためのDispatchとSupervisorを設計した。Day 3では、Underground Model Portという実案件を完成させ、その後のVisual Migrationを二つの短いRunへ投入した。

3日間で積み上がったものは、

だった。

最終夜に、HermesはClaude Codeを起動した。Claude CodeはTask Packetを受け取り、専用worktreeで実装した。

Run 001では、Visual Foundationを構築した。Run 002では、その基盤を使ってDashboard Visual Migrationを拡張した。二つのRunは、テスト、production build、runtime確認まで完了した。

そして、その結果から、次の1時間Runを設計するためのデータが得られた。

これは完成形ではない。しかし、AI Organizationが実際のMissionを動かし始めたという意味では、大きな一歩だった。

最初の航路から、次の航続距離へ

最終夜に行ったのは、いきなりの長距離航行ではなかった。

Run 001で、HermesからClaude CodeへのDispatchとVisual Foundationを確認した。Run 002で、その基盤を再利用した継続実装を確認した。

二つの短いRunを通して、実装量、実行時間、テスト増分、Provider消費、停止条件を計測した。そのデータから、次に必要なものも分かった。

Work Package Queue
Builder Assignment
Token Budget
Non-Interactive Execution
Resume / Reuse
Deterministic Verification
Final Human Gate

さらに、次のBuilder候補として、ローカルLLMのQwen3.5-35B-A3Bも検証する。ただし、最初から配属を決めるのではない。

Launch → Usable → Assignable

その順序を守り、実測を通して役割を決める。

Summer Intensive Training Campで完成したのは、完璧な長距離航行システムではない。

最初の航路と、その航続距離を伸ばすための実測データだった。

次は、複数のWork PackageをQueueとして接続する。各タスクに適したBuilderを割り当てる。テストとbuildを決定論的に処理する。最後はHuman Gateで止める。

一つのAIに長い仕事を任せるのではない。異なるAIが役割を持ち、Missionを受け渡しながら進む。

AI LIFE OSのMission Controlは、最終夜に初めて自分で動き始めた。

#AI #AILIFEOS #Herdr #ClaudeCode #HumanGate #開発合宿 #AI航海士