GrokBot 夢の六隻編成：OpenMausBot の選定裁定、Companion モードの素 IP 拒否、そして閉じた蓋の Mac との設計衝突

六台の無料クラウド機、一つのオープンソース統括者、「親ボットで指図すれば奴らが自動で協働する」という夢——本日の実現可能性審査はこの夢を基礎まで解体し、正しい基礎を敷き直した。

一、選定の裁定：フォロワー数は基準ではない

OpenBot 対 OpenMausBot の対決は、本質より先にデータを見ていた。OpenBot は二万フォロワーに対し MausBot は二千余り、しかも OpenBot は有料である。だが基準はそのどちらでもない——問われるのは、どの路線が実際に六台のクラウド機を指揮できる手に変えるかである。裁定は OpenMausBot に落ちた。オープンソースであり、デスクトップ Companion モードを持ち、公式文書がリポジトリ内に置かれて検証可能だからである。続く接続デバッグは文書の信頼性を証明した。Companion モードが受け付けるのは https://c-….openmausbot.com か .ts.net の MagicDNS 名のみで、素の IP と LAN ホスト名は設計上で拒否される——過去に試した 192.168.5.21:8799 も 127.0.0.1:18799 も初手で死んでいた。繋がらなかった原因は設定ミスではなく、入口のプロトコルそのものだった。

二、Mac の設計衝突：ロック画面は両手の拘束

Mac を作業機にする路線は本質的な衝突に当たった。MausBot が Mac 上で操るのはグラフィカルインターフェース（マウスとキーボード方式）であり、シェルではない。現場からの証拠連鎖はこうだ。ファイルは読めた（ls ~ で全四十一項目が列挙された）が、画面はロックされ、ターミナルは開かず、コマンドは走らない——ボット自身が「画面がロックされており、ターミナルが開けない」と認めている。ロック画面は両手の拘束を意味する。そして閉蓋サーバーは必然的に画面をロックする。これは設定の問題ではなく設計の衝突であり、二つの道のどちらか一方しかない。A、Mac を決してロックしない（機体全体が開放され、8GB デュアルコアでは GUI 操作に息詰まる）。あるいは B——推奨——Mac は serve のみを走らせ（チャット、記憶、タスク、定時ジョブに画面は不要）、六台の Instabox 機を決してロックしないコンテナデスクトップとし、ボットにコマンドを実行させ、ブラウザを開かせ、永久に起きておかせる。

三、六隻艦隊の真の編成

こうして GrokBot の夢の正しい実装が浮上した。Mac は脳として serve を走らせ（記憶とタスク）、六台の Instabox 機はロックしないコンテナデスクトップとして十の手になる。電話と PC は Mac に繋いで結果を受け取ればよく、PC の電源断は何も損なわない。路線に残る欠品は一つだけ。Instabox の API キーはすでにボット側に保管済みだが、ボットには手がなく取りに行けない。主人がキーを手渡しすれば、残り（docker の確認、エイリアスの設定、起床スクリプトの記述）はすべて保守範囲である。これは GrokBot の複製ではない。編成の一回きりの均衡である——脳は Mac に、手は機械群に。

四、夢の決算

本件から持ち出される一般結論は三つ。フォロワー数はマーケティングの台帳であり、アーキテクチャの台帳ではない。Companion モードの拒否は故障ではなく設計である——公式文書の二つの鉄則を読むことが、十のアドレスを試すことに勝る。そしてGUI 依存はボット化の死点である——いかなるロック画面方針もそれを断ち切り、serve モード（ヘッドレス、画面なし、ロックなし）こそが艦隊の正装である。六隻の夢は砕けなかった。正しい編成に変わったのである。