Apple が macOS Server.app を終了したとき、Mac ユーザは Web サイトやサービスを手軽に運用する手段を失いました。FrontierStack はそれを取り戻し、さらにその先へ進みます。Apache・PHP・MySQL・PostgreSQL・Nginx をはじめ 1,000 を超えるサービスを、目の前の Mac でも、連携したすべてのサーバでも、インストール・制御・保護・監視します。そして、ツールを使う AI 管理者が舵を取ります。

本マニュアルはデスクトップアプリの完全リファレンスです。iPhone／iPad アプリについては別冊のモバイル版マニュアルを参照してください。まず本章を通してお読みください。その後は必要なパートへお進みください。

1.1FrontierStack とは

FrontierStack はネイティブの macOS アプリです — Web パネルでも、世話の焼けるコンテナでもありません。実際のマシン上の実サービスを、それぞれが標準で備えるツール（Homebrew フォーミュラ、launchd・systemd ユニット、Apache・Nginx の設定、証明書、ファイアウォール、SSH）を使って管理します。次の 3 つを同時に実現します。

• コントロールパネル。検証・ライブ状態・ワンクリック修正付きで、サービスをインストール・起動・停止・設定 — 現代化した macOS Server の後継です。
• 監視・通知システム。継続的なヘルススイープがサービス・サイト・証明書・ディスク・フリート全体を見守り、トラブルの最初の兆候を、選んだチャネルへのメッセージに変えます。
• AI 管理者。あなたの構成を正確かつライブに把握する、ガードレール付きのツール使用アシスタント。何が壊れているか診断し、あなたが承認する修正案を提示し、ローカルでもフリート全体でも実行し、アプリをあなたの構成ぴったりに作り替えます。

1.2AI ファーストの設計

多くのアプリはチャットボックスを横に付け足すだけです。FrontierStack は逆です。AI は、あなたが使うのと同じ操作を行う一級のオペレータです。AI は監査済みの固定されたツール（ログを読む・診断を実行する・サービスを再起動する・証明書を発行する・ファイルを書く）を通じてのみ動作するため、その行為はすべてあなたが手作業でできることであり、システムを変更する操作はすべて、実行前にあなたの承認のため提示されます。

本番サーバを任せられるだけの安全性を支えるのは、3 つの原則です。

• 既定は読み取り専用。初期状態ではアシスタントは見るだけで触れません。変更とスクリプトは明示的なトグルで解除し、変更を伴う操作はすべて実行前に承認カードを表示します。
• 秘密情報はモデルに届きません。パスワードや API トークンはローカルの .env ボールトに置きます。スクリプトは名前で参照し、アプリが実行時に（ローカルまたは SSH 経由で）実際の値を注入します。クラウドモデルが見るのは名前だけで、値は決して見ません。ログやファイルは送信前に秘密情報を伏せます。
• AI は自前で。クラウドモデルでもローカルモデル（Ollama・LM Studio）でも接続できます。MCP 経由で自分のサブスクツール（Claude Code・Cursor）から動かせば、従量課金のトークン請求は一切ありません。

1.3対象ユーザ

FrontierStack は、Mac でサーバを運用している（あるいは運用したい）すべての方に向いています。

• MAMP や XAMPP ではなく、クリーンなローカルスタックを使いたい開発者。
• POS・CRM・EC・メール・ヘルプデスクを Mac mini でセルフホストする小規模事業者。
• 旧来の Xserve や Mac mini を macOS Server のままリモート管理で活かしたい管理者。
• 従量課金の SaaS からセルフホストへ移行したい方、あるいは Mac・Linux・BSD・Raspberry Pi のフリートを 1 つの画面から運用したい方。

1.4主要な概念と用語

本マニュアル全体で繰り返し登場する用語を、ここで一度だけ紹介します。

1.5本マニュアルの構成

マニュアルは作業の流れに沿っています。

• パート I — はじめに：インストール、初回起動、インターフェイスの概観。
• パート II — サービスの運用：Web スタック、データベース、全カタログ、サイトとドメイン。
• パート III — フリート・ネットワーク・セキュリティ：サーバ連携、ネットワークと境界、堅牢化、監視とアラート。
• パート IV — 自動化と AI：スクリプトとスケジュール、AI 管理者の全容、MCP、AI スタック。
• パート V — ビジネスとリファレンス：業種別ソリューション、設定、ショートカット、ライセンス、トラブルシューティング。

まったく初めての方は、第 2 章「インストールと初回起動」へお進みください。AI だけを理解したい方は第 13 章へ進んでも構いませんが、そこでの安全モデルは上記の概念を前提とします。

FrontierStack は他の Mac アプリと同じようにインストールできます — /Applications にドラッグして開くだけです。その先はあなた次第です。macOS が標準で出す操作ごとのパスワードプロンプトのまま動かすことも、一度だけ少数の許可を与えて以後は一切尋ねられないようにすることもできます。本章では初回起動の全体をたどり、続いて既存のローカルスタックを移行してサイトとデータベースを引き継ぐ方法を示します。

2.1システム要件

FrontierStack は署名済みのネイティブ macOS アプリです。必要なものは次のとおりです。

どれも特別なものではありません。現行の macOS を動かせる程度に新しい Mac なら、FrontierStack も動きます。

2.2ダウンロードと初回起動

アプリをダウンロードし、FrontierStack.app を /Applications フォルダに移動してダブルクリックします。アプリは Enfour, Inc.（Apple Developer チーム 6Y87KNMALP）によって署名・公証されているため、macOS は「開発元未確認」の警告なしに開きます。

1. FrontierStack を開きます。メインウィンドウが表示され、左にサービスのサイドバー、中央にヘルス概要が現れます — 第 1 章で見たレイアウトです。
2. Homebrew がまだ無い場合、それを必要とするペインはその旨を表示し、インストールを提案します。今でも後でも構いません。
3. FrontierStack は単一インスタンスを強制します。既に 1 つ開いている状態でもう一度起動しても、2 つ目が立ち上がるのではなく、既存のウィンドウが前面に出てくるだけです。これにより、2 つのウィンドウが同じサービスや設定ファイルを奪い合うのを防ぎます。

初回起動はシステムに何の変更も加えません。アプリはインストール済みのものを読み取って状態を表示するだけで、あなたが指示するまで何も起動・停止・再設定はしません。

2.3特権ヘルパー — と macOS が求める許可

サービスの起動・停止やシステム設定（Apache・Nginx・MySQL・DNS・ファイアウォール）の編集は特権操作です。初期状態では、FrontierStack はそれぞれを標準の macOS 認可プロンプト経由で実行します。つまり毎回パスワードを入力します。安全ではありますが、すぐに煩わしくなります。

任意のヘルパーがこの手間を取り除きます。これは小さな特権ツール — SMAppService デーモン — で、アプリが macOS に登録することで、毎回パスワードを再入力せずに管理操作を実行できます。インストールは意図的に行います。サイドバー下端の「インストール」の案内を使うか、ある操作が初めてそれを必要としたときのプロンプトを承認します。

1. サイドバー下部のヘルパー行で「インストール」をクリックします。
2. macOS が「ログイン項目と機能拡張」の承認を表示します（または「システム設定 ▸ 一般 ▸ ログイン項目」でバックグラウンド項目の有効化を求めます）。承認してください — これはデーモンの実行を許可するかどうかを macOS が尋ねているのであり、アプリが何かを上書きしているのではありません。
3. サイドバーの行が、ヘルパーが登録され実行中であることを示す表示に切り替わります。以後、サービスの起動／停止や設定編集は操作ごとのパスワードプロンプトなしで進みます。

ヘルパーはいつでも削除できます。その場合 FrontierStack は操作ごとの管理者プロンプトに戻ります。どちらのモードでも動作します — ヘルパーは純粋に利便性のためのものです。

2.4Homebrew のインストール

カタログの大半 — ウェブサーバ、データベース、キャッシュ、メール、多数の CLI ツール — は Homebrew フォーミュラとしてインストールされます。Homebrew は FrontierStack がそれらのサービスを取得・更新するために使うパッケージマネージャなので、Mac にまだ無ければ早めに用意しておくとよいでしょう。

サイドバーから Homebrew ペインを開きます。Homebrew が無い場合、ペインは「Homebrew isn't installed. It's the package manager this app uses to install services.」と表示し、「Get Homebrew…」ボタンを出します。インストールはアプリのアプリ内コンソールで実行されます。公式の Homebrew インストーラを走らせ、インストーラが管理者権限を必要とする時点であなた自身がコンソールにパスワードを入力します。FrontierStack はそれを取得も保存もしません — プロンプトは Homebrew 自身のものです。

Homebrew が用意できると、ペインは本格的なパッケージマネージャになります。インストール済みフォーミュラ／キャスクとそのバージョンの検索可能な表、「Install formula or cask」フィールド、未更新件数を表示する「Update All」ボタン、行ごとの「Update」／「Uninstall」操作が揃います。AI 管理者は install_homebrew と install_package ツールで同じ流れを駆動でき、これもパスワードを入力するアプリ内コンソール経由です。

2.5Command-Line PATH ペイン

FrontierStack はインストール済みツールを、シェルと同じやり方で解決して検出します。ときおり、pip・pipx・virtualenv・非標準のプレフィックスでインストールしたツールがアプリの見る PATH に無く、ツールが未インストールと報告されることがあります。Command-Line PATH ペインがこれを解決します。

• シェルプロファイル（例：~/.zprofile）を選びます。追加したディレクトリは、そのファイル内の明示的にマークされた管理ブロックに書き込まれ、PATH の先頭に追加されます — 変更を反映するには新しいターミナルを開いてください。
• 「Directories to add」では、入力するか「Choose…」でパスを追加できます。最上位のエントリが最初に検索されます。「Current PATH (effective)」はログインシェルの PATH を表示し、アプリが管理するエントリにタグを付けます。
• PATH Doctor はツールが検出されない理由を診断します。コマンド（例：mlx_lm.server、gcloud）を入力すると、アプリが見つけるか、シェルだけが見つけるか、そもそもインストールされていないかを報告します — アプリに欠けているディレクトリにはワンクリックの「Add to managed PATH」が付きます。

2.6インストールウィザード

ゼロから始めるなら、サイドバーのインストールウィザードが動くスタックへの最短ルートです。目的のユースケース — WordPress/PHP、フルスタック JS、Python/Django、Rails、静的サイト、データベース、リバースプロキシ — を選ぶと、その目的に推奨されるコンポーネント（ウェブサーバ、データベース、キャッシュ）が自動選択されます。好みに合わせて選択を調整すると、Homebrew で一式インストールします。

同じペインでは、ネイティブの Apache + MySQL + PHP スタックの状態をひと目で確認でき、Mac に既にあるオールインワンバンドル — XAMPP、MAMP、AMPPS、Local — を検出します。見つかった場合は、並行スタックをインストールするのではなく「セットアップを移行」へ誘導するので、何もかも二重に動かす羽目になりません。

2.7既存スタックの移行

すでに MAMP・XAMPP・Apple の Server.app でローカルにサイトを運用しているなら、作り直す必要はありません。「セットアップを移行」ペインがそれらのスタックを検出し、その構成要素を FrontierStack のネイティブ Homebrew スタックに取り込みます。ウェブファイル、MySQL データベース、PHP 設定、そして各サイトを定義する Apache vhost です。

1. 「セットアップを移行」を開きます。インストール済みのソース — MAMP／MAMP Pro、XAMPP、Apple Server — をスキャンし、見つかったもの（サイト、データベース、PHP の検出有無）を報告します。（AI 管理者の detect_migration_sources ツールが同じ読み取り専用スキャンを実行します。）
2. 「Sites to import」一覧を確認します。各候補はサーバ名と待ち受けポートを表示し、きれいに移行できないものは理由とともに「Skipped」に並びます。
3. 設定については、「Import All Settings」がソースの php.ini・my.cnf・nginx.conf を対応する Homebrew 設定に上書きコピーします。各ファイルの .pre-mamp.bak バックアップが残るので、比較や復元ができます。
4. 「Import Selected」を選んで移行を実行します。必要な Homebrew サービスのインストール、ウェブファイルのコピー、MySQL データベースの移行、vhost の取り込みが進む様子が、ペインにライブ進捗として表示されます。
5. 実行後は確認してください。ソースの設定は旧ツールのパスやポート（例：MAMP の extension_dir・datadir・socket、ポート 8889）を参照していることが多いため、運用に頼る前に取り込んだ設定を点検してください。

AI 管理者は run_migration でこれを一気通貫に駆動できますが、ソースを検出してあなたに確認した後でのみ — しかも変更が有効な場合のみです。

2.8データの保存場所

FrontierStack は自身の状態を予測可能な標準的な場所に保持するため、何に触れているかが常に分かり、バックアップもできます。

アプリの Apache 設定を専用の frontierstack/ ディレクトリに置くことで、FrontierStack は手作業で保守している設定を壊さずに安全に vhost を管理できます。バンドル識別子は jp.co.enfour.frontierstack です（ヘルパーと DDNS コンポーネントは .helper および .ddns のサフィックスを使います）。

アプリをインストールし、ヘルパーを決め、Homebrew を整え、古いスタックを移行したら、いよいよ実際に使う準備が整いました。第 3 章「インターフェイス」でウィンドウを詳しく案内します。サイドバー、ペイン、検索、メニューバー、そして毎日使うコントロールです。

FrontierStack は膨大な種類のサービスを管理しますが、それらを 1 つの見慣れた macOS ウィンドウで提示します。左にサービスのサイドバー、中央に選択中のサービスの画面、そしてツールバーには常時使えるツールが並びます。このレイアウトを一度覚えれば、Apache から Cloudflare ゾーンまで、本書のどのペインも予想どおりの場所に収まります。本章ではインターフェイスを端から端まで案内します。以降の章が単に「Sites ペインを開く」と言うだけで、やり方が分かるようになります。

3.1メインウィンドウ

ウィンドウは標準的な macOS の NavigationSplitView で、3 つの領域から成ります。左はサービスサイドバー。表示すると選んだすべてのサービスとツールを、カテゴリごとにまとめた、スクロール・折りたたみ可能なリストです。中央はアクティブなペイン。サイドバーで選んだものの画面で、独自のヘッダー・タブ・コントロールを持ちます。上部に渡るのがツールバー。そのボタンはどのペインにいても使えます。

ツールバーには右から左へ、検索（虫めがね、⌘F でも）、AI アシスタント（ワンド。フローティングのコマンドパレットを開きます）、現在の作業ディレクトリにターミナルを開く Shell ボタン、macOS がライトでもダークを強制するダークモード切り替え、そして選択中のペインがフロート可能なときの切り離しボタンが並びます。Setup に未保存の変更があると、ここにオレンジの未保存メニューも現れます。

サイドバーの幅は自由に設定できます。仕切りをドラッグすれば、FrontierStack は起動をまたいで記憶します。最後に選んでいたペインも再オープン時に復元され、続きから始められます。

3.2サービスサイドバー

サイドバーは 2 段構成です。上部に Overview — アプリ自身の組み込みツール（Local Health、Status Page、Alerts、Domains、Logs、Certificates、Notes、Scripts、Setups、Settings ほか）。その下に、サービスカテゴリごとのセクション — Web Servers、Databases、Caching、Mail、Networking、Security Tools、Containers、AI など多数 — それぞれカタログ（第 6 章）から表示を選んだサービスが並びます。各セクションヘッダーのシェブロンをクリックすれば折りたためます。畳んだグループはアプリが記憶します。

各サービス行は、起動中はステータスドットを表示します。サービスを右クリックすると 2 つのクイック操作が出ます。Pin to Top of Section はよく触るサービスをカテゴリの先頭に固定し、Hide はサイドバーから外します。Hide で何かがアンインストールされることはありません — サービスは動き続け、検索から到達できます。リストを散らかさなくなるだけです。

カテゴリの下には、アプリの他の場所でピン留めしたものに応じてセクションが増えます。連携サーバ（どのサービスが動いているかを示す小さなカテゴリアイコン付き）、監視中の Wi-Fi ネットワーク、Cloudflare ゾーン、Kubernetes クラスタ。サイドバー上部のフィルタ欄に入力すれば、すべてのセクションを一度に絞り込めます。

3.3Presets と Setups

サイドバーの表示を決めるのは 2 つの機能です。Presets メニュー（メニューバー）は、ユースケースを丸ごと一気に読み込む近道です。Base — show services for… セクションはサイドバーをシナリオ向けの厳選セット（Web スタック、メールサーバ、ショップ）に切り替え、Add to current view… は今ある表示にグループを追加します。Show All はすべてを表示する逃げ道で、見つからないときに使います。

Setups はさらに踏み込みます。Setup は作業ビュー全体の名前付きスナップショットです — どのサービスを隠し、どれをピン留めし、さらに開いているフローティングパレットとその位置まで含みます。Presets ▸ Save Current as Setup…（または Setups ペイン）で保存し、Presets メニュー上部で切り替えます。アクティブなものにはチェックが付きます。パレットのレイアウトはウィンドウを動かすたびにアクティブな Setup へ自動保存されるので、Setup は常に実際の働き方を反映します。表示サービスを変えると Setup は未保存（dirty）になり、ツールバーにオレンジの未保存バッジと Update・Save as New・Revert が出ます。

