CIのログに、APIキーやトークンがそのまま出てしまうことがあります。デバッグのために環境変数を一覧で表示した、利用しているツールがエラーのときに接続文字列ごと出力した、といった経路です。GitHub Actionsは登録したシークレットの値をログで伏せ字にしますが、登録していない鍵は伏せられません。値が変形された文字列も、伏せられるとは限りません。しかもログは、リポジトリを読める人なら誰でも開けます。
GitHubのシークレットスキャンに、このワークフローのログを検査する機能が加わりました。本記事では、GitHubのドキュメントのリポジトリ（github/docs）に2026年11月5日に入った原稿と、公開中のGitHub Enterprise Cloud版のドキュメントを、2026年11月6日に確認した内容をもとに整理します。
何ができるようになったのか
ドキュメントには「Secrets detected in GitHub Actions workflow logs」という節が加わり、次のように説明されています。
- 提供段階はパブリックプレビュー。 内容は変わる可能性があると注記されている
- 既定はオフ。 Enterpriseのオーナーが、Enterprise内のすべてのリポジトリに対して有効にする
- 検査は実行の完了後。 有効にしたあとの新しいワークフローの実行について、実行が終わってからログを検査する。過去の実行のログは検査しない
- 対象はシークレットスキャンが有効なリポジトリだけ
設定の場所は、Enterpriseの「Policies」の「Advanced Security」にある「Secret scanning for Actions workflow logs」です。「All repositories」のメニューで Enabled（有効）か Disabled（無効）を選びます。
この機能の定義ファイル（data/features/secret-scanning-actions-logs.yml）では、対象の版が GitHub Enterprise Cloud（ghec）だけになっています。公開中のドキュメントでも、この節が載っているのはEnterprise Cloud版のページで、既定の版のページにはありません。組織単位やリポジトリ単位で有効にする手順は、今回の原稿にはありません。
シークレットスキャンそのものの利用条件も別にあります。組織が持つプライベートと内部のリポジトリでは、GitHub Secret Protectionが有効になっていることが前提です。
検出できるもの、できないもの
原稿には、検出の範囲がはっきり書かれています。
| 項目 | ワークフローのログでの扱い |
|---|---|
| サービス提供元のパターン（provider patterns） | 検出する |
| 汎用のパターン（generic patterns） | 検出しない |
| 独自に定義したパターン（custom patterns） | 検出しない |
| AIで検出するシークレット（AI-detected secrets） | 検出しない |
| Actionsがログで伏せ字にした値 | 検出しない |
つまり、主要なクラウドやSaaSが発行する、形式の決まった鍵が主な対象です。社内システムのパスワードや、独自形式のトークンは見つかりません。ログに出さない仕組みづくりが先で、この検査は取りこぼしを拾う網と考えるのが妥当です。
プレビューの間は通知が出ない
実務で一番気をつけたいのは、次の一文です。
パブリックプレビューの間、ワークフローのログで見つかったシークレットのアラートは通知を生成しない。確認するには、リポジトリのシークレットスキャンのアラートを確認する。
有効にしただけでは、検出されても誰にも知らせが届きません。誰が、どの頻度でアラートの一覧を見るのかを、有効にする前に決めておく必要があります。
アラートの中身についても書かれています。同じシークレットが複数の実行やジョブに出た場合は、1つのアラートに複数の場所がまとめられます。場所ごとに、シークレットが出たもとのワークフローのファイルと、ログの該当行へのリンクが付きます。ただし、ログの内容はアラートの画面に表示されません。
見つかったときの手順
対処の手順は、別のページ（アラートの解決）に追加されました。原稿に書かれた順序は次のとおりです。
- アラートとリンク先のジョブのログを見て、どの鍵が、どこから出たのかを特定する。ワークフロー自体、アクション、そのほかの依存のどれが出力したかを確かめる
- 鍵がまだ有効かを確かめる。有効な場合や、状態を確認できない場合は、発行元の管理画面ですぐに無効化（rotate / revoke）する
- 出力の原因を直す。ワークフローや依存の更新、ハードコードした鍵の削除、暗号化されたシークレットへの移行など
- 必要なら、
::add-mask::<値>で以後のログに値を出さないようにする
原稿には警告として、「出力の原因を直すまでワークフローを再実行しない。原因を残したまま再実行すると、シークレットが再び露出する可能性がある」とあります。失敗したジョブをとりあえず再実行する、という普段の操作が、ここでは逆効果になります。
Actionsのセキュリティのページには、伏せられなかったシークレットがログに出た場合は、ログを削除してシークレットをローテーションするよう書かれています。アラートの手順には載っていませんが、鍵を無効にしたあとの後始末として確かめておきます。
::add-mask:: は、ジョブの中で値を伏せ字にするワークフローコマンドです。ドキュメントでは、ジョブごと・値ごとに1回実行する必要があり、伏せた値は出力（outputs）として受け渡せなくなると説明されています。
有効にする前に決めておくこと（編集部の提案）
ここからは、ドキュメントの記述をもとにした編集部の提案です。実際のEnterpriseで有効にして検出を確かめたわけではありません。
ログを残す期間と閲覧範囲を見直す。 検査は実行の完了後なので、検出されるまでの間もログは読める状態です。公開リポジトリや、外部の協力会社が読めるリポジトリでは、ログを読める人の範囲そのものが露出の範囲になります。
アラートを見る担当と頻度を決める。 プレビューの間は通知がないため、週に1回など、一覧を確認する運用を決めます。リポジトリの数が多い組織では、セキュリティの概要画面やAPIで横断して確認する方法も検討します。シークレットスキャンのアラートをAIエージェントから扱う方法は、GitHubのシークレットスキャンとMCPサーバーの記事で扱いました。
ログに出さない書き方を、ワークフローの点検項目に入れる。 環境変数をまとめて表示する env や printenv の実行、set -x によるコマンドの展開、ツールの詳細ログの有効化は、鍵をログに出しうる経路です。Actionsのワークフローを継続的に点検する方法は、Actionsのサプライチェーン監査の記事も参考にしてください。
確認した範囲と、まだ分からないこと
2026年11月6日に、公開中のGitHub Enterprise Cloud版のドキュメント（「Secret scanning」「Resolving alerts from secret scanning」「Enforcing policies for code security and analysis for your enterprise」）、ワークフローコマンドとActionsのセキュリティのページ、GitHubのドキュメントのリポジトリ（github/docs）のコミット 4435d78（2026年11月5日、「Republish: Secret scanning detection in GitHub Actions workflow logs [public preview]」）の差分を確認しました（資料調査）。同じ原稿は2026年10月7日に一度公開され（c34f4bd）、10月15日に取り消されたあと（f137520）、11月5日に再公開されています。取り消しの理由は記録から読み取れません。GitHub Changelogの2026年10月と11月（6日まで）の一覧には、この機能の告知は見つからず、機能の提供開始日は確認できていません。Enterpriseでの有効化と検出の実機の確認もしていません。
CI/CDの鍵の扱いや、ワークフローの点検の進め方は、グリームハブの開発・AI・自動化のご相談で承っています。リポジトリの構成や協力会社との分担によって進め方が変わるため、お問い合わせからご相談ください。
参考資料
- GitHub Docs — Secret scanning（Enterprise Cloud版）
- GitHub Docs — Resolving alerts from secret scanning（Enterprise Cloud版）
- GitHub Docs — Enforcing policies for code security and analysis for your enterprise
- GitHub Docs — Workflow commands for GitHub Actions（Masking a value in a log）
- GitHub Docs — Secure use reference
- github/docs — commit 4435d78
