Archestraとは｜MCPゲートウェイ内蔵のOSS企業AI基盤を実測、無料で使える境界線はどこまでか

Archestra（archestra-ai/archestra）は、MCPゲートウェイ・LLMゲートウェイ・エージェント実行基盤・ガードレールを1本のURLの背後に束ねる、OSSの企業向けAI基盤です。GitHubスター4,143、TypeScript製。「社内のAI利用を1か所に集約して、認証もコストも監査も効かせたい」という要求に、単機能ツールの寄せ集めではなく1つのプラットフォームで答えようとしています。

MCPそのものの前提を先に押さえたい方は MCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアル を参照してください。本記事はその先にある「複数のMCPサーバーとLLMを、組織としてどう統制するか」の層を扱います。

ただしArchestraはOpen Coreです。READMEと公式ドキュメントは「AGPLベース＋一部Enterprise」「30人未満は無料」と書きますが、この一文だけでは導入判断に必要な粒度に届きません。そこで本記事は、リポジトリを実際にクローンしてライセンスの線を数え、実行時のゲートをソースで追いました。結論を先に言うと、境界線は2本あって、しかも一致しません。

Archestraとは——13の機能を1つのURLの背後に束ねる

ArchestraのREADMEは自らを「all-in-one open-source enterprise AI platform」と称します。実際に何が入っているかを、公式ドキュメントとソースツリーの対応で並べると次のようになります。

・チャット（非エンジニア向け）：社内AIアシスタント。Slack・MS Teams・メールをフロントエンドにできる
・開発者向けLLM／MCPポータル：Claude Code・Codex・Cursorを1つのトークンで通す
・LLMゲートウェイ：Anthropic・OpenAI・Azure・Bedrock・DeepSeekなどをコスト上限・仮想APIキー・動的モデルルーティング付きで束ねる
・MCPゲートウェイ：OAuthとOn-Behalf-Of（OBO）に対応し、ツールが共有サービスアカウントではなく利用者本人として実行される
・A2Aゲートウェイ：エージェント間トリガー
・プライベートMCPレジストリ：自社製ツールを社内配布する
・MCPオーケストレータ：Kubernetes Operatorでサーバー群を管理し、環境間のセルフサービス昇格を行う
・エージェント実行基盤：スケジュール／メール／Webhookトリガー、サブエージェント委譲、再利用可能スキル、サンドボックス化されたコード実行
・RAGナレッジベース、ミニアプリビルダー、決定論的ガードレール、SSO・RBAC・シークレット管理、環境別のegressポリシーとコスト上限、OpenTelemetry／Prometheusによる可観測性

管理画面を見ると、この構成がそのままナビゲーションになっているのが分かります。次は公式デモから切り出した実際の管理画面です。

注目すべきは右のテーブルです。gemini-2.5-flash と claude-opus-4-8 が混在し、リクエストごとに $0.005350 $0.1447 といった単価がセッション単位で記録されています。「誰がどのモデルにいくら使ったか」を後から追える——これがゲートウェイを1本に束ねる実利です。

Archestraが解決しようとしているのは、AIツールの分散が生む統制の空白です。開発者はClaude Codeを使い、営業はチャットUIを欲しがり、それぞれが別々にAPIキーを持ち、MCPサーバーは各自の端末で野良運用される。この状態ではコストも権限も監査もかかりません。エンタープライズAI基盤としてのArchestraは全部を1つのURLの背後に置き、そこで認証・ポリシー・記録を効かせます。

MCPゲートウェイの肝は「誰として実行されるか」

数ある機能の中で、MCPゲートウェイの設計思想がもっとも明快に出ているのがOn-Behalf-Of（OBO）への対応です。公式ドキュメントの表現を借りれば、ツールは「共有サービスアカウントではなく、利用者本人として」実行されます。

