GitLab 19.1リリースノート

これまで、Agentic Chatがツールの呼び出しを承認するよう求めた際、1回だけ承認するか、セッション中に同じ引数でのツール呼び出しをまとめて承認するかを選択できました。異なる引数を使用する場合は、その都度追加の承認が必要でした。

git 操作の連続実行など、類似したコマンドを繰り返すワークフローでは、ほぼ同一のプロンプトが次々と表示されていました。

今回のリリースで、新たに3つ目の承認オプションとして、Approve all uses of this tool for session （セッション中このツールのすべての使用を承認する）が追加されました。このオプションを選択すると、引数が承認済みのパターンに一致する限り、セッション中のそのツールの呼び出しがすべて承認されます。

パターンベースの承認は、GitLab UI、GitLab Duo CLI、GitLab for VS Code、およびJetBrains IDE向けGitLab DuoプラグインのAgentic Chatで利用できます。

管理者およびトップレベルグループのオーナーは、組織内で利用可能なAIエージェントとフローを制御できるようになりました。具体的には、以下の操作が可能です。

• ユーザーによるカスタムエージェントおよびフローの作成や有効化を禁止する。これにより、一元的に承認されたAI自動化のみが使用されるようになります。
• グループ階層外のプロジェクトが所有するエージェントおよびフローをユーザーが有効化することを制限する。これにより、未承認の外部コンテンツへの露出を抑えられます。

AIカタログで、カスタムフローの設定を保存またはトリガーする前に検証できるようになりました。

これまでは、カスタムフローにおける構文エラーや設定ミス（例: 入力の欠落や不明なツールパラメーター）は、CIジョブが開始された後のランタイム時にしか検出できませんでした。そのため、デバッグに時間がかかり、困難を伴うことがありました。

今回のリリースで、AIカタログでカスタムフローを保存または更新する際に、GitLabが設定を事前にチェックし、エラーをUIに直接表示するようになりました。問題のないフローには影響がなく、これまでどおり保存およびトリガーできます。

これまでのGitLabでは、コードレビューフローはAnthropicのClaudeモデルのみをサポートしていました。契約上、ポリシー上、または調達上の制約によりAnthropicモデルを使用できないチームは、コードレビューフローを実行する手段がありませんでした。

コードレビューフローのモデルとして、GPT-5.2またはGPT-5.3 Codexを選択できるようになりました。トップレベルグループのオーナーは、設定 > GitLab Duo > 機能の設定から、GitLab Duo Agent Platformのエージェント型コードレビューのモデルを切り替えられます。GPTモデルはGitLab AIゲートウェイを通じてホストされるため、追加の設定は不要です。

両モデルはGitLab Duoコードレビューデータセットを用いたベンチマーク評価に合格しており、デフォルトのClaude Sonnet 4.6 Vertexモデルと同等のレビュー品質を示しています。結果については、コードレビューベンチマークをご覧ください。

以前のバージョンのGitLabでは、サービスアカウントがメンションされた場合、割り当てられた場合、またはレビュアーとして追加された場合にのみ、フローと外部エージェントを実行できました。マージリクエストのライフサイクルの残りの部分や、作業アイテムの作成に関する自動化を調整するには、外部の連携ツールが必要でした。

現在は、4つの追加イベントに対してトリガーを設定できます。

• マージリクエスト準備完了: ユーザーがドラフトのマージリクエストをレビュー準備完了としてマークした場合。以前は機能フラグの後ろでリリースされていましたが、このイベントトリガーは現在一般提供されています。
• マージリクエストコードコンフリクト: コードコンフリクトにより、マージリクエストをマージできなくなった場合。
• マージリクエスト承認済み: マージリクエストが必要なすべての承認を受け取った場合。
• 作業アイテム作成済み: ユーザーがプロジェクトに作業アイテムを作成した場合。

トリガーを設定するには、プロジェクトの AI > トリガー に移動するか、フローを有効にする際にトリガーを選択してください。

GitLab Duo Agentic Chatで、承認済みモデルの許可リストを設定し、組織全体のデフォルトを指定できるようになりました。この設定は以下のユーザーが行えます。

• GitLab.comでは、トップレベルグループのオーナー
• GitLab Self-Managedでは、インスタンス管理者

これにより、Agentic Chat使用時にユーザーが選択できるモデルを組織として管理できます。

GitLab Duoのヘルスチェックに、基本フローの準備状況チェックが追加されました。このチェックでは、以下の項目を確認します。

• インスタンスレベルのフロー実行設定が有効になっているか。
• インスタンスレベルの基本フロー設定が有効になっているか。
• gitlab--duo タグが付与されたアクティブなインスタンスRunnerが少なくとも1つ登録・接続されており、Docker互換のexecutorを使用しているか。

GitLab.com上の新規GitLab Duoトライアルユーザーを対象に、コードレビューフローの自動レビューがデフォルトで有効になりました。手動での設定なしに、初日からマージリクエストに対するAIによるフィードバックを受け取れます。

