AIによるコードレビューを自動化しよう

この章では、Claude Code ActionとレビューSkillsを組み合わせたAIレビューのCI/CD統合をハンズオン形式で学習します。これにより、機械的な指摘はAIに任せて人によるレビューが設計判断とビジネスロジックに集中できるプルリクエスト運用が構築できるようになります。

本章のハンズオンでは、Anthropic APIの利用料として 数百円程度 の従量課金が発生します（Anthropic Consoleでのクレジット購入は最低$5からで、残額は他の章でも利用できます）。料金の発生を避けたい場合は、実際に手を動かさず、本章を読んで仕組みを把握するだけでも構いません。

1. 本章の概要

1.1 本章の目的

これまでの章で、静的解析と自動テストを自動化しようでは機械的に拾える指摘の自動化を、GitHubで保護ブランチを設定しようでは人によるマージ前チェックを扱いました。両者の中間にあたる「AI による一次レビュー」を CI/CD パイプラインに組み込むと、命名規則や定型的な脆弱性のような「機械が見た方が速く正確な指摘」を AI に任せ、人によるレビューは設計判断とビジネスロジックの検討に集中できる運用が実現します。また、人が気付きにくい観点も AI が指摘するため、レビュー全体の網羅性が向上します。

本章では、Anthropic が公式に提供する Claude Code Action を GitHub Actions に組み込み、レビュー観点を Skills として管理することで、自チームの規約に沿った AI レビューが継続的に動く状態を目指します。

1.2 ハンズオンの流れ

サンプルリポジトリを作り、Claude Code Action を GitHub Actions に組み込んでプルリクエスト時に AI レビューコメントが自動で投稿される状態を作ります。次にコーディング規約を coding-standards Skill として書き出し、AI が自チームの規約に沿った指摘を返すよう精度を上げます。最後に Skills を改善するサイクルを回し、AI レビューがチーム資産として育つ運用の型を持ち帰ります。

1.3 事前準備

前提となる講座

この章では、以下の知識を前提としています。自信がない場合は先に関連講座を実施してみましょう。

必要なツール

この章では、以下のツールを使用します。まだインストールしていない場合は、リンク先の手順に沿って準備をお願いします。

必要なアカウント

この章では、以下のアカウントを使用します。まだ用意していない場合は、リンク先の手順に沿って準備をお願いします。

2. AIレビューが求められる理由

AIレビューは「便利だから入れる」というより、そもそも人だけで完結させると成立しにくい領域を補うために入れます。まず人だけでレビューを回したときに起きる課題を整理し、その上でAIが何を解決するかを確認します。

2.1 人が苦手とする領域

人だけでコードレビューを回すと、次のような領域で品質が安定しません。

細かいコーディング規約のチェック

コーディング規約は数十〜数百項目に及ぶことがあり、レビュアーが全項目を頭に入れておくのは現実的ではありません。命名規則やフォーマットの逸脱は「気づいた人が指摘する」形の運用に流れやすく、指摘漏れも重複指摘も発生します。集中力を保ち続ける必要のある領域なので、レビュアーの疲労や時間帯によって品質が左右されます。

スキルによるレビュー品質の差分

レビュアーの経験・得意分野・過去に携わってきたプロジェクトによって、指摘できる観点と見落とす観点が変わります。セキュリティに強い人であればSQLインジェクションの疑いを一次判定できますが、そうでない人が担当すると同じ観点が抜けます。結果として「誰がレビューするか」で本番に流れる品質が変動し、レビュー体制の再現性が確保できません。

レビュー着手までの待ち時間

レビュアーの手が空くまでプルリクエストが滞留し、開発者は次のタスクに移りにくくなります。1件あたりの待ち時間が数時間〜半日単位で積み上がると、指摘が届く頃には作業内容の記憶が薄れており、修正の効率も落ちます。レビュアー側にも「溜まった分をまとめて見る」プレッシャーがかかり、1件ごとの深さが浅くなりがちです。

2.2 AIの活用

上で挙げた課題は、AIレビューを組み合わせることで大部分を先回りできます。

コーディング規約のチェックは、規約をSkill（後述）としてAIに渡しておけば、AIが淡々と全項目を照合します。人が行うと疲弊する領域を、AIが体力を消耗せずに担当できます。

スキル差の問題は、AIに固定の観点セットを持たせておくことで「誰のプルリクエストであっても最低ラインの観点は同じ基準で入る」状態を作れます。人はその上で、自分の得意領域に集中して深いレビューを重ねられます。

待ち時間の問題は、AIをプルリクエスト作成と同時に自動起動することで解消できます。人がレビューに着手する頃には規約違反や定型的な指摘は既にAIから届いており、開発者は着手前に自己修正を進められます。

2.3 人とAIの役割分担

AIレビューを導入したら、次に決めておきたいのが「AIが見た方が速く正確なもの」と「人が見た方が価値があるもの」の切り分けです。この整理を先にやっておかないと、AIレビューは「もう1人の遅いレビュアー」になってしまいます。

人とAIの分担として望ましい形を下記にまとめました。

上段の「AI領域」は、レビュー観点をきちんと言語化してあればAIが漏れなく淡々と指摘してくれる領域です。下段の「人領域」は、プロジェクトの背景や過去の議論を踏まえた判断が必要で、AIに任せると精度が上がらないままSkillsが肥大化しがちです。

2.4 Claude Code Actionの位置づけ

本章で利用するClaude Code Actionについて、位置づけを整理しておきます。

Claude Code Actionとは

Claude Code Action は、Anthropicが公式に提供しているGitHub Appです。GitHub Actionsの中でClaudeを呼び出す仕組みで、プルリクエストやIssueに対するコメント投稿、PR内容の読み取り、コード修正の提案などができます。詳細はClaude Code Action（GitHub公式リポジトリ）に記載があります。

直接呼び出しとの違い

GitHub ActionsからAnthropic APIやAmazon Bedrockを直接呼び出してAIにレビューさせる構成も組めますが、その場合は認証・プルリクエストへのコメント投稿・レビューコメントの位置指定などを独自に実装する必要があります。