Setup はロケーション（第 8 章）に紐づけることもできます。「Office」の Setup をオフィスのネットワークに紐づければ、到着時に自動で切り替わります — 今いる場所に合った、正しいサービスと正しいパレットへ。

3.4フローティングパレットとミニパレット

他の作業をしながら 1 つの画面を見えるようにしておきたいことがあります。モニタ系のペインは切り離してフローティングパレットにできます。macOS の NSPanel を用いた、常に最前面に出る小さなユーティリティウィンドウで、メインウィンドウや他のアプリの上に留まります。ツールバーの切り離しボタン（または最前面のパレットを閉じる ⌘⌥⇧W）を使います。Local Health、Containers、Cloud Servers、Wi-Fi Analyzer などがフロートできます。

もっと省スペースにしたいならミニパレットがあります — ペイン全体ではなく、ひと目で分かるコンパクトな要約です。ミニは Local Health、Cloudflare Zones、Wi-Fi、Printers、Router & Network、Containers、Scripts、Message Delivery、AWS にあります。各ミニ行には、詳細が必要なときに対応するペインをメインウィンドウで開くボタンがあります。開いているパレットは Setup の一部なので、保存したビューはフローティングウィンドウを配置どおりに復元します。

3.5コマンド／AI パレット

ツールバーのワンドボタンは AI アシスタントパレットを開きます — ドラッグ可能で常に最前面の NSPanel で、何でも尋ねられる入力欄が 1 つあります（「サイトが落ちている理由は？」「MySQL をチューニングして」「使っているものだけ表示して」）。第 13 章で扱う AI 管理者そのものを、作業の傍らに置けるフローティングウィンドウとして出したものです。他のフローティングパレット同様メインウィンドウの上に留まりますが、他と違って応答し、修正を提案し — あなたの承認のもとで — 実行します。独自の会話履歴と、変更を伴う操作の承認カードを備え、あなたが許可するまで何も実行しません。

3.6メニューバー項目

FrontierStack は macOS のメニューバーに小さな項目を置けます（Show in Menu Bar で切り替え）。ウィンドウ全体を前面に出さずに操作する一番の近道です。ここから、起動グループの Start／Stop、コアサーバ（Apache、Nginx、PHP-FPM、MySQL、Postgres）の Restart や稼働中すべての再起動、ブラウザでの localhost オープン、ステータス更新、Launch at Login の設定、アプリの起動・終了ができます。

3.7アプリ内検索

検索（虫めがね、⌘F）は何にでも到達する最速の手段です。「search services, tools & actions…」と入力し始めると、ペイン・ツール・サービス・操作が入力に応じて一致します — サイドバーから隠したサービスも含めて。結果を選べばそこへ直接移動します。Semantic モードは正確な名前ではなく意味で検索でき（「IP をブロック」「ディスクを空ける」）、FrontierStack での呼び名を知らなくても機能を見つけられます。

3.8ヘルプウィンドウ

⌘? で専用の FrontierStack Help ウィンドウを開きます。アプリの構成を映した、れっきとしたアプリ内ドキュメントの本です。ヘルプは読むだけではありません。各ページには Open in app リンクが付いています。クリックすると FrontierStack がメインウィンドウをその正確なペインやサービスへ移動させます — ヘルプウィンドウは横に開いたまま残るので、手順を読みながら一歩ずつ進められます。多くのペインはヘッダーに小さなヘルプボタンを持ち、該当トピックのヘルプを開きます。

3.9Notes ペイン

Notes は資格情報・ランブック・サービスごとの手順のための、あなた専用の場所です。各ノートはタイトル・サービスタグ・本文を持ち、全体がmacOS キーチェーンで暗号化されます — 平文ファイルには保存しません。決め手となるのはノートごとのロックです。各ノートには Share with AI Administrator トグルがあり、既定はオフです。ノートがロックされている間、AI はそれを文字どおり読めません。アシスタントにその資格情報や手順を使ってほしいときだけ解除します。すると AI の list_notes に現れ、必要に応じて読まれます。

3.10Status Page

Status Page ペインは、Local Health と同じ稼働データから静的な index.html を生成して公開します。顧客や同僚がアプリにアクセスせずに何が動いているかを確認できます。公開先を選び（Apache サイトの DocumentRoot 内のフォルダにすれば /status/ のようなパスで配信されます）、ページタイトルを設定し、Include item details を入れるか決めます（詳細行は内部ホストやポートを露呈しうるので、公開ページではオフに）。ページは設定した間隔で、または Generate Now で都度再生成されます。プレーンな静的 HTML なので、別途動かすものはありません。

3.11Local Health とロケーションの概観

日常で要となる 2 つの Overview ペインには、それぞれ専用の章があります。Local Health は「すべて問題ないか？」に答えるボードです。監視中のすべてのサービス・デバイス・サブシステムを UP／DOWN 状態と 1 行サマリーで示します。各ペインから項目を重要（critical）に指定するとボードに加わり、フローティングパレットとミニも兼ねます。ヘルススイープ・しきい値・アラート連動を含む全容は第 11 章です。

Locations は、Mac が今ネットワーク上のどこにいるか — Home、Office、On VPN — を Wi-Fi ネットワークやサブネットから判定して教えます。ロケーションにより監視はネットワークを意識したものになります。認識されない場所にいる間はアプリがAwayとして扱い、ロケーション限定のチェックを一時停止するので、カフェやホテルのネットワークが誤報を出すことはありません。前述のとおり Setup の紐づけにも使います。ロケーションの定義、アラートと到達性のスコープ、フリートを含む完全なモデルは第 8 章です。

レイアウトを覚えたら、いよいよ実践です。次のパートはペインそのものを開いていきます。まずは第 4 章「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 はそれらを、単一のグローバルインストールではなく、切り替える集合として扱います。

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

• Apache モジュール。Apache ペインの PHP Module セクションの Load for websites ピッカーで、Apache が読み込む libphp.so のバージョンを選びます。変更すると管理対象設定を書き換えて Apache をリロードします。
• サイトごとの PHP。ローカル開発サーバ（下記 Localhost ペイン）には独自の PHP Version・PHP Binary 欄があり、あるプロジェクトを古い PHP で、別を最新で動かせます — マシンの他の部分が使うものを変えずに。旧来アプリと新規アプリを同時に成り立たせる、いつもの方法です。

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サイトとバーチャルホスト

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.5サイトの TLS 証明書

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

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

4.6.htaccess エディタ

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

4.7Nginx とリバースプロキシ

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.8Localhost・DNS・開発スタック

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

• Localhost — 即席のローカル開発サーバのマネージャ。New Local Server を追加し、Runtime（PHP・Python/Django・Node/Vite…）とフォルダを選び、ポートと任意の ServerName を設定して Start。サーバごとの Environment Globals と .test リゾルバで myapp.test がローカルに解決されます。Free Port ヘルパーと localhost を掴んでいるものを止める操作で、よくある競合を解消します。
• DNS — ローカルの名前解決と権威ホスティング。dnsmasq・unbound・nsd を実行し、ゾーンファイルをインポート／エクスポートし、レコード変更時にリゾルバをフラッシュして、Mac が古い応答を返さないようにします。
• LAMP / DevStacks — ワンクリックのスタック。LAMP ペインはプリセット（Choose a Setup）を提供し、揃ったコンポーネント一式をまとめてインストール・起動（Install & Start・Start All・Stop All）。DevStacks はプロジェクトフォルダのフレームワークを検出し、それを動かす適切なコマンドと npm スクリプトを表示します。

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

Web スタックは、その下にあるデータの質を超えることはできません。FrontierStack はデータベースを一級のサービスとして扱います。インストールして実行し、中身を閲覧し、AI 管理者がサイトのデータベースを平易な言葉で点検・修復し、そして — 多くの構成が忘れがちな部分ですが — 実際に復元できる検証済みのスケジュールですべてをバックアップします。本章では、リレーショナルエンジン、インメモリキャッシュ、新しいベクトル・分析ストア、そしてそれらすべてを守るバックアップの仕組みを扱います。

5.1MySQL／MariaDB ペイン

サイドバーの Databases セクションから MySQL を開きます。ペインはサーバが未導入なら Homebrew でインストールし、Server.app がかつて備えていた操作を提供します。Start・Stop とライブ状態ランプ、リッスンポート（既定 3306）、サーバ上のデータベース一覧です。MySQL 互換のフォークである MariaDB も同じように管理でき、ペインはインストールされている方を認識します。

ローカル開発は意図的な 1 つの慣習に従います。ローカルの root アカウントはパスワードなしです。これは MAMP／XAMPP の慣行であり、ワンクリック構築と AI の SQL ツールが資格情報の入力なしに動作する理由です。安全なのは、Mac 上の MySQL が 127.0.0.1 のみでリッスンし、そのマシンからしか到達できないからこそです。パスワード付きアカウントや連携サーバ上のデータベースなど、外部から到達する必要が生じた瞬間に、後述の秘密情報ボールトへ切り替えます。

5.2Database Ops と SQL の実行

Database Ops ペインは、データベースがブラックボックスでなくなる場所です。Replication セクションは、設定済みサーバが MySQL レプリカか PostgreSQL スタンバイかを検出し、遅延を表示します。MySQL は SHOW REPLICA STATUS（IO・SQL スレッド、Seconds_Behind_Source）を読み、PostgreSQL は pg_is_in_recovery() と再生タイムスタンプを使います。レプリケーションの停止やしきい値超過の遅延は、選んだチャネルにアラートを出します — Database Slave 監視プリセットの基礎です。

データの点検や修正には、AI 管理者の run_sql ツールがあります。「この注文の合計がなぜ間違っているのか」「元の重複ユーザより古い重複を削除して」のように平易な言葉で頼むと、ローカルサーバに対して SQL を実行し、結果を表として表示します — MAMP の Claude 連携によく似ています。文がデータを変更し得るため、run_sql は変更の有効化を必要とします。読み取り専用のクエリはアシスタントが有効になった時点で動作します。既定はパスワードなしのローカル root で、設計上ローカル専用です。

5.3パスワード付き・リモートのデータベース

ローカル root のショートカットは、ネットワークが始まるまさにその境界で止まります。パスワードが必要なデータベースや、リモート・連携サーバ上のデータベースでは、パスワードをプロンプトやツールに貼り付けることは決してしません。代わりに、AI 管理者の Script secrets (.env) バーに DB_PASSWORD や MYSQL_PWD という名前付き秘密として一度だけ追加し、アシスタントは run_script 経由で mysql クライアントを実行し、値を $DB_PASSWORD として参照しながら、名前付きサーバに対して SSH 経由で実行します。実際の値は Mac に留まり実行時に注入され、クラウドモデルが見るのは名前だけで秘密は見ません。

5.4PostgreSQL

高度な SQL・リッチな JSON・全文検索・GIS を求めるプロジェクトには Postgres を開きます。ペインは PostgreSQL（既定ポート 5432）をインストールして実行し、MySQL と並んで同じ開始／停止／状態の操作を備えます。アプリやフレームワークが前提とするなら PostgreSQL を、それ以外なら MySQL／MariaDB が手軽な既定です。両エンジンとも、後述のバックアップジョブと AI ツールの一級の対象であり、PostgreSQL は後述の特化型ストアのいくつかの土台にもなります — 埋め込み用の pgvector、時系列の TimescaleDB、Postgres データベース上に即席 REST API を載せる PostgREST です。

5.5Redis とその他のキャッシュ

セッション・キュー・レート制限・ホットパスのキャッシュは通常、リレーショナルテーブルよりインメモリストアを求めます。FrontierStack は Caching カタログから 2 つの標準を実行します。インメモリのキーバリューストアであり Redis Streams も支える Redis（ポート 6379）と、シンプルな分散キャッシュ用の Memcached（ポート 11211）です。他のサービスと同様にインストール・起動・監視できます。多くの CMS やフレームワークの構成は Redis を MySQL または PostgreSQL と組み合わせます。すべての選択肢はサービスカタログ（第 6 章）に並びます。

5.6ベクトル・分析データベース

2 つの新しいストアの系統が、独自のカタログカテゴリを持ちます。ベクトルデータベースは、検索拡張生成（RAG）や意味検索のための埋め込みを保持します。AI スタック（第 15 章）がモデルに自分のドキュメントへのアクセスを与える方法です。分析データベースは、トランザクション的な読み書きではなく、大規模データの高速な集計のために作られた列指向・時系列エンジンです。

完全にインプロセスのベクトル検索には FAISS（ライブラリ、ポートなし）もあります。フレームワークが前提とするエンジンを選んでください。各ペインは同じカタログの仕組みで一つひとつをインストール・実行します。

5.7データパイプラインと ETL

これらのストアの間でデータを移動・整形することは、それ自体が一つの分野です。Data Pipelines & ETL カタログカテゴリが概観レベルでこれを扱います。数百のコネクタを持つ抽出・ロードの Airbyte と Meltano、SQL ベースの変換・モデリングの dbt、そして作業をスケジューリングする Dagster・Prefect・Kestra などのオーケストレーターです。これらは本格的なプラットフォームで、FrontierStack はインストール・実行して Web UI を提示しますが、パイプラインのロジックは各ツールの中にあります。プログラマブルなデータパイプライン DAG には、Workflow Orchestration カテゴリの Apache Airflow もあります。

5.8バックアップ：ダンプ・概要ペイン・CCC

テスト済みバックアップのないデータベースは、未来の障害です。FrontierStack はこれに 2 方向から取り組みます。Database Ops では、サーバごとに検証済みのダンプスケジュールを定義します。名前、エンジン（MySQL か PostgreSQL）、ホスト、ポート、ユーザ、データベース（空欄＝すべて）、バックアップディレクトリです。期限の来たジョブはアプリ起動中に自動実行され、Run Now は即座に 1 回実行します。各実行はダンプ以上のことを行います — mysqldump は一貫した InnoDB スナップショットのため --single-transaction で実行され、続いて Verify が gzip の整合性とダンプが完了マーカーで終わっていること（切り詰められた・書きかけのファイルを検出）を確認し、.md5 サイドカーを書き、保持数にローテートし、鍵ベースの SSH で結果をオフサイトへ rsync します。

AI 管理者は同じ操作をツールとして公開します。db_dump はデータベースをターゲット上の .sql ファイルにダンプし（mysqldump または pg_dump を使用）、backup_now は設定・サイト・データフォルダのタイムスタンプ付き tar.gz を作成します。どちらも変更を伴うため、承認と変更の有効化が必要です。DB パスワードには $NAME のボールト秘密を参照し、貼り付けた値は決して使いません。

Backups 概要ペインは、すべての仕組みをまとめ、古さがひと目で分かるようにします。Time Machine の状態、Carbon Copy Cloner のタスク、アプリ管理の Apache 設定スナップショット、Git による設定のバージョン履歴、スケジュール済み自動エクスポートです。Carbon Copy Cloner ペインは CCC のタスクと履歴をその ccc コマンドラインツール経由で読み取り、タスクを必要に応じて Run できます。Time Machine と CCC はどちらも Alerts エンジンに供給されます — しきい値内に実行されていないバックアップや、失敗した CCC タスクは、選んだチャネルにアラートを出します（第 11 章）。

5.9復元 — そして復元の安全性

バックアップは復元のために存在し、復元こそが危険な半分です。AI の restore ツールは .tar.gz アーカイブを展開するか、.sql ダンプをデータベースにインポートします。ダンプのインポートは稼働中のデータベースを上書きし、アーカイブの展開はその場でファイルを上書きするため、restore は変更を伴い、破壊的になり得ます。常に変更の有効化付きの明示的な承認が必要で、SQL インポートは DB パスワードを $NAME のボールト秘密として参照します。

5.10壊れたデータベースのリカバリ

データベースが単に停止するより悪い状態——起動しない、テーブルが破損している——になることがあります。FrontierStack は AI 管理者（第 13 章）に、手作業で使うのと同じツールを、いつもの承認カードのうえで与えます。mysql_check_tables と pg_check_tables は mysqlcheck／pg_amcheck を実行して破損・クラッシュしたテーブルを見つけます。repair をオンにすると先に mysqldump／pg_dump でバックアップを取ってから修復（--auto-repair／REINDEX）するので、修正は取り消し可能です。mysql_service_control と pg_service_control は、systemd・launchd・Homebrew・service(8) をまたいで、ローカルでも SSH 経由でも、サーバの起動・停止・再起動・状態確認を行います。

難しいケースにはガイド付きのスキル——「Recover Broken MySQL」と「Recover Broken PostgreSQL」——があり、手順全体をたどります。エラーログを読み、原因を診断し、読めるものをすべてダンプし、新しいデータディレクトリに再構築し、壊れたテーブルを修復または作り直し、再起動します——常に古いデータディレクトリはコールドバックアップとして名前を変えて退避し、決して削除せず、破損を伴う各ステップの前に確認します。リモートホストでは、サーバペインのデータベース行にある赤い Emergency ボタンが最短の入り口です。そのホスト向けの適切なリカバリスキルを読み込んだ状態でアシスタントを開きます。

