Anthropicが2026年4月にローンチしたClaude Code Routinesは、保存されたClaude Code設定です。プロンプト、1つ以上のリポジトリ、コネクタをパッケージ化し、Anthropic管理クラウドインフラ上で自動実行されます。公式ドキュメントでは、スケジュール実行、API（ベアラートークン付きHTTP POST）、GitHubイベントの3つのトリガータイプが説明されています。一方、GitHub Actionsはあなたが書いたスクリプトをGitHubホストランナー上で実行します。どちらもスケジュール実行されるAIエージェントを動かせますが、同じものではありません。選択を誤るとコストか膨大なYAML作業のいずれかが増加します。このポストは判断基準をマップして、ブログキュー処理をウォークスルーし、障害復旧について解説します。
Cloud Routines、Desktop、Session Loops、Actionsから選択
4つのホスティングオプションが存在します。互換性はありません。
Cloud Routinesはノートパソコンの電源状態に関わらずAnthropicのインフラ上で実行されます。ドキュメントによると、各ルーチンはスケジュール実行トリガー、APIトリガー、またはGitHubイベントトリガーを持つことができ、1つのルーチンで3つすべてを組み合わせることができます。トレードオフは、実行のたびに新規クローンされるため、ローカルファイルは利用できません。
デスクトップスケジュールタスクはあなたのマシン上で動作します。ローカルファイルシステム、ローカルデータベース、.envファイルへの完全なアクセスが可能です。マシンが無い場合、タスクは実行されません。シンプルです。
セッションスコープのスケジュール実行（CronCreate、CronList、CronDeleteツール）は開いているCLIセッション内でのみ動作します。これらはセッションスケジューリングツールであり、クラウドルーチンAPIではありません。セッション終了時に消滅します。
cronトリガー付きGitHub Actionsはワークフローヤマルファイルで、GitHubはホストランナー上で実行します。パブリックリポジトリは無料、プライベートは格安、決定論的で、コードベースと深く統合されています。GitHubに住んでいなければオーバーヘッドは実在しますが、開発者にとっては最小限です。
では、どう選びますか？
- タスクがマシンの電源状態に関わらず実行され、本当のAI推論（要約、ドラフト、選別）が必要ですか？Cloud Routine。
- タスクがローカル
.env、ローカルデータベース、またはローカルツールが必要ですか？デスクトップスケジュールタスク。 - タスクがCI/CDパイプライン、PRイベントハンドラ、またはAPIを呼び出してSlackに投稿する決定論的スクリプトですか？GitHub Actions。LLMなしの短いPythonスクリプトで十分な場合もあります。
- タスクが探索的で、すでに実行中の単一セッション内に存在しますか？Session loop。
AI Magicxの分析は明確です。ルーチンが「APIを呼び出す、変換する、Slackに投稿」なら、10行のPythonスクリプト付きGitHub Actionsの方が安く、シンプルです。Routinesが正しい選択になるのは、作業がClaude推論から本当の恩恵を受ける場合です。報告対象の選別、ナラティブ執筆、品質レビューなど。
ホスト別の永続性、ローカルファイル、認証情報
ここがオペレーターが失敗する箇所です。以下の表は、公式ドキュメントとコミュニティリサーチからの情報を使用しており、テスト結果を主張するものではありません。
| ホスト | ローカルファイル | .env | 認証情報 | ラップトップクローズ後も保持 |
|---|---|---|---|---|
| クラウドルーチン | いいえ（フレッシュクローン） | いいえ | ルーチン環境変数 | はい |
| デスクトップスケジュール済みタスク | はい | はい | ローカル設定 | いいえ |
セッションループ（CronCreate） | はい（セッションスコープ） | はい | セッションスコープ | いいえ |
| GitHub Actions | リポジトリファイルのみ | いいえ | GitHub Secrets | はい |
Shareuhack の 2026年の記事は、引用する価値のある特定の落とし穴を指摘しています。
「すべてのクラウドルーチン実行は Anthropic のクラウド環境でフレッシュクローンを実行するため、ローカルの .env.local、ローカルデータベース、またはその他のローカル状態にアクセスすることはできません。」
もう1つあります。クラウドルーチンのネットワークアクセスはデフォルトで「trusted」に設定されており、一部の API は明確に拒否します。ClickUp または別の API が trusted モードリクエストをドロップしている場合は、ルーチンの環境設定で「full」ネットワークアクセスに切り替えてください。若干のセキュリティトレードオフがあるため、リポジトリの機密性に照らし合わせて判断してください。
GitHub Actions の場合、シークレットはリポジトリの Secrets 設定に保存され、実行時に環境変数として挿入されます。Claude Agent SDK の上に構築された anthropics/claude-code-action@v1 アクションは、これらを自動的にピックアップします。--model、--max-turns、--allowedTools は claude_args 入力で渡して、エージェントが実際に実行できる内容を制御します。
現在のブログキュー作業者を読む
ブログキュー作業者はルーチン（または同等のスケジュール済みジョブ）で、キューから投稿を取得し、コンテンツを生成し、完了としてマークします。以下は現在の構造で、コードが実際に何をするのか、あなたが何を仮定するかもしれないかについて明確な警告があります。
条件付きクレーム：ワーカーがポストを取得する前に、そのポストが既にクレームされているかどうかをチェックします。これにより、少なくともハッピーパスでは2つの実行が同じアイテムを同時に取得するのを防ぎます。現在のコードに欠けているのは、stale-claim recovery（古いクレームの回復）です。ワーカーがポストを「進行中」にマークしたまま途中で停止した場合、そのポストは誰かが手動でリセットするまでクレームされたままになります。これを exactly-once delivery または 1日1ポストの保証として説明しないでください。どちらの主張もこのコードがサポートしている範囲を超えています。
ワーカーダイアグラムはおおよそこのようになります：
- キューをフェッチし、
status = queuedでフィルタリング - 最初に利用可能なポストをクレーム（
status = in_progressに設定、タイムスタンプを記録） - クレームされたポストのメタデータに対して生成プロンプトを実行
- 成功時：
status = publishedに設定、出力パスを記録 - 失敗時：
retry_countをインクリメント、status = queued にリセット（リトライが残っている場合）またはstatus = failedに設定
ステップ5は、ほとんどのチームが投資不足な箇所です。リトライロジックはルーチンプロンプトまたはラッパースクリプト内に存在する必要があります。クラウドインフラストラクチャ自体がエラーで終了したルーチンを再実行することはないからです。
このようなコンテンツパイプラインを構築しており、agentic レイヤーを自分で処理したくない場合、Seahawk Media で行っている agentic engineering の仕事がまさにこのパターンに対応しています。
予定されたジョブをスケジュールして、リトライを処理する
CLI でルーチンをスケジュールするには、Claude Code v2.1.225 以降が必要です。v2.1.211 より前のバージョンでは、スケジュールトリガーのないルーチンに対して phantom next-run time（年1）が報告されていました。古いログを読んでいる場合は知っておく価値があります。
API またはGitHub イベントトリガーのみを持つルーチンには、次の実行時刻がありません。CLI には何も表示されません。これは正しい動作であり、バグではありません。
リトライ処理には、2つのオプションがあります：
- プロンプト内でリトライする。プロンプトを記述して、失敗したステップを最大N回まで再試行してから、ジョブを失敗としてマークします。Claude の推論は、一時的なネットワークエラーと本当のコンテンツ問題を区別できます。
- 別のスケジュール済みルーチン経由でリトライする。軽量な「requeue」ルーチンが1時間ごとに実行され、
status = queuedかつretry_count < 3のポストをスキャンし、メインワーカーをAPI トリガー経由で再トリガーします（bearer トークンを使用して、ルーチンごとのエンドポイントへのPOST）。
2番目のパターンはスケール時により洗練されています。リトライポリシーを生成プロンプトから切り離し、メインルーチンに触れずにリトライ制限を調整できます。
日次実行上限と共有サブスクリプション使用量は、Arcade のエンタープライズ記事が指摘するように、チームにとって現実的な制約です。彼らの推奨：すべての作業を単一の日次「meta-orchestrator」ルーチンにバッチ処理し、リアルタイムトリガーは高優先度のイベントのみに予約します。
コンテンツパイプラインの SEO キーワード検索側については、DataForSEO + Claude Code で文書化した automation stack がこれを別途処理し、キュースキーマを設計する前に読む価値があります。
スタックしたクレームを検出して、公開された出力を検証する
Stale claims（古いクレーム）はキューベースのパイプラインの静かな殺し屋です。6時間以上 in_progress 状態にあるポストはほぼ確実にスタックしており、実行中ではありません。
検出ルーチンは次のようにシンプルにできます：
status = in_progressかつclaimed_at < now() - 2 hoursのポストをクエリ- これらのステータスを queued にリセットし、ワーカー識別子をゼロにして、リセットをログに記録します
- リセット数がしきい値を超えた場合、Slack またはウェブフック経由でアラートを送信します
これをメインワーカーに組み込むのではなく、別の低頻度ルーチンとして実行します（2時間ごとで問題ありません）。ここでは関心の分離が重要です：メインワーカーは自分自身の後片付けに責任を持つべきではありません。
公開出力の検証は別の問題です。ステータスフラグとしての「Published」はデータベースが書き込まれたことを意味します。投稿がサイトに正しく表示されたこと、可読性チェックに合格したこと、またはインデックスされたことを意味しません。検証ステップは以下を行うべきです：
- ライブ URL をフェッチして 200 を返すことを確認します
- 定義されたしきい値に対して、単語数または軽量な品質シグナルをチェックします（独自の数値を選択し、ユニバーサル標準ではなくチームヒューリスティックとしてラベル付けしてください）
- チェックが失敗した場合、ステータスを
queuedに戻し、インクリメントされたretry_countとverification_failedフラグを付けます
AI Content Humanizer Pipeline で説明したヒューマナイザーパイプラインは、同様の公開後検証パスを実行しており、その層を構築している場合は相互参照する価値があります。
運用コストと所有権
ここで「ルーチンはシンプル」という物語は摩擦に直面します。
Cloud Routines は Anthropic インフラストラクチャ上で実行され、対話的セッションと同じように Claude Code セッション制限を消費します。研究プレビューはこれを明示しています：ルーチンはあなたの制限を消費します。1日3〜4回のルーチンを実行する小規模なインディ事業者の場合、おそらく問題ありません。1日20回以上のバッチ実行をしているチームの場合、上限に達し、それに合わせてアーキテクチャを構築する必要があります。
GitHub Actions はパブリックリポジトリでは無料で、プライベートリポジトリではあたりの分で課金されます。anthropics/claude-code-action@v1 経由で Actions 内で実行される Claude Code エージェント実行は、依然として API トークンを消費します（Anthropic API レートで課金）が、ランナー、タイムアウト、および再試行ロジックを完全に制御できます。その所有権がポイントです。
実践での所有権の分割：
- ルーチンが所有：判断力が必要なタスク（Claude の推論が必要）、インフラストラクチャオーバーヘッドなしで無人実行する必要があるタスク、GitHub トリガー PR レビュー、および Sentry/ログトリアージ。
- GitHub Actions が所有：CI/CD パイプライン、PR イベント処理とインストールフロー、決定論的なビルド-テスト-デプロイシーケンス、および 10 行の Python スクリプトで本当に仕事をするすべてのタスク。
どちらが他方に取って代わることもありません。Shareuhack の記事はこれをよくまとめています：「最適な組み合わせでは、GitHub Actions が CI/CD を処理し、ルーチンは推論集約的な部分を処理します。」このフレーミングは正しく、ブックマークする価値のある決定境界です。
FAQ
Cloud Routine は私のリポジトリに書き戻すことができますか？
はい。ルーチンは1つ以上のリポジトリに接続でき、接続されたリポジトリを通じてコミットをプッシュしたり、プルリクエストを開くことができます。できないことは、ローカルマシンにのみ存在するファイルにアクセスすることです。ルーチンが必要とするものはすべてリポジトリ内にあるか、ルーチンのクラウド環境設定で環境変数として設定されている必要があります。
Cloud Routine が実行中にレート制限に達した場合はどうなりますか？
ルーチン自体は、レート制限エラー時に自動的に再試行しません。エラーで終了した場合、次のスケジュール実行またはAPI エンドポイント経由での手動トリガーまで失敗したままです。プロンプトに再試行ロジックを構築する（レート制限応答を検出し、待機し、再試行する）か、別の再キューイングルーチンを使用することが両方とも合理的な軽減策です。
GitHub App インストールは CLI web-setup コマンドとは別ですか？
はい、これは人々を困惑させます。CLI で /web-setup を実行するとクローンアクセスをルーチンに許可しますが、GitHub App はインストールしません。GitHub イベントトリガーのウェブフック配信には、別の GitHub App インストールが必要です。ルーチン設定フローはこれをステップバイステップで案内しますが、2つのステップは異なります。
GitHub イベントトリガーは、研究プレビュー中の Routines でレート制限の対象ですか？
公式の Routines ドキュメントによると、GitHub webhook イベントは研究プレビュー中、ルーティンごと、アカウントごとの時間単位のキャップの対象となります。キャップを超えたイベントはウィンドウがリセットされるまで削除されます。PR アクティビティのバースト増加が予想される場合は、計画を立てておいてください。
GitHub Actions ワークフロー内で `anthropics/claude-code-action` を使用してスキルを利用できますか？
はい。prompt 入力は /skill-name のようなスキル呼び出しを受け入れます。アクションを実行する前に actions/checkout ステップが必要です。そうすることで、.claude/skills/ 内のスキルファイルが runner に存在することになります。Claude Code ではスキルとコマンドは別の概念です。この 2 つを混同する前に、公式スキルドキュメントを確認してください。
上記のすべての中で最も重要な注意点: Cloud Routines はインタラクティブセッションと全く同じ方法で Claude Code セッション制限を消費しており、現在のキューワーカーには stale-claim リカバリー機構が組み込まれていません。本番環境に配備する前に、両方に対応する設計にしてください。