ここまでは目の前の 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 上で実行されます。