STDIO設計欠陥とは、MCPの起動コマンドがそのまま実行される構造のことです。

事務所でAIエージェントを動かすとき、設定ファイルに書いた一行がそのままパソコン上で実行される。この構造が2026年4月に公表され、いまも設計としてそのまま残っています。本記事は、MCPのSTDIO接続に指摘された構造上の問題と、士業事務所が導入前に確認しておく7つの軸を扱います。士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、脆弱性の内容はCloud Security Allianceのリサーチノートと開示元の公表資料で確認しています。

2026年4月に公表された内容を先に押さえる

結論から書くと、指摘されたのは個別の実装バグではなく、MCPの公式SDKに共通する設計の話です。Cloud Security Allianceは2026年4月23日付のリサーチノートで、OX Securityが同年4月15日に開示した内容として、AnthropicのMCPのSTDIOトランスポート接続に、設定を操作できる攻撃者が任意のシェルコマンドを実行できる系統的な脆弱性があると整理しています（出典: CSAリサーチノート）。

MCPには二つの接続方式があります。ネットワーク越しにリモートのサーバーへつなぐHTTP+SSE方式と、ローカルでプロセスを起動して標準入出力でやり取りするSTDIO方式です。後者はホストと同じプロセス権限で動くため速くて単純ですが、実行権限が設定ファイル一つに集約される構造になります。CSAのリサーチノートは、公式SDKがこの起動コマンドを信頼境界として扱わず、設定から読んだコマンド文字列をサニタイズせずにシェルへ渡していると説明しています。

さらに厄介なのが、実行が無条件に起きる点です。指定されたサーバーのプログラムが存在せず起動に失敗した場合でも、シェルはコマンド文字列を実行する。つまり、設定ファイルに書き込める立場の相手は、AIモデルに何もさせなくてもホスト上でコードを動かせる、という整理になっています（出典は前掲のCSAリサーチノート）。プロンプトインジェクションのようにモデルの推論を突く攻撃ではなく、AIの安全機構より下の層で起きる話だという点が、この件の性質を決めています。

規模感も押さえておきます。CSAのリサーチノートは、パッケージのダウンロード数が1億5,000万件を超え、公開到達可能なサーバーが約7,000、脆弱な状態のデプロイが推定20万にのぼり、執筆時点で少なくとも14件のCVEが割り当てられたと記しています（出典: CSAリサーチノート）。開示当初に文書化されていたのは10件から11件で、そこから増えた形です。

そしてもうひとつ、事務所の判断に直結する事実があります。Anthropicはこの動作を想定された挙動だとして、プロトコル設計の変更に応じない立場を示し、入力のサニタイズはSDKを使う側の開発者の責任だとしているとCSAは記しています。設計側が直さない以上、CVEは下流のツール側に積み上がっていく構図です。CSAは、MCPを使うAIツールやエージェント基盤は、下流の依存関係がパッチ済みであることとSTDIO接続が固められていることを確認するまで、リモートコード実行の面として扱うべきだと推奨しています。

導入前に置く7つの確認軸

士業事務所がこの件で問われるのは、脆弱性を自力で直すことではありません。使うツールの選定と、事務所のパソコンでどこまで権限を渡すかの設計です。7つの軸に整理します。

第一の軸は、そもそもSTDIO接続を使っているかどうかの把握です。AIコーディング環境や一部のデスクトップアプリは、ローカルでMCPサーバーを起動する形が既定になっています。設定ファイルの中にコマンドを指定する項目があれば、それがSTDIO接続です。CSAは、この項目の値が既知の信頼できるプログラムのパスに固定されているかを確認するよう推奨しています。

第二の軸は、設定ファイルの出どころです。自分で書いたものか、配布されたテンプレートか、リポジトリを開いたときに一緒に入ってきたものか。CSAが挙げる攻撃ファミリーのひとつは、開発環境で悪意ある設定を含むプロジェクトを開くだけでコードが動く形でした。事務所の実務でいえば、外部から受け取ったフォルダを丸ごとAIツールで開く運用に、この論点が乗ってきます。

