7つのAIエージェントが私たちの夜を回す：コーディング以外で働くスケジュールエージェントと、そのプロンプト

9月23日、Robというユーザーが私たちの公開バックログにこう書きました：「would love to get examples of how you guys are doing stuff beyond coding」（コーディング以外で何をしているのか、具体例を知りたい）。もっともな質問です。このサイトはどこを見てもコーディングエージェントの話ですが、私たちが毎晩実際に動かしているものは、ほとんどがコーディングではありません。

8月28日から、7つのエージェントが20:00にMac mini上で起動しています。その日のコミット、Search Console、管理画面のダッシュボード、バックログ、ユーザーから届いたフィードバック、前夜のレポートを読みます。バグを直し、Webサイトを修正し、3日ごとにブログ記事を書いて翻訳し、3つのSNSに投稿し、製品のナレッジベースを更新します。そして22:00に7つ目のエージェントが、他の6つが残したものを読み、25行のメールを送ります。誰も見ていません。創業者は翌朝、そのメールをスマートフォンで読みます。

この記事はRobへの答えです。何が動いているのか、どう配線されているのか、エージェントが一度も会話せずにどう仕事を受け渡すのか、どのモデルがどの仕事をなぜ担うのか、プロンプトが痛い目を見て学んだ4つのルール、そしてコピーできるブロックにまとめたプロンプトそのもの。以下の数字はすべてリポジトリから取っています：レポートは毎晩そこにコミットされています。

33晩で生まれたもの

リポジトリのレポートフォルダーには、8月28日から9月30日まで、日付の付いたディレクトリが33個あります。それを読むと、こうなります：

• 報告担当が送った朝のメール31通。
• 修正担当が直したバグ51件。どれもレポートの行にコミットへのリンクが付いています。いくつかは公開バックログでユーザーから報告されたもので、次のリリースで返信を受け取りました。
• 9月10日からSEOチームが書いたブログ記事7本。3日に1本、まず英語とフランス語で書き、同じ晩のうちにさらに18言語へ。
• 29日分のSNSの記録：毎晩3つのネットワークと5つのFacebookグループ、さらにユーザーがAgentsRoomをシェアしてくれた投稿すべてへのお礼コメント。
• 約100枚のファクトシートからなる製品ナレッジベース。その日のコミットに合わせて更新され、アプリ内アシスタントが読み、サイトが llms-full.txt として配信しています。

20:00以降、どれも人間を必要としませんでした。一部は8:00に人間を必要とし、それこそが最後のエージェントの存在理由です。

顔ぶれ：20:00に動くのは誰か

どのエージェントもAgentsRoomのスケジュールタスクです：プロンプト、エージェント（ロール、CLI、モデル）、マシン、時刻。7つともClaude Codeで動きます。そのうち2つは単独のエージェントではなく2ステップのチームで、その理由は後で説明します。

最後の列の .md ファイルはすべて reports/night/<date>/ にあり、コミットされ、プッシュされています。このフォルダーが連携の仕組みのすべてで、次のセクションではその理由を説明します。

配線のしかた

7つはどれも同じ形のスケジュールタスクです：

• 毎日20:00に発火（報告担当は22:00）。cron式はなく、頻度はエディターで選びます。
• 1台のマシンに固定。 プロジェクトは複数のコンピューターで開かれていて、制限しない限り、トリガーはそのプロジェクトを持つすべてのマシンで発火します。私たちのトリガーはMac miniに限定しているので、20:05に開いたノートPCが2人目のCEOを起動することはありません。
• マシンを起こす。 Mac miniはスリープします。タスクには「マシンを起こす」オプションがあり、実行の数秒前に、OS標準のツール（macOSでは pmset、Windowsではスリープ解除付きのタスクスケジューラ、Linuxでは rtcwake）でウェイクを予約します。これがないと、スリープ中のマシンはただ実行を逃します。
• 取りこぼし分の実行のオン・オフはタスクごと。 20:00にマシンの電源が切れていた場合、この機能がオンのタスクは次の起動時に発火します。CEO、PM、報告担当はオンです。SEO、修正担当、SNS、ドキュメントのタスクはオフです：翌朝11:00に始まる実行は、同じチェックアウトでその日の作業とぶつかってしまうからです。
• 権限モードはタスクに設定し、プロバイダーには設定しません。無人の実行が午前3時に承認待ちで止まるわけにはいかないので、タスクは承認なしで動きます。一方、創業者が同じCLIで手動で操作するエージェントは、今まで通り先に確認を求めます。
• コンソールは60分アイドルで閉じる。 終わったエージェントが、誰かが閉じるまでサイドバーに居座ることはありません。
• プロンプトが最初のメッセージ。 各プロンプトの本文はプロンプトライブラリに保存されていて、トリガーのプロンプト欄と同じテキストなので、片方を編集すれば両方を編集したことになります。プロンプトはフランス語です。創業者がレポートをフランス語で読むからです。それ以外、コミットメッセージからナレッジベースまで、すべて英語です。

