実例カタログ — 何ができる？（テスト・CodeQL・レビューBot・デプロイ・リリース…）
📖 このページのゴール：GitHub Actions で実際に何ができるのかを、実名つきのカタログでつかむ。大きく分けて「品質を守る（こわれてないか自動でチェック）」と「届ける（CD）（自動でデプロイ・リリース）」の2グループ。いま注目の自動化（CodeQL・レビューBot）もここで紹介します。 ← 目次・はじめにへもどる
ここまでで「on:（いつ） → jobs:（やること） → steps:（手順）」という形は読めるようになりました。このページは、その手順に何を載せられるのか——つまり「ベルトコンベアに流せる作業」のメニュー表です。🏭
ぜんぶ覚える必要はありません。「へえ、こんなことまで自動にできるんだ」と眺めるだけでOK。難易度の目印：🟢 基礎（まずはここ） ／ 🔧 応用（読み飛ばし可）。
A. 品質を守る（こわれてないか、自動でチェック）
コードを上げるたびに、機械がこまめに検査してくれるグループです。人が見る前の「一次チェック」を自動化します。
| できること | きっかけ | 何が嬉しい？ | |
|---|---|---|---|
| ① 🟢 | テスト / lint / 型 / build を自動（npm test lint tsc build） |
PR・push | こわれていたらマージをブロック（＝必須チェック）。壊れたコードを本流に入れない |
| ② 🟢 | CodeQL（コードキューエル）＝セキュリティスキャン | PR・push・定期 | コードの脆弱性（ぜいじゃくせい＝バグの穴）を自動で発見。GitHub製でパブリックは無料 |
| ③ 🟢 | コードレビューのBOT | PRが来たとき | PRに自動でレビューコメント。人のレビュー前の一次チェックで見落としを減らす |
| ④ 🟢 | Dependabot（ディペンダボット） | 自動・定期 | 依存ライブラリの更新や脆弱性アラートを自動でPRにしてくれる |
① テスト・lint・型・build を自動（＝必須チェック）
いちばん基本で、いちばん効きます。「PRが来たら自動でテスト」を設定し、その結果を必須チェックにしておくと、テストが通るまでマージできないようにできます。「自分の環境では動いたのに…」をチームから消せます。
② CodeQL ＝ GitHub のセキュリティスキャン ⭐いま注目
CodeQL は、コードを読んで「ここ、攻撃に使われる穴があるよ」という脆弱性を自動で見つけるしくみ（コードスキャン）です。専門家でなくても、機械が安全の一次チェックをしてくれます。パブリックリポジトリは無料で使えます。
# .github/workflows/codeql.yml（ぐっと縮めた例）
name: "CodeQL"
on: [push, pull_request]
jobs:
analyze:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: github/codeql-action/init@v3 # スキャンの準備
- uses: github/codeql-action/analyze@v3 # 解析して結果を報告
1行ずつ読むと： on: で push と PR をきっかけにし → checkout でソースを取り → init でスキャンの下ごしらえ → analyze で実際に解析。見つかった脆弱性は GitHub の「Security」タブに表示されます。
③ コードレビューのBOT ⭐いま注目
PRを出すと、ロボットが先にレビューコメントを付けてくれます。バグの匂い・読みにくい所・改善案などを指摘するので、人間レビューの前の「下読み」になります。代表例：
| BOT名 | ざっくり何者？ |
|---|---|
| CodeRabbit（コードラビット） | PRの差分を要約＋指摘してくれる定番のレビューBot |
| Sourcery（ソーサリー） | コードの改善提案・リファクタ目線のコメントが得意 |
| GitHub Copilot code review | GitHub純正。PRに対しCopilotがレビューを付ける |
🟢 ポイント：BOTは一次チェック。最終判断は人がします。「機械がまず拾う → 人は本質に集中」という分担です。
④ Dependabot ＝ 依存ライブラリの番人
アプリはたくさんの外部ライブラリに支えられています。Dependabot は、それらに新しい版や危険な脆弱性が出たら、自動で「更新しよう」というPRを作ってくれます。ほうっておくと古くなって危なくなる依存を、勝手に見張ってくれる番人です。
B. 届ける（CD）＝ 自動でデプロイ・リリース
CI（こわれてないか確認）が通ったら、今度はできあがったものを世の中・サーバー・ユーザーへ自動で届けるグループです。🚚
| できること | きっかけ | 何が嬉しい？ | |
|---|---|---|---|
| ⑤ 🟢 | デプロイ（公開・反映） | push・マージ | push したら本番に自動反映。手作業アップの事故をなくす |
| ⑥ 🟢 | リリース | タグを push | GitHub Release を自動作成＋成果物を添付。配布がワンタッチ |
| ⑦ 🔧 | 定期実行（cron＝定期） | 毎朝など | 毎朝バッチ・リンク切れチェックなどをほっといても実行 |
| ⑧ 🔧 | 通知 | 実行のたび | 結果を Slack / Discord へ自動連絡。失敗にすぐ気づける |
| ⑨ 🔧 | Issue / PR 自動化 | 起票・PR時 | ラベル付け・テンプレ・自動クローズなどの雑務を肩代わり |
⑤ デプロイ（公開・反映）
「コードを push したら、自動で本番に反映される」状態をつくれます。届け先はいろいろ：
| 届け先 | やり方のイメージ |
|---|---|
| Vercel / Netlify | GitHub と連携。push → 自動デプロイ（設定が手軽でフロント向き） |
| GitHub Pages | actions/deploy-pages で公開。※このサイト自身もこれで動いています |
| 自前のサーバー | SSH / rsync でファイルを送る |
| Docker イメージ | ビルドしたコンテナを push（レジストリへ） |
🟢 デプロイ先の選び方は、姉妹編 コンピューティングの選択肢（動かす） と地続きです。「どこで動かすか」を決めたら、その先へ自動で届けるのがこの章。
⑥ リリース ＝ タグを push したら自動で配布物をつくる
「バージョンを切る（例：v1.2.0 というタグを付けて push）」をきっかけに、GitHub Release を自動で作成し、アーティファクト（ビルド済みの成果物）を添付できます。
# タグを push したら Release を作る（縮めた例）
on:
push:
tags: ["v*"] # v1.0.0 などのタグで起動
jobs:
release:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: softprops/action-gh-release@v2 # Release を自動作成＋ファイル添付
with:
files: dist/* # 配布したい成果物
1行ずつ読むと： tags: ["v*"] で「vで始まるタグを push したら」起動 → checkout でソース取得 → action-gh-release が GitHub Release を作り、files: に書いた成果物を添付。gh release create コマンドでも同じことができます。「リリース手順を毎回手でやる」事故が消えます。
⑦ 定期実行（cron＝定期）
「毎朝9時にバッチ」「毎晩リンク切れチェック」のような時刻きっかけの自動実行です（schedule: ＝ cron）。きっかけが人の操作ではなく時計になるのがポイント。誰も操作しなくても、決めた時間に勝手に走ります。
⑧ 通知（Slack / Discord へ）
ワークフローの結果（成功・失敗）を Slack や Discord に自動で送ることができます。とくに失敗にすぐ気づけるのが価値。「いつの間にか壊れていた」を防ぎます。
⑨ Issue / PR の自動化
ラベルの自動付け、Issue/PR のテンプレ運用、放置されたものの自動クローズなど、地味な運用の雑務を肩代わりさせられます。チームが増えるほど効いてきます。
🟢 ひとことで言うと
GitHub Actions でできることは、大きく 「品質を守る」（テスト必須チェック・CodeQL=セキュリティスキャン・レビューBot=CodeRabbit/Sourcery/Copilot・Dependabot）と、「届ける（CD）」（デプロイ・タグ→リリース＋成果物添付・定期実行・通知）の2つ。まずは①のテスト自動化だけでも十分。いまどきは CodeQL とレビューBot で「人が見る前の安全＆品質チェック」まで自動にできます。次は、その自動化を支える鍵（シークレット）の守り方へ。🗝