サイト・ドメイン・Web

動く Web サイトとは、ただ Apache が起動していること以上のものです。ドメインが名前解決され、証明書が有効で、正しいマシンが応答し、その前に CDN が立ち、検索エンジンがその存在を知っている必要があります。FrontierStack はそのすべてを Sites ペインと小さなツール群に集約し、レジストラ・DNS・TLS・CDN・ホスト・SEO という連鎖全体を 1 つのウィンドウから可視化し、修正できるようにします。本章はスタックの上にある Web を扱います。vhost と証明書そのものは第 4 章を参照してください。

7.1Sites ペインと Domain Health

サイドバーから Sites を開きます。最上部には Domain Health セクション、つまり FrontierStack が把握するすべてのホスト名を集めたライブダッシュボードがあります。定義済みのローカル Apache・Nginx vhost、連携サーバ上の vhost、トークンにあるすべての Cloudflare ゾーン、レジストラ監視のすべてのドメインです。各ドメインには状態バッジ付きの行が並び、行の Check、またはヘッダーの Check All を押すと、アプリがドメインを端から端まで検査し、バッジを緑または橙に色付けします。

このダッシュボードの目的は、1 つの問いに確実に答えることです — このドメインは本当に配信されているか、どこから配信されているか？ 検査は公開インターネットに対して実行されるため（実際の DNS 検索、実際の HTTP リクエスト、実際の TLS ハンドシェイク）、ローカルの設定確認では決して見えない障害を捉えます — 誤った IP を指すレコード、期限切れの証明書、「pending」のまま固まった Cloudflare ゾーン、名前解決はできるが 502 を返すサイト。

7.2サイトごとの Search Console・アナリティクス・Ahrefs

Domain Health の各行には、ヘルスバッジの下に Search Console・GA4・Ahrefs の 3 つのチップを並べた行があります。灰色はそのサイトで未設定、緑は有効で問題なし、黄色は要確認、オレンジはアラートも出る問題です。チップにポインタを重ねると検出内容を表示し、クリックするとそのサービスのペインを開きます。ベンダーのコンソールを再現するものではありません。サイトごとに「サービスは有効か」「所有者が知るべき問題はないか」の 2 点に答えます。

確認できる内容は、接続しているサービスによって増えていきます。

• キーが無くても、公開中のトップページ、robots.txt、ドメインの TXT レコードを読み取ります。Google アナリティクスと Tag Manager のタグ、Ahrefs Web Analytics のスクリプト、Google と Ahrefs の確認トークンを検出します。トップページに noindex（meta タグまたは X-Robots-Tag ヘッダ）がある場合や、robots.txt が Googlebot・AhrefsBot・AhrefsSiteAudit をサイト全体から締め出している場合は警告します。何も収集しなくなった旧 Universal Analytics（UA-）のタグも指摘します。
• Google にサインインしていれば（Search Console ペインのGoogle でサインイン、またはサービスアカウントキー）、各サイトを Search Console プロパティと照合し、次の点を確認します。
  • プロパティの所有権確認がまだ有効か
  • 送信済みのサイトマップにエラーがないか
  • Google の URL 検査でトップページがどう判定されているか（取得できたか、robots.txt や noindex でブロックされていないか、インデックスされているか）
  • 検索の表示回数が前週比で急減していないか
  同じサインインで、ウェブストリームの URL またはページが実際に送信している測定 ID からサイトを GA4 プロパティと照合します。プロパティがデータを受信しなくなった場合や、ページの送信先がプロパティの想定と異なる測定 ID の場合に警告します。
• Cloudflare トークンがあれば、ゾーンのファイアウォールイベントを読み、過去 1 日に WAF・レート制限・ボットのルールにブロックされた Googlebot・AhrefsBot・AhrefsSiteAudit のリクエストを探して、原因のルールを表示します。対象は Google と Ahrefs 自身のネットワークからのリクエストだけです。Googlebot を名乗るだけの偽物を Cloudflare がブロックするのは正常な動作なので、報告しません。

6 時間ごとに再確認するほか、チェックやすべて確認を押したときにも確認します。問題はアラートの検索・アナリティクスグループに、サイトとサービスの組み合わせごとに 1 項目として送られるため、解決すると復旧も通知されます。Ahrefs の問題は、実際に Ahrefs を使っているサイトでのみ通知します。使っていないクローラのブロックは障害ではなく選択だからです。

7.3ChatGPT Sites：監視、独自ドメイン、セルフホスト

ChatGPT Sites セクションは、FrontierStack 内のどこでも同じ一覧を使います。公開された name.openai.chatgpt.site URL を貼り付けると、他のサイトと同様にドメインヘルス、SEO、アラートの対象になります。ワークスペースまたは所有者限定 Site は非公開に設定すると、サインイン画面を障害と誤認しないよう外部プローブを停止します。

Import or Move には、所有者が選ぶ 2 つの経路があります。Use my domain は ChatGPT 上のホスティングを維持します。まず Site の ChatGPT 設定でドメインを追加し、ChatGPT が示す正確な DNS レコードをコピーします。FrontierStack は各レコードが選択した Cloudflare ゾーン内にあることを検証して DNS のみで公開します。別の DNS プロバイダでは、そこでレコードを追加して Save Domain を使います。どちらも元の Sites アドレスとカスタムドメインを記録します。DNS 反映後、ChatGPT に戻ってドメイン状態を更新します。

Self-host は Site のローカルプロジェクトフォルダから始めます。FrontierStack は .openai/hosting.json と package.json を読み、フレームワークと完成済み出力フォルダを特定し、D1／R2 バインディングと環境変数例の名前だけを表示して、確認済み Web 出力を管理対象 Apache ドメインへコピーします。パッケージスクリプトや秘密値は実行・読取せず、リンクとソース管理メタデータを除外し、50,000 ファイルまたは 5 GB に制限し、失敗時に戻せるステージングフォルダを使います。先にプロジェクトをビルドし、index.html を含む dist、build、out、public などを取り込みます。

7.4ドメイン所有権の証明

ベンダーは、所有者にしか作成できない DNS TXT レコードの公開を求めることでドメインの所有を確認します — ACME の DNS-01 チャレンジと同じ「DNS による証明」ですが、レコードの形式はベンダーごとに異なります。Domain Health 行の確認（Verify）ボタンはその形式を 1 か所に集約します。サービス — Google（Search Console／Workspace）、Microsoft 365、Meta、Apple Business Manager、Atlassian、OpenAI、Stripe、GitHub 組織、またはカスタムレコード — を選び、ベンダーのコンソールからトークンを貼り付けると、FrontierStack が TXT レコードをドメインの Cloudflare ゾーンに直接公開します。ドメインが Cloudflare トークンにない場合は、DNS ホストに追加すべきレコードをそのまま提示します。トークンだけを貼り付けても自動補完されます（Google で abc123 を貼ると google-site-verification=abc123 になります）。

