3,601件の全件再スキャン: 成功率99.9%の意味と残課題

用語

用語	意味
全件再スキャン	登録済みの全MCPサーバーに対して検査を再実行すること
処理完了率	検査が正常に終了した件数の割合
処理失敗	タイムアウトや取得失敗により検査が完了しなかったケース
サイズ超過分岐	パッケージが上限を超えた場合に、通常経路を回避する安全設計
連続監視	検査の実行中に処理停止やハングが発生しないことを確認するための継続的な観測

リード

検査基盤の信頼性は「1件が動くか」ではなく「全件を通して安定するか」で測られる。個別の検査が正しく動作することは前提条件にすぎず、数千件規模で連続実行した場合に、どの程度の完了率を達成し、どのような例外が発生し、それらが予測可能で管理可能であるかが、運用品質の本質的な指標となる。

本稿では、3,601件のMCPサーバーに対する全件再スキャンの運用実績を分析し、99.9%という処理完了率が何を意味するか、そしてその数値の裏にある課題を整理する。

Key Findings

1. 3,601件中 3,597件が正常完了（処理完了率 99.9%）。
2. 処理失敗は2件（0.06%）で、主因はタイムアウトまたは取得先の一時障害。
3. サイズ超過による運用分岐が2件（0.06%）で発生し、設計どおりに機能した。
4. 31.2時間の連続監視で、処理の停止や全体のハングは確認されなかった。
5. 高い完了率でも、失敗した検査の「理由を説明できるか」が次の品質基準になる。

背景: なぜ全件再スキャンが必要か

ポイント・イン・タイムの限界

ソフトウェアの安全性検査は、多くの場合「導入時に一度だけ」実施される。しかし、この「ポイント・イン・タイム」検査には根本的な限界がある。パッケージの更新、依存関係の変化、メンテナの交代、脆弱性データベースの更新など、検査時点以降に発生する変化は反映されない。

MCP エコシステムでは、この問題が特に顕著である。サーバーの更新頻度が高く、エコシステム自体が急速に進化しているため、一度の検査で得られた安全判定の有効期間は限られる。定期的な再検査は、導入時の検査を補完する不可欠な運用プラクティスである。

全件再スキャンの運用的意味

「全件」であることには技術的・運用的な意味がある。選択的な再スキャン（例：最近更新されたサーバーのみ）は効率的だが、更新検知自体の信頼性に依存する。全件再スキャンは、更新検知の漏れに依存しない網羅的なアプローチであり、定期的に実施することで「何かを見落としている」リスクを構造的に低減する。

ただし、全件再スキャンが現実的な運用として成り立つには、処理時間が許容範囲内であること、完了率が十分に高いこと、例外が管理可能であることが必要条件となる。本稿は、これらの条件が満たされているかを実データで検証する。

Methodology

項目	値
対象	3,601件の MCP サーバー
期間	2026-03-26〜2026-03-27
連続監視時間	31.2時間
指標	状態別件数、完了率、失敗率、サイズ超過件数

検査は全件を対象に連続実行し、各検査の状態（正常完了 / サイズ超過分岐 / 処理失敗）を記録した。処理失敗の原因分類、処理時間の推移、キュー内の滞留パターンなども併せて観測した。

結果

全体概要

状態	件数	比率
正常完了	3,597	99.89%
サイズ超過による分岐	2	0.06%
処理失敗	2	0.06%
合計	3,601	100%

処理失敗の分析

処理失敗の2件は、いずれも外部要因によるものだった。

失敗原因	件数	説明
タイムアウト	1	取得先の応答が制限時間内に完了しなかった
取得失敗	1	パッケージの取得先が一時的に利用不可だった

これらの失敗は検査基盤自体の問題ではなく、外部のパッケージソースの一時的な障害に起因する。検査基盤としては、タイムアウトと取得失敗を正常に検知し、処理をスキップして後続の検査を継続できた点が重要である。

サイズ超過分岐

サイズ超過分岐の2件は、パッケージサイズが処理上限を超えたケースである。この分岐は設計上の安全措置であり、上限を超えるパッケージを無理に処理して他の検査に影響を及ぼすことを防ぐためのものである。サイズ超過が発生したサーバーは、別途個別対応の対象として記録される。

連続監視の結果

31.2時間の連続監視を通じて、以下の点が確認された：

• 処理の停止（ハング）は発生しなかった
• キュー内の処理滞留の偏りは観測されなかった
• 処理速度の大幅な低下は発生しなかった
• メモリ使用量の異常な増加は検出されなかった

この結果は、検査基盤が3,601件規模の連続処理を安定して実行できることを実証している。

