メインコンテンツまでスキップ

❓ FAQ

🌐 Q: ローカルのOpenAPIツールサーバーがWebUIのインターフェースからアクセスできないのはなぜですか？​

A: ツールサーバーがローカルで稼働している場合（例: http://localhost:8000）、ブラウザベースのクライアントはCORS（Cross-Origin Resource Sharing）ポリシーによってアクセスが制限されることがあります。

OpenAPIサーバーで明示的にCORSヘッダーを有効にする必要があります。例えば、FastAPIを使用している場合、以下を追加できます:

from fastapi.middleware.cors import CORSMiddleware

app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],  # またはクライアントのオリジンを指定
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

また、Open WebUIがHTTPSで提供されている場合（例: https://yourdomain.com）、ローカルサーバーは以下の条件のいずれかを満たす必要があります:

  • 同じドメイン内でHTTPSを使用してアクセスする（例: http://localhost:8000）。
  • または、ローカルホスト（127.0.0.1）上で稼働し、ブラウザがローカル開発のためにセキュリティを緩和する。
  • それ以外の場合、ブラウザはHTTPSページからHTTP APIへの不安定なリクエストを混在コンテンツルールのためにブロックする可能性があります。

本番環境でHTTPSを使用して安全に運用するためには、OpenAPIサーバーもHTTPSで提供される必要があります。

🚀 Q: サーバー実装にFastAPIを使用する必要がありますか？​

A: いいえ！リファレンス実装はFastAPIを使用して明瞭性と使いやすさを提供していますが、有効なOpenAPI（Swagger）仕様を生成する任意のフレームワークや言語を使用できます。一般的な選択肢には以下があります:

  • FastAPI (Python)
  • Flask + Flask-RESTX (Python)
  • Express + Swagger UI (JavaScript/Node)
  • Spring Boot (Java)
  • Swag または Echo を使用した Go

重要なのは、サーバーが有効なOpenAPIスキーマを公開し、HTTP(S)を介して通信することです。 すべてのエンドポイントでカスタム操作IDを設定することが重要です。

🚀 Q: MCPではなくOpenAPIを選ぶ理由は何ですか？​

A: OpenAPIは、その簡便さ、ツールエコシステム、安定性、開発者フレンドリーであることから、ほとんどの現実世界のシナリオでMCPよりも優れています。以下が理由です:

  • ✅既存のコードを再利用: 以前にREST APIを構築した経験があれば、ほとんど完了しています—ロジックを再構築する必要はありません。有効なOpenAPI仕様を定義し、現在のコードをツールサーバーとして公開するだけです。

    MCPでは、ツールロジックをカスタムプロトコル層内で再実装する必要があり、作業を重複させ、維持する面積を増やしていました。

  • 💼保守・デバッグが簡単: OpenAPIは現代の開発ワークフローに自然に適合します。Postmanを使用してエンドポイントをテストしたり、組み込みのAPIでログを確認したり、成熟したエコシステムツールで簡単にトラブルシューティングができます—通常、コアアプリを変更する必要はありません。

    MCPは、新しいトランスポート層、スキーマ解析、実行時の癖などを導入し、それらすべてを手動でデバッグする必要がありました。

  • 🌍標準に基づく: OpenAPIは技術業界で広く採用されています。その明確に定義された構造により、ツール、エージェント、サーバーは特別なブリッジや翻訳なしで即座に相互運用できます。

  • 🧰優れたツール: OpenAPIをサポートするツールの世界があり—クライアント/サーバーの自動生成、ドキュメント化、検証、モック、テスト、さらにはセキュリティ監査ツールまでがあります。

  • 🔐セキュリティの第一級サポート: OpenAPIはOAuth2、JWT、APIキー、HTTPSなどをネイティブでサポートし、一般的なライブラリや標準を利用して安全なエンドポイントを構築することが容易になります。

  • 🧠既に多くの開発者が知っている: OpenAPIを使用することで、バックエンドチーム、フロントエンド開発者、DevOps、プロダクトエンジニアに既に馴染みのある言語を話すことになります。学習曲線や高コストなオンボーディングは必要ありません。

  • 🔄将来性と拡張性: OpenAPIはAPIの標準とともに進化し、前方互換性を維持します。一方、MCPはカスタムで実験的であり、周囲のエコシステムの変化に伴って頻繁に変更を必要としました。

🧵 結論: OpenAPIはより少ない労力、コードの重複を避け、予期しない事態を減らしながら、より多くのことを実現します。プロダクション準備が整った開発者フレンドリーな方法で、すべてを一から再構築することなくLLMツールを強化します。

🔐 Q: OpenAPIツールサーバーをどのように保護すればよいですか？​

