GitHub Actionsとは？CI/CDの仕組み・基本ワークフロー・案件単価をフリーランス視点で解説

GitHub Actionsとは

一言でいうとどんなサービスか

GitHub Actionsは、GitHub上のイベントをきっかけにビルド・テスト・デプロイを自動実行できるCI/CD（継続的インテグレーション／継続的デリバリー）機能です。リポジトリの「.github/workflows/」配下にYAMLファイルを置くと、GitHubがその内容を読み取り、コミットやプルリクエストなどのイベントをトリガーにジョブを動かします。

たとえば「mainブランチにマージされたら自動でテストを回し、本番環境にデプロイする」「pull_requestが来たらLintを走らせる」といった処理を、サーバを別途用意せずに組めます。

CI/CDとの関係

CI/CDは、コードの変更を頻繁に統合（CI）し、自動でテスト・デプロイまでつなげる（CD）開発スタイルを指します。GitHub Actionsはこの自動化を実行する基盤の1つです。Gitのソースコード管理と一体になっているため、リポジトリの状態を直接ハンドリングしやすい点が他のCI/CDサービスとの違いになりやすい部分です。

他のCI/CDツールとの位置づけ

CI/CDの世界には、Jenkins・CircleCI・GitLab CI/CD・AWS CodePipelineなど複数の選択肢があります。GitHub Actionsは「GitHubと密結合のSaaS型CI/CD」というカテゴリに入り、GitHubを使う開発体制では採用されるケースが目立ちます。GitHubが毎年公開するOctoverseなどの公開レポートでもGitHub Actionsの利用拡大が示されており、CI/CDの主要候補の1つになっています。

公式ドキュメントはGitHub Actions Documentationにまとまっています。本記事は執筆時点の仕様をもとに記載しており、バージョン名やUIは更新される可能性があるため、最新仕様は公式リリースノートで確認してください。

ミニFAQ

• Q: GitHub Actionsは無料で使えますか？

• A: PublicリポジトリはGitHub-hosted ランナーを無料で使える範囲が広く、Privateリポジトリはプランごとの無料利用枠を超えると従量課金になります。Self-hosted ランナーかGitHub-hosted ランナーかで費用感が変わるため、最新の数値は後述の料金章と公式料金ページで確認してください。

GitHub Actionsでできること

ビルド・テストの自動化

最も基本的な用途は、コードの変更ごとに自動でビルドとテストを実行することです。プルリクエストでテストが落ちれば赤バッジが付き、レビュー前に問題を検知できます。NodeやPython、Java、Goなど主要言語向けの公式アクションが用意されており、最低限のYAMLで動かせます。

デプロイ自動化

ステージング・本番環境へのデプロイにも使われます。AWS・GCP・Azure・Vercel・各種PaaSに対する公式または準公式のアクションがあり、シークレットを使った認証情報の受け渡しもサポートされています。手元のデプロイスクリプトを呼ぶ「シェル実行型」の運用と組み合わせるケースも多いです。

定期実行・運用自動化

cron式でスケジュール実行できるため、夜間バッチや定期的なデータ取得、リポジトリのメンテナンス処理など、CI/CDの枠を超えた運用自動化のハブとして使われることもあります。GitHubのIssueやPRに対するラベル付与・自動コメントもよく見るパターンです。

主要な概念とコンポーネント

GitHub Actionsを理解するには、5つの登場人物の関係をおさえておくのがおすすめです。

ワークフロー

「.github/workflows/」配下に置いたYAMLが1ファイル＝1ワークフローです。「CI用」「デプロイ用」「定期処理用」のように分割するのが一般的です。

ジョブとステップ

ジョブは1台のランナー上で実行される作業のまとまり、ステップはその中の個々の処理です。ジョブを並列実行してテストを高速化したり、依存関係（needs）を指定して順序を制御したりできます。

アクション

「アクション」は再利用可能な処理部品で、公式・サードパーティ含めて多数あります。たとえばリポジトリのチェックアウトには「actions/checkout」、Node.js環境の用意には「actions/setup-node」を使うのが定番です。利用時はバージョンを明示し、信頼できる発行元を選ぶことが推奨されています。

ランナー（GitHub-hosted / Self-hosted）

