1. はじめに

CI/CDという言葉は知っていましたが、なかなか勉強するまでには至りませんでした。それが仕事で使うことになり、とうとう勉強を始めることにしました。

とはいえ、どこから手をつければいいのか分かりません。調べると記事はたくさんあり、手順も丁寧に書かれています。ただ、どれも「こう書けば動く」が中心で、なぜpushしただけで最後まで流れるのかは、読んでもいまいち分かりませんでした。

幸い、今はAIという優秀なパートナーがいます。そこで今回は、AI(Claude Code)に助けてもらいながら、自分の環境で1つずつ検証していきました。

まず作ったのは、GitHubにpushすると、GitHub ActionsがCloudflare Workersへ自動で公開してくれるしくみです。画面で操作したのは3つ、書いたファイルも3つだけで、pushすると公開まで勝手に進んでいきます。実際に動かしてみても、やはり疑問は「何で流れるの?」、これだけでした。

この記事では、手順に加えて、なぜ最後まで自動で流れるのかを図で説明します。同じところでもやもやしている人の参考になればうれしいです。

なお、記事の内容はすべて自分の環境で動かして確かめていますが、CI/CDは初心者です。間違いなどがあれば、コメントで教えていただけるとうれしいです。

2. 作ったもの

GitHubのmainブランチにpushすると、約30秒で https://test.tobaru.net のページが更新されるしくみです。ページはHTMLファイル1つだけの、いちばん小さなものにしました。

ひとことで言うと、GitHubに置いたファイルを、GitHubのロボット(Actions)がCloudflareまで運んでくれます。運ぶときにCloudflareのドアを開けるので、ロボットに合鍵(APIトークン)を預けてあります。

自分で用意したサーバーはありません。DNSのレコードとhttpsの証明書も、手では作っていません。

3. 環境

項目	内容
GitHub	Freeプラン、Privateリポジトリ
Cloudflare	Freeプラン
ドメイン	Cloudflare Registrarで取得した`tobaru.net`(DNSもCloudflare)
デプロイの道具	`cloudflare/wrangler-action@v4`、wrangler 4
作業したPC	Windows 11、VS Code、Git

自分のPCにNode.jsやwranglerは入れていません。wranglerはGitHub Actionsの中でだけ動きます。

ドメインのDNSがCloudflareにあることが、後で出てくる「1行でDNSと証明書ができる」の条件になります(5章の(5))。

4. 手順

画面で操作したのは(1)〜(3)の3つだけです。(4)はファイルを書くだけ、(5)はpushするだけです。

(1) GitHubにリポジトリを作る

名前はtobaru-net-test、Privateにしました
README・.gitignore・ライセンスは付けず、空のリポジトリにします(ローカルで作ったファイルをそのままpushするため)

(2) CloudflareでAPIトークンを作る

右上の人のアイコン → プロフィール → APIトークン → トークンを作成する
テンプレート「Cloudflare Workers を編集する」を使う
範囲を絞る
- アカウントリソース: 自分のアカウントだけ
- ゾーンリソース: 特定のゾーン → tobaru.netだけ
作成する。トークンは一度しか表示されないので、そのまま(3)に貼る

範囲を絞っておくと、万一トークンが漏れても、できることは「Workersの更新」と「tobaru.netの設定」だけです。

(3) GitHubのSecretsに登録する

リポジトリの Settings → Secrets and variables → Actions → New repository secret で、2つ登録します。

Name	値
`CLOUDFLARE_API_TOKEN`	(2)で作ったトークン
`CLOUDFLARE_ACCOUNT_ID`	CloudflareのアカウントID

(4) ファイルを3つ書く

tobaru-net-test/
├─ public/
│   └─ index.html            … 見せるページそのもの
├─ wrangler.jsonc            … Cloudflareへの注文書(何を・どこで出すか)
└─ .github/
    └─ workflows/
        └─ deploy.yml        … Actionsへの指示書(いつ・何をするか)

public/index.htmlは、ふつうのHTMLです(中身は省略)。

wrangler.jsoncです。ふつうのJSONはコメントが書けませんが、jsonc(JSON with Comments)は//で書けます。

{
  // Cloudflare側でのWorkerの名前(名札)。
  // この名前のWorkerがなければ新しく作り、あれば中身を置き換える
  "name": "tobaru-net-test",

  // Workersの動き方の基準日
  "compatibility_date": "2026-10-01",

  // 静的なファイル(HTML・画像など)の置き場所。この中身がそのままサイトに並ぶ
  "assets": {
    "directory": "./public"
  },

  // どのURLで出すか。custom_domain: true でDNSレコードと証明書も作ってくれる
  "routes": [
    { "pattern": "test.tobaru.net", "custom_domain": true }
  ],

  // xxx.workers.dev というCloudflareのURLでは公開しない
  "workers_dev": false
}

