公開：2025年4月18日
2分で読めます
GitLab 18.0における破壊的な変更に関するガイド
次期メジャーリリースで予定されている機能の削除に備えましょう。GitLab 18.0にスムーズに移行できるように、ご自身にどのような影響があるかを見極め、ドキュメントに記載されている影響を軽減するためのステップをご確認ください。
次のメジャーリリースであるGitLab 18.0では、DevSecOpsによるイノベーションの限界を打ち破る新機能が多数提供されます。一方で、GitLabからいくつかの非推奨機能が削除される予定です。このページでは、予定されている破壊的な変更についてご留意いただきたい点と、その影響を軽減する方法をご紹介します。
デプロイスケジュール
GitLab.com
GitLab.comでは破壊的な変更が以下の3つの期間にのみデプロイされる予定です。
- 2025年4月21～23日
- 2025年4月28～30日
- 2025年5月5～7日
その他にも多くの変更が、今月いっぱい実装される予定です。各期間中にデプロイされる影響度の高い変更については、こちらの破壊的な変更に関するドキュメントで詳細をご覧いただけます。
注：例外的な状況が生じた場合は、破壊的な変更が上記の期間をわずかに前後する可能性があります。
GitLab Self-Managed
GitLab 18.0は5月15日から提供開始されます。リリーススケジュールの詳細については、こちらをご覧ください。
GitLab Dedicated
GitLab 18.0へのアップグレードは、2025年6月24日から29日までのメンテナンス期間中に行われます。詳細およびご自身の地域のメンテナンス期間については、こちらをご覧ください。
また、18.0へのアップグレードに先立ち、導入される変更点がお客様の環境に及ぼす影響を評価し、必要な対応を計画する上で役立つカスタムツールとリソースをご用意しました。影響を緩和するためのツールとリソースに関する情報はこちらでご確認いただけます。
18.0で削除される予定の全項目の一覧については、非推奨機能のページをご覧ください。今後の予定に加え、デプロイ方法に基づき今年予定されているリリースに向け準備する方法については、本ページでご紹介していますのでぜひ最後までお読みください。
破壊的な変更
影響度：高
1. CI/CDジョブトークン - 「プロジェクトからのアクセスを制限」設定の削除
GitLab.com | Self-Managed | Dedicated
GitLab 14.4ではセキュリティ強化の目的で、プロジェクトのCI/CDジョブトークン（CI_JOB_TOKEN）からのアクセスを制限する設定を追加しました。この設定は当初、CI_JOB_TOKENアクセスを制限という名前でしたが、よりわかりやすくするために、GitLab 16.3でこのプロジェクトからのアクセスを制限という名称に変更されました。
GitLab 15.9では、**認証されたグループとプロジェクト**という別の設定を新たに追加しました。この設定は、許可リストを使用してプロジェクトへのジョブトークンでのアクセスを制御します。新たに追加されたこの設定は、元の設定よりも大幅に改善されています。最初のイテレーションはGitLab 16.0で非推奨となっており、GitLab 18.0で削除される予定です。
すべての新規プロジェクトでは、このプロジェクトからのアクセスを制限設定はデフォルトで無効になります。GitLab 16.0以降のバージョンでは、この設定が無効になったプロジェクトで再度有効にすることはできません。代わりに、認証されたグループとプロジェクト設定を使用して、プロジェクトへのジョブトークンでのアクセスを制御してください。
2. CI/CDジョブトークン - 認証されたグループとプロジェクトの許可リストの強制適用
GitLab.com | Self-Managed | Dedicated
GitLab 15.9で**認証されたグループとプロジェクトの設定（GitLab 16.3でこのプロジェクトへのアクセスを制限**に名称が変更）が導入されたことで、プロジェクトへのCI/CDジョブトークンでのアクセスを管理できるようになりました。このプロジェクトと許可リストに含まれるすべてのグループおよびプロジェクトのみに設定されている場合、許可リストに追加されたグループまたはプロジェクトのみがジョブトークンを使用してプロジェクトにアクセスできます。
- GitLab 15.9より前のバージョンでは、デフォルトでは許可リストは無効になっており（すべてのグループとプロジェクトアクセス設定が選択されていた）、どのプロジェクトからもジョブトークンでアクセスできるようになっていました。
- GitLab 17.6以降のバージョンでは、GitLab Self-ManagedおよびDedicatedインスタンスの管理者は、プロジェクトメンテナーがすべてのグループとプロジェクトを選べないように設定して、すべてのプロジェクトに対してより安全性の高い設定を強制できるようになりました。この変更により、プロジェクト間でのセキュリティレベルをさらに強化できます。
- GitLab 18.0では、この設定がデフォルトで有効になります。GitLab.comでは、プロジェクトの認証ログに基づいて、プロジェクトの許可リストが自動的に作成されます。
- GitLab.comでのこの変更に備えて、クロスプロジェクトの認証にジョブトークンを使用しているプロジェクトメンテナーは、担当するプロジェクトにおいて認証されたグループとプロジェクトの許可リストを入力する必要があります。完了後、このプロジェクトと許可リストに含まれるすべてのグループとプロジェクトのみに設定を変更してください。GitLab 18.0より前のバージョンのプロジェクトの認証ログに基づき許可リストの作成を自動化するには、ご用意している移行ツールのご利用をおすすめします。
- Self-Managedユーザーは18.0へのアップグレードを完了する前に、許可リストの入力を完了する必要があります。
- Dedicatedユーザーは、お客様固有のインスタンスに適した計画を立ててください。GitLabアカウントチームがお手伝いいたします。
3. 依存プロキシへのトークンスコープの強制適用
GitLab.com | Self-Managed | Dedicated
コンテナの依存プロキシは、パーソナルやプロジェクト、グループアクセストークンを用いた**docker loginおよびdocker pull**リクエストを受け取った場合、そのスコープを検証せずにリクエストを受け入れます。
GitLab 18.0では、依存プロキシでの認証の際に**read_registryおよびwrite_registry**スコープが必要となります。この変更の適用後に、これらのスコープを持たないトークンによる認証リクエストが行われた場合、拒否されます。
そのため、アップグレードする前に、必要なスコープを持つアクセストークンを新たに作成し、作成したトークンを使用してワークフローの変数とスクリプトを更新してください。
また、Dependency Token Checkerをご利用いただくことも可能です。コミュニティが開発したスクリプトで、トークンの表示および自動でのローテーションを行えます。
影響度：中
1. GitLab.comでの脆弱性に関する新しいデータ保持制限
GitLab.com - Ultimateプランのお客様のみ
GitLab 18.1から、システムのパフォーマンスと信頼性の向上の目的で、GitLab.comでUltimateプランをご利用のお客様を対象に、6か月間にわたり段階的に新しいデータ保持制限を導入します。データ保持制限は、脆弱性データの保存期間に影響します。
12か月以上前に検出されたもので更新されていない脆弱性は、自動的にコールドストレージアーカイブに移動されます。コールドストレージアーカイブのデータに関する詳細は以下のとおりです。
- GitLab UIからアクセスおよびダウンロード可能
- 3年間保持される
- 3年後に完全に削除される
2. allowed_pull_policiesにないコンテナイメージのプルポリシーを拒否
GitLab.com | Self-Managed | Dedicated
設定済みのプルポリシーはすべて、Runnerの**config.tomlファイル内のallowed_pull_policies設定に含まれていなければなりません。含まれていない場合、incompatible pull policy**エラーにより、ジョブの実行が失敗します。
現在の実装では、複数のプルポリシーが定義されている場合、少なくとも1つのプルポリシーが**allowed-pull-policies**の設定内容と一致すれば、ほかのポリシーが含まれていなくても、ジョブの実行は成功します。
GitLab 18.0では、**allowed-pull-policiesに含まれるプルポリシーと一致するものがない場合にのみ、ジョブが失敗します。ただし、これまでの動作とは異なり、allowed-pull-policies**に含まれるプルポリシーだけをジョブが使用するようになります。この違いにより、現在成功しているジョブがGitLab 18.0では失敗する可能性があります。
3. PostgreSQL 14と15がサポート対象外に
Self-Managed
GitLabは、PostgreSQLの年間アップグレードスケジュールに従っています。
そのため、GitLab 18.0でPostgreSQL 14と15はサポート対象外となる予定です。GitLab 18.0で必要となるPostgreSQLの最小バージョンは、PostgreSQL 16です。
PostgreSQL 14と15は、GitLab 17の全リリースサイクルでサポートされます。PostgreSQL 16は、GitLab 18.0より前のバージョンにアップグレードしたインスタンスでもサポートされます。
この変更に備えて、PostgreSQLクラスターを使用していないインスタンス（Omnibus Linuxパッケージがインストールされた単一のPostgreSQLインスタンスを実行中の場合など）では、GitLab 17.11へのアップグレード時にPostgreSQLをバージョン16に自動的にアップグレードしようと試行します。PostgreSQLクラスターを使用している場合、またはこのような自動アップグレードを希望しない場合、GitLab 18.0にアップグレードするには、事前にPostgreSQL 16に手動でアップグレードする必要があります。その際、アップグレードを行えるように十分なディスク容量があることを確認してください。
4. Terraform CI/CDテンプレートの非推奨化
Self-Managed
Terraform CI/CDテンプレートは非推奨化されており、GitLab 18.0で削除される予定です。影響を受けるテンプレートは以下のとおりです。
Terraform.gitlab-ci.ymlTerraform.latest.gitlab-ci.ymlTerraform/Base.gitlab-ci.ymlTerraform/Base.latest.gitlab-ci.yml
これにより、GitLabはジョブイメージの**terraform**バイナリをBSLライセンスのもとで提供されているバージョンに更新することができなくなります。
引き続きTerraformを使用するには、テンプレートとTerraformイメージを複製し、適宜保持してください。カスタムビルドイメージへの移行手順の詳細についてはこちらでご確認いただけます。
また、代替案として、GitLab.comで新しいOpenTofu CI/CDコンポーネントの使用、またはGitLab Self-Managedで新しいOpenTofu CI/CDテンプレートの使用をおすすめします。 CI/CDコンポーネントはGitLab Self-Managedではまだ利用できませんが、イシュー#415638において、この機能の追加が提案されています。GitLab Self-ManagedでCI/CDコンポーネントが利用可能になると、OpenTofu CI/CDテンプレートは削除される予定です。
新しいOpenTofu CI/CDコンポーネントの詳細についてはこちらをお読みください。
5. Prometheusサブチャートのメジャーアップデート
Self-Managed
GitLab 18.0とGitLabチャート9.0で、Prometheusサブチャートのバージョンが15.3から27.3にアップデートされます。
このアップデートに伴い、デフォルトではPrometheus 3が付属するようになります。
アップグレードを実行するには、手動での設定が必要です。Alertmanager、Node Exporter、Pushgatewayのいずれかが有効になっている場合は、Helm値も更新する必要があります。
詳細については、移行ガイドを参照してください。
影響度：低
1. SUSE Linux Enterprise Server 15 SP2パッケージのビルド終了
Self-Managed
SUSE Linux Enterprise Server (SLES) 15 SP2の長期サービスおよびサポート（LTSS）の提供は、2024年12月に終了しました。
これに伴い、Linuxパッケージインストール用のSLES SP2の配布を終了します。引き続きサポートをご利用いただくには、SLES 15 SP6にアップグレードする必要があります。
2. Gitalyレートリミッターの削除
Self-Managed
以前、GitalyではRPCベースのレート制限がサポートされていました。この機能では期待する結果が得られなかったため、GitLabでは非推奨となります。詳細については、非推奨化に関するイシューをご覧ください。
（非推奨となる）レートリミッターを設定している場合は、エラーは返されず、単に設定が無視されます。
代わりに、並行処理リミッターのご利用をおすすめします。
3. NGINXコントローラーイメージ1.3.1のサポートの非推奨化
Self-Managed
デフォルトのNGINXコントローラーイメージが1.11.2に更新されます。新しいバージョンでは、新たなRBACルールが必要となります。ユーザーによっては、独自のRBACルールを管理するためにnginx-ingress.rbac.create: falseを設定しています。
これらのユーザーは、1.11.2以降のバージョンに移行する前に、RBACルールを追加する必要があります。そのため、このHelm値が上記のように設定されている場合にのみ、1.3.1をデプロイするフォールバックメカニズムを実装しました。また、nginx-ingress.controller.image.disableFallbackも追加しました。デフォルトではfalseに設定されています。独自のRBACを管理しているユーザーは、新しいRBACルールが適用されていることを確認してから、この値をtrueに設定することで、デプロイ環境で1.11.2も使用できるようになります。
なお、バージョン17.5では、1.3.1のイメージのサポートとフォールバックメカニズムを非推奨とする予定です。これにより、1.3.1のサポートが完全に終了となり、多数のセキュリティ上のメリットを得られる1.11.2のみを使用できるようになります。
4. アプリケーションセキュリティテストアナライザーのメジャーバージョンをアップデート
GitLab.com | Self-Managed | Dedicated
GitLab 18.0のリリースに合わせて、アプリケーションセキュリティテストステージで使用されるアナライザーのバージョンが大幅に更新されます。
デフォルトで含まれているテンプレートを使用していない場合、または利用するアナライザーのバージョンを固定している場合は、CI/CDジョブの定義を更新して、固定したバージョンを削除するか、最新のメジャーバージョンに更新する必要があります。
GitLab 17.0～17.11をお使いの場合は、GitLab 18.0のリリースまで、通常どおりアナライザーのアップデートをご利用いただけます。GitLab 18.0以降のバージョンでは、新たに修正されたバグや機能はすべて、新しいメジャーバージョンのアナライザーでのみリリースされます。
GitLabのメンテナンスポリシーに基づき、バグ修正や新機能を非推奨バージョンに実装することはありません。セキュリティパッチは、必要に応じて最新の3つのマイナーリリースにバックポートされます。
5. API Discoveryにおいてデフォルトでブランチパイプラインを利用するように
GitLab.com | Self-Managed | Dedicated
GitLab 18.0では、API DiscoveryのCI/CDテンプレート（API-Discovery.gitlab-ci.yml）のデフォルトの動作が更新されます。
このテンプレートはGitLab 18.0より前のバージョンでは、MRが開いているときに、デフォルトでマージリクエストパイプラインを実行するように設定されていました。
GitLab 18.0からは、ほかのASTスキャナーのStableテンプレートエディションの動作に合わせて、このテンプレートの動作を変更します。
- デフォルトでは、本テンプレートはブランチパイプラインでスキャンジョブを実行するようになります。
- CI/CD変数のAST_ENABLE_MR_PIPELINES: trueを設定すると、MRが開いているときに代わりにMRパイプラインを使用できます。この新しい変数の実装状況は、イシュー#410880で追跡されています。
6. DASTのDAST_DEVTOOLS_API_TIMEOUTのデフォルト値を低めに変更予定
GitLab.com | Self-Managed | Dedicated
DAST_DEVTOOLS_API_TIMEOUTは、DASTスキャンがブラウザからの応答を待つ時間を指定する環境変数です。GitLab 18.0より前のバージョンでは、この変数の値は45秒に固定されていました。GitLab 18.0から、DAST_DEVTOOLS_API_TIMEOUT環境変数に動的な値が設定されます。この値は、他のタイムアウト設定をもとに算出されます。
多くの場合、45秒という値は多くのスキャナー機能のタイムアウト値よりも高いものでした。動的に値を算出することで、__DAST_DEVTOOLS_API_TIMEOUT__変数をよりさまざまな状況で適用できるようになり、使いやすくなります。
影響を制御するためのツールとリソース
予定されている変更点がご利用のGitLabインスタンスに及ぼす影響を把握できるように専用ツールを開発しました。GitLab 18.0にスムーズに移行できるように、ご自身にどのような影響があるかを見極めてから、ドキュメントに記載されている影響を軽減するためのステップをご確認いただくことをおすすめします。
- 非推奨機能の高度な検索：このツールはGitLabのAdvanced Search APIを使って、GitLabのグループやプロジェクト全体で、非推奨に関連する文字列を検索します。手動でチェックすべきファイルがあれば、それも報告します。注：誤検出が生じる可能性もあります。
- 依存関係スキャンビルドサポート検出ヘルパー：このツールは、依存関係スキャンの3つの非推奨事項（1、2、および3。すべて19.0に延期）の影響を受けるプロジェクトを特定します。APIを使用して、関連するファイルとCIジョブ名をスキャンします。
- GitLab Detective（Self-Managedでのみ利用可能）：実験的なツールで、インストールされているGitLabに既知の問題がないか自動的にチェックします。設定ファイルやデータベースの値を調べて、複雑な確認作業を行います。注：必ずGitLabノード上で直接実行してください。
また、GitLab Universityでは、これらの変更点に備え、計画および影響を緩和するための対応を行う上で役立つミニコース（15分以内）を公開しました。ぜひこちらから学習を開始してください。
有料プランをご利用の方で、ご紹介した変更点についてご質問がある場合や、サポートをお求めの場合は、GitLabサポートポータルでサポートチケットを作成してください。
Gitlab.comのFreeプランをご利用の場合は、GitLabドキュメントやGitLabコミュニティフォーラム、Stack Overflowなどのコミュニティソースを通じて追加サポートを受けられます。