Claude Code自動化スクリプト3パターン

Claude Codeで自動化スクリプトを作りたいけれど、どこから手をつければいいか迷っていませんか。

結論から言うと、claudeコマンドに-pフラグを1つ足すだけで、対話なしのスクリプト実行ができます。あとはシェルスクリプトやCI/CDの設定ファイルに組み込むだけです。

この記事では、以下の内容を解説します。

• Claude Code自動化スクリプトの基本的な仕組み
• スクリプトを動かすための3ステップ
• 実際に使える自動化の3パターン
• 実際にハマったポイントと対策

Claude Code自動化スクリプトとは何か

「対話モード」と「スクリプトモード」の違い

Claude Codeには大きく2つの使い方があります。普段よく使う対話モードと、今回解説するスクリプトモードです。

対話モードは、ターミナル上でClaudeと会話しながら作業を進めるスタイルです。「このファイルを修正して」「テストが通るか確認して」というように、やり取りしながら作業を進めます。人がその場にいる前提で動くため、細かい確認を挟みながら慎重に進められるのが特徴です。

スクリプトモードは、プロンプトをあらかじめ渡して、Claude Codeに一気に処理させる使い方です。具体的には、claude -p "プロンプト"というコマンドを使います。人が画面の前にいなくても動くため、cron（定期実行）やCIパイプラインへの組み込みが可能です。

2つの違いをまとめると、次のようになります。

• 対話モード：人が画面の前にいる前提。確認しながら進める
• スクリプトモード：人がいなくても動く。自動化・バッチ処理向け

自動化スクリプトとして使いたい場合は、スクリプトモードが必須の知識になります。

どんな場面で使われているか

Claude Codeの自動化スクリプトは、すでに様々な場面で活用されています。代表的な用途を3つ挙げておきます。

ひとつ目は、毎日のレポート自動生成です。ログファイルやCSVを読み込んで、日次サマリーをMarkdownやHTML形式で出力します。cronで毎朝7時に実行しておくだけで、手動作業がゼロになります。

ふたつ目は、CI/CDへのコードレビュー組み込みです。プルリクエストの差分を自動でClaude Codeに送り、コメントを取得します。GitHub Actionsなどと組み合わせることで、レビューの初動を自動化できます。

みっつ目は、コミット前チェックの自動化です。Gitのpre-commitフックからClaudeを呼び出し、コードの問題点を自動検出します。うっかりミスをコミット前に拾えるので、後から修正する手間が減ります。

いずれも「人が毎回やっていた繰り返し作業」を置き換えるイメージです。一度仕組みを作れば、あとはClaudeが回し続けてくれます。

Claude Code自動化スクリプトを作る3ステップ

Claude Codeをスクリプトとして動かすには、3つのオプションを理解するだけで十分です。難しいセットアップは不要で、claudeコマンドのオプションを組み合わせるだけで実現できます。

ステップ1：-pフラグで非対話モードに切り替える

最初に覚えるべきは、-pフラグです。このフラグを使うと、対話画面を開かずに1回だけ処理を実行して終了します。基本的な書き方は次の通りです。

claude -p "このファイルのバグを探して修正してください" --allowedTools "Read,Edit,Bash"

ポイントは、プロンプトをダブルクォートで囲んで-pの直後に渡すことです。これだけで、対話なしにClaudeが処理を実行してくれます。

また、CI/CDなどのスクリプト呼び出しでは--bareフラグも合わせて使うのがおすすめです。フック・スキル・MCPなどのローカル設定をスキップして、余計な処理が入らなくなります。

claude --bare -p "ファイルを要約してください" --allowedTools "Read"

シンプルなタスクほど--bareが有効で、実行速度も上がります。ローカル環境の設定に引っ張られずに動いてほしい場面では積極的に使いましょう。

ステップ2：--allowedToolsで使えるツールを絞り込む

