Zenn
tacomsテックブログPublicationへの投稿
🖌️

Claude Code ActionとGitHub Appで実現するリポジトリ横断のAIコードレビュー

Masato Inoue @ tacoms CTO
に公開
GitHub Actions
Claude
Claude Code
Claude Code Actions
tech

tacomsの開発組織では昨年末から、DevinやCursorを全員に配布するなど積極的にAIツールを導入してきましたが、最近はClaude Codeが本当に優秀ですね！

そんなClaude CodeがGitHub上で使えるClaude Code Actionも話題になっていますが、実際に使ってみる中でちょっとした課題があったので、Tips的な記事を書いてみました。

https://zenn.dev/tacoms/articles/efeb008ce810f3

Claude Code Actionが便利！

Claude Code ActionとはClaude CodeをGitHub Actionsから呼び出せるサービスで、GitHubワークフローからClaude Codeを利用できるものです。
Code RabbitのようなAIコードレビューから、Devin・GitHub Coding agentのようなAIによるPR作成なども実現できるため、使い方によっては様々な可能性を秘めたサービスだと感じています。

なお、詳しい話は公式Docを見ていただくのが一番良いです！

導入方法は非常に簡単で、Claude Codeを手元のPCで使っている方であれば、以下のコマンドを実行するだけでファイルが自動生成されます。
/install-github-app

上記コマンドで作成したActionsファイルがリポジトリにマージされれば、そのリポジトリの中におけるイシューやPRのページで @claudeするだけで、Claudeが良い感じに答えてくれます。
（以下はイシューを分析して実行計画を作ってくれている例）

この設定はほんの数分で完了するため、導入が非常に手軽です。ぜひ試してみてください。
複雑なプロンプトや設定なしでも、コードレビューにおいて有用な情報を提供してくれます。

こんな雑なコメントでも網羅的にレビューしてくれる

実際に使ってみて感じた課題

前述の通り、導入も容易ですし、複雑なプロンプトなしでも精度の高いコードレビューを提供してくれます。
ただし、あくまで同一リポジトリ内のコードやドキュメントを参照したレビューのみで、他のリポジトリを参照したいケースでは権限の問題でうまく動作しません。
当然のことですが、Actionsファイル内で参照できるGITHUB_TOKENは他リポジトリにはアクセスできない権限設定になっています。

https://docs.github.com/ja/actions/security-for-github-actions/security-guides/automatic-token-authentication

これはリポジトリ構成にも関連しますが、よほど完全なモノレポでない限り、レビューする際に複数のリポジトリを参照してレビューする機会があると思います。以下は代表的なケースです。

  • APIスキーマが別リポジトリにあるケース
  • インフラ・データベースの仕様ドキュメントが別リポジトリにあるケース
  • 共通ライブラリが別リポジトリにあるケース
  • フロントエンド・バックエンドの実装が分かれているケース
  • マイクロサービスなど、Aというリポジトリに依存するサービスのリポジトリが分かれているケース
  • GitHub上でPRDやADRなどを管理しており、作業リポジトリとは別リポジトリにあるケース

上記を踏まえて、精度の高いAIレビューを実現するためには、リポジトリ横断でAIが確認できる状態にする必要があると考えました。

GitHub App × Claude Code Actionで他リポジトリも参照できるようにする

標準のGITHUB_TOKENではなく、GitHub Appを作成し適切なリポジトリの権限を付与したトークンをClaude Code Actionに渡し、Claude Code Actionの内部でghコマンドを許可することで、他リポジトリの参照を出来るようにしました。

具体的な手順

1. GitHub Appの作成と設定

# Repository permissions (必要最小限)
Repository permissions:
  Contents: Read                    
  Issues: Read                     
  Metadata: Read                    
  Pull requests: Write
  • 参照が必要なリポジトリを選択してAppをインストールします。
  • Github Actionsを起動するリポジトリにおいて、GitHub Appsがインストールされてるか確認しましょう

2. GitHub Actionsワークフローファイルの設定例

以下のような流れで設定します。

  • 1）Claude Code Actionで使用するGitHubトークンを、GitHub Appのトークンに切り替えます。
  • 2）Bash(gh:*)を許可

MCPではなくghコマンドを許可した上で、プロンプトの指示に含めたところ、適切に参照してくれました

  • 3）関連するファイルがあれば参照するようプロンプトに含める（以下は参考例）
name: Claude Code

on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
  issues:
    types: [opened, assigned]
  pull_request_review:
    types: [submitted]

