push したら世界が自動で更新される― GitHub Actions で CI/CD を完成させ、連載を締める

実戦編もいよいよ最終回です。第13回で、育ててきた TODO アプリを GitHub Pages で公開しました。でも今のままだと、コードを直すたびに、また手で公開しなおす必要があります。今日はそこを自動化します。main に push したら、GitHub が勝手にチェックして、勝手に公開ページを更新してくれる。その仕組みを作って、連載を締めくくります。

もちろん、今回も私はコマンドを打ちません。「push したら自動で更新されるようにして」「ついでに軽くチェックも」「組んだら実際に動くか確認して」と、AI に言葉で頼むだけです。

TL;DR

• GitHub Actions で「CI(コードが壊れていないかのチェック) が通ったら、自動でデプロイ (公開) する」流れを、設定ファイル 1 枚で組みます。AI に一言で deploy.yml を生成させます。
• GitHub Pages の公開元を「Actions が上げたもの」に切り替えると、main に push するたびに、約 23 秒で公開 URL が自動更新されます。
• CI は「index.html があるか」「コンフリクトの跡が残っていないか」を見る軽いもの。Node.js 20 の非推奨警告が出ますが、実害はなく、将来の対応でかまいません。
• 連載は全 14 回。小さな TODO アプリ 1 本を育てながら、Git の基礎から CI/CD まで、すべて AI への言葉だけで通しました。

この回でやること――CI/CD とは何か

今日のキーワードは CI/CD です。短く言うと、こうです。

• CI(継続的インテグレーション): コードを変えるたびに「壊れていないか」を自動でチェックすること
• CD(継続的デリバリー／デプロイ): チェックが通ったら、自動で公開 (デプロイ) すること

この 2 つをつなぐと、「main に push する→自動でチェック→問題なければ自動で公開」という流れができます。人が公開ボタンを押さなくても、push しただけで世界が更新される。それが今日のゴールです。

flowchart TD PU["main に push"] --> CI["CI ジョブ<br/>index.html の存在 / コンフリクト跡を確認"] CI -->|"通ったら(needs: ci)"| DP["Deploy ジョブ<br/>actions/deploy-pages で公開"] DP --> URL["公開 URL が自動更新<br/>約 23 秒で反映"]

AI への一言で、自動デプロイを組む

GitHub Actions は、.github/workflows/ に置いた設定ファイル (YAML) の指示どおりに、push などのきっかけで処理を走らせる仕組みです。これも、私が書くのではなく AI に頼みます。

これからは main に push するたびに自動でサイトが更新されるようにしたい。
GitHub Actions で自動デプロイを組んで。

AI は .github/workflows/deploy.yml を作りました。まず、ファイルの上半分と、公開を担当する deploy ジョブを見ます。

name: CI & Deploy to GitHub Pages
on: push: branches: - main
permissions: contents: read pages: write id-token: write
# 同時デプロイを防ぎ、進行中のデプロイはキャンセルせず待機させる
concurrency: group: "pages" cancel-in-progress: false
jobs: deploy: name: Deploy to GitHub Pages needs: ci runs-on: ubuntu-latest environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} steps: - uses: actions/checkout@v4 - uses: actions/configure-pages@v5 - uses: actions/upload-pages-artifact@v3 with: path: "." - id: deployment uses: actions/deploy-pages@v4

on: push: branches: [main] が「main に push されたら走る」という引き金。deploy ジョブの中では、GitHub 公式の部品 (actions/configure-pages や actions/deploy-pages) を組み合わせて、リポジトリの中身を Pages に公開しています。

ここでも、私が言っていないことを AI が補っています。ワークフローの名前 (CI & Deploy to GitHub Pages)、対象を push だけにしたこと、permissions を必要な 3 つだけに絞ったこと、concurrency で「公開が重なったら順番待ちにする」設定。とくに permissions を最小限にするのは、安全のための定石です。「自動デプロイを組んで」のひと言から、こうした細部まで埋まりました。

Pages の公開元を Actions に切り替える

第13回では、Pages の公開元を「main ブランチの中身」に設定しました。でも今回は「Actions が上げたもの」を公開したいので、設定を切り替えます。これも AI が gh で行いました。

gh api -X PUT repos/ikuma-hiroyuki/todo-app-git-deep-dive/pages -f build_type=workflow

build_type を legacy(ブランチの中身をそのまま公開) から workflow(Actions のデプロイ結果を公開) に変える、という指定です。GitHub の設定画面 (Settings → Pages) でも切り替えられますが、AI はコマンド一発で済ませました。これで、さきほどの deploy ジョブが上げたものが、公開ページになります。

AI への一言で、軽い CI を足す

公開の自動化はできました。次に、公開する前のチェック (CI) を足します。完璧なテストは要りません。「最低限これだけは」という軽いもので十分です。

push のときに簡単なチェック(CI)も。index.html があるか、コンフリクトの跡が
残ってないか、くらいの軽いやつで。

