目次
AIに「テストして本番へ自動デプロイする設定を書いて」と頼むと、短時間でGitHub ActionsのYAMLができあがります。しかし、その設定はコードを実行し、場合によってはリポジトリーやクラウドへ変更を加えるプログラムです。構文が通ることだけで、本番へ入れてよいとは判断できません。
情報確認日：2026年10月15日。本記事はGitHubなどの公式資料をもとにしたCIの権限設計の解説です。特定のワークフローが侵害されたという報告ではありません。既存の依存パッケージ対策の記事とは分け、今回は実行のきっかけと資格情報の境界を中心に扱います。
スポンサーリンク
ワークフローを三つの軸で読む
本サイトでは、まず「何が実行を始めるか」「誰が変更したコードを動かすか」「その場で何の権限を持つか」を確認する方法を提案します。pushやPRというイベント名だけでなく、対象ブランチ、チェックアウトする版、利用する外部Action、後続の処理まで追います。
説明用に、外部からのPRを検査するジョブと、本番サイトを更新するジョブを考えます。前者は信頼していない変更を読む必要があります。後者は本番の書き込み権限が必要です。この二つを同じ環境と資格情報でまとめると、検査対象のコードへ強い能力を与えるおそれがあります。
AIが生成した設定にコメントで「安全なPRテスト」と書かれていても、実際の実行条件の保証にはなりません。使っているイベント、参照先、権限、秘密情報を、YAMLと提供元の仕様から確認します。意図の説明と、実際の動作を分けてレビューしてください。
pull_request_targetは、名前だけで通常のPRテストと考えない
GitHubのSecure use referenceは、pull_request_targetやworkflow_runの特権的な文脈で、信頼できないPRのコードをチェックアウトして使う危険を説明しています。イベントを選んだ後で、どのコードを実行するかが重要です。 根拠資料：GitHub Docs：Secure use reference。
メタデータの分類やラベル付けのための処理と、PRが変更したスクリプトを動かす処理を分けます。特権のあるジョブで、検査対象のビルドスクリプトや任意コマンドを実行しない構成を提案します。外部からの変更を、内部の運用者と同じ信頼で扱わないことが出発点です。
また、別のワークフローへ渡す成果物にも注意します。前段のテストが通ったというだけで、成果物の中のスクリプトやパスを後段で無条件に使うべきではありません。内容、出所、対応するコミットを確認し、本番の実行コードとして読み込む境界を明確にします。
スポンサーリンク
PRのタイトルも、シェルへ直接埋め込まない
PRタイトル、ブランチ名、コメント本文などは、外部の人が変更できる場合があります。それらをスクリプトのソースへ直接差し込むと、文字列が実行するコードの一部になる可能性があります。AIが作る短い例では、見落とされやすい場所です。
GitHubは、適切なActionへの引数渡しや、中間の環境変数を使う方法を説明しています。ただし、環境変数へ入れればあらゆる使い方が安全になるわけではありません。その後にevalへ渡したり、コマンドの構文として再解釈したりしない設計が必要です。
本サイトでは、外部から来る値を台帳に列挙し、値として比較する場所と、実行コードになる場所を分けるレビューを提案します。正規の文字列だけでなく、引用符、改行、長い値、空の値を使い、必要な処理が意図どおり止まるかを検証します。
GITHUB_TOKENの権限を、仕事ごとに限定する
テストを実行するために、リポジトリーへ書き込む権限が常に必要とは限りません。GitHub公式はGITHUB_TOKENの権限を必要最小限にし、必要に応じてジョブ単位で増やすことを勧めています。設定ファイルのpermissionsを、具体的な操作と照合します。
すべてをwriteへ変えるとエラーが解消する場合があっても、その変更が妥当とは限りません。何のAPIが拒否されたかを確認し、その操作が本当に必要かを決めます。使っていない公開や管理の能力を、動作確認のためだけに残さないようにします。
外部Actionも、そのジョブの環境で動くコードです。便利な部品を追加するときは、入出力と権限を確認します。依存先の固定や更新も必要ですが、固定された版であること自体が、そのコードの安全性を証明するわけではありません。
スポンサーリンク
OIDCで長命キーを減らしても、信頼条件が残る
GitHub ActionsからAWSなどへ接続する場合、OIDCにより長期間有効なクラウドキーの保管を減らせる構成があります。しかし「OIDCを有効にした」だけでは、どのリポジトリーのどの処理へ本番権限を渡すかは決まりません。
GitHubのAWS向け公式資料は、信頼ポリシーでaudやsubなどを確認する構成を説明しています。対象のリポジトリー、ブランチ、環境と、クラウド側の条件を一致させます。広すぎるワイルドカードで、意図しない実行元まで信頼しないようにします。 根拠資料：GitHub Docs：Configuring OpenID Connect in Amazon Web Services。
確認した資料では、リポジトリーの状態によってsubの形式が異なる場合も説明されています。古い例をそのまま貼らず、実際に使用する形式を確認してください。正しい接続元だけがロールを取得できることと、そのロールが必要最小限であることを、別々に点検します。
本番展開の許可を、検査ジョブから切り離す
本サイトでは、未信頼の変更を調べる処理、本番へ進める判断、実際の展開を分ける構成を提案します。本番用の環境には、必要なブランチや承認条件を設定し、検査だけで使うジョブへ本番の秘密情報を渡しません。
承認画面には、何を展開するかが分かるコミットや成果物の識別情報を出します。「テスト成功」という名称だけでは、承認した版と配信した版が同じか確認できません。承認後に別の版を取り直す経路がないかも点検します。
レンタルサーバーへSFTPなどで配信する場合も、使うアカウントの対象ディレクトリーや操作範囲を絞ります。クラウドのOIDCを利用できない環境だからといって、管理者用の資格情報をCIへ広く配布する必要はありません。提供元の制約に合わせて分離を考えます。
実行環境を使い回す場合の注意点
セルフホスト型のランナーを使う場合、前の仕事が残したファイルやプロセスが、次の仕事へ影響しないかを確認します。本番用のランナーで外部PRのコードを実行するような構成は、特に境界を明確にする必要があります。
キャッシュや成果物の共有も、処理を速くする一方で、出所の異なる内容をつなぐ経路になります。キャッシュがあることを信頼の根拠にせず、どの入力から作られ、どの権限のジョブで使うかを整理します。検査前の内容を、検査済みとして再利用しないでください。
異常時には、対象ジョブの停止、資格情報の失効、実行環境の再作成を行えるようにします。ログや成果物を確保する手順も準備します。単に同じジョブを再実行して成功したことだけで、不審な変更の影響が消えたとは判断できません。 根拠資料：OWASP：Secrets Management Cheat Sheet。
テストと展開で、成果物の取り扱いを分ける
テストの結果を後続へ渡す場合は、何を受け取るかを限定します。本サイトでは、成否や対象コミットのような必要な情報と、実行可能なスクリプトや設定を区別する方法を提案します。前段から届いた文字列を、後段のシェルコードや配信先のパスへ自由に使わないようにします。
配布用の成果物についても、どのジョブで作り、どのコミットと対応し、途中で置き換わらないかを確認します。承認されたコードと別の版を再ビルドする場合には、同じ入力かを検証する必要があります。「前段が成功した」という一つの値で、成果物の出所まで保証されたと考えないことが重要です。
スポンサーリンク
AIへ設定修正を頼むときの入力を限定する
動かないワークフローをAIへ相談するとき、秘密を含む全ログや環境変数を渡す必要はありません。発生したジョブ、イベント、エラーコード、権限の宣言、資格情報を除いた設定を整理します。特に、取得したOIDCトークンやクラウドの一時資格情報を再現資料に含めないようにします。
提案された修正では、動くようになった箇所だけでなく、権限の拡大やイベントの変更を確認します。認証エラーを消すために信頼条件を広げる、検査エラーを消すために処理を飛ばすといった変更が混ざっていないかを見ます。実行成功と、拒否すべき入力が拒否されることの両方をレビュー結果へ記録してください。
設定変更のレビューと、拒否テストを用意する
ワークフローの変更は、通常の画面表示の修正より広い影響を持つ場合があります。本サイトでは、イベント、権限、秘密情報、展開先が変わる差分を、担当者が確認する対象として明示することを提案します。AIが作った変更も同じ手順に載せます。
- 信頼していないPRから、本番の資格情報を取得できない。
- タイトルやコメントに特殊な文字があっても、実行コードにならない。
- 許可外のブランチ・環境では、クラウドのロール取得が拒否される。
- 承認した版と配信する成果物が一致し、途中で別の版へ置き換わらない。
- 失敗時のログに秘密が出ず、停止と失効の担当者が分かる。
検証は、本番データを持たないリポジトリーと最小権限の環境で行います。AIによって設定を書く時間が短くなっても、信頼していない入力と本番権限を分ける仕事は残ります。ワークフローをプログラムとして読み、入口と実行能力を一緒に確認しましょう。
スポンサーリンク
