何が起きたか
朝起きてCursorを開いたら、AIの作業が8回目まで進んでいました。
寝る前にやったのは、方針を決めて、Claude Codeのセッションをいくつか開いておいたことだけです。1回1時間ほどの作業が終わるたびに、数分後には次の回が勝手に始まっていました。そのあいだ、自分は一度も手を出していません。起きて見張っていた人もいません。見張っていたのも、AIです。
自分は受託開発のPMとして、10年ほど人のチームを回してきました。AIで開発するようになってからは、Claude Codeのセッションを何本も並べて動かすのが当たり前になっています。ただ、その運用には、ずっと困っていたことがありました。AIとAIのあいだを取り持つのが、自分の仕事になっていたことです。
この記事では、その「中継係」をAIに引き継いだやり方を書きます。AIを1つ司令塔として立てて、残りのセッションを回してもらう運用です。
題材と環境
| 項目 | 内容 |
|---|---|
| 題材 | 自作ツールの大きな改修（具体は伏せる）。中心はテストの作り直しで、1回1時間ほどの作業が十数回続く |
| 環境 | Mac（メモリ16GB）。Cursorの中でClaude Codeを動かす |
| 体制 | 司令塔のセッション1つと、作業役のセッション（夜の分として15個を先に開いておく） |
中継係から司令塔へ
長い作業をAIに任せるとき、自分は作業を「回」に分けています。1回を1つのセッションでやり切り、終わったら新しいセッションで次の回を始めます。1つのセッションに詰め込みすぎると、終盤でコンテキストがあふれて、AIが最初に読んだ決まりを忘れ始めるからです。
回の最後には、次のセッションを始める文（キックプロンプト）をAIに書いてもらいます。次の回のAIは、この文を読んで仕事を始めます。
困っていたのは、このキックプロンプトを次のセッションに貼るのが、自分だったことです。AIが「終わりました。次はこの文で始めてください」と言う。自分がそれをコピーして、新しいセッションに貼る。1時間後、また同じことをする。中身を読んで判断しているわけでもない、ただの伝言です。それでも、自分が寝れば全部が止まります。
最初の一手は単純で、この伝言だけを別のセッション（運び役）に頼みました。そのときの指示は、記録にこう残っています。
内容を理解する必要はない・無駄な token は使わずに、終わったことを確認したら次のセッションに運ぶことが仕事
これで伝言は自分の手を離れました。ところが、それでも作業は止まりました。
作業をしているAI（作業役）は、途中で判断が要ると、こちらに聞いてきます。「この部分は、この回に入れますか。次の回に分けますか」。推奨と理由と、ほかの選び方まで並べた、よくできた問いです。ただ、中身を読まない約束の運び役には答えられません。止まったセッションを前に、自分が言ったのはこの一言でした。
判断してくれる人がいないと止まる
そこで、運び役に判断も任せることにしました。伝言係ではなく現場を回す役になったので、名前も「司令塔」に変えています。寝る前に頼んだのは、これだけです。
あらかじめセッションを起動しておいて、一人司令を立てて監視と判断をし続けて俺が寝てる間に全てを終わらせるようにしたい
司令塔に任せることと、人に残すこと
司令塔の仕事は4つです。
- 運ぶ：作業役が書いたキックプロンプトを、次の作業役に渡す
- 判断する：作業役が止まって聞いてきたら、決めて答える
- 照らし合わせる：作業役の報告が受け入れ条件を満たしているかを見る（レビュー役を兼ねる）
- 見回る：1時間ごとに、止まっている作業役がいないかを見る
ただ、判断を任せるといっても、何でも任せたわけではありません。任せる前に、司令塔が決めていいことと、人に聞くことを分けておきました。
司令塔が自分で決めていいこと：
- 作業の手順
- 作業を何回に分けるか（「この回に収まらないので分けたい」への答え）
- 確かめ方
決めずに人に聞くこと：
- 作るものの方向を変える判断（機能の追加や削除、ゴールの変更）
- 元に戻せない操作（ファイルの削除など）
- 人の目でしか確かめられないもの（見た目や使い心地）
聞くことに当たる問いが夜中に出たら、司令塔はそれを決めずに保留して、朝の自分に回します。そのあいだも、止める必要のない部分は進めてもらいます。
確かめ方も、夜と朝で分けました。夜のあいだは機械で判定できるチェックだけで進め、人の目で見たいものは朝にまとめて見ます。こうしておけば、人の目が要る場面が来るたびに止まらずに済みます。
人のチームでも、任せる範囲と上に上げる範囲を先に決めておかないと、任された側は全部を聞いてくるか、全部を勝手に決めるかのどちらかになります。AIでも、そこは変わりませんでした。
引き継ぎ書とキックプロンプトの設計
判断を任せるには、司令塔がいまの状況を分かっている必要があります。ところが、司令塔の手元に届くのは、作業役が送ってくる文と、ファイルに書き残したものだけです。そこで、作業役が回の終わりに何を書き残し、次の回が何から読み始めるかを、先に決めておきました。
回の終わりに書かせる2つのもの
作業役は回の終わりに、必ず次の2つを書きます。
- 引き継ぎ書：その回でやったこと、確かめた数字、やらなかったこと、次の回への申し送り。節の見出しは毎回同じ
- キックプロンプト：次のセッションを始める文
引き継ぎ書は、チームの議事録と引き継ぎメモを兼ねたものです。次の回の作業役はまずここを読み、前の回のセッションの記憶には頼りません。
キックプロンプトの型
キックプロンプトは、この型で書かせています（中身はぼかしています）。
（作業の名前）の3回目をしてください。計画は引き継ぎ書の§12。
目的は〜。決まりは〜（やってはいけないこと）。
最初に読むファイル（この順）:
1. 記憶の索引
2. 引き継ぎ書の§11の全部（とくに次の回への申し送り）
3. 作業の記録の最後の数件
最初にすること: スリープ止めを動かして、効いているかを確かめる。
今の状態を確かめること（記録をそのまま信じない・数は実行して確かめてから書く）:
- 前の回が終わったときと同じ状態か（テストの数・ファイルの数）
進め方:
- 作る前に、確かめた結果と計画から変える点を、引き継ぎ書の新しい節に書く
- 1つのセッションに収まらないと分かったら、そこで止めて分け方を聞く
- 判断が要るときは、まず司令塔に聞く
やらないこと: 〜
終わったら: 結果を引き継ぎ書に書き、記録を直して、次のセッションを始める文（キックプロンプト）を出して止まる。同じ文を司令塔にも送る（1行目に「終わったときの文」か「途中の続きの文」かを書く）。
最後の「終わったら」の段落があるので、作業役は自分の回を終えると、次の回の始め方まで書いてから止まります。次の作業役も同じ型で始まるので、また次を書く。こうして作業が鎖のようにつながっていき、司令塔はその鎖を次のセッションに渡すだけで済みます。
もうひとつ効いているのが、「記録をそのまま信じない・数は実行して確かめてから書く」の一文です。次の回の作業役は、前の回が書いた数字を写さず、テストを回し直してから書き始めます。前の回の記録に誤りがあっても、次の回の入口で、数字の食い違いとして見つけやすくなります。
運ぶ前に2か所の文を突き合わせる
キックプロンプトは、引き継ぎ書の中と、キックプロンプトだけを集めたフォルダの2か所に残させています。司令塔は運ぶ前に、この2つが1字も違わないかを機械で確かめます。違っていたら、作業役がまだ書き終えていないか、どちらかを書き損じたということなので、運びません。
作業役が司令塔に送る文の1行目には、「終わったときの文」か「途中の続きの文」かが書いてあります。司令塔は中身を全部読まなくても、次に運ぶべきか、待つべきかが分かります。
司令塔に渡した決まりのファイル
司令塔の側にも、決まりを書いたファイルを1つ渡してあります。決めていいことと聞くことの分け方や、上の突き合わせ方を書いたものです。作業役が引き継ぎ書を書いているあいだは同じファイルに手を出さない、という約束も入れてあります。司令塔の答えは、作業中はメッセージで伝えるだけにして、引き継ぎ書に書くのは作業役が書き終えて止まってからです。
どの回の作業役も、前の回のセッションの記憶には頼らず、書いて残されたものだけを頼りに動きます。この運用を回しているのは、AIの賢さよりも、書き残すものの設計です。
引き継ぎ書を書かせる運用は、236画面の仕様書をAIで作ったときに始めたものです。AIの代替わりで何が起きたかはこちらに書いてます。
AIの出力を信用するな——236画面の仕様書を自動生成して学んだこと
セッション間のメッセージ、見回り、スリープ止め
仕組みの部分は、思ったより地味です。Claude Codeには、同じPCで動いているほかのセッションの一覧を見る機能（ListAgents）と、ほかのセッションにメッセージを送る機能（SendMessage）があります1。司令塔は、これで作業役にキックプロンプトを渡します。送るときに「止まったら知らせて」と頼んでおくと（notify_when_idle）、作業役が止まったときに司令塔へ知らせが届きます。司令塔はふだん、この知らせを待っているだけです。
作業役にはa、b、c……と名前を付けて、開いた順に使っています。ただ、送り先は名前ではなく、セッションごとに決まっているソケット2で指定しています。一覧に出るセッションの名前が、別々のセッションで同じになっていたことがあったからです。
知らせを出さずに止まる作業役がいても気づけるように、司令塔には1時間ごとの見回りも入れました。Claude Codeの定期実行（CronCreate）で、今の作業役が動いているかを確かめさせています。
最後がスリープ止めです。Macが寝てしまうと全部止まるので、各セッションに caffeinate を動かさせています。
# このセッション（Claude Codeのプロセス）が生きているあいだ、スリープさせない
caffeinate -is -w <Claude Codeのプロセス番号>
全体の流れを図にすると、こうなります。
一晩で起きたこと
時刻は、どれもセッションの記録にある実測値です。
| 回 | 中身 | 始まり | 終わり |
|---|---|---|---|
| 1 | 測って表を作る | 01:13 | 02:44 |
| 2 | 作り直しの計画 | 03:20 | 04:06 |
| 3 | 作り直し（1） | 04:15 | 05:27 |
| 4 | 作り直し（2の前半） | 05:32 | 06:56 |
| 5 | 作り直し（2の後半） | 07:03 | 08:05 |
| 6 | 作り直し（3） | 08:10 | 09:09 |
| 7 | 作り直し（4） | 09:13 | 10:23 |
| 8 | 作り直し（5の前半） | 10:32 | 11:44（起きたときは途中） |
1回目と2回目のあいだが空いているのは、自分がまだ起きていて、方針を決めていたからです。2回目が終わってからは、4〜9分で次の回が始まっています。3〜7回目の長さは、1回59〜84分でした。
06:22、4回目が1つのセッションに収まらない
4回目の作業役が、06:22に司令塔へ相談してきました。この回に予定していた部分を全部入れると、1つのセッションに収まらない。次の回に分けたい、という内容です。
司令塔の答えは、同じ06:22に返っています。「推奨どおり、2つに分ける」。後半は5回目の作業役が07:03から引き継いで、08:05に終えました。4回目と5回目が「2の前半」と「2の後半」に分かれているのは、このときの判断によるものです。自分が起きていても、たぶん同じ判断をしていました。
機械のチェックとミューテーションテスト
3〜7回目では、書いたものが決まりに合っているかを機械で調べるチェックが、5回とも1回ずつ引っかかっています。そして5回とも、作業役がその回の中で書き直し、チェックを通してから次に渡していました。朝の記録に残っていたのは、「引っかかって、直した」という報告だけです。
作り直したテストが本当に効いているかも、毎回確かめています。わざとコードを壊して、テストがそれに気づくかを見るやり方（ミューテーションテスト）です。5回で試した壊し方は合わせて696通りで、どの回も、すべてにテストが気づいたことを確かめてから次の回に渡しています。
10:48、人に聞くと決めていた種類の問い
8回目の作業役は、10:48に、今あるコードを直すかどうかに関わる判断を持ってきました。人に聞くと決めていた種類の問いです。
司令塔は10:49に、その1件を決めずに保留にして外し、残りを進めるよう答えています。あわせて、起きた自分に聞く項目として積んでおきました。8回目は、その1件を除いた分をすべて確かめて、11:44に終わっています。起きると、その問いが、判断に要る材料と一緒に待っていました。人の目で見てほしいもの（回ごとの確認の一覧）も、同じように積んであります。
一晩回して分かった注意点
- 送る前に、相手が生きているか確かめる：名前を付けておいたセッションが、運ぶ前に閉じていたことがありました。司令塔には、運ぶ前に相手のプロセスが生きているかを確かめさせています
- 同じ役を2つのセッションに割り当てない：同じ名前を2つのセッションに付けかけたことがあります。同じ引き継ぎ書を2つの作業役が同時に書き始めると、片方の書いたものが消えかねません
- Macのスリープ設定を見ておく：自分のMacは、触らずに1分たつとスリープする設定でした。夜のあいだに消えたのが画面だけで済んだのは、スリープ止めが効いていたからです。スリープ止めを動かしているセッションを全部閉じると、すぐに寝ます
- Cursorを閉じると全部止まる：セッションは全部Cursorの中で動いているので、Cursorを閉じたり、アップデートで再起動したりすると全部止まります。夜は、ふたを開けたまま、電源につないだままにしておきます
- 承認ダイアログで止めない：作業役がコマンドの承認を求めてくると、そこで朝まで止まります。パーミッションの設定は先に詰めておきます
「設定したのに毎回聞かれる」問題には僕も散々やられたので、原因と対策をまとめてあります。
「設定したのになぜ？」Claude Codeのパーミッションが効かない理由と、今すぐできる対策
PMの仕事をAIに引き継げた理由
振り返ると、この運用でやったことに、新しいことはほとんどありません。
- 何が正しいかの正本を決める（ここでは引き継ぎ書）
- 任せる範囲と、上に上げる範囲を分ける（決めていいことと、聞くこと）
- 引き継ぎを、口頭ではなく文章にする（キックプロンプトの型）
- 品質の確認を、仕組みにやらせる（夜のあいだの機械のチェック）
全部、受託のPMとして人のチームでやってきたことです。前に書いた記事でも、40人日を10時間にしたのはAIの操作のうまさではなく、PMの仕事そのものだったと書きました。
今回はその続きで、AIのチームのPMを、AIに引き継いだことになります。引き継げたのは、どう引き継ぐか、何を決めて何を聞くか、どう確かめるかが、文章で決まっていたからです。人のチームでも、仕事が属人化しているPMは休めません。AIのチームでも、同じでした。
今夜、1回だけ試してみてください。いつものキックプロンプトの最後に、1行足すだけです。
「終わったら、次のキックプロンプトを書いて止まる」
-
macOSでは、セッション間のメッセージ（
ListAgentsとSendMessage）はClaude Code v2.1.224以降、notify_when_idleは送る側と受ける側の両方でv2.1.236以降、定期実行（CronCreate）はv2.1.72以降で使えます。公式ドキュメント：セッション間のメッセージ、定期実行 ↩ -
/statusの Peer address の欄で確かめられます。uds:/tmp/cc-socks/<プロセス番号>.sockのような形です。 ↩