Claude Code Actionを使う一番の違いは、GitHubとの統合が最初から用意されている ことです。認証・PRコメントの投稿・レビューコメントの位置指定・Actionsワークフローからの起動が箱に入って揃っているので、間にAWS側の中継コンポーネントを挟む必要がなく、Actionsのワークフローを1つ用意するだけでAIレビューが動く状態になります。

逆に、GitHubと連動しない独自の処理として実装したい場合（例: 独自のワークフローに組み込む・レビュー結果を独自のダッシュボードに集約するなど）は、直接呼び出しの方が柔軟に設計できます。GitHub上で完結する自動レビューに寄せる場合はClaude Code Action、GitHub以外の連携を含めた独自ワークフローを組む場合は直接呼び出し、と使い分けます。

Claude Codeとの違い

Claude Code などのAIコーディングエージェントは、ローカルのターミナルで動かすCLIツールで、開発者が自分の手元で対話的にAIを使うためのものです。一方、Claude Code Action は、GitHub Actions上で動くGitHub Appで、プルリクエスト起点でClaudeを自動起動するためのものです。

Claude Code Actionは、コアで動くAIエージェントがClaude Codeと共通で、そこにGitHubに寄せた実行環境と自動起動の仕組みが加わったものです。ローカルで作業しながら相談したい場面はClaude Codeなどのローカル型のツール、プルリクエスト起点で自動レビューさせたい場面はClaude Code Action、と使い分けます。

また、課金モデルにも違いがあります。Claude Codeにはサブスクリプション（定額）で利用できるプランがあるのに対し、Claude Code Actionや直接呼び出しは基本的にトークン単位の従量課金です。同じ量のレビューを回した場合、後者の方が結果的に高く付くこともあるので、レビューの頻度と規模を踏まえて課金モデルの向き不向きを判断します。

3. Claude Code Actionの初期設定

Claude Code ActionはAnthropicのAPIを呼び出してClaudeを動かします。GitHub Actionsに組み込む前に、Anthropicのアカウントを作成し、クレジットをチャージし、GitHub Actionsから安全にAnthropic APIを呼び出せる状態にしておきます。

Anthropicは、GitHub Actionsからの認証方式として 静的なAPIキー方式 と OIDC（ワークロードIDフェデレーション）方式 の2つを提供しています。本章では、静的な機密情報を持ち回らなくて済む OIDC方式 を採用します。GitHub Actionsが発行する短命なOIDCトークンをAnthropicに送り、それと引き換えに短命なアクセストークンを受け取る仕組みなので、GitHub Secretsに長期の秘密情報を保管する必要がありません。

3.1 Anthropicアカウントの作成

OIDC連携の設定は、Anthropic Consoleというブラウザ管理画面で行います。まずはそのアカウントを作成します。既にAnthropicアカウントを持っている場合は、この手順はスキップして次の「使用クレジットの購入」に進んでください。

Anthropic Console にアクセスすると、「Claude Platform で開発する」画面が表示されます。「Googleで続行」または「メールで続ける」からアカウントを作成します。登録後、電話番号による本人確認が求められる場合があるので、SMSで届いた認証コードを入力してアカウントを有効化します。

サインアップが完了すると、Anthropic Consoleのダッシュボードに遷移します。ここまで到達すればアカウント作成は完了です。

3.2 使用クレジットの購入

Claude Code Actionは従量課金なので、実際にClaudeを呼び出すには、支払い情報を登録して事前にクレジットをチャージしておく必要があります。

サインアップ直後、または左メニュー「クレジット」→「資金を追加」から「使用クレジットを購入して開始する」画面に入ります。以下を入力します。

「クレジットを購入」をクリックしてチャージ完了です。ダッシュボード左メニュー「クレジット」欄にチャージした金額が反映されれば、Claude API呼び出しの準備が整った状態です。

3.3 OIDC連携の設定

GitHub ActionsからOIDC経由でAnthropic APIを呼び出せるようにするため、Anthropic Console側で以下の4つを登録します。

1. 発行者（Issuer）: どのIDプロバイダを信頼するかを登録する（GitHub ActionsのOIDC発行者URL）
2. フェデレーションルール: どのリポジトリ・ブランチ・イベントを受け入れるかの一致条件を設定する
3. サービスアカウント: 認証成功時に紐付けるAnthropic側のIDと権限スコープを定義する
4. 接続テスト用ワークフロー: 実際にトークン交換が動くかを確認するYAMLを取得する

順番に設定していきます。

発行者（Issuer）の登録

Anthropic Consoleにログインしたら、左メニューから「APIキー」を開きます。

「キーを作成」をクリックします。

APIキー方式かOIDC方式かを選択するダイアログが開きます。今回は静的キーを持たない方式を採用するため、「ID連携を設定する」 をクリックします。

「ワークロード ID フェデレーション」の管理画面に遷移します。まだ発行者が1件も登録されていないので、「発行者を登録」をクリックします。

発行者（Issuer）とは、OIDCトークンを発行する信頼元のことで、ここではGitHub ActionsのOIDCトークン発行URLとその署名鍵の取得方法を登録します。この登録によって、Anthropicは「そのURLから発行され、正しい署名が付いたトークンなら本物として受け入れる」という判断基準を持てるようになります。

発行者登録ダイアログが開くので、以下を入力します。

入力が終わったら、「登録する」をクリックします。

発行者一覧に github-actions が「有効」ステータスで追加されれば、発行者の登録は完了です。

ワークロードの接続

続いて、この発行者と、GitHub Actions側の一致条件・サービスアカウントを紐付ける4ステップウィザードに進みます。

画面右上の 「ワークロードを接続」 をクリックします。

ステップ1: 発行者

先ほど登録した github-actions を選択して「続ける」をクリックします。

ステップ2: フェデレーションルール

「このルールはどのワークロードに一致させますか？」画面で、以下を入力します。

「続ける」をクリックします。

ステップ3: 対象（サービスアカウント）

