レッスン7：GitHub Actions と Pages——自動化と公開

このレッスンで学ぶこと

• GitHub Actions の概念（CI/CD）を理解する
• 基本的なワークフローファイルの構造を読める
• 自動テストと自動デプロイの初歩を整理する
• GitHub Pages で静的サイトを公開する手順を持つ
• 2026 年 6 月時点の AI 連携（Copilot・Claude Code・Cursor 等）の動向を把握する
• 自動化を業務に組み込む発想を持つ

---

前のレッスンでは、Issue と GitHub Projects でタスクとコードを結ぶ進捗管理を扱いました。今回のレッスンでは、視点を「人がやるべきことを自動化する」に移して、GitHub Actions と Pages を扱います。「コミット → 自動テスト → 自動デプロイ」「main にマージ → 自動公開」といった現代の標準ワークフローの入口に立つレッスンです。

CI/CD と GitHub Actions

CI/CD とは

CI/CD は、

• CI（Continuous Integration、継続的インテグレーション）：コードの変更を自動でテスト・統合する仕組み
• CD（Continuous Delivery／Continuous Deployment、継続的デリバリー／継続的デプロイ）：テストを通過したコードを自動で本番環境に届ける仕組み

の総称です。「コミットしたら自動で全部やってくれる」の理想形を実現します。

GitHub Actions とは

GitHub Actions は、GitHub が提供する CI/CD プラットフォームです。2019 年に提供開始、2026 年 6 月時点では CI/CD の業界標準の 1 つになっています。

• リポジトリ内の YAML ファイルでワークフローを定義
• 「push されたら」「PR が作られたら」「定刻になったら」などのイベントで起動
• ビルド・テスト・デプロイ・通知などを自動実行
• 無料アカウントでも一定の実行時間が無料

競合と業界状況

• GitHub Actions：GitHub の標準、シンプル、初心者にも扱いやすい
• GitLab CI/CD：GitLab の標準
• CircleCI、Jenkins、Travis CI：歴史のある CI/CD ツール
• AWS CodePipeline、Azure DevOps：クラウドベンダーのソリューション

業務でどれを選ぶかは、組織のクラウド戦略やリポジトリホスティングの選択に依存します。GitHub を使う前提なら、GitHub Actions が自然な選択です。

💡 ポイント CI/CD は「あったほうがいい」ではなく「現代の標準」です。最初は最小構成（自動テストだけ）から始めて、徐々に拡張するのが現実的です。

ワークフローファイル

GitHub Actions のワークフローは、リポジトリの .github/workflows/ フォルダに置く YAML ファイルで定義します。

最小のワークフロー例

.github/workflows/hello.yml：

name: Hello World

on:
  push:
    branches:
      - main

jobs:
  greeting:
    runs-on: ubuntu-latest
    steps:
      - name: Print greeting
        run: echo "Hello, GitHub Actions!"

これは、

• main ブランチに push されたとき
• Ubuntu の仮想マシンで
• 「Hello, GitHub Actions!」と出力

する最小のワークフローです。

ワークフローの構成要素

要素	役割
name	ワークフローの表示名
on	起動条件（push、pull_request、schedule など）
jobs	実行する仕事の集合
runs-on	実行環境（ubuntu-latest、windows-latest、macos-latest）
steps	実行するステップ
uses	既製のアクションを使う
run	コマンドを直接実行

既製のアクション（Actions）

GitHub Marketplace に、コミュニティが作った既製のアクションが多数公開されています。

例：

• actions/checkout@v4 ：リポジトリをチェックアウト
• actions/setup-node@v4 ：Node.js をセットアップ
• actions/setup-python@v5 ：Python をセットアップ
• github/super-linter@v6 ：複数言語のリンター実行

これらを uses で取り込むと、自分でゼロから書く必要がなくなります。

📝 補足 アクションは @v4 のようなバージョンタグを指定するのが標準です。@main のように指定すると、後から変わって動作が壊れるリスクがあります。

自動テストの初歩

CI の代表的な用途が、PR や push のたびに自動テストを走らせる仕組みです。

例：Node.js プロジェクトのテスト

.github/workflows/test.yml：

name: Test

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

これで、main への push、または main への PR があるたびに、Node.js 20 系の環境で npm install と npm test が自動実行されます。テストが落ちたら PR がマージできない、という運用も可能です。

例：Markdown のリンク切れチェック

ドキュメントリポジトリで、リンク切れを自動チェックするワークフローも作れます。

name: Markdown Link Check

on:
  pull_request:
    branches: [main]

jobs:
  check-links:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: gaurav-nelson/github-action-markdown-link-check@v1

これだけで、PR のたびに Markdown ファイルのリンクが全部チェックされます。

