Web スタック

Web サーバは多くのセルフホスト構成の心臓部です。だから FrontierStack はそれを一級の対象として扱います。Apache ペインは Homebrew 版 Apache のインストール・起動・検証・設定を行い、PHP・Localhost・Certificates・DNS の各ペインが、開発とホスティングの完全なスタックを仕上げます。あらゆる変更が検証を通るため、タイプミスがサイトを黙って落とすことはありません。

本章では、目の前の Mac で Web サイトを作り、動かすペインを扱います。そのスタックを実ドメインと公開インターネットへ繋ぐのは第 7 章、本番向けに堅牢化するのは第 10 章です。

4.1Apache ペイン

サイドバーから Apache ペインを開くと、Web サーバの状態がひと目で分かります。バージョン、起動の有無、待ち受けポート。上部のボタンが日々使う操作です — Start・Stop・Restart・Validate Config。検証は apachectl -t（本物の構文チェック）を実行し、結果を Last Result に表示するので、リロード前に変更が妥当だと確認できます。

FrontierStack は macOS のシステム版ではなく Homebrew 版 Apache を推奨します。Homebrew 版は /opt/homebrew（Intel Mac では /usr/local）以下に置かれ、brew services 経由で毎回 root を求められずに自分の権限で動き、System Integrity Protection に縛られません — だから最新の mod_php がきれいに読み込まれ、スタック全体が 1 つのツールチェーンに揃います。/etc/apache2 のシステム版は OS アップデートで消去され、Apple 同梱の libphp に縛られます。Homebrew 版 Apache が未インストールなら、ペインがワンクリックの Install Homebrew Apache… を提示します。

複数の Apache ビルド（Homebrew 版、旧来のローカルビルド、リモートサーバのもの）を併用する場合は、バイナリ選択（Add Homebrew Apache ／ Add Local Build…）で登録し、それぞれのバージョンとポートを見ながら切り替えられます。

4.2モジュール・ポート・管理対象の設定

Apache ペインの下部には、最も頻繁に編集する設定が、ファイルではなくコントロールとして並びます。

コントロールとして出ていない項目には、設定行から Edit Managed Config…（FrontierStack の include）と Edit httpd.conf…（メインファイル）を直接編集できます。保存のたびに apachectl -t で検証し、グレースフルにリロードし、新しい設定が構文エラーならロールバックします — 誤った編集は、稼働中のサーバを壊す前に捕捉されます。

モジュールを切り替えると、その LoadModule 行を書き換えて再検証します。変更で httpd -t が失敗した場合（代表例は proxy なしで proxy_fcgi を有効化するケース。アプリが自動で proxy も有効化します）、モジュールウィンドウはエラーを表示し、黙って閉じません。修正するか、Save anyway（このまま保存）を選びます。Apache が固まって起動しない場合（Homebrew の典型的な Bootstrap failed: 5: Input/output error。既にロード済み、または sudo brew services が httpd のパスを root 所有にしてしまったのが原因）、ペインの Recovery & reset（復旧とリセット）セクションに 3 段階の対処があります：Restart cleanly（ユーザとシステム両方の launchd ドメインで httpd を停止してから 1 回だけ起動）、Reset config to default（httpd.conf をバックアップして Homebrew の既定を復元）、Remove & Reinstall（root 所有のパスを消して formula を再インストール）。いずれもアプリ内コンソールで実行され、sudo プロンプトと出力を確認できます。Service Watchdog のキープアライブが Apache に対して有効な場合、httpd を自動で再起動することがあります（想定内ですが、手動復旧と競合するなら一時停止してください）。

4.3PHP バージョンの選択

PHP ペインを開くと、Mac にインストールされた PHP ランタイムを管理できます。Homebrew は複数のメジャーバージョン（例：[email protected] から最新版まで）を併存させられ、FrontierStack はそれらを、単一のグローバルインストールではなく、切り替える集合として扱います。

