GitLab 18.10の新機能とパッチ18.10.8までの修正｜保守終了後の19.4・19.5への移行経路

GitLab 18.10は2026年3月19日にリリースされたマイナー版です。GitLab.comのFreeプランでもGitLab Creditsを買えばDuo Agent Platformを使えるようになり、SASTの誤検知判定がGAになりました。公式の日本語ブログによると、改善点は60件以上、コミュニティからのコントリビュートは212件です。

2026年10月31日時点の最新版は10月28日公開の19.5.3で、18.10は6月10日の18.10.8を最後にセキュリティ修正の対象から外れています。この記事では、18.10で入った機能をティア別に整理し、18.10.1〜18.10.8のパッチ履歴、保守終了後に18.10へ積み上がった脆弱性、Self-Managedで18.10を動かしている場合の19.4.5・19.5.3への移行経路をまとめます。19系の機能はGitLab 19.2の解説で扱っています。

まとめ：GitLab 18.10の新機能と保守状況の要点

• リリース日：2026年3月19日（Runner 18.10も同じリリースノートで告知）。最後のパッチは2026年6月10日の18.10.8
• AI機能：GitLab.comのFreeでもクレジットを購入すればDuo Agent Platformを利用できる。Code Review Flowはレビュー1回あたり0.25クレジットの定額。Premium以上ではAgent SkillsとMCPサーバーのパイプライン操作ツールが加わった
• セキュリティ（Ultimate）：SASTの誤検知判定がGA、シークレット検出の誤検知判定がベータ。依存関係スキャンのSBOM方式がSelf-Managedでも既定で有効になった
• CI/CD（全ティア）：ジョブ単位で型付きの入力を定義できるinputsキーワードが追加された（Runner 18.9以降が必要）
• 保守状況：保守対象は19.5・19.4・19.3。18.10.8の公開後、影響範囲に18.10を含む脆弱性は10月28日までに98件見つかったが、18.10向けの修正版は1本も出ていない。CVSS 10.0のCVE-2026-110264も18.10では直らない
• 移行経路：必須の経由版18.11と19.2の最新パッチ（18.11.14・19.2.10）を順に通り、19.4.5か19.5.3まで一気に上げる。経由版は保守対象外で、10月の脆弱性の多くが残る

GitLab 18.10の主な新機能とティア別に異なる提供範囲

GitLab 18.10のリリースノートに載った主な機能を、使えるティアと提供形態で並べました。ティアが合わない機能は、アップグレードしても画面に出てきません。

SASTとシークレットの誤検知判定、Agent Skillsは、Dedicated for Governmentを除く全形態が対象です。macOS Tahoe 26・Xcode 26は、ホステッドRunnerのジョブイメージの提供開始を示しています。

GitLabの画面構成やプロジェクト作成からCI/CDまでの基本操作をまだ押さえていない場合は、GitLabの使い方の手順解説を先に読むと、以下の機能がどこに出てくるかを追いやすくなります。

FreeでのクレジットとCode Review Flowの定額化

GitLab.comのFreeのトップレベルグループでは、オーナーが月額のクレジットを年間契約で購入できるようになりました。基本プランを契約しなくても、Duo Agent Platformのエージェントとフローを使えます。購入したクレジットは毎月補充され、後でPremiumやUltimateに上げても契約は引き継がれます（18.10時点では、Premiumへの切り替えは営業経由の手続きです）。Self-Managedにはこの購入方法がありません。

同じ日に、Code Review Flowの料金がレビュー1回あたり0.25クレジットの定額になりました。マージリクエストの大きさや、フローの内部ステップ数で値段は変わりません。4回のレビューで1クレジットなので、月に何件のMRをAIレビューに回すかが分かれば費用を見積もれます。クレジットの単価や付属分などプラン全体の仕組みは、GitLab Duo Agent PlatformとGitLab Creditsの解説にまとめています。

クレジットの利用明細はCSVで書き出せるようになり、ダッシュボードから消費をエージェントのセッション単位でたどれるようになりました（Premium以上）。

Duo Agent PlatformのAgent Skills・MCP連携・ネットワーク制御

エージェントまわりで実務に効くのは、次の4点です。いずれもPremium以上が対象です。

