AI LIFE OS Summer Intensive Training Camp Day 3 前半戦｜Underground Model Portが、localhostで動き始めた FableからOpusへ。差し戻しと再検証を越えて、モデルの地下港は実動MVPになった

IO｜AI航海士です。

3日間のAI LIFE OS Summer Intensive Training Campも、ついに最終日を迎えた。

Day 1では、Claude、Hermes、OpenCode、Codexの4つのAIをOrca上に配置し、Mission Runtime v0.1を完成させた。Day 2では、夜間にAIチームを動かすためのNight Run Supervisorを実装した。モデルが停止しても、差し戻されても、別のAIが同じMissionを引き継げる構造まで確認できた。

そしてDay 3。いよいよ、これまで構想とデザインを積み重ねてきたUnderground Model Portを、実際に動くアプリケーションへ変える。

今回のMISSION-004は、この3日間で作ってきたMission Control、Human Gate、Worktree、Artifact、Review Loopを、実案件へ投入する最初のMissionだった。

結果から言えば、Underground Model Portはこの日、構想図ではなくなった。ブラウザの中で、実際に動き始めた。

#Now Listening…

MISSION-004｜Underground Model Port MVP

Underground Model Portは、AIモデルを大量に並べるための倉庫ではない。

どのモデルが起動できるのか。実用レベルで使えるのか。どの役割へ配属できるのか。どの環境で動き、どのようなEvidenceを持ち、停止した場合にどのRouteへ切り替えられるのか。

モデルの所在、来歴、実測結果、配属可能性を共同で維持する「情報港」として考えてきた。

今回のMVPでは、その中から以下の機能を縦に切り出した。

Dashboard
Current Core Models
Model Capsule
Launch / Usable / Assignable
Assignment Map
HAZAR Bounty
Watchtower

対象となるモデルは、AION-COREでこれまで検証してきたモデル群だ。

DwarfStar 4
Qwen 3.6 35B-A3B
Qwen 72B
Kimi K3
Qythos 9B

これらを単なるモデル一覧としてではなく、「起動」「実用」「配属」という状態を持つ存在として画面上へ配置する。

Claudeが設計し、Human Gateで4つの判断を確定した

MISSION-004は、ClaudeによるArchitecture設計から始まった。

既存のMISSION-001からMISSION-003までの構造を読み込み、Underground Model PortのMVP範囲、画面構成、データ構造、Acceptance Criteria、Gateの流れを定義する。

設計段階では、4つのHuman Gate判断が必要になった。

Q1｜VitestをどのようにNight Run Supervisorへ接続するか

既存のNight Run Supervisorを変更せず、Python標準ライブラリだけで動くvitest_runner.pyをラッパーとして追加する。

Q2｜レビュー担当

Codex GPT-5.6 SolをG4 Reviewerとして維持する。

Q3｜テスト結果のスキーマ

既存のbuilder-result.json構造を維持し、self_test_exit_codeにVitestの終了コードを格納する。

Q4｜HAZAR BountyのSeed定義

B001 = Long Context Reliability
B002 = Sub-10B Launchpad
B003 = Full Stack Assignability

この3つを承認した。

Claudeが設計を保存し、G1を通過。次にHermesがArchitectureを読み込み、Fable Task Packet、Supervisor Config、Vitest Runner、Review Packet、Morning Report Templateを生成した。

46項目の整合性チェックをすべて通過し、MISSION-004はG2 Human Gateへ進んだ。

ここまで、実装コードはまだ書かれていない。先にMissionの境界と判断を固定する。この順序が、今回のHarnessの重要な部分だった。

Fableを、外部実装エンジンとして接続する

G2承認後、HermesはMISSION-004専用のworktreeを作成した。

Worktree = /Users/apple/Documents/AION-FULL-PACKAGE-RUN-wt/mission-004-builder
Branch   = camp/mission-004-builder

main workspaceとは分離されている。

このworktreeをClaude DesktopのCode画面から開き、Fable 5へTask Packetを渡した。Orca内部で全員を動かすのではなく、実装だけを外部のFableへ渡す。

OrcaはMission Control。FableはPrimary Builder。ArtifactとWorktreeを境界として接続する。この構成にした。

ところが、実行開始直後に予想外のことが起きた。Fable 5のセーフガードがプロンプトを検知し、モデルがOpus 5へ自動的に切り替わった。

指示には、branch、HEAD、worktree、テスト、コマンド実行、禁止操作、Night Run Supervisorなど、セキュリティ分類が広く反応しそうな要素が多く含まれていた。危険な依頼ではない。しかしFable 5は安全側へルーティングし、Opus 5が実装を継続した。

