GitHub Actionsの肥大化を防ぐCI/CD設計パターン：ワークフロー分割とキャッシュ最適化の実践ガイド

2026年4月2日

当ページのリンクには広告が含まれています。

IT女子アラ美

🚀 CI/CD設計スキルで年収を上げなさい！
DevOps経験を活かしたキャリアアップでハイクラス転職を実現しなさい
自分らしく働けるエンジニア転職を目指すなら【strategy career】

この記事の結論

GitHub Actionsの肥大化はワークフロー分割・Reusable Workflows・キャッシュ最適化の3つで防げます。ビルド時間を50%短縮し、YAMLファイルの行数を1/3に削減した事例とともに設計パターンを解説します。

お疲れ様です！IT業界で働くアライグマです！

「GitHub Actionsのワークフローが500行を超えて、もう誰もメンテできない」「CIが30分かかるせいで、PRのマージが渋滞している」。こうした悩みを抱えているチームは多いのではないでしょうか。

GitHub Actionsは手軽にCI/CDを構築できる反面、無計画に機能を追加すると急速に肥大化します。本記事では、ワークフローの肥大化を防ぎ、保守性と実行速度を両立する設計パターンを解説します。

GitHub Actionsが肥大化する3つの原因

IT女子アラ美

💡 CI/CDの設計を独学で消耗してるの？体系的に学びなさい！
DevOps・インフラスキルを個人レッスンで習得できるわよ
資格と仕事に強い！個人レッスンのプログラミングスクール【Winスクール】

GitHub Actionsの肥大化は、ほとんどの場合以下の3つのパターンに集約されます。

原因1：1つのワークフローに全てを詰め込む

リント → テスト → ビルド → デプロイ → 通知を1つの .github/workflows/ci.yml に書くと、あっという間に300行を超えます。変更の影響範囲が把握できず、「触ると壊れそうだから誰も手を出さない」状態になります。

原因2：コピペの繰り返し

複数のワークフローで同じステップ（Nodeセットアップ、キャッシュ設定、Slack通知など）をコピペしていると、変更時に全ファイルを修正する必要があります。修正漏れがCI障害の原因になります。

原因3：キャッシュ未活用

npm install や pip install を毎回フルインストールしていると、依存関係の数に比例してビルド時間が伸びます。キャッシュを使えば数分の処理が数秒に短縮できます。

GitHub Actionsの基本的なCI/CD構成についてはGitHub Actions CI/CD自動化ガイドで解説しています。

IT女子アラ美

500行のYAML、見た瞬間に閉じたくなるよね…。「これ誰が書いたの？」って聞いても全員が目をそらす。

ITアライグマ

あるあるですね。「最初は30行だった」はずなのに、気づいたら500行になっている。CIのスパゲッティ化です。

設計パターン1：ワークフロー分割とReusable Workflows

肥大化を防ぐ最も効果的な方法は、ワークフローを責務ごとに分割することです。

分割の基本方針

lint.yml：コードスタイルチェック（ESLint, Ruff, etc.）
test.yml：ユニットテスト + インテグレーションテスト
build.yml：ビルド + アーティファクト生成
deploy.yml：デプロイ（main branch のみ）

Reusable Workflowsで共通処理を1箇所に

GitHub ActionsのReusable Workflowsを使えば、共通のステップを1つのファイルに集約し、他のワークフローから呼び出せます。

# .github/workflows/reusable-node-setup.yml
name: Node.js Setup
on:
  workflow_call:
    inputs:
      node-version:
        required: false
        type: string
        default: '20'

jobs:
  setup:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}
          cache: 'npm'
      - run: npm ci

これを各ワークフローから uses: ./.github/workflows/reusable-node-setup.yml で呼び出します。Node.jsのバージョン変更が1箇所で済み、コピペ地獄から解放されます。

Git運用の設計についてはソロ開発者のGitワークフローも参考にしてください。

IT女子アラ美

Reusable Workflows、名前は知ってたけど使ったことなかった。コピペ地獄の解決策がこれだったのね。

ITアライグマ

導入コストはほぼゼロです。既存のワークフローから共通部分を切り出すだけで始められますよ。

設計パターン2：キャッシュ戦略とビルド高速化

ビルド時間の短縮は、開発者体験（DX）に直結します。

依存関係のキャッシュ

actions/cache を使って、node_modules や .venv をキャッシュします。

- uses: actions/cache@v4
  with:
    path: ~/.cache/pip
    key: ${{ runner.os }}-pip-${{ hashFiles('requirements.txt') }}
    restore-keys: |
      ${{ runner.os }}-pip-

変更ファイルに基づく条件実行

paths フィルターを使って、関連ファイルが変更された場合のみワークフローを実行します。

on:
  push:
    paths:
      - 'src/**'
      - 'tests/**'
      - 'package.json'

ドキュメントの修正やREADMEの更新でCIが走らなくなり、不要なビルドを80%削減できます。

開発環境の最適化についてはuvでPythonパッケージ管理を高速化する方法も参考になります。

IT女子アラ美

READMEの修正でCIが走るの、無駄だと分かってても放置してた。paths設定、今日やるわ。

ITアライグマ

設定2行で済む改善です。月間のビルド時間が大幅に削減されて、コスト削減にもなりますよ。