• GitHub-hosted ランナー: GitHubが提供する仮想マシン。Linux・Windows・macOSが選べます。標準的なツールがプリインストールされており、すぐに動かせます

• Self-hosted ランナー: 自社や自分の管理するマシンで動かす方式。社内ネットワークやGPU環境を使いたい場合に有効ですが、運用責任は利用者側になります

ミニFAQ

• Q: アクションとワークフローは何が違いますか？

• A: ワークフローは「自動処理全体の設計図」、アクションは「その中で呼び出す部品」です。設計図の中で「checkoutアクションを呼ぶ」「自前のシェルを実行する」といった具合に組み合わせます。

基本ワークフローの書き方

YAMLファイルの構成

ワークフローは大まかに、name・on（トリガー）・jobs（実行する処理）の3要素で構成されます。たとえば「pushでテストを動かす」最小構成なら、on: pushでトリガーを指定 → jobs配下に1つジョブを定義 → runs-on: ubuntu-latest を指定 → stepsでcheckoutとテスト実行を順に並べる、の4ステップで成立します。最小構成のイメージは次のとおりです。

トリガー（on）の指定

代表的なトリガーには次のようなものがあります。

• push: 指定ブランチへのコミットでワークフローを起動する

• pull_request: PRが開かれた、または更新されたタイミングで起動する

• schedule: cron式で定期実行する

• workflow_dispatch: GitHubのUIから手動でキックする

• release: リリース作成時に起動する

環境変数とシークレット

APIキー・トークン・パスワードなどはYAMLに直書きせず、リポジトリのSecretsに登録して「secrets.XXX」のように参照します。平文の機密情報はGitHub側のシークレットスキャンで検知・警告される場合もありますが、検知に依存せず直書きしない運用を徹底するのが前提です。あわせて「Secretsの命名規約」「不要なログ出力の禁止」を運用ルールで決めておくと安全度が上がります。

公式のセキュリティ強化に関するガイドでは、サードパーティ製アクションはコミットSHAで固定する運用が推奨されています。

料金プラン

無料枠と従量課金

GitHub Actionsの料金は「実行時間（分）×ランナー種別の係数」で決まる従量課金が基本で、プラン（Free・Pro・Team・Enterprise）ごとに含まれる無料分が異なります。

最新の数値はGitHubの公式料金ページで必ず確認してください。WindowsやmacOSのランナーはLinuxより係数が大きい傾向があるため、CI実行時間が長い案件ではOS選定が費用に直結します。

費用が膨らみやすいパターン

• 大規模なテストスイートを全コミットで実行している

• macOSランナーを大量に使ってiOSビルドを回している

• 1日の何度も走るスケジュール実行ジョブが残ったまま放置されている

• マトリクスビルドで多バージョンを同時に走らせている

費用が気になる場合は、ジョブの並列度・キャッシュの活用・Self-hosted ランナーへの切り替えなどで調整するのが一般的です。

Jenkins・CircleCI・GitLab CIとの違い

CI/CDツール選定でよく比較される代表的な選択肢を、フリーランス案件で見かけやすい観点で整理します。

※ 学習コストや案件での見かけやすさは、GitHub中心のWeb開発案件を想定した相対比較です。組織のスタンダードや既存資産によって印象は変わります。

Jenkinsとの大きな違いは、「サーバ構築・プラグイン管理」のような運用作業が要らない点です。一方Jenkinsには、長期運用された巨大なパイプラインを動かしている既存資産が多く、保守・改修案件で必要になることがあります。新規開発はGitHub Actions、既存保守はJenkinsという住み分けをしている現場も見かけます。

フリーランスエンジニアにとっての案件動向と単価

ここでの数字は主要フリーランスエージェントの公開案件・求人情報を参考にした目安で、業界別・スキルセットによって大きく変動します。具体の金額はフリコンを含むエージェントとの面談で個別に確認してください。

案件の見え方

GitHub Actions単独を前面に出した募集は相対的に少なく、SRE・DevOps・クラウドエンジニア案件の要件に「CI/CD構築・改善」が含まれる形が多い傾向です。次のようなパターンで募集を見かけます。

• 既存のJenkinsからGitHub Actionsへの移行支援

• マイクロサービス向けの新規CI/CDパイプライン設計

