GitHub Actions pull_request_targetの既定ルールは、まずInsightsの評価結果で対象ワークフローを特定し、その後に阻止するか、必要なワークフローだけ明示的に許可するかを決めてください。対象は適用されるイベントポリシーがまだない公開リポジトリです。非公開・内部リポジトリに一律適用される規則ではありません。
この記事の対象 - 公開GitHubリポジトリのActionsポリシーを管理し、影響範囲を確かめたいIT責任者。 - iOS/macOSのPRワークフローとMac Runnerの実行を管理するCI基盤担当者。 - 例外承認の範囲と監査記録を確認するセキュリティ担当者。
最終更新：2026年10月28日。GitHubの公式告知、イベントポリシーの管理手順、Actionsの使用状況指標を照合しています。GitHub側の更新があれば、対象範囲と実行日を再確認してください。
01 適用範囲を先に切り分ける
GitHubが公表した既定ルールは、適用されるイベントポリシーが設定されていない公開リポジトリについて、評価モードの後に実行へ移る計画です。告知では実行開始日を2026年12月2日としています。非公開・内部リポジトリはこの既定ルールの対象外です。実際に自社のリポジトリが該当するかは、既存ポリシーと評価結果で判断してください。(公式告知)
| リポジトリの状態 | 今回の既定ルールとの関係 | あなたの確認事項 |
|---|---|---|
| 公開、適用イベントポリシーなし | 告知された既定ルールの対象候補 | Insightsの評価結果と対象ワークフローを確認 |
| 公開、適用イベントポリシーあり | 既定の挙動をそのまま当てはめない | 設定済みポリシー、対象イベント、ファイル範囲を確認 |
| 非公開または内部 | 公開リポジトリ向け既定ルールの対象外 | 組織・リポジトリ独自のポリシーを別途確認 |
最初に、リポジトリの可視性、イベントポリシー、pull_request_targetを指定したワークフローファイルを一覧にします。社内全体へ同じ扱いを適用する前に、公開・非公開・内部を分けてください。
- [ ] リポジトリごとの可視性と管理責任者を記録する。
- [ ] 適用中のイベントポリシーを確認する。
- [ ]
pull_request_targetを使うファイルと用途を一覧化する。
02 Insightsの評価を影響調査に使う
評価モードは、ルールが適用された場合に影響を受ける実行を把握するためのものです。評価結果が表示されていても、その時点ですでに実行が阻止されたという意味ではありません。GitHubの使用状況指標の確認手順を参照し、評価の記録をリポジトリとワークフローに結び付けてください。
| 確認する記録 | 記録する内容 | 次の判断 |
|---|---|---|
| Insightsの評価結果 | 対象イベント、ワークフロー、判定内容 | 該当ファイルと責任者を特定 |
| ワークフロー定義 | トリガー、実行する処理、参照するコード | 信頼境界と必要権限をレビュー |
| ポリシー設定 | 適用範囲、許可・拒否、ファイル指定 | 例外の過不足を確認 |
評価結果から対象のイベントとワークフローを拾い、リポジトリ名、ファイルパス、担当者を記録します。過去の一度の観察だけでは、今後の変更や別の実行経路まで影響がないとは判断できません。
- [ ] 評価結果を対象リポジトリとワークフローファイルにひも付ける。
- [ ] 判定結果と実際のワークフロー定義を照合する。
- [ ] 結果をレビュー担当者に割り当て、未確認の項目を残す。
03 トリガーと信頼境界をレビューする
pull_request_targetの判断軸は、Mac Runnerの機種やハードウェアではありません。PRから来た信頼できないコードをチェックアウトまたは実行するか、基盤リポジトリの権限や秘密情報に触れ得るかです。GitHubの安全な利用に関する説明を基準に、ワークフローごとに確認してください。
- [ ] トリガーの後に、PR由来のコードやスクリプトを取得・実行するか確認する。
- [ ] ワークフローに与える権限と、アクセス可能な資格情報を記録する。
- [ ] PRのコード、ワークフロー定義、署名処理、成果物の関係を整理する。
pull_request_targetを使う理由がラベル付けやメタデータ処理なのか、PRコードを使ったビルドなのかで、必要な権限と対策は異なります。イベント名だけで安全とも危険とも決めず、実際の処理を根拠にしてください。権限はワークフロー構文のpermissions設定でも確認できます。
評価結果が「影響なし」でも、それだけで資格情報やコード実行の境界が安全だとは証明できません。評価記録とワークフローの実装を別々に確認してください。
04 例外は必要なファイルだけに限定する
業務上必要だからという理由だけで、イベントを広く許可しないでください。まず、別のトリガーや権限構成へ変更できるか確認します。残す場合は、イベントポリシーの適用範囲とワークフローファイル指定を照合し、必要なファイルだけに限定します。設定方法はActionsポリシーの管理文書で確認できます。
- [ ] 継続利用の理由と、代替トリガーを採用できない理由を記録する。
- [ ] 対象リポジトリ、イベント、ワークフローファイルを明記する。
- [ ] 承認者、見直し条件、例外の終了条件を変更記録に残す。
例外を明示的に許可しても、そのワークフローが自動的に安全になるわけではありません。許可範囲と、コード実行・権限・資格情報のレビュー結果を別々に保管してください。ポリシーを変更する際は、組織・リポジトリの設定画面で対象範囲を再確認し、変更記録にも反映します。
05 Mac CIで変更前の実行境界を確かめる
切り替え前に、管理された検証環境で許可される経路と拒否される経路をそれぞれ確認します。Mac Runnerでジョブが成功したかだけでは、イベントポリシーが意図どおりか、署名資格情報へのアクセスが適切かは判断できません。
- [ ] 期待するトリガーでワークフローが実行されることを確認する。
- [ ] 拒否する想定のトリガーがポリシー評価と実行記録で想定どおり扱われることを確認する。
- [ ] Runnerから利用できる署名資格情報、リポジトリ権限、成果物の保存先を確認する。
- [ ] 失敗時の症状、対応責任者、切り戻し判断を記録する。
自ホストRunnerを使う場合は、イベントポリシーの評価とは別に、ホストのアクセス範囲とジョブ後の状態を確認してください。GitHubの自ホストRunnerを安全に使うためのガイダンスも参照し、信頼できないPRコードがRunner上で何に触れ得るかを点検します。
06 よくある判断の確認
非公開リポジトリにも同じ既定ルールを適用しますか？
いいえ。この告知の既定ルールは公開リポジトリ向けです。ただし、非公開リポジトリにも個別のイベントポリシーを設定している場合があります。既定ルールの対象外という理由で、既存設定の確認を省略しないでください。
Insightsの評価結果だけでMac CIへの影響を確定できますか？
できません。評価結果は影響調査の材料です。実際のワークフローファイル、トリガー、権限、資格情報の利用状況と照合し、管理された検証で許可・拒否の挙動も確認します。
07 適用前に放行判断を残す
判断は「阻止する」「必要なワークフローだけ許可する」「修正が終わるまで変更を保留する」のいずれかに整理します。どの選択でも、公開範囲、設定したポリシー、Insightsの評価、検証結果、例外承認を同じ変更記録から追えるようにします。
- [ ] 影響するリポジトリとワークフローを確定する。
- [ ] 阻止・限定許可・保留の判断と根拠を記録する。
- [ ] 2026年12月2日の実行予定日をレビューの節目にする。(GitHub公式告知)
- [ ] GitHubが適用範囲や実行日を更新した場合、結論を再確認する。
既存のMac CIを自社保有のRunnerだけで運用すると、初期調達や保守の負担があり、必要なときだけ実行環境を増やす判断もしにくくなります。一方、リモートMacのレンタルは、常時稼働する専用ノードや物理接続が必要な構成に常に適するわけではありません。ワークフローと資格情報の境界を先に固めたうえで、一時的な検証環境や追加のMac実行環境が必要なら、CALMVPSのサービス概要と料金情報を確認し、運用要件に合うか比較してください。使用を検討する場合は、利用手続きへ進む前に、必要なアクセス方式とチームの利用期間を確認しましょう。