「これはどのサービスアカウントにしますか？」画面で、以下を入力します。

「適用して続行」をクリックします。

ステップ4: テスト用ワークフローの取得

最後に、接続テスト用のワークフローYAMLが表示されます。ここには次の4つの識別子が埋め込まれており、後の手順でGitHub Actionsのワークフローを書くときに使います。

• federation_rule_id
• organization_id
• service_account_id
• workspace_id

右上のコピーボタンでYAML全文をコピーし、テキストファイルなどに貼り付けて保管しておいてください。 これらの値は後で Anthropic Console から再度確認できますが、ここで控えておくと後の手順がスムーズです。

この時点ではまだGitHub Actions側からトークン交換のリクエストが来ていないため、接続テスト欄は「認証を待機中…」のままで問題ありません。実際の疎通確認は、次章以降でサンプルリポジトリにワークフローを配置してから行います。「完了」を押してダイアログを閉じます。

4. サンプルリポジトリの準備

ハンズオンを始める前に、AIレビューの対象となるサンプルリポジトリを用意しておきます。プルリクエストを出す前提のリポジトリなので、main ブランチには最小限のコードだけを置き、実際のレビュー体験は別ブランチのプルリクエストで行います。

4.1 フォルダの作成

本章専用の作業フォルダを作成します。任意の場所に ai-review-handson フォルダを作成し、Visual Studio Codeの「ファイル」→「フォルダーを開く」から、作成した ai-review-handson フォルダを開きます。以降の操作は、Visual Studio Codeのターミナルから行います。

ai-review-handson  ← このフォルダを作成

4.2 初期コードの作成

まずはレビュー対象の起点となる最小限のPythonアプリケーションを作成します。あとで別ブランチで意図的に問題のある変更を加えて、AIがそれをどう指摘するかを確認します。

Visual Studio Codeのエクスプローラーで ai-review-handson フォルダを右クリックし、「新しいファイル」から app.py を作成します。

ai-review-handson
└── app.py  ← このファイルを作成

作成したファイルに以下の内容を記述して保存します。

def calculate_total(items: list[dict]) -> int:
    """商品リストの合計金額を計算する"""
    total = 0
    for item in items:
        total += item["price"] * item["quantity"]
    return total

このコード自体にも、price や quantity が欠けたときの例外処理、負の値のバリデーション、list[dict] の dict の中身が明示されていない型ヒント、docstringの引数・戻り値の説明といった改善余地が残っています。あとの手順でより明確な問題を含む変更を加え、これらと合わせてAIレビューがどこまで指摘してくるかを見ていきます。

4.3 GitHubリポジトリの作成

GitHub Actionsを動かすには、その入れ物となるGitHubリポジトリにコードが乗っている必要があります。本章専用の検証用リポジトリを新規作成します。

ブラウザで GitHubの新規リポジトリ作成画面 を開き、以下の設定でリポジトリを作成します。

General

Configuration

「Create repository」をクリックして作成します。

作成直後、リポジトリのトップページに「Quick setup」ブロックと、その下の「…or push an existing repository from the command line」ブロックが表示されます。後者に git remote add origin ... から git push -u origin main までのコマンドが載っているので、次の手順ではこの git remote add origin ... のリポジトリURLをコピーして使います。

4.4 ローカルからのPush

先ほど作成したGitHubリポジトリに、ローカルのコードをPushします。

以下のコマンドで、Git がインストールされていることを確認します。

git --version

以下のように Git のバージョンが表示されれば、インストールは確認できています。

git version 2.x.x

バージョンが表示されない場合は、Git/GitHubのセットアップ を先に実施してください。

インストールが確認できたら、ローカルでGitリポジトリを初期化します。

git init

ファイルをコミットします。

git add app.py

git commit -m "Add initial calculate_total"

リモート設定とPushを行います（<your-username> をご自身のGitHubユーザ名に置き換えてください）。

git remote add origin https://github.com/<your-username>/ai-review-handson.git

git branch -M main

git push -u origin main

GitHubのリポジトリページで app.py がコミットされていれば、リポジトリの準備は完了です。

5. OIDC接続の疎通確認

Anthropic Console側でOIDC連携の登録は済みましたが、まだGitHub Actions側からのトークン交換が発生していないため、Anthropic Consoleの接続テストは「認証を待機中…」のまま停止しています。実際にトークン交換が動くことを確認するため、Anthropic Consoleが生成した接続テスト用のワークフローをリポジトリに配置し、プルリクエストで起動させます。

疎通が確認できたらテスト用ワークフローは削除し、次のセクションでAIレビュー用のワークフロー作成に進みます。

5.1 サブジェクトパターンの修正

Anthropic Consoleのウィザードが自動生成したサブジェクトパターンは repo:<owner>/<repo>:* の形式ですが、GitHub Actionsが実際に発行するOIDCトークンの sub クレームは、リネームへの耐性のため 数値IDが埋め込まれた形式（repo:<owner>@<owner_id>/<repo>@<repo_id>:<event>）になっています。このままだと接続テストで match_subject_prefix エラーになるので、フェデレーションルールのサブジェクトパターンをこの形式に合わせて修正します。

GitHubの数値IDを確認する

先ほど作成したGitHubリポジトリに対して、ご自身の 数値ユーザID と 数値リポジトリID を取得します。

まず、ユーザIDを確認します（<your-username> はご自身のGitHubユーザ名に置き換えてください）。

curl https://api.github.com/users/<your-username>

以下のような出力の "id" の値をメモします。

{
  "login": "<your-username>",
  "id": 46599122,
  ...
}

続いて、リポジトリIDを確認します。

curl https://api.github.com/repos/<your-username>/ai-review-handson

以下のような出力の "id" の値をメモします。

{
  "id": 1383273738,
  "name": "ai-review-handson",
  ...
}

サブジェクトパターンの書き換え

Anthropic Consoleで 「APIキー」→「ワークロード ID フェデレーション」→「ルール」タブ → ai-review-handson を開き、右上の「編集」をクリックします。

サブジェクトパターン の値を、以下の形式に書き換えます。