5.11ORM とアプリネイティブのツール：Drizzle と Convex

最後に、2 つのツールがアプリケーションのスキーマ定義の場であなたを迎えます。Drizzle ORM ペインは Drizzle プロジェクト（そのテーブル・マイグレーション・バックエンドの方言）を検出し、drizzle-kit タスクを代行します — スキーマから SQL を Generate、Migrate、スキーマを直接 Push、既存データベースを Pull（イントロスペクト）、そしてデータ閲覧用に Drizzle Studio を開きます。Convex ペインは、組み込みデータベースを備えるリアクティブバックエンドの Convex を管理します。npx convex dev で関数を監視・プッシュするか、Docker でセルフホストのバックエンドを立ち上げます。どちらも Node.js を必要とし、未導入ならペインが Homebrew でインストールします。これらはアプリケーション自身のデータ層を扱います。上記のダンプとバックアップは、それらが書き込むものを引き続き守ります。

FrontierStack は 112 カテゴリにわたる 1545+ サービスのカタログを備えています。各項目はアプリから検出・インストール・起動・設定・監視でき、AI 管理者はそのすべてを操作できます。本章はそのフィールドガイドです。各カテゴリと所属サービス、そして全サービスの 1 行説明を掲載します。サービス説明はアプリのラベルと一致させるため英語のままにしています。

各サービスには frontierstack.app/services/ に専用ページがあり、ポート・既定の Web UI・Homebrew フォーミュラを掲載しています。

6.1Overview

6.2Setup & Migration

6.3Locations & Places

6.4Fleet & Remote

6.5Networking

6.6VPN

6.7Routers & Firewalls

6.8Web Servers

6.9DNS

6.10Runtimes

6.11Databases

6.12Vector Databases

6.13Analytics Databases

6.14Data Pipelines & ETL

6.15Caching

6.16Search

6.17Backup

6.18Storage & NAS

6.19Object Storage & S3-Compatible

6.20Mail

6.21Mailing Lists

6.22Email Deliverability & Reputation

6.23Message Queues & Streaming

6.24Push Services

6.25Chat & Collaboration

6.26SMS & iMessage Gateways

6.27Business Messaging

6.28Calendars

6.29Identity & Accounts

6.30Customer Identity

6.31Decentralized Identity

6.32Version Control

6.33CI/CD

6.34Build & Compile

6.35Internal Developer Portals

6.36Infrastructure as Code

6.37API Testing & Synthetic Monitoring

6.38Proxies & Load Balancers

6.39Proxy Gateways

6.40CDN & Edge

6.41Hosting

6.42AWS Control

6.43FinOps & Cloud Cost

6.44Containers

6.45Service Mesh (Kubernetes)

6.46Apps & CMS

6.47Knowledge & Memory

6.48E-Commerce

6.49QR & Link Management

6.50Student Information Systems

6.51Learning Management

6.52Digital Library

6.53Campus & School Ops

6.54Sourcing & Suppliers

6.55Print-on-Demand

6.56Shipping & Fulfilment

6.57Inventory Sync

6.58Profit Analytics

6.59Mesh Networking

6.60Anonymity Networks

6.61Secrets & Vaults

6.62Monitoring

6.63Security Tools

6.64Secrets Scanning & Supply Chain Security

6.65Policy, Compliance & Governance

6.66MDM & Device Management

6.67Logging & Observability

6.68Incident Management & On-Call

6.69Status Pages

6.70Mining

6.71AI / LLMs

6.72AI Clusters

6.73Agent Platforms

6.74ML Workbench

6.75AI Governance & Safety

6.76GPU Infrastructure

6.77Speech AI

6.78Image & Video AI

6.79MCP

6.80Self-Hosted Apps

6.81Web3

6.82Crypto

6.83RPC Services

6.84Tools

6.85Home Automation

6.86Cameras

6.87IoT

6.88MQTT Brokers

6.89POS Systems

6.90CRM & Loyalty

6.91Helpdesk & Ticketing

6.92IT Assets

6.93Project Management

6.94PMS

6.95Meeting Rooms & Desk Booking

6.96Coworking & Shared Spaces

6.97Facilities & Maintenance

6.98Accounting & ERP

6.99Healthcare

6.100Automation & Workflows

6.101Workflow Orchestration

6.102HRIS Integration

6.103VoIP & Telephony

6.104Contact Centre & IVR

6.105SEO & Marketing

6.106Conversion Rate Optimization

6.107Social Media

6.108Media Servers

6.109Download Automation

6.110AV & Stage

6.111Render Farm

6.112Tracking & Telematics

動く 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ドメイン所有権の証明

ベンダーは、所有者にしか作成できない 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.3AI 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.4ワンクリック CMS インストール（Apps & CMS）

CMS のインストールは最初の一日にすぎません。残りを受け持つのが WordPressサイトです。ホスト（このMacまたは任意のフリートサーバ）を選び、一般的なウェブルート配下の wp-config.php を検索すると、そのマシン上の全 WordPress が、コア・プラグイン・テーマのバージョンと更新待ちの項目とともに一覧表示されます。すべて更新は、何かに触れる前にデータベースを書き出します。不具合のあるプラグイン更新は復旧できますが、失われたデータベースは戻らないからです。整合性を検査は、コアファイルを WordPress.org が公開するチェックサムと照合します。改ざんやバックドアを最も手早く見つける方法です。無料の WPScan トークンを追加すれば、インストール済みプラグインとコアを脆弱性データベースと照合し、修正が未公開のものを明示します。マルチサイトではサブサイトも一覧します。残る作業は、通常なら 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 つのフローでインストールします。各アプリは専用ペインを持ちます：WordPress・Drupal・Joomla・Statamic・Grav・Kirby・Craft CMS。インストーラはアプリをダウンロード（Composer ベースの Statamic・Craft は composer create-project）してドキュメントルートに展開し、データベースが必要なもの（WordPress・Drupal・Joomla・Craft）はデータベースとユーザを作成して設定を所定の場所に書き出します。フラットファイル CMS（Grav・Kirby・Statamic）はデータベース不要です。続いてアプリのセットアップ／管理ページ（/wp-admin/install.php・/admin・/panel・/cp・/admin/install など）を開いてアカウントを作成でき、周辺の vhost・PHP・信頼された HTTPS は FrontierStack が設定します。インストール先フォルダは、Apache が既に管理しているサイトをメニューから選ぶ（ドメイン・ドキュメントルート・ポートを自動入力）か、選択…で新しい空フォルダを指定できます。新しいフォルダには対応する vhost が作成され、既存サイトのドメインなら更新されます。不具合時は上記の Fix My Site（AI） でデバッグします。

7.5Domain 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 は引き続き監視します。

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

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

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

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

7.9サイト転送：マシン間でのコピー

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

ここまでは目の前の Mac の話でした。本パートでは視野を一気に広げ、運用環境全体を扱います。ラック内の Linux、いまも macOS Server が動く旧来の Xserve、棚の Raspberry Pi、クラウド VPS、そして Windows ホストまで。それぞれを SSH で一度連携すれば、FrontierStack はそれらを単一のフリートとして扱います。診断を実行し、コマンドを一斉展開し、サイトをデプロイし、健全性を見守ります。さらに、この Mac がネットワーク上のどこにいるかも把握するので、自宅・オフィス・カフェを移動するノートでも、いま単に見えないだけのサーバについて誤報を出すことはありません。

本章では連携とフリートの運用を扱います。第 9 章はネットワークと境界を、第 10 章は堅牢化とセキュリティ監査を、第 11 章は継続的な監視とアラートを掘り下げます。AI 管理者は同じツール群でここのほとんどを操作できます（第 13 章）。

8.1ロケーションとプレイス

Locations & Places ▸ Locations を開きます。ロケーションとは、名前を付けたネットワーク（Home・Office・On VPN）にすぎず、複数の信号から認識されます。Wi-Fi の SSID、ルータ（ゲートウェイ）の MAC アドレス、Wi-Fi の BSSID、IP アドレスのサブネットプレフィックス（例：192.168.1.）、グローバル IP のブロック、そして VPN が有効かどうかです。ヘッダーは今どこにいるか（Now: Office）を示し、その下にライブのスナップショット（Wi-Fi 名・IP・ゲートウェイ・VPN 状態）が並びます。検出は 30 秒ごとに走ります。

FrontierStack が見覚えのないネットワークを検出すると「新しいネットワークを検出」のバナーを表示します。「追加…」で保存できます。「現在のネットワークをロケーションとして追加」を押してから条件を調整することもできます。ロケーションは設定したすべての条件が成立したときに一致し（SSID とルータ MAC はいずれか一致）、空欄の項目は無視されます。複数が一致した場合は、リストの先頭ではなく最も限定的なものが採用されます。モードピッカーで自動検出の代わりに手動で固定することもでき、信号が曖昧なときに便利です。

信号の信頼度は同じではなく、この違いは見た目以上に重要です。サブネットは identity ではありません。家庭用ルータもカフェもホテルも 192.168.1.× を配るため、サブネットだけで定義したロケーションはまったく別の建物にも平然と一致します。ルータ MAC が最も強い信号です。1 台のハードウェアに固有で、特別な許可なしに読み取れます。ルータ照合が存在する前に保存したロケーションには、「現在のネットワークからすべての条件を更新」がワンクリックの修正になります。

8.11.1GPS で場所をピン留めする

やっかいなケース — 2 つの拠点が本当に同じサブネットを使っていて、MAC アドレスをいじりたくない場合 — では、ロケーションに GPS ピン を持たせることもできます。その場所に立って対象のロケーションを開き、「Pin This Spot (GPS)」を押します。半径スライダで「ここ」とみなす範囲を設定します（既定 150 m。屋内測位は粗く、拠点は点ではなく建物だからです）。

ピンは相互参照であり、必須条件ではありません。役割は 2 つです。弱い一致を裏付けること、そしてより有用なこととして、誤った一致を拒否することです。これにより、同じサブネットを使うカフェを Home と判定しなくなります。検出が悪化しないよう、共有されうる条件（サブネット、VPN の有無）だけで識別されたロケーションは、位置情報が得られていてそれと矛盾する場合、確定として報告されなくなりました。自信を持った誤答の代わりに Away / Unknown が表示されます。

デバイスもロケーションに属します。Device Discovery で、監視デバイスの ⋯ メニュー ▸ Assign to Location から特定の拠点に配置できます。自動のままにすると、そのサブネットを持つロケーションに入ります。デバイス自身のペインからも設定でき、各ロケーションの行には割り当て済みデバイスが一覧されます。Mac が認識済みのロケーションに到着すると、FrontierStack はそれらのデバイスを確認し（VPN 経由などで最近確認済みのものはスキップ）、状態を色で示します：緑=到達可能、赤=ここにあるはずなのに応答なし、オレンジ=この Mac が到達できない Wi-Fi セグメント上（別のアクセスポイントや帯域が典型。Mac が 5 GHz のときの 2.4 GHz 専用センサーなど）。オレンジは「消えた」ではなく「ここからは確認できない」という意味です。

これらすべての狙いは「ロケーション依存の監視」セクションです。Overview ▸ Alerts でデバイス・Wi-Fi・Cloudflare ゾーン・ウォッチを重要としてマークし、ここで「Office のときのみ」に絞ります。そのチェックは他の場所では一時停止され、ホテルから NAS が DOWN と鳴ることも、職場で自宅 Wi-Fi が失われたとアラートが出ることもありません。一時停止された項目は戻れば静かに再開します。ロケーション自体が変わったときは、ローカル通知の表示、Messaging Gateways 経由の「📍 Now at: Office」アラート送信、またはその両方が可能です。

8.2SSH によるサーバ連携

サーバは「Link a Server」シート（デバイスのペイン・Device Discovery・Cloud Servers／Remote Tools ペインから開けます）でフリートに加わります。名前、ホストまたは IP、ポート、SSH ユーザ名（root・ubuntu・ec2-user など）、ログインパスワードを入力します。そのパスワードは一度だけ使われます。アプリがこの Mac の管理対象 SSH 鍵をサーバの authorized_keys に入れ、以降は鍵のみで接続します。保存されるのはサーバのアドレスだけで、パスワードは破棄されます。

パスワードログインのない鍵専用サーバでは、「パスワードが使えない場合は鍵を手動でインストール」を展開し、表示された公開鍵を自分で authorized_keys にコピーしてから連携します。「監視ヘルパーも併せてインストール」にチェックを入れると、同じ手順でホストモニタを設定できます（後述）。

連携サーバには到達性を示す小さな緑／赤のステータスドットが付きます。Permission denied (publickey) で赤くなった場合（通常はサーバ再インストール後や鍵が未インストールのとき）、AI ツール repair_ssh_access が古いホスト鍵を消して管理対象鍵を再インストールします。一度きりのログインパスワードはボールトの秘密情報として保持され、ローカルで読み取られて鍵アクセスを再設定します。成功するとドットは再び緑になります。

8.3管理対象鍵と保存された sudo パスワード

鍵アクセスでアプリは接続できますが、多くの有用な操作（/var/log の読み取り、Apache 設定の編集、ファイアウォールのリロード）にはサーバ上の root が必要です。FrontierStack はホストごとの sudo パスワードでこれを扱い、macOS キーチェーンに保存します（平文ファイルには決して書きません）。サーバ連携時に自動取得され、後からホストのペインや Remote Tools のターゲットセクション（Sudo password 欄）で設定・変更できます。

root 限定のコマンドを実行するとき、ヘルパーは SSH セッション越しに保存済みパスワードで sudo の資格情報キャッシュを準備してからコマンドを実行します。パスワードが保存されていない場合、root 操作はパスワード不要の sudo -n にフォールバックし、それも未設定なら単に「needs sudo」と報告します。秘密情報は名前で参照されるため、複数を保持できます。たとえばサーバごとに異なる MySQL パスワードを .env ボールトに置けます。

8.4Fleet Run — 全ノードへ 1 コマンド

Fleet & Remote ▸ Fleet Run は、単一の操作をすべての連携サーバ（または選んだ一部）へ一斉展開し、ホストごとのライブ結果を返します。Targets を選び（ホストをトグル。到達性ドットで起動中が分かります）、Operation を選んで「Run on N Server(s)」を押すと、すべてが SSH 上で並行実行され、各ホストが下に結果を返し、展開すれば全出力が見られます。

操作は OS を認識します。パッケージ更新はホストに応じて apt・dnf・pacman・zypper・apk・brew に割り当てられ、サービス再起動は systemd を試してから Homebrew にフォールバックします。OS ごとのコマンドを手で書く必要はありません。

Fleet Run はドリフトを見つける最速の手段です。ディスク使用量や稼働時間と負荷を実行してホストをひと目で比較するか、次の Remote Tools にあるファイルチェックサムやヘルスチェックで、フリート間で食い違った設定を見つけられます。

8.5Remote Tools — ノード単位の診断

Fleet & Remote ▸ Remote Tools は、実際のフリートデバッグ作業から抽出した SSH 駆動の診断スイートです。まずターゲット（固定サーバ、または保存していないアドレス用の Other (IP / host)…。その sudo パスワードもキーチェーンに保持されます）を選び、次にツールとそのパラメータを選びます。読み取り専用チェックに root は不要で、保護されたログや設定を読むものは保存済み sudo パスワードをヘルパー経由で使い、一部はmutating（変更あり）と表示されます。

一部のツールは複数の選択ノードに同時に働きます。File Diff・Healthcheck・TLS Expiry・配信経路診断（Serving Path Diagnosis）（どのノードが稼働中か、各ノードがどの公開 IP をバインドしているか、プロセス単位の CPU 飽和と停止中サービス、そしてピン留めした全 Cloudflare ゾーンのオリジン IP との照合）は設計上フリート横断で、すべての Web ノードが同じ内容を有効な証明書で配信していることを確認するのにまさに使えます。ペイン下部では、/etc/hosts（root、ヘルパー経由）と SSH ユーザ自身の ~/.ssh/known_hosts を SSH 越しに安全に編集でき、各保存はまず .fsbak にバックアップします。

8.6ホストモニタ（リモートエージェント）

SSH 診断はオンデマンドです。継続的な可視性にはホストモニタをインストールします。サーバ上に常駐する小さな読み取り専用の Go ヘルパー（fsagent）で、サイクルごとの SSH なしに自分の健全性を報告します。連携ホストのペインからインストールを選ぶ（または Link a Server のチェックボックスをオンにする）と、既存の鍵越しにアプリがホストの OS とアーキテクチャに合ったバイナリを送り、プラットフォームのサービス（systemd・launchd・BSD の rc.d）を設定し、その TLS 証明書をピン留めします。AI ツール install_monitor も要求に応じて同じことを行います。

