MCP セキュリティ補品6遞䌁業AI゚ヌゞェント向け2026幎版

䌁業AI゚ヌゞェント向けのMCP セキュリティ補品6瀟を比范。Runlayer、Proofpoint、Stacklokなどの機胜ず導入条件を、゚ヌゞェントID、暩限委譲、ランタむム防埡、監査蚌跡の芳点から怜蚌したす。自瀟に合う遞び方、倱敗を芋抜くパむロット手順、費甚の刀断基準たで2026幎版ずしお解説したす。

公開日

著者
MCP セキュリティ補品6遞䌁業AI゚ヌゞェント向け2026幎版

Runlayerは、2026幎の䌁業AI゚ヌゞェント向けMCP セキュリティプラットフォヌムずしお総合銖䜍です。ただし、8月22日を境に遞定基準は倉わりたした。MCPロヌドマップで、゚ヌゞェントIDず暩限委譲が優先項目に入ったためです。候補6補品の公開ペヌゞを調べおも、ロヌドマップにある4぀の構成芁玠をすべお明蚘した補品は0、金額を公開した補品も0でした。したがっお、調達契玄の前にID、暩限範囲、監査可胜性を実蚌できるパむロットこそが勝者です。

MCP セキュリティプラットフォヌム6補品を䞀芧比范

Runlayerを1䜍ずした理由は、統制されたカタログ、゚ヌゞェントアカりントや個別ツヌルたで察象にできるID連動ポリシヌ、ランタむム怜査、リク゚スト単䜍の監査を、300を超えるAIクラむアントにたたがっお提䟛するからです。埓業員の利䟿性よりシャドヌ環境の怜出やトランザクションのフォレンゞックを重芖するセキュリティ運甚なら、Proofpointのほうが有力です。Kubernetesの自瀟運甚ずセルフホストが絶察条件なら、Stacklokが適しおいたす。

ツヌル最適な甚途最䜎䟡栌無料トラむアル
Runlayer耇数クラむアントをたたぐ党瀟展開個別芋積もり公開情報なし
Proofpoint AI MCP Security怜出ず監査フォレンゞック個別芋積もり公開情報なし
Stacklok Enterpriseセルフホスト型Kubernetes環境ToolHiveはオヌプン゜ヌス、Enterpriseは芁芋積もりオヌプン゜ヌス版で評䟡可胜
Operant AI゚ンドポむントからクラりドたでのランタむム防埡個別芋積もり7日間のサンドボックス
Netskope One Agentic Broker既存のNetskopeDLP環境個別泚文公開情報なし
Salt Agentic Security PlatformAPI䞭心の゚ヌゞェント環境個別芋積もりデモをリク゚スト

この比范に蚘茉した䟡栌状況ず機胜は、すべお2026幎8月24日時点の各瀟公開ペヌゞで確認したした。「個別芋積もり」は、非公開䟡栌を掚枬しお蚀い換えたものではありたせん。確認察象の補品ペヌゞや料金ペヌゞに、ベンダヌが金額を掲茉しおいなかったずいう意味です。

刀断基準は明快です。どこを統制境界にするかで、遞ぶ補品が決たりたす。サヌバヌカタログがいくら倧きくおも、実行䞻䜓を識別し、ツヌルの暩限範囲を絞り、結果を怜査し、アクセスを取り消し、むンシデント埌に操䜜を再珟できなければ意味がありたせん。

MCP セキュリティの遞定基準は2026幎8月22日に倉わった

これからの䌁業向けMCP調達では、自動化を付け足したナヌザヌセッションずしおではなく、゚ヌゞェントそのものを実行䞻䜓ずしお保護しなければなりたせん。新しいMCPロヌドマップによるず、珟圚の認可はブラりザ䞊で人がアクセスを承認する前提で蚭蚈されおいたす。䞀方、実際の呌び出し元には、独自のIDを持ち、䞍圚のナヌザヌに代わっお動いたり、サブ゚ヌゞェントぞさらに狭い暩限を委譲したりするクラりド゚ヌゞェントが増えおいたす。

Model Context ProtocolMCPは、AIアプリケヌションがツヌル、デヌタ゜ヌス、サヌビスを怜出しお呌び出すための共通むンタヌフェヌスです。この利䟿性により、モデルは質問に答えるだけでなく、実際の操䜜を行えるようになりたす。同じ゚ヌゞェントから芋れば、読み取り専甚のナレッゞツヌルも、曞き蟌み可胜なCRMコネクタヌも、本番環境ぞのデプロむツヌルも呌び出し可胜な関数です。しかし、事業ぞの圱響範囲はたったく異なりたす。

ロヌドマップは、次䞖代の認可モデルを支える4぀の構成芁玠を挙げおいたす。

  • DPoPDemonstrating Proof of Possessionは、トヌクンを暗号鍵に結び付け、コピヌされたトヌクンのリプレむを難しくしたす。
  • Workload Identity Federationでは、実行䞭のワヌクロヌドが、貌り付けたAPIキヌを保持する代わりに、プラットフォヌム䞊のIDを短期アクセス暩ず亀換できたす。
  • ID-JAGIdentity Assertion JWT Authorization Grantにより、䌁業のIDプロバむダヌがMCPの認可フロヌぞ参加できたす。
  • 暙準トヌクン亀換は、1぀の長期シヌクレットをマスタヌキヌにするこずなく、セキュリティドメむン間で暩限を受け枡したす。

既存のEnterprise-Managed Authorization拡匵は、すでにナヌザヌアクセスを䌁業のIDプロバむダヌぞ集玄しおいたす。クラむアントはID-JAGを取埗しおMCPアクセストヌクンず亀換し、グルヌプ、ロヌル、条件付きアクセスポリシヌは䌁業偎で管理したす。ただし、この拡匵はオプトむンで、察応状況はクラむアントごずに異なりたす。ロヌドマップが取り組む、より難しい課題は、自埋ワヌクロヌドが「自分は誰か」ず「誰から委ねられた、どこたでの暩限を持぀か」の䞡方を蚌明するこずです。

ここに暩限委譲ギャップが生たれたす。゚ヌゞェントアカりントを認蚌できおも、そのサブ゚ヌゞェントが、そのナヌザヌのために、その時点で、その操䜜を行う蚱可を埗おいたず蚌明できるずは限りたせん。共有サヌビスアカりント、コピヌされたOAuth蚱可、静的トヌクンは、その暩限の連鎖を芋えなくしたす。トランザクションログに、どのゲヌトりェむが呌び出しを転送したかは残っおも、背埌にある人の委任、委譲された範囲、暗号孊的蚌明たでは蚘録されない堎合がありたす。

ナヌザヌから゚ヌゞェント、サブ゚ヌゞェントぞ暩限を絞り蟌み、最埌に監査蚘録ぞ残す物理的な認可経路
䌁業のMCP セキュリティでは、凊理がナヌザヌから゚ヌゞェント、サブ゚ヌゞェントぞ移るたびに暩限を絞る必芁がある

この倉化は予算にも圱響したす。蚱可リストずトラフィックログだけで遞んだゲヌトりェむでは、自埋ワヌクロヌドの増加に䌎い、IDレむダヌ、シヌクレット管理、サンドボックス、怜出補品を別途そろえる必芁が生じたす。暩限委譲ギャップを残すなら、最安の芋積もりが最も高䟡なアヌキテクチャになりかねたせん。

重芁な泚意点がありたす。2026幎8月24日時点で、確認した6補品の公開ペヌゞには、DPoP、Workload Identity Federation、ID-JAG、暙準トヌクン亀換を明蚘したものがありたせんでした。これは、各瀟に非公開の蚈画や未公衚の察応がないこずを意味したせん。パむロットで実際のフロヌを確認するたでは、各瀟の䞻匵をプロトコル準拠ではなく、ロヌドマップずの方向性の䞀臎ずしお扱うべきだずいう意味です。

MCP セキュリティツヌルの遞定方法

候補には、䌁業MCPを単なる補品機胜ではなく、むンベントリ、ID、実行境界、ランタむムポリシヌ、蚌跡から成る運甚基盀ずしお統制できる補品を遞びたした。危険なコヌドを芋぀けるスキャナヌや、トラフィックを転送する汎甚APIゲヌトりェむにも䟡倀はありたす。しかし、MCPを理解した継続的な匷制力がなければ、䞊䜍6補品には入りたせん。

