世の中ではDevinやGithub CopilotなどのAIコードレビューが定着しつつあります。
しかし、セルフホストGitLabを利用している企業では、対応製品が少なかったりサードパーティ製品のセキュリティチェックや保守が気になってしまい導入が進めづらいと思います。
エムスリーでは、Claude CodeとGitLab CIを組み合わせ、わずか9行でAIコードレビュー導入が可能な仕組みを構築しました。
【Unit1 ブログリレー1日目】Unit1(製薬企業向けプラットフォームチーム)のチームリーダーの佐野です。本日からUnit1のブログリレーが開始されます🎉
趣味は業務改善で、SlackWFやClaude Code、GASなど手軽に使える様々なツールを組み合わせて新しい仕組みを日々発明することを考えています。
最近はspec駆動開発の社内用フレームワークを作れないか考え中です。

本題に戻ります。この記事を読むと以下のことが分かるようになりますので、ぜひご一読いただければと思います。
- セルフホストGitLabで全リポジトリに爆速でAIコードレビューを導入する方法
- AIコードレビューの個別カスタマイズ対応の仕組み
tl;dr
百聞は一見にしかず。まずは以下のGitLab CIの9行のyamlをご覧ください。
include: - project: 'm3/ci-templates' file: '/ai-code-review/ai-code-review.yml' ai_code_review_job: stage: test extends: .ai-code-review-wif variables: AI_CODE_REVIEW_WORKFLOW_FILE_PATH: "my_project_rules/code_review_guidelines.md" # 上書きする場合に指定。デフォルトはdocs/code_review.md AI_CODE_REVIEW_ADDITIONAL_PROMPT_TEXT: "特にセキュリティに関する観点からレビューを強化してください。" # 追加指示を出す場合に指定。デフォルトは空文字
エムスリーの場合、どのリポジトリでもこの9行を追加するだけでAIコードレビューが即座に利用可能になります。
この仕組みを支えているのは、7月に公開された横本さんの以下の記事で紹介されている「Workload Identity Federation (WIF)」です。
WIFを利用することでAPI Keyを配布/管理することなく、GitLab CI上でClaude Codeが利用可能になります。
課題と解決アプローチ
導入背景:コードレビューの現実的課題
まず、なぜAIコードレビューを導入するに至ったのか、当時の課題から説明します。
おそらくどこの会社でもよくある課題かと思います。
- 人によってコードレビューの深さや観点が異なる
- コードレビューの負担が特定の人に集中してしまう
- 大きな変更のレビューは読み始めるまでが大変
AIコードレビューによってこれらの課題が解決できると考え、導入を決定しました。
1. 人によってコードレビューの深さや観点が異なる
- レビュー観点をドキュメント管理し育てていくことで品質を底上げできる
- 最新のベストプラクティスを与えることで一定の品質を担保できる
2. コードレビューの負担が特定の人に集中してしまう
- AIコードレビューが読み込ませたドキュメントや指示の通り1回レビューしてくれるので、レビュー負担が軽減される
- チームで観点を育てていくため全員がレビューに気軽に参加できるようになる
- 社歴が浅かったりレビューが苦手な人でもレビュー観点ドキュメントを読むことで勉強できる
3. 大きな変更のレビューは読み始めるまでが大変
- AIコードレビューがまず全体をレビューしてくれるため、人間はAIの指摘を確認しつつより深い観点でレビューできる
- まっさらな状態からコードを読むよりも、AIが指摘した箇所を中心にレビューする方が圧倒的に楽
なぜClaude Codeを選んだのか
エムスリーでAIコードレビューの仕組みが広まっていったのは2025年5月でした。
この当時はまだあまりAIコードレビューの選択肢が多くありませんでした。
Visual Studio CodeでClineやRoo Codeを使うのが主流でCLI型AIコーディングエージェントはまだ登場したばかりでした。
そのため、AIによるコードレビューの選択肢は大きく2つでした。
- ローカルのVisual Studio Code上でClineやRoo Codeを使ったコードレビュー
- GitLab CI上でCLI型AIコーディングエージェントを使ったコードレビュー
どちらもAIコーディングエージェントにレビューをしてもらうのは同じですが、運用面で大きく異なります。
| 比較項目 | ローカルでのAIコードレビュー (Visual Studio Code) | GitLab CI上でのAIコードレビュー |
|---|---|---|
| 実行の強制力 | 🤔 個人の意思に依存する | ✅ CI/CDパイプラインで自動実行され、徹底を担保できる |
| レビュー準備 | 🤔 レビュー対象のブランチをローカルに取得する手間がかかる | ✅ マージリクエストの情報がそのまま使える |
| 導入・横展開 | ✅ 環境構築が不要で手軽に始められる | ✅ 仕組みの横展開が可能で組織全体へのスケール効果が高い |
| コスト・ROI | ✅ 最小限のレビュー実行になるためROIは高い | ⚠️ AIのレビュー精度が低いとROIが悪化するリスクがある |
上記のように比較検討し、将来的に価値が大きいGitLab CI上でのAIコードレビューを選択しました。
実装と段階的展開
AIレビューの実装
tl;drでご紹介したように、GitLab CIのyamlを9行追加するだけでAIコードレビューが導入できるのですが、最も重要なincludeするもとになっているyamlファイルの紹介をします。
Claude Codeは -p オプションを利用し、「SDK経由でクエリを実行し、終了」という挙動をさせます。
これにより対話形式が起動することなく自律してコードレビューを完了してくれます。
紹介用に少し簡略化したもののため、ご利用される際は詳細を理解の上カスタマイズしてご利用ください。
特に以下の点に気をつけてください。
selfhost.gitlab.comは貴社のセルフホストGitLabのドメインに置き換えてください- GCP Vertex AIを利用する例です
簡略化しましたが、ほぼそのままのため、すぐご利用できるかと思います。
.ai-code-review: image: public.ecr.aws/docker/library/node:24 needs: [] variables: ANTHROPIC_MODEL: "claude-sonnet-4@20250514" ANTHROPIC_SMALL_FAST_MODEL: "claude-3-5-haiku@20241022" CLAUDE_CODE_USE_VERTEX: "1" CLOUD_ML_REGION: us-east5 ANTHROPIC_VERTEX_PROJECT_ID: xxxxxxxxx AI_CODE_REVIEW_WORKFLOW_FILE_PATH: "docs/code_review.md" AI_CODE_REVIEW_ADDITIONAL_PROMPT_TEXT: "" MCP_CONFIG: '{"mcpServers":{"mcp-gitlab":{"transportType":"stdio","command":"npx","args":["-y","@zereight/mcp-gitlab"],"autoApprove":["get_merge_request","get_merge_request_diffs","create_merge_request_thread","create_note","list_merge_request_discussions","create_merge_request_note"]}}}' ALLOWED_TOOLS: "WebFetch(domain:selfhost.gitlab.com) mcp__mcp-gitlab mcp__mcp-gitlab__get_merge_request mcp__mcp-gitlab__get_merge_request_diffs mcp__mcp-gitlab__create_merge_request_thread mcp__mcp-gitlab__create_note mcp__mcp-gitlab__list_merge_request_discussions mcp__mcp-gitlab__create_merge_request_note" # mcp-gitlab の環境変数 # CLAUDE_AI_REVIEWER_TOKENはGitLabのリポジトリでCI/CD変数に設定する GITLAB_PERSONAL_ACCESS_TOKEN: "${CLAUDE_AI_REVIEWER_TOKEN}" GITLAB_API_URL: "https://selfhost.gitlab.com/api/v4" GITLAB_READ_ONLY_MODE: false script: - npm install -g @anthropic-ai/claude-code - echo "${MCP_CONFIG}" > mcp.settings.json - | FILE_PATH=${AI_CODE_REVIEW_WORKFLOW_FILE_PATH:-"docs/code_review.md"} if [ ! -r "$FILE_PATH" ]; then echo "$FILE_PATH が見つかりません"; exit 1; fi if [ -n "${CI_MERGE_REQUEST_IID}" ]; then # マージリクエストパイプラインの場合 MR_INFO="merge_request_iidは ${CI_MERGE_REQUEST_IID} です。" else # ブランチパイプラインの場合 MR_INFO="対象のmerge_request_iidはブランチ名を元に get_merge_request で取得してください。ブランチ名は ${CI_COMMIT_BRANCH} です。" fi PROMPT_STRING=" マージリクエストの差分を見て日本語でコードレビューをしてください。コードレビューは ${FILE_PATH} に従ってください。 gitlab のレポジトリです。project_idは ${CI_PROJECT_ID}、 ${MR_INFO} レビュー結果はメンション付きでマージリクエストにコメントするため、出力の先頭に @${GITLAB_USER_LOGIN} を入れてください。 具体的に指摘できる箇所があれば create_note ではなく create_merge_request_thread でコードの箇所を指定してコメントを残してください。 必ず最初に list_merge_request_discussions を実行し、既存のディスカッションをすべて確認してください。 ${AI_CODE_REVIEW_ADDITIONAL_PROMPT_TEXT:-} " claude --model ${ANTHROPIC_MODEL} --mcp-config mcp.settings.json --allowedTools ${ALLOWED_TOOLS} -p "${PROMPT_STRING}" rules: # Draftの場合、手動実行 - if: '$CI_MERGE_REQUEST_DRAFT == "true"' when: manual allow_failure: true # Draftではない通常のMRの場合、自動実行 - if: $CI_PIPELINE_SOURCE == "merge_request_event" allow_failure: true .ai-code-review-wif: extends: .ai-code-review variables: GOOGLE_CLOUD_PROJECT: "xxxxxxxxx" SERVICE_ACCOUNT_EMAIL: "xxxxxx@xxxxxxx.iam.gserviceaccount.com" WORKLOAD_IDENTITY_PROVIDER: "xxxxxxx" id_tokens: GITLAB_OIDC_TOKEN: aud: https://selfhost.gitlab.com script: - echo "Checking OIDC token availability..." - echo "GITLAB_OIDC_TOKEN length:" $(echo -n "$GITLAB_OIDC_TOKEN" | wc -c) - | if [ -z "$GITLAB_OIDC_TOKEN" ]; then echo "No OIDC token found" exit 1 fi - echo "Installing Google Cloud SDK..." - curl -O https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-cli-linux-x86_64.tar.gz - tar -xf google-cloud-cli-linux-x86_64.tar.gz - ./google-cloud-sdk/install.sh --quiet - export PATH="./google-cloud-sdk/bin:$PATH" - echo $GITLAB_OIDC_TOKEN > /tmp/gitlab_token - echo "Creating Workload Identity Federation credential configuration..." - | gcloud iam workload-identity-pools create-cred-config \ $WORKLOAD_IDENTITY_PROVIDER \ --service-account=$SERVICE_ACCOUNT_EMAIL \ --output-file=/tmp/credential_config.json \ --credential-source-file=/tmp/gitlab_token - export GOOGLE_APPLICATION_CREDENTIALS=/tmp/credential_config.json - gcloud config set project $GOOGLE_CLOUD_PROJECT - gcloud auth login --cred-file=/tmp/credential_config.json - !reference [.ai-code-review, script]
上記のyamlを使ったAIコードレビューは以下の図のようなフローとなります。
実際は3と4の間にinstallやWIF認証等のscript処理が入ります。

