予約タスク4,758回のモデルをローカルの台帳から数えてみた。変わるときは全部いっぺんに変わった

Posted at 2026-11-01

はじめに

Claude のデスクトップアプリで、予約タスク（スケジュール実行）を100本以上動かしている。巡回や見張りのような、1日に何度も走る定型の仕事が中心だ。

あるとき、予約タスクがまるごと止まった日があった。原因を探すうちに、定型の巡回まで高いほうのモデルで走っていたことに気づいた。予約タスクの作成画面には、手順とスケジュールを書く欄はあるが、モデルを指定する欄が見当たらなかった。

そこで、手元に残っているセッションの記録（JSON）を集計して、予約タスクの回が実際にどのモデルで走ったかを数え直した。以前に自分で書いた下書きには「対話側のモデル選択を引き継いでいる」と書いてあった。この記事は、その主張が数字で再現できるかを確かめた記録でもある。

結果を先に書くと、予約タスクのモデルは、2026年6月24日から11月1日の4,758回で8回しか変わらず、変わるときは全タスクがいっぺんに変わった。一方で、「対話側の選択を引き継ぐ」という主張は、この記録だけでは確かめられなかった。

この記事で分かること

※数字はすべて、2026-11-01 時点の手元の記録を集計した実測（出典＝集計スクリプトの出力）
予約タスク4,758回（タスク170種類、2026-06-24〜11-01）のモデルは、8回しか切り替わっていない
同じ1時間に2つのモデルが現れた時間帯は、実測で3つだけで、どれも切替の時刻を含んでいた。タスクごとに別のモデルで走っていた形跡は無かった
10/17（実測）は104回すべてが Opus 5.5 で、そのうち72回（69%）は毎時で動く3本だった
10/12〜10/15 の198回はすべて Sonnet 4.6、10/19 の87回はすべて Sonnet 5.5 で、手元のメモと一致した
10/26 14:10 に予約タスクは Opus 5.5 へ戻っていた。下書きの時点では気づいていなかった変化だ
「対話側の選択を引き継ぐ」は確かめられなかった。10/16 は対話で Sonnet 5.5 を始めた23分後に、予約タスクは Opus 5.5 になった
実測から外れた範囲、つまり測れなかったこと：トークン量と金額（この記録には入っていない）、他のマシンの挙動

測定のやり方
集計スクリプト
日ごとの分布
切替は8回だけだった
全部いっぺんに変わる
10/17 の104回の内訳
手元のメモの主張を確かめる
対話セッションとの関係
止まっていた時間
effort も一緒に変わっていた
やったことと、測れなかったこと
測定の限界
まとめ
参考

測定のやり方

実測した環境

実測は手元の Mac で、次の環境で行った。

項目	内容
アプリ	Claude デスクトップアプリ 4.4212.0
OS	macOS 26.5
Python	3.9.6（標準ライブラリだけ）
記録の場所	`~/Library/Application Support/Claude/claude-code-sessions`
記録の数	JSON 4,823 ファイル（うち予約タスク由来が4,758、壊れていて読めなかったものが1）
期間	2026-06-24 〜 2026-11-01（JST）

記録は、セッションごとに1ファイルの JSON になっている。開始時刻（createdAt）、モデル名（model）、思考量の設定（effort）、予約タスクの識別子（scheduledTaskId）などが入っている。予約タスクから始まった回だけ scheduledTaskId を持つので、それで対話セッションと分けた。

何を数えるか

数える観点は3つに絞った。

日ごとに、どのモデルで何回走ったか
モデル名が前の回から変わった時刻（切替）
同じ1時間の中に2つ以上のモデルが現れた時間帯（出典＝集計の出力）

3つ目は「タスクごとに別のモデルが使われているか」を見るための指標だ。もしタスクごとに選ばれているなら、切替の前後以外でも、同じ1時間に複数のモデルが常に混ざるはずだ。

出力に入れないもの

予約タスクの名前や題名、会話の本文は読まない。集計スクリプトは、日付・モデル名・件数・タスクの識別子の数だけを出力する。記事の図もこの出力だけから作った。

集計スクリプト

集計は標準ライブラリだけで書いた。全文は手元にあるが、記事には核になる2つの関数を載せる。

まず、記録を読み込む部分。壊れたファイルと、開始時刻の無いファイルは数えずに、件数だけ控える。

import json, collections, datetime as dt
from pathlib import Path
from zoneinfo import ZoneInfo