Version ▸ Add Version… から、既存のものと並べて別のバージョンを追加インストールできます — 置き換えは起こらず、使用中のバージョンも変わりません。一覧は 2 つに分かれます。上段は Homebrew が提供する、現在もサポートされているリリース。下段はサポート終了のビルド — PHP 8.0 から 5.6 まで — で、PHP 本体の修正提供が終わり Homebrew からも削除されたものです。これらは コミュニティの shivammathur/php タップから取得するため、タップ自身のコードを実行することになり、インストールのたびに確認を求めます。サポート終了の PHP は、手元での旧来サイトのテストや保守に留め、公開インターネットに向けては使わないでください。

選択は 2 つに分かれます。

• Apache モジュール。Apache ペインの PHP Module セクションの Load for websites ピッカーで、Apache が読み込む libphp.so のバージョンを選びます。変更すると管理対象設定を書き換えて Apache をリロードします。
• サイトごとの PHP。ローカル開発サーバ（下記 Localhost ペイン）には、インストール済みの全バージョンを並べた独自の PHP Version ピッカーがあり、あるプロジェクトを古い PHP で、別を最新で動かせます — マシンの他の部分が使うものを変えずに。旧来アプリと新規アプリを同時に成り立たせる、いつもの方法です。これは PHP 内蔵サーバと Apache ランタイムの両方に効きます。Apache は mod_php 経由で配信するため 1 点だけ注意があります。そのバージョンの keg が libphp.so を同梱している場合にのみ使用でき、選んだものが該当しないときはエディタが知らせます。その場合は内蔵サーバで動かすか、PHP-FPM 経由で配信してください。

PHP キャッシュ。PHP ペインの PHP キャッシュセクションで、キャッシュなし・OPcache・OPcache + APCu から選びます。OPcache は各スクリプトのコンパイル結果を共有メモリに保持し、ページを高速化します。APCu はアプリが直接呼び出すキー・バリューキャッシュ（apcu_store／apcu_fetch）を追加し、WordPress のオブジェクトキャッシュプラグイン、Laravel、Symfony が利用します。OPcache のメモリ量と変更ファイルの確認を設定します。リクエストごとは開発向けで、編集したファイルが次の再読み込みで反映されます。確認しないは本番向けで、コードの変更は再起動後にのみ反映されます。APCu は PECL 拡張なので、初めて選ぶときは APCu をインストールを押します。キャッシュ設定を適用で php.ini を書き換えて Apache を再起動します。PHP-FPM で配信しているサイトは、プールの再起動時に変更が反映されます。

Runtime Health ペインはより広い全体像を示します — PHP に加え Python・Node.js・Java・Go・Rust・Ruby・Perl・.NET — 欠落やサポート終了のランタイムを、問題になる前にフラグするセルフチェック付きです。

Runtimes セクションにはフロントエンド向けの React ペインもあります。新規アプリのスキャフォールド（Vite・TanStack Start・Next.js）、任意の React プロジェクトの指定、そして役割別に整理された厳選ライブラリ一覧を提供します — 状態管理（Zustand・Jotai・Redux Toolkit）、データ取得とサーバ状態（TanStack Query — 旧称 React Query — と SWR）、フルスタックフレームワーク（TanStack Start・Next.js）、ルーティング、バリデーション（ArkType・Zod）、フォーム、認証（Clerk）。各行にはドキュメントへのリンク、選択中プロジェクトでの使用状況、そのプロジェクトへのワンクリック npm install が並びます。

4.4古い Mac の PHP を MacPorts でアップデート

古い Mac（macOS 10.13 High Sierra 以前。Apple の Server.app を使っている機種を含む）では、今も Apple 標準の PHP が動いています。High Sierra では PHP 7.1 で、2019 年以降セキュリティ修正が出ていません。Homebrew はこれほど古い macOS をサポートしていませんが、MacPorts はまだ対応しています。MacPorts で最新の PHP を Apple の PHP と並べてインストールし、コマンドラインと Web サイトをそちらへ切り替えます。コマンドはその Mac のターミナルか SSH で実行します。変更を伴う port コマンドにはすべて sudo が必要です。「attempt to write a readonly database」と表示されたら sudo の付け忘れです。リンク済みのサーバなら、AI 管理者に手順を案内させることもできます。

1. ターミナルから MacPorts を使えるようにする。/opt/local/bin/port があるのに port が「command not found」になる場合は、MacPorts のインストーラが PATH の設定行を書き込んでいません。~/.bash_profile（シェルが読み込むのが ~/.profile ならそちら）を開き、「MacPorts Installer addition」というコメントを探します。その行と「Finished adapting」の間に何もなければ、次の行を追加して、ターミナルのウインドウを開き直します。

