GitLab 19.4リリースノート

エージェントセッションに関する重要な詳細を確認するには、煩雑なパネルを探し回る必要がありました。 新しいセッション詳細パネルでは、必要な情報を一目で確認できます。ステータス、タイムスタンプ、トリガーした ユーザーが概要バーに表示され、右側のレールにはID、実行、補足の詳細が明確にラベル付けされたグループとして整理されています。

新しいリンクされたアイテムセクションでは、セッションを開始したものと、マージリクエスト、作業アイテム、ジョブ、コメントなど、セッションが生成したものが分けて表示されます。GitLab Duoサイドパネルでは、セッションの詳細が下部に固定された折りたたみ可能なバーに表示されるようになり、作業の邪魔にならずにアクセスできます。

GitLab Duo CLIに/goalスラッシュコマンドが追加されました。このコマンドは、オープンエンドな目標をローカルで実行される管理された目標駆動型フローに委任します。

目標を記述すると、GitLab Duoが実装と検証を担当します。独立した判定機能により、目標が達成されたか、またはイテレーション上限に達したかを判断します。一時停止、目標の更新、エージェントの方向転換など、常にユーザーが主導権を持ちます。

/goalスラッシュコマンドを使用するには、GitLab 19.3以降およびGitLab Duo CLI 9.17.0以降が必要です。

使い始めるには、/goal <task>を実行してください。

例:

/goal Fix the failing tests in spec/models/user_spec.rb

GitLab UIに切り替えることなく、Slackから直接GitLab Duoエージェントフローを実行できるようになりました。

GitLab Duo Slackインテグレーションを使用すると、任意のSlackチャンネルやスレッドで@GitLabとメンションすることができます。GitLabをメンションすることで、エージェントフローのトリガー、コードベースからの回答取得、会話からのGitLabイシュー作成が可能です。GitLab Duoはリアルタイムで進捗をSlackスレッドにストリーミングし、Slackを離れることなく回答を評価できるサムズアップ・サムズダウンのフィードバックボタンも表示されます。

このインテグレーションは実験的機能として提供されています。フィードバックを共有するには、イシュー624364にコメントを追加してください。

新しいCI/CDツールにより、エージェントはあらゆるMCPクライアントからCI/CDをトリガー、確認、制御できるようになりました。

• save_pipelineは、ツールを切り替えることなくパイプラインの実行、再試行、またはキャンセルを行います。
• get_jobは、ジョブのメタデータとジョブのトレースを返します。これにより、エージェントは失敗したビルドのログを読み取り、問題を自律的に診断できます。

これまで、エージェントはMCPを通じてパイプラインをトリガーしたり確認したりする手段がありませんでした。

マージリクエストツールを使用すると、エージェントはGitLab MCPサーバーを通じてマージリクエストのフルループを実行できます。

• save_merge_request はMRを作成・更新します。
• get_merge_request はMRを詳細に検査し、差分、コンフリクト、承認のファセットを新たに提供します。
• list_merge_requests はグループスコープでも動作するようになりました。
• save_merge_request_review は行レベルのレビューコメントを残し、差分コメントのバッチ処理とサマリーを1回の呼び出しで行います。
• accept_merge_request はチェックが通過するとMRをマージし、承認または承認取り消しも行えます。

semantic_code_search は semantic_search に名称変更されました。このツールは、以前のリリースから変わらず、完全一致するシンボルやファイル名ではなく、意味によってコードを検索します。名称変更に伴い scope パラメーターが追加され、将来のリリースで追加のインデックス作成済みコンテンツタイプを同じツールに統合できるようになります。現時点では、scope は code のみを受け付けます。

新しいプロジェクトおよびユーザーツールにより、エージェントはGitLab MCPサーバーを通じて作業を正確に対象とするために必要なコンテキストを取得できます。

• get_projectとlist_projectsはプロジェクトの詳細を検索・取得します。
• list_project_membersはメンバーとその役割を一覧表示します。
• get_userは割り当てやメンションのためにユーザーの詳細を検索します。

以前は、エージェントはGitLab MCPサーバーを通じてプロジェクトのメンバーシップやユーザー情報を取得する方法がありませんでした。