スクリプトモードで動かすとき、Claude Codeが何のツールを使えるかを明示的に指定する必要があります。これが--allowedToolsオプションです。指定できる主なツールは次の通りです。

• Read：ファイルを読む
• Edit：ファイルを書き換える
• Bash：シェルコマンドを実行する
• Write：新しいファイルを作る

たとえば、ファイルを読んで要約するだけのスクリプトなら--allowedTools "Read"だけでいいです。ファイルを修正するなら--allowedTools "Read,Edit"を渡します。

セキュリティの観点から、使わないツールは渡さないのが原則です。Bashを許可するとシェルコマンドが走るため、自動化スクリプトの中で予期しない動作が起きるリスクが上がります。

Bashツールを特定のコマンドだけに絞りたい場合は、カッコで制限できます。

--allowedTools "Read,Bash(git diff *),Bash(git status *)"

これで、git関連コマンドだけを許可するBashツールとして機能します。必要最小限のツールだけを指定する習慣をつけておくと、スクリプトの動作が予測しやすくなります。

ステップ3：--output-format jsonで出力を他スクリプトと連携する

Claudeの出力をそのままテキストとして受け取るだけでなく、JSON形式で受け取ることもできます。これにより、他のシェルスクリプトやPythonスクリプトとのパイプ連携が格段にしやすくなります。

claude -p "このプロジェクトの概要を教えて" --output-format json

JSONの出力には、Claudeの返答テキストのほかに、セッションID・使用トークン数・実行時間などのメタデータが含まれます。jqコマンドと組み合わせると、必要な部分だけを取り出せます。

result=$(claude -p "レポートを生成して" --output-format json)
text=$(echo "$result" | jq -r '.result')

さらに、JSON Schemaを使って出力の形式を指定する--json-schemaオプションもあります。関数名の一覧を配列で取得したいなど、構造化されたデータが必要な場面で活躍します。

3ステップをまとめると、「-pで非対話実行 → --allowedToolsでツール指定 → --output-format jsonで出力を整形」という流れです。

この3つを組み合わせるだけで、実用的な自動化スクリプトが完成します。

実際に動いているClaude Code自動化スクリプト3パターン

Claude Code自動化スクリプトの具体的な使い方を3パターン紹介します。「これなら自分の業務にも使えそう」というイメージを持てるよう、実用的な例を選びました。

パターン1：定型レポートの毎日自動生成

毎日同じ形式でレポートを作る作業は、自動化の恩恵が大きい典型例です。ログファイルやCSVを読み込んでサマリーを生成するスクリプトを一度作れば、あとはcronに任せられます。たとえば、エラーログを毎朝確認して日次レポートを作るスクリプトはこう書けます。

#!/bin/bash
DATE=$(date +%Y-%m-%d)
REPORT_FILE="report_${DATE}.md"

cat logs/error_${DATE}.log | claude --bare -p \
  "このエラーログを分析して、件数・傾向・注目すべきエラーを日本語でまとめてください" \
  --allowedTools "" \
  > "$REPORT_FILE"

echo "レポートを生成しました: $REPORT_FILE"

catでファイルをパイプするとき、ファイルサイズが10MBを超えると処理できない点に注意が必要です（詳しくは後述）。大きなログファイルを扱う場合は、tail -n 1000などで行数を絞り込んでから渡すのが現実的な対処法です。cronへの登録はcrontab -eで次の1行を追加するだけです。

0 7 * * * /path/to/daily_report.sh

毎朝7時に自動実行されるようになります。一度設定したら、あとは確認するだけで済みます。

パターン2：コードレビューをCIパイプラインに組み込む

プルリクエストのたびにコードレビューをClaudeにやってもらうパターンです。GitHub Actionsと組み合わせると、プルリクエストを出した瞬間にAIのコメントが届くようになります。

基本的な仕組みはシンプルで、git diffの出力をClaudeに渡してレビューを依頼します。

