Claude CodeとGitLab Duo Agent Platformの違い — MRとIssueで何を任せるか
GitLabに内蔵されたDuo Agent PlatformとClaude Codeの連携を、実行場所・課金・権限・前提条件で比べます。IssueからMRを作る場面でどちらに任せるかの切り分け表つきです。
GitLabでIssueからMRを作らせる手段は2系統あります。GitLabが自前で持つ「GitLab Duo Agent Platform」と、CI/CDジョブとして動かす「Claude Code」です。どちらもIssueやMRのコメントから起動でき、変更はMRとして返ってきます。違いは、エージェントがどこで動き、誰の課金で動き、どの権限を持つかにあります。
結論を先に書きます。GitLabのプランとクレジットの枠内で、GitLab上の定型作業をまとめて任せたいならDuo Agent Platformが近道です。自分のRunnerとAPIキー(またはBedrock・Google Cloud)で動かし、CLAUDE.mdとプロンプトで挙動を細かく決めたいならClaude Codeです。以下、その根拠を一次ソースに沿って分けます。
2つの仕組みは何が根本的に違うのか
Duo Agent Platformは、GitLabがソフトウェア開発のライフサイクル全体に複数のエージェントを埋め込む製品です。ドキュメントは「リニアなワークフローではなく、AIエージェントと非同期に協働する」「リファクタリングやセキュリティスキャン、調査といった定型作業を専門のエージェントに委ねる」と説明しています。エージェントも課金の単位もGitLab側にあります。
Claude Codeの連携は別物です。GitLab CI/CDのジョブの中でclaudeコマンドを走らせる構成で、Claude Code CLIとAgent SDKの上に作られています。Claude Codeのドキュメントによると、この統合はGitLabが保守するベータ版で、サポート窓口もGitLabのIssueです。Anthropicが保守するGitHub Actions版とは提供元が違う点は、Claude CodeとGitLab CI/CDの連携でも整理しています。
要するに、前者は「GitLabの機能としてのエージェント」、後者は「GitLabのRunnerで動くClaude Codeのジョブ」です。
実行場所・課金・権限を並べると
| 観点 | GitLab Duo Agent Platform | Claude Code(GitLab CI/CD) |
|---|---|---|
| 動く場所 | GitLab Duo Agent PlatformGitLabのエージェント基盤(Self-Managedでは自社インスタンス側の構成が必要) | Claude Code(GitLab CI/CD)自分のGitLab Runner上のコンテナ |
| 課金 | GitLab Duo Agent PlatformGitLabクレジットを消費 | Claude Code(GitLab CI/CD)Runnerの実行時間とトークン消費 |
| モデル | GitLab Duo Agent Platformページ上はAnthropic Claude Sonnet 4と記載 | Claude Code(GitLab CI/CD)Claude API・Amazon Bedrock・Google CloudのAgent Platformから選択 |
| 必要なプラン | GitLab Duo Agent PlatformPremium以上(機能ごとにFreeで使えるものもある) | Claude Code(GitLab CI/CD)プラン条件の記載なし(Runnerが使えること) |
| 起動 | GitLab Duo Agent PlatformIssue・MR・IDE・Duo CLI | Claude Code(GitLab CI/CD)ジョブのトリガー(手動、MRイベント、@claudeを拾う仕組み) |
| 挙動の調整 | GitLab Duo Agent Platformカスタムエージェント、カスタムフロー | Claude Code(GitLab CI/CD)CLAUDE.mdと-pのプロンプト、許可ツール |
| 成熟度 | GitLab Duo Agent PlatformGitLab 18.8で一般提供 | Claude Code(GitLab CI/CD)ベータ |
表の「動く場所」の違いが、そのまま残りの行を決めています。
前提条件はどちらが重いか
Duo Agent Platformを使うには、GitLab Duoを有効にします。GitLab Duo ProまたはEnterpriseが無い場合は、トップレベルグループまたはインスタンスでGitLab Duo Coreを有効にします。GitLab 18.8以降ではAgent Platformそのものの有効化も必要です。18.7以前はベータ・実験的機能の有効化で代替します。GitLab 18.9以前ではGitLab Duo Enterpriseアドオンと併用できず、使うには18.10以降へのアップグレードが必要です。Self-Managedはインスタンスの設定を行い、Duo Self-HostedならAI GatewayにAgent Platformサービスを入れます。
ローカル環境で使うなら、エディター拡張のインストールとGitLabでの認証、グループ名前空間にあるプロジェクト、Developer以上のロールが要ります。
Claude Code側の最短手順は、マスク付きCI/CD変数ANTHROPIC_API_KEYを1つ登録し、.gitlab-ci.ymlにジョブを1つ足すことです。GitLabのバージョン条件は記載がありません。そのぶん、本番向けにはプロバイダーの認証設計(OIDCやWorkload Identity Federation)を自分で組みます。
導入の手間は、GitLabの管理者権限とバージョン管理に寄せられるならDuo、CI/CDの設定を自分で持てるならClaude Codeが軽くなります。
IssueからMRを作る場面で何が違うか
Duo側でこの役割を担うのはDeveloper Flowです。機能一覧には「IssueをMRに変換する、またはAgentic ChatやGitLab Duo CLIでコーディングタスクを完了する」とあります。MR上では、コメントスレッドで質問や議論ができる機能、レビューのディスカッションを解析して変更をプッシュしスレッドを解決する機能、マージコンフリクトを解析して解決コミットをプッシュする機能も一般提供です。コンフリクト解決とディスカッション解決は、Freeプランでは使えません。
Claude Code側はIssueのコメントに次のように書く使い方が公式の例です。
@claude implement this feature based on the issue descriptionここで押さえたいのは、@claudeが自動で反応する仕組みはクイックセットアップのジョブに含まれない点です。コメントを検知するwebhookと、AI_FLOW_INPUT・AI_FLOW_CONTEXTを付けてパイプライントリガーAPIを呼ぶリスナーを自分で用意します。Duoなら機能として最初から用意されている部分です。
Issueを受けてMRを出すまで
Duo Agent Platform
Developer Flowを起動します。リスナーやRunnerのジョブ定義は不要で、GitLabクレジットで動きます。
Claude Code
webhookとリスナー、ジョブ、APIキー変数を自分で組みます。その代わりプロンプトと許可ツールをジョブ単位で決められます。
Claude Code側で自由度をどう使うか
Claude Codeを選ぶ理由は、ジョブの中身を自分で書けることにあります。公式サンプルは--allowedTools "Bash Read Edit Write mcp__gitlab"と--permission-mode acceptEditsで動かしますが、Bashを丸ごと許可しているので、実運用では絞る余地があります。次はレビュー専用に権限を絞った例です。公式のクイックセットアップのジョブを土台にした形で、実際の出力を示すものではありません。
claude-review:
stage: ai
image: node:24-alpine3.21
timeout: 20m
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
variables:
GIT_STRATEGY: fetch
before_script:
- apk add --no-cache git curl bash
- curl -fsSL https://claude.ai/install.sh | bash
- export PATH="$HOME/.local/bin:$PATH"
script:
- >
claude -p "Review this MR against CLAUDE.md. Do not edit files."
--max-turns 8
--allowedTools "Read Bash(git diff *)"あわせてリポジトリ直下のCLAUDE.mdに、レビューで見る観点を書いておきます。Claudeは実行中にこのファイルを読み、規約に沿って提案します。
# レビュー観点
- 公開APIの破壊的変更は必ず指摘する
- テストが無い分岐を挙げる
- 変更範囲外のファイルは編集しないDuo側にも調整手段はあり、カスタムエージェントとカスタムフローが一般提供です。複数のエージェントを組み合わせて自社の課題に当てる位置づけで、GitLab上のカタログと権限の仕組みに乗ります。ジョブ単位でコマンドラインまで握りたい場合はClaude Codeのほうが細かく決められます。
コストと上限の考え方
DuoはGitLabクレジットを消費します。一般提供の機能は消費対象で、Freeプランで使える機能でもクレジットの購入が必要です。ベータや実験的機能には、消費しないものと消費するものが混在します。ベータが一般提供になると、全バージョン・全提供形態で使用量課金に変わります。
Claude Code側は、Runnerの計算時間とトークン消費の2系統です。トークン量はタスクの複雑さとコードベースの規模で変わります。上限を掛ける手段として公式が挙げるのは、@claudeコマンドを具体的にすること、--max-turnsとジョブのtimeoutを設定すること、同時実行数を絞ることです。
課金の見通しを立てやすいのはどちらか、という問いには注意が要ります。Duoはクレジット単位でGitLabの請求に寄ります。Claude Codeは既存のAnthropic契約やクラウド契約を使えるため、調達が決まっている組織では後者のほうが話が早いことがあります。
使い分けの早見表
| 場面 | 向く選択 | 理由 |
|---|---|---|
| IssueからMRを定型的に量産したい | 向く選択Duo | 理由Developer Flowが機能として用意されている |
| レビューコメントを受けて修正を自動で反映させたい | 向く選択Duo | 理由ディスカッション解決の機能がある |
| 失敗したパイプラインの原因調査 | 向く選択Duo | 理由Fix CI/CD Pipeline Flowが一般提供 |
| 独自のプロンプトと許可ツールでジョブを固定したい | 向く選択Claude Code | 理由-pと--allowedToolsをジョブ側で決められる |
| Bedrock・Google Cloud経由で動かしたい | 向く選択Claude Code | 理由プロバイダーを選べる |
| GitLabのプランがFreeでクレジット予算が無い | 向く選択Claude Code | 理由Runnerが使えれば、APIキーで動く |
迷ったら、定型作業はDuo、手触りを細かく決めたい作業はClaude Codeと分けて併用する手もあります。ただし両者が同じIssueに反応すると、同じ内容のMRが2本できる可能性があります。トリガーの条件は排他になるよう分けておきます。
Duo側のMCPとの関係
Duo側にはMCPの機能が2つあります。MCP clientsとMCP serverです。MCP serverはGitLabインスタンスに外部のAIツールを安全につなぐ機能で、全プランで使えます。つまりClaude Codeから見て、GitLabのデータをMCP経由で読む入り口がDuo側にも用意されています。MCP clients自体はクレジットを直接消費しませんが、MCP client経由のモデル要求などAgent Platformの利用が消費につながる可能性があります。
GitKrakenのプラグインでGitHubとGitLabを横断する方法はClaude CodeでGitKrakenプラグインを使う手順に、手元の対話セッションでglabとMRを結びつける方法はClaude CodeとGitLabの連携方法にあります。クラウド側のエージェントとの比較は、GitHub側の例ですがClaude Code on the webとCopilot cloud agentの違いが同じ軸で書かれています。
まとめ
Duo Agent Platformは、GitLabのプランとクレジットを土台に、IssueからMRまでの定型作業を機能として受け持つ基盤です。Claude Codeは、自分のRunnerで動くジョブとして、プロンプト・許可ツール・認証経路を自分で決める部品です。前者は導入が軽く、後者は調整の余地が広いというのが両者の本質的な差です。
選ぶ前に確かめるのは3点です。GitLabのバージョンとプラン(Duoの前提条件)、クレジットを使えるか、Runnerとモデルの契約が決まっているか。GitLabがバージョンの壁になっている環境ではClaude Code、契約がGitLabに集約されている環境ではDuoが素直な出発点になります。