GitLab Duo Agent Platformとは？GA後の機能とGitLab Creditsの実費を解説

GitLab Duo Agent Platformは、ソフトウェア開発ライフサイクル全体に複数のAIエージェントを組み込み、それらを束ねて動かすためのGitLabの機能群です。2026年1月15日の一般提供開始（GA）以降、この機能群の課金はGitLab Creditsという従量制で行われます。従来のGitLab Duo ProとDuo Enterpriseはアドオンのシート課金のまま残るため、シート課金が丸ごと置き換わったわけではありません。Agent Platformを使うぶんだけ、何をどれだけ実行すると費用がいくらになるのかが導入判断の中心になります。

この記事は、公式ドキュメントとプレスリリース・料金ページを2026年9月時点で確認し、プラン別の可否・クレジットの実費・フローの一覧・有効化手順・サービスアカウントの権限設計をまとめたものです。料金とモデルとサンドボックスの条件はGitLab側の変更が速いため、各章に公式ページへのリンクを置いています。バージョンは記事作成時点の最新リリースである19.4を基準にしています。

まとめ

• GitLab Duo Agent PlatformはGitLab 18.8でGAしました。プレスリリースの日付は2026年1月15日です。ベータでの登場は18.2です。
• ティア表記はPremiumとUltimateですが、GitLab.comのFreeネームスペースは18.10からクレジットを購入して一部機能を使えます（Self-Managedは19.0から）。
• 課金単位はGitLab Creditsで、追加分の定価は1クレジットあたり1ドルです。Premiumは12クレジット／ユーザー／月、Ultimateは24クレジット／ユーザー／月が付属しますが、これはGA後の期間限定のプロモーションで、GitLabの裁量で変更されると明記されています。
• 消費量は機能ごとに定額のものとモデル呼び出しごとのものがあります。Code Suggestionsは1クレジットで50回、Code Review Flowは4回、SAST Vulnerability Resolution Flowは0.25回（＝1回に4クレジット）です。
• GitLab Duo ProとEnterpriseの機能は従量課金の対象外でクレジットを消費しません。ただし18.9以前はDuo EnterpriseアドオンとAgent Platformを併用できません。
• フローはサービスアカウントとコンポジットアイデンティティで実行され、実行者の権限とサービスアカウントの権限の狭いほうが適用されます。

GitLab Duo Agent Platformの位置づけとGAまでの経緯

公式ドキュメントは、GitLab Duo Agent Platformを「ソフトウェア開発ライフサイクル全体に複数の知的アシスタント（エージェント）を組み込むAIネイティブなソリューション」と説明しています。直線的なワークフローに沿って作業するのではなく、AIエージェントと非同期に協働し、コードのリファクタリングやセキュリティスキャン、調査といった定型作業を専門のエージェントへ委譲する、という位置づけです。

GitLabがこの製品で掲げている問題意識は、プレスリリースに明記されています。AIによってコードを書く速度は上がったが、開発者が実際にコードを書いている時間は全体の約20%に過ぎないため、開発全体の速度改善は限定的にとどまる、というものです。GitLabはこれを「ソフトウェアデリバリーにおけるAIパラドックス」と呼んでいます。この20%という数字はGitLab自身が前提として置いている主張であり、独立した調査の結果として示されているものではない点は押さえておいてください。

実体としては、以下の機能の集合です。対話型のエージェント型チャット、GitLabが作り込んだ基盤フロー、利用者が組むカスタムフロー、それらを共有するAI Catalog、そして実行を統制するコンポジットアイデンティティとモデル選択です。

GitLab Duo Agent Platformの対応プランと利用条件

ドキュメントの製品ページはティアをPremiumとUltimateと表記していますが、機能一覧の表にはFree列があり、注記として「Freeティアで利用できる機能にはGitLab Creditsの購入が必要」と書かれています。つまりPremium契約がなくてもクレジットを買えば一部機能に触れます。ただしFreeネームスペースのオンデマンド利用には月25,000ドルの上限があり、到達すると自動的に停止して翌月頭にリセットされます。

プラン別の主な可否は次のとおりです。

