2026年6月8日、Microsoft MVPの胡田昌彦氏は「Claude Codeを5時間放置｜AIに自律でインフラを作らせる時代」（動画9分36秒）で、Claude Code が約4時間55分かけて Nested Hyper-V ラボ（ebibibi/hyperv-nestlab）を自律構築した事例を公開した。プロンプト1発ではなく、長時間ループが前提だ。
同じ時期、筆者（ITPRODX）は Mac mini 上の launchd 15分間隔ランナー（~/Projects/ai-company-24h/runner.py）と朝便ランナー群（agent-skill-exec.sh 経由の cursor-agent --model auto）で「放置運転」を回している。2026年8月15日の Codex 上限到達を機に Cursor へ切り替えたが、エンジン配線の不整合と CLI のプロンプト渡し方で3日間、成果物ゼロの暗転が起きた。本稿は、胡田氏の公開事例と筆者の一次ログを対比し、長時間ループ型運転を回すための配線チェックリストを整理する。
結論
| 確認項目 | 胡田氏の公開事例（出典付き） | ITPRODX実体験（2026-08-15〜18） | 直すこと |
|---|---|---|---|
| 実行モデル | Claude Code が長時間ループで作業継続 |
cursor-agent --model auto に統一（Codex は明示切替のみ） |
~/.config/itprodx/agent-engine と各 runner の実呼び出しを一致させる |
| 成果の単位 | YAML + bootstrap.ps1 で冪等なインフラ |
SAFEジョブ1本＝下書き1ファイル（outputs/<date>/） |
DONE ログと成果物ファイルの両方で成功を判定する |
| 停止原因 | （動画・READMEは外部参照。ここでは断定しない） | Codex 上限 → runner.py が Codex 固定 → No prompt provided for print mode
|
エンジン切替時に 全ランナー をgrepで横断確認 |
| 人間の関与 | AD参加後のライセンス認証など（README記載） | Telegram 承認ゲート（公開・送信は人間✅のみ） | 自律化してよい境界と、必ず止める境界を分離 |
胡田氏の hyperv-nestlab：長時間ループが効く条件
確認できる事実
- 動画: Claude Codeを5時間放置｜AIに自律でインフラを作らせる時代（2026-06-08公開、@ebibibi、9:36）
- リポジトリ:
ebibibi/hyperv-nestlab— 「宣言的・冪等な Nested Hyper-V ラボ構築基盤」 - README 上の要点: 既存 Hyper-V ホスト1台に
bootstrap.ps1を実行すると、制御 VM（Ansible）を自己構築し、YAML 宣言から Nested ホストと VM 群を再現する - 完了判定に使える中間状態: README のチェックリスト（L0→L1 冪等プロビジョニング、L2 Windows/Ubuntu/AD など）が公開されている
実務解釈
胡田氏の事例で再現性が高いのは、「最終ゴール1文」ではなく 冪等な中間チェックポイント がある点だ。bootstrap.ps1 と YAML が「同じコマンドを再実行しても壊れない」形になっているため、エージェントが数時間ループしても状態が収束しやすい。
コーディングエージェントの長時間運転を自社インフラに載せるときも、同型の設計が必要になる。具体的には次の3点だ。
-
完了条件を機械判定できる形にする（例:
pytestが exit 0、特定ファイルが生成される） -
1ジョブのスコープを「1成果物」に切る（24hランナーなら
shukyaku-qiita= Qiita下書き1本） -
ログに
DONE/FAIL/ 成果物パスを必ず残す（後から「動いていたが空回り」を検知する）
ITPRODX側：2026-08-15のエンジン切替と暗転
確認できる事実（HQ日報・runner.log・決定記録）
2026-08-15 07:30 — hq-morning-runner が Codex 使用量上限で exit=1（決定記録: 00_Codex_HQ/30_Decisions/2026-08-15-hq-morning-cursor-engine.md）
同日の方針:
- 朝運転・日次ランナー群の正本エンジン = Cursor（
agent-skill-exec.sh経由） - モデル =
auto既定 - Codex は
switch-agent-engine.sh codexの明示切替時のみ
24hランナーの成果物本数（HQ日報 _token-meter）:
| 日付 | 成果物本数 | runner INVOCATION |
|---|---|---|
| 2026-08-14 | 35 | 35 |
| 2026-08-15 | 0 | 48 |
| 2026-08-16 | 0 | （日報上0本） |
| 2026-08-17 | 0 | 113 |
| 2026-08-18 | 11 | 12 |
8/15〜8/17は launchd が 15分ごとに起動しているのに、SAFEジョブの DONE が成果物に結びつかない状態が続いた。runner.log では 8/15 0時台から exit=1 / RETRY / FAIL が連続している。
8/17 22:55以降 — runner.py を Cursor 経路（cursor-agent --model auto --trust）へ修正後、kickstart で DONE が復帰:
2026-08-17T22:55:07+09:00 DONE douga-safe-plan:2026-08-17T22 status=needs_human artifact=.../douga-safe-plan__2026-08-17T22.md
2026-08-17T23:27:00+09:00 DONE revenue-demand-radar:2026-08-17T23 status=done_draft artifact=.../revenue-demand-radar__2026-08-17T23.md
Qiita/Zenn writer の別系統障害 — agent-skill-exec.sh が cursor-agent -p に stdin パイプでプロンプトを渡しており、即死していた:
2026-08-16 07:05:05 launching cursor agent (model=auto, timeout=1200s) ...
Error: No prompt provided for print mode
2026-08-18 07:05:06 ...（同エラー）
2026-08-18 09:46:49 ...（修正後 kickstart）
Qiita下書き完了・承認待ち: Copilot StudioからPower Automateフローをアクションとして呼ぶ入門
2026-08-18 修正 — CLI 引数渡しへ変更（agent-skill-exec.sh 78行目付近）:
# stdin 受取 → cursor-agent -p へ CLI 引数で渡す（-p は stdin 非対応・2026-08-18 修正）
"$agent_bin" -p --model "$cursor_model" --output-format text -f --trust \
--workspace "$workspace" -- "$(< "$prompt_file")"
実務解釈
暗転の原因は「モデルが弱い」ではなく 配線の不整合 だった。
- 朝便だけ Cursor、24hだけ Codex 固定 — 上限に当たった瞬間、半分のパイプラインが止まる
-
exit=0 でも中身が空 —
No prompt provided for print modeは exit=0 で終わる日があり、watchdog が「起動した」と誤認しうる - 成功判定がログだけ — 成果物ファイルが無いのに INVOCATION だけ増えると、運転している錯覚が起きる
胡田氏の hyperv-nestlab が長時間で回るのは、冪等な中間状態があるからだ。ITPRODX側も DONE ログ と outputs/<date>/ のファイル存在の両方を見ないと、同じ錯覚を起こす。
実装チェックリスト
-
エンジン切替時:
grep -r 'codex\|cursor-agent' ~/Claude/automation ~/Projects/ai-company-24hで横断確認 -
~/.config/itprodx/agent-engineの値と、各 runner の 実際の起動コマンド が一致しているか -
cursor-agent -pにプロンプトを渡す経路は CLI引数 か（stdin パイプは非対応） -
成功判定:
runner.logのDONE+ 成果物パスの 両方 を日次で確認 - 外向きアクション（公開・送信・デプロイ）はランナーから直接実行しない（Telegram 承認ゲート）
-
Mac sleep 設定（
pmset）とcaffeinateの組み合わせを就寝前に確認（sleep=1 設定は暗転リスク） -
エンジン切替決定は
30_Decisions/に残し、次回同じ轍を踏まない
失敗パターン
パターン1：エンジンは切り替えたが runner.py だけ古い → 対策: 切替当日に runner.py / plist / shell ラッパーを同一PR（または同一コミット）で更新。8/15〜8/17の0成果物はこの典型例。
パターン2：No prompt provided for print mode が exit=0 → 対策: ランナーログで stderr を grep し、stdout が空でも失敗扱いにする。agent-skill-exec.sh の stderr tail を監視対象に入れる。
パターン3：INVOCATION だけ増えて成果物が増えない → 対策: HQ日報の _token-meter（成果物本数）を朝一で見る。113 INVOCATION / 0 本（8/17）は異常信号。
パターン4：長時間ループに完了条件がない → 対策: 胡田氏事例のように、YAML/README/pytest 等で 機械判定可能な中間ゲート を先に書く。/goal や「続けて」頼みだけにしない。
参考リンク
- Claude Codeを5時間放置｜AIに自律でインフラを作らせる時代（YouTube）
- ebibibi/hyperv-nestlab（GitHub）
- 胡田昌彦氏 情シス・SIer向けページ（ebisuda.net）
- ITPRODX HQ決定記録:
00_Codex_HQ/30_Decisions/2026-08-15-hq-morning-cursor-engine.md（ローカル）
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
問い合わせ対応の自動化や、AIエージェントの長時間運転の設計については itprodx.com からご相談ください。日々の検証ログは note でも発信しています。