GitHub Actions cache-mode一般提供｜キャッシュ汚染を防ぐ4モードと開発委託の受入条件

「自動テストが通ったので納品完了」では、開発の供給網を受け入れたことになりません。外部から届く変更が、共有キャッシュへ何を読み書きできるかまで検収条件に入れる必要があります。

GitHubは2026年9月10日、GitHub Actionsのキャッシュへのアクセスをread、write、write-only、noneの4モードで制御するcache-modeを、github.comの全プランで一般提供したと発表しました。ワークフロー単位またはジョブ単位で指定でき、ジョブ単位の設定がワークフロー単位より優先されます。

目的は最小権限とキャッシュ汚染の防止です。外部のプルリクエストなど、信頼度が低い変更を処理するジョブに共有キャッシュへの書き込みを許すと、その後の信頼された処理が改変されたキャッシュを利用する恐れがあります。新機能はその権限を明示的に分けられるようにします。

ただし、設定項目が増えたこと自体は安全の保証ではありません。低信頼イベントには安全側の既定値がありますが、明示的にwriteやwrite-onlyを指定すれば書き込みを許可でき、GitHubはキャッシュ汚染リスクを高めるとして警告を表示します。機能があるかではなく、どのイベントとジョブにどのモードを指定したかを受け入れる必要があります。

結論：イベント、キャッシュ、シークレット、配備権限を一表で検収する

開発会社から受け取るべき最小の受入表は、次の形です。

これは万能の推奨値ではありません。開発言語、利用するアクション、成果物の作り方、外部貢献の有無で変わります。重要なのは、開発者の暗黙の判断を、発注側が承認できる表へ変えることです。

経営者が見るべき問いは三つです。外部から来た未承認コードが共有領域へ書き込めるか。その共有領域を本番成果物の構築で読むか。シークレットや配備権限を持つ処理と同じ境界で動くか。この三つが全て「はい」なら、テストが通るかどうかとは別に設計を見直す必要があります。

4モードの違い

GitHubの発表内容を、発注側の判断へ翻訳すると次のようになります。

readは読み取り専用です。外部からの変更を試験するとき、既存キャッシュを使って処理時間を短縮しながら、その変更から新しいキャッシュを保存させない構成にできます。

writeは復元と保存の両方を許します。信頼されたブランチへ反映した後に依存関係や構築結果を保存する場面が候補です。ただし、外部入力をそのまま含むキーや内容を保存し、後の信頼された処理が読むなら、権限設定だけでは不十分です。

write-onlyは既存キャッシュを読まず、新しいキャッシュを保存します。信頼された定期処理でキャッシュを作り直す、既存内容の影響を受けずに生成する、といった役割分離に使えます。名前だけでwriteより安全と判断せず、誰が生成処理を変更できるかを確認します。

noneはキャッシュへアクセスしません。本番配備が既に署名・検証された成果物を受け取るだけなら、配備段階で依存関係を再構築せず、キャッシュも使わない設計が候補です。一方、何でもnoneにすると処理が遅くなり、開発者が別の非公式な近道を作る可能性があります。リスクと運用負荷を見て選びます。

安全側の既定値があっても、明示設定を検収する理由

GitHubは、pull_request_targetのような低信頼イベントにreadを、pushのような信頼されたイベントにwriteを既定として示しています。設定しない場合は、この安全側の既定動作が続きます。

一方で、ワークフローにcache-mode: writeまたはcache-mode: write-onlyを明示すると、低信頼イベントでも書き込みを許可できます。GitHubはその場合に警告を加えます。警告があることと、組織の規則で禁止されていることは同じではありません。急ぎの修正で警告を無視する、処理時間短縮のため例外にする、再利用部品の中で権限が広がっている、といった状態を発注側が見つける仕組みが必要です。

また、ジョブ単位の設定はワークフロー単位を上書きします。全体にreadを設定していても、一つのジョブだけwriteなら、そこが書き込み可能です。「上に安全な設定がある」だけで確認を終えず、全ジョブの有効値を一覧にします。

再利用ワークフローの権限境界

