一人で 6 つのサイトと累計 5,000 万ダウンロードのアプリ事業を並行運用していると、ボトルネックは「作業内容」ではなく「いつ誰が動くか」になります。自律エージェントに任せる作業が増えるほど、タスク同士の衝突・リソースの取り合い・そして外から見たときの不自然な挙動が、品質よりも先に問題化してくるのです。先日 AdMob のサーバーサイド入札パートナーを 11 社申請する単発作業を、定常運用の合間に差し込んだとき、改めて「スケジュール設計こそが並行運用の本体だ」と感じました。
私は 2014 年からの個人開発で累計 5,000万ダウンロードのアプリ事業を運営し、国際芸術賞 17冠のアート活動と並行して、いまは 4 つの技術ブログ（Claude / Gemini / Antigravity / Rork の各 Lab）と 2 つの読み物系ブログを自律エージェントのスケジュールタスクで回しています。1 日あたり 16 本以上の記事生成タスクに加え、AdMob のフロア調整やレポート取得、サイト整合性チェックが毎日走ります。アプリ更新では段階公開でクラッシュフリー率 99.7% 以上・ANR 0.20% 未満を監視していますが、こうした数値監視と同じ規律を、複数サイトの運用スケジュールにも持ち込んでいます。これを破綻させずに回すために組んだ時間割と、その背後にある判断基準を共有します。
まず「ピーク帯」を地図にする
スケジュール設計の出発点は、機能ではなく「避けるべき時間帯」を地図にすることでした。読者のアクセスが集中する時間にエージェントを走らせると、サイトのキャッシュパージや再ビルドが読者体験を直撃します。逆に深夜に全タスクを固めると、同時刻に複数タスクが起動してリソースを奪い合います。
私が避けると決めたピーク帯は、朝 7〜9 時（通勤）、昼 12〜13 時、夕方から夜の 18〜23 時（プライムタイム）です。加えて、既存の自動処理が走る時刻（読み物系ブログの投稿が 2:30、壁紙アプリのデータ更新が 3:30 と 15:30、キャッシュクリアが 11:48 と 23:40）も衝突点として地図に書き込みました。これらを塗りつぶした「空き時間」にだけ、新しいタスクを置いていきます。
4 サイト × 4 種類を 45 分刻みでずらす
実際の時間割は、4 サイト各 4 種類（プレミアム / 実体験レビュー / トラブルシューティング / 通常記事）を、サイトごと・種類ごとに 45 分〜1 時間ずつずらして配置しています。
# 自律タスクのオフピーク分散（JST・抜粋）
02:00 Claude Lab プレミアム
02:45 Gemini Lab プレミアム
04:00 Antigravity プレミアム
04:45 Rork Lab プレミアム
05:30 Claude Lab 実体験レビュー
...
11:00 Claude Lab トラブルシューティング
14:00 Antigravity トラブルシューティング
15:00 Claude Lab 通常記事
17:00 Rork Lab 通常記事
45 分刻みにしているのは、1 記事の生成＋日英 2 言語＋品質ゲート＋ push が、長くても 30 分前後で終わるからです。前のタスクが多少押しても次に食い込まない余白を確保しつつ、空き時間に詰め込めるだけ詰める。この「処理時間 + バッファ」を 1 枠の単位にすると、時間割が一気に組みやすくなります。
実際にこの設計に行き着くまでには失敗もありました。初期は深夜帯にプレミアム記事生成を 4 サイト分まとめて 2:00〜2:30 に固めていたのですが、同時刻に複数タスクがリポジトリ操作とビルドを走らせてディスクを奪い合い、後発のタスクが ENOSPC（容量不足）で落ちる事故が起きました。45 分刻みに散らしてからは、1 タスクが作業ディレクトリを使い終えてから次が起動するため、容量も帯域も奪い合いません。「同時に動かさない」というだけのことが、無人運用では決定的に効きます。
エージェント設計の観点で重要なのは、各タスクを完全に独立させることです。タスク同士が共有状態を持つと、片方の遅延がもう片方を巻き込みます。私は各サイトのリポジトリ操作を別々の作業ディレクトリで完結させ、タスク間で受け渡す状態をゼロにしています。並行運用のスケジュールは、独立性が担保されて初めて「ただ時刻をずらすだけ」で衝突が消えます。
1 サイト 1 日あたりの生成上限を設ける
並行運用で見落としがちなのが、外から見たときの生成ペースです。Google は「大規模コンテンツ生成スパム」を品質ポリシー違反として扱います。複数サイトを自律エージェントで回していると、技術的には 1 日 10 本でも 20 本でも生成できてしまいますが、それは確実にスパム判定のリスクを上げます。
そこで私は 1 サイトあたり 1 日 5 本を絶対上限とし、現在は 4 本/日で運用しています。これはエージェントの能力の制約ではなく、意図的に課した上限です。指標が悪化したサイトは速やかに 3 本/日へ戻すことを推奨します。スケジュールタスクを 1 つ追加・再開するときは、必ず「そのサイトの当日合計本数」を先に数えてから設定する、というルールを自分に課しています。
並行運用の自動化では、「もっと回せる」と「回すべき」は別物です。エージェントのスループットが上がるほど、上限を人間側が明示的に握っておく重要性が増します。これは前のセクションのタスク独立性と並んで、フリート設計の二本柱だと考えています。
単発タスクを定常フリートに割り込ませる
定常運用が時間割で埋まっていると、AdMob 入札パートナーの 11 社申請のような単発作業をどこに差し込むかが問題になります。ここでの設計判断は2つでした。
ひとつは、単発タスクを定常タスクのピーク帯（生成が固まる深夜〜午前）にぶつけないこと。申請作業はブラウザ操作とネットワーク待ちが主体で、記事生成とリソース特性が違うため、生成タスクが空く午後の枠に寄せました。
もうひとつは、単発タスクにも定常タスクと同じ完了条件と検証ゲートを通すこと。入札パートナーの申請でいえば、「有効化できた」で完了にせず「レポートに実インプレッションが立った」を完了条件に置きました。定常の記事生成タスクが push 前に品質ゲート 3 点（記事品質・リダイレクト整合性・フロントマター整合性）を必ず通すのと同じ思想です。フリートに割り込む単発作業ほど、定常と同じ検証規律を適用しないと、後から「あの作業だけ検証が抜けていた」という穴になります。
フリートの健全性を毎朝 1 分で確認する
16 本以上のタスクを無人で走らせる以上、「全部成功したか」を毎朝 1 分で把握できる仕組みがないと、静かな失敗が積み上がります。私は各タスクが完了時に更新ログ（日付ごとのテキスト）へ 1 行追記する設計にしていて、朝はそのログの行数と各サイトの日英記事件数の一致だけを確認します。
確認するのは 2 点だけです。ひとつは 各サイトの日本語版と英語版の記事数が一致しているか。片方だけ生成されると言語切替で 404 が出るため、件数の差は無人運用の失敗を最も早く検知できる指標になります。もうひとつは 当日の生成本数が上限内に収まっているか。タスクの重複起動や再実行で上限を超えていないかを、ここで人間が握り直します。
監視は「全メトリクスを眺める」より「壊れたら確実に気づく 1〜2 個の指標」に絞るほうが、並行運用では現実的に機能します。毎朝の確認が 1 分で終わる設計にしておくこと自体が、フリートを長く回し続けるための条件だと考えています。
エラーで止めない — 自律リカバリを前提に組む
最後に、並行運用で最も効いた設計が「エラーで人間に投げ返さない」ことです。16 本以上が毎日走ると、ネットワークの一時失敗や git の rebase 衝突は日常的に起きます。これを毎回人間が拾っていたら、自律運用の意味がありません。
私は各タスクに、失敗時の自動リカバリ手順を最初から組み込んでいます。push が失敗したら git pull --rebase 後に再 push、それでも駄目ならリポジトリを作り直して再 clone から push。復旧不可能なケースだけログに記録して終了し、人間への通知は最小限にしています。**「迷ったら最善と思われる選択を自己判断で実行する」**を各タスクの行動原則として明文化しておくと、エージェントが途中で確認待ちになって時間割全体が崩れる事故が防げます。
並行運用のスケジュール設計は、突き詰めると「人間が介在しなくても回り続ける状態」をどう作るかに尽きます。タスクを独立させ、生成上限を握り、単発作業にも同じ検証を通し、エラーでは止めない。この 4 つを満たすと、6 サイトの運用は驚くほど静かに回り続けます。
タスクを 1 つ追加する前に、私は必ず次の順で点検しています。
- そのサイトの当日合計が上限（5 本）を超えないか数える
- 起動時刻が既存タスク・ピーク帯・キャッシュ処理と衝突しないか時間割で確認する
- そのタスクが他タスクと状態を共有していないか（独立した作業ディレクトリか）を確認する
- 完了条件が実データで判定できる形になっているか確認する
- 失敗時の自動リカバリ手順が組み込まれているか確認する
この 5 点を満たさないタスクはスケジュールに載せません。
まずは自分の運用タスクを 1 枚の時間割に書き出し、ピーク帯を塗りつぶしてみてください。空いている時間と衝突点が可視化された瞬間に、何を自律エージェントに預けられるかがはっきり見えてきます。