.github/workflows/deploy.ymlです。

name: Deploy

# いつ動くか(イベントの条件)
on:
  push:
    branches: [main]     # mainブランチにpushされたとき
  workflow_dispatch:     # Actionsタブの「Run workflow」ボタンで手動でも動かせる

jobs:
  deploy:
    runs-on: ubuntu-latest   # GitHubが数十秒だけ貸してくれるLinux
    permissions:
      contents: read
    steps:
      # 1. このcommitのファイル一式をランナーに取り出す
      - uses: actions/checkout@v5

      # 2. wranglerをインストールして動かす(commandを書かなければ wrangler deploy)
      - name: Deploy to Cloudflare Workers
        uses: cloudflare/wrangler-action@v4
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}    # 金庫の合鍵
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}  # どのアカウントに送るか
          wranglerVersion: "4"

(5) pushする

git init -b main
git add -A
git commit -m "最初のページとデプロイ設定"
git remote add origin https://github.com/<ユーザー名>/tobaru-net-test.git
git push -u origin main

pushしてから約30秒で、https://test.tobaru.netが開けるようになりました。10秒おきに確かめると、最初の3回はつながらず、4回目で200が返ってきました。

5. なぜ最後まで自動で流れるのか

答えを先に書くと、何かがずっと監視しているわけではありません。「イベントが起きたら、こう動く」という小さな決まりが、前の結果を受け取ってつながっているだけです。

pushしてから公開されるまでを、5つの段階に分けました。

画像をクリックすると、大きく表示されます。

ここからは、私が分からなかったところを順に説明します。

(1) GitHubはフォルダを監視しているの?

監視はしていません。pushやプルリクエストなどのイベントが起きたときにだけ、GitHubがそのcommitの.github/workflows/を開きます。中のYAMLを全部読んで、on:の条件に合うものだけを動かします。

それが分かる例です。

こんなとき	デプロイは動く?
`README.md`だけ変えてpush	動く。`deploy.yml`は変わっていないが、「mainへのpush」というイベントが起きたから
`deploy.yml`を書き換えたが、pushしていない	動かない。GitHubは自分のPCの中を見ていない
`deploy.yml`を書き換えてpush	書き換えた後の内容で動く。そのcommitのファイルを読むから
別のブランチにpush	動かない。`on:`が`branches: [main]`だから
プルリクエストをmainにマージ	動く。マージするとmainにcommitが入り、mainへのpushと同じになるから

「受付の人がマニュアルをずっと見張っている」のではありません。「呼び鈴が鳴ったらマニュアル棚を開いて、今回の用件に当てはまるページを探す」イメージです。マニュアル棚が.github/workflows/、ページの見出しがon:です。

(2) ファイルを指定していないのに、なぜwrangler.jsoncが使われるの?

deploy.ymlのデプロイの手順には、「どのファイルを送るか」を書いていません。それでも動くのは、書かなかったときの決まり(既定値)が2段階あるからです。

wrangler-actionの決まり: commandを書かなければdeployを実行する(action.ymlに「Defaults to "deploy"」とあります)。workingDirectoryも書かなければ、リポジトリのいちばん上で実行する
wranglerの決まり: wrangler deployは、実行したフォルダでwrangler.jsonc / wrangler.json / wrangler.tomlを探して読む

しかも、wrangler.jsoncそのものは送られません。「何を・どこに・どんな名前で」の指示として読まれ、送られるのはassets.directoryに書いたpublic/の中身です。

決まった名前・決まった場所に置けば何も書かなくても動き、変えたいときだけ書く。この考え方を「設定より規約(Convention over Configuration)」と呼ぶそうです。(1)の.github/workflows/も同じです。

(3) Cloudflareで何も作っていないのに、なぜWorkerができるの?

wrangler.jsoncの"name": "tobaru-net-test"で、「この名前のWorkerを、この中身にして」と頼んでいるからです。Cloudflareは、その名前のWorkerがなければ新しく作り、あれば中身を置き換えます。上の図のaltのところです。

どのアカウントに作るかはaccountId、入っていいかはapiTokenで伝えています。どちらもSecretsから渡しているので、deploy.ymlには値そのものを書いていません。

(4) Secretsは何のため?

Secretsは合鍵を入れておく金庫です。deploy.ymlには${{ secrets.CLOUDFLARE_API_TOKEN }}と、「金庫のこの引き出しを使って」とだけ書きます。合鍵そのものはどのファイルにも書かないので、コードを人に見せても漏れません。

(5) 1行でDNSと証明書までできるの?

できました。routesに"custom_domain": trueと書くと、「このホスト名をまるごとこのWorkerにする」意味になり、CloudflareがDNSのレコードとhttpsの証明書を作ってくれます。

