--- title: "GitHub ActionsのSecrets管理｜置き場所の選定と漏えい経路・OIDC移行の判断" url: "https://www.issoh.co.jp/tech/details/16939/" published: 2026-08-25 updated: 2026-09-29 categories: ["GitHub"] publisher: "株式会社一創" --- # GitHub ActionsのSecrets管理｜置き場所の選定と漏えい経路・OIDC移行の判断 GitHub Actionsのシークレットは、登録画面が単純なぶん、設計しないまま増やしても動いてしまいます。半年後にリポジトリの設定画面を開くと、誰がいつ発行したのか分からないトークンが並ぶ。受託開発の引き継ぎでよく見る光景です。この記事では、リポジトリ・組織・環境という3階層のどこへ置くかの基準、ログの伏せ字が効いていても値が外へ出る経路、外部シークレットストアへ寄せる構成が見合う規模、そして長期キーをOIDCへ置き換えるかどうかの分岐までを、GitHub公式ドキュメントの現行仕様（2026年8月時点）を根拠に整理します。envとvarsとsecretsをワークフロー内でどう書き分けるかは[GitHub Actionsの環境変数を3系統で書き分ける解説](https://www.issoh.co.jp/tech/details/16921/)で扱っているため、ここでは値の保管と運用に絞ります。 ## まとめ：Secretsの置き場所と長期キーの扱いを先に決める 結論から示します。置き場所は「その値が漏れたときに何ができてしまうか」で決めます。外部SaaSへ送るアップロードトークンを扱う例は、[CodecovのCODECOV\_TOKENをSecretsへ置く手順](https://www.issoh.co.jp/tech/details/17720/)で具体的に示しました。複数リポジトリで共有する読み取り専用のトークンは組織、本番環境へ書き込む資格情報は環境、そのリポジトリでしか意味を持たない値はリポジトリ。この3分類を先に紙へ書いてから登録すれば、あとで棚卸しが成立します。 次に、ログの伏せ字はあくまで事故の被害を減らす保険であって、防御ではありません。GitHub公式ドキュメントは伏せ字が完全一致に依存すると明記しており、JSONの塊に包んだ値やBase64へ変換した値では外れます。守るべき線は別のところにあります。第三者Actionをタグではなくコミットの完全なSHAで固定すること、`pull_request_target`で信頼できないコードをチェックアウトしないこと、`GITHUB_TOKEN`の既定権限を読み取りへ落とすこと。この3点のほうが、伏せ字の設定より効きます。 そして長期キーです。AWS・Azure・Google Cloudのいずれかへデプロイしていて、そのワークフローが月1回以上走るなら、長期のアクセスキーをシークレットへ置く構成はやめてOIDCへ寄せる、と判断してよい段階に来ました。逆に、外部シークレットストアの導入は規模で決まります。リポジトリが5本以内でシークレットが20件を下回るなら、ストアを1つ増やすより四半期に一度の手動棚卸しのほうが安く回るでしょう。以下、この判断に至る仕様と条件を順に開きます。 ## リポジトリ・組織・環境の3階層と上限値で決まるシークレットの置き場所 3つの階層は、保管場所の違いというより配布範囲の違いです。上の階層へ置くほど多くのワークフローから読め、そのぶん漏れたときの影響範囲が広がります。まず現行の上限値から押さえます。 ### 組織1,000個とリポジトリ100個・環境100個という現行の上限と48KBの制約 GitHub公式ドキュメントのシークレット仕様（2026年8月時点）では、組織に最大1,000個、リポジトリに100個、環境に100個まで登録できます。1つあたりのサイズ上限は48KBです。ただし、登録できる数と1回の実行から読める数は一致しません。 | 階層 | 登録上限 | ワークフローから読める範囲 | | ----- | ------ | --------------- | | 組織 | 1,000個 | アルファベット順の先頭100個 | | リポジトリ | 100個 | 全100個 | | 環境 | 100個 | 全100個 | 48KBという上限は、証明書やサービスアカウントの鍵ファイルを丸ごと1件に入れると現実的に効いてきます。名前の制約も見落とされがちで、使えるのは英数字とアンダースコアだけ、`GITHUB_`で始まる名前と数字始まりは登録できません。参照時は大文字小文字を区別しないため、`API_KEY`と`api_key`は同じものとして扱われます。シークレットを`if`条件の中で直接参照できない点も、分岐を書く前に押さえておくべき仕様です。 ### 組織シークレットのアクセスポリシー3種と選択リポジトリへ絞る判断 組織へ置くと決めたら、次に配る先を選びます。GitHubは組織シークレットに3つのアクセス範囲を用意していて、全リポジトリ、プライベートとインターナルのみ、選択したリポジトリのみ、から選ぶ形です。指定しない場合はプライベートのみが既定になります。 ここで判断が分かれます。通知用のチャットWebhookのように、漏れても被害が「社内の情報が1つ見える」程度で止まる値は、全リポジトリで構いません。一方、決済代行のAPIキー、本番データベースの接続情報、顧客データを含むストレージの資格情報は、選択したリポジトリへ必ず絞ります。組織に100人の開発者がいて全リポジトリへ配る設定にしていると、誰か1人がワークフローファイルを追加できる立場にあるだけで、その値を自分のログへ書き出せてしまうためです。受託開発で複数の顧客案件を1つの組織に同居させているなら、案件をまたぐ共有は原則禁止にしておくと監査が楽になります。 ### 同名時に環境が勝つ優先順位とアルファベット順で切られる100個の壁 同じ名前のシークレットが複数の階層に存在するとき、優先されるのは環境、次にリポジトリ、最後に組織の順です。この規則を使うと、組織に検証用の既定値を置き、本番環境にだけ本番の値を置いて上書きする構成が組めます。環境シークレットと承認ゲートを組み合わせた設計は[GitHub ActionsのEnvironmentsで承認ゲートと環境別シークレットを設計する解説](https://www.issoh.co.jp/tech/details/16935/)に詳しいので、環境単位の分離を詰めるならそちらを先に読んでください。 あまり知られていない落とし穴が、組織シークレットの読み取り上限です。登録は1,000個までできるのに、1回の実行から読めるのはアルファベット順に並べた先頭100個だけと明記されています。101個を超えた時点で、名前が後ろのほうにある値は静かに空になります。エラーではなく空文字として渡るため、原因の特定に時間を取られる種類の障害です。組織シークレットが3桁に近づいたら、命名を並べ替えるのではなく、そもそも組織へ置く必要がある値かを見直してください。 ## マスキングが効いてもシークレットが外へ出る4つの経路と塞ぎ方 GitHubはワークフローログに出力されたシークレットを自動で伏せ字にします。ただし公式ドキュメントには但し書きがあり、自動の伏せ字は保証されないと明記されているのが実際です。仕組みと限界を踏まえたうえで、伏せ字に頼らない経路の遮断へ手を入れます。 ### JSONで包んだ値とBase64変換でログの伏せ字が外れる具体的な条件 伏せ字の判定は、登録した値そのものとの完全一致で行われます。だからJSON・XML・YAMLの塊にシークレットを包むと、整形や改行の入り方で一致が崩れ、伏せ字が働きません。公式ドキュメントも、JSONやXMLのような形式でシークレットの値を包むことを名指しで避けるよう求めています。Google Cloudのサービスアカウント鍵をJSONのまま1件に入れる構成が典型例で、ログへ流れた瞬間に生の値が読めてしまいます。 変換も同じです。Base64やURLエンコードを通した値は、元の文字列と一致しないため伏せ字の対象から外れます。変換後の文字列も別のシークレットとして登録するのが公式の指示です。実行時に生成した値、たとえば一時的に払い出したトークンを伏せたい場合は、add-maskのワークフローコマンドでランナーへ登録します。実務としては、JSONを丸ごと1件にせず必要なフィールドだけを個別のシークレットへ割る。これだけで事故の確率がかなり下がります。 ### 第三者Actionが全シークレットへ届く構造とコミットSHA固定での封じ込め ワークフローが呼ぶ`uses`のActionは、そのジョブに渡されたシークレットへ手が届きます。公式ドキュメントの表現では、ワークフロー内の単一Actionが侵害されると、そのリポジトリに設定された全シークレットへアクセスされうる、という整理です。`v4`のようなタグ参照はリポジトリ側で付け替えられるため、昨日まで安全だったタグが今日は別のコミットを指している事態が起こります。 公式が挙げる対策は明快で、コミットの完全な長さのSHAへ固定することが、Actionを不変のリリースとして使う唯一の方法だと書かれています。設定手順と組織全体への強制、pinactによる一括変換は[SHA PinningでGitHub ActionsをコミットSHAへ固定する解説](https://www.issoh.co.jp/tech/details/10238/)にまとまっています。運用の落としどころとしては、自社で管理していないActionだけをSHA固定の対象にして、Dependabotで更新プルリクエストを受ける形が現実的でしょう。 ### フォークPRでは渡らない前提とpull\_request\_targetが崩す境界線 オープンソースを公開しているなら、フォークからのプルリクエストが最大の関心事になります。仕様上は安全側に倒れていて、`GITHUB_TOKEN`を除くシークレットは、フォークから起動したワークフローのランナーへ渡りません。 境界を崩すのが`pull_request_target`と`workflow_run`です。この2つは特権的なトリガーで、mainブランチと同じキャッシュを共有し、書き込み権限と参照先のシークレットへ到達しうると公式ドキュメントが警告しています。ここで信頼できないプルリクエストのコードをチェックアウトしてビルドやテストを走らせると、外部から送られたコードが自社のシークレットを持ったまま動く形になります。原則は2つ。`pull_request_target`は必要がなければ使わない。使う場合はフォーク側のコードを絶対にチェックアウトしない。ラベルの付与やコメント返信のように、コードを実行しない処理だけに限定してください。 ### GITHUB\_TOKENの既定権限を読み取りへ落として被害範囲を切る手順 フォークからでも渡る唯一のシークレットが`GITHUB_TOKEN`です。既定の権限が広いままだと、侵害されたActionがそのトークンでリリースを差し替えたり、ブランチへ書き込んだりできます。公式ドキュメントの推奨は、既定をリポジトリ内容の読み取りのみに設定し、必要なジョブでだけワークフローファイル側から権限を上げる方式です。 手順としては、設定でワークフロー権限を読み取り専用へ切り替え、その後で失敗したワークフローに`permissions`ブロックを足していきます。逆順にすると、どのジョブが何の権限を必要としているのか永遠に分かりません。一度に全リポジトリを切り替えると開発が止まるため、影響の小さいものから順に倒すのが安全でしょう。 ## 外部シークレットストア連携と実行時取得へ寄せる構成の採用条件 GitHubの外へ値を出し、ワークフローの実行時に取りに行く構成もあります。判断は「入れれば安全になるか」ではなく「棚卸しと入れ替えが自分の手で回るか」で分かれます。 ### AWS・Azure・Vaultの公式Actionと2026年8月時点の主要版 主要な保管先には、それぞれ提供元が管理するActionがあります。以下はGitHubのリリース情報を2026年8月25日に取得した時点の最新タグです。 | 保管先 | 公式Action | 取得時点の最新タグ | | --------------------- | ------------------------- | --------- | | AWS Secrets Manager | configure-aws-credentials | v6.2.3 | | Azure Key Vault | Azure login | v3.0.1 | | Google Secret Manager | auth（Google提供） | v3 | | HashiCorp Vault | vault-action | v4.0.0 | 公開日を見ると、AWS向けが2026年7月、Azure向けが2026年8月、Vault向けが2026年5月と更新が続く一方、Google Cloud向けは2025年9月公開のv3系が最新のままでした。いずれもOIDCによる短命な資格情報の取得に対応しているため、外部ストアへ寄せる場合も入口の認証で長期キーを持たずに済みます。動的シークレットやリース期限といったVault固有の考え方は[HashiCorp Vaultの仕組みと採用判断を実装者目線で整理した解説](https://www.issoh.co.jp/tech/details/15580/)で確認してください。社員がすでに1Passwordを使っている組織なら、公式のload-secrets-actionでサービスアカウント経由で読む構成も選べます。YAMLの書き方とレート制限は[1Password CLIのサービスアカウント運用とレート制限](https://www.issoh.co.jp/tech/details/17930/)で扱っています。 ### 外部ストアへ寄せる価値が出る規模とGitHub内で持つほうが安い場面 外部ストアが効くのは、同じ値を多数のリポジトリで使っていて、入れ替えのたびに更新漏れが起きる状態です。10本のリポジトリに同じデータベースパスワードを配っていれば、1本の更新漏れが翌日の障害になります。ストアへ寄せれば更新は1箇所で済み、いつ誰が読んだかの記録も残せます。 逆に、規模が小さいうちは持ち込まないほうがよい、と言い切ります。リポジトリが5本以内、シークレットの総数が20件を下回り、入れ替えが年に1回程度なら、ストアの利用料と接続の保守コストが棚卸しの手間を上回るためです。この規模でストアを入れると、ストア自体の認証情報という新しい管理対象が1つ増えるだけで終わりがちになります。判断の分岐点は数ではなく重複です。同じ値が3つ以上のリポジトリに登録されている状態が2つ以上できたら、その時点で移行を検討してください。 ### 長期キーをOIDCへ寄せる判断基準と移行を見送ってよい2つの条件 クラウドへのデプロイに使うアクセスキーは、そもそもシークレットに置かない選択肢があります。OIDCを使うと、ワークフローが実行のたびにIDトークンを提示してクラウド側で短命な資格情報へ交換するため、長期の鍵を保存する必要がなくなります。公式ドキュメントも、これらの資格情報を長期のシークレットとして保存するのをやめられる、と明言しました。 判断基準はこうです。AWS・Azure・Google Cloudのいずれかへデプロイしていて、そのワークフローが月1回以上走るなら、移行します。実装で必要なのはワークフロー側の`id-token`書き込み権限と、クラウド側の信頼ポリシーの設定だけで、AWSでの具体的な手順は[GitHub ActionsとTerraformでOIDC連携のCI/CDを構築する手順](https://www.issoh.co.jp/tech/details/2715/)に実装例があります。アクション単体の入力とエラーの対処は[configure-aws-credentialsの使い方とv6の変更点を解説した記事](https://www.issoh.co.jp/tech/details/17939/)にまとめています。移行を見送ってよい条件は2つだけです。1つは、デプロイ先がIDトークンを受け付けない場合。オンプレミスの機器や、外部連携がAPIキー方式しかないSaaSが該当します。もう1つは、対象が数週間で廃棄する移行専用のリポジトリで、鍵の有効期限を作業期間に合わせて切れる場合。この2つ以外で「あとでやる」と決めた長期キーは、ほぼ確実に残り続けます。 ## 棚卸しとローテーションを回す運用設計と受託開発で先に決める線引き ここまでの設定は、入れた時点では正しく動きます。壊れるのは半年後です。人が入れ替わり、案件が終わり、鍵の持ち主が分からなくなったときに、消せない値だけが残ります。 ### 命名規則と棚卸し台帳で「誰の鍵か分からない」状態を防ぐ設計手順 名前に使える文字は英数字とアンダースコアだけなので、情報を詰め込む余地は限られます。それでも、発行元のサービス名を先頭に置く規則だけは決めておいてください。`STRIPE_SECRET_KEY`のように読めば発行元が分かる名前なら、退職者の棚卸しでも追えます。参照時に大文字小文字が区別されない点も、規則を大文字へ統一する理由になります。 そのうえで、GitHubの画面の外に台帳を1枚持ちます。列は4つで足ります。シークレット名、発行元のサービスと発行アカウント、失効予定日、使っているワークフローのファイル名。GitHubの設定画面は値も作成者も見せてくれないため、この4列がないと「消してよいか分からないから残す」判断しかできません。公式ドキュメントも登録済みシークレットの定期的な見直しと不要分の削除を求めていますが、判断材料は自分たちで持つしかないのです。 ### ローテーション周期を決める2つの軸と自動化が過剰投資になる規模 入れ替えの周期は、値の権限と、失効を自動化できるかどうかの2軸で決めます。本番データベースへ書き込める資格情報や決済のAPIキーは、四半期に一度。読み取り専用のトークンや検証環境の値は、年に一度で足ります。発行元が短命トークンに対応しているなら、そもそも周期の議論が不要になるため、入れ替えの設計より先に短命化できないかを確認するほうが順序として正しくなります。 自動化については線を引きます。シークレットが20件を下回り、リポジトリが5本以内の組織では、ローテーション基盤を組むのは過剰投資です。四半期に一度、台帳を開いて手で入れ替えるほうが速く、壊れません。自動化を検討してよいのは、入れ替え対象が50件を超えるか、監査で入れ替え記録の提出を求められる場合に限られます。なお、過去のコミットに混入した値は入れ替えても消えないため、履歴の走査は別の仕組みで並行して回してください。 ### 委託先へ開発を出すときにシークレットを渡さずに済ませる分離の型 受託開発で必ず問題になるのが、開発を委託した相手にどこまで資格情報を渡すか、という線引きです。結論としては、本番の資格情報は渡しません。渡さなくても開発は回ります。型は3つの組み合わせです。委託先が触るリポジトリには検証環境の値だけを置く。本番の値は環境シークレットへ隔離し、必須レビュアーによる承認ゲートを自社側の担当者に設定する。クラウドへのデプロイはOIDCにして、信頼ポリシーの条件へ環境名を含めることで、承認を通ったジョブ以外は本番の権限を取得できないようにする。 この構成なら、委託先はワークフローを書けますが、本番の資格情報を読み出すことはできません。逆に「開発中だから」と本番キーをリポジトリシークレットへ置くと、契約終了後もその値が残り、元担当者が過去のフォークから参照できる状態が生まれます。すでにその状態にあるか、既存のパイプラインに同じ穴がないか外から確かめたいなら、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で設定と権限まで含めて点検する方法もあります。設定を直す前に、どこまで露出しているかを先に把握してください。 ## よくある質問 GitHub ActionsのSecrets管理について、実装の現場で繰り返し出てくる質問をまとめます。 ### GitHub ActionsのSecretsはどこに登録するのが正解ですか？ 漏れたときの影響範囲で決めます。複数リポジトリで共有し、漏れても被害が限定的な値は組織シークレット。本番環境へ書き込む資格情報は環境シークレット。そのリポジトリでしか意味を持たない値はリポジトリシークレットです。組織へ置く場合も、アクセス範囲を全リポジトリのままにせず、決済や本番データベースの値は選択したリポジトリへ絞ってください。迷ったら、より狭い階層から始めて必要になってから上げるほうが安全になります。 ### Secretsの値をワークフローのif条件で分岐に使えますか？ 直接は参照できない仕様です。「シークレットが設定されていればデプロイする」といった分岐を書きたい場合は、ジョブレベルの環境変数へ一度代入し、その変数を`if`で判定します。なお、この方法でも値そのものを条件式へ晒す書き方は避けてください。設定の有無だけを真偽値へ変換して判定するのが安全な形になります。値の受け渡し全般の書き方は、環境変数側の解説にまとまっています。 ### フォークからのプルリクエストでSecretsは使えますか？ 使えません。`GITHUB_TOKEN`を除いて、フォークから起動したワークフローのランナーへシークレットは渡らない仕様です。これは既定の安全側の挙動なので、そのままにしておくのが正しい状態になります。問題になるのは`pull_request_target`や`workflow_run`を使って回避しようとしたときです。この2つは特権的に動くため、フォーク側のコードをチェックアウトすると外部のコードへシークレットが届きます。コードを実行しない処理に限定してください。 ### Secretsに登録した値がログに出てしまうことはありますか？ あります。GitHubの伏せ字は登録した値との完全一致で判定するため、JSONやYAMLの塊に包んだ値、Base64やURLエンコードで変換した値では働きません。公式ドキュメントも自動の伏せ字は保証されないと記載しています。対策は3つ。構造化データに包まずフィールド単位で登録する、変換後の文字列も別のシークレットとして登録する、実行時に生成した値はadd-maskでランナーへ登録する。 ### 再利用可能ワークフローにSecretsを渡すにはどうしますか？ 自動では渡りません。呼び出し側で明示的に渡す必要があり、個別に指定する方法と、呼び出し元のシークレットをまとめて引き継ぐinherit指定があります。inheritは記述が短くなる一方、渡す必要のない値まで届いてしまうため、呼び出し先が社外や別チームの管理下にある場合は個別指定にしてください。呼び出し方と入出力の設計は、再利用可能ワークフローの解説で扱っています。 ## 関連記事 - [GitHub Actionsの環境変数｜env・vars・secretsの使い分けと受け渡し](https://www.issoh.co.jp/tech/details/16921/)：3系統の書き分けとスコープ、受け渡しの実装を扱った記事。本記事で保管設計を決めたあと、実際に書く段階で読めます。 - [GitHub ActionsのEnvironments｜承認ゲートと環境別シークレットの設計](https://www.issoh.co.jp/tech/details/16935/)：環境単位の分離と保護ルール、承認ゲートの設計を扱った記事。委託先へ本番資格情報を渡さない型を組む土台になります。 - [AWS Secrets Managerとは？料金・ローテーションと採用判断](https://www.issoh.co.jp/tech/details/15888/)：外部ストアの代表格について、料金体系と自動ローテーションの仕組み、採用判断を整理した記事。移行の見積もりを立てる段階で参考になります。 - [gitleaksとは？シークレット検出の仕組みと使い方・設定](https://www.issoh.co.jp/tech/details/10403/)：コミット履歴に混入した資格情報を走査する仕組みと設定を解説した記事。入れ替えでは消えない過去の混入を洗い出す工程で使えます。 - [CI/CDとは？仕組み・パイプライン・導入すべき企業の判断基準](https://www.issoh.co.jp/column/details/13002/)：本記事の親にあたる解説。パイプライン全体の設計や導入判断から確認したい場合は、こちらから読めます。 --- 出典: [GitHub ActionsのSecrets管理｜置き場所の選定と漏えい経路・OIDC移行の判断]()（株式会社一創）