Claude CodeをCIで動かすときに必要なフラグは何ですか？

-p（または--print）フラグが必須です。これを付けると非インタラクティブモードで動作し、結果を標準出力に返してプロセスを終了します。付けないとパイプラインがハングします。

Claude Codeが生成したコードを同じセッションでレビューさせるのは問題ですか？

問題があります。コード生成時の思考パターンが残っているため、自分で作った問題を見逃す傾向があります。別のClaudeインスタンス（独立したセッション）でレビューさせることを推奨します。

プルリクエストに同じコメントが重複して付かないようにするにはどうすればよいですか？

再レビュー時に前回のレビュー結果をコンテキストに含め、「未解決の問題のみ報告する」と指示します。差分コミットのみを対象にする設定も有効です。

Claude CodeをCI/CDパイプラインに組み込む実践ガイド

結論

Claude CodeをCI/CDパイプラインに組み込むと、プルリクエストのコードレビューとテスト生成が自動化できます。導入に必要な変更は最小限で、-pフラグを付けた実行コマンドとCLAUDE.mdへのプロジェクト設定の追記が中心です。

ただし設計を間違えると、パイプラインがハングしたり、同じ指摘が何度も付いたり、生成したコードの問題を見逃したりします。この記事では、実際の導入で起きる問題とその解決策を具体的に説明します。

なぜCIにClaudeを入れると価値があるか

コードレビューには人間のエンジニアが時間をかけています。特定のパターン確認（セキュリティの穴・ハードコードされた認証情報・エラー処理の漏れ）のような定型的なチェックは、AIに任せることで人間がより価値の高い判断に集中できます。

テスト生成も同様です。「この関数のエッジケースをテストしてほしい」という依頼を、マージのたびに自動で行えます。

CI/CDへの統合で自動化できる主な用途は次の通りです。

用途	具体的な内容	適切なAPI
プルリクエストレビュー	マージ前のセキュリティ・バグ確認	同期API（開発者が待つため）
テスト生成	新機能に対応したテストケースの生成	同期API（マージ前に必要）
技術的負債レポート	コードベース全体の問題点の洗い出し	バッチAPI（翌朝確認で十分）
夜間品質チェック	週次・夜間の定期分析	バッチAPI（非リアルタイム）

CI環境で必須の-pフラグ

Claude Codeを通常どおり起動すると、対話型のインターフェースが立ち上がります。CI環境では誰も操作できないため、プロセスが応答待ちのまま止まってしまいます。

解決策は-pフラグ（または--printフラグ）の追加です。

# NG: パイプラインがハングする
claude "このプルリクエストのセキュリティ問題を確認してください"

# OK: 結果を標準出力に返してプロセスを終了する
claude -p "このプルリクエストのセキュリティ問題を確認してください"

-pフラグを付けると、Claude Codeは非インタラクティブモードで動作し、応答を標準出力に返した後に自動終了します。

構造化出力が必要な場合

レビュー結果をプログラムで処理してPRコメントに投稿したい場合は、JSON出力を強制できます。

claude -p "このコードをレビューし、問題点をJSON形式で返してください" \
  --output-format json \
  --json-schema review_schema.json

これにより機械読み取り可能な形式でレビュー結果を取得し、GitHub Actions等から自動でPRコメントとして投稿できます。

CLAUDE.mdでCIの動作を制御する

Claude CodeはCIから呼ばれるときも、プロジェクトのCLAUDE.mdを読み込みます。ここにプロジェクト固有のレビュー基準を書いておくことで、Claudeが「このプロジェクトでは何を重視すべきか」を知った状態でレビューします。

CIレビュー向けCLAUDE.mdの書き方

具体的なバグカテゴリを定義する

「問題を見つけてください」では、Claudeが何でも指摘してしまいノイズが増えます。報告すべき問題と報告しなくてよい問題を明示します。

## コードレビュー基準

### 必ず報告する問題
- SQLインジェクション・XSSの可能性
- 認証情報のハードコード（APIキー・パスワード）
- 未処理の例外・エラーハンドリングの欠如
- 競合状態（Race Condition）

### 報告しない問題
- スタイルの好みの差（変数名の命名規則は別途ESLintが担当）
- ローカルに固有のパターン（このコードベースでの意図的な設計）
- コメントの文体

この基準を書くことで、誤検知が大幅に減ります。「保守的に」「確信があるものだけ」のような曖昧な指示は効果がなく、具体的なカテゴリ定義の方が精度向上につながります。

テスト生成の基準を書く

既存のテストとの重複を避けるため、テストの基準・命名規則・利用できるフィクスチャも記載します。

## テスト生成ルール

- テストファイルの命名: `*.test.ts`（コンポーネントと同じディレクトリ）
- 使用フレームワーク: Jest + React Testing Library
- モックの使い方: `src/test/mocks/` にある共通モックを優先
- カバーすべきケース: ハッピーパス・空入力・APIエラー・ローディング状態
- 既存テストとの重複は生成しない

重複コメントを防ぐ設計

プルリクエストに新しいコミットが積まれるたびにレビューを再実行すると、同じ問題が何度もコメントされてしまいます。開発者にとってこれは大きなノイズになり、AIレビューへの信頼を下げます。