GitLab MCPサーバーに作業アイテムツールが追加され、エージェントおよびMCPクライアントからイシュー、エピック、タスク、インシデント、目標、主な成果の検索・参照・作成・更新が行えるようになりました。

get_work_itemで単一アイテムの詳細を取得し、list_work_itemsでグループまたはプロジェクト横断の検索を行い、save_work_itemであらゆる作業アイテムタイプの作成・更新が可能です。

イシューとエピックは作業アイテムタイプの一種であるため、get_work_itemとsave_work_itemは、現在のget_issueおよびcreate_issueの機能をカバーしています。

save_noteを使用すると、エージェントが作業アイテムやマージリクエストにコメントを投稿したり、既存のディスカッションスレッドに返信したりできます。このツールの導入に伴い、既存のcreate_merge_request_noteおよびcreate_workitem_noteはリネームされました。

新しいリポジトリツールにより、エージェントはGitLab MCPサーバーを通じてプロジェクトの構造を参照し、コミット履歴を確認し、変更を提案できるようになりました:

• list_repository_tree はファイルツリーを探索します。
• list_branches と list_tags はrefsを列挙します。
• list_releases は公開済みリリースを確認します。
• get_commit はコミットのメタデータ、差分、またはノートを取得します。
• list_commits はブランチの履歴をページングします。
• add_commit は1回の呼び出しで1つ以上のファイル操作をコミットします。特定の開始refまたはソースプロジェクトから新しいブランチへのコミットも可能です。
• fork_repository はプロジェクトをフォークします。これにより、エージェントはクライアントを離れることなく、アップストリームリポジトリの探索から変更の提案までをシームレスに行えます。

以前のバージョンのGitLabでは、マージリクエストトリガーイベントタイプは承認済み、レビュー準備完了、マージコンフリクトのアクションのみをサポートしていました。GitLab外のツールを使用せずに、誰かがマージリクエストを開いた瞬間にフローや外部エージェントを実行する方法はありませんでした。

作成済みをトリガーアクションとして選択できるようになりました。誰かがドラフトまたはレビュー準備完了の状態でマージリクエストを開き、GitLabが差分を生成すると、フローまたは外部エージェントが実行されます。最初のレビューや、関連するイシューからのコンテキスト追加にご活用ください。

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

GitLab for VS Code拡張機能に搭載された新しいビジュアルエディタ「GitLabフロービルダー」を使用して、GitLabプロジェクト用のカスタムフローを構築できます。 コンポーネント（エージェント、カスタムツール、AIタスク）を視覚的に組み合わせてフローを作成するか、基盤となるYAMLを直接編集することができます。

開始するには、VS CodeでフローのYAMLファイルを開き、GitLabフロービルダーを開くを選択します。 実行ボタンでフローをテストすると、実行コンソールが開きます。 フローの準備ができたら、公開を選択してAIカタログに公開します。

フロービルダーは、GitLab for VS Code 6.87.0以降でベータ版機能として利用できます。使用を開始するには、VS Codeでgitlab.featureFlags.flowBuilder設定を有効にしてください。

GitLab Duo Agent Platformは、GLM 5.3、Kimi K3、MiniMax M3の3つのオープンウェイトモデルをサポートするようになりました。

GitLab Duo Agentic Chatでは、これらのモデルをご自身の会話に選択できます。グループのオーナーロールを持つユーザーおよび管理者は、Agentic Chatやその他のエージェント、フロー、機能のデフォルトとして設定することもできます。

GitLab Duo Agent Platformは、デベロッパーフローに対して独立したモデル選択をサポートするようになりました。 管理者は、他のGitLab Duo Agent Platform機能とは別に、デベロッパーフロー専用のAIモデルを選択できます。これにより、チームはモデル選択をより細かく制御できるようになります。

以前のバージョンのGitLabでは、フローが自動的に開始されないようにするには、トリガーを完全に削除するしか方法がありませんでした。 トリガーを削除すると、設定済みの複雑なフィルター設定も失われてしまいます。

今回のリリースで、フロートリガーをオフにしても設定を保持できるようになりました。 新しい切り替えを使用して、いつでもオンに戻すことができます。

トリガーを管理するには、AI > トリガーに移動します。

