Claude Code 自動化｜Routines・GitHub Actions・スケジュール実行ガイド

本記事は「Claude Code をローカルで使いこなしてきたけれど、PC を閉じても動かしたい」「GitHub の PR や Issue 起点で動かしたい」という中級者向けに、Claude Code Routines と GitHub Actions を中心とした自動化の地図を整理します。ヘッドレスモード・SDK・Routines の使い分け、任せる前に決めるべき項目、失敗時の確認ポイントまで、まず把握しておきたい全体像を 1 記事にまとめました。

🌱 Claude Code Routines とは何か

ひとことで：Anthropic クラウドで動く、公式の自動化機能です。PC を閉じていても動きます。

Claude Code Routines は、Anthropic が提供するクラウド側で Claude Code を実行する公式機能です。ローカルの PC が必須だったこれまでの Claude Code とは違い、PC を閉じていても・電源が切れていても、クラウド側でジョブが動き続けます。

「Claude Code Cloud」という呼び方をネット記事で見かけることがありますが、正式名称は Routines です。本記事でも「Routines」で統一します。

Routines が向いている使い方

Routines が真価を発揮するのは、次のような人間がリアルタイムで張り付かなくていいタスクです。

• 毎朝 9 時に open な PR をまとめてレビューさせる
• GitHub Issue が新規作成されたら、関連コードを読んで分類ラベルを付ける
• リリース前のセキュリティチェックを API 経由で起動する
• 週次レポートを自動生成して Slack に投稿する

これらは「ローカルの Claude Code でもできる」ものですが、毎回手元で claude を叩くのが面倒な作業です。Routines を使えば、トリガーだけ仕掛けておけば後はクラウドが勝手にこなしてくれます。

🆚 ローカル実行とクラウド実行の違い

ひとことで：実行場所・対話の有無・結果の届き方が違います。

ローカル実行（CLI・IDE 拡張・デスクトップアプリ）と、クラウド実行（Routines）の違いを整理します。

観点	ローカル実行	Routines（クラウド実行）
実行場所	あなたの PC	Anthropic 側のクラウド
PC の状態	起動・接続が必須	閉じていても OK
対話の有無	対話的（リアルタイム）	非対話的（事前定義したジョブ）
結果の届き方	ターミナル／アプリで即時表示	通知・コミット・PR・Slack 等
トリガー	人間がコマンド実行	Schedule / API / GitHub event
向いているタスク	探索・即時の修正	定期実行・イベント駆動

ローカルとクラウドは敵対関係ではなく補完関係です。普段の探索的なコーディングはローカル、定期処理やイベント駆動はクラウドに振り分けるのが自然な使い分けです。

データはクラウドに送られる

ここは明示的に書いておきます。Routines を使うと、対象リポジトリの内容や実行ログは Anthropic のクラウドに送信されます。社外秘リポジトリで使う場合は、社内のセキュリティポリシーと照らし合わせて利用可否を判断してください。詳しくは Anthropic の公式 Docs で利用規約を確認するのが確実です。

🎛️ 3 つのトリガー：Schedule / API / GitHub event

ひとことで：時刻起点・呼び出し起点・GitHub イベント起点、の 3 通りで Routines を起動できます。

Routines のトリガー（起動のきっかけ）は大きく 3 種類あります。

Schedule（定期実行）

cron 的な時刻ベースの定期実行です。「毎朝 9 時」「平日のみ 18 時」「月曜と木曜の昼」のような繰り返しジョブに最適です。

使いどころ：

• 毎朝 open PR を要約して Slack に通知
• 週次レポート生成
• 月初に依存ライブラリの更新候補をリストアップ

API（呼び出し起点）

外部システムから API 呼び出しで起動するパターンです。CI/CD パイプライン、社内ツール、自社サービスから Claude を呼びたいときに使います。

使いどころ：

• リリース直前のセキュリティレビューを CI から呼ぶ
• バグレポートが Sentry に届いたら Claude に解析させる
• Slack のスラッシュコマンドから呼び出す

GitHub event（GitHub イベント起点）

PR 作成・コメント・push などの GitHub イベントを起点に Claude を起動します。Routines のなかでも最も使われやすいトリガーです。

使いどころ：

• PR が作成されたら自動コードレビュー
• @claude メンション付きコメントへの自動回答
• Issue 作成時に関連コードを読んで初期トリアージ

⚙️ Claude Code GitHub Actions の基本セットアップ

ひとことで：公式の anthropics/claude-code-action を .github/workflows/claude.yml に書くと、@claude メンションで動かせます。

3 つのトリガーのうち、もっとも導入のハードルが低いのが GitHub Actions 経由です。Anthropic 公式の anthropics/claude-code-action を使います。

必要な準備

1. GitHub リポジトリ（自分が write 権限を持つもの） 2. 認証用の API キー（Anthropic API / Bedrock / Vertex AI / Foundry のいずれか） 3. .github/workflows/claude.yml ファイル

ワークフロー定義の最小例

下記は雰囲気をつかむための抜粋です。実運用で使う場合は必ず公式 Docs の最新例を参照してください。