解決策: 前回のレビュー結果をコンテキストに含める

再レビューの指示例:

「このプルリクエストのコードをレビューしてください。

前回のレビュー結果（2024-06-04 14:00時点）:
- L45: SQLインジェクションの可能性 → 未解決
- L78: ハードコードされたAPIキー → 開発者が修正済み
- L102: エラーハンドリング欠如 → 未解決

今回のレビューでは:
1. 前回指摘した未解決の問題が修正されたかどうかの確認
2. 今回の差分コミットで新たに追加された問題の検出

上記以外の問題（前回指摘済みで既解決のもの）は報告不要です。」

これにより、新しいコミットで修正された問題は「解決済み」と認識し、未解決の問題と新しい問題だけが報告されます。

テスト生成の品質を上げるコンテキスト設計

「テストを生成してください」とだけ伝えると、既存のテストと重複したケースや、このプロジェクトでは使えないAPIを使ったテストが生成されることがあります。

効果的なテスト生成プロンプトには次の要素が必要です。

テスト生成の指示例:

「`src/components/OrderForm.tsx`のテストを生成してください。

コンテキスト:
- 既存のテストファイル: `src/components/OrderForm.test.tsx`（添付）
- 既にカバーされているケース: 正常送信・バリデーションエラー表示

生成してほしいテスト:
- APIエラー時のエラーメッセージ表示
- ローディング状態のスピナー表示
- 在庫切れ商品の注文ブロック処理

使用できるモック: `src/test/mocks/api.ts`の`mockOrderAPI`関数
使用するフレームワーク: Jest + React Testing Library

既存のテストファイルをコンテキストとして提供することで、カバレッジの抜け穴だけを補完するテストが生成されます。

生成コードのレビューに独立したインスタンスを使う

「Claude Codeがコードを書いて、同じセッションでそのコードをレビューする」という使い方は精度が落ちます。コード生成時の推論過程が記憶として残っているため、自分の判断ミスを見つけにくくなります。

これは人間でも同じです。自分で書いたコードを直後にレビューするより、翌日冷静な目で見た方がバグを発見しやすいのと同じ原理です。

推奨する2段階設計

生成インスタンス: コードを書く
独立レビューインスタンス: 前のセッションの文脈を持たず、コードと元の要件だけを見てレビューする

CIパイプラインでこれを実現するには、コード生成と最終レビューを別のclaude -p呼び出しとして設計します。前の呼び出しのセッションIDを渡さないことで、完全に独立した視点からのレビューになります。

この独立インスタンスのレビューはマルチエージェント設計でいうサブエージェントの独立実行と同じ考え方です。レビュー結果をJSON形式で取得してシステムに連携する方法はClaudeのJSONスキーマ構造化出力で詳しく解説しています。

同期APIとバッチAPIの使い分け

Claude CodeがCIで呼ぶのは主に同期API（即時応答）ですが、メッセージバッチAPIという選択肢もあります。

判断基準	同期API	バッチAPI
開発者がマージを待っているか	必要	不要
処理完了が今すぐ必要か	必要	不要
コスト	通常料金	50%削減
処理時間保証	あり（秒〜分）	なし（最大24時間）

具体的な判断は次のようになります。

同期APIを使うべき場合

プルリクエストのマージ前チェック（開発者が結果を待つ）
手動トリガーのコードレビュー

バッチAPIを使うべき場合

夜間に全ファイルをスキャンする技術的負債レポート
週次のセキュリティ監査
大量コミットの一括分析（翌朝確認でよい場合）

「バッチAPIは処理が終わったらポーリングすれば同期っぽく使える」という考え方は誤りです。24時間かかる可能性があるサービスにSLAを求めることはできません。

セキュリティ上の注意点

CI環境でClaudeを使うとき、注意すべき点があります。

APIキーの管理: Claude CodeのAPIキーはCI/CDの環境変数として管理し、コードリポジトリには直接含めません。GitHub ActionsならSecretsに、GitLab CIならCI/CD Variablesに設定します。

コード外部送信の考慮: CI経由でコードをAnthropicのAPIに送信することになります。機密性の高いソースコード（自社のコアロジック・個人情報を含む処理）を扱う場合は、エンタープライズプランや適切なデータ処理契約の確認が必要です。最新の契約条件は公式サイトで確認してください。

アクセス権限の絞り込み: CIからClaudeに与えるアクセス権限（読み取り対象のファイル・実行できるコマンド）を最小限にします。全ファイルへの書き込み権限を与える必要はありません。

まとめ

Claude CodeをCI/CDに組み込む実践のポイントをまとめます。

-pフラグを必ず付ける。これがないとパイプラインがハングする
CLAUDE.mdに具体的なレビュー基準を書く。曖昧な「高精度で」より「SQLインジェクションを報告する」の方が効果的
再レビュー時は前回の結果をコンテキストに含め、重複コメントを防ぐ
テスト生成には既存テストファイルをコンテキストとして渡す
コード生成と最終レビューは別のインスタンスで行う
マージ前チェックは同期API、夜間バッチはバッチAPIで50%コスト削減

この設計を実装することで、エンジニアの手動レビュー時間を削減しながら、定型的なバグパターンの検出率を向上させられます。