Claude Code Action は、Claude Code のエージェントをプルリクエスト上に配置する GitHub Action である。コミット数2倍でもレビュー品質を維持！AI時代のコードレビューフロー再設計 は、あるチームが特定の理由からこれを導入した経緯を説明している。メンバーはすでに一日の多くを GitHub の PR 画面でコメントや CI のステータスを確認して過ごしており、同じ画面上でコードレビューまで完結できればかなり効率的になるだろう、というのがその記事の考えであった。
その記事が決定的とみなしている性質は、レビューフローをどこまで作り込めるかである。記事はカスタマイズの自由度がかなり大きいと評価しており、3 つのツールの比較では、このツールのカスタマイズ性を「無制限」とし、自動学習されるカスタムルールを評価している Greptile を「高」、GitHub Copilot を「中」としている。チームは固定されたレビューを調整するのではなく、独自のフローを書いてアクションにそれを実行させた。
機能
- プルリクエストに対して Claude Code のエージェントを実行する。コードレビュー、CI 失敗の診断と修正、そしてレビューコメントへの対応（コメントから新しいプルリクエストを作成することを含む）に利用できる。
- レビューフローは、関心事ごとに別々のサブエージェントを割り当てた複数のフェーズとしてスクリプトで記述できる。記事のチームが構築したフローは、Claude 自身が公開しているコードレビューの例をモデルにしたもので、4 つのフェーズを実行する。PR のメタデータ、解決しようとしているイシュー、作成者、開発領域、そこに適用されるガイドラインを収集する準備フェーズ、レビュー観点ごとに 1 つのサブエージェントがそれらのガイドラインに照らして作業するレビューフェーズ、各 AI コメントが妥当か、捏造されていないか、どの程度深刻かをサブエージェントが判断する重要度評価フェーズ、そして重要度の高い指摘だけをインラインコメントし、サマリーを送信し、他のエージェントがすでに述べたことを抑制する投稿フェーズである。
- 同じスクリプト化の仕組みは、コメントだけでなく承認にも及ぶ。DMM の別のチームは、このアクションを使って、AI にプルリクエストを採点させ、スコアがしきい値を超えたときに自動で承認する仕組みを構築した。そのレビュアープロンプトは 4 つの軸 ―
pr_clarity_score、code_quality_score、test_quality_score、security_quality_score― で採点し、基準を満たした場合にauto_approvalを"Y"に設定するオブジェクトを、プルリクエストのサマリーと理由の説明とともに出力する。このチームは精度は悪くないと報告しており、プロンプトの調整によって安定した運用を実現したと述べている（AIが教えてくれたコードレビューの本質 ― 意図共有という学び ―）。 - 最初の記事では、比較された 3 つのツールのうちドメイン理解で最も優れ、レビュー品質でも高いと評価されている。コードベースの深い理解は、他のツールとの比較で点数をつけられるのではなく、その特徴的な機能の 1 つとして挙げられている。
- 報告されている欠点として、セットアップが面倒だと評価されており、記事はその原因を権限まわりに注意が必要なことに帰している。また、3 つの中でレビューが最も遅い。記事はさらに、Enterprise 版では API キーと個人トークンのどちらを使うかの判断が難しいとも記している。
採用とエコシステム
最初の記事のチームは、これを GitHub Copilot および Greptile と並ぶ 3 つの AI レビュアーの 1 つとして運用している。同じチームは人間による承認の後に 最終ゲートキーパーとしての AI のチェックも運用しているが、記事はそれをどのツールが担っているかは述べていない。著者は、その活用シナリオは事実上無制限であり、生産性と並行開発のための強力なてこであるとしており、チームのメンバーは熱心なユーザーであると報告されている。
その記事がカスタマイズについて最も直接的に述べている主張は比較に基づくものである。チームのニーズに合わせて形作ったフローを構築したことで、単にガイドラインを渡してレビューを依頼するよりも、レビュー品質が著しく向上したという。これは測定を伴わない、チーム自身の利用に基づく評価である。
DMM の記述は反対の事例であり、機能ではなく定着についてのものである。そのチームは 2025 年 7 月に自動承認の仕組みを構築し、実用的な精度と安定した運用にもかかわらず、それがチーム内に定着しなかったと報告している。記事が挙げる理由は、アクションの性質ではなく、自動化の対象の性質にある。記事は、コードレビューは品質チェックであると同時に意図を共有するための対話でもあり、そのやりとりなしにプルリクエストを承認する仕組みは、チームが価値を置いていた部分を取り除いてしまうと論じている。そして、レビューを AI に適したコード品質のレイヤーと、人間に委ねる意図と判断のレイヤーとに分けることを提案しており、これによればこの種のスクリプト化された採点は前者のレイヤーにのみ位置づけられることになる。これは 1 つのチームの体験報告であり、ここでの 2 つの記述が食い違っているのはアクションが何をするかではなく結果についてである。どちらも独自のフローを書いたことを説明し、どちらもそれが機能したと報告しているが、一方のチームはそれを使い続け、もう一方はそうしなかった。
どちらの記述も、アクションのドキュメントではなく、それを利用しているチームのエンジニアリングブログの記事に由来する。したがって、両者が合わせて示しているのは 2 つのチームがそれをどう構成し、その結果をどう受け止めたかであり、プロジェクトそのものについてはほとんど何も示していない。