AI は、deploy.yml に ci ジョブを足しました。

 ci: name: CI Check runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: index.html が存在するか確認 run: | if [ ! -f index.html ]; then echo "::error::index.html が見つかりません" exit 1 fi - name: コンフリクトマーカーが残っていないか確認 run: | if grep -rn --include="*.html" --include="*.css" --include="*.js" \ -E "^(<{7}|>{7}|={7})" .; then echo "::error::コンフリクトマーカーが残っています" exit 1 fi

やっていることは 2 つです。index.html がちゃんとあるか。そして、第9回で見た <<<<<<< のようなコンフリクトの跡 (解決し忘れ) が残っていないか。どちらかが引っかかったら exit 1 で止まり、::error:: という書き方で、失敗の理由が Actions の画面に赤く表示されます。

そして、さきほどの deploy ジョブに付いていた needs: ci。これが効いてきます。「deploy は ci が通ってから走る」という依存関係です。これで「チェックが通ったら公開」という直列の流れができました。CI と Deploy を別ファイルに分けることもできますが、index.html 1 枚の小さなアプリなら、1 ファイルに直列で書いたほうが流れが一目で分かります。AI はその判断で 1 ファイルにまとめました。

push して、自動デプロイを確認する

組み上がったら、本当に動くか確かめます。これも頼みます。

組んだら、小さな変更を push して、Actions が走って自動デプロイされるのを確認して。

AI は、確認用に小さな変更を入れました。ブラウザのタブに出るタイトルを、TODO から TODO App に変えるだけの変更です。それを push すると、Actions が自動で走りました。

2 回とも成功 (緑のチェック)。push してから約 23 秒で、公開 URL のタイトルが TODO App に変わっていました。もう、公開しなおす操作は要りません。コードを直して push すれば、チェックが走り、問題なければ世界が更新される。これが CI/CD の手応えです。

Warning と向き合う――「今すぐ壊れる」ではない

成功はしましたが、Actions のログには黄色い警告が出ていました。

actions/checkout@v4 などが使っている Node.js 20 は、2026 年 6 月 16 日以降は Node.js 24 が既定になります

これは、GitHub が部品の動作環境を新しくする予定だ、というお知らせです。大事なのは、**この警告が出ても実行は成功している (exit 0)**ということ。今すぐ何かが壊れるわけではありません。対応するなら、FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true という設定を足すか、将来 actions/checkout@v5 のように新しいバージョンへ上げればいい。今日の時点では、放っておいても動きます。

Actions の警告は「今すぐ直せ」ではなく「いずれ対応してね」という告知です。赤いエラー(失敗) と黄色い警告 (注意) を読み分けられると、必要以上に慌てずにすみます。

AI に頼むときの言い方

最終回も、私が指定したことと、AI が補ったことに分かれていました。

「自動デプロイを組んで」「軽い CI も」という方向だけで、AI は YAML を書き、安全な権限設定を選び、依存関係をつないで、実際に push して動作確認まで済ませました。私が決めたのは、「自動化したい」「チェックも欲しい」という方向だけです。

まとめ――連載をふりかえって

第 14 回として、GitHub Actions で「push したら、チェックして、自動で公開」の仕組みを完成させました。

• 「自動デプロイを組んで」と頼むと、AI が deploy.yml を書き、gh api で Pages の公開元を Actions に切り替えた。
• 「軽い CI も」で、index.html の存在とコンフリクト跡をチェックする ci ジョブを足し、needs: ci で「チェックが通ったら公開」の直列にした。
• push してから約 23 秒で公開 URL が自動更新されることを、タイトル変更で確認した。Node.js 20 の警告は実害なし (将来対応)。

そして、この回で実戦編 (第8回〜第 14 回) が完結します。小さな TODO アプリ 1 本を、ゼロから育てながら、Git と GitHub の操作をひととおり通してきました。

通してみて、いちばん伝えたかったのは、最初から最後まで変わりません。私たちは、コマンドを暗記した技術者になる必要はないということです。やったことは、ずっと同じでした。「こうしたい」を言葉で AI に伝え、AI が選んだ操作の意味を理解し、判断が要る場面 (コンフリクトをどう直すか、push 済みを取り消すか、どのブランチを残すか) では自分で決める。手は AI が動かし、舵は自分が握る。それだけで、ゼロから作ったアプリが、自動で更新される公開サービスにまで育ちました。

Git の全コマンドを覚えていなくても、何が起きているかの地図さえ頭にあれば、AI に的確に頼めます。その地図を、本編 (第1回〜第7回) と、この実戦編で一緒に描いてきました。あとは、あなた自身のアプリで、同じことをやってみるだけです。

なお、この記事で AI に渡したひと言は、すべて Claude(Sonnet) に実際に渡し、書いてあるとおりに動くことを確かめたものです。deploy.yml の生成から Pages の切り替え、push による動作確認まで、私はコマンドを打たず、すべて AI への言葉だけで実機検証しました。Actions は実際に緑のチェックで通り、公開 URL は今も push のたびに自動更新されます。モデルやその日の状態によって、AI が勝手に決める値 (ワークフロー名や設定の細部など) は変わります。指定しなかった部分は変わりうる、と思って読んでください。