Registry Descriptions Go Stale Unevenly: An 89-Day Measurement of Model Context Protocol Drift, and Why Drift-Ranked Re-Auditing Under-Covers It

インターネットを、コンピューター（「エージェント」と呼ばれます）が仕事を手伝ってくれる道具を探しに行く、巨大で賑やかな市場だと想像してみてください。この作業を容易にするために、「Model Context Protocol (MCP)」レジストリという公開された「電話帳」が存在します。この電話帳には、すべてのツールが何をするものかを説明した小さなカードが付いています。最近、セキュリティの専門家たちが、そのカードが嘘をついていないか、あるいは危険ではないかをチェックし始めました。彼らは電話帳のスナップショットを撮り、カードを読み、「これは安全だ」あるいは「これは怪しい」と判断します。

しかし、ここには落とし穴があります。現実世界の電話帳は常に更新されています。今日、ある説明文を読んだとして、それは明日も同じ内容であると言えるでしょうか？ あるいは、見ていない隙に所有者がこっそりテキストを書き換えてしまったのではないでしょうか？ 本論文は、シンプルかつ極めて重要な問いを投げかけます。「ある説明文に対するセキュリティチェックは、その説明文自体が変化するまで、実際にどのくらいの期間有効であり続けるのか？」 これは、ツールの中身（道具自体）が危険かどうかという問題（それは別の話です）ではなく、セキュリティ担当者が読んだ「テキスト」が、そのツールが現在表示している「テキスト」と一致しているかどうかの問題なのです。もしテキストが変わってしまえば、古いセキュリティチェックは実体ではなく、幽霊を見ていることになってしまいます。

---

89日間の謎：電話帳が古くなる時

MCPレジストリを、数時間おきに新しい本が追加され、既存の本の表紙が絶えず書き換えられる、巨大で生きている図書館だと考えてみてください。ある研究者が、この図書館で「間違い探し」のゲームをすることにしました。彼らは単に写真を一枚撮ったのではありません。約89日間（およそ3ヶ月間）にわたり120回のスナップショットを撮り、図書館の蔵書が約3,500冊から19,000冊近くへと成長していく様子を観察しました。彼らの目的は、「変化のブレ」がどれほどの速さで発生するか、そしてセキュリティ担当者が「次に誰が表紙を書き換えるか」を予測できるかどうかを見極めることでした。

大きな驚き：「多忙な少数派」と「静かな多数派」

研究者は、誰が説明文を変更しているのかについて、非常に興味深い事実を発見しました。19,000人の生徒がいる教室を想像してみてください。「今日、服を着替えた人は誰ですか？」と尋れたとき、クラスの半分くらいが着替えていると予想するかもしれません。しかし、この図書館では、75%のサーバー（「生徒」）が、89日間の全期間を通じて説明文を一度も変更しませんでした。 彼らは岩のように安定していました。

しかし、実際に起きた変更は、驚くほど集中していました。全員が少しずつ変えたのではなく、ごく一部の者による大規模な変化だったのです。最も活動的な上位5%のサーバーが、**全変更の61%**を占めていました。これは、学校の生徒の5%が、校内の落書きの61%を引き起こしているようなものです。残りの生徒たちは、ただ静かに座っていただけなのです。

壊れた「水晶玉」

セキュリティチームは、変更の履歴があるサーバーだけを再チェックすることで時間を節約しようとすることがよくあります。その論理は、「昨日説明を変えたなら、今日も変える可能性が高い。だから『常連客』だけをチェックしよう」というものです。

研究者はこの手法をテストしました。彼らは過去の変更履歴に基づいてサーバーをランク付けし、未来を予測しようと試みました。その結果、この方法はランダムに推測するよりは「いくらか」マシではあるものの、説明文の変化を捉える戦略としては最悪であることが分かりました。

• もし予算を使って、変更履歴の多い上位5%のサーバーをチェックした場合、次の期間に実際に説明文を変更したサーバーの**約20%**しか捕捉できませんでした。
• さらに悪いことに、この手法は**「新規参入者」に対して完全に盲目でした。新しいサーバーには履歴がないため、ランク付けができないからです。しかし、研究者は「新しいサーバーこそが、最も説明文の変更が頻繁に起きている場所である」**ことを発見しました。「古株」だけを見ていれば、表紙を最も頻繁に書き換えている「新入生」たちを見逃してしまうのです。