登録されると、モニタはライブのメトリクスをストリームします。CPU・メモリ・マウントごとのディスク・起動中のネットワークインターフェイス、検出されたサービス、ファイアウォールと fail2ban の状態、そして GPU ホストでは GPU ごとの温度と使用率を報告し、マイニングや ML のリグでも温度が把握できます。list_monitors はフリートのヘルパー、バージョン、最新メトリクスを報告します。重要なのは、モニタは Mac アプリがオフラインのときでも監視を続けてアラートでき、自前のチャネルで直接通知し、アプリが戻れば蓄積分を再送します。ログウィンドウもモニタを優先します。サーバ上で root として動くため、sudo パスワードなしで特権ログを読めます。

登録済みホストのペインには動作と履歴チャートも表示されます。CPU・メモリ・ディスクを5分解像度で最大30日分描画し、学習したベースラインで異常を検出します。赤い縦線が同じタイムライン上にインシデントを示します。実線の赤はサーバの再起動（報告された稼働時間から導出）、オレンジの破線はウォッチドッグの問題 — サービスの強制再起動、データベース破損警告、再起動エスカレーションです。OS のクラッシュレポータが CPU を使い始めた場合（プロセスが繰り返しクラッシュしている状態）はオレンジの Crashes 曲線も加わり、「昨夜 MySQL が2回強制再起動され、何かがクラッシュループしていた」ことが一目で分かります。

モニタは既定で読み取り専用です。Host Monitor ペインでAllow actionsをオンにすると、小さく固定された制御動詞（任意シェルは決して含みません）が解放され、ゲートされた monitor_action ツールで駆動されます。許可リスト内サービスの restart/reload/start/stop、DNS フラッシュ、ファイアウォールや fail2ban のリロード、再起動です。各アクションはサーバ上に記録されます。対象は Linux（amd64／arm64／arm — あらゆる Raspberry Pi を網羅）、macOS（OS X 10.11 El Capitan までさかのぼるレガシー Intel ビルドを含む）、FreeBSD（pfSense／OPNsense／TrueNAS）、Windows です。

モニタを長期的に健全に保つ作業は自動化されています。モニタ認証情報をローテーションはベアラー認証情報をその場で差し替えます。新しいシークレットは Mac 上で生成され、承認済みの FS1 署名鍵で送られ、表示や AI への引き渡しなしにサーバ上で有効化されます。自己アップデートを許可が有効なら、新しいビルドの配布は構造的に安全です。候補バイナリのリリース署名を検証し、root 権限を与える前に互換性セルフテストに合格する必要があり、直前のバイナリはロールバック用に保持されます。新しいバイナリがヘルスチェックに応答しなければ、FrontierStack が自動的に元へ戻します。プルモードの更新は、恒久トークンではなく短命・単回使用の付与でバイナリを取得します。モニタが FS1 署名リクエストを検証しているときは、そのペインに FS1 signed バッジが表示されます。

8.7Cloud Servers・Server Clone・リモート Apache

コンピュート系のペインに加え、AWS ▸ DynamoDB は選択中のリージョンのテーブルを、ステータス・アイテム数・サイズ・パーティションキー/ソートキーとともに一覧します。実際にコストや事故につながる 2 点を重視しています。キャパシティモードのカプセルは、アクセスの有無にかかわらず読み書きキャパシティに継続課金されるプロビジョンドのテーブルと、リクエスト単位で課金されるオンデマンドのテーブルを区別します。PITR無効の表示は、ポイントインタイムリカバリが無いテーブルを示します。新規テーブルでは既定で無効であり、誤った書き込みから巻き戻す唯一の手段です。ポイントインタイムリカバリは各行のメニューから切り替えられます。DynamoDB には一括の describe が無いため、テーブルごとに問い合わせ、リージョンあたり 40 件を上限としています。

Fleet & Remote ▸ Cloud Servers は、API トークンを設定したクラウドプロバイダ（DigitalOcean・Vultr・Linode・Hetzner・Sakura・Contabo）と AWS の EC2・Lightsail・RDS を横断する 1 つのインベントリにまとめます。読み取り専用のロールアップです（電源制御は各プロバイダのペインに残ります）。IP を持つ起動中インスタンスごとに、待ち受けを調べる Services ボタンと、SSH で連携してモニタを一手にインストールする + Helper ボタンがあります。シートで正しいユーザ名と鍵を設定するだけです。

Server Clone は、フリートサーバをこの Mac に合わせて立ち上げるガイド付きウィザードです。検出した Homebrew スタックをインストールし、設定とサイトファイルを元のパスにコピーし、ドメイン設定をプッシュして Web サーバをリロードし、MySQL データベースをクローン（ローカルの mysqldump を SSH 越しにターゲットの mysql へパイプ）できます。各ステップは鍵ベースの SSH で実行され、再実行しても安全で、既存データは削除されません。

単一サイトを公開する準備ができたら、（ドメインのコンテキストメニューからの）Promote to Production プッシュが、その vhost 設定をローカルと同じパスへ送り、必要ならドキュメントルートとデータベースをコピーし、Cloudflare 経由で DNS をターゲットに向け、certbot で本物の Let's Encrypt 証明書を発行できます。ファイル・データベース・vhost・DNS・HTTPS を 1 回のプッシュで。

リモートサーバの Apache も直接管理できます。リモートホストが 1 つでもあると Apache ペインにホストセレクタ（This Mac／各連携サーバ）が現れます。サーバを選ぶと FrontierStack が SSH 越しにその Apache を検出し（バージョン・設定構成・実ログパス付きの全アクティブ vhost）、vhost・モジュール・MIME タイプ・ポート・WebDAV を編集できます。各変更は検証（httpd -t）して優雅にリロードしてから確定し、設定が無効ならロールバックします。レガシーの macOS Server.app の Apache ツリーも理解します。Sites リストの Push to Server… は、ローカルサイトの vhost をモニタ連携サーバにドキュメントルートを差し替えて展開します。これらが対応するローカル Apache と Sites のワークフローは第 7 章が扱います。

8.8KVM-over-IP：コンソールと電源、無人運用

SSH や画面共有は、マシンが起動しネットワーク上にあることが前提です。そうでないとき — カーネルパニック、BIOS／ファームウェア画面、ネットワークスタックが上がらない — に必要なのがアウトオブバンドアクセス、すなわち OS に依存せず実際の HDMI 出力を取り込み USB キーボード／マウスを注入する KVM-over-IP 機器です。リモート KVMペインは、所有する機器（PiKVM・JetKVM・TinyPilot・NanoKVM・GL.iNet Comet・汎用機）を好きなだけ登録でき、各機器はピン留めでき、Web コンソール（BIOS レベルまで）にワンクリックで接続できます。

電源制御を持つ機器はループを閉じます。ATX ボード付き PiKVM、ネットワーク PDU、あるいは GL.iNet の Comet Pro（GL-RM10） — KVM とスマート電源プラグを 1 台に兼ねる — は主電源を切り替えられ、本当にフリーズした機体を強制的に電源サイクルできます。こうした機器はサーバの電源セクション（SwitchBot・UPS・PDU コマンドと並ぶ）で電源ソースとしてリンクでき、オン／オフ／サイクルが可能です。AI 管理者からも操作できます：list_kvms・kvm_power・server_power（最後のものは reboot_host に応答しないハングしたサーバを、リンク済みのプラグ／PDU／KVM で再起動します）。

8.9古い Mac・Raspberry Pi・Windows ホスト

フリートの意義のひとつは、古い・風変わりなハードウェアを活かし続けることです。いまも macOS Server が動く旧来の Xserve や Mac mini は他のホスト同様に連携できます。リモート Apache 検出は Server.app 独自の Apache ツリーと内部ポートを理解するので、その Web サイトが表示され編集でき、モニタのレガシー Intel ビルドは OS X 10.11 El Capitan までさかのぼって動きます。棚いっぱいの Raspberry Pi は通常の Linux として連携できます。モニタの arm ビルドは Zero を含む全 Pi を網羅するので、CPU・ディスク・サービスを他のすべてと並べて監視できます。

Windows ホストは Microsoft の OpenSSH サーバ経由で参加します。SSH 診断のために Linux 同様に連携し、モニタはネイティブの Windows サービスとしてインストールします（Windows サービスはマシン環境変数を確実には継承しないため、設定は実行ファイルの隣のファイルから読みます）。Windows のモニタインストールは自動プッシュではなく、Host Monitor ペインから付属の PowerShell インストーラで手動で行います。

診断を超えた対話的な制御には、カタログにリモートアクセスツール（RustDesk・MeshCentral・Apache Guacamole・Windows Remote Desktop・WinRM）も揃っていますが、それらは SSH フリート自体ではなく運用するサービスです。フリートの強みは、すべてを 1 つのウィンドウから均一・スクリプト可能・低負荷で管理できることであり、第 13 章の run_script でノードを名前で指定すれば、AI がリモートサーバを 2 段階で診断・修正できます。読み取り専用のテスト、続いて最小限の修正、そして再実行で確認です。

8.10移行ウィザード：スタックを新しいデバイスへ

古いサーバの引退が「すべて手作業で再インストール」を意味することは、もうありません。FrontierStack はレガシーマシンからスタックを取り出し、選んだ移行先——この Mac、別の Mac、あるいは Linux——に立ち上げる移行ウィザードを備えています。移行元は読み取るだけで、書き込みはすべて移行先に対して行います。

Migrate Setups ペインは MAMP・XAMPP・Apple Server.app の Web スタックを扱います。移行元を自動検出し、何を引き継ぐかをチェックで選べます。Homebrew ツール、Web ファイル、MySQL データベース、サイト（vhost）、MIME の上書き、Apache モジュール、PHP 設定、WordPress の wp-config.php 修正、Git リポジトリなどです。Set up on ピッカーで移行先を選択します。This Mac のままならアプリ内で完全移行し、連携ホストを選べば SSH 経由でその新しいデバイスにスタックをインストールし、Web ファイル（rsync）とデータベース（SSH 経由のダンプ）をコピーします。Linux トグルで Homebrew の代わりに apt/dnf を使います。

Apple Server Migration ペインは Server.app マシン全体のためのワンクリックウィザードです。移行元（この Mac またはリモート）を指定すると、serveradmin で全サービス——Websites・Mail・Calendar と Contacts・Messages（XMPP）・VPN・DNS・DHCP・NetInstall・Open Directory・File Sharing・Time Machine・Profile Manager ほか——に加えて、稼働中の git サーバ・データベース・Docker・単体の Nginx なども棚卸しします。各サービスに状態バッジと現代的な代替が示され、妥当な代替が複数ある場合（Calendar → Radicale／SOGo／Baïkal、VPN → WireGuard／strongSwan、DHCP → dnsmasq／Kea）はどれを使うか選べます。移行先マシンと OS を選ぶと、代替をインストールし、正確な引き継ぎチェックリストを表示します。専用インポータを持つサービス——Websites（vhost とファイルの完全コピー）と Open Directory（ユーザとグループ）——はそれぞれのペインへ、検出された git サーバは Git Server 移行へ引き継ぎます。

8.11Git サーバ：Gitea とリポジトリ移行

Git Server ペインは、任意の移行先——この Mac、連携サーバ、NAS、Docker ホスト、Linux——にセルフホストの Gitea（自動 HTTPS のため Caddy 背後）を立ち上げます。プラットフォームを検出して適切な方法でインストールします。稼働後はアクセストークンで接続すると、バージョン・リポジトリ数のライブ監視と、ミラーが元から遅れたときのバックアップ鮮度アラートが得られます。

同じペインで別の Git サーバを Gitea へ移行・ミラーできます。ディスク上のベアリポジトリ——レガシー macOS アプリ Simple Git Server、Xcode Server、Gitolite、素の git-daemon、任意のフォルダ——か、稼働中のリモートサーバ（git://・https://・ssh:// の任意のクローンベース。リポジトリ名は SSH で列挙するか貼り付け）を指定します。Scan でリポジトリを一覧し、Migrate で各リポジトリを全履歴・全ブランチ・全タグごとミラークローンし、API でリポジトリを作成して Gitea へ push します。コピーはこの Mac 上で実行されます。

サービスを動かす Mac はネットワークの中に存在し、現実のトラブルの多くはそのネットワークから始まります — WAN リンクが切れたルータ、誤ったサブネットに紛れたデバイス、何か月も前に開けたまま閉じ忘れたポート。FrontierStack は、ネットワークとその境界（LAN とインターネットの境目）を一級のオブジェクトとして扱います。ルータを直接読み取り、LAN をスキャンしてインベントリを作り、データフロー図を描き、外部へサービスを公開するための規律ある複数の方法を提供します。

本章はサーバを取り巻くネットワークを扱います。サーバ自体を SSH で連携する方法は第 8 章、ホストファイアウォール・fail2ban・セキュリティ監査は第 10 章、Cloudflare の DNS と TLS は第 7 章を参照してください。

9.1読み取り・操作できるルータとファイアウォール

FrontierStack は、管理 API があればそれを通じて、なければ SSH で、ネットワーク機器と対話します。最も緊密な連携は OPNsense（フル REST API）と Cloudflare（第 7 章）の 2 つで、より広範なルータ・ファイアウォール群はライブ状態を報告します。Router & Network ペインでアドレス・ベンダー・API キーを指定してデバイスを追加すると、AI 管理者の router_info ツールが バージョンとモデル、稼働時間、CPU・メモリ、WAN リンクとゲートウェイ（上／下）、インターフェイス、クライアント数を読み取れます — さらに FrontierStack がマップしないフィールドの生の API JSON も。読み取り専用で、デバイス自身の API を照会し、SSH は使いません。

OPNsense と pfSense では、API キーを設定すると継続的なファイアウォール監視（ピン留めデバイスのペインにあるトグル）が使えます。アラートのスイープごとにファイアウォール自身へゲートウェイ状態・インターフェイスのキャリア・サービスの稼働を照会します — マルチ WAN ルータがサイレントにフェイルオーバーして WAN 回線の死を隠しても（サーバは外に出られるのにサイトへのインバウンドは全滅）、原因不明の赤いドットの海ではなく、どのゲートウェイが落ち、どのポートがキャリアを失ったかを名指しで通知します。ルータには何もインストールしません。OPNsense の REST API は標準搭載、pfSense は REST API v2 パッケージのみ必要です。同じペインから OPNsense ルータをテイルネットに参加させることもできます。Mac 側で Tailscale にサインイン（Google アカウント可）して事前認証キーを発行し、デバイスペインの Tailscale セクションに貼り付けるだけで、FrontierStack が必要に応じて os-tailscale プラグインをインストールし、キーとログインサーバ（Headscale も可）を保存してサービスを API 経由で再起動します。ルータでのブラウザログインは不要です。

攻撃と障害の兆候。ゲートウェイを監視するのと同じスイープが、ルータ自身のトラブルも監視します。異常のあるルータはサイドバーでオレンジ＋警告三角になります — 理由はホバーで表示。侵入検知プラグインを有効にした OPNsense では、同じ API 経由で直近の Suricata アラートを読み取り、件数と上位シグネチャを表示します（ファイアウォール UI を開かずに攻撃の試みを可視化。pfSense の REST API は IDS を一律に公開しないため現状は OPNsense のみ）。すべての監視対象ルータ — OPNsense、pfSense、OpenWrt ほか — では各スイープが、予期しない再起動（稼働時間の急減：クラッシュ・電源イベント・攻撃）、ルータ管理／SSH への総当たりの急増（失敗ログインの連続。最も多い送信元 IP をルータ自身のログから名指し）、リソース逼迫（メモリまたは負荷が危険なほど高い — DoS・暴走／侵害されたプロセス）、利用可能なファームウェア更新（古いファームウェア＝既知の穴）も検出します。それぞれアラートを上げ、あるプラットフォームが報告できない兆候は単にスキップします — 誤った「異常なし」にはなりません。OPNsense と OpenWrt が最も多く報告し、pfSense の API はより限定的です。

ルータの操作と診断。AI 管理者は読み取り以上のこともできるようになりました：reboot_router はサーバの再起動と同じ方法でアプライアンスを再起動し（OPNsense／pfSense は API、OpenWrt は SSH）、「Allow changes」でゲートされます。ルータ自身のコンソールで行う方が本当に適したタスクのときは、アシスタントが open_web_ui でその Web UI を開くことを提案します — アドレスは推測せずデバイスペインから解決します。FrontierStack 自身はこれらアプライアンスのファイアウォールルールを意図的に編集しません — OPNsense／pfSense／OpenWrt は独自の設定システムでルールを管理するため、ペインとアシスタントは代わりにネイティブのファイアウォールページを案内します（ルータを右クリック ▸ Open firewall rules… が直接移動）。ペインの利便機能が 2 つあります：Diagnostics ボタンは API 不要の到達性チェック（ping、よく使う管理ポート 80／443／8443／53、逆引き DNS、ゲートウェイ）を実行するので、API キーがなくてもルータをトリアージできます。またルータ／ファイアウォールでは、Discover Services がポートスキャンではなく Web UI を開くことを提案します（自分の境界機器をスキャンするのは通常望ましくありません）。OPNsense や pfSense への SSH が拒否される場合、SSH が無効になっているか — より多いのは — 特定のインタフェース（多くは WAN ではなく LAN）でのみ許可されているためです：LAN 経由（例：VPN 経由）なら通常つながり、外部からは通常ブロックされます。Web UI で SSH と待ち受けインタフェースを有効にしてください（OPNsense は System ▸ Settings ▸ Administration ▸ Secure Shell）。SSH ボタン自体が非表示になるのは、管理シェルをまったく持たない民生用ゲートウェイ（NTT、一部の TP-Link／FRITZ!Box）だけで、その場合は Web UI が唯一の入口です。