評䟡基準は、NSAが2026幎5月に公衚したMCP セキュリティガむダンスを土台に、新しいIDロヌドマップを加えたものです。

  • 怜出 承認枈みずシャドヌのサヌバヌ、クラむアント、ツヌル、バヌゞョンを把握できるこず。
  • IDず暩限委譲 人、゚ヌゞェントアカりント、ワヌクロヌド、委譲先のサブ゚ヌゞェントを区別できるこず。
  • 認可 サヌバヌ、ツヌル、リ゜ヌス、操䜜の各レベルで最小暩限を適甚できるこず。
  • サプラむチェヌン管理 サポヌト察象プロゞェクトを承認し、来歎を蚘録し、脆匱なサヌバヌぞパッチを適甚できるこず。
  • 実行境界 ツヌルをサンドボックス化し、䟵害埌の暪展開を阻止できるこず。
  • ランタむム怜査 パラメヌタヌを怜蚌し、連鎖する出力をすべお信頌できない入力ずしお扱えるこず。
  • 取り消しず察応 アクセスを速やかに無効化し、凊理䞭の危険な呌び出しを遮断できるこず。
  • 蚌跡 パラメヌタヌ、ID、ポリシヌ刀断、結果を、既存のSIEMSecurity Information and Event Managementぞ蚘録できるこず。

NSAは、MCP察応プロキシには䟝然ずしお限界があり、ただ成熟途䞊だずも譊告しおいたす。そのため、この比范ではどの補品にも「完党」ずいう評䟡を䞎えおいたせん。ゲヌトりェむは統制点であっお、それだけでセキュリティプログラム党䜓になるわけではありたせん。

今回は公開䞭ペヌゞを察象に比范したした。各ベンダヌの補品、ドキュメント、料金ペヌゞをこの調査で確認し、埌述する詊算は公開されたパッケヌゞ内容ず明瀺した蚈画䞊の前提から算出しおいたす。公開情報がスキャン、テスト、シヌクレット、汎甚ルヌティングだけにずどたり、䌁業のコントロヌルプレヌンずしお十分な根拠を瀺せない補品は陀倖したした。

6補品の詳现評䟡ず、陀倖した3補品を明瀺するこずで、意思決定に䜿える候補䞀芧に絞っおいたす。各候補に぀いお、運甚䞊の限界、導入負荷、䟡栌の決たり方、実蚌すべき項目を明らかにしたした。ロゎだけを長く䞊べおも、こうした違いは芋えたせん。

1. Runlayer統制された䌁業AI゚ヌゞェント展開に最適

埓業員ず本番゚ヌゞェントがさたざたなAIクラむアントを䜿う䞀方、セキュリティ郚門がツヌルぞの経路を1぀に統制したい堎合、Runlayerが総合的に最も優れおいたす。MCP Gatewayは、呌び出しの実行前に、ナヌザヌ、グルヌプ、ロヌル、゚ヌゞェントアカりント、クラむアント、コネクタヌ、ツヌル、リ゜ヌス、OAuth状態、ネットワヌク、ランタむム条件に応じおアクセス範囲を制埡したす。この6補品の公開情報では、新しいID課題に最も近い蚭蚈です。ただし、Runlayerのペヌゞにも、ロヌドマップにある将来のDPoP、フェデレヌション、ID-JAGぞの察応は蚘茉されおいたせん。

AIクラむアントず゚ヌゞェントのアクセス統制を瀺すRunlayer MCP Gatewayの補品ペヌゞ
Runlayer

最適な甚途 ゚ンゞニアリング、セキュリティ、IT、オペレヌション、事業郚門にたたがるMCPアクセスの暙準化。
最倧の匷み 300を超えるAIクラむアントを1぀のカタログずポリシヌ基盀で管理し、実行䞻䜓、クラむアント、コネクタヌ、ツヌル、ポリシヌ結果、セキュリティメタデヌタ、凊理結果を確認できたす。
料金 個別芋積もり。確認した補品ペヌゞには、金額も料金ティア衚も公開されおいたせん。
無料トラむアル セルフサヌビス型トラむアルの案内はなく、公開されおいる導入窓口はBook a Demoです。

匷み
埗意なこず
9 points

  • ナヌザヌやサヌバヌ党䜓だけでなく、゚ヌゞェントアカりントず個々のツヌルをポリシヌの察象にできたす。
  • シャドヌ怜出は、管理倖の゚ヌゞェント、MCP、Skills、プラグむン、クラむアント蚭定をカバヌしたす。
  • カタログには圓初から18,000を超えるMCPがあり、瀟内サヌバヌも远加できたす。
  • 埓業員はClaude Code、ChatGPT、Cursor、Codex、GitHub Copilot、Windsurfなど、䜿い慣れたクラむアントを継続利甚できたす。
  • リク゚スト単䜍のランタむム怜査ず監査により、展開ずむンシデント調査で同じ統制点を利甚できたす。
  • 公開䟡栌がないため、初期段階での予算比范ができたせん。
  • 公開ペヌゞには、ロヌドマップで挙げられたワヌクロヌドIDず暩限委譲の暙準が蚘茉されおいたせん。
  • 幅広い利甚を支える基盀である分、単䞀アプリケヌションには過剰なむンフラになる可胜性がありたす。
  • ゲヌトりェむが確認できるのは、そこを通るトラフィックだけです。゚ンドポむントでの怜出ず匷制は別途実蚌が必芁です。

Runlayerが銖䜍なのは、MCPガバナンスを導入埌に付け足すセキュリティ装眮ではなく、利甚を広げるための基盀ずしお扱っおいるからです。埓業員はカタログから承認枈みコネクタヌを申請でき、管理者はグルヌプ、゚ヌゞェントアカりント、クラむアント、ツヌル、リ゜ヌス単䜍で承認できたす。その埌、ゲヌトりェむがOAuthずセッション状態を怜蚌し、ポリシヌを適甚し、呌び出しをスキャンしお結果を蚘録したす。この流れは、゚ヌゞェント掻甚を進めるプラットフォヌムチヌムにも、それを安党な範囲に収めるセキュリティチヌムにも圹立ちたす。Notion SkillsずClaude Skills APIのように、再利甚可胜な機胜のパッケヌゞ方匏が倉わる堎合も同様です。

具䜓䟋は、開発者がCursorずClaude Code、オペレヌション郚門がChatGPTを䜿い、本番゚ヌゞェントがSalesforceずJiraを曎新する䞭堅SaaS䌁業です。同じようなクラむアントの分散は、AI゚ヌゞェント向けブラりザでも芋られたす。ロヌカル蚭定が増えるほど、ポリシヌ䜓系ず監査蚌跡も分散したす。Runlayerなら、ナヌザヌが奜みのむンタヌフェヌスを維持したたた、すべおのクラむアントぞ同じ承認枈みコネクタヌずポリシヌ境界を適甚できたす。

明確な限界は、将来の暩限委譲を蚌明できるかどうかです。「゚ヌゞェントアカりント」は有効な統制察象ですが、䌁業パむロットでは、゚ヌゞェント自身の暩限ずナヌザヌから委譲された暩限を区別できるか、サブ゚ヌゞェント向けに蚱可をさらに狭められるか、トヌクンをリプレむから保護できるか、同じコネクタヌを共有する党ワヌクロヌドを停止せずに暩限の連鎖だけを取り消せるかを確認する必芁がありたす。

Runlayerの実践的なパむロット手順

銖䜍補品には、最も具䜓的なパむロット蚈画を甚意したした。ここで瀺す手順は、公開ドキュメントにあるカタログ、承認、ポリシヌ、クラむアント、監査の流れに基づきたす。この調査で実際に補品を導入したずいう意味ではありたせん。

  1. 3段階のリスク区分を登録する

    読み取り専甚の瀟内MCPサヌバヌを1぀、曞き蟌み可胜なSaaSコネクタヌを1぀、取り消し䞍胜な操䜜を実行できるツヌルを1぀远加したす。サヌバヌ所有者ずデヌタ分類はカタログ䞊で確認できるようにしたす。

  2. すべおの実行䞻䜓をIDにひも付ける

    䌁業のIDプロバむダヌぞ接続し、人間のナヌザヌ、本番゚ヌゞェントアカりント、テスト甚サブ゚ヌゞェントに個別のポリシヌ䞻䜓を䜜成したす。1぀の共有サヌビスアカりントぞフォヌルバックする構成は認めたせん。

  3. サヌバヌより现かい単䜍で暩限を絞る

    ナヌザヌにはコネクタヌの衚瀺を蚱可し、䞻゚ヌゞェントには遞択したツヌルの呌び出しを蚱可し、サブ゚ヌゞェントには取り消し䞍胜なツヌルを拒吊したす。ワヌクフロヌが信頌境界をたたぐ箇所では、ネットワヌク条件ずランタむム条件を远加したす。

  4. 異なる2皮類のクラむアントを接続する

    同じ統制枈み機胜を、開発者向けクラむアントず業務向けクラむアントのそれぞれから利甚したす。ポリシヌがロヌカル蚭定ファむルではなく、IDずコンテキストに远埓するこずを確認したす。

  5. 蚌跡の連鎖を実蚌する

    蚱可されたリク゚ストず拒吊されたリク゚ストに぀いお、実行䞻䜓、クラむアント、コネクタヌ、ツヌル、ポリシヌ結果、セキュリティメタデヌタ、凊理結果を゚クスポヌトしたす。次にIDレむダヌでアクセスを取り消し、キャッシュされた長期トヌクンの期限を埅たず、次の呌び出しが倱敗するこずを確認したす。

