AI LIFE OS POST-CAMP RUN｜13分のRelayで、ローカルQwenからKimi K3へMissionが渡った

IO｜AI航海士です。

Summer Intensive Training Campは、昨日終わった。しかし翌夜、Campで作ったMission Controlを止めることはできなかった。

今度は訓練ではない。ローカルモデルとクラウドモデルへ、実際の開発Missionを順番に渡す。最初のSerial Multi-Builder Runを始めた。

ローカルAIが動き出すと、Macのファンが回り始めた。LM Studioでは、Qwen3.5-35B-A3Bの生成トークンが増えていく。OrcaのMission Controlでは、HermesがQueueを進めている。

その後、MissionはOpenCodeへ渡り、Kimi K3がWorktreeへ直接ファイルを書き始めた。

ストップウォッチを止めた時、表示されていた時間は13分31秒だった。

Campで構築したAI Organizationが、初めて一つのMissionを複数のBuilderへRelayし、Human Gateまで運んだ。

ただし、最後のCodexレビューはAPPROVEではなかった。判定はREVISE。実装が失敗したからではない。成果を証明するEvidenceが、まだ十分ではなかったからだ。

Campが終わった翌夜、最初の実運用Runを始めた

今回のNight Run 003では、二つのBuilderを直列に動かすことを目指した。

最初のBuilderは、M1 Max 64GB上で動くローカルQwen。次のBuilderは、OpenCodeを経由して動くクラウドモデル。

設計したQueueは、次の順番だった。

WP-01 Local Qwen Builder
    ↓
WP-02 OpenCode Cloud Builder
    ↓
WP-03 Deterministic Verification
    ↓
WP-04 Codex Independent Review
    ↓
PAUSED_FOR_HUMAN_GATE

人間が行うのは、最初のLaunch Approvalと、最後のHuman Gateだけ。途中で承認要求や入力待ちが発生した場合はSAFE_STOPする。Commit、Merge、Push、Deploy、Publishは行わない。Builderの自己申告も、検証Evidenceとしては採用しない。

今回試したかったのは、単に複数AIにコードを書かせることではなかった。AIからAIへ仕事を渡す。別の仕組みで結果を検証する。そして、人間が判断すべき地点までMissionを運ぶ。

AI OrganizationとしてのRelayを成立させることだった。

最初に止まったのはローカルQwenだった

WP-01では、LM Studio上のQwen3.5-35B-A3BをNative REST APIから呼び出した。

使用したモデルは、Q4_K_M量子化の22.07GB。M1 Max 64GB上で、生成速度はおよそ毎秒50トークン前後だった。

起動そのものは問題なかった。しかし、最初のRunは途中で停止した。

原因候補として最初に見えたのは、Context Lengthだった。初期設定は4096。Qwenは実装案をreasoning側へ出力し続けたが、最終成果物として必要なJSONへ到達する前に出力上限へ達した。

finish_reasonはlength。最終contentは空だった。

そこでContext Lengthを8192へ増やし、WP-01をResumeした。しかし、再びSAFE_STOPした。Contextを倍にしても、Qwenは大量のトークンをreasoningへ使い、最終JSONを完成できなかった。

ここで分かった。問題は、単なるContext不足ではなかった。

当初指定していた、

"reasoning": "off"

が、LM Studio側では実際には効いていなかった。

reasoning: offでは止まらなかった

Hermesに、Qwenのrequestとresponseを調査させた。その結果、LM Studioで実際に機能したのは別の設定だった。

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

この構成では、Qwenはreasoningへ大量のトークンを消費せず、最終成果物まで到達できた。

今回のRunで得られた重要なEvidenceの一つが、これだった。

仕様上は同じ「思考を止める」という意図でも、API、Endpoint、Model、Chat Templateによって、実際に効く指定は異なる。ドキュメント上で対応しているように見える設定と、実運用で本当に効く設定は同じではない。

この違いは、モデルを実際の組織へ配属しなければ見えない。

Qwenは、起動できるだけではBuilderにならない。仕事を渡し、失敗させ、Evidenceを確認し、実行条件を調整して初めて、組織の一員として配属できる。

