実装はあるのに実行されないレーンを、機体固定と回帰テストで塞ぐ
今回やったこと
実装済みのレーンが、毎日 applied=0 のまま一度も処理を実行していない状態を点検した。原因は、GPU を必要とするレーンが汎用リースの既定値へ吸収され、実行対象から外れてもエラーを出さず停止していたことだった。実装ファイルが存在することと、実機で実行対象に選ばれることは別の契約である。
scripts/config/lane_roles.json を実行場所の正本とし、機体固有の GPU レーンには pinned_host を設定した。起動設定、設定台帳、回帰テストを一緒に確認することで、存在するが呼ばれないレーンを見逃さない構成にしている。
汎用リースに任せると何が起きるか
このリポジトリのレーンには、リースを持つ機だけが動く leader、どの機でも動く any、特定の機体だけで動く pinned_host がある。公開や起稿のように二重実行が不可逆なものはリースで1台に絞る。一方、GPU や住宅回線のように、特定のハードウェア・ネットワークが存在理由になっている処理は、リースの既定値へ混ぜると意味が失われる。
画像ドレインの起動設定は com.ntmedia.image-drain というラベルを持ち、実体のスクリプトを leader_exec.sh 経由で呼ぶ。レーンが正しくインストールされていても、実行場所の判定が用途に合わなければ、処理は静かに skip される。エラー終了ではないため、単純な「プロセスが起動したか」だけでは発見できない。
{
"com.ntmedia.image-drain": {
"pinned_host": "gpu-worker-mac",
"reason": "GPU（ComfyUI / ollama）と画像生成の常設機"
}
}
pinned_host は、どの機体にも適当に配置するための設定ではない。GPU がある機体だけで実行するという制約を、レーンの選択ロジックが読める形で明示するための値である。設定台帳には機体自体も登録し、存在しない名前への固定を別の検査で検出できるようにした。
「配線されている」をテストで定義する
修正の中心は、実装ファイルを追加したことではなく、呼ばれる条件をテストで固定したことにある。scripts/test_lane_wiring.py は、GPU のモデルを名指しするレーンが pinned_host を持つこと、固定先の機体がホスト台帳に存在することを確認する。画像ドレイン固有の回帰テストも、設定ファイルと起動設定が消えていないかを確認する。
このテストには、意図的に登録を外した状態を検出する対照もある。設定が空になったときに、テスト対象がゼロ件なので成功するのでは意味がない。検査対象が一定数あることまで確認し、スキャンが空振りしていないことを条件へ含める。
失敗を通知だけで終わらせない
無人運用では「エラーが出たら通知する」だけでは不十分である。今回のように、処理対象から外れたまま終了コードも異常にならない状態は、エラー監視だけでは見えない。必要なのは、レーンが呼ばれたか、呼ばれたレーンが実行対象として選ばれたか、選ばれた結果が適用されたかを分けて見ることだ。
実装・設定・起動の3か所を同じ変更単位で点検すると、次の担当者が「コードはあるのに動かない」状態を未然に防ぎやすくなる。GPU レーンを機体へ固定する判断は、性能最適化ではなく、実行対象の誤選択を防ぐ安全弁である。
試した環境・バージョンは、launchd の plist、JSON のレーン台帳、Python の配線回帰テスト、GPU 依存を表す設定の静的検査である。GPU 本体の処理性能を測る記事ではなく、無人ジョブの呼び出し条件を検査する実装記録として整理した。
更新履歴
- 2026-09-14: 初稿。GPU 依存レーンを機体固定し、配線を回帰テストで監査する設計を記録。
訂正履歴
- なし。