GitHub Actionsが承認待ちで実行されない原因と解除方法｜新しい保護動作を解説

GitHub Actionsが「承認待ち」のまま実行されない場合、ワークフローの記述ミスやランナー不足ではなく、GitHubが2026年7月28日に導入した新しいセキュリティ保護が働いている可能性があります。

この保護では、github.com上の公開リポジトリで、潜在的に悪意があると判定されたワークフローが実行前に保留されます。解除するには、リポジトリへの書き込み権限を持つ共同作業者が、ブラウザの認証済みWebセッションから内容を確認して承認しなければなりません。GitHub Enterprise Serverは、現時点では対象外です。(The GitHub Blog)

ただし、承認ボタンをすぐに押すのは危険です。GitHubが想定しているのは、侵害されたアカウントから悪意のあるGitHub Actionsワークフローが追加され、CI/CDの認証情報などを盗まれる攻撃です。まず変更されたワークフローファイル、実行者、トークン権限を確認し、安全だと判断できた場合にだけ承認してください。

GitHub Actionsのワークフローが承認待ちになる原因

GitHubが新しい保護を導入した背景には、侵害されたGitHubアカウントを悪用するサプライチェーン攻撃があります。

攻撃者が共同作業者の認証情報を入手すると、公開リポジトリに悪意のあるワークフローファイルを追加できます。そのワークフローが実行されれば、リポジトリのシークレット、GITHUB_TOKEN、クラウド環境への認証情報などが狙われる可能性があります。

そこでGitHubは、潜在的に悪意があると判定した一部のワークフローを、ジョブの開始前に保留するようにしました。GitHubの発表では、利用者による事前設定は不要で、保護は自動的に適用されると説明されています。(The GitHub Blog)

新しい保護動作の条件は、次のとおりです。

項目	内容
対象サービス	github.com
対象リポジトリ	公開リポジトリ
保留される実行	GitHubが潜在的に悪意があると判定した一部のワークフロー
事前設定	不要。GitHubが自動適用
承認できる人	リポジトリへの書き込み権限を持つ共同作業者
承認方法	認証済みWebセッションから承認
承認後の動作	通常どおりワークフローを続行
GitHub Enterprise Server	現時点では対象外

重要なのは、GitHubが具体的な検出ロジックや判定条件の完全な一覧を公開していない点です。発表では「certain workflow runs」とされているため、すべての不正ワークフローが必ず保留されると考えるべきではありません。

新しい保護は、人間によるコードレビューやアカウント保護の代わりではなく、侵害時の被害を抑える追加防御として扱う必要があります。

新しい保護動作かどうかを見分ける方法

GitHub Actionsには、今回の新しい保護以外にも承認や待機が発生する仕組みがあります。

「承認待ち」「Pending」「Queued」など、似た表示でも解除方法は異なります。

状況	主な原因	確認する場所	対応
ワークフロー全体が実行前に保留	新しい悪意あるワークフロー対策	Actionsのワークフロー実行画面	書き込み権限を持つユーザーがWeb画面から確認・承認
フォーク元からのPRが承認待ち	外部コントリビューター向け承認設定	Pull requestのマージ状況パネル	`Approve workflows to run`から承認
デプロイジョブだけが停止	Environmentの必須レビュー	ワークフロー実行画面のDeployment欄	`Review deployments`から対象環境を承認
`Pending`または`Queued`	concurrency制御や同時実行数の上限	Actionsの実行詳細、ワークフローYAML	先行ジョブの終了やランナーの空きを待つ
チェックがPendingのまま	パス・ブランチ条件やコミットメッセージでスキップ	ワークフローのトリガー条件	トリガー条件を確認し、新しいコミットで再実行

フォークPRの承認とは別の仕組み

従来からGitHub Actionsには、公開リポジトリへのフォークPRについて、外部コントリビューターのワークフローを承認制にする仕組みがあります。

フォークPRの場合は、Pull requestの「Files changed」で変更内容を確認し、マージ状況パネルの「Awaiting approval」から「Approve workflows to run」を選択します。承認できるのは書き込み権限を持つメンテナーです。(GitHub Docs)