7つすべてが共有する部品がもう1つあります：「夜間エージェント、共通ルール」という名前のスキルです。どのプロンプトも「このスキルを読み込んで適用すること」で始まり、スキルには全員に当てはまることがすべて入っています：誰が何を担当するか、「1晩に1実行」のガード、gitの権限、レポートの形式、バックログのルール、そして報告担当向けのメール形式。ルールが変わるときは、1か所だけが変わります。

会話せずに仕事を受け渡す方法

7つのエージェントは互いにメッセージを送りません。送ることはできます。AgentsRoomにはエージェント間メッセージングがあります。でもメッセージは翌朝には見えず、grepもできません。すべては、夜を越えて残る3つのものを通ります：

リポジトリ。 各エージェントは reports/night/<date>/<agent>.md を書きます。実行の最初の1分で開き、仕事を1つ終えるたびに書き直し、コミットしてプッシュします。レポートには4つの固定セクションがあります：「ひとことで」（箇条書き、やったこと1つにつき1項目）、「決めること」（プロンプトが人間に委ねているものだけ）、「確認すること」（開くべきローカルURLや画面）、「詳細」（必要なだけ長く）。最後は実行マーカーで終わります：エージェントが最後に見たコミットです。

バックログ。 別のエージェント向けの仕事を見つけたエージェントは、その仕事をしません。タグ付きのチケットを開きます：修正担当が引き受ける、検証済みの小さなバグには ceo-fix。狙う検索クエリ付きのコンテンツ作業には ceo-seo。人間を必要とするもの（データベース、課金、認証、暗号化、価格、インデックス済みのURL、デフォルトの挙動）には ceo-decision。ドキュメント担当がコミットを読んでいて、サイトにページのない機能を見つけたら、ceo-seo のチケットを出し、次の晩にSEOが引き受けます。CEOがエラーログを読んでいて、原因がコード上にあるバグを見つけたら ceo-fix、次の晩に修正担当が引き受けます。

前日のレポート。 どんな作業を始める前にも、各エージェントは前夜の自分のレポートと、日中にクローズされたチケットの一覧を読みます。昨日指摘したことは、日中に直されていることがよくあります。すでに扱われた話題は再び持ち出さず、すでに開いているチケットは作り直しません。

ループを閉じるのは人間です。報告担当のメールは1行で終わります：プロダクトマネージャーに答えるには、rapport.md の末尾に「## 決定」セクションを追加し（P1 OK / P2 不可：理由 / P3 あとで）、コミットして、プッシュする。PMは翌晩プッシュされたバージョンを読み、承認されたことを実行します：チケットを作り、重複をマージし、残りは理由を添えて保留にします。3晩答えのない判断は、それ自体がひとつの判断です：提案はメールから外れ、チケットとして残ります。

どのモデルがどの仕事を、なぜ担うのか

上の表には2つのモデルが出てきます。これは現時点の構成であってベンチマークではなく、今後も変わります。ただし、分け方は意図的です。