9.2Device Discovery：LAN のインベントリ

Device Discovery を開き、Find Monitors を押します（先にサブネットを選んでも構いません）。FrontierStack は選んだ /24 を利用可能なすべての方法で一斉にスイープし、ルータ・アクセスポイント・スイッチ・NAS（Synology、QNAP、ZimaCube／ZimaOS など）・プリンタ・カメラ・他のサーバをまとめて浮かび上がらせます。

• Ping／ARP — ICMP スイープ。ARP／MAC が各ホストのベンダーを示します。TCP Probe をオンにすると、ICMP をフィルタするホストも見つかります。
• Bonjour（mDNS）と SSDP／UPnP — アドバタイズされたサービスとそのフレンドリ名。
• SNMP と LLDP／CDP — net-snmp と lldpd をインストールするとモデル・ポート・近隣の詳細が加わります（ペイン内のボタンでインストール）。
• Windows サービスポート — ICMP をフィルタするマシンも、特徴的なポート（RDP・WinRM・SMB など）を探ることで見つかるため、Windows PC がスイープから隠れることはなくなりました。

スキャンは各ホストの到達方法も記録します。ローカルで AnyDesk が稼働中、または既定ポート 7070 で応答すると AnyDesk バッジが付き、この Mac 自身の tailscale status から Tailscale バッジ（ピアがオンラインなら緑）が付いてメッシュのピアを検出デバイスに対応付けます（保持するのはエンドポイント・ホスト名・OS のみで、ログイン名は保持しません）。直接接続の LAN では、macOS が既に Bonjour で把握している Mac やデバイスが低速な IP スイープより先に現れ、一覧がすばやく埋まります。デバイス詳細には対応する AnyDesk／Tailscale 行とアプリを開くショートカットがあります。

AI 管理者の discover_devices ツールは同じスキャンを実行し、種別を確信を持って識別できたデバイスを自動でピン留めします。あいまいなものは推測せず一覧に戻すので、アシスタントはそれが何かをあなたに尋ね、pin_device でピン留めできます。ピン留め（監視）されたデバイスはその種別のサイドバーセクションに現れ、ダブルクリックでペインを開けます。行の Open Web UI・Discover Services・Reclassify・Remove も使えます。アドレスが分かっていれば Add a device by IP フィールドが直接プローブしてピン留めします — 全体スキャンは不要です。

9.3Data Map

Data Map ペインはロケーションごとのデータフロー図を描きます。1 つの拠点で、データがどこに存在し、デバイスやサービスを横断してどう流れるかを示します。FrontierStack はそのロケーションのインベントリ — 検出したデバイス、その役割、（任意で）スキャンしたポート — をシリアライズし、秘密情報を伏せて、ローカルの claude CLI を通じてあなたのサブスクリプション Claude に渡します（アプリ内ハーネスが使う従量課金 API ではありません）。返答は Mermaid フローチャートと短い説明として戻り、ペイン内でオフライン描画されます。各ロケーションの最新図は保持され、Obsidian ボールトにランブックとして保存できます。ロケーション自体は第 8 章で説明します。

9.4ポートを開く：UPnP と NAT-PMP／PCP

従来の方法でインターネットからサービスへ到達するには、ルータのポートを Mac へフォワードする必要があります。手作業でルータにログインさせる代わりに、FrontierStack はルータがアドバタイズする標準プロトコルでマッピングを依頼できます。

• UPnP IGD（miniupnpc 経由）— 一般的な家庭用ルータの方法。
• NAT-PMP／PCP（libnatpmp 経由）— Apple 由来の方式とその現代的後継。
• OPNsense — その API を通じて境界ルールとポートフォワードを直接設定。

これらのツールは初回使用時にオンデマンドでインストールされます。一時セッション用に作ったマッピング（Debug Share 参照）は、セッション終了時に自動で撤去されます。

9.5ダイナミック DNS：変化する IP を追う

家庭や小規模オフィスの回線は静的 IP を持たないことが多く、今日のアドレスに向けたホスト名は明日には古くなります。Dynamic DNS ペインはホスト名を現在のパブリック IP に追従させます。Name、Hostname（例 myhost.duckdns.org）、プロバイダのアカウント情報でエントリを追加し、Update Now で即時公開するか、Update automatically をオンにします。更新を FrontierStack の実行中のみ行うか、システムサービスとして恒久的に行うかを選べるので、アプリを閉じてもレコードは最新に保たれます。Cloudflare ユーザにはより緊密な経路があります — パブリック IP を追う Cloudflare DDNS A レコードで、第 7 章と同じ Cloudflare 連携が動かします。他プロバイダは更新 URL による汎用インターバル更新がカバーします。

9.6トンネルとメッシュ：開けずに届く

外部からサービスへ到達するより良い方法は、受信ポートを完全に省くことです。トンネルは外向きの接続を張り、外部エンドポイントがそれに乗って戻ってくることで、何もフォワードせず NAT を越えます。

• Cloudflare Tunnel — クイックトンネルはアカウント不要で公開 *.trycloudflare.com URL を、名前付きトンネルは恒久的なホスト名を与えます。
• Tailscale — Serve はサービスを tailnet 内で非公開に保ち、Funnel は Tailscale ノードを通じてインターネットへ公開します。

マシン間の継続的な接続には、メッシュ／VPN ネットワークが、どこへ移動しても各ノードに安定した私的アドレスを与えます。FrontierStack は一般的なものを管理します — 対応ルータ（OPNsense）では API で、サーバでは SSH で。

9.11.1テイルネット：Tailscale 全体のビュー

サーバごとの Tailscale 操作は各サーバのペイン内にあり、SSH 経由で「そのマシンでデーモンが動いているか」を確認します。テイルネットペインは、Tailscale 自身の API でしか分からないネットワーク全体の状況を扱います。API アクセストークン（このペインは書き込みを行わないため、デバイスの読み取り権限だけで十分）を貼り付けると、各デバイスのアドレス、OS、クライアントバージョン、所有者、タグ、最終確認時刻が一覧表示されます。

このペインの価値は「要対応」リストにあります。期限が近づいたノードキー（キーが失効するとデバイスは静かにテイルネットから外れ、再認証するまで戻りません＝予定された障害）、承認待ちのデバイス、承認されていないルートを広告しているデバイス（ノードは正常なのにサブネットへ到達できない典型的な原因）、そして数週間チェックインしていないデバイスを表示します。キーの期限切れと承認待ちはアラートにも通知されます。

9.11.2自前の ZeroTier コントローラを運用する

ZeroTier のクライアントはメンバ側だけで、ネットワークの管理は通常 my.zerotier.com で行います。しかし zerotier-one はどのインストールでも、そのネットワークのコントローラ自体になれます。完全にセルフホストでき、メンバ一覧を第三者に預ける必要もありません。ただしこの構成にはローカルの管理 UI が一切付属しません。ZeroTier コントローラペインがその欠けた部分を埋めます。

コントローラの identity と所有するネットワークを表示し、メンバの承認キューをワンクリックの承認／取り消しで処理できます。承認済みでも 2 週間確認されていないメンバには印が付きます。使われていない許可はネットワークの穴になり続けるためです。ネットワーク名、公開／非公開、ルート、IP 割り当てプールを編集でき、ZeroTier 独自のルール言語でフロールールを記述できます。入力しながらローカルでコンパイルされ、よくある構成のテンプレートに加えて、全員を締め出すルールセットを保存する前に警告が出ます。

すべての操作はコントローラ自身のループバック API に対して SSH 経由で行われます。コントローラは 127.0.0.1:9993 で待ち受け、root 権限で読めるトークンで認証するため、FrontierStack はコントローラ API を外部に公開する必要がなく、むしろ公開しない設計です。内蔵の監査は、誰かが公開してしまっている場合や、ファイル権限が緩い場合、バックアップがない場合に警告します。Prometheus への書き出し、ウォームスタンバイのバックアップ／復元、ZeroTier Central からの移行アシスタントも用意しています。

9.7UniFi：クラウドゲートウェイと Dream Machine

Ubiquiti のコンソールには専用ペインを用意しています。UniFi ゲートウェイは、汎用のルータ監視では見えない仕事をしているためです。UniFi ペインは Ubiquiti の 2 つの API を扱います。両者は答える問いが異なります。Site Manager キー（unifi.ui.com で作成する 1 つのキー）は、アカウント内の全コンソールを機種・ファームウェア・オンライン状態とともに一覧します。遠隔サイトが電源やインターネットを失ったことを知る唯一の方法です。ネットワークから切り離されたコンソールは、ローカルでは何も伝えられないからです。コンソール側（設定 ▸ 管理者とユーザ）で作成するローカル API キーは、ゲートウェイの現在の動作を明らかにします。

ローカル接続では、WAN 回線を ISP・レイテンシ・スループットとともに表示し、実際に通信を担っている回線を示します。この点が重要です。プライマリ回線が落ちると UniFi は無言でバックアップに切り替えますが、バックアップは多くの場合低速で従量課金です。通常これに気付くのは翌月の請求書です。さらに、アダプト済みデバイスとファームウェア、ゲートウェイが評価する順序どおりのファイアウォールルール、クライアント一覧、そしてすべてのポートフォワードを表示します。有効なポートフォワードはいずれもファイアウォールに意図的に開けた穴なので、任意の送信元アドレスからの接続を受け付けるものには印を付けます。公開ウェブサーバなら妥当ですが、それ以外では確認する価値があります。

アラートは、コンソールのオフライン、WAN 回線のダウン、バックアップ回線での稼働、デバイスのネットワーク離脱、インターネットに開放されたポートフォワードを対象とします。このペインは意図的に読み取り専用です。ルールやネットワークの変更は、その検証機構がある UniFi コンソール側に残します。PoE のポート制御は次節が扱い、コンソールの単純な到達性は従来どおり Router & Network にも表示されます。

9.8Power over Ethernet：電源ボタンのない機器の電源ボタン

アクセスポイント、カメラ、ドアコントローラ、デスクフォンには電源スイッチがありません。唯一の電源は接続先のスイッチポートです。そのため、応答しなくなった機器の復旧手段である「電源を入れ直す」には、通常ベンダの Web UI にログインするか、キャビネットまで歩く必要があります。

Power over Ethernet ペインは、そのポートをボタンに変えます。管理スイッチを IP で追加すると、ポートごとに PoE の状態（給電中、検索中、障害）、受電機器のクラス、優先度、スイッチが報告していれば消費電力が表示され、電源のオン／オフと電源の入れ直しが行えます。さらにスイッチの電力バジェット（総容量、使用中の電力、スイッチ自身の使用率しきい値の超過警告）も表示します。しきい値を超えるとスイッチは優先度の低いポートから給電を止めるため、ポート優先度もここで変更できます。

幅広く動作するのは PoE が標準化されているからです。RFC 3621 の POWER-ETHERNET-MIB は、ほぼすべての管理スイッチ（Cisco、Aruba/HPE、Netgear、TP-Link/Omada、Ubiquiti、MikroTik、D-Link、Zyxel）が実装しています。読み取りにはデバイス検出の SNMP コミュニティを使います。ポートの電源操作には読み書き可能なコミュニティが必要で、スイッチごとに設定し、キーチェーンに保存されます。接続機器の電源を切る操作は明示的な同意に値しますし、多くのスイッチではこのコミュニティが読み取り専用とは別に管理され、初期状態では無効になっています。監視を有効にすると、障害状態のポートや電力バジェットを超えたスイッチがアラートに上がります。どちらも、誰かがカメラの停止に気づくまで見えないままになりがちな問題です。

9.9インターネットヘルスと速度テスト

Internet Health ペインは回線そのものを見るための画面です。Targets の一覧（Cloudflare の 1.1.1.1 など、編集可能）を継続的に ping し、レイテンシとパケットロスを表示して 30 秒ごとに再テストします。ICMP をブロックするホストは :443 への TCP 接続レイテンシにフォールバックします。Live Traffic は全アクティブインターフェイスのリアルタイムスループットをグラフ化し、Addresses & Networks は各インターフェイス、そのサブネット（直接到達できるネットワーク）、ゲートウェイを一覧します。組み込みの traceroute は、トラフィックが横切る ISP やトランジット事業者を示します。Speed Test セクションで Test Now を押す — または AI に internet_speed を頼む — と、ダウンロード・アップロード・レイテンシ・応答性を測定します。Ookla の speedtest CLI があればそれを、なければ Apple の networkQuality を使います。

9.10Debug Share：localhost サーバを一時的に公開

localhost で動く開発サーバを同僚やスマホに見せたいとき、Debug Share ペインがそれをセッション中だけ公開し、その後自ら閉じます。ポートを入力（または Scan localhost で稼働中のサーバを検出）し、Expose via で公開方法を選び、Auto-close 時間を設定して、Open debug session を押します。すべての共有は FrontierStack 終了時にも自動で閉じます。

LAN フォワーダには 2 つの追加機能があります。ホストファイアウォールがオンなら、ペインに Open port in firewall が現れ、そのポートをセッション中だけ pf ルールで許可します。また Outside access ピッカーで UPnP・NAT-PMP・OPNsense API 経由の WAN ポートをマップし、DDNS host と組み合わせれば、LAN 共有をパブリックインターネットから到達可能にできます — マッピングは共有終了時に削除されます。AI 管理者もセッションの開始・一覧・終了ができます（debug_share_open／_list／_close）。「Allow changes」がオンなら MCP 経由でも可能です。

9.11名前付きトンネル：恒久的な公開ホスト名

クイックトンネルはあえて使い捨てです。この Mac のサービスを実際のアドレスで恒久的に到達可能にしたいとき — セルフホストのアプリ、社内ダッシュボード、Webhook 受信口など — は、代わりに名前付きトンネルを使います。サービスに自分の Cloudflare ゾーン上の安定したホスト名（例：app.example.com）を与え、再起動しても維持され、他のトンネル同様に着信ポートを一切開きません：Mac が Cloudflare のエッジへダイヤルアウトするため、フォワードするものも、ポートスキャンで見つかるものもありません。

Cloudflare ペインの名前付きトンネルセクションで作成します：新規トンネル…、続いて自分のゾーン配下のホスト名と、その前段に置くローカルポート。FrontierStack はすでに保持しているトークンを使い、Cloudflare API 経由でセットアップ全体を実行します — トンネルを作成し、イングレスルール（hostname → http://localhost:PORT）を書き込み、ホスト名を <id>.cfargotunnel.com に向けるプロキシ済み CNAME を追加し、cloudflared service install で永続デーモンをインストールします。最後の手順には一度きりの管理者プロンプトが必要です（/Library 配下に LaunchDaemon を書き込みます）。cloudflared 自体は初回利用時に Homebrew から取得されます。トンネルと DNS の作成だけを行い、cloudflared を別ホストで実行したい場合は、この Mac で今すぐ実行のチェックを外します。削除はそのすべて — デーモン、DNS レコード、アカウント側のトンネル — を巻き戻します。AI 管理者も同じ 3 つの動詞（tunnel_create／tunnel_list／tunnel_delete）を持ち、作成はサービスをインターネットに公開するため赤い確認でゲートされます。

サーバが最も無防備になるのは、何かに攻撃されたときではなく、静かに状態がずれていったときです。開けっ放しのファイアウォール、誰も無効化しなかったパスワードログイン、先週切れた証明書、誰にでも中継してしまうメールサーバ。FrontierStack は堅牢化を一度きりのチェックリストではなく、継続的で観測可能な状態として扱います。セキュリティペインは目の前のホストのコンソールであり、AI 管理者（第 13 章）が同じチェックを SSH 経由でフリート全体に適用します。ここで扱う内容はすべて、変更を依頼するまで読み取り専用で、どの変更もあなたが手作業で行えるものです。

10.1ファイアウォール：Application Firewall と pf

macOS は 2 つのファイアウォールを備えており、FrontierStack は両方を読み取ります。Application Firewall（ALF）はシステム設定で構成するアプリ単位の層で、セキュリティペインはその状態（有効・ステルスモード・すべての受信をブロック・アプリルール数）を表示するので、有効になっているかひと目で確認できます。pf パケットフィルタはより下位のポート単位の層で、FrontierStack が直接管理するのはこちらです。

アプリが管理する pf ルールは専用ファイル ~/Library/Application Support/FrontierStack/pf-frontierstack.conf に置かれ、システムの /etc/pf.conf に冪等に組み込まれた専用の frontierstack アンカーに読み込まれます。ルールを専用アンカーに置くことで、FrontierStack が Apple の基本ルールセットを編集することはなく、あなたのルールはリロードしても他を壊さずに残ります。ルールの追加・削除では、認証付きの管理者プロンプトを通じて pf がリロードされます。