gh pr diff "$PR_NUMBER" | claude --bare -p \
  "このコード差分をレビューしてください。セキュリティの問題・バグのリスク・改善点を指摘してください" \
  --allowedTools "" \
  --output-format json | jq -r '.result'

この出力をGitHubのPRコメントとして自動投稿する流れにすると、レビュー依頼から初動コメントまでが自動化されます。AIのレビューで全部が解決するわけではなく、あくまで人間のレビューを補助するためのものです。「明らかなミスを先に拾う」という役割が向いています。

実際にこのパターンを試した感想としては、単純なタイポや命名の一貫性チェックは精度が高く、人間が時間をかけてやることではないな、と感じました。一方で、設計上の判断が必要な部分はやはり人が見る必要があります。うまく役割分担することが大事です。

パターン3：コミット前のチェックを自動化する

Gitのpre-commitフックからClaudeを呼び出して、コミット前に問題を自動検出するパターンです。うっかりミスをコミット前に拾えるので、後から修正する手間が減ります。.git/hooks/pre-commitファイルを作って実行権限を付けます。

#!/bin/bash
STAGED_FILES=$(git diff --cached --name-only --diff-filter=ACMR | grep -E '\.(py|js|ts)$')

if [ -z "$STAGED_FILES" ]; then
  exit 0
fi

DIFF=$(git diff --cached -- $STAGED_FILES)

RESULT=$(echo "$DIFF" | claude --bare -p \
  "このコードの変更を確認して、明らかなバグや問題があれば報告してください。問題なければ'OK'とだけ答えてください" \
  --allowedTools "")

if echo "$RESULT" | grep -qi "ok"; then
  echo "✅ Claude Codeのチェックを通過しました"
  exit 0
else
  echo "⚠️ Claude Codeがコミット前に問題を検出しました："
  echo "$RESULT"
  echo ""
  echo "問題なければ --no-verify を付けてコミットしてください"
  exit 1
fi

このスクリプトは、ステージングされたPython・JavaScript・TypeScriptファイルの差分をClaudeに渡してチェックします。「OK」が返ってきたらコミットが通り、問題を指摘された場合はコミットが止まります。強制したくない場合はexit 0に統一して、出力を参考にするだけにするのもありです。チームの進め方に合わせて柔軟に調整してください。

Claude Code自動化スクリプトのハマりパターン

ツールの許可設定を忘れると何も実行されない

スクリプトモードで最初にやりがちなミスが、--allowedToolsを指定し忘れることです。対話モードではClaude Codeが確認を取りながらツールを使いますが、スクリプトモードでは許可されていないツールを黙って使わずに処理を続けます。

たとえば、「このファイルを読んで要約して」というプロンプトを送っても、Readツールを許可していなければClaudeはファイルを読まずにデフォルトの応答を返して終わります。「なぜか期待した出力が出ない」「何も処理されていないようだ」というときは、まず--allowedToolsの設定を確認してください。

デバッグのコツは、--verboseフラグを付けて実行することです。どのツールが呼ばれたか（または呼ばれなかったか）の詳細が出力されるので、問題の特定が早くなります。これを付けるだけで、「あ、Readが呼ばれていない」とすぐ気づけます。

stdinに10MBの上限があってファイルが読めなかった

パイプでデータをClaudeに渡すとき、stdinは10MBまでという制限があります。ログファイルを丸ごと渡そうとして、サイズが上限を超えて処理が止まるというパターンにハマりました。エラーメッセージが曖昧で、最初は原因がわからず混乱しました。

対処法はシンプルで、渡すデータを事前に絞り込むことです。

• 直近1,000行だけを渡す：tail -n 1000 logfile.log | claude ...
• エラー行だけを抽出する：grep "ERROR" logfile.log | claude ...
• ファイルパスをプロンプトに書いてClaudeに読ませる：Readツール経由なら10MB制限の影響を受けない