export PATH="/opt/local/bin:/opt/local/sbin:$PATH"

2. MacPorts をアップデートして現状を確認する。最後のコマンドで、MacPorts が提供する PHP 8 系のバージョンが一覧表示されます。

sudo port selfupdate
port installed 'php*'
port echo 'name:^php8[0-9]$'

3. 新しい PHP と拡張機能をインストールする。例は PHP 8.4 です。サイトが今使っているものと同じ拡張機能を入れてください。port installed 'php80-*' で旧バージョンの拡張機能を確認できます。

sudo port install php84 php84-fpm php84-mysql php84-openssl
sudo port install php84-curl php84-intl php84-mbstring php84-gd php84-zip
sudo cp /opt/local/etc/php84/php.ini-production /opt/local/etc/php84/php.ini

新しい php.ini で date.timezone を設定します。MacPorts は通常ビルド済みのものをダウンロードします。ソースからのコンパイルになった場合は 1 時間ほどかかることがあり、Apple のコマンドラインツール（xcode-select --install）が必要です。

4. コマンドラインを切り替える。

sudo port select --set php php84
hash -r; php -v

php -v が 8.4 と表示されれば完了です。Apple の /usr/bin/php は 7.1 のまま残るため、フルパスで指定している cron ジョブやスクリプトは、/opt/local/bin/php に書き換えるまで古いバージョンで動きます。

5. Web サイトを PHP-FPM に切り替える。Apple の Apache は MacPorts の mod_php を読み込めません（MacPorts 独自の Apache 向けにビルドされているため）。代わりに PHP を FastCGI サービスとして動かします。

cd /opt/local/etc/php84
sudo cp php-fpm.conf.default php-fpm.conf
sudo cp php-fpm.d/www.conf.default php-fpm.d/www.conf

php-fpm.d/www.conf で、macOS の Apache が動作するアカウントである user = _www と group = _www を設定します。PHP-FPM は 127.0.0.1:9000 で待ち受けます。lsof -iTCP:9000 -sTCP:LISTEN でそのポートが既に使われているとわかったら、別のポートを選んでください。今すぐ起動し、起動時にも自動で立ち上がるようにします。

sudo port load php84-fpm

次に、.php ファイルを PHP-FPM に渡すよう Apache に設定します。下の内容を、末尾が .conf のファイル（例：zz-php84-fpm.conf）として保存します。Server.app の Mac では /Library/Server/Web/Config/apache2/other/ に置きます。Server.app のない Mac では /etc/apache2/other/ に置き、/etc/apache2/httpd.conf の mod_proxy と mod_proxy_fcgi の LoadModule 行の先頭にある # を外します。

<FilesMatch "\.php$">
    SetHandler "proxy:fcgi://127.0.0.1:9000"
</FilesMatch>

この設定は Apple の PHP モジュールを削除しなくても優先されるので、Server.app の PHP 設定はそのままで構いません。Apple の設定では .html ページも PHP で処理されますが、PHP-FPM が処理するのは .php だけです。ほかの拡張子も処理させるには、ここと www.conf の security.limit_extensions の両方に追加します。

6. 設定を確認して Web サーバを再起動する。Server.app の Mac では次のとおりです。

export SERVER_INSTALL_PATH_PREFIX=/Applications/Server.app/Contents/ServerRoot MODULE_INSTALL_PATH_PREFIX=
httpd -t -D WEBSERVICE_ON -f /Library/Server/Web/Config/apache2/httpd_server_app.conf
sudo serveradmin stop web; sudo serveradmin start web

Server.app の Apache は独自のプロセス ID ファイルを使うため、apachectl graceful は使わないでください。Server.app のない Mac では sudo apachectl configtest を実行してから sudo apachectl graceful を実行します。確認結果が「Syntax OK」以外なら、再起動する前にファイルを修正してください。

7. 動作を確認する。<?php phpinfo(); と書いたファイルをサイトのフォルダに置き、ブラウザで開きます。Server API が「FPM/FastCGI」、バージョンが 8.4 になっていれば成功です。このファイルはサーバの設定を誰にでも見せてしまうので、確認後は削除してください。