これは監査の前提を変えます。共有アカウント方式では、GitHubやJiraのログに残るのは「Archestraというbot」であり、実際に誰の指示だったかはゲートウェイ側のログと突き合わせないと分かりません。OBOならば上流システム側のログにも本人が残り、かつその人が本来持っていない権限をエージェント経由で行使することもできません。

ただしここは線の引き方に注意が要ります。OktaとEntraに対するトークン交換（RFC 8693）を実装する services/identity-providers/enterprise-managed/ の14ファイルは、AGPLではなくEnterprise側です。MCPゲートウェイ本体（archestra-mcp-server）はAGPLですが、企業IdPと連携する最深部だけがEnterprise扱いになっている——これが実際の線です。ただし後述するとおりこの領域はユーザー数で自動的に開くゲートの側にあり、30人未満なら環境変数なしで利用できます。「Enterpriseライセンスのコード」と「有効化に手続きが要る機能」は一致しません。

付属する2つの資産——MCPカタログと移行キット

リポジトリにはプラットフォーム本体以外に、単体でも参照価値のある資産が2つ含まれています。

・MCPカタログ（mcp-catalog/）：data/mcp-servers.json に889件のMCPサーバー定義、data/mcp-evaluations/ に903件の個別評価JSONが入っています。各評価は tools prompts user_config category などを持ち、どのサーバーがどんなツールを公開するかを機械可読な形で持っています
・移行キット（migration-kit/）：Claude Code・OpenClaw・HermesのPoC構成をArchestraへ移すためのSkill（migrate-to-archestra）です。プロジェクト指示ファイル・MCP設定・フック・ローカルスクリプトを読み取り、Archestraのエージェントとスキルへ対応付けます。README曰く「バイト単位の移植ではなく、重要な挙動差を適用前に表面化させること」が目的で、探索・秘密情報の伏字化・APIペイロード検証といった決定論的な処理は依存ゼロのPythonヘルパーが担い、対応付けの判断はモデルに任せる構成です

Claude Codeで組んだ検証環境を持っている読者にとって、後者は実質的な入口になります。

Archestraのライセンスを実測する——境界は「ファイル単位」ではなく「行単位」

GitHub APIが返すライセンス表記は NOASSERTION です。これは「判定不能」であって「不明瞭」という意味ではありません。実体は LICENSE.md に書かれたLicense Router（ライセンス・ルーター）で、次の4規則を先にマッチしたものが勝つ方式で適用します。

1. ファイル冒頭のSPDXヘッダが最優先（// SPDX-License-Identifier: LicenseRef-Archestra-Enterprise）
2. ファイル内の SPDX-SnippetBegin 〜 SPDX-SnippetEnd で囲まれた区画だけがEnterprise。同じファイルの残りはAGPLのまま
3. 命名規約——*.ee.{ts,tsx,js,jsx,py,rs,sql,json,yaml,yml,md} または ee/ ディレクトリ配下
4. 既定：AGPL-3.0-only

規則2が示すとおり、この設計では1つのファイルの中に2つのライセンスが同居します。「このディレクトリは有償」といった粗い線ではありません。

そこで、検証時点の main をクローンして実際に数えました。

git clone --depth 1 https://github.com/archestra-ai/archestra.git
cd archestra

# 規則1: ファイル全体がEnterprise（冒頭のSPDXヘッダ）
grep -rl "SPDX-License-Identifier: LicenseRef-Archestra-Enterprise" --exclude-dir=.git .

# 規則2: ファイル内のEnterprise区画の数
grep -r "SPDX-SnippetBegin" --exclude-dir=.git . | wc -l

# 規則3: 命名規約によるEnterprise
find . -path ./.git -prune -o -type f -name "*.ee.*" -print | wc -l

結果は次のとおりです。

重要なのはどこに173ファイルが集中しているかです。サブシステム別に数えると、Enterprise側は次の領域に固まっていました。