小さく始めて大きく広げる
Claude CodeによるAIレビューの実装をご紹介しましたが、最初からこのような構成になっていたわけではありません。
MVP(Minimum Viable Product)の考え方で、最初はAPI Keyと特定のリポジトリのみで動作するCIから始めました。
このプロトタイプの段階では、AIレビューの精度が低く価値あるレビュー結果はあまり得られませんでした。
そこで、AIコードレビューの観点をファイルで与えられるようにしたり、追加の指示を与えられるようにしました。
その結果、現在では下記の記事のように、各チーム毎にレビュー観点を育てるという概念が生まれました。
効果と今後の展望
改善効果の調査結果
今ではAIによる自動コードレビューは1週間に200投稿以上されるようになりました。
コードレビューの時間の長さは計測しづらいため実数値での比較は難しいですが、AIコードレビュー導入後に色々な人にインタビューした結果、以下のような効果が得られたと感じています。
- タイポや簡単なミスの見落としが減った
- プロジェクト特有の暗黙知をレビューしてくれるので、レビュアーはより深い観点でレビューできる
- ドメイン知識やプロジェクト固有の背景による暗黙ルールがドキュメント管理され見える化された
- エラー再発防止の観点をレビューに組み込めるようになった
まとめ
私が感じるAIコードレビューを導入した一番の効果は、コードレビューそのものに興味が向くようになったことです。
どうしたらより良い指摘をしてくれるようになるか、ドメイン知識や暗黙知を読み込ませられないか、この言語/フレームワークのベストプラクティスを理解させてレビューできないか、など。
コードレビューでは小さなバグや仕様と異なる挙動の検知だけではなく、重大な障害につながるセキュリティに関してもレビューする必要があり非常に重要な業務です。
コードレビューを効率化することでプロダクト開発が加速し、事業価値が向上することを期待しています。
ちなみに、エムスリーでは現在GitHub移行を進めています。
現在のGitLab上の仕組みはGitHubのAIレビューサービスと精度、カスタマイズ性、費用等を勘案しながら移行を検討しています。
GitHub移行の記事はこちら www.m3tech.blog
We are hiring!!
エムスリーでは最新のAIツールをつかった業務改善も可能です!
AIを活用して開発効率を圧倒的に向上させているエンジニアもいます!
プログラミングと最新技術が大好きなエンジニアを募集しています! ご興味のある方は、ぜひ下記リンクからご応募ください。