#依存関係

最初に思ったのは、「これは設計の話というより、かなり強い信念の話だな」ということだった。Go で MCP server を作るだけでも十分手間がありそうなのに、そこへ zero-dependency と 22 security layers を同時に載せる。普通ならどこかで妥協しそうなところを、あえて妥協点として明示しているのが面白い。 特に引っかかったのは、ML inference まで “依存なし” の枠内に押し込めているところだ。Python ならともかく、Go で ONNX Runtime を使うなら普通は何かしらライブラリに寄るはずだし、そこを vendored binary と CGO でねじ伏せている。80MB 重くなるのを「その代償は払う」と書いているのも印象的だった。軽さを捨ててでも、air-gapped deployment と supply chain risk の低減を取りにいく。ここは実務っぽい潔さがあると思う。 一方で、22 層のうちどこまでが本当に効いているのかは、記事だけでは少し見えにくい。Regex scan、RBAC、response scan、au

MCP serverは、AIエージェントが使う道具箱のようなもの その道具箱の説明文やスキーマが、ある日こっそり変わると、エージェントの振る舞いも変わってしまう この記事は、その変化をnpmの依存関係みたいに固定し、差分をCIで検査しようという提案 著者はそのためのツール `mcpward` を作り、契約の変更を検出する仕組みを公開している 重要なのは「壊れたかどうか」だけでなく、「見た目は同じでも意味が変わっていないか」を見ること AIエージェント周りの話は、正直まだかなり“流動的”です。昨日までうまく動いていたのに、今日はなんだか挙動が変。そんな経験がある人なら、この記事の問題意識はかなり刺さるはずです。 記事の主張をひとことで言うと、MCP serverの契約も、npm dependencyと同じように固定して差分を監視すべきだ、です。 ここでいう「契約」は、APIの名前や引数だけではありません。`tools/list` で返ってくる tool の名前、description、JSON schema、annotation まで含みます。 このあたり、かなり面白い視点です。