FrontierStack ユーザマニュアル マニュアル先頭
デスクトップ版マニュアル モバイル版マニュアル English frontierstack.app ↗
7

第 7

サイト・ドメイン・Web

Mac 上の vhost からレジストラ、DNS、CDN、検索エンジンまで — ドメインが本当に健全かを一目で示し、そうでないときに直すためのツール群を 1 つのペインに。

動く 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 を返すサイト。

検査項目測定方法問題の見え方
DNSホスト名の実リゾルバ検索(host/dig)と返る IP。レコードなし、または自分のサーバでないアドレス。
HTTPステータスコードを記録するライブリクエスト(curl -w %{http_code})。200–399 以外 — 404、502、リダイレクトループ。
SSL/TLS証明書の終了日を読む TLS ハンドシェイク(openssl s_client → x509 -enddate)。バッジに残日数を表示。期限切れ、まもなく期限切れ、または名前不一致。
HTTP/3サーバが Alt-Svc ヘッダで HTTP/3 を告知しているとティール色のバッジが付きます。Apache 自体は HTTP/3 を持たないため、Apache サイトでこのバッジを得る通常の方法はドメインの Cloudflare ゾーンペインにある HTTP/3 トグルです(ブラウザはエッジと QUIC で通信し、オリジンは h1/h2 のまま)。HTTP/3 は UDP 443 を使うことに注意——TCP のみのファイアウォールではブラウザは黙って HTTP/2 にフォールバックします。h3 を配信しているはずのサイトにバッジがない——エッジ設定がオフか、UDP 443 がブロックされています。
Cloudflareトークンから取得するゾーンの状態とプラン。例:active · Pro。レジストラでネームサーバを切り替えていないため「pending」のゾーン。
配信ホスト応答した IP と Server ヘッダーから判定。リモートを期待したのに「This Mac (Apache)」、あるいはオリジンを隠す「Cloudflare」。
スクリーンショット追加予定
図 7.1. Sites ペイン最上部の Domain Health ダッシュボード。各ドメインの DNS/HTTP/SSL バッジと配信ホスト。撮影手順: capture: Sites ペインを最上部までスクロールし、Domain Health セクションに 3〜4 個のドメイン、緑と橙が混在するバッジ、1 つに「CF: active · Pro」と配信ホストのラベルを表示した状態
メモダッシュボードはサイトを保存するのではなく、読み取ります。ローカル vhost は Sites の設定に、リモート vhost は各連携サーバの Apache スナップショットに、それ以外は Cloudflare とレジストラ監視に存在します。サイトを追加し、サーバを連携し、Cloudflare トークンを貼り付ければ、次の検査でここに現れます。

7.2ChatGPT 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 などを取り込みます。

注意Web 出力のセルフホスト化は、ホスト済みデータ全体のエクスポートではありません。OpenAI の公開 Sites ドキュメントには、D1 データ、R2 アップロード、ホスト済みシークレット、分析履歴、ChatGPT 専用 ID データの外部エクスポート API は記載されていません。FrontierStack はこれらの依存関係を検出し、一部を黙って置き去りにせず、所有者が別途移行する必要があることを明示します。

7.3ドメイン所有権の証明

ベンダーは、所有者にしか作成できない 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.4AI 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 レポートシートで開き、所見を読んで対処できます。

ヒントAI SEO と Fix My Site は単発・読み取り専用のハーネスを再利用するため、追加コストはかからず、変更を明示的に有効化しない限りサーバには一切触れません。コンテンツ変更の前後で SEO 監査を実行し、スコアの変化を確認しましょう。

7.5ワンクリック 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 が無いホストにはインストールを提案します。サイトをピン留めすると、更新待ち・整合性検査の失敗・新たな脆弱性をアラートが知らせます。

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。インストーラはアプリをダウンロード(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 やリモートアクセスとも自然に組み合わせられます。

7.6Domain 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、Onamae)は手動で追加しますが、RDAP は引き続き監視します。

注意失効したドメインは、再起動では直らない唯一の障害です — 一度切れると数時間で他者に取得されかねません。余裕のあるリマインダー期間(30〜60 日)を設定し、レジストラのアラートを実際に読むチャネルに接続してください。これはアプリ全体で最も安価な保険です。
ドメインの購入
同じペインに Register a new domain フォームがあります。名前を入力して空き状況と価格を確認し、Porkbun または Namecheap で登録します — 購入手順は必ず先にプレビューし、確認したときだけ課金されます。AI も domain_check(読み取り専用)と domain_register ツールで実行でき、後者は明示的な確認の背後にゲートされています。登録には、保存済みのレジストラ認証情報と、一度だけ記入する登録者連絡先プロフィールを再利用します。

7.7Cloudflare:ゾーン・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.8ホスティングプロバイダ

運用するものすべてが Mac 上にあるわけではありません。Hosting カテゴリは VPS とマネージドのプロバイダを同じウィンドウに取り込みます。VPS プロバイダ — DigitalOcean、Vultr、Linode、Hetzner、さくら ほか — は API トークンでサーバを公開します。貼り付ければ、ペインが各サーバをプラン・ロケーション・状態・IP とともに一覧し、確認付きで起動・停止・再起動できます。ダッシュボード型のプロバイダ(Hostinger のようなマネージドホスティング)はトークンを保存し、コントロールパネル・ドキュメント・サインアップへのクイックリンクを示します。いずれの場合も認証情報は Keychain に保存され、SSH で到達できるサーバはフリートの一部になります(第 8 章)。

7.9IndexNow:検索エンジンへの即時送信

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

メモIndexNow は IndexNow 参加エンジンを対象とします。Google は IndexNow を使いません — Google 向けには、FrontierStack が gsc_verify_domain と index_site ツールでドメインを Search Console に確認し、サイトマップを送信します。Google にサインインしていれば自動で行われます。各 Domain Health 行の Index ボタンは両方の経路を一度に駆動します。

7.10サイト転送:マシン間でのコピー

手作業の 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.11新しい 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 を立て、証明書を発行し、フリートにクローンできます — 課金やシステム変更を伴う各手順は、必ず先にあなたの承認のためプレビューされます。

セキュリティすべてのプロビジョニングツールは変更を伴うためゲートされています。Allow changes がオンで、あなたがアクションを承認しない限り、ゾーン作成・DNS レコード書き込み・証明書発行・ドメイン購入のいずれも実行されません。Cloudflare とレジストラのトークンはローカルのボールトに留まり — 実行時に注入され、モデルには決して送られません。完全な信頼モデルは第 13 章を参照してください。

FrontierStack ユーザマニュアル · バージョン 1.0.0 · 第 7