• Agent Skills：Agent Skillsの仕様に沿ったスキルをプロジェクトのワークスペースに置くと、エージェントが該当する作業のときに自動で読み込む。名前・ファイルパス・カスタムのスラッシュコマンドで手動でも呼べる。IDEのフローとAgentic Chat、CI/CDパイプラインで動くフローで使える
• MCPサーバーのmanage_pipeline：GitLab MCPサーバーのツールとして、パイプラインの作成・キャンセル・リトライ・削除・メタデータ更新を1回の呼び出しで行える
• リモートフローのネットワーク制御：Runner上で動くフローの通信先を、agent-config.ymlのnetwork_policyで許可制にできる。このファイルはブランチ保護とMRの承認で守られる
• 有効化の権限：AI Catalogのエージェントとフローを、プロジェクトのMaintainerが自分のプロジェクトで有効にできるようになった。以前はトップレベルグループのオーナー権限が必要だった

このほか、エージェント用のgitlab_blob_searchツールがグループ全体とインスタンス全体のコード検索に広がり（Free以上）、Self-Managedの「Duo Agent Platform Self-Hosted」でVertex AI上のモデルを使えるようになりました。AI Catalogのカスタムエージェントを外部のMCPサーバーにつなぐ機能は、GitLab.comだけの実験的機能です。

SASTとシークレットの誤検知判定における提供段階と有効化の注意点

Ultimate向けには、スキャン結果のうち重大度がCriticalとHighの検出だけをDuo Agent Platformが分析し、誤検知である可能性を脆弱性レポートに表示する機能が入りました。SAST版は18.7のベータを経て18.10でGAになり、シークレット検出版は18.10でベータとして追加されています。シークレット版は判定に信頼度スコアが付き、テスト用の認証情報やプレースホルダーを見分ける用途を想定しています。

注意点は、シークレット版の有効化手順です。本来は「グループで基盤フローを許可→プロジェクトごとに有効化」の2段階ですが、18.10へアップグレードすると全プロジェクトで有効化済みの状態になります（GitLab 18 upgrade notes）。グループで許可すると配下の全プロジェクトで分析機能が有効になるため、許可する前にプロジェクトの設定を確認してください。

シークレット検出では、18.9で入ったセキュリティ構成プロファイル「Secret Detection – Default」がパイプラインでの走査にも広がりました。プッシュ保護、MRパイプライン、デフォルトブランチのパイプラインの3つの契機を、CI/CDの設定ファイルを触らずにまとめて有効にできます。

ジョブ単位で型付きの入力を定義するinputsの書き方と実行条件

CI/CD変数は上書きの優先順位が複雑で、手動ジョブやリトライのたびに何が効いているか分かりにくくなりがちです。18.10では、ジョブの定義にinputsを書くと、そのジョブだけが受け付ける型付きのパラメータを宣言できるようになりました。型はstring（既定）・number・boolean・arrayの4種で、optionsで許可する値を絞ったり、regexで形式を検証したりできます。

deploy_job:
  inputs:
    target_env:
      default: staging
      options: [staging, production]
    replicas:
      type: number
      default: 3
  script:
    - 'echo "Deploying to ${{ job.inputs.target_env }}"'
    - 'echo "Replicas - ${{ job.inputs.replicas }}"'
    # 実際のデプロイ処理は、入力値を引数などで渡す形で別途実装します。

パイプライン全体のテンプレートに使うspec:inputs（参照は$[[ inputs.NAME ]]）とは別の機能です。ジョブ入力は必ずdefaultを持ち、参照は${{ job.inputs.NAME }}と書き、そのジョブの外からは参照できません。値は手動実行やリトライのときに画面から変えられます。利用にはGitLab Runner 18.9以降が必要です。Jenkinsfileでパイプラインを定義するJenkinsとの書き方の違いはJenkinsの導入と使い方の解説で扱っています。

依存関係スキャンのSBOM方式とSelf-Managedでの機能フラグ

SBOMを使う新しい依存関係スキャンは、18.5でGitLab.com限定・機能フラグdependency_scanning_sbom_scan_api（既定は無効）として始まりました。18.10ではSelf-Managedでも限定提供になり、このフラグが既定で有効になっています。パイプラインの完了後にSBOMを処理する従来のベータ方式と違い、CI/CDジョブの中で脆弱性の結果まで生成します。