判断が仕事の中心ならFable。 CEOは、オラクルへの低評価が本当のエラーなのか、好みの問題なのかを判断します。修正担当は、バグ報告が本当のバグなのか、特定のマシン固有の設定なのかを判断し、そのうえでコードの中に原因を見つけます。SEOのステップ1は、今日のコミットでサイトのどの文が誤りになったか、どの記事を書くか、どのページには手を付けないかを決めます。SNSのステップ1はその晩のテーマを選び、生成された文章を3行で見抜く読者に向けて書きます。これらのプロンプトは長く（SEOのものは約4,000語）、短い例外リスト付きの「自分で決める、聞かない」というルールに満ちています。最も強いモデルがそのコストに見合う働きをするのは、ここです。

量が仕事の中心なら1Mコンテキストの Opus。 サブエージェント（1つにつき3ロケール）で記事を18言語に翻訳し、その後フランス語の参照版と突き合わせてマージを確認するのは、大量に読んで書く作業で、同じルールを18回適用します。ドキュメント担当は、1日分の差分を約100枚のファクトシートと突き合わせて読みます。PMは8 MBある離脱時の会話のエクスポートを読みます。報告担当は5つのレポートを読んで写すだけで、考えません。そこでは判断力よりも、大きなコンテキストとトークン単価の低さのほうが重要です。

そのため7つのうち2つは、2ステップのエージェントチームで、各ステップがそれぞれ自分のモデルを持つエージェントです。Fable上のステップ1は、共有レポートに「ハンドオフ」セクションを書いて終わります：翻訳担当が納品すべきファイルとキーの正確な一覧、または投稿担当が公開すべき投稿の正確な中身です。Opus上のステップ2はそのセクションを読み、そこに並んだことだけを行います。チームのグラフは直線的で1サイクル、レポートはステップ2が消すまで「実行中」の行を保ちます。外から見ると、22:00にまだ「実行中」と書かれたレポートは、切れた実行か、2つのステップの間にいるチームのどちらかを意味し、報告担当はどちらなのかを書きます。

プロンプトが学ばなければならなかった4つのルール

最初のプロンプトは職務記述書でした。今のプロンプトはほとんどがルールで、どのルールにも日付があります。どれも、うまくいかなかった夜のあとに書かれたものだからです。

1. 前日のレポートから読む実行マーカー。 SEOエージェントの最初のバージョンは「直近24時間のコミット」を読んでいました。問題は2つ：20:00の実行と翌日20:10の実行は同じ24時間を見ていないこと、そしてエージェントが動かなかった晩の分は、誰も見ない1日分のコミットになってしまうことです。今では各レポートが 最後に見たコミット: <sha> で終わり、次の実行は時計が何を示していようと、そのコミットから始まります。マーカーがなければ（初日の夜、レポートの欠落）2日前までさかのぼり、レポートにそう書きます。

2. 履歴はディスクにある。だから何かを報告する前にgrepする。 最初の2週間でいちばん多く返ってきた不満は「それはもう聞いた、昨日直した」でした。対策は、コマンドを含んだルールです：話題を指摘する前、作業を始める前に、grep -ril "<話題>" reports/night/ と git log --since="30 days ago" -- <ファイル> を実行する。ヒットしたら、まずそのレポートを読む。扱い済みの話題にもう一度触れてよいのは3つの場合、3つだけです：修正が効いておらず、今それを検証した場合。修正が部分的で、残っているものを名指しする場合。話題の性質が変わった場合。これに2つの帰結が付いてきました。1晩に1実行：今夜のレポートが存在し、「ひとことで」を含み、もう「実行中」と書かれていなければ、エージェントは止まる。そして3晩答えのない提案はレポートから外れ、チケットは残る。

3. レポートは作業を始める前に開く。 以前は、21:30に切れた実行は何も残しませんでした。今では、スキルを読み込んだあとエージェントが最初にするのは、mkdir -p reports/night/$(date +%F) を実行し、4つのセクション見出しと 実行中、20:01 開始 という行を持つレポートの骨組みを書くことです。作業を1つ終えるたびにファイル全体を書き直します。切れた実行は、報告担当が写せる途中までのレポートを残します。「動かなかった」エージェントよりずっとましです。

