寝てる間に動く無人開発チームを作った話——Claude Code＋タスクスケジューラの最小構成
何の話か
「オーナーが寝ている間に、昨日の状況を踏まえて優先順位を決め、実装し、自分でレビューし、朝までにまとめる」——これを無人で回す、というのが今回の試みだ。
Zennに投稿されたエンジニア・01zerone氏の記事は、Claude CodeとWindowsタスクスケジューラだけでそのAIループを構築した記録だ。n8nもLangChainも使わない。外部のオーケストレーション基盤に頼らず、PowerShellスクリプト1本と標準のタスクスケジューラで最小構成を組んでいる。
実験的な試みには違いない。だが、この記事が面白いのは「動かしてみた」自慢ではなく、設計判断の理由と、踏んだバグの記録がきちんと残っているところだ。実務感がある。
なぜ今この話が重要か
「AIをどう使うか」の話から、「AIをどう運用設計するか」の話へ、議論の重心が移っている。
プロンプトを書けばAIが動く、というフェーズはとっくに終わった。今の現場で問われているのは、AIをいつ・どのタイミングで・どんな権限で動かすかという運用設計の話だ。
この記事が描いているのはまさにそこだ。「深夜に動く無人チーム」という言葉は派手だが、その実態はシンプルな設計判断の積み重ねである。そして、その判断のひとつひとつに、AI運用の現在地が透けて見える。
ソロ開発者や副業エンジニア、あるいは小規模なプロダクトチームにとって、「自分が席を外している間も開発サイクルを回し続ける仕組み」の需要はじわじわと高まっている。今回の事例は、その実装の最小単位を示した記録として読める。
具体的な構成——6サイクル、役割別プロンプト
システムの全体構成はシンプルだ。1日6回（22時・0時・2時・4時・6時・8時）、タスクスケジューラが同じスクリプトを起動する。スクリプト側は起動時刻（Get-Date).Hour）で分岐し、その時間帯に対応したテーマを割り当てる。
22時：棚卸しと優先順位決定
0時：機会探索
2時：実装
4時：完成度を上げる
6時：最終チェック
8時：朝の報告
各サイクルで claude -p $prompt --allowedTools "Read,Grep,Glob,Write,Edit,WebSearch" を呼び出す形だ。前のサイクルが出力したファイルを次のサイクルが参照することで、夜通しのコンテキスト継承が成立する。
実際に1晩動かしたところ、6サイクルすべてが正常終了。最後のサイクルが自分たちの成果物を自己レビューし、顧客への案内漏れを1件発見して自分で修正した、と記事には記されている。朝起きた時には、前夜の判断・実装・自己レビューの記録が1ファイルにまとまっていた。
設計判断1：シェル実行権限を渡さない
この記事で最も注目したい判断がこれだ。
--allowedTools に渡しているのは Read, Grep, Glob, Write, Edit, WebSearch, PushNotification のみ。BashもPowerShellも一切渡していない。
外部APIの呼び出しやスケジューラの登録といった「実行を伴う作業」は、無人セッションにやらせない。無人セッションは「ファイルを読み書きするだけ」に制限し、実行が必要な項目は tasks.md に「実行待ち」として書き出させる。翌朝、人が同席するセッションでそれを確認してから実行する、という設計だ。
記事の言葉を借りれば、「10時間×6サイクル、無監督で動くシステムほど、実行権限は最小にしておく価値がある」。
ここからは見方になるが、これは技術的な制約というより、思想の問題だと思う。AIに「できること」と「やらせること」は別だ。APIを叩ける権限があるからといって、無人セッションにそれを渡す理由はない。監督のない時間帯こそ、権限を絞る。障害の影響範囲を人間が制御できる形に留める。この判断は、AI運用における一種の倫理的な設計指針でもある。
設計判断2：1プロセス長時間ループではなく6回の個別起動
もうひとつの判断は、アーキテクチャの話だ。
当初は while ((Get-Date) -lt $endTime) { ...; Start-Sleep } という1プロセスの長時間ループも検討された。しかし採用しなかった。理由は明確だ。
- 1回のサイクルがハングした時、後続の5サイクルも巻き添えで止まる
- タスクスケジューラの実行結果コードが「1プロセス丸ごと」でしか取れず、サイクル単位の成否が追えない
タスクスケジューラの複数トリガーに任せることで、1サイクルの失敗が他のサイクルに影響しない。Get-ScheduledTaskInfo で各起動の結果コードを個別に確認できる。
これはAIとは関係なく、障害分離（Fault Isolation）の基本だ。長時間プロセスを1本走らせるより、短いプロセスを独立して複数回起動する方が、障害の局所化がしやすい。クラウドインフラの設計でも同じ原則が使われる。AIループを設計するときに同じ考え方が適用されているのは、実務的に正しい判断だ。
ハマったバグ——2つの教訓
記事が正直に記録しているのが、実運用で踏んだバグだ。
バグ1：日本語が文字化けしてJSONが壊れた
claude -p や自社CLIツールの出力をPowerShell変数に取り込むと、日本語が文字化けする。ひどい時はJSON構造そのものが壊れて解析エラーになった。原因は [Console]::OutputEncoding を明示していなかったこと。PowerShell 5.1はデフォルトでシステムのANSIコードページ（日本語環境ならcp932）で外部プロセスの標準出力をデコードする。UTF-8で書き出されたテキストが、この経路で化ける。
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
スクリプトの先頭にこの1行を足すだけで解決する。ただし気づきにくいのは、化けたデータがそのままファイルに書き込まれてログが汚染される点だ。今回は活動ログに巨大な壊れたJSONが挿入されるまで誰も気づかなかった、とある。外部プロセスの出力を変数で受けるPowerShellスクリプトを書くなら、まずこの1行を確認する習慣を持つべきだ。
バグ2：無人セッションが質問で止まった
プロンプトに「無人実行のため質問で止まらず完走すること」という一文を入れていなかった。あるサイクルが実行途中でオーナーへの確認を求めて停止し、誰も答えられないまま止まっていた。
対処はシンプルで、「不明点があっても質問せず、合理的な解釈で最後まで完走すること」をプロンプトに明記する。対話的なプロンプトをそのまま無人実行に転用すると高確率で踏む、というのが教訓だ。
これも実務感があるバグだ。Claude Codeを普段インタラクティブに使っているエンジニアが、そのプロンプトをそのままバッチに流す。その瞬間に起きやすい落とし穴だ。
AIおじさんとしての見方——「すごいことが起きる」わけではない
記事の末尾に、このプロジェクトの本質をついた一文がある。
「無人ループの価値は『何かすごいことを発見する』ことより、『起きている間に決めたルールを、寝ている間も律儀に守り続けてくれる』ことにある」
これは期待値の話として正直だと思う。無人AIループを組むと、夜の間に世紀の大発見をしてくれるとか、予想外のアイデアが生まれるとかを期待する人もいるだろう。実態はそうではない。昼間に人間が決めた方針を、夜間も粛々と実行し続けるというのが、このシステムの本質だ。
それ自体に価値はある。ただ、それは「何もしなくてもAIが勝手に何かを生み出す」とは本質的に違う。
次の論点として気になるのは3点だ。
コスト管理：6サイクル×毎日動くとなると、Claude APIのコストが積み上がる。記事では具体的なコスト感には触れていない。実際に運用するなら、ここを見積もる必要がある。
ログ監査とトレーサビリティ：無人で動くシステムが何を判断し、何を書き換えたかを後から追えるか。今回は「1ファイルにまとまっていた」とあるが、規模が大きくなるにつれてログ設計は複雑になる。
意思決定の責任帰属：無人セッションが「合理的な解釈で完走」した結果、誰かに不利な影響が出た場合、それは誰の責任か。小規模な個人プロジェクトなら問題は小さいが、チームや外部サービスに影響が及ぶ規模になると、この問いは避けられない。
実務的な示唆
ソロ開発者、副業エンジニア、小規模プロダクトの運営者にとって、この設計は参考になる部分が多い。特に以下の3点は応用しやすい。
- 権限の最小化を最初の原則にする：
--allowedToolsの設定は後付けでなく、設計の出発点にする - 長時間プロセスより短サイクルの独立起動：ハングのリスクとデバッグのしやすさを考えると、個別起動の方が運用は楽だ
- 無人プロンプトは別途設計する：対話用プロンプトを流用しない。「質問しない」「合理的な解釈で完走」はテンプレートとして持っておくべき一文だ
インフラとしての複雑さがないぶん、導入障壁は低い。Windows環境とClaude Codeのアクセス権さえあれば、今日から試せる。その分、設計の良し悪しがそのまま結果に出る。この記事が記録した判断の積み重ねは、同じものを作ろうとする人にとって、スタート地点として読む価値がある。
