業務での使い方 2026.05.13

ClaudeをMRパイプラインに組み込む実践ガイド：自動コードレビューの導入手順

タグ：Claude / MR自動レビュー / CI/CDパイプライン / AIエージェント / 開発効率

このやり方で何ができるか

MergeRequest（MR）が作成されたときに、自動でClaudeが走ってコードの問題点をチェックしてくれます。人間のレビュワーが対応する前に、まず生成AIが目を通すという流れです。

これまでのコードレビューは、開発チームのメンバーが手作業で読み込んで意見を返すやり方がほとんどです。でも実装パターンの重複チェックや命名規則の確認、セキュリティリスクの初期スクリーニングなど、決まった視点での指摘は機械的です。ここをAIエージェントに任せることで、人間は本当に重要な設計判断や業務ロジックの妥当性だけに集中できるようになります。

開発チーム全体の視点では、レビュー待ち時間が短くなり、コードの品質ばらつきが減り、「基本的なルール違反」で往復メールが増える現象も防げます。新人開発者にとっても、AIからの指摘を通じて暗黙的なコード規約を学びやすくなる副次効果も期待できます。

準備するもの

GitLab または GitHub などの MR / Pull Request 機能を持つリポジトリ管理サービス
Claude の API キー（Anthropic の公式サイトから取得）
簡単なスクリプト実行環境（CI/CD パイプライン・GitHub Actions・GitLab CI など、リポジトリホスティングサービスに付属するもの）
基本的な開発知識（Git、リポジトリ管理の仕組み）
大体 20 分〜 1 時間程度の初期設定時間

手順（所要時間目安）

1. Claudeの API キーを取得する（5分）

Anthropic の公式サイトで Claude の API キーを生成します。ログイン後、ダッシュボード内の API キー管理から新規作成できます。このキーは環境変数として安全に保管します（ファイルに直書きしたり、リポジトリに含めたりしてはいけません）。

リポジトリホスティングサービス（GitLab、GitHub など）の設定画面で、環境変数として登録します。GitLab なら「CI/CD 変数」、GitHub なら「Secrets」という機能です。

2. MR トリガーでスクリプトが走る仕組みを作る（15分）

リポジトリの CI/CD パイプライン設定ファイル（GitLab なら .gitlab-ci.yml、GitHub なら .github/workflows/ 配下）に、「MR が作成・更新されたときに走るジョブ」を追加します。

ここで重要なのは、MR で変更された部分だけを Claude に見せるという工夫です。全ファイルを送るのではなく、差分（diff）を抽出して、その部分だけをプロンプト（AI への質問・指示）に含めます。これにより API コスト（Claude の使用量）を抑え、レスポンス時間も短くできます。

3. 差分を取得してプロンプトを作成する（20分）

MR に含まれる変更内容を Git コマンド（git diff など）で抽出します。その差分テキストを、あらかじめ用意した「チェック指示」のプロンプトと組み合わせて、Claude に送ります。

プロンプトの内容としては、以下のような指摘項目を Claude に指示します：

変数名や関数名が直感的か、チームの命名規則に従っているか
古いパターンや非推奨な書き方が混ざっていないか
セキュリティ上の問題（認証・暗号化・入力チェックの漏れ）がないか
エラーハンドリングが適切か
パフォーマンスの明らかな問題（無限ループ、不要な重複処理）がないか

重要なのは、チーム固有のコード規約も含めるという点です。「ウチのプロジェクトではこう書く」というローカルルールを Claude に教えておくことで、精度が大幅に上がります。

4. Claudeの回答を MR コメントに自動投稿する（15分）

Claude から返ってきた指摘内容（JSON 形式で構造化されている）をパースして、MR の「コメント」機能を使って自動投稿します。GitLab API や GitHub API を呼び出すスクリプトで実装できます。

この際、「AI による自動指摘です。最終判断は人間レビュワーに委ねます」という旨を明記しておくと、チーム内の認識がそろいやすくなります。

5. レビュワーが人間的な判断を加える（参加者次第）

AI の指摘に対して、開発者が修正するか、「このケースではこの理由で例外」と返答するかを決めます。その上で、人間レビュワーが最終チェックを行うという流れになります。

つまずきやすいところ

API キーの管理ミス

APIキーをソースコードやリポジトリに含めてしまう例をよく見ます。GitHub で公開リポジトリを使っている場合、キーが含まれるコミットを push すると、数秒以内に攻撃者に拾われる可能性があります。

対策： 絶対にファイルに直書きしない。CI/CD サービスの「環境変数」または「シークレット」機能を使い、パイプライン実行時に読み込ませます。

差分の取得漏れ

Git のオプションミスで、意図しない範囲の diff が取得されるケースもあります。特にマージコミット（複数の親を持つコミット）がある場合、git diff だけでは足りなくなります。

対策： git diff を使う際は、「MR 作成元のブランチ」と「マージ先のブランチ」を明示的に指定します。GitLab や GitHub のサービス側でも diff の取得 API が用意されているので、こちらを使う方がより確実です。

プロンプトが長すぎる・短すぎる

差分が数千行あると、プロンプトが巨大になりすぎて Claude の処理が遅くなったり、料金が高額になったりします。逆に「コード品質をチェック」だけでは Claude が具体的に何をすべきか判断できず、的外れな指摘が増えます。

対策： 大きすぎる MR は分割するよう開発ルール化する。プロンプトは「チェック項目」を明確に箇条書きにし、不要な背景説明は省く。

誤検知への対応

AI は時に「実は問題ではない」コードに対しても警告を出すことがあります。例えば「このループは効率が悪い」と指摘されたが、実際には速度が必要ない部分だった、というケースです。

対策： チーム内で「AI の指摘は参考値であり、最終判断は人間がする」という共通認識を作る。無視しても構わないし、「その指摘は今回は優先度が低い」と返答する文化を作ります。

慣れてきたら試したいこと

言語ごとの専門的なチェック

最初は「汎用的なコード品質」を見ていますが、慣れたら言語やフレームワーク固有のベストプラクティスを Claude に教えられます。例えば Python なら「type hint が欠けていないか」、JavaScript なら「非同期処理の誤りがないか」といった専門知識を込めたプロンプトにレベルアップできます。

過去のレビューコメントからの学習

チーム内で「よく指摘される点」をピックアップして、それを Claude のプロンプトに組み込むことで、よりカスタマイズされた自動レビューになります。実装パターンの歴史的な「ウチのチームはこう書く」が反映されていくわけです。

セキュリティスキャンとの組み合わせ

Claude と同時に、SAST ツール（Static Application Security Testing = 静的コード解析）やセキュリティ専門の linter も走らせることで、より多層的なチェックが実現できます。AI の判断と自動化ルールの両輪で、漏れを減らせます。

チーム内フィードバック・改善ループ

何週間か運用すると、「Claude の指摘は実は役に立った」「逆にこのタイプの指摘は当たらないな」といった傾向が見えてきます。定期的に無視されたコメント・修正されたコメントの比率を集計して、プロンプトを調整するという改善サイクルが回せます。

レガシーコードへの適用

既存の古いコード（いわゆるレガシーコード）に対しても、段階的に Claude のレビューを当てはめることで、品質を少しずつ上げていく戦略も考えられます。新規機能のコードだけでなく、保守フェーズのコード改善を加速させるツールとしても機能します。