name: Claude Code
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]

jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

ポイントは次の 2 点です。

• @claude メンションを含むコメントだけ起動するように if: で絞っている
• API キーは GitHub Secrets に保存（コードに直書きしない）

設定が済むと、PR や Issue のコメント欄で @claude このバグ調査して のようにメンションするだけで、Claude が起動して回答コメントを返してくれます。

認証方法は 4 種類

公式 Action は次の 4 種類の認証経路に対応しています（2026 年時点）。

• Anthropic API：個人や中小チーム向け、もっとも簡単
• AWS Bedrock：AWS インフラ前提のチーム
• Google Vertex AI：GCP インフラ前提のチーム
• Foundry（Azure）：Azure インフラ前提のチーム

社内ですでに使っているクラウドに合わせて選べばよく、機能差はほぼありません。

📋 任せる前に決める 5 つの項目

ひとことで：範囲・権限・通知・失敗時の挙動・ロールバック、の 5 項目を最初に決めておきます。

自動化を仕掛けるとき、最初に決めるべき 5 項目があります。これを曖昧にして始めると、後で想定外の暴走 → 慌てて止めるという事故が起きやすくなります。

1. 範囲（Scope）

Claude が触っていい範囲を明確に決めます。

• 触っていいリポジトリ：1 つに絞るか、複数許可するか
• 触っていいブランチ：main への直接 push は禁止が原則
• 触っていいファイル：legacy/ や docs/ など、対象外を明示

2. 権限（Permissions / allowedTools）

Claude が使えるツール（コマンド／API）を絞ります。デフォルトで全部許可ではなく、必要最小限に制限するのが運用の鉄則です。allowedTools 設定で「Bash の中でも git 系だけ」「ファイル編集は許可、rm は禁止」のように細かく制御できます。

3. 通知（Notifications）

Claude が動いた結果を、誰がどこで確認するかを決めます。

• GitHub PR コメント：もっとも自然、人間レビューと同じ場で見られる
• Slack 通知：オフィスチャットに集約したい場合
• メール：低頻度のジョブ向け
• Webhook → 自社ツール：監査ログを残したい場合

4. 失敗時の挙動（Failure handling）

Claude が失敗したり、予期しない結果になったときの方針を決めます。

• リトライ：一時的な API エラーなら自動で再実行
• 人間に通知：致命的な失敗は Slack/メールで担当者を呼ぶ
• スキップ：軽微な失敗は無視して次へ

5. ロールバック（Rollback）

自動で書き込み（コミット・PR 作成）させる場合、戻す手段は必ず用意しておきます。

• 必ず別ブランチを切る（main への直接 push は禁止）
• PR を立てて人間レビューを必須にする
• GitHub の Suggested changes として提案させる（適用は人間）

🔔 通知とレビューの設計

ひとことで：人間レビューを必ず挟める導線を、最初から作ります。

自動化の世界で一番危ないのは「動いたけど誰も見ていない」状態です。Claude の出力を必ず人間が確認できる導線を設計しましょう。

GitHub の Suggested changes として提案させる

Claude にコードを書き換えさせるとき、直接コミットするのではなく Suggested changes（提案コメント）として出させる運用は安全です。提案を「Apply」するのは人間で、Claude は「提案するだけ」の役割に留まります。

PR を作って人間レビューを必須にする

複数ファイル変更を伴うタスクでは、Claude に PR を作らせる運用がおすすめです。GitHub の Branch Protection（ブランチ保護）と組み合わせて「承認なしでは main に入らない」状態を作っておくと、Claude が暴走しても被害が局所化します。

Slack/メールで完了通知

長時間ジョブ（毎朝のレビューなど）は、完了したことを Slack やメールに通知させると見落としがありません。Anthropic Console の利用ログでも進行状況は見えますが、自分のいつもの場所に通知が届くほうが運用が回ります。

🆘 失敗時の確認ポイント

ひとことで：GitHub Actions のログ・Anthropic Console・パーミッション、の 3 か所を順に見ます。

Routines や GitHub Actions が想定通り動かないときの診断ポイントを、頻度の高い順に並べました。

1. GitHub Actions のログを見る

Actions タブから該当のワークフロー実行を開き、ステップごとのログを確認します。認証エラー・トリガー条件のミスマッチ・依存ステップの失敗が大半をここで見つかります。

2. Anthropic Console の利用ログ

Anthropic Console には、API 経由で実行した Claude のログが残ります。クォータ超過・モデル指定ミス・プロンプトの問題はここで切り分けます。

3. パーミッション・トークン・シークレットの設定

secrets.ANTHROPIC_API_KEY が空、Workflow の permissions: 設定が不足、@claude メンションの権限がない、といった設定漏れが次に多い原因です。.github/workflows/ のファイルと、リポジトリの Settings → Secrets / Actions / Branch protection を順番に確認してください。

🎯 依頼例：Schedule / GitHub Actions のプロンプト

ひとことで：自動化でも、プロンプト設計の 4 要素（CC-14）はそのまま効きます。

