Claude Codeの/scheduleコマンド解説｜寝てる間にAIが働く自動化術【2026年】

寝ている間にAIがコードレビューして、朝起きたらPRが整理されている。SF映画の話じゃなく、2026年4月14日にリリースされたClaude Codeの/schedule（Routines）で実現できることです。CS対応メール1通あたり15分→3分（80%削減）、営業レポート作成2〜3時間→3〜5分——こうした数字が出始めています（uravation.com、SyncGTM）。ただし、最初のRoutineがサイレントに失敗する確率がかなり高いのも事実。環境変数の罠、ステートレス実行の壁、テスト用ルーティンの消し忘れで請求3倍——失敗パターンも含めて、このガイドで全部潰していきます。

/scheduleの基本——PCの電源オフでも動く仕組み

まず押さえておくべき核心は、/scheduleはAnthropicのクラウドVM上で実行されるということです。ローカルのターミナルもPCの電源もいりません。実行のたびにGitHubリポジトリのデフォルトブランチをフレッシュにcloneし、タスクを実行し、VMが破棄されます。完全にステートレス。

アクセス方法は2つあります。

• CLI: Claude Codeのターミナルで /schedule と入力
• WebUI: claude.ai/code/routines からブラウザで設定

3種類のトリガー

cronトリガーの最小間隔は1時間です。5分間隔で回したい場合は後述する/loopのほうが適しています。

プラン別の実行回数制限

/scheduleはProプラン以上で使えます。無料プランでは利用できません。

個人で使うならPro（1日5回）でも「朝・昼・夕方・夜・深夜」の5サイクルが回せるので、日次レポートや定期レビュー程度なら十分です。15回以上必要になるのはチーム開発で複数リポジトリを監視するケースくらいでしょう。

/schedule vs /loop——どっちを使うべきか

Claude Codeには似たような定期実行の仕組みとして /loop もあります。「どっちを使えばいいの？」という質問をよく見るので、違いを整理しておきます。

選び方の基準はシンプルです。

• PCを閉じても動いてほしい → /schedule
• 5分〜30分おきにローカルファイルを監視したい → /loop
• 前回の結果を踏まえて次のアクションを変えたい → /loop

たとえば「毎朝9時にGitHubのissueを棚卸しして優先度を整理する」なら/schedule。「コード変更を検知したら即テスト実行」なら/loopです。

実際のところ、/scheduleと/loopは競合ではなく補完関係にあります。/scheduleで日次のルーティンタスクを回しつつ、開発中は/loopでリアルタイム監視する——この組み合わせが一番実用的です。

現場の成功事例——数字で見るインパクト

抽象的な話ばかりしても仕方ないので、実際に/scheduleまたはClaude Code自動化で成果が出ている事例を見ていきます。

事例1: CS対応メールの自動処理

カスタマーサポートのメール対応で、1通あたりの処理時間が15分→3分に短縮。月間で約60時間の工数削減に成功しています。過去の対応履歴をGitHub上のナレッジベースとして構造化し、/scheduleで定期的に新着メールを取得→下書き生成→レビュー待ちステータスにする——という流れです（uravation.com）。

事例2: 映像ディレクターのワークフロー効率化

映像ディレクターがClaude Codeの自動化を活用し、1日2時間、月60時間の削減を達成。撮影スケジュールの調整、素材管理、クライアントへの報告書作成といった「クリエイティブじゃないけど必須」な業務を自動化しています（genai-ai.co.jp）。

事例3: 営業日報レポートの自動生成

営業チームの日次レポート作成が2〜3時間→3〜5分に。CRMのデータをGitHub Actionsで定期exportし、/scheduleでClaudeがMarkdownレポートを生成してPRを作成する仕組みです（SyncGTM）。

事例4: 求人票作成の自動化（Findy）

エンジニア採用プラットフォームのFindyでは、求人票の作成時間を20〜60分→5分に短縮。職種要件と社内テンプレートをGitHubリポジトリに格納し、/scheduleで新規ポジションが追加されるたびに自動で求人票のドラフトを生成しています（uravation.com）。