GitHubの発表では、cache-modeは再利用ワークフローへ引き継がれ、呼び出された側は呼び出し元より大きな権限を得られないと説明されています。共通部品の中で勝手に権限を広げられないため、良い境界です。

ただし、呼び出し元が最初から広い権限を渡せば、共通部品もその範囲を使えます。複数案件で同じ再利用ワークフローを使う開発会社では、一つの変更が多くの案件へ波及します。発注側は、共通部品の保管場所、変更できる人、版の固定方法、更新時の試験、障害時の切戻しを確認してください。

「再利用しているから品質が高い」とは限りません。再利用は効率と同時に影響範囲を増やします。共通部品がどの顧客、どの環境、どの配備に使われているかを台帳化し、変更承認を分けることで初めて利益につながります。

キャッシュ汚染が経営問題になる経路

キャッシュは処理を速くするための一時データに見えます。しかし、依存関係、コンパイル結果、解析結果、ツール本体など、後続処理が信頼する材料を保存する場合があります。汚染の典型的な経路は次のとおりです。

1. 外部または権限の弱い利用者が変更を提案する。
2. その変更を試す自動処理が共有キャッシュへ書き込む。
3. 信頼されたブランチの構築が同じキーや広い復元条件でキャッシュを読む。
4. 改変された依存関係や成果物が、正規の処理へ混ざる。
5. シークレットや配備権限を持つ後段で実行される。

実際の成立条件は構成によって異なります。cache-modeだけで上の全てを防げるとは限りません。キャッシュキーの設計、復元条件、依存関係の固定、利用するアクションの版固定、成果物の署名と検証、シークレットの範囲、ブランチ保護を組み合わせます。

開発ツールを入口とする供給網リスクはGlassWormと拡張機能の確認手順、パッケージ依存の継続確認はnpm供給網攻撃から作る委託先チェック、AIが生成したコードを含む受入条件はAI生成コードのSAST・SCA・レビュー設計で整理しています。

RFPへ入れる8つの質問

開発会社を選ぶ前なら、次の質問を提案依頼書へ入れます。製品名の列挙ではなく、証拠と責任を求める質問です。

1. 外部プルリクエスト、内部プルリクエスト、保護ブランチへの反映、定期実行、本番配備ごとに、キャッシュの読み取り・書き込み権限を示してください。
2. 低信頼イベントからwriteまたはwrite-onlyを指定する必要がある箇所はありますか。ある場合、理由と代替案を示してください。
3. キャッシュキーと復元条件に、ブランチ、依存関係の固定値、実行環境をどう含めますか。
4. 再利用ワークフローと外部アクションの保管場所、版固定、変更承認、脆弱性対応を示してください。
5. キャッシュを読むジョブは、どのシークレットと権限へ到達できますか。
6. 本番成果物はどのジョブで作り、どこへ保存し、配備前に何を検証しますか。
7. 納品時に、全ワークフローとジョブの有効なcache-mode一覧を提出できますか。
8. 例外設定を誰が承認し、いつ失効させ、監査記録をどれだけ保存しますか。

回答の評価では、「ベストプラクティスに従う」「GitHubの既定値を使う」だけでは不足です。対象ファイル、イベント、ジョブ、モード、理由が示されているかを見ます。提案段階で答えられない会社が、納品後に発注側へ十分な運用資料を残す可能性は高くありません。

契約と検収へ入れる受入条件

RFPで方針を確認したら、契約と検収へ落とします。次の条件を仕様書または受入基準に含めます。

• 全ワークフローとジョブの一覧、起動イベント、有効なキャッシュモードを納品する
• 低信頼イベントのキャッシュ書き込みは原則禁止し、例外は発注者の書面承認を要する
• ジョブ単位の上書きと再利用ワークフローを含めた実効権限を検査する
• 外部アクションは固定した版またはコミットで管理し、更新手順を残す
• シークレットはジョブ単位で最小化し、プルリクエスト処理へ原則渡さない
• 構築と本番配備を分け、配備は承認済み成果物だけを受け取る
• キャッシュキー、復元条件、削除・無効化手順を文書化する
• 例外設定、警告、失敗した検査を受入報告書へ残す
• 納品後の脆弱性情報確認と設定変更の責任分界を定める