一方、2026年7月に導入された新しい保護は、リポジトリ管理者が設定した外部コントリビューター向けポリシーではありません。GitHub自身が実行内容を評価し、潜在的に悪意があると判断したワークフローを自動的に保留します。

GitHubの発表は新しい保護をフォークPRに限定していません。そのため、「共同作業者による通常のpushだから新しい保護ではない」とは判断できません。

Environmentのデプロイ承認とも異なる

Environmentに必須レビュアーを設定している場合は、ワークフロー全体ではなく、対象Environmentを使用するジョブが待機します。

この場合、実行画面に表示される「Review deployments」から環境を選び、「Approve and deploy」を押します。Environmentで自己承認を禁止している場合は、ワークフローを開始した本人が承認できないこともあります。(GitHub Docs)

新しい保護で必要なのは、Environmentのデプロイ承認ではなく、潜在的に悪意があると判定されたワークフローそのものに対する承認です。

PendingやQueuedは承認待ちとは限らない

ワークフローにconcurrencyが設定されていると、同じグループの実行が終わるまで後続の実行がpendingになることがあります。

また、利用可能な同時実行数を使い切っている場合や、条件に一致するセルフホステッドランナーがオフラインの場合も、ジョブはキューに残ります。これらは人間の承認では解決しません。(GitHub Docs)

GitHub Actionsの承認待ちを解除する方法

新しい保護で保留されている場合は、次の手順で確認と承認を行います。

書き込み権限があるアカウントでgithub.comにログインする

承認には、対象リポジトリへの書き込み権限が必要です。

読み取り権限やTriage権限だけでは承認できません。組織リポジトリの場合は、自分に付与されているリポジトリロールも確認してください。

さらに、新しい保護の承認は認証済みWebセッションから行う必要があります。GitHub CLIやREST APIによる自動承認を、この保護の代替として運用しないようにしてください。(The GitHub Blog)

対象リポジトリのActionsを開く

github.comで対象リポジトリを開き、上部メニューから「Actions」を選択します。

左側のワークフロー一覧から対象ワークフローを選び、承認待ちになっている実行を開きます。最近の実行履歴は、Actions画面からワークフロー単位で確認できます。(GitHub Docs)

実行者とコミットを確認する

承認する前に、最低限次の情報を確認します。

ワークフローを発生させたユーザー
対象ブランチ
コミットSHA
コミットメッセージ
push、pull request、workflow_dispatchなどの実行イベント
変更を行ったユーザーが、その変更を認識しているか
通常と異なる時間帯や操作経路ではないか

身に覚えのないユーザーやコミットが表示されている場合は、承認せず、アカウント侵害を前提に調査してください。

ワークフローファイルの差分を確認する

特に確認すべき場所は、次のディレクトリです。

.github/workflows/

新しいYAMLファイルが追加されていないか、既存のワークフローが意図せず変更されていないかを確認します。

フォークPRの承認手順でも、GitHubは.github/workflows/配下の変更を特に注意して確認するよう案内しています。(GitHub Docs)

画面上の承認操作を実行する

変更内容に問題がないと判断できたら、ワークフロー実行画面に表示される承認操作を実行します。

ボタンやパネルの文言はGitHubのUI更新によって変わる可能性がありますが、潜在的に悪意があるとして保留されたことを示す案内と、レビュー・承認の操作が表示されます。

承認が完了すると、保留されていたワークフローは通常どおり続行されます。(The GitHub Blog)

承認前に確認すべきセキュリティ項目

以下は、GitHubが使用している判定条件ではありません。リポジトリ管理者が安全性を判断するための実務的な確認項目です。

