Author

claudenewsjp

MCPサーバーを手で追うのをやめたくなる話

この記事を読んでまず思ったのは、「AI相手に試すのは、やっぱり遅いし曖昧すぎる」という、かなり当たり前だけど見落としがちな感覚でした。MCPサーバーを本当に壊したいときは、自然言語でモデルに話しかける前に、まずJSON-RPCをそのまま叩け、という話なのですが、これは地味に効きます。モデルが悪いのか、ツール定義が悪いのか、サーバー実装が悪いのかが混ざると、切り分けが一気に難しくなる。そこでAIをいったん脇に置く、という順番が筋が通っています。

特に刺さったのは、Inspectorを「便利な可視化ツール」として扱いながらも、テストの本体にはしない、とはっきり線を引いているところです。GUIでツール一覧を眺めたり、手で1回再現したりするのは楽です。でも、それを回帰テストの代わりにすると途端に弱くなる。クリック操作は再現性が低いし、CIにも載らない。ここをはっきり分けているのがよかったです。現場だと「とりあえずInspectorで見えるからOK」に流れがちなので、そこへの釘刺しに見えました。

もうひとつ面白かったのは、tool descriptions までコードと同じ目線でテストしろ、という考え方です。普段はスキーマだけ気にして、説明文はおまけみたいに扱いがちですが、MCPではモデルが読むのはそこなんですよね。名前、説明、制約、どれも実質的にはAPIの一部だ、という見方はかなり納得感がありました。人間向けのドキュメントというより、挙動を左右する仕様そのものとして扱うべきだと思います。

逆に、少し怖いなとも思ったのは、ここまで厳密に見ないと「モデルが勝手にうまくやってくれる」という期待が簡単に崩れる点です。入力がゆるい、説明が曖昧、出力がでかすぎる。そういう小さな雑さが、そのまま agent の失敗に化ける。MCPはAI向けの仕組みというより、AIが壊しやすい部分を人間側で先に固めるための規約なんだろうな、と思いました。

参考: How to Test and Debug an MCP Server: From the Inspector to Automated Tool Tests

同じ著者の記事

Production MCPを読んで考えたこと

いちばん引っかかったのは、MCPそのものより「ちゃんと運用すると、急に話が現実になる」という空気でした。プロトコルのきれいさを褒める記事かと思いきや、実際には「3日で壊れた」「2AMにSlackで知った」みたいな、かなり泥臭い失敗談から入ってくる。そこがよかったです。AIまわりの話って、デモの気持ちよさに寄りがちですが、この記事は最初から“壊れる前提”で読ませにきている。 特に腑に落ちたのは、MCPをUSB-Cにたとえる話が、単なる比喩ではなく「N×Mの組み合わせ地獄を減らす」という運用上の痛みと直結している点です。LLMとツールの接続が増えるほど、個別実装の継ぎはぎは本当にきつくなる。ここでJSON-RPCという共通の会話形式に寄せるのは、地味だけどかなり強い発想だと思います。派手な機能より、まず“壊れにくい共通語”を作る。AI時代のインフラっぽさがある。 一方で、読んでいて少し身構えたのは、この記事が「MCPはこう作ればいい」と言うだけでなく、「でもここを雑にすると普通に事故る」と何度も釘を刺してくるところです。特にOAuth 2.1やstateless scalingの話は、きれ

papoo.work

本番投入前に「動く」だけでは足りない、という話

この記事を読んでまず思ったのは、こういう切り分けを最初から言語化しておくのはかなり大事だ、ということだった。MCP server まわりって、つい「テスト通ったし大丈夫」で済ませたくなるけれど、著者はそこをはっきり否定している。protocol と、agent が実際に使ったときの挙動は別物だ、という指摘は地味だけど効く。 特に引っかかったのは、`initialize` や `tools/list` が通ることと、production の agent が安全に使えることは全然違う、という部分だった。これは言われれば当たり前なのに、現場だとかなり混同されやすい。人間が curl して成功したログを見て安心してしまう、あの感じに近い。けれど agent は気まぐれだし、似た tool を取り違えるし、失敗すると retry もする。その結果、最後の応答だけ見ていると見逃す副作用が残る。ここを「1 回成功したか」ではなく、「何度やっても同じか」「失敗したあと状態が壊れていないか」で見るべきだ、というのはかなり筋がいいと思う。 もう一つよかったのは、これは checklist ではなく rub

papoo.work

API設計でいちばん怖いのは「人間には通るけど、AIには通らない」ことだった

