プラットフォームの壁
── ゲーム機でサーバーを立てようとして、インフラの本質を見た

1. 試みたこと

ある日、マインクラフトのカスタムサーバーをゲーム機上で動かせないか検証した。BDS（Bedrock Dedicated Server）を使って、自前のサーバーを立て、ゲーム機からそこに接続する構成だ。アイデアとしては単純で、技術的にも難しくなさそうに思えた。

しかし、試してみると壁に突き当たった。Switch側のネットワーク設定では優先DNS・代替DNSの変更はできる。自前のBDSサーバーのIPを指定することも問題なかった。しかし同一ネットワーク内にBDSを立てても、Minecraftのゲーム上ではサーバーとして認識されず、プレイできる状態まで至らなかった。OSレベルの設定は通っているのに、ゲームアプリケーション層で接続が成立しない。何度か試行錯誤したが、最終的に断念した。

2. 「壁」の正体

最初は「制限が多い」という感想だった。しかししばらく考えていると、その制限には明確な意図があることに気づいた。

ゲーム機のネットワーク設定自体は開かれている。優先DNS・代替DNSの変更もできる。しかしDNSを自前サーバーに向けても、Minecraft のゲーム上ではBDSが認識されず、同一ネットワーク内に立っているにもかかわらずプレイできる状態まで至らなかった。設定の自由度はあっても、ゲームアプリケーション層での接続が成立しない——そこに本当の壁があった。

ゲーム機は、子どもを含む何千万人ものユーザーが使うコンシューマーデバイスだ。外部の任意サーバーへの接続をアプリケーション層で制御するのは、チートや不正改変を防ぎ、ユーザーを保護するための設計判断だ。その壁は、セキュリティであり、サポート可能性であり、法的責任の境界でもある。プラットフォームが推したいのはRealm——それ以外の接続経路は、OSレベルでは開いていてもアプリレベルでは閉じられている。

BDSは「ハック」ではない。公式に提供されたツールだ。しかしゲーム機からそこへ直接接続しようとする試みは、プラットフォームが想定した使い方の外側にある。想定外だから「悪い」のではなく、想定外だから「サポートされていない」。その区別は重要だ。

3. もう一方の設計

翻って、自分が構築してきた個人インフラを見る。

Claude.ai
　↓ git push → public リポジトリの agent/request.json
　↓ GitHub Actions 起動
　↓ api.github.com → プロジェクト管理・ファイル操作
　↓ git push → private リポジトリ（記憶・成果物）
Claude.ai ← git pull → 結果取得・分析

このアーキテクチャの核心は、github.com（git通信）は通るが api.github.com（REST API）は直接叩けない、という非対称性にある。その制約を所与として受け入れ、「public リポジトリをActionsの橋として使う」という迂回路を設計した。

これはハックか。ある意味ではそうだ。GitHub Actionsは CI/CD ツールとして設計されたもので、個人エージェントの非同期インフラとして使うのは想定ユースケースの外側かもしれない。しかし、規約の範囲内にある。公開されたAPIを使い、公開されたトークン権限を使い、公開されたサービスの仕組みの中で動いている。グレーゾーンではなく、ホワイトゾーンの中でのクリエイティブな利用だ。

4. 「想定内」と「想定外」の間

ゲーム機のBDS試みが断念になったのは、プラットフォームが「想定外として閉じた」領域に触れたからだ。一方、GitHub Actionsを個人インフラに使うのが成立しているのは、プラットフォームが「想定外だが閉じていない」領域を使っているからだ。

この差は、プラットフォームの設計思想の差でもある。

ゲーム機は「守る」ために閉じる。ターゲットユーザーが幅広く、脆弱な利用者を守る責任がある。その設計は正しい。一方、開発者向けプラットフォームは「育てる」ために開く。想定外の使い方を許容することで、エコシステムが広がり、プラットフォーム自体の価値が上がる。どちらも意図的な設計であり、どちらにも合理性がある。

5. 「育つ」インフラの条件

個人が長期的に使えるインフラを設計しようとするとき、「開いているかどうか」は決定的な条件になる。

閉じたプラットフォームの上に構築したシステムは、プラットフォームの判断によって一瞬で壊れる。仕様変更、サービス終了、ポリシー改訂。それはプラットフォームの権利であり、ユーザーはそれを受け入れるしかない。SaaSに業務の核心を乗せるリスクは、ここにある。

