ブログを長く運営していると、「この先もずっとWordPressを中心に運用していくのが、自分にとって一番いいのだろうか」と考えることがあります。
私自身、これまではWordPressを中心にサイトを運営してきました。今でもWordPressはとても便利ですし、豊富なテーマやプラグイン、使いやすい管理画面には大きな価値があると思っています。
ただ、ChatGPTなどのAIを日常的に使うようになってから、少しずつサイト運営に対する考え方が変わってきました。
AI時代のWebサイト運営では、記事を書くことだけでなく、
- 更新やメンテナンスをどこまで簡単にできるか
- 記事作成から公開までをどこまで自動化できるか
- GitHubなどの外部ツールと連携しやすいか
- 人間が毎回管理画面を操作しなくても運営できるか
といった点も、以前より重要になってくるのではないかと感じています。
そこで今回、新しいサイト用のドメインを国内のドメインサービスではなく、Cloudflare Registrarで取得してみることにしました。
（ちなみに普段はXドメインを使っています）
理由は、単にCloudflareのドメイン料金が魅力的だったからではありません。
ドメイン、DNS、GitHub、サイトのbuild・deployまでを、できるだけつながった状態で運用してみたかったからです。
この記事では、なぜCloudflareでドメインを取得したのか、実際にどんな手順で設定したのか、そしてGitHubとCloudflareをつないでサイトを公開してみてどう感じたのかを、実際のスクリーンショットとともに紹介します。
- 先に大事なこと。Cloudflareでドメインを買う必要はない
- なぜWordPress以外の運用も試してみたくなったのか
- Cloudflare Registrarでドメインを取得してみる
- 登録が終わると、そのまま次の作業へ進める
- DNSSECやWHOIS Privacyも同じ場所で確認できる
- ここからがCloudflareを選んだ一番の理由
- GitHubとつないでサイトを公開できる
- 公開するGitHubリポジトリを選ぶ
- buildとdeployの方法を設定する
- 独自ドメインを接続する
- Custom Domainとして追加された
- GitHubの変更から自動deployできた
- 独自ドメインで実際にサイトが表示された
- AIを使うなら、この運用が面白いと思った理由
- AIに任せれば全部うまくいくわけではなかった
- WordPressよりCloudflareの方が優れている、という話ではない
- Cloudflare Registrarを使う前に知っておきたい制約
- Cloudflareが向いていそうな人
- まとめ：Cloudflareでドメインを買った本当の理由
先に大事なこと。Cloudflareでドメインを買う必要はない
最初に、ひとつ大事なことを書いておきます。
Cloudflareを使うために、Cloudflare Registrarでドメインを購入する必要はありません。
他社で取得したドメインをCloudflareへ追加して、DNSなどをCloudflare側で管理することもできます。Cloudflare WorkersやGitHub連携を使うために、Cloudflare Registrarで購入することが必須というわけでもありません。
Cloudflare Registrarで買わなければ今回の仕組みが作れなかった、という話ではないのです。
それでも今回Cloudflare Registrarを選んだのは、
どうせCloudflareをDNSやサイト公開の基盤として使うのであれば、ドメイン取得の段階から同じ場所へ寄せてみよう
と思ったからです。
今回の目的には、この選択がよく合っていました。
Cloudflare Registrar自体は、レジストリやICANNへ支払う費用に上乗せしない「at cost」の料金体系を掲げています。また、WHOIS情報のredactionやDNSSECも提供されています。
なぜWordPress以外の運用も試してみたくなったのか
ここも誤解のないようにしておきたいところです。
「AI時代だからWordPressはもうダメ」という話ではありません。
WordPressは、人間が管理画面から記事を書き、画像を入れ、テーマやプラグインを使ってサイトを管理する仕組みとして、今でも非常によくできています。
一方で、私自身の作業方法が変わってきました。
以前なら、
- WordPressの管理画面へログインする
- 記事を貼り付ける
- 画像をアップロードする
- 表示を整える
- 公開する
といった作業を人間が行っていました。
ところが最近は、AIを使っていると、
- AIと相談する
- AIがGitHub上のファイルを読む
- 文章やコードを変更する
- GitHub上で変更内容を確認する
- 本番へ反映する
- 最後に人間が公開画面を見る
という方法も現実的になってきました。
こうなると、ふと疑問が生まれます。
人間向けの管理画面を、サイト運営の中心に置き続ける必要はあるのだろうか。
私がやってみたかったのは「脱WordPress」そのものではありません。
AIとGitHubを中心にしたサイト運営を、一度きちんと試してみること。
その公開基盤としてCloudflareが面白そうだった、というのが今回の出発点です。
Cloudflare Registrarでドメインを取得してみる
まずCloudflare Registrarで、新しい.comドメインを取得しました。
Cloudflareの購入画面では、登録料金とあわせて、そのドメインで利用できる項目が表示されます。
今回の画面では、
- WHOIS Privacy
- DNSSEC
- Email Forwarding
などの項目が表示されていました。
特に分かりやすかったのが、ドメイン料金と利用できる機能を同じ画面で確認できたことです。
Cloudflare RegistrarではWHOIS情報が原則redactされ、DNSSECも追加料金なしで利用できます。DNSSECについては「利用できる」ことと「すでに有効になっている」ことは別なので、取得後に設定画面から状態を確認しました。
料金だけを理由にCloudflareを選んだわけではありませんが、レジストラ側の上乗せ料金を設けない料金体系は分かりやすいと感じました。
登録が終わると、そのまま次の作業へ進める
購入が完了すると、ドメインの登録完了画面が表示されました。
ここで印象に残ったのが、その先の導線です。
ドメインを管理するだけでなく、サイトの公開やセキュリティ関連の設定へ、そのまま進めるようになっています。
一般的なドメイン取得では、
ドメインを買ったので、ここで一旦終了
という感覚になりがちです。
Cloudflareの場合は、
ドメインを取った。それでは次に何を作る？
と、そのまま次の工程へ進んでいく印象でした。
DNSSECやWHOIS Privacyも同じ場所で確認できる
ドメインを取得したあと、設定画面も確認しました。
ここでは、
- DNSSEC
- WHOIS Privacy
- レジストラ移管関連
などを確認できます。
DNSSECについては、途中で状態を確認しながら設定しました。
最初から何も考えず一発で終わったわけではありません。
それでも、ドメイン管理とDNS関連の設定がCloudflare側にまとまっているため、
今どの会社の、どの管理画面を触っているんだっけ？
となりにくかったのは助かりました。
ここからがCloudflareを選んだ一番の理由
ここまでなら、使いやすいドメイン管理サービスという話です。
私がCloudflareを試してみたかった本当の理由は、この先にあります。
GitHubとつないでサイトを公開できる
今回作っていたサイトは、記事や設定をGitHub上のファイルとして管理しています。
Cloudflare WorkersではGitHub repositoryを接続し、GitHubへのpushをきっかけに自動でbuild・deployするGit integrationが用意されています。
CloudflareのWorkers & Pagesから新しいapplicationを作ると、GitHubとの連携を選択できます。
私にとって重要なのは、AIとGitHubの相性がいいことです。
AIに文章を書いてもらうだけなら、
- AIが文章を書く
- 人間がコピーする
- WordPressへ貼る
- 画像を設定する
- 公開する
という作業が残ります。
これでは、最後に人間が「運搬係」になってしまいます。
GitHubをサイト運営の中心に置けば、AIが扱ったファイルを、そのまま次の工程へつなげやすくなります。
ここが今回、一番試してみたかった部分でした。
公開するGitHubリポジトリを選ぶ
GitHubを接続すると、Cloudflareからrepositoryを選択できます。
今回は、サイト用に用意していたGitHub repositoryを選択しました。
この時点で、
サイトの中身を管理するGitHub
と、
サイトをbuild・公開するCloudflare
がつながります。
WordPressでは、記事などのコンテンツをWordPressのデータベース内で管理するケースが一般的です。
今回のサイトでは、記事やコードの正本をGitHub側に置いています。
Cloudflareは、それをbuildして公開する役割です。
buildとdeployの方法を設定する
次に、Cloudflare側でbuildとdeployの設定を行いました。
今回のサイトでは、
- Build command：
npm run build - Deploy command：
npx wrangler deploy
という設定にしました。
エンジニアではない人が初めてこの画面を見ると、少し難しそうに感じるかもしれません。
私も最初からすべてを理解していたわけではありません。
ただ、AIに確認しながら進めれば、
このコマンドでサイトを組み立て、このコマンドでCloudflareへ公開する
という役割を理解するところから始められます。
WordPressの方が簡単に始められる部分は間違いなくあります。
一方、この方法では、サイトがどのファイルから作られ、どう公開されるのかを追いやすいのがメリットです。
独自ドメインを接続する
次に、作成したWorkerへ独自ドメインを接続します。
今回は取得したドメインそのものではなく、サイト用にサブドメインを作りました。
イメージとしては、
example.com
というドメインを取得して、
sub.example.com
を今回のサイトに割り当てる形です。
Cloudflare WorkersのCustom Domainsでは、Workerへdomainまたはsubdomainを接続できます。
Custom Domainを設定すると、必要なDNSレコードと証明書はCloudflare側で作成されます。
そのため今回は、DNSレコードを一つずつ手作業で追加する必要はありませんでした。
ただし、ここでも大事な点があります。
Cloudflare Registrarでドメインを買った人だけが使える機能ではありません。
Cloudflareのzoneとして適切に管理されているdomainへWorkerのCustom Domainを設定する仕組みです。
「Cloudflareで買わなければ簡単に接続できない」と誤解しないようにしたいところです。
Custom Domainとして追加された
設定後、WorkersのDomains画面に作成したサブドメインが表示されました。
この段階で、
- GitHub repository
- Cloudflare Worker
- 独自ドメイン
がつながりました。
ドメイン購入だけを切り取って考えれば、Cloudflare Registrarでなければならない理由はそれほど強くありません。
でも、ここまで一連の作業をしてみると、
「最初からCloudflareへ寄せておいて、自分には扱いやすかった」
と感じました。
GitHubの変更から自動deployできた
さらに重要なのが、その後の更新です。
Cloudflare WorkersのGit integrationでは、接続したGitHub repositoryへ変更をpushすると、自動でbuild・deployできます。production branchとして選んだbranchへのpushをproduction deploymentにつなげることもできます。
今回も、GitHub側の本番branchへ変更を反映したあと、Cloudflare側でautomatic deploymentが行われるところまで実際に確認しました。
ここは今回の実験で特に重要なところでした。
一度この仕組みを作っておけば、
AIがGitHub上のファイルを変更する
→ 人間が内容を確認する
→ 本番branchへ反映する
→ Cloudflareがbuild・deployする
という運用ができます。
人間が毎回サイトの管理画面へ入り、文章をコピー＆ペーストする必要がありません。
私がCloudflareを試したかった最大の理由は、まさにここです。
独自ドメインで実際にサイトが表示された
最後に、設定した独自ドメインへアクセスしました。
ちゃんとサイトが表示されました。
ここまでで、
ドメイン取得
→ Cloudflareで管理
→ GitHub接続
→ build / deploy
→ Custom Domain接続
→ 独自ドメインで公開
までを実際に確認できました。
途中で調べたり、設定内容を確認したりする場面はありました。
「何も分からなくても数クリックで全部終わった」というほど単純ではありません。
それでも、ドメイン、DNS、build、deploy、独自ドメインがCloudflare側でつながっているため、別々の会社の管理画面を何度も行き来する感覚は少なかったです。
AIを使うなら、この運用が面白いと思った理由
今回の本音はここです。
単にWordPressとは違う新しい技術を使ってみたかったわけではありません。
AIにもっとサイト運営そのものを任せられる形を作ってみたかった。
これが一番の理由です。
現在のAIは、文章を書くことだけではなく、環境が整っていれば、
- GitHubの中身を読む
- ファイル同士の関係を確認する
- 記事を書く
- コードを修正する
- 差分をレビューする
- validation結果を確認する
といった作業にも使えます。
そうなると、人間が毎回WordPressへ文章を貼る方式より、
サイトそのものを、AIも扱いやすいファイルとして管理した方が自然なのではないか
と思うようになりました。
今回のCloudflare＋GitHubは、その実験です。
AIに任せれば全部うまくいくわけではなかった
実際にサイトを公開してみると、問題も見つかりました。
記事自体は正常にbuildされ、deployも完了していました。
ところが、実際のページを人間の目で見ると、画像の表示サイズが想定と違っている箇所がありました。
つまり、
build成功 = 人間から見て完璧なページ
ではありません。
そこで表示部分を修正し、GitHubへ反映して、もう一度公開画面を確認しました。
この経験から、
AIに機械的な作業を多く任せ、人間は判断や最終確認へ集中する
という役割分担が、自分には合っているのではないかと思っています。
「AIに全部丸投げする」のとは少し違います。
人間が一つひとつファイルを運ぶ必要は減らす。
一方で、最終的な品質や公開判断は人間が見る。
そんな運用を試しています。
WordPressよりCloudflareの方が優れている、という話ではない
ここまでCloudflareのメリットを書いてきましたが、WordPressの方が向いている人もたくさんいます。
たとえば、
- 管理画面のエディタから直接記事を書きたい
- テーマを簡単に変更したい
- プラグインで機能を追加したい
- GitHubやbuild、deployといった言葉には触れたくない
という場合は、WordPressの方が始めやすいでしょう。
WordPressなら、データベースや管理画面、投稿システムなど必要なものが最初から揃っています。
一方、今回のような構成にすると、WordPress固有の
- データベース管理
- テーマ更新
- プラグイン更新
- プラグイン同士の互換性確認
といった保守対象からは距離を置けます。
ただし、リスクや保守作業そのものが消えるわけではありません。
GitHub、npmの依存関係、Cloudflare、build設定など、別の管理対象があります。
そのため、
「Cloudflareの方が安全」ではなく、「管理するものの種類が変わる」
と考える方が正確だと思います。
Cloudflare Registrarを使う前に知っておきたい制約
実際に使う前に知っておいた方がよい点もあります。
Cloudflare Registrarで取得したドメインは、Cloudflareのnameserverを使用します。
Cloudflare Registrarを使っている間は、第三者DNS providerのnameserverへ自由に変更することはできません。別のDNS providerのnameserverを使いたい場合は、基本的にRegistrar自体を移管する必要があります。
つまり、
Cloudflareでドメインだけ買って、DNS管理は完全に別会社へ任せたい
という人には向きません。
今回の私は、
DNSもCloudflareで管理したい
と思っていたので問題ありませんでした。
むしろ、その制約と自分の目的が一致していたので扱いやすかったです。
逆にDNS providerを自由に選びたい人は、他のRegistrarを選ぶ方が合う可能性があります。
Cloudflareが向いていそうな人
今回使ってみた範囲では、Cloudflareを中心にした構成は、次のような人には面白いと思います。
- AIをサイト運営にも活用してみたい
- GitHubをコンテンツやコードの管理場所にしたい
- 更新からdeployまでを自動化したい
- WordPress以外のサイト構成も試してみたい
- DNSや公開基盤をCloudflareへまとめたい
- 人間のコピー＆ペースト作業を減らしたい
一方で、
- とにかく簡単に記事を書いて公開したい
- GitHubを使う予定がない
- コマンドやbuild設定を見たくない
- WordPressのテーマやプラグインを活用したい
という人なら、無理にCloudflare中心の構成へ変える必要はありません。
まとめ：Cloudflareでドメインを買った本当の理由
今回Cloudflare Registrarで新しいドメインを取得しました。
でも、Cloudflareでなければドメインを取得できなかったわけでも、Cloudflare Registrarで購入しなければWorkersを使えなかったわけでもありません。
それでもCloudflareを選んだのは、
AI、GitHub、Cloudflareをつないだサイト運営を試してみたかったからです。
これまで私は、
人間がWordPressの管理画面へ入り、サイトを更新する
という方法を当たり前だと思っていました。
今回試しているのは、
AIと人間がGitHub上でサイトを管理し、Cloudflareが公開する
という方法です。
どちらが絶対に正しいという話ではありません。
ただ、自分の作業方法がAIによって変わってきたのであれば、サイトを動かす仕組みも一度見直してみる価値はあるのではないか。
今回Cloudflareを使ってみて、そう感じました。
まだこの方法で長期間サイトを運営したわけではありません。
数か月後には、
やっぱりWordPressの方が楽だった
と思っているかもしれません。
逆に、
もう管理画面へ文章をコピー＆ペーストする運営には戻れない
と思っている可能性もあります。
どちらになるのかも含めて、しばらく実際に運用してみようと思います。
Cloudflareでドメインを取得したこと自体より、AI時代のサイト運営を自分で試し始めたこと。
振り返ってみると、それが今回の一番大きな変化だったのかもしれません。
コメント