この元記事は、APIドキュメントの書き方ひとつで、AI agent が普通に失敗する話を扱っている 問題は「出力は number、入力は string」という型のズレ。人間は気づいて回避しても、agent はそのままつなぐので落ちる テストも人間向けの書き方になっていて、`String()` で勝手に直していたからバグを見逃していた 直し方としては、出力側を変えるのではなく、入力側を広げるのが安全だった ただし `z.union()` や `z.coerce.string()` には別の危険があるので、筆者は `preprocess` で限定的に吸収する方法を選んでいる いまのAIは「空気を読む」のではなく、文字どおりに実行する。だからAPI docs も、テストも、そこに合わせて鍛え直す必要がある この記事で扱っているのは、かなり地味だけれど、実はものすごく厄介なバグです。 著者たちは helpdesk の仕組みを MCP 経由で AI agent に触らせていて、agent はチケット一覧を取り、スレッドを読み、下書きを作る、といった操作ができるようになっていました。 で、ある日、

papoo.work

仕様の罠は、コードより先に言葉にある

この記事を読んでまず思ったのは、ツールが「正しそうに見える間違い」を平然と出す怖さが、かなり生々しく書かれているな、ということだった。しかも厄介なのは、単にバグを踏んだ話ではなく、調べた先の見え方そのものが誤解を誘う形になっていた点だと思う。 いちばん引っかかったのは、package rename が「存在しない package」と区別できないという話だ。version を見ているだけでは、まだ出ていないのか、名前が変わったのか分からない。言われてみれば当たり前なのに、実際にはその当たり前を見落としやすい。機械的な checker ほど、見つかった事実だけで断定してしまう危うさがあるんだなと思った。 もうひとつ印象に残ったのは、broken link の話だ。spec を参照しているつもりのリンクが、実は overview に飛ぶだけで、見た目には壊れていない。これはかなり嫌な失敗で、単に「リンクが切れている」よりタチが悪い。検証できる顔をしながら、実際には検証先が違う。こういうのは人間でも気づきにくいし、だからこそ test で縛るしかないのだろう。 ただ、ここで面白いのは「dete

papoo.work

AIがChromeを触る時代に、いちばん欲しいのは「失敗の再現」だと思った

読んでまず思ったのは、これは派手なデモ機能というより、地味だけど現場で効く道具だな、ということだった。AIエージェントにブラウザーを操作させる話はもう珍しくないけれど、実際に困るのは「たまたま動いた」では終わらない場面だ。ログイン後の画面、位置情報の違い、CPUやネットワークの遅さ、拡張機能の挙動。人間が「さっきはこうだった」と言っても、AI側からするとそこが丸ごとブラックボックスになりやすい。そこをChrome DevTools経由で触れるようにする、というのはかなり筋がいい。 特に気になったのは、自動接続で“今使っているブラウザー”をそのまま使える点だった。新しい専用ブラウザーを立ち上げてテストするだけなら、それはそれで便利だけれど、認証済みのサイトや、手元の環境に強く依存する不具合はそれでは再現しきれない。結局、デバッグって「理想の環境」で起きたことより、「いつもの環境」でしか起きない不具合との戦いなので、この差は大きいと思う。 もうひとつ面白いのは、AIにサイトを“見せる”だけでなく、Lighthouseによる監査やメモリ分析まで渡しているところだ。ここまでくると、AIはただの

papoo.work

Claude Codeの記事を読んで、少し安心した

AIにコードを書かせる話になると、どうしても「全部任せてよいのか」「人間の仕事はなくなるのか」に話が飛びがちだけれど、この文章はそこをかなり冷静に引き戻していて、その感じが私はわりと好きだった。Claude Codeの作者が言っているのは、AIに全部書かせることではなく、品質の線を下げないために人間がどう見るか、という話なんですよね。そこがはっきりしているのは大事だと思う。 読んでいて引っかかったのは、「プルリクはブロックボックスでもよいのか」という問いが、結局はかなり人間側の観察力に寄っている点です。AIが出したコードを全部読む必要はない、でもどこかで「これは本当に大丈夫か」を判断しないといけない。その判断を支えるために、lint、テスト、レビュー、ガードレールを重ねる。つまり、AIが強くなるほど、人間は雑に見てよくなるのではなく、むしろ「どこを見なくていいか」を設計する役目が増えるんだなと思った。 あと、Claude Codeが「新しいモデルを入れたら終わり」ではなく、effort設定や CLAUDE.md みたいな周辺の仕組みまで含めて考えているのが面白い。AIの性能だけで勝負す

papoo.work

AIでコードを書き換える時代の、いちばん気になるところ