シートには apex にすでに公開されている確認レコードも表示されます — このドメインが現在どのサービスに証明済みかの簡易監査です。Check DNS は公開 DNS（1.1.1.1）に新しいレコードを照会するので、ベンダー側で「確認」を押す前に証明が見えているか確かめられます。

証明書については、Let's Encrypt サービスペイン（セキュリティとシークレットカテゴリー）がもう一方のドメイン証明の常時ヘルスチェックです。ACME API・Let's Encrypt のステータスページ・ドメインの実際の証明書を監視し、ACME クライアントは残り 30 日で更新するため、証明書の更新遅延を警告します — certbot／acme.sh の自動更新の故障を、訪問者が期限切れ警告を目にする数週間前に捉えます。

7.5スパムブロックリスト：ドメイン、メールサーバ、ネットワークのパブリック IP

受信側は、公開のブロックリストに問い合わせてメールを受け入れるかどうかを判断します。Domain Health 行のブロックリスト（同じセクションは Cloudflare のゾーンのペインとメールサーバのペインにもあります）は、ドメインをドメインのリスト — Spamhaus DBL、SURBL、URIBL — で、メールサーバ（MX ホストと SPF の単一アドレス）をIP のリスト — Spamhaus ZEN、SpamCop、Barracuda、PSBL、Mailspike — で調べます。応答はリストごとに解読するので登録の理由が分かり、検索ボタンでリストの削除ページを開けます。行には最後の結果が表示されます。

同じセクションの定期チェックで、ドメインを定期確認できます：オフ・毎日・毎週・2 週間ごと・毎月。アラートを出すのは定期チェック中のドメインだけです。リストは負荷の高いリゾルバを制限するため、確認は間隔を空けて 1 件ずつ行い、アラートの巡回では実行せず、結果は再起動後も保持します。Domain Health の下のスパムブロックリストセクションには、定期チェック中のドメインが頻度と最後の結果とともに並び、アラートのスイッチもあります。

同じセクションのネットワークのパブリック IPは、固定済みのルータやファイアウォールのパブリック（WAN）アドレス — デバイスの詳細で設定した外部 IP — を独自の頻度で IP リストと照合します。ゲスト Wi-Fi や LAN のマシンがスパムを送ると、その NAT アドレスから送ることになります。そこでの登録は、内部の誰かが気づくよりずっと早く、外から分かる最初の兆候であることがよくあります。

リンク済みサーバのペインのメールサーバポリシー監査（第 10 章参照）も、そのサーバのパブリックアドレスとメールを受信するドメインについて同じ照会を行い、登録を失敗、注意を警告、応答のないリストを情報として報告します。回答は 6 時間再利用するので、ペインを開き直してもリストへ問い合わせ直しません。

7.6AI SEO と「Fix My Site」

ドメイン行のバッジのうち 2 つは、単なる診断ではなくボタンで、問題を AI 管理者に引き渡します。Fix My Site は壊れた、あるいは不調なサイトを受け取り、決まった手順でアシスタントを動かします — Host ヘッダー付きでサイトをローカルに curl して障害を再現し、関連ログを読み、Apache・PHP・データベースの稼働を確認し、最も可能性の高い根本原因と具体的な次の手順を提示します。Allow changes がオフなら助言のみ、オンなら可逆的な修正（サービス再起動、設定ファイルの誤値修正、データベース修復）を適用できます。WordPress 向けの派生版もあり、定番の白画面、「Error establishing a database connection」、壊れたパーマリンク、固まったメンテナンスモードに対応します。

SEO アクションは端末上の読み取り専用監査を実行します — アシスタントがホームページ・robots.txt・サイトマップを取得し、100 点満点で採点し、短いレポート（タイトル、メタディスクリプション、見出し、クロール可能性、構造化データ）を書き出します。結果は SEO レポートシートで開き、所見を読んで対処できます。

7.7ワンクリック CMS インストール（Apps & CMS）

WordPress は、新しいサイトのインストールと既存サイトの運用を 1 つのペインで扱います — このMacでも、任意のフリートサーバでも。この統合には意味があります。従来のインストーラペインはこの Mac にしか書き込めませんでしたが、本ペインの処理はすべて、選択したホスト上の WP-CLI で実行されるため、リモートサーバも新規インストールの正式な対象になります。ペイン下部の新しい WordPress サイトをインストールは、選択したホストへ WordPress をダウンロードし、wp-config.php を書き出し、データベースを作成し、指定した管理者アカウントでセットアップまで完了します。この Mac から何かを転送することはなく、そのパスに既存のインストールがある場合は上書きせず拒否します。新しいフォルダを配信するにはバーチャルホストが別途必要です — ローカルなら Sites ペインで、リモートならサーバ側の Web サーバで作成してください。CMS のインストールは最初の一日にすぎず、残りも同じペインが受け持ちます。ホスト（このMacまたは任意のフリートサーバ）を選び、一般的なウェブルート配下の wp-config.php を検索すると、そのマシン上の全 WordPress が、コア・プラグイン・テーマのバージョンと更新待ちの項目とともに一覧表示されます。すべて更新は、何かに触れる前にデータベースを書き出します。不具合のあるプラグイン更新は復旧できますが、失われたデータベースは戻らないからです。整合性を検査は、コアファイルを WordPress.org が公開するチェックサムと照合します。改ざんやバックドアを最も手早く見つける方法です。無料の WPScan トークンを追加すれば、インストール済みプラグインとコアを脆弱性データベースと照合し、修正が未公開のものを明示します。マルチサイトではサブサイトも一覧します。各サイトにはプラグインを追加の一覧もあります。予約・コマース・メール配信・バックアップ・キャッシュ・セキュリティを網羅した厳選カタログで、ローカルでもリモートでも、そのサイトへ直接インストールでき、インストール後に有効化するかも選べます。この一覧は WordPress.org ディレクトリの写しではありません。掲載するのは、壊れたときに目に見えて失敗するもの、または FrontierStack が別の場所ですでに監視している何かを生み出すものだけで、稼働後にアプリが何を把握できるかも各項目に明記しています。インストールが、存在しない監視をほのめかすことはありません。すでにサイトに入っているものは「インストール済み」と表示され、二重に提示されることはなく、WordPress.org のスラッグを持たない有料プラグインは代わりに配布ページへリンクします。WordPress サイトがまだ無いホスト（または WP-CLI が無いホスト）でも、カタログはグレー表示・選択不可の状態で一覧されるため、空のペインに出会うことなく、何が使えるようになるかを確認できます。残る作業は、通常なら SSH とうろ覚えのコマンドを要するものばかりです。ロックアウトされた管理者のパスワード再設定、ドメイン移行のための検索置換（WP-CLI はシリアライズされた PHP 内の URL も正しく書き換えます。単純な SQL 置換ではデータが壊れるため、必ず予行演習から）、ステージングへの複製、データベースの書き出しと最適化です。複製はファイルをコピーし、複製側に専用のデータベースを与え、その中の URL を書き換え、検索エンジンよけを設定します。ステージングが本番に書き込んだり、検索順位で上回ったりすることはありません。すべて SSH 経由の WP-CLI で動作し、WP-CLI が無いホストにはインストールを提案します。サイトをピン留めすると、更新待ち・整合性検査の失敗・新たな脆弱性をアラートが知らせます。

