こんにちは。もるふぉです。
夜中の2時、git worktree add を打って、新しい環境変数をコピーして、Claude Codeを起動して、もう一個ターミナル開いて、別のworktreeで違うタスクを走らせて……ってやってる途中で「あれ、自分は今コードを書いてるんだっけ、それともworktreeの世話してるんだっけ」と虚無になった経験、ありませんか。
自分はあります。
並列AIエージェントを動かしたい気持ちはあるのに、お膳立てが面倒すぎて結局シングルスレッドでClaude Codeを叩き続けて、1機能しか進まないまま朝になる。
そんな中、こんなリポジトリを見つけました。
英語圏で「TypeScript Wizard」と呼ばれているMatt Pocockさんが、まさにこの「夜にAIエージェントを並列で走らせて、朝にマージレビューだけする」という運用を可能にするツールをOSSで公開している。
sandcastle という名前です。
これ、軽く触ってみたんですが、マジでいいんですよ。
何がいいって、git worktree の手動管理から完全に解放されます。
ということで本記事では、sandcastleの正体・テンプレート・実装イメージ・安全設計・導入判断までを、私の視点でまとめていきます。
「夜寝てる間に開発を進めたい」と本気で思っているエンジニアにこそ読んでほしい内容です。
AFK開発とは何か——「離席中に仕事が進む」時代の到来
AFK（Away From Keyboard）の意味と開発への転用
AFKというのは元々ゲーマー用語で、「Away From Keyboard」、つまり「キーボードから離れている状態」のことです。
これを開発文脈に転用したのが「AFK開発」という概念で、要するに「自分がキーボードを叩いていない時間にも開発が進んでいる状態」を指します。
具体的に言うと、寝てる間、ご飯食べてる間、子供の送り迾えしてる間に、AIエージェントが複数のタスクを並列で消化していて、自分が席に戻ったときには「成果物がコミット済みで、あとはレビューだけ」という状態になっている。
これがAFK開発です。
「いやそれって理想論でしょ」と思った方、自分も最初はそう思ってました。
ところが、Matt Pocockさんが実際にこれを日常運用しているという話を聞いて、考えが変わりました。
Matt Pocockさんが実証した「夜5タスク、朝レビューだけ」ワークフロー
Matt Pocockさんは、TypeScriptコミュニティで「TypeScript Wizard」と呼ばれている、英語圏では非常に有名なエンジニアです。
Stately（XStateのコアチーム）→VercelのDeveloper Advocate→Total TypeScript独立、というキャリアの方で、TypeScriptに関する知見の深さは折り紙付き。
そのMattさんが公開している .claude 設定集である skills リポジトリは、現時点で49,100スター超え。
ネタ元投稿によると、夜間に5タスクを並列で走らせて、朝起きたらマージレビューをするだけ、というワークフローを日常的に回しているらしいんですよ。
これ、最初聞いたときは「いや、5並列って衝突しないの？」「sandboxどうしてるの？」「マージで死ぬのでは？」と疑問しか湧かなかったんですが、それを解決するために作られたのが sandcastle というわけです。
次のセクションで、その具体的なカラクリを見ていきます。
sandcastleの正体——並列AIエージェント管理専用フレームワーク
git worktreeの手動管理とsandcastleの決定的な違い
sandcastleは、TypeScript製のOSSフレームワークで、並列AIエージェントを管理することに特化しています。
最新リリースは2026年4月29日のv0.5.6。
ここがミソなんですが、sandcastleは「git worktreeを自分で叩く」という手作業を完全に隠蔽してくれるんですよ。
普段やってるであろう手作業を思い出してみてください。
git worktree add ../feature-a-task1 -b feature-a-task1
cd ../feature-a-task1
cp .env ../current/.env
npm install
claudeこれを5タスク分やる、ですよ。
しかも各worktreeで違うブランチ戦略にしたい、終わったらマージしたい、失敗したら掃除したい、コンテナのライフサイクルも管理したい……となると、結局シェルスクリプトを自作するハメになる。
自分も過去に書きました。書いたんですが、メンテが面倒すぎて結局放置しました。
sandcastleは、この一連の流れを sandcastle.run() という1つのAPIに集約しています。
いわば「並列エージェント管理の煩雑な儀式を全部やってくれる執事」みたいなものです。
自分はコードを書かなくていい。仕事の指示だけ出せばいい。
sandcastle.run()が解決する3つの問題
sandcastle.run() は、ざっくり以下の3つを一気に面倒見てくれます。
head / merge-to-head / branch（名前付きブランチ）から選択onWorktreeReady / onSandboxReady フックで宣言的に書けるこれ何が嬉しいかっていうと、「並列で走らせる前準備」と「並列で走らせた後処理」のコードを毎回書かなくていい、という一点に尽きます。
毎回のスクリプト作業が sandcastle.run() の呼び出し1行に集約される。感覚的には、Dockerfileを書く前にDocker Composeがあって「あ、これでよかったのか」と気づいたときの感じに近いです。
しかも branch strategy が型で守られているので、「あれ、どのブランチに今のエージェントを乗せるんだっけ」みたいな事故が起きにくい。
これだけでも自分は乗り換える価値があると感じました。
対応プロバイダー：Docker / Podman / Vercel
sandcastleは、エージェントを動かすsandboxとして以下のプロバイダーに対応しています。
- Docker
- Podman
- Vercel（クラウドのFirecracker microVMs）
ローカルで完結したいならDocker/Podman、クラウドで分散させたいならVercelという使い分けですね。
ローカル開発機のリソースを食い潰したくないなら、夜間バッチでVercel側に逃がすのもアリだと思います。
ここで重要なのは、「ホストマシンに直接エージェントを走らせる選択肢」がデフォルトでは封じられている点です。
これ、地味にすごい設計思想なんですが、後ろの章で詳しく触れます。
ではテンプレートの話に入りましょう。ここが一番「実際にどう使うのか」がイメージしやすい部分です。
sandcastleの5つのテンプレートと選び方
sandcastleには現在5つのテンプレートが用意されていて、ユースケースに応じて使い分けます。
blanksimple-loopsequential-reviewerparallel-plannerparallel-planner-with-review5つあるとはいっても、AFK開発目的で最初に覚えるべきは実質2つです。
parallel-plannerの動作フロー：計画→並列実行→マージ
主役はやっぱり parallel-planner です。
AFK開発の核になるテンプレートなので、ここだけは押さえてほしい。
動作フローをざっくり書くとこうなります。
- プランナーエージェントが、与えられたタスクを複数のサブタスクに分解する
- 各サブタスクが個別のworktree/sandboxで並列に実行される
- 全部終わったら、結果がメインブランチに統合される
ポイントは「サブタスク同士が衝突しない設計」を最初のプランナーが組み立ててくれるところ。
たとえば「APIのエンドポイント追加 / フロントの画面追加 / E2Eテスト追加」みたいに、ファイルが被らないタスクに分割するわけです。
ここ、想像してみてください。今まで「衝突しないように順番に走らせるしかない」と思って直列でやってたタスクが、人間がプランを考えなくてもプランナーが分解してくれて、勝手に並列で走る。
これがちゃんと機能するなら、確かに夜の間に5タスク並列で走らせて朝レビューだけ、という運用も現実的になります。
parallel-planner-with-reviewが向いているケース
parallel-planner-with-review は、parallel-plannerの最後に「レビューエージェント」を挟むバリエーションです。
実装→自動レビュー→必要なら修正、というフローが組まれます。
向いているのは以下のようなケース。
- セキュリティ要件があるコード（認可ロジック、入力バリデーション等）
- マージレビューに使える時間が限られている朝
- 複数人レビューが必要だがまだチーム外秘のコード
「朝のレビュー時間を圧縮したい」という用途では、これが一番刺さります。
simple-loopとsequential-reviewerの使い分け
残り2つのテンプレートは目的が明確に違うので、簡単に。
simple-loop: 「同じプロンプトを5回試して一番良いやつを選びたい」みたいな評価用途。AIエージェントの精度比較や、プロンプトの安定性検証で使うsequential-reviewer: 1エージェントが実装→別エージェントがレビュー→修正、という直列パイプライン。並列ではなく品質重視のときに使う
AFK開発の文脈で主役になるのは parallel-planner 系の2つで、残りはオプション、と覚えておくのが実務的かなと思います。
テンプレートを選んだら、次は「どうプロンプトを書くか」が鍵になります。ここで失敗すると、夜中に5体全員が固まります。
Claude Codeとsandcastleで実現するAFK開発の実際
.sandcastle/prompt.mdの書き方と注意点
sandcastleでは、エージェントに渡すプロンプトを .sandcastle/prompt.md のようなファイルで管理するのが一般的です。
ここで気をつけたいのは、「夜に5タスク並列で走らせる」という前提だと、プロンプトの曖昧さが致命傷になるということ。
昼間にClaude Codeを対話的に使っているときは、エージェントが質問してくれば答えればいい。でも夜寝てる間に走らせるなら「質問されたら止まる」という挙動が一番困る。
なので、プロンプトには以下を必ず明記します。
- ゴール条件（どうなったら完了か）
- 制約条件（触っていいファイルの範囲、外部API叩いていいかなど）
- テストの実行方法と合格基準
- 不明点があった場合のフォールバック動作（質問せずに保守的に倒すなど）
特に最後の「不明点があった場合のフォールバック」は重要で、ここが抜けてると夜中に5体のエージェントが全員プロンプトの前で固まっている、という地獄が発生します。
「朝起きたら誰も1行も書いてない」というのは、笑えない話です。
並列エージェントが衝突しないための設計原則
並列エージェントを動かすうえで一番ハマるのが、ファイルの衝突です。
parallel-planner がプラン段階でうまくタスクを分割してくれるとはいえ、人間側でも以下の原則は意識しておきたい。
- 1タスク=1機能（ファイルの責務が分かれていること）
- 共通の設定ファイル（package.jsonやtsconfig）は触らせない、もしくは1タスクに集約する
- 共通ライブラリの修正は別タスクとして直列に流す
- マイグレーションは1個ずつ、絶対に並列で走らせない
特にDB関連は地獄を見るので、マイグレーション系は sequential-reviewer のような直列テンプレートに分けたほうが安全です。
ここは経験則ですが、自分は「DBスキーマ触るタスクは並列禁止」というルールを徹底してます。
朝のマージレビューに集中するための準備
AFK開発の真価が発揮されるのは「朝のマージレビュー」のフェーズです。
逆に言うと、ここがちゃんと回せないと、夜の並列実行は無意味になります。
朝のレビューを楽にするために自分が意識しているのは以下の3点。
- 各タスクで必ずテストを書かせる（テスト駆動でAIを制御するのは基本）
- 差分が大きくなりすぎないよう1タスクのスコープを絞る
- セッションキャプチャを活用して、エージェントが何をやったかの再現性を担保する
sandcastleはセッションキャプチャ機能を持っていて、Claude Codeエージェントの動作を後から再開できるようになっています。
これが地味に便利で、「朝レビューしてみたら微妙な実装だったから、ここから差し戻したい」というときに、最初から走らせ直さずに途中から修正させられるんですよ。
手作業のworktree運用ではまず実現できない芸当です。
ここまで「何ができるか」を見てきましたが、自分が一番感心したのは「何をさせないか」の設計です。次で詳しく説明します。
sandcastleの「サンドボックス必須」設計思想
AFK実行で no-sandbox が型レベルで禁止される理由
ここがsandcastleで自分が一番感心したポイントなんですが、AFK実行モードでは「sandboxを使わない」という選択肢が型レベルで禁止されています。
つまり、TypeScriptのコンパイル段階で「ホストマシンに直接走らせる構成」を書こうとするとエラーになる。
これ、何が嬉しいかというと、「設定ミスで本番環境のシェルにエージェントが直アクセスする事故」を物理的に起こせなくしてくれるんですよ。
夜間にAIエージェントを5体走らせて、そのうち1体が rm -rf を打ってホスト環境を消し飛ばす、みたいなホラーは絶対に避けたい。
設計者がこの危険性を理解した上で「使わせない」と決めた設計思想は、シニアエンジニアとして本当に頷けます。
「できる設計より、できない設計のほうが安全なことがある」。これ、APIを設計するときにも言える話ですよね。
no-sandbox を使えるのはあくまで対話モード（人間が見張っている時）だけ、という割り切り方が綺麗です。
DockerとVercelの使い分け基準
実務での使い分けはざっくりこう考えています。
個人的には、最初はDockerで試して、慣れたらVercelに逃がすのが現実的なルートだと感じています。
Dockerならローカルで完結するので、APIキーの取り扱いとか機密ファイルへのアクセスとかが気にならないし、デバッグもしやすい。
sandcastleの導入判断——向いているプロジェクト・向いていないプロジェクト
正直に書きます。
sandcastleは万能ではないし、全プロジェクトに必要なわけでもない。
向いているケース、向いていないケースを率直に並べておきます。
sandcastleが向いているケース
- 1日に複数機能を実装したい個人開発・スタートアップ
- 機能追加が多く、ファイル責務が綺麗に分かれている中規模アプリ
- テストがちゃんと書かれていて、CI/CDが整備されている
- Claude Code/Cursor/Codexなど複数エージェントを既に使い分けている
- 夜間バッチ的に開発を進めたい習慣がある
sandcastleが向いていないケース
- 1日1機能で十分回るスケールの小規模プロジェクト
- ファイルの責務が混在していて、並列でのファイル衝突が頻発しそう
- テストカバレッジが低く、AIの出力を検証する手段が乏しい
- DBスキーマ変更や大規模リファクタが多い時期
- まだClaude Codeに慣れていない（先にシングル環境で慣れたほうがいい）
最後の点は重要で、Claude Code単体でも使いこなせていない状態でいきなり並列5体に挑むと、デバッグが地獄になります。
「シングルClaude Codeを完全に手懐けてから、次のステップとしてsandcastleに来る」という順番をおすすめします。
「あ、これ今の自分のプロジェクトに使えそうだ」と思った方は、まずREADMEを眺めるところから始めてみてください。
sandcastleまとめ——「コードを書かない」の次は「夜に並列実行させる」
自分はずっと「書ける人が書かなくなる」というスタンスで発信してきました。
その先にあるのが、「書かない人が、夜に複数のエージェントに同時に書かせる」というフェーズなんだと思います。
sandcastleはそのフェーズに必要なインフラを、TypeScriptネイティブで、安全設計込みで提供してくれているOSSです。
特に以下の3点は、自分にとって決定的でした。
git worktreeの手動管理から解放されるparallel-plannerがタスク分割と並列実行を一気通貫でやってくれる- AFK実行モードで
no-sandboxが型レベルで禁止されている安全設計
夜中の2時にworktreeのスクリプトをポチポチ書いていた頃の自分に、「もうそれ要らなくなるよ」と教えてあげたい気持ちです。
まだv0.5.6で発展途上なので、本番のクリティカルなプロジェクトで使うのは慎重になるべきだと思います。
ただ、個人開発や副業案件、検証用のリポジトリでは、今すぐ試す価値があるツールです。
最初のステップはシンプルです。
READMEを眺めて、parallel-planner テンプレートのコードを眺める。それだけでいいです。インストールも設定も、その後で十分。
自分はこれを機に、夜のうちに並列タスクを仕込んで朝にレビューだけやる、という運用を本格的に始めようと思っています。
「コードを書かない」の次は「夜に並列実行させて、朝レビューだけする」。
エンジニアの働き方が、また一段変わる気がしています。
それでは、また。
- 2
- 0
日系メガベンチャー → 外資系ITプログラマー → ベンチャーCTOを経て独立。 現在はAI駆動開発で実案件を回してます。
クリエイターの他の記事
-
コードをかかないAIエンジニア
- 33
- 1
-
- 24
- 1
-
- 7
- 0
-
- 7
- 2
こちらもおすすめ
-
- 3
- 0
-
- 2
- 0
-
AI脱社畜
- 3
- 0
-
- 2
- 0
-
- 2
- 0
-
AI経営者の参謀@ひで
- 28
- 1
-
- 33
- 1
-
- 7
- 2
-
- 1
- 0
-
- 1
- 0
-
- 1
- 0
-
- 1
- 0
-
プロンプト画伯
- 3
- 0
-
- 2
- 0
-
- 2
- 0
-
AI集客@ルイ
- 2
- 0
-
- 3
- 0
-
- 2
- 0
-
- 4
- 1
-
- 6
- 0
AimanaVo
あなたのAI知見も、資産にしませんか？
読んだ・試した・気づいた — そんな体験が誰かの力になる。 有料記事で収益化も、アフィリエイトも。
💬 コメント
ログイン か 会員登録 するとコメントできます