実際に Routines に書いたり、GitHub Actions のコメントとして送るプロンプトの例を 3 つ挙げます。

例 1：Schedule（毎朝のレビュー）

[Goal] 毎朝 9 時、open な PR を最大 3 件レビューしたい。
[Context] このリポジトリの open PR を作成日順に取得し、レビュー基準は CONTRIBUTING.md を参照。
[Constraints] PR を直接マージしない。コメント追記のみ。
[Done when] 各 PR に「サマリー＋気になる点 3 つ」のコメントを残し、必要なら needs-review ラベルを付ける。

例 2：GitHub event（メンション応答）

[Goal] @claude メンションされた質問に、関連コードを読んで回答する。
[Context] 対象は同一リポジトリの src/ 配下。テストや設定ファイルは参考程度に。
[Constraints] ファイルは編集しない。コメントだけ返す。
[Done when] Markdown 形式の回答コメントを 1 つ投稿。

例 3：API（リリース前セキュリティレビュー）

[Goal] リリース前ブランチに対するセキュリティレビューを実行する。
[Context] 対象は release/* ブランチの直近 50 コミット差分。重点項目は OWASP Top 10。
[Constraints] コードは修正しない。Issue 作成のみ。
[Done when] 重大度（High/Medium/Low）付きで Issue を起票し、High が 0 件なら✅、High が 1 件以上なら❌で API レスポンス。

CC-14 で扱った 4 要素プロンプトは、ローカルでもクラウドでもそのまま使えます。むしろ自動化では人間がリアルタイムで誘導できないので、4 要素を厳密に書く価値が増します。

🔀 ヘッドレスモード・SDK・Routines の使い分け

ひとことで：手元で一発・プログラムから・クラウドで定期、の 3 つを使い分けます。

Claude Code を「対話なし」で使う方法は実は 3 種類あります。混同されやすいので、軸で整理します。

方式	実行場所	起動方法	自由度	向いているタスク
ヘッドレスモード（claude -p）	あなたの PC	シェルから 1 発	中	CI/CD のステップ、ローカル自動化
Claude Agent SDK	任意（プログラムから）	TS/Python から呼び出し	最高	自社サービスへの組み込み、複雑な業務フロー
Routines	Anthropic クラウド	Schedule/API/GitHub event	中（運用基盤付き）	定期実行、PC を閉じても動かす

ヘッドレスモード（claude -p）

ローカルの claude コマンドに -p フラグを付けると、対話なし・1 発実行モードになります。シェルスクリプトやパイプとの相性が抜群です。

cat error.log | claude -p "根本原因を 1 文で要約して"
git diff main --name-only | claude -p "セキュリティ観点でレビュー"

CI/CD のジョブステップに組み込むのも、ヘッドレスモードが定番です。

Claude Agent SDK

TypeScript / Python から Claude エージェントをライブラリとして呼び出す方式です。自社サービスに AI 機能を埋め込むときの第一候補で、自由度が最も高くなります。

Routines

ここまで本記事で扱ってきた、Anthropic クラウドで動く公式機能です。トリガー基盤と運用画面が付属するため、自前でジョブスケジューラを作らなくていいのが利点です。

迷ったら次のように選んでください。

• 手元のシェルで完結する自動化 → ヘッドレスモード
• 自社サービスに組み込みたい → Agent SDK
• PC 不要で定期実行・GitHub 連携したい → Routines

⚠️ やりすぎ注意のポイント

ひとことで：自動 push を main に直接させない・機密リポジトリで bypassPermissions を使わない・「動き続ける」前提を持たない。

便利な反面、自動化は事故が起きると影響範囲が大きいので、最初に押さえておきたい注意点を 3 つだけ挙げます。

main ブランチへの自動 push は禁止

何度も書きますが、これは絶対です。Claude に書き込み権限を与えるなら、必ず別ブランチを切って PR を作らせる運用にしてください。main 直 push を許すと、人間レビューが入る前にコードが本流に流れ込み、ビルドやテストの破壊で全員の作業が止まります。

機密情報を含むリポジトリで bypassPermissions 相当を使わない

社外秘・個人情報・認証情報を含むリポジトリでは、「全部許可」モードに相当する設定は使わないでください。トークンの誤送信や .env の漏洩は、自動化で一瞬にして起きえます。

「動いた」≠「動き続ける」

Claude のモデルは進化し、API の仕様も変わります。今日動いた自動化が、半年後も同じ品質で動く保証はありません。月に一度はジョブの結果を人間が確認し、想定外の挙動が混ざっていないか定期点検する仕組みを作っておきましょう。

📚 次に読む記事

ここまで来たら、自動化の地図はほぼ揃いました。最後の仕上げに次の記事を読むのがおすすめです。

• 応用テクニックの集大成 → プロのベストプラクティス完全集（CC-09）
• 権限設計を深めたい → パーミッションと安全設定ガイド（CC-05）
• Skills を Routines にも流用したい → スラッシュコマンド & スキル完全ガイド（CC-06）
• 用語の確認 → Claude Code 用語集（CC-01）（Routines 項目あり）