GoDaddy から移したサイト。GoDaddy のマネージド WordPress はすべてのサイトに必須（must-use）のシステムプラグインと Memcached 用の object-cache.php を入れ、旧来のホスティングでは wp-config.php に gd-config.php の読み込みを加えます。どれもほかのサーバでは動かず、GoDaddy のバックアップを戻すと白い画面やデータベース接続エラーで止まるのが典型です。ペインは更新時にこれを見つけて「GoDaddy の残り物を取り除く…」を表示します。ファイルは wp-config.php のコピーと一緒にサーバの ~/frontierstack-godaddy-leftovers へ移され、読み込み行はコメントアウトされ、同じフォルダへデータベースを書き出したあと、仮ドメイン *.myftpupload.com のままのリンクをサイト自身のアドレスに向けます。これらのファイルが基盤そのものである GoDaddy 自身のサーバでは実行しません。

WordPress が自前のマシンではなくマネージドホスティングにある場合も、ホスティングの各ペインがサイトを一覧します。WP Engine・Kinsta・Cloudways・Pressable は API 経由でインストール（環境・主要ドメイン・状態）を取得し、Cloud Servers で VPS インスタンスと並べて集約されるため、運用中のすべてを 1 つのインベントリで把握できます。これらはマシンではなくサイトなので、電源操作はありません。

Apps & CMS セクションは、その他のセルフホスト CMS を Apache／PHP／MySQL スタックに 1 つのフローでインストールします。各アプリは専用ペインを持ちます：Drupal・Joomla・Statamic・Grav・Kirby・Craft CMS・FreshRSS。同じインストーラを使う Magento Open Source は E-Commerce に分類されています。インストーラはアプリをダウンロード（Composer ベースの Statamic・Craft は composer create-project）してドキュメントルートに展開し、データベースが必要なもの（Drupal・Joomla・Craft）はデータベースとユーザを作成して設定を所定の場所に書き出します。フラットファイル CMS（Grav・Kirby・Statamic）はデータベース不要です。続いてアプリのセットアップ／管理ページ（/admin・/panel・/cp・/admin/install など）を開いてアカウントを作成でき、周辺の vhost・PHP・信頼された HTTPS は FrontierStack が設定します。インストール先フォルダは、Apache が既に管理しているサイトをメニューから選ぶ（ドメイン・ドキュメントルート・ポートを自動入力）か、選択…で新しい空フォルダを指定できます。新しいフォルダには対応する vhost が作成され、既存サイトのドメインなら更新されます。不具合時は上記の Fix My Site（AI） でデバッグします。

FreshRSS だけは最後まで仕上げます。セルフホストの RSS／Atom リーダで、上記の CMS と違いセットアップウィザードは一切残りません。ペインでアカウント名とパスワードを指定すると、インストーラはリリースをダウンロードし、データベースを作成し、FreshRSS 自身のコマンドラインインストーラで設定を書き出してスキーマを構築し、そのアカウントを作成して、p/ を指すバーチャルホストを登録します。p/ は FreshRSS が実際に配信するサブフォルダで、残りのコードは本来あるべきウェブルートの外に置かれます。ブラウザはインストールの第一歩ではなく、動作するリーダのログイン画面を開きます。API が Google Reader 互換のため、公開すれば Reeder や NetNewsWire などのモバイルクライアントと同期でき、本書の他章で扱う HTTPS やリモートアクセスとも自然に組み合わせられます。

Magento Open Source も別の理由で最後までインストールします。Magento はブラウザ用インストーラを廃止したため、コマンドラインからしか入れられません。ペインは bin/magento setup:install に必要な情報（管理者のユーザ名・パスワード・メールアドレス・氏名、ストアの通貨、稼働中の OpenSearch（または Elasticsearch 8）のアドレス）を集め、発見に時間のかかる問題を先に確認します。PHP が 8.2 より古い、Magento の拡張が欠けている、検索サーバが応答しない、MySQL のバージョン、の各点です。そのうえで composer create-project を実行します。取得元は既定でキー不要の Mage-OS ミラー、または Marketplace のアクセスキーを使う Adobe の repo.magento.com で、キーはこの 1 回のダウンロードだけに使い保存しません。ダウンロードは数百のパッケージからなり、通常 5〜15 分かかります。続いてデータベースを作成し、入力したアカウントでセットアップを実行し、Magento が実行時に書き込むフォルダをウェブサーバから書き込めるようにして、pub/ を配信するバーチャルホストを登録します。管理画面は /admin_k3x9qz/ のようなランダムなパスになり、ログに表示されブラウザで開きます。Magento は通常、すべての管理者にメールのリンクから 2 段階認証を設定させます。メールを送れないローカルのテストストア向けに、これをオフにするトグルがあります（.local・.test の名前では最初からオフ）。ダウンロード後にセットアップが失敗した場合は、原因を直してインストールをもう一度押すと、再ダウンロードせずにデータベースの手順から再開します。最後に、Magento はインデックス作成やメール送信を cron で行うため、ストアが動いたらインストールフォルダで bin/magento cron:install を実行してください。

同じペインでライセンス版の Adobe Commerce（オンプレミス）もインストールできます。エディションを Adobe Commerce にし、ライセンスを持つアカウントの Marketplace アクセスキーを入力します。このエディションは repo.magento.com からしかダウンロードできないためです。MySQL settings for Magento セクションは、選んだインスタンスから 3 つの値を読み取ります。バイナリログが有効な間（MySQL 8 の既定）は必須の log_bin_trust_function_creators（ないと Magento のインデクサが作るトリガを MySQL がエラー 1419 で拒否します）、64 MB 以上の max_allowed_packet、チェックした場合は 1 GB の InnoDB バッファプールです。適用は SET GLOBAL でその場で設定し、日時付きのバックアップを横に保存してから、インスタンスの my.cnf の [mysqld] に書き込みます。再起動で黙って元に戻ることはありません。サイズは増やすだけで、別ホストのサーバには編集せず追加すべき行を示します。インストール時にも同じ処理を行います。インストール後は、ペインにストアのライブ売上モニタも表示されます。Adobe がホストする Adobe Commerce on Cloud Infrastructure・Adobe Commerce as a Cloud Service・Adobe Commerce Optimizer はカタログのサービスで、それぞれ専用のモニタがあります。