4. 進めながらコミットし、最後にまとめない。 9月9日に計測しました：2つのエージェントが同じ分に止められました。作業ごとにコミットしていた方は何も失いませんでした。もう一方は、変更済みでプッシュされておらず誰のものかも分からないファイルを45個残し、創業者が翌朝それを手作業で拾い上げました。そのエージェントのレポートは存在しませんでした。それ以来ルールは、終えた作業ごとに1コミット、ファイルは1つずつ名指し、レポート用に最後のコミット、そして実行中に少なくとも1回のプッシュ、です。コミットは日付付きの痕跡でもあり、ルール2がgrepするのはまさにそれです。

5つ目のルールは記憶ではなく勇気の話で、成果をいちばん大きく変えたのはこれです。SEOのプロンプトにはこうあります：「あなたは所見を報告する監査人ではない。夜のあいだ、サイトはあなたのものだ。確認待ちの手がかりを6つ並べて終わる実行は、失敗した実行だ。」続いて、エージェントが行動する代わりに尋ねなければならない6つの場合、6つだけを挙げます：URLの削除や名前変更、検索順位の付いているページのタイトル変更、法的な文章、価格やクォータ、プライバシーや暗号化についての主張、5ページを超える変更。それ以外はすべて実行し、気に入らないものは翌朝創業者が取り除きます。修正担当にも、3つの場合を例外とする同じルールがあります。このルールの前、レポートは提案の一覧でした。このルールの後、それはコミットの一覧です。

プロンプト

原文はフランス語で、長いものです。以下は移植できる部分で、プロジェクト固有のパスや名前は取り除いてあります。3つのブロック：全エージェントが読み込む共通ルール、報告担当、そして2つの「自分で決める、聞かない」セクションです。

ブロック1：共通ルール（7つすべてがスキルとして読み込む）

# 夜間エージェント：共通ルール
自分のプロンプトと食い違う場合は、こちらが優先する。

## 1晩に1実行
DAY=$(date +%F); F=reports/night/$DAY/<自分>.md
F が存在し、「ひとことで」を含み、もう「実行中」を含まない場合：
止まる。何も書かず、何も送らず、1行のメッセージで終える。
まだ「実行中」とある場合：それは数分前に切れた自分自身の実行だ。
止まったところから再開し、最初からやり直さない。

## やってよいこと
- Git：add <名指ししたファイル>、commit、自分自身の作業の push を、進めながら行う。
  禁止：add -A、commit -a、push --force、stash、reset、checkout、clean、新しいブランチ。
- ビルド：typecheck、lint、チェック用スクリプト、確認のためのローカルビルド。
  禁止：デプロイや公開を行うスクリプトすべて。
- バックログ：チケットの作成、チケットへの追記、自分が直したチケットのクローズ。
  禁止：ユーザーへの返信（メールが送られる）、チケットの削除、説明文の上書き。
- でっち上げた数字は決して書かない。ソースが使えなければ、そう書いて次へ進む。
- git に書き込む前に必ず：git status --short。ツリーは他のエージェントと共有している。

## 追いつき、「すでに」行われたことを知る
git fetch && git status -sb
遅れていてクリーン：git pull --ff-only。遅れていて未コミットの変更あり：pull せず、レポートの冒頭にそう書く。
自分の実行マーカー：前日のレポート末尾にある「最後に見たコミット: <sha>」の行。
マーカーがない場合：--since="2 days ago"、そしてそう書く。
分析の前に必ず読むものが3つ：
1. git log --no-merges --format='%h %s' <sha>..HEAD と git diff --stat <sha>..HEAD
2. 昨日以降にクローズされたチケット、そして人間が保留にしたチケット
3. 前日の自分のレポート：「ひとことで」と「決めること」

## レポートフォルダーこそが自分の履歴
指摘を上げる前、作業を始める前に：
grep -ril "<話題>" reports/night/ | sort | tail -5
git log --since="30 days ago" --oneline -- <ファイル>
ヒットしたら：何かを決める前にそのレポートを読む。
同じ話題に2晩続けて取り組んだら：2晩目は無駄だ。
自分が手を入れたページや文章は、3週間は再び触らない。
ただし、誤りになったことを直す場合は除く。

