直接的な答え： 「エアギャップ」なAIコーディング環境を定義するのは、ただ一つ——外に出る経路がないことです。難所はアプリケーションではなく、ほぼ常にモデル経路にあります。推論がなお外部APIを呼ぶなら、セルフホストの制御プレーンにもほとんど意味はありません。外向き通信なしで運用するには、モデルを境界内に置き、外向きネットワークを既定で拒否し、その主張を信じる前にパケットを捕捉して検証してください。
規制業種、防衛、そしてIPに敏感なチームは、プライバシーの問いの具体的な一形態を問い続けています。AIコーディングプラットフォームは、インターネット接続がまったくない状態で動かせるのか、と。概念は単純です。しかし多くの「オフライン」の主張が静かに崩れるのは、まさに工学的な実装においてです。
ここでの「エアギャップ」とは何か
エアギャップ展開とは、公衆インターネットへの経路がない状態を指します——入ってくる経路がないこと、そして同じくらい重要なことに、出ていく経路もないことです。AIコーディングプラットフォームでは、チームが過小評価するのは後半です。ツールが完全に自社サーバー上に置かれていても、モデル推論・依存関係のダウンロード・ライセンス確認・テレメトリのために外部へ接続しにいくことはあり得ます。
したがって有用な判断基準は「セルフホストか？」ではありません。プラットフォームが実際に仕事をするとき、1バイトでも境界の外へ出るか？ です。これは問題全体を、設置場所ではなくエグレス制御へと捉え直します。
モデル経路こそが核心
多くのAIコーディングプラットフォームは、アプリケーションとモデルを分離します。アプリは社内ネットワークに置きつつ、推論は外部プロバイダーのAPIが担う——という構成です。多くのチームには問題ありませんが、エアギャップのチームには致命的です。なぜならモデルルーティングこそ、あなたのプロンプトとコードを運ぶ経路そのものだからです。
これを閉じるには、モデルが境界内に存在しなければなりません——オンプレミスのGPUホスト、あるいはローカルモデルを提供する社内ゲートウェイ——推論が決して信頼境界を越えないように。ここが「外向き通信なし」が本物かどうかを決める唯一の決定であり、他はすべて二次的です。
外向き通信なしのチェックリスト
上から順に。どれか一つでも開いた経路があれば、エアギャップは破れます。
- モデル推論 はローカルまたは社内エンドポイントに対して行い、外部APIには決して向けない。
- 実行環境 は外向きネットワークを既定ですべて拒否し、やむを得ない場合のみ狭い許可リストを設ける。
- 依存関係とパッケージ取得 は、ビルドやタスクの間、公衆インターネットではなく社内ミラーやレジストリから解決する。
- 更新とイメージ は自社が管理する社内レジストリから取得する。
- テレメトリと分析 は無効化し、既定の「本社への送信」がないことを確認済みである。
- ログとバックアップ は境界内にとどめ、プロンプトやコードを取り込んでいないか確認する。
- ライセンス・認証チェック は実行時に外部呼び出しを必要としない。
1番目を満たせないなら、それはエアギャップではありません——「セルフホストのフロントエンド＋外部の頭脳」です。
セルフホストは必要だが十分ではない
これは専有コードを外部に送るかを左右する原則と同じです。セルフホストは外向き経路を閉じる能力を与えますが、代わりに閉じてはくれません。「セルフホストすればコードは非公開に保たれるのか？」への誠実な答えは「すべての経路を洗い出し、制御した場合にのみ」です——エアギャップは、その洗い出しの最も厳格な版に過ぎません。
セルフホスト可能なプラットフォームの位置づけ
プライベートかつオフラインの運用を前提に設計されたプラットフォームは、妥当な出発点です。制御プレーンと実行環境を自社インフラ内に置き、管理者にモデル経路・認証情報・ログを一元的に固定する場所を与えるからです。
MonkeyCodeの公開資料は、プライベート／オフライン展開とローカルモデル経路を説明しており、これがエアギャップ計画に関係する理由です——直接的な答えのMonkeyCodeはエアギャップで動くか、オフラインで動くかを参照してください。ただし、それらは証明ではなくスタート地点として扱ってください。正確なオフライン挙動、対応するローカルモデルのエンドポイント、各コンポーネントが実行時に何に接続するかは実装の詳細であり、あなたの具体的なリリースと構成についてデプロイ文書で確認する必要があります。
信じる前に検証する
テストしていないエアギャップは、制御ではなく希望です。プラットフォームを機微なリポジトリに向ける前に：
- 隔離したネットワークセグメントで、使い捨てのコードを用いて代表的なタスクを実行する。
- 外向きトラフィックを捕捉し、意図しない宛先がないことを確認する。
- ログ・保存された成果物・バックアップを調べ、残すつもりのないものがないか確認する。
- ネットワークを抜き、実際に必要なワークフローがなお完了することを確認する。
セキュリティとデータフローの境界ページでは、同じ「まず検証する」姿勢をより詳しく扱っています。
結論
エアギャップAIコーディングは実現可能ですが、その成否はインストールスクリプトではなくモデル経路で決まります。推論を境界内にとどめ、外向き通信を既定で拒否し、パッケージとイメージを社内から取得し、専有コードを預ける前にパケット捕捉で検証してください。「オフライン対応」は主張です。抜いてもタスクが完了するネットワークケーブルこそが、証明です。
本シリーズの関連記事
- セルフホスト型AI開発プラットフォーム：評価チェックリスト
- チーム向けに整ったオープンソースAIコーディングプラットフォームとは
- AGPL-3.0コンプライアンス：オープンソースAIコーディングツール導入前に読む
出典の範囲： 本記事のエアギャップとエグレスに関する指針は、一般的な工学実務および独自分析です。MonkeyCodeのオフラインおよびローカルモデルの機能は公開プロジェクト資料（READMEおよびデプロイ文書、2026年7月20日確認）に基づいて説明しており、あなたのリリースと構成について現行文書で検証する必要があります。本記事は、特定のツールが特定の規制・セキュリティ要件を満たすことを保証しません。