Security teams can use the bulkSetVulnerabilityFindingsDueDates GraphQL mutation to assign, update, or remove due dates for vulnerability findings in bulk. Each request supports up to 1,000 finding UUIDs and returns counts for assigned, removed, and skipped updates, along with structured errors. Teams can use this information to connect vulnerability remediation timelines with existing service-level agreement (SLA) and workflow automation.

When you apply filters to the Vulnerability Report, exported CSV reports will respect those filters. Rows that are not included in the Vulnerability Report UI after filtering will not appear in the CSV file export either.

ファイルがロックされている場合、blobビューアーを離れることなく、ロックしたユーザーと利用可能な操作を確認できるようになりました。

以前は、ロック済みラベルのみが表示され、誰がファイルをロックしたか、自分でロックを解除できるかどうかを確認する方法がありませんでした。現在は、ラベルの横にポップオーバーが表示され、ロックしたユーザーを確認できます。ファイルのロック解除権限がある場合、ポップオーバーにはロック解除アクションが含まれます。権限がない場合は、その理由が説明されます。ロックされたディレクトリの場合、ポップオーバーから変更をブロックしている特定のファイルに直接リンクされます。

以前のバージョンのGitLabでは、SASTの誤検出検知、GitLab Duoの脆弱性の修正、シークレット検出の誤検出検知、依存関係スキャンの自動修正をプロジェクトごとに個別に有効化する必要がありました。今回のリリースで、自動トリアージおよび修正プロファイルをグループまたはプロジェクトに適用し、重大度と実行モードを一度の操作でまとめて設定できるようになりました。プリセットから始めることも、各フローを個別に設定することも可能です。

• Conservative: オンデマンド、高重大度。
• Standard: 自動、中重大度以上。
• Proactive: 自動、すべての重大度。

プロファイルはGraphQL APIでのみ利用可能で、トップレベルグループでファウンデーショナルフローが有効になっているGitLab Duo Agent Platformが必要です。ほとんどのフローはGitLabクレジットを消費します。

GitLab 19.4では、GitLab MCPサーバーに脆弱性管理のための以下の新しいツールが追加されました。

• list_vulnerabilities: カーソルページネーションを使用して、重大度やレポートタイプによるオプションのフィルタリングとともに、GitLabプロジェクトのセキュリティ上の脆弱性を一覧表示します。
• get_vulnerability: 数値IDで単一の脆弱性の詳細情報をフェッチし、gid://gitlab/Vulnerability/<id>のグローバルID形式に変換します。
• save_vulnerability: 1つの統合ツールでGitLabの脆弱性に対する5つの書き込み操作をカバーします。
  • dismiss: オプションのコメントと却下理由を指定して、脆弱性を却下済みとしてマークします。
  • confirm: 脆弱性を確認済みとしてマークします。
  • revert_to_detected: 脆弱性の状態を検出済みに戻します。
  • update_severity: 必須コメントとともに重大度をオーバーライドします。
  • link_to_issue: 脆弱性にリンクされた新しいイシューを作成します（project_full_pathが必要です）。

これらの新しい脆弱性管理ツールにより、AIエージェントはGitLab MCPサーバーを通じて脆弱性のトリアージと修正アクションを実行できるようになります。

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

新機能

• Fastzipがキャッシュとアーティファクトのデフォルトアーカイバーになりました
• gitlab_runner_job_router_get_job_duration_secondsにrunnerおよびsystem_idラベルを追加
• ジョブルーターに専用のSLI、SLO、およびアラートインテグレーションを追加
• Kubernetesエグゼキューターにサスペンドおよびレジューム機能のサポートを追加
• ジョブ完了時のPUTリクエストに環境キーを出力
• ジョブログにおけるキャッシュのアップロードおよびダウンロードURLを非表示にするオプション
• Dockerエグゼキューターの設定にservices_cap_addおよびservices_cap_dropオプションを追加

バグ修正