第三の軸は、パッチ状況の確認です。CSAのリサーチノートでは、LiteLLMとBishengには修正が出ており、Windsurf、Cursor、DocsGPT、GPT Researcher、Agent Zero、LangChain-Chatchatなどは対応状況がまちまちだと整理されています。事務所で使っているツールが一覧に載っていなくても、MCPを使っていれば確認の対象になります。

第四の軸は、STDIO接続を切れるかどうかです。CSAは、要件をHTTP+SSE接続で満たせる組織はそちらへ移行することを推奨しています。無条件のシェル実行という同じ構造を持たないためです。事務所で使う機能によっては、ローカル起動を要さない場合もあります。

第五の軸は、動かす場所の切り分けです。CSAが挙げる短期的な緩和策の中心は、プロセス分離です。コンテナや仮想マシン、OSのサンドボックス機構の中で、その用途に要る最小の権限だけを与えて動かす。侵害されても、事務所の認証情報や顧問先ファイルへ手が届かない構造にしておく発想です。

第六の軸は、記録と監視です。設定ファイルを版管理し、書き込み権限を絞り、変更を追える状態にしておく。CSAは、MCP設定ファイルをアプリケーションの秘密情報と同じ厳格さで扱うよう推奨しています。事務所では、誰がどの設定を入れたかを残せるかが分かれ目になります。

第七の軸は、ツール説明の検証です。CSAは、STDIOの問題と同時に進行する論点としてツールポイズニングを挙げています。MCPのツール説明文はモデルには見えるが利用者には見えにくく、そこに隠した指示をモデルが読んで動いてしまう形の攻撃です。複数サーバーを同時につなぐ構成では、悪意あるサーバーが正規のサーバーの挙動を上書きする形も示されています。初期化時にツール説明文を既知の内容と突き合わせ、変化を検知する運用が緩和策として挙げられています。

確認軸を実際の設定ファイルに当てるときは、次のような形でAIに下読みさせると抜けが減ります。出力はそのまま信用せず、最終判断は事務所の責任者が行う前提で使います。

次のMCP設定ファイルの内容を読み、以下の観点で分類してください。
推測での補完は行わず、判断できない項目は「要確認」としてください。

1. transport の種類（stdio / http+sse / 判別不能）
2. command フィールドの値が固定のパス指定か、変数・外部入力を含むか
3. 起動されるプログラムの配布元（自作 / 公式 / 第三者 / 不明）
4. 環境変数で秘密情報を渡している箇所の有無
5. 同時に接続されるサーバーの数と、その組み合わせ

出力は項目ごとに「分類 / 該当箇所の引用 / 追加で確認したい点」の3行で。

導入可否を事務所として決めるときは、ツール単位で同じ質問を投げて記録を残す形が回ります。

あなたは事務所の情報管理を補助するアシスタントです。
次のツールについて、公開ドキュメントの記載だけを根拠に表を使わず箇条書きで
整理してください。記載が見つからない項目は「記載なし」としてください。

- MCPのSTDIO接続を使うか、無効化できるか
- 起動コマンドの設定をどこから読むか
- 入力データを学習に利用するかどうかの記載
- 脆弱性の開示窓口とパッチ提供の履歴
- 監査ログの取得可否

各項目の末尾に、根拠となる公開ドキュメントのURLを添えてください。
URLが確認できない項目は「出典なし」と明記してください。

外部のMCPサーバーそのものをどう審査するかは外部MCPサーバーの安全性をどう審査するか 士業事務所の導入基準7項目で別途整理しています。本記事はクライアント側の接続方式に絞りました。

顧問先データを扱う端末で何が問題になるのか

先に結論を書くと、この件で士業事務所が向き合うのは、生成AIの入力範囲の話ではなく、端末そのものの管理の話です。入力するデータを絞っていても、端末上でコードが動けば、そこに置いてあるファイルは読めてしまうためです。

