github-actions-efficiency

GitHub Actions の効率化

このスキルは、GitHub Actions の効率化に取り組む際の簡潔な入り口として使用します。リポジトリを調査して、無駄の原因を特定し、現在のタスクに必要な参考資料だけを読み込みます。

まだワークフローが存在しない場合は、references/actions.md を読み込み、以下の手順に進む前にベースラインを定めます。

シェルまたは gh CLI にアクセスできない場合： .github/workflows/ の内容と gh run list --limit 10 の出力をユーザーに貼り付けてもらいます。一部のファイルしか提供されていない場合は、「提供されたファイルのみを対象とした監査です。一部の分析は不完全な可能性があります。」と明記します。ファイルのみを使った回答は、次の文から始めます：「静的分析のみ（実際の実行では未確認）。」

このスキルを使用する場面

• ユーザーが GitHub Actions の実行時間、CI コスト、または無駄なワークフロー実行の削減を希望している場合。
• リポジトリに .github/workflows/ 内の既存ワークフローがある場合、または GitHub Actions の設定について明示的な質問がある場合。
• ユーザーがキャッシュ、並行実行、パスフィルター、マトリックスの縮小、ジョブの最適化、またはワークフロー固有の修正を依頼している場合。
• ユーザーが新しい GitHub Actions ワークフローや CI ベースラインを一から作成するための支援を必要としている場合。

必要なものだけを読み込む

• references/actions.md — 監査、ジョブの実行条件、マトリックスの縮小、実行時の検証、ワークフロー固有の修正。
• references/reporting.md — ユーザーが効率化の変更前後のレポートを求めている場合。
• references/patterns.md — インラインの監査コマンドだけでは不十分な場合に使用する、YAML の完全な例。

基本的なワークフロー

1. まず測定する

rg -n "on:|concurrency:|paths:|paths-ignore:|strategy:|matrix:|cache:" .github/workflows
gh run list --limit 10
run_id=$(gh run list --limit 1 --json databaseId --jq '.[0].databaseId')
gh run view "$run_id" --log-failed

次の点を確認します。依存関係キャッシュがない、concurrency によるキャンセルがない、トリガーの範囲が広すぎる、ワークフローの対象範囲が重複している、変更範囲に関係なくすべての変更でコストの高いジョブが実行される。

2. ガードレールを適用する

修正案を推奨する前に、以下のルールに照らしてそれぞれ確認します。

1. 必須の検証を隠さないこと — リリース、スキーマ、マイグレーション、共有ライブラリのチェックを削除する修正案は除外します。
2. 正当な理由なく並列性を下げないこと — ユーザーがレイテンシよりコストを優先し、かつ新しいクリティカルパスが元の 1.25 倍以内に収まる場合を除き、該当する修正案は除外します。
3. 文書化されたマトリックスの組み合わせのみを維持すること — バージョンまたはプラットフォームに関する明示的な要件がない組み合わせは除外します。
4. 書き戻しジョブにはオプトイン方式のトリガーを使うこと — 自動実行されるフォーマッターやボットのジョブは除外せずに指摘し、代わりにオプトイン方式のトリガーを推奨します。
5. リポジトリの変更と組織設定を分けること — リポジトリで編集可能な YAML と組織レベルまたは GitHub アカウントの設定を混在させる修正案は、別々の 2 つの推奨事項に分けます。

3. 優先度の高い修正を 3 つ選ぶ

以下の 6 つの候補から、手順 1 の監査証拠で裏付けられ、かつ手順 2 のすべてのガードレールを満たすものだけを残します。残った候補は、1 日あたりの推定 CI 時間削減量（1 回あたりの削減量 × 1 日あたりの実行回数）で順位付けします。両方の条件を満たす候補を、最大 3 つまで選択します。

1. ロックファイルに基づくキーを使って依存関係キャッシュを追加する
2. concurrency によるキャンセルを追加または修正する
3. ジョブを統合する前に、重複するワークフローの対象範囲をなくす
4. ワークフローまたはジョブのトリガー範囲を安全に狭める
5. リスクとイベントの種類に合わせてマトリックスの範囲を縮小する
6. クリティカルパス上の独立したジョブを並列化する

4. 検証する

• gh CLI にアクセスできる場合は、保護されていないブランチへのテスト用プッシュを実施し、パスによる実行制御と concurrency によるキャンセルを実際に検証します。
• 実際の検証ができない場合は、その旨を出力に明記します。
• YAML が正しく見えても、実際の動作が予想と異なる場合は、実際のバグとして扱います。

必須の出力

1. 無駄の原因 — 手順 1 で見つかった、コストまたはレイテンシへの影響が大きい要因
2. 修正案 — 優先度の高いものから 3 つ（または残った候補すべて）と、それを裏付ける監査証拠
3. 検証 — 実際に確認できたこと、ローカルでのみ確認したこと、残っているリスク
4. 影響 — 予想される削減量と測定された削減量。PR の実時間とランナーの合計実行時間は分けて記載する

参考資料

• references/actions.md
• references/reporting.md
• references/patterns.md
• references/review-rubric.md — 効率化作業の完了後にレビューする際に読み込んでください