はじめに

MCPを導入するエンタープライズチームには、単なるゲートウェイ以上のものが必要です。彼らが求めているのは、運用モデル、セキュリティ要件、そしてAIインフラ戦略に適合するプラットフォームです。

IBM ContextForgeとTrueFoundryはどちらもMCPトラフィックの前面に配置され、エージェントが呼び出せるツールを一元管理できます。しかし、その先にあるターゲット層は異なります。ContextForgeは、自前で運用する無料のオープンソースプロキシ兼レジストリです。一方、TrueFoundryは、AIゲートウェイとMCPゲートウェイの機能を統合し、ガバナンス、可観測性、デプロイの柔軟性を備えたマネージド型のエンタープライズプラットフォームです。

本ガイドでは、IBM ContextForgeとTrueFoundryをアーキテクチャ、デプロイ、エンタープライズセキュリティ、価格、運用負荷の観点から比較し、どちらのプラットフォームが最適かを見極めるための判断材料を提供します。

IBM ContextForge：概要

ContextForge（mcp-context-forge GitHub）は、IBMが提供するオープンソースのAIゲートウェイ、レジストリ、プロキシであり、MCP、A2A、REST/gRPC APIを単一のエンドポイントの背後に統合します。管理UI、レート制限付きのOAuthスコープ認証、HTTP/WebSocket/SSE/stdioにわたるトランスポートサポート、OpenTelemetryトレーシング、40以上のプラグインエコシステムを備えています。RedisベースのフェデレーションによりKubernetes上でスケーリングが可能で、エアギャップ環境でのデプロイもサポートしています。

また、エンタープライズレベルのカスタマイズと統合も重視しています。JWTベアラートークン、Basic認証、カスタムヘッダー方式など複数の認証方法をサポートし、安全なツールアクセスのためにAES暗号化された資格情報を使用します。PostgreSQL、MySQL、SQLiteといった複数のデータベースとの互換性により、組織は既存のインフラを大幅に変更することなく導入できます。

重要な差別化要因は、複数のMCPサーバーをエージェントにとって単一の論理エンドポイントとして見せる「仮想サーバー構成」です。ただし、IBMはContextForgeを公式な商用サポートのないアルファ/ベータ段階のプロジェクトと明示しています。強力なツールではありますが、その運用上の複雑さとインフラ構築の負荷を考慮すると、シンプルで完全に管理されたMCPソリューションを求めるチームよりも、社内に強力なDevOpsの専門知識を持つ組織に適しています。

トレードオフは運用面にあります。Kubernetesクラスターのプロビジョニングと保守、ソフトウェアのパッチ適用、独自の可観測性バックエンド（Phoenix、Jaeger、Zipkinなど）の構築、そしてベンダーのSLAなしでのインシデント対応を自前で行う必要があります。ライセンス料はかかりませんが、LLMトラフィック用のAIゲートウェイはバンドルされていません。ContextForgeが管理するのはMCP/A2A/RESTであり、モデルのルーティングやLLMのコスト管理は対象外です。

TrueFoundry：概要

TrueFoundry は、 AIゲートウェイ と MCPゲートウェイ を単一のコントロールプレーンに統合しています。1,000以上のLLMを単一のOpenAI互換API経由で利用でき、ゲートウェイのレイテンシは約3〜4ミリ秒、単一のvCPUで毎秒350以上のリクエストを処理可能です。ContextForgeとは異なり、完全に管理されたSaaS製品として提供されるため、最初のMCPサーバーを登録する前にKubernetesクラスターをプロビジョニングする必要はありません。

MCPに関しては、 TrueFoundry は、登録されたMCPサーバーにRBAC（ロールベースのアクセス制御）を適用し、仮想MCPサーバーをサポートするほか、すべてのツール呼び出しを包括的なメトリクスとともにログに記録します。また、SOC 2、HIPAA、GDPRに準拠しており、データレジデンシー要件を持つチーム向けに、VPC、オンプレミス、または完全に隔離されたエアギャップ環境へのデプロイも可能です。