• Terraform・Ansibleを併用したインフラ自動化

• セキュリティ要件（SAST・DAST組み込み）対応

• リリース自動化・ステージング自動化の整備

単価のレンジ感（目安）

ここで挙げる金額は、主要フリーランスエージェントの公開案件（週5日・首都圏／フルリモート含む業務委託）の傾向から見た目安です。集計時期や媒体によって幅が出るため、実際の金額はフリコンを含むエージェントとの面談で個別に確認してください。

公開案件ベースで観測される傾向としては、アプリ実装中心の案件と比べると、インフラ設計や運用改善を含むSRE・DevOps案件は高めに設定される傾向があります。週5日・業務委託の月額相場は、SRE・DevOps系では70〜100万円前後の募集が多く、AWS・Kubernetesを含む上流寄り案件（要件整理・設計フェーズから入る案件、複数チーム横断のプラットフォーム改善案件など）では100万円超の事例も見られます。

ただし「GitHub Actionsが書ける」だけで高単価につながるわけではない点には注意が必要です。クラウド構築・コンテナ運用・監視・セキュリティといった周辺領域とのセットで評価されます。年収・単価の全体像はフリーランスエンジニアの単価相場も合わせて確認するとイメージしやすくなります。

セットで評価されやすいスキル

CI/CDの実装力を強くアピールしたいなら、次のようなスキルをセットで持っておくと案件選びの幅が広がります。

• Docker・Kubernetesによるコンテナ運用

• Terraform・AnsibleなどIaC（Infrastructure as Code）の実装経験

• AWS・GCP・Azureいずれかのクラウド運用経験

• 観測性（Datadog・New Relic・CloudWatchなど）の設計

• セキュリティ（脆弱性スキャン・依存ライブラリ管理）の組み込み

関連職種としては、SRE・DevOpsエンジニア・クラウドエンジニアあたりが近く、これらの職種記事も参考になります。

ミニFAQ

• Q: GitHub Actionsを学ぶだけでフリーランス案件は取れますか？

• A: 単独で案件になるケースは限定的です。SRE・DevOps・クラウドの中でCI/CD設計を担当する形がメインなので、Docker・Kubernetes・Terraform・主要クラウドのいずれかと組み合わせて経験を積むのが現実的です。

学習ロードマップ

「これから触ってみたい」「実務で書けるレベルまで持っていきたい」エンジニア向けに、段階別のロードマップを整理します。

ステップ1: 手元の小さなリポジトリで動かす

PythonでもNode.jsでもよいので、自分の練習リポジトリに最小のCIを組み込みます。具体的には次の3つに絞ると着手しやすいです。

• pushでテストを動かすワークフローを書く

• pull_requestでLintを走らせる

• スケジュールで定期処理を回す

ステップ2: 公式アクションとマーケットプレイスを使い分ける

「actions/checkout」や「actions/setup-*」系の公式アクションに加え、デプロイ系（AWS・Vercelなど）のアクションを実際に試します。アクションを呼ぶときはバージョン固定・信頼できる発行元の選択を意識しておきます。

ステップ3: 業務寄りの応用に踏み込む

ここまで来たら、業務で使えるレベルに引き上げる段階です。

• Secretsを使った安全な認証情報受け渡し

• マトリクスビルド・並列ジョブによる高速化

• キャッシュ活用（依存ライブラリ・ビルド成果物）

• 監視・通知（Slack通知・失敗時のリトライ）

• セキュリティガイドに沿った権限最小化・OIDC連携

ステップ4: 他CI/CDツールとの比較ができるようにする

実務では「Jenkinsから移したい」「GitLab CIで動いているものをGitHub Actionsへ寄せたい」といった要件が出てきます。Jenkinsfileの読み方、CircleCIの設定構造、GitLab CIの.gitlab-ci.ymlを一度は触っておくと、移行案件で強くなります。

よくある失敗と対策

実務でGitHub Actionsを使い始めるときによく見かけるつまずきポイントを整理します。

失敗1: 全コミットでフルテストを回し費用が膨らむ

軽いLintから重いE2Eテストまで全部を毎回回すと、Privateリポジトリでは無料枠を超過しやすくなります。対策は、PRサイズや変更ファイルに応じてジョブを分割する、夜間バッチに重いテストを寄せる、キャッシュを利用するなどです。