AI 側では firewall_rule ツールがポートに対する許可／拒否ルールを 1 つ追加・削除し、必要に応じて送信元アドレスで絞り込みます。まず対象の OS を判別し、This Mac とリモートの macOS ホストには pf（frontierstack アンカー）を、Linux サーバには ufw を使います。Mac に ufw コマンドを、Linux に pf ルールを送ることは決してありません。

10.2侵入防止と開放ポートの監視

開いたままにせざるを得ないポートにも見張りは必要です。セキュリティペインは 2 つの侵入防止エンジンを統合します。fail2ban は不正なログパターンに合致した IP アドレスを禁止します — SSH や Apache へのブルートフォースが典型です。ペインには導入・稼働状況、jail 数、現在禁止中のアドレス数が表示され、ワンクリックのリロードと、既存の設定を上書きせずに健全な SSH jail を投入する「スターター jail.local を書き込む」アクションがあります。CrowdSec はその上に共有レピュテーションネットワークを加え、アクティブな決定数とメトリクスボタンを表示します。どちらも Homebrew で導入する root サービスです。

Open Ports セクションはホスト上のすべての待ち受けを一覧します。併設の監視 — リモート操作・画面共有の露出 — は、VNC／画面共有（:5900）、Apple Remote Desktop、AnyDesk、TeamViewer、Chrome Remote Desktop、Splashtop、RustDesk、Tailscale の exit-node 広告を特に検出し、今まさに誰かが接続していれば赤く表示します。Recent Intrusions と Active Bans セクションは fail2ban.log、CrowdSec、Suricata の eve.json、Wazuh の alerts.json からの検出を新しい順に集約し、動かしていないソースは単に飛ばされます。新たな禁止、新たな待ち受け、進行中の受信セッションはそれぞれアラートを上げられます — 配信は第 11 章で設定します。

10.3SSH の堅牢化

SSH は多くのサーバで最も価値のある扉なので、セキュリティペインには SSH Hardening Audit があります。sshd -T で実効構成を読み — ディスク上のファイルではなく、ドロップインを適用したあとにデーモンが実際に使う設定を読み — 重要な項目（PermitRootLogin、PasswordAuthentication ほか）を指摘します。SSH がネットワークから到達可能なときは、ペインがそれを明示します。まさにそこで指摘が効いてくるからです。

インターネットに面したホストの基本は、鍵ベース認証と PasswordAuthentication no です。修正は本体ファイルではなく /etc/ssh/sshd_config.d/ を編集して行えば、パッケージ更新でも堅牢化が残ります。FrontierStack 自身のフリートチャネルはすでにこれらに従っています。Ed25519 鍵、BatchMode=yes、IdentitiesOnly=yes、そして known_hosts に記録される初回接続時のホスト鍵信頼（第 8 章）を使います。ホストの鍵アクセスが壊れた場合、repair_ssh_access ツールがローカルのボールトに保管した一度限りのログインパスワードで管理鍵を再インストールします — パスワードは Mac 上で読まれ、AI に送られることはありません。

10.4サーバセキュリティ：リモートホストの状態チェック

ここまではこの Mac のセキュリティペインの説明でした。サーバセキュリティペインは連携サーバ向けの対になるもので — 同じ状態チェックを SSH 経由で、フリート内のどのホストに対しても行います。サーバの詳細を開いてセキュリティ横の チェック… をクリックするか、ペインを直接開いてホストメニューからサーバを選びます。1 回のスキャンで、重要な SSH ハードニング（PermitRootLogin、PasswordAuthentication、待ち受けポート）、ファイアウォールの有無と有効状態（ufw、firewalld、nftables、生の iptables）、稼働中の侵入防止エンジン（fail2ban、CrowdSec）、保留中のセキュリティ更新の件数（apt、dnf、yum）、全インタフェースで待ち受けるサービス、ホスト整合性の兆候（スティッキビットのない誰でも書き込み可能なディレクトリ、想定外の SUID バイナリ）を報告します。

各所見は High · Warning · Info · OK でスコア付けされ、1 行のサマリバッジにまとめられます。フリートを見渡して、どのホストが対応を要するか一目で分かります。ペインは何も変更しません：修正するリンクが、実際に変更を行うペインへ移動します — ファイアウォールを有効化・ルール編集するサーバファイアウォールペイン、リモートツールの SSH ハードニングレビュー、fail2ban／CrowdSec を導入するセキュリティツールなど。root またはパスワードなし sudo で最も深く読み取れますが、なければ可能な範囲で実行し、その旨を伝えます。相互リンクは双方向です：ローカルのセキュリティペインは macOS ファイアウォールへ、サーバセキュリティはサーバファイアウォールへ、ピン留めサーバのペインは両方へリンクします。

10.5Malware Audit ペイン

Malware Audit ペインは 1 台の Mac のための防御者のダッシュボードで、安価で常時動く確認から重いフォレンジックへとセクション順に構成されています。

同じオンデマンド ClamAV スキャンはセキュリティペインにもあり、AI の malware_scan ツールは依頼に応じて任意のパスに対し ClamAV や YARA を実行します — いずれも読み取り専用です。

10.6より深いフォレンジックツール

クイックスキャンでは足りないとき、重い解析はSecurity Toolsカタログカテゴリの導入可能サービスとして用意されています — カタログのフィルタ（第 6 章）で表示できます。Volatility 3 は RAM キャプチャを調べるメモリフォレンジックフレームワーク、capa は実行ファイルに潜む機能（capability）を特定し、CAPE と Cuckoo サンドボックスは疑わしい検体を隔離環境で起爆させ、その構成と挙動を抽出します。その隣には Wazuh（ファイル整合性監視付きのホスト SIEM/XDR）や、URLhaus・OpenPhish・OpenCTI といった脅威インテリフィードがあり、YARA やサンドボックスのルールを供給します。これらは組み込みペインではなく本格的なツールです。FrontierStack が導入・管理するので、インシデントが要求したときにそこにあります。

10.7EDR Fleet ボード

すでにエンドポイントで商用 EDR エージェントを動かしているなら、EDR Fleet ペインがすべてのコンソールを横断する読み取り専用の集約を提供します。Add Console… を選び、プロバイダを選んで API 資格情報を貼り付けます — キーチェーンに保管され、AI には見えません。エンドポイント数と未対応検出数は各ベンダーの REST API から取得され、対応は SentinelOne、Huntress、CrowdStrike、Sophos Central、Bitdefender GravityZone、Microsoft Defender for Endpoint。Jamf Protect と LimaCharlie は到達性のために接続し、その他のコンソールは Generic（到達性のみ）として追加できます。Fleet totals 行が全体を合算します。ボードは数分ごとに更新し、コンソールが到達不能になると Security グループのアラートを上げ、未対応検出数がアラートの詳細に同伴します。深い作業には Open Console でベンダー自身のダッシュボードへ移動します。

10.8読み取り専用のセキュリティ監査

ホストの実態を最も早く知る方法は、AI の security_audit ツールです。This Mac または連携サーバに対し SSH 経由で、完全に読み取り専用の包括的なスイープを実行します。OS を自動判別し、保留中のセキュリティ更新、ディスク暗号化（FileVault または LUKS）、ファイアウォール（macOS では Application Firewall + pf、Linux では ufw／iptables）、SSH 堅牢化、待ち受けポート、UID-0 と特権アカウント、パスワード不要の sudo（NOPASSWD）項目、侵入防止、直近の失敗ログインを確認します。パスワード不要の sudo は使える場合のみ使い、使えない場合は優雅に縮退します。何も変更されません。優先順位付きの所見と具体的な修正案が得られ、自分で適用しても、通常の承認カードを介して AI に戻しても構いません。リモートで監査するには target にサーバ名を、ローカル Mac なら省略します。

10.9セキュリティ監査ペイン：サンドボックス内の「悪用可能なものだけ」監査

上記の読み取り専用 security_audit はホストがどう構成されているかを教えてくれます。セキュリティ監査ペインはより難しい問い — ここで攻撃者が実際に悪用できるものは何か？ — に答えます。コーディングエージェントを敵対的な監査担当に変え、対象を把握し、多角的に攻撃を試みます — インジェクション、アクセス制御不備、認証・認可、ビジネスロジック、暗号、シークレット露出、SSRF、設定ミス、連鎖攻撃 — そして各所見を自ら反証しようと試み、具体的な攻撃経路があるものだけを残します。各所見には攻撃シナリオと修正案が付き、理論上のノイズはありません。

2 つのモードがあります。コードベースはエージェントをリポジトリや Web プロジェクトのフォルダに向け、ソースを監査します。インフラは FrontierStack が既に集めている信号 — Cloudflare ゾーンとその TLS/WAF 設定、ドメイン／証明書の健全性、ピン留めサーバの OS・公開サービス・リモートアクセス・MDM／アクティベーションロック／FileVault 状態、ローカルファイアウォール — を秘匿化したインベントリにまとめ、エージェントがそれを攻撃します。

実行全体は Sandcastle の Docker サンドボックス内で行われるため、信頼できないコードに向けた敵対的エージェントがホストに直接触れることはありません。初回監査時にサンドボックスのイメージとランナーをアプリが構築します（Docker または Podman の起動が必要）。以降は即座に開始します。所見は重大度バッジ付きで表示され、Obsidian に保存したり、重大／高リスクを アラートとして発報できます。他と同様、Mac から出るのは秘匿化済みのプロンプトのみ（シークレットは事前に除去）で、サンドボックス内のエージェントは claude setup-token のトークン（または Anthropic API キー）であなたの Claude サブスクリプションで認証します。

10.10Strix：AI ペネトレーションテスト

ここまでの監査は読み取り専用で、ホストの構成やコードのどこが悪用可能かを調べるものでした。Strix はさらに踏み込み、能動的なペネトレーションテストを実行します。セキュリティペインの Strix AI セキュリティテストセクションから、リポジトリフォルダ、Git URL、ドメイン、URL、IP アドレス（または連携ホストのいずれか）を指定し、深さを クイック・標準・ディープから選ぶと、攻撃対象領域をマッピングし、実際の攻撃経路を試み、ペネトレーションテストレポートを作成します。

FrontierStack はこれを、オープンソースの Strix コマンドラインエージェントを Mac 上でローカルに駆動し、そのディスク上の実行成果物 — 検出結果・実行メタデータ・レポート — を読むことで行います。ホスト型サービスをスクレイピングすることはありません。CLI が未導入ならその旨を示し Install Strix… リンクを提示します。Update Strix は uv または pipx 経由で更新し、スクリプトをシェルにパイプすることはありません。AI プロバイダキーは任意で、指定した場合は macOS Keychain に保存され、ローカルの Strix プロセスにのみ渡され、表示もクラウドモデルへの送信もされません — ペインはキーが設定済みかどうかのみを示します。

タイルは直近の実行を要約します：Critical・High・Medium の件数、所要時間、24 時間以内の新規、失敗したスキャン。実行中はライブのフェーズ表示と Stop ボタンが出て、新しい Critical／High の所見が現れると（アラートを消音が有効でない限り）ローカル通知が届きます。検出結果を開くとレポートを書き出すで詳細を確認でき、失敗したスキャンを再実行とスキャンエンジンを再起動で不調から回復します。重大な所見は機微情報として扱われ、クラウド AI に送られることはありません。AI アドミニストレーターからも strix_status・strix_scan・strix_control で駆動でき、第 13 章で扱います。

10.11Certificate Sources と TLS

証明書の失効は自ら招く障害です。Certificate Sources ダッシュボードは、ホスト上の発行スタックごとに 1 行を表示します — Let's Encrypt（acme.sh 経由）、Certbot、Step CA、Traefik、Cloudflare SSL — 失効日は openssl で証明書そのものから直接読み取ります。Cloudflare は分析用に構成したトークンとゾーンを使い、この Mac に存在しないソースは淡色で表示されます。Traefik はその acme.json を、Step CA はその URL をダッシュボードに指定できます。

証明書の発行には 2 つの経路があります。mkcert はローカルで信頼される証明書を作成します — 公的 CA が無関係な .localhost や LAN 名での開発に最適で、Certificates ペインの Get アクションは導入済みならこれを使います。一般に公開するものには Let's Encrypt を使います。AI の issue_certificate ツールが This Mac または連携サーバで acme.sh や certbot を実行し、DNS-Cloudflare 方式では実行時に注入される CF_TOKEN ボールトシークレットを読み — モデルに送られることはありません。

10.12メールのセキュリティ

メールサーバには 2 つの異なるリスクがあります。なりすまされること（誰かがあなたのドメインとしてメールを偽造する）と、悪用されること（見知らぬ相手のためにメールを中継する）です。FrontierStack は両方に対処し、Postfix が下層にいる旧 Apple Server のケースも理解するツールを備えます。

• なりすまし対策の DNS — email_auth_dns が SPF、DMARC、（任意の）DKIM の TXT レコードを生成します。SPF はドメインの送信元を宣言し、DMARC は失敗時の扱いを受信者に伝え、DKIM は送信メールを暗号署名します。publish=cloudflare ならレコードを作成し、そうでなければ BIND、dnsmasq、レジストラに貼り付ける正確なレコードを表示します。
• DKIM 鍵 — generate_dkim_key はサーバ上でドメインとセレクタに対し opendkim-genkey を実行し、公開鍵を公開すべき TXT レコードとして返します。秘密鍵は OpenDKIM ミルターのためサーバに残ります。
• Postfix の堅牢化 — harden_mail_postfix は SSH 経由で postconf により安全なデフォルトを適用します。中継には SMTP AUTH を必須化（これでオープンリレーを閉じます）、未知・未登録の送信元ドメインを拒否、任意で送信者／ログインの一致を強制します。Postfix をリロードし、実効設定を表示します。
• オープンリレーテスト — test_open_relay は安全な SMTP 会話（EHLO／MAIL FROM／RCPT TO を外部ドメインへ、送信せず QUIT）を行い、外部宛先が拒否されたか（良好）受理されたか（オープンリレー — 不良）を報告します。

10.13外部から変更してよいのは誰か

ここまでは FrontierStack が面倒を見るマシンの堅牢化でした。本節は FrontierStack 自身の堅牢化です。フリート全体の SSH 鍵・データベースのパスワード・クラウドトークンを預かるアプリは、管理下のどのサーバよりも魅力的な標的だからです。

FrontierStack は複数の入口から外部操作できます。AI クライアント向けの MCP サーバ、Webhook やモバイルパネル向けの受信 HTTP 制御サーバ、ショートカットや Siri 向けの App Intents、そして有効化した場合のエージェント連携です。いずれも独自のトークンを持ちますが、その上位にリモート制御・ロック内の 2 つの設定があります。それぞれが答える問いは異なります。

アプリロックは「ロック中に何が残るか」に答えます。パスワードを設定してロックすると、ウィンドウは覆われ、すべての外部経路が完全ブロックか読み取り専用に制限されます。

外部からの変更は別の問いに答えます。ロックしていない状態で、外部の呼び出し元が何かを変更するまでに何を要求するか、です。MCP サーバ・制御パネル・ショートカット・コマンドラインのすべての外部経路に同時に適用されます。レベルは 3 つ。全自動は確認なしで実行させます。接続するクライアントとその動作環境をすべて信頼できる場合にのみ妥当です。既定の操作ごとに確認は、変更のたびに呼び出し元を明示した承認パネルを表示します。パスワードが必要は、外部ツールがサーバに触れる前にパスワードを求めます。

確認レベルには、障害対応時に効く逃がし弁があります。承認時にこのセッションのみ許可を選ぶと 5 分間有効になりますが、その呼び出し元・その種類の操作に限られます。MCP クライアントからのサービス再起動を承認しても、同じクライアントでのシェル実行や、モバイルパネルからの再起動が許可されるわけではありません。この狭さこそが要点です。障害中に確認が繰り返されることが、人を「全自動」へ恒久的に切り替えさせる主因であり、横に漏れる許可はそれ以上に危険だからです。

どのレベルでも共通する 3 つの性質が、この設定を単なる設定項目ではなく信頼できるものにしています。読み取りは決して制限されません。障害中に暗転するダッシュボードは害にしかならないため、監視クライアントはどの設定でも動き続けます。認証情報・シェル・FrontierStack 自身の設定は、どのレベルでも外部から変更できません。これらは確認を出すのではなく拒否されます。パスワードの読み出しや任意コマンドの実行にとって、リモートツールからの要求はそもそも発生源として適切ではないという判断です。そしてセッション許可はディスクに書かれません。アプリの終了やロックで消えるため、5 分間の利便性が、与えたことを忘れた恒久的権限に変わることはありません。

10.14auth.md によるエージェントログイン

