2026年11月9日時点で、GitHubは、GitHub Actionsのpull_request_targetを、2026年12月2日からすべての公開リポジトリで既定でブロックすると告知しています。当てはまるActionsのイベントのポリシーで明示的に許可している場合は動き、強制は当初の11月2日の予定から延期されました（GitHubの変更履歴「pull_request_target blocked by default December 2」）。pull_request_targetは、フォーク（元のリポジトリを写して作った別のリポジトリ）からのプルリクエスト（PR）でも、受け側のリポジトリ（ベースリポジトリ）のGITHUB_TOKEN（ジョブごとに自動で作られる認証のトークン）とシークレット（APIキーなどの秘密の値）を使って動くイベントです。対象はGitHub Free・GitHub Team・GitHub Enterprise Cloudの公開リポジトリで、非公開リポジトリと内部（internal）リポジトリは影響を受けず、GitHub Enterprise Server（自社のサーバーで動かす版）も対象外です。
本番の強制の前に、GitHubは一時的に強制する時間帯（ブラウンアウト）を2回設けています。11月9日と11月16日の16:00〜18:00（UTC。日本時間では11月10日と11月17日の1:00〜3:00）で、この間に既定のルールで止められたpull_request_targetのワークフローは、エラーの注釈つきの失敗した実行になります。AIのコードレビューを、フォークからのPRにもAPIキーを使って掛けるためにpull_request_targetを選んでいる公開リポジトリは、12月2日までに「pull_requestなどに変える」「ポリシーで明示的に許可する」「止めたままにする」のどれにするかを決めることになります。
この記事は、2026年11月9日時点で確認したGitHubの変更履歴と公式の文書、AIのコードレビューのActionの文書をもとに書いています。当社はポリシーの設定を試しておらず、画面の名前と手順は公式の文書の表記のままです。
この記事の要点（2026年11月9日時点）
- 何が変わるか：12月2日から、公開リポジトリのpull_request_targetは既定でブロックされます。当てはまるActionsのイベントのポリシーで明示的に許可すれば動きます。非公開・内部リポジトリとGitHub Enterprise Serverは対象外です。
- なぜか：シークレットを使える文脈でフォークのコードを実行すると、パイプラインの乗っ取りやシークレットの持ち出しにつながりうる、というのがGitHubの説明です。
- 確かめ方：設定の「ポリシー分析情報」でブロックされる実行を見られます。手元では .github フォルダをgrepで探せます。
- 直し方：シークレットが要らなければpull_requestに変える、PRのコードを扱いつつシークレットも要るならworkflow_run（別のワークフローの完了で起動するイベント）に分ける、PRのコードを実行しない用途ならワークフローを絞って許可し守りを足します。使っていなければ既定のブロックのままにします。
対象読者：公開リポジトリを持つ開発者・OSSの保守者・会社の開発チームで、pull_request_targetでAIのコードレビューやシークレットを使うActionを動かしている人。
今日やること：公開リポジトリでpull_request_targetを使うワークフローを一覧にし、ポリシー分析情報で止まる実行を確かめる。
pull_request_targetとは｜pull_requestとの違い
pull_request_targetは、GitHub Actionsのワークフローを起動するイベントの1つで、既定ではPRが開かれた・更新された・再び開かれた時に動きます（typesでほかの活動も指定できます）。pull_requestと違うのは、PRのマージコミットではなく、ベースリポジトリの既定のブランチの文脈で動く点です。GitHub Docsは、このイベントを使うとフォークからのPRにラベルを付けたりコメントしたりでき、PRのコードをビルド・実行する必要がある場合は使わないよう書いています（GitHub Docs「ワークフローをトリガーするイベント」）。GitHub Security Labも、もともとPRへのラベル付けやコメントのために導入されたと説明しています（GitHub Security Lab「Preventing pwn requests」）。
2つのイベントの違いを、GitHub Docsの「pull_request_target を安全に使用する」とイベントの文書をもとに並べると次のとおりです。
| 項目 | pull_request | pull_request_target |
|---|---|---|
| 動くワークフローのファイル | PRのマージコミットにあるもの | ベースリポジトリの既定のブランチにあるもの |
| GITHUB_REF（実行の基準になる参照） | refs/pull/番号/merge（開いていてマージできるPRの場合） | 既定のブランチ（GITHUB_SHAはその最新のコミット） |
| actions/checkoutがrefの指定なしで取り出すもの | PRのマージコミット | 既定のブランチ |
| フォークからのPRでのシークレット | GITHUB_TOKEN以外は渡されない | リポジトリと組織のシークレットを使える |
| フォークからのPRでのGITHUB_TOKEN | 読み取り専用 | ベースリポジトリのトークン（読み書きの権限も与えられる） |
| 向いている用途 | PRのコードのビルドとテスト | ラベル付け・トリアージ（仕分け）・コメント・認証済みの状態チェックの投稿（PRのコードを実行しない処理） |
| 12月2日以降の公開リポジトリ | 今回の既定のブロックの対象外 | 既定でブロック（明示的に許可するポリシーがあれば動く） |
GitHub Docsは、pull_request_targetが既定で安全なのは、既定のブランチの信頼できるコードだけが動き、フォークのコードは既定では実行されないからだと説明しています。この前提は、ワークフローの作者がPRのコードを取り出して実行した時に崩れます。
なお、同じリポジトリのブランチから出したPRなら、pull_requestでもシークレットを使えます（GitHub Security Lab）。会社のチームがフォークを使わずにPRを出しているなら、pull_requestで足りる場合があります。AIのコードレビューの道具の全体像はAIコードレビューエージェントの比較にまとめています。
12月2日に変わること｜公開リポジトリで既定でブロック
GitHubの11月2日（日本時間11月3日）の変更履歴の原文は「Starting December 2, 2026, GitHub Actions will block pull_request_target events by default in all public repositories, unless an applicable Actions event policy explicitly allows them.」です。2026年12月2日から、すべての公開リポジトリでpull_request_targetのイベントを既定でブロックし、当てはまるActionsのイベントのポリシーが明示的に許可している場合だけ動かす、という意味です。続く「Enforcement was previously scheduled for November 2, 2026.」のとおり、強制は以前は11月2日の予定でした。
対象と仕組みは次のとおりです（11月2日の変更履歴とGitHub Docs「pull_request_target を安全に使用する」）。
- 対象はGitHub Free・GitHub Team・GitHub Enterprise Cloudの公開リポジトリで、GitHub Enterprise Serverは対象外です。非公開リポジトリと内部リポジトリは影響を受けません。
- このルールは「ワークフロー実行保護」（workflow execution protections。ワークフローを起動できる人とイベントを許可リストで決める仕組み）の既定のルール（Docsの言い方では既定のポリシー）として入り、今は評価モードで動いています。評価モードではワークフローは止まらず、強制の後に止まる実行を「ポリシー分析情報」（英語の画面ではPolicy insights）で確かめられます。
- 既定のポリシーは、すでに構成してある当てはまるイベントのポリシーを置き換えません。
- ブラウンアウトの間は、止められた実行がエラーの注釈つきの失敗になり、ワークフローは動きません。時間帯が終わると評価モードに戻り、警告つきで動きます。
- GitHubが示す選択肢は、既定のルールのままpull_request_targetを止めるか、当てはまるActionsのイベントのポリシーで明示的に許可するかの2つです。許可する時は、ワークフローのファイルを指定して特定のワークフローだけを許可できます。
GitHub Docsと9月17日の変更履歴は、12月2日に強制する対象を「一般提供前に既定の pull_request_target ポリシーを使用していた影響を受けるリポジトリ」（日本語版のDocsの表記）と書いています。9月17日より後に作った公開リポジトリにどう当たるかは、読んだ文書では確かめられませんでした。実際の扱いはポリシー分析情報で見てください。
pull_request_targetの守りは、この1年で段階的に足されてきました。日付は各変更履歴のとおりです。
| 日付 | 変わったこと |
|---|---|
| 2025年12月8日 | pull_request_targetのワークフローのファイルとcheckoutのコミットが、PRのベースのブランチに関係なく、常に既定のブランチから取られるようになった（2025年11月7日の告知） |
| 2026年6月18日 | ワークフロー実行保護がパブリックプレビューに（変更履歴）。同じ日にactions/checkout v7が一般提供になり、pull_request_targetとworkflow_runでフォークのPRのコードの取り出しを既定で断るようになった（変更履歴） |
| 2026年7月20日 | checkoutの保護を、v1を除く対応中のメジャー版に移植（当初は7月16日の予定） |
| 2026年9月17日 | ワークフロー実行保護が一般提供に。ワークフローのファイル単位の指定とInsightsが加わり、公開リポジトリにpull_request_targetの既定のルール（評価モード）が入った |
| 2026年10月21日 | 9月17日の変更履歴に編集注が付き、自動の強制の日が12月2日に変わった（11月2日の変更履歴は、以前の予定を11月2日と書いている） |
| 2026年11月2日 | 12月2日からの既定のブロックと、11月9日・16日のブラウンアウトを告知 |
| 2026年12月2日 | 公開リポジトリで既定のブロックを恒久的に強制 |
なぜ危ないのか｜pwn requestの仕組み
GitHubは今回の変更の理由を、pull_request_targetはベースリポジトリの文脈で動いてそのシークレットにアクセスでき、ワークフローがフォークの信頼できないコードを実行すると、そのコードがパイプラインを乗っ取ったりシークレットを盗んだりしうるからだと説明しています（11月2日の変更履歴）。GitHub Docsは、この形を「pwn request」（日本語版のDocsでは「pwn 要求」）と呼び、複数のサプライチェーン侵害の根本原因になったと書いています。GitHub Security Labが2021年8月に出した解説記事の題名にも「Preventing pwn requests」が入っています。
GitHub Docsの説明では、pull_request_target自体は既定では安全です。危なくなるのは、ワークフローの作者が既定を上書きしてPRのコードを取り出し、後の手順でそれを実行した時です。checkoutの手順だけではコードは動きません。PRから来たMakefile、ビルドスクリプト、テストのコマンド、依存関係、設定ファイルを後の手順が実行した時点で、そのコードがベースリポジトリのシークレットとトークンを持ったまま動きます。npm installやnpm run buildのように、はっきりしたビルドの手順が無くても実行は起こりうる、とDocsは注意しています（pull_request_target を安全に使用する）。
Docsが挙げる危ない形は次の3つです。攻撃の手順ではなく、自分のワークフローを点検するための形として挙げます。
- actions/checkoutでPRのheadまたはマージのコミットを取り出し、ビルド・テストなどで実行する
- repository:にフォークを指定して、フォークのブランチを直接取り出す
- git fetchやgh pr checkout、フォークのpull_requestの実行が作った成果物のダウンロードなど、actions/checkoutの外でPRのコードを取ってきて実行する
シークレットを参照しないワークフローでも安全とは限りません。GitHub Security Labは、pull_request_targetでは読み書きできるトークンがメモリにあり、actions/checkoutのpersist-credentials（取り出しに使った認証情報を残す設定）の既定がtrueなので、後の手順で動くコードがディスクのトークンを読めると書いています。
pwn requestはpull_request_targetだけの問題でもありません。Docsは、シークレットを持って動くイベントなら、信頼できないコードを取り出して実行すれば同じように脆弱になると書き、issue_comment（コメントで起動するイベント）やworkflow_runを例に挙げています。workflow_runのワークフローは、ほかのワークフローが上げた成果物を信頼できないデータとして扱う必要があります。
AIのコードレビューをActionsで動かしている時に確かめること
AIのコードレビューのActionには、claude-code-actionのANTHROPIC_API_KEYやcodex-actionのOPENAI_API_KEYのように、AIのサービスの鍵をシークレットで受け取るものがあります。pull_requestで動かすと、フォークからのPRにはシークレットが渡らないため、フォークのPRにもAIのレビューを掛けたいリポジトリがpull_request_targetを選ぶことがあります。たとえばOpen Code Reviewの公式のワークフローの例は、フォークからのPRでもシークレットを使えるようにpull_request_targetを使い、このActionは差分を読むだけでPRのコードを実行しないので安全だ、とコメントに書いています（ocr-review.yml）。公開リポジトリでこの形を使っていれば、12月2日以降は許可するポリシーが無い限り、pull_request_targetで起動する部分は既定でブロックされます。同じ例にあるコメントでの再レビュー（issue_comment）は、このルールの対象ではありません。
主なAIのActionと機能の公式の文書が、pull_request_targetや信頼できない入力について書いていることは次のとおりです。文書に書かれていないことは書いていません。
| Action・機能 | 公式の文書の記載 |
|---|---|
| anthropics/claude-code-action（Claude Code） | セキュリティの文書に、pull_request_targetとworkflow_runで使う時の節がある。どちらもベースリポジトリのシークレットで動き、このActionより前にPRのheadを作業場所の根（$GITHUB_WORKSPACE）に取り出すと、ActionとClaudeはそれを作業場所として動く。このActionの前に信頼できないrefを作業場所の根に取り出さないよう求め、ベースのrefを取り出す形（推奨）か、ベースを根に置きPRのheadを下のフォルダに取り出して--add-dirで渡す形を示している。起動できるのは書き込み権限がある人だけで、権限の無い人に広げるallowed_non_write_usersは「RISKY」と書かれている（Security） |
| openai/codex-action（Codex） | 既定で起動できるのは書き込み権限がある人だけ。PRの本文（HTMLのコメントで隠せる）・コミットメッセージ・PR側のAGENTS.mdなどを、プロンプトインジェクション（AIへの隠れた命令）の入り口として挙げ、OPENAI_API_KEYを守るためにdrop-sudoかunprivileged-userを使うよう求めている（Security）。この文書にpull_request_targetの語は無い |
| google-github-actions/run-gemini-cli（Gemini CLI） | PRのレビューはメンテナーが意図して始める形を選び、フォークで自動で動かさないよう勧めている。信頼できないデータを扱う時は、使える道具をlist_directory・read_file・grep_searchのような最小限に絞る（Trust Guidance） |
| GitHub Copilotのコードレビュー | 自分でワークフローを書くActionではなく、PRでCopilotにレビューを頼むGitHubの機能。エージェントの機能をGitHub Actionsのランナー（ワークフローを実行する機械）で動かす。カスタムの指示・エージェントの指示・スキルは、ベースではなくPRのheadのブランチから読む（GitHub Copilot code review）。読んだ文書にpull_request_targetの記載は無い |
claude-code-actionの文書は、PRに対して動く時に.claude/・.mcp.json・CLAUDE.mdなど決まった設定のパスだけをベースのブランチから戻し、package.json・Makefileなどそれ以外はPRのheadのままだとも書き、設定のフックがパッケージのスクリプトを呼ぶとPRが持ち込んだファイルを通って動くと注意しています。また、actions/checkoutの保護がフォークのPRで取り出しを断る条件はrefとrepositoryの指定で、取り出す場所（path）は条件に入っていません（checkoutの変更履歴）。下のフォルダに取り出す形でも、フォークのPRのheadを指定すれば断られ、続けるにはallow-unsafe-pr-checkout: trueが要ります。
AIのレビューをActionsで動かしているリポジトリは、12月2日の前に次の5つを確かめておきます。
- どのイベントで動くか（pull_request_target・pull_request・issue_comment・workflow_run）
- PRのコードを取り出しているか、どこに取り出し、後の手順で実行していないか
- AIに許している道具（コマンドの実行・ファイルの書き込み）が、そのActionの設定で必要な分だけになっているか
- 渡しているシークレット（AIのAPIキーなど）とGITHUB_TOKENの権限が最小限か
- 誰のPR・コメントでAIが動くか。PRの本文・コミットメッセージ・PR側の指示のファイルを信頼できない入力として扱っているか
PRやWebページに隠した指示でAIを操るプロンプトインジェクションの実例と止め方はCopilot CLIのプロンプトインジェクションの記事、CodexのActionでPRをレビューする設定はCodex GitHub Action入門で扱っています。
自分のリポジトリが当たるかの確かめ方
当たるかどうかは、画面と手元の両方で確かめます。GitHub Docs「GitHub Actions ワークフローの実行の管理」と11月2日の変更履歴をもとにすると、見る所は次の4つです。
- ポリシー分析情報：リポジトリまたは組織の［設定］タブを開き、左のサイドバーの［アクション］の下の［ポリシー］を開くと、そのすぐ下にある。評価モードのポリシーでは止められていたはずの実行が、アクティブなポリシーでは止められた実行が出る。組織やエンタープライズの単位でも見られる
- pull_request_targetで動くワークフロー：手元で .github/workflows をgrepで探す
- PRのコードを取り出す指定：headのSHA・PRのref・フォークのリポジトリの指定と、checkoutの保護を外している所を探す
- ［Actions］タブの実行：ブラウンアウトの時間帯（日本時間11月10日と11月17日の1:00〜3:00）にPRの活動があった公開リポジトリでは、止められた実行がエラーの注釈つきの失敗として残る。それ以外の時間は評価モードなので、警告つきで動く
手元で探すgrepの例です。どれも一般的なgrepの使い方で、ファイルの中身は変えません。
# pull_request_targetで動くワークフローを探す
grep -rn "pull_request_target" .github/workflows/
# PRのコードを取り出す指定（headのSHA・PRのref・フォークのリポジトリ）を探す
grep -rnE "pull_request\.head\.(sha|ref)|refs/pull/|head\.repo\.full_name" .github/
# checkoutの保護を外している所と、checkoutの外でPRのコードを取ってくる所を探す
grep -rnE "allow-unsafe-pr-checkout|gh pr checkout|git fetch" .github/見つかった行は、pull_request_target・workflow_run・issue_commentで動くワークフローの中にあるか、取り出したコードを後の手順で実行していないかで読み分けます。actions/checkoutの版も見ておきます。actions/checkout@v4のような浮動のメジャー版タグなら7月20日の保護が入っていますが、コミットのSHAやマイナー版・パッチ版で固定している場合は、保護の入った版（v7.0.0以降か、移植の入ったv6.1.0・v5.1.0・v4.4.0・v3.7.0・v2.8.0以降）に上げるまで入りません（checkoutの変更履歴・Releases）。今回の既定のブロックで見るのは公開リポジトリだけで、非公開リポジトリと内部リポジトリは対象外です。
直し方の選択肢｜pull_request・workflow_run・許可して使う
GitHub Docsは、影響を受けるワークフローごとにpull_request_targetがまだ必要かを決めるよう求めています。要らなければpull_requestなど安全なイベントに変え、どうしても必要なら明示的に許可するポリシーを作り、許可しないなら既定のポリシーのままにします（pull_request_target を安全に使用する）。ワークフローの目的で分けると、次の4つの道があります。
| ワークフローの目的 | 直し方 | 注意 |
|---|---|---|
| シークレットも書き込みの権限も要らない（テストなど） | pull_requestに変える | フォークからのPRではトークンが読み取り専用になり、シークレットは渡らない |
| PRのコードをビルド・テストし、結果を書き込みの権限やシークレットで返す（カバレッジのコメントなど） | pull_requestで動かして結果を成果物に保存し、workflow_runの別のワークフローがそれを読んでコメントする | 成果物は信頼できないデータとして読み、特権のあるワークフローで実行しない |
| PRのコードを実行せずにシークレットを使う（ラベル付け・コメント・差分を読むAIのレビューなど） | ワークフローのファイルを指定してpull_request_targetを許可し、守りを足す | 許可は既定のブロックを外すだけで、pwn requestの危険は残る |
| 使っていない・要らない | 既定のポリシーのままにする | 12月2日以降、そのイベントで起動するワークフローはブロックされる |
2つ目の分け方は、GitHub Security Labが示す形です。権限の無いpull_requestのワークフローでPRのコードを扱って結果を成果物に残し、続けてworkflow_runで起動するワークフローが、書き込みの権限とシークレットを持ってコメントなどを行います。GitHub Docsも、ワークフローの間で特権を分けるにはworkflow_runの方が適したトリガーだと書いています（セキュリティで保護された使用に関するリファレンス）。AIのレビューをこの形に移しても、AIが読むのはPRから来たデータなので、前の節の確かめる点はそのまま残ります。claude-code-actionは、workflow_runでは上流の実行を始めた人（フォークのPRの作者など）の書き込み権限も確かめ、権限が無ければClaudeを動かす前に止まります。
pull_request_targetを許可する時の手順
GitHub Docsの「ワークフロー実行ポリシーの作成」をもとにした流れです。
- リポジトリまたは組織の［設定］タブを開く（エンタープライズは［ポリシー］タブから入る）
- 左のサイドバーの［アクション］の下にある［ポリシー］をクリックする
- 新しいポリシーを作り、名前を付ける
- 強制の状態を選ぶ（［評価］はGitHub Enterprise Cloudだけで選べ、ポリシー分析情報で影響を見られる）
- 対象を、許可したいワークフローのファイル（パス）とリポジトリに絞る
- イベントのルールで、そのワークフローを起動してよいイベントを選び、pull_request_targetを入れる
- ポリシー分析情報で、意図したワークフローだけが通っていることを確かめる
イベントのルールは、選んだイベントだけがワークフローを起動できる許可リストです（REST APIではallowed_events）。対象にしたワークフローがpushなど別のイベントでも動くなら、そのイベントも選んでおきます。リポジトリが多い時は、REST APIでワークフローのパスの条件を含めてポリシーを作成・更新できます。
許可して使い続けるワークフローには、GitHub Docsの「pull_request_targetワークフローの強化」の守りを足します。PRのコードを取り出すかどうかに関係なく当てはまります。
- GITHUB_TOKENの権限を最小にし、使うリポジトリと組織のシークレットを必要な物だけにする
- キャッシュポイズニング（後で使われるキャッシュに細工した中身を入れること）を防ぐため、pull_request_targetのワークフローは既定のブランチの範囲のキャッシュを読むだけになっている。書き込めるcache-modeを宣言して戻すと、その危険が戻る
- セルフホストのランナーを使うなら、内部の資源から切り離し、実行ごとに使い回さない
- コマンドインジェクションなどほかの弱点にも気を付け、GitHub ActionsのCodeQL（GitHubのコードの解析）を有効にする
actions/checkoutの保護を外すallow-unsafe-pr-checkout: trueは、取り出したコードが決して実行されないことを確かめた後だけに使います。GitHubは、コードレビューや静的解析で見つけやすいようにわざとこの名前にしたと説明しています。ラベルを付けたPRだけを動かす方法について、GitHub Security Labは、承認の後に新しい変更を押し込まれる競合が残るため、正しい直しが入るまでの一時しのぎにとどめるよう書いています。
会社で決めること｜12月2日までのチェック表
公開リポジトリを複数持つ会社は、各リポジトリの担当者に任せきりにせず、組織として次の7つを決めておくと、12月2日の強制の後に止まったワークフローを一つずつ調べ直さずに済みます。
| 決めること | 中身 | 見る所 |
|---|---|---|
| 対象の洗い出し | 公開リポジトリのうち、pull_request_targetで動くワークフローの一覧を作る | 組織のポリシー分析情報・grep |
| ワークフローごとの扱い | pull_requestに変える・workflow_runに分ける・許可する・既定のままにするのどれか | 直し方の表 |
| 許可の決め方 | 誰が許可を承認するか。許可はワークフローのファイル単位に絞る | 設定の［アクション］→［ポリシー］ |
| シークレット | AIのAPIキーなど、ワークフローに渡すシークレットを必要な物だけにする | リポジトリと組織のシークレット |
| トークンの権限 | GITHUB_TOKENの既定をリポジトリの内容の読み取りだけにし、ジョブごとに要る権限を足す | ワークフローのpermissions |
| checkoutの保護 | allow-unsafe-pr-checkoutを使ってよい場面と、使う時のレビューの仕方 | grep・コードレビュー |
| ランナーとAIの道具 | 公開リポジトリでセルフホストのランナーを使わない。AIに許す道具を設定で絞る | runs-on・各Actionの設定 |
トークンとランナーの2行は、GitHub Docsの勧めです。GITHUB_TOKENは既定を読み取りにしてジョブごとに広げるのがよく、公開リポジトリでは誰でもPRを開いてランナーの環境を乗っ取れるので、セルフホストのランナーはほぼ使うべきでないと書かれています（セキュリティで保護された使用に関するリファレンス）。
入られた後（疑いに気づいた後）にやること
pull_request_targetのワークフローで信頼できないコードが動いた疑いがある時は、公式の文書をもとに次の順で手を打ちます。
- ワークフローを止める：［Actions］タブでそのワークフローを選び、［ワークフローを無効にする］を選ぶ（GitHub CLIなら gh workflow disable）。無効にしても、既にある実行は取り消されない（ワークフローの無効化と有効化）
- シークレットを作り直す：そのワークフローが使えたシークレット（AIのAPIキーを含む）を無効にして作り直す。AnthropicはClaude ConsoleのAPI keysのページで鍵を消し（Delete API key）、新しい鍵を作るよう案内している（Claude Help Center）。マスクされていないシークレットがログに出ていたら、ログを消して替える（GitHub Docs）
- GITHUB_TOKENの期限を知る：トークンはジョブが終わるか最大の有効期間を過ぎると切れる。GitHubのホストのランナーでは最大6時間、セルフホストのランナーでは更新できるのが最大24時間まで（GITHUB_TOKEN）。切れる前に行われた操作は、次の記録で確かめる
- 記録を確かめる：組織の監査ログで、シークレットの変更（org.update_actions_secret）などの操作を確かめる
- キャッシュを消す：［Actions］タブの［Caches］で、怪しいキャッシュを消す。書き込み権限のある人が消せ、gh cacheのサブコマンドでも消せる（キャッシュの管理）
- セルフホストのランナーを調べる：GitHub Docsは、信頼できないコードでセルフホストのランナーが持続的に乗っ取られうると書いているので、その機械も調べる
戻せるかでいうと、無効にしたワークフローは再び有効にでき、キャッシュは消して作り直せます。一方、外に出た可能性のあるシークレットは取り消せないので、無効にして作り直すしかありません。鍵の失効と作り直しを日頃の運用に組み込む考え方はAIエージェントのシークレット管理の記事にまとめています。
【要注意】読み違えやすい4つのこと
読み違い1：非公開リポジトリも12月2日に止まる
❌ 会社の非公開リポジトリのpull_request_targetも、12月2日から止まる。
⭕ 変更履歴が対象とするのは、GitHub Free・GitHub Team・GitHub Enterprise Cloudの公開リポジトリです。非公開リポジトリと内部リポジトリは影響を受けず、GitHub Enterprise Serverも対象外です。非公開リポジトリで止めたい時は、自分たちでイベントのポリシーを作り、リポジトリの公開範囲などで対象を指定します。
読み違い2：pull_requestに変えれば同じに動く
❌ イベントの名前をpull_requestに変えれば、今までどおり動く。
⭕ フォークからのPRでは、pull_requestにはGITHUB_TOKEN以外のシークレットが渡らず、トークンも読み取り専用です。AIのAPIキーをシークレットで渡すレビューは、フォークのPRでは鍵が無いので実行できません。同じリポジトリのブランチからのPRならシークレットを使えます。フォークのPRにもシークレットが要るなら、workflow_runに分けるか、守りを足して許可するかを選びます。
読み違い3：許可すれば元どおりで安全
❌ イベントのポリシーでpull_request_targetを許可すれば、前と同じように安全に使える。
⭕ 許可は既定のブロックを外すだけで、pwn requestの危険は残ります。GitHub Docsは、必要な時だけ許可し、このイベントのワークフローでは信頼できないPRのコードを、シークレットや特権のあるGITHUB_TOKENを持ったままcheckout・ビルド・実行しないよう警告しています。actions/checkoutの保護は別の仕組みなので、ポリシーで許可しても、フォークのPRのheadを指定した取り出しは断られます。ただし、v1や、保護の入る前の版にSHAやマイナー版・パッチ版で固定しているcheckoutでは、この保護は働きません。
読み違い4：issue_commentやworkflow_runに移せば安全
❌ 止まるのはpull_request_targetだけなので、issue_commentやworkflow_runに移せば安全になる。
⭕ GitHub Docsは、シークレットを持って動くイベントなら、信頼できないコードを取り出して実行すると同じpwn requestになると書き、issue_commentとworkflow_runを例に挙げています。12月2日の既定のブロックの対象はpull_request_targetだけで、actions/checkoutの保護もissue_commentでは働きません。workflow_runが保護の対象になるのは、PRのイベントから始まった実行の時だけです（checkoutの変更履歴）。
よくある質問
pull_request_targetとは何ですか？
GitHub Actionsのワークフローを起動するイベントの1つです。PRの活動で動きますが、ベースリポジトリの既定のブランチの文脈で動き、フォークからのPRでもベースリポジトリのGITHUB_TOKENとシークレットを使えます。フォークのPRへのラベル付けやコメントのためのイベントで、PRのコードをビルド・実行する用途には向きません。
pull_request_targetとpull_requestの違いは？
pull_requestはPRのマージコミットにあるワークフローを動かし、フォークからのPRではGITHUB_TOKEN以外のシークレットが渡らず、トークンは読み取り専用です。pull_request_targetは既定のブランチにあるワークフローを動かし、シークレットと読み書きの権限を持てます。12月2日からの既定のブロックはpull_request_targetだけが対象です。
非公開リポジトリやGitHub Enterprise Serverも12月2日から止まりますか？
止まりません。変更履歴が対象とするのはGitHub Free・GitHub Team・GitHub Enterprise Cloudの公開リポジトリで、非公開・内部リポジトリとGitHub Enterprise Serverは対象外です。公開リポジトリでも、pull_request_targetを明示的に許可する当てはまるイベントのポリシーがあれば動きます。
pull_request_targetの脆弱性（pwn request）とは何ですか？
pull_request_targetのワークフローがフォークからのPRのコードを取り出して実行し、そのコードがベースリポジトリのシークレットとトークンを持ったまま動いてしまう形です。GitHub Docsは、複数のサプライチェーン侵害の根本原因になったと書いています。PRのコードを実行しなければpull_request_target自体は既定では安全だ、というのがGitHub Docsの説明です。
AIのコードレビューのActionがpull_request_targetを使っている時はどうすればいいですか？
公開リポジトリなら12月2日までに、イベントのポリシーでそのワークフローだけを許可するか、pull_requestやworkflow_runに作り直すかを決めます。許可するなら、PRのコードを実行しないこと、AIに許す道具とシークレットを絞ること、誰のPRで動くかを、そのActionの公式の文書で確かめます。非公開・内部リポジトリには、今回の既定のブロックは当たりません。
pull_request_targetの許可はどこで設定しますか？
リポジトリか組織の［設定］→［アクション］→［ポリシー］でポリシーを作り、イベントのルールで許可するイベントにpull_request_targetを入れ、対象をワークフローのファイルに絞ります。エンタープライズは［ポリシー］タブから入ります。自分で作るポリシーで強制の状態に［評価］を選べるのはGitHub Enterprise Cloudだけです（既定のルールの評価モードは公開リポジトリ全体に当たります）。REST APIでも作成・更新できます。
まとめ
2026年11月9日時点で、GitHubは12月2日から、GitHub Free・Team・Enterprise Cloudの公開リポジトリでpull_request_targetを既定でブロックすると告知しており、当てはまるActionsのイベントのポリシーで明示的に許可した場合だけ動きます（当初の予定は11月2日）。非公開・内部リポジトリとGitHub Enterprise Serverは対象外です。理由は、フォークのコードをシークレットのある所で実行してしまうpwn requestで、許可してもその危険は消えません。AIのコードレビューをシークレットつきでフォークのPRに掛けている公開リポジトリは、影響が出やすい所です。
次にやることは、ポリシー分析情報とgrepで対象のワークフローを洗い出し、ワークフローごとにpull_request・workflow_run・許可・既定のままのどれにするかを決めることです。2回目のブラウンアウト（日本時間11月17日1:00〜3:00）で失敗した実行が出ないかを見て、12月2日までに設定を終えておきます。
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）
参考・出典
- pull_request_target blocked by default December 2 — GitHub Changelog・2026-11-02（参照日: 2026-11-09）
- Workflow execution protections in GitHub Actions generally available — GitHub Changelog・2026-09-17（2026-10-21の編集注あり）（参照日: 2026-11-09）
- Control who and what triggers GitHub Actions workflows — GitHub Changelog・2026-06-18（参照日: 2026-11-09）
- Safer pull_request_target defaults for GitHub Actions checkout — GitHub Changelog・2026-06-18（2026-07-15の編集注あり）（参照日: 2026-11-09）
- Actions pull_request_target and environment branch protections changes — GitHub Changelog・2025-11-07（参照日: 2026-11-09）
- pull_request_target を安全に使用する — GitHub Docs（日本語版）（参照日: 2026-11-09）
- Securely using pull_request_target — GitHub Docs（英語版）（参照日: 2026-11-09）
- GitHub Actions ワークフローの実行の管理 — GitHub Docs（参照日: 2026-11-09）
- アクション ポリシーについて — GitHub Docs（参照日: 2026-11-09）
- REST API endpoints for GitHub Actions policies — GitHub Docs（参照日: 2026-11-10）
- ワークフローをトリガーするイベント — GitHub Docs（参照日: 2026-11-09）
- セキュリティで保護された使用に関するリファレンス — GitHub Docs（参照日: 2026-11-09）
- GITHUB_TOKEN — GitHub Docs（参照日: 2026-11-09）
- ワークフローの無効化と有効化 — GitHub Docs（参照日: 2026-11-09）
- キャッシュの管理 — GitHub Docs（参照日: 2026-11-09）
- Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests — GitHub Security Lab・2021-08-03（例は2026-06-17に更新）（参照日: 2026-11-09）
- actions/checkout（README）・Releases — GitHub（参照日: 2026-11-09）
- claude-code-action Security・FAQ — Anthropic（参照日: 2026-11-09）
- codex-action Security — OpenAI（参照日: 2026-11-09）
- run-gemini-cli Trust Guidance — Google（参照日: 2026-11-09）
- GitHub Copilot code review — GitHub Docs（参照日: 2026-11-09）
- examples/github_actions/ocr-review.yml — alibaba/open-code-review（参照日: 2026-11-09）
- What should I do if I suspect my API key has been compromised? — Claude Help Center（参照日: 2026-11-09）