4.5「古い Mac サーバのモダナイズ」ペイン

Apple の Server.app をまだ動かしているリンク済みの Mac には、古い Mac サーバのモダナイズペイン（セットアップと移行）が上記の手順を実行し、さらにその先まで進めます。サーバを選んでサーバをチェックを押してください。まずサーバで実際に動いているサービスを調べ、該当するセクションだけを表示し、省いたセクションも示します。ボタンを押すまで何も変更されず、変更はすべてコンソールで実行されるので進行を確認できます。

1. システムディスク — システムが HDD から起動しているときに上部に表示します。内蔵、または Thunderbolt・USB 3・FireWire 800 の外付け SSD のうち、その機種で最速の方法で SSD に移します。
2. MacPorts — MacPorts をインストールまたはアップデートし、ターミナルの PATH に追加します。
3. PHP 8.4（PHP-FPM） — Apple の PHP と並べて PHP 8.4 をインストールし、Web サイトを切り替えます。古い php.ini の上限値を引き継ぎ、Deprecated 通知を隠し、前後に各サイトのホームページを確認し、壊れたら自動で元に戻します。 PHP-FPM のプールは（PHP の初期設定の 5 ワーカーではなく）Mac のメモリに合わせて調整されます。ワーカー数をメモリに合わせるで、実際のワーカーのサイズから調整し直せます。
4. ヘルスチェック — 各サイトに応答した PHP、失敗、表示されている PHP のメッセージ、頻度の高い PHP エラー。
5. コード更新 — PHP 8 向けの機械的な修正（$s{0} のオフセット、each() ループ、リテラルの create_function()、マジッククォート、error_reporting(E_ALL)、オプトインの短縮 <? タグ）。残りは AI 管理者に任せます。
6. Apache の移行（任意）— ペインのほかの機能はすべて Server.app の Web サービスのままで使えるので、残すこともできます（Server.app の Web を残す。一括実行はこれに触れません）。または、今も修正が出ている MacPorts の Apache にすべての Web サービス（serviceproxy と、その後ろの Server.app 自身の Apache。Apple の PHP の停止後。フロントエンドのみテストは serviceproxy だけ）を移せます。serviceproxy を廃止は Apple の PHP の停止と同じ方法で、すべてのサイト、Server.app のサービスのパス、ページ、ファイルを前後で名前を挙げて両方のフロントエンドから取得し、フォルダの index ページ以外のスクリプトは開かず、応答が一つでも違えば serviceproxy をすぐに戻します。serviceproxy を戻すで元に戻せます。
7. Server.app のサービス — サービスプロキシ（ポート 80/443）を動かし続け、設定が壊れている場合はむやみに再起動せずに報告するガード。Apple の BIND がまだ動いている環境では、Cloudflare か MacPorts の最新 BIND への移行を案内します。Server.app の L2TP VPN が動いている場合は、ユーザを WireGuard、OpenVPN、Tailscale に移してからオフにするよう勧めます。
8. ディレクトリ（LDAP と Kerberos） — 匿名での読み取り、LDAPS の証明書、Kerberos の弱い暗号化の確認。ディレクトリのポートをプライベートネットワークに限定する pf のルール。Open Directory の暗号化アーカイブを毎晩作成。
9. パスワード推測のブロック — 第 18 章で説明するメールのブロックと、SSH・画面共有・Kerberos・Web サイトのログインガード。Cloudflare 経由の攻撃は Cloudflare のレート制限ルール用にサイトごとに一覧表示します。
10. メール認証（DKIM） — OpenDKIM、ドメインごとの鍵、DNS に鍵が載ってからの署名。レコードはペインから公開、コピー、または AI に依頼できます。
11. メールの TLS — TLS 1.2 以降のみ。自己署名の代わりにこの Mac で発行した Let's Encrypt の証明書。
12. メールの DNS — ドメインごとの SPF（参照回数付き）、DMARC、DKIM、TLS-RPT、MTA-STS。DMARC の quarantine 化と TLS-RPT はペインから、SPF の修正と MTA-STS は AI と行います。
13. 迷惑メールのフィルタ — X-Spam ヘッダを追加するだけの rspamd。
14. リモートアクセス（Tailscale） — macOS 10.13 用に用意した 1.44.3 のビルドで、誰もログインしていなくても起動時に始まるシステムサービスとして Tailscale を動かします（ビルドが対応するより古いサーバにはインストールしません）。tailnet の通信が本当にトンネルを通っているかも確認します。Tailscale.app が同時に動いていると経路を取り合い、終了すると経路も消えます。Tailscale.app を停止はアプリを終了し、ログイン時の起動をオフにしてデーモンを再起動します。
15. 新しい curl・rsync・OpenSSL — Apple のもの（Server.app は引き続きこれを使用）と並べて /opt/local にインストールします。
16. 管理用ポートのファイアウォール — 画面共有、Remote Desktop、ポート 311、AFP、SMB（任意で SSH）が、プライベートネットワーク、Tailscale、FrontierStack の接続元にだけ応答するようにします。FrontierStack が新しい接続で確認しない限り、ルールは 10 分以内に自動で元に戻ります。
17. ファイルの整合性 — 起動ジョブ、sudoers、pf、ssh 鍵、cron、Server.app と Apache の設定、サイトの PHP を root 専用の SHA-256 で毎日確認します。変更があったとき、またベースラインが知らないうちに置き換えられたときに FrontierStack がアラートします。変更を承認で現在のファイルを新しいベースラインにします。
18. ClamAV によるセキュリティスキャン — オープンソースのスキャナ ClamAV をこのペインがインストールしてスケジュール実行します。定義ファイルを毎日更新し、Web サイトを毎週スキャン（報告のみ）したうえで、Web シェルのコードとアップロードフォルダ内の PHP を確認します。迷惑メールフィルタ経由で受信メールのウイルススキャンも任意で行えます。
19. OpenSSH — 新しい OpenSSH をインストールし、Apple のホスト鍵でポート 2222 で動かしてログインをテストしてから、ポート 22 を切り替えます。切り替えには別の接続手段が必要で、FrontierStack が再接続して確認しなければ自動で元に戻ります。
20. このサーバの周囲のネットワーク — リンク済みのファイアウォールとサブネットから、前段の OPNsense の Suricata と Zenarmor、Web アプリケーションファイアウォールを置く場所、VPN 経由のみの管理、同じネットワークにあるマシンを読み取ります。
21. セキュリティチェックリスト — TLS、SPF、DMARC、DKIM、逆引き DNS、サービスプロキシ、SSH ログイン、OS のサポート状況。それぞれ直すペインにリンクします。