ペインの名前は Magento で、3 つのタブがあります。この Mac は上で説明したインストーラです。ストアは、この Mac やフリートのどのサーバ上でも、FrontierStack が把握するすべての Magento ストアを管理します（ストアを探すでサーバのウェブルートを検索）。各ストアについて、バージョンと新しいセキュリティパッチの有無、デプロイモード、ストアフロントの応答、メンテナンスモード、cron がインストールされているかと最後のジョブの完了時刻、古くなったインデクサ、無効なキャッシュ、サーバ上での既定の /admin/ パスや 2 段階認証の欠如、今日の例外を、重大なものから順に報告します。ボタンでキャッシュのフラッシュ、再インデックス、インデクサモードの切り替え、メンテナンスの切り替え、デプロイモードの変更、メンテナンスページを出したままの安全な setup:upgrade、cron のインストール、管理者のロック解除、ログの表示ができ、常にストアのファイルの所有者として実行します。ストアを修復（AI）はストアを AI エージェントに渡し、エージェントは ecommerce ツールで同じ情報を読み、1 つずつ承認できる変更を提案します。

サーバでホストは、稼働するストアへのワンクリックの道です。Ubuntu 24.04 以降または Debian 12 以降のサーバ、ドメイン、管理者アカウントを選ぶと、FrontierStack は 11 の段階を順に表示しながら進めます。サーバの確認（メモリ、ディスク、ポート 80 にほかのサービスがないこと）、Nginx・PHP-FPM・MySQL または MariaDB・Composer・Redis のインストール、ループバック専用の OpenSearch のインストール、Magento 用の MySQL 設定を含むデータベースの作成、専用の PHP-FPM プールを持つ magento ユーザの作成、Composer での Magento のダウンロード、setup:install の実行、Magento 自身の nginx.conf.sample からの Nginx サイトの構築、本番モードへの切り替え、cron のインストール、Let’s Encrypt の証明書の取得です。所要時間は 20〜40 分です。サーバの root 権限が必要で、生成したパスワードは非公開ファイルで渡され、最後に削除されます。段階が失敗するとその理由を示して止まります。原因を直してストアをホストを再度押せば、完了済みの段階はスキップされます。新しいストアは通知がオンの状態でストアタブに加わります。

7.8Domain Registrar 監視

Sites はドメインが今日動くかを教えます。Domain Registrars ペイン（DNS カテゴリ）は、それが動き続けるかを教えます。ドメインを追加すると FrontierStack は次の 3 つをスケジュールで監視し、いずれかがずれるとアラートを発します。

• 有効期限 — 登録の終了日、レジストラ、ネームサーバ。RDAP で取得（whois フォールバックあり）。レジストラを問わずあらゆるドメインで機能します。
• DNS — ドメインがまだ名前解決されるか（dig）。
• SSL — 証明書の有効期限。openssl で直接確認。

更新警告は、有効期限がリマインダー期間内、すでに過ぎている、または自動更新がオフのときに発火します。対応レジストラでは、ペインがドメイン一覧と自動更新の状態を API で取り込めます — GoDaddy、Porkbun、Gandi、Value Domain、Route 53（AWS CLI 経由）、Cloudflare（Cloudflare トークンを再利用）。使える一覧 API がないレジストラ（Namecheap、Squarespace、お名前.com、ムームードメイン）は手動で追加しますが、RDAP は引き続き監視します。

7.14.1ドメイン会社：レジストラの稼働監視

Cloudflare のゾーンからは、ドメインの登録をどこが持っているかは分かりません。FrontierStack はピン留めした各ゾーンを RDAP で照会し、ゾーンペインのドメイン会社セクションにレジストラと現在のネームサーバを表示します。Cloudflare ペインの各ゾーン行にも active · Pro · registered at GoDaddy のように表示されます。ドメインの背後にあるレジストラと DNS ホスト（GoDaddy、Namecheap、Porkbun、Gandi、Squarespace、DNSimple、Route 53、Value Domain、お名前.com、Name.com、Hover、Dynadot、IONOS、OVHcloud、さくらインターネット、Cloudflare）を 5 分ごとに次の 3 つで確認します。

• 公式ステータス — 各社のステータスページ（Statuspage／Instatus の JSON、Route 53 は AWS の RSS）。ページに載っていれば、ドメイン・DNS・メール・ホスティング・SSL・サイトビルダーなどサービスごとの状態も表示します。
• 到達性 — Web サイトと API ホストが応答するか。
• ネームサーバ — まだその会社に委任しているドメインについて、ネームサーバが応答するか。

サイドバーのゾーンの横に黄色の建物アイコンが出たらレジストラか DNS ホストが不調、赤なら停止です。会社をピン留めすると（ゾーンペイン、ゾーンのコンテキストメニュー、ドメインレジストラのドメイン会社一覧から）サイドバーに専用の行ができ、停止時はドットが点滅します。停止するとドメイン会社アラートが発生します。ステータスページのない会社は到達性だけで判定し、この Mac がどの会社にも到達できないときは誤った障害ではなくオフラインと表示します。

7.14.2ドメインを Cloudflare へ移す

Cloudflare トークンを設定していれば、レジストラに API がある場合は次の 2 つをワンクリックで行えます。

• DNS のみ — まだ Cloudflare にないドメインは、ドメインレジストラの「Cloudflare DNS に追加…」でゾーンを作成し、現在の公開レコードをコピーしてピン留めします。レコードを確認したら、ゾーンのドメイン会社セクションの「ネームサーバを切り替え」で、GoDaddy・Porkbun・Gandi・DNSimple・Route 53 に Cloudflare の 2 つのネームサーバを設定し、Cloudflare に有効化の再確認を依頼します。その他のレジストラではコピー用に 2 つのネームサーバを表示します。
• 登録そのもの — 「Cloudflare へ移管…」は、ドメインの現在の状態を読むチェックリストを開きます：Cloudflare で DNS が有効、60 日ロックの対象外、移管ロック解除（GoDaddy・DNSimple・Route 53 はロック解除ボタンあり）、認証コード（Route 53・Gandi から取得、DNSimple はメール送付）。最後のステップで Cloudflare の移管ページを開き、そこで 1 年分の更新料を確認・支払います（移管の開始に使える API は Cloudflare にありません）。