つまりArchestraが引いた線は、「企業IDとの深い連携」「ナレッジベースの権限同期」「保存時暗号化」「Vault」「ホワイトラベル」に集中しています。逆に言えば、MCPゲートウェイ・エージェント実行基盤・ガードレール・K8sオーケストレータ・可観測性という「プラットフォームの中核」は全てAGPL側にあります。Open Coreというと中核が有償になりがちですが、この製品はそうなっていません。

「30人未満は無料」の境界線——7機能中3つは環境変数を立てないと動かない

公式のPricing Modelは、小規模チーム条項をこう定めています。

全社のArchestra.AIユーザー総数が30人未満なら、下記のEnterprise機能を有料サブスクリプションやEnterpriseライセンスなしに本番利用してよい。

そして「下記」として7機能を挙げます——RBAC／SSO & OIDC／ナレッジベースとRAGのアクセス制御／データ保持ウィンドウ／Real User Monitoring／保存時コンテンツ暗号化／二要素認証。ドキュメント上、この7つはすべて小規模チーム条項の対象です。

ところが実行時のゲートは1種類ではありません。ソースを追うと、2つの異なる判定が使い分けられています。

ゲートA：ユーザー数で自動的に開く

platform/backend/src/enterprise-tier.ts が、DBのユーザー数を60秒ごとに数えて判定します。

・しきい値は SMALL_TEAM_THRESHOLD = 30 のハードコード
・判定は userCount < 30 の厳密な小なり（ちょうど30人は小規模チームに該当しない）
・有効判定は isCoreActive() = 環境変数 || 小規模チーム——つまり環境変数がなくても30人未満なら有効
・DB接続前の初回だけ userCount = 0 にフォールバックするfail-open。コード内のコメントは「新規デプロイが機能を失わないように」と理由を明示している

このゲートAを使っているのは、SSO／IdP連携、チームとRBAC、組織設定、ナレッジベースのアクセス制御、そして二要素認証です。二要素認証には気の利いた配慮があり、登録（enrollment）だけを塞ぎ、検証と解除は開いたままにしています。ライセンスが切れても既に登録済みの利用者が締め出されないための設計です。

ゲートB：環境変数だけを見る（ユーザー数は無関係）

一方、次の機能群は enterpriseTier.isCoreActive() を使いません。config.enterpriseFeatures.core——すなわち環境変数 ARCHESTRA_ENTERPRISE_LICENSE_ACTIVATED の値だけを直接見ます。

・データ保持ウィンドウ（data-retention/license-gate.ee.ts）
・保存時コンテンツ暗号化（content-encryption/guard.ee.ts）
・Real User Monitoring（observability/rum/exporter.ee.ts）
・監査ログ、HashiCorp Vault連携（公式の7機能リストには未掲載）

この差は実害を伴います。前2者は設定だけして環境変数を立てないと、起動時に例外を投げてプロセスが停止します。黙って無効化されるより安全側の設計で、コード内のコメントもその理由を述べています。

「configured but not running」は大きな声で失敗しなければならない——保持期間を設定した運用者はコンプライアンス要件のためにそれを頼りにしている可能性があるため、削除を黙ってスキップするのではなく起動を失敗させる。（license-gate.ee.ts のコメントより要約）

保存時暗号化はさらに厳格で、「秘密情報は入れ直せるがチャット履歴と対話ログは戻らない」という理由から、鍵の受け入れ回避口を意図的に用意していません（fail-closed）。

この差をどう解釈すべきか

ここは正確に切り分けが必要です。ライセンス上の許諾と実行時のスイッチは別物です。

小規模チーム条項は「30人未満なら使ってよい」という許諾であり、7機能すべてに及びます。一方 ARCHESTRA_ENTERPRISE_LICENSE_ACTIVATED は単なる機能スイッチです。したがって30人未満のチームがデータ保持や保存時暗号化を使いたい場合、ライセンス上は許されているのに、自分で環境変数を立てる必要がある——これが実装から読み取れる帰結です。