ローカルQwenの機関室

設定修正後、WP-01を再開した。

LM StudioのLocal Server画面では、Qwenの生成がリアルタイムで見えた。GENの表示。増えていくToken数。Developer Logsへ流れる処理記録。生成速度は、およそ50tok/s前後。

そして、負荷が上がるとMacのファンが回り始めた。

OrcaがMission Controlなら、LM Studioは機関室だった。Hermesが指示を出す。ローカルQwenが実際に演算する。その痕跡が、別の画面へ現れる。

AIが動いていることを、抽象的なメッセージではなく、機械の挙動として確認できた。

この時、ストップウォッチを回し始めた。

QwenからOpenCodeへRelayされた

QwenがWP-01を完了すると、Hermesは次のWork Packageへ自動で進んだ。

WP-02では、OpenCodeのAgentがWorktreeへ直接ファイルを書き始めた。Hermesのログには、次の記録が残った。

Kimi K3 is using tools
Kimi K3 has now used 22 tools including 2 write calls

ここで、一つ重要なことが分かった。

OpenCodeの画面上では、DeepSeek V4 Flash Freeが選択されていた。しかし、今回Hermesが非対話CLI経由でDispatchしたPrimary BuilderはKimi K3だった。

G2パケットでは、Kimi K3がPrimary、DeepSeekがFallbackとして設定されていた。

つまり今回成立したRelayは、正確には次の構成だった。

Local Qwen
    ↓
Hermes
    ↓
OpenCode / Kimi K3
    ↓
Deterministic Verification

画面上で選択されているモデルと、非対話プロセスで実際にDispatchされたモデルは一致するとは限らない。これも重要な学びだった。

次回以降は、Provider IDとModel IDをRun Evidenceへ明示的に保存する必要がある。「どの画面に何が表示されていたか」ではなく、「実際にどのプロセスが、どのモデルを呼んだか」を記録しなければならない。

Kimi K3はWorktreeへ直接書いた

QwenのWP-01では、厳格なJSON Delivery方式を使用した。一方、Kimi K3はOpenCode AgentとしてWorktreeへ直接ファイルを書いた。

今回対象になったのは、次のUIコンポーネントだった。

ModelCapsule.tsx
ModelIdentityCard.tsx
AssessmentPanel.tsx
AssignmentMiniMap.tsx

OpenCodeのプロセスは正常終了した。ただし、Hermesはそれをそのまま成功とは判定しなかった。

実ファイルを確認する。許可されたファイル範囲を検証する。テストを実行する。

途中で、「interactive promptが存在する」という検出も発生した。しかし実際には、Agent Event JSON内に含まれていた?や>などの文字列を、検出ロジックが誤認した偽陽性だった。

Hermesは最初の判定をそのまま採用せず、実際のプロセスと出力を調査した。Builderを信じるのでもない。検出ツールを盲信するのでもない。Evidenceを取り直してから次へ進んだ。

133件のテストが通った

WP-02の独立テスト結果は、133/133 PASSだった。内訳は次の通り。

120 existing tests
5 WP-01 tests
8 WP-02 tests

既存テストにRegressionはなかった。Qwenが作成したWP-01の成果も保持されていた。Kimi K3が追加した8件のテストも、すべて通過した。

Hermesは、その後WP-03へ進んだ。WP-03では、次の検証が行われた。

Full Test Suite
Production Build
Runtime HTTP
Git Boundary
Dependency Boundary
Protected File Boundary

途中、git showを使った依存関係比較がDangerous Commandとして表示された。一瞬止まったように見えた。しかし処理はその後も継続し、最終的にNight Run 003はHuman Gateへ到達した。

表示された最終状態は、次だった。

NIGHT RUN 003 PAUSED FOR HUMAN GATE

ストップウォッチは13分31秒だった。

13分31秒で起きたこと

設定修正後の本走では、次の処理が行われた。

Local Qwen WP-01
    ↓
Qwen output verification
    ↓
OpenCode / Kimi K3 WP-02
    ↓
Worktreeへの直接書き込み
    ↓
