Claude Code 自動化ガイド — Routines・Headless・4 方式を使い分ける方法

Claude Code で自動化できる業務 — 3 カテゴリの全体像

Claude Code の自動化が向いている業務は大きく 3 カテゴリに分けられます。

① コーディング補助の定期実行 毎朝決まった時間にコード品質チェック・テストカバレッジレポート生成・依存パッケージの更新提案を自動実行するパターンです。複数人が同一プロジェクトを触る環境でも、AI がナイトリーでリグレッションを確認してレポートを出力するため、朝会でのレビュー負担を大きく減らせます。コードベースの「漂流」—— 古くなったドキュメントや放置されたコメント —— を定期検出する用途にも向いています。

② イベント駆動型のレビュー自動化 プルリクエストの作成や特定ブランチへのプッシュなど、Git リポジトリ上の変更イベントをトリガーにして Claude Code を起動する方式です。レビュアー待ちの時間をゼロにし、コーディング規約チェック・バグ候補の指摘・ライブラリ移行の差分確認といった初期フィードバックを自動化できます。

③ 外部サービス連携による運用自動化 デプロイ完了通知・監視アラート・カスタマーフィードバック受信など、外部システムからの HTTP 呼び出しをトリガーにするパターンです。Slack・Linear・Google Drive などのコネクタ（MCP）と組み合わせると、チケット自動分類・ドキュメント自動更新・デプロイ後の動作確認まで連続して処理できます。受信したアラートの本文を AI に読ませ、影響範囲の特定とロールバック判断の素案を作らせるところまで一気通貫で組めるため、夜間オンコールの初動対応を大きく軽量化できます。

自動化が効きやすい業務の見分け方

3 カテゴリに共通するのは「判断基準が明文化できる繰り返し作業」という性質です。コード品質チェックなら社内のレビュー観点リスト、PR レビューなら規約ドキュメント、運用通知なら過去のインシデントレポートが、AI に渡す判断基準のソースになります。逆に「センスで決めている」「毎回前提が違う」業務は、まずチェックリストを書き起こすところから始めるのが近道です。Claude Code はチェックリストの読み込みと実行が極めて得意なため、判断基準を文章化できた瞬間に自動化の射程に入ります。

導入時の優先順位

最初に着手すべきは「毎朝の同じ確認作業」です。テスト失敗パターンの分類、依存パッケージの脆弱性チェック、ドキュメントと実装の差分検出など、現状エンジニアが手で 30 分〜1 時間かけている定型作業から潰していくと、ROI が早期に可視化されます。逆に最初から PR レビュー全自動化のような大がかりなフローを組むと、規約の文書化が追いつかず途中で頓挫しやすいので避けたほうが無難です。

Routines — クラウドで動く 3 種のトリガー

