「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- AIモデルと外部システムのやりとりを標準化するオープンプロトコル
- MCP が注目される理由は
- 入り口に過ぎない「単純なローカルツール統合以上」の将来性を期待されている。
- 将来 SaaS クライアントが MCP サーバーとして公式対応する世界を見据えている。
- 関心の本丸はSaaS「法人向けの重量級機能」の利用「統一的なアクセスポイント化」にある。
詳細 †
仕組み †
ホスト / クライアント / サーバー †
ホストがクライアントとサーバーを使用して機能を実装する
- ホスト：アプリケーション、クライアントを通じて外部データやツールにアクセス。
- クライアント：サーバとの接続を確立し、リソース、ツール、プロンプトなどの機能を利用するためのリクエストを送信
- サーバー：クライアントからのリクエストを処理し、必要なデータ（データソース）や機能（ツール）を提供へのアクセスを提供
通信方式（STDIO と SSE） †
MCP サーバーとやり取りする場合に使われる通信方式
- STDIO (Standard Input/Output)
- ローカルの MCP サーバーで使われる。
- 標準入出力を使った安全・シンプルな通信方式。
- 技術的には JSON-RPC over stdio
- 標準入力に JSON を書き込み、標準出力から JSON を受け取る。
- SSE (Server-Sent Events)
- クラウドや SaaS で動く MCP サーバーで使われる。
- リモート環境に適したHTTPの一方向ストリーミング を使った通信方式。
- サーバーがクライアントに対して「イベント」をプッシュできる。
MCPでなければ実現しづらいこと †
- シンプルさ、低レイテンシ、依存最小を優先する小規模・短期の用途なら、requests を直接ツール化する方法が手軽。
- セキュリティ分離、標準化、運用・監査・ガバナンス、再利用性を重視するなら MCP 経由の fetch が適している。
プロセス分離 †
- 最小権限・責務分離、ポリシー一元適用がし易い。
- シークレットをMCP 側に閉じ込めることでLLMからの漏洩を防止できる。
標準化・相互運用性 †
- ツールの発見、スキーマ、エラー、リソース等のやり取りがプロトコルで標準化されている。
- モデルやランタイムが変わっても同じ MCP ツールを再利用し易い（多言語・多環境での再利用）。
運用・ガバナンス †
- ツールは独立したサーバとしてデプロイ・バージョン管理でき、
- ローテーションやロールバック、レート制限、監査ログの集約が容易。
- 組織のネットワーク制御や DLP と統合しやすい（同様にサーバ側で統制）。
可観測性・監査 †
- ツール呼び出しのログやメトリクスが明確な境界で記録・計測される。
- 拡張性・機能発見 ツールが自己記述的に機能や引数スキーマを公開するため、エージェントが動的に能力を発見し易い。
MCPをサポートするプロダクト †
エージェント・フレームワーク †
ローコード †
その他 †
参考 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