repo:<your-username>@<user_id>/ai-review-handson@<repo_id>:pull_request

具体例（your-username=kymx1983、user_id=46599122、repo_id=1383273738 の場合）:

repo:kymx1983@46599122/ai-review-handson@1383273738:pull_request

「追加のクレーム条件」はそのままで問題ありません。画面下部の「保存」をクリックして修正を反映します。

5.2 接続テストワークフローの配置

Anthropic Consoleの「ワークロードを接続」ウィザード最後で表示された anthropic-wif-test.yml を、リポジトリに配置します。コピーしていない場合は、Anthropic Consoleで対象のフェデレーションルールを開き、テスト用ワークフローを再表示してコピーしてください。

Visual Studio Codeのエクスプローラーで ai-review-handson フォルダを右クリックし、「新しいフォルダー」から .github/workflows を作成し、その中に anthropic-wif-test.yml を作成します。

ai-review-handson
├── app.py
└── .github/
    └── workflows/
        └── anthropic-wif-test.yml  ← このファイルを作成

作成したファイルに、Anthropic Consoleからコピーしたテスト用YAMLをそのまま貼り付けて保存します。ご自身の環境では以下のような形になっているはずです（federation_rule_id / organization_id / service_account_id / workspace_id の値はご自身のものになります）。

name: anthropic-wif-test
on: pull_request
permissions:
  id-token: write
  contents: read
jobs:
  call-claude:
    runs-on: ubuntu-latest
    steps:
      - name: Fetch GitHub OIDC token
        uses: actions/github-script@v8
        with:
          script: |
            const token = await core.getIDToken('https://api.anthropic.com');
            core.setSecret(token);
            core.exportVariable('JWT', token);
      - name: Exchange for an Anthropic access token
        run: |
          curl -sS https://api.anthropic.com/v1/oauth/token \
            -H "content-type: application/json" \
            --data @- <<JSON | jq 'with_entries(if (.key | test("token$")) then .value = "<redacted>" else . end)'
          {
            "grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer",
            "assertion": "$JWT",
            "federation_rule_id": "fdrl_xxx...",
            "organization_id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
            "service_account_id": "svac_xxx...",
            "workspace_id": "wrkspc_xxx..."
          }
          JSON

主要な部分を解説します。

permissions:
  id-token: write
  contents: read

id-token: write は、GitHub ActionsのランナーがOIDCトークンを取得するために必要な権限です。OIDC連携を使うワークフローには必ず付与します。

- name: Fetch GitHub OIDC token
  uses: actions/github-script@v8
  with:
    script: |
      const token = await core.getIDToken('https://api.anthropic.com');

audience として https://api.anthropic.com を指定してOIDCトークンを取得します。このaudience値は、後段のトークン交換先であるAnthropicに向けたトークンであることを主張するために使います。

- name: Exchange for an Anthropic access token
  run: |
    curl -sS https://api.anthropic.com/v1/oauth/token \
      ...

取得したOIDCトークンを、Anthropicのトークン交換エンドポイント (/v1/oauth/token) に渡し、短命なアクセストークンと引き換えます。federation_rule_id / organization_id / service_account_id / workspace_id の4つの識別子で、どのルールに対する認証かをAnthropic側に伝えます。

5.3 プルリクエストからの起動

このワークフローは on: pull_request で動くため、mainへの単純なpushでは起動しません。プルリクエストを開いて起動させます。

まず、追加したファイルをmainブランチにコミット・pushします。

git add .github/workflows/anthropic-wif-test.yml

git commit -m "Add OIDC connectivity test workflow"

git push origin main

続いて、疎通確認用の別ブランチを作成します。今回のワークフローは on: pull_request トリガーで設定したので、実行するにはプルリクエストを開く必要があります。プルリクエストは「あるブランチの内容を別のブランチに取り込む提案」なので、main に対して差分を持つ別ブランチが必要です。ここではその差分を作る作業ブランチとして test/oidc を作成します。

git switch -c test/oidc

軽微な変更として、README.md を新規作成します。Visual Studio Codeのエクスプローラーで ai-review-handson フォルダを右クリックし、「新しいファイル」から README.md を作成します。

ai-review-handson
├── app.py
├── README.md  ← このファイルを作成
└── .github/
    └── workflows/
        └── anthropic-wif-test.yml

作成したファイルに以下の内容を記述して保存します。

# ai-review-handson

コミット・pushします。

git add README.md

git commit -m "Trigger OIDC test"

git push -u origin test/oidc

GitHubのリポジトリページで test/oidc ブランチから main に対するプルリクエストを作成します。プルリクエストが作成されると、anthropic-wif-test ワークフローが自動的に走ります。

5.4 認証成功の確認

GitHub Actions側とAnthropic Console側の両方で成功を確認します。

GitHub Actions側

リポジトリの「Actions」タブで anthropic-wif-test ワークフローの実行が緑になっていることを確認します。Exchange for an Anthropic access token ステップのログを開くと、以下のようなJSONレスポンスが表示されているはずです（トークン本体は自動でマスクされます）。

{
  "access_token": "<redacted>",
  "token_type": "Bearer",
  "expires_in": 3600,
  ...
}

access_token が返っていれば、GitHub Actions → Anthropicのトークン交換が成立しています。

Anthropic Console側

Anthropic Consoleで、対象のフェデレーションルール ai-review-handson を開き、上部のタブを 「接続テスト」 に切り替えます。ページ下部の 「認証ログ」 セクションに、直近のトークン交換が「成功」（緑丸）として記録されているはずです。前節「サブジェクトパターンの修正」の書き換え前に走った試行があれば、そちらは「拒否」（赤丸、match_subject_prefix）としてタグ付きで並びます。

該当のエントリをクリックすると、Anthropic側が検証したJWTのクレーム一覧が展開されます。ここで sub / repository / repository_owner_id などがフェデレーションルールの一致条件と噛み合っていたことを意味します。

これでOIDC連携の疎通確認は完了です。次のセクションで、AIレビュー用のワークフローを構築していきます。