💡 ポイント 自動テストはエンジニアだけの専売特許ではありません。Markdown のリンク切れ、画像の最適化、文書のスペルチェック、HTML の構文チェック——いろいろなチェックが GitHub Actions で自動化できます。

自動デプロイの初歩

CD の代表的な用途が、main にマージされたら自動でサイトを公開・更新する仕組みです。

GitHub Pages へのデプロイ例

name: Deploy to GitHub Pages

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pages: write
      id-token: write
    steps:
      - uses: actions/checkout@v4

      - name: Setup Pages
        uses: actions/configure-pages@v5

      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: './public'

      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

このワークフローは、main への push があるたびに、./public フォルダの中身を GitHub Pages にデプロイします。

ほかのクラウドへのデプロイ

• AWS S3、Cloudflare Pages、Vercel、Netlify などへのデプロイも、それぞれの公式アクションで簡単に組めます
• 認証情報は GitHub の Secrets（後述）に登録して使う

Secrets——機密情報の安全な扱い

ワークフローで API キーや認証情報を使うときは、GITHUB_SECRET のような「Secrets」を使います。

• リポジトリの Settings → Secrets and variables → Actions
• 「New repository secret」で名前と値を登録
• ワークフローで ${{ secrets.MY_SECRET }} として参照

ワークフローファイルに直接書かないことで、リポジトリが公開されても秘密情報が漏れません。

⚠️ 注意 Secrets はワークフロー内では参照できますが、出力（ログ）には自動でマスクされます。echo で意図せず表示しようとしても、ログには *** と表示されます。これは GitHub の保護機能です。

GitHub Pages

GitHub Pages は、GitHub リポジトリの中身をそのまま静的ウェブサイトとして公開できる機能です。無料で使えます。

公開できるもの

• HTML/CSS/JavaScript の静的サイト
• Jekyll で生成された静的サイト
• Next.js／Astro／Hugo などの静的サイトジェネレータの出力
• ドキュメントサイト（MkDocs、Docusaurus など）
• 個人ポートフォリオ

設定手順（最も簡単な方法）

1. リポジトリの Settings → Pages
2. Source を選択（Deploy from a branch または GitHub Actions）
3. ブランチとフォルダを選択（多くは main ブランチの / または /docs）
4. 数分後、https://ユーザー名.github.io/リポジトリ名/ で公開

カスタムドメイン

Settings → Pages → Custom domain で、独自ドメインを設定できます。HTTPS 化も自動で行われます（Let's Encrypt 経由）。

Pages の用途例

• 自分のポートフォリオサイト
• HTML・CSS の練習サイト
• 学習記録のブログ
• OSS プロジェクトのドキュメント
• 教材・社内ドキュメントの公開

📝 補足 Pages は無料で十分強力ですが、サーバーサイドの処理（PHP、データベース、API バックエンドなど）は動きません。動的処理が必要なら別のホスティング（Vercel、Netlify、AWS など）が必要です。

2026 年 6 月時点の AI 連携の動向

GitHub Actions と並んで、2026 年 6 月時点で大きく動いているのが「AI 駆動開発」との連携です。

GitHub Copilot

GitHub Copilot は、コードのオートコンプリート・チャットを提供する AI 機能です。2021 年プレビュー、2022 年一般提供、その後の更新でコードレビュー支援、PR 説明文の自動生成、Actions ワークフロー作成支援などにも広がりました。

2026 年 6 月時点では、

• VS Code、JetBrains、Neovim などの主要エディタに対応
• GitHub の Web UI 上でも利用可能（コードリーディング、レビュー）
• PR レビューでの「Copilot がレビューする」機能

が標準的に使えます。

Claude Code・Cursor・Devin など

GitHub Copilot 以外にも、Claude Code（Anthropic）、Cursor、Devin、Continue、Aider などの AI 駆動開発ツールが普及しています。

• ローカルエディタや専用環境で動く
• リポジトリ全体を読み込んでコード変更を提案
• 自動でブランチ・PR を作成する機能を持つものも
• それぞれ得意分野や料金体系が異なる

Actions と AI の組み合わせ

• AI が生成したコードを CI で自動検証
• AI 生成 PR のレビュー支援
• ドキュメント自動生成・更新

「AI がコードを書き、人間がレビューし、CI が検証する」というスタイルが、2026 年 6 月時点の標準になりつつあります。

注意点

• AI が生成したコードはハルシネーション（架空の関数呼び出しなど）を含む可能性があり、必ず人間がレビュー
• 機密情報（API キー、個人情報、社内コード）の扱いは AI ツールのプライバシーポリシーを確認
• AI で「楽になる」だけでなく、「自分で説明できる」を保つ姿勢が重要