失敗2: アクションのバージョンを @main で固定してしまう

「@main」のような可動ブランチで指定していると、アクション側の破壊的変更でCIが突然落ちる可能性があります。タグやコミットSHAで固定し、Dependabotで管理する運用が推奨されています。

失敗3: シークレットをログに出してしまう

デバッグ目的で環境変数をechoしてしまうと、シークレットがログに残るリスクがあります。GitHub側でマスキングはされますが、組み合わせ次第で漏れるケースがあるため、本番ワークフローでのデバッグ出力は最小限にとどめます。

失敗4: 権限の付け過ぎ

ワークフローのデフォルト権限は、組織・リポジトリ側の設定やイベント種別に左右されます。意図しない広い権限がジョブに渡るケースを避けるため、permissionsキーを明示して最小権限の原則に寄せる運用が安全です。組織の管理画面で「Workflow permissions」を確認しておくと、想定外の権限付与を防ぎやすくなります。

失敗5: Self-hosted ランナーの管理を疎かにする

Self-hosted ランナーを使うと費用は抑えられますが、OS・ランナー本体・依存ツールのアップデート、信頼境界の管理が必要になります。Publicリポジトリに対しては基本的に使わないなど、運用ルールを決めておきます。

実践チェックリスト

GitHub Actionsを本番運用するときに、最低限見ておきたい観点をまとめます。

• ワークフローはname・on・jobsの役割が読み取れる粒度で分割しているか

• アクションのバージョンはタグかコミットSHAで固定しているか

• Secretsの登録・参照ルールがチーム内で決まっているか

• permissionsキーを明示し、最小権限になっているか

• 重いジョブはキャッシュ・並列化・条件分岐で最適化しているか

• Self-hosted ランナーを使う場合、運用・更新ルールが決まっているか

• 失敗時の通知導線（Slack・メール等）が用意されているか

• 監査用にワークフローの実行履歴を一定期間保持しているか

まとめ

GitHub Actionsは、GitHubリポジトリと一体で動くCI/CDプラットフォームで、CI/CDの導入ハードルを大きく下げてくれます。フリーランスとして武器にするなら、CI/CD単独ではなくDocker・Kubernetes・Terraform・主要クラウドとの組み合わせで経験を積むのが近道です。

要点を整理すると次のようになります。

• GitHub Actionsはリポジトリ内のYAMLで自動処理を組むSaaS型CI/CDサービス

• ワークフロー・ジョブ・ステップ・アクション・ランナーの5要素を押さえると一気に理解しやすくなる

• 料金は無料枠＋従量課金で構成され、PublicとPrivate、ランナー種別で大きく差が出る

• Jenkins・CircleCI・GitLab CIなど他CI/CDツールとは、提供形態と運用責任の重さで比較できる

• フリーランス案件ではSRE・DevOps・クラウド領域の一部として募集されることが多く、組み合わせスキルで評価される

次のアクションとしては、まずpushでテストを動かす最小のCIを練習リポジトリで作り、慣れたらDocker・Terraform・主要クラウドと組み合わせる方向に広げていくのがおすすめです。案件面の相談は、フリコンを含むフリーランスエージェントに具体の経歴と希望条件を伝えて、CI/CD構築・改善が含まれる案件を紹介してもらうのが手早い進め方です。

参考リンク・関連記事

• GitHub Actions Documentation

• GitHub Actions セキュリティ強化ガイド

• GitHubの料金プラン

• SREとは？仕事内容・年収・必要スキルとDevOpsとの違いをエンジニア視点で解説

• DevOpsエンジニアとは？仕事内容・年収・必要スキル・なり方をわかりやすく解説

• クラウドエンジニアとは？仕事内容や必要なスキル、年収について解説

• Dockerとは？コンテナ技術の仕組み・できること・フリーランス案件の単価への影響を解説

• Kubernetesとは？仕組み・Dockerとの違い・フリーランス案件の単価をエンジニア視点で解説

• Terraformとは？IaCの仕組み・できること・フリーランス案件の単価をエンジニア視点で解説

• GitHub Copilotの使い方｜エンジニアの開発効率と案件単価への影響を解説

• 【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？