変更要約: GH-200 第5章を新規作成（セキュリティのベストプラクティス＝スクリプトインジェクション緩和・GITHUB_TOKEN 最小権限/PAT対比・OIDC クラウド連携・SHA ピン留め/信頼できるアクション/利用ポリシー・アテステーション/provenance(SLSA)・環境承認ゲート、パフォーマンス/コスト最適化＝actions/cache・retention(REST API)・matrix サイズ/max-parallel・concurrency+cancel-in-progress・paths/branches フィルター・if 条件・ランナーサイズ）
5.2パフォーマンスとコストの最適化
キャッシュとアーティファクトの保持による効率化、REST API での保持ポリシー適用、そして並列度・matrix サイズ・concurrency・ランナー選択・条件分岐・パス/ブランチフィルターによるワークフローのスケーリングとコスト最適化の戦略を理解します。
GitHub Actions の利用は 実行時間（分） とストレージ（アーティファクト/キャッシュ）に応じて課金されます。GH-200 では、結果を犠牲にせずに 速く・安く 回す最適化が問われます。レバーは大きく「無駄を減らす（不要な実行/再ダウンロードを避ける）」と「並列と保持を調整する」の 2 つです。
5.2.1キャッシュと保持（retention）
依存の再取得を避ける キャッシュ（actions/cache） は、最も効果的な高速化手段です（第1章）。アーティファクトとログには 保持期間（retention） があり、長く保持するほどストレージ課金が増えます——既定値を見直し、upload 時の retention-days で短くするとコストを抑えられます。これらの 保持ポリシーは REST API からも適用・確認でき、組織全体で古いデータの自動削除を運用できます。キャッシュは無料枠/サイズ上限があり、古いキャッシュは自動的に追い出される点も押さえます。
5.2.2matrix サイズと並列度
matrix は便利ですが、組み合わせが増えるほど 実行分（コスト） が膨らみます。本当に必要な OS×バージョンだけに絞り、exclude で不要な組み合わせを削り、include で例外だけ足します。同時実行数は max-parallel で抑えてランナー枠とコストを調整します。失敗の切り分けが要らない通常の CI では fail-fast: true（既定）で早期に打ち切ると無駄な実行を避けられます。
5.2.3concurrency で重複実行を抑える
同じブランチ/PR に短時間で何度も push すると、古い実行が無駄に走り続けます。concurrency グループを設定し cancel-in-progress: true にすると、新しい実行が始まったときに 同じグループの進行中の実行を自動キャンセル でき、最新コミットだけを検証してコストを節約できます。デプロイのように直列化したい場合は cancel せずにキューイングする使い方もあります。
5.2.4フィルターと条件分岐で無駄を減らす
そもそも 動かす必要のない実行を起こさない のが最大の節約です。push/pull_request の paths/paths-ignore・branches/branches-ignore フィルターで「ドキュメントだけの変更では CI を回さない」などを実現します。ジョブ/ステップの if 条件で不要な処理をスキップし、重いジョブは 必要なときだけ 実行します。ランナーは、要件に合うサイズ（標準 vs larger）を選び、過剰なスペックを避けてコストを最適化します。
| 目的 | 手段 |
|---|---|
| 依存の再取得を避ける | actions/cache |
| 不要な実行を起こさない | paths/branches フィルター・if 条件 |
| 古い実行を止める | concurrency＋cancel-in-progress |
| matrix のコスト抑制 | exclude・max-parallel・必要最小限 |
| ストレージ課金抑制 | retention-days・保持ポリシー（REST API） |
頻出：
①最速の高速化＝actions/cache（依存の再取得回避）。
②concurrency＋cancel-in-progress で古い実行を自動キャンセル（最新だけ検証）。
③paths/branches フィルター・if 条件で不要な実行を起こさない。
④matrix は必要最小限＋exclude＋max-parallelでコスト抑制。
⑤ストレージは retention-days/保持ポリシー（REST API） で短縮。
⑥ランナーは要件に合うサイズを選び過剰スペックを避ける。
混同・注意：
①キャッシュ（高速化・再生成可）とアーティファクト（残す成果物）は別——キャッシュに長期保管を期待しない。
②concurrency の cancel-in-progress はデプロイには不向きな場合がある（途中キャンセルの副作用）——直列化はキューイングで。
③matrix を闇雲に増やすとコストが跳ね上がる。
④フィルターやif での過剰なスキップはカバレッジ低下を招く——バランスを取る。
⑤保持期間を短くしすぎると必要なログ/成果物が消える。
5.2.5この節のまとめ
- actions/cache で依存を高速化、retention-days/保持ポリシー（REST API）でストレージ課金を抑制
- concurrency＋cancel-in-progress で古い実行を自動キャンセルし最新だけ検証
- paths/branches フィルター・if 条件で不要な実行を起こさない、matrix は必要最小限＋exclude＋max-parallel
- ランナーは要件に合うサイズを選び過剰スペックを避ける（速さと結果のバランス）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 開発者が PR に短時間で何度も push するたびに古い CI 実行が走り続け、ランナー枠とコストを浪費しています。最も適切な対策はどれですか？
Q2. ドキュメント（*.md）だけの変更で重い CI（ビルド・テスト）が毎回走ってしまいます。最もシンプルな節約策はどれですか？
Q3. ビルドのたびに npm 依存を再ダウンロードして遅く、実行分も消費します。最も効果的な高速化はどれですか？
Q4. アーティファクトのストレージ課金が増えています。コストを抑える適切な方法はどれですか？
Q5. テスト対象の OS×バージョンの matrix が肥大化してコストが急増しました。結果を保ちつつコストを抑える方法はどれですか？
Q6. キャッシュとアーティファクトの違いとして正しいものはどれですか（最適化の観点）？