変更要約: 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（既定）で早期に打ち切ると無駄な実行を避けられます。