2026年10月22日のGitHub公式告知では、GitHub.comのActions blob storageにホスト端点が追加されたと案内されています。個別ホストを列挙して許可しているなら現在の公式リストと照合して更新し、対象ドメインをワイルドカードで許可済みなら、まず範囲を確認してから通常は変更不要と判断してください。 どちらの場合も、最後は実際のワークフローで通信を確かめます。
企業ファイアウォール、プロキシ、DNSフィルターを管理し、ルールが新しいストレージ端点をカバーするか確認したい方に向けた手順です。 自ホストMac Runnerを運用し、CIのログ、概要、成果物転送を止めたくないプラットフォーム担当者にも役立ちます。 公開フローのIT・開発効率担当者は、端点変更時の受け入れと記録の仕組みづくりに活用してください。
端点の適用範囲を確かめる
最初に確認するのは、ルールが主にホスト名を見ているのか、IPアドレスを見ているのかです。今回の対象はGitHub.comのActions blob storage端点であり、Runnerラベルやワークフローファイルの変更ではありません。発表内容をGitHub Enterprise Serverにもそのまま適用できると解釈しないでください。
既存ルールは、概ね次の形に分けて点検できます。
- 個別ホスト許可：ホスト名を一件ずつ指定します。公式リストに新しいホストが加われば、登録内容との照合が必要です。
- ドメインのワイルドカード許可：対象ドメイン配下を許可する設定です。今回の告知では、該当範囲をすでにカバーする組織は新しい項目のために別ルールを追加する必要はないとされています。
- IPアドレス許可：ホスト名ベースのルールとは判定条件が異なります。DNS解決後の通信先と実際のファイアウォール判定を確認してください。
**注意：** IPアドレスの許可だけで運用している環境では、ホスト名ルールと同じ判断を流用できません。通信ログ、名前解決結果、現在のルール条件を照合してから変更を決めます。
ルールの粒度を決めてから変更する
「白リストに新しいホストを足すか」という判断は、登録方式とセキュリティ条件を分けると誤りにくくなります。特に、個別許可の運用を続けるのか、ドメイン単位の許可を認めるのかは、チームの安全基準に沿って決めます。
| 現在の許可方式 | 変更判断 | 運用上の確認 |
|---|---|---|
| ホスト名を個別に列挙 | 公式の現行リストと照合し、不足があれば追加 | 古い申請記録だけでなく、適用中の設定と比較 |
| 対象ドメインをワイルドカードで許可 | 告知の対象範囲内なら、追加前に既存ルールを確認 | DNS制約と組織のセキュリティ基準を再確認 |
| IPアドレスを許可 | IP条件に基づいて別途判断 | 名前解決先と拒否ログを根拠にする |
| プロキシやDNSフィルターを併用 | 各制御点で個別に判定 | ファイアウォールだけで完結すると想定しない |
- 対象ドメインをカバーするワイルドカードがあり、適用ルールとDNS制約も確認できた場合：今回のホスト追加だけを理由に新しい許可項目を作らず、代表的なMacワークフローで通信を検証します。
- ホスト名を個別に登録している場合：GitHubの公式告知と現在のMeta API応答を照合し、不足するホストだけを追加します。
- IPアドレス指定、プロキシ、DNSフィルターのどれが通信を止めているか特定できない場合：範囲を広げず、ログと名前解決を先に確認します。
公式リストを根拠にホスト範囲を照合する
GitHub Actions Meta APIは、GitHubが公開するネットワーク情報を確認するための情報源です。Meta APIの仕様を参照し、現在のMeta API応答を取得して、静的な例や過去のチケットに残った一覧を現行情報の代わりに使わないようにします。
2026年10月22日の告知は、Actions blob storageについて追加された2つのホスト範囲を示しています。範囲の表記は変換や手入力で転記せず、告知本文と現在のAPI応答を確認して、組織の許可ルールに照合してください。APIの応答例は固定の許可リストではなく、運用時点の情報を確認するための参照先です。
Meta APIのホストリストはどのくらいの間隔で見直しますか。 GitHubは一律の定期確認間隔をこの告知で指定していません。更新頻度を独自の運用基準で決め、少なくともGitHubの端点告知やRunnerネットワーク文書の更新を検知したときに再照合します。変更を検知した人、承認者、確認日、取得したリストを記録しておくと、後からルールの根拠をたどれます。
**運用メモ：** Meta APIのサンプル応答をそのまま設定管理に貼り付けるのではなく、取得時点の応答を保存し、適用したルールとの差分をレビュー対象にしてください。
機能ごとの通信をワークフローで受け入れる
blob storage端点に関係する転送と、GitHub Actionsのほかの通信要件を分けて検証します。自ホストRunnerのネットワーク要件では、Runnerの通信先と要件が説明されています。今回の端点追加だけで、GitHub API、リポジトリ取得、Xcodeのツールチェーンに起因する障害まで説明できるわけではありません。
GitHubの公式資料では、ワークフローのログや概要、成果物、依存関係キャッシュがそれぞれの機能として説明されています。成果物の扱いはワークフロー成果物の公式資料、キャッシュは依存関係キャッシュの公式資料を参照し、チームが実際に使う経路を試験に含めてください。
Mac Runnerのビルドは完了するのに、ログや概要が見られない場合は何を確認しますか。 まずワークフロー実行記録、Runner側の通信ログ、プロキシとファイアウォールの拒否記録を同じ実行時刻で照合します。続いて、概要の表示と、チームが使う成果物またはキャッシュのアップロード・取得を別々に試し、DNS解決失敗、プロキシ拒否、ファイアウォール拒否、権限エラーを区別してください。ビルドが成功したことだけでは、ストレージ転送まで正常とは判断できません。
変更後の検証結果を記録する
変更作業は、設定を更新した時点ではなく、対象ネットワーク上のワークフローで必要な通信を確認した時点で完了とします。次の手順を、ステージングまたは影響を限定できるMac CI環境から実施してください。
- 適用中のファイアウォール、プロキシ、DNSフィルターのルールをエクスポートし、ホスト名・ワイルドカード・IPアドレスのどれで制御しているか記録します。
- GitHubの告知、Meta API文書、現在のAPI応答、自ホストRunnerのネットワーク要件を照合し、確認日時と取得元を保存します。
- 影響範囲が個別ホスト許可なら、不足する範囲だけを変更案に含めます。ワイルドカードがある場合は、今回の範囲を実際に含むか、DNSやセキュリティ制約に抵触しないかを確認します。
- 変更を承認・適用したら、対象のMac Runnerで代表的なワークフローを実行し、ログと概要の参照、利用中の成果物またはキャッシュの転送を検証します。
- 実行結果、ルール命中、拒否ログ、必要な通信の成否を対応づけて保存し、問題があればDNS、プロキシ、ファイアウォール、権限の順に切り分けます。
再確認の責任と実行環境を決める
端点リストの管理担当者、変更承認者、ワークフロー受け入れ担当者を明確にし、GitHubの告知・Meta API応答・Runnerネットワーク文書のいずれかに更新があったときの確認経路を定めます。変更記録には、適用した範囲、確認したワークフロー、実行結果を残してください。公開前の確認だけで終わらせず、端点やネットワーク要件の更新を再確認のきっかけにします。
Mac CIを自社設置で運用する場合は、物理機器、更新、ネットワーク境界の管理を自社で担います。一方、クラウド上のMacを利用する場合も、利用側のファイアウォールやプロキシ方針との適合を検証する必要があります。既存のMac運用を比較する場合は、Macの調達・構成情報も参照し、機器の購入とリモート環境の利用で、どの管理責任を自社に残すか整理してください。
ログの場所やネットワーク経路が組織ごとに異なる以上、特定のサービスがこの端点を通すと前提にして判断することはできません。独立したネットワーク境界を持つMac CI環境では、実際の許可ルールとワークフローで適合性を確認してください。自前の機器では調達・保守・稼働管理を抱え、一般的なクラウド実行環境ではmacOS固有の要件やネットワーク境界の確認が別途必要になります。短期の検証環境や追加のビルド環境を用意する場合は、MACGPUのリモートMac環境を候補に加え、接続方式と自社のネットワーク要件を照合したうえで選定してください。
最終更新：2026年10月27日。 GitHubの2026年10月22日付公式告知、Meta API文書、自ホストRunnerのネットワーク要件を確認しています。複数の情報源に変更があれば、実際の許可ルールとワークフローをあらためて検証してください。