確認項目	比較的安全と判断しやすい状態	承認を止めるべき状態
実行者	変更を予定していた既知の共同作業者	本人が操作を否定している、見覚えがない
ワークフローファイル	予定されたテストやビルド処理の変更	未承認のワークフロー追加、難読化されたコマンド
`permissions`	必要な権限だけを個別指定	理由なく書き込み権限や`id-token: write`を追加
シークレット	既存の処理で必要なものだけを参照	新しい外部ホストへの送信処理が追加
外部Action	信頼できるActionをコミットSHAで固定	見覚えのないActionや可変タグを突然追加
シェルコマンド	ビルド・テストに必要な明確な処理	外部スクリプトの直接実行、Base64などによる難読化
セルフホステッドランナー	隔離された一時環境で実行	社内ネットワークや恒久サーバーへ直接アクセス可能
実行トリガー	通常の`push`や`pull_request`	不審な`pull_request_target`や`workflow_run`の追加

GITHUB_TOKENの権限が広がっていないか

ワークフローにpermissionsが追加・変更されている場合は、特に注意が必要です。

例えば、単純なテストでリポジトリへの書き込みが不要なら、次のように読み取り権限へ制限できます。

permissions:
  contents: read

一方、次のような権限が追加されている場合は、用途を確認してください。

permissions:
  contents: write
  packages: write
  id-token: write

これらはリリースやクラウドへのOIDC認証では正当な場合があります。しかし、単なるテストワークフローに突然追加されていれば、承認前の調査が必要です。

外部ActionがコミットSHAで固定されているか

外部Actionをタグだけで参照すると、タグの移動や侵害によって、後から異なるコードが実行される可能性があります。

GitHubは、Actionを変更不能な参照として利用する方法として、完全長のコミットSHAへの固定を推奨しています。(GitHub Docs)

steps:
  - uses: actions/checkout@<full-length-commit-sha>

タグ参照が直ちに悪意を意味するわけではありませんが、承認待ちになった実行でActionの参照先まで変更されている場合は、実際のソースコードを確認してください。

pull_request_targetで外部コードをcheckoutしていないか

pull_request_targetは、ベースブランチ側の権限やシークレットを利用できる強力なイベントです。

このイベントを使いながら、信頼できないフォーク側のコードをcheckoutして実行すると、リポジトリやシークレットが侵害される危険があります。GitHubも、不要なpull_request_targetの利用を避け、信頼できないコードを明示的にcheckoutしないよう案内しています。(GitHub Docs)

次のような変更が突然追加されていた場合は、承認を止めて設計を見直してください。

on:
  pull_request_target:

steps:
  - uses: actions/checkout@<full-length-commit-sha>
    with:
      ref: ${{ github.event.pull_request.head.sha }}

この構成が必ず脆弱とは限りませんが、高い権限を持つコンテキストで外部コードを実行する可能性があるため、慎重な確認が必要です。

セルフホステッドランナーを使用していないか

セルフホステッドランナーは、GitHub-hosted runnerのように毎回クリーンな一時仮想マシンが用意されるとは限りません。

悪意のあるワークフローが実行されると、ランナー上への永続化、内部ネットワークへのアクセス、保存済み認証情報の窃取につながる可能性があります。GitHubは、公開リポジトリのフォークから危険なコードが実行されるリスクを理由に、セルフホステッドランナーを主にプライベートリポジトリで使用することを推奨しています。(GitHub Docs)

公開リポジトリでセルフホステッドランナーを使用している場合は、「承認後にワークフローが成功するか」だけでなく、「実行を許可してもランナーや社内環境が侵害されないか」を確認してください。

承認してよいケースと承認を止めるべきケース

承認してよいと判断しやすい例

次の条件をすべて満たすなら、レビュー後に承認できる可能性が高いでしょう。

ワークフロー変更が事前に計画されている
コミットした本人が変更内容を認識している
.github/workflows/の差分を担当者がレビュー済み
GITHUB_TOKENの権限が必要最小限
新しいシークレット参照や外部送信処理がない
外部Actionの提供元と参照先を確認できる
セルフホステッドランナーへの危険な影響がない

例えば、既知の担当者がNode.jsのバージョンを更新し、それに伴ってテストワークフローを修正したケースです。差分が想定内で、Actionの参照先や権限にも問題がなければ、承認後に通常のCIを続行できます。

承認せず調査すべき例

