GitLab 18.10の概要と2026年3月リリースで変わる開発体験

GitLab 18.10の概要と2026年3月リリースで変わる開発体験

GitLab 18.10は2026年3月19日に公開された最新メジャーリリースです。AI支援によるコーディングが高速化した現在、コードを書いた後のセキュリティスキャン、レビュー、デプロイといった下流工程がボトルネックになりがちですが、今回のリリースはその課題を正面から解消する方向性を打ち出しています。60件以上の改善と212件のコミュニティ貢献が反映され、Duo Agent Platformの無料枠開放、SAST偽陽性のAI自動判定、パスキーによるパスワードレス認証、ワークアイテム統合リストなど、開発からセキュリティ、プロジェクト管理まで幅広い領域でアップデートが行われました。本記事では、各機能の具体的な仕様と導入時に押さえるべきポイントを網羅的に解説します。

60以上の改善を含むGitLab 18.10リリースの全体像

GitLab 18.10には大小合わせて60件以上の機能改善が含まれています。主要なハイライトとして、Duo Agent PlatformのSAST偽陽性検出がGA（正式版）に昇格し、無料枠ユーザーがクレジットを購入してAI機能にアクセスできるようになりました。また、パスキーによるパスワードレスサインインが全プランで利用可能となり、ワークアイテム統合リストと保存ビューが導入されています。CI/CD領域では、ジョブレベルの型安全な入力パラメータ（inputs）が新たに追加され、変数管理の複雑さを大幅に軽減できるようになりました。セキュリティ面ではシークレット誤検知のAI判定がベータとして登場し、セキュリティ構成プロファイルによるプッシュ保護とパイプライン検出の統合管理も実現しています。パッケージ管理ではHelm ChartレジストリがGA昇格、Conan 2.0がベータに昇格し、コンテナ仮想レジストリのUI管理も追加されました。

AI支援コーディング後のボトルネックを解消する設計思想

GitLab 18.10の開発方針は明確で、コード生成が加速した後に残るレビュー・テスト・セキュリティ対応のボトルネック解消を目指しています。AIアシスタントによるコード生成が普及した結果、開発チームの課題はコードを書く速度よりも、書いた後の品質保証プロセスに移行しました。GitLabのChief Product and Marketing OfficerであるManav Khurana氏も、開発チームがこれまで以上に高速にコードをデリバリーしている現状において、セキュリティ確保とデプロイの自動化がその速度に追随する必要があると述べています。エージェントコードレビューは1件あたり0.25ドルの定額で利用でき、全グループ・全プロジェクトに展開可能です。SAST偽陽性の自動判定も、CriticalおよびHigh重要度の脆弱性を対象にAIが自動分析し、トリアージの判断根拠をレポート上に直接表示します。これにより、手動レビューのバックログが数日から数週間の遅延を生むという従来の課題を大幅に緩和できます。セキュリティ対応と開発速度を両立する仕組みが、プラットフォーム全体の設計思想として貫かれているのが18.10の特徴です。

コミュニティ212件の貢献が反映された主要変更の内訳

GitLab 18.10にはコミュニティから212件のコントリビューションが寄せられ、製品品質に大きく貢献しています。今月のNotable Contributorに選ばれたHarshith Sudar氏は、トリアージ自動化のIssueSummaryプロセッサを複数プロジェクトに対応させる改善や、GitLab Duo使用量の計算ロジック改善、DORA指標の日付範囲定数の統合、Value Stream Analyticsのラベルピッカーに無限スクロールを追加するなど、分析基盤とコントリビューター体験の両面で多岐にわたる改善を実施しました。コミュニティ貢献は機能追加だけでなく、バグ修正やパフォーマンス改善、UIの細かな改良にも及んでおり、実際のユーザー視点に立ったフィードバックが製品全体の品質向上に直結しています。オープンソースプロジェクトとしてのGitLabの強みは、こうした外部開発者の継続的な参加によって支えられています。

Free・Premium・Ultimateの3プランで異なる機能提供範囲

GitLab 18.10で追加された機能は、プランごとに利用範囲が異なるため、自チームの契約プランとの照合が必要です。パスキー認証やワークアイテム統合リスト、CI/CDジョブ入力（inputs）、Helm Chartレジストリ、Conan 2.0レジストリはFreeプランを含む全プランで利用可能です。一方、MRタイトルの正規表現バリデーション、コンテナ仮想レジストリのUI管理、エージェント・フローのプロジェクト有効化はPremium以上が必要になります。SAST偽陽性検出やシークレット偽陽性検出、SBOM依存関係スキャン、セキュリティ構成プロファイル、Dart/Flutterライセンススキャンなどのセキュリティ高度機能はUltimate限定です。Duo Agent Platform関連機能は、Ultimateに加えてDuo Core・Duo Pro・Duo Enterpriseのアドオン契約が別途必要なケースもあります。

上記のように、セキュリティ自動化の恩恵を最大限に受けるにはUltimateプランが前提となります。まずは自チームの優先課題と照合し、プランアップグレードの必要性を判断してください。

GitLab 18.9以前との機能差分で見る進化ポイント5選

GitLab 18.10を前バージョンと比較すると、5つの重要な進化ポイントが浮かび上がります。第一に、SAST偽陽性検出が18.7でベータ導入された後、18.10でGA昇格し、本番環境での利用に耐える安定性を確保しました。第二に、Helm Chartレジストリは長期間ベータのままでしたが、index.yamlの1000件制限解消やGeoレプリケーション対応を経てGA昇格しています。第三に、パスキー認証は18.9までfeature flag制御下でしたが、18.10でデフォルト有効となりセルフマネージドインスタンスでも標準利用可能になりました。第四に、CI/CDジョブ入力はこれまで変数のオーバーライド階層に依存していた動的設定を、型安全なinputsで明示的に定義できるように進化しています。第五に、依存関係スキャンのSBOMベースの新方式がGitLab.comだけでなくセルフマネージド環境にも拡張され、CI/CDジョブ実行中に即時スキャン結果が得られるようになりました。