6. Claude Code Actionの組み込み

サンプルリポジトリとOIDC連携が整ったので、Claude Code ActionをGitHub Actionsに組み込み、プルリクエストに対してAIレビューが動く状態を作ります。

6.1 Claude Code Action GitHub Appのインストール

これから作る AI レビューワークフローは、GitHub Actions 上で anthropics/claude-code-action@v1 を呼び出します。これはAnthropicが公式に提供している Claude Code Action の実体で、ソースコードは Claude Code Action 公式リポジトリ で公開されています。

ただし、この Action をワークフローから呼び出すだけでは動きません。対応する Claude GitHub App も対象リポジトリにインストールしておく必要があります。理由と手順を順に見ていきます。

GitHub App が必要な理由

疎通確認で置いた anthropic-wif-test.yml では GitHub App は不要でした。あのワークフローは Anthropic API を呼び出してトークン交換のレスポンスをログに出すだけで、GitHub リポジトリ側への書き込みは一切していなかったためです。

一方、これから作る AI レビューワークフローは、Claude が生成したレビューコメントを プルリクエストに書き戻す 必要があります。プルリクエストへのコメント投稿・レビューコメントの行紐付け・@claude メンションへの反応など、Claude が GitHub 上で操作するには、そのための GitHub 上のアイデンティティ（＝Claude GitHub App）が必要です。App を入れておくことで、Claude Code Action は投稿を「Claude」という明確なボットとして行い、権限も PR・Issue 操作に必要な範囲に絞られた状態で動きます。

インストール手順

ブラウザで Claude GitHub App のインストール画面 を開きます。画面右上のボタンは、アカウントの状態によって表示が変わります。まだClaude Appをインストールしていない場合は「Install」ボタンが表示されます。すでに別のリポジトリでClaude Appを使っている場合は「Configure」ボタンが表示されるので、そこから対象アカウントの設定画面に入り、「Repository access」に ai-review-handson を追加する形で進めます。

ボタンをクリックしてご自身のGitHubアカウントを選択すると、インストール設定画面に進みます。以下の設定を行います。

権限一覧を確認して、画面下部の「Install & Authorize」（既にインストール済みで設定を変更する場合は「Save」）をクリックします。これでGitHub App のインストールは完了です。以降、ai-review-handson リポジトリのプルリクエストに対して Claude Code Action からコメント投稿ができるようになります。

初回インストール時は、続けて claude.ai 側のGitHub連携画面に自動的に遷移します。

インストールの確認

Claude App が正しくインストールされたかは、ai-review-handson リポジトリの Settings → Integrations → GitHub Apps から確認できます。「Installed GitHub Apps」の一覧に「Claude」が「Configure」ボタン付きで表示されていれば、このリポジトリに対して App がインストールされている状態です。

6.2 ワークフローファイルの作成

Claude Code Actionをプルリクエストのタイミングで動かすワークフローを作成します。認証は先ほど設定したOIDC連携を使い、実行時に短命なアクセストークンを取得してClaude Code Actionに渡す構成にします。

前節の疎通確認で test/oidc ブランチに切り替えたままになっているので、まず main ブランチに戻ります。

git switch main

Visual Studio Codeのエクスプローラーで ai-review-handson/.github/workflows/ を右クリックし、「新しいファイル」から ai-review.yml を作成します。

ai-review-handson
├── app.py
└── .github/
    └── workflows/
        └── ai-review.yml  ← このファイルを作成

作成したファイルに以下の内容を記述して保存します。<federation_rule_id> / <organization_id> / <service_account_id> / <workspace_id> は、Anthropic Consoleの接続テストで確認したご自身の値に置き換えてください。

name: AI Review

on:
  pull_request:
    types: [opened, synchronize]

permissions:
  id-token: write
  contents: read
  pull-requests: write
  issues: write

jobs:
  ai-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_federation_rule_id: <federation_rule_id>
          anthropic_organization_id: <organization_id>
          anthropic_service_account_id: <service_account_id>
          anthropic_workspace_id: <workspace_id>
          prompt: |
            REPO: ${{ github.repository }}
            PR NUMBER: ${{ github.event.pull_request.number }}

            あなたはシステム開発の経験が豊富な開発者です。
            今回のプルリクエストの変更差分を、一般的なコード品質の観点でレビューしてください。

            変更差分は、すでにカレントディレクトリにチェックアウト済みです。

            全体的な所感は `gh pr comment` を使って投稿してください。
            該当行に紐付けたレビューコメントは `mcp__github_inline_comment__create_inline_comment` を使って投稿してください。
            レビュー内容はメッセージ返答ではなく、必ず GitHub コメントとして投稿してください。

          claude_args: |
            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

ワークフローを解説します。

on:
  pull_request:
    types: [opened, synchronize]

プルリクエストの作成時（opened）と、既存のプルリクエストに新しいコミットがPushされた時（synchronize）にワークフローが動きます。Draftから通常に切り替えたときなど、他のイベントは対象外です。

permissions:
  id-token: write
  contents: read
  pull-requests: write
  issues: write

id-token: write はOIDCトークンの取得のために、それ以外はClaude Code Actionがプルリクエストにレビューコメントを投稿するために必要な権限です。最小権限の原則 に従い、書き込みが必要な範囲だけに絞ります。

- uses: anthropics/claude-code-action@v1
  with:
    anthropic_federation_rule_id: <federation_rule_id>
    anthropic_organization_id: <organization_id>
    anthropic_service_account_id: <service_account_id>
    anthropic_workspace_id: <workspace_id>
    prompt: |
      REPO: ${{ github.repository }}
      PR NUMBER: ${{ github.event.pull_request.number }}
      ...

Claude Code Actionは、4つの識別子を渡すだけで Action の内部で OIDC トークン交換を実行 します。疎通確認で書いた curl によるトークン交換ステップを別途書く必要はなく、Action がそれ相当の処理を自動で行ってくれます。anthropic_api_key は指定しません（指定すると静的APIキーが優先され、OIDC 連携が使われなくなります）。