TrueFoundryのアプローチはシンプルです。組織がすでにLLM向けのAIインフラを管理している場合、MCPツールのためだけに別のシステムを導入して運用を断片化するメリットはほとんどありません。TrueFoundryは、LLMインフラとMCP管理を単一のコントロールプレーンに統合し、セキュリティ、可観測性、ガバナンス、パフォーマンスの各機能を共有します。この一元化されたアプローチにより、AI運用が簡素化されると同時に、エンジニアリングチームは監視、デプロイ、コスト管理のための統合プラットフォームを利用できるようになります。

LLMの呼び出しであれMCPツールの実行であれ、すべてのリクエストは同一の可観測性ビューに表示されます。トークン使用量、レイテンシのパーセンタイル、コストなどが、モデル、チーム、または付与したメタデータタグごとに分類されます。ContextForgeのOpenTelemetryトレースで同等のビューを得るには、セルフホスト型のPhoenixまたはJaegerインスタンスが必要です。

‍

TrueFoundryの主な機能

• 単一のコントロールプレーンによるLLMとMCPツールの統合インフラ
• インメモリ認証とレート制限による、負荷時でも3ms未満の低レイテンシ
• チームや環境間で論理的に分離できるMCPサーバーグループ
• 一元管理されたオーケストレーションによるコンテナ化されたMCPサーバーのデプロイ
• 認証とアクセス制御を備えた統合AIゲートウェイ
• カスタム設定、ガードレール、フォールバックメカニズム、負荷分散
• 組み込みのレート制限とクラウドベースのモデルデプロイサポート
• 本番環境対応のコード生成機能を備えた、多言語対応のインタラクティブなプレイグラウンド
• AIワークロードとMCPツール利用全体にわたる統合的な可観測性、監視、課金管理
• n8n、Slack、Claude Codeなどのプラットフォームとの統合

TrueFoundryが最適なケース

TrueFoundryは、すでに大規模なAIワークロードを運用しており、ツールを断片化するのではなく既存のインフラを拡張したいと考えている組織に最適です。その統合アーキテクチャは、単一ベンダーによるAIインフラの一元管理を好む企業にとって特に魅力的です。

また、デプロイ、監視、ファインチューニング、オーケストレーション機能が統合された、管理が容易で機能豊富なエンタープライズ向けソリューションを求めるエンジニアリングチームにも最適です。エージェント型ワークフローやMCPエコシステムを採用するチームは、その運用の簡便さ、幅広い統合機能、クラウドネイティブなデプロイの利点を活用できます。

フルマネージドSaaSとして利用可能なほか、Pro Plusプラン以上ではVPC、オンプレミス、エアギャップ環境でのセルフホストにも対応しており、SOC 2、HIPAA、GDPRへの準拠準備も整っています。料金体系は以下の通りです：Developerプラン（無料、月間5万リクエスト、MCPサーバー5台まで）、Proプラン（月額499ドル、月間100万リクエスト、MCPサーバー25台まで）、Pro Plusプラン（月額2,999ドル、MCPサーバー50台まで、VPC/オンプレミス対応）、およびエアギャップ環境や無制限のスケールに対応したカスタムEnterpriseプラン。

機能比較

IBM ContextForgeを選ぶべきケース

すでにKubernetesとRedisを大規模に運用しており、ライセンス費用を抑えたい場合、またパッチ適用、スケーリング、インシデント対応を自社で完結させる体制が整っているなら、ContextForgeが適しています。ソースコードレベルでの完全な制御を求め、このインフラ層においてベンダーとの関係を構築したくないプラットフォームチームにとって、堅実な選択肢となります。

TrueFoundryを選ぶべきケース

AIゲートウェイとMCPゲートウェイのガバナンスを単一のプラットフォームで統合したい場合、あるいは自前で構築することなくコンプライアンス認証やサポートSLAを確保したい場合、さらにはプロキシクラスターを運用・保守するためのDevOpsリソースが不足している場合は、TrueFoundryが適しています。ContextForgeではカバーできないLLMのルーティングやコスト管理もMCPトラフィックと併せて行いたい場合、TrueFoundryの方がより良い選択肢となります。

