2026年8月1日土曜日

MCP変更

 C#用のSDKが整備されたようなので、MCPの開発をPythonから、C#に変更することにしました。


結論から言うと、「C# GUIのMCPサーバー」を作る目的によって、Pythonを使うのが正解（メリットあり）か、それともC#で統一すべき（不正解に近い）かが明確に分かれます。

MCP（Model Context Protocol）は言語を問わない標準プロトコル（主に標準入出力 stdio や EventSource を使用）であるため、PythonでMCPサーバーを作ること自体は技術的に全く問題ありません。しかし、「C#で構築された既存のGUIアプリ」とどう連携させるかによって、最適な開発言語が変わります。 [1, 2]
状況に合わせた判断基準を以下の通り整理しました。

1. Pythonを使うのが「正解」なパターン

  • すでにPythonで動く便利なAI/データ分析スクリプトやツールがある
    • 既存のPython資産をそのままMCPサーバー化し、C# GUIアプリ（MCPクライアント）からプロセス起動して呼び出す場合、Pythonを使うのが最も効率的です。
  • 強力なPython用MCP SDKを活用したい
    • Anthropicが公式に提供している Python用MCP SDK は機能が豊富で情報も多く、サーバーを素早く立ち上げるのに向いています。 [2]

2. C#に統一すべき（Pythonだと不正解・遠回りになる）パターン

  • 「C# GUIアプリ自体」の内部データやコントロールをAIに操作させたい
    • 例えば、C#のWPFやWinFormsで作った画面のボタンをAIに押させたり、アプリ内のメモリデータを直接読み取らせたりしたい場合です。
    • この場合、PythonでMCPサーバーを作ると、C#（GUI） ⇄ Python（MCP鯖） ⇄ AIクライアント という複雑なプロセス間通信（IPC）が余計に発生し、開発効率もパフォーマンスも悪化します。
    • 現在はC#用MCP SDK（modelcontextprotocol/csharp-sdk）も公式に提供されているため、C# GUIアプリ自体にMCPサーバー機能を組み込んで（インプロセスで）動かす方が遥かにスマートです。 [2]

最適な構成パターンの比較