## 同じことを二度上げない
すでに対処された指摘が翌日また出てくるのは過失だ。
許されるのは3つの場合だけ：
1. 修正が効いておらず、今それを検証した：「<date> に <commit> で修正済み、まだ壊れている：<証拠>」
2. 修正が部分的：残っているものを正確に名指しする
3. 話題の性質が変わった：新しい原因、新しい測定値、新しい範囲
総数を数え直さない。報告するのは増減であって、総数ではない。

## 答えのない提案は3晩で消える
1晩目から3晩目：その行にカウンターと初出日を付ける（「2晩目、9/7に初出」）。
4晩目から：「決めること」から外す。チケットは残り、「詳細」に書くのはせいぜい1行。
判断が自分の範囲内なら、3晩目に決めて、そう書く。

## 進めながらコミットしてプッシュする
最初の作業が終わって検証できたら、すぐに最初のコミット。その後は作業ごとに1つ。
最後のコミットは自分のレポート用。実行中に少なくとも1回、最後に1回プッシュする。
プッシュが拒否された（リモートが進んだ）：git pull --ff-only、それから push。まだ拒否される：force しない、
rebase しない、レポートに書く。

## レポート：最初に開き、最後にだけ書くことはしない
reports/night/<YYYY-MM-DD>/<自分>.md を作業の「前」に作り、中身は：
  # <Agent> - <date>
  _実行中 - <HH:MM> 開始_   （最後に削除）
  ## ひとことで      （3〜5行、または箇条書き：やったこと1つにつき1項目）
  ## 決めること      （プロンプトが人間に委ねているものだけ。なければ「なし」）
  ## 確認すること    （- [ ] 何を：どこで：何が見えるべきか。なければ「なし」）
  ## 詳細            （必要なだけ長く：証拠、ファイル、コマンド）
  ## 実行マーカー
  最後に見たコミット: <最後のコミット後の git rev-parse HEAD>
作業を1つ終えるたびにファイル全体を書き直す。
読み手はスマートフォンで2分だけ読む：短い文で、最初のセクションにはファイルパスも、
SHA も、関数名も入れない。数字は判断を変える場合だけ。

ブロック2：報告担当（22:00）

あなたは報告担当だ。他のエージェントの2時間後に動く。
仕事は1つだけ：彼らが残したものを読み、創業者がスマートフォンで1分で読めて、
他に何も開かずに理解できるメールを「1通」送る。
何も分析しない、何も直さない、何も提案しない。集めて、分かりやすくする。

報告する晩は、時計ではなくディスクから読む：
DAY=$(ls -1 reports/night | sort | tail -1)

1. git fetch; ツリーがクリーンなら git pull --ff-only：レポートはコミットされている。
2. ls reports/night/$DAY：5つのファイル（ceo, seo, pm, fixer, social）を待つ。
   足りなければ：9分 sleep して数え直す、最大6回。その後は欠けているのが誰かを明記して、それでも送る。
3. まだ「実行中」とあるレポートは、切れた実行であって、欠席ではない。
   中身を写し、「うまくいかなかったこと」にそのエージェントが切れたと書く。
4. 各レポートから取るのは3つのセクションだけ：「ひとことで」「決めること」「確認すること」。
   「詳細」は決して引用しない。
5. 修正担当の修正済みバグは、" > " で区切った3部構成の箇条書き：
   ユーザーが困っていたこと > 原因を1文で > コミットのURL。
   リンクも含めて一字一句そのまま「修正したバグ」に写す。
6. git status -sb と git log --oneline --since="4 hours ago"：コミットのない作業を主張するレポート、
   誰も名乗らない変更ファイル、未プッシュのコミットがあれば：メールの1行目に書く。