新しいフラット料金モデルにより、より賢く、より迅速なコードレビューをすぐに活用できます。必要に応じて、グループ設定からオプトアウトすることも可能です。

デフォルトでは、GitLabのOAuthアクセストークンは2時間後に有効期限が切れます。GitLab 19.1では、GitLab Self-ManagedおよびGitLab Dedicatedのインスタンス管理者が、新しいOAuthアクセストークンのカスタム有効期間を設定できるようになりました。300秒から7200秒の範囲で任意の値を設定できます。これにより、既存のトークンの動作を変更することなく、MCPクライアントを含むセキュリティ上重要なOAuthインテグレーションに対して、有効期間の短いトークンを適用できます。

プロジェクトおよびグループのWikiページに、絵文字リアクションを直接追加できるようになりました。

GitLabの絵文字ピッカーを使用してページのコンテンツにリアクションできます。各ページにはリアクション数とリアクションしたユーザーが表示されます。リアクションはページの編集やバージョンをまたいで保持されます。

SARIF 2.1.0準拠のスキャナーであれば、そのセキュリティ検出結果をGitLabの脆弱性管理で活用できるようになりました。

スキャナーを実行してSARIFアーティファクトを出力するCI/CDジョブを定義するだけで、GitLabがその検出結果を解析・検証し、セキュリティワークフローにインポートします。結果はパイプラインのセキュリティタブ、脆弱性レポート、セキュリティダッシュボード、マージリクエストのセキュリティウィジェット、セキュリティポリシーに、GitLabネイティブスキャナーの出力と並べて表示されます。この機能により、セキュリティチームはどのツールで検出された脆弱性も一元的に把握できます。

GitLabは各検出結果の識別子をもとにレポートタイプを割り当て、SAST、dependency scanning、secret detectionなどのカテゴリに分類します。対応スキャナーには、SASTではSemgrepとCheckmarx、依存関係スキャンとコンテナスキャンではTrivyとSnyk、シークレット検出ではGitleaksが含まれます。

スキャナー有効化ウィザードを使用することで、注意が必要なプロジェクトを手動で特定することなく、プロジェクト全体のスキャナーカバレッジのギャップを解消できるようになりました。

セキュリティ設定プロファイルは、実行するスキャナーとその方法を定義します。セキュリティインベントリは、プロジェクト全体のスキャナーカバレッジを表示し、選択したプロジェクトやサブグループにプロファイルを一括適用できます。ウィザードはその上に目標主導のワークフローを追加します。目標を設定すると、カバレッジが不足しているプロジェクトを検出し、そのギャップのみを解消します。

スケジュールパイプライン実行ポリシーがベータ版として利用可能になり、有効化に実験フラグが不要になりました。コミットの有無に関わらず、プロジェクト全体でカスタムCI/CDジョブを日次・週次・月次のケイデンスで適用できます。スケジュールポリシーを使用することで、定期的なコード変更が行われないリポジトリに対しても、コンプライアンススクリプト、セキュリティスキャン、依存関係チェックを実行できます。

スケジュールポリシーは、通常のパイプライン実行ポリシーと一貫した変数の優先順位を適用するようになりました。各セキュリティポリシープロジェクトは最大5つのスケジュールポリシーをサポートし、ポリシーが無効化または削除された場合、GitLabは実行中のパイプラインを自動的にキャンセルします。スケジュールはYAMLまたはUIで設定でき、タイムゾーンのサポート、時間帯分散、ブランチターゲティング、スヌーズ機能を備えています。

セキュリティマネージャーロールが一般提供開始となりました。このロールにより、脆弱性管理、セキュリティダッシュボード、ポリシー設定、コンプライアンスツールなど、セキュリティ機能への包括的なアクセスが可能になります。セキュリティチームはセキュリティ機能にアクセスするためにデベロッパーロールやメンテナーロールを必要とせず、職務分離を維持しながら過剰な権限付与の懸念を解消できます。

セキュリティマネージャーロールを持つユーザーは、以下のアクセス権を持ちます。

• 脆弱性管理: グループおよびプロジェクト全体の脆弱性を表示、トリアージ、管理します。
• セキュリティポリシー: グループレベルでセキュリティポリシーを表示・管理し、プロジェクトレベルでポリシーYAMLにコントリビュートします。
• セキュリティインベントリ: グループ内のすべてのプロジェクトにわたるスキャナーのカバレッジを表示します。
• セキュリティ設定プロファイル: グループおよびプロジェクトのセキュリティ設定プロファイルを表示します。
• コンプライアンスツール: グループおよびプロジェクトの両レベルで、監査イベント、コンプライアンスセンター、コンプライアンスフレームワーク、コンプライアンスステータスレポート、依存関係リストを表示・管理します。
• シークレットプッシュ保護: グループおよびプロジェクトのシークレットプッシュ保護を有効にします。
• オンデマンドDAST: プロジェクトのオンデマンドDASTスキャンを作成・実行します。
• Runnerの表示: グループおよびプロジェクトのRunnerを表示します。

