正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

CI/CDの設定

  • プラン: Free、Premium、Ultimate
  • 提供形態: GitLab Self-Managed、GitLab Dedicated

管理者エリアでGitLabインスタンスのCI/CDを設定します。

次の設定を使用できます:

  • 変数: インスタンス内のすべてのプロジェクトで使用できるCI/CD変数を設定します。
  • 継続的インテグレーションとデプロイ: Auto DevOps、ジョブ、アーティファクト、インスタンスRunner、パイプライン機能の設定を行います。
  • パッケージレジストリ: パッケージ転送とファイルサイズの制限を設定します。
  • Runner: Runnerの登録、バージョン管理、トークンの設定を行います。
  • ジョブトークンの権限: プロジェクト全体でのジョブトークンアクセスを制御します。
  • ジョブログ: 増分ログの生成などのジョブログの設定を行います。

継続的インテグレーションとデプロイの設定にアクセスする

Auto DevOps、インスタンスRunner、ジョブアーティファクトなどのCI/CD設定をカスタマイズします。

これらの設定にアクセスするには、次の手順に従います:

  1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
  2. 設定 > CI/CDを選択します。
  3. 継続的インテグレーションとデプロイを展開します。

すべてのプロジェクトでAuto DevOpsを設定する

.gitlab-ci.ymlファイルがないすべてのプロジェクトに対して実行するようにAuto DevOpsを設定します。これは、既存のプロジェクトと新しいプロジェクトの両方に適用されます。

インスタンス内のすべてのプロジェクトに対してAuto DevOpsを設定するには、次の手順に従います:

  1. すべてのプロジェクトでデフォルトのAuto DevOpsパイプラインチェックボックスをオンにします。
  2. (オプション)自動デプロイとAuto Review Appsを使用するには、Auto DevOpsベースドメインを指定します。
  3. 変更を保存を選択します。

インスタンスRunner

新しいプロジェクトでインスタンスRunnerを有効にする

すべての新しいプロジェクトで、インスタンスRunnerをデフォルトで利用可能にできます。

インスタンスRunnerを新しいプロジェクトで利用可能にするには、次の手順に従います:

  1. 新しいプロジェクトでインスタンスのRunnerを有効にするチェックボックスをオンにします。
  2. 変更を保存を選択します。

インスタンスRunnerの詳細を追加する

インスタンスRunnerに関する説明テキストを追加します。このテキストは、すべてのプロジェクトのRunner設定に表示されます。

インスタンスRunnerの詳細を追加するには、次の手順に従います:

  1. Instance runner details(インスタンスRunnerの詳細)フィールドにテキストを入力します。Markdown形式を使用できます。
  2. 変更を保存を選択します。

レンダリングされた詳細を表示するには、次の手順に従います:

  1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトまたはグループを見つけます。新しいナビゲーションをオンにした場合、このフィールドは上部のバーに表示されます。
  2. 設定 > CI/CDを選択します。
  3. Runnersを展開します。

プロジェクトのRunner設定に、インスタンスRunnerのガイドラインに関するメッセージが表示されます。

プロジェクトRunnerを複数のプロジェクトで共有する

プロジェクトRunnerを複数のプロジェクトで共有します。

前提要件:

プロジェクトRunnerを複数のプロジェクトで共有するには、次の手順に従います:

  1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
  2. 左側のサイドバーで、CI/CD > Runnersを選択します。
  3. 編集するRunnerを選択します。
  4. 右上隅で、編集 pencil )を選択します。
  5. Restrict projects for this runner(このRunnerのプロジェクトを制限する)で、プロジェクトを検索します。
  6. プロジェクトの左側にある有効を選択します。
  7. 追加の各プロジェクトに対して、このプロセスを繰り返します。

ジョブアーティファクト

ジョブアーティファクトがGitLabインスタンス全体でどのように保存および管理されるかを制御します。

アーティファクトの最大サイズを設定する