Duo Agent PlatformのGA機能と無料枠ユーザー向けクレジット開放

GitLab 18.10ではDuo Agent Platformの利用範囲が大幅に拡大し、特にコスト面でのハードルが下がりました。無料プランユーザーがクレジットを購入してAIエージェント機能にアクセスできるようになったほか、エージェントコードレビューの定額課金、セルフホスト環境でのVertex AI対応、プロジェクト単位での権限制御など、導入のしやすさと運用管理の両面で強化されています。

無料枠でもクレジット購入でDuo Agent Platformが利用可能に

GitLab 18.10の目玉の一つが、GitLab.comの無料枠ユーザーに対するGitLab Credits購入オプションの開放です。これまでDuo Agent Platformを利用するにはPremiumまたはUltimateのサブスクリプション契約が前提でしたが、月額のクレジットコミットメントを購入するだけでAIエージェント機能にアクセスできるようになりました。購入はGitLabのセルフサービス購入フローで完結し、年間契約の形でクレジットが毎月自動補充されます。グループ内の全メンバーがクレジットを共有できるため、シートごとの個別課金は発生しません。さらに、後からPremiumやUltimateにアップグレードした場合、既存のクレジットコミットメントがそのまま引き継がれるため、将来の拡張も見据えた柔軟な導入が可能です。現時点ではGitLab.comの無料トップレベルグループのみが対象ですが、小規模チームにとってAI活用のハードルを大きく下げる変更といえます。

エージェントコードレビューが1件0.25ドルの定額で使える仕組み

Duo Agent Platformのエージェントコードレビューは、マージリクエスト1件あたり0.25ドル（GitLab Credit換算で1クレジットにつき4レビュー）の定額課金で利用できます。従来、手動コードレビューには開発者の工数がかかり、レビュー待ちのバックログが数日から数週間にわたることも珍しくありませんでした。エージェントコードレビューはリポジトリ全体のコンテキスト、パイプライン情報、セキュリティポリシーを考慮した上で自動レビューを実行し、全グループ・全プロジェクトに展開可能です。レビュー件数が増加するほどスケールメリットが発揮され、人件費と比較して大幅なコスト削減が見込めます。手動レビューを完全に代替するものではありませんが、初期フィルタリングとして活用することで、人間のレビュアーは設計上の判断やビジネスロジックの妥当性確認に集中できるようになります。定額制のため予算管理もしやすく、利用量の予測が立てやすい点も実務上の利点です。

Vertex AIをセルフホスト環境で利用する際の構成要件

GitLab 18.10では、Duo Agent Platform Self-Hostedの対応LLMプラットフォームとしてGoogle Vertex AIが新たに追加されました。セルフマネージド環境のPremiumまたはUltimate顧客は、Vertex AI上でホストされたAnthropicモデルをDuo Agent Platformの各機能に接続できます。この構成により、データの主権を自社インフラ内に保ったままAIエージェント機能を利用することが可能になります。設定はGitLab管理画面のLLMサービング設定からVertex AIのエンドポイントと認証情報を構成する形で行います。注意点として、本機能はGitLab.comやGitLab Dedicated環境では利用できず、セルフマネージドインスタンス限定です。オンプレミスやプライベートクラウドでGitLabを運用しているエンタープライズ組織が、データ残留要件を満たしつつAI機能を導入する際の選択肢として有力な構成といえます。

プロジェクト単位でエージェントを有効化する権限モデルの変更点

GitLab 18.10では、AI CatalogのエージェントやフローをプロジェクトMaintainer権限で直接有効化できるようになりました。以前はトップレベルグループのOwner権限が必要だったため、個別プロジェクトでのAIエージェント導入に管理者の介入が不可避でした。今回の変更により、プロジェクトMaintainerがExploreページやプロジェクト設定から直接エージェントを有効化でき、トップレベルグループOwnerもグループ単位や特定プロジェクトへの適用を一括設定できます。加えて、カスタムエージェントがMCP（Model Context Protocol）を通じて外部データソースやツールに接続する機能も実験的に追加されました。ネットワークアクセス制御はagent-config.ymlのnetwork_policyセクションで構成し、ブランチ保護ルールやMR承認ワークフローによって保護されます。権限の分散とセキュリティ制御を両立する設計になっている点が実務上重要です。

クレジット使用量のCSVエクスポートとセッション単位の監査連携

GitLab Creditsダッシュボードに2つの重要な管理機能が追加されました。1つ目はクレジット使用量のCSVエクスポート機能で、Customers Portal上のCreditsダッシュボードから当月の日次・アクション別消費内訳をCSV形式でダウンロードできます。コミットメント、免除、トライアル、オンデマンド、インクルードの各クレジット区分が明細化されており、ExcelやGoogle Sheets、BIツールでのコスト配賦やチャージバックレポートに直接活用可能です。2つ目はセッション単位の監査連携で、ユーザー別ドリルダウンビューのAction列に、Duo Agent Platformのセッション詳細へのリンクが付与されるようになりました。Agentic ChatやFoundational Agentsの利用行をクリックすると該当セッションに遷移でき、請求とAIセッション挙動の直接的な監査証跡を確保できます。ユーザー一覧のソート機能（クレジット消費量順・ユーザー名順）も追加され、大規模組織での管理効率が向上しています。