なお表記には注意が必要です。この可否はAgent Platformの製品ページが持つ機能一覧の表に従っていますが、基盤フローの個別ページはティアをPremiumとUltimateと表記しており、公式ドキュメント内で記述が揃っていません。Freeでの利用を前提に設計するなら、対象機能ごとに現物で確認してください。

有料プランの価格は、料金ページの記載でPremiumが1ユーザーあたり月29ドル（年払い）、Ultimateは個別見積りです。

前提条件で見落としやすいのが次の3点です。

• GitLab Duo Enterpriseとの併用にはバージョン条件がある。ドキュメントは「18.9以前ではGitLab Duo EnterpriseアドオンとAgent Platformを併用できない。併用するには18.10以降へアップグレードする」と明記しています。Duo Enterpriseを買っているのに有効化できない、という詰まり方をします。
• Duo Pro／Enterpriseを持たない場合はGitLab Duo Coreを有効にする。最上位グループまたはインスタンスに対して設定します。
• 個人ネームスペースのプロジェクトでは使えない。ローカル環境で使うには、グループネームスペース配下のプロジェクトであること、DeveloperまたはMaintainerかOwnerのロールを持つこと、エディタ拡張を入れてGitLabに認証していることが要ります。

GitLab Creditsの実費と1クレジットあたりの実行回数

GitLab Creditsは従量課金の共通通貨で、Agent Platformと一部の非エージェント機能の利用に対して消費されます。課金はプロジェクト単位ではなくルートネームスペース（最上位グループ）単位で集計され、消費は実行した主体に紐づきます。主体には人間のユーザーだけでなく、サービスアカウントや自動フローを動かすボットのような非人間の主体も含まれます。

クレジットの入手経路は通常3つで、消費される順序が決まっています（GitLab Credits and usage billing）。

1. 付属クレジット。PremiumとUltimateの各ユーザーに割り当てられます。料金ページの記載ではPremiumが12クレジット／ユーザー／月、Ultimateが24クレジット／ユーザー／月です。個人に割り当てられるため他のユーザーと共有できず、毎月初にリセットされて繰り越しはありません。GitLabはこれを「GA後の限られた期間のプロモーション」であり裁量で変更すると明記しているので、恒久的な条件として見積もらないでください。コミュニティプログラムの契約には付属クレジットがありません。
2. 月次コミットメントプール。組織で共有する購入済みのプールです。年単位または複数年で購入し、年間購入数を12で割った量が毎月使えます。増額は随時できますが、減額は更新時のみです。こちらも繰り越しはありません。
3. オンデマンドクレジット。付属分とプールを使い切った後の従量分で、定価は1クレジット1ドルです。利用には従量課金規約への同意が必要で、一度同意すると契約期間中は取り消せません。

この3つとは別に、評価用の一時クレジットがあります。月次コミットメントプールを購入しておらず従量課金規約にも同意していない段階で、営業に連絡すると発行を依頼できるものです。評価する人数に応じて共有プールへ割り当てられ、有効期限は30日で、期限を過ぎると使えません。消費順序では付属クレジットの次に使われ、月次コミットメントプールより先に減ります。

機能ごとの定額消費

一部の機能は、内部で何回モデルを呼んだかにかかわらず、1回の実行あたり決まった量を消費します。セルフホストモデルで動かす場合の20%割引は19.1でself_hosted_flat_pricing_discountという機能フラグ付きで入ったもので、ドキュメントは提供可否がこのフラグで制御されると明記しています。次の表のセルフホスト欄は、割引が適用されている場合の値です。

1回あたりの定価換算はオンデマンドの1クレジット1ドルで割り戻した値です。SAST脆弱性解決フローは1回で4クレジットを使うため、人間ユーザーに課金が帰属する場合、Ultimateの付属24クレジットは同フロー6回分です。非人間主体には付属クレジットがなく、月次コミットメントプールまたはオンデマンドから消費されます。脆弱性を一括処理する運用なら付属分だけでは足りないので、月次コミットメントプールを購入するか、オンデマンドだけで賄うかを先に決めてください。プール購入時にもオンデマンド利用を含む従量課金規約へ同意するため、プールを使い切れば追加課金が発生します。