7.9Cloudflare：ゾーン・DNS・キャッシュ・トンネル・保護

Cloudflare ペインは、API トークンを貼り付け、どのゾーンをサイドバーに表示するかを選ぶ場所です。Pin to sidebar したゾーンはそれぞれ独自のペインになり、そのゾーンの Cloudflare／DNS／HTTP／SSL 健全性、DDoS・ボット保護、WAF ルール、Workers、CDN 分析、開発モード、キャッシュパージ（全体・URL リスト・プレフィックス単位）を備えます。トークンのスコープは慎重に — 読み取り専用トークンはゾーンを一覧できますが、DNS 編集、証明書の DNS-01 検証、開発モード、キャッシュパージ、ゾーン作成にはそれぞれ専用の権限が要り、新規ゾーンの作成にはアカウントレベルの Zone · Zone · Edit 権限が必要です。「トークンを作成…」ボタンは、アプリが使うすべての権限が入力済みの状態で Cloudflare のトークン作成フォームを開きます（任意のアカウントレベルのゾーン作成権限だけは手動で追加が必要です）。「トークンをテスト」ボタンは実際の API を検査して、トークンがこれらの権限のうちどれを持ち、どれを欠くかを一覧表示します（読み取りは直接実行、書き込みは意図的に無効なリクエストで検査するため、何も変更されません）。Dashboard ボタンは現在のゾーンの Cloudflare Web コンソールへディープリンクします。

ピン留めしたゾーンに警告が出たり HTTP チェックが応答しなくなったときは、ペインの診断ボタンが、色付きドットで終わらせずに原因を突き止めます。配信経路の各レイヤを順に調べます — Cloudflare 上のゾーン状態、公開ネームサーバ、DNS 解決、エッジ経由の HTTPS（Cloudflare の 52x エラーを解読：521 オリジン停止、522 タイムアウト、524 アプリまたはデータベースのハング、525/526 オリジン TLS）、オリジンサーバのポート 80／443 への直接プローブ、そして FrontierStack がそのドメインを配信していると把握しているマシン（この Mac ならローカルの Web サーバ、連携サーバならオンホストモニタのサービス状態 — 停止中の mysql はレポートにそのまま現れます）。公開経路が壊れている場合はフリートもスイープします。どの連携サーバが稼働中か、どれがオリジン IP をバインドしているか、どれがこのドメインの vhost を既に配信できるか — オフラインになってサイトの玄関口 IP を道連れにしたホストを名指しし、引き継げるサーバも提示します。各レイヤの合否を表示し、どのレイヤが壊れ、どう対処すべきかを平易な結論としてまとめます。

Cloudflare はアプリの随所に登場します。AI の dns_record ツールは管理ゾーンにレコードを書き込み、既存レコードのその場更新 — サブドメインのプロキシ（オレンジクラウド）と DNS のみの切り替えを含む — もでき、issue_certificate は Cloudflare DNS-01 で検証でき、email_auth_dns は SPF／DMARC を公開できます（第 13 章）。同じアカウントは、ローカルサイトを公開する Cloudflare DDNS と Cloudflare トンネルも支えます — どちらも第 9 章で扱います。

7.14.3サイトが攻撃を受けたとき：Under Attack Mode

ピン留めした各ゾーンのペインの先頭には「攻撃を受けている」ボタンがあります。ゾーンを Cloudflare の Under Attack Mode（セキュリティレベル under_attack）に切り替え、すべての訪問者がオリジンに到達する前に数秒のブラウザチェックを受けるようにします。ほとんどのリクエストフラッドはこれで止まります。オンの間は JavaScript を実行できないもの — API クライアント、Webhook、モバイルアプリ、死活モニタ — もブロックされるため、オンにする前に確認があります。同じ操作はサイドバーのゾーンの右クリックメニュー（攻撃を受けている…）と Cloudflare ゾーンミニパレットにもあり、ペインを探さずに実行できます。サイドバーの赤い盾とパレットの攻撃中バッジで対象ゾーンがわかります。解除は確認なしでオフにし、以前のセキュリティレベルに戻します（FrontierStack 以外でオンにされた場合は medium）。トークンには Zone · Zone Settings · Edit が必要です。AI 管理者も cloudflare_dev_mode の action=under_attack で同じ操作ができます。

7.14.4Email Routing と Email Service

ゾーンペインのメールセクションには、Email Routing のオン／準備状態、ルーティングルールとキャッチオール、未確認の転送先アドレス（確認されるまで転送メールは破棄されます）、直近 7 日間の Email Service イベント（失敗は強調表示）、ゾーンの MX が表示されます。メール用ホスト名がオレンジクラウドになっている場合も警告します。Cloudflare のプロキシはウェブ通信しか中継しないため、プロキシされたホストへの SMTP／IMAP は失敗します — DNS のみにしてください。メール配信モニタにも、ピン留めした全ゾーンを同じトークンで読む Cloudflare Email Service セクションがあります。トークンには Zone · Email Routing Rules · Read（転送先には Account · Email Routing Addresses · Read も）が必要です。AI は cloudflare_dev_mode の action=email_status で同じ情報を読みます。

7.14.5Core Web Vitals

ゾーンペインの Core Web Vitals セクションは、Cloudflare の無料 Web Analytics から、直近 7 日間に実際の訪問者が体感した値を表示します（ボットは除外）。

各値は 75 パーセンタイルで、「良好」だったページ読み込みの割合と緑／オレンジ／赤の評価が付きます。サイトで Web Analytics を有効にし、トークンに Account · Account Analytics · Read が必要です（「トークンを作成…」ボタンで入力済みになりました）。AI：cloudflare_dev_mode の action=web_vitals。

7.14.6レート制限と WAF ルール

ゾーンペインのルールセクションには、ゾーンのレート制限ルールとカスタム WAF ルールが、アクション・制限（例：「ブロック、IP ごとに 10 秒間で 20 リクエスト超」）・式とともに表示されます。スイッチでルールのオン／オフを切り替えます。編集では名前・式・アクション・制限を変更できます。⋯メニューには、直前の編集前のバージョンに戻す「以前のバージョンに戻す」（FrontierStack が保持します）と、アプリからは元に戻せない「ルールを削除」があります。変更は適用するとすぐ Cloudflare に反映され、解析できない式は Cloudflare が何も変更せずに拒否します。

オレンジの警告に注意してください。ホスト名の条件がないルールは、Web サイトだけでなくゾーン内のすべてのホスト名に適用されます。/djs/ のような URL パスで一致するルールは、同じパスを含むメディア／画像ホストにも一致するため、1 ページを読み込む訪問者が画像の途中でエラー 1015（HTTP 429）でブロックされることがあります。レート制限はキャッシュより前に実行されるため、キャッシュ済みの画像でも防げません。エディタには、式を (http.host ne "host") and (…) で包む <host> を除外ボタンがあります。