SAST誤検知の自動判定とシークレット検出で加速するセキュリティ対応

GitLab 18.10ではセキュリティスキャンの精度向上と運用負担軽減に大きな進展がありました。SAST偽陽性検出のGA昇格、シークレット誤検知AI判定のベータ導入、セキュリティ構成プロファイルの統合管理により、セキュリティチームの日常業務が効率化される構成になっています。

SAST偽陽性検出がGAへ昇格しCritical・High脆弱性を自動分析

SAST偽陽性検出機能は、GitLab 18.7でベータとして導入された後、18.10で正式にGA（一般提供）へ昇格しました。セキュリティスキャン実行後、Duo Agent Platformがデフォルトブランチ上のCriticalおよびHigh重要度のSAST脆弱性を自動的に分析し、偽陽性の可能性を評価します。各評価には信頼度スコアが付与され、80〜100%は偽陽性の可能性が高い、60〜79%は偽陽性の可能性はあるが手動レビュー推奨、60%未満は偽陽性でない可能性が高い、という3段階で判定されます。さらに、なぜその検出結果が偽陽性と判断されたか（またはされなかったか）のAI推論根拠が、コードコンテキスト・データフロー・脆弱性特性を踏まえて説明されます。手動介入なしに自動で分析が実行される点が大きな特徴ですが、個別の脆弱性については脆弱性詳細ページから手動でオンデマンド分析を実行することも可能です。利用にはUltimateプランとDuo Agent Platformの契約が必要で、グループまたはプロジェクトの設定画面から機能を有効化する必要があります。

シークレット誤検知AI判定がベータで導入された背景と信頼度スコア

GitLab 18.10では、SAST偽陽性検出に続いてシークレット検出の偽陽性判定もAI化されました。テスト用認証情報、サンプル値、プレースホルダートークンが本物のシークレットとして誤検知されるケースは実務上多発しており、アラート疲れを引き起こしてスキャン結果への信頼を損なう要因になっていました。本機能では、セキュリティスキャン実行後にGitLab DuoがCriticalおよびHigh重要度のシークレット検出脆弱性を自動分析し、各評価に信頼度スコアを付与します。この信頼度スコアはモデルの確信度を数値化したもので、チームがレビューの優先順位を決定する際の判断材料として活用できます。手動トリガーオプションも用意されており、脆弱性詳細ページから個別にオンデマンド分析を実行することも可能です。現時点ではベータ版としてUltimate顧客に無料提供されていますが、グループまたはプロジェクト設定で明示的に有効化する必要があります。

セキュリティ構成プロファイルでプッシュ保護とパイプライン検出を統合

GitLab 18.9で導入されたセキュリティ構成プロファイルが18.10で拡張され、シークレット検出のプッシュ保護とパイプラインベーススキャンを一元管理できるようになりました。Secret Detection – Defaultプロファイルは3つのスキャントリガーを統合的にカバーします。Push Protectionは全Gitプッシュイベントをスキャンしてシークレットを検知するとプッシュをブロックし、コードベースへのシークレット混入を未然に防止します。Merge Request Pipelinesはオープン中のMRに新しいコミットがプッシュされるたびに自動スキャンを実行し、MRで新たに導入された脆弱性のみを報告します。Branch Pipelines（デフォルトブランチのみ）は変更がマージまたはプッシュされた際に自動実行され、デフォルトブランチのシークレット検出状態を包括的に把握できます。YAML設定は不要で、グループ単位で適用すれば配下の全プロジェクトに伝播し、プロジェクト単位での細かな制御も可能です。

脆弱性レポート上で偽陽性理由を確認するワークフロー実例

SAST偽陽性検出を活用する場合の実務ワークフローを具体的に見てみましょう。まず、デフォルトブランチ上でCI/CDパイプラインのSASTスキャンが正常に完了すると、Duo Agent Platformがバックグラウンドで自動的にCritical・High脆弱性の偽陽性分析を開始します。分析結果は脆弱性レポートの各項目に信頼度スコアとAI推論根拠として付与され、偽陽性の可能性が高い項目にはバッジが表示されます。セキュリティ担当者はレポートを開くだけで、どの脆弱性に優先的に対応すべきかを即座に判断できます。偽陽性と判定された項目は根拠を確認した上でステータスを変更し、真陽性の項目のみに対してリメディエーション作業を進めるという流れです。手動トリガーを使えば、自動分析の対象外だった脆弱性や、後から追加検証が必要になった項目についても個別に分析を実行できます。従来はセキュリティチームがコードを読み込んで手動判定していた工程が自動化されるため、トリアージ時間の大幅な短縮が期待できます。

手動トリガーと自動分析を使い分ける判断基準と運用パターン

偽陽性検出には自動分析と手動トリガーの2つのモードがあり、運用パターンに応じて使い分けることが推奨されます。自動分析はスキャン実行後に自動的に起動するため、日常のCI/CDパイプラインに組み込むだけで追加操作なしに偽陽性判定を受けられます。大量の検出結果が出るプロジェクトでは、自動分析による一次フィルタリングが特に効果的です。一方、手動トリガーは脆弱性詳細ページからオンデマンドで実行するもので、Medium以下の重要度の脆弱性を追加検証したい場合や、コード変更後に再評価が必要な場合に適しています。実務上の判断基準として、パイプラインの通常実行では自動分析に任せ、セキュリティレビュー会議前やリリース直前のタイミングで手動トリガーを活用するパターンが効率的です。なお、SAST偽陽性検出は1フローあたり1 GitLab Creditの消費となるため、大量に手動トリガーを実行する場合はクレジット消費量の事前見積もりが必要です。