本論文は、過去の変更に基づいて誰が変更するかを予測しようとする試みは、昨日の雲だけを見て明日の天気を予測しようとするようなものだと主張しています。それでは、押し寄せてくる新しい嵐の雲を見逃してしまうのです。

「単純な数学」の罠

もう一つの罠も、研究者によって暴かれました。ある一日の変更回数を調べ、その数字に30を掛けて（一ヶ月の変更数を予想するために）計算すると、全く的外れな答えになるという罠です。

• 単純な推測： もし毎日1.5%のサーバーが変更を行うなら、30日目には約**36%**のサーバーが変更されていると考えるかもしれません。
• 現実： 実際に測定してみると、30日目までに変更されていたのはわずか**12%**のサーバーでした。

なぜ違いが出るのでしょうか？ 単純な数学では、すべての変更が「異なる」サーバーで行われると仮定しています。しかし現実には、同じ少数のサーバーが何度も繰り返し変更を行っています。これは、一人の人が一日に10回シャツを着替えるようなものです。着替えられたシャツの数を数えても、それは10人の人間が着替えたことにはなりません。説明文の「棚持ち（シェルフライフ）」は、単純な数学が示唆するよりもずっと長いのですが、特定のセキュリティ判定の「棚持ち」は、テキストが消えたり現れたりするため非常にトリッキーなのです。

真の解決策：履歴ではなく「指紋」をチェックせよ

予測ができないのであれば、どのようにして図書館の安全を守ればよいのでしょうか？ 研究者は、予測よりもはるかに優れた、シンプルな2段階のルールを提案しています。

1. 指紋ルール（コンテンツ・バインディング）： 誰が変更するかを予測するのではなく、説明文の「指紋（デジタルハッシュ）」をチェックします。指紋がわずかでも変われば、そのセキュリティチェックは即座に無効となります。誰が変えたかを知る必要はありません。「テキストが変わった」という事実を知るだけでよいのです。これにより、自動的に1日あたり約20件の変更を捕捉できます。
2. 一斉調査（スイープ）： 新規サーバーや変更頻度の低いサーバーに対しては、毎週または毎月、図書館全体の一斉調査を行います。

このアプローチは、次にどの泥棒が襲ってくるかを予測しようとする警備員とは異なります。代わりに、本の表紙が入れ替えられた瞬間にアラームが鳴るスキャナーを持ち、さらに週に一度は通路を巡回して、新しい本が紛れ込んでいないかを確認する警備員のようなものです。

隠れた不具合：「生まれながらの陳腐化」

最後に、研究者は自分たちのセキュリティスキャナーの裏側を覗いてみました。そこで、巧妙な問題を発見しました。スキャナーが説明文をチェックしているとき、すでに図書館側で更新されているにもかかわらず、スキャナーがそれに気づかないことがあったのです。これは、シェフがスープを変えてしまった後に、警備員が10分前のメニューを読んでいるような状態です。彼らが見つけた「陳腐化した（stale）」判定の約半分は、スキャナが仕事を始める前から、すでに古いデータを見ていたことによるものでした。この「ラグ（遅延）」により、一部の判定は、時間が経過して古くなったからではなく、誕生した瞬間からすでに間違っていたのです。

まとめ

ここでの主な教訓は、図書館が混沌としているということではありません。図書館は**「集中している」**ということです。ほとんどのものは変化しませんが、一部のものが激しく変化し、そして新しいものが最も変化するのです。過去を見て未来を予測しようとする試みは、新しい参入者を見逃すため、行き止まりの戦略です。安全を確保するための最善策は、水晶玉を作ることではなく、テキストが変わったことを即座に検知するシステムを構築し、新しいものに対して定期的にチェックを行う計画を持つことです。これは、デジタル世界において「一度チェックすれば十分」ということは決してなく、単に履歴を見るのではなく、常に「テキスト」に目を光らせておく必要があるということを教えてくれます。