守秘義務の根拠条文を確認しておきます。弁護士法第23条は、弁護士または弁護士であった者は、その職務上知り得た秘密を保持する権利を有し、義務を負うと定めています。税理士法第38条は、正当な理由がなくて税理士業務に関して知り得た秘密を他に洩らし、または窃用してはならないと定めています。いずれも秘密の保持を求める条文で、端末の管理不備によって外部に流出した場合にどう評価されるかは、事案ごとに検討される論点です。

実務としては、三つの層で考えると整理しやすくなります。第一層は、MCPを使うAIツールを入れる端末を決めることです。顧問先の実データが入っている端末と、AIツールで検証をする端末を分ける構成を採る事務所があります。第二層は、その端末から到達できる範囲を絞ることです。共有フォルダをすべてマウントした端末でAIエージェントを動かすと、侵害時の影響範囲がそのまま事務所全体になります。第三層は、記録です。誰がどのツールをいつ入れたかを残しておかないと、後から影響範囲の特定ができません。

権限の設計そのものは、有資格者と補助者で線を引く話ともつながります。士業事務所の生成AI権限設定 有資格者と補助者で分ける5階層のルールで整理した階層に、MCPを使えるかどうかの列を足しておくと、運用の判断が早くなります。

事務所規程に落とすなら、MCPサーバーの追加を承認事項にしている事務所があります。ツールの追加は個人の裁量で進みやすい領域ですが、設定ファイル一つが実行面になる構造を踏まえると、追加の記録を残す運用のほうが後から追える形になります。

事務所で起きやすい3つの失敗

ひとつめは、公式だから安全だと考えてしまう失敗です。今回指摘されているのは公式SDKの設計そのもので、配布元が公式かどうかとは別の軸の話になります。CSAのリサーチノートも、設計側が変更しない方針を示したことで、修正の負担が下流の各プロジェクトに分散したと整理しています。配布元の名前ではなく、接続方式と設定の中身で判断する視点が要ります。

ふたつめは、リポジトリやフォルダを無造作に開く失敗です。CSAが挙げる攻撃ファミリーには、AIコーディング環境でプロジェクトを開くだけで実行される形が含まれます。士業事務所では開発リポジトリを扱う場面は多くありませんが、外部から受け取った資料一式をフォルダごとAIツールに読ませる運用は珍しくありません。受け取ったフォルダに設定ファイルが紛れていないかを確認する工程が、地味ですが効きます。

みっつめは、モデル側の対策で足りると考えてしまう失敗です。プロンプトインジェクション対策はモデルの入出力に対する防御ですが、今回の構造はその手前で起きます。AIエージェントのプロンプトインジェクション対策 士業事務所の権限設計4ステップで扱った権限設計と、端末側の実行環境の分離は、別々に手当てする領域だと捉えておくと抜けが減ります。

確認と切り分けにかかる工数と担当

工数の山は、棚卸しと端末構成の見直しの二つです。棚卸しは、事務所で使っているAIツールを列挙し、それぞれがMCPを使うか、STDIO接続かを確かめる作業で、ツール数に比例します。端末構成の見直しは、分離の方針を決めるところに時間がかかり、実際の設定変更そのものは比較的短時間で終わります。

担当の置き方としては、ツールの棚卸しを事務所で一本化する形が扱いやすくなります。職員が個別にツールを入れている状態だと、棚卸しのたびに聞き取りから始めることになります。導入済みツールの台帳を持ち、追加のときだけ更新する運用にすれば、次回以降の確認は差分だけで済みます。

費用面では、新規の支出よりも既存環境の設定変更に時間が向かう構図です。分離用の端末や仮想環境を用意する場合は追加の費用が出ますが、顧問先データの置き場を整理する副次効果も見込めます。着手の順番は、顧問先の実データを扱う端末でAIエージェントを動かしている箇所を先に見る形が現実的です。

設計を直さないという判断が残すもの

