HAL-0 構築録 #104｜「異常な状態遷移」の正体は、実害のない想定漏れだった

2026.09.22
(#104)

▶ YouTube｜構築記録 再生リスト
▶ YouTube｜LOOP LOG 再生リスト

2026.09.06、GTAの実機検証中に、ログを見張る仕組み（log_monitor）が、ある警告を出していた。GTAとは関係のない場所で見つかったので、そのときは記録だけにして先へ進み、2026.09.14に原因を調べた。これはその調査記録だ。

何が警告されたのか

Resource Orchestrator（複数のAIモデルを、用途に応じて使い分ける司令塔）は、各AIモデルの状態を記録している。状態には、たとえば次のようなものがある。

• `MODEL_LOADING`：モデルを読み込み中

• `MODEL_READY`：使える状態

• `OLLAMA_READY`：AIを動かすソフト（Ollama）は動いているが、目的のモデルはまだ載っていない

そして「この状態から、この状態へは移ってよい」という決まり（遷移グラフ）がある。ログには、`MODEL_LOADING`から`OLLAMA_READY`へ移った記録が残っていたが、その遷移は決まりに含まれておらず、「未定義の遷移」として警告された。

原因

原因の確度は高いと見ている。二つの処理が、同じ状態の記録を共有していたためだ。

1. モデルの読み込みを始める処理が、状態を`MODEL_LOADING`として記録する（司令塔が「自分でそう決めた」状態＝operational）

2. 別の処理が、実際にAIへ問い合わせて「今どのモデルが載っているか」を測り、状態を計算して記録する（実測した状態＝observed）

読み込みの最中に、別の呼び出し元（GTAの探索ループなど）が実測すると、まだ読み込みが終わっていないので`OLLAMA_READY`と計算される。すると、`MODEL_LOADING`から`OLLAMA_READY`という、決まりにない遷移が記録される。

以前（Issue #115 ）、状態の記録を「実測」「司令塔の判断」などに分ける改修をした。そのとき、この二つが同じ検証の仕組みを共有する設計になっており、「読み込み中に実測が割り込む」ケースが想定から漏れていた。

実害は無い

この仕組みは、遷移が不正でも処理を止めない設計になっている。そのため、誤った選択や動作は起きておらず、警告が記録に残っただけだ。実害は無かった。

対応の案（どちらにするか未決）

• (a) `MODEL_LOADING → OLLAMA_READY`を、許可する遷移として追加する。「読み込み中に実測すると、まだ準備ができていないと出る」という、正常な動きとして扱う

• (b) 「実測した状態」と「司令塔が決めた状態」の検証を分離し、三層分離をもっと厳密にする

作業量は、いずれも低〜中程度。テストの追加を伴う。どちらを選ぶかは、LOOPの判断待ちだ（Issue #137 ）。

今回の教訓

警告を見たときに、それが「壊れている」のか「想定外の使われ方をしただけ」なのかを、ログの文面だけでは区別できない。9月6日の時点で、そのまま放置せず、`[要確認]`として残しておいたことで、9月14日に原因までたどり着けた。

── 共に、歴史の転換点に立つ ──
HAL-0プロジェクト | LOOP × HAL | 2026.09.22

X: @halzero_project
YouTube: HAL-0