ローカルプロセス・ネイティブアドオン・リモートゲートウェイ？

まず結論から

ローカル MCP プロセスは、統制された環境での 1 オペレーター向けです。Odoo アドオンは、ケイパビリティが Odoo デプロイとそのモジュールライフサイクルと共に存在するべき場合に使います。リモートゲートウェイは、複数の外部クライアントまたは Odoo インスタンスが、1 つの安定した失効可能な境界を必要とする場合に使います。いずれの場合も、接続された Odoo ユーザーの権限が常に正（オーソリティ）です。

アーキテクチャ図は簡単な部分です。有用な比較は、最初の成功した呼び出しの後も、クライアント認可、クレデンシャル保管、アップグレード、インスタンスルーティング、書き込みポリシー、監査、稼働率を誰が所有するかです。

環境

このアーキテクチャ分析は、オープンソースの odoo-mcp 系統のメンテナンス、Odoo 16–19 互換性を軸にした ERPipe のホステッド経路の構築、そして Odoo と MCP プラットフォームの境界のレビューに基づいています。対象のクライアントは MCP 対応のデスクトップまたはホステッドエージェントです。Odoo 側は、サポートされたリモート API 経路を通じて到達する、顧客管理の Community、Enterprise、または Odoo.sh インスタンスです。

応答時間のベンチマーク比較は行わず、すべてのサードパーティアドオンが同じ挙動を示すと主張するものでもなく、公開 HTTPS ゲートウェイをプライベート専用の Odoo ネットワークへの正解に仕立てるものでもありません。

方法

私たちは、ツールがレコードの一覧化と読み取りをできるようになった後も残る責務に照らして、3 つの配置を比較しました:

• 外部クライアントがどう認証するか、そしてアクセスをどう失効させるか。
• Odoo のクレデンシャルがどこに置かれるか。
• 複数のクライアントとデータベースが、1 つの明示的なルーティングモデルを共有するかどうか。
• どのチームがアップグレードと可用性を所有するか。
• Odoo が ACL とレコードルールを適用する前に、書き込みをどう狭めるか。
• 失敗または曖昧なツール呼び出しの後に、どんなエビデンスが残るか。

結果

リモートゲートウェイは Odoo のセキュリティを取り除いたのではなく、その手前に第 2 のコントロールプレーンを追加しました。この区別が重要です。レコードの読み書きを接続ユーザーに許すかどうかは Odoo が決めます。このクライアント、このツール、このフィールド、この提案されたミューテーションを Odoo に届かせるべきかどうかは、ゲートウェイが決められます。

繰り返し見つかった失敗モード

• ローカルプロセスが偶然共有インフラになる。 ノート PC の設定が数人にサービスを提供し始めるのに、稼働率、トークンローテーション、アップグレード経路の所有者がいない。
• アドオンが外部クライアントの認可として扱われる。 Odoo 内部でコードを実行しても、外部の AI クライアントすべてに対する安全な OAuth と失効モデルが自動的に得られるわけではない。
• ゲートウェイが選択中のデータベースを隠す。 明示的なインスタンスキーのないマルチインスタンスアクセスでは、もっともらしいエージェント呼び出しが誤った環境に着地する。
• 書き込みのタイムアウトが再試行になる。 呼び出し元は Odoo がコミットしたかどうかを知れないため、自動再生はビジネスアクションを複製しかねない。
• ACL の成功がビジネス意図と取り違えられる。 サービスユーザーが取引先の更新を許可されていても、エージェントがこの特定の変更を今行うべきことの証明にはならない。

実用的なデフォルト

ツール契約を学んでいる間はローカルで始めてください。ケイパビリティが本当に Odoo デプロイに属するときだけ、アドオンへ移します。複数のクライアント、複数のインスタンス、または中央集権的な失効が、追加のサービスを運用する価値を生むとき、リモートゲートウェイを追加してください。

本番経路では、最小権限の専用 Odoo ユーザーを使い、読み取り専用から始め、インスタンスを明示し、アクセスの一時停止や失効の方法を実証してください。書き込みを有効にする場合は、正確なターゲットとペイロードをプレビューし、結果が unknown のとき何が起きるかを定義してください。

限界

これは実装のフィールドノートであり、独立したパフォーマンスまたはセキュリティ認証ではありません。ネットワークトポロジー、データレジデンシーの要件、Odoo カスタマイズ、クライアントサポート、チームの運用能力によっては、この推奨が逆転します。ERPipe の現在のホステッドベータでは、リモートゲートウェイに公開到達可能性が必要です。プライベート専用のインスタンスは、別のデプロイ判断を必要とします。

ソースと検証可能なエビデンス

• MCP アーキテクチャとローカル/リモートトランスポートモデル: https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture
• MCP 認可の境界: https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
• Odoo のアクセス権、レコードルール、セキュリティの落とし穴: https://www.odoo.com/documentation/19.0/developer/reference/backend/security.html
• ERPipe オープンソースの系統: https://github.com/erpipe-org/mcp-odoo と https://github.com/erpipe-org/erpipe
• 日付付きホステッドツールカタログ と 互換性マトリクス

関連

• Odoo MCP サーバーとは何か？
• Odoo 19 の AI エージェント vs 外部ゲートウェイ
• Odoo MCP ゲートウェイを自作するか購入するか
• セキュリティ境界