この件で長く効いてくるのは、脆弱性そのものより、設計側が変更しないという判断の扱いです。CSAは、プロトコルの設計者が悪用可能な挙動を設計上の仕様だと位置づけると、CVEはプロトコルではなく下流のプロジェクトに積み上がり、開示と修正の双方が分散すると整理しています。利用する側から見れば、どこまで直ったかを確かめる相手が増え続ける構図です。

士業事務所にとっての含意は二つあります。ひとつは、ツール選定の質問項目に、設計上の既知の課題をどう扱っているかという軸を足す流れが出てきたことです。個別の脆弱性が直っているかだけでなく、直さない方針の部分があるかを聞く。もうひとつは、AIツールの導入判断を情報システムの判断として扱う必要が出てきたことです。生成AIの導入検討が入力データの線引きに寄りがちだった段階から、実行環境の設計を含む段階へ移ってきています。

CSAは、AI連携のプロトコルが企業規模で採用される速度に、セキュリティの検証が追いついていない可能性を指摘しています。事務所としては、新しい接続規格が出るたびに全部を追う必要はありませんが、顧問先の情報が乗る端末で何が動いているかは把握しておく構えが要ります。接続方式の選択肢は今後も増えるため、方式ごとに何が実行され得るかを一度整理しておけば、次の規格が出たときの判断が早くなります。

よくある質問

何が問題として指摘されたのですか

MCPのSTDIO接続で、設定に書かれた起動コマンドがサニタイズされずにシェルで実行される構造です。Cloud Security Allianceは、この挙動が公式SDKのPython、TypeScript、Java、Rustに共通すると整理しています（出典: CSAリサーチノート）。

AIモデルに変なことを入力しなければ大丈夫ですか

いいえ、モデルの入出力とは別の層の話です。CSAは、この脆弱性がAIの推論や安全機構より下のインフラ層に存在し、設定ファイルに影響を与えられれば足りると説明しています。モデル側の対策だけでは手当てできない領域です。

Anthropicは修正しないのですか

CSAのリサーチノートは、Anthropicがこの実行挙動を想定されたものと位置づけ、プロトコル設計の変更に応じない立場を示し、サニタイズはSDKを使う開発者の責任だとしていると記しています（出典は前掲のリサーチノート）。

事務所でMCPを使うのをやめるべきですか

やめるかどうかは、使っている機能と代替手段の有無で変わります。CSAは、要件を満たせる場合はHTTP+SSE接続への移行を、STDIO接続を残す場合はプロセス分離やネットワークの制限といった緩和策を推奨しています。事務所ごとの用途に応じて判断する領域です。

CVEはいくつ出ているのですか

CSAのリサーチノートは、執筆時点で少なくとも14件のCVEが個別のMCP依存プロジェクトに割り当てられたとしています。開示当初に文書化されていたのは10件から11件でした（出典: CSAリサーチノート）。

顧問先に説明する必要はありますか

事務所がどの端末でどのツールを使っているかは、顧問先との守秘の取り決めに関わる部分です。ツール利用の説明を契約時に行っている事務所では、その説明の範囲に接続方式や端末構成が含まれるかを見直す契機になります。個別の説明義務の有無は、契約内容を踏まえて有資格者が判断する領域です。

小規模事務所でもプロセス分離まで必要ですか

規模にかかわらず、顧問先の実データが乗る端末でエージェントを動かしているかどうかが分岐点になります。分離用の環境を用意せずとも、AIツールを入れる端末を限定し、その端末から到達できる共有フォルダを絞るだけでも影響範囲は変わります。できる範囲から段階的に手当てする事務所があります。

参考文献

• Cloud Security Alliance MCP STDIO Design Flaw Enables Systemic AI Supply Chain RCE
• OX Security The Mother of All AI Supply Chains
• Model Context Protocol 公式ドキュメント Transports
• e-Gov法令検索 弁護士法第23条（秘密保持の権利及び義務）
• e-Gov法令検索 税理士法第38条（秘密を守る義務）

※士業のチカラでは、生成AIの導入支援から運用最適化まで、貴事務所の業務に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://shigyonochikara.jp/contact/