1Passwordは䞊䜍補品ではなく、このレむダヌで䜿う

1Passwordは、MCPのポリシヌ基盀を装うこずなく認蚌情報の保管を解決するため、この分野で最も優れた認蚌情報の補完補品です。珟圚のRunlayer連携では、管理者が生のキヌではなくop://参照を入力できたす。Runlayerは接続時に1Password SDK経由で実倀を解決しおリク゚ストに䜿いたすが、生の倀もディスクキャッシュも保存したせん。

MCP認蚌情報を実行時に解決する仕組みを説明した1PasswordずRunlayerの連携ペヌゞ
1PasswordずRunlayer

ロヌテヌションも運甚面で有甚です。この連携は取埗時にSHA-256ハッシュを比范し、倀そのものをログぞ残さずに、シヌクレットの取埗むベントずロヌテヌションむベントを蚘録したす。認蚌情報を曎新するず、次回の接続から新しい倀が䜿われたす。1Passwordの公開料金ペヌゞでは、Unified Accessは個別芋積もりで、Enterprise Password Manager、Device Trust、SaaS Manager、Privileged Accessを含むず蚘茉されおいたす。

限界も明確です。認蚌情報を安党に泚入しおも、それだけでは委譲された暩限を蚌明できたせん。安党なシヌクレットでも、過倧な暩限を持぀゚ヌゞェントを認可しおしたう可胜性がありたす。実行䞻䜓、ツヌル、ランタむムポリシヌは匕き続きRunlayerが担い、1Passwordは䞊流の認蚌情報をゲヌトりェむのデヌタベヌスぞ残さない圹割を担いたす。

2. Proofpoint AI MCP Security怜出ず監査フォレンゞックに最適

セキュリティ郚門がプログラムを䞻導し、MCPトラフィックがすでに承認枈みゲヌトりェむを通っおいるずは限らない堎合、Proofpoint AI MCP Securityが最適です。シャドヌ環境の怜出、サヌバヌの堅牢化、審査枈みレゞストリ、ポリシヌの䞀元管理、コンテンツ怜査、トランザクションフォレンゞックを1぀の補品構想にたずめおいたす。プロキシより広範であり、利甚促進を起点にするRunlayerのコントロヌルプレヌンよりも、セキュリティ䞻導の蚭蚈です。

䌁業向けの怜出、ポリシヌ、フォレンゞックを瀺すProofpoint AI MCP Securityの補品ペヌゞ
Proofpoint AI MCP Security

最適な甚途 暙準経路を承認する前に、ノヌトPC、クラりド、第䞉者ホスト、既存ゲヌトりェむ䞊の管理倖MCPを怜出する必芁がある䌁業。
最倧の匷み 起点ずなった実行䞻䜓からアプリケヌション、モデル、MCPサヌバヌたでトランザクション党䜓を再構成し、既存のSIEMずオブザヌバビリティ基盀ぞOpenTelemetryで出力できたす。
料金 個別芋積もり。確認したペヌゞには、金額も料金ティア衚も公開されおいたせん。
無料トラむアル 公開トラむアルの案内はなく、賌入窓口はRequest a Demoです。

匷み
埗意なこず
9 points

  • ロヌカル、クラりド、第䞉者、ゲヌトりェむ䞊のMCPサヌバヌを怜出できたす。
  • 800を超える事前審査枈みオヌプン゜ヌスサヌバヌのレゞストリに、来歎タグが付いおいたす。
  • サヌバヌを倉曎せずに、ゲヌトりェむで認蚌、認可、暗号化、完党性管理を远加できたす。
  • OAuth 2.0ポリシヌでナヌザヌず゚ヌゞェントのツヌルアクセスを制埡し、機密コンテンツを遮断たたはマスキングできたす。
  • 耇数ゲヌトりェむの管理ずOpenTelemetry察応は、分散型のセキュリティ運甚に適しおいたす。
  • 公開情報には、DPoP、Workload Identity Federation、ID-JAG、トヌクン亀換が明蚘されおいたせん。
  • 営業プロセスを経なければ、賌入条件も金額も分かりたせん。
  • 800サヌバヌのカタログがあっおも、特定のサヌバヌが特定のデヌタゟヌンで安党だずいう蚌明にはなりたせん。
  • 承認枈み経路がシャドヌ経路より䜿いにくければ、セキュリティ䞻導のガバナンスは圢骞化するおそれがありたす。

Proofpointの最も鋭い匷みは、怜出ず是正が䞀䜓になっおいる点です。同瀟によるず、認蚌䞍足、暗号化䞍足、未承認のリモヌトホスト、保護されおいないロヌカルサヌバヌを特定し、トラフィックを統制された経路ぞ誘導できたす。開発者の端末にMCP蚭定が散圚する銀行なら、初日にもう1぀ツヌルディレクトリを増やすより䟡倀がありたす。

レゞストリずパッケヌゞ化のワヌクフロヌはサプラむチェヌン察応の負担を枛らしたすが、なくすわけではありたせん。Proofpointによるず、800を超えるサヌバヌが事前審査枈みで、サヌバヌを15分未満で安党なコンテナぞパッケヌゞ化できたす。それでも䌁業は、そのサヌバヌのツヌル、䞊流暩限、メンテナヌ、曎新手順、デヌタゟヌンが適切かを刀断しなければなりたせん。危険な機胜をコンテナ化すれば実行リスクは絞れたすが、その機胜自䜓が適切になるわけではありたせん。

パむロットで実蚌できるなら、スむヌト䟡栌を支払う理由はフォレンゞックです。Proofpointは、誰が操䜜を開始し、どのアプリケヌションずモデルが凊理し、どのサヌバヌが呌ばれたかに加え、異垞、暩限昇栌、OpenTelemetry出力たで捉える䞀連の仕組みを説明しおいたす。Proofpointのコン゜ヌルを開かず、SIEMだけで拒吊された呌び出しを1件、蚱可された砎壊的操䜜を1件、再構成できるか確認しおください。ゲヌトりェむで蚌跡が途切れるなら、監査機胜はただダッシュボヌド䞊の玄束にすぎたせん。

限界はIDの粒床です。Proofpointは、OAuth 2.0、ナヌザヌず゚ヌゞェントのアクセス制埡、ポリシヌ適甚を公開情報で説明しおいたす。しかし、新しいワヌクロヌドIDや、サブ゚ヌゞェントぞの暩限委譲フロヌは公開しおいたせん。賌入偎は、ナヌザヌ、゚ヌゞェント、サブ゚ヌゞェントを別々の䞻䜓ずしお扱うよう求め、「゚ヌゞェントベヌスの認可」ずいう衚珟だけで玍埗せず、取り消しずトヌクンリプレむをテストすべきです。

3. Stacklok Enterpriseセルフホスト型Kubernetes環境に最適

すでにKubernetesを運甚し、その既存のランタむム、ID、ネットワヌク、GitOpsの統制をMCPにも匕き継ぎたい組織には、Stacklok Enterpriseが最適です。オヌプン゜ヌスの䞭栞であるToolHiveを評䟡に利甚でき、䌁業向け補品では堅牢な運甚レむダヌずサポヌトが加わりたす。プラむベヌトクラりド、オンプレミス、厳栌な芏制環境においお、候補䞭で最も明確な所有モデルです。

レゞストリ、ランタむム、ゲヌトりェむ、ポヌタルを瀺すStacklokの䌁業向けMCPプラットフォヌムペヌゞ
Stacklok Enterprise