A: OpenAPIは以下のような業界標準のセキュリティメカニズムをサポートします:

  • OAuth 2.0
  • APIキーのヘッダー
  • JWT（JSON Web Token）
  • Basic認証

本番環境ではHTTPSを使用して転送中のデータを暗号化し、適切な認証／認可方法でエンドポイントを制限してください。これらはOpenAPIスキーマ内のsecuritySchemesフィールドを使用して直接組み込むことができます。

❓ Q: OpenAPIツールサーバーを使用してどのようなツールを構築できますか？​

A: REST API経由で公開できるものであれば構築できます。一般的なツールには以下が含まれます:

  • ファイルシステム操作（ファイルの読み書き、ディレクトリのリスト）
  • Gitおよびドキュメントリポジトリアクセス
  • データベースのクエリやスキーマ探索
  • ウェブスクレイパーや要約ツール
  • 外部SaaS統合（例: Salesforce、Jira、Slack）
  • LLMに接続されたメモリストア／RAGコンポーネント
  • エージェントに公開される内部マイクロサービスを保護する

🔌 質問: 複数のツールサーバーを同時に実行できますか？​

回答: もちろんです。各ツールサーバーは独立して動作し、自身のOpenAPIスキーマを公開します。エージェント構成は複数のツールサーバーを指すことができ、必要に応じて組み合わせが可能です。

制限はありませんが、各サーバーが独自のポートまたはアドレスで実行され、エージェントホストから到達可能なことを確認してください。

🧪 質問: ツールサーバーをLLMエージェントにリンクする前にテストするにはどうすればいいですか？​

回答: 次の方法でOpenAPIツールサーバーをテストできます：

  • Swagger UIまたはReDoc（FastAPIにデフォルトで組み込まれています）
  • PostmanまたはInsomnia
  • コマンドラインからのcurlまたはhttpie
  • Pythonのrequestsモジュール
  • OpenAPIバリデーターおよびモッカー

検証済みの後で、LLMエージェントまたはOpen WebUIを介してツールサーバーを登録できます。

🛠️ 質問: 参照サーバーを拡張またはカスタマイズできますか？​

回答: はい！servers/ディレクトリ内のすべてのサーバーはシンプルなテンプレートとして構築されています。以下を行うためにフォークして変更してください：

  • 新しいエンドポイントやビジネスロジックを追加する
  • 認証を統合する
  • レスポンス形式を変更する
  • 新しいサービスや内部APIに接続する
  • Docker、Kubernetes、または任意のクラウドホストを使用してデプロイする

🌍 質問: OpenAPIツールサーバーをAWSやGCPのようなクラウドプラットフォームで実行できますか？​

回答: はい。これらのサーバーは通常のHTTPサービスです。次のようにデプロイできます：

  • API Gatewayを使用したAWS Lambda（サーバーレス）
  • EC2またはGCP Compute Engineインスタンス
  • GKE/EKS/AKSのKubernetesサービス
  • Cloud RunまたはApp Engine
  • Render、Railway、Herokuなど

エージェントやユーザーが必要とする場合は、安全に設定され、（必要であればVPN経由で）公開アクセスが可能であることを確認してください。

🧪 質問: 既存のMCPサーバーを持っている場合はどうすればいいですか？​

回答: 素晴らしいニュースです！私たちのMCP-to-OpenAPI Bridge、mcpoを使用すると、既存のMCPベースのツールを簡単にOpenAPI互換のAPIとして公開できます。コードを書き直す必要もなく、手間もなく、ただ接続するだけで完了です！🚀

MCPプロトコルを使用して既に作成されたツールがある場合、mcpoを使用すると、それらを即座にOpen WebUIおよび任意のOpenAPIベースのエージェントと互換性のある状態にすることができます。これにより、あなたの努力は完全に活かされ、将来に備えた状態を保つことができます。

設定手順については、ドキュメントのオプションセクション「Bridge to MCP」をご覧ください。

クイックスタート:

uvx mcpo --port 8000 -- uvx mcp-server-time --local-timezone=America/New_York

✨ これでMCPサーバーがOpenAPI対応になりました！

🗂️ 質問: 1つのOpenAPIサーバーで複数のツールを実装できますか？​

回答: はい。単一のOpenAPIサーバーで、異なるエンドポイントに分類された複数の関連機能を提供できます。たとえば、ドキュメントサーバーは、検索、アップロード、OCR、要約を1つのスキーマ内で提供できます。

分離や柔軟性を優先する場合は、ツールごとにOpenAPIサーバーを作成して完全にモジュール化することもできます。

🙋 他に質問がありますか？GitHubのディスカッションを訪れて、コミュニティからヘルプやフィードバックを得てください：
👉 コミュニティディスカッション