次のいずれかに該当する場合は、承認しないでください。

コミットした本人が「操作していない」と回答した
.github/workflows/に見覚えのないファイルが追加された
permissionsが突然広げられた
新しいリポジトリシークレットやクラウド認証情報を参照している
curlやwgetで取得したスクリプトを直接実行している
コマンドやURLが難読化されている
知らない外部Actionが追加された
成果物や環境変数を外部サーバーへ送信している
公開リポジトリから社内のセルフホステッドランナーを利用しようとしている

正常な業務変更に見えても、本人確認と差分確認が完了するまでは承認しないことが重要です。

承認ボタンが表示されない場合の確認事項

自分に書き込み権限があるか確認する

新しい保護で承認できるのは、対象リポジトリへの書き込み権限を持つ共同作業者です。

権限がない場合は、リポジトリ管理者や書き込み権限を持つメンバーへ確認を依頼してください。

Webブラウザでログインしているか確認する

今回の保護では、認証済みWebセッションからの承認が必要です。

GitHub CLIでログインしているだけ、またはPersonal Access TokenでAPIを利用できるだけでは、発表されている承認条件を満たしません。github.comをブラウザで開き、正しいアカウントでログインしていることを確認してください。(The GitHub Blog)

フォークPRの承認画面を確認する

フォークPRに起因する従来の承認待ちでは、Actions画面ではなくPull request側から操作します。

対象PRを開き、次の順に確認します。

「Files changed」で差分を確認する
「Awaiting approval」を開く
「Approve workflows to run」を選択する

フォークPRの承認待ちには、30日を超えると実行が自動削除されるという別の仕様があります。この期限が、新しい潜在的悪意ワークフローの保護にも同じように適用されるとは発表されていません。両者を混同しないようにしてください。(GitHub Docs)

Environmentの必須レビュアーか確認する

「Review deployments」が表示されている場合は、新しい保護ではなくEnvironmentのデプロイ承認です。

対象Environmentのレビュアーに指定されているか、自己承認が禁止されていないかを確認してください。(GitHub Docs)

GitHub Enterprise Serverを使用していないか確認する

今回の新しい保護は、現時点ではGitHub Enterprise Serverに追加されていません。

GHESでワークフローが承認待ちになっている場合は、フォークPRの承認ポリシー、Environmentの保護ルール、ランナーの状態、組織やリポジトリのActions設定など、別の原因を確認してください。(The GitHub Blog)

身に覚えのないワークフローだった場合の対応

不審なワークフローを発見した場合は、承認せず、単なる誤検知として処理しないことが重要です。

GitHubが説明している今回の脅威は、侵害されたGitHub認証情報を使って悪意のあるワークフローをpushする攻撃です。ワークフローだけを削除しても、攻撃者がアカウントやトークンへアクセスできる状態が残っていれば、再び変更される可能性があります。(The GitHub Blog)

次の順序で調査してください。

不審なコミットとワークフローを隔離する

まず、対象ブランチやコミットを記録します。

コミットSHA
実行者
実行日時
変更されたファイル
参照されたシークレット名
外部通信先
利用しようとしたランナー
ワークフロー実行ID

証拠を残す前に履歴を書き換えると、侵入経路を追跡しにくくなります。必要な情報を保存してから、不審な変更のrevertやブランチ保護を行います。

アカウントのセキュリティログを確認する

身に覚えのない操作がある場合は、GitHubアカウントのセキュリティログを確認します。

あわせて、次の項目も点検してください。

登録メールアドレス
Personal Access Token
SSHキー
OAuthアプリ
GitHub Apps
リポジトリのWebhook
組織の監査ログ
最近変更されたリポジトリ設定

GitHubも、不正アクセスが疑われる場合は、セキュリティログ、メールアドレス、Webhook、認可済みアプリなどを確認するよう案内しています。(GitHub Docs)

不審なトークンやSSHキーを失効させる

見覚えのないPersonal Access TokenやSSHキーがあれば、削除または失効させます。