あなたの実現したいシステム構成が以下のどちらに該当するかで判断してください。
パターンシステムの構成の流れ評価とアドバイス
パターンA
(C#が主役)		AIアプリ（Cursor等） ⇄ (MCP) ⇄ C# GUIアプリ（内部にMCPサーバーを内蔵）C#で統一するのが正解です。GUIアプリの内部状態をAIに直接見せたり操作させたりできます。Pythonを挟む必要はありません。
パターンB
(Pythonが主役)		C# GUIアプリ（MCPクライアント） ⇄ (MCP) ⇄ Python（MCPサーバー）Pythonを使うのが正解です。C#で作った独自のAIツールから、背後にあるPythonの高度なAI/データ処理ロジックを呼び出す形になります。
現在開発中のシステムは、上記の「パターンA」と「パターンB」のどちらの構成を目指していますか？
また、「C# GUIアプリ」と「Python MCPサーバー」の間でどのようなデータや操作のやり取りを想定しているか教えていただければ、より具体的な実装方針（C#への切り替え提案、またはプロセス間通信の設計など）をご案内できます。



ローカルPC内におけるAIアプリ（ClineやCursorなど）と、C#で作成したMCPサーバー（GUIアプリ内蔵）との通信は、主に標準入出力（stdio）を介したプロセス間通信、またはローカルHTTPサーバー（SSE）を介して行われます。
現在主流のAIアプリ（MCPクライアント）の多くは、標準入出力（stdio）での接続を基本としています。それぞれの通信メカニズムの詳細は以下の通りです。

1. 標準入出力（stdio）による通信

AIアプリ（親プロセス）が、C# GUIアプリの「エグゼクティブファイル（.exe）」をバックグラウンドで起動し、パイプライン（標準入力と標準出力）を繋いで通信する方式です。
[ AIアプリ (Client) ]
       │  (1) .exe を起動（プロセス生成）
       ▼
┌──────────────────────────────────────┐
│ [ C# GUIアプリ (Server) ]           │
│                                      │
│  AIアプリの標準出力 ──> 独自の標準入力   │ ※ JSON-RPC 2.0
│  AIアプリの標準入力 <── 独自の標準出力   │   フォーマットのデータ
└──────────────────────────────────────┘
  • 仕組み:
    • AIアプリは設定ファイル（mcpConfig.json など）に従い、C#アプリの .exe パスを指定して起動します。
    • AIアプリが「コマンド」を文字列（JSON-RPC 2.0形式）としてC#アプリの Console.In（標準入力）へ流し込みます。
    • C#アプリはそれを検知して処理し、結果を Console.Out（標準出力）へ書き戻します。
  • 特徴:
    • ポートの競合やファイアウォールのブロックを気にする必要がありません。
    • 最もシンプルかつセキュアで、現在のMCPの標準的な接続方法です。

2. Server-Sent Events（SSE）による通信

C# GUIアプリの内部でローカルHTTPサーバー（localhost）を立ち上げ、Web技術をベースに双方向のやり取りを行う方式です。
[ AIアプリ (Client) ] ──(HTTP Post / Request)──> [ C# GUIアプリ (Server) ]
[ AIアプリ (Client) ] <───(SSE / Stream)─────── [ 内部でWebサーバーが起動 ]
  • 仕組み:
    • C#アプリ起動時、内部で localhost:5000 などの一時的なローカルWebサーバーを起動します。
    • AIアプリはそこへHTTP接続を確立し、サーバー側からクライアントへの通知（イベント配信）には SSE (Server-Sent Events) という技術を使ってデータを流し続けます。
  • 特徴:
    • AIアプリ側が「すでに起動しているC#アプリ」に対して後から自由に接続・切断できます。
    • C#アプリをAIアプリのバックグラウンドプロセスとしてではなく、ユーザーが通常通りダブルクリックして起動した状態のまま連携させたい場合に最適です。

C#（パターンA）で実装する際の注意点

もし標準入出力（stdio）方式を採用する場合、C#のGUIアプリ（WPFやWinForms）で1点だけ注意が必要です。
通常、GUIアプリとしてプロジェクトを作成すると「コンソール（黒い画面）」が非表示になり、Console.WriteLine などの標準入出力が正常に機能しない、あるいはAIアプリ側と正しくパイプが繋がらない原因になります。
これを解決するために、公式の modelcontextprotocol/csharp-sdk を利用して、プロジェクト設定（.csproj）を一時的にコンソールアプリケーション（<OutputType>Exe</OutputType>）として作成し、コード側でGUI（Applicationクラスなど）をスレッド起動する構成にするのが一般的です。
C#アプリの通信方式として、どちらの運用イメージが近いですか？
  • AIアプリを開いたときに、裏で自動的にC# GUIアプリが起動してほしい（stdio方式）
  • 自分で先にC# GUIアプリを起動しておき、そこにAIアプリを接続させたい（SSE方式）
イメージに合わせたC#側の実装コードの骨組みや、設定ファイルの書き方をご案内できます。
結論からお伝えすると、圧倒的に「パターンA（C#にMCPサーバーを内蔵する）」の方が楽です。
一見、C#のMicrosoft Storeアプリの制限を回避するパターンAは難しそうに見えますが、パターンB（PythonでMCPサーバーを作り、C#と通信させる）を選んでしまうと、さらにその「何倍も面倒な地獄」が待っています。
それぞれの理由をシンプルに解説します。

パターンA（C#に内蔵）が楽な理由

C#用の公式SDK（modelcontextprotocol/csharp-sdk）をNuGetで導入するだけで、AIアプリとC#アプリが1対1で直接おしゃべりできるようになります。
  • 実装がシンプル: AIから命令が届いたら、C#のコード（メソッド）がそのまま実行されるため、GUIのボタンを押したり画面のデータを書き換えたりする処理がダイレクトに書けます。
  • 面倒なのは「最後だけ」: 開発中は通常のC#アプリ（Win32）として作れば制限を気にする必要がありません。Microsoft Store向けに公開する「最後のパッケージ化」のときだけ、設定ファイルを少し書き換えるだけで済みます。

パターンB（Pythonを挟む）が「地獄」になる理由

「C# GUI」と「AIアプリ」の間に「Python MCPサーバー」を挟むと、登場人物が3人に増えるため、通信経路が2つに増えて破綻します。
[ AIアプリ ] ──(通信①)──> [ Python MCP ] ──(通信②: ここが地獄)──> [ C# Storeアプリ ]
  1. 謎の通信（通信②）を自作する羽目になる
    PythonからC# Storeアプリへデータを送るための、独自のプロセス間通信（gRPC、Websocket、共有メモリなど）をゼロから設計・実装しなければなりません。
  2. Storeアプリの制限はどのみち回避できない
    PythonとC#の間でローカル通信（通信②）を発生させるため、結局C# Storeアプリ側の「ループバック制限（他のアプリとの通信禁止）」に引っかかります。つまり、パターンAの苦労から逃げたのに、パターンBでも同じ苦労をすることになります。
  3. ユーザーへの配布が困難になる
    Microsoft Storeからアプリをダウンロードした一般ユーザーのPCに、「Pythonの実行環境」や「依存ライブラリ」をどうやって一緒にインストールさせるかという、配布の超難問にぶち当たります。

💡 結論として進むべき道

迷わずパターンA（C#で完結させる）で進めてください。
開発の手順としては、以下の流れが最もストレスフリーで簡単です。
  1. まずは普通のC#アプリとして作る
    WPF、WinUI 3、Windows Formsなど使い慣れたものでOKです。C#のMCP SDKを入れ、AIアプリと繋いでGUIが動く楽しさをまずは体験してください。
  2. アプリが完璧に完成してから「Storeアプリ化」する
    最後にMicrosoft Storeアプリの形式（MSIX）に変換し、先述した「ループバック制限解除」や「実行エイリアス」の設定を追加します。
まずはC#だけでMCPサーバーの骨組みを作ってみるのが一番の近道です。
投稿者 時刻:

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)