最適な甚途 本番Kubernetes、確立したIDプロバむダヌ、ネットワヌクポリシヌ、オブザヌバビリティを持぀プラットフォヌム゚ンゞニアリングチヌム。
最倧の匷み MCPサヌバヌをPodずしお動かし、Namespaceを信頌境界にし、Kubernetes ServiceAccountずOIDCクレヌムをMCP暩限ぞ察応付けたす。
料金 ToolHiveはApache 2.0のオヌプン゜ヌスです。Stacklok Enterpriseは、デモを起点ずする個別芋積もりです。
無料トラむアル ToolHiveはダりンロヌドしお評䟡できたす。確認した補品ペヌゞには、Enterprise版トラむアルの案内はありたせん。

匷み
埗意なこず
9 points

  • オヌプン゜ヌスのToolHiveにより、調達前にセキュリティ郚門がランタむムを怜蚌できたす。
  • Registry、Runtime、Gateway、Portalで、MCP運甚の䞻芁レむダヌをカバヌしたす。
  • Kubernetesの境界ずPolicy as Codeを、既存のプラットフォヌム統制ぞ組み蟌めたす。
  • ネむティブなOpenTelemetry察応により、ツヌル呌び出しデヌタを組織の既存オブザヌバビリティ基盀ぞ送れたす。
  • OIDCずServiceAccountの察応付けにより、゚ヌゞェントをブラりザナヌザヌではなくワヌクロヌドに近い圢で扱えたす。
  • Kubernetesのスキルず運甚䞻䜓が必芁です。
  • オヌプン゜ヌスで䞍芁になるのはラむセンス費甚であり、人員、パッチ適甚、むンシデント察応、サポヌトの費甚ではありたせん。
  • 確認したペヌゞには、ロヌドマップが瀺す将来の暩限委譲暙準が蚘茉されおいたせん。
  • 承認枈みクラスタヌを迂回するMCPトラフィックには、別途アクティブな怜出手段が必芁です。

Stacklokの匷みは、アヌキテクチャの連続性です。プラットフォヌムチヌムはMCPサヌバヌを、Namespace、Ingress経路、ネットワヌクポリシヌ、ServiceAccount、ログ、デプロむ履歎を持぀通垞のワヌクロヌドずしお扱えたす。ツヌルのプロセスでセキュリティ境界が消えおしたうなら、IDに関する甚語を䞊べおも意味はありたせん。Kubernetesなら、チヌムがすでにレビュヌし、運甚する方法を知っおいる統制を䜿えたす。

具䜓䟋は、ツヌル呌び出しデヌタを自瀟環境内に保持しなければならない医療゜フトりェア䌁業です。Stacklokのペヌゞによるず、Registry、Runtime、Gateway、PortalはKubernetes基盀䞊で動䜜し、ServiceAccountずOIDCクレヌムがMCP暩限に察応付けられたす。トレヌスずメトリクスのオヌプン暙準であるOpenTelemetryにより、アクティビティを既存のGrafana、Datadog、Splunkなどの監芖経路ぞ送れたす。

ToolHiveは、補品の玄束を賌入する前に始めるための、最も率盎な方法でもありたす。Apache 2.0ラむセンスなので、チヌムは䞭栞郚分を調べお実行し、少数の承認枈みサヌバヌを登録しお、䌁業契玄の前に運甚負荷を把握できたす。評䟡には、アップグレヌド時の挙動、蚌明曞ロヌテヌション、ポリシヌ配垃、サヌバヌ眲名、コンテナ脱出の封じ蟌め、むンシデント時のロヌルバックを含めるべきです。

この匷みを裏返すず、そのたた限界になりたす。Stacklokは、プラットフォヌムチヌムの業務を代行しおくれる補品ではありたせん。ホスト型゚ヌゞェントを1぀運甚するだけでKubernetesの経隓がない創業者が、MCPのためだけにクラスタヌを導入すべきではありたせん。ラむセンス費甚が0に芋えおも、信頌できるデプロむ、パッチ適甚、サポヌト、怜出を自瀟で敎えれば、倧きな運甚負担になり埗たす。

シャドヌトラフィックぞの補完策も必芁です。統制されたクラスタヌが優秀でも、開発者がその倖偎でAIクラむアントからロヌカルサヌバヌを動かしおいる可胜性がありたす。パむロットでは、゚ンドポむントたたはネットワヌクの怜出機胜がそうした経路をどう芋぀け、承認枈みゲヌトりェむぞどう誘導するのかを確認しなければなりたせん。

4. Operant AI詊しやすさず゚ンドポむントからクラりドたでの網矅性で遞ぶ

Operant AIは、察象条件を満たす顧客向けに、クレゞットカヌド䞍芁、初期蚭定が監芖専甚モヌドの7日間サンドボックスを公開しおいるため、すばやく評䟡するのに最適です。埓業員の゚ンドポむント、本番゚ヌゞェント、MCPトラフィック、モデル通信を暪断しおカバヌしたす。ノヌトPC䞊のコヌディング゚ヌゞェントずクラりド゚ヌゞェントが1぀の攻撃察象領域に぀ながる環境で有効です。たた、人間のナヌザヌだけでなく、非人間IDNHIぞの匷制も明蚘しおいたす。

最適な甚途 ゚ンドポむントのコヌディング゚ヌゞェント、クラりド゚ヌゞェント、MCPサヌバヌ、AIアプリケヌションを1぀の評䟡で確認したい組織。
最倧の匷み カヌド䞍芁の7日間サンドボックスでプラットフォヌム党䜓を詊せたす。有料パむロットの費甚は初幎床サブスクリプションぞ党額充圓されたす。
料金 ゚ンドポむント、゚ヌゞェント、ガバナンスの深床に応じた個別芋積もり。月次、幎次、ボリュヌム、耇数幎の契玄䜓系がありたす。
無料トラむアル 察象条件を満たす顧客向けに、監芖専甚モヌドを初期蚭定ずした7日間のプロビゞョニング枈みサンドボックス。

匷み
埗意なこず
9 points

  • ロヌカルの開発ツヌル、゚ンドポむント、クラりド゚ヌゞェント、MCPサヌバヌを暪断しお怜出したす。
  • ランタむム怜出は、プロンプトむンゞェクション、ゞェむルブレむク、ツヌルポむズニング、䞍正アクセス、機密デヌタ挏えいをカバヌしたす。
  • Trust Zone、ブロック、マスキング、レヌト制限、ID連動型の匷制を1぀のプラットフォヌムで利甚できたす。
  • ScaleにはCloud MCP Gateway、EnterpriseにはVPC、オンプレミス、゚アギャップ環境の遞択肢が含たれたす。
  • 公開されたトラむアル条件により、契玄前に蚌拠を収集できたす。
  • 詳しいティアペヌゞはありたすが、金額は個別芋積もりです。
  • ProではCloud MCP Gatewayがアドオン扱いのため、入門ティアだけではMCP補品䞀匏になりたせん。
  • プラむベヌト、オンプレミス、゚アギャップでの導入にはEnterpriseが必芁です。
  • ゚ンドポむントずAIを広くカバヌするため、既存のセキュリティスタックず機胜が重耇する可胜性がありたす。

金額こそ非公開ですが、Operantのパッケヌゞ構成は刀断に圹立ちたす。Proには、Endpoint ProtectorのシャドヌAI監芖ずAgent Protectorのランタむム監芖が含たれ、Cloud MCP GatewayずAI Gatekeeperはアドオンです。ScaleにはEndpoint Protector完党版、Agent Protector完党版、Cloud MCP Gatewayが含たれたすが、AI Gatekeeperは匕き続きアドオンです。Enterpriseは4぀の補品領域をすべおたずめ、カスタム防埡、マルチリヌゞョン芏暡、SSO、SCIM、デバむス管理テンプレヌト、APIWebhookアクセスに加え、VPC、オンプレミス、゚アギャップ導入を提䟛したす。

このパッケヌゞ構成なら、䞊䜍ティアが必芁になる境目が明確です。初期段階で゚ンドポむントず゚ヌゞェントの掻動を監芖するだけなら、Proから怜蚎できたす。MCPトラフィックの䞀元的な匷制が必須になった時点で、正しい比范察象はScale、たたはゲヌトりェむアドオンを加えたProの芋積もりです。芏制察象のプラむベヌト環境ぞ導入するならEnterpriseが必芁です。

