Cloudflare（クラウドフレア）を導入するとは、ドメインの「住所録」（DNS）の置き場所を Cloudflare に移し、サイトへの通信を Cloudflare 経由にすることです。サイトやメールの中身は今のサーバーに置いたまま、通り道だけを変えます。
この記事では、私が実際に AI を活用して、毎日記事を更新している地域メディアに Cloudflare を導入した事例を紹介します。管理画面の操作と確認の多くは AI に任せ、取り消しにくい操作の確定と、鍵になる値の扱いは私が受け持ちました。
いちばん気をつけたのはメールです。このサイトには、サイトの行き先を変えた瞬間にメールが届かなくなる設定が残っていました。
作業は2つの日に分けました。1日目は DNS だけを移し、29件のレコードを取り込んで、新旧の DNS に56通りの問い合わせを投げて答えを比べました。違いは意図して変えたメールの1件だけです。3日後の深夜に、サイトの行き先を数秒で切り替えました。サイトの表示もメールも止まっていません。
Cloudflare は、DNS を移す日と、サイトの通信を通す日を分けると止めずに入れられます。その段取りを、実際の画面とあわせてたどります。Cloudflare そのものの仕組みや使い方から知りたい方は、「Cloudflareとは？初心者向けに無料プランの始め方と設定を画面でたどる」 から読んでください。
CONTENTS
なぜ Cloudflare を入れたのか
このサイトは、WordPress を新しいサーバーに作り直している途中でした。新しいサーバーは外からの入口を開けずに、Cloudflare を通してだけ公開する作りにしたので、Cloudflare の導入が切り替えの前提でした。
公開には Cloudflare Tunnel を使います。サーバーの側から Cloudflare へつなぎに行く仕組みで、サーバーに外から入れる入口が要りません。主な目的は、速さよりもサーバーを守ることです。
当時の構成は次のとおりです。
- ドメインの登録はムームードメイン
- DNS・サイト・メールは Xserver の共用サーバー（同じサーバー）
- メールは info@ などに月150件前後が届く
- スマホアプリや管理システムが、同じドメインの別の名前（サブドメイン）で動いている
最優先は、今のサイト・メール・連携アプリを一切止めないことでした。毎日記事を更新しているので、止めてよい日はありません。
Cloudflare で何ができるか（DNS・配信の高速化・SSL・攻撃からの守り）と、無料プランの始め方は、実際の画面つきでCloudflare の初心者向けの解説にまとめました。
なお、速さだけが目的なら、入れない判断もあります。DNS を移すと、サイトだけでなくメールや外部サービスの確認用の設定まで影響が及ぶからです。速さはサーバーとサイト側の改善で足りることも多く、その手順はLCP 改善の具体策とWordPress 高速化の定番施策で扱います。
導入を2段階に分けた全体の流れ
導入は、DNS を移す日と、サイトの通信を Cloudflare に通す日に分けました。DNS を移す日は全部の設定を「DNS のみ（グレー）」にしておけば、今のサイトの動きは何も変わりません。その間に、通信を通す日のための設定を済ませられます。
Cloudflare の DNS には、レコードごとに2つの状態があります。
- グレー（DNS のみ）: 住所録の答えを返すだけ。訪問者は今のサーバーへ直接つながる
- オレンジ（プロキシ）: 訪問者はいったん Cloudflare につながり、Cloudflare がサーバーへ取り次ぐ。キャッシュや守りの設定はここで効く
今回は新しいサーバーへの引っ越しと重なったので、2日目は Tunnel への切り替えになりました。今のサーバーのまま Cloudflare を通すだけなら、2日目の作業は「サイトのレコードをオレンジにする」になります。
移す前に、今の DNS を全部書き出す
最初にやったのは、Xserver の DNS に登録されているレコードを全部書き出すことです。全部で32件ありました。
そのうち3件はネームサーバー（住所録の置き場所そのもの）の行で、Cloudflare が自分で持つので移しません。残りの29件を移しました。種類は次のとおりです。
| 種類 | 役割 |
|---|---|
| サイト | ドメインと www の行き先 |
| メール | メールの届け先（MX）、送信元の確認（SPF・DKIM・DMARC） |
| アプリ用 | スマホアプリの管理システムや API の行き先 |
| メール配信 | 外部のメール配信サービスの確認用 |
| 証明書の検証用 | SSL 証明書を発行するときの確認用 |
| 所有確認 | Google のサービスなどの所有確認用 |
アプリ用のレコードは、別のサービス（AWS）にあるサーバーを指していました。自分のサイト以外を指すレコードは、Cloudflare に移したあともグレーのままにします。オレンジにすると、相手のサーバーの証明書や接続元の判定と合わなくなり、アプリが止まるおそれがあるためです。
管理画面の一覧は、長い名前が途中で切れていて読み切れませんでした。そこで AI が Xserver の DNS に直接問い合わせて正確な値を取り、読めない文字は候補を総当たりして確定しました。その値を、Cloudflare に取り込める BIND 形式のファイル（DNS の設定を書き並べた標準の書式）にまとめています。
メールとサイトが止まる所を、先に潰す
Cloudflare の画面を触る前に、別の AI に専門家の役をさせて、計画を点検させました。止まる所を先に洗い出すためです。指摘のうち、いちばん影響が大きかったのはメールでした。
メールを止めないために確かめたこと
メールは止まっても気づきにくく、届かなかった問い合わせは後から取り戻せません。今回、順に確かめたのは次の6つです。
- MX が自分のドメインを指していないか。MX はメールの届け先を示すレコードです。このサイトは MX が自分のドメイン名を指していて、そのドメインの行き先はサイトと同じサーバーでした。この形のままサイトの行き先を変えると、その瞬間からメールも新しい行き先へ向かい、届かなくなります。先に、MX をメールサーバー自身の名前に変えました
- メールに関わるレコードを1件も落とさない。MX・SPF・DKIM・DMARC と、メール配信サービスの確認用の行です。取り込んだ後に新旧の答えを比べました（次の次の章）
- メールサーバーを指すレコードはグレーのままにする。Cloudflare のプロキシが取り次ぐのはウェブの通信だけです。メールの通り道をオレンジにすると、メールが届かなくなります
- 編集部のメールソフトのサーバー名。メールソフトの受信・送信サーバーをドメイン名で設定していると、サイトの行き先を変えた日から送受信できなくなります。編集部全員の設定が、メールサーバーの名前になっていることを私が確かめました
- 切り替えの前に試しのメールを送る。切り替えの前日に新しいサーバーから試しのメールを送り、届いたメールのヘッダーで SPF・DKIM・DMARC がすべて pass になることを確かめました
- 切り替えの後も SPF が通るか。SPF に「このドメインの住所から送ったメールは正しい」という書き方が入っていると、住所が Cloudflare に変わった後はその行が別の場所を指します。今回は、メールサーバーの名前と MX の行でも通る書き方だったので影響はありませんでした
メールを止めないいちばんの近道は、サイトの行き先を変える前に、MX とメールソフトのサーバー名を「メールサーバーの名前」にそろえておくことです。なお、DNS を移してもメールのアカウントやパスワードは変わりません。メールは今のサーバー会社に置いたままです。
サイトとアプリを止めないために
サイトとアプリについての指摘は3つでした。
- DNS を移す日は全部グレーにする。オレンジにすると、Xserver の管理画面が海外からの接続を止める設定にはじかれて入れなくなる、Xserver の無料 SSL が更新できなくなる、アプリ側が証明書の不一致で動かなくなる、の3つが起こりえます
- 自動の読み取りに頼らない。Cloudflare には今の DNS を自動で読み取る機能がありますが、
_で始まる名前や深い階層の名前は拾えません。手で打ち込むのも写し間違いのもとなので、ファイルで取り込みます - 反映まで旧 DNS を消さない。ネームサーバーの変更が行き渡るまで最大2日ほどかかり、その間は古い DNS に問い合わせる人もいます。Xserver 側の DNS は残しておきます
DNSSEC（DNS の答えに署名する仕組み）は使っていなかったので、今回は対応していません。使っている場合は、移す前に今の管理画面で外しておく必要があります。
Cloudflare にドメインを追加し、レコードを取り込む
ここからが Cloudflare の画面での作業です。AI がブラウザを操作し、私は画面を見ながら要所で止めて確かめました。
- ドメインを接続する（AI）。Cloudflare のホームから「ドメインを接続」を選び、ドメイン名を入れる
- AI クローラーの設定を決める（AI、方針は人）。検索・エージェント・トレーニングの3つとも「許可」のまま。その下の Bot Preference Sync はオフにした
- DNS の取り込み方を「手動で入力」にする（AI）。自動の読み取りは使わない
- プランを選ぶ（AI）。無料プラン
- BIND ファイルを取り込む（AI、確定の前に人が画面を確認）。下の落とし穴に注意する
Bot Preference Sync は、2026年8月に Cloudflare が発表した機能です。オンにすると、AI クローラーの方針で「ブロック」などを選んだときに、Cloudflare がサイトの robots.txt の先頭に行を足します。このサイトは robots.txt をサイトの側で管理しているので、決める場所を1つにするためにオフにしました。robots.txt で AI クローラーをどう扱うかは、robots.txt の書き方で扱います。
取り込み画面の落とし穴
取り込みで、いちばん危なかったのがここです。BIND ファイルを選ぶと、「プロキシにより DNS レコードをインポートしました」に勝手にチェックが入ります。このまま取り込むと、取り込んだレコードのうちオレンジにできるものが、全部オレンジで入ります。
全部オレンジで入ると、前の章で挙げた3つ（管理画面に入れない、SSL が更新できない、アプリが止まる）が、ネームサーバーを切り替えた瞬間に起こります。チェックを外してから取り込み、取り込んだ後に全レコードがグレーであることを一覧で確かめました。
取り込むと「完全に保護されていません」という警告が出ます。全部グレーにしたので、これは想定どおりです。「後で実行」を選んで進めました。
新旧の DNS で答え合わせしてから、ネームサーバーを変える
取り込んだら、すぐにネームサーバーを変えたくなります。その前に、Xserver の DNS と Cloudflare の DNS に同じ問い合わせを投げて、答えが同じかを確かめました。
問い合わせは56通りで、AI が両方に投げて答えを並べました。違いは、意図して変えた MX の1件だけでした。
手で確かめる場合は、dig コマンドで問い合わせ先のネームサーバーを指定して、両方の答えを比べます。
# 旧（今のサーバー会社）の DNS に聞く
dig @ns1.example-old.jp example.jp MX +short
# 新（Cloudflare）の DNS に聞く
dig @xxx.ns.cloudflare.com example.jp MX +short例のドメインとネームサーバー名は、自分のものに置き換えてください。少なくとも、サイト（ドメインと www）、MX、SPF などの TXT、アプリ用の名前は比べておくと安心です。
答えがそろったら、ドメインを登録しているムームードメインでネームサーバーを Cloudflare の2台に変えます。
アカウントには多くのドメインが入っていたので、AI は絞り込みで対象のドメインだけを開いて入力しました。最後に出る確認のポップアップは、ブラウザの仕様で AI からは押せません。取り消しにくい最後の確定は、私が入力内容を見てから押しました。
反映は、AI が5分おきに .jp の登録情報を確かめて見張りました。14時38分に新しいネームサーバーが返るようになり、Cloudflare の画面が「保護されています」に変わりました。
反映の後に確かめたのは、サイトの表示（全部グレーなので、まだ今のサーバーが直接応答します）、メールサーバーへの送信・受信の接続、DKIM の値です。どれも変わりありませんでした。
オレンジにする前に、設定を済ませておく
切り替えの前日（DNS を移した2日後）に、オレンジにする日のための設定を入れました。設定はオレンジのレコードの通信にしか効かないので、全部グレーの間なら今のサイトに影響を出さずに準備できます。設定のたびに、今のサイトがこれまでどおり応答することを確かめました。
| 設定 | 決めた値 | 理由 |
|---|---|---|
| SSL/TLS の暗号化モード | フル（厳格） | サーバー側にも有効な証明書がある。「フル」は証明書の中身を確かめない |
| 常に HTTPS を使用 | オン | http で来た人を https へ送る |
| Rocket Loader | オフのまま | jQuery を前提にしたテーマが壊れる |
| メールアドレスの難読化 | オフ | ページのメールアドレスの書き方が変わる |
| ブラウザ キャッシュ TTL | 既存のヘッダーを優先 | サイト側のキャッシュの指定を上書きしない |
| Bot Fight モード | オフのまま | アプリが RSS を取りに来る通信を止めない |
| APO・Cache Everything | 使わない | ログイン中の画面が他人に配られる事故を防ぐ（下で説明） |
| www の転送 | www なしへ 301 | URL を1つにそろえる |
「フル（厳格）」では、Cloudflare がサーバーの証明書を確かめ、期限切れや名前の違う証明書ならつながりません。サーバー側に正しい証明書があるなら、こちらを選びます。HTTPS 化そのものの手順はHTTPS 化の手順で扱います。
WebP の画像は Cloudflare に保存させない
このサイトは、同じ画像の URL で、WebP に対応したブラウザには WebP を、対応していないブラウザには JPEG を返しています。Cloudflare の標準のキャッシュは URL を鍵に保存するので、最初に保存された形式が、ほかの人にも配られるおそれがあります。
そこで、/wp-content/ の JPEG と PNG は Cloudflare に保存しない（キャッシュをバイパスする）ルールを入れました。画像は毎回サーバーが返しますが、負荷は小さいと判断しています。
ブラウザに合わせて画像の形式を出し分けてキャッシュする「Vary for Images」もありますが、Pro 以上の有料プランの機能です。2026年7月からは、キャッシュ ルールで Vary を有効にして URL ごとに複数の版を保存する方法も無料プランで使えるようになりました。今回は手間の少ないバイパスを選びました。
ログイン中の画面を保存させない
失敗談
以前、別の案件で Cloudflare を入れたとき、ログインした後の管理画面に他人のアカウントが表示されたことがあります。ログイン中の画面を Cloudflare が保存し、別の人に配っていたのが原因でした。HTML まで全部キャッシュする設定にすると起きる事故です。
今回は、同じことが起きないように3段で防ぎました。
- HTML は Cloudflare に保存させない（APO・Cache Everything を使わない）
- サーバーの側でも、ログイン中の人と管理画面にはキャッシュを使わない
- 切り替えの直後に、HTML が保存されていないことと、別々のアカウントで自分の名前が出ることを確かめる（次の章）
切り替えの1時間以上前に TTL を下げる
最後に、サイトのレコードの TTL を 3600 秒から 60 秒に下げました。TTL は、問い合わせた答えをどれだけの間覚えておいてよいかの指定です。3600 のまま切り替えると、最大1時間は一部の人が古いサイトを見続け、その間の問い合わせが古いサイトに入ります。下げた値が行き渡るように、切り替えの1時間以上前に済ませました。
切り替え当日は、数秒でつなぎ替えてすぐ確かめる
切り替えは、DNS を移した3日後の深夜0時台です。人の OK をもらってから始めました。
- 直前の確認（AI）。新しいサーバーの準備と、DNS の設定を見直す
- OK を出す（人）。ここで私が進めてよいと伝える
- つなぎ替え（AI）。Tunnel の「公開ホスト名を追加」の画面を入力済みで開いておき、0時38分にサイトの A レコードを消して、数秒で保存した（オレンジの CNAME が自動でできる）。0時40分に www もオレンジにした
- キャッシュを全部消す（AI）。Purge Everything
- 確かめる（AI と人）。下のチェックリスト
数秒にこだわったのは、レコードが無い間に問い合わせた人のパソコンや回線が、「その名前は無い」という答えを最大30分覚えてしまうためです。この長さは、ドメインの設定（SOA）の値で決まります。
切り替えの直後に確かめたのは次の項目です。
- 主なページが表示され（200）、サーバーエラー（500番台）が0件
- 応答の
cf-cache-statusが DYNAMIC か MISS（HTML を Cloudflare が保存していない） - 検索から外す印（
X-Robots-Tagの noindex）が付いていない。robots.txt はサイトのものがそのまま返る - www 付きや http の URL が、301 で正しい URL に着く
- アプリが読むファイル（
/.well-known/の2つ、ads.txt）が表示される - サーバーの記録に、Cloudflare ではなく訪問者の本物の IP が残る（ログイン画面の回数制限が、全員まとめて効いてしまわないように）
- 2つのアカウントでログインして、それぞれ自分の名前が出る（人が確認）
- メールの SPF が、サイトの行き先を変えた後も通る
- Cloudflare のセキュリティ イベントで、アプリなどの通信がはじかれていない
- お問い合わせフォームを実際に送って、届く
ほとんどの項目は数分で確かめられました。お問い合わせフォームは、切り替えの直後は送信に失敗していました。原因は新しいサーバー側のネットワークの設定で、Cloudflare ではありません。1時15分に直し、送信から通知メールまで通ることを確かめています。画面の表示だけでは気づけないので、フォームは実際に送って確かめます。
セキュリティ イベントは、切り替えから7分後と1時間あまり後に見て、どちらも0件でした。Search Console へのサイトマップの送り直しと、古いサイトで動いていた定期処理を止める判断（2か所で同じ処理が動かないように）は人が受け持ちました。
戻し方を先に書いておく
切り替えの前に、うまくいかなかったときの戻し方も書いておきました。数分で戻せる手順です。
- Tunnel の公開ホスト名を外す
- 自動でできた CNAME が残っていたら消す（残っていると、同じ名前の A レコードを作れない）
- サイトの A レコードを古いサーバーへ、オレンジで作る
3でグレーにすると、Cloudflare の住所を覚えている人が、覚えている間（最大5分）エラーになります。オレンジなら、Cloudflare が古いサーバーへ取り次ぐのですぐに戻ります。結果として、この手順は使わずに済みました。
AI に任せた所と、人が受け持った所
今回の作業で、AI と人と機械の照合がそれぞれ受け持った所をまとめます。
| 工程 | AI | 人 | 機械の照合 |
|---|---|---|---|
| DNS の書き出し | 正確な値の取得、ファイル化 | 管理画面の一覧を出す | ― |
| 計画の点検 | 別の AI が専門家役で点検 | 方針を決める | ― |
| 取り込み | 画面の操作 | チェックの状態を確認 | 取り込み後の全件グレーを確認 |
| 答え合わせ | 問い合わせの実行 | 結果を見る | 新旧56通りの比較 |
| ネームサーバーの変更 | 入力、反映の見張り | 最後の確定を押す | ― |
| 切り替え前の設定 | 設定の操作、TTL の変更 | Tunnel の鍵をサーバーに入れる | 今のサイトの応答を確認 |
| 切り替え | つなぎ替え、確認の項目 | 直前の OK、ログインの確認 | 主なページの応答 |
| 切り替えの後 | セキュリティ イベントの確認 | サイトマップの送信、旧サイトの処理を止める判断 | ― |
Tunnel の鍵（サーバーを Cloudflare につなぐための値）は、AI が読まないように画面で私に渡させ、私がサーバーに入れました。鍵や確定のボタンのように、取り違えたときに取り返しがつかないものは人が持つ、という線を引いています。
ドメインと DNS は、止まったときの影響が広い場所です。AI に手を動かさせるなら、次の3つは外さないことを勧めます。
- 計画を、別の目（別の AI や人）に点検させる
- 結果を、人の目ではなく機械で突き合わせる
- 取り消しにくい操作と、鍵になる値は人が扱う
AI で業務を自動化する仕組みの全体はSEO 業務の自動化ガイド、人が判断する所の置き方はAI ライティングの実務で扱います。サーバーごと移すときに検索の評価を落とさない手順はサイトリニューアルの移行手順、サイト全体の構造はサイト構造の設計がまとめています。
よくある質問
DNS を移すと、メールの設定は何か変わりますか？
メールのアカウントとパスワードは変わりません。メールは今のサーバー会社に置いたままです。変わる可能性があるのは、メールソフトの受信・送信サーバーをドメイン名で設定している場合です。メールサーバーの名前に変えておきます。
切り替えの間、サイトは止まりますか？
レコードがそろっていて、つなぎ替えを数秒で済ませれば、ほぼ止まりません。今回はレコードを消してから数秒で新しい行き先を足しました。間が空くと、その間に問い合わせた人には最大30分ほど「名前が無い」と覚えられることがあります。
無料プランで足りますか？
DNS を移し、SSL と基本の守り、キャッシュのルールを入れるところまでは無料プランで足りました。画像の形式を出し分けてキャッシュする Vary for Images のように、有料プランで楽になる機能はあります。
- DNS を移す日と、サイトの通信を Cloudflare に通す日を分ける。メールは、MX とメールソフトのサーバー名を先にメールサーバーの名前へそろえる
- DNS は全部書き出して取り込み、新旧の答えを機械で突き合わせる。設定は全部グレーの間に済ませる
- 切り替えは数秒で済ませてすぐ確かめ、戻し方を手元に置く。取り消しにくい操作は人が押す
参考にした一次情報
- Say it once: introducing Bot Preference Sync Cloudflare Blog・2026-08-21、確認日 2026-11-02
- robots.txt setting Cloudflare Docs・確認日 2026-11-02
- Import and export records Cloudflare Docs・確認日 2026-11-02
- Full (strict) - SSL/TLS encryption modes Cloudflare Docs・確認日 2026-11-02
- Vary Cloudflare Docs・最終更新 2026-08-14、確認日 2026-11-02
- Vary for images Cloudflare Docs・最終更新 2026-08-14、確認日 2026-11-02
- Published applications Cloudflare Docs・Cloudflare Tunnel、確認日 2026-11-02
