AGNTCon MCPCon Europe 2026：MCP展開

2026年9月17日から18日にかけて、AGNTCon + MCPCon Europe 2026はアムステルダムで開催されます。公式日程には、MCPの課題、ツールインターフェース、Agent基盤に関するセッションが掲載されています。(events.linuxfoundation.org)

症状： ローカルのMCP ServerをHTTPで公開しただけで、誰がどのツールを使えるのか、トークンがどこまで届くのか、失敗時に何が記録されるのかが決まっていない。
最短の解決策： 先に資源と信頼境界を定義し、その後に隔離環境、OAuth 2.1、HTTPS、資格情報分離、ログ脱落防止、接続試験の順で進めてください。

この手順を使うべき人

対象は、すでにローカルSTDIO型のMCP Serverを作り、チームや複数のAI Agentから共有したい開発者です。共通のツール入口を提供するプラットフォームエンジニアや、認可、監査、実行分離を担当するセキュリティ担当者にも適しています。

単に「接続できるサーバー」を作るのではなく、どの操作を誰に許可し、どの失敗を利用者へ見せ、どの情報を運用担当者だけに残すかを決めるための手順です。

まず公開範囲と信頼境界を固定する

ローカルMCP Serverをリモート化する最初の作業は、ポートを開けることではありません。公開するツール、参照するファイルやデータベース、外部APIへの書き込み、ユーザーの同意が必要な操作を一覧にします。

たとえば、読み取り専用の検索ツールと、チケットを作成するツールでは危険度が異なります。後者には利用者の明示的な同意、対象プロジェクトの限定、入力値の検証、監査記録が必要です。

この段階で「外部公開しないツール」と「リモート化してよいツール」を分けてください。秘密鍵、個人ファイル、社内ネットワークへの無制限アクセスを、便利だからという理由だけでツール化するのは避けるべきです。

初回デプロイは再構築できる隔離環境から始める

実行環境には、専用の非特権アカウントを使います。サービスが書き込めるディレクトリを限定し、ホームディレクトリ全体、SSH鍵、クラウド認証情報、環境変数の一括参照を許可しない構成にしてください。

ネットワークも同じです。受信ポートは必要な入口だけに絞り、下流APIやデータベースへの送信先を許可リストで管理します。管理用SSH、監視用エンドポイント、MCP接続用エンドポイントを同じ公開面に置かない方が、事故時の切り分けが容易です。

公式SDKには、Streamable HTTP、STDIO、認証ヘルパーを含む実装例があります。ただし、サンプルが動作することと、本番の権限分離が完了していることは別です。(github.com)

HTTP化したら認可とHTTPSを先に通す

リモートのMCP Serverでは、HTTPSを「あとでリバースプロキシに追加する項目」と考えないでください。認可サーバーのエンドポイントとリダイレクトURIはHTTPSで提供し、認可コードフローではPKCEを使います。公式仕様では、クライアントが認可要求とトークン要求の双方でresourceを指定し、MCP Server側が自分向けに発行されたトークンか検証することが求められています。(modelcontextprotocol.io)

MCP Serverが下流APIへ接続する場合、クライアントから受け取ったトークンをそのまま転送してはいけません。これはトークンパススルーと呼ばれる危険な構成で、対象サービスの検証や監査を迂回する混乱した代理人問題につながります。下流API向けには、MCP Server自身が別の資格情報または別のOAuthフローを使ってください。(modelcontextprotocol.io)

注意: Authorizationヘッダーをログに残したまま接続試験を行うと、認証が正しく動いていても秘密情報の保管に失敗します。HTTPステータス、エラー種別、相関IDは残し、トークン値、Cookie、認証コード、完全な入力本文は伏せてください。

資格情報とログを用途ごとに分ける

最低でも、次の3種類を別々に管理します。

• MCPクライアントが認可を受けるためのクライアント情報。
• MCP Serverが下流APIへ接続するためのサービス資格情報。
• 利用者の同意に基づくアクセストークンやリフレッシュトークン。

同じ環境変数ファイルにすべてを詰め込むと、バックアップ、障害調査、開発者への参照権限が広がります。秘密管理基盤を使う場合でも、アプリケーションの実行ユーザーが必要な秘密だけを読み取れるようにし、更新時は古い値を無期限に残さない設計にしてください。

ログには、相関ID、MCPのツール名、利用者またはクライアントの識別子、結果区分、処理時間、下流サービスの分類を記録します。一方で、Authorizationヘッダー、アクセストークン、APIキー、個人データを含む入力値は記録対象から外します。

クライアント接続と失敗処理を試験する