CI/CDジョブの型安全入力とRunner 18.10で実現するパイプライン最適化

CI/CD領域ではジョブレベルの型安全な入力パラメータ機能の追加が最大のトピックです。Runner 18.10のアップデートやmacOSイメージの刷新も含め、パイプラインの構成管理と実行環境の両面で改善が進んでいます。

ジョブレベルinputsで型安全なstring・number・boolean・arrayを定義

GitLab 18.10で導入されたジョブレベルinputsは、CI/CDジョブに対して明示的に型付けされた入力パラメータを定義できる機能です。サポートされる型はstring、number、boolean、arrayの4種類で、自動バリデーションが適用されます。従来のCI/CD変数は複雑なオーバーライド階層を持ち、パイプライン実行中に値が変更される可能性がありましたが、inputsはジョブ作成時に補間され固定されるため、予測可能な動作を保証します。定義されていない入力は拒否されるため、意図しないパラメータの混入を防止できます。入力値の参照は${{ job.inputs.INPUT_NAME }}構文で行い、scriptやその他のサポートされたキーワード内で直接使用可能です。ジョブinputsの利用にはGitLab Runner 18.9以上が必要である点に注意してください。

デフォルト値・許可リスト・正規表現バリデーションの設定手順

ジョブinputsは、デフォルト値・許可リスト（options）・正規表現バリデーション（regex）の3つの制御機構を備えています。すべての入力は必ずデフォルト値を持つ必要があり、手動指定なしでもジョブが正常に実行されることを保証します。デプロイ先の環境を制御する場合、optionsにstaging・productionのような許可リストを定義すれば、入力値は大文字小文字を区別した完全一致でバリデーションされます。バージョン文字列のように特定のパターンに準拠させたい場合は、regex制約を使って入力値のフォーマットを強制できます。設定はgitlab-ci.ymlのジョブ定義内にinputsキーワードを追加し、各入力にtype・default・options・regexを指定する形で行います。手動ジョブの実行時やジョブのリトライ時にはUI上でフォームが表示され、入力値を変更できます。APIやGraphQLからの実行時にもjob_inputsパラメータで値を指定可能で、CI/CD自動化パイプラインへの組み込みも容易です。

変数オーバーライド階層の複雑さをinputsで解消する実務例

従来のCI/CD変数による動的設定は、インスタンス・グループ・プロジェクト・ジョブの各レベルでオーバーライドが可能なため、最終的にどの値が適用されるかの追跡が困難でした。特にデプロイ先環境やレプリカ数のような実行時パラメータを変数で管理する場合、意図しないオーバーライドによるデプロイ事故のリスクがありました。ジョブinputsではこの問題が根本的に解決されます。たとえば、デプロイジョブにtarget_env（string型、options: staging/production）、replicas（number型、デフォルト3）、debug_mode（boolean型、デフォルトfalse）を定義すれば、各パラメータの型と許容値が明示的に制約されます。入力値はジョブスコープに限定され、他のジョブやincludeファイルからはアクセスできません。これにより、変数の意図しない伝播や上書きを防止しつつ、リトライ時に値を変更する柔軟性も確保できます。パイプライン変数の代わりにinputsを使用することがGitLab 17.7以降推奨されており、セキュリティ向上の観点からもinputsへの移行が望ましいとされています。

Runner 18.10のPodレベルリソース定義とS3キャッシュ403修正

GitLab Runner 18.10も同日リリースされ、Kubernetes環境での運用改善を中心にいくつかの重要な変更が含まれています。新機能として、Kubernetesランナーでビルドポッドに対してPodレベルリソースを定義できるようになりました。これにより、ポッド全体のリソース上限をジョブ単位で制御し、クラスター内のリソース消費を最適化できます。また、Goのバージョンおよびパッケージ更新を全Runnerプロジェクトで自動化する仕組みが導入され、セキュリティパッチの適用速度が向上しています。バグ修正としては、S3キャッシュでRoleARNを使用した場合にキャッシュが存在しない際に404ではなく403が返される問題、ヘルパーイメージのnanoserver21H2でinit-permissionsエラーが発生する問題、macOS M1アーキテクチャでLaunchAgentサービスの初期化に失敗する問題がそれぞれ解消されました。セルフマネージドのKubernetes環境やmacOSビルド環境を運用しているチームにとって、直接的な恩恵がある修正です。

macOS Tahoe 26・Xcode 26イメージで始めるAppleアプリビルド

GitLab 18.10では、ホステッドランナーのmacOSイメージにmacOS Tahoe 26とXcode 26の組み合わせが追加されました。最新世代のAppleデバイス向けアプリケーションの開発・テスト・デプロイを、GitLab CI/CDに統合されたセキュアなオンデマンドビルド環境で実行できます。利用方法は.gitlab-ci.ymlファイルでイメージとしてmacos-26-xcode-26を指定するだけで、追加のインフラ構築は不要です。ただし、この機能はGitLab.comのPremium以上のプランで利用可能なホステッドランナーが前提であり、セルフマネージドやGitLab Dedicated環境では利用できません。iOSやmacOSアプリの開発チームが自前のMacインフラを維持するコストを削減しつつ、最新のビルドツールチェーンを即座に利用できる点が大きなメリットです。従来のXcodeバージョンを引き続き使用する場合は、既存のイメージ指定をそのまま維持できます。

Helm GA・Conan 2.0対応・仮想レジストリUIで広がるパッケージ管理