アカウント侵害が強く疑われる場合は、関連する認証情報を一括して無効化し、新しいトークンやSSHキーを作成します。ただし、認証情報を失効させると、既存のスクリプトやCI/CD、自動デプロイが停止する可能性があります。影響範囲を確認しながら更新してください。(GitHub Docs)

CI/CDの認証情報をローテーションする

保留されたワークフロー自体が実行前に止まっていれば、その実行によってシークレットが読み取られていない可能性は高いでしょう。

しかし、攻撃者が保留前に別のワークフローを実行していた可能性は残ります。Actionsの実行履歴を確認し、必要に応じて次の認証情報を更新してください。

クラウドサービスのアクセスキー
パッケージレジストリのトークン
コンテナレジストリの認証情報
デプロイ用SSHキー
外部APIキー
Webhookシークレット
長期間有効なPersonal Access Token

同様の問題を防ぐためのGitHub Actions対策

ワークフローファイルをCODEOWNERSで保護する

.github/workflows/をCODEOWNERSの対象にすると、ワークフロー変更について指定担当者のレビューを必須にできます。

.github/workflows/ @example-org/platform-security

GitHubも、ワークフローファイルの変更を監視する方法としてCODEOWNERSの利用を案内しています。(GitHub Docs)

CODEOWNERSだけでなく、ブランチ保護やRulesetと組み合わせて、指定レビューが完了するまでデフォルトブランチへマージできないようにすると効果的です。

GITHUB_TOKENを最小権限にする

リポジトリ全体のデフォルト権限を制限し、ワークフローごとに必要な権限だけを指定します。

permissions:
  contents: read

Issueへの書き込みが必要なジョブだけ、次のように追加します。

permissions:
  contents: read
  issues: write

すべてのワークフローへ一律に書き込み権限を与えないことが重要です。

外部Actionを完全長のコミットSHAで固定する

タグやブランチは便利ですが、参照先が将来変更される可能性があります。

重要なリリースやデプロイ処理では、外部Actionを完全長のコミットSHAで固定し、そのSHAが正規のリポジトリに存在することを確認してください。(GitHub Docs)

長期間有効なクラウド認証情報を減らす

GitHub Actionsからクラウドサービスへ接続する場合は、可能であればOpenID Connectを利用します。

OIDCを使えば、リポジトリに長期間有効なクラウドアクセスキーを保存せず、実行時に短期間だけ有効な認証情報を発行できます。GitHubも、クラウドプロバイダーへの認証では、短期間かつ限定された権限のトークンを利用する方法としてOIDCを推奨しています。(GitHub Docs)

公開リポジトリとセルフホステッドランナーを分離する

公開リポジトリから、社内ネットワークへ接続されたセルフホステッドランナーを直接利用する構成は慎重に設計してください。

必要な場合は、次の対策を組み合わせます。

実行ごとに破棄するエフェメラルランナーを使う
内部ネットワークへの通信を制限する
ランナー専用の低権限アカウントを使う
永続的な認証情報をランナーへ保存しない
承認済みブランチだけがランナーを利用できるようにする
ランナーグループで利用可能なリポジトリを限定する

GitHub Actionsが承認待ちになったときの対応まとめ

GitHub Actionsが突然「承認待ち」になった場合は、まず新しいセキュリティ保護、フォークPR承認、Environment承認、単なるキュー待ちのどれに該当するかを切り分けます。

新しい保護に該当する場合の基本対応は、次のとおりです。

書き込み権限のあるアカウントでgithub.comへログインする
Actionsから保留されたワークフローを開く
実行者、コミット、.github/workflows/の差分を確認する
トークン権限、シークレット、外部Action、外部通信を確認する
安全だと判断できた場合だけWeb画面から承認する
身に覚えがなければ承認せず、アカウント侵害として対応する

この保護は、正常なCI/CDを妨げる単なる待ち時間ではありません。リポジトリや認証情報が侵害される直前で実行を止めている可能性があります。

承認を「ワークフローを動かすための作業」ではなく、リポジトリの権限でコードを実行してよいかを判断するセキュリティレビューとして運用することが重要です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。