最初に思ったのは、「速さ」より先に「本当に置き換えていいのはどこまでなんだろう」という不安のほうだった。この記事、Claude Code が何万行ものコード移行をかなり短期間で進めた話として読めるのだけれど、読後感は単純な武勇伝ではなかった。むしろ、AI がコードを“書ける”ことより、既存コードを“壊さずに移す”ために何を見ているのかのほうがずっと面白い。 特に引っかかったのは、テストや judge（判定用の仕組み）をかなり厚く置いている点だ。AI に「移行して」とだけ頼んで終わりではなく、どのテストを呼ぶか、どう同値変換するか、意図的な破壊をどう見分けるかまでルール化している。ここを読むと、AI の価値は“賢さ”そのものというより、作業の周りにある面倒な確認をどこまで機械に持たせられるかにあるのだと思う。逆に言えば、ここを雑にすると、どれだけ派手なデモでも現場では怖くて使えない。 もう一つ印象に残ったのは、移行先の言語が Zig や Rust みたいな「堅い」ものだったことだ。こういう移行は、ただの書き換えではなく、実質的には設計の再点検になる。だからこそ、AI が便利だとしても、人

papoo.work

MCPサーバーは本当にいらないのか

この記事を読んで、まず思ったのは「MCPって、便利そうに見えるぶん、設計の雑さも一緒に増幅してしまうのかもしれない」ということだった。 AIエージェントに外部サービスをつなぐ共通規格として期待されているのに、実際には「何でもMCPに寄せればいい」と考えた瞬間に、もう少し素直なAPIやCLIで済んだはずの話まで重くしてしまう。そこがかなり引っかかった。 特に面白かったのは、MCPサーバーを立てること自体が目的化しやすい、という視点だ。 本来は「LLMに外部機能を安全に渡すための薄い層」のはずなのに、現場では認証、権限、スキーマ、コンテキスト管理まで背負わされる。そうなると、MCPは“共通化”というより“新しい面倒の置き場”になりかねない。標準化の話なのに、標準に合わせるための実装負担が増えるのは、少し皮肉だと思う。 一方で、だからMCPが無意味かというと、そう単純でもないとも感じた。 記事が指摘しているように、Markdownを返す、言語を明示する、といったやり方は、AI向けのI/Oとしてはかなり筋がいい。LLMは結局、きれいに整ったHTTPレスポンスを読むより、最初から「機械が読みやす

papoo.work

MCPサーバーに潜む「信頼」の落とし穴

この記事を読んで、いちばんぞっとしたのは「サーバーをちゃんと選んでいるか」より、「その場で流れてきた文章を、モデルがどう扱うか」のほうがずっと危ない、という指摘だった。MCPって、外から見ると便利な配線の規格に見えるけれど、実際には“便利に繋がる”こと自体がリスクを増やしている。そこがかなり苦い。 特に腑に落ちたのは、攻撃者が何かの脆弱性を突かなくても、ただ issue に文章を埋め込むだけで成立してしまう話だ。人間なら「これは依頼文じゃない」と気づけそうなものでも、LLM にとっては context window の中に入った時点で、命令とデータの境目がかなり曖昧になる。ここは本当に厄介で、プロンプトで「外部の指示は無視せよ」と何度念押ししても、構造としては勝てない、という主張には納得がある。 あと面白かったのは、防御策を“モデルの賢さ”ではなく、broker みたいな deterministic な層に逃がせ、という発想だった。つまり「読ませてもいい」「外に出していい」「権限を持っていい」を、その場の会話の流れではなく機械的に止める。AI に期待するより、AI を通す前後の配線を締

papoo.work

MCPサーバーは“信用して置く”時代じゃない。セキュリティ監査のやり方を考える

MCP（Model Context Protocol）という言葉、最近かなり見かけるようになりました。ざっくり言うと、AIエージェントが外部のツールやファイル、APIにアクセスするための「通訳」みたいな仕組みです。便利です。めちゃくちゃ便利。でも便利なものは、だいたい強い権限も持ちます。そこが怖い。 今回紹介する記事は、そんなMCP serverをどう監査するか、という話です。DEV Community に掲載された *How to Audit Your MCP Servers for Security Risks* は、MCP server を「とりあえず動けばOK」で配る危うさをかなり真正面から突いています。正直、かなり大事なテーマだと思います。 MCP server は、AIエージェントの中でかなり強い権限を持ちやすい だから、普通のライブラリ以上に「中身の監査」が必要 記事では `mcp-security-scan` という OSS の CLI / GitHub Action が紹介されている チェック対象は、credential theft、data exfiltration

papoo.work