モデルごとの消費

エージェント型チャットのように定額でない機能は、LLMの呼び出し1回を単位として課金されます。1クレジットで何回呼べるかはモデルごとに異なり、新しく複雑なモデルほど回数が少なくなります。ドキュメントの倍率表から代表的なものを抜き出すと次のようになります。

セルフホストモデルは、対応モデルであれば一律で1クレジットあたり8回です。

注意したいのは、ユーザーから見た1回の操作が必ずしもモデル呼び出し1回ではないことです。ドキュメントは「1つのユーザーリクエストが複数のモデル呼び出しを引き起こすことがある。たとえばコンテキストを理解するための呼び出しと、応答を生成するための呼び出し」と説明しています。チャットに1回質問した結果が1クレジット分の1回で済むとは限りません。

環境によって異なる失敗時の課金

GitLab.comでGitLab提供モデルを使っている場合、完了前に失敗したフローはクレジットを消費しません。すでにLLMを何回か呼んでいてもです。一方でGitLab Self-Managedでセルフホストモデルを使い、定額課金でない機能を動かしている場合は、呼び出しが開始された時点で計測されるため、途中で失敗しても開始済みの呼び出し分は課金されます。これとは別に、定額課金の機能では、失敗しても呼び出し回数にかかわらず定額の全額が請求されるという扱いがあり、これもドキュメントがセルフホストモデルを使うGitLab Self-Managedの説明として書いているものです。GitLab提供モデルのGitLab.comについては、完了前に失敗したフローはクレジットを消費しないとだけ書かれています。

エージェント型チャットとフローの使い分けと作り込み

Agent Platformの機能は、人が対話しながら進めるエージェント型チャットと、定義済みの手順を自律実行するフローに分かれます。

エージェント型チャットが横断できる範囲と、検索がキーワードベースである制約

従来の非エージェント型チャットが単一のコンテキストで答えるのに対し、エージェント型チャットは複数のプロジェクトを横断して検索・取得・統合したうえで回答します。イシューやマージリクエストの検索、ローカルファイルへのパス指定なしのアクセス、複数箇所のファイル作成・編集ができ、Web UIではコミットも作れます。ただしこの検索はキーワードベースでセマンティック検索ではないとドキュメントが明記しています。使える場所はGitLab UI、VS Code、JetBrains系IDE、Windows版Visual Studio、GitLab Duo CLIです。

基盤フロー11本の一覧と、UIで動かすときの実行条件

基盤フローはGitLabが構築・保守する既製のワークフローで、AI Catalog上でGitLab保守のバッジが付きます。2026年9月時点で提供されているのは次の11本ですが、提供段階と課金の扱いは揃っていません。11本のうち8本が一般提供でクレジットを消費し、Security Reviewはベータでクレジットを消費、Agentic Breaking Change ResolutionとRecommend Reviewersはベータまたは実験段階でクレジットを消費しません。ドキュメントは、ベータの機能が一般提供へ変わった時点で全バージョン・全提供形態において課金対象になると明記しているので、消費しない前提で運用を組まないでください。

UIから動かす基盤フローはGitLab CI/CD上で実行されます。そのため前提として、最上位グループで基盤フローを許可する設定、サービスアカウントを許可するプッシュルールの設定、そして自前ランナーまたはGitLabホステッドランナーの用意が要ります。自前ランナーには通常、インスタンスへの登録または最上位グループへの割り当て、gitlab--duoタグ、Dockerイメージに対応したexecutor（docker・docker-autoscaler・kubernetes）が必要です。このタグが無いとフローのジョブは延々とキューに残り続け、shell executorは非対応です。最上位グループでIPアドレス制限をかけている場合はホステッドランナーを使えない（動的IPのため許可リストに載せられない）ので、最上位グループに自前のグループランナーを置くことになります。コンピュート時間を消費する点は通常のパイプラインと同じです。

