GitHub、12月2日から公開リポジトリでpull_request_targetを既定でブロック：11月9日と16日にブラウンアウト

2026年11月2日、GitHubはGitHub Actionsがすべての公開リポジトリでpull_request_targetイベントを既定でブロックするという変更ログを公開した。適用されるActionsのイベントポリシーが明示的に許可した場合は例外になる。日付が重要だ。変更ログによれば、強制は当初2026年11月2日に予定されており、恒久的な強制の新しい日付は2026年12月2日である。この項目は「廃止」に分類され、公開リポジトリの所有者に、動かなくなるワークフローを見つけるための短い猶予を与えている。

理由はセキュリティだ。pull_request_targetイベントはベースリポジトリのコンテキストで実行され、そのシークレットにアクセスできる。これを使うワークフローがフォークからの信頼できないコードを実行すると、そのコードがパイプラインを侵害したり、シークレットを盗んだりする可能性がある。GitHubは、既定のルールがこのリスクを減らしつつ、このトリガーに依存するワークフローを所有者が意図して許可できるようにすると述べている。ルールはワークフロー実行保護を通じて導入され、当初は評価モードで動くため、所有者は強制が始まる前に、どのワークフロー実行がブロックされるかを確認できる。

範囲は重要で、変更ログの記述は狭い。この変更は、GitHub Free、GitHub Team、GitHub Enterprise Cloudの公開リポジトリに適用される。GitHub Enterprise Serverには適用されず、プライベートおよびインターナルのリポジトリも影響を受けない。リポジトリの種類が混在する組織は、まず公開リポジトリを洗い出すべきだ。実行がブロックされ得るのはそれらだけだからである。

恒久的な強制の前に、GitHubは予定された二つのブラウンアウトで既定の保護を実際に適用する。日程は2026年11月9日と11月16日で、いずれもUTCの16:00から18:00である。この時間帯には、影響を受ける公開リポジトリで既定のルールがブロックしたpull_request_targetのワークフロー実行は、エラー注釈付きの失敗した実行になり、ワークフローは実行されない。各時間帯の後、ルールは評価モードに戻り、ワークフローは警告付きで再び動く。したがって、ブラウンアウトはこれらのワークフローにとって書類上の予行演習ではなく、実際の停止である。

変更ログは二つの選択肢を示す。最初のブラウンアウトの前に、Insightsでルールがブロックするワークフロー実行を確認する。その上で、既定のルールを維持してトリガーをブロックしたままにするか、ワークフローが依存している場合は適用されるActionsのイベントポリシーでpull_request_targetを明示的に許可し、ワークフローファイルの指定で特定のワークフローだけを許可する。リポジトリ全体にイベントを許可するのは、1ファイルだけを許可するより広い判断であり、変更ログはワークフロー実行の制御方法に関するドキュメントを案内している。

そのドキュメントには、変更ログが繰り返さない詳細がある。ワークフロー実行保護は、誰がワークフローをトリガーできるか、どのイベントを実行できるかを制限でき、ロックファイルを必須にもできる。イベントのルールはpush、pull_request、pull_request_target、workflow_dispatchなどを扱う。アクターのルールでは、dependabot[bot]のようにGitHubの機能に結びつくIDがワークフローを実行する必要があるとき、許可されたアクターに追加しなければならない。ポリシーはリポジトリ、組織、エンタープライズの各レベルで設定でき、大きなポリシーを一つ作るより、明確に定義した複数のポリシーを推奨している。確認すべき食い違いもある。ページは、ポリシーの実施状態に「評価」（Evaluate）を選ぶと、ユーザーがいつ制限に当たるかをポリシーインサイトで監視できると述べ、評価はGitHub Enterprise Cloud限定と記している。一方、変更ログは、既定のルールはFree、Team、Enterprise Cloudの公開リポジトリで評価モードから始まると述べる。FreeとTeamの所有者が同じInsightsの画面を使えるかどうかはこれらのページから分からないので、頼る前に自分の設定で確かめたい。

実際の進め方は短い。公開リポジトリでpull_request_targetを使うワークフローをすべて探す。それぞれについて、ベースリポジトリのシークレットや書き込み権限が本当に必要か、pull_requestで足りるかを判断する。残す必要があるなら、フォークからどのコードをチェックアウトしているかを確認する。ルールが狙っているのは、まさにその危険なパターンだからだ。次に、そのファイルだけに明示的な許可を追加し、担当者と理由を記録して、11月9日の時間帯にテストする。12月2日以降は、許可ルールがなければワークフローはただ動かなくなる、と考えておくとよい。

オープンソースを運営するチームには、もう一つ意味がある。ラベル付けの自動化、コメントボット、依存関係の更新といった流れは、これまで書き込み権限を得るためにpull_request_targetに頼ることが多かった。ブラウンアウトの間、これらが同時に止まり、貢献者には失敗したチェックだけが見えるかもしれない。コントリビューションガイドや固定のIssueで事前に予定を知らせておくと、当日になって初めてメンテナーが自動化の停止に気づく事態を避けられる。