PHP を最新の修正に保つ。ペインはサーバの PHP を php.net にあるそのブランチの最新リリースと比べるので、PHP がセキュリティリリースを出したその日に、MacPorts のパッケージ化を待たずに警告します。MacPorts にまだない間は、警告にもそう表示されます。MacPorts に入ったら、PHP 8.4 をアップデート（インストールのボタンをもう一度実行）で PHP のポートをアップグレードし、PHP-FPM を再起動するので、古いコードのまま動き続けるワーカは残りません。curl・rsync・OpenSSL のアップデートも同じようにそれらのポートをアップグレードし、MacPorts のセクションにはサーバ上で古くなっている MacPorts のツールがすべて表示されます。MacPorts のインストーラは、macOS 26 と 27 を含め、MacPorts が対応するすべての macOS で動きます。セキュリティのチェックリストでは、Apple の PHP のままの Web サイトが不合格の項目になります。Apple の PHP は 2019 年から修正がなく、mod_php として Apache の中で動くため、リモートでコードを実行される脆弱性に最もさらされやすい構成だからです。

4.6サイトとバーチャルホスト

Apache ペインの Websites リストがバーチャルホストの管理場所です。各行にサイト名、バインドアドレス、ポート（例：:8080）、そしてライブ状態を示す Running トグルが表示されます。ボタンで Add Site…、編集、複製、無効化、Push to Server…（連携サーバへ vhost をコピー）、ブラウザで開く、が行えます。Import Sites… と Copy from… は、MAMP・XAMPP・Apple の Server.app・別の Apache から既存 vhost を取り込み、既定で localhost にバインドします。