ジョブアーティファクトのサイズ制限を設定して、ストレージの使用量を制限します。ジョブ内の各アーティファクトファイルのデフォルトの最大サイズは100 MBです。

artifacts:reportsで定義されたジョブアーティファクトには、異なる制限が適用される場合があります。異なる制限が適用される場合、小さい方の値が使用されます。

この設定は、最終的なアーカイブファイルのサイズに適用され、ジョブ内の個々のファイルには適用されません。

次のアイテムに対してアーティファクトのサイズ制限を設定できます:

  • インスタンス: すべてのプロジェクトとグループに適用される基本設定です。
  • グループ: グループ内のすべてのプロジェクトのインスタンス設定をオーバーライドします。
  • プロジェクト: 特定のプロジェクトのインスタンスとグループの両方の設定をオーバーライドします。

GitLab.comの制限については、アーティファクトの最大サイズを参照してください。

インスタンスのアーティファクトの最大サイズを変更するには、次の手順に従います:

  1. **アーティファクトサイズの上限 (MB)**フィールドに値を入力します。
  2. 変更を保存を選択します。

グループまたはプロジェクトのアーティファクトの最大サイズを変更するには、次の手順に従います:

  1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトまたはグループを見つけます。新しいナビゲーションをオンにした場合、このフィールドは上部のバーに表示されます。
  2. 設定 > CI/CDを選択します。
  3. 一般パイプラインを展開します。
  4. アーティファクトサイズの上限の値を変更します(MB単位)。
  5. 変更を保存を選択します。

アーティファクトのデフォルトの有効期限を設定する

ジョブアーティファクトが自動的に削除されるまでの保持期間を設定します。デフォルトの有効期限は30日です。

期間の構文はartifacts:expire_inに記載されています。個々のジョブ定義は、プロジェクトの.gitlab-ci.ymlファイルに指定されているこのデフォルト値をオーバーライドできます。

この設定の変更は、新しいアーティファクトにのみ適用されます。既存のアーティファクトは、元の有効期限を保持します。古いアーティファクトを手動で期限切れにする方法については、トラブルシューティングのドキュメントを参照してください。

ジョブアーティファクトのデフォルトの有効期限を設定するには、次の手順に従います:

  1. デフォルトのアーティファクトの有効期限フィールドに値を入力します。
  2. 変更を保存を選択します。

最後に成功したパイプラインからのアーティファクトを保持する

有効期限に関係なく、Git ref(ブランチまたはタグ)ごとに、最後に成功したパイプラインからのアーティファクトを保持します。

この設定はデフォルトで有効になっています。

この設定は、プロジェクトの設定よりも優先されます。インスタンスに対して無効になっている場合、個々のプロジェクトに対して有効にすることはできません。

この機能が無効になっている場合、既存の保持されているアーティファクトはすぐには期限切れになりません。アーティファクトを期限切れにするには、新しい成功したパイプラインをブランチに対して実行する必要があります。

すべてのアプリケーション設定には、カスタマイズ可能なキャッシュの有効期間があるため、設定の反映が遅れることがあります。

最新の成功したパイプラインからのアーティファクトを保持するには、次の手順に従います:

  1. 最新の成功したパイプライン内のすべてのジョブの、最新のアーティファクトを保持しますチェックボックスをオンにします。
  2. 変更を保存を選択します。

アーティファクトを有効期限の設定に従って期限切れにするには、このチェックボックスをオフにします。

外部リダイレクト警告ページを表示または非表示にする

ユーザーがGitLab Pagesでジョブアーティファクトを表示するときに、警告ページを表示するかどうかを制御します。この警告は、ユーザーが生成したコンテンツの潜在的なセキュリティリスクについて警告します。

デフォルトでは、外部リダイレクト警告ページが表示されます。非表示にするには、次の手順に従います:

  1. Enable the external redirect page for job artifacts(ジョブアーティファクトの外部リダイレクトページを有効にする)チェックボックスをオフにします。
  2. 変更を保存を選択します。

パイプライン

パイプラインをアーカイブする