ただし、次の2つがそろっているからできることです。

tobaru.netのDNSが、同じCloudflareアカウントにある(Cloudflareが自分でレコードを書き込める)
APIトークンにtobaru.netを触る権限がある(4章の(2)でゾーンを絞って許可した)

DNSが別の会社にあるドメインでは、この1行だけでは済みません。

custom_domainを付けずに"pattern": "test.tobaru.net/api/*"のように書くと、「このURLに来たアクセスだけWorkerが受け取る」という別の使い方になります。この場合、DNSのレコードは自分で作ります。

6. 警告が出たところ

最初は、他の記事と同じくcloudflare/wrangler-action@v3を使っていました。デプロイは成功しましたが、Actionsの結果のAnnotationsに、警告1件とお知らせ1件が出ました。

(1) Node.js 20 is deprecated(警告)

Node.js 20 is deprecated. The following actions target Node.js 20 but are being forced to run on Node.js 24: cloudflare/wrangler-action@v3.

wrangler-action@v3はNode.js 20向けに作られていて、GitHub側がNode.js 20を廃止していく途中なので、Node.js 24で動かしているという知らせです(GitHubのお知らせ)。今は動いていますが、将来動かなくなるおそれがあります。

調べるとv4が出ていて、action.ymlにusing: "node24"とありました。入力の項目(apiToken・accountIdなど)は同じなので、@v3を@v4に変えるだけで警告が消えました。

この修正もdeploy.ymlを1文字直してpushしただけです。しくみそのものの設定を変えた場合も、ページを変えた場合と同じ流れで反映されます(5章の(1)の表の3行目)。

(2) ubuntu-latestがUbuntu 26に移る(お知らせ)

The ubuntu-latest label will migrate to Ubuntu 26 beginning October 19, 2026.

runs-on: ubuntu-latestの中身が、順に新しいUbuntuに切り替わるという案内です(runner-imagesのIssue)。今回のワークフローはwranglerを動かすだけなので、そのままにしています。

(3) nameを変えるときの注意

つまずいたわけではありませんが、しくみから考えると注意が必要だと分かったところです。

nameを変えてpushすると、Cloudflareは名前が変わったとは受け取りません。「その名前のWorkerがないので新しく作る」と受け取ります(5章の(3))。古いWorkerは残ったままになるので、変えるときは古いほうの片付けも必要です。

7. Cloudflareの画面で確かめる

Cloudflareの画面では何も作っていませんが、pushしたあとに開くと、次の2つができていました。

(1) Workersの一覧

「Workers & Pages」を開くと、wrangler.jsoncのnameで付けたtobaru-net-testがあり、routesで頼んだtest.tobaru.netがつながっていました。

「デプロイメントを表示」を開くと、pushした回数ぶんの履歴が並んでいます。GitHubのcommitと1回ずつ対応しています。

(2) DNSのレコード

tobaru.netのDNSのページには、自動で作られたtestのレコードがありました。自分では1つも作っていないのに、本当にレコードが出ていてびっくりしました。

見えているもの	意味
左端の鍵のアイコン	自動で作られたレコードなので、ここからは編集できない
タイプ「Worker」	AやCNAMEではなく、「このWorkerに届けて」という特別なレコード
コンテンツ「tobaru-net-test」	`wrangler.jsonc`の`name`。名札でつながっている
「プロキシ済み」	アクセスはいったんCloudflareが受け取る

外のDNS(1.1.1.1)にtest.tobaru.netを聞いてみると、返ってくるのはCloudflareのIPアドレス(104.21.x.xなど)でした。「プロキシ済み」なので、サーバーの場所ではなくCloudflareのアドレスが返ります。応答のヘッダーにはServer: cloudflareとCF-RAY: …-NRTがあり、東京の拠点から返っていることも分かりました。

8. まとめ

最初は、なぜ自動で最後まで流れるのかが、いまいち理解できませんでした。でも、監視という大掛かりな仕組みではありませんでした。イベントが起きたときの動きが決まっていて、その決まりどおりに動くと、流れるように最後までつながる。それが分かったとき、美しいなーと思いました。DNSの画面に、自分では作っていないレコードが出ていたときも感動しました。

今回分かったことを並べると、次の3つです。

GitHubは監視していない。イベントが起きたときに.github/workflows/を読み、on:に合うものだけを動かす
書いていないことは既定値で動く。wrangler-actionはdeployを実行し、wranglerは決まった名前のwrangler.jsoncを探す
CloudflareはnameでWorkerを見分け、なければ作り、あれば置き換える。custom_domain: trueならDNSと証明書も作る

次は、プルリクエストを作ったらチェックだけを動かし、mainにマージしたらデプロイする形(CIとCDの分離)を試す予定です。チェックも、pull_requestというイベントに決まりを足すだけで作れるはずです。