今回の実装Runは、厳密にはこうなる。

Fable 5
    ↓ Safety Routing
Opus 5
    ↓ Same Packet / Same Worktree
Implementation Continued

モデルが変わっても、Missionは変わらない。誰が作業するかではなく、何を、どこまで、どの境界内で作るかがArtifactに残っているからだ。

実は、worktreeには既に実装の痕跡が残っていた

Opusがworktreeを確認すると、underground-model-port/には、先行Runで作られた完全に近い実装ツリーが存在していた。

ここでOpusは、既存のbuilder-result.jsonをそのまま信用しなかった。レポートには14項目のAcceptance Criteriaを通過したと書かれていたが、自己申告だけでは承認しない。

コード、データ、テスト、ブラウザ動作を、最初から独立して確認し直した。

この姿勢は今回かなり重要だった。AIが書いた「完了しました」を、別のAIがそのまま信じない。Evidenceを再取得する。まさにDay 1とDay 2で作ってきたReview Loopが、実案件の中で機能し始めていた。

localhost:5173に、地下港が現れた

実装されたUnderground Model Portは、ViteによるReactアプリケーションとして起動した。

localhost:5173

最初に表示されたのはDashboard。5つのモデルがカードとして並び、それぞれにLaunch、Usable、Assignableの状態が表示される。

DwarfStar 4          = Launch PASS / Usable FAIL
Qwen 3.6 35B-A3B     = Launch PASS / Usable PARTIAL
Qwen 72B             = Launch PASS / Usable PASS / Assignable PARTIAL
Kimi K3              = Launch PASS / Usable PASS / Assignable PASS
Qythos 9B            = Launch FAIL

次にCurrent Core Models。モデル名、Family、Size、Quantization、Launch、Usable、Assignable、Updatedが一覧化された。

Model Capsuleでは、モデルごとの詳細が表示される。Kimi K3のCapsuleには、Family、Parameters、Quantization、Context Window、Local Path、Port Statusに加え、Launch、Usable、AssignableそれぞれのAssessmentとEvidenceが並んだ。

Assignment Mapでは、Architect、Builder、Reviewer、Supervisor、Commanderの5つの役割に対し、各モデルの配属可能性がマトリクスで表示された。

Watchtowerには、3つのHAZAR Bountyが表示された。

Long Context Reliability
Sub-10B Launchpad
Full Stack Assignability

これまで記事やデザインの中で使っていた言葉が、初めて一つのアプリケーション内で接続された。

Model Capsule。Assignment Map。HAZAR Bounty。Watchtower Evidence。すべてが同じlocalhost上に存在している。

この瞬間、Underground Model Portは構想ではなくなった。

Opusは、既存実装の不具合も修正した

独立検証の中で、Opusは小さな問題を見つけた。

MapMatrix.tsxに未使用importが残っていた。また、モデル一覧では名称部分だけがリンクになっており、行全体はクリックできなかった。そこで、行全体をナビゲーション対象へ変更した。

Kimi K3のQuantizationセルをクリックし、/models/kimi-k3へ遷移することも実ブラウザで確認した。

さらに、先行レポートにはVite serverがポート5173で動いたと書かれていたが、これも信用せず再実行した。

起動時間 = 158ms
HTTP    = 200
コンソールエラー = 0
Vitest  = 36/36 PASS

production buildも成功した。

ここでPrimary Implementationは一度完了した。

FABLE IMPLEMENTATION COMPLETE
— READY FOR BUILDER INTEGRATION

Codexは、完成を認めなかった

次に、Codexによる独立レビューを行った。画面は動いている。テストも通っている。buildも成功している。

それでもCodexは、2つの不足を指摘した。

1つ目は、コンポーネントレベルの回帰テストがないこと。2つ目は、未定義URLへアクセスした際の明示的なNot Found Routeがないこと。

加えて、いくつかのResidual Riskも整理された。

Verdictは、G4 REVISE。

一度動いたから終わりではない。レビューで止まり、修正へ戻る。今回も、AIチームは一直線には進まなかった。

Focused Revision｜36件から87件へ

Codexの指摘を受け、OpusへFocused Revisionを依頼した。変更範囲は限定した。

修正後、テスト数は36件から87件へ増えた。新しいテストファイルだけで51件が追加された。

production buildは再び成功。localhost:5173での起動も確認。