使うにはv2テンプレートJobs/Dependency-Scanning.v2.gitlab-ci.ymlをインポートします。Self-Managedで問題が出たときは、管理者がこのフラグを無効にすれば従来の挙動に戻ります。あわせて、Gradleプロジェクトはロックファイルが無くてもDS_ENABLE_MANIFEST_FALLBACKを"true"にすればbuild.gradleとbuild.gradle.ktsから直接の依存関係だけを検出できるようになり、Dart・Flutterのライセンススキャンにも対応しました。いずれもUltimate向けです。

レジストリの提供段階と計画・認証機能の変更

• Helmチャートレジストリ：index.yamlが1,000チャートまでしか返さなかった上限を解消してGAになった
• Conan 2.0：これまでConan 1.x限定の実験的機能だったレジストリが、v2 APIとレシピリビジョンに対応してベータへ昇格した
• ワークアイテムリスト：エピック・イシュー・タスクを1つの一覧に並べ、フィルタや並び順を保存ビューとしてチームで共有できる
• Markdownの表：表のセルにタスク項目のチェックボックスを書けるようになった。以前は生のHTMLを混ぜる必要があった
• パスキー：パスワードレスのサインインと2FAの両方に使える。2FAを有効にしているアカウントでは既定の2FA手段になる。機能自体は18.9でGA
• MRタイトルの正規表現：［設定］＞［マージリクエスト］で指定すると、タイトルが一致するまでマージできない。CIでの検査と違い、後からタイトルを変えても再判定される
• Exploreのプロジェクト一覧：ActiveとInactiveの2タブに整理された。Trendingタブは19.0で削除予定と告知された

GitLab Runner 18.10の変更点と本体更新時の版の整合性

Runner 18.10はGitLab 18.10のリリースノートで同時に告知されました。Kubernetes executorでビルドPodにPodレベルのリソース指定（Pod Level Resources）を定義できるようになり、不具合修正としては、RoleARNを使うS3キャッシュで存在しないキャッシュに404ではなく403が返る問題などが直っています。

Runnerのドキュメントは、Runnerのメジャー・マイナー版をGitLab本体にそろえるよう求めています。マイナー版の違いなら後方互換は保証されますが、上で触れたジョブ入力のように、新機能が特定のRunner版を必要とすることがあります。本体を18.10から上げるときは、Runnerも同じマイナー版へ追従させる計画にしてください。

10月28日のパッチでは、Runnerの更新が別に必須になりました。Runnerは証明書を自前で検証するため、本体を上げても失効した中間CA証明書（次の章で説明）を信頼したままになります。告知はSelf-HostedのRunnerを19.5.1以降へ上げ、ca-certificatesを同梱したジョブイメージを作り直すよう求めています。Runner 19.5.2も同じ日に出ています。Self-HostedのGitLab AI Gatewayを利用している場合は、こちらも本体とは別に修正版へ更新する必要があります。AI Gatewayの修正版は19.4系では19.4.3、19.5系では19.5.3です。

GitLab 18.10.1〜18.10.8のパッチ履歴と脆弱性修正件数

18.10系のパッチ版は18.10.1〜18.10.8の7本です（18.10.2は欠番）。脆弱性の件数は、各パッチリリースの告知のうち影響範囲に18.10が含まれるものを数えました。同じ告知で18.11や19.0向けにだけ修正された脆弱性は含めていません。

18.10.2はGitLabが番号を飛ばした欠番で、この番号のパッチは公開されていません（リポジトリには2026-03-31付のタグだけが残っています）。18.10.3には、WebSocket接続で公開されたメソッドの問題、TerraformステートロックAPIとGraphQL APIのサービス拒否など、重大度Highが3件含まれています。18.10系に残るなら最終の18.10.8まで上げるのが前提ですが、次の章のとおり、18.10.8で止めてよい状況ではもうありません。

GitLab 18.10を使い続けるリスクと2026年10月の保守状況