「新規ルール…」では、レート制限・カスタム WAF ルール・キャッシュルール（一定時間キャッシュ、またはバイパス）・リダイレクトを作成できます。パスだけでなくホスト名（任意でパスの先頭部分）の入力を求めるため、新しいルールが気付かないうちに全ホストに及ぶことはありません。式を手で書いた場合も同じ警告が出ます。ゾーンにマネージド WAF・URL 書き換え・リクエスト／レスポンスヘッダのルールがあれば一覧に表示されます。これらはオン／オフ、名前変更、削除ができますが、パラメータ（キャッシュ TTL、リダイレクト先、ヘッダ）は表示のみで編集できません。変更するにはルールを作り直してください。

種類ごとに別のトークン権限（Zone WAF・Cache Rules・Single Redirect・Transform Rules）が必要で、表示には Read、変更には Edit です。不足している権限はペインに表示されます。「Cloudflare でルールを開く」でダッシュボードが開きます。AI：cloudflare_dev_mode の action=rules でルールを一覧し、action=rule_create で作成、action=rule_update で変更します（いずれも変更を許可と確認が必要）。ルールの無効化はできますが、削除はできません。

7.14.7セキュリティイベントと Bot Fight Mode

ゾーンペインのセキュリティイベントセクションには、直近 24 時間に Cloudflare がゾーンでブロック・チャレンジ・ログ記録したものが、発生源（レート制限、カスタムルール、マネージドルール、DDoS、ブラウザ整合性チェックなど）・ルール・ホスト名ごとに表示されます。カスタムルールとレート制限ルールの ID は名前で表示されます。オレンジの三角は、メインサイト以外のホスト名で訪問者が止められたことを示します（ページ向けのルールにメディアや画像ホストが引っかかっている場合が典型）。画像が表示されない、エラー 1015 や 429 が出ると言われたら、まずここを確認し、ルールで修正してください。

一覧の下の Bot Fight Mode は、Cloudflare の無料のボットチャレンジの表示と切り替えです。オンにする前に確認があります。正当なボット・フィード・Webhook・モニタをブロックすることがあり、無料プランではルールで除外できないためです。Zone · Analytics · Read が必要です。AI：action=security_events と action=bot_fight。

7.14.8ホスト名ごとのキャッシュ

ゾーンペインのホスト名ごとのキャッシュセクションには、直近 24 時間の各ホスト名のリクエスト数と、キャッシュ可能なリクエスト（HTML と API 応答は除く）のうち Cloudflare がキャッシュから返した割合、そしてキャッシュから返されなかった上位ファイルが表示されます。ゾーン全体のヒット率では、まったくキャッシュされない画像ホストが隠れてしまいますが、ここでは見えます。100% を大きく下回るホストは、キャッシュルールがない、オリジンが Set-Cookie や Cache-Control: no-store を返している、またはルールがキャッシュに届く前にリクエストをブロックしている、のいずれかが多いです。AI：action=cache_hosts。

7.14.9Workers

アカウントペインの Workers セクションには、各 Worker とそのルート、直近 1 日のリクエスト数・エラー数・99 パーセンタイルの CPU 時間、そしてプランの公表されている使用枠（Workers Paid は月 1,000 万リクエスト、Free は日 10 万リクエスト）に対する使用量のバーが表示されます。70% でオレンジ、90% で赤になります。Account · Workers Scripts · Read、Workers Routes · Read、Account Analytics · Read が必要で、「トークンを作成…」ボタンで入力済みになります。AI：action=workers。

7.14.10プランと通知

アカウントペインのプランと通知セクションには、アカウントのサブスクリプション（プラン、料金、状態、更新日）と通知ポリシーが表示され、ポリシーが 1 つもない場合は警告します。その場合、障害・証明書の期限切れ・Workers の使用量を知らせるものがありません。表示のみで、請求と通知でダッシュボードが開きます。Account · Billing · Read（入力済み）と Account · Notifications · Read が必要です。後者にはトークンテンプレートのショートカットがないため、手動で追加してください。AI：action=plan_usage。

7.14.11Turnstile ウィジェット

Turnstile は、登録・ログイン・問い合わせフォーム向けの Cloudflare の無料 CAPTCHA 代替です。Cloudflare ペインの Turnstile セクションにはウィジェットが一覧表示され、それぞれにサイトキーをコピーボタンがあります。新規ウィジェット…では名前、最大 10 個のホスト名、モード（Managed（推奨）、Non-interactive、Invisible）を指定します。新しいウィジェットのシークレットはコピーとシークレットをスクリプトシークレットに保存付きで表示され、保存すると $TURNSTILE_SECRET_<NAME> としてスクリプトから使えます。既存のウィジェットのシークレットも各行の ⋯ メニューから扱えます。シークレットキーをコピー（クリップボードは 60 秒後に消去）、シークレットをスクリプトシークレットに保存、シークレットをローテーション…です。ローテーションすると Cloudflare が新しいシークレットを発行し、古いシークレットも 2 時間は有効なままなので、それまでにウィジェットを検証するすべてのサーバに新しいシークレットを設定してください。スクリプトシークレットにある場合は自動で更新されます。サイトキーはページに、シークレットはサーバに置き、サーバが Cloudflare の siteverify で各訪問者のトークンを検証します。ウィジェットを削除…も同じメニューにあります。

7.14.12名前付きトンネル：状態・通知・Access

名前付きトンネル（第 9 章）の各行には状態行があります。Cloudflare から見たコネクタの状態 — healthy・degraded・down・inactive — に加え、この Mac で動かしているトンネルではローカルポートが応答するかも確認します。トンネルが正常でも背後のサービスが停止していれば失敗するためです。ベルをオンにすると、そのトンネルまたはサービスがダウンしたときに通知します（アラートグループネットワーク／ルーティング）。保護…はホスト名の前に Cloudflare Access のサインインを置きます。メールアドレスや @ドメインを列挙し、サインインの有効期間（1 時間〜30 日）を選ぶと、訪問者はメールで届くワンタイム PIN または ID プロバイダでサインインします。FrontierStack は再利用可能な許可ポリシーとセルフホスト型の Access アプリケーションを作成します。保護中のトンネルには青い鍵が付き、Access を解除で外せます。Access にはアカウントで一度 Zero Trust を設定しておくこと（無料プランで 50 ユーザまで）と Account · Access: Apps and Policies · Edit が必要です。

7.14.13Cloudflare MCP による AI アクセス