JST = ZoneInfo("Asia/Tokyo")

def load(root):
    rows, inter, skipped = [], [], 0
    for f in Path(root).rglob("*.json"):
        try:
            d = json.loads(f.read_text(encoding="utf-8"))
            t = d["createdAt"] / 1000
        except (ValueError, KeyError, TypeError, OSError):
            skipped += 1
            continue
        when = dt.datetime.fromtimestamp(t, JST)
        if d.get("scheduledTaskId"):
            rows.append((when, d.get("model"), d.get("effort"), d["scheduledTaskId"]))
        else:
            inter.append((when, d.get("model")))
    rows.sort(key=lambda r: r[0])
    return rows, inter, skipped

次に、切替と「1時間に2モデル」を数える部分（実測に使ったコードそのもの）。

def switches_and_mixed(rows):
    switches, prev = [], None
    for t, m, e, _ in rows:
        if m != prev:
            switches.append((t.strftime("%Y-%m-%d %H:%M"), prev, m, e))
            prev = m
    hours = collections.defaultdict(set)
    for t, m, _, _ in rows:
        hours[t.strftime("%Y-%m-%d %H")].add(m)
    mixed = sorted(h for h, s in hours.items() if len(s) > 1)
    return switches, mixed

実際の analyze はこれに加えて、日ごとの集計、空白時間、10/17 のタスク別回数も返す。

集計の正しさを確かめる

実データだけで動かすと、数え方が間違っていても気づけない。そこで、合成した記録で期待値を決めてから走らせる検査も書いた。

合成した記録は、モデル A で3回、11時台にモデル B へ切り替わって1回、2日あけてさらに2回、という並びにした。予約タスクでない記録と、壊れた JSON、開始時刻の無い記録も混ぜた。確かめたのは次の9点だ（合成データでの実測）。

予約タスクの回の合計が6になること（対話の記録を数えない）
読めなかったファイルが2件と数えられること
タスクの種類が2になること
日ごとの集計が {"A": 3, "B": 1} になること
切替が A、B の順に1回だけ出ること
1時間に2モデルが現れた時間帯が「11時台」だけになること
最も長い空白が48.0時間になること
切替の12時間以内に対話の記録が無いと判定されること
24時間まで広げると、その記録が拾えること

9つとも通ったので、集計の数え方は期待どおりに動いている。実データの集計はその後に走らせた。

日ごとの分布

2026-09-01〜11-01 の予約タスクの回を、日ごとにモデルの系統で塗り分けたのが冒頭の図1だ。

実測では、9/1〜10/10 は、記録のある38日すべてが Opus 系だった
10/6 と 10/7 は、記録が1件も無い（空白の理由は、この記録からは分からない）
10/11 の途中で Sonnet 系に変わり、10/12〜10/15 は全日 Sonnet 系だった
10/16 は途中で Opus 系へ、10/18 は途中で Sonnet 系へ変わった
10/19〜10/25 は全日 Sonnet 系で、10/26 の午後から Opus 系に戻った

1日の回数は、集計の出力では9月に40〜90回、10月に入ってからは最大104回だった。

全期間でモデル別に数えた実測は、次のとおり（2026-11-01 時点）。

モデル	回数
opus-5	3,391
opus-5-5	553
sonnet-5-5	437
sonnet-4-6	266
opus-4-8	110
sonnet-5	1

Opus 系は合計4,054回で、全体の85%を占める。ただし、これは記録のある期間の割合で、費用の割合ではない。

切替は8回だけだった

記録を開始時刻順に並べ、モデル名が前の回から変わった所を拾った（出典＝集計スクリプトの出力、JST）。

実測で、130日あまりに切替は8回だった。うち4回は 10/11 以降の3週間に集中している。

10/11 12:18：Opus 5 から Sonnet 4.6 へ
10/16 16:03：Sonnet 4.6 から Opus 5.5 へ
10/18 14:19：Opus 5.5 から Sonnet 5.5 へ
10/26 14:10：Sonnet 5.5 から Opus 5.5 へ

最後の10/26 は、下書きを書いた時点では把握していなかった。この日以降、予約タスクはまた Opus 5.5 で走っている。この記録からは、戻った原因は読み取れない。

全部いっぺんに変わる

次に、「タスクごとに別のモデルが選ばれているのか、全タスクに共通なのか」を調べた。