パッケージ管理領域では長期間のベータ期間を経たHelm ChartレジストリのGA昇格を筆頭に、Conan 2.0サポートのベータ昇格、コンテナ仮想レジストリのUI管理機能が追加されています。依存関係スキャンの対応範囲拡大と合わせて、パッケージライフサイクル全体の管理がGitLab内で完結しやすくなっています。

Helm ChartレジストリがGA昇格した経緯と1000件制限の解消

Helm Chartレジストリは長らくベータ提供が続いていましたが、GitLab 18.10で正式にGA（一般提供）へ昇格しました。GA昇格にあたっては複数の技術的課題が解消されています。まず、index.yamlエンドポイントが1000チャートを超えると返却できなかったハードリミットが撤廃されました。次に、新しくパブリッシュされたチャートバージョンがインデックスに反映されないバックグラウンドインデキシングのバグが修正されています。さらに、AppSecセキュリティレビューが完了し、Helmメタデータキャッシュのgeoレプリケーションサポートが追加されたことで、GitLab Geoを運用するセルフマネージド顧客の高可用性要件にも対応しました。標準的なHelmクライアントワークフローを使って、パーソナルアクセストークン、デプロイトークン、CI/CDジョブトークンによる認証でチャートのパブリッシュとインストールが行えます。ソースコード、パイプライン、セキュリティスキャンと同じ場所でHelmチャートを管理できる点が、プラットフォームエンジニアリングチームにとっての最大のメリットです。

Conan 2.0レジストリがBetaに昇格しv2 API完全互換を実現

C/C++開発チーム向けのConanパッケージレジストリが、ExperimentalからBetaへ昇格しました。従来はConan 1.xクライアントのみに対応した実験的な提供だったため、Conan 2.0ツールチェーンへの移行済みチームにとっては実用性が限定的でした。18.10ではv2 API完全互換、レシピリビジョンサポート、改善された検索機能、–forceフラグを含むアップロードポリシーの適正処理が実装されています。標準的なConanクライアントワークフローでGitLabから直接パッケージをパブリッシュ・インストールでき、JFrog Artifactoryのような外部アーティファクト管理ソリューションへの依存を減らせます。プロジェクトレベルおよびインスタンスレベルのエンドポイントに対応し、認証方式もパーソナルアクセストークン、デプロイトークン、CI/CDジョブトークンをサポートしています。GA昇格に向けたフィードバックが引き続き募集されているため、導入を検討するチームは早期に試用して課題を報告することが推奨されます。

コンテナ仮想レジストリのUI管理でAPI操作が不要になる変更点

前マイルストーンでベータ導入されたコンテナ仮想レジストリは、Docker Hub、Harbor、Quayなど複数のアップストリームコンテナレジストリを単一のプルエンドポイントに集約する機能です。しかし、初期リリースではすべての構成がAPI呼び出しによる操作に限られており、スクリプトの維持やcurlコマンドの手動管理が必要でした。18.10ではGitLab UIから仮想レジストリの作成・編集・削除、アップストリームソースの認証情報設定が直接行えるようになり、APIを一切呼び出さずに管理が完結します。グループレベルのコンテナレジストリページから操作する形になっており、既存のコンテナレジストリ体験とシームレスに統合されています。この機能はPremium以上のプランで利用可能なベータ版です。プラットフォームエンジニアリングチームが複数のコンテナレジストリを運用している場合、プルエンドポイントの一本化によるネットワーク構成の簡素化と認証管理の集約が見込めます。

SBOM依存関係スキャンがセルフマネージドへ拡張された影響範囲

SBOMベースの依存関係スキャン機能が、GitLab 18.10でセルフマネージドインスタンスにも拡張されました。この機能は18.5でGitLab.com限定のリミテッドアベイラビリティとして初期リリースされ、feature flag dependency_scanning_sbom_scan_apiの配下でデフォルト無効の状態でした。18.10では改善と修正を経てこのfeature flagがデフォルト有効化され、セルフマネージド環境でも利用可能になっています。従来のベータ版はCI/CDパイプライン完了後にSBOMレポートを処理していましたが、新方式ではCI/CDジョブ実行中に即座にスキャン結果が生成されるため、カスタムワークフローで脆弱性データに即時アクセスできます。利用にはv2依存関係スキャンテンプレート（Jobs/Dependency-Scanning.v2.gitlab-ci.yml）のインポートが必要です。問題が発生した場合は、feature flagを無効化することで旧挙動にフォールバックできます。

Gradle・Dart/Flutterプロジェクトで新たに対応した検出項目

GitLab 18.10では、依存関係スキャンとライセンススキャンの対応範囲がGradleプロジェクトとDart/Flutterプロジェクトに拡大されました。Java Gradleプロジェクトについては、これまでロックファイルの存在が前提でしたが、ロックファイルがない場合にbuild.gradleおよびbuild.gradle.ktsファイルへの自動フォールバックが実装されました。フォールバック時は直接依存のみが抽出・報告されます。有効化にはCI/CD変数DS_ENABLE_MANIFEST_FALLBACKをtrueに設定する必要があります。Dart/Flutterプロジェクトについては、pubパッケージマネージャーを使用するプロジェクトのライセンススキャンが新たにサポートされました。ライセンスデータは公式Dartパッケージリポジトリpub.devから取得され、他のエコシステムのスキャン結果と同列に表示されます。なお、Dart/Flutterの依存関係スキャンと脆弱性検出は以前から対応済みであり、今回の追加はライセンスコンプライアンスの面での対応拡充です。

ワークアイテム統合リストとパスキー対応で刷新されるプロジェクト管理

