業務システムにLLM（大規模言語モデル）連携機能を組み込む際、社内ツールをどう「エージェントから呼び出せる形」にするかで迷う場面が増えています。MCP（Model Context Protocol、LLMとツール・データソースをつなぐための共通プロトコル）はその選択肢の1つです。本記事はMCPサーバーとクライアントを実際に構築するチームに向けて、トランスポート方式（通信の仕組み）の選び方を整理します。
MCPを使うと、LLM側は「どんなツールが使えるか」「どんなリソースが読めるか」を事前に問い合わせ、必要なものだけを呼び出せます。Pythonのmcpパッケージやコミュニティ版のfastmcpを使えば、関数に@mcp.tool()のようなデコレータを付けるだけでツール登録が完了します。ここで重要なのは、サーバーとクライアントの通信方式にstdio（標準入出力を使ったプロセス間通信）とstreamable-http（HTTP経由のストリーミング通信）という2種類があり、業務要件によって適不適が分かれる点です。
どんな場面でこの判断が必要になるか
社内バッチ処理やCLIツールをLLMエージェントから呼び出したい、あるいは複数チームがそれぞれ管理するAPIをまとめてエージェントに公開したい、という場面で最初に決めるのがトランスポート方式です。
ローカル開発中に動いていたstdio方式の構成を、そのまま本番のマイクロサービス環境に持っていこうとして詰まるケースもあります。実行環境がプロセス起動を前提にしているか、ネットワーク越しの呼び出しを前提にしているかで、選ぶべき方式が変わります。
判断軸
実行環境の分離度が1つ目の軸です。stdioはクライアントがサーバーをサブプロセスとして起動する方式です。StdioServerParametersにPythonインタプリタの絶対パスとスクリプトパスを渡し、stdio_clientで子プロセスを立ち上げます。同一ホスト上でクライアントとサーバーが常に一緒に動く前提なら扱いやすい一方、サーバーだけを別のコンテナやサーバーにスケールさせたい場合には向きません。
複数クライアントからの同時接続が2つ目の軸です。streamable-httpはサーバー側でhostとportを指定し、通常のWebサーバーのようにHTTP経由でリクエストを受け付けます。社内の複数のエージェントやバックエンドサービスが同じMCPサーバーを共有したい場合、この方式でないと現実的に運用できません。
既存インフラとの親和性が3つ目の軸です。すでにKubernetesやDockerでマイクロサービスを運用している組織であれば、streamable-httpはロードバランサーやヘルスチェック、既存の認証基盤（APIゲートウェイなど）と組み合わせやすい構成です。一方、社内の開発端末や単一のバッチサーバーでツールを動かすだけなら、stdioのほうが余計なインフラを増やさずに済みます。
起動時の障害切り分けのしやすさも見落とせない軸です。stdio方式はクライアントがサーバーのスクリプトをそのまま子プロセスとして起動するため、サーバー側でimportエラーが起きるとクライアントの起動処理自体が原因不明のまま失敗します。運用前に必ずサーバースクリプト単体を起動して、正常に立ち上がることを確認しておく必要があります。
選択肢の比較
| 観点 | stdio | streamable-http |
|---|---|---|
| 起動方式 | クライアントが子プロセスとして起動 | 独立したHTTPサーバーとして常駐 |
| 同時接続 | 基本は1対1 | 複数クライアントから同時接続可能 |
| デバッグのしやすさ | プロセス起動失敗の切り分けがやや難しい | 通常のHTTPログ・監視ツールが使える |
| 既存基盤との統合 | ローカル完結・追加インフラ不要 | ロードバランサーや認証基盤と統合しやすい |
ケース別の推奨
社内の1人の開発者がCLIから対話的にツールを試したり、CI環境でスクリプトとして1回だけツールを呼び出したりする用途ならstdioを選ぶのが妥当です。追加のネットワーク設定やポート管理が不要で、コードもシンプルに保てます。
複数の業務システムやチームが同じツール群（社内API・DB参照ツールなど）を共有し、将来的にエージェント経由のリクエストが増える見込みがあるならstreamable-httpを選ぶべきです。既存のマイクロサービス構成にMCPサーバーを1つのサービスとして組み込み、通常のHTTPサービスと同様に監視・スケーリングできます。
既存コードベースにMCPを段階的に導入したい場合は、まずstdioでツールの入出力仕様（型ヒント・docstring）を固め、モデルに渡る説明文の品質を検証してからstreamable-httpに切り替える進め方も現実的です。ツール定義の関数シグネチャや docstring はそのままモデルへの説明文になるため、方式を変える前に固めておくと手戻りが減ります。
あえて見送るべき条件
リモートホストへの任意コマンド実行を許可するようなツール（SSH経由でシェルを叩く、といった構成）は、どちらの方式であっても慎重になるべきです。許可リストや認証、人間による確認ステップを挟まない「なんでも実行できるツール」をエージェントに公開するのは、業務システムの運用リスクとして避けたほうが安全です。
また、社内に既にgRPCやREST APIとして安定運用されている業務ロジックがある場合、それをすべてMCPツールとして作り直す必要はありません。既存APIの薄いラッパーとしてMCPツールを用意し、ビジネスロジック自体は既存のサービス層に残す構成のほうが保守性は高くなります。
導入前に確認すること
まずはuv add mcp fastmcpまたはpip install mcp fastmcpでローカルに環境を作り、stdio方式でサーバー単体が起動するか確認するところから始めるのが安全です。
そのうえで、複数クライアントからの同時利用が必要かどうか、既存のコンテナ基盤に載せる予定があるかどうかを整理し、streamable-httpへの移行が必要かを判断してください。
ツールとして公開する関数の型ヒントとdocstringは、モデルに渡る説明そのものになります。方式選定と同じくらい、この記述の丁寧さが実運用での呼び出し精度に影響する点も意識しておく価値があります。