GitLabの保守ポリシーでは、不具合修正は現行の安定版だけ、セキュリティ修正は現行版と直前2つの月次リリースにバックポートされます。2026年10月15日に19.5が出たので、10月31日時点の保守対象は19.5・19.4・19.3です。18.10は6月10日の18.10.8を最後に修正が止まっています。

18.10.8公開後に見つかった脆弱性98件の時期別の内訳

修正が止まった後も、18.10に影響する脆弱性は見つかり続けています。各パッチ告知の影響範囲（Impacted Versions）を1件ずつ読み、18.10.8が含まれるものを数えました。

9月までの69件には、認証なしでサーバー上の任意のファイルを読めるリポジトリコミットAPIのパストラバーサル（CVE-2026-85706、CVSS 10.0）、GraphQLサブスクリプションの安全でないデシリアライゼーション（CVE-2026-87719、9.9）、GraphQLディレクティブ経由のコードインジェクション（CVE-2026-19478、9.4）が含まれます。10月12日の告知にあるCVSS 10.0のCVE-2026-97229は影響範囲が19.2以降なので、18.10には当たりません。インターネットに公開しているSelf-Managedのインスタンスを18.10で据え置く判断は、この時点で成り立ちません。

CVE-2026-110264とeMudhra証明書の失効も18.10では直らない理由

10月21日の告知で修正されたCVE-2026-110264は、細工した正規表現をコンパイルする処理の整数オーバーフローにより、認証されていない利用者がサーバー上で任意のコードを実行できるおそれがある問題です（CVSS 3.1基本値10.0）。影響範囲の下限は7.0で、18.10系はどのパッチでも対象に入ります。GitLabは保守対象外の18.11・19.0・19.1にもこの1件だけを18.11.13・19.0.10・19.1.9としてバックポートしましたが、18.10向けはありません。

10月28日の告知（CVE-2026-111943）は、秘密鍵が漏えいしたeMudhraの中間CA証明書8件を、GitLabが同梱する証明書ストアの信頼から外すものです。影響範囲は「18.11.14より前の全版」で、こちらも18.10は対象です。この回では19.5.2と19.4.4が欠番になっており、18.10.2と同じく、その番号のパッケージはありません。

告知の受け取り方や、上げられない間に入れる検知ルール、複数のインスタンスの版をまとめて判定するスクリプトは、GitLab脆弱性の対応手順で解説しています。

稼働中のGitLabが18.10系かをAPIで確かめる手順

Self-Managedで今の版を確かめるには、メタデータAPIを呼びます。

curl --request GET \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/metadata"

レスポンスのversionが18.10.x-ee（CEなら18.10.x）のように返れば18.10系です。98件はCEとEEを合わせた集計で、EE限定の問題も含みます。自環境への該当性はエディションと利用機能・設定で確認しますが、該当する問題について18.10向けの修正版はありません。GitLab.comは常に最新版で動いているので、利用者が版を気にする必要はありません。この章の話は、Self-Managedで自分で版を管理している環境に限られます。

GitLab 18.10から19.4.5・19.5.3へのアップグレード経路と所要の準備

必須の経由版18.11.14と19.2.10を通る3段階の手順

GitLab 17.5以降、アップグレード時に必ず経由する版（required upgrade stop）はx.2・x.5・x.8・x.11に固定されています（Plan your upgrade path）。経由版では最初のパッチではなく、そのマイナー版の最新パッチを選びます。2026年10月31日時点の経路は次のとおりです。

1. 18.10.x → 18.11.14（GitLab 18の最後の必須経由版。9月のCVSS 10.0と9.9、10月のCVE-2026-110264、10月28日の証明書の失効がこの版まで届いている）
2. 18.11.14 → 19.2.10（GitLab 19の最初の必須経由版）
3. 19.2.10 → 19.4.5または19.5.3

作業直前にも各経由版と移行先の最新パッチを確認してください。各段階では、バックグラウンドマイグレーションが終わったのを確かめてから次へ進みます。18.9以降は次のRakeタスクで一覧と進捗を見られます。

sudo gitlab-rake gitlab:background_migrations:list