考察

1. 「99.9%」は堅牢性の証拠だが、完了ではない

99.9%という完了率は高い水準だが、「失敗ゼロ」ではない。運用品質の観点では、重要なのは失敗率の数値そのものよりも、「なぜ失敗したかを説明できるか」「失敗パターンが予測可能か」「失敗が他の検査に波及しないか」の3点である。

今回の結果では、失敗の2件とも原因が特定され、外部要因に分類された。検査基盤内部の問題ではないことが確認されたことで、「失敗は起きたが、原因は把握され、再現条件は明確で、他の検査への波及はなかった」という品質基準を満たしている。

次の品質段階は、失敗した検査の自動リトライとその成功率の追跡、そして失敗パターンの傾向分析による予防的対応である。

2. サイズ超過分岐は異常ではなく、設計済みの安全措置

運用指標を設計する際に、サイズ超過分岐を「失敗」に含めるか「正常な分岐」に含めるかは重要な選択である。本稿では、サイズ超過分岐を失敗とは区別している。

理由は明確で、上限を超えるパッケージを通常経路で無理に処理しないことは、安全側の選択だからである。仮にサイズ超過パッケージを強制的に処理した場合、処理時間の増大、メモリ不足、他の検査への影響といった二次的な問題を引き起こすリスクがある。上限を設け、超過時に別経路に分岐することは、全体の安定性を守るための設計判断である。

この区分を運用レポートに反映することで、「完了率が下がった」というアラートが、本質的な問題なのか設計どおりの動作なのかを判別できるようになる。

3. 31.2時間の連続監視は、安定性評価の出発点

31.2時間は一回の全件スキャンとしては十分な時間だが、安定性の評価としてはまだ一回分のデータにすぎない。短時間テストでは出ない遅延偏りや処理停滞を観測できる時間幅が確保された一方、以下の観点は今後の継続的な測定が必要である：

• 曜日・時間帯の影響: パッケージソースの応答速度が曜日や時間帯によって変動する可能性
• 処理回数の累積効果: 再スキャンを繰り返した際に、パフォーマンスの劣化が発生しないか
• スケールの影響: サーバー数が4,000件、5,000件と増加した場合に、処理時間と完了率がどう変化するか

4. 定期実行の実現可能性

3,601件を31.2時間で処理できたことは、週次での全件再スキャンが現実的であることを示している。仮に週1回のペースで全件再スキャンを実施した場合、各サーバーの安全判定は最大でも1週間前の情報に基づくことになる。これは「リアルタイム」ではないが、月次や四半期ごとの検査と比較すれば、問題の検出が格段に早まる。

ソフトウェアサプライチェーンの監視における業界標準と比較しても、週次の全件再スキャンは十分に高い頻度であり、コストと検出速度のバランスとして妥当な運用水準と言える。

運用上の推奨

1. 失敗指標と分岐指標の分離: 運用レポートでは、処理失敗とサイズ超過分岐を明確に分離し、それぞれの件数と推移を追跡する。
2. 失敗原因の分類の標準化: 失敗原因を「タイムアウト」「取得失敗」「その他」に分類し、原因ごとの対応手順を定義する。
3. 自動リトライの導入: 失敗した検査に対する自動リトライ機構を導入し、一時的な外部障害による影響を最小化する。
4. 長期トレンドの追跡: 週次の全件再スキャンを継続し、完了率・失敗率・処理時間の長期的な推移を監視する。

限界

1. 本稿は単一の実行ウィンドウ（31.2時間）に基づく結果であり、複数回の実行にまたがる再現性は未検証。
2. 個別の失敗事象の深掘り分析は別稿で扱う。
3. 外部公開向けに個別サーバー情報は除外しており、集計データのみを報告。
4. パッケージソースの応答速度変動が処理時間に与える影響は、定量的に分離していない。

Conclusion

検査基盤の再スキャン運用は「動くかどうか」の段階を終え、「例外をどこまで説明可能にするか」の段階に入った。3,601件を31.2時間で処理し、99.9%の完了率を達成した実績は、週次での定期再スキャンが運用として成立することを実証している。

次の改善軸は完了率の微増ではなく、失敗事象の再現性ある改善サイクルの確立、そしてサーバー数の増加に対するスケーラビリティの検証である。検査基盤の信頼性は、数値の高さだけでなく、例外が発生した際にその原因を迅速に特定し、対応できる体制の有無によって評価されるべきである。

---

MCP Guard の検査基盤は、3,601件規模の全件再スキャンを31.2時間で完了する運用実績を持っています。