プロジェクト管理とユーザー認証の領域でも、実用性の高いアップデートが行われています。ワークアイテムの統合表示、保存ビュー、パスキー認証、MRタイトルバリデーション、Exploreページの整理と、日常的に使う機能の改善が中心です。

エピック・イシュー・タスクを統合リストで一元表示する利点

GitLab 18.10で導入されたワークアイテムリストは、エピック、イシュー、その他のワークアイテムを単一の統合リストに集約して表示する機能です。これまではワークアイテムの種類ごとに別々のページを切り替える必要があり、計画オブジェクト間の関係性を把握するのに手間がかかっていました。統合リストでは、フィルタリングやソートを使ってすべてのワークアイテムを横断的に確認でき、エピックとその配下のイシューの関係や、プロジェクト横断的なタスクの進捗状況を一覧で把握できます。この機能はGitLabのワークアイテムアーキテクチャ統一に向けた取り組みの一環であり、将来的にはさらに一貫した計画ツール群の提供が予定されています。全プランで利用可能なため、規模を問わずすべてのチームがプロジェクト管理のワークフロー改善に活用できます。スプリント計画やバックログリファインメントの際に、エピックからイシューへのドリルダウンが同一画面内で完結するため、コンテキストスイッチの削減による会議効率の向上も見込めます。

保存ビューでフィルタ・ソート・表示設定をチーム共有する手順

ワークアイテムリストと同時に導入された保存ビュー機能は、カスタマイズしたリスト設定を保存・共有できる仕組みです。フィルタ条件、ソート順序、表示オプションを組み合わせて独自のビューを作成し、名前を付けて保存できます。たとえば「今週のP1イシュー」「レビュー待ちMR」「特定マイルストーンのエピック」といった定型的な確認パターンをビューとして定義しておけば、毎回フィルタを手動設定する手間が省けます。チームメンバー間で標準化されたビューを共有することで、同じ基準でワークアイテムを確認でき、ステータス会議やスプリント計画での認識齟齬を減らすことにつながります。保存ビューの作成はワークアイテムリスト画面からフィルタを設定した後、保存操作を行うだけで完了します。頻繁にアクセスするビューをチーム内で標準化し、プロジェクト管理の一貫性を確保するのが効果的な活用方法です。特に複数のプロジェクトを横断して管理するリーダーやスクラムマスターにとって、用途別のビューを事前に用意しておくことで日常の進捗確認作業を大幅に効率化できます。

パスキー対応でパスワードレスサインインを実現する設定方法

GitLab 18.10ではパスキーによるパスワードレスサインインが全プランで正式にサポートされました。パスキーはWebAuthn技術と公開鍵暗号を基盤とし、デバイスの指紋認証、顔認証、またはPINを使ってアカウントにアクセスします。秘密鍵はデバイス内に保持されGitLabには送信されないため、仮にGitLabのサーバーが侵害されても認証情報の流出リスクがありません。対応デバイスはデスクトップブラウザ（Chrome、Firefox、Safari、Edge）、モバイルデバイス（iOS 16以降、Android 9以降）、FIDO2/WebAuthn対応ハードウェアセキュリティキーです。設定手順は、プロフィール設定からAccess → Password and authenticationに移動し、Passkey sign-inセクションでAdd passkeyを選択、デバイスのプロンプトに従って登録を完了します。2FAが有効なアカウントでは、パスキーがデフォルトの2FA方式として自動的に利用可能になります。セルフマネージド環境では管理者がSign-in restrictionsでパスキー認証の有効・無効を制御できます。

MRタイトルの正規表現バリデーションでマージ前に命名規則を強制

GitLab 18.10では、マージリクエストのタイトルに正規表現パターンを設定し、マージ可能性チェックとして強制できる機能が追加されました。Conventional Commits形式や社内チケット番号の付与ルールなど、チームが定めた命名規則をプラットフォームレベルで担保できます。従来は外部ツールやカスタムCI/CDジョブで命名規則を検証していましたが、パイプライン実行後にタイトルが変更された場合に再検証が行われないという致命的なギャップがありました。新機能ではマージ時点のタイトルを正規表現と照合するため、タイトルがいつ変更されても準拠しない限りマージがブロックされます。設定はプロジェクトのSettings → Merge requestsからMerge request title must match regexフィールドにパターンを入力するだけです。Premium以上のプランで利用可能で、既存のMRワークフローには影響せず、明示的に正規表現を設定したプロジェクトのみに適用されます。

Exploreページのタブ整理でTrending廃止が決定した背景

GitLab 18.10ではExploreページのプロジェクト一覧がリデザインされ、冗長なタブが整理されました。新しいインターフェースはActiveタブとInactiveタブの2つに集約されています。Activeタブには直近のアクティビティがあるプロジェクトが表示され、Inactiveタブにはアーカイブ済みや削除予定のプロジェクトが格納されます。廃止されたタブのうち、Most starredはActive/Inactiveタブのスター数ソートで代替でき、Allタブは両方のタブを参照することで同等の情報にアクセスできます。Trendingタブについては機能が限定的で利用率も低いため、GitLab 19.0で完全撤廃される予定です。今回の変更は他のプロジェクトリストとの視覚的一貫性を確保するためのもので、同じコンテンツにはより論理的な構成と柔軟なソートオプションを通じてアクセスできます。Markdownテーブル内でのタスクアイテムチェックボックス構文サポートも追加され、イシューやエピックのテーブル内で直接タスク完了を追跡できるようになりました。

セルフマネージド環境へのアップグレード時に確認すべき互換性と注意点

セルフマネージドインスタンスのアップグレードには、いくつかの既知の問題と注意事項があります。事前の影響確認と対策を怠ると、データ不整合やサービス停止のリスクがあるため、計画的な移行が重要です。

バッチドバックグラウンドマイグレーション不具合の修正内容

GitLab 18.10では、バッチドバックグラウンドマイグレーションに関する重要なバグ修正（merge request 224446）が含まれています。この修正は18.9のパッチリリースにもバックポートされています。問題の背景として、18.8へのアップグレード時に、対象テーブルのレコードが1件しかないバッチドバックグラウンドマイグレーションが実行されずに完了扱いになるバグが存在していました。この不具合により、データのバックフィルが行われないまま後続のアップグレードが失敗するケースがセルフマネージドインスタンスで発生していました。修正パッチ（merge request 225461）は、影響を受けたマイグレーション（queued_migration_versionが18.5から18.8の範囲でmin_value = max_valueまたはmin_cursor = max_cursorの条件に合致するもの）のステータスをfinished/finalizedからpausedにリセットし、スケジューラーが再実行する仕組みです。18.8経由でアップグレードしたインスタンスは、18.10適用前にこの修正状況を確認することが推奨されます。

18.5以降のNGINXルーティング変更で発生する404エラーの回避策

GitLab 18.5.0で導入されたNGINXルーティング変更が、一致しないホスト名を使用している環境でサービスへのアクセス不能を引き起こす可能性があります。具体的には、設定されたFQDN以外のホスト名（localhostや代替ドメイン名など）でアクセスした場合、ヘルスチェックエンドポイント（/-/healthなど）が正常なレスポンスではなく404エラーを返したり、GitLab WebインターフェースがFQDN以外のホスト名で404エラーページを表示する症状が発生します。セルフマネージド環境では、内部ネットワークからlocalhostやIPアドレスでアクセスするケースが多いため、この問題の影響範囲は広い可能性があります。対応策としては、external_url設定を実際のアクセスFQDNと一致させるか、NGINXの設定をカスタマイズして複数ホスト名を受け付けるようにする方法があります。18.10へのアップグレード前に、現在の環境でどのホスト名経由のアクセスが行われているかを洗い出し、影響範囲を事前評価することが重要です。

ブロックユーザーのデプロイキーAPI拒否が18.8.2で適用された影響

GitLab 18.8.2、18.7.2、18.6.4のパッチリリースから、ブロックされたユーザーに関連付けられたデプロイキーによるAPIリクエストが拒否されるようになりました。この変更はセキュリティ強化を目的としていますが、運用上の影響を見落とすと予期しないCI/CDパイプラインの失敗やデプロイ障害が発生します。特に、退職や異動によってユーザーアカウントがブロックされた際、そのユーザーが作成したデプロイキーがまだアクティブに使用されている場合に問題が顕在化します。18.10へのアップグレードを計画しているチームは、現在使用中のデプロイキーの所有者がブロック状態でないかを事前に確認し、必要に応じて新しいデプロイキーをアクティブユーザーのアカウントで再作成してください。影響を受けるパイプラインの特定には、CI/CDの認証エラーログを確認し、403レスポンスが返されているデプロイキーを洗い出す方法が有効です。

feature flag無効化によるSBOMスキャンのフォールバック手順

SBOMベースの依存関係スキャンがセルフマネージド環境でデフォルト有効化されましたが、問題が発生した場合はfeature flagを無効化して旧挙動にフォールバックできます。対象のfeature flagはdependency_scanning_sbom_scan_apiで、Rails consoleまたはGitLab APIを通じて無効化が可能です。フォールバック後は、CI/CDパイプライン完了後にSBOMレポートを処理する従来の方式に戻ります。ただし、旧方式ではジョブ実行中の即時脆弱性データアクセスができなくなるため、カスタムワークフローに影響がないかを事前に評価してください。新方式への移行はv2依存関係スキャンテンプレート（Jobs/Dependency-Scanning.v2.gitlab-ci.yml）のインポートが前提であり、旧テンプレートを使用している場合はそもそも新方式が適用されません。テンプレートの切り替えとfeature flagの状態は独立して管理されるため、段階的な移行では「まずテンプレートを切り替え → 問題なければfeature flagは有効のまま運用 → 問題発生時のみflag無効化」という手順が安全です。

18.4→18.10の推奨アップグレードパスと事前検証チェックリスト

セルフマネージドインスタンスのアップグレードパスは、GitLabの公式ドキュメントに基づいて計画する必要があります。18.4以降のバージョンではいくつかの既知の問題が累積しているため、段階的なアップグレードが推奨されます。18.4.2/18.4.3ではバッチドバックグラウンドマイグレーションでnil文字列変換エラーが発生する可能性があり、最新パッチへの適用またはワークアラウンドの適用が必要です。18.5ではNGINXルーティング変更の影響確認が必須です。18.8では単一レコードマイグレーションのスキップバグの影響有無を確認し、必要に応じてワークアラウンドを適用します。

1. 現在のバージョンから最新パッチリリースに更新する
2. バッチドバックグラウンドマイグレーションの完了状態を確認する
3. NGINXのホスト名設定とFQDNの一致を検証する
4. デプロイキーの所有者がブロック状態でないか確認する
5. ステージング環境で18.10へのアップグレードを事前テストする
6. post deploymentマイグレーションの実行時間を見積もる
7. ロールバック手順とデータベースバックアップを準備する

特にdesign_management_designsテーブルが大きいインスタンスでは、post deploymentマイグレーションに最大10分程度かかる場合があるため、メンテナンスウィンドウの確保が必要です。

GitLab 18.10導入で開発チームが得られる費用対効果と活用戦略

