GitHub Actionsのログが見えないとき：追加された120ホストから考える
ワークフローを変えていなくても、ログやジョブサマリーが開けなくなることがあります。実行開始と結果保存では接続先が異なる場合があるからです。GitHubの10月22日の発表は、その裏側の基盤に関わるものです。
二つの範囲は両端を含みます
追加対象はproductionresultssa30.blob.core.windows.net〜productionresultssa49.blob.core.windows.netと、productionresultssa100.blob.core.windows.net〜productionresultssa199.blob.core.windows.netです。20個と100個で合計120個。50〜99が今回の追加範囲に入るわけではありません。
対象となるのはActionsのBlobストレージにネットワーク許可リストを使う環境です。既存のproductionresultssa*.blob.core.windows.netの許可なら今回の追加をカバーするとGitHubは説明しています。個別ホスト方式ではログやサマリーの中断を避けるため新しい名前を追加します。
名前の追加とルールの拡張は別の変更
ワイルドカードは増えた番号をすでに含める場合がありますが、完全一致のリストは名前ごとの許可です。まず既存設定と追加分を照合すると、必要以上に範囲を広げずに済みます。
説明用に二つの範囲からローカルのSetを作成しました。画像は自作コードで、GitHub画面ではありません。公開Meta APIの応答も別途取得・保存しました。この120個はGitHub全体の許可リストではありません。
境界を試すと違いが見えます
実行結果では30・49・100・199が含まれ、200と末尾に.example.orgを付けた名前は含まれませんでした。見慣れた文字列を含むだけでは正しいドメインとは限りません。これは完全一致の判定であり、ファイアウォールや通信の試験ではありません。
実環境では最新のMeta APIと、機器がFQDN・ワイルドカード・IPをどう扱うかを合わせて確認します。公式資料の応答は例示で、最新値はAPIで取得するよう案内されています。ランナー資料は用途別ドメインやCNAME先の追加ルールにも触れています。
緑のチェックの隣に残る空白
結果ページは開くのにログだけ開かないなら、ジョブ開始とログ取得を分けて考えると調査しやすくなります。これは診断例で、再現した障害ではありません。新ホストがすべてのエラーの原因という意味でもありません。
今回変わるのはYAML構文より、結果を保存する裏側の住所です。個別ホストを管理する環境では二つの範囲を照合し、変更後にログとサマリーを実際に開くところまで確認できます。詳しくは以下の公式資料を参照してください。
出典と関連資料
GitHub Docs · Self-hosted runners · Communication
2026年10月24日確認。最新の公式一覧と利用機器の名前解釈を照合して適用してください。