指定された期間が経過した後、古いパイプラインとそのすべてのジョブを自動的にアーカイブします。アーカイブされたジョブは、次のようになります:

  • ロックアイコン( lock )が表示され、ジョブログの上部にThis job is archived(このジョブはアーカイブされています)と表示されます。
  • 再実行または再試行できません。
  • 環境の自動停止時に、停止時のデプロイアクションとして実行できません。
  • ジョブログは引き続き表示されます。

アーカイブ期間は、パイプラインが作成された時点から測定されます。少なくとも1日以上である必要があります。有効な期間の例としては、15 days1 month2 yearsなどがあります。パイプラインを自動的にアーカイブしない場合は、このフィールドを空のままにします。

GitLab.comの場合は、スケジュールされたジョブのアーカイブを参照してください。

ジョブのアーカイブを設定するには、次の手順に従います:

  1. パイプラインをアーカイブフィールドに値を入力します。
  2. 変更を保存を選択します。

デフォルトでパイプライン変数を許可する

新しいグループの新しいプロジェクトで、デフォルトでパイプライン変数を許可するかどうかを制御します。

無効にすると、新しいグループのパイプライン変数を使えるデフォルトロール設定が誰にも許可しないに設定され、新しいグループの新しいプロジェクトにカスケードされます。有効にすると、代わりにこの設定のデフォルトがデベロッパーに設定されます。

新しいグループとプロジェクトに対してもっとも安全なデフォルトを維持するために、この設定を無効にすることをおすすめします。

新しいグループのすべての新しいプロジェクトで、デフォルトでパイプライン変数を許可するには、次の手順に従います:

  1. Allow pipeline variables by default in new groups(新しいグループでデフォルトでパイプライン変数を許可する)チェックボックスをオンにします。
  2. 変更を保存を選択します。

グループまたはプロジェクトの作成後に、メンテナーは別の設定を選択できます。

デフォルトでCI/CD変数を保護する

プロジェクトとグループ内のすべての新しいCI/CD変数がデフォルトで保護されるように設定します。保護変数は、保護ブランチまたは保護タグで実行されるパイプラインでのみ使用できます。

すべての新しいCI/CD変数をデフォルトで保護するには、次の手順に従います:

  1. デフォルトで保護されるCI/CD変数チェックボックスをオンにします。
  2. 変更を保存を選択します。

インクルードの最大数を設定する

includeキーワードを使用してパイプラインにインクルードできる外部YAMLファイルの数を制限します。この制限により、パイプラインにインクルードされるファイルが多すぎる場合のパフォーマンスの問題を防ぐことができます。

デフォルトでは、パイプラインには最大150ファイルをインクルードできます。パイプラインでこの制限を超えると、エラーが発生して失敗します。

パイプラインあたりのインクルードできるファイルの最大数を設定するには、次の手順に従います:

  1. 最大インクルードフィールドに値を入力します。
  2. 変更を保存を選択します。

ダウンストリームパイプライントリガーレートを制限する

1つのソースから1分間にトリガーできるダウンストリームパイプラインの数を制限します。

最大ダウンストリームパイプライントリガーレート制限は、プロジェクト、ユーザー、コミットの特定の組み合わせに対して、1分間にトリガーできるダウンストリームパイプラインの数を制限します。デフォルト値は0です。これは、制限がないことを意味します。

Gitプッシュあたりのパイプライン制限

1回のGitプッシュによってトリガーできるタグパイプラインまたはブランチパイプラインの最大数を設定します。この制限の詳細については、Gitプッシュごとのパイプライン数を参照してください。

  1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
  2. 設定 > CI/CDを選択します。
  3. 継続的インテグレーションとデプロイを展開します。
  4. 各Git pushのパイプラインの制限の値を変更します。
  5. 変更を保存を選択します。

デフォルトのCI/CD設定ファイルを指定する

すべての新しいプロジェクトで、CI/CD設定ファイルとしてデフォルトで使用するカスタムパスとファイル名を設定します。デフォルトでは、GitLabはプロジェクトのルートディレクトリにある.gitlab-ci.ymlファイルを使用します。

