GitLab 19.2とは？Duo CLI・カスタムフローGAで変わる開発運用

GitLab 19.2は2026年7月16日に公開されました。この版で広がったのはUIではなく、エージェントが手を動かせる範囲です。GitLab Duo CLIとカスタムフローが一般提供へ移り、依存関係スキャンの自動修正とセキュリティレビューフローがベータで入りました。破壊的変更と非推奨の告知はありません。各機能の提供ティア・成熟度・有効化に必要な設定値を実装目線で整理し、19.2へ上げるべきチームと据え置いてよいチームの線を引きます。

まとめ：GitLab 19.2で先に着手する機能と据え置いてよい機能の線引き

先に触るならGitLab Duo CLIです。Premium以上なら追加契約なしに入り、プロジェクト構造・パイプライン・既存のエージェント設定を読んだ状態で、ターミナルから質問と実行ができます。導入コストはインストールと権限確認だけ。既存のCI設定に手を入れずに検証を始められます。

Ultimate契約で脆弱性のトリアージが滞っているなら、依存関係スキャン自動修正を並行して評価してください。ベータですが、機能フラグとプロファイルを設定すれば修正マージリクエストが自動で立ちます。既定の対象はパッチとマイナーの更新のみ。メジャー更新まで任せるには、破壊的変更のエージェント型解決を別途オンにする手順が要ります。

据え置いてよいのはカスタムフローの本格展開。YAMLによる多段自動化はGAへ昇格したものの、AIカタログの既存カスタムエージェントを呼び出せず、フロー側で自前のエージェントを組み直す仕様です。自動化する対象が定まっていないうちに飛びつくと、設定だけが増えます。

GitLab 19.2の全体像｜2026年7月16日リリースで変わった開発フロー

19.2でGitLabが解こうとしたのは、コード生成が速くなった結果としてレビューとセキュリティ検査が詰まるという偏りです。

4機能のGA昇格と4機能のベータ投入で構成された19.2の中身

一般提供へ移ったのはGitLab Duo CLI、カスタムフロー、スケジュールされたパイプライン実行ポリシー、CIエキスパートエージェントの4つ。ベータで投入されたのが依存関係スキャン自動修正、セキュリティレビューフロー、デフォルト以外のブランチにおける脆弱性トラッキング、AI監査イベントレポートです。

GitLabのプレスリリースは、Maven系エコシステムの脆弱性のおよそ63%が推移的依存を経由すること、依存更新のおよそ8件に1件が破壊的変更を伴うことを、自動修正投入の根拠に挙げています。同社が委託したForrester Consultingの調査による400%のROI・6か月未満の投資回収という数字も併記されていますが、ベンダー委託の調査である点は割り引いて読む対象です。

破壊的変更と非推奨がゼロ｜18.10からの差分で見る移行コスト

19.2のリリースノートに破壊的変更と非推奨の項目はありません。アップグレードそのものの改修コストは小さく、判断材料は新機能を使うかどうかに寄ります。

前の版で入ったクレジット課金モデルやSAST偽陽性の自動判定はGitLab 18.10の概要と変わった開発体験で扱っています。18.10がセキュリティ検査の精度と課金の仕組みを整えた版だとすれば、19.2はその土台の上でエージェントに実際の修正作業をさせる版という位置づけです。

Free・Premium・Ultimateで分かれる19.2機能の提供範囲

同じ19.2でも契約プランで使える機能が変わります。検証を始める前に、対象機能が手元のプランで動くかを確認してください。

Freeで届くのはカスタムフロー、CIエキスパートエージェント、詳細権限PAT、19.2で無料開放されたMCPサーバーまで。セキュリティ系の自動化はUltimateに寄っており、脆弱性対応を目的に検証するならプラン変更の判断が前提になります。

GitLab Duo CLIのGA｜ターミナル常駐エージェントの導入と実行モード

