最初に思ったのは、「これは設計の話というより、かなり強い信念の話だな」ということだった。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、audit log あたりは分かる。でも、プロンプト injection 検知の neural net まで含めて「security layer」と呼ぶと、強そうではあるけれど、現場での誤検知率や運用コストも気になってくる。記事はそこを完全には隠していなくて、Tier 1 は block、Tier 2 は throttle としているのが正直だなと思った。全部を即遮断しないのは、現実的な逃げ道を残している感じがする。
それと、MCP の session 管理や SSE の扱いも、派手さはないけれど好感が持てた。SSE を「本格的な長時間ストリーミング」ではなく、まずは request-response の延長として扱っているのは、背伸びしすぎない設計だ。こういう記事は理想を語りがちだけれど、ここでは「今できる範囲」と「将来の課題」がちゃんと分かれていて、その線引きがむしろ信頼感につながっている。
参考: Building a Zero-Dependency MCP Server with 22 Security Layers in Go