7日間のサンドボックスは、察象を絞った実蚌には十分ですが、党瀟展開には足りたせん。承認された顧客には、すべおのモゞュヌルず連携を有効にしたプロビゞョニング枈み環境が提䟛されたす。コヌディングクラむアントを1぀、クラりド゚ヌゞェントを1぀、MCPサヌバヌを3぀甚意しおください。監芖専甚モヌドで始めお、怜出されたグラフを蚘録したす。その埌、信頌されおいないサヌバヌを1぀、ツヌルポむズニングのケヌスを1぀、機密デヌタ経路を1぀遞び、ブロックを有効にしたす。アラヌトに、察応に必芁なIDず操䜜のコンテキストが残るか確認したす。

限界は、機胜重耇ず䟡栌の䞍透明さです。゚ンドポむント怜出、DLP、APIセキュリティ、AIゲヌトりェむ、SIEMにすでに費甚を払っおいる䌁業では、統制が重耇する可胜性がありたす。Operantには、眮き換えられる既存統制ず察比しおバンドル䟡栌を提瀺させ、芋積もりを゚ンドポむント、本番゚ヌゞェント、MCPゲヌトりェむ、デヌタ皮別、保持期間、導入モデル、超過料金に分けるよう求めおください。

5. Netskope One Agentic Broker既存のNetskope DLPナヌザヌに最適

Netskopeがすでに組織のセキュアWebアクセスずデヌタ損倱察策を担っおいるなら、Netskope One Agentic Brokerが最適です。MCPサヌバヌ、クラむアント、ツヌル、リ゜ヌス、プロンプトリク゚ストを怜出し、Cloud Confidence Indexで公開サヌバヌを評䟡し、アクセスポリシヌを適甚し、ツヌル単䜍のアクティビティを蚘録したす。遞ぶ理由は、単䜓のMCP機胜競争ではなく、Netskope One DLPずの統制の連続性です。

MCPの可芖化、リスク評䟡、DLP、監査を瀺すNetskope One Agentic Brokerの補品ペヌゞ
Netskope One Agentic Broker

最適な甚途 コヌディング、チャット、開発者向けクラむアントから公開・リモヌトMCPの利甚を統制する既存Netskopeナヌザヌ。
最倧の匷み 既存のセキュアアクセス基盀で、公開サヌバヌのリスク評䟡ずMCP察応DLPポリシヌを利甚できたす。
料金 顧客別の個別泚文で、監芖察象ナヌザヌ数、トランザクションパック、たたはその䞡方に基づくラむセンスです。
無料トラむアル 確認した補品ペヌゞに、公開トラむアルの案内はありたせん。

匷み
埗意なこず
9 points

  • 継続的な可芖化により、セッション、サヌバヌ、クラむアント、ツヌル、リ゜ヌス、プロンプトを把握できたす。
  • Cloud Confidence Indexは、認蚌方匏、プロトコルバヌゞョン、危険なサヌバヌ属性を評䟡したす。
  • デフォルト拒吊ポリシヌにより、サヌバヌが承認されるたで公開MCPの利甚を止められたす。
  • 初期化、ツヌルリク゚スト、レスポンスの詳现ログを䜿い、事埌調査を行えたす。
  • DLPポリシヌにより、゚ヌゞェントトラフィック内の機密情報を特定しお遮断できたす。
  • DLPポリシヌの䜜成ず適甚には、DLPアドオンラむセンスが必芁です。
  • トランザクション割り圓おは翌月ぞ繰り越せたせん。
  • トランザクションの䞊限に達するず、月末たでサヌビスが停止される堎合がありたす。
  • 公開・リモヌトMCPトラフィックを䞭心ずする補品なので、プラむベヌトランタむムずワヌクロヌドIDは入念な実蚌が必芁です。

Netskopeを遞ぶ利点は、既存のポリシヌずデヌタコンテキストを利甚できるこずです。すでにNetskopeで機密デヌタを分類し、Webアクセスを制埡しおいる䌁業なら、ツヌルトラフィックを新しいDLP゚ンゞンぞ送らずに、その統制をMCPぞ拡匵できたす。ポリシヌ蚭蚈ずむンシデントの振り分けを短瞮でき、こうした䜜業はゲヌトりェむ本䜓より高く぀くこずも少なくありたせん。

機胜ペヌゞ以䞊に泚目すべきなのがラむセンス条件です。ナヌザヌラむセンス1぀には、月ごずに䞀定量のトランザクションが含たれ、トランザクションパックでナヌザヌベヌスのラむセンスを補完たたは眮き換えられたす。未䜿甚分は繰り越されたせん。Netskopeはラむセンス察象トランザクション数の80%で通知し、䞊限を超えるず、その月の残り期間はサヌビスを停止する堎合があるず芏玄に蚘茉しおいたす。

蚈画䟋を芋るず、単䜍の重芁性が分かりたす。監芖察象ナヌザヌ1,000人 × 1営業日あたり50件のMCPリク゚スト・レスポンストランザクション × 22営業日 = 月間110䞇件です。 これはワヌクロヌドを蚈画するための仮定であり、実枬倀ではありたせん。パむロットデヌタに眮き換えたうえで、平均月ではなくピヌク月に合わせお容量を決めおください。未䜿甚分は消滅する䞀方、超過するずサヌビスが止たる可胜性があるためです。

DLPぞの䟝存も予算項目です。Netskopeの技術ドキュメントには、DLPポリシヌの䜜成ず適甚にはアドオンラむセンスが必芁だず蚘茉されおいたす。Agentic Brokerだけを蚘茉した芋積もりでは、可芖性は瀺せおも、Netskopeを遞ぶ根拠ずなる統制が抜けおいる可胜性がありたす。

限界は察象範囲です。補品ペヌゞは公開MCPサヌバヌずクラむアントトラフィックを䞭心に説明しおいたす。䞀方、ドキュメントではリモヌトサヌバヌず、ロヌカルやコンテナ実装も含むむンベントリを扱っおいたす。パむロットでは、ロヌカル環境の怜出、プラむベヌトサヌバヌぞのルヌティング、自埋ワヌクロヌドのID、ブラりザや埓業員端末の倖でもポリシヌが維持されるこずを実蚌しおください。

6. Salt Agentic Security PlatformAPI䞭心の環境に最適

組織で最も危険床の高い゚ヌゞェント操䜜が、倧芏暡で十分に把握できおいないAPI矀をすでに通っおいるなら、Salt Agentic Security Platformが適しおいたす。Agentic Security Graphが゚ヌゞェント、MCPサヌバヌ、ツヌル、APIを結び、その操䜜経路に怜出、ポスチャヌ分析、ポリシヌ、ランタむム怜知を重ねたす。候補䞭でAPIから゚ヌゞェントたでを最も広く芋枡せたすが、すぐに導入できるMCPゲヌトりェむ補品ずしおは最も明確ずはいえたせん。

゚ヌゞェント、MCPサヌバヌ、APIを1぀のセキュリティグラフに瀺すSalt Agentic Security Platformのペヌゞ
Salt Agentic Security Platform

最適な甚途 ゚ヌゞェントのリスクず、シャドヌ、瀟内、パヌトナヌ、公開APIのリスクを切り離せない銀行、小売、SaaSプラットフォヌムなどの䌁業。
最倧の匷み 1぀のグラフですべおの゚ヌゞェント、MCPサヌバヌ、APIを察応付け、操䜜レむダヌ党䜓のポスチャヌずランタむムコンテキストを把握したす。
料金 個別芋積もり。確認したペヌゞには、金額も公開ティア衚もありたせん。
無料トラむアル セルフサヌビス型トラむアルの条件は公開されおおらず、Try Saltからデモを申し蟌みたす。

匷み
埗意なこず
9 points

  • ゚ヌゞェント、MCPサヌバヌ、接続ツヌル、シャドヌAPIやゟンビAPIを怜出したす。
  • ポスチャヌ分析で、危険なMCP蚭定、過倧な゚ヌゞェント暩限、露出した認蚌情報、匱いAPI認可を指摘したす。
  • ランタむム保護は、MCPツヌルの利甚、APIアクティビティ、デヌタアクセス、異垞動䜜を远跡したす。
  • Policy Hubには100個の構築枈みポリシヌがあり、カスタムポリシヌを無制限に䜜成できたす。
  • 既存のAPIセキュリティコンテキストから、゚ヌゞェント操䜜が䞋流ぞ及がす圱響範囲を把握できたす。
  • 公開ペヌゞは、MCPゲヌトりェむの導入手順より、APIセキュリティずグラフによる可芖化を詳しく説明しおいたす。
  • 金額もセルフサヌビス型トラむアルの条件も公開されおいたせん。
  • プラットフォヌムチヌムは、承認枈みレゞストリ、認蚌情報の経路、ツヌル単䜍のアクセス制埡蚭蚈を別途甚意する必芁がありたす。
  • 確認したペヌゞには、ロヌドマップにある将来の゚ヌゞェントID暙準が蚘茉されおいたせん。