AI アクセス（Cloudflare MCP）セクションでは、保存済みのトークンを使って AI 管理者が Cloudflare 公式の MCP サーバ（mcp.cloudflare.com）を利用できるようにします。FrontierStack にペインのない製品（WAF ルール、Workers、R2、KV、D1、Access）に役立ちます。「AI管理者にCloudflare MCPの使用を許可」をオンにして接続をテストを押します。既定では読み取り専用で、AI は Cloudflare のドキュメントと API 仕様全体を検索できるだけです。既定でオフのAPI 呼び出しを許可（execute）をオンにすると本番 API に対して JavaScript を実行できますが、実行のたびに「変更を許可」とあなたの承認が必要です。FrontierStack に接続した MCP クライアントも、hosted_mcp ツールの provider=cloudflare で同じサーバを利用できます（第 13 章のツール表を参照）。他の MCP クライアント ▸ 設定をコピーは、Claude・Cursor などのアプリ向けにトークンを含まない設定を作ります（アプリ自身が OAuth で Cloudflare にサインイン）。

7.14.14Cloudflare 開発者ツール

Cloudflare ペインの開発者ツールセクションでは、Cloudflare 公式のエージェントセットアップガイドにあるツールをインストールできます。インストールは、アプリ内コンソールで npm により Cloudflare CLI（cf、ベータ）を追加します（必要なら先に Homebrew で Node を追加）。サインイン…は cf auth login を実行し、ブラウザでアカウントを承認します（保存済みの API トークンは使いません）。Claude Code プラグインの行は、cloudflare/skills マーケットプレースを追加して cloudflare プラグイン（Cloudflare のスキルと、API・ドキュメント・バインディング・ビルド・オブザーバビリティの MCP サーバ）をインストールします。第三者のプラグインコードをインストールするため、その後 Claude Code で /reload-plugins を実行してください。この Mac に Claude Code が必要です。

7.10ホスティングプロバイダ

運用するものすべてが Mac 上にあるわけではありません。Hosting カテゴリは VPS とマネージドのプロバイダを同じウィンドウに取り込みます。VPS プロバイダ — DigitalOcean、Vultr、Linode、Hetzner、さくら ほか — は API トークンでサーバを公開します。貼り付ければ、ペインが各サーバをプラン・ロケーション・状態・IP とともに一覧し、確認付きで起動・停止・再起動できます。ダッシュボード型のプロバイダはトークンを保存し、コントロールパネル・ドキュメント・サインアップへのクイックリンクを示します。Hostinger はさらに対応が進んでいます。hPanel ▸ アカウント ▸ API の API トークンを使って、VPS の一覧と電源操作、VPS スナップショットの作成（Hostinger は VPS ごとに 1 つ保持するため、新しいものに置き換わります）、有効期限付きのドメイン一覧とホスティングのウェブサイト一覧を表示し、AI 管理者は dns_record（provider=hostinger）で DNS レコードを読み取り・設定できます。AI アクセス（Hostinger MCP）セクションでは、同じトークンで AI を Hostinger 公式の MCP サーバに接続します。書き込みを許可をオンにするまでは読み取りツールのみです。いずれの場合も認証情報は Keychain に保存され、SSH で到達できるサーバはフリートの一部になります（第 8 章）。ConoHa はコントロールパネルの API ページにある 3 つの値（API ユーザ、そのパスワード、テナント ID）でサインインし、VPS 3.0（または旧 2.0）のサーバを一覧・電源操作し、ConoHa DNS のゾーンを扱う DNS セクションを追加します。レコードはここで追加・編集・削除でき、AI も dns_record（provider=conoha）で操作できます。ConoHa DNS は ConoHa の利用者なら無料で、DNS API を持たないお名前.com で登録したドメインを API で管理する定番の置き場所です。Tencent Cloud は API キーのペア（CAM ▸ API キーの SecretId と SecretKey。SecretKey は Mac の外に出ません）で各リクエストに署名します。全リージョンの CVM と Lighthouse のサーバを一覧・電源操作し、DNSPod のレコードを管理し（AI も provider=dnspod で操作できます）、SSL 証明書を期限順に、COS ストレージバケット（ACL で公開読み取りになっているものに警告）、CDN と EdgeOne のサイト、今月の料金を表示します。国際版と中国版はアカウントが別なので、アカウントのサイトを設定してください。Tencent Cloud で登録したドメインは、ほかのレジストラと同じくドメインレジストラで取り込み、新しいドメインもそこで購入できます。Tencent が価格を提示し、アカウントの登録者プロファイルで登録して、プレビューと確認のあとで残高から支払います。

Xserver（エックスサーバー）は XServer アカウントの API キー管理で発行した API キー 1 つ（移行用の SSH 設定以外は読み取り専用で十分）で、レンタルサーバ、XServerビジネス、Xserverドメイン、Xserver VPS、Xserver VPS Cloud、XServer for WordPress を扱います。ペインはすべての契約（VPS Cloud の VPS、DB サーバ、ロードバランサ、NFS、追加 IP を含む）をプランと更新日付きで一覧し、VPS と VPS Cloud のリソースは電源操作でき、各レンタルサーバのディスクとファイル数の使用率と、期限切れや期限間近の証明書を表示し、契約を Xserver が公開している 12 か月定価付きで支出と請求に取り込み、Xserverドメインの更新をドメインレジストラに取り込みます。ライブモニタは、契約の停止、自動更新オフのまま迫る更新、上限 90% への到達、証明書の期限切れ、API キーの期限切れ間近を通知します。この Mac に移行…はレンタルサーバのサイトを手元に移します。FrontierStack が API からドメイン、ドキュメントルート、データベース、WordPress を読み取り、専用の SSH キーを登録し、各ドキュメントルートを rsync でコピーし、各データベースを、サイトの wp-config.php のパスワードによる mysqldump のライブコピーか前夜の自動バックアップから Homebrew の MySQL にコピーします。/home/xs… のパスを書き換え、WordPress ごとにローカルの MySQL ユーザを作り、サイトを Apache に追加し（公開を選ぶまでは 127.0.0.1）、DNS ゾーン、cron ジョブ、メールアカウント、切り替え手順を XSERVER-IMPORT.md に書き出します。メールは移行しません。Xserver はメールボックスもそのパスワードもエクスポートしないためです。移行の実行にはライセンスが必要ですが、一覧の取得には不要です。

7.11IndexNow：検索エンジンへの即時送信

ページが変わったとき、クローラーが気づくのを待つ必要はありません。IndexNow Manager（SEO & Marketing）は、参加エンジン — Bing、Yandex、Seznam、Naver ほか — に即座に伝えます。管理サイトの 1 つを選び、Install Key File を押すと、FrontierStack はサイトのドキュメントルートに <key>.txt ファイルを書き込み、エンジンがキー所有を確認できるようにします。Verify で配信を確認します。あとは単一の URL を送信、pending キューを一括送信、またはサイトマップから供給し、スケジュールで自動送信もできます。すべては api.indexnow.org に送られ、参加エンジンへ展開されます。URL のホストは選択中のサイトとそのキーに一致している必要があります。