特に3つ目の発想の転換が効きます。「ファイルの中身をパイプで渡す」のではなく、「ファイルのパスをプロンプトに書いてClaudeに読ませる」という考え方です。大きなファイルを扱う場合はこちらを標準にしておくと、制限にハマりにくくなります。

--bareを入れ忘れると予期しない動作になる

CI/CDや定期実行スクリプトで動かすとき、--bareを忘れると、ローカルのCLAUDE.mdやhookが読み込まれて、想定外の動作になることがあります。たとえば、プロジェクトのCLAUDE.mdに「変更前に必ず確認を取る」という指示が書いてある場合、スクリプトモードでも影響を受ける可能性があります。

--bareを付けると、hook・スキル・plugin・MCPなどのローカル設定を一切読まずに実行するため、スクリプトの動作が安定します。

ローカルで実行するスクリプトは--bareなしでも動きますが、CI環境など「ローカル設定が存在するかどうかわからない」場所で動かす場合は--bareを付けるのが原則です。「環境依存の動作を排除したい」という場面では必ず使う、と覚えておけば問題ありません。Claude Code CLAUDE.mdの書き方の記事と合わせて読むと、CLAUDE.mdがどう影響するかがより理解しやすくなります。

Claude Code自動化スクリプトに関するよくある質問

Claude Code自動化スクリプトについて、よく聞かれる質問に答えます。

Q：Windowsでも自動化スクリプトは動きますか？

A：動きます。ただし、シェルスクリプト（.sh）はWindows標準環境では動かないため、WSL2（Windows Subsystem for Linux）やGit Bashを使う必要があります。PowerShellからclaudeコマンドを呼び出すことも可能ですが、コードの可搬性を考えると、WSL2上で動かすのがおすすめです。CI/CD環境（GitHub Actionsなど）はLinuxベースで動くため、Windowsローカルでの環境差異を気にする必要はありません。Claude CodeをWindowsにインストールする方法も参考にしてください。

Q：無料プランのままスクリプト実行はできますか？

A：自動化スクリプトの実行自体はプラン問わず可能ですが、自動化で使うトークン量はあっという間に増えます。無料枠のまま定期実行スクリプトを動かすと、数日で上限に達することが多いです。cronでの定期実行やCIへの組み込みをメインにしたい場合は、有料プランを前提に考えるのが現実的です。料金プランの詳細はClaude Code料金プランを比較をご覧ください。

Q：スクリプトがエラーになったときの確認手順は？

A：まず--verboseフラグを付けて実行してみてください。どのツールが呼ばれたか、どの段階で止まったかが出力されます。次に確認するのは--allowedToolsの設定です。必要なツールが許可されているかを見直してください。それでも解決しない場合は、echo $?で終了コードを確認します。0なら正常終了、1以上ならエラーです。Claude Codeエラー対処法の記事も参考になります。

まとめ

Claude Code自動化スクリプトの基本は、-p・--allowedTools・--output-format jsonの3つのオプションです。

• -p：非対話モードで1回だけ実行する
• --allowedTools：使えるツールを明示的に指定する
• --output-format json：他のスクリプトと連携できる形式で出力する

3パターンの活用例（定型レポート生成・CIコードレビュー・コミット前チェック）はどれも、「毎回手でやっていた作業」を置き換えるものです。一度動く仕組みを作ってしまえば、あとはClaudeが粛々と動き続けます。

ハマりポイントも事前に知っておけば怖くありません。ツール許可の設定漏れ・stdinの10MB上限・--bareの忘れ、この3つを頭に入れておくだけで、デバッグ時間が大幅に変わります。

まず試すなら、cat ファイル名 | claude --bare -p "このファイルを要約して" --allowedTools ""の1行から始めてみてください。思ったよりシンプルに動くはずです。

Claude Codeの使い方全体を学びたい方は、Claude Code 使い方｜初心者向け3ステップ入門もあわせてどうぞ。業務効率化の実例についてはClaude Code業務効率化の実例をご覧ください。