Routines は 2026 年 4 月 14 日に Anthropic がリサーチプレビューとして公開した、クラウド完結型の自動化機能です（[src: https://claude.com/blog/introducing-routines-in-claude-code]）。ユーザーのノートパソコンが閉じていても、Anthropic が管理するサーバー上で Claude Code が動き続ける点が最大の特長です。

プラン別の実行上限（1 日あたり）

スケジュール型 Routines は一回限りの「ワンオフ実行」も設定可能で、特定日時に一度だけ処理を走らせる用途にも対応しています。API トリガーはベータヘッダー anthropic-beta: experimental-cc-routine-2026-04-01 を付与した HTTP リクエストで起動し、text フィールドに実行時コンテキストを渡せます（[src: https://code.claude.com/docs/en/routines.md]）。

Routines は 個人の Claude.ai アカウントに紐付くため、現時点でチームメンバーへの共有は非対応です。チーム全体で共有したい自動化は、後述の Headless モードや CI 連携との組み合わせを検討してください。

API トリガーの実装イメージ

API トリガー型 Routines は、Webhook 受信を起点とした自動化に向いています。Anthropic の API エンドポイントへ POST すると、登録済み Routine が起動し、text フィールドの内容をその回の追加コンテキストとして読み込みます。たとえば監視ツールから障害アラートを受信した瞬間に、関連サービスのログ分析と影響範囲のサマリ生成を走らせる、といったフローが組めます。エンドポイント URL とトリガー ID は Routines の管理画面で発行され、シークレットを介して認証されます。本番運用ではアラート抑止（フラッピング対策）と再送制御を呼び出し元側で実装しておくと、誤発火による上限消費を防げます。

Git イベントトリガーの活用パターン

Git イベントトリガーは、特定のリポジトリ・ブランチ・PR の状態変化に対して Routines を起動する仕組みです。代表的な使い方は「main ブランチへのマージ直後にリリースノートのドラフトを生成する」「draft PR が ready に切り替わったタイミングでカスタムレビュー観点を流す」など、Pull Request のレビュー初動を AI に肩代わりさせるパターンです。GitHub Actions のように YAML を書く必要はなく、Routines の管理画面から数クリックで設定できる点が利点ですが、リポジトリへの書き込み権限が広く付与されることになるため、対象ブランチを保護ブランチに限定する設定をおすすめします。

Headless モード（-p / --bare）— スクリプトと CI への組み込み

Claude Code は -p フラグを付けて起動すると、インタラクティブな UI を起動せずにコマンドラインやスクリプトから直接呼び出せるプログラマティックモードになります。

# 基本的な Headless 実行
claude -p "src/app.ts のテストカバレッジを確認してレポートを出力して"

# 構造化 JSON で出力
claude -p "変更点を箇条書きにして" --output-format json

CI 環境（ビルドパイプラインなど）では --bare フラグの追加が推奨されています。--bare を指定すると、フック・スキル・MCP・CLAUDE.md の読み込みをスキップして起動が高速化されます。公式ドキュメントには「将来的に -p のデフォルト動作になる予定」と明記されており、CI で使う場合は今から --bare を習慣にしておくと移行コストがかかりません（[src: https://code.claude.com/docs/en/headless.md]）。

Headless モードの主要オプション早見表

JSON 出力をパイプで処理する実例

--output-format json を組み合わせると、Claude Code の応答を構造化データとして受け取り、後段のスクリプトに渡せます。たとえば「変更ファイル一覧と各ファイルの差分要約」を JSON で受け取り、jq で整形して Slack に通知する、といった連携が組めます。stream-json を選ぶとトークン単位でのストリーミング受信になるため、長時間かかる解析タスクの進捗をリアルタイムでログ化したい場合に有効です。出力スキーマは公式ドキュメントに記載があり、type フィールドで assistant / tool_use / result を識別して処理を分岐させるのが基本パターンになります（[src: https://code.claude.com/docs/en/headless.md]）。

CI 環境での実装パターン

CI で Headless モードを使う場合、押さえておきたいポイントは 3 点あります。第一に、API キーは CI のシークレットマネージャから注入し、リポジトリにコミットしないこと。第二に、--allowedTools で使用ツールを最小限に絞り、想定外のファイル書き込みやネットワークアクセスを起こさせないこと。第三に、ジョブのタイムアウトを十分に確保しておくことです。長時間タスクの途中で CI ランナーが SIGTERM を受けると中途半端な変更がリポジトリに残るため、タイムアウト時に git reset するクリーンアップステップを別途用意しておくと安全です。

自動化方式の選び方チャート

4 方式は「PC が不要か」「ローカルファイルにアクセスできるか」「チームで共有できるか」でそれぞれ棲み分けがあります。この 3 軸を押さえると迷わずに選択できます。

判断フロー:

1. PC を閉じても動かしたい → Routines（クラウド）
2. ローカルファイルを毎朝操作したい → デスクトップ Schedule
3. チームで共有・CI 組み込みが必要 → Headless モード + ビルドパイプライン
4. セッション中に確認なしで繰り返したい → /loop + Auto モード

上記の判断軸に加え、コストの試算も考慮が必要です。Routines はプラン上限内なら追加費用なし。Headless モードを CI で多用すると API トークン費用が別途発生します。処理量が多い場合は Routines のプランアップグレードと CI 利用の費用を比較してから選定するのが賢明です。

コスト試算の考え方

Routines は「1 日◯回までは固定料金で使える」サブスクリプション課金、Headless モードは「実行ごとに入出力トークン量で課金」の従量課金です。簡単な目安として、毎朝 1 回・週 5 営業日・1 回あたりトークン量がそれほど大きくないジョブなら Routines が圧倒的に安く済みます。一方、PR が日に何十件も飛んでくる活発なリポジトリで全件 AI レビューを通したい、あるいはモノレポを丸ごと監査するような重いジョブを CI に組み込む場合は、Headless モードを API キー経由で動かしたほうが上限に縛られず柔軟です。実運用では「定期巡回は Routines、PR 駆動レビューは Headless+CI」というハイブリッド構成が最もコスパに優れます。

移行のしやすさ

4 方式は排他ではなく段階移行できる点も重要です。まずは /loop でセッション内の手動繰り返しから始め、定型化できたらデスクトップ Schedule、PC を閉じても動かしたくなったら Routines、チームに展開する段階で Headless+CI へ昇格する、という流れが自然な階段になります。各段階のプロンプトと指示書は再利用できるので、最初から完成形を狙わず、いちばん手軽な /loop で「自動化に向く形」を見つけてから上位方式に持ち上げると失敗が少なくなります。

セキュリティと運用の注意点

確認なし実行のリスクを理解する

Routines は起動するとすべての操作が確認プロンプトなしで実行されます。インタラクティブモードで毎回確認されていた「このファイルを編集してよいですか？」という操作が、Routines では自動承認されます。公式ドキュメントには次のように記載されています。

「Routines 実行時、コネクタに含まれるツールはすべて承認なしで使用される」
— [src: https://code.claude.com/docs/en/routines.md]

対策として CLAUDE.md で操作スコープを明示的に制限し、コネクタ（MCP）は必要最小限のツールのみ許可する設定が推奨されます。外部サービスとの連携コネクタは「読み取り専用」から始め、書き込み権限は十分なテスト後に付与するアプローチが安全です。

運用で押さえておくべき制限事項

• 最短間隔は 1 時間: スケジュール型 Routines は 1 時間未満の間隔は設定不可
• 7 日間未使用で自動非活性化: 設定した Routines は 7 日間起動されないと自動でオフになる
• Free プランは利用不可: Routines は Pro 以上が必要
• 現在はリサーチプレビュー: 仕様変更の可能性があり、本番クリティカルな用途での使用には注意が必要

チーム運用のベストプラクティス

個人アカウント紐付けの Routines をチームに展開したい場合、Routines の Git イベントトリガーを共有リポジトリに設定するか、CI 環境上の Headless モードに切り替えてリポジトリ管理する設計が現実的です。将来的にチーム共有機能が追加される可能性はありますが、2026 年 5 月時点では未対応です。チームに広げる前段で、誰がどの自動化を所有しオンコール対応するのかを決めておくと、休暇や離職時の引き継ぎコストを抑えられます。

監査ログと再現性の確保

自動化が増えてくると「なぜこの変更が入ったのか」を追跡できる仕組みが不可欠になります。Routines は実行履歴と各ステップのツール呼び出しが管理画面に残るため、まずはこのログを定期的にエクスポートしておくのが最低限の防衛線です。Headless モードを CI で動かす場合は、--output-format json で得た構造化ログをジョブのアーティファクトとして保存し、後から差分原因を辿れるようにしておきましょう。再現性を高めるには、プロンプトと CLAUDE.md の内容をリポジトリにコミットしておき、いつ・どのバージョンで動いたかをコミットハッシュで特定できる状態に保つのが鉄則です。

出典

• Introducing routines in Claude Code — Anthropic 公式ブログ（2026-04-14）
• Automate work with routines — Claude Code 公式ドキュメント
• Headless mode — Claude Code 公式ドキュメント
• Claude Code ドキュメントインデックス