Not Found Routeについては、存在しないURLへ直接アクセスし、Page Not Foundが表示されることを確認した。また、/models/qwen-72b/extra/depthのような深いURLでもNot Found Routeへ移ることを確認。

一方で、/models/no-such-modelは既存のModel Detail Routeへマッチし、「Model not found」と表示される。Routeの優先順位も意図どおり維持された。

Opusは残留リスクも消さずに報告した。

deriveVerdict()は依然としてrender pathへ接続されていない。Static Rendering Testではクリックイベントまでは完全に検証できない。ReactのuseLayoutEffect warningが出る。jsdomは承認済み依存に含まれていないため、今回のテストはserver-rendering中心。

修正したことだけでなく、修正しなかったことも記録する。

これでFocused Revisionは完了した。

FOCUSED REVISION COMPLETE
— READY FOR G3 VERIFICATION

Hermes停止。Missionは停止しない

この間、Mission Controlを担当するHermesのGLM-5.2 Coding Planは、5時間上限へ到達した。

HTTP 429
リセット時刻 = 17時44分

Hermesは一時的に利用不能になった。

ただし、MISSION-004のworktree、Task Packet、実装、テスト、Evidenceはすべて保存されている。実装担当のOpusは作業を完了。Codexもレビューを完了。Hermesだけが停止している。

つまり、AIチーム全体が停止したわけではない。

今回のCampで作っているものは、どれか一つのモデルを永続的に動かす仕組みではない。モデルが止まっても、ArtifactとWorktreeを残し、次の航路へ接続する仕組みだ。

GLM-5.2の枠が復帰するまで、MISSION-004は凍結された。焦って別Providerへ切り替える必要はない。境界が保存されているから、待つことも正しい操作になる。

正式G3｜87件のテストを再実行する

18時44分を過ぎ、GLM-5.2の5時間枠が0%へリセットされた。Hermesを再起動し、正式なG3 Re-verificationを実施した。

Opusの完了報告は信用しない。Codexのレビュー結果も、そのままでは採用しない。Hermes自身がworktree、branch、HEAD、変更ファイル、テスト、build、runtime、Evidenceを確認する。

結果は以下。

Vitest                     = 87/87 PASS
production build           = exit 0
main HEAD                  = unchanged
staging                    = なし
worktree isolation         = 維持
state.json / registry同期   = 一致
lifecycle                  = REVIEW
G3                         = passed
nextHumanGate              = G4

正式Verdictは、

G3 PASS
— READY FOR G4 RE-REVIEW

Codex再レビュー｜G4 APPROVE

続いてCodexへFormal G4 Re-reviewを依頼した。前回指摘した2つのBlocking Findingが、本当に解決されているかを確認する。

コンポーネントレベルの回帰テスト。明示的なNot Found Route。

Codexは実装ファイル、テスト、Evidence、Governance Recordを直接確認した。結果、前回のBlocking Findingはすべて解消。

実装は専用worktree内に限定。main workspaceの実装ファイルは未変更。依存パッケージは承認済み15件のみ。commit、merge、push、deploy、publish、アカウント変更なし。builder-result.jsonも実状態と一致。

Formal G4は承認された。次のGateは、G5 Human Gate。最終判断はAIではなく、人間が行う。

Human Gate｜63ファイルを承認する

HermesはG5前に、Controlled Staging Planを作成した。対象は合計63ファイル。

内訳は以下。

underground-model-port/  = 46ファイル
Evidence                 = 1ファイル
Injected Packet          = 4ファイル
Mission Governance       = 10ファイル
Repository Root          = 2ファイル

除外対象は5,076ファイル。node_modulesとdistはすべて除外。

この時点で、stagedなし、committedなし、mergedなし、pushedなし。

私はHuman Gateとして、63ファイルのstagingとclosureを承認した。

G5 APPROVED BY IO

HermesはControlled Stagingを実行。Builder Branchへcommit。mainへmerge。Closure Recordを更新した。

最終状態は以下。

Implementation Commit = 3a3bac9
Merge Commit          = 9c1aff6
Main HEAD             = f7e0e73
Vitest                = 87/87 PASS
production build      = exit 0
main working tree     = clean
G3                    = passed
G4                    = approved
G5                    = approved
nextHumanGate         = null
closedBy              = IO

MISSION-004は正式に閉じた。

これはHarness構築であり、Loop Engineeringであり、AI組織設計でもある

Day 3の途中で、改めてフローを見直して感じた。今やっていることは、現在の言葉で言えば完全にHarness構築であり、Loop Engineeringだ。