運用上の落とし穴を1つ挙げます。GitLab側で基盤フローをオフにしても、IDEやGitLab Duo CLIのセッションからは引き続き実行できます。ドキュメントはこの設定が「GitLab内で動くフロー」を制御するものであり、利用者が自分で動かすフローは対象外だと明記しています。組織としてフローを止めたつもりでも、手元では動き続けます。

カスタムフローの共有とAI Catalogの版管理・版固定

カスタムフローは18.8でベータ、19.2で一般提供になりました。作成したエージェントやフローはAI Catalogで共有します。AI Catalogには版管理があり、カスタムエージェントのシステムプロンプトを更新したり外部エージェントの構成を変更したりすると、自動的に新しい版が作られます。版は不変で、グループで有効にすると最新版が固定され、そのアイテムを管理していないプロジェクトでは所属する最上位グループと同じ版が固定されます。カタログ側の更新が勝手に手元の挙動を変えない設計です。例外はアイテムを管理しているプロジェクト自身で、ここでは版が固定されず常に最新版が使われます（18.10で導入）。18.10より前に管理元プロジェクトで有効化していた場合は固定されたままで、一度手動で最新版へ更新すると、以降は自動的に最新版を使う挙動に切り替わります。基盤のエージェントとフローには版管理がありません。

AGENTS.mdによる指示の共通化とCode Review Flowの除外

リポジトリ構成やコーディング規約、ビルド・テストの手順をエージェントへ渡すにはAGENTS.mdを使います。GitLab 18.8で一般提供になり、GitLab Duo Chatと基盤フローでは置くだけで読み込まれます。ただしカスタムフローでは自動では読まれません。ドキュメントは前提条件として、フローの構成ファイル側で実行体から渡されるcontext:inputs.user_ruleを受け取る設定を加えるよう求めています（optional: trueを付ければAGENTS.mdが無い場合も落ちません）。自作フローに規約が反映されない場合は、まずこのコンテキスト入力の設定を確認してください。

ただしCode Review Flowだけは対象外とドキュメントに明記されています。レビューの観点をAGENTS.mdに書いても反映されません。レビュー向けにはカスタムレビュー指示という別の仕組みが用意されています。

配置場所は3階層あり、使う場所によって効く階層が違います。ユーザーレベルはLinuxとmacOSでは~/.gitlab/duo/AGENTS.md、Windowsでは%APPDATA%\GitLab\duo\AGENTS.mdに置きます。プロジェクトレベルはリポジトリ内、サブディレクトリレベルはモノレポの構成要素ごとに置きます。このうちGitLab UIで効くのはプロジェクトレベルだけで、ユーザーレベルとサブディレクトリレベルはエディタ拡張とGitLab Duo CLIでのみ有効です。エディタ側の必要バージョンはVS Code拡張が6.60以降、JetBrains向けプラグインが3.26.0以降、GitLab Duo CLIが8.47.0以降です。

更新した内容が効くのは、追加・更新より後に開始した会話とフローだけです。既存の会話には遡って適用されません。

agent-config.ymlによる実行環境の固定

UIから動くフローはCI/CD上で実行されるため、実行環境を明示的に固定できます。設定ファイルはプロジェクトの.gitlab/duo/agent-config.ymlで、既定ブランチからのみ読み込まれます。他のブランチにコミットしたものは、そのブランチからフローを動かしても無視されます。設定を勝手に緩められない作りです。

# .gitlab/duo/agent-config.yml
# このイメージにはSRTがないため、下記network_policyは適用されません。
image: python:3.11

setup_script:
  - apt-get update && apt-get install -y build-essential
  # pipの既定キャッシュはホーム配下なので、cache.pathsと保存先を揃える
  - pip install --cache-dir .cache/pip -r requirements.txt

cache:
  key:
    files:
      - requirements.txt
    prefix: python-deps
  paths:
    - .cache/pip

network_policy:
  include_recommended_allowed: true
  allowed_domains:
    - my-own-site.com
  denied_domains:
    - malicious.com