検収試験では、設定ファイルを目視するだけでなく、低信頼イベントを模した試験で保存が拒否されること、シークレットが渡らないこと、本番配備が起動しないことを確認します。設定の意図と実際の動作を両方残します。

納品後に残す証跡

納品時点の一覧だけでは、翌月の設定変更を追えません。ワークフロー変更を通常のソースコードと同じレビュー対象にし、キャッシュモード、権限、シークレット、配備先が変わる差分には、指定した責任者の承認を必須にします。例外は理由、対象、承認者、終了日を記録し、終了日に自動で確認課題を起票します。

月次では、低信頼イベントから書き込み可能なジョブ数、シークレットへ到達するジョブ数、本番配備できるジョブ数、期限切れ例外数を追います。目標を「事故ゼロ」だけにすると、危険な状態が残っていても事故が起きるまで見えません。構成上の危険な組み合わせが減ったかを先行指標にします。

新規案件では最初の提案時、既存案件では次の保守更新時に、この証跡を契約成果物へ加えます。後から追加料金になるかを避けるため、一覧作成、試験、例外管理、引継ぎの工数を見積段階で分けてください。

開発会社が変わる場合は、一覧、試験記録、例外、外部アクション、再利用ワークフロー、キャッシュ削除手順を引継ぎ対象にします。担当者の個人口頭説明に依存しないことが、次回の見積比較と障害復旧の時間を短くします。

監査結果には、問題点だけでなく「なぜこのモードを選んだか」を一行ずつ残します。理由があれば次の担当者が安全性と処理時間のトレードオフを再評価できます。理由のない例外は、担当者が替わった後も消せず、権限だけが残りやすいためです。半年ごとに利用実績を確認し、使われていない処理、古い例外、退職者しか説明できない共通部品を廃止候補にします。

既存案件を30分で点検する手順

既にGitHub Actionsを使っているなら、全体の作り直しから始める必要はありません。

最初の10分で、起動条件を並べます。 .github/workflows配下を一覧にし、外部プルリクエスト、pull_request_target、push、手動、定期実行、再利用呼び出しを分類します。どの変更元が起動できるかを記録します。

次の10分で、権限の交差を見ます。 cache-mode、シークレット、リポジトリ権限、クラウド認証、本番配備の有無をジョブごとに置きます。設定がなければ既定値を記録し、ジョブ単位の上書きを確認します。

最後の10分で、危険な組み合わせへ印を付けます。 低信頼イベント、キャッシュ書き込み、シークレット、本番配備のうち二つ以上が交差するジョブを先にレビューします。全件の完全監査ではなく、優先順位を決める作業です。

この結果を一枚にして開発会社へ返せば、「セキュリティを強化してください」という曖昧な依頼より、見積範囲が明確になります。改修前後で危険な組み合わせが何件から何件へ減ったかも測れます。

よくある5つの失敗

失敗1：既定値が安全なので設定を見ない。 ジョブ単位の上書きや明示的な書き込み指定があれば、実効値は変わります。既定値は出発点であって、検収結果ではありません。

失敗2：内部の開発者は全員信頼済みとする。 個人端末や認証情報の侵害、誤操作、退職者権限の残存があります。人への信頼ではなく、処理ごとの最小権限で設計します。

失敗3：キャッシュは一時ファイルなので成果物ではないと考える。 後続処理が読む以上、供給網の一部です。保存者、利用者、削除条件、保持期間を管理します。

失敗4：構築と配備を同じジョブで行う。 キャッシュや依存関係を扱う広い処理が、そのまま本番権限を持ちます。成果物を境界にして分け、配備側は検証済み成果物だけを受け取ります。

失敗5：ソースコード納品だけで契約を終える。 自動化設定、外部アクション、権限、シークレット、キャッシュ、配備手順もシステムの一部です。納品物と保守対象へ明記します。

費用対効果：安全と処理時間を同じ表で決める