prompt にはClaudeに与える指示を書きます。ここでは、対象リポジトリとプルリクエスト番号を明示するために REPO と PR NUMBER を先頭に置き、「経験が豊富な開発者」として振る舞わせることでコード品質だけでなく設計判断やビジネスロジックの妥当性まで広く見てもらう指示にしています。加えて、レビュー対象がカレントディレクトリにチェックアウト済みの変更差分であることを伝え、投稿手段として総評は gh pr comment を、行単位の指摘は mcp__github_inline_comment__create_inline_comment を使うよう明示的に指定しています。最後に「メッセージ返答ではなくGitHubコメントとして投稿」と念押しし、投稿が確実に行われるようにしています。

観点の詳細は次のセクションで coding-standards Skill として切り出し、規約に沿った指摘に絞り込んでいきます。

claude_args: |
  --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

claude_args は、Claude Code Action の内部で起動する Claude Code SDK にそのまま渡す引数です。--allowedTools で プロンプトで使うよう指示したツールを明示的に許可 します。ここで許可していないツールは、Claude が使おうとしても権限拒否で弾かれ、レビューが動いてもコメント投稿までたどり着けません。今回は以下の4つを許可しています。

• mcp__github_inline_comment__create_inline_comment: 該当行に紐付いたレビューコメントを投稿する MCP ツール
• Bash(gh pr comment:*): プルリクエストへの総評コメントを gh CLI で投稿するためのBash実行
• Bash(gh pr diff:*) / Bash(gh pr view:*): プルリクエストの差分・情報を確認するためのBash実行

6.3 ワークフローのコミットとPush

ワークフローファイルをリポジトリに反映します。

git add .github/workflows/ai-review.yml

git commit -m "Add Claude Code Action for PR review"

git push origin main

GitHubのリポジトリページを開き、.github/workflows/ フォルダを確認します。ai-review.yml が最新のコミットメッセージ「Add Claude Code Action for PR review」と一緒に並んでいれば、ワークフローがリポジトリに反映された状態です。

6.4 プルリクエストでの動作確認

意図的にレビューされるべき変更を含むブランチを作成し、プルリクエストを出してAIレビューが動くことを確認します。

git switch -c intentional-issues

Visual Studio Codeで app.py を以下の内容に書き換えます。

import os

API_KEY = "sk-1234567890abcdef"


def calculate_total(items: list[dict]) -> int:
    """商品リストの合計金額を計算する"""
    total = 0
    for item in items:
        total += item["price"] * item["quantity"]
    return total


def do_thing(data):
    return eval(data)

このコードには以下の問題が意図的に含まれています。これらがAIレビューで指摘されるかを、この後のプルリクエストで確認していきます。

変更をコミットしてPushします。

git add app.py

git commit -m "Add eval and hardcoded key (for review demo)"

git push -u origin intentional-issues

GitHubのリポジトリページで intentional-issues ブランチから main に対するプルリクエストを作成します。タイトルはコミットメッセージがそのまま使われるので、そのまま「Create pull request」で作成します。

プルリクエストを作成すると、AI Review / ai-review チェックが Started として動き出します。前節で作った anthropic-wif-test / call-claude も同じイベントで動いていますが、こちらは疎通確認のワークフローなので独立して走ります。

数十秒〜1分程度で AI Review が完了し、claude[bot] からプルリクエスト全体への総評コメントと、変更行に紐付けたインラインコメントが投稿されます。

インラインコメント（該当行に紐付いたレビュー）

APIキーのハードコードに対する指摘。修正提案（Suggested change）で環境変数取得への置き換え案まで提示してくれます。

eval による任意コード実行の脆弱性への指摘。安全な代替関数（ast.literal_eval / json.loads）まで提案されます。

calculate_total の入力値検証・型の整合性への指摘。前節で「あとで指摘対象になる」と伝えていたポイントもAIが自力で拾ってきています。

総評コメント（プルリクエスト全体へのサマリ）

必須対応と改善提案を分けたサマリが gh pr comment 経由で投稿されます。個別行の指摘とセットで見ることで、レビュアーは「まず何を直すべきか」を短時間で把握できます。

指摘の答え合わせ

前節で「これらがAIレビューで指摘されるかを確認する」と挙げた4点は、いずれも AI が拾えていました。

これでAIレビューが「動くだけ」の状態ができました。ただしこの状態のままだと、レビューコメントの粒度がプロジェクトごとの規約に合わず、ノイズも多いという問題が残ります。次のセクションで観点を Skillsとして管理し、精度を上げていきます。

トラブルシューティング

初回のAIレビュー起動時によく踏むポイントを、症状と対処のセットでまとめておきます。

7. レビュー観点のSkillsによる管理

前のセクションで、AIレビューがプルリクエストにコメントを投稿する状態は作れました。ただ、いま動いているレビューはClaudeの一般常識に依存しているため、そのままでは実運用に耐えません。まずAIレビューが持つ性質を整理し、その上でSkillsという仕組みで観点を明文化する運用に切り替えていきます。

7.1 AIレビューの注意点

前節で動いたAIレビューには、以下のような性質があります。運用に乗せる前に、性質を理解しておかないと「思ったより使えない」という印象で終わってしまいます。

レビュー品質のばらつき

同じプロンプト・同じ変更差分でも、AIが「何をチェックするか」は毎回同じにはなりません。指摘の粒度・拾える観点が実行のたびに変わるため、レビュー結果を再現しにくく、品質にもばらつきが出ます。加えて、モデルのバージョンアップや時期による振る舞い変化にも影響を受けるため、「先週まで拾えていた指摘が、今日は拾えていない」ということも起こります。

さらに、前回のレビューで指摘された内容を対応したのに、次回のレビューでは前回出なかった別の指摘が新しく返ってくる、ということも珍しくありません。1回のレビューで拾える観点が有限で、しかも毎回同じ観点セットが選ばれるわけではないため、対応 → 再レビュー → 新しい指摘 → 対応、と繰り返してもレビューが収束しない状態に陥りがちです。