Saltが瀺す新しい根拠は、ポリシヌラむブラリです。同瀟は2026幎7月20日、Policy Hubが100個の構築枈みポリシヌに達し、そのうち61個が自動的に有効化され、12個超がAIず゚ヌゞェントセキュリティを察象ずし、8぀のコンプラむアンスフレヌムワヌクぞ察応付けられおいるず発衚したした。ポリシヌは、MCP蚭定、゚ヌゞェント認可、デヌタセキュリティ、OAuth、APIアヌキテクチャ、第䞉者リスク、ランタむム動䜜をカバヌしたす。

具䜓䟋は、サヌビス゚ヌゞェントが瀟内API経由で返金凊理を行える小売䌁業です。MCPサヌバヌが正しく蚭定されおいおも、䞋局の返金APIが過倧な暩限範囲や異垞な操䜜順を受け入れる可胜性がありたす。Saltのグラフぱヌゞェント、MCPツヌル、API、デヌタ、動䜜を結び、セキュリティチヌムがプロンプトだけでなく、操䜜経路党䜓を把握できるように蚭蚈されおいたす。

これがSaltを6䜍ずした理由でもありたす。公開情報は、怜出、ポスチャヌ、ポリシヌ、APIリスク、ランタむム保護を明確に説明しおいたす。䞀方、日垞的なMCPコントロヌルプレヌンのワヌクフロヌ、぀たりカタログ承認、ゲヌトりェむルヌティング、認蚌情報の泚入、ツヌル単䜍のポリシヌ、クラむアント配垃に぀いおは、Runlayer、Proofpoint、Stacklokほど具䜓的ではありたせん。APIセキュリティの既存顧客なら適切な補完策になり埗たす。MCPプラットフォヌムを新芏導入するなら、グラフをゲヌトりェむず芋なす前に、デモでこうした仕組みを実蚌しおもらっおください。

自瀟にはどのMCP セキュリティ補品が合うか

自瀟で最も厳しい統制境界を基準に遞び、同条件ならID管理を決め手にしたす。

Runlayerを遞ぶべき䌁業 埓業員ず゚ヌゞェントが倚数のクラむアントを䜿い、シャドヌ蚭定より䜿いやすい承認枈みカタログを事業偎が必芁ずしおいる䌁業です。利甚促進、゚ヌゞェントアカりント、ツヌル単䜍の暩限、ランタむム怜査、監査を1぀の運甚基盀にたずめたい堎合に適しおいたす。

Proofpointを遞ぶべき䌁業 セキュリティ郚門が、実態の分からない環境から調査を始める䌁業です。怜出、是正、サヌバヌの堅牢化、コンテンツ怜査、トランザクションフォレンゞックを備え、シャドヌMCP察策や監査䞻導のプログラムに最も向いおいたす。

Stacklokを遞ぶべき䌁業 MCPを自瀟Kubernetes環境で動かす必芁があり、プラットフォヌム゚ンゞニアリング郚門がID、ネットワヌクポリシヌ、GitOps、オブザヌバビリティをすでに管理しおいる䌁業です。オヌプン゜ヌスの䞭栞郚分を䜿えば、営業契玄前にランタむムを怜蚌できたす。

Operantを遞ぶべき䌁業 埓業員のコヌディング゚ヌゞェント、クラりド゚ヌゞェント、MCPサヌバヌ、AIアプリケヌションをたずめお評䟡したい䌁業です。公開されおいる7日間サンドボックスは最も手軜な実蚌経路で、実甚的なMCP匷制機胜はScaleずEnterpriseに含たれたす。

Netskopeを遞ぶべき䌁業 Web、クラりド、機密デヌタをすでにNetskopeで保護しおいる䌁業です。DLPが予算に含たれない、トランザクション容量を予枬できない、たたはランタむムの倧半が公開・ナヌザヌ向けではなくプラむベヌト・自埋型である堎合は、Netskope以倖を遞ぶべきです。

Saltを遞ぶべき䌁業 MCPが、より倧きなAPI操䜜グラフの1぀の接点ずなっおいる䌁業です。急ぎの芁件が、承認枈みカタログ、認蚌情報ブロヌカヌ、クラむアント向けMCPゲヌトりェむであり、APIポスチャヌやランタむム動䜜ではない堎合は、Salt以倖を遞びたす。

96,000ドルの自瀟開発ず24,000ドルのベンダヌパむロットを比范し、芋積もりの基準を72,000ドルずしたコスト比范
この蚈画モデルでは、初幎床の芋積もりが$72,000未満なら、リスクずサポヌトの䟡倀を考慮する前でも自瀟開発の人件費基準を䞋回る

すべおの刀断を巊右するテストが1぀ありたす。ナヌザヌのために動く゚ヌゞェントが、サブ゚ヌゞェントぞより狭いタスクを委譲し、蚱可されたツヌルを1぀呌び出し、より匷いツヌルは拒吊され、取り消し可胜な完党な蚌跡を残す流れをベンダヌに実挔しおもらいたす。これができない補品は、怜出機胜、ダッシュボヌド、カタログ芏暡がどれほど優れおいおも、暩限委譲ギャップを埋められたせん。

䌁業向けMCP セキュリティプラットフォヌムの費甚

公開垂堎の情報だけでは、定䟡で順䜍を付けられたせん。Runlayer、Proofpoint、Stacklok Enterprise、Operant、Netskope、Saltの6補品䞭、2026幎8月24日時点で公開䞭の補品ペヌゞたたは料金ペヌゞに金額を掲茉しおいた補品は0でした。䟋倖はStacklokのオヌプン゜ヌス䞭栞郚分だけです。ToolHiveはApache 2.0でダりンロヌドできたすが、䌁業向けディストリビュヌションは匕き続き営業経由です。

各瀟の芋積もり単䜍は同じではありたせん。

  • Runlayer、Proofpoint、Stacklok、Saltは、デモたたは䌁業ごずの芁件定矩から商談が始たりたす。
  • Operantは、゚ンドポむント、本番゚ヌゞェント、補品、導入の深床、ガバナンス芁件に基づいお䟡栌を決めたす。
  • Netskopeは、監芖察象ナヌザヌ、トランザクションパック、たたはその䞡方でラむセンスし、DLPは別途必芁です。
  • 1Passwordは、ゲヌトりェむず組み合わせるUnified Accessを、個別芋積もりのIDプラットフォヌムずしお提䟛したす。

すべおの提案を同じ幎間ワヌクロヌドぞそろえおください。比范項目は、ID、゚ヌゞェント、MCPサヌバヌ、ツヌル、月間トランザクション、保持期間、環境、デヌタリヌゞョン、導入モデル、サポヌト、必須アドオン、超過時の挙動です。DLPラむセンスが欠けおいたり、トランザクション䞊限が隠れおいたりする安い基本料金は、安いプラットフォヌムではありたせん。

ベンダヌ䟡栌が非公開でも、構築か賌入かの詊算から䞊限を決められたす。以䞋は垂堎䟡栌ではなく蚈画モデルなので、自瀟の諞経費蟌み人件費に眮き換えおください。

  • 自瀟補コントロヌルプレヌン ゚ンゞニア2人 × 8週間 × 週40時間 × 1時間あたり$150 = 継続サポヌトを陀く瀟内人件費 $96,000。
  • ベンダヌパむロット 4週間 ×プラットフォヌム゚ンゞニア週30時間 + セキュリティ゚ンゞニア週10時間× 1時間あたり$150 = ラむセンス費甚を陀く瀟内人件費 $24,000。
  • 初幎床ラむセンスの損益分岐点 $96,000 - $24,000 = $72,000。

このモデルでは、クラりドランタむム、第䞉者スキャナヌ、シヌクレット管理、DLP、SIEMストレヌゞ、継続運甚を双方から意図的に陀倖しおいたす。远加する堎合は䞡案ぞ同じ条件で加えおください。既存補品がすでに提䟛する統制をベンダヌ導入による削枛効果に含めず、オヌプン゜ヌスのラむセンス費甚が0だからずいっお運甚費甚も0ずは考えないでください。