パスワードは自動化に最も向かない資格情報なので、FrontierStack はサードパーティサービスの長期パスワードを貼り付けるよう求めることは決してありません。代わりに auth.md を検出します — サービスが https://<host>/auth.md に公開できるオープン仕様（WorkOS 発）で、AI エージェントが代理でサインインする方法を伝えます。サービスの Connect ▸ Login Automation (auth.md) 開示と、AI の check_authmd ツールがその公開ファイルを取得し、広告されたフロー（agent-verified または user-claimed）、スコープ、OAuth エンドポイントを要約します — あるいは未公開と報告します。付与そのものはサービス側で行われ、短命で取り消し可能、スコープ付きのトークンが発行されます。FrontierStack はパスワードを保存しません。現在 Cloudflare と Firecrawl が auth.md を公開しており、対応サービスは増えつつあります。

10.15署名付きリクエストの信頼モデル（FS1）

FrontierStack 自身の制御面 — ローカルの制御サーバ、MCP サーバ、リモートの fsagent — は TLS 上のベアラートークンで保護されています。しかしトークン単体は共有秘密であり、再送可能で、誰が呼んでいるかの証明にはなりません。FS1 署名付きリクエストはその上に第二の要素を加えます。すべてのリクエストが承認済みのデバイス単位 Ed25519 鍵で署名され、サーバは公開鍵の許可リストを保持し、明示的に承認していない鍵で署名されたものを拒否します。漏れたトークンはそれ単体では何も制御できません — これはフリートがすでに信頼している SSH 鍵の HTTP 版です。

各リクエストはデバイスの鍵 ID、タイムスタンプ、ランダムなノンス、正規化文字列に対する署名を運びます。サーバは、鍵が承認済みであること、タイムスタンプが 60 秒の窓内であること、ノンスが未使用であること（署名が検証された後にのみ消費されるため、不正な署名でノンスを浪費できない）、署名が有効であることを検証します。同じ方式が macOS アプリ、Go エージェント、iOS クライアントで同一に実装され、言語横断テストで固定されています。

デバイスはサイドバー概要グループの Paired Devices ペインで管理します（以前はこのセキュリティペイン内にありました）。ペア済みの各電話・タブレットには、ラベル、鍵フィンガープリント、最終確認時刻、スコープ選択、Revoke ボタンが表示されます。ペアリングは数台ずつ持つ 1〜2 名を想定し — 登録は 4 台まで — 各デバイスはスコープを帯びます。

同じセクションには、制御サーバと MCP サーバそれぞれの署名要求（Require request signing）スイッチがあります。展開は意図的に緩やかです。署名が任意のあいだサーバはトークンまたは署名を受け入れ、すでに持っているトークンで最初の鍵を登録できるブートストラップ例外があるため — 強制を有効にしても全員を締め出すことは決してありません。

各行にはさらに 2 つのデバイス単位の制御があります。AI 管理者を許可（既定はオン、どのスコープでも）は、その電話が AI と会話できるかどうかを制御します — 信頼する 1 台にはチャットを許可しつつ別の 1 台をブロックできます。このスイッチは制限のみを行います：オンでも AI は依然としてアプリのロック解除、署名済みデバイス、変更を伴う操作には full スコープの「変更を許可」を必要とします。リモートシェルを許可は full スコープでのみ表示され、既定はオフです。これは電話がコマンドラインシェルを開き、さらにこの Mac がオフラインでも直接アクセスするために自身の SSH 鍵をサーバに導入するために必要な明示的許可です。電話を紛失した場合、紛失した電話を保護は端末と古いキュー操作を直ちに遮断し、セッションを終了し、到達可能なサーバから直接 SSH 鍵を削除し、プッシュトークンを無効化します。オフラインのサーバは復帰後にクリーンアップを完了できるよう一覧に残ります。

Bluetooth によるペアリングのフォールバック。新しい電話が Wi-Fi や Tailscale でこの Mac に到達できないとき — 制限されたゲストネットワーク、クライアント分離、キャプティブポータルなど — 登録は Bluetooth 経由でも完了できます。Bluetooth ペアリングを許可（既定はオフ）を有効にすると、Mac はペアリングダイアログを開いている間だけ短命の GATT サービスをアドバタイズします。電話は同じ一度きりの QR コードをスキャンし、まったく同じ署名付き登録ハンドシェイクを実行します — HTTPS の代わりに BLE で運ばれるだけです。FS1 署名はトランスポートに依存しないため、Bluetooth 経路は TLS チャンネルなしで同じ信頼保証を継承します。

10.16ヘッドレス Mac の堅牢化

ディスプレイのないサーバには固有のセキュリティ上のトレードオフがあり、Headless Setup ツール（詳細は第 8 章と第 17 章）はここで最も重要なものを表に出します。System Status セクションは FileVault が有効なとき警告します。キーボードも画面もない暗号化 Mac は起動時に解除できず — オンラインに戻る代わりに FileVault のプロンプトで止まるからです。ヘッドレス機では一般に、フルディスク暗号化と無人再起動のどちらかを選ぶことになり、FrontierStack はその選択を、次の停電後に気づくのではなく明示的にします。そうしたホストで画面共有やリモートログインを有効にすることは、まさに Open Ports 監視がその後見張る種類の露出です。

変更しかできないコントロールパネルは、半分の道具にすぎません。もう半分は、何かがおかしくなったとき——できれば障害になる前に——それを知ることです。FrontierStack は、監視対象として登録したすべてを継続的にスイープし、トラブルの最初の兆候を、あなたが選んだチャネルへのメッセージに変えます。本章では、全体を要約する Local Health ボード、警告を発報・配信する Alerts ペイン、それを運ぶメッセージングゲートウェイ、そしてクラウドサービス・プロジェクトツール・電源・ストレージ向けの専用モニタを扱います。

11.1Local Health ボード

Overview ▸ Local Health を開くと、「今、何か壊れているか?」に答える 1 画面が現れます。監視対象のサービス・デバイス・サブシステムはすべて UP または DOWN の行として、領域別（Web・データベースサービス、フリート、サイトと証明書、ディスク、UPS・SNMP デバイス、接続済みクラウドアカウント）にまとまって表示されます。最上部には X up / Y down の形式で 1 行サマリーがあり、すべての行を読まずともフリート全体の状態をひと目で把握できます。

このボードは、AI 管理者が get_server_health ツールで読むのと同じデータです。「何が落ちている?」と尋ねれば、この画面が示す内容をそのまま報告し、修正案を出す前に調査を申し出ます（第 13 章参照）。スイープはおよそ 60 秒ごとに走り、各 DOWN 項目はそれを所有するペインにも紐づけられます。これがサイドバーの行や Dock アイコンに赤いカウントのカプセルが現れる理由です——トラブルが「ある」だけでなく「どこにあるか」が分かります。

11.2Alerts ペイン：監視する対象

Local Health ボードは状態を表示します。Alerts ペイン（Overview ▸ Alerts）は、何がメッセージに値するかを判断して送信します。「重要なサービスを監視して通知する」をオンにすると、スイープがアラートを発報し始めます。監視する対象は次のとおりです。

• サイトとサービスの健全性 — HTTP／ループバックのチェック、TCP ポート、さらに踏み込んだプロトコルプローブ（SMTP／IMAP ログイン、データベースの SELECT 1、LDAP バインド）。待ち受けてはいるが実際は壊れているサービスも検知します。MySQL プローブはさらに接続プール（max_connections に対する使用率と "too many connections" の拒否カウンタ）を読み取り、プールが 90% を超えたときやスイープ間にクライアントが拒否されたときに通知します。各スイープはデータベースヘルスペインの接続ヘルス履歴としてチャート化され、プール使用率の推移に、拒否バーストと停止が赤い線で刻まれます。
• 連携サーバ — 各フリートホストの SSH エンドポイントをスイープごとに到達性チェックします（ログイン試行なしの素の TCP 接続）。完全に停止したサーバは明確な「サーバダウン」アラートを発報し、復帰時には「サーバ復旧」を送ります。これはホストが稼働中に接続を制限しているときだけ出る SSH クールダウン通知とは別物です。
• 証明書とドメイン — フリート全体の TLS 有効期限に加え、レジストラ／DNS／SSL のチェックで、失効する当日の朝ではなく数日前に警告します（第 7 章）。
• ディスクの逼迫 — 後述の Disk Health モニタから、空き容量しきい値を下回ったボリュームを通知します。
• セキュリティの露出 — 新しい開放ポートや想定外のリスナー、VPN トンネルの切断、SSH がネットワークから到達可能な状態での重大な SSH 堅牢化の失敗。
• 決済の失敗と請求 — 接続した有料サービス（OpenAI・Anthropic・Cloudflare・Google Cloud）がクォータ不足・残高不足・認証エラーを返す——カード失効の症状です。
• 接続したクラウドサービス — Stripe・Shopify・Freshdesk・SendGrid などのライブ監視が、設定したしきい値を超えると発報します。

多くのチェックはしきい値ベースなので、「トラブル」の定義はあなたが決められます。証明書が残り N 日になったら、未対応チケットが一定数を超えたら、ディスクが一定割合を超えたら——。余裕を持ったしきい値にすれば、事後検証が事前の知らせに変わります。ペインには「侵入を通知」もあります。新しい fail2ban／CrowdSec のバン、高深刻度の Suricata シグネチャ、注目すべき Wazuh アラート（レベル ≥ 7）が発生時にメッセージされ、既存の履歴は再アラートされません。

11.3メッセージングゲートウェイ

アラートは届いて初めて役に立ちます。Alerts ペインでは複数のゲートウェイを同時に有効化でき、チャネルごとに複数の宛先を指定できるので、相手が既に開いているアプリに確実に届きます。ボットトークンや Webhook URL を貼り付け、テストを送れば稼働します。AI 管理者は get_messaging_channels で有効なゲートウェイを列挙し、send_notification で送信できます（第 13 章）。

11.11.1オンコールの呼び出し（PagerDuty・Opsgenie・緊急 ntfy）

上記のメッセージゲートウェイは送りっぱなしのテキストです。ページングチャンネルは質的に異なり、ステートフルです。監視項目がダウンすると、FrontierStack はその項目にキー付けされたインシデントをトリガします——PagerDuty（Events API v2 のルーティングキー）または Opsgenie（GenieKey）がエスカレーションポリシーを実行し、誰かが応答するまでオンコール担当者にプッシュ・SMS・電話をかけ続けます。項目が復旧すると、FrontierStack は同じインシデントを自動的にリゾルブします。インシデントは項目ごとにキー付けされるため、フラッピングするサービスは 1 つのインシデントを更新するだけで当番を何度も呼び出さず、すでに終わった障害で誰も起こされません。オンコールサービスがない場合は、ntfy ゲートウェイのダウン時にページトグルで「ダウン」アラートを ntfy の最高優先度で送信できます——より大きく繰り返し鳴り、多くのスマホのサイレント設定を突破します（復旧とレポートは通常優先度のまま）。各ページングチャンネルのテストページを送信ボタンは実際のインシデントを発生させ、約 10 秒後に自動リゾルブして、エスカレーション経路全体を端から端まで検証します。

トークンと Webhook は macOS キーチェーンに保存され、Mac の外には出ません。スケジュール配信の AI 評価レポートも送れます。AI 管理者がライブの監視健全性から（読み取り専用の診断を実行して）サマリーを作成し、日次・週次でメール送信、あるいは有効なすべてのチャネルへプッシュします。重大項目が 2 件以上同時に DOWN のときは、任意でより詳しいレポートも送れます。

11.4配信エラーとその直し方

アラートが黙って送信失敗するモニタは無価値です。FrontierStack はすべての送信を検証します。ゲートウェイが失敗すると、Alerts ペインの配信エラーセクションに、平易な日本語の修正ガイドと、その下に生のエラー、そして設定の誤ったチャネルの設定へ直接スクロールする Fix ボタンとともに記録されます。サイドバーの Alerts 行と Dock アイコンに赤いバッジが現れて確実に気づけるようになり、クリアするまで残ります。AI 管理者は get_alert_errors で同じ一覧を読むので、「なぜアラートが届かない?」と尋ねるだけで済みます。

よくある原因は地味で、すぐ直せます。

11.5オンホストの Service Watchdog とデータベースの健全性

ここまでのモニタはMac上で動作します。重要なサーバには、そのマシン自身に常駐するWatchdogも必要です。そうすればMacがスリープ・オフラインでも動き続けます。FrontierStackのService Watchdogはホストモニタとともに配備され（第8章）、短い間隔でサービスを確認し、失敗すれば再起動し、最後の手段として許可した場合だけマシンを再起動します。各ウォッチのチェック種別は、プロセス、HTTP／TCPプローブ、または専用のMySQL／PostgreSQLチェックです。

データベースのハートビートは、プロセス／ポート確認が見逃す故障を捉えます。MySQLハートビートはパスワードなしでSELECT 1を要求します。成功または「access denied」ならMySQLが応答中、接続拒否、タイムアウト、接続上限到達なら異常です。MySQLパスワードは保存せず、テーブルも読み取りません。空のプローブ名はrootではないfs_watchdogになり、このアカウントは実在しなくても構いません。PostgreSQLハートビートはユーザ名やパスワードなしでpg_isreadyを使います。エラーログの早期警告をオンにすると、データベース自身のエラーログも追尾して破損の兆候を重大イベントとして通知します。これらはサーバ上で動くため、MacがオフでもntfyやWebhookで自律的に通知できます。

チェック専用アカウントを作るには、your_databaseと例のパスワードを置き換えます。

CREATE USER 'frontierstack_health'@'localhost' IDENTIFIED BY 'use-a-unique-random-password';
GRANT SELECT ON `your_database`.* TO 'frontierstack_health'@'localhost';

このログインをDatabase Healthに保存します。手動チェックと検証済みバックアップが両方成功するまで自動修復はオフにしてください。完全なバックアップや修復に追加権限が必要な場合は、MySQLが示したスキーマ単位の権限だけを追加し、*.*は使いません。別のマシンから接続するモニタでは、localhostをその1つの正確なプライベートアドレスに置き換えます。

ピン留めサーバのサービス行では、定期テーブルスキャンまたはサーバ自己修復が有効な間、緑のDBチェッカー：オンを表示します。対象はあるがどちらも動いていない場合は一時停止、MySQLスキャンを選択していてもパスワードがない場合は緑ではなくオレンジのログインが必要を表示します。Database Healthは低頻度でテーブルを検査し、ハートビートは停止を素早く検出してサーバ上でMySQLを再起動するため、両方は補完関係です。

データベースが停止ではなく遅い・詰まっているときは、Database Healthペインの各対象にある「Why slow/stuck?」ボタンがその場で答えます。サーバのライブ活動（MySQLはSHOW FULL PROCESSLIST、PostgreSQLはpg_stat_activity）を読み、実行中クエリを形状ごとにまとめます。リモート対象はSSH経由で調べるため、データベースのポートを公開する必要はありません。

11.11.2保守のためにチェックを一時停止する

意図的にサービスを停止している最中に、再起動してくれるウォッチドッグはまさに邪魔です。保護をオフにして — そして自分で戻し忘れないことに頼る — のではなく、Guardian ヘッダーの 「Pause Checks…」、または各サービス行の一時停止ボタンを使います。15 分から 1 日までの範囲を選べます。

一時停止中、Guardian は対象のヘルスチェックも再起動も行わないため、作業と衝突しません。何も無効化されず、設定も失われません。Keep Alive、Auto Recover、しきい値、間隔はそのまま保持され、時間が過ぎれば自動的に再開します。「Resume Now」を押せば即座に再開できます。一時停止がその期間を超えて残ることはなく、アプリを終了して再度開いても同じです。

11.6ケーススタディ：High Sierra Server.app の serviceproxy ハング

High Sierra 上の macOS Server（Server.app）を今も動かしている古い Mac には、よく知られた故障があります。Web フロントプロキシ——実際のバックエンドの手前でポート 80／443 を握る launchd ジョブ com.apple.serviceproxy——が、ときどきハングするのです。TCP 接続は受け付け続けるのに一切応答しなくなるため、背後のすべてのウェブサイトが停止する一方、プロセスチェックはどれも正常に見えます。Apple からの修正はありません。このスタックはサポート終了です。Service Watchdog はまさにこのケースを念頭に作られています。

ウォッチの設定方法。サーバのペインでサービス名 serviceproxy のウォッチドッグ項目を追加し、——ここが重要ですが——プロセスチェックではなく、ターゲット http://127.0.0.1/ の HTTP チェックを設定します。本当の故障（接続は受けるが応答しない）を見抜けるのは HTTP プローブだけです。失敗すると、ウォッチドッグは launchctl kickstart で復旧します——管理者が手で打つ修復コマンドそのものです。HTTP ステータスが 500 未満なら生存と見なされ（プロキシが 403／404 を返しても応答している証拠です）、各プローブは 6 秒でタイムアウトするため、ハングしたプロキシはタイムアウトでチェックに失敗します。プロキシ背後のバックエンドも同様に server-httpd として監視できます。