7.12OpenSEO と DataForSEO：自分の SEO ツールキット

OpenSEO（SEO & Marketing）は Semrush や Ahrefs のオープンソース代替です。キーワード調査、順位トラッキング、競合分析、被リンク、サイト監査、AI 可視性を備え、AI エージェントが同じデータを使える MCP サーバもあります。ペインはまずどこで動かすかを尋ねます。

• ホスト版 — app.openseo.so。無料で試用でき、プロジェクト支援は月額 $10。SEO データは OpenSEO クレジット（DataForSEO の価格＋28%）で課金されるため、自分の DataForSEO アカウントは不要です。
• この Mac の Docker — セットアップして開始で ghcr.io/every-app/open-seo を取得し、http://localhost:3001 で起動します。プロジェクトは open_seo_data ボリュームに保存されるため、設定を適用して再起動（キーやポートの変更後）とアップデート（最新イメージ）でも保持されます。OpenSEO のテレメトリは既定でオフです。OpenRouter キーを共有すると SAM エージェントを有効にできます。
• 他所でセルフホスト — 既存インスタンスの URL を入力するか、Cloudflare にデプロイ…を押します。FrontierStack はリポジトリを取得し、DataForSEO キーと Cloudflare Access で許可するメールアドレスを所有者のみ読める .env.selfhost に書き込み、アプリ内コンソールで pnpm deploy:selfhost を実行します。初回は Cloudflare へのサインインがあり、OAuth スコープのカスタマイズに「はい」と答えて access:write を有効にします。表示された Worker URL を Instance URL に貼り付けます。

ライブ監視はインスタンスの /api/health を読みます。ここには DataForSEO キー、データベース、認証モード、AI、Search Console のセットアップチェックが並びます。アラートを受け取るを固定すると、失敗したチェックでアラートが出ます。oseo_ API キーを貼り付けると MCP エンドポイントで検証されるため、失効したキーも検出できます。AI エージェント欄では MCP URL、claude mcp add コマンド、Claude Desktop／Cursor 設定をコピーできます。API キー版はシェルの $OPENSEO_API_KEY を読むため、FrontierStack がキーをクリップボードに置くことはありません。

DataForSEO は OpenSEO のデータソースで、独自のライブ監視を持ち、OpenSEO ペインにも組み込まれています。app.dataforseo.com ▸ API Access の API ログインとパスワード（ダッシュボードのパスワードではありません）を入力するか、ログインを空にして長い Base64 資格情報を貼り付けます。監視はプリペイド残高、本日の利用額、API 呼び出し数を表示し、本日の利用額がしきい値を超えたときや、設定した下限を残高が下回ったときにアラートできます。セルフホスト版 OpenSEO も同じ資格情報を使うため、入力は一度で済みます。

7.13サイトの複製：マシン間でのコピー

サイトの複製ペイン（セットアップと移行）は、Web サイト（ファイルと MySQL データベース）を現在の場所から別の場所へ、番号付きの 4 つの手順でコピーします。サイトの現在の場所（この Mac、ピン留めしたサーバ、または SFTP／FTPS で接続するホスティングアカウント）と、コピーの行き先（この Mac、ピン留めしたサーバ、新しいサーバ…、またはホスティングアカウント）を選びます。サイトとデータベースを探すは、サーバの Web サーバが公開しているフォルダとデータベースを一覧にするので、入力せずに選べます。新しいサーバは複製の開始時に SSH で連携され、サイドバーにピン留めをオンにするとその後もほかのサーバと一緒に残ります。データベースは 1 回だけコピーするか、MySQL レプリカとして同期し続けることができます。同期では、複製元にレプリケーション用ログインを作成し、バイナリログの位置がわかるダンプを読み込み、そのデータベースだけを運ぶレプリケーションチャネルをコピー側で開始します。確認は何も変更せずに先に両側をテストし、レプリカを妨げるもの（8.0.23 より古い MySQL、オフのバイナリログ、127.0.0.1 でしか待ち受けない複製元）を示します。

ほかにも、手作業の rsync なしにサイトを移す 2 つのツールがあります。Copy Websites Between Apache はローカルのケースを扱います — Mac に複数の Apache インストール（例えば Homebrew のものと古い Server.app のもの）があるとき、ソースのインストールを選び、移したいサイトにチェックを入れると、FrontierStack はそのドキュメントルートと vhost 定義を、現在選択中の Apache にコピーします。同じドメインのサイトは上書きされるので、移行後の再取り込みにも使えます。

サイトを別のマシンへ移すには、AI の promote_site ツールがローカルサイトを指定したフリートホストにクローンします — ドキュメントルートをアップロードし、向こう側に vhost（Apache または Nginx）を書き、Web サーバをリロードし、新しいホストを指す Cloudflare A レコードを追加できます。手動のフリートプッシュと同じ手順を、1 回の呼び出しで行います。

7.14新しい Web プロジェクトのプロビジョニング

以上の部品が組み合わさり、プロジェクトのインフラをゼロから立ち上げる単一のフローになります。発想は明快な役割分担です — あなたの AI ツール（MCP 経由）がコードを担い、FrontierStack がインフラを担います。組み込みの Provision Web Project スキルが、アシスタントをレシピの順に導きます。

1. 確認 — ターゲット、特権アクセス、導入済み Apache／Nginx、接続済み DNS プロバイダを確認し、公開変更の前に不足する前提サービスを特定または導入します。
2. ゾーン — cloudflare_zone_create が Cloudflare ゾーンを作り、レジストラで設定するネームサーバを返します（トークンにアカウントレベルのゾーン作成権限がなければ率直に伝えます）。
3. vhost とフォルダ — vhost_create が Apache／Nginx サイトを定義します。ドキュメントルートが未指定なら、FrontierStack がプラットフォームに適した空フォルダを作成し、パスを返します。サイトのデザインやコンテンツ生成は行いません。
4. DNS — dns_record が名前をホストに向けます。
5. TLS — issue_certificate が Let's Encrypt 証明書を発行します。
6. プレビュー — localhost のテスト地点のための一時的な共有（第 9 章）。
7. プロモート — 任意で promote_site がフリートホストにクローンします。

ドメインの登録は domain_register でこのレシピの先頭に加えられるため、エージェントは原理的に、名前を買い、ゾーンを作り、vhost を立て、証明書を発行し、フリートにクローンできます — 課金やシステム変更を伴う各手順は、必ず先にあなたの承認のためプレビューされます。