なお公式Pricingドキュメントの lastUpdated は2026-06-23で、コードは日次で動いています。この差はドキュメントの追随遅れである可能性が高く、意図的な制限と決めつけるべきではありません。ただし導入検証では「ドキュメントに書いてあるから無料で有効になるはず」と仮定せず、実際に起動して確認する必要があります。

そしてもう一点。検証時点のリポジトリを検索した限り、ライセンスキー・署名・有効期限を検証するコードは存在しません。

# ライセンス検証らしきコードを探す（結果は0件）
grep -rniE "license.?(key|token|jwt|signature|verify|validate)" \
  platform/backend/src --include="*.ts" | grep -vi test | wc -l

jose（JWTライブラリ）は使われていますが、用途はOIDC/JWKS検証、GitHub Appの認証、Okta／EntraのOBOトークン交換で、ライセンス検証ではありません。つまりEnterpriseの有効化は環境変数の文字列比較のみで決まり、小規模チーム条項の遵守は利用者の自己申告に委ねられています。OSSのOpen Coreでは珍しくない運用ですが、「技術的に縛られていない」ことは把握しておくべきです。

ガードレールの中身——Lethal Trifectaを決定論的に断つ

Archestraが前面に押し出すのがガードレールです。ここは全9ファイルがAGPL、つまり無償で使える中核機能にあたります。

対象は「Lethal Trifecta」——セキュリティ研究者Simon Willison氏が名付けた、次の3つが同時に揃うと成立するプロンプトインジェクションのリスクパターンです。

・プライベートデータへのアクセス（DB・ファイル・社内文書・認証情報）
・信頼できないコンテンツへの曝露（Webページ・メール・アップロード・サードパーティAPIの応答）
・外部への送信能力（メール送信・HTTPリクエスト・他システムへの投稿）

攻撃者は信頼できないコンテンツに命令を埋め込みます。モデルは入力を1つのトークン列として処理するため、埋め込まれた命令と本来のタスクを確実には区別できません。プロンプト工学だけでは原理的に解けないというのが公式ドキュメントの立場で、だからこそポリシーを決定論的に適用します。

ツール結果に対しては4つのアクションが定義されています。

加えてツール呼び出し側にも block_when_context_is_sensitive（文脈が機微になったら呼ばせない）などのポリシーがあります。公式の組み込み設定では、Web検索やブラウザ操作のように外部の生コンテンツを返すツールに対し、呼び出し側を block_when_context_is_sensitive、結果側を sanitize_with_dual_llm と二重に指定する方針が示されています。

実装で注目したのは guardrails/trusted-data.ts（737行）の失敗時の扱いです。Dual LLMによる要約自体が失敗したとき、生の結果で代替したり「信頼できない」と印を付けて続行したりはせず、リクエスト全体をfail-closedで失敗させます。コード内のコメントは理由をこう述べています——そうしないと、ポリシーが隔離しようとしていたまさにその内容をモデルに渡すことになる、と。

この判断は地味ですが本質的です。ガードレールは「失敗したときにどちらへ倒れるか」で価値が決まります。なお同ディレクトリのテストは trusted-data.test.ts だけで1,720行あり、実装737行に対して2.3倍です。テスト量が品質を保証するわけではありませんが、この部分に開発リソースが割かれていることは読み取れます。

インストールと、自分の環境で境界線を確かめる手順

起動はDocker 1コマンドです。PostgreSQLは同梱され、/var/run/docker.sock をマウントするのはMCPサーバーをコンテナとして起動するためです。

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 \
  -e ARCHESTRA_BETA=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

起動後は http://localhost:3000 が管理画面、9000 がゲートウェイのポートです。本番向けにはHelmチャートとTerraform providerが公式に用意されています。

導入検討時に自分で確かめるべきは、前述の「2本の境界線」がその環境でどう出るかです。次の3点は起動後すぐ確認できます。