この設定は、変更後に作成された新しいプロジェクトにのみ適用されます。既存のプロジェクトは、現在のCI/CD設定ファイルパスを引き続き使用します。

カスタムのデフォルトCI/CD設定ファイルのパスを設定するには、次の手順に従います:

  1. デフォルトのCI/CD設定ファイルフィールドに値を入力します。
  2. 変更を保存を選択します。

個々のプロジェクトでこのインスタンスデフォルトをオーバーライドするには、カスタムCI/CD設定ファイルを指定します。

パイプライン提案バナーを表示または非表示にする

パイプラインがないマージリクエストにガイダンスバナーを表示するかどうかを制御します。このバナーは、.gitlab-ci.ymlファイルの追加方法に関するチュートリアルを示します。

バナーには、GitLabパイプラインの開始方法に関するガイダンスが表示されます。

パイプライン提案バナーはデフォルトで表示されます。非表示にするには、次の手順に従います:

  1. パイプライン提案バナーを有効にするチェックボックスをオフにします。
  2. 変更を保存を選択します。

Jenkins移行バナーを表示または非表示にする

JenkinsからGitLab CI/CDへの移行を推奨するバナーを表示するかどうかを制御します。このバナーは、Jenkinsインテグレーションが有効になっているプロジェクトのマージリクエストに表示されます。

JenkinsからGitLab CIへの移行を促すバナー

Jenkins移行バナーはデフォルトで表示されます。非表示にするには、次の手順に従います:

  1. Jenkinsからの移行バナーを表示するチェックボックスをオンにします。
  2. 変更を保存を選択します。

CI/CDの制限を設定する

リソースの使用状況を制御し、パフォーマンスの問題を防ぐために、CI/CDの制限を設定します。

次のCI/CD制限を設定できます:

  • インスタンスレベルのCI/CD変数の最大数
  • dotenvアーティファクトの最大サイズ(バイト)
  • dotenvアーティファクトの変数の最大数
  • パイプラインごとの最大ジョブ数
  • 現在アクティブなパイプラインの合計ジョブ数
  • プロジェクトとの間のパイプラインサブスクリプションの最大数
  • パイプラインスケジュールの最大数
  • ジョブが持てる必要な依存関係の最大数
  • 過去7日間にグループ内で作成または有効にできるRunnerの最大数
  • 過去7日間にプロジェクト内で作成または有効にできるRunnerの最大数
  • パイプラインの階層ツリー内のダウンストリームパイプラインの最大数

これらの制限によって制御される内容の詳細については、CI/CDの制限を参照してください。

CI/CDの制限を設定するには、次の手順に従います:

  1. CI/CDの制限で、設定したい制限の値を設定します。
  2. 変更を保存を選択します。

パッケージレジストリ設定にアクセスする

NuGetパッケージの検証、Helmパッケージの制限、パッケージファイルサイズの制限、パッケージ転送を設定します。

これらの設定にアクセスするには、次の手順に従います:

  1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
  2. 設定 > CI/CDを選択します。
  3. パッケージレジストリを展開します。

NuGetパッケージのメタデータURLの検証をスキップする

NuGetパッケージ内のprojectUrliconUrl、およびlicenseUrlメタデータの検証をスキップします。

デフォルトでは、GitLabはこれらのURLを検証します。GitLabインスタンスがインターネットにアクセスできない場合、この検証は失敗し、NuGetパッケージをアップロードできません。

NuGetパッケージのメタデータURLの検証をスキップするには、次の手順に従います:

  1. NuGetパッケージのメタデータURLの検証をスキップチェックボックスをオンにします。
  2. 変更を保存を選択します。

チャンネルごとのHelmパッケージの最大数を設定する

チャンネルごとにリストできるHelmパッケージの最大数を設定します。

Helmパッケージの制限を設定するには、次の手順に従います:

  1. パッケージ制限で、チャネル毎のHelmパッケージの最大数フィールドに値を入力します。
  2. 変更を保存を選択します。

パッケージファイルサイズの制限を設定する

ストレージの使用量を制御し、システムのパフォーマンスを維持するために、パッケージの種類ごとにファイルの最大サイズ制限を設定します。

次のパッケージの最大ファイルサイズ制限(バイト単位)を設定できます:

  • Conanパッケージ
  • Helmチャート
  • Mavenパッケージ
  • npmパッケージ
  • NuGetパッケージ
  • PyPIパッケージ
  • Terraformモジュールパッケージ
  • 汎用パッケージ

パッケージファイルサイズの制限を設定するには、次の手順に従います:

  1. パッケージファイルサイズの制限で、設定する制限の値を入力します。
  2. Save size limits(サイズ制限を保存)を選択します。

パッケージ転送を制御する

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed

パッケージがGitLabパッケージレジストリで見つからない場合に、パッケージリクエストをパブリックレジストリに転送するかどうかを制御します。

デフォルトでは、GitLabはパッケージリクエストをそれぞれのパブリックレジストリに転送します:

パッケージ転送を停止するには、次の手順に従います:

  1. 次のいずれかのチェックボックスをオフにします:
    • Forward Maven package requests to the Maven registry if the packages are not found in the GitLab Package registry(パッケージがGitLabパッケージレジストリにない場合、MavenパッケージリクエストをMavenレジストリに転送する)
    • Forward npm package requests to the npm registry if the packages are not found in the GitLab package registry(パッケージがGitLabパッケージレジストリにない場合、npmパッケージリクエストをnpmレジストリに転送する)
    • Forward PyPI package requests to the PyPI registry if the packages are not found in the GitLab package registry(パッケージがGitLabパッケージレジストリにない場合、PyPIパッケージリクエストをPyPIレジストリに転送する)
  2. 変更を保存を選択します。

Runner設定にアクセスする

Runnerのバージョン管理と登録の設定を行います。

これらの設定にアクセスするには、次の手順に従います:

  1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
  2. 設定 > CI/CDを選択します。
  3. Runnersを展開します。

Runnerのバージョン管理を制御する

インスタンスがRunnerのアップグレードが必要かどうかを判断するために、GitLab.comから公式のRunnerバージョンデータをフェッチするかどうかを制御します。

デフォルトでは、GitLabはRunnerバージョンデータをフェッチします。このデータのフェッチを停止するには、次の手順に従います:

  1. Runnerのバージョン管理で、GitLab.comからGitLab Runnerのリリースバージョンデータを取得するチェックボックスをオフにします。
  2. 変更を保存を選択します。

Runner登録を制御する

Runnerを登録できるユーザーと、登録トークンを許可するかどうかを制御します。

Runner登録トークンを渡し、特定の設定引数をサポートするオプションは、レガシーと見なされ、推奨されません。Runner作成ワークフローを使用して、Runnerを登録するための認証トークンを生成します。このプロセスは、Runnerの所有権の完全なトレーサビリティを提供し、Runnerフリートのセキュリティを強化します。

詳細については、新しいRunner登録ワークフローに移行するを参照してください。

デフォルトでは、Runner登録トークンと、プロジェクトメンバーとグループメンバーの登録の両方が許可されています。Runnerの登録を制限するには、次の手順に従います:

  1. Runner登録で次のチェックボックスをオフにします:
    • Runner登録トークンを許可
    • Members of the project can create runners(プロジェクトのメンバーはRunnerを作成できる)
    • Members of the group can create runners(グループのメンバーはRunnerを作成できる)
  2. 変更を保存を選択します。

プロジェクトメンバーのRunner登録を無効にすると、登録トークンが自動的にローテーションされます。前のトークンは無効になり、プロジェクトの新しい登録トークンを使用する必要があります。

特定のグループに対するRunner登録を制限する

特定のグループのメンバーがRunnerを登録できるかどうかを制御します。

前提要件:

  • Runnerの登録設定Members of the group can create runners(グループのメンバーはRunnerを作成できる)チェックボックスがオンになっている必要があります。

特定のグループに対するRunnerの登録を制限するには、次の手順に従います:

  1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
  2. 左側のサイドバーで、概要 > グループを選択し、グループを見つけます。
  3. 編集を選択します。
  4. Runnerの登録で、新しいグループRunnerを登録できますチェックボックスをオフにします。
  5. 変更を保存を選択します。

ジョブトークン権限設定にアクセスする

CI/CDジョブトークンがプロジェクトにアクセスする方法を制御します。

これらの設定にアクセスするには、次の手順に従います:

  1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
  2. 設定 > CI/CDを選択します。
  3. ジョブトークンの権限を展開します。

ジョブトークン許可リストを強制する

すべてのプロジェクトで、許可リストを使用してジョブトークンアクセスを制御することを必須にします。

強制すると、CI/CDジョブトークンがプロジェクトにアクセスできるのは、そのCI/CDジョブトークンのソースプロジェクトがプロジェクトの許可リストに追加されている場合に限られます。詳細については、プロジェクトへのジョブトークンアクセスを制御するを参照してください。

ジョブトークン許可リストを強制するには、次の手順に従います:

  1. 認証されたグループとプロジェクトで、Enable and enforce job token allowlist for all projects(全プロジェクトでジョブトークンの許可リストを有効にして適用する)チェックボックスをオンにします。
  2. 変更を保存を選択します。

ジョブログ設定にアクセスする

CI/CDジョブログの保存と処理の方法を制御します。

これらの設定にアクセスするには、次の手順に従います:

  1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
  2. 設定 > CI/CDを選択します。
  3. ジョブログを展開します。

増分ログの生成を設定する

Redisを使用してジョブログを一時的にキャッシュし、アーカイブされたログをオブジェクトストレージに段階的にアップロードします。これにより、パフォーマンスが向上し、ディスク容量の使用量が削減されます。

詳細については、増分ログの生成を参照してください。

前提要件:

すべてのプロジェクトで増分ログの生成をオンにするには、次の手順に従います:

  1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
  2. 設定 > CI/CDを選択します。
  3. ジョブログセクションを展開します。
  4. Incremental logging configuration(増分ログの生成の設定)で、増分ログを有効にするチェックボックスをオンにします。
  5. 変更を保存を選択します。

必要なパイプライン設定(非推奨)

  • プラン: Ultimate
  • 提供形態: GitLab Self-Managed

この機能は、GitLab 15.9で非推奨となり、17.0で削除されました。17.4以降は、デフォルトで無効になっている機能フラグrequired_pipelinesを有効にした場合にのみ使用できます。代わりに、コンプライアンスパイプラインを使用してください。これは破壊的な変更です。

GitLabインスタンスのすべてのプロジェクトに対して、CI/CDテンプレートを必須のパイプライン設定として指定できます。次のテンプレートを使用できます:

  • デフォルトのCI/CDテンプレート

  • インスタンステンプレートリポジトリに保存されているカスタムテンプレート

    インスタンステンプレートリポジトリで定義された設定を使用する場合、ネストされたinclude:キーワード(include:fileinclude:localinclude:remoteinclude:templateを含む)は機能しません

パイプラインの実行時に、プロジェクトCI/CD設定は必須のパイプライン設定とマージされます。マージ後の設定は、必須のパイプライン設定でincludeキーワードを使用してプロジェクトの設定を追加した場合と同じになります。プロジェクトのマージ済み設定全体を表示するには、パイプラインエディタで設定全体を表示します。

必須のパイプライン設定のCI/CDテンプレートを選択するには、次の手順に従います:

  1. 左側のサイドバーの下部で、Admin Area(管理者エリア)を選択します。
  2. 設定 > CI/CDを選択します。
  3. 必須のパイプライン設定セクションを展開します。
  4. ドロップダウンリストからCI/CDテンプレートを選択します。
  5. 変更を保存を選択します。