133/133 tests PASS
    ↓
Production build PASS
    ↓
Runtime HTTP 200
    ↓
Git / Dependency boundary check
    ↓
Codex Reviewer Packet生成
    ↓
PAUSED_FOR_HUMAN_GATE

短いRunだった。しかし、その13分31秒の中で、複数のAIと複数の環境が連動した。

OrcaではAI Organizationが見えた。Z.aiではHermesのGLM-5.2利用量が増えた。LM StudioではQwenの生成速度とreasoning挙動が見えた。OpenCode GoではクラウドBuilderの利用量が増えた。Gitにはファイル変更が残った。Test Runnerには133件の結果が残った。

一つのRunが、複数の観測面へ同時に痕跡を残した。

別Providerだから、痕跡が顕著に現れた

今回面白かったのは、使用したモデルが一つのProviderに閉じていなかったことだ。

Hermes = Z.ai。Qwen = LM Studio上のローカルモデル。Kimi K3 = OpenCode Go。Codex = OpenAI。それぞれ別の場所に利用痕跡が残る。

Hermes / GLM      = Z.ai利用量
Qwen Local        = LM Studio GEN、tok/s、reasoning tokens、Macの負荷
OpenCode / Kimi K3 = OpenCode Go利用量、Tool Calls、Write Calls
Repository        = Git Diff、Test、Build、Runtime
Codex             = Independent Review

別Providerだからこそ、痕跡が顕著に現れた。

HermesがKimi K3を動かしたと報告する。同時刻にOpenCode Goの利用量が増える。Worktreeに対象ファイルの変更が残る。133件のテストが通る。

複数の外部痕跡が一致することで、「本当に動いた」という実行事実を再構成できる。これは、単一サービス内で完結するログよりも面白い。複数の独立した観測面が、互いを裏付け始めるからだ。

Token Cockpitはフライトレコーダーになる

Token Cockpitは、単なるトークン使用量のグラフでは足りないのかもしれない。必要なのは、分散した痕跡をRun IDで束ねるフライトレコーダーだ。

記録すべきなのは、トークン数だけではない。

Run ID
Model
Provider
Role
開始時刻
終了時刻
実行時間
Input Tokens
Output Tokens
Reasoning Tokens
Tool Calls
Write Calls
対象ファイル
Test結果
Build結果
Runtime結果
SAFE_STOP理由
Review判定

これらが一つのRunとして束ねられれば、AI Organizationが何をしたかを後から再構成できる。

どのモデルが高かったか。どのモデルが速かったか。どのRoleで止まったか。どの構成ならHuman Gateまで到達できたか。

今回、ストップウォッチを回したことで、トークンだけでは見えなかったRunの密度が急に見えるようになった。

開発が、作業ではなくMission Runになった。

UMPへ流れ込むModel Evidence

今回のQwen配属だけでも、Model Capsuleへ残せる情報は多い。

Model         = Qwen3.5-35B-A3B
Environment   = M1 Max 64GB
Quantization  = Q4_K_M
Size          = 22.07GB
Generation    = 約50 tok/s
Context 4096  = 実Repository Taskでlength stop
Context 8192  = reasoning有効時はfinal JSON未到達
Verified non-reasoning = reasoning_effort: none
Minimal Assignable     = PASS
Real Repository WP-01  = PASS

これはModel Cardのスペック表ではない。実際のAI Organizationへ配属したEvidenceだ。

起動できるか。使えるか。仕事を割り当てられるか。どの条件で止まるか。何を修正すれば通るか。

UMPが扱うべきなのは、このレベルの運用知なのだと思う。モデルの性能を語るだけではない。実際の環境で、どのRoleへ配属できるかを残す。

今回、Qwenは単なるローカルLLMから、限定されたWork Packageを担当できるLocal Builderへ一段進んだ。

Codexの判定はREVISEだった

Night RunはHuman Gateへ到達した。その後、CodexへReviewer Packetを渡し、G4 Independent Reviewを実行した。

判定はAPPROVEではなかった。

G4 REVIEW COMPLETE — REVISE