💡 ポイント AI 駆動開発は半年単位で動向が変わります。「特定ツールを覚える」より「AI と協業する考え方」を身につけるのが現実的です。

業務で自動化を組み込む発想

GitHub Actions と Pages の使いどころを、業務に組み込む観点で整理します。

個人レベル

• ポートフォリオサイトを Pages で公開
• 学習ログを Markdown で書き、Actions でリンク切れチェック
• AI 連携（Copilot 等）を日常使い

小規模チーム

• PR で自動テスト（最低限のチェック）
• main マージで自動デプロイ（Pages か Vercel・Netlify など）
• Issue・PR テンプレートで品質を揃える

中規模・大規模組織

• 多段階の CI（ユニットテスト、結合テスト、E2E テスト、セキュリティスキャン）
• 環境ごとのデプロイ（staging → production）
• リリースノートの自動生成
• メトリクスの自動収集
• AI 駆動開発の組織標準化

「最小から始める」発想

業務に CI/CD を導入するとき、最初から完璧を目指さないことが重要です。

• まず PR で自動テストを 1 つだけ
• 慣れたら追加
• 必要に応じて拡張

「動く CI が 1 つあること」が「壮大な計画があるが何も動いていない」より、はるかに価値があります。

講師の現場メモ：「自動テストを 1 つ入れただけで品質が変わった日」

私（青木）が独立後、ある中堅 Web 制作会社で支援した話です。当時のチームは、サイト納品時のチェックを手動で行っていました。

• HTML のバリデーション：人間が目視確認
• リンク切れチェック：人間がクリック確認
• 画像の表示確認：人間がブラウザで確認

10 サイトを納品すると、最低 1〜2 件は「リンクが切れていた」「画像が表示されていない」事故が起きていました。

私はリーダーに「GitHub Actions で、PR ごとに Markdown のリンク切れチェックを自動化しませんか」と提案しました。「自動化って難しそう」と最初は懐疑的でしたが、私が次のワークフローを書きました。

name: Link Check

on:
  pull_request:
    branches: [main]

jobs:
  check-links:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: gaurav-nelson/github-action-markdown-link-check@v1

これだけです。15 行に満たないファイル 1 つを .github/workflows/ に置いて、main に push しました。

その日から、PR ごとに自動でリンク切れチェックが走るようになりました。リンク切れがあれば、PR に赤い × が付き、マージ前に気づけます。

3 か月後、リンク切れ事故はゼロになりました。チームメンバーは「自動化って 15 行で書けるんだ」と驚き、徐々に HTML バリデーション、画像最適化、SEO チェックなど、自動化の範囲を広げていきました。半年後には、納品前のチェックが「PR を見れば全部わかる」状態になりました。

そのときに痛感したのは、「自動化は壮大な計画から始まらない」ということです。15 行のワークフロー 1 つで、品質が変わります。本コースで Actions を 1 レッスン分扱うのは、皆さんにも「まず 1 つ自動化してみる」感覚を持ち帰っていただきたいからです。

最初の自動化は、必ずあなたの業務を楽にします。

まとめ

このレッスンでは、以下のことを学びました。

• CI（継続的インテグレーション）：コードの変更を自動でテスト・統合
• CD（継続的デリバリー／デプロイ）：テスト通過コードを自動で本番環境に届ける
• GitHub Actions は GitHub の CI/CD プラットフォーム（2019 年提供開始）
• ワークフローは .github/workflows/ の YAML ファイルで定義
• 構成要素：name／on（起動条件）／jobs／runs-on／steps／uses／run
• 既製のアクション：actions/checkout、actions/setup-node などを Marketplace から
• 自動テスト例：push と PR で npm test、Markdown のリンク切れチェック
• 自動デプロイ例：main マージで GitHub Pages へ自動公開、AWS／Vercel／Netlify などへも
• Secrets：機密情報を安全に扱う仕組み、ワークフローに直接書かない
• GitHub Pages：リポジトリの中身を静的ウェブサイトとして無料公開、カスタムドメインも可能
• 2026 年 6 月時点：GitHub Copilot、Claude Code、Cursor、Devin などの AI 駆動開発ツールが標準、「AI が書き、人間がレビューし、CI が検証する」スタイル
• 業務での導入：個人 → 小規模 → 中大規模で段階的に。「動く CI が 1 つあること」が壮大な計画より価値が高い

次のレッスンでは、ブランチ戦略・コミットメッセージ・秘密情報・OSS コミュニティ・修了後の方向を扱います。

---

確認クイズ

このレッスンの理解度をチェックしましょう。

回答する もう一度挑戦