reports/night/$DAY/rapport.md を書く。本文は最大25行
（セクション見出しと「修正したバグ」の行は数えない）。
6つのルールを1行ずつ適用する：
1. 1項目 = 単独で成り立つ完結した1文。「昨日報告したとおり」は禁止。
2. 1つの話題は「1つ」のセクションにだけ出す。
3. 専門用語ゼロ：パスも、SHA も、キー名も、内部の略語も書かない。
   例外は1つ：コミットの完全な GitHub URL。「修正したバグ」の各行に必須。
4. 数字は判断を変える場合だけ。それも増減であって、総数ではない。
5. 1項目は最大2行。詳細はエージェントのレポートにある。
6. 悪いニュースを良いニュースより先に。1行目で何かが壊れているかどうかを言う。

セクションの順番：決めること / 確認すること / 修正したバグ / やったこと /
SNS（最大3行、リンク込み） / CLIとモデル（1行） /
うまくいかなかったこと。空のセクションは一語で：「なし」。
決して削らない：「決めること」、リンク付きの「修正したバグ」、投稿のリンク、SEOの記事。
送信する。HTTPコードを確認する。末尾に「送信先 ... - HTTP <code>」を追記する。
rapport.md をコミットしてプッシュする。二度送らない：今日の rapport.md にすでに
「送信先」の行があれば、止まる。

ブロック3：「自分で決める、聞かない」セクション

SEOエージェント、プロンプトのセクション0：

# 0. 自分で決める。聞かない
これはこのプロンプトで最も重要なルールで、慎重になろうとする反射よりも優先する。
あなたは所見を報告する監査人ではない。夜のあいだ、サイトはあなたのものだ。
「手がかりを6つ挙げました、確認をお願いします」で終わる実行は、失敗した実行だ。
迷ったら創業者の立場に立ち、4つの基準で決める：
- 製品が実際に何をしているか。リポジトリと公開済みのバージョンで確かめ、既存のコピーでは決して判断しない。
- サイトがすでに語っていること：その切り口、トーン、約束。延長はしても、作り直しはしない。
- Search Console が示すこと：どのページが生きているか、どの検索意図が実際に存在するか。
- 読み手：Googleで検索する開発者と、ツールを推薦するAIアシスタント。
  彼らにとって重要なのは：検証でき、日付を特定できる主張。1つの明確な質問に答えるページ。
  ページと整合した最新の llms.txt。誠実な比較。
創業者は翌朝あなたのレポートを読み、気に入らないものは取り除けと言ってくる。
余計な修正1つのコストは5分。何も生まなかった夜は永遠に失われる。

意見を求めてよいのは、次の6つの場合だけ：
1. 既存URLの削除または名前変更。
2. 検索順位の付いているページのタイトルやメタディスクリプションの変更（それが誤りでない場合）。
3. 法的な文章（利用規約、プライバシー、ライセンス）。
4. 価格、商用のクォータ、オファー。
5. プライバシー、暗号化、データがどこで処理されるかについての主張。
6. 一度に5ページを超えて手を入れる変更。
この6つの場合：判断用のタグを付けたチケット、「決めること」に1行、そして次へ進む。
それ以外はすべて今夜やる。「決めること」に他のものが入っていたら、
それは自分が下すべき判断を人に回したということだ。

修正担当、プロンプトのセクション0：

# 0. 直す。分類しない
ユーザーが報告したバグは約束だ。誰かが時間を割いて書き、待っていて、
今夜ほかに対応する者はいない。「5件のバグを分析、1件修正、
4件を記録」を返す実行は、失敗した実行だ。目標は空のキュー：ユーザーのバグから、
古いものから順に、次に残りを、なくなるまで。
修正で迷ったら、3つの基準で決める：
- 今日コードが何をしているか。推測ではなく、読んで確かめる。
- 報告を書いたとき、ユーザーが明らかに期待していたこと。
- 最小のリスク：原因を解決する最も狭い修正。最もエレガントな修正ではない。
議論の余地がある修正を取り消すのは5分。あと1か月放置されたバグはユーザーを1人失う。

報告されたバグを修正せずに残してよいのは、次の3つの場合だけで、チケットの中で証明する：
1. 本当に調査しても原因が見つからなかった：「再現できない」だけでなく、
   何を除外したかを書く。
