社内向けの定期レポートや通知を、サーバーを持たずに自動化したいと考えるエンジニアに向けた内容です。Claude Code（Anthropicが提供するAIコーディングエージェント）には、クラウド上で定期実行する「routines」という機能があります。この記事ではこの機能を業務システムの小規模バッチとして使う場合に、何を確認し、どこに注意すべきかを整理します。
ルーティン自体は目新しい発想ではありません。cronジョブやGitHub Actionsのスケジュールトリガーと同じく、決まった時刻に処理を走らせる仕組みです。違うのは、実行内容が固定のスクリプトではなく、自然言語の指示書に基づいてLLM（大規模言語モデル）が都度判断しながら動く点です。情報収集やレポート作成のように、毎回の入力が変わり厳密な手順化が難しい業務に向いています。
routinesが解決する運用コストの種類
社内向けの定期配信バッチは、処理自体は小さくても運用上の負担が積み重なります。実行サーバーの維持、APIキーの管理、障害時の再実行、通知先の調整など、内容の割に周辺コストが高くなりがちです。
Claude Codeのroutinesは、この周辺コストの一部を肩代わりします。2026年10月時点では、Pro・Max・Team・Enterpriseの各プランでリサーチプレビュー（試験提供）として使え、claude.ai/code/routinesの画面かCLIの/scheduleコマンドから設定できます。
重要なのは課金体系です。routinesで消費されるのはサブスクリプションの利用枠であり、API従量課金ではありません。小規模な社内バッチをAPI経由で動かす場合に発生しがちな「想定外の請求」を避けやすい構成といえます。
クラウド実行ゆえの3つの制約
ルーティンの実行環境はAnthropicのクラウド上にあり、手元のPCやサーバーの電源状態と無関係に動きます。ただしこの「サーバーレスでの楽さ」には、業務利用の前にチェックすべき制約が3つあります。
1つ目は、リポジトリが毎回フレッシュクローン（まっさらな状態での再取得）される点です。ローカルファイルへの永続的な書き込みはできません。状態を保持したい場合は、履歴データをすべてGitリポジトリにコミットしておく設計が必須になります。
2つ目は、ネットワークアクセスの制限です。デフォルトの「Trusted」というネットワーク設定では、パッケージレジストリなど既定の許可リスト以外への外向き通信が遮断されます。Slackのhooks.slack.comのような外部APIへ直接POSTしようとすると、403エラーで弾かれる事例が報告されています。一方でapi.github.comへのアクセスやgit pushは通ることが確認されています。
3つ目は、LLMの指示遵守が確率的である点です。手順書に正しい指示を書いても、毎回必ず実行されるとは限りません。日付をUTC（協定世界時）ではなく日本時間で取得するよう明記していても、ある実行回でその指示が抜け落ち、前日付のレポートが生成された事例があります。
業務システムに組み込む前の設計チェックリスト
これらの制約を踏まえると、routinesを業務バッチとして採用する前に確認すべき点が見えてきます。既存の運用基盤と照らし合わせて、以下を確認してください。
- 永続データの扱い：状態管理が必要な処理なら、履歴JSONなどをリポジトリにコミットする設計に変えられるか
- 外部通信の要否：SlackやWebhookなど外部サービスへの通知が必要な場合、ネットワーク設定を「Custom」にして許可ドメインを追加するか、GitHub Actionsなど外部通信に制限のない実行環境へ処理をリレーするか
- 秘密情報の置き場所：Webhook URLやAPIトークンをクラウドセッションの環境変数に置くと、そのセッションを使う全員から見える可能性がある。機密情報は別の実行環境のsecrets機能に隔離できるか
- LLMが担う判断と、コードが担う処理の切り分け：「何を配信するか」のような曖昧な判断はLLMに任せつつ、「ファイルを正しい形式で更新する」といった毎回同じ結果を要求する処理は通常のスクリプトに分離できるか
この最後の項目が、エンタープライズの既存コードベースに組み込む際にもっとも効いてきます。数百件規模の履歴データをLLMに直接編集させると、形式を壊す・レコードを消すといった事故が確率的に起こり得ます。マージ処理やバリデーションは従来型のPythonスクリプトに任せ、LLMには新規差分の生成だけを担当させる分業が安全です。
GitHub Actionsとの役割分担という考え方
routinesとGitHub Actionsを組み合わせる設計は、CI/CDパイプラインに慣れたエンジニアには馴染みやすい発想です。routinesを「情報収集とコンテンツ生成」、GitHub Actionsを「配信と外部連携」に分けることで、それぞれの得意分野に処理を寄せられます。
具体的には、レポートファイルがリポジトリに新規追加されたタイミングだけでActionsのワークフローを発火させる設定が考えられます。
on:
push:
branches: [main]
paths:
- "reports/report-*.md"このように発火条件をファイルパスで絞ることで、スクリプトの修正コミットでは誤配信が起きず、「新しいレポートが生まれたときだけ通知が飛ぶ」動きになります。
今日確認できること
導入を検討する前に、まず自社の契約プランがPro・Max・Team・Enterpriseのいずれかであるかを確認してください。リサーチプレビュー扱いの機能なので、提供条件は今後変わる可能性があります。公式ドキュメントのroutines関連ページで最新の対象プランと利用上限を確認するのが確実です。
次に、既存の定期バッチのうち「判断を伴う情報整形」と「機械的なデータ更新」が混在している処理がないか棚卸ししてみてください。前者はLLMへの置き換え候補になり、後者はスクリプトのまま残すべき処理です。
最後に、通知先が社内Slackなど外部サービスの場合、ネットワーク設定を「Trusted」のままにするか「Custom」で許可ドメインを足すか、あるいはGitHub Actionsのような別環境にリレーするかを、秘密情報の管理方針とあわせて決めておく必要があります。
まとめ
routinesは、サーバー管理の負担なく定期的なAIエージェント処理を回せる仕組みです。業務導入の際は次の3点を起点に検討してください。
- 状態はすべてリポジトリへのコミットで持たせる設計に変えられるか
- 外部通信が必要な処理は、許可ドメイン追加かGitHub Actionsへのリレーのどちらで解決するか
- LLMに任せる判断と、スクリプトに任せる機械的処理をどう切り分けるか
この3点を既存の運用ルールと照らし合わせれば、小さく試す対象として現実的かどうかの判断材料になります。