初回接続では、成功ケースだけを確認してはいけません。公式のTypeScript SDKでは、認証が必要な場合に未認証エラーを受け、認可フロー完了後に再接続する流れが示されています。実装するSDKの挙動に合わせ、401を受けたときに無限リトライしないことも確認してください。(github.com)

場面としては、社内のAI Agentが文書検索とチケット作成を同じMCP Serverから呼ぶケースを想定すると分かりやすいです。検索は読み取り専用スコープ、チケット作成は追加同意と限定されたプロジェクト権限を要求し、下流のチケットサービスにはMCP Server専用の資格情報で接続します。

上線前に5つの検査を完了する

本番相当の環境へ移す前に、次の順番で確認します。

1. 公開ツールを再確認する。 一覧にないツールが表示されないこと、不要な管理機能が無効であることを確認します。
2. 権限を最小化する。 実行ユーザー、ファイル、送信先、データ範囲、ツール単位のスコープを見直します。
3. 失効を試す。 アクセストークン、リフレッシュトークン、クライアント資格情報を失効させ、既存セッションがいつまで有効か測定します。
4. ログを監査する。 認証ヘッダーや秘密値が残っていないこと、相関IDから一連の操作を追跡できることを確認します。
5. 復旧を試す。 バックアップ、依存パッケージ更新、証明書更新、設定ロールバックを実際に実行します。

仕様やSDKが更新された場合は、以前のテストが通っていることを互換性の根拠にしないでください。現在の公式仕様と利用中SDKの対応表を確認し、認可、セッション、スコープ、資格情報分離に関する試験をやり直します。公式SDKの開発版では仕様世代に関する移行情報も公開されているため、固定バージョンのまま放置せず、更新前後の差分を記録してください。(github.com)

現在の環境とMacstripeの使い分け

自分のノートパソコンだけで検証を続ける方法は、初期費用を抑えやすい一方、常時稼働、電源やネットワークの安定性、チーム共有、環境の再現性に弱点があります。一般的なクラウド環境も柔軟ですが、権限設計、ネットワーク分離、秘密管理、不要な稼働時間の管理を自分で組み立てなければなりません。

短期間のMCP Server検証、複数クライアントの接続試験、隔離されたAI Agent開発環境が必要なら、Macstripeのレンタル環境を選択肢に入れる価値があります。長期にわたる高負荷運用、専用の物理インターフェース、厳格な社内ネットワーク接続が必要な場合は、自社管理のサーバーや専用基盤の方が適しています。

まずは注文前の構成設定ガイドで必要な実行環境を整理し、続いてヘルプセンターの案内を確認してください。既存MCP Serverの検査項目をすべて通過させてから、リモート環境への移行と運用分離を進めるのが安全です。

最終更新：2026年7月29日。開催日程は公式イベントページ、認可要件はMCP公式仕様と公式セキュリティ文書、SDK挙動は公式SDK資料を確認しています。

よくある質問

ローカルのMCP Serverをリモートサーバーへ移すとき、最初に何を確認すべきですか？

最初に確認するのは、起動方法ではなく公開するツール、読み取るデータ、書き込み操作、利用者の同意が必要な処理です。STDIOでは同一端末内の信頼を前提にしやすい一方、HTTPでは認証、認可、通信保護、監査を別途設計しなければなりません。機能一覧と禁止事項を先に固定してください。

リモートのMCP Serverでは必ずOAuth 2.1を使う必要がありますか？

すべての構成で同じOAuthフローが必要という意味ではありませんが、複数利用者、ユーザー同意、権限委任を扱うなら、公式仕様に沿ったOAuth 2.1ベースの認可を選ぶのが安全です。単一の内部サービスでも、トークンの対象確認、HTTPS、失効、監査を省略してよい理由にはなりません。

MCP ServerでAPIキーやユーザートークンの漏えいを防ぐにはどうしますか？

クライアント用資格情報、下流API用資格情報、ユーザーのアクセストークンを別々に保管し、ログには認証ヘッダー、Cookie、秘密値、完全なリクエスト本文を残しません。MCP Serverが受け取ったトークンを、そのまま下流サービスへ渡すトークンパススルーも避け、下流向けには別の認証処理を実装します。

MCPのSTDIOとHTTPでは、運用上どのような違いがありますか？

STDIOはクライアントがローカルプロセスを起動し、プロセス境界と端末の利用者権限に依存する構成です。HTTPはネットワーク上の複数クライアントを受け付けるため、TLS、認証、トークンの対象、レート制限、セッション、監査ログまで設計対象になります。接続できるだけでは本番運用の条件を満たしません。

関連記事

• リモートMacへのAI環境の展開方法を実装面から確認する
• ゲートウェイを常時稼働させるためのlaunchd設計と安定運用
• Kubernetesでの秘密情報管理と障害対応の実践