2. バグではなく判断事項：データベース、課金、認証、暗号化、プライバシー、
   インデックス済みのURL、デフォルトの挙動。判断用のチケットを、自分の推奨を添えて。
3. ゲートが修正を拒否し、それを直せない。
「大きい」「複数のファイルに触る」「聞いたほうがいい」は理由にならない。
1バグ = 1コミット。それからチケットを完了に移し、ユーザーが報告したものなら、
次のリリースで届く2文のメッセージを用意する。「保留」には決して入れない：その列は
人間のものだ。
修正したバグごとのレポートの行。朝のメールにそのまま写される：
- <ユーザーが困っていたこと> > <原因、簡単な1文で> > <コミットのURL>

残りの4つのプロンプト（CEO、PM、ドキュメント担当、SEOのステップ2）も同じ骨組みです：スキルを読み込み、書いてよいファイルを名指しし、読むものを順番に並べ、何をチケットに、何をレポートに入れるかを示し、実行マーカーで終える。

うまくいかなかったこと、今もうまくいかないこと

いくつかの晩は、メールの「うまくいかなかったこと」セクションに載っています。あなたもぶつかることになるので、挙げておく価値があります。

• 5つのエージェントが同じ分に同じブランチへプッシュ。 リモートが進んだためにプッシュが拒否されます。ルールは git pull --ff-only してからプッシュ、force は決してしない。2回失敗したらレポートにそう書き、朝に人間がプッシュします。週に1回ほど起きます。
• 別のエージェントがステージしたファイルを巻き込んだコミット。 9月29日、SEOの最初のコミットに、ドキュメント担当が共有チェックアウトでステージしていた削除が入り込みました。何も失われませんでした（削除は意図したものでした）が、そのコミットは別のエージェントのものとして記録されています。それ以来、すべてのコミットは明示的なパス指定を使い、「ファイルは1つずつ名指し」というルールは好みの問題ではなくなりました。
• 20:10にディスクの空き容量がゼロバイトに、2晩連続。 エージェントとは無関係で、20:25にひとりでに回復し、ファイルは失われませんでした。それでもレポートには書かれます。ディスクが満杯の夜は、エージェントが何もしなかった夜とまったく同じに見えるからです。
• 来ないレポートを54分待つ報告担当。 9分を6回が上限です。22:00に2つのステップの間にいるチームは切れた実行のように見え、メールには「終わっていなかった」と書かれます。正直ですが、読むと少しどきっとします。
• 同じ指摘が繰り返された最初の数週間。 上のルール2は、創業者が「それは3日前に聞いた」と4回目に書くまで存在しませんでした。

自分で構築する方法

7つのエージェントは要りません。必要なのは、あなたが読むレポートを書くエージェント1つです。報告担当が役に立つのは、エージェントが3つ目になってからです。AgentsRoomでは：

1. プロンプトライブラリにプロンプトを書きます。上のブロック1をスキルとして使い、このエージェントが何を担当し、どのファイルを書いてよいかを示す短いプロンプトから始めます。
2. プロジェクトにスケジュールタスクを作ります：毎日好きな時刻に、エージェントのロール、CLI、モデル、プロンプト、そして詳細設定ブロックで無人実行用の権限モード。実行するマシンに固定し、そのマシンがスリープするなら「マシンを起こす」をオンにします。
3. リポジトリに reports/night/ フォルダーを作ってコミットします。これが連携レイヤーのすべてです。
4. 1つ目のエージェントが他の誰か向けのチケットを作り始めた日に、2つ目のエージェントを追加します：ceo-fix タグは、次の晩に修正担当がそれを読んで初めて意味を持ちます。
5. 1つの仕事が判断と量に分かれるなら、2つのモデルを使う2ステップのチームにし、ステップ2が読むハンドオフのセクションをステップ1に書かせます。

スケジュールタスクのページで各項目を説明しています。コーディングエージェントを夜勤に回す記事は、この顔ぶれに先立つ考え方をまとめたものです。エージェントが1台のマシンを共有するなら、まず10個のエージェントが同じコマンドを実行すると何が起きるかを読んでください：それはここで、夜に起きたことで、解決策は小さな共有ロックです。

