セルフホストAIワークスペース「OpenMake LLM」を作った：vLLM/LiteLLM・MCP・エージェントを分離する設計

ローカルLLMをチャット画面につなぐだけなら、OpenAI互換APIとUIがあれば始められます。しかし、日常的に使えるワークスペースにしようとすると、次の課題がすぐに出てきます。

• 通常のチャットと、調査・エージェント実行をどう分けるか
• ローカルモデルと外部モデルを同じ操作感でどう扱うか
• MCPツールを増やしても、毎回すべてのスキーマをモデルへ渡さずに済むか
• シェル、ブラウザ、ファイル操作をどこまで隔離するか
• PDF/DOCXなど、回答の先にある成果物をどう作るか

この問題を自分たちの環境で解くために、MITライセンスの OpenMake LLM を開発しています。本稿では機能一覧ではなく、セルフホスト環境でどの境界を分けたかを中心に紹介します。

• ソース: github.com/openmake/openmake_llm
• 日本語ページ: openmake.cc/ja
• デモ: chat.openmake.cc

0. なぜ、もう1つAIワークスペースを作るのか

OpenMakeは会社ではありません。オープンソースソフトウェアとオープンハードウェアが好きで、自分たちのマシンでサービスを動かすことを大切にしているチームです。

OpenMake LLMを作り始めた理由は、多くのAIワークスペースがローカルモデルに接続できても、実際の設計はクラウド中心で、ローカルモデルが互換オプションに見えることでした。私たちは順序を逆にしたいと考えました。自分のvLLM/LiteLLM gatewayを通常の経路にし、外部モデルは運用者が必要なときだけ、自分のキーとポリシーで有効にする構成です。

私たちが実際に開発・運用検証に使っているのは、Mac mini + NVIDIA DGX Spark の2台構成です。DGX SparkはNVIDIA GB10 Grace Blackwell Superchipを搭載しています。Mac miniでOpenMake、PM2、loopback専用LiteLLM gatewayを動かし、Tailscaleの内側に置いたDGX SparkでQwen、BGE、FLUXのvLLM endpointを提供しています。これは必須ハードウェアではなく、OpenAI互換endpointであれば別の構成に置き換えられます。

Mac mini
  OpenMake / PM2 / LiteLLM (127.0.0.1)
                     │
                 Tailscale
                     │
NVIDIA DGX Spark (GB10 Grace Blackwell)
  vLLM: Qwen / BGE / FLUX

また、すべての質問を複数agentへ送る構成にもしていません。通常chatは1つのモデルと共通tool loopで処理し、複数の視点が必要なときだけDiscussionを明示的に使います。Discussionでは専門家を選択し、数を制限した並列意見、相互レビュー、根拠の再利用、最終統合を行います。この区別は、単純な質問を速く保ちながら、必要な仕事だけに追加の計算資源を使うためです。

現在のv1.19.0は完成した「AgentOS」ではありません。ローカル・オープンウェイトAgentOSは方向性であり、永続実行、Memoryのscope、検証、運用者向け監査記録にはまだ作るべき層があります。本稿では完成している部分と、まだ制約として残る部分を分けて説明します。

1. リクエスト処理とモデル実行を分離する

OpenMake LLMでは、リクエストの検証・組み立てと、実際のモデル呼び出しを別の層にしています。

WebSocket / REST
       │
       ▼
message-pipeline
  - provider gate
  - security / language policy
  - prompt / toolの組み立て
  - custom agentの解決
       │
       ▼
streamFromExternalProvider
  - local / external共通のtool loop
       │
       ▼
LLMClient.chat
  - context見積もり
  - truncation / output cap
       │
       ▼
vLLM → LiteLLM（OpenAI互換endpoint）

message-pipeline がprovider gate、セキュリティ事前検査、言語ポリシー、system promptとtoolの組み立てを担当します。現在の ExecutionPlanBuilder は名前を互換性のために残し、所有権を確認しながらcustom agentを読み込む責務だけを持っています。intentの分類はルーティング観測用の軽量な処理であり、別のLLMを一度呼んでモードを決める方式にはしていません。通常チャットでは、ローカルと外部モデルが共通の実行経路とMCP tool loopを通ります。

一方、DiscussionやDeep Researchのように複数ステップが本質になる処理は、その前段で明示的に分岐します。通常チャットを不必要に重くせず、複雑な処理だけを別モードとして扱うためです。

