直接回答： セルフホストはインフラへの制御を高めますが、モデル経路・リポジトリアクセス・ワークロード隔離・シークレット・ログ・バックアップ・アップグレード・運用責任を明示的に設計して初めて、プライベートで信頼できるものになります。
AI開発プラットフォームをセルフホストすると、組織はコード・プロジェクトデータ・モデルアクセス・実行インフラをより多く制御できます。同時に、重要な運用責任が組織側に移ります。
正しい問いは単に「展開できるか？」ではありません。「エンジニアリングチームのために、信頼でき、安全で、有用に運用できるか？」です。
より広いロールアウトの前に、このチェックリストで試験運用を準備してください。
1. セルフホストの理由を定義する
解決したい制約から始めます。よくある理由には次があります。
- ソースコードはプライベートネットワーク内に留める必要がある
- 開発タスクが内部サービスへのアクセスを必要とする
- 組織がモデル提供者を集中管理したい
- データレジデンシーや内部方針がホスト型サービスを制限する
- チームが独自イメージ・計算資源・ネットワーク構成を必要とする
- 組織が単一のホスト型インターフェースからの運用上の独立を望む。
理由を書き留めてください。それが設計判断を導き、セルフホストのプロジェクトが際限のないインフラ作業になるのを防ぎます。
2. コントロールプレーンとタスク環境を分ける
AI開発プラットフォームには通常、二つの異なるインフラ役割があります。
コントロールプレーンはユーザー・プロジェクト・要件・タスク・モデル構成・管理状態を扱います。開発環境ホストはコードを実行し、依存関係をインストールし、プロジェクトをビルドし、テストを実行し、プレビューを公開します。
役割を分けることは隔離と容量計画に役立ちます。ビルドの急増が管理コンソールを利用不能にすべきではありません。
MonkeyCodeの現在の公開展開ガイダンスは次を推奨します。
| コンポーネント | 開始時の最小構成 |
|---|---|
| MonkeyCodeコンソール | 2 CPUコア、4 GBメモリ、40 GBストレージ |
| 開発環境ホスト | 8 CPUコア、16 GBメモリ、100 GBストレージ |
これらは出発点であり、容量の保証ではありません。実際の容量はタスクの同時実行、リポジトリサイズ、ビルド負荷、ベースイメージ、保持方針に依存します。
3. 同時実行より先に隔離を計画する
各タスクは、信頼できないプロジェクトコードやモデル生成のコマンドを実行し得ます。開発環境をワークロード隔離の境界として扱ってください。
確認事項：
- タスクのファイルシステムがどう分離されるか
- どのネットワーク宛先に到達できるか
- CPU・メモリ・ストレージ・実行時間をどう制限するか
- 認証情報が環境にどう出入りするか
- 特権コンテナやホストマウントが必要か
- 環境と成果物がいつ削除されるか
- 開発者が制御を回避せずに実行中のタスクをどう確認できるか。
低い同時実行から始めてください。実際のCPU・メモリ・ディスク・ネットワークの挙動を観察してから増やします。
4. ソース管理と認証情報を棚卸しする
試験運用に含めるリポジトリを列挙し、範囲を絞った認証情報を使ってください。組織全体のトークンから始めないこと。
各ソース管理の統合について記録します。
- リポジトリの読み書き権限
- ブランチ作成権限
- プルまたはマージリクエストの権限
- Webhookのエンドポイントとシークレット
- トークンの所有者とローテーション手順
- 監査ログの利用可否
- 認証情報が期限切れになったときの挙動。
AIエージェントには、選ばれたタスクに必要なアクセスだけを与えるべきです。プラットフォームの管理上の利便性がトークンの範囲を広げてはいけません。
5. モデルへの到達方法を決める
プラットフォームのセルフホストは、すべてのモデルがローカルで動くことを自動的には意味しません。展開は外部モデルAPI、プライベートなモデルゲートウェイ、または同一ネットワーク内で運用されるモデルを呼ぶことがあります。
各経路を次の観点で評価します。
- 提供者へ送られるコードとプロンプトのデータ
- 提供者の保持・学習方針
- 地域の可用性とレイテンシ
- 認証とクォータ管理
- 代表的なタスクでのモデル品質
- 提供者の障害時のフォールバック挙動
- チームまたはプロジェクト単位のコスト可視性。
MonkeyCodeはGLM、Kimi、MiniMax、Qwen、DeepSeekを含む複数のモデルファミリーに対応します。試験運用では、一般的なベンチマークだけでモデルを選ぶのではなく、少なくとも二種類のタスクを試すべきです。
6. 承認済みの環境イメージを構築する
タスク環境は、制御されない認証情報とパッケージの寄せ集めになることなく、プロジェクトに必要なツールを含むべきです。
記録事項：
- ベースOSと更新スケジュール
- 言語ランタイムとパッケージマネージャー
- ビルドツール・ブラウザー・システムライブラリ
- 内部認証局とパッケージミラー
- 脆弱性スキャンとイメージ署名
- 誰がイメージを公開または選択できるか
- 古い環境がどうセキュリティ更新を受けるか。
試験運用では少数の承認済みイメージを使ってください。柔軟すぎると失敗の再現が難しくなります。
7. 可観測性を製品要件として扱う
運用者はインフラのメトリクスを、開発者はタスク単位の証拠を必要とします。
最低限、次を収集します。
- コントロールプレーンの健全性とエラー率
- 環境作成の時間と失敗率
- ホスト別のCPU・メモリ・ディスク・ネットワーク使用
- タスクの所要時間と状態
- モデルリクエストのエラーとスロットリング
- ビルドとテストの結果
- 保持とクリーンアップのイベント。
どのログがソースコード・プロンプト・モデル応答・認証情報を含み得るかを判断し、それに応じてアクセスと保持の制御を適用してください。
8. バックアップとアップグレードの手順を用意する
どの状態が永続的で、どの環境が再作成可能かを特定します。永続状態をバックアップし、復元をテストし、責任者を記録します。
アップグレード前：
- 現在のプロジェクトのリリースノートを読む
- 永続データをバックアップする
- ステージング環境で新バージョンをテストする
- 代表的なタスクと統合を実行する
- ロールバックの発動条件と手順を定義する
- ユーザーに見える変更を周知する。
オープンソースはシステムを検査・適応する力を与えますが、日常的なプラットフォーム運用を不要にはしません。
9. 小さく測定可能な試験運用を設計する
少数の開発者、限定したリポジトリ集合、代表的な三〜五種類のタスクを選びます。最初のタスクを走らせる前に成功を定義してください。
有用な指標には次があります。
- 環境起動の成功率と時間
- レビュー可能な変更に至ったタスクの割合
- ビルドとテストの合格率
- 人によるレビュー時間
- 完了タスクあたりのモデルとインフラのコスト
- アクセスまたは信頼性のインシデントの件数と深刻度
- エージェントの作業を理解し修正できるという開発者の自信。
試験運用は、ソフトウェアが導入できるかだけでなく、ワークフローが適合するかを明らかにすべきです。
10. ライセンスと組織方針をレビューする
MonkeyCodeはGNU Affero General Public License v3.0で公開されています。ライセンス、計画している改変、ネットワーク利用を法務チームとレビューしてください。あわせて、ソースコード・シークレット・サードパーティモデル・ソフトウェアサプライチェーン・ログ・インシデント対応に関する既存方針と展開を整合させてください。
公式情報で展開経路を確認する
インストールコマンド、構成、統合は時事的です。インストール前に現在のMonkeyCode展開ドキュメントを読み、オープンソースリポジトリを確認してください。
ドキュメントがリモートのインストーラーを提供する場合は、権限を昇格して実行する前にその内容を確認し、非本番環境でテストしてください。試験運用で使った正確なバージョン、構成、モデル経路、ロールバック手順を記録します。