サイトの追加・編集では、vhost が必要とする要点を設定します。ServerName（ドメイン）、document root（フォルダを Choose…）、バインドのアドレスとポート。サイトを有効化するとライブ状態ドット付きで一覧に現れます。FrontierStack は vhost を管理対象ツリー下の .conf ファイルに書き込み、検証し、リロードします。vhost・証明書・Cloudflare DNS レコードをまとめて作るには New Site + DNS… を使います — 第 7 章で解説する一括ウィザードです。

4.7サイトの TLS 証明書

Certificates ペインは、サイトに鍵マークを付ける証明書を発行・管理します。用途に応じた 3 つの方法があります。

発行後、Deploy to Apache が証明書をサイトの vhost に組み込みます。Expiry Monitoring セクションは証明書（および Watch で追加した任意のドメイン）を監視し、期限切れの十分前に通知します — HSTS や最新の暗号方針を含むより深い堅牢化は第 10 章です。

4.8証明書の更新 — この Mac とリンク済みサーバ

Installed Certificates の各証明書には、発行元と残り日数が表示されます。行の アップデート… でその場で更新でき、その証明書に合う方法だけが選べます。自己署名で再発行（既定では同じ秘密鍵、最長 397 日）、certbot または acme.sh で更新（クライアント自身のデプロイフックが動きます）、mkcert で更新、そして他で購入した証明書のための ファイルから置換… です。以前のファイルは .bak として新しいファイルの隣に残り、同じ手順で Web サーバをリロードすることもできます。

リンク済みサーバがあると、ペイン上部に ホスト ピッカーが表示されます。サーバを選ぶと、ペインが SSH でその証明書を読み込みます。対象は Let’s Encrypt、acme.sh、/etc/ssl、nginx・Apache・Caddy・HAProxy の証明書フォルダです。秘密鍵が隣にある証明書だけを表示します。アップデートと 作成… もそこで使えます。変更はサーバに保存した sudo パスワードで root として実行するので、パスワードがなければそのサーバは読み取り専用で表示されます。

インストール済みの証明書は、この Mac でもリンク済みサーバでも 自動で監視 され、期限前に アラート が警告します。設定は不要です。各行のベルで監視のオン・オフを切り替えられ、最初に見つけた時点ですでに期限切れの証明書は対象外になります。

4.9.htaccess エディタ

ディレクトリ単位の Apache ルール（リライト・リダイレクト・アクセス制御）は .htaccess ファイルに置かれます。FrontierStack はそれ専用のエディタを、行番号と構文の妥当性チェック付きで提供します。Use Site Root でサイトの document-root の .htaccess を開くか、custom path を指定します。Insert Recipe は、よくある正しいスニペット（フロントコントローラのリライト、HTTPS 強制ブロック）を挿入するので、記憶ではなく動くルールから始められ、保存前に明らかな問題をフラグします。Export PHP Router… は .htaccess のリライトルールを、組み込み PHP 開発サーバ用のルータファイルに変換します — サイトを Localhost ペインに移すときに便利です。

4.10Nginx とリバースプロキシ

FrontierStack は Nginx を、代替の Web サーバとして、またはアプリの前段のリバースプロキシとして管理します。両方がインストールされていると、Domains ビューはサイトをサーバごとに分類し — Apache のバーチャルホストと Nginx の server ブロックを並べて — 各 Nginx server ブロックの listen ポート・root・TLS 状態を読み取ります。リバースプロキシは、高位ポートで HTTP を話すアプリ（Node・.NET・Python のサービス）の前に立てる標準パターンです。Nginx が 443 で TLS を終端し、アプリへ転送します。Apache も Nginx も既定で 80/443 を欲しがるため、併用する場合は Apache ペインの Ports セクションで一方をそこから外してください。

4.11Localhost・DNS・開発スタック

ローカルの全体像を完成させる、もう 3 つのペインがあります。