組織やプロジェクトの規約に合わない

観点を絞らずレビューさせると、AIは一般的なベストプラクティスに沿った指摘を返します。自チームの命名規則、非推奨としている書き方、過去のインシデントから得た学習など、プロジェクト固有の規約は反映されません。結果、「チーム内ではOKなのに毎回指摘される」「本当に見てほしい観点は素通りされる」というズレが発生します。

例えば「外部公開する認証機能には多要素認証を必須とする」という組織ルールがあっても、AI はそこまでは知らないため、一般的なパスワード認証の実装として問題がなければ素通りします。逆に、社内で非推奨にしている書き方でも一般的には推奨とされていれば、AI からは「良い書き方」として扱われてしまうこともあります。

細かすぎる指摘

AIは目についた改善案をすべて列挙する傾向があります。細かすぎる指摘や、実装コストに合わないマイクロ最適化まで返ってくると、レビュアーがAIコメントに疲弊し、結果として「AIコメントは読まない」という運用に陥ります。

例えば、数ミリ秒しか変わらないループの書き換え提案、コメントの句読点の付け方、既に別で対応する予定になっているリファクタリング提案などが混ざってくると、本当に対応が必要な指摘が埋もれてしまいます。

7.2 Skillsの利用

上記3つは、いずれもAIに渡す観点を明文化・固定化することで抑え込めます。Claude Code Action の場合、これを実現するのが Skills という仕組みです。

Skillsとは

Skillsは、Claudeが参照するタスク別のガイドライン集です。リポジトリの .claude/skills/<skill名>/SKILL.md として配置しておくと、Claudeはプロンプトから該当するSkillを読み込み、その内容に沿って動作します。例えば coding-standards Skill を書けば、AIレビュー時に必ずその規約・優先度・出力フォーマットに従わせられます。

Skillsはリポジトリ内のファイルとして管理されるため、Git上でレビュー・履歴管理・変更追跡できるチーム資産になります。チームの知見が変わればSkillを更新するだけで、AIレビューの精度もそれに追従します。

前節の注意点をどう解決するか

Skillsを使うことで、前節で挙げた3つの注意点をまとめて抑えられます。まず「レビュー品質のばらつき」は、Skillに「必ず見る観点」と優先度を明文化しておくことで、実行のたびに同じ基準で指摘が入るようになります。「組織やプロジェクトの規約に合わない」については、Skillに自チームのコーディング規約・NG事項・過去のインシデントから得た学習を書き込むことで、一般的なベストプラクティスではなく自チームの規約に沿ったレビューに寄せられます。そして「細かすぎる指摘」も、Skillに重要度別の出しどころとノイズにならない出力方針を書いておけば、レビュアーが本当に見るべき指摘に絞り込めます。

7.3 coding-standards Skillの作成

Claude Code Actionは、リポジトリの .claude/skills/ 配下に置いたSkillファイルを自動で読み込みます。コーディング規約をここに書くと、Actionがプロンプトと合わせてこの内容もClaudeに渡してくれる仕組みです。詳細は Claude Code Skills（Anthropic公式ドキュメント） に記載があります。

Skillの追加そのものはレビュー対象ではないため、main ブランチに直接追加してpushします。まずローカルを main ブランチに戻して、リモートの最新を取り込みます。

git switch main

git pull origin main

Visual Studio Codeのエクスプローラーで ai-review-handson フォルダを右クリックし、「新しいフォルダー」から .claude/skills/coding-standards を作成し、その中に SKILL.md を作成します。

ai-review-handson
├── app.py
├── .claude/
│   └── skills/
│       └── coding-standards/
│           └── SKILL.md  ← このファイルを作成
└── .github/
    └── workflows/
        └── ai-review.yml

作成したファイルに以下の内容を記述して保存します。なお、以下の Skill は Skills の動作確認用に非常にシンプルにしたサンプルで、実運用に耐えられる内容ではありません。実プロジェクトでは、実際の運用ルール・過去のインシデント・チーム固有の知見を踏まえて内容を書き足してください。

# 開発規約

本ドキュメントは、本プロジェクトの開発とレビューの両方で参照する規約です。

## 命名

- 関数名は動詞から始める
- 変数名は名詞・名詞句にする
- クラス名は PascalCase で書く

## エラー処理

- エラーは呼び出し元まで wrap して返す
- レスポンスの JSON 形式は統一する
- HTTP ステータスは意味に合わせて選ぶ

## テスト

- 変更に対応するテストを追加する
- テストは仕様ベースで書く（実装をなぞらない）

## セキュリティ

- シークレット・トークンはコードに埋め込まない
- 入力バリデーションが必要な箇所で抜けを作らない
- ログに個人情報を出さない

## ドキュメント

- 公開関数には docstring を付ける
- TODO コメントには担当者を明記する

## 指摘の優先度

すべての指摘には以下のいずれかの優先度を付ける。優先度を付けない指摘は投稿しない。

- **must**: マージ前に必ず直す（バグ、セキュリティ、規約違反）
- **should**: 可能なら直す（可読性、命名の改善）
- **nice-to-have**: 覚えておく程度（提案レベルの改善案）

## ノイズを避けるための指針

- 自明な指摘はしない（Prettier や eslint で機械的に直せる範囲）
- 既存コードのスタイルに従う（PR の変更範囲外を「ついでに」直させない）
- 同じ観点の指摘は1つに集約する（同じ内容を複数箇所で繰り返さない）
- 意見が分かれるトピックは指摘しない（設計判断は人間のレビュー領域）

## 指摘のフォーマット

- 該当行に紐づけて投稿する（PR コメントではなく inline review comment）
- 「なぜそう変えるべきか」の理由を1文添える
- 修正案がある場合は、コードブロックで具体的に示す
- 優先度は指摘の冒頭に `[must]` `[should]` `[nice-to-have]` で明示する