これらの事例に共通するのは、**「繰り返し発生する」「フォーマットがある程度決まっている」「人間の最終確認は入る」**という3条件です。完全放置ではなく、AIがドラフトを作って人間がレビューする——この「AIファースト・ヒューマンラスト」の設計が成功のカギになっています。

失敗パターン6選——最初のRoutineが落ちる理由

成功事例だけ見て「よし、やるぞ」と飛びつくと痛い目を見ます。/scheduleには初心者が確実に踏む地雷がいくつかあります。正直、全部踏んでから気づくより先に知っておいたほうが100倍マシです。

地雷1: 環境変数がクラウドに引き継がれない

これが最も多い失敗です。 ローカルの.envファイルに入れているAPIキーやDB接続情報は、Anthropicのクラウド VMには存在しません。ローカルでは完璧に動くプロンプトが、/scheduleで実行すると何のエラーも出さずにサイレントに失敗する。原因に気づくまで数時間ハマった、という報告が続出しています（popularaitools.ai）。

対策: 環境変数はRoutineの設定画面で明示的に登録するか、GitHub Secretsを利用してください。

地雷2: APIトークンは一度しか表示されない

APIトリガー用のトークンは生成時に1回だけ表示されます。コピーし忘れた？ 残念ですが、そのRoutineを削除して最初から作り直すしかありません（popularaitools.ai）。

対策: トークン生成したら即座にパスワードマネージャーに保存。メモ帳に「後で保存しよう」は確実に忘れます。

地雷3: ネットワーク制限（trustedモード）

デフォルトの "trusted" モードでは、一部の外部APIへのアクセスがブロックされます。Slack APIやGitHub以外の外部サービスと連携する場合、"full" アクセスモードに変更する必要があります（popularaitools.ai）。

地雷4: テスト用Routineの消し忘れ→請求3倍

これはQiitaで報告された実話です。テスト用に「5分間隔」で設定したRoutineを消し忘れたまま一晩放置した結果、通常の3倍の請求が発生しました（Qiita nogataka氏）。

/scheduleの最小間隔は1時間ですが、/loopで5分間隔のテストをした場合にも同様のリスクがあります。テストが終わったらRoutine（またはloopセッション）を必ず停止・削除する癖をつけてください。

地雷5: ステートレス実行の壁

毎回フレッシュなVMで実行されるということは、前回の実行結果を覚えていないということです。「昨日のissueは処理済みだから今日は新しいものだけ」という判断は、プロンプトだけでは不可能です（Zenn dely_jp）。

対策: GitHub issueのラベル、外部DBのフラグ、あるいはリポジトリ内のステートファイル（state.json等）を使って、処理済み・未処理の状態を外部に永続化する設計にしてください。

地雷6: ブランチpush制限

/scheduleからのpushは、デフォルトで claude/ プレフィックスのブランチにしか許可されていません。mainに直接pushしようとしても弾かれます（popularaitools.ai）。

これはセキュリティ上の正しい制約ですが、知らないと「PRが作れない」「pushが通らない」で悩むことになります。ブランチ名はclaude/daily-reportのようにclaude/で始めてください。

実践セットアップ——最初のRoutineを動かすまで

ここまで読んで「で、具体的にどうやるの？」と思っている方向けに、最小構成のセットアップ手順を解説します。

ステップ1: GitHubリポジトリの準備

/scheduleはGitHubリポジトリのデフォルトブランチをcloneして実行します。つまり、自動化したい処理に必要なファイルがすべてリポジトリ内に揃っている必要があります。

my-automation-repo/
├── CLAUDE.md          # プロンプト（Claudeへの指示）
├── templates/         # テンプレートファイル
│   └── daily-report.md
├── state.json         # ステート管理用（地雷5の対策）
└── README.md

CLAUDE.mdにプロジェクトの背景、制約条件、期待する出力フォーマットを書いておくと、/scheduleの実行精度が格段に上がります。

ステップ2: Routineの作成

CLIの場合:

claude
# Claude Code起動後
/schedule

対話形式でトリガーの種類、実行間隔、プロンプトを設定していきます。