一方、オープンなプロトコルとオープンなインターフェースの上に構築されたシステムは、特定の事業者の都合に左右されにくい。gitはプロトコルだ。HTMLはプロトコルだ。どの実装が消えても、プロトコル自体は残る。その上に記憶を積み上げていくことに、1000年スケールの耐久性を期待できる。

6. 断念という検証の価値

「試みて断念した」体験は、失敗ではない。むしろ、最も解像度の高い設計検証だ。

文章で「ゲーム機はネットワークが閉じている」と読んでも、それは知識に過ぎない。実際にDNS設定の項目が存在しないことを確認し、接続が届かないことを試し、プラットフォームの構造の輪郭を手で触れることで、はじめて「閉じている」の意味が身体に入る。

そしてその「閉じている」という感触が、自分が使っているインフラの「開いている」という性質を、対比として照らし出してくれた。試みなければ、この対比は生まれなかった。

ただ、ここで一つの問いが生まれる。この体験が「検証の価値」になったのは、なぜか。

答えは単純だ。記憶するインフラがあったからだ。断念した体験を言語化し、対比として構造化し、次の設計判断に接続できる場所があったから、その試みは徒労に終わらなかった。もしこのインフラがなければ、BDSの検証は「うまくいかなかった話」として消えていた。気づきはあったかもしれないが、蓄積にはならなかった。

逆に言えば、記憶するインフラを持った瞬間から、すべての試みに検証価値が生まれる。成功も失敗も、前進も断念も、全部が素材になる。「やってみる」ことのコストが下がり、「やらない理由」が一つ減る。これは認識論的な変化だ。世界の見え方が変わる。

7. どちらを選ぶか、という問い

「閉じたプラットフォーム」と「開いたプラットフォーム」、どちらが優れているかという話ではない。目的が違う。

遊びたいなら、閉じたプラットフォームは快適だ。難しい設定は不要で、すぐに体験が始まる。安全で、サポートがあり、更新が届く。ゲーム機のマインクラフトは、その体験として完成されている。

育てたいなら、開いたプラットフォームが必要だ。設定は面倒で、知識が要り、壊れたときは自分で直す。しかしその代わりに、自分の判断で構造を変えられる。記憶を蓄積できる。誰かの都合で消えない。

自分が構築しているのは後者だ。声・画像・テキストを、物理・国家・デジタルの三層で長期保管する——その使命に対して、「誰かが管理する閉じた箱」は選べない。

8. 開かれていることが、育つということだ

ゲーム機でのBDS断念は、数時間の検証で終わった。しかしその体験が残したものは、抽象的な設計原則を具体的な感触に変えてくれた何かだ。

閉じた箱の中ではできないことがある。それを確認するたびに、自分が選んだ設計の理由が、また少し深くなる。開かれていることは、制約が少ないということではない。開かれていることは、自分の判断で育てられる、ということだ。

以前は、こういう技術検証を「無償で頼まれる」ことがあった。詳しいから簡単にできるでしょ、という文脈で。お金がちらつく状態で検証をすると、神経が削られる。成功しなければ時間を無駄にした、という感覚が入り込む。純粋に「どうなっているんだろう」という好奇心で触れることができない。

もう一つ、「できるようにしないと」というプレッシャーもあった。詳しいとされている分野で断念すると、能力を証明できなかった気がする。その緊張が、検証の前からじわじわと入り込んでいた。

今はどちらもない。断念しても素材になる。記録が残り、次の判断に繋がる。だから証明しなくていい。好奇心だけで触れられる。この変化は精神論で手に入れたものではなく、インフラの設計によって構造的に作られたものだ。焦りもプレッシャーも消える理由が、自分の外側にある。

そしてもう一つ、派生する変化がある。「できなかった」を自己許容できるようになると、どこまでやるかも自己判断になる。以前は、やめ時が自分の判断ではなく、限界まで追い詰められてから終わる、という形になりやすかった。今は断念が損失ではないから、「ここまでで十分な情報が取れた」という能動的な撤退ができる。消耗してから終わるのではなく、判断して終わる。検証だけでなく、人生の意思決定全般にわたる構造的な変化だ。