推奨タイミング。チェックは 30 秒ごと、3 回連続で失敗したら再起動、再起動は最大 3 回、再起動後の猶予はデフォルト（約 20 秒。古いハードウェアの Apache にも十分）のまま。これで行動前に約 90 秒かけてハングを確認します——1 回の遅い応答や一時的な負荷スパイクでは kickstart せず、本物のハングなら約 2 分でサイトが自動復旧する長さです。サイトが重要なら 15〜20 秒間隔・2 回失敗（確認まで約 40 秒）に詰めても構いません。それ以上詰めても誤再起動が増えるだけです——古いマシンは負荷時に応答へ数秒かかることが普通にあるからです。「回復に失敗したらサーバを再起動」は、完全に無人のマシンでない限りオフのままに。実際には kickstart でハングは解消しますし、この種のマシンでの最終手段の再起動はダウンタイムを増やすだけです（ブートループ防止ガードにより、ウォッチドッグ再起動の間隔は最低 30 分が強制されます）。

なぜプロセスチェックではだめか。serviceproxy という名前のプロセスは存在しません——このジョブは特殊な設定ファイルを持つ httpd として動きます——そのため v1.6.1 より古いモニタは、正常なプロキシを恒久的に「停止中」と誤読し、何度も再起動を繰り返し、再起動へのエスカレーションを許可していれば正常なマシンを定期的に再起動していました。v1.6.1 からモニタは launchd にジョブの実状態を問い合わせるため、プロセスチェックも真実を伝えます。ただし本当のハングを捉えるのは引き続き HTTP チェックです。原因不明の再起動を繰り返す古いサーバがあれば、まずモニタのバージョンを確認してください。なお「なぜ再起動した？」はウォッチドッグ起因の再起動を明示的に帰属させます（v1.6 以降のモニタでは理由付き。それより古いモニタもスタンプを残し、それも報告されます）。

配信についてもう 1 つの保証があります。アラートは決して沈黙しません。メッセージングゲートウェイに加えて、状態変化のアラートはすべて、ゲートウェイとは独立にネイティブの macOS 通知とプッシュも発報します——メールをオフにしすべてのチャネルを無効にしても、サービスの停止は Mac 上であなたに届きます。データベースのリカバリ——mysqlcheck／pg_amcheck の実行や AI ガイド付き再構築——は第 5 章で扱います。

11.7インシデント・オンコール・ステータスページ

すでに正式なインシデント対応を運用しているチーム向けに、FrontierStack はそれを置き換えるのではなく、お使いのツールへ接続します。各ツールはカタログのエントリから開けるライブペインを持ち、読み取り専用の API キーを貼り付けると現在の状態を表示します。

• インシデント管理・オンコール — PagerDuty（オープン／高緊急度のインシデント、オンコール担当、サービス）、Opsgenie（未対応／未確認のアラート、US／EU リージョン切替）、incident.io と Rootly（進行中のインシデント）。
• ステータスページ — Statuspage（未解決インシデントと DOWN のコンポーネント）と Better Stack（モニタの up／down／paused）。

各ペインでキーを設定し（例：PagerDuty ▸ Integrations ▸ API Access Keys）、接続を確認します。これらは同じ監視像に流れ込むので、PagerDuty のオープンインシデントやステータスページの DOWN コンポーネントが、自前の健全性と並んで表示されます。

11.8SaaS ライブ監視とプロジェクト管理ペイン

FrontierStack はインフラだけにとどまりません。設定駆動の SaaS ライブ監視が接続済みクラウドアカウントを見守り、数分ごとに更新します。各サービスには資格情報フォーム、ライブのメトリックタイル、「Alert me」トグル、しきい値があります。アラート対応サービスはメトリックが線を超えると DOWN アラートを発報し、残りは到達性を監視します。ライブ監視には Stripe（要対応の係争、残高）、Shopify と WooCommerce（未処理注文）、Freshdesk と Zammad（オープン／保留／期限超過チケット）、SendGrid・Mailgun・Postmark（バウンスとブロック）、GitHub Copilot（非アクティブシート）、アイデンティティプロバイダの Okta と Microsoft Entra ID が含まれます。サービスをピン留めすれば、アラート設定に関わらず常時 Local Health に表示できます。

同じパターンがプロジェクト管理ツールにトークンログインのライブペインを与えます。Jira（オープン／未割当／ブロック／スプリント内の件数）、Linear、monday.com、OpenProject、Plane、Taiga。これらはアラート源というよりダッシュボードですが、チームの作業量を、それを動かすサーバと同じウィンドウに並べます。メール配信には専用の統合 Email Delivery ペインがあり、トランザクションプロバイダのメトリックと SPF／DKIM／DMARC チェックを統合します（第 7 章）。

11.9キュー運用

キュー運用は RabbitMQ、Kafka、NATS／JetStream、Redpanda、AWS SQS、Azure Service Bus、Google Pub/Sub、Celery／Flower、Redis Streams、Apache Pulsar、Apache RocketMQ の読み取り専用ダッシュボードです。ブローカ、名前空間、クラウドアカウントごとにモニタを追加します。プロバイダが公開する範囲で、キューまたはコンシューマグループ名、待機中・処理中・コンシューマ数、遅延、デッドレター数、最古メッセージの経過時間を表示します。メッセージ本文を読んだり保存したりすることはありません。

クライアントポートと管理ポートは分けて扱います。たとえば RabbitMQ クライアントは通常 AMQP の 5672、管理 API は 15672、NATS クライアントは 4222、監視は 8222、Pulsar クライアントは 6650、HTTP 管理 API は 8080 です。監視エンドポイントは非公開にしてください。オンホストの FrontierStack モニタを経由しない場合は TLS と監視専用アカウントを使います。

連携サーバでは導入済みモニタを選ぶと、署名付き接続を通じて、資格情報を受け取らないヘルパから上限付きサマリーを取得します。クラウドプロバイダは通常のローカル CLI プロファイル、またはキーチェーンに保存した権限を絞った資格情報を使います。重大しきい値は Alerts スイープに入り、同じサニタイズ済みサマリーを iPhone／iPad アプリと AI 管理者の読み取り専用 get_server_health ツールから確認できます。このダッシュボードには消去・削除・発行・確認応答・再生の操作はありません。

11.10UPS 監視と SNMP デバイス

電源は、停電するまで忘れられがちな故障モードです。FrontierStack は UPS を 3 通りで検出します——macOS の電源ソース（pmset -g ps）、NUT デーモン（upsc）、apcupsd（apcaccess）——そして充電・残時間・負荷・入力を Power Control の UPS セクションに表示します。アラートをオンにすれば、ユニットがバッテリー駆動になったとき、設定した低充電しきい値に達したとき、コントローラとの通信を失ったときに呼び出されます。UPS をピン留めすれば Local Health と Places マップに残せます。NUT や apcupsd が無ければワンクリックボタンでインストールできます。スキャンはこれらのデーモンの応答を待つため、実行中は Stop ボタンが表示されます。NUT サーバが固まっている場合は待ち続けずに停止でき、取得済みの読み取り値は保持され、自動更新は Refresh を押すまで一時停止します。

SNMP を話すその他のもの——マネージドスイッチ、プリンタ、ネットワーク UPS、NAS——には、デバイス詳細ペインの SNMP / OIDs セクションが直接問い合わせます。組み込みのテンプレート（System、Host Resources、Interfaces、Printer RFC 3805、UPS RFC 1628、Synology、QNAP、APC PowerNet）を選んで Query を押せばラベルと値の読み出しが得られ、単一のカスタム OID を手動で取得することもできます。OID をウォッチすることも可能です。比較としきい値（より大きい、等しい、含む、または単に「変化したら通知」）を設定すると、FrontierStack がポーリングし、条件が満たされるとアラートを発報します。net-snmp を使い、ワンクリックでインストールできます。

11.11ディスク・RAID・SMART の健全性

ドライブは、耳を傾けていれば予兆とともに故障します。Disk Health ペイン（組み込みの監視ツール）は複数の層を組み合わせます。ボリュームの空き容量と Time Machine の状態は常に表示されます。smartmontools をインストールすると（ワンクリックの Install ボタン）、各物理ドライブがディープ SMART 属性——健全性、温度、通電時間、代替済み／保留中セクター、故障予測フラグ——で補強され、ドライブごとに Check ボタンと、生レポート用の Details シートで確認できます。ドライブは SMART 失敗または懸念される属性（代替済み／保留中セクター、故障予測）でアラートを発報し、完全な死亡時だけではありません。

ソフトウェアの AppleRAID セット（ミラー、ストライプ、連結）は、レベル・状態・メンバーごとの状態とともに独自のセクションに表示されます。セットが劣化したりメンバーがオフラインになるとアラートが発報します。Alerts & Thresholds でディスクアラートをオンにすれば、他のすべてのモニタと同様にチャネルへ流れます。

これらのモニタを合わせると、ひと目で見るボード 1 つ、調整するペイン 1 つ、あなたに届くチャネル 1 式が得られます——そして同じ健全性を読み、あなたに代わって同じ通知を送る AI 管理者（第 13 章）があります。フリート全体の CPU・メモリ・GPU メトリックをこの像に流し込むホストモニタは第 8 章で扱います。

優れたサーバ管理者は、同じ数種類の作業を何度も繰り返します。バックアップを取る、キャッシュを温める、バックエンドを正しい手順で再起動する、vhost が思った通りのものを実際に配信しているか確認する。FrontierStack はそれぞれを保存済みスクリプトとして取り込み、ワンクリックで実行し、信頼できると判断したら cron に渡して無人で走らせます。そこからさらに外へ — Apple ショートカット、Siri、frontierstack:// URL スキーム、そしてアプリ自身がスケジュールで行うアクションへと広がります。

本章は自動化の機械的な側面 — スクリプト、スケジュール、macOS の自動化の入口 — を扱います。知的な側面、つまりこれらのスクリプトをあなたの代わりに書き・保存し・スケジュールする AI は、第 13 章です。ここで扱うものはすべて、AI 管理者が自身の監査済みツールを通じて操作できるため、両章は同じ仕組みを両端から説明しています。

12.1Scripts & Cron ペイン

サイドバーから Scripts & Cron を開きます。保存済みスクリプトのライブラリとスケジューラが 1 か所にまとまっています。上部の Saved Scripts セクションには保存した全スクリプトが、名前と本文の冒頭行とともに並びます。各スクリプトには 4 つのボタンがあります — Run（今すぐ実行）、Schedule（後述の cron に渡す）、Edit（エディタを開く）、そして削除のゴミ箱アイコン。Add Script… で新規作成します。

保存済みスクリプトは、アプリが解釈する断片ではなく、ディスク上の本物の実行ファイル（シェル・PHP・Python）です。分かりやすい名前と、目的を記したメモを付けておけば、半年後の自分（あるいはライブラリを走査する AI 管理者）が、何をするスクリプトかをひと目で把握し、正しいものを選べます。保存されたファイルそのものが実行されるので、手で試したものが、そのままスケジュール実行されます。

各スクリプトは既定の This Mac、ローカルの Docker コンテナ、または名前を指定した連携サーバを SSH 経由で対象にできます。資格情報が必要な場合、スクリプトはローカルの .env ボールトの名前付きシークレットを環境変数（$DB_PASSWORD、"$SSH_SUDO_PASS"）として参照します。アプリは実行時に実際の値を注入し、その値がクラウドモデルに届くことは決してありません（第 13 章）。

12.2cron でのスケジュール実行

Cron Jobs セクションは、本物のシステム crontab への分かりやすいフロントエンドです — アプリが独自に考えた別物のスケジューラではなく、何十年も Unix で無人作業を走らせてきた、まさにその cron です。各行はジョブの名前、スケジュールの平易な説明（FrontierStack が 5 フィールド構文を翻訳します）、実行するコマンドを表示し、有効／無効の切り替えと、Run（今すぐ実行）・Edit・削除のボタンを備えます。

保存済みスクリプトの Schedule、または任意コマンド用の Add Job… を押すとスケジュールビルダーが開きます。頻度（毎時・毎日の指定時刻・毎週）を選ぶと、FrontierStack が crontab エントリを書き込み、自身のジョブには # AC: コメントを付けて後から名前で見つけ・更新できるようにします。AI 管理者でも同様で、list_cron がジョブを読み、schedule_cron が作成・更新します（同名のジョブがあればその場で更新）。

完全に制御したい場合は、ペイン下部の Edit raw crontab を展開します。これはテキストエディタで開いた標準の crontab で、FrontierStack 管理のジョブは # AC: コメントとして現れるため、どの行がアプリの所有かが分かります。手で編集して Apply を押します。

12.3同梱のサンプルスクリプト

FrontierStack は、実績ある定番の管理スクリプトを小さな読み取り専用ライブラリとして同梱しています。あなたのスクリプトではなく — その場で編集はできません — が、どれも全ソースを読んで学び、自分のライブラリにコピーして手を加えられます。Mac の Web スタック（とくに旧 macOS Server バックエンド）の実地の癖を踏まえているため、自作の前に 1 つ読んでおくと不意打ちを避けられます。AI 管理者も list_sample_scripts と read_sample_script でまず読むので、その生成スクリプトも同じ苦労から得た知見を受け継ぎます。

12.4Apple ショートカット・App Intents・Siri

FrontierStack はネイティブの App Intents を備えます — macOS の ショートカットアプリ、Spotlight、そして（いくつかは）話せる組み込み Siri フレーズとして現れるアクションです。ホットキー・メニューバー・フォルダアクションから起動するショートカットに組み込めます。Automator からも利用可能で（Automator はショートカットや AppleScript を実行できるため）。出荷時のアクション:

カタログはさらに広く — Get Server Status、List Servers、List Docker Containers、Check a Website などもショートカット作成に利用でき、組み込みの Siri フレーズを持たないものも含めて使えます。

12.5スクリプトからアプリを操作する

App Intents は本物のショートカットアクションなので、macOS の shortcuts コマンドラインツールでシェルから呼び出せます — 保存済みスクリプト、cron ジョブ、Automator の「シェルスクリプトを実行」、あらゆるランチャの中で便利です。FrontierStack のアクションを一行のショートカットに包み、shortcuts run "My Shortcut" で呼び出して、スクリプトの他の処理と連鎖させます。

この組み立ては AI 管理者に任せられます。ショートカット経由でアプリを操作する自動化スクリプトを頼むと、list_app_intents を呼んで利用可能なアクションと各々の正確な shortcuts run 呼び出しを把握し、save_script でスクリプトを作成（または schedule_cron でスケジュール）します。ヒントではなく、完成して実行可能なスクリプトが手に入ります。

12.6スケジュールされたアプリアクション

cron ジョブはシェルコマンドを実行します。スケジュールされたアプリアクションはそれとは異なり、アプリ自身がスケジュールで行うタスクで、保存した資格情報と、あなたや AI 管理者が使うのと同じ監査済みツールを用います — 生のシェルコマンドではありません。連携サーバの再起動、アプリが制御するローカルサービスの開始・停止・再起動、DNS のフラッシュを時間割で行うのに使います。schedule_app_action で管理し、list_app_actions で一覧でき、ペインの Scheduled App Actions に現れます。作成の自然な方法は AI 管理者に頼むこと — 「web-03 を毎晩 3 時に再起動」— そして承認することです。

cron との重要な違いが 1 つあります。アプリアクションは FrontierStack が起動している間だけ実行されます。アプリを通じて動作するため、アプリが閉じている間に期限を迎えたものは取りこぼします。一方 cron は、アプリが開いていようといまいと、システムレベルで実行されます。何があっても起こさねばならないことは cron を、アプリ自身の資格情報とツールで行わせたいことはアプリアクションを選んでください。

12.7frontierstack:// URL スキーム

すべてのペイン・サーバ・サイト・コンテナ・Cloudflare ゾーンに frontierstack:// のディープリンクがあります。AppleScript、Automator のシェルステップ、ランチャ、あらゆるスクリプトランナーから、open frontierstack://pane/Security のような一行で、アプリを前面に出して目的のペインへ直行します。ヘッドレスでアクションを実行するのではなく、特定の場所でアプリを画面に出したいときに、FrontierStack を既存のワークフローへ組み込む最速の方法です。URL スキームの完全なリファレンスは第 18 章にあります。

12.8バックアップ・ログ・変更ログの自動エクスポート

定型自動化の最後のピースは、FrontierStack 自身が生成したファイルをスケジュールで Mac の外へ出すことです。Backups の概要にある Auto-export to a folder セクションは、生成された成果物を選んだ任意のフォルダへコピーします — オフサイト保全のための Dropbox フォルダ、または独自の後続ルールを駆動する Hazel 監視フォルダへ。3 つのフィードが組み込まれています:

• 設定バックアップ — 構成バックアップの zip。
• 変更ログ — アプリを通じて行われた変更の記録。
• アプリログ — FrontierStack 自身のログの zip。

各フィードに間隔（毎時・6 時間・12 時間・毎日・毎週）を設定し、保存先フォルダを選び、必要なら Empty after export をオンにして、コピー後にソースをローテートできます（変更ログとアプリログに便利。際限なく肥大しません）。Export now はフィードを即時実行し、各フィードは前回の結果を表示します。ファイルは選んだフォルダに FrontierStack-<feed>-<timestamp> として置かれます。