Codexが指摘したのは、主にEvidenceの不足だった。実装そのものについては、多くの項目が肯定された。

一方で、次の点は証明が弱いと判断された。

Pre-run baseline hashがない

Run開始前のファイルハッシュが保存されていなかった。そのため、現在の差分に含まれている変更が、今回のRunによるものか、それ以前から存在したものかを完全には証明できない。

Scope再判定の比較Evidenceがない

Hermesは、一度scope failureと判定した変更を、後からpre-existing changeとして再分類した。しかし、その比較に使ったEvidenceが十分に保存されていなかった。

Runtimeの生ログが薄い

最終的なHTTP 200は記録されていた。ただし、その前に失敗したprobeもあり、最終成功を裏付けるraw logが弱かった。

Codexの判断は、「コードが悪い」ではなかった。成果は存在する。しかし、それを承認可能な水準で証明できていない。そのためREVISEだった。

成果ではなく、証明が足りなかった

この結末は、AI Organizationとして健全だったと思う。

Builderが実装する。Mission Controlが検証する。Independent Reviewerが、Mission Controlの報告すら疑う。最終的に、人間が判断する。

AIがAIを動かすだけでは、組織にはならない。役割が分かれ、相互に検証し、必要なら止められること。

今回、Qwenは複数回止まった。Hermesはそのたびに次へ進まず、SAFE_STOPした。Kimi K3の実装後も、自己申告だけでは通さなかった。Codexは、実装が動いていてもEvidence不足を理由にREVISEした。

Campで作りたかったAI Organizationは、少しずつ形になってきた。完成したのではない。しかし、動かしたからこそ、次に直す場所が見えた。

次回必要なのは、コードの全面修正ではない。Run開始前からEvidenceを設計することだ。

Pre-run file hashes
Pre-run git diff snapshot
Protected-file hashes
Runtime probe raw log
Post-run comparison report
Provider / Model execution record

これらを保存できれば、次のG4はさらに強くなる。

AI LIFE OSは、時間を循環させる

今回のCampを終えて感じたことがある。AI Organizationを作る面白さは、生活の中の時間に、それぞれ意味を持たせられることだ。

Mission Controlを作る。開発が進む。そのRunからデータが取れる。トークン消費。実行時間。モデルごとの特性。失敗地点。修正時間。Builder間のRelay。Test数。Review結果。

そのデータはToken Cockpitへ流せる。モデルの配属EvidenceはUMPへ流せる。Runの過程は記事になる。記事は次の仕事や接続を生む。

一つの時間が、一つの成果だけで終わらない。

生活
    ↓
Mission
    ↓
AI Organization
    ↓
Run
    ↓
Evidence
    ↓
Product
    ↓
Knowledge
    ↓
Publishing
    ↓
次のMission

効率化とは、同じ仕事を短く終わらせることだけではない。同じ時間から、複数の意味と成果を回収すること。

今回の13分31秒は、開発時間であり、モデル検証であり、組織実験であり、Token Cockpitの入力であり、UMPのModel Capsuleであり、この記事の素材でもある。

AI LIFE OSの中で、時間が循環し始めている。

十三秒のSignalから、13分のRelayへ

ACT2には、以前「十三秒のSignal」という出来事があった。MIRAは、その短いSignalを捨てなかった。

今回残ったのは、13分31秒のRunだった。

13秒は、Signalを保存した。13分は、AI Organizationの実行痕跡を保存した。

どちらも、一見すれば短い時間だ。しかし、その短い時間の中に、次の構造へつながる情報が含まれていた。

ACT2における13は、不吉な数字ではないのかもしれない。Signalが意味へ変わるための時間。壊れたものが、次の形を見せるまでの時間。

今回、MissionはローカルQwenからKimi K3へRelayされた。そして最後にARCAは言った。

成果はある。しかし、まだ証明が足りない。

Summer Intensive Training Campは、昨日終わった。だが、Campで作ったAI Organizationは、その翌夜から実運用を始めた。

訓練が終わったから、Runが始まった。

#AI #AILIFEOS #Qwen #KimiK3 #ローカルLLM #NightRun #AI航海士