実務で効くのはnetwork_policyですが、効くのはサンドボックスが適用されているときだけです。上の例のようにpython:3.11という素の公式イメージを指定すると、後述のSRTが入っていないためサンドボックスは適用されず、通信制限もかかりません。通信を絞るなら、GitLab既定のイメージ（v0.0.6以降）を使うか、カスタムイメージにSRTを入れたうえで特権ランナーモードを有効にしてください。そのうえでnetwork_policyは、エージェントの実行環境からの通信先を許可・拒否のドメイン一覧で制御でき、それぞれ最大1,000件まで指定できます。include_recommended_allowedはGitLabが推奨する許可ドメインをまとめて含める指定で、既定はfalseです。cache.key.filesで指定できるファイルは最大2件です。なおこのファイルには定義済みCI/CD変数を使えません。

ただしsetup_scriptは扱いが別です。ドキュメントは、setup_scriptのコマンドがサンドボックス（SRT）の適用前にその外側で実行され、フロー内のすべての環境変数（実行を起こしたユーザーのOAuthトークン、サービストークン、身元情報を含む）にアクセスできると明記しています。agent-config.ymlへの変更は実質的に認証情報へ触れられる変更なので、既定ブランチの保護とマージリクエストのレビュー対象として扱ってください。

GitLab 19.2で入ったDuo CLIやカスタムフローのGAについてはGitLab 19.2とは？Duo CLI・カスタムフローGAで変わる開発運用で扱っています。

GitLab Duo Agent Platformの既定モデルと選択範囲

機能ごとに既定モデルが決まっています。ドキュメントは、GitLabが性能を最適化するために既定モデルを更新することがあり、その変更はAI Gateway側から来るため自分のGitLabのバージョンに関係なく反映されると書いています。これは「既定のまま使っている場合」の話です。機能によっては明示的に別のモデルを選べて、選んだモデルは自分で変更するまで維持されます。ただし維持されるのは選択肢に残っている間だけで、サポート対象から外れれば使えなくなります（下記のClaude Sonnet 4.5が実例です）。2026年9月時点の既定は次のとおりです（Agent Platform AI models）。

選択できるモデルの幅は機能によって大きく違います。エージェント型チャットとその他のエージェントはClaude、Gemini、GPT、GLM、Kimi、MiniMaxを含む30種類以上から選べますが、Code Review FlowはClaude Sonnet 4.6、Claude Sonnet 5、GPT-5.2、GPT-5.3 Codexの4つだけです。Code Review Flowの設定は19.1から他の機能と分離され、Agentic Code Reviewという独立した設定になりました。なおClaude Sonnet 4.5は2026年8月10日にCode Review Flowのサポート対象として非推奨となり、8月25日に削除されています。チャットで使えるモデルがレビューでも使えるとは限らない、という前提で設計してください。

19.1からは、エージェント型チャットで使えるモデルを特定のものに限定する設定も追加されています。コストを読みたい組織は、1回の呼び出しで消費するクレジットが大きいモデル（前の表で1クレジットあたりの回数が少ないもの）を選択肢から外すのが直接的な手段です。ただし絞れるのはチャットの選択肢で、既定モデルは常に利用可能で選択肢から外せません（保存するには既定モデルに加えて最低1つ選ぶ必要があります）。Code Review FlowやSecurity Review Flowのように選べるモデルがもともと限られている機能もあるため、機能ごとに効き方が違う点も押さえてください。

GitLab Duo Agent Platformの有効化・権限・実行環境

まず押さえておきたいのは、Agent Platform自体は既定でオンだという点です。ドキュメントは「GitLab Duo Agent Platform is on by default」と書いています。オンオフを切り替えられるのはGitLab.comでは最上位グループ単位、GitLab Self-Managedではインスタンス単位で、Ownerロールまたは管理者が「設定」から「GitLab Duo」を開き、構成の変更画面にある「Turn on GitLab Duo Agentic Chat, agents, and flows」のチェックで操作します。オフにするとフローと基盤エージェントの関連設定、およびAI Catalogが画面から消えます。GitLab Self-Managedでこの設定を使うには、有効なDuo Pro／Enterprise／Self-Hostedのいずれかの有償アドオン、または有効なGitLab Creditsが要ります。

そのうえでフローを動かすには、フロー実行の許可と基盤フローの許可という2段階の設定を、上位から順に入れていきます。GitLab.comの最上位グループであればOwnerロールで構成の変更画面からフロー実行の許可と基盤フローの許可にチェックを入れ、使うフローを個別に選びます。プロジェクト側ではMaintainerまたはOwnerロールで、設定の一般からGitLab Duoを展開し、同じトグルを入れます。上位でオフになっていると下位では入れられません。

GitLab Self-Managedの場合は管理者がインスタンス全体で同じ設定を入れます。基盤フローのイメージ取得元は管理画面のイメージレジストリ欄で指定します。レジストリのホスト名だけを入れて既定イメージをそこから取りに行かせるか、19.0で対応したregistry.example.com/group/project/image:tagのような完全なイメージ参照でイメージごと上書きするかを選べます。空欄なら既定のregistry.gitlab.comを使います。閉域環境でイメージを内部に置きたい場合の出口がここです。GitLab Duo Self-Hostedでモデルまで自前にする場合は、AI GatewayにAgent Platformサービスを入れてインスタンスを構成する必要があります。

サービスアカウントとコンポジットアイデンティティ

フローやエージェントがランナー上で実行されるとき、認証にはコンポジットアイデンティティという仕組みが使われます。これは「実際に操作するサービスアカウント」と「リクエストを開始した人間のユーザー」という2つのアイデンティティを、1つのトークンに束ねたものです。18.8で一般提供になり、18.9からはAgent Platformに自動で組み込まれたため、オンオフの設定自体がなくなりました。

権限の決まり方が重要です。フローをプロジェクトで有効にすると、最上位グループにai-flowname-groupnameのような名前のサービスアカウントが作られ、Developerロールでプロジェクトに追加されます。フローを実行すると、実行者のロールとサービスアカウントのDeveloperロールのうち制約の強いほうが採用されます。実行者がMaintainerでもサービスアカウントがDeveloperなら、フローはDeveloper相当の権限で動きます。アクセスできるプロジェクトも、実行者とサービスアカウントの両方がアクセスできるものの積集合です。人間の権限をそのまま引き継ぐのではなく、意図的に交差させて権限昇格を防いでいます。

一方で、フローが作ったマージリクエストはサービスアカウントではなく実行した人間のユーザーに帰属します。職務分離を求めるコンプライアンス要件に合わせるためです。またコンポジットアイデンティティはランナー上で動くフローとエージェント（基盤フロー、カスタムフロー、外部エージェント）に適用されるもので、UIやIDEのエージェント型チャットには適用されません。チャットは実行者自身の権限で動きます。

実行環境ごとに異なるリスクの大きさ

もう1つ設計に効くのが、同じエージェントでも動く場所によって守りの強さが違うことです。ドキュメントはプロンプトインジェクションの危険度を「機微なシステムへのアクセス」「信頼できないコンテンツへの露出」「承認なしの自律実行」の3要素（lethal trifecta）で整理し、実行環境ごとに次のように評価しています。

この表はドキュメントが「エージェントとフローが利用可能なすべてのツールにアクセスできる」場合として示しているもので、CI上のフローの優位はサンドボックスが実際に効いていることが前提です。外部通信の遮断も全面遮断ではなく、許可リスト方式です。実行時に書き出される設定を見ると、既定の許可先にはgitlab.comや*.gitlab.com、エージェント基盤のホストが含まれており、そこへの通信は通ります。

そしてサンドボックスは、次の条件を満たさない構成では適用されないまま実行されます。

• イメージ。Agent Platformの既定イメージ、ハードニング済みのUBI 9 Minimalイメージ、またはSRTを入れたカスタムイメージのいずれかが要ります。ドキュメントは「SRTが入っていないカスタムイメージではサンドボックスを使えない」と明記しています。SRTはnpmの@anthropic-ai/sandbox-runtimeで、0.0.20以降が必要です。
• 名前空間の作成権限。ランナー設定のprivileged = trueは要件を満たす手段の1つであって、それ自体では十分でも必須でもありません。実体としての要件はジョブがユーザー名前空間とマウント名前空間を作れることで、実行時はunshare -mを先に試し、駄目ならunshare -rmへ退避します。

ホスト側のuser.max_user_namespacesが0、seccompやAppArmorがCLONE_NEWUSERを塞いでいる、docker-autoscalerやkubernetes executorの構成で特権設定がジョブコンテナまで届いていない、といった場合はprivileged = trueでも初期化に失敗します。そのときはジョブログにWarning: SRT found but can't create sandbox (insufficient privileges), running command directlyが出て、サンドボックスなしで走ります。CI上だから安全、と構成を確認せずに判断しないでください。

実行モード別の防御の当たり方は次のとおりで、IDEとCLIのエージェントにはサンドボックスもネットワーク制御も適用されません。

フローには人による承認が無く、代わりにサンドボックスとツール制限で縛る設計です。裏返すと、サンドボックスが効かない構成のフローは承認もサンドボックスも無い状態になります。ツールの承認ポリシーを設定できるAgent tool governanceはまだベータなので、当面は手元のエージェントに与えるツールを絞る運用と、フロー用ランナーの構成確認が現実解になります。詳細はSecurity threats in agentic systemsとRemote execution environment sandboxで確認できます。

UIから動く基盤フローがアクセスできるAPIは、プロジェクト、イシュー、マージリクエスト、リポジトリファイル、ブランチ、コミット、CIパイプライン、ラベル、エピック、ノート、および検索の各APIに限定されています。監査の観点では、どこまで触れる可能性があるかをこの一覧で評価できます。DevOpsの体制側の前提整理はDevOpsとは？開発と運用を統合する実践・ツール・導入判断を実装視点で解説も参考にしてください。

よくある質問

GitLab Duo Agent Platformはいつから正式版になりましたか？

GitLab 18.8で一般提供になりました。GitLabのプレスリリースの日付は2026年1月15日です。ベータとしての登場は18.2で、GitLab Self-Managed向けは18.4に実験機能として入り、18.7でフラグが有効化され、18.9でフラグが削除されました。

GitLab Duo ProやDuo Enterpriseを契約していればクレジットは不要ですか？

Duo ProとDuo Enterpriseの機能自体は従量課金の対象外で、クレジットを消費しません。ただしAgent Platformの機能はクレジット建てで課金されるため、Agent Platformを使うならクレジットが要ります。また18.9以前はDuo EnterpriseアドオンとAgent Platformを併用できないため、併用したい場合は18.10以降へ上げてください。

Freeプランでも使えますか？

GitLab.comのFree最上位グループネームスペースとGitLab Self-ManagedのFree EEインスタンスは、月次コミットメントプールを購入することでAgent Platformの一部機能を使えます。GitLab.comでは18.10、GitLab Self-Managedでは19.0からです。個人ネームスペースは対象外です。なおFreeネームスペースのオンデマンド利用は暦月あたり25,000ドルで自動停止します。

1か月にどれくらいのクレジットを見込めばよいですか？

用途によって桁が変わります。Code Suggestionsは1クレジットで50回なので、1人が月1,000回補完を受けても20クレジットです。一方でSAST脆弱性解決フローは1回で4クレジットなので、月50件処理すると200クレジットになります。エージェント型チャットはモデル依存で、Claude Sonnet 4.6なら1回のLLM呼び出しが0.5クレジットです。1回の質問で複数回呼び出されることがある点も見込んでください。

組織として基盤フローを止めれば、誰も実行できなくなりますか？

なりません。設定でオフにできるのはGitLab上で動くフローで、利用者がIDEやGitLab Duo CLIのセッションから自分で動かすフローは止まりません。IDE側の利用まで止めたい場合は、そのプロジェクトやグループでAgent Platform自体を使えなくする必要があります。

関連記事

• GitLab 19.2とは？Duo CLI・カスタムフローGAで変わる開発運用
• GitLab 18.10の概要と2026年3月リリースで変わる開発体験
• SASTとは？DAST・SCAとの違いとCI/CDへの組み込み・導入判断を実装視点で解説
• コードレビューとは？目的・観点・進め方と実装現場の運用設計を解説
• DevOpsとは？開発と運用を統合する実践・ツール・導入判断を実装視点で解説