【無料ユーザも使えます！】GitLab 18.4 新機能：CI/CD Job Token で Git Push ができるようになった話

はじめに

GitLab 18.4（2025年9月18日リリース）では、CI/CD 周りにうれしいアップデートが入りました。

その中でも Free プランのユーザにも関係する 機能のひとつが、「CI/CD Job Token を使って Git Push できるようになった」というものです。

この記事では、この機能を中心に、仕組みと使い方をわかりやすく解説します。

対象バージョン・プラン

項目	内容
対象バージョン	GitLab 18.4 以降（2025年9月18日リリース）
対象プラン	Free / Premium / Ultimate（全プラン対象）
対象オファリング	GitLab.com / Self-Managed / Dedicated

Free プランでも使えます。

CI/CD Job Token とは？

GitLab のパイプラインジョブが実行されるとき、GitLab は自動的に一時的なトークン（CI_JOB_TOKEN）を発行し、ジョブに渡します。

このトークンは：

• ジョブが実行されている間だけ有効
• ジョブが終了すると自動的に失効する
• パイプラインを起動したユーザと同等のアクセス権限を持つ（ただしアクセスできるリソースはパーソナルアクセストークンより限定的）

これまでも、コンテナレジストリへのログインやパッケージレジストリへのアップロードなど、さまざまな認証に使われてきました。

今回の新機能：Job Token で Git Push が可能に

バージョン履歴

この機能は以下の経緯で正式リリースされています。

• GitLab 17.2：フラグ付きで試験導入（デフォルト無効）
• GitLab 18.3：GitLab.com で有効化
• GitLab 18.4：正式リリース（GA）、フラグ削除

GitLab 18.4 で晴れて フィーチャーフラグが削除され、正式機能 となりました。

何が嬉しいのか

これまで CI/CD パイプラインの中でリポジトリに変更を push する場合、以下のいずれかが必要でした。

• パーソナルアクセストークン（PAT）をシークレット変数に埋め込む
• デプロイキーを設定する

どちらも管理の手間がかかり、トークンの漏洩リスクがありました。

今回の機能を使えば、パイプラインが自動生成する CI_JOB_TOKEN で Git Push が完結 します。トークンを別途発行・管理する必要がありません。

設定方法

手順

1. 対象プロジェクトのページを開く
2. 左サイドバーの「Settings」→「CI/CD」を選択
3. 「Job token permissions」を展開
4. 「Permissions」セクションで 「Allow Git push requests to the repository」 を有効化（UIに保存ボタンが表示される場合は押して確定する）

REST API を使う場合は、ci_push_repository_for_job_token_allowed パラメータをプロジェクト API に渡すことでも設定できます。

動作の仕様

• push できるのは、そのプロジェクト自身のパイプラインで生成された Job Token のみ（デフォルト）
• push が成功しても、CI/CD パイプラインは新たにトリガーされない
• Job Token の権限は、パイプラインを起動したユーザの権限に依存する

実際のパイプライン例

stages:
  - update

auto-commit:
  stage: update
  script:
    - git config user.email "[e-mail]"
    - git config user.name "CI Bot"
    - git remote set-url origin "https://gitlab-ci-token:${CI_JOB_TOKEN}@${CI_SERVER_HOST}/${CI_PROJECT_PATH}.git"
    - git add updated-file.txt
    - git commit -m "CI: 自動更新 [skip ci]"
    - git push origin HEAD:${CI_COMMIT_BRANCH}

[skip ci] をコミットメッセージに含めると、push してもパイプラインが再実行されません。

注意点

Pull Mirror プロジェクトでは使わないこと

プロジェクトが「Pull Mirror（他リポジトリからの自動同期）」として設定されている場合、この設定を有効にするのは危険です。

ミラー元のリポジトリオーナーが CI_JOB_TOKEN を悪用して、ミラー先プロジェクトに不正なコミットを push できてしまう可能性があります。

semantic-release との既知の問題

semantic-release ツールを使っている場合、パーソナルアクセストークンで認証するよう設定していても、このオプションを有効にすると Job Token で認証されてしまうことがあります。Job Token は新しいパイプラインをトリガーしないため、リリースパイプラインが動かないケースが報告されています。

詳細は semantic-release/gitlab の issue #891 を参照してください。

応用：クロスプロジェクトへの Push（GitLab 19.1 以降 GA）

GitLab 19.0 でフラグ付き試験導入、GitLab 19.1 で正式リリース（GA） となった機能として、Allowlist に登録された別プロジェクトの Job Token からも push を許可する 設定があります。

GitOps ワークフロー、サブモジュールのタグ付け、クロスリポジトリ CI/CD パイプラインなど、複数リポジトリをまたいだ自動化に活用できます。

クロスプロジェクト push には以下の条件がすべて必要です。

• ターゲットプロジェクトで「Allow Git push requests to the repository」が有効
• ターゲットプロジェクトで「Allow cross-project Git push requests from allowlisted projects」が有効
• Job Token Allowlist が有効になっている
• ソースプロジェクトが Allowlist に ADMIN_REPOSITORIES の fine-grained permission 付き、またはデフォルト権限（fine-grained 制限なし）で追加されている（ソースプロジェクトを含むグループエントリでも可）
• パイプラインを起動したユーザがターゲットプロジェクトで Developer 以上のロールを持つ

まとめ

GitLab 18.4 で正式リリースされた「CI/CD Job Token による Git Push」機能は、Free プランを含む全ユーザが使える 機能です。

パーソナルアクセストークンやデプロイキーを別途管理しなくても、パイプラインの中で安全にコミット・Push ができるようになりました。

バージョン管理ファイルの自動更新、ドキュメントの自動生成、リリースノートの自動コミットなど、さまざまな自動化に応用できます。

GitLab には Free プランでも使える機能がまだまだたくさんあります。ぜひ色々と試してみて、開発ワークフローをもっと便利にしてみてください。

参考

• GitLab 18.4 リリースノート
• CI/CD job token ドキュメント
• プロジェクト API（ci_push_repository_for_job_token_allowed）