集計した4,758回のうち、同じ1時間に2つのモデルが現れた時間帯は3つだけだった。8/04 の8時台、10/11 の12時台、10/18 の14時台で、どれも切替の時刻を含んでいた。

切替が8回あるのに時間帯が3つなのは、実測の出力を見ると、残りの5回は、切替の前後で同じ1時間に予約タスクの回が2つ以上起動しなかったためだ。つまり、切替の前後以外の時間帯で、あるタスクだけが別のモデルで走った形跡は、この記録には無かった。

これは、モデルがタスクごとに決まっているのではなく、全タスクに共通の1つの値から来ていることを示している。170種類のタスクが同じ日に同じモデルで走り、ある時刻を境にいっせいに入れ替わっていた。

ただし、「共通の値の正体」までは、この記録だけでは分からない。アプリの既定のモデルなのか、別の設定なのかは、次の節のとおり確かめきれなかった。

10/17 の104回の内訳

10/17 は、集計の出力で104回すべてが Opus 5.5 だった。タスクごとの回数を多い順に並べると、次のようになった（実測）。

23種類のタスクのうち、毎時で動く3本が24回ずつ（計72回）を占めた。2〜3回しか走らない10本が22回、1回だけの10本が10回だ。

この日に限らず、1日に何度も走る定型の仕事は、既定のモデルを引き継ぐ形だと影響が大きくなる。1回あたりの差が小さくても、回数に掛かるからだ。ただし、この記録にはトークン量が入っていないので、金額への影響は計算していない。

手元のメモの主張を確かめる

以前の下書き（2026年10月末の時点）には、予約タスクのモデルについて5つの主張が書いてあった。これを台帳の実測で確かめた。

最初の4つは、集計の出力で数字まで再現できた。

10/12〜10/15 の4日間の計198回は、すべて Sonnet 4.6 だった（36、49、59、54回）
10/17 の104回は、すべて Opus 5.5 だった
10/18 は 14:19 を境に、Opus 5.5 から Sonnet 5.5 へ入れ替わった。Opus 5.5 が58回、Sonnet 5.5 が41回だった
10/19 の87回は、すべて Sonnet 5.5 だった

5つ目の「予約タスクは対話側のモデル選択を引き継ぐ」だけは、台帳では確かめられなかった。理由は次の節に書く。

対話セッションとの関係

「対話側の選択を引き継ぐ」を確かめるには、対話セッションが何のモデルで始まったかと、予約タスクの切替時刻を突き合わせればよい。記録には対話セッションも入っているので（出典＝同じ集計の出力）、各切替の前後12時間以内にある対話セッションを探した。

結果は、集計の出力を見るかぎり、はかばかしくなかった。

実測では、台帳にある対話セッションの記録は、全期間で64件しか無い
切替の前後12時間に対話の記録があったのは、8回の切替のうち3回だけ
7/27 の切替は、前の晩に始めた対話が Opus 5 で、予約タスクも Opus 5 になった（一致する向き）
8/04 18:40 の切替は、対話の記録が切替より後の時刻にしか無い
10/16 の切替は、対話で Sonnet 5.5 を始めた23分後に、予約タスクが Opus 5.5 になった（一致しない向き）

つまり、一致する例が1つ、判定できない例が1つ、一致しない例が1つだった。「対話側の選択がそのまま予約タスクに移る」と言えるだけの根拠は、この台帳には無い。

ここで、下書きに書いていた「引き継ぐ」は、日ごとの分布が揃って入れ替わることから推測しただけの言い方だったと認める必要がある。記事のタイトルも、この点を書き換えた。

もう1つ注意したいのは、台帳の対話セッションの記録が、アプリで開いた全部を覆っていない可能性があることだ。64件という数が、アプリで開いた対話の全部なのかは分からない。記録が残る条件までは確かめていない。

止まっていた時間

台帳は、予約タスクが走っていなかった時間も教えてくれる（実測、JST）。開始時刻の間隔が長く空いた区間を、上位5つ拾った。

集計の出力で最も長い空白は 10/05 00:18 から 10/08 14:59 の86.7時間だった。その次が 7/20〜7/23 の84.9時間、10/24〜10/25 の35.6時間、9/27〜9/28 の25.2時間と続く。

9/27 04:19 から 9/28 05:33 の25.2時間は、手元のメモ（2026年9月の記録）にある「週の利用上限に当たって予約タスクが丸1日止まった」日と重なる。ただし、台帳に理由は書かれていないので、メモのほうを根拠にしている。ここは台帳だけでは裏が取れていない。