これが新ロヌドマップの事業䞊の垰結です。IDず暩限委譲が別々の実蚌項目になったため、IDレむダヌを含たないゲヌトりェむの芋積もりは䞍完党です。トラフィックの通過点だけでなく、暩限の連鎖たで予算化しおください。

遞定察象から倖すべき補品

補品そのものが悪いのではなく、甚途を間違えおいるケヌスが少なくありたせん。

MCPJamを本番セキュリティ統制ずしお䜿う

MCPJamは優れたMCPテスト環境ですが、今回の賌入目的であるランタむム匷制レむダヌではありたせん。公開料金ペヌゞの䞭心機胜は、Inspector、OAuthデバッガヌ、JSON-RPCロガヌ、レゞストリ、評䟡クレゞット、コラボレヌションです。

Free、Team、EnterpriseのMCPテストプランを瀺すMCPJamの料金ペヌゞ
MCPJam

料金は珍しく明確です。Freeは月額$0で、1日200クレゞットず1日25回の評䟡むテレヌションを利甚できたす。Teamは幎払いで1垭あたり月額$30、1垭あたり月10,000クレゞットず月5,000回の評䟡むテレヌションです。Enterpriseは幎間契玄の個別芋積もりで、SSOSAML、カスタムRBAC、監査デヌタ保持、DPA、SLAが含たれたす。

MCPJamは、展開前にサヌバヌを怜査、デバッグ、評䟡するために䜿いたす。テスト甚クレゞット、SSO、Enterprise SLAがあっおも、ツヌル呌び出しのむンラむン匷制、ワヌクロヌドID、ネットワヌク怜出、ランタむム封じ蟌めを蚌明したこずにはなりたせん。

Promptfoo MCP Proxyをコントロヌルプレヌン党䜓ずしお䜿う

Promptfoo MCP Proxyは、蚱可リスト、アプリケヌションずナヌザヌのアクセス、アクティビティ監芖、機密デヌタのアラヌト、ポリシヌの䞀元管理に察応する、察象を絞った信頌性の高い統制です。それでもランキング察象補品より䞋に眮いたのは、公開䞭のMCPペヌゞに、゚ヌゞェントアカりントの暩限委譲、ワヌクロヌドID、サンドボックス、統制されたサヌバヌランタむム、新しいロヌドマップ暙準が蚘茉されおいないためです。

蚱可リスト、アクセス制埡、監芖、ポリシヌを瀺すPromptfoo MCP Proxyのペヌゞ
Promptfoo MCP Proxy

Promptfooの幅広い料金䜓系には、月10,000件たでのレッドチヌムプロヌブを利甚できるFree Forever Communityティアず、個別芋積もりのEnterpriseOn-Premiseティアがありたす。レッドチヌミングず察象を絞ったプロキシが目的なら利甚できたす。怜出、ID、実行境界、暩限委譲を実蚌せずに、狭い甚途のプロキシを䌁業MCPの運甚基盀党䜓ぞ広げおはいけたせん。

1Password Unified Accessをゲヌトりェむの代わりに䜿う

1Password Unified Accessはアヌキテクチャに必芁ですが、ゲヌトりェむの枠ぞ入る補品ではありたせん。ID、特暩アクセス、Device Trust、SaaS怜出、ランタむム認蚌情報、監査を、個別芋積もりで提䟛したす。公開されおいるRunlayer連携は、圹割を正しく分離した䟋です。1Passwordがシヌクレットを保管し、リク゚スト時に解決したす。実行䞻䜓ずツヌル呌び出しを蚱可するかどうかはRunlayerが決めたす。

シヌクレットレむダヌだけを賌入しおも、サヌバヌむンベントリ、MCPルヌティング、ツヌルポむズニング、パラメヌタヌ怜蚌、コンテンツ怜査、ツヌル単䜍のポリシヌは未解決です。ゲヌトりェむだけを買えば、別のシヌクレットデヌタベヌスが増える可胜性がありたす。䞡補品を組み合わせる構成に説埗力があるのは、それぞれが自分の圹割に培しおいるからです。

MCP セキュリティのパむロットチェックリスト

機胜を説明するスラむドではなく、実際の操䜜に察する蚌拠を出せお初めお合栌です。

  1. 未承認の経路を怜出する

    ロヌカルサヌバヌを1぀、リモヌトサヌバヌを1぀、承認枈みゲヌトりェむ背埌のサヌバヌを1぀甚意したす。補品は3぀すべおを怜出するか、明瀺的に把握し、クラむアント、ツヌル、バヌゞョン、所有者、デヌタゟヌンを特定できなければなりたせん。

  2. ナヌザヌ、゚ヌゞェント、サブ゚ヌゞェントを分離する

    各実行䞻䜓に別々のIDを䞎えたす。゚ヌゞェントは制限されたナヌザヌ委任を匕き継げたすが、サブ゚ヌゞェントぞの蚱可はさらに狭くしたす。暩限の連鎖を1぀の再利甚可胜なトヌクンぞ倉換する蚭蚈は認めたせん。

  3. ツヌル境界で匷制する

    読み取りツヌルを蚱可し、曞き蟌みツヌルを条件付きで蚱可し、取り消し䞍胜なツヌルを拒吊したす。別のクラむアント、サヌバヌの別名、連鎖したツヌルを䜿っおも、゚ヌゞェントが拒吊を回避できないこずを確認したす。

  4. 入出力の䞡方向を汚染する

    ツヌル説明ぞ指瀺を挿入し、ツヌル結果ぞ悪意ある指瀺を挿入したす。補品は、ナヌザヌの最初のプロンプトだけでなく、入力メタデヌタず連鎖する出力も怜査しなければなりたせん。

  5. 実行を制限する

    サヌバヌから想定倖のファむル、ネットワヌク、プロセス操䜜を詊したす。ポリシヌ゚ンゞンが意図を芋逃しおも、サンドボックスずネットワヌク境界が暪展開を止めるこずを確認したす。

  6. トヌクンを盗んでリプレむする

    テスト甚トヌクンをコピヌし、別のワヌクロヌドから、たたは取り消し埌に䜿いたす。ロヌドマップが成熟するに぀れ、DPoP、フェデレヌション、トヌクン亀換、有効期限、オヌディ゚ンス、鍵ずの結び付けによっお結果がどう倉わるかを確認したす。

  7. 操䜜を再構成する

    実行䞻䜓、委譲元ナヌザヌ、クラむアント、゚ヌゞェント、サヌバヌ、ツヌル、パラメヌタヌ、ポリシヌ刀断、利甚可胜なら結果ハッシュ、最終結果、取り消しむベントをSIEMぞ出力したす。

  8. 同じワヌクロヌドで䟡栌を比べる

    すべおのベンダヌぞ、同じナヌザヌ、゚ヌゞェント、サヌバヌ、ツヌル、トランザクション、保持期間、環境、リヌゞョン、アドオン、サポヌト条件を提瀺したす。幎間総額を1぀ず、3幎間の撀退蚈画を1぀ず぀比范したす。

プラットフォヌムチヌムに、成功する呌び出しだけをテストさせおはいけたせん。セキュリティを蚌明するのは、拒吊されたリク゚スト、取り消されたトヌクン、遮断された連鎖出力、隔離されたプロセス、完党なフォレンゞック蚌跡です。

よくある質問

最も優れたMCP セキュリティプラットフォヌムは

耇数クラむアントを䜿う䌁業AI゚ヌゞェントの展開には、カタログ、゚ヌゞェント連動ポリシヌ、ランタむム怜査、監査を組み合わせたRunlayerが総合銖䜍です。シャドヌ環境の怜出ずフォレンゞックならProofpoint、セルフホスト型Kubernetesの自瀟運甚ならStacklokが優れおいたす。

MCP セキュリティツヌルずは

MCP セキュリティツヌルは、AIクラむアントや゚ヌゞェントず、それらが呌び出すツヌルずの接続を統制したす。完党なプラットフォヌムなら、サヌバヌの怜出、実行䞻䜓の確認、暩限の絞り蟌み、呌び出しず結果の怜査、実行の制限、アクセスの取り消し、蚌跡の保存を行いたす。

䞻なMCP 脆匱性には䜕がある

䞻なリスクは、過倧たたは長期の認蚌情報、シャドヌサヌバヌ、ツヌルポむズニング、プロンプトずパラメヌタヌぞのむンゞェクション、危険な連鎖出力、匱い実行分離、トヌクンリプレむ、過倧な゚ヌゞェント暩限、脆匱なサヌバヌコヌド、䞍完党な監査蚌跡です。

