接続不能でも判定を空白にしない: 10件で見た暫定判定の役割
10件のMCPサーバーのうち5件は、完全な接続証拠なしで暫定判定された。暫定判定は、欠けた証拠を無視するためではなく、判定空白を減らすために機能していた。
用語
| 用語 | 意味 |
|---|---|
| 出所 | 公開者の身元と配布経路が妥当かどうか |
| 暫定判定 | 完全な接続証拠がないときに返す保守的な判定 |
| 判定空白 | 使える判定が返らず、運用判断が宙に浮く状態 |
| 部分検査 | 実際に取得できた証拠だけで行う検査 |
リード
本番の検査では、接続不能は珍しくない。MCPサーバーが一時的にダウンしている、ネットワークポリシーで遮断されている、一部のエンドポイントだけ応答しない。こうした状況は実運用では日常である。
重要なのは、理想的には完全証拠の方がよい、という一般論ではない。完全証拠が欠けたとき、システムは何を返すべきかである。本稿では10件のサンプルから、空白判定より保守的な暫定判定の方が有用かを考える。
Key Findings
- 10件中5件が、部分証拠だけで判定されていた。
- 暫定判定の全件が WARN で、PASS でも BLOCK でも「判定不能」でもなかった。
- 暫定判定の主な根拠は 過去の検査履歴、公開者情報、パッケージメタデータ だった。
- 暫定判定の価値は、完全検査と同等の精度ではなく、判定空白を減らすこと にあった。
- 暫定判定は通常判定と分けて追わないと、接続性の問題をリスク上昇と誤読しやすい。
データセット
| 項目 | 値 |
|---|---|
| 対象 | 10件のMCPサーバー |
| 注目ケース | 完全な接続証拠なしで判定されたケース |
| 中心指標 | 暫定判定比率、判定結果、利用証拠 |
| 位置づけ | 探索的サンプル |
なぜ空白判定が問題なのか
「判定不能」は技術的には正直だが、運用上は真空を作る。
結局、現場は次のどれかを決めなければならない。
- 一時的に許可する
- 一時的に遮断する
- 手動レビューへ回す
- 次回スキャンまで保留する
つまり、空白判定は中立ではない。判断の負担を、構造化された根拠なしで別の場所へ押し出している。
MCP検査では接続ギャップが珍しくない以上、この問題は設計対象にすべきである。
実際に観測されたこと
暫定判定比率
| 指標 | 値 |
|---|---|
| 全件 | 10 |
| 暫定判定 | 5 |
| 暫定判定比率 | 50% |
サンプルの半数が、何らかの部分証拠処理を必要としていた。
この時点で、暫定判定を例外扱いするより、前提として設計する方が自然である。
暫定判定で使われた証拠
| 証拠源 | 利用件数 |
|---|---|
| 過去の検査履歴 | 5/5 |
| 公開者 / 出所情報 | 5/5 |
| パッケージメタデータ | 5/5 |
| 依存関係の静的分析 | 4/5 |
これらのケースは、何も分からないまま決められたのではない。
不完全ではあるが、意味のある証拠で決められていた。
暫定判定の結果
| 結果 | 件数 |
|---|---|
| PASS | 0 |
| WARN | 5 |
| BLOCK | 0 |
| 空白 / 判定不能 | 0 |
この分布は設計意図そのものを示している。
- PASS を出さないのは、ランタイムの確信が足りないから
- BLOCK を出さないのは、証拠欠落だけで最重判定にしないため
- WARN は、保守的にレビューへつなぐ中間状態として使うため
暫定判定は何のためにあるのか
1. 検査カバレッジを実用状態に保つ
暫定判定がなければ、このサンプルの半数は使える判定を持てなかった。
これはUI上の不便ではなく、カバレッジの欠損である。
2. 不完全証拠を完全証拠のふりで扱わない
暫定判定は、部分証拠を完全証拠と同一視しない。ただし、それでも「何も返さない」よりは保守的な判断を返す。その中間設計に価値がある。
3. 再検査の優先順位づけに使える
暫定判定は、そのまま再検査キューのシグナルになる。
証拠が欠けていた対象を、次回以降で優先的に取り直す理由を残せる。
暫定判定でできないこと
暫定判定には明確な限界もある。
十分に確認しにくいもの:
- ランタイムの挙動整合性
- 接続時にだけ表れる振る舞い
- 一部の相互作用依存リスク
したがって、暫定判定は完全検査の代替ではない。完全検査までの橋渡しである。
実務上の提案
- 暫定判定比率を通常 WARN 率と分けて追う。
- ユーザー向け表示でも 部分検査 を明示する。
- 暫定判定対象は再検査キューで優先する。
- 接続不能が繰り返される対象は、別の運用シグナルとして扱う。
これが必要なのは、WARN 増加が同じ意味とは限らないからである。
- 本当にリスクが増えたのか
- 接続性が悪化しただけなのか
- 対象の可用性が落ちたのか
この3つは別問題である。
限界
- サンプル数は10件であり、暫定判定の精度を大規模に評価したものではない。
- 後日の完全検査結果との比較は行っていない。
- 接続不能の原因分類は詳細化していない。
- 記事の目的は検査設計の説明であり、個票の特定ではないため、実名は出していない。
まとめ
暫定判定は、品質を下げる近道ではない。完全証拠が欠けたときに、判定空白を減らすための設計である。
今回の10件では、半数がその対象だった。もし空白判定を許容していたら、監視とレビューの実務は大きく痩せていたはずだ。保守的な暫定 WARN は、監視対象をレビューの流れの中に留めるために機能していた。
MCP Guard は、完全証拠が取れない場合でも、使える根拠に基づいて保守的な暫定判定を返す。