10/05〜10/08 の空白と、10/24〜10/25 の空白の理由は、この記録から読み取れなかった。

effort も一緒に変わっていた

記録には、思考量の設定（effort）も入っている（件数は2026-11-01 時点の実測）。予約タスクの回でこの項目を持つのは1,252件で、すべて「引き継いだ」という印（effortInherited）が付いていた。内訳は medium が990件、high が262件だ。

この項目が現れたのは 10/11 12:12 からで、それより前の3,506件には入っていなかった（集計の実測）。記録の形式がその頃に変わったのだと思う。

注目したのは、10/16 16:03 の切替で、モデルと effort が同じ回で一緒に変わったことだ。Sonnet 4.6 の high から、Opus 5.5 の medium へ。10/18 の切替では effort は medium のままだった。

モデルだけでなく effort も「引き継ぐ」形で入っているなら、予約タスクは、モデル名を選んでいるというより、アプリが持っているセッションの既定値のかたまりを受け取っているように見える。ただし、これも台帳の形からの推測だ。

やったことと、測れなかったこと

分布が揃って入れ替わる以上、対話側で変えても予約タスク側が追従するとは限らないが、とりあえず次の対策をした。

対話セッションのモデルを、設計や裁定が終わったら軽いものに戻す
Opus が必要な仕事は、サブエージェント呼び出しの model 指定で、担当だけに使う
1日に何度も走る見張りと巡回の間隔を、短い設定から広げた

測れなかったのは、これらの効果だ。台帳に入っているのはモデル名と回数で、トークン量や金額は入っていない。「Sonnet に戻したら、いくら減ったか」は、この記録からは出せない。

一方で、モデルの切替は10/26 に Opus 5.5 へ戻っているので、対話側で戻しても予約タスクが戻らない（または別の理由で変わる）可能性がある。今の運用が効いているのかどうかは、定点で台帳を数えて確かめる必要がある。

測定の限界

1台のマシンの記録だけで、他の環境の挙動は確認していない
台帳の対話セッションは実測で64件で、切替との突き合わせには足りない
「全タスクがいっぺんに変わる」は、実測では1時間単位の粒度での確認で、秒単位の同時性まで保証するものではない
モデルの変更が、アプリの更新、設定の変更、別の操作のどれで起きたかは、記録から読み取れなかった
トークン量、金額、週間の利用上限への影響は測っていない
公式ドキュメントのうち、モデルの選び方を説明するモデル設定のページには、デスクトップアプリの予約タスクのモデルの決まり方を書いた箇所を見つけられなかった（ページ内を「scheduled」「routine」で検索して0件）
記録の形式はアプリの更新で変わりうる。effort の項目が 10/11 から現れたのも、その一例かもしれない

まとめ

実測した予約タスク4,758回のモデルは、130日で8回しか切り替わらず、変わるときは全タスクがいっぺんに変わった。同じ1時間に2モデルが混ざった時間帯は3つで、すべて切替の時刻を含んでいた
10/17 の104回（実測）はすべて Opus 5.5 で、毎時の3本が72回（69%）を占めた。1日に何度も走る仕事ほど、既定のモデルの影響が回数に掛かる
手元のメモの数字4つは再現できたが、「対話側の選択を引き継ぐ」は台帳だけでは確かめられなかった。10/16 は逆向きの動きもあった
10/26 14:10 に Opus 5.5 へ戻っていた。原因が記録から読み取れないので、予約タスクのモデルは放っておくと気づかないうちに変わりうる
トークン量と金額は台帳に無く、節約額は測れていない

今回いちばん役に立ったのは、「記事に書く前に、自分の下書きの主張を台帳の数字で確かめ直す」という手順だった。4つ当たって、1つは外れた。外れた1つを、そのまま書いておく。

次の1アクション

次の1アクションは、これだけ。上のスクリプトを、自分の記録のフォルダに向けて1回走らせてみてほしい。出てきた日ごとの分布を見て、「自分が選んだ覚えの無いモデルで、予約タスクの回が走っていないか」を確かめる。見つかったら、その切替の時刻の前後に、自分が何をしたかを思い返してみてほしい。

予約タスクや自動運用を、モデルの継承や空白時間まで含めて棚卸ししたい場合は、自動運用の棚卸しの窓口から相談できます。

参考

同じ系統の記事

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up