GitHub Actionsの保存先ホストが追加：ログ・サマリーの接続許可を確認しよう

GitHub Actionsのジョブ自体は動くのに、ログやジョブサマリーを取得できない。ネットワークの接続許可を厳しく管理している環境では、保存先ホストの追加も確認しておきたいね。

GitHubは2026年10月22日、github.comのActions用blob storageのエンドポイントを追加し、Meta APIにも反映したと発表したよ。blob storageは、ここではログなどのデータを保存するための接続先のこと。

個別ホストを許可している組織が確認対象

公式発表が示した追加範囲は次の二つ。両端の番号を含むよ。

productionresultssa30.blob.core.windows.net
  ～ productionresultssa49.blob.core.windows.net

productionresultssa100.blob.core.windows.net
  ～ productionresultssa199.blob.core.windows.net

この表記は範囲の説明で、そのまま一行の設定値として投入するものではない。利用中のファイアウォールやプロキシが受け付ける形式に合わせ、管理者が確認する必要がある。

公式は、すでにproductionresultssa*.blob.core.windows.netを許可している場合、この追加のための変更は不要としている。一方、個別ホストで許可している場合は、新しいホストを追加しないとログやジョブサマリーに支障が出る可能性がある。

ワイルドカードへ広げることが、唯一の対応ではない

すべての組織へ広い許可設定を勧めているわけではないよ。必要な接続先を個別に管理する方針なら、今回の追加と現在の一覧を照合して、同じ方針で変更をレビューしよう。

GitHubは、最新の接続先一覧をMeta APIから取得できると案内している。この記事の範囲だけを永続的な完全一覧として固定せず、管理元の最新情報で確認してね。

問題が起きたときの切り分け

まず、閲覧権限のある実行で、ジョブの状態とログ・サマリーの取得を別に確認しよう。ネットワーク担当へは、発生時刻、対象機能、拒否された接続先を伝える。トークンや秘密の認証ヘッダーを、調査用の共有ログへ貼る必要はないよ。

接続設定の変更後も、許可が必要以上に広がっていないか確認する。運用中のルールを丸ごと削除したり、TLSの検証を無効にしたりする方法で確認しないようにしたいね。

今回は公式の追加案内を確認した記事で、組織の接続許可を変更した実測ではない。github.com向けの案内を、GitHub Enterprise Serverの全構成へそのまま当てはめないでね。認証情報と通常設定の区別には、SecretsとVariablesの解説も参考になるよ。