jobs:
  claude:
    if: |
      (github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude')) ||
      (github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude')) ||
      (github.event_name == 'pull_request_review' && contains(github.event.review.body, '@claude')) ||
      (github.event_name == 'issues' && (contains(github.event.issue.body, '@claude') || contains(github.event.issue.title, '@claude')))
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 1

      - name: Generate GitHub App token
        id: generate-token
        uses: actions/create-github-app-token@v1
        with:
          app-id: ${{ secrets.GITHUB_APP_ID }}
          private-key: ${{ secrets.GITHUB_APP_PRIVATE_KEY }}
          # 参照が必要なリポジトリ一覧を追記
          repositories: |
            example-api-schema
            example-frontend
            example-terraform
            example-backend-service-1
  
      - name: Run Claude Code
        id: claude
        uses: anthropics/claude-code-action@beta
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          # GitHub Appのトークンを利用
          github_token: ${{ steps.generate-token.outputs.token }}
          allowed_tools: "ReadFile,Edit,Replace,CreateFile,Bash(gh:*)"
          custom_instructions: |
            あなたはフルスタック開発チームのシニアエンジニアです。
            このバックエンドAPIの変更をレビューする際、必要に応じて関連リポジトリのファイルを参照し整合性を保った包括的なレビューを提供してください。

            ## 異なるリポジトリへのアクセスパターン
            - 異なるリポジトリに対してのアクセスは、`gh`コマンドを使用してください。
            - 例） `gh repo view example-api-schema`
          
            ## 関連リポジトリと参照すべきファイル

            ### フロントエンド
            - リポジトリ: `example-frontend`
            - 本リポジトリとの関連性
              - APIクライアントとしてのフロントエンド
            - 重要ファイル:
              - `src/types/api.ts` - API型定義
              - `src/services/api.ts` - API呼び出し関数

            ### APIスキーマ
            - リポジトリ: `example-api-schema`
            - 本リポジトリとの関連性
              - APIスキーマの定義
            - 重要ファイル:
              - `openapi.yaml` - OpenAPI仕様

            ### 他のバックエンドサービス
            - リポジトリ: `example-backend-service-1`
            - 本リポジトリとの関連性
              - XXXのタイミングで呼び出すバックエンドサービス
            
            ### インフラ定義
            - リポジトリ: `example-terraform`
            - 本リポジトリとの関連性
              - インフラの定義
            - 重要ファイル:
              - `prd/xxxxx/xxxxx.tf` - インフラの定義
            
            ## 追加でレビューしてほしい観点
            標準的なレビュー観点に加えて、以下の観点を追加でレビューしてください。

            1. **API実装と仕様の整合性チェック**
               - 実装されたAPIが既存スキーマ定義と整合しているか（`example-api-schema`の`openapi.yaml`と比較）
               - 破壊的変更がフロントエンドに与える影響の評価（`example-frontend`の`src/types/api.ts`、`src/services/api.ts`を参照）
               - ビジネスロジックとAPI設計の意図が一致しているかの検証

            2. **バックエンドサービス間連携**
               - 他のバックエンドサービスとの依存関係（`example-backend-service-1`との連携確認）
               - サービス間通信のデータ形式統一性
               - 分散システムにおけるデータ整合性

            3. **インフラストラクチャ整合性**
               - インフラ定義との整合性（`example-terraform`の設定確認）
               - 環境変数や設定値の依存関係
               - デプロイメント設定への影響

            4. **エラーハンドリング**
               - フロントエンドでのエラー処理との整合性
               - エラーレスポンス形式の統一性
               - 他サービスとのエラー伝播パターン

3. PR上でClaude呼び出し
設定がうまくいっていれば別リポジトリの情報踏まえてレビューしてくれるはずです
これにより、他リポジトリを踏まえた上でClaudeがコードレビューしてくれるようになりました！

実際に導入してみた効果

まだ試験導入の段階ですが、この辺りは問題なく行えてそうでした。期待したい効果に合わせて、プロンプトを調整することでより精度の高いレビューが実現できると思います。

API実装と仕様の整合性チェック

  • 破壊的変更がフロントエンドに与える影響を事前に検知
  • ビジネスロジックとAPI設計の意図の一致を確認

インフラ・データベースドキュメントを踏まえたレビュー

  • example-terraformリポジトリのインフラ定義を参照した上で環境変数や設定値の依存関係を考慮したレビュー

共通ライブラリ・実装参照の課題解決

  • 共通ライブラリにある実装を確認してコードの重複を検出
  • 共通ライブラリ内部の実装を確認した上で、関数などを正しく利用できているかを確認

リポジトリ間の依存関係の確認

  • フロントエンドとバックエンドの互換性を包括的にレビュー
  • AサービスからBサービスへの連携など、サービスの依存関係を踏まえたレビュー

注意点

GitHub Appの権限について

  • Claude上でコードを編集してもらい再びPRを作成してもらうためには、Contents: Writeなどの追加権限が必要になります。
  • 必要に応じてこの権限を付与しても良いですが、GitHub Appに紐づくすべてのリポジトリのWrite権限を渡すのは権限が広すぎるため注意が必要です。
  • WorkflowファイルをWrite用とRead用で分けて@claudコマンドを分割しても良いですし、同じWorkflowファイルでStepを分ける形でも良いかもしれません

Claude Code Actionにおけるデフォルトのallowed_tools/disallowed_toolsについて

  • 内部の実装を確認したところ、デフォルトでは以下のようになっているようです
const BASE_ALLOWED_TOOLS = [
  "Edit",
  "MultiEdit",
  "Glob",
  "Grep",
  "LS",
  "Read",
  "Write",
  "mcp__github_file_ops__commit_files",
  "mcp__github_file_ops__delete_files",
  "mcp__github_file_ops__update_claude_comment",
];
const DISALLOWED_TOOLS = ["WebSearch", "WebFetch"];

https://github.com/anthropics/claude-code-action/blob/b10f287695caa3a755ab23184c63137ab72b7843/src/create-prompt/index.ts#L25

  • デフォルトでBashなどは許可されていないですし基本的なリスクは考慮されてるかと思いますが、独自でallowed_toolsをカスタマイズした際には注意する必要がありそうです。

今後の活用に向けて

今回の記事ではPRのレビューというスコープで複数リポジトリを参照するメリットをご紹介しましたが、レビュー以外でも活用の幅があると思います。
また、custom_instructionsのプロンプトに例を示しましたが、他リポジトリを横断して特に注力してレビューしてほしいポイントをプロンプトに含めることをお勧めします。
Claude Code ActionとGitHub Appトークンの活用により、AIレビューの精度が格段に向上したと実感しています。

AIにより開発スピードが速くなればなるほど、レビューがボトルネックになることは明白です。日々新しいツールに触れながら、開発組織としてのベストプラクティスを探究していきたいと思います！！！

tacomsテックブログ
tacomsテックブログPublication

株式会社tacomsメンバーのテックブログです！ 各メンバーの日々の学びから会社の取り組みまで掲載していきます！

Discussion