AIの予約タスクを約100本回して、週の利用上限を使い切った記録（実測）
僕は個人のサイト運営や情報収集を、AI（Claude）の「予約タスク」でかなり自動化しています。決まった時刻に、決まった手順書を読んで作業する仕組みです。2026年10月19日に一覧を取ったときで、登録は約100件ありました。
先に結論です。2026年9月に、週の利用上限に当たって、予約タスクが24.5時間まるごと止まりました。原因は作業量ではなく、使っていたモデルでした。予約タスクには、モデルを指定する欄がありません。発火するたびに、アプリが覚えている既定のモデル（対話で最後に選んだモデル）を引き継ぎます。10月17日には、その日の予約タスク104回が、すべて上位モデルで動いていました。
1. よく読まれている解説と、足りなかったもの
書く前に、「Claude Code 利用上限 対策」で検索して上位の解説を3本開きました（2026年11月1日）。どれも、週の上限はすべてのモデルで共有の1つの枠であること、残りは使用量の画面で確かめられること、作業に合わせてモデルを使い分けると長持ちすることを説明していました。冒頭に結論を置き、プランごとの違いを表にまとめる構成も共通しています。
一方で、3本とも自分で測った数字はありませんでした。公式の説明やコミュニティの声をまとめた内容です。そして、「人が見ていない予約タスクが、どのモデルで動いているか」に触れた記事はありませんでした。僕が上限を使い切った原因は、まさにそこでした。
2. 24.5時間、すべて止まった
止まったのは、9月26日11時04分から翌27日11時36分までの約24.5時間です（自分の作業記録より）。この間、30分おきの見張りも、毎時のチェックも、毎朝のレポートも、予約タスクは1本も動きませんでした。締切のある作業もまたいでしまいました。
その少し後、9月30日に予約タスクの実行記録を開いて、どのモデルで動いたかを見ました。
| 予約タスク | 頻度 | 実際のモデル |
|---|---|---|
| 止まっていないかの見張り | 30分おき（1日48回） | 上位モデル（長文脈版） |
| 抽選・先着の確認 | 毎時（1日24回） | 上位モデル（長文脈版） |
どちらも「変わったことが無いか見て、無ければ終わる」だけの定型の作業です。それが、いちばん重い枠で1日に72回動いていました。
3. 週の上限は3日で63%から99%に
止まった後も、すぐには直せませんでした。使用量の画面で週の枠（全モデル共通）を毎日見ていた数字が、こちらです。
| 確認した日 | 週の枠の消費 | メモ |
|---|---|---|
| 10月2日 | 63% | リセットまで約2日 |
| 10月3日 | 89% | 1日で26ポイント増 |
| 10月4日 | 99% | リセットの約10時間前 |
リセット直前で間に合いましたが、9月に止まったときと同じ水位です。この週も、予約タスクは上位モデルのままでした（10月4日に実行記録で確認）。
4. 日ごとのモデル内訳で、仕組みが見えた
原因をはっきりさせたのは、10月19日に取った集計です。アプリが手元に残しているセッションの記録から、予約タスクの回だけを抜き出し、日ごとにどのモデルで動いたかを数えました。
| 日付 | 内訳 | 備考 |
|---|---|---|
| 10月12日〜15日 | すべて標準モデル | — |
| 10月16日 | 標準43・上位27 | 2種類が混在 |
| 10月17日 | 上位104（すべて） | 標準モデルは0回 |
| 10月18日 | 上位58→標準41 | 対話側を切り替えた時刻で入れ替わった |
| 10月19日 | すべて標準モデル | — |
10月18日に、対話のほうのモデルを標準に戻した時刻を境に、予約タスクの回もそろって入れ替わりました。予約タスクは独立して設定されているのではなく、人が対話で最後に選んだモデルについてくるということです。設計の相談で一時的に上位モデルを選び、そのまま1日置いておくと、裏の予約タスクが全部それで動きます。
ただし、例外も1回ありました。10月2日に対話で標準モデルを選んだ直後に発火した予約タスクは、まだ上位モデルのままでした。このときはなぜ切り替わらなかったのか、原因を特定できていません。「切り替えれば必ずすぐ反映される」とまでは言えないので、切り替えた後に実行記録で1回確かめるようにしています。
5. やったことと、効かなかったこと
上限に当たらないようにするために、2026年10月に次のことをしました。
- 対話のモデルを、作業が終わったら標準に戻す。いちばん効いたのはこれです。上位モデルが要る仕事は、対話全体ではなく、その仕事を任せる担当（サブエージェント）にだけモデルを指定して渡すようにしました。
- 30分おきの見張りを、60分おきにした（10月2日）。止まったら自動で再開する仕組みを別に用意できたので、10月19日には見張りの予約タスク自体を止めました。
- 毎時のチェックが読む手順書を分けた（10月19日）。35,088バイトの手順書を、毎回読む本体27,548バイトと、1日3回だけ読む詳細9,507バイトに分けました。1日24回のうち21回は本体だけを読むので、読み込みが21.5%減ります。
効かなかったこともあります。実行済みの1回きりの予約タスク44本を、フォルダごと別の場所に移して一覧を軽くしようとしましたが、アプリは登録を別に持っていて一覧から消えませんでした。元に戻しています。手順書を分けたのも、目標にしていた15KBには届きませんでした。毎時の回でも使う部分が多く、削れなかったためです。
なお、対策の後に上限へ当たる回数がどれだけ減ったかは、今回の手元の記録では測れていません。ここに書いたのは、対策の前に起きていたことの実測です。
6. 予約タスクを増やす前に決めておくこと
自分の失敗をふまえて、予約タスクを何本も動かすなら、この順番がいいと思っています。
- 予約タスクの実行記録を開いて、実際に動いたモデルを1回見る。設定画面ではなく、動いた結果を見ます。
- 対話で上位モデルを選んだら、終わったときに標準へ戻す。戻した後、次に動いた予約タスクのモデルをもう一度見ます。
- 頻度の高いタスクほど、手順書を短くする。毎時なら1日24回読まれるので、1回あたりの差がそのまま24倍になります。
- 使用量の画面で、週の枠を毎日1回見る。僕の場合、63%から99%までは3日でした。
まとめ
- 2026年9月、週の利用上限に当たって予約タスクが24.5時間すべて止まりました
- 予約タスクにはモデルの指定欄がなく、対話で最後に選んだモデルを引き継ぎます。10月17日は104回すべてが上位モデルでした
- 週の枠は10月2日の63%から、4日に99%まで進みました
次の1アクションとして、予約タスクを使っているなら、直近の実行記録を1件開いて、どのモデルで動いたかを確かめてみてください。数分で終わります。
ほかにも、自分で運営して測った記録を書いています。GA4に混ざっていた本番以外のホストの実測や、Qiita記事を19本書いた結果もどうぞ。