セルフホストのContextForgeからTrueFoundryへ移行する理由

移行の最も一般的な理由は、ContextForgeの機能に対する不満ではありません。MCPのガバナンスだけでは課題の半分しか解決できないという点にあります。チームは、どのLLMを呼び出し、どのようなコストとガードレールを適用するかを管理する必要があり、結果としてそのために2つ目のゲートウェイを運用することになります。TrueFoundryはこれら両方を1つのコントロールプレーンに統合し、RBAC、予算管理、監査ログをLLMとMCPのトラフィック全体に一貫して適用します。これにより、2つのシステムと2セットのポリシーを維持する手間が省けます。

結論

IBM ContextForgeとTrueFoundryは、どちらもMCPベースのワークフローをサポートしていますが、解決する課題は異なります。

インフラを完全に制御できるオープンソースのMCPゲートウェイの運用を優先するのであれば、IBM ContextForgeは強力な選択肢です。デプロイ、アップグレード、監視、継続的な運用を管理するリソースがあるエンジニアリングチームにとって、独自のMCP環境を構築・カスタマイズする柔軟性を提供します。

しかし、本番環境向けのAIアプリケーションを構築する場合、MCPゲートウェイ以上の機能が必要になるでしょう。TrueFoundryは、AIゲートウェイとMCPゲートウェイの機能を単一のプラットフォームに統合し、エンタープライズ認証、可観測性、ポリシー適用、デプロイの柔軟性、商用サポートを標準で備えています。これにより、運用上の複雑さを軽減しつつ、LLMとMCPサーバーの両方に対して統一されたコントロールプレーンを提供します。

最終的に、どちらが適しているかはチームの優先事項によって決まります。Kubernetesの運用能力があり、無料で完全にセルフホスト可能なプロキシを求めるなら、ContextForgeは妥当な選択です。一方、AIゲートウェイとMCPゲートウェイのガバナンス、コンプライアンス対応、サポートを単一のマネージドプラットフォームで実現したい場合は、 デモを予約する か、 TrueFoundryのMCPゲートウェイの詳細を確認する ことで、現在計画中のセルフホスト環境と比較してみてください。

よくある質問

IBM ContextForgeとTrueFoundry、エンタープライズに適しているのはどちらですか？

‍TrueFoundryは、AIゲートウェイとMCPゲートウェイを統合した管理プラットフォームを必要とし、コンプライアンス認証やサポート体制を重視する企業に最適です。一方、ContextForgeは、無料のセルフホスト型プロキシを希望し、それを運用するためのインフラリソースを自社で確保できるチームに適しています。

IBM ContextForgeは無料ですか？

‍はい、ライセンス料不要のオープンソースです。ただし、Kubernetes、Redis、可観測性バックエンドの構築や、それらを維持管理するためのエンジニアリング工数など、セルフホストに伴うコストが発生します。

TrueFoundryを導入すれば、ContextForgeは不要になりますか？

‍MCPガバナンスとLLM/AIゲートウェイ管理を一元化したいチームにとっては、その通りです。TrueFoundryのMCPゲートウェイは、ContextForgeが提供するRBAC（ロールベースのアクセス制御）やツール呼び出しのガバナンス機能を網羅しており、セルフホスト型のKubernetesインフラを構築する必要もありません。

TrueFoundryは自社のVPCやオンプレミス環境にデプロイできますか？

‍はい、可能です。TrueFoundryは、VPC、オンプレミス、エアギャップ環境、ハイブリッド環境、マルチクラウド環境など、あらゆる環境で実行できます。データが外部に出ることは一切ないため、ContextForgeのセルフホストを選択する理由となる「デプロイの制御権」を維持できます。

TrueFoundryは何種類のLLMに対応していますか？

‍OpenAI互換の単一APIを通じて、1,000種類以上のLLMに対応しています。ContextForgeにはLLMルーティング機能は含まれておらず、MCP、A2A、REST/gRPCトラフィックの管理に特化しています。