ログイン中: ゲストモード

Research2026年2月22日Abcas Security Research

単一スコアでは何が隠れるか: 10件のMCPサーバーを検証観点ごとに分解した

10件のMCPサーバーを検証観点ごとに分解した結果、重要だったのは1つの点数ではなく、どこからリスクが生まれたかを追える判定だった。

用語

用語意味
検証観点出所、動作、履歴など、検査を構成する個別の観点
検査判定PASS / WARN / BLOCK の最終判定
動作上の矛盾宣言された動作と観測された動作が一致しないこと
部分検証期待した証拠の一部だけで判定するケース

リード

MCPサーバーのレビューを1つのスコアに圧縮すると、最も運用上重要な情報が消える。なぜその判定になったのか、である。

そのズレを見るために、10件のMCPサーバーを検証観点ごとに分解した。結論として重要だったのは、見栄えの良い単一スコアではない。判定をどの根拠まで遡れるかだった。

Key Findings

  1. 10件中 7件がレビューまたは遮断対象だった。
  2. 5件は部分的な証拠だけで判定されていた。
  3. 動作上の矛盾は2件で見つかり、最終判定に大きく影響した。
  4. 履歴上の評価は 低リスク寄り5件 / 要注意5件 に割れた。
  5. 最終判定は、1つの強い指標よりも、複数観点の組み合わせで決まることが多かった。

データセット

項目
対象10件のMCPサーバー
方式最終判定を検証観点ごとに分解
注目点追跡可能性、矛盾の影響、部分証拠での判定
位置づけ探索的分析

単一スコアが隠してしまうもの

同じ「70点」でも、その中身はまったく違いうる。

  • 公開者は確認できるが、動作に矛盾がある
  • 動作は整合しているが、出所が不明
  • 接続証拠は不足しているが、過去の検査履歴は強い

これらは同じ種類のリスクではない。
必要な対応も違う。だから、単一スコアは説明層として弱い。

10件で観測されたこと

最終判定の分布

判定件数比率
PASS330%
WARN660%
BLOCK110%

このサンプルで重要だったのは、「どう順位付けするか」より、「何がレビュー対象に押し上げたか」だった。

部分検証は珍しくなかった

モード件数比率
全観点で検証550%
部分検証550%

半数は、期待した証拠の一部が欠けた状態で判定されていた。
これは、実運用の検査が常に完全情報で動くわけではないことを示している。

矛盾は少数だが重かった

指標
動作上の矛盾があったサーバー2/10
履歴上、低リスク寄りだったサーバー5
履歴上、要注意だったサーバー5

矛盾は2件だけだったが、どちらも最終判定に大きく効いた。
頻度より影響度が大きいシグナルである。

なぜ多観点で見る必要があるか

1. リスクの種類を分けて扱える

同じ WARN でも、中身は違う。
ある WARN は出所の不透明さから来る。別の WARN は、宣言と実動作の不一致から来る。

観点ごとの分解がなければ、UI上は似て見えても、実際の対応優先順位を誤りやすい。

2. 部分証拠でも判定を止めなくて済む

ある層で十分な証拠が取れなくても、別の層の証拠を使って保守的な判定を返せる。これにより、「不明」のまま放置される運用空白を減らせる。

3. 誤判定の修正が速くなる

判定がズレたときに重要なのは、「スコア全体がズレたか」ではない。どの観点の根拠がズレたかである。多観点モデルは、その診断経路を短くする。

実務上の含意

このモデルの価値は抽象論ではない。運用上の反応が変わる。

  1. WARN対応: 出所レビューなのか、ランタイム挙動レビューなのかを分けられる。
  2. 監査対応: どの根拠で許可したのかを説明できる。
  3. チューニング: 誤判定が起きたとき、原因の観点だけを重点修正できる。

つまり、説明可能性はレポートの見栄えではなく、運用品質の一部である。

この文章が主張していないこと

このサンプルは小さいため、「必ず何層必要か」「重み付けをどうすべきか」を一般法則として示すものではない。

ここで十分に言えるのは次の2点である。

  • このサンプルでは、単一スコアだけでは重要な判定差分を説明しにくかった
  • 観点ごとの根拠を残すことで、判定は説明しやすく、修正もしやすくなった

限界

  1. サンプル数は10件であり、母集団統計としては限定的。
  2. 観点間の最適な重み付けまでは扱っていない。
  3. 検査実装の詳細は公開していない。
  4. 時系列の変化追跡は本稿の範囲外である。

まとめ

単一スコアの弱点は、精度が荒いことそのものより、判断の構造を隠してしまうことにある。

今回の10件では、価値があったのは「各サーバーに1つの数字を付けること」ではなく、出所、動作、履歴、部分証拠処理といった根拠まで遡れる判定だった。レビュー、修正、組織内説明を可能にするのは、その追跡可能性である。


MCP Guard は、複数の検証観点に根拠を分けて保持し、判定の説明可能性を重視する。