GitHub Actionsのシークレット管理：ワークフローでAPIキーとパスワードを保護する

By Mirko Peters · 2026-10-26

GitHub Actionsのシークレットを正しく使い、CI/CDパイプラインを保護する方法を解説します。APIキーとアクセストークンを安全に管理するためのベストプラクティスを紹介します。

Automatically translated with AI from the original post. Read the English original

クラウド上で自動化処理を完全に無人で実行する場合、認証情報の安全な管理が極めて重要になります。GitHub Actionsのシークレットを適切に管理することで、APIキー、デプロイ用のパスワード、アクセストークンをソースコードの外に置きつつ、プロジェクトのビルドと配布に必要なワークフローからは簡単に参照できる状態を保てます。

重要なポイント

• 機密性の高いパスワード、APIキー、アクセストークンを、ワークフローのYAMLファイルに直接ハードコードしないでください。
• GitHubには、リポジトリシークレット、組織シークレット、環境シークレットの3つのレベルがあります。
• シークレットは、GitHubに届く前に暗号化され、実行ログ内では自動的にマスクされます。
• 環境シークレットでは、デプロイ用の認証情報をジョブが利用できるようになる前に、人による承認を必須にできます。
• 常に最小権限の原則に従い、各シークレットには必要最小限のアクセス許可だけを付与してください。

CI/CDで平文の認証情報が問題になる理由

新しいパイプラインを急いで構築している開発者は、APIキーをそのままワークフローの設定ファイルに貼り付けたくなるものです。ワークフローがプライベートであれば、誰が見るというのでしょうか。しかし、このような考え方は深刻なセキュリティ上の脆弱性を生みます。ワークフローファイルはバージョン管理されているため、すべての過去の変更履歴、コミット、ブランチに、YAMLファイルに書かれた内容がそのまま永続的に残ります。

さらに、リポジトリの権限が変更されたり、プライベートからパブリックに切り替えられたり、貢献者によってフォークされたりすることも珍しくありません。認証情報を設定ファイルに平文の文字列として置いていると、権限設定のわずかなミスで本番環境全体が露出するおそれがあります。設定ファイルは処理手順として扱い、機密データは暗号化された、設定から分離された保管場所に格納する。これが現代のクラウドセキュリティの基本原則です。

GitHubシークレットの3つの階層

GitHubでは、認証情報ごとに利用範囲が異なることを前提としています。開発者がアクセス制御を効率的に管理できるよう、プラットフォームでは3つの異なる組織レベルでシークレットを設定できます。

リポジトリレベルのシークレット

リポジトリシークレットは、1つのプロジェクトにのみ属します。単独のアプリケーションや1つのプラグインを開発している場合、リポジトリシークレットを使うと、接続文字列やデプロイ用トークンを特定のワークスペースに限定して保護できます。組織内の他のプロジェクトからは参照できません。

組織レベルのシークレット

企業内の複数のリポジトリが、中央のコンテナレジストリやエンタープライズのコード署名証明書などの共有リソースにアクセスする必要がある場合、組織シークレットを使えば同じ値を何度も登録する手間が省けます。管理者はポリシーを定義し、これらの組織全体の認証情報を継承できるリポジトリやチームを指定できます。

環境レベルのシークレット

環境シークレットは、ステージングや本番環境などの特定のデプロイ先に認証情報を紐付けます。実稼働環境のシステムを操作するために必要なキーは、ここに保存します。特に重要なのは、環境シークレットでは必須のレビュー担当者を設定できる点です。本番環境の認証情報が取り出されてランナーに渡される前に、必ず人が手動でデプロイの実行を承認する仕組みを作れます。

GitHubがデータの転送中をどう保護するか

セキュリティは、シークレットをどこに保存するかだけでなく、実行中にどのように受け渡されるかまでを含みます。シークレットは GitHub に送信される前にローカル マシン上で暗号化されるため、ネットワーク上で平文として送信されることはありません。保存後は、リポジトリの設定画面でも完全に非表示になります。

ワークフローの実行時には、${{ secrets.DATABASE_URL } } のような式構文を使い、ステップやアクションにシークレットを名前で明示的に渡す必要があります。これにより、不注意または悪意のあるサードパーティ製のマーケットプレース アクションが、リポジトリ内のすべての資格情報を勝手に取得することはできません。明示的に渡された情報だけが受け取られます。

さらに GitHub は、機密性の高い文字列をマスクするために、ジョブの出力ログを自動的にスキャンします。スクリプトが誤ってシークレットの値をコンソールに出力すると、GitHub は文字をアスタリスクに置き換えようとします。ただし、スクリプトは出力前に文字列を加工したりエンコードしたりできるため、ログのマスキングだけに頼ることは、安全なコードを書くことの代わりにはなりません。

安全な自動化のためのベストプラクティス

堅牢な GitHub Actions のシークレット管理を実現するには、日々の具体的な習慣が必要です。まず、構成設定とシークレットを必ず区別してください。公開 Web サイトのアドレス、環境名、機密性のない機能フラグなどの値は、チームがパイプラインの動作を容易に把握できるよう、YAML ファイル内に平文で記述してください。シークレット機能は、機密を保つ必要があるデータにのみ使用してください。

次に、最小特権の原則を採用してください。有効期限ができるだけ短く、権限の範囲が最も狭い、きめ細かいアクセス トークンを生成します。デプロイ トークンが特定の 1 つの S3 バケットへの書き込みだけを必要とする場合は、クラウド インフラストラクチャ全体に対する管理者権限を与えないでください。

まとめ

GitHub Actions のシークレット管理を習得すると、CI/CD パイプラインは潜在的なセキュリティ上のリスクから、堅牢でエンタープライズ級の自動化エンジンへと変わります。認証情報をコードから分離し、多層的なアクセス制御を活用することで、セキュリティを犠牲にすることなく、迅速にソフトウェアを提供できます。

ワークフロー自動化の基礎を学ぶには、エピソードの全編を聴くをご覧ください。トリガー、ジョブ、ランナーの設定について詳しく知りたい方は、ぜひ全編をお聴きください。最新のクラウド環境向けの実践的な内容が詰まっています。

よくある質問

フォークからのプルリクエストで、GitHub Actions のシークレットを読み取ることはできますか？

既定では、悪意のあるコードが実行されて認証情報が盗まれることを防ぐため、GitHub はリポジトリ外の共同作成者（フォーク）からのプルリクエストが、リポジトリのシークレットにアクセスすることを禁止しています。

ワークフローからシークレットを特定のステップに渡すにはどうすればよいですか？

ステップまたはジョブ内で 'env' コンテキストを使用し、GitHub のシークレットを環境変数に対応付けます。例えば env: API_KEY: ${{ secrets.MY_API_KEY } } のように記述します。

GitHub Actions のシークレットは、ログで必ず隠されますか？

GitHub は、既知のシークレット値を実行ログ内で自動的にマスクします。ただし、これは絶対的な保証ではありません。シークレットの値が出力前に加工、エンコード、または変換されると、一部が露出する可能性があります。

リポジトリ シークレットと環境シークレットの違いは何ですか？

リポジトリ シークレットは、そのリポジトリ内のすべてのワークフローで利用できます。一方、環境シークレットは、ステージングや本番などの特定のデプロイ環境に紐付けられ、手動による承認を必要とする場合があります。