使用を開始するには、グループに移動して管理 > メンバーを選択し、メンバーを招待してセキュリティマネージャーロールに割り当てます。

Wikiページが最近表示したアイテムに表示されるようになり、よく訪問するページに戻りやすくなりました。

GitLabホームページのクイックアクセスウィジェットに、イシュー、マージリクエスト、エピックと並んで、最近表示したプロジェクトおよびグループのWikiページが一覧表示されます。削除されたページや、アクセスできなくなったページはGitLabが自動的に削除します。

GitLab監査イベントストリーミングインフラストラクチャを通じて、AI監査イベントを外部宛先にストリーミングできるようになりました。これにより、セキュリティおよびコンプライアンスチームは、LLMとAIのインタラクションをリアルタイムで把握できます。

AI監査イベントストリーミングを有効にすると、GitLabはこれらのイベントを、SIEM（セキュリティ情報およびイベント管理）を含むアクティブなインスタンスのすべてのストリーミング先に、他の監査イベントとともに転送します。

これまでは、blame情報を確認するには別のページに移動する必要があり、コードレビュー中の作業フローが中断されていました。

今回のリリースで、ファイルビューから直接blame情報を切り替えられるようになりました。各行には最終に変更したユーザーが表示され、ホバーするとコミットのポップオーバーで詳細を確認できます。この変更前のblameを表示を選択してさらに履歴をたどったり、特定のリビジョンを無視を選択してblameビューから特定のコミットを除外したりできます。

以前のバージョンのGitLabでは、CI/CD分析ページ（<project>/-/pipelines/charts）の失敗率と成功率のメトリクスに、キャンセルされたパイプラインとスキップされたパイプラインが計算に含まれていました。これにより、両方の率が予想より低く表示されていました。たとえば、gitlab-org/gitlabでは、2つの率の合計が約100%ではなく98%にとどまっていました。

今回のリリースで、GitLabは完了したパイプラインのみを使用して失敗率と成功率を計算するようになり、結果がパイプラインの健全性を正確に反映するようになりました。

本日、GitLab Runner 19.1もリリースしました。GitLab Runnerは、CI/CDジョブを実行してその結果をGitLabインスタンスに送信する、高いスケーラビリティを持つビルドエージェントです。GitLab Runnerは、GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。

新機能

• Runner設定に設定可能なget_sourcesタイムアウトを追加

バグ修正

• 具体的な実行（FF_CONCRETE）が複数の動作領域で抽象シェルと乖離する問題
• FF_USE_GIT_PROACTIVE_AUTHとFF_USE_GIT_BUNDLE_URISが有効な場合、Bundle URIのダウンロードが機能不足エラーで失敗する問題
• 競合状態によりUI経由でジョブをキャンセルした際にスクリプトがダンプされる問題を修正
• Kubernetesのexecutorヘルパーコンテナのメモリ使用量がOOMキルを引き起こす問題を修正

すべての変更点の一覧は、GitLab RunnerのCHANGELOGをご確認ください。

これまで、大きな変更を相互に依存する小さなマージリクエストに分割した場合、UIにはそれらの関連性を示す情報が表示されませんでした。作成者とレビュアーは、順序を手動で追跡する必要がありました。

GitLabはスタックされたマージリクエストを自動的に検出し、マージリクエストのヘッダーに表示するようになりました。マージリクエストが別のオープン中のマージリクエストのソースブランチをターゲットにしている場合、またはオープン中の別のマージリクエストがそのソースブランチをターゲットにしている場合、そのマージリクエストはスタックに追加されます。ソースブランチの横にあるスタックコントロールには現在の位置（例: 2件中1件目）が表示され、スタック内の任意のマージリクエストにジャンプできます。

コマンドラインからスタックされたマージリクエストを作成するには、GitLab CLIのスタックされた差分を使用してください。

GitLab 18.10では、人間のユーザーによるGit操作（clone、pull、fetch、push）が監査ログに記録されるようになりました。

GitLab 19.1では、この機能がすべてのアクタータイプに拡張され、デプロイトークンを使用するRunnerやSSH証明書ユーザーも対象となりました。 これにより、監査ログはリポジトリ全体のすべてのGitアクティビティを、操作の実行者を問わず完全に反映するようになりました。

これまで、リポジトリのコミットリストはフィルタリング機能が限られており、長い履歴の中から特定のコミットを見つけることが困難でした。

再設計されたコミットリストには、以下の機能が含まれています。

• 作成者、コミットメッセージ、または日付範囲によるコミットのフィルタリングと検索
• ブランチ、タグ、コミットSHAなどのGitリビジョンによるリストのフィルタリング
• 日付ごとにグループ化されたコミット表示による視認性の向上
• 大規模リポジトリに対するパフォーマンスとページネーションの改善

GitLab 19.1では、脆弱性の結果の詳細ページで、スキャン結果に対して一貫性があり、わかりやすく、セキュリティ業界標準に準拠した用語が使用されるようになりました: