GitLab：「You are not authorized to run this manual job」
手動ジョブを実行しようとして Run が押せず、この文が出るのは、ジョブのデプロイ先が保護された環境で、その Allowed to deploy にあなたのアカウントが入っていないときか、プロジェクトが古いデプロイのジョブを止める設定で、このジョブを動かすと最新のデプロイを上書きしてしまうときです（GitLab の説明「ジョブのトラブルシューティング」・2026年10月28日に確認）。保護されたブランチでも止められます。そちらはパイプラインやジョブの断りへ。
You are not authorized to run this manual job
保護された環境
- デプロイできる人：保護された環境には、権限のある人しかデプロイできません。GitLab の管理者はどの環境も使えます。保護された環境は GitLab の Premium と Ultimate の機能です（保護された環境）。
- 設定の場所：プロジェクトの Settings > CI/CD で Protected environments を開きます（Maintainer 以上）。Allowed to deploy には、役割（Maintainers か、Maintainer と Developer を意味する Developers）、プロジェクトに招待したグループ、Developer・Maintainer・Owner の役割のユーザーを入れられます。
- Reporter の役割：Reporter を入れられるのは、Reporter の役割でプロジェクトに招待したグループを通したときだけです。これはデプロイだけの権限で、ブランチに push やマージができなくてもデプロイできます。
- グループの設定：グループは、
productionのようなデプロイの段階（deployment tier）で環境を保護できます。プロジェクトとグループの両方が保護しているときは、両方で許されている必要があります。 - trigger のジョブ：
triggerがあってenvironmentの無いジョブは保護された環境に結び付かないので、デプロイだけの権限が効きません。trigger のジョブにenvironmentを書きます。 - 手動でないジョブ：そこへデプロイできないユーザーのために始まろうとしたとき、GitLab はジョブを
protected_environment_failureで失敗にします。文は「The environment this job is deploying to is protected. Only users with permission may successfully run this job.」（このジョブのデプロイ先の環境は保護されている。権限のあるユーザーだけがこのジョブを成功させられる）です（GitLab のソースee/app/services/ee/ci/process_build_service.rbとapp/presenters/commit_status_presenter.rb・2026年10月28日に読んだもの）。
Prevent outdated deployment jobs（古いデプロイのジョブを止める）
- 設定：プロジェクトの Settings > CI/CD で General pipelines を開き、Prevent outdated deployment jobs です。古いデプロイのジョブが新しいものより後に終わって、新しいデプロイを上書きするのを防ぎます（デプロイの安全）。
- 手動のジョブ：最新のデプロイより古ければ、GitLab は Run を押せなくし、手動で始めるジョブだが最新のデプロイより古いので動かせない、と出します。
- 始まったジョブ：
failed_outdated_deployment_jobで失敗し、パイプラインではfailed outdated deployment job、ジョブでは「The deployment job is older than the latest deployment, and therefore failed.」（デプロイのジョブが最新のデプロイより古いので失敗した）と出ます。 - 古さ：GitLab が比べるのはジョブの始まった時刻で、コミットの時刻ではありません。パイプライン A（古いコミット）と B（新しいコミット）の両方に手動のデプロイのジョブがあり、B ができた後に A のジョブを始めると、B のジョブが古いとして止められます。
- 巻き戻し：Allow job retries for rollback deployments（既定で有効）なら、もう動いた古いデプロイのジョブを再実行して巻き戻せます。外してあるときは、古いコミットで新しいパイプラインを動かします。
API の答え
- ジョブの実行（
POST /projects/:id/jobs/:job_id/play）：GitLab は、ジョブが動かせるかより先に、あなたのアカウントが動かしてよいかを見るので、答えは400 Unplayable Jobではなく403 Forbiddenです。ジョブの再実行と取り消しも同じように断られます（GitLab のソースlib/api/ci/jobs.rb・app/policies/ci/deployable_policy.rb）。 - GraphQL：ジョブの
playableはジョブが動かせるかで、動かしてよくないアカウントにも true のままです。canPlayJobは、ジョブが動かせて、今のユーザーが動かしてよいかです（app/graphql/types/ci/job_type.rb）。
直す所
- 保護された環境：Maintainer に、あなたのアカウントか役割か、入っているグループを Allowed to deploy に足してもらうか、そこにいる人にジョブを動かしてもらいます。
- 古いジョブ：いちばん新しいパイプラインのデプロイのジョブを動かします。わざと古いコードをデプロイするなら、巻き戻しの再実行が許されていればそのデプロイのジョブを再実行するか、そのコミットで新しいパイプラインを動かします。
- 保護されたブランチ：保護されたブランチでは、そこにマージか push できるユーザーしか手動ジョブを動かせません（保護された環境がデプロイを許していれば別です）。パイプラインやジョブの断りへ。
IntelliJ IDEA で GitLab のジョブを見るなら
Lesstep の Pipeline Inbox for GitLab CI は、JetBrains IDE（2024.1 以降）のプラグインです。GitLab のプロジェクトのパイプラインを、ジョブを段ごとに並べて一覧にし、Pro なら再実行・取り消し・実行もできます。1.0.21 からは、GitLab があなたのアカウントに実行を認めていない手動ジョブ（canPlayJob）では実行を押せなくし、説明に理由（役割か、保護されたブランチや保護された環境の設定か、最新のデプロイより古いジョブ）を出します。403 で断られたときの文も保護された環境に触れます。それより前は、GitLab がジョブを動かせると言えばどこでも出し、403 では役割か保護されたブランチにしか触れませんでした。見るのは無料、再実行・取り消し・実行は Pro（月 US$1.50・30日間の無料試用つき）です。画面は日本語です。
GITLAB は GitLab Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitLab Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。
ほかに：GitLab のパイプラインやジョブの断り（400・403・409・429） · GitLab の「Insufficient permissions to set pipeline variables」 · GitLab のジョブが詰まった・時間切れで落とされた · GitLab のジョブがリソース待ちで進まない · GitLab のジョブのログが見えない・空 · GitLab 18.0 のあとの「This job does not have a trace.」 · GitLab の「insufficient_scope」 · JetBrains の IDE で GitLab のパイプラインを見る · English