ケーススタディ：ビルド時間を50%短縮した改善事例

IT女子アラ美

💡 DevOpsスキルがあるならフリーランスで稼ぎなさい！
CI/CD設計の経験があれば月収80万以上の案件が狙えるわよ
ITフリーランスエンジニアの案件探しなら【techadapt】

ここでは、井上さん（仮名・31歳・DevOpsエンジニア・経験6年）のチームがGitHub Actionsを最適化した事例を紹介します。

状況（Before）

ワークフロー構成：1つの ci.yml に全処理を記述（約450行）
ビルド時間：平均28分（リント→テスト→ビルド→デプロイを直列実行）
PRマージ待ち：CIの完了待ちで平均40分のアイドルタイムが発生
心境：「CIが遅すぎて、PR出した後にコーヒー2杯飲む時間がある」

行動（Action）

ワークフロー分割：450行の ci.yml を lint.yml / test.yml / build.yml / deploy.yml の4ファイルに分割。各ファイルは80〜120行に
並列実行：lint と test を並列実行するように変更。従来は直列で15分かかっていた工程が8分に
キャッシュ導入：npm ci のキャッシュで、依存関係インストールを5分→30秒に短縮
pathsフィルター：docs/ や README の変更では CI を実行しないように設定。月間の不要ビルドを35%削減
Reusable Workflows：Node.jsセットアップ、Slack通知、AWS認証の3つの共通処理を切り出し

結果（After）

ビルド時間：28分 → 14分（50%短縮）
YAML行数：450行 → 合計320行（4ファイル合計。共通処理は別管理）
月間ビルド数：800回 → 520回（pathsフィルターで35%削減）
メンテナンス性：「変更が怖くない」状態になり、改善サイクルが回り始めた

井上さんは振り返ります。「ワークフロー分割と並列実行を先にやったのが正解だった。キャッシュだけだと効果は限定的で、構造の改善が一番効いた」。

GitHub連携の高度な活用についてはGitHub Copilotのチーム生産性ガバナンスも参考にしてください。

IT女子アラ美

CIのせいで「コーヒー2杯分」のアイドルタイムがあったの笑える。でもうちも同じ状況だわ…。

ITアライグマ

CIの待ち時間は「見えないコスト」です。エンジニアの集中力が切れるのが一番の損失ですね。

さらなる実践・活用に向けて

GitHub Actionsの最適化を進めたら、次のステップとして以下を検討してみてください。

GitHub Actions以外の選択肢

プロジェクトの規模やセキュリティ要件によっては、CircleCI（並列実行が強力）やGitLab CI（オンプレ対応）、Dagger（ローカルで再現可能なCI）も検討対象です。

セルフホストランナーの活用

大規模プロジェクトでは、GitHub提供のランナーよりもセルフホストランナーの方がコスト効率が良い場合があります。特にGPUやカスタムハードウェアが必要なビルドでは必須です。

DevOpsスキルを活かしたキャリア設計についてはフリーランスエージェント5社比較も参考にしてください。CI/CD設計の経験はフリーランス市場でも高く評価されます。

IT女子アラ美

セルフホストランナーはコスト削減になるのね。でも管理コストとのトレードオフがありそう。

ITアライグマ

月間のビルド時間が100時間を超えたら検討する価値があります。それまではGitHub提供ランナーで十分ですよ。

よくある質問

ワークフローを分割するとジョブ間のデータ共有はどうしますか？

actions/upload-artifact と actions/download-artifact を使えば、ジョブ間でビルド成果物やテスト結果を共有できます。アーティファクトのサイズ上限は500MBです。

Reusable Workflowsと Composite Actionsの違いは？

Reusable Workflowsはワークフロー全体を再利用する仕組みで、Composite Actionsはステップ単位で再利用する仕組みです。大きな処理の共通化にはReusable、小さなユーティリティにはCompositeが適しています。

GitHub Actionsの実行時間の上限は？

1ジョブあたり最大6時間、1ワークフローあたり最大35日です。Freeプランでは月間2,000分の実行時間制限があります。Proプランは3,000分、Teamプランは3,000分です。

自分のスキルを活かしてフリーランスとして独立したい方は、以下の5社を比較して最適なエージェントを見つけましょう。

比較項目	techadapt	Midworks	フリーランスキャリア	フリーランスボード	IT求人ナビ
単価帯	月60〜120万円高単価特化	月50〜90万円中〜高単価	月70〜100万円高単価エンド直	月40〜150万円30万件横断検索	AI診断適正単価を自動提案
マージン	◎10〜20%公開	◎10〜15%公開	◯公開（案件個別）	—検索サイト	◯案件ごと
保障・福利厚生	限定的案件品質で勝負	正社員並み社保・交通費・研修	基本的福利厚生あり	—スカウト機能あり	相談サポートチャット・オンライン
対応エリア	首都圏東京・神奈川中心	首都圏+関西大阪・名古屋	全国（リモート多）地方でもOK	全国対応リモート・週3可	全国対応リモートあり
おすすめ度	S経験3年以上	S独立初期	Aリモート派	A相場把握に	B+初心者向け
公式サイト	案件を探す	案件を探す	案件を探す	案件を検索	AI診断する