MCP

Archestra エンタープライズ AI プラットフォーム：向いているチームと初回の Docker 起動ガイド

セルフホスト環境で MCP の接続を 1 か所に集めたいチームは、Archestra の Docker quickstart を 1 回試す価値がある。ただし起動コマンドはホストの /var/run/docker.sock をマウントし、ローカルのデータボリュームに書き込み、archestra/platform:latest は通常 release candidate が動く。この 2 点を受け入れてから試すこと。

公式ソース · Archestra

インストール

docker pull archestra/platform:latest

docker run \
  -p 127.0.0.1:9000:9000 -p 127.0.0.1:3000:3000 \
  -e ARCHESTRA_QUICKSTART=true \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v archestra-postgres-data:/var/lib/postgresql/data \
  -v archestra-app-data:/app/data \
  archestra/platform:latest

向いているのは誰か

  • 公式の位置づけは「オールインワンのオープンソース企業 AI プラットフォーム」：MCP registry、gateway、orchestrator を兼ねており、単一用途の MCP server ではない。適した形は、チームが自分のマシンにプラットフォームをセルフホストし、ユーザー、agent、Claude / Codex / Cursor クライアントを同じ 1 つの URL に向けること。ツール呼び出しはプラットフォームがまとめて引き受け、クライアントが知る入り口は 1 つだけだ。
  • その MCP gateway は OAuth + On-Behalf-Of を採用し、ツールを共有サービスアカウントではなくユーザー本人として実行する。呼び出しごとに人への帰属を重視するチームが明確な受益者だ。
  • 判断基準：問題が「あるクライアントにツールが 1 つ足りない」だけなら、単一の MCP server を探せば十分。複数のサービス、複数のクライアント、複数のアイデンティティを一元管理するとき、初めてプラットフォーム層の出番になる。
  • 適した環境：ローカルや社内ネットワークで Docker を動かせ、ソケットマウントのコストを評価する用意があるチーム。quickstart はポートをループバックアドレスに束ねるため、まず 1 台で試し、副作用を許容してから長期運用に移すのに向く。
  • 実行の前提：手元に Docker があること。証拠には最低リソース構成も対応 OS の範囲もなく、Docker 以外の実行方法にも触れていない。いずれも未確認だ。

3 分で初回試行

  • 実行の前に、公式が明示する 2 つの副作用を受け入れるか確認する。1 つは、コマンドがホストの /var/run/docker.sock をマウントし、コンテナがホストの Docker daemon を操作できるようになること。もう 1 つは、イメージの latest タグが最新の release を指し、通常は release candidate が動くこと。この 2 点は公式の説明に書かれており、評価の段階から織り込むべきで、デプロイ後の細かい話ではない。
  • 初回起動は読み取り専用の操作でもない。名前付きボリューム archestra-postgres-data と archestra-app-data が、データベースとアプリケーションのデータをローカルの Docker ボリュームに書き込む。公式のクリーンアップや取り消しコマンドはなく、繰り返し実験の間に古いデータが次の起動に影響するかも証拠では不明だ。重要なデータのあるホストで気軽に試さないこと。
  • 受け入れたうえで、公式のクイックスタートコマンドを実行する：
docker pull archestra/platform:latest

docker run \
  -p 127.0.0.1:9000:9000 -p 127.0.0.1:3000:3000 \
  -e ARCHESTRA_QUICKSTART=true \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v archestra-postgres-data:/var/lib/postgresql/data \
  -v archestra-app-data:/app/data \
  archestra/platform:latest
  • 確認できる成功シグナルはここまで：コンテナが動き続け、2 つのポートが 127.0.0.1 のローカルループバックアドレスだけに束ねられていること。quickstart が明示する設定は ARCHESTRA_QUICKSTART=true とこの一連のポート・マウントだけだ。ループバック限定のため、既定ではローカルマシンからしかアクセスできず、リモート接続の構成方法は証拠にない。
  • 次の一手は、Claude / Codex / Cursor をこの 1 つの URL に向けること。URL の具体的な値はコマンドに含まれず、プラットフォームの起動後にプラットフォーム側で確認する。初回ログインの手順も同様に未言及だ。

使用例

  • 例 1：複数クライアントの統一入口。場面：チームで Claude、Codex、Cursor を併用しており、クライアントごとに MCP を個別接続したくない。やり方：上の手順でプラットフォームをクイックスタートし、各クライアントを Archestra の同じ URL に向ける。期待できること：ツール呼び出しが MCP gateway を経由してユーザー本人として実行され、同じツール群が 3 つのクライアントで同じ入口を通る。境界：プラットフォーム側が具体的にどのサービスを受け入れられるか、証拠に一覧はなく、接続前に必要なサービスが含まれるか確認すること。
  • 例 2：共有サービスアカウントに残さない。場面：すべてのツール呼び出しが 1 つの共有サービスアカウント名で記録されることを、チームが受け入れない。使うのは gateway の同じアイデンティティ機構だ。やり方：接続後、ツールがユーザー本人として動くか確認する。今、共有アカウントで自動化を回しているなら、前後で比較できる。確認できる範囲：公式の説明はその通り。アカウント設定画面や呼び出しログの形は証拠になく、存在を前提にしないこと。
  • 2 つの例の違い：例 1 は入口の統一を、例 2 はアイデンティティの帰属を検証する。前後して各 1 回試すとよい。

利用の境界

  • 読み書きの性質：初回起動の時点でローカルの状態を書き込む（2 つの名前付きボリューム）。ソケットマウントによってコンテナはホストのコンテナを操作できる。これが最も重い副作用で、評価では独立して検討すべきだ。
  • 資格情報とアイデンティティ：gateway は OAuth に依存する。プロバイダーの構成方法や、アイデンティティソースの事前接続が必須かは証拠で説明がなく、未確認だ。
  • クライアントとプラットフォームの関係：公式の方針は、ユーザー、agent、クライアントを 1 つの URL に向けて残りをプラットフォームに任せるもの。各クライアントに必要なバージョンやプラグインは証拠にない。
  • バージョンの境界：公式の見解では、本番デプロイは正確なバージョンタグを固定すべきとされる。latest は通常 release candidate に当たるため、そのまま本番負荷を負わせないこと。
  • 手順の順序：ソケットマウントとバージョンの 2 点をまず受け入れ、それからコマンドを実行する。初回試行はローカルのループバック環境で完結させ、直接インターネットに公開しない。
  • 未確認の重要情報：リソース使用量、アップグレードとロールバックの手順、データのバックアップ方法、プラットフォーム内の各 MCP ツールの読み書き宣言、初期資格情報の方針は、いずれも証拠でカバーされていない。初回試行環境に本番データを入れないこと。説明が見つからないことはリスクがないことではなく、結論は公式ドキュメントに従う。