• Localhost — 即席のローカル開発サーバのマネージャ。New Local Server を追加し、Runtime（PHP・Python/Django・Node/Vite、または専用の Apache・Nginx・Caddy…）とフォルダを選び、ポートと任意の ServerName を設定して Start。サーバごとの Environment Globals と .test リゾルバで myapp.test がローカルに解決されます。Free Port ヘルパーと localhost を掴んでいるものを止める操作で、よくある競合を解消します。Tailscale でも公開をオンにすると、他の Tailscale デバイスからこの Mac のテイルネットアドレス（同じポート）で接続できます — サーバ自体は localhost のみで待ち受け、FrontierStack がテイルネットからの接続を転送するため、LAN からは到達できません。Django サーバでは Tailscale ホストを許可…が、変更内容を確認したうえでテイルネットアドレスをプロジェクトの ALLOWED_HOSTS に追加します（設定が環境変数から作られている場合は、追加すべき行を表示します）。AI 管理者（および MCP 経由のエージェント）も debug_share の action serve で同様にフォルダを起動でき、返答に localhost のホストとポート、指定時は Tailscale の URL が含まれるので、エージェントはサイトの稼働場所を報告できます。
• DNS — ローカルの名前解決と権威ホスティング。dnsmasq・unbound・nsd を実行し、ゾーンファイルをインポート／エクスポートし、レコード変更時にリゾルバをフラッシュして、Mac が古い応答を返さないようにします。
• LAMP / DevStacks — ワンクリックのスタック。LAMP ペインはプリセット（Choose a Setup）を提供し、揃ったコンポーネント一式をまとめてインストール・起動（Install & Start・Start All・Stop All）。DevStacks はプロジェクトフォルダのフレームワークを検出し、それを動かす適切なコマンドと npm スクリプトを表示します。

Localhost の概観は、稼働中のローカルサーバをすべて並べて表示するので、世話の焼ける Terminal ウィンドウの壁なしに、多数のサイトを同時に動かせます。

4.12サイトの公開とエージェントへの引き渡し

各ローカルサーバの詳細にはインターネットアクセス欄があります。Cloudflare のホスト名を選び、自分のゾーン上の名前（例：demo.example.com）を入力すると、FrontierStack がルートと DNS レコードを追加し、cloudflared をシステムサービスとして動かします。アプリを閉じても再起動後もアドレスは維持されます。管理者パスワードを求めるのは最初のサイトだけで、以降のサイトは同じトンネルをそれぞれ別のホスト名で共有します。ほかに一時リンク（trycloudflare.com）と Tailscale Funnel も選べます。Vite と Django は知らないホスト名を拒否しますが、Cloudflare 経由では代わりに localhost を渡すので、そのまま動きます。

同じ地球ボタンは Apache ▸ ウェブサイトの各行（トンネルは ServerName でサイトを指定）と、カタログサービス、Docker コンテナ、Vagrant、Spin アプリにもあります。

ホスティング設定…（Localhost ペインと、設定 ▸ ウェブサイトとホスティング）で、新しいサイトの置き場所を決めます。この Mac、Apache サイト、自分のサーバ、here.now、Hostinger、Vercel、ChatGPT Sites から選び、必要ならサイトの種類ごとに変えられます。新サイトを動かす Web サーバ（Apache・Nginx・Caddy、または毎回確認する）、新サイトに使うドメイン、作成先フォルダ、制作の担当、担当が従うデザインスキル（SKILL.md を含むフォルダ）もここに保存します。

あとは AI 管理者にサイトを頼むだけです（「パン屋の 1 ページサイト。暖色系で、営業時間と地図を入れて」）。依頼で指定していない場合やホスティング設定で決めていない場合は、まずどの Web サーバで動かすかを尋ねます——Apache・Nginx・Caddy・その他（名前を指定）。静的サイトと PHP サイトはこの Mac 上でそのサーバの専用インスタンスが配信し、その他のサーバは担当向けに記録して、プレビューは内蔵サーバで行います。そのうえで 1 回でフォルダを作り、サイト設定入りの .env（パスワードは入れません）、BRIEF.md、担当向けルールの AGENTS.md、.claude/skills のデザインスキルを書き込み、サーバを起動し、公開アドレスを付け、最初の git コミットを行います。そのうえでページを自分で作るか、隔離された Sandcastle コンテナで動く Claude Code または Codex に任せます。完了するとファイルがフォルダに書き戻され、通知が届きます。MCP で接続した外部エージェントも同じ準備を依頼し、渡されたフォルダで制作できます。