読む担当のいない定時実行を、私は止めている。

私の定時実行は、PC のタスクスケジューラ、Claude のデスクトップアプリの定期タスク、クラウドのルーティンの 3 か所で動いています。どれも結果を書き出すところまでは進みます。ところが、その結果を読んで次に動く担当が決まっていませんでした。この記事では、その穴をふさいだ「受信箱」と、同じ日に定時実行を減らした中身を書きます。

1. 残す基準は「読む担当がいるか」

受信箱の決まりは 1 文です。担当が結果を読んで次の仕事を始めるものだけを残し、読む担当のいない定時実行は止めます。受信箱は、結果に次の 3 つの判定のどれかを付けます。

01. 結果は 4 行のページに置かせる

定時実行は、動くたびに自分専用の小さなページを丸ごと置き換えます。受信箱が読むのは、この 4 行だけです。

4 行にしたのは量の問題でした。2026年10月8日、結果を溜めていた月ごとのページ 4 枚を全文で読ませたところ、1 回の照合で約 14 万トークンを使いました。4 行のページなら、1 本数百トークンで読めます。

02. 表は 12 行

受信箱の表は 12 行です（2026年10月21日時点）。行ごとに、動く日・読む日・担当・始める条件・始める仕事を書いています。12 行のうち 9 行は要対応のときに次の仕事を始め、残りの 3 行は次の仕事の材料か、私の判断待ちの候補なので、何も始めません。

2. 受信箱の 1 日

受信箱は、平日の 11 時 40 分に Claude のデスクトップアプリの定期タスクとして回ります。

01. 止まりは、要対応より上に書く

クラウドのルーティンには、止まっても私に知らせる仕組みがありません（2026年10月21日時点）。4 行のページの実行日が古いことが、止まったと気づく手がかりです。だから止まりを先頭に書かせ、2 回続けて古いときだけ見張りの担当を起動します。

02. 最初の 6 営業日

作った翌日の 10月14日から 21日までの 6 営業日、受信箱は毎日回りました。担当が書いた票は合わせて 6 枚で、いちばん多い 15日は上限の 3 件でした。19日の票では、担当が実物を測り直したところ、私の 4 つのサイトのうち 1 つが、トップも記事も応答コード 500 を返していました。

3. 2026年10月13日に減らしたもの

受信箱を作った日に、定時実行の棚卸しもしました。私の指示は「エージェントに必要なものだけ残す」です。結果を読んで次の仕事を始める担当がいるかを、1 本ずつ当てはめました。

01. 止めた理由は 3 つの型

02. 止める前に、戻し方を書く

変えた 1 行ずつに戻し方を書き、消すルーティンは指示文と設定（時刻・モデル・道具）の控えを先に取りました。クラウドのルーティンは、削除すると過去の実行の記録も消えて戻せません。そこでクラウドの 5 本は自動にせず、私が画面で消しました。

03. 結果の置き場も、積み上がらない形に

それまでの月ごとのページは、9 月分が 1 枚で 184,723 字あり、大半が定時実行の追記でした。いまは定時実行ごとの記録ページを、今回・前回・履歴の 3 節に置き換えています。

4. つまずいたこと

01. 「要確認」も要対応に数える

10月16日、提携先の変更点を照合する日次の結果に「要確認」の行が 2 つ出ました。受信箱の条件がこの判定を拾っておらず、2 行はだれにも渡らないまま残りました。条件は「除外」「対象なし」以外はすべて要対応、と書き直しました。

02. 時刻を変えた直後は、止まりに見える

10月14日の初回の止まり 2 件は、どちらも前日に時刻を変えた定時実行でした。変更後の初回の結果がまだ入っていなかっただけで、受信箱は担当を起動せず、先頭に書いただけです。21日には 2 本とも期間内に戻っていました。

03. Windows と Mac、向かない人

受信箱の手順書は Markdown 1 枚で、OS の違いはありません。違いが出るのは回す側です。私の Windows の PC は 10月5日の夜に再起動し、アプリを開いたのは翌朝の 10 時 28 分でした。アプリの定期タスクは開いている間しか動かないので、6日の朝の回が抜けました。

定時実行が結果を決まった形で書き出していないなら、受信箱には読む物がありません。先に、結果を 4 行で置き換える形にそろえてからです。

5. よくある質問

6. まとめ

受信箱の結果を引き継いで回す、毎日の点検の中身は日次・週次の点検を 1 枚にまとめる回に書きました。