2. ローカルを標準経路にし、外部モデルはBYOKで追加する

標準構成は、vLLMで提供するローカルモデルをLiteLLMのOpenAI互換endpointの後ろに置く形です。外部モデルは、必要な利用者だけが自分のキーを登録します。

モデルの選択とは別に、機能ごとのroleを用意しています。たとえば agent、judge、research、spawn、review、summary です。roleごとの解決順は次の通りです。

user mapping
  → admin global mapping
  → environment default
  → local default

これにより、通常チャットはローカルのまま、調査やレビューだけ別モデルへ割り当てる構成も取れます。外部プロバイダーは必須ではありません。登録した認証情報は暗号化して保存し、到達不能なモデルは選択肢から除外します。

3. エージェントとMCPをDocker境界の中で動かす

チャットで検索ツールを1回呼ぶことと、エージェントがシェルやファイルを数ターン操作することは、同じ権限では扱えません。

OpenMake LLMのアプリケーション本体（APIとWeb）はPM2で動かし、PostgreSQL（必須）とRedis（任意）、エージェント・MCP・アーティファクト処理はDocker側に置きます。外部MCPサーバーにもnon-root、capability drop、memory/pids上限、network policyを適用できる構成です。

MCPサーバーが多くのツールを公開していても、毎回すべてのschemaを会話へ入れる必要はありません。カタログ側のallowlistと明示的なtool pickerを分け、通常会話で自動公開するツールを絞っています。

自律エージェントは永続的なDocker sandboxで複数ターンを進めます。シェル、Python、ブラウザ、ファイル操作に加えて、人の承認が必要な操作を途中で止められるようにしています。checkpointを保存し、サーバー再起動後は手動resumeで続きを実行できます。定期実行も別の仕組みとして用意しています。

4. 回答だけでなく、成果物まで同じ経路で扱う

調査結果をチャット本文だけで終わらせず、HTML artifactとして表示し、PDF/DOCXへ変換できます。

レポートでは、モデルにレイアウトそのものを書かせず、構造化データを生成させて固定rendererで描画します。これにより、KPI、表、SVG chart、出典の見た目を揃えやすくしています。PDF変換はheadless Chromium、DOCX変換は保存した構造化データを使い、変換処理はnetworkを切ったone-shot sandboxで実行します。

5. 最小構成で起動する

現在の前提はNode.js 24、Docker、PostgreSQL、そしてOpenAI互換LLM endpointです。

git clone https://github.com/openmake/openmake_llm.git
cd openmake_llm
npm install

cp .env.example .env
docker compose -f infra/docker-compose.yml up -d postgres

npm run dev

最低限、.env にはデータベース接続、JWT署名、認証情報暗号化、LLM endpointに関する値が必要です。詳しい変数とproduction起動方法はREADMEのGetting Startedにまとめています。

6. 現時点のトレードオフ

この構成には、次のような前提と制約があります。

• vLLMをローカルで動かす場合、対応GPUとモデル用のメモリが必要です。
• Node.js 24とDockerを前提にしているため、軽量な単一バイナリではありません。
• エージェントに強い権限を与えるほど便利になりますが、承認境界とsandbox設定の運用が重要になります。
• 外部モデルは任意ですが、有効にした場合のAPI利用条件や料金は各プロバイダー側に依存します。
• 公開デモは機能確認用です。セルフホスト時の性能は、使用するGPU、モデル、context長に大きく左右されます。
• ローカル・オープンウェイトAgentOSはロードマップ上の方向です。現在の実装を完成したAgentOSとして宣伝する段階ではありません。

おわりに

OpenMake LLMでは「全部を自動で判断する巨大なagent」ではなく、ポリシー、モデル実行、ツール、sandbox、成果物生成の境界を明示する方向を選びました。セルフホスト環境では、その方が障害箇所と権限範囲を追いやすいと考えたためです。

特に、次の点についてフィードバックをいただけるとうれしいです。

• 使用しているGPU・モデルと、実用的だったcontext設定
• vLLM/LiteLLMを既存環境へ組み込むときに不足しているドキュメント
• MCPサーバーの隔離とtool allowlistの設計
• エージェントに任せたいが、必ず人の承認を残したい操作

ソースとissue: github.com/openmake/openmake_llm