Duo CLIはDuo Chatをターミナルへ移しただけのものではありません。プロジェクト構造・パイプライン・既存のエージェント設定を把握したうえで、実行まで引き受けます。

glab経由とnpm単体｜Duo CLIの2つのインストール手順

導入経路は2つ。GitLab CLIを入れているなら glab duo cli --update で取得できます。単体で入れる場合のコマンドは npm install --global @gitlab/duo-cli@latest。

アクセスは既定で有効です。Self-ManagedとDedicatedでは管理者エリアのGitLab Duo設定から無効化できるため、生成AIの利用範囲を社内ポリシーで絞っている環境では、先に管理者側の設定状態を確認しておくと手戻りが減ります。

対話モードとヘッドレスモードの使い分けとCIへの組み込み前提

対話モードはDuo Chatに近い体験で、buildモードとplanモードを切り替えられます。設計だけ相談する段階ではplan、ファイルへ手を入れさせる段階ではbuild、という分け方になります。

ヘッドレスモードはRunnerやスクリプトからの非対話実行向けで、パイプラインのジョブとしてエージェントを呼び出す構成が組めます。CI側で回すなら、先にプラットフォーム全体の構造を押さえたほうが早い。エージェント・フロー・カタログの関係はGitLab Duo Agent Platformの仕組みで解説しています。

AGENTS.mdとchat-rules.mdで縛るエージェントの振る舞い設定

Duo CLIはカスタムインストラクションを読み込みます。対象は chat-rules.md、AGENTS.md、SKILL.md の3種類。コーディング規約や禁止操作をリポジトリ側へ置けば、CLIから起動したエージェントにも同じ制約が効きます。未整備のリポジトリでは、提案が慣習から外れる前提で使い始めることになります。

カスタムフローGA｜YAML定義とトリガーで組む多段自動化の設計方針

カスタムフローは、GitLabが組み込みフローを出すのを待たずに自分たちの手順をエージェントへ渡す仕組みです。19.2でFree以上の全プランへ開きました。

マージリクエストとパイプラインを起点にするフロー起動条件の設計

トリガーに指定できるイベントは、パイプラインイベント、マージリクエストのレビュー準備完了、コードコンフリクトの発生、承認アクション、ワークアイテムの作成、ワークアイテムのステータス変更、そしてイシュー・マージリクエスト・エピックでのメンションと担当割り当てです。

推論に使われるモデルはClaude Sonnet 4。設計上で効く制約が1つあります。カスタムフローはAIカタログやプロジェクトにある特定のカスタムエージェントを呼び出せず、YAMLの記述から自前のエージェントを生成する仕様です。既存のカスタムエージェント資産を部品として組み合わせる構成は、19.2時点では成立しません。完成したフローの配布側は19.2で一括有効化に対応し、1回の操作で最大100プロジェクトを選べます。

id_tokensでOIDC認証を通す外部連携とシークレット管理の設計

エージェント設定に id_tokens を追加すると、OpenID Connectのトークンで外部サービスへ認証できます。長期保管のシークレットを置かずに、キーレス署名やシークレットストアからの取得が組める形です。フローが外部APIを叩く構成では、ジョブスコープの短命トークンで完結するかどうかが監査の通りやすさを分けます。

ベータ2機能の実装条件｜依存関係スキャン自動修正とセキュリティレビュー

19.2で話題の中心になった2機能は、どちらもUltimate限定のベータです。上げただけでは動かず、明示的な有効化が要ります。

機能フラグとプロファイル設定で有効化する依存関係の自動修正MR

依存関係スキャン自動修正を動かす前提は4つあります。機能フラグ dependency_management_auto_remediation が有効であること、プロジェクトに自動修正プロファイルが紐づいていること、依存関係スキャンが結果を出していること、対応するパッケージマネージャーを使っていること。