なお、このSkillには「あなたはコードレビュアーです」のような役割の指示は含めていません。役割・ペルソナはSkill側ではなく、呼び出し側（本章では ai-review.yml の prompt）で渡すのが一般的です。Skillはタスクの中身（規約・観点・出力方針）を持ち、呼び出し側は「誰として、何をするか」を渡す、という役割分担にしておくと、同じSkillを別の呼び出しコンテキスト（例: ローカルのClaude Codeでの手動レビュー）から再利用しやすくなります。

各セクションの狙いを整理します。

7.4 Skillを反映したプルリクエストで動作確認

Skillファイルを main にコミット・pushし、その後のプルリクエストでAIレビューの精度がどう変わるかを確認します。

git add .claude/skills/coding-standards/SKILL.md

git commit -m "Add coding-standards skill"

git push origin main

main にSkillが反映されたら、もう一度意図的な問題を含むプルリクエストを出してAIレビューを確認します。前セクションのブランチには手を加えず、main から新しくブランチを切ります。

git switch -c intentional-issues-v2

Visual Studio Codeで app.py を以下の内容に書き換えます。

import os

API_KEY = "sk-1234567890abcdef"


def calculate_total(items: list[dict]) -> int:
    """商品リストの合計金額を計算する"""
    total = 0
    for item in items:
        total += item["price"] * item["quantity"]
    return total


def do_thing(data):
    return eval(data)

初期状態の app.py（calculate_total 関数のみ）に対して、前セクションと同じ意図的な問題を再度含めています。同じ問題を Skill 適用前と適用後で比較することで、AI レビューの粒度・優先度・出力フォーマットがどう変わるかを確認する狙いです。今回加えた変更は以下の3点です。

• 未使用の import os の追加
• API_KEY = "sk-1234567890abcdef" — シークレットのハードコード
• def do_thing(data): return eval(data) — eval の使用、意味のない関数名、型ヒントの欠如

変更をコミットしてPushします。

git add app.py

git commit -m "Add eval and hardcoded key (v2 for review demo)"

git push -u origin intentional-issues-v2

intentional-issues-v2 から main へのプルリクエストを作成します。

プルリクエストを作成すると、ai-review.yml ワークフローが起動し、Claude Code Action が coding-standards Skill の規約を参照した状態でレビューを投稿します。

インラインコメント

APIキーのハードコードには [must] の優先度が付き、環境変数から読み込む形への Suggested change が提示されます。すでにpush済みのシークレットに対する対応（無効化・再発行）まで明記されています。

eval の指摘にも [must] が付き、代替関数（ast.literal_eval / json.loads）を示したうえで、規約の「関数名は動詞から始める」「公開関数には docstring を付ける」に紐付ける形で parse_literal への書き換え案がまとめて提示されます。

calculate_total の入力値検証には [should] が付き、キー欠落・負数・非数値などの想定外入力に対する扱いを決めるよう促されます。修正例のコードブロックも添えられています。

総評コメント

gh pr comment 経由でプルリクエスト全体への総評が投稿されます。must / should / その他 の3セクションで指摘がまとめられ、「セキュリティ上の重大な問題が2点あるため、現状ではマージ不可」という判定まで含まれています。

Skill 適用前と比べての変化

前セクション（Skill 適用前）の結果と比べて、次の変化が確認できます。

• 指摘の冒頭に [must] [should] の優先度ラベルが付き、対応の優先順位を判断できるようになった
• Skill に書いた規約への言及（「規約：関数名は動詞から始める／公開関数には docstring を付ける」など）が指摘の根拠として明示されるようになった
• 総評コメントも must / should / その他 に構造化され、マージ可否の判定まで含む形になった

7.5 改善サイクルの回し方

8. 不要リソースの削除

ハンズオンで作成したリソースを削除します。OIDC連携はキーが漏れる仕組みではありませんが、放置するとフェデレーションルールから予期せぬ認証が通る余地が残るため、忘れず削除します。

8.1 Anthropic ワークロード ID フェデレーションの削除

Anthropic Console にログインし、左サイドメニュー「APIキー」から「ワークロード ID フェデレーション」を開きます。「ルール」タブから ai-review-handson ルールを選択して削除し、続いてサービスアカウント ai-review-handson も削除します。他に使う予定がなければ「発行者」タブから github-actions 発行者もアーカイブしておきます。

8.2 GitHub App のリポジトリからの削除

GitHubのユーザ設定画面から「Applications」→「Installed GitHub Apps」を開き、「Claude Code」の「Configure」から ai-review-handson リポジトリを外します。GitHub App自体をアカウントから削除する場合は「Uninstall」を選択します。

8.3 GitHubリポジトリの削除

GitHubのリポジトリ「Settings」から「Delete this repository」で ai-review-handson リポジトリを削除します。

8.4 ローカルの削除

ローカルフォルダも不要であれば削除できます。

cd ..

rm -rf ai-review-handson

9. まとめ

この章では、Claude Code ActionとレビューSkillを組み合わせたAIによるコードレビューの自動化を体験しました。

• 人とAIの役割分担を整理でき、機械が見た方が速く正確な指摘はAIに任せ、設計判断・ビジネスロジックは人間のレビュアーが担う運用の型を持てる
• Anthropic Console のワークロード ID フェデレーションを設定することで、静的APIキーを持たずにGitHub ActionsからOIDCで安全にClaudeを呼び出すことができる
• Claude Code Actionを GitHub Appとしてリポジトリにインストールし、OIDCで取得した短命アクセストークンを渡して ai-review.yml からClaudeを呼び出すワークフローを構築できる
• プルリクエストの作成・更新をトリガーに、AIが変更差分を読んでレビューコメントを該当行に投稿する状態を作れる
• .claude/skills/coding-standards/SKILL.md に開発規約とレビュー時の指摘方針を書き出すことで、AIレビューが自チームの規約に沿った精度で動く
• 「有用な指摘」と「ノイズ」を分類しながらSkillを改善するサイクルを回すことで、レビューの品質がSkillの質に集約されていくチーム資産の型を持てる

次の章では、Claude Code ActionとSkillsを組み合わせた、Issue起点・PRメンション起点のAI開発フローの自動化をハンズオン形式で体験します。