・ユーザー数によるゲートA：組織のユーザーを30人以上にしたとき、SSO・RBAC・2FA登録・ナレッジベースのアクセス制御が閉じるか。バックエンドは routes/config.ts で enterpriseCoreActive を返しており、フロントエンドはこの値で表示を切り替える
・環境変数によるゲートB：ARCHESTRA_LLM_LOGS_RETENTION_DAYS などの保持期間を設定し、ARCHESTRA_ENTERPRISE_LICENSE_ACTIVATED を立てずに起動する。設計どおりならエラーメッセージを出して停止する
・しきい値の境界：ユーザー数ちょうど30人は小規模チーム条項の対象外（userCount < 30 の厳密比較）

他のMCPゲートウェイと比べてどう選ぶか

「MCPゲートウェイ」という語は、いま射程の異なる製品を同じ名前で呼んでいます。Archestraを検討するなら、まずどの層が欲しいのかを切り分けるのが早道です。

判断の目安は次のとおりです。

・個人・小規模で、MCPサーバーの設定重複を解消したいだけなら、Archestraは重すぎます。単一バイナリで完結するMCPJungleの方が適切です
・全社導入で、誰がどのモデルにいくら使ったかを追い、SSOと権限を効かせたいなら、Archestraの射程に入ります。ここはMCPゲートウェイ単体では埋まりません
・プロンプトインジェクション対策を仕組みとして持ちたい場合、決定論的ガードレールがAGPL側にあることは実利です

導入判断——強みと、正直な留保

強みは3つあります。第一に、中核が本当にAGPLであること。MCPゲートウェイ・エージェント基盤・ガードレール・K8sオーケストレータ・可観測性が無償側にあり、Open Coreにありがちな「試せるが実用にならない無償版」ではありません。第二に、失敗時の倒れ方が設計されていること。保存時暗号化とデータ保持は起動を止め、Dual LLMの失敗はリクエストを止めます。第三に、ライセンスの線が機械可読であること。SPDXで表現されているため、本記事のように誰でも数えられます。

留保も正直に挙げます。

・ドキュメントと実装のずれ：前述のとおり、小規模チーム条項の適用範囲がPricingページの記述と実行時の挙動で一致しません。導入前に自分の構成で確認が要ります
・運用の重さ：Docker＋PostgreSQL＋（本番なら）Kubernetesが前提です。単機能のゲートウェイとは要求水準が違います
・AGPLの含意：既定がAGPL-3.0-onlyです。改変してネットワーク越しにサービス提供する場合の開示義務が自社方針と両立するか、法務確認が必要です
・検証していない公称値：READMEは「累計資金調達1,350万ドル」「Fortune 50企業3社での導入」「p95で31ミリ秒」を挙げますが、いずれも同社の主張であり本記事では独立検証していません。性能値は構成依存でもあるため、自社環境での実測を推奨します
・新しさ：リポジトリ作成は2025-07-15で、まだ1年余りです。一方でリリースは活発で、検証時点の最新は platform-v1.3.30（2026-08-09）でした

なお同プロジェクトは Linux Foundation / CNCF への参加を公表しています。ガバナンス面の材料として、単独ベンダー製OSSよりは判断しやすい状況です。

Archestraは「MCPゲートウェイが欲しい人」の道具ではなく、「社内のAI利用そのものを1か所で統制したい組織」の基盤です。射程を取り違えなければ、無償で使える範囲は想像より広い——それが実測から得られた結論です。

参照ソース

・archestra-ai/archestra — GitHubリポジトリ（README・LICENSE.md・platform/backend/src 以下のソース。検証時点のスター4,143、最新リリース platform-v1.3.30）
・Pricing Model — Archestra公式ドキュメント（小規模チーム条項とEnterprise機能7項目。lastUpdated: 2026-06-23）
・Tool Guardrails — Archestra公式ドキュメント（Lethal Trifectaの定義とツール結果ポリシー）
・The lethal trifecta for AI agents — Simon Willison（用語の初出）