キャッシュを制限すると、依存関係の取得や構築が増え、実行時間と通信量が増える場合があります。そこで、全てを禁止する議論ではなく、処理一回あたりの短縮時間、月間回数、追加費用、汚染時の影響を同じ表にします。

たとえば、外部プルリクエストが月10回で一回5分遅くなるなら、noneの追加時間は月50分です。一方、その処理が本番用キャッシュへ書き込み、侵害時に全顧客へ影響するなら、短縮時間より分離の価値が上回ります。逆に、信頼されたmain反映後の構築が一日50回あり、依存関係が固定され、配備と分離されているなら、writeで効率を得る合理性があります。

この比較は、開発会社に安全性だけを要求して費用を無視するためではありません。どこを厳しくし、どこで速度を取るかを発注者が承認するためです。共通の受入表を複数案件で再利用すれば、提案比較と監査の工数が下がり、継続支援の粗利も守れます。

GXOへ相談する判断線

次のどれかに当てはまる会社は、ソースコードの品質とは別に発注条件を見直す段階です。

• 開発会社が本番配備まで行うが、権限一覧を受け取っていない
• 外部プルリクエストを受け付けるが、キャッシュとシークレットの扱いが不明
• 再利用ワークフローの更新が複数システムへ波及する
• 納品物に自動化設定、アクションの版、復旧手順が含まれていない
• 警告が出たときの例外承認者と期限が決まっていない

GXOの見積もり・提案書セカンドオピニオンでは、機能と工数だけでなく、CI/CD、供給網、権限、成果物、保守責任が見積と受入条件に入っているかを確認します。要件整理から発注する場合はシステム開発支援、既存環境の技術的な確認はセキュリティ支援へつなげます。

目的は特定の開発会社を否定することではありません。発注者と受注者が、どの設定を誰が決め、何をもって納品とするかを共通の表で合意することです。曖昧な責任を減らすほど、追加改修と障害対応の採算が読みやすくなります。

FAQ

Q. readとwrite-onlyの違いは何ですか。

A. readは既存キャッシュを復元できますが保存できません。write-onlyは既存キャッシュを復元せず、新しいキャッシュを保存できます。低信頼の検査で保存させたくない場合はreadまたはnone、管理された生成処理はwrite-onlyが候補です。

Q. 設定しなければ安全ですか。

A. GitHubはイベントに応じた安全側の既定値を用意していますが、ジョブ単位の上書き、再利用ワークフロー、シークレット、本番配備との組み合わせまで自動で受け入れてくれるわけではありません。有効な設定を一覧にして確認してください。

Q. pull_request_targetでは常にreadですか。

A. 既定はreadと案内されていますが、明示的な設定でwriteまたはwrite-onlyを指定できます。その場合はリスクを高める警告が出ます。設定値と警告を検収対象にします。

Q. GitHub Enterprise Serverでも使えますか。

A. 本稿で確認した発表はgithub.comの全プランでの一般提供です。GitHub Enterprise Serverへの提供時期は、この発表だけでは断定しません。利用中の版の公式文書と更新情報を確認してください。

Q. この設定だけでキャッシュ汚染を防げますか。

A. いいえ。書き込み権限を減らす重要な対策ですが、キャッシュキー、依存関係固定、外部アクションの版、シークレット、成果物の署名・検証、ブランチ保護を合わせて設計します。

この記事の確認範囲

本稿は2026年9月12日にGitHub Changelogと公式ワークフロー構文資料を確認して作成しました。4モード、ワークフロー・ジョブ単位の指定、ジョブ設定の優先、イベント別の既定値、低信頼イベントで書き込みを明示した場合の警告、再利用ワークフローの権限制約、github.com全プランでの一般提供は公式発表に基づきます。GitHub Enterprise Serverの提供は断定していません。RFP、契約、検収の表はGXOの実務上の整理であり、GitHubの保証や法的助言ではありません。

参考資料

• Control GitHub Actions cache access with cache-mode（GitHub Changelog・2026年9月10日）
• Workflow syntax for GitHub Actions（GitHub Docs）