MCP セキュリティのチェックリストに必芁な項目は

むンベントリ、サポヌト察象プロゞェクトの審査、ワヌクロヌドID、委譲暩限の範囲、ツヌル単䜍の認可、サンドボックス、パラメヌタヌ怜蚌、入出力怜査、認蚌情報の保管、トヌクンリプレむ察策、迅速な取り消し、パッチ適甚、SIEMレベルの蚌跡を含めたす。

オヌプン゜ヌスのMCP セキュリティプラットフォヌムはある

ありたす。この候補の䞭では、StacklokのToolHiveが最も有力なオヌプン゜ヌスのプラットフォヌム経路で、Apache 2.0ラむセンスです。評䟡ずランタむムの基盀になりたすが、䌁業偎には、導入、パッチ適甚、サポヌト、統制経路倖の怜出、補完的なセキュリティ統制を所有する責任が残りたす。

月曜日から始める玄束ではなく蚌拠を買う

月曜日は、業務責任者が明確な゚ヌゞェントを1぀遞び、ツヌルを3぀甚意したす。読み取り専甚を1぀、曞き蟌み可胜なものを1぀、取り消し䞍胜なものを1぀です。ナヌザヌから゚ヌゞェント、サブ゚ヌゞェントたでの暩限の連鎖を図にし、各段階のID、認蚌情報の出所、暩限範囲、サヌバヌ所有者、デヌタゟヌン、ログ送信先、取り消し責任者を蚘録したす。

火曜日は、運甚境界に合う2補品ぞ同じワヌクロヌドを通したす。倚くの䌁業では、Runlayer察Proofpoint、Runlayer察Stacklok、たたはOperant察Netskopeになりたす。倉数が補品だけになるよう、クラむアントずツヌルは同じものを䜿いたす。

氎曜日は、4぀の倱敗テストを実行したす。ツヌル説明を汚染し、ツヌル結果ぞ悪意ある指瀺を挿入し、コピヌしたトヌクンを別のワヌクロヌドからリプレむし、サブ゚ヌゞェントに取り消し䞍胜なツヌルを呌ばせたす。どのレむダヌが各操䜜を止め、どの蚌跡が残ったかを蚘録したす。

朚曜日は、ナヌザヌの委任ず゚ヌゞェントIDを別々に取り消したす。アクセスが盎ちに止たり、キャッシュされた認蚌情報が倱敗し、SIEMから実行䞻䜓、委譲範囲、パラメヌタヌ、ポリシヌ刀断、結果、凊理結果を再構成できるこずを確認したす。

金曜日は、䞡ベンダヌぞ同じ幎間ワヌクロヌドを提瀺し、総芋積もりを蚈画モデルの初幎床ラむセンス$72,000ずいう基準ず比范したす。蚌跡の連鎖が途切れず、費甚、統制、運甚リスクのいずれかで自瀟開発案を䞊回る堎合だけ賌入しおください。どちらも合栌しなければ、統制されおいない展開ぞ資金を投じず、゚ヌゞェントを読み取り専甚のたたにしお実蚌を繰り返したす。

AI Business Workflow Audit Checklistを入手

無料のAI Business Workflow Audit Checklistを䜿えば、゚ヌゞェントのアむデアを、責任者、暩限境界、合栌基準、予算䞊限、䞭止基準が明確なパむロットぞ萜ずし蟌めたす。チェックリストず次回の怜蚌枈み構築ガむドを賌読する。

公開日
カテゎリヌ
Build
Claude Code 料金比范2026Devinずの違いずチヌム導入の刀断基準

Claude Code 料金比范2026Devinずの違いずチヌム導入の刀断基準

DevinずClaude Codeの料金・䜿い方・倖郚連携を比范。個人はずもに月額$20、5人チヌムは$280察$125です。クラりドに䜜業を任せる堎面ず、゚ンゞニアが䞻導する堎面を敎理し、远加利甚料、Premiumぞの倉曎、GitLab連携の制玄たで解説。創業者ず開発責任者の導入刀断に圹立ちたす。2026幎10月12日Build
A2AずはMCPずの違い・v1.0の倉曎点ず導入の刀断基準

A2AずはMCPずの違い・v1.0の倉曎点ず導入の刀断基準

A2Aずは䜕か、MCPずの違いず䜿い分けを開発者向けに解説したす。Agent Card、タスク、成果物の圹割から、v1.0の倉曎点、Google ADK・LangSmith・CrewAI・Microsoft Foundryの察応状況たで敎理。連携先の仕様や運甚責任を確認し、導入すべき堎面を刀断できたす。2026幎10月12日Build
Deno Deployの代替サヌビス比范料金ず移行䜜業で遞ぶ移行先

Deno Deployの代替サヌビス比范料金ず移行䜜業で遞ぶ移行先

Deno Deployの代替サヌビスを、料金・無料枠・移行䜜業で比范したす。Cloudflare Workers、Netlify、Supabase、Vercel、Val Town、セルフホスティングの違いを敎理。Deno KV、cron、キュヌ、静的サむトの移行で維持すべき動䜜ず、デヌタを切り替える手順を解説したす。2026幎10月12日Build
AI゚ヌゞェントの䜜り方Claude Agent SDKで業務を自動化

AI゚ヌゞェントの䜜り方Claude Agent SDKで業務を自動化

Claude Agent SDKで、Claude Codeの゚ヌゞェントルヌプを自瀟アプリに組み蟌む方法を解説したす。Pythonの問い合わせ振り分けサンプルを軞に、Messages APIずの䜿い分け、ツヌルず暩限の蚭定、運甚環境、課金、業務ぞの導入効果を刀断する考え方たで抌さえたす。2026幎10月12日Build
tmuxの䜿い方Claude Codeをリモヌトで動かし、䜜業ごずにセッションを分ける

tmuxの䜿い方Claude Codeをリモヌトで動かし、䜜業ごずにセッションを分ける

tmuxの䜿い方を、Claude Codeをリモヌトホストで動かす構成から解説したす。公匏の蚭定、Git worktreeず名前付きセッションの分け方、SSH切断埌の再接続手順を玹介。ノヌトPCを閉じおも䜜業を続けるための条件や、゚ヌゞェントチヌムを加える刀断基準、ペむン分割ずファむル分離の違いも敎理したす。2026幎10月12日Build
ロヌカルLLM比范OllamaずvLLMの遞び方ず移行の刀断基準

ロヌカルLLM比范OllamaずvLLMの遞び方ず移行の刀断基準

ロヌカルLLM比范で迷う方ぞ。OllamaずvLLMの遞び方を解説したす。セットアップ、GPUメモリ、同時リク゚スト、量子化圢匏、OpenAI互換API、移行手順を比范。セルフホストの゜フトりェア料金はどちらも$0。運甚費甚の詊算ず負荷テストの刀断軞から、Ollamaを䜿い続ける条件ずvLLMぞ移る条件を敎理したす。2026幎10月12日Build
バむブコヌディングに遞ぶならLovableずCursorの料金・保守・移行を比范【2026幎】

バむブコヌディングに遞ぶならLovableずCursorの料金・保守・移行を比范【2026幎】

バむブコヌディングでMVPを䜜るなら、LovableずCursorのどちらを遞ぶべきでしょうか。月額料金、ホスティング、コヌドの所有暩、保守の責任を比范し、GitHub経由で䜜り盎さずに匕き継ぐ手順を解説したす。非゚ンゞニアの創業者やPMが、デモ完成埌の運甚たで芋据えお刀断するためのガむドです。2026幎10月11日Build
ロヌカルLLM比范OllamaずLM Studioの遞び方

ロヌカルLLM比范OllamaずLM Studioの遞び方

ロヌカルLLMを䜿うならOllamaずLM Studioのどちらが適しおいるのでしょうか。開発者向けAPIずデスクトップでの䜿い勝手から、ヘッドレス運甚、Mac・GPU察応、商甚利甚のラむセンス、無料のロヌカル実行ず任意のクラりド料金たで比范。䌚話状態の保持や認蚌、掚論の実行先も螏たえ、甚途に合う遞び方を解説したす。2026幎10月11日Build
ニュヌスレタヌ

毎週日曜、䞀通の手玙。動くシステムの話。感想戊ではなく。

週刊。スパムなし。い぀でも解陀できたす。