• ジョブルーターの409レスポンスによりRunnerマネージャーが1時間無効化される
• logrotate使用状況ライターが共有Runnerラベルを変更することでRunnerがパニックを起こす可能性がある
• Windowsサービスのコンソール復元失敗により、正常停止中のジョブが強制終了される
• ヒストグラム内のjob_idおよびrunner_controller_id属性に対する無制限のカーディナリティ
• TOMLタグはあるがJSONタグのないnull許容フィールドに対して設定検証がgot nullと警告する
• Gitバージョンチェック時のSIGPIPEによりget_sourcesで断続的なサイレント障害が発生する
• FF_USE_ADAPTIVE_REQUEST_CONCURRENCYが有効な場合に誤ったRequest bottleneck警告が表示される
• AWS、GCP、Azure、およびGitLabシークレットマネージャーのシークレット解決失敗が原因別に分類されるようになりました
• RunnerのショートIDが-で始まる場合にKubernetesのポーズポッドが起動に失敗する
• Windowsサービスとして実行中にジョブをキャンセルすると常にプロセスが強制終了される

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

Previously, pasting a copied table into a table cell always merged the copied cells into the existing table, which made it difficult to create a nested table.

Now you can choose how a pasted table behaves:

• Select Paste into cell to insert the copied table as a nested table inside the cell.
• Select Paste and merge into table to distribute the copied cells across the existing table, which remains the default behavior.

You can also use a keyboard shortcut to paste a table into a cell as a nested table: Command+Option+V on macOS, or Control+Alt+V on Windows and Linux.

Standard paste with Control+V or Command+V works as it did before.

Security dashboards are now available at the organization level.

Users can see the following data across all top-level groups in an organization:

• Vulnerability severity panels
• Vulnerabilities over time
• Top 10 CWEs
• Risk score
• Vulnerabilities by age

シークレット検出が公開プロジェクトで漏洩したGitLabパーソナルアクセストークンを検出すると、自動レスポンスによってそのトークンが失効します。GitLab 19.4より前のバージョンでは、失効処理は1つの検出ルールのみを使用し、レガシートークン形式のみを失効させていました。GitLab 18.3以降で作成されたトークンは、ルーティング可能形式またはバージョン付きルーティング可能形式を使用します。GitLabはこれらのトークンを検出してレポートしていましたが、失効させることはありませんでした。

GitLab 19.4以降では、失効処理がGitLabパーソナルアクセストークンの3つの検出ルールすべてに対応しました。

• gitlab_personal_access_token
• gitlab_personal_access_token_routable
• gitlab_personal_access_token_routable_versioned

失効処理は、GitLab Secret Scanning for Source CodeおよびGitleaksベースのアナライザーからの検出結果にも対応しています。設定を変更する必要はありません。自動レスポンスが有効なインスタンスでは、この拡張されたカバレッジがすぐに適用されます。

1つのページからグループ階層全体のスキャナーカバレッジを確認できるようになりました。以前のバージョンのGitLabでは、セキュリティインベントリはサブグループごとのカバレッジを表示するのみで、グループ全体の合計は表示されていませんでした。カバレッジウィジェットにより、グループおよびそのサブグループ内のすべてのプロジェクトにわたるスキャナーカバレッジが集計され、各スキャナーが有効、無効、失敗、または古い状態になっているプロジェクトの割合と数が表示されます。SASTや依存関係スキャンなど特定のスキャナーに絞り込むには、スキャナーのドロップダウンリストを使用します。次にステータスを選択してプロジェクトリストをフィルタリングし、カバレッジされていないプロジェクトのスキャナーを有効にします。

セキュリティインベントリでは、表示する列を制御できるようになりました。脆弱性、ツールカバレッジ、セキュリティ属性の列を表示または非表示にするには、表示を選択します。

以前のバージョンのGitLabでは、依存関係スキャンは既知のCVEを持つパッケージのみを検出していました。タイポスクワッティング、メンテナーアカウントの侵害、または埋め込みマルウェアによって害を与えるように作られた悪意のあるパッケージは、検出結果に表示されませんでした。

GitLab 19.4では、悪意のあるパッケージの検出がベータ版として導入されました。依存関係スキャンがGitLabマルウェアアドバイザリに対して依存関係を確認するようになり、広く知られる前に脅威を検出できます。検出結果は依存関係リストと脆弱性レポートに赤いマルウェアバッジで表示され、常にCritical重大度で、CVEではなくGLAM- IDで識別されます。

マージリクエスト承認ポリシーのマルウェアルールを使用して、悪意のあるパッケージがマージされる前にブロックすることもできます。