メジャーバージョンの更新まで任せるには、破壊的変更のエージェント型解決を別途オンにします。機能フラグは enable_dependency_bump_breaking_changes、プロジェクトAPIからは duo_dependency_bump_breaking_changes_enabled をtrueにする形です。有効化すると、更新でパイプラインが落ちた際にエージェントが同じマージリクエスト内で解消を試みます。GitHub側でDependabotを回してきたチームなら、GitHub ActionsとDependabotによる依存関係の自動更新との差は「提案で止まるか、失敗の解消まで引き受けるか」です。

対応パッケージマネージャーとMR上限10件・並列数の運用制限

対応範囲はRubyのBundler、JavaのMavenとGradle、Pythonのpip・pipenv・poetry・setuptools・uv、JavaScriptのnpm・yarn・pnpm・bun。運用面の制限は数値で決まっています。

• 既定の更新範囲はパッチとマイナーのみ
• 対象は重大度がHigh以上の脆弱性
• 新しく公開されたバージョンは7日間のクールダウン後に採用
• 1プロジェクトで同時にオープンできる自動修正MRは10件まで
• 処理は重大度の高い順に3件ずつ
• 並列数は security_update_scheduler_max_concurrency で調整（既定30・最大200・0で停止）
• パイプライン1回あたりの処理は脆弱性1件、バッチ化は将来のリリース待ち

非破壊で直せるバージョンが存在しない脆弱性では、マージリクエストが作られません。自動修正を入れても脆弱性レポートが空にならないのはこのためです。

Duo Security Reviewをレビュアー指定して検出するロジック欠陥

セキュリティレビューフローは自動では起動しません。マージリクエストのレビュアー欄で Duo Security Review を指定したときだけ走る手動トリガーの機能で、サービスアカウント名はトップレベルグループ名を含む命名になります。

検出対象はパターンマッチでは拾えないロジック上の欠陥です。ユーザー制御キーによる認可バイパス（CWE-639）、認可の欠落（CWE-862）、アクセス制御の不備（CWE-284）、情報漏えい（CWE-200）、ビジネスロジックの誤り（CWE-840）、マスアサインメント（CWE-915）、競合状態（CWE-362）が公式に挙げられています。指摘はCWE分類・重大度・階層（1が悪用可能、2がロジック欠陥、3が設計上の課題）付きで差分にスレッド投稿されます。

差分の規模で変わるクレジット消費量とレビュー結果の受け止め方

コストはGitLabクレジットで、差分の複雑さに比例します。公式ドキュメントの目安は、小さな差分でLLM呼び出し約16回・クレジット約8、標準的なブランチで約28回・約14、大きくロジック中心の差分で約40回・約20です。

このフローがマージリクエストを承認することはありません。CriticalかHighの指摘があればレビュアー状態を「変更をリクエスト」に、それ以外なら「コメント」に設定するところまで。読み取り予算に上限があり誤検知も含まれるため、人のレビューを置き換える設計ではなく、レビュー前に論点を洗い出させる用途で組み込むのが実務に合った使い方です。

詳細権限PATとAI監査イベント｜エージェント運用のガバナンス設計

エージェントに手を動かさせるほど、誰が何をしたかの記録と権限の粒度が効いてきます。19.2はこの層にも手を入れました。

リソースとアクションで絞る詳細権限PATと従来スコープの違い

詳細権限パーソナルアクセストークンがGAになりました。従来のスコープ付きトークンがapiやread_repositoryという広い括りで権限を渡していたのに対し、詳細権限PATはリソースとアクションの組み合わせで指定します。リソースの境界はグループとプロジェクト、ユーザー、グローバルの3つ。アクションは作成・読み取り・更新・削除に沿う形です。

もう1点効くのが権限の二重判定で、トークンの権限と使用者自身の権限の両方が許可する操作しか通りません。既定の有効期限は365日。GitHub側で同種の仕組みを触ったことがあるなら、GitHub PATのclassicとfine-grainedの違いと考え方が近いと分かります。API対応範囲には差があり、RESTは全面対応、GraphQLは主要な型とミューテーションが対象です。

