GCP環境でのPoCへの壮絶なトライ
筆者が目指すAIコンサルティング事業の一つの核は、**「AI連携ハブ（I.N.）」**という新しいインフラ思想の確立です。そのコンセプトの裏付けを得るため、GCP上でPoC環境の構築にトライしました。
- 目的: Go言語とGemini APIをセキュアに連携させ、ローカル環境とのハイブリッド接続を検証する。
- 初期設計: 最小限の費用で、PostgreSQL、Goアプリ、K3sを動かす。
Always Free環境の過酷な制約
費用ゼロのポリシーを貫くため、Google CloudのAlways Free枠を適用しました。その制約は予想以上に過酷でした。
| 項目 | 適用された制約 | 考察 |
| 場所 | オレゴン (us-west1) | 日本に近いという利点と、リソースが混雑しにくいという技術的な利点を優先。 |
| VM基盤 | e2-micro (1 GB RAM) | CPUパワーはCeleron下位レベル。インフラエンジニアの経験から「ドタ勘」で性能の低さを予測。 |
| ディスク | HDDベースの標準永続ディスク | 「まだHDDを使っていたのか！」と驚愕。SWAP発生時のI/O遅延（懐かしい遅さ）が避けられない。 |
この制約を受け入れ、「懐かしい遅さ♪」になるのを覚悟で、4 GBのSWAP領域を確保し、VMを作成しました。
💥 Docker、K3sインストール時点でのフリーズ
初期設定の段階で、早くも超貧弱な基盤の限界に直面しました。
- ネットワークの壁: VM作成直後、外部IPアドレスがない状態で
sudo apt updateやcurlが、IPv6のタイムアウトエラーでフリーズ。 - K3sの拒絶反応: ネットワークを修正し、軽量KubernetesであるK3sをインストールしたところ、システムが固着しました。
- 壮絶なログ:
net/http: TLS handshake timeoutというエラーが頻発し、ノードが「Ready」から「NotReady」へ転落する不安定な状態に陥りました。
**長年の経験から、「この現代っ子（K3s）は、レトロ環境では生きていけないんだ」**と悟りました。（実際は、1GBの物理メモリ不足により、K3sの複雑な内部RPC通信がSWAP遅延でタイムアウトを起こしていると推測）。
😴 運用設計の断念とAI連携への集中
このままではPoCの時間をリソース不足によるトラブルシューティングに費やすだけだと判断しました。
夜中まで作業し、Windows Updateの再起動というローカルPC最大の脅威に遭遇したことがきっかけで、**「運用系は全て諦める」**という決断に至ります。
- 当初の運用系PoCはリソース不足で無理と判明。
- 夢の中での決断: 運用系はバッサリ切り、**「GCP内でしかできないこと」**だけに絞る。
この方針変更により、PostgreSQLは諦め、SQLiteへの移行を決定。リソースをGoアプリと**「AIとの連携ロジック」**に全振りすることにしました。
🌟 Intelligent Nexus（I.N.）の誕生秘話
リソースの制約から生まれた究極の効率化コンセプトが、**「AI連携ハブ」**です。
筆者が「複数のサービスを連携させるハブの役割」を説明する際、ふと口にした言葉から、I.N.のネーミングが生まれました。
| ステップ | ログメッセージ（イメージ） | コンセプト |
| 旧技術の発見 | 筆者：「えっと、こういうなんかスイッチみたいなのなんていうんだっけ、L7スイッチとかどう？」ジェミニ：「2000年頃からすでにあります」 | 筆者はただの「時代遅れ」だったことに気づき、大恥をかくところでした（笑）。 |
| 新概念への昇華 | 筆者：「じゃあAI連携ハブとかどうよ。ネットワーク的にはレイヤ低いけど自然言語にちかくって、いいかもね、ハブ空港とかあるし。」 | **「AI連携ハブ」**という、サービスの中心としての役割を表現する概念が誕生。 |
| 最終決定 | 筆者：「このインテリジェントネクサス、かっけ～！」 | 響きと技術的洗練度を追求し、Intelligent Nexusに決定。 |
Intelligent Nexus（I.N.）とは、最小リソースで最大効果を出すために、認証（SSO）、AI、DB（SQLite）といった全てのトラフィックを理解し、知的にルーティングする、PoCの核心的コンセプトです。
📈I.N.の価値：集中と分散の「最適な境界線」そして未来
このI.N.の誕生は、ITの歴史的サイクルからも裏付けられます。
- 筆者：「大先輩に集中と分散は繰り返されるって聞いたけど本当だね。」
- ジェミニ：「その通りです。」
お客様の「集中と分散を繰り返して発展していく」という30年前の大先輩の教えは、今も完全に生きています。
| サイクル | 主なインフラ | 特徴 | コスト要因 |
| 集中 (Mainframe) | 大型集中処理 | 高いセキュリティと統制。 | 高額な維持費、柔軟性ゼロ。 |
| 分散 (C/S時代) | PC、LAN | 柔軟性と処理の分散。 | 管理の複雑化、セキュリティの分散。 |
| 再集中 (現在) | AWS/GCP (巨大データセンター) | 最高レベルのセキュリティ、無限の拡張性。 | コスト集中、特にセキュリティとガバナンスの維持費用。 |
サイクル主なインフラ特徴コスト要因集中 (Mainframe)大型集中処理高いセキュリティと統制。高額な維持費、柔軟性ゼロ。分散 (C/S時代)PC、LAN柔軟性と処理の分散。管理の複雑化、セキュリティの分散。再集中 (現在)AWS/GCP (巨大データセンター)最高レベルのセキュリティ、無限の拡張性。コスト集中、特にセキュリティとガバナンスの維持費用。
このPoCは、単なる技術検証ではなく、まさにクラウド時代の新しいインフラ思想を具現化しようとしています。
I.N.の弱点
- 略語の弱点: I.N.は略すと「IN」になり紛らわしい。
- 解決: A.I. 映画のように、I.N. または I.N. とドットを打ち、洗練された略称として運用することで決定。
まさかこの「Intelligent Nexus」という言葉が、超貧乏で2core 1GB RAM環境とHDDを使わざるを得なかった状況から生まれたとは、誰も思うまい。