個別のモデルへ一度だけ良いプロンプトを投げるのではない。Architecture、Task Packet、Worktree、Builder Result、Evidence、Review Result、Human Gateを接続し、失敗と差し戻しを前提としたLoopを作る。

Architecture
    ↓
Mission Packet
    ↓
Implementation
    ↓
Verification
    ↓
Independent Review
    ↓
Focused Revision
    ↓
Re-verification
    ↓
Human Gate
    ↓
Commit / Merge / Closure

ただし、ここで作っているものはHarnessやLoopだけではない。
さらに上の層では、AI組織そのものを設計している。

ClaudeをArchitectへ置く。HermesをMission Controlへ置く。Builderへ実装を渡し、CodexをReviewerへ置く。そして最後の判断をHuman Gateへ残す。設計、実装、検証、監査、承認という責任を分離し、それぞれを異なるAIと人間へ割り当てる。

Harnessは、AIが働くための実行環境を作る。Loop Engineeringは、失敗と修正を含む循環を作る。その上にあるMission Engineeringは、Loopへ目的、境界、役割、Gateを与える。そしてAI Organization Designは、誰がMissionを動かし、誰が止め、誰が引き継ぐかを決める。

今回のCampで作っていたのは、AIにコードを書かせる仕組みだけではなかった。

AIがチームとしてMissionを完遂するための、組織と運用のOSだった。

フロンティア依存を減らす港を、フロンティアモデルが作った

今回の展開には、少し皮肉もある。

Underground Model Portは、特定のフロンティアモデルへの依存を減らすための構想だ。しかし、そのMVPを実装したのはFableから切り替わったOpus 5だった。

フロンティア依存を減らすために、フロンティアモデルを使った。

ただし、目的は高性能モデルを拒否することではない。どのモデルも、停止した瞬間にMission全体を止められない構造を作ることだ。

モデルを使わないのではなく、交換可能にする。依存を消すのではなく、依存先を固定しない。

その意味では、今回の展開そのものがUnderground Model Portの思想を表していた。

Underground Model Portは、まだ白い

今回完成したMVPは、機能骨格を優先している。以前作成したデザインと比べると、見た目はまだシンプルだ。

白いDashboard。表形式のModels。基本的なCard。簡易的なAssignment Map。

だが、これは未完成というより、動作保証済みのUI骨格だ。Route、Data Type、Test、Build、Model Capsule、HAZAR Bounty、Watchtowerが既に接続されている。

次のMISSION-005では、この骨格を維持したまま、以前作成したUnderground Model Portのデザインへ移行する。

AION-CORE Compatibility Lab Dashboard
Model Capsule Detail
HAZAR Bounties
Assignment Map
CAT Polaris Dark Entrance

機能を壊さず、Visual Layerだけを移植する。そのためのVisual Migration Missionも、すでにGanttへ追加した。

そして今夜、Night Run Supervisorを初めて実戦投入する

Day 2で完成したNight Run Supervisorは、まだ本番Missionで夜間運転されていない。今夜、初めて実際のMissionへ投入する。

ただし、Night Run Supervisorが行うのは、勝手な開発ではない。

Mission Freeze
Worktree、Branch、HEAD、Quotaの確認
承認済みTestの実行
Production Build
localhost Runtime Verification
Evidence収集
Morning Report生成

失敗した場合も、Retry回数と実行時間は制限される。そして最後は、必ずここで止まる。

PAUSED_FOR_HUMAN_GATE

自動承認しない。commitしない。mergeしない。pushしない。

朝、Human GateがEvidenceを読み、Approve、Revise、Holdを判断する。それが、AI LIFE OSにおける夜間自律運転の境界だ。

Day 3 前半戦の到達点

最終日の前半で、Underground Model Portはlocalhost上に現れた。

5つのモデル
5つの役割
3つのHAZAR Bounty
Model Capsule
Assignment Map
Watchtower
87件のテスト

ただ、今回の成果は画面だけではない。AIチームが、外部実装エンジンを含めて、一つのMissionを完遂した。

設計したAI。Packetを作ったAI。実装したAI。差し戻したAI。再検証したAI。最終承認した人間。

全員が同じモデルである必要はなかった。同じ画面にいる必要さえなかった。必要だったのは、共通のArtifactと、越えてはいけない境界と、次のGateだった。

Underground Model Portは、モデルを置くための港として作り始めた。しかし今日、その港を作るAIたち自身が、すでに異なるRouteを渡り始めていた。

地下港は、もう構想ではない。localhostで、静かに稼働している。

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