追加のセットアップは不要です。サポートされているパッケージタイプ（npm、PyPI、Maven、Go、NuGet、Cargo、RubyGems）に対してカバレッジが適用されます。同じアドバイザリが継続的な脆弱性スキャンにも使用され、オフラインインスタンスでは手動でダウンロードできます。

イシュー606036でフィードバックをお寄せください。

Geo SSHプロキシがデフォルトで有効化

GitLab 19.4では、以下の機能フラグがデフォルトで有効になりました。

• geo_proxy_fetch_ssh_to_primary
• geo_proxy_push_ssh_to_primary

Geo SSHプロキシは、Geoセカンダリサイトへのフェッチおよびプッシュをプライマリサイトにプロキシする際に、より信頼性の高いパスを提供します。また、プッシュオプションを使用したプッシュや大規模リポジトリからのフェッチなど、プロキシ経由の操作が失敗していた長年のバグも解決されます。

Cloud Native GitLabデプロイメントにおける対応が必要

バンドルされたNGINX Ingressを使用するCloud Native GitLabデプロイメントでは、以下のいずれかの対応が必要です。

• このロールアウト前にGateway APIとEnvoy Gatewayへの移行を実施する、または
• ロールアウト後に両方の機能フラグを無効にする。

これらの対応を行わない場合、Geoセカンダリ経由のSSHフェッチおよびプッシュがハングまたはタイムアウトする可能性があります。

詳細については、SSHプロキシに関するGeoトラブルシューティングドキュメントを参照してください。

GitLab 19.3では、予約しきい値に達した場合および上限付き機能が停止した瞬間に、メール通知が送信されるようになりました。ただし、支出上限自体には早期警告の仕組みがなく、上限に関する最初のメールが届く時点では、すでに使用が停止している状態でした。

GitLabでは、機能のオンデマンド使用量が月次支出上限の50%または80%に達した時点で、請求アカウント管理者にメールで通知するようになりました。通知には、対象の機能名とクレジット単位での上限額が記載されます。送信されるのは超過した最も高いしきい値のみで、請求期間ごとに機能あたり最大1回に限られます。なお、$10未満の上限は通知対象外となるため、少額の上限設定によって不要な通知が発生することはありません。

クレジットキャップは、各ユーザーが消費できるGitLabクレジットの上限を制限する機能ですが、これまではGraphQL APIを通じてのみ設定できました。一部のユーザーに異なるキャップを設定するには、ミューテーションを手動で記述する必要がありました。

新しいクレジットキャップページでは、すべてのユーザーにデフォルトで適用されるフラットキャップを設定し、検索可能なピッカーを使用して個々のユーザーにユーザーごとのオーバーライドを追加できます。 このページは、GitLab.comのグループオーナーおよびGitLab Self-Managedの管理者向けに、GitLabクレジット内で利用できます。 キャップの変更をスクリプト化する場合は、引き続きGraphQLミューテーションを使用できます。

クレジット使用状況エクスポートでは、1日1行のデータが提供されていました。これにより、サブスクリプションの消費量は把握できましたが、何に使用されたかは分かりませんでした。クレジットをチーム、プロジェクト、または特定の自動化処理に紐付けるには、推測に頼るしかありませんでした。

エクスポートは2つのCSVファイルを含むZIPファイルとして出力されるようになりました。1つは従来の日次サマリー、もう1つは請求対象イベントごとに1行を含むイベント別ファイルです。各行には、製品、フロータイプ、セッション、ユーザー、ネームスペース、プロジェクト、使用クレジット数、トークン数が含まれます。エクスポートはバックグラウンドで実行され、ファイルの準備が完了するとGitLabからダウンロードリンクがメールで送信されます。

サブスクリプションに一時的な評価クレジットがある場合、すべての使用量はその共有プールから先に消費されていました。各ユーザーの月次含有クレジットは、評価プールが枯渇するまで使用されず、月末にリセットされていました。

GitLabは各ユーザーの含有クレジットを先に消費するようになり、ユーザーが含有クレジットを使い切った後にのみ、一時的な評価クレジットの共有プールから消費するようになりました。月次コミットメントプール、ワンタイムチャージクレジット、およびオンデマンドクレジットは従来と同じ順序で消費されるため、請求額への影響はありません。