AI監査イベントレポートとサブグループ単位のDuoロック設定

AI監査イベントレポートはPremium以上のベータです。ガバナンスページからエージェント単位・セッション単位で絞り込み、ダウンロードできる記録として出力できます。どのエージェントがどのリポジトリに何をしたかを後から追えるため、監査部門への説明材料になります。

DuoロックはUltimateのGitLab Dedicated向けで、既定拒否の許可リスト方式。親グループで「常にオフ（ロック済み）」を設定し、限られたサブグループだけ有効化する運用が組めます。自動コードレビューの対象を絞るなら、.gitlab配下のduoディレクトリに mr-review-automated-rules.yaml を置き、作成者やブランチ名のグロブパターンで除外ルールを書く方法も。ボットが起票するマージリクエストをレビュー対象から外したいときの受け皿になります。

スケジュールパイプライン実行ポリシーで一括適用する定期スキャン

セキュリティポリシープロジェクトでスケジュールを1回定義すれば、対象プロジェクト全体へ適用されます。日次・週次・月次のケイデンスに対応し、タイムゾーンを指定でき、実行時刻を時間帯で分散させられます。Ultimate限定でGAへ移りました。プロジェクトごとに手でスケジュールを作っていた運用を1か所へ寄せられ、深夜帯にスキャンが集中してRunnerが枯渇する構成も避けられます。

GitLab 19.2へ上げる3条件と見送る2条件｜受託開発での採用判断

ここからは判断です。機能の一覧ではなく、どのチームが今動くべきかを条件で示します。

今すぐ上げる3条件｜Ultimate契約・依存脆弱性の滞留・CI失敗の常態化

次の3つのうち2つ以上に当てはまるなら、19.2への更新と新機能の検証を同じスプリントで進める判断になります。

• Ultimate契約があり、脆弱性レポートに未対応のHigh以上が積み上がっている
• 依存更新を人手で追っており、月に数回はビルド破損の切り分けに時間を取られている
• パイプライン失敗の原因調査が特定の担当者へ集中している

1つ目に当たるなら依存関係スキャン自動修正から、3つ目ならCIエキスパートエージェントとCI/CDパイプライン修正フローから着手する順番です。後者は19.2でマージリクエストの差分に対して直接コード提案を返すよう変わり、失敗の分類診断と子パイプラインの解析にも対応しました。挙動の調整は AGENTS.md で行います。

見送ってよい2条件｜Free運用と人手レビューが機能しているチーム

逆に、次の2条件に当てはまるチームは19.2の新機能を導入しないほうが結果が良くなります。

1つはFreeプランで運用していて、セキュリティ検査をGitLab以外の製品で回している場合。19.2のセキュリティ自動化はUltimateに集中しており、Freeで届くのはカスタムフロー、CIエキスパートエージェント、MCPサーバーまでです。プラン変更を伴わない範囲での効果は限定的になります。

もう1つはコードレビューが人手で回っており、指摘の質に不満がない開発体制。セキュリティレビューフローは誤検知を含む助言として設計されているため、真偽を判定する工数が新たに発生します。レビューが滞留していないなら、クレジット消費とノイズだけが増える。導入しない判断を先に置いてください。

Runner 19.2とDuo接続ヘルスチェック｜アップグレード前の確認項目

GitLab Runnerも19.2が同時にリリースされました。ジョブ完了時のPUTリクエストにenvironmentキーが載るようになり、KASへのリクエストが失敗した際にRailsへ切り替わるサーキットブレーカーが入っています。シークレット解決のタイムアウトやアーティファクトのダウンロード失敗、Runnerトークンの自動ローテーション周りのバグ修正も同時期の対応です。

Self-Managedでは、アップグレード後にGitLab Duoのヘルスチェックを走らせてください。カスタマーポータル、AIゲートウェイ、Duoワークフローサービスへの接続と、課金エンドポイントへの疎通が確認対象。ここが通らないと、エージェント系の機能は設定だけ有効で動かない状態に陥ります。19.2で詰まるとすればこの工程です。

エージェント前提のDevSecOps構築を外部委託する際の見積もり項目

19.2相当の構成を外部へ任せる場合、見積もり項目は機能の有効化ではなく判断基準の設計に置いてください。自動修正MRをどこまで自動マージするか、セキュリティレビューフローの指摘をどの重大度から対応必須にするか、クレジット消費の上限をどこへ引くか。決めずに進めると、設定は完了したのに誰も自動化を信用しない状態になります。

成果物としては、カスタムフローのYAML一式、自動修正プロファイルの設定値、ロールと詳細権限PATの割り当て表、クレジット消費の実測レポートを求める形が現実的です。エージェントを含む開発基盤の設計から実装までを外部へ委ねるなら、生成AI開発・AI受託開発で扱う範囲が近いところにあります。既存のCI/CD資産を残したまま段階導入する前提で切り出すと、見積もりのブレが小さくなります。

よくある質問

GitLab 19.2の導入検討で挙がりやすい論点を、公式ドキュメントとリリースノートの記載に沿って整理します。

GitLab 19.2に破壊的変更はありますか？

19.2のリリースノートには破壊的変更と非推奨の項目が記載されていません。既存のパイプライン設定やAPI呼び出しを書き換える必要は、この版に関しては生じない見込みです。ただしSelf-Managedではバージョンをまたぐアップグレードパスの制約が別にあるため、複数版を飛ばして上げるならRunnerを19.2へ揃えたうえで各中間版の告知を確認してください。

GitLab Duo CLIはFreeプランでも使えますか？

使えません。Duo CLIの提供ティアはPremiumとUltimateで、GitLab.com・Self-Managed・Dedicatedのいずれでも同じです。Freeプランで19.2の新機能に触れるなら、カスタムフロー、CIエキスパートエージェント、詳細権限PAT、無料開放されたMCPサーバーが対象です。

依存関係スキャン自動修正はDependabotとどう違いますか？

更新提案を自動化する点は共通しますが、19.2の自動修正は破壊的変更の解消まで踏み込みます。エージェント型の解決を有効にすると、更新でパイプラインが失敗した場合に同じマージリクエスト内で修正を試みる挙動です。対象の絞り方も異なり、既定では重大度High以上に限定し、新しいバージョンは7日のクールダウンを置いてから採用します。

セキュリティレビューフローは人のレビューを置き換えられますか？

置き換えられません。公式ドキュメントは結果を「助言であり、権威ある完全なセキュリティ評価ではない」と位置づけています。読み取り予算に上限があるため大きなファイルでは見落としが起き、誤検知も含まれる前提です。マージリクエストを自ら承認することもありません。

カスタムフローで既存のカスタムエージェントを呼び出せますか？

19.2時点では呼び出せません。カスタムフローはYAML設定から自前のエージェントを生成する仕様で、プロジェクトやAIカタログにある特定のカスタムエージェントを指定する記述はサポートされていません。AIカタログのカスタムエージェントを複数プロジェクトへ配る運用と、フローで多段処理を組む運用は、別々の設計として扱ってください。

関連記事

• GitHubとGitLabの違いを比較｜CI/CD・セキュリティで選ぶ判断基準：そもそもGitLabを選ぶかの判断材料になります
• GitLabでPR-AgentのAIコードレビューを導入する手順：Duo以外の選択肢でAIコードレビューを組む構成が分かります
• DevSecOpsとは？DevOpsとの違い・ライフサイクル・導入判断を実装視点で解説：19.2のセキュリティ自動化を位置づける全体像です
• SBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説：依存関係スキャンの前提になる部品表の考え方を扱います
• CI/CDとは？仕組み・パイプライン・導入すべき企業の判断基準を解説：パイプライン修正フローやスケジュール実行ポリシーの土台です