WebUIの場合は claude.ai/code/routines にアクセスして、GUIで同じ設定ができます。

ステップ3: 環境変数の設定

ローカルの.envに依存しているものはすべてRoutineの設定画面で登録します。登録を忘れた状態で実行すると地雷1を踏みます。

ステップ4: テスト実行と確認

設定したら必ず手動で1回テスト実行してください。成功したことを確認したら、本番のスケジュールを有効化。テスト用のRoutineは忘れずに削除（地雷4の対策）。

ONIで/scheduleをもっと簡単に

正直なところ、/scheduleのセットアップには技術的なハードルがあります。GitHubリポジトリの構成、環境変数の管理、ステートレス設計——エンジニアなら対処できますが、非エンジニアのビジネスユーザーにはちょっと厳しいのが現実です。

ONI（自動化の鬼） は、こうしたClaude Code系の自動化をGUIベースで簡単に構築できるデスクトップアプリです。/scheduleの概念（定期実行・トリガー・外部連携）をコマンドラインではなくビジュアルに設定できるので、「やりたいことは明確だけどCLI操作がハードル」という方には選択肢になります。

また、ONIはClaude Codeの/scheduleが苦手とするローカルファイル操作やデスクトップアプリとの連携もカバーしています。/scheduleで対応しきれない業務は、ONIのワークフロー機能で補完する——という使い分けも現実的です。

働き方はどう変わるのか——/scheduleの本質的なインパクト

/scheduleの本質は「タスクの非同期化」です。これまでの仕事は「人間がPCの前に座っている時間＝生産可能な時間」でした。/scheduleはこの前提を壊します。

note.comのユニコ氏が指摘しているように、「AIが24時間稼働する世界では、人間が管理すべきは"時間"ではなく"タスクの設計"」です（note.com ユニコ）。寝ている間にAIがドラフトを仕上げ、朝はレビューから始まる。作業の主語が「自分がやる」から「AIにやらせて確認する」に変わります。

ただし、やすだ.devが解説しているように、この変化を活かすにはプロンプト設計とステート管理のスキルが必要です（note.com やすだ.dev）。「何を自動化するか」だけでなく「どう状態を管理するか」「エラー時にどうリカバリーするか」まで設計しないと、/scheduleは「毎朝ゴミを量産するbot」に成り下がります。

まとめ——/scheduleは「仕組み」を作れる人が勝つ

/scheduleは間違いなく強力なツールです。PCを閉じてもクラウド上でAIが動き続ける。成功事例を見れば、月60時間以上の工数削減も夢ではありません。

しかし、この機能の本当の価値は「コマンドを覚えること」ではなく、自動化すべき業務を見極め、ステートレスな環境で動く仕組みを設計できることにあります。環境変数を正しく管理する。状態をGitHubリポジトリや外部DBに永続化する。エラー時のリカバリーを設計する。これができる人とできない人で、/scheduleの成果は天と地ほど変わります。

まずは1日5回（Proプラン）で十分なので、小さなRoutineから始めてみてください。日次レポートの自動生成、issueの棚卸し、コードの定期レビュー——どれも「毎日やってるけど面倒」な作業が最適な出発点です。そして慣れてきたら、ONIのようなGUIツールを組み合わせることで、ローカルファイル操作も含めた包括的な自動化環境を構築できます。

寝ている間にAIが働く。その未来は、もう手の届くところにあります。

出典・参考リンク

• Anthropic公式 Claude Code Routines: claude.ai/code/routines
• uravation「Claude Code自動化ケーススタディ2026」: uravation.com
• SyncGTM「Claude Code Sales Reporting」: syncgtm.com
• genai-ai.co.jp「映像ディレクターの活用事例」: genai-ai.co.jp
• Popular AI Tools「Claude Code Scheduled Tasks & Routines 2026」: popularaitools.ai
• Qiita nogataka氏「テスト用Routineの消し忘れ事例」: qiita.com
• Zenn dely_jp「ステートレス実行の設計」: zenn.dev
• note.com ユニコ「schedule機能の働き方への影響」: note.com
• note.com やすだ.dev「/schedule完全解説」: note.com