Robさん、これがコーディング以外で私たちがやっていることです。プロンプトこそが製品です。

よくある質問

このようにエージェントをスケジュール実行するには、AgentsRoomが必要ですか？

いいえ。cronの1行とclaude -pがあれば、どのマシンでも20:00にClaude Codeのセッションを起動できます。そのあと自分で書くことになるのは残りの部分です：スリープ中のコンピューターを起こす、マシンが逃した実行を取り戻す、プロジェクトが2台のコンピューターで開かれているときに1晩1回の実行に抑える、あるエージェントのレポートを別のモデルで動く2つ目のエージェントに渡す、そして実行が質問で止まっていることをスマートフォンで確認する。AgentsRoomのスケジュールタスクはこれらの部品を備えていて、この記事の7つのエージェントはそのすべてを使っています。プロンプトとルールは、何がセッションを起動するかにかかわらず、そのまま移植できます。

7つのエージェントを1晩動かすと、いくらかかりますか？

AgentsRoomで起動する他のエージェントと同じく、Claudeのサブスクリプション上のClaude Codeセッションとして動くので、トークン単位の請求はなく、1晩あたりのコストも公開していません。コストに上限をかけているのは「1晩に1実行」のガードです：2回発火したトリガーや、途中で切れて再起動した実行が、同じ仕事を繰り返すことはありません。各エージェントが最初にするのは、今夜のレポートがすでに存在し、閉じられているかを確認することだからです。

誰も見ていない間にエージェントにコミットとプッシュをさせて、安全なのですか？

安全なのは、何を望むよう言われているかではなく、何を禁じられているかのおかげです。共通ルールは git add -A、commit -a、強制プッシュ、stash、reset、checkout、clean、ブランチの作成、そしてデプロイを行うあらゆるスクリプトを禁止しています。すべてのコミットはファイルを1つずつ名指しし、書き込みの前には必ず git status でツリーを確認し、リモートが進んでいたために拒否されたプッシュは fast-forward の pull で解決するか、人間に任せます。朝のレビューとはその晩のコミット一覧のことで、何か問題があっても5分の revert で済みます。

なぜエージェントはダッシュボードではなく、リポジトリにMarkdownのレポートを書くのですか？

レポートが記憶でもあるからです。各エージェントはまず前夜の自分のレポートを読み、そこにある実行マーカー（最後に見たコミット）を見つけ、何かを報告する前にレポートフォルダー全体を grep します。だから先週扱った話題がまた持ち上がることはありません。ダッシュボードなら同じ数字を見せても、何も覚えていません。レポートをコミットすれば日付も付き、次の晩は前の晩が何に手を入れたかを正確に知ることができます。

7つのうち2つが、異なる2つのモデルで動く2ステップのチームなのはなぜですか？

仕事の前半と後半が、同じ種類の仕事ではないからです。Search Consoleを読み、サイト上で何が誤りになったかを判断し、記事を英語とフランス語で書くSEOのステップには判断力が必要で、Fableで動きます。その記事を他の18言語に翻訳し、i18nのゲートとビルドを通すのは量の仕事で、1Mコンテキストの Opus で動きます。最初のステップは共有レポートに明示的なハンドオフのセクションを書き、2番目のステップはそのセクションに並んだことだけを行います。SNSチームも同じ分け方です：執筆とビジュアルはFable、Chromeでの投稿とお礼はOpus。

実行が途中で切れたらどうなりますか？

レポートは実行の最初の1分から存在し、「実行中」と書かれた行を持ち、終わった仕事はその場でコミットされます。だから21:40に切れた実行は、途中までのレポートとそのコミットを残し、追跡されていないファイルは残しません。報告担当は途中までのレポートを写し、そのエージェントが切れたことを書きます。これは9月9日に痛い目を見て学びました：2つのエージェントが同じ分に止まり、進めながらコミットしていた方は何も失わず、もう一方は誰のものか分からない変更ファイルを45個残しました。