途中の版の組み合わせは、GitLabサポートチームが公開しているUpgrade Path toolで計算できます。19.5.3と19.4.5には通常のマイグレーションが含まれ、単一ノード構成ではマイグレーションの完了までGitLabが起動しないためダウンタイムが必要です。マルチノード構成のゼロダウンタイムアップグレードは、マイナー版を1つずつ上げることが条件なので、上の3段階の経路をそのまま無停止で進めることはできません。停止点がx.2・x.5・x.8・x.11に置かれる仕組みと、停止点を1つずつ上げるコマンドはGitLabアップグレードパス：必須停止点の経由手順とコマンドで扱っています。PostgreSQLのメジャー更新も別途計画が必要です。

経由版の18.11.14と19.2.10で運用を止めてはいけない理由

経由版は通過点で、ここで作業を中断すると脆弱な状態が続きます。18.11と19.2は10月31日時点では保守対象外です。19.2には10月12日の通常のセキュリティ修正も届いていますが、10月21日と28日の対象外系列へのセキュリティ修正は、CVE-2026-110264と証明書の失効への対応に限られます。

• 18.11.14：10月12日の告知で18.10にも影響する17件は「19.2.8未満」が対象で、18.11には修正版が無い。10月21日の残り11件のうち10件も未修正
• 19.2.10：10月12日分は19.2.8で修正済み。ただし10月21日の残り11件は影響範囲が「19.3.6未満」などのため、19.2.10にも残る
• 19.4.5・19.5.3：10月12日・21日・28日の告知の脆弱性がすべて修正済み

段階ごとにバックグラウンドマイグレーションを待つと、18.11.14から19.4.5まで数日かかることがあります。インターネットから到達できるインスタンスなら、作業期間中は外部からのアクセスをVPNや許可IPに絞り、最後の段まで一気に進める計画を立ててください。

移行先を19.4.5と19.5.3から選ぶ際の保守期間の違いと判断基準

保守ポリシーでは、マイナー版は毎月第3木曜日に出ます。この日程に当てはめると19.6は2026年11月19日、19.7は12月17日、19.8は2027年1月21日で、次のメジャー版20.0は2027年5月20日の予定と明記されています（いずれも予定）。セキュリティ修正の対象は直近3つのマイナー版なので、19.4系は19.7が出る12月17日ごろに、19.5系は19.8が出る1月21日ごろに対象から外れる見込みです。

• 19.5.3を選ぶ場面：次の更新まで1か月長く保守を受けたい、19.5の新機能を使いたい、Runnerも同時に19.5系へそろえられる。19.5はx.5の必須経由版でもあるので、次に19.8以降へ上げるときの起点になる
• 19.4.5で止める場面：検証環境で19.4系を確認済みで、手順書をそのまま流用したい。19.5の破壊的変更をまだ評価していない

19.4.5を選ぶと、2か月足らずで次の更新が必要になります。どちらを選んでも、月2回のパッチリリースを追い続ける運用が前提です。18.10のように保守切れの版で数か月止まった原因が、更新手順の属人化やCI/CDの検証不足にあるなら、DevOps・CI/CD導入支援で版の追従を含む運用設計から相談できます。

18.10系の既知の不具合と仕様変更における影響範囲と更新前の対処

アップグレード前の版や作業中に踏みやすい問題を、GitLab 18 upgrade notesから抜き出しました。

表のHelm・Operatorのジョブ滞留は、Sidekiqのジョブが滞留する問題です。SLES 12.5について、公式更新ノートの表は18.10.4〜18.10.5をインストール可能とする一方、本文の列挙には18.10.5が含まれていません。公式記述に食い違いがあるため、18.10.5を選ぶ場合は事前検証が必要です。

最後の行はUltimateのパイプライン実行ポリシーに関わる仕様変更です。18.10から、variables_overrideでallowed: falseを設定したポリシーでは、artifacts:reports:dotenvで渡した変数でもポリシー側の変数を上書きできなくなりました。従来の挙動が必要ならvariables_overrideにdotenv: allow_overrideを加えます。

18.11と19.0で必要になる環境の更新とOS・データベースの移行条件

経由する版では、GitLab本体より周辺の環境のほうが作業量が多くなります。