ここまで解説した各機能を実際のチーム運用に落とし込むと、どのような費用対効果が得られるのでしょうか。導入コストの試算から段階的な活用戦略まで、意思決定に必要な観点を整理します。

クレジット従量課金と従来シート課金のコスト比較シミュレーション

GitLab 18.10で導入された無料枠向けクレジット購入オプションにより、AI機能の利用コスト構造が変わりました。従来はPremiumまたはUltimateのシート課金が前提でしたが、クレジット従量課金モデルではシート数に関係なくAI機能の利用量に応じた支出となります。たとえば5人チームでエージェントコードレビューを月100件利用する場合、1件0.25ドル×100件＝月25ドルとなり、Premium契約（月額29ドル/ユーザー×5人＝145ドル）と比較して大幅に低コストです。ただし、クレジットモデルではPremiumの他機能（MRタイトル正規表現、コンテナ仮想レジストリUIなど）は使えないため、AI機能のみの利用を前提とした比較になります。利用量が多いチームではクレジット消費が増加するため、Creditsダッシュボードでの月次監視とCSVエクスポートによるコスト分析が重要です。

最適なモデルはチーム規模とAI機能の利用頻度によって異なるため、まずは月間のレビュー件数やスキャン頻度を基に消費クレジット量を試算してから判断してください。

セキュリティ自動化で手動トリアージ工数を削減する導入効果

SAST偽陽性検出とシークレット偽陽性検出のAI自動化による最大のメリットは、セキュリティチームの手動トリアージ工数の削減です。一般的に、SASTスキャンの結果には多数の偽陽性が含まれ、セキュリティエンジニアがコードを読み込んで真偽を判定する作業に相当な時間が費やされています。AI自動判定により、CriticalおよびHigh重要度の脆弱性について偽陽性の可能性が事前に評価されるため、セキュリティ担当者はAIの判定結果と根拠を確認するだけで済むケースが増えます。シークレット検出に関しても、テスト用トークンやプレースホルダー値の誤検知を信頼度スコア付きで自動仕分けすることで、アラート疲れの軽減が期待できます。定量的な効果はプロジェクトの規模と脆弱性検出数に依存しますが、週あたりのトリアージ会議の時間短縮やリリースサイクルの高速化といった形で効果が現れる傾向があります。導入初期はAI判定結果の精度を手動でも確認し、運用ノウハウを蓄積していくアプローチが推奨されます。

Duo Agent Platformを段階導入する3ステップのロードマップ

Duo Agent Platformの導入は段階的に進めることで、リスクを抑えつつ効果を検証できます。第1ステップはエージェントコードレビューの試行導入です。特定のプロジェクトを選定し、MRに対する自動レビューを有効化して、AI判定の精度と実用性を2〜4週間かけて評価します。レビュー1件0.25ドルのコスト感覚を実際の利用量で体感する期間でもあります。第2ステップはSAST偽陽性検出の有効化です。グループ設定でDuo Agent Platformの偽陽性検出を有効にし、CriticalおよびHigh脆弱性の自動分析をセキュリティパイプラインに組み込みます。この段階でトリアージ工数の変化を定量的に計測してください。第3ステップは全社展開と最適化です。クレジット消費量の実績データに基づいて月間コミットメント額を調整し、カスタムエージェントやMCP連携による外部ツール統合も検討します。各ステップの評価期間は最低2週間を確保し、定量データに基づいて次のステップへ移行するか判断してください。

小規模チームが無料枠クレジットで始めるAI活用の実践例

5人以下の小規模チームがGitLab.comの無料プランでAI機能を活用する具体的なシナリオを考えてみましょう。まず、グループOwnerがCreditsの購入フローにアクセスし、月額のクレジットコミットメントを契約します。これだけでグループ内の全メンバーがDuo Agent Platformの各機能にアクセスできるようになります。日常的なユースケースとしては、MRが作成されるたびにエージェントコードレビューを自動実行し、コードスタイルの一貫性チェックや潜在的なバグの指摘を受けるパターンが効果的です。月間50件のMRを処理する場合、レビューコストは12.5ドル程度に収まります。クレジット消費量はCreditsダッシュボードでリアルタイムに確認でき、月末にCSVエクスポートで詳細分析も可能です。将来的にチーム規模が拡大した場合、既存のクレジットコミットメントを維持したままPremiumへのアップグレードが行えるため、初期投資を無駄にせずスムーズに移行できます。

Ultimate移行を判断するための機能要件チェックリスト10項目

PremiumからUltimateへの移行を検討する際、18.10の機能マップに基づいて必要性を評価できます。以下の項目のうち該当数が多いほど、Ultimate移行のメリットが大きくなります。

1. SAST偽陽性検出（GA）を本番パイプラインで活用したい
2. シークレット偽陽性検出（Beta）で誤検知対応を自動化したい
3. SBOMベースの依存関係スキャンを即時結果取得で運用したい
4. Dart/Flutterプロジェクトのライセンスコンプライアンスを管理したい
5. Java GradleプロジェクトでロックファイルなしのSBOMスキャンが必要
6. セキュリティ構成プロファイルで組織横断的なポリシー適用を行いたい
7. Duo Agent Platform Self-HostedでVertex AIを利用したい
8. クレジット使用量のセッション単位監査が必要
9. パイプラインシークレット検出の統合プロファイル管理を導入したい
10. Runner Controllerによるジョブアドミッション制御を試行したい

5項目以上に該当する場合は、Ultimateへの移行コストとセキュリティ自動化による工数削減効果を比較検討することが推奨されます。特にセキュリティスキャンの偽陽性対応に月間20時間以上を費やしているチームでは、AI自動判定によるROIが早期に回収できる可能性が高いといえます。