• 18.11：Linuxパッケージの単一ノード構成では、アップグレード時にPostgreSQL 17.7へ自動で更新される。Geo構成では自動更新されないので、別途計画が必要
• 18.11：ジョブごとのコンパイル済み設定に1MiBの上限がかかり、超えるとパイプラインを作成できない。19.2.2以降などの修正版では上限を設定で変えられる
• 19.0：PostgreSQL 17が最低要件になり、外部Redis 6のサポートが削除された（Redis 7.0以上かValkey 7.2へ移行）
• 19.0：Container Registryの旧s3ドライバーが削除され、s3・s3awsの名前はs3_v2の別名になった。MinIOなどのS3互換ストレージではregionendpointにhttps://付きのURIが必要になる
• 19.0：LinuxパッケージのUbuntu 20.04とSUSE系のサポートが終了し、MattermostとSpamcheckが同梱されなくなった
• 19.0：gitlab.rbにmattermost[...]の設定が残っているとアップグレードが止まる。18.11.7から上げる場合は設定を消しても止まるため、18.11.9以降を経由する（上の経路の18.11.14なら該当しない）
• 19.0（Helm chart）：同梱のBitnami PostgreSQL・Bitnami Redis・MinIOが削除された。使っている場合は19.0の前に外部サービスへ移す

Linuxパッケージでの運用を続ける場合、Ubuntu 20.04やSLESから対応OSへの移行が必要です。SUSE系を継続する場合は、公式が案内するDocker構成への移行も選択肢になります。OSの移行、外部PostgreSQLの17への更新、外部RedisのRedis 7.0以上かValkey 7.2への更新を先に片付けてから18.11へ進むと、経路の途中で止まらずに済みます。準備に数か月かかり、それまで18.10で動かすしかないなら、セルフホストを続けるかGitLab.comへ移すかを決め直す時期です。GitHubを含めた比較はGitHubとGitLabの違いの解説が参考になります。

よくある質問

GitLab 18.10の版や修正、移行について、よく調べられている5つの疑問に答えます。

GitLabの最新バージョンはいくつですか？

2026年10月31日時点の最新版は、10月28日に19.4.5・19.3.7などと同時に出た19.5.3です。19.5.2は欠番で、パッケージはありません。月次の19.5は10月15日に公開され、次の19.6は11月19日の予定です。18.10はセキュリティ修正の対象から外れています。

GitLab 18.10.3では何が修正されましたか？

2026年4月8日公開のセキュリティパッチで、18.10に関わる脆弱性12件を修正しています。重大度Highは、WebSocket接続で公開されたメソッドの問題、TerraformステートロックAPIのサービス拒否、GraphQL APIのサービス拒否の3件です。18.10.3で止まっているなら、18.10.8ではなく19.4.5以降への移行を計画してください。

GitLab 18.10.2はありますか？

ありません。GitLabは18.10.3の告知で、18.10.2を飛ばしたことを明記しています。リポジトリにv18.10.2タグは残っていますが、パッケージは公開されておらず、18.10.1の次は18.10.3です。

GitLab 18.10にCVE-2026-110264の修正版は出ますか？

2026年10月31日時点で出ていません。保守対象外の18.11・19.0・19.1にはこの1件だけがバックポートされましたが、18.10は対象外で、影響範囲の下限が7.0なので18.10の全パッチが該当します。18.11.14と19.2.10を経由して19.4.5以降へ上げてください。

GitLab Runnerは本体と同じ版に合わせる必要がありますか？

推奨はメジャー・マイナー版の一致です。版が違っても動くことはありますが、ジョブ入力（Runner 18.9以降が必要）のように新機能が使えないことがあります。経由版の段階ごとにRunnerを上げる必要はなく、最終の版に合わせれば足ります。10月28日の証明書の失効はRunner側の更新も必要なので、本体を19.5.3へ上げるならRunnerも19.5.1以降へそろえてください。

関連記事

• GitLab脆弱性の対応手順：CVSS 10.0の修正版19.5.1／19.4.3と判断基準【2026年10月】
• GitLab 19.2とは？Duo CLI・カスタムフローGAで変わる開発運用
• GitLab Duo Agent Platformとは？GA後の機能とGitLab Creditsの実費を解説
• GitHubとGitLabの違い｜ActionsとGitLab CIの対応表・料金・セルフホスト比較
• GitLabの使い方：プロジェクト作成からIssue・MR・CI/CDまでの手順【2026年10月】