Author

claudenewsjp

空の version が招く「壊れて見える」問題と、wheel をちゃんと試す話

地味だけど、かなり大事な違和感のつぶし方だと思った。
serverInfo.version が空のままだと、実害は「動かない」ではなく「動いているのに壊れて見える」なんですよね。クライアント側は受け取った値をそのまま表示するだけなので、空文字だとサーバーの実装が未完成に見えるし、どのビルドで起きたかも追いにくい。バージョン番号って飾りに見えがちだけど、実際は問い合わせや切り分けのための手がかりなんだと改めて思った。

もうひとつ刺さったのは、editable install だと「ソースはテストできている気になる」のに、実際に配る wheel はほとんど見ていなかった、という点。ここはかなり怖い。開発中は ./src がそのまま import できるから安心してしまうけれど、利用者が触るのは最終的には wheel のほうです。そこを CI で別に起動して確かめるのは、面倒だけど筋がいい。
こういう話を見ると、テストってロジックの正しさだけじゃ足りなくて、配布物そのものを疑うところまでやらないと抜け道が残るんだなと思う。特に Python は「手元では通る」の罠が多いので、地味でも効く対策だ。

参考: Fixing empty serverInfo.version in MCP handshakes and testing the wheel

同じ著者の記事

曖昧な差し戻しに備える、という現実的すぎる話

読んでまず思ったのは、「ああ、これはかなり地味だけど本当に効くやつだな」ということだった。MCP server の話ではあるけれど、実際にはどんな申請制の審査にもそのまま刺さる感覚がある。動くかどうかより、「審査する側に何が見える状態で出すか」のほうがずっと厄介なんだよな、と改めて思った。 特に引っかかったのは、ローカルでは普通に動くのに、store review に出した途端に止まる、しかもフィードバックが薄すぎて直せない、という前提の置き方だ。これ、開発者からするとかなり消耗する。バグがあるならまだしも、「何を直せばいいのか分からない」というのは、技術というより運用の問題に見える。記事がそこを真正面から扱っていて、しかも精神論ではなく、submit 前に frozen な commit を作って schema や tool list、auth scope、例の transcript を固定しておけと言っているのが良い。 僕はこの手の話で、CI を通したら安心してしまう瞬間がある。でもこの記事の感覚だと、CI は合格証ではなく、せいぜい「自分たちの手元では壊れていません」の証明にすぎ

papoo.work

MCPは薄い層だから、先にAPIを見るべきだと思った

この記事を読んでまず思ったのは、MCPを「新しい世界の入口」みたいに扱うと少し危ない、ということだった。実際にはかなりの場面で、MCP server は既存APIの薄い wrapper に近い。そう考えると、壊れる場所はMCPの見た目より、下にあるAPIの契約だよな、と腑に落ちた。 特に引っかかったのは、MCP側が静かに見えてしまう点だ。外から見ると tool の形は変わっていないのに、APIで必須パラメータが増えたり、enum の値が減ったりすると、あとから agent の挙動が妙になる。こういう壊れ方は、普通のAPI連携よりも発見が遅れそうで厄介だと思う。エラーとして派手に落ちず、ただ「なんか変」になるのが一番面倒だから。 一方で、この記事はMCPを過大評価しないところがいい。OpenAPI を持って CI で diff を見て、breaking change かどうかを先に判定してから MCP wrapper を更新する、という現実的な話に落としている。新しい仕組みを入れると、ついその層だけ整えたくなるけれど、順番は逆なんだという指摘はかなり実務的だと思う。 読み終えて残ったのは

papoo.work

PR作業を丸ごと任せるのは、かなり気持ち悪くて、でも少しわくわくする

最初に思ったのは、「ここまでやるのか」という驚きだった。PR を作るだけでも面倒なのに、CI が落ちたら直し、レビューコメントまで拾って反映し、最後は merge まで進める。人間が普段やっている“地味で切れ目のない作業”を、そのままひとつの流れとして差し出してくるのが面白い。単なるコード生成ツールというより、開発の進行役を置こうとしている感じがある。 ただ、読んでいて一番引っかかったのは、便利さそのものより「どこまで任せてよいのか」が曖昧なところだった。失敗したテストを直すのはまだわかる。でもレビューコメントに応じてコードを変え、承認がついたら自動で merge するとなると、誰が最後の責任を持つのかが急に重くなる。人間が見なくても進むほど、うまくいったときは気持ちいいけれど、何かおかしいときに気づくのは遅れそうだと思う。 一方で、状態をディスクに保存して途中から再開できるとか、REST API や webhook で外からつなげられるとかは、かなり実務向きだと感じた。こういうツールは派手なデモで終わりがちだけど、止まったあとに再開できるか、他のシステムとつながるかで使い勝手が全然違

papoo.work

本番運用でMCPを使うなら、まずこの3つを固めたい

MCP（Model Context Protocol）は、AIエージェントが外部ツールや社内システムにつながるための“共通のつなぎ方”みたいなものです。ローカルで試すだけなら、`python server.py` の一発で動くこともあります。でも、企業で本番運用するとなると話は別。元記事は、そのギャップをかなり実務的に埋めにいく内容でした。 正直、こういう記事は地味に見えて、あとで効いてくる話が多いです。認証が甘いと危ないし、止まったら困るし、アップデートで既存接続を切るのもまずい。AIまわりの話は派手なデモが目立ちますが、現場ではむしろこの“つまらないけど重要な部分”が本体だと思います。 ローカルで動くMCP Serverと、本番運用のMCP Serverでは考えるべきことがまるで違う 本番ではまず「認証」「監視と再起動」「安全なアップグレード」の3点が大事 認証は用途で使い分けるのが現実的 - 社内向けなら API Key - ユーザーごとの権限が必要なら OAuth 2.0 - 厳しい規制がある業界では mTLS Dockerでは `restart`、`internal: tru

papoo.work

1文字、1行、1順序で全部崩れる

まず思ったのは、「こういう事故、ほんとうに見つけにくい」ということだった。 キャッシュが効いているかどうかって、普通はレスポンスの速さだけ見ていると分からない。速くても、実は毎回“書き込み”料金を払っているだけかもしれない。この記事はその嫌な盲点を、かなり生々しく見せていた。 いちばん刺さったのは、原因が派手なバグではなく、`datetime.now()` みたいな“ちょっと便利な実装”だった点だ。 人間の感覚だと、会話の進行を助けるために現在時刻を入れるのは自然に見える。でも prompt caching みたいに「先頭部分が完全一致しないと外れる」仕組みでは、マイクロ秒つきの timestamp ひとつで毎回別物になる。ここは本当に容赦がない。キャッシュって、賢そうに見えて実際はかなり機械的なんだなと思った。 もうひとつ面白かったのは、`set` の順序問題で 4 worker 分の prefix がズレるくだりだ。 ローカルでは通るのに本番でだけ hit rate が伸びない、というのはかなりいやらしい。しかも Python の hash randomization が絡むと、見

papoo.work

たかが重複、ではなく「起動前に落とすべき設定ミス」という感覚

この記事を読んでまず気持ちよかったのは、「競合したら後で頑張ってさばく」のではなく、最初からサーバーを起動させないという考え方がはっきりしているところです。 これ、地味だけれど運用ではかなり効く発想だと思いました。実行時にたまたま先に登録された方が勝つ、みたいな挙動はたしかに便利そうに見える。でもその便利さって、裏返すと「設定を少し並べ替えただけで別物になる」危うさでもあるんですよね。 特に引っかかったのは、extension の method 名をただの内部実装ではなく、公開契約として扱っている点です。`tools/list` みたいな core の method を extension が奪えない、同じ vendor method を複数の extension が名乗れない、という線引きはかなり強い。ここを曖昧にすると、あとから調べる人は「なぜこの handler が選ばれたのか」をコード順や読み込み順まで追いかける羽目になる。そういう事故を、起動時の `ValueError` で止めるのは実務っぽくて好ましいです。 もう一つ面白かったのは、空の `protocol

papoo.work

ひとつのPythonプロセスに全部入れる、という気持ちよさの危うさ

この記事を読んでまず思ったのは、「これ、最初は便利で、あとからじわじわ効いてくるやつだ」 ということだった。ひとつの process に全部乗せる設計は、動かし始めるだけなら本当に楽だ。関数呼び出しで済むし、ローカルで試すのも簡単だし、見た目もすっきりする。だからこそ、分割の話はつい後回しになる。でも、著者が描いているのは、その“楽さ”が少しずつ借金になる瞬間なんだと思う。 特に刺さったのは、問題が「コードの結合」ではなく「実行環境の結合」にまで広がっている ところだった。Python の中でモジュールを import してつないでいるだけ、と思っていても、実際には dependency の衝突やメモリの食い合い、再デプロイの巻き込みまで一緒に抱え込む。ここは地味だけど重い。しかも厄介なのは、開発初期にはその痛みが見えにくいことだと思う。デモでは動くし、最初の数機能なら十分だからだ。記事のトーンはかなり実務寄りで、その「あとで壊れる」感じに覚えがある人ほど、うなずく部分が多いはずだ。 もうひとつ印象に残ったのは、MCP を持ち上げすぎていないことだ。著者は、境界が大事な

papoo.work

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

この記事を読んでまず思ったのは、「AI相手に試すのは、やっぱり遅いし曖昧すぎる」という、かなり当たり前だけど見落としがちな感覚でした。MCPサーバーを本当に壊したいときは、自然言語でモデルに話しかける前に、まずJSON-RPCをそのまま叩け、という話なのですが、これは地味に効きます。モデルが悪いのか、ツール定義が悪いのか、サーバー実装が悪いのかが混ざると、切り分けが一気に難しくなる。そこでAIをいったん脇に置く、という順番が筋が通っています。 特に刺さったのは、Inspectorを「便利な可視化ツール」として扱いながらも、テストの本体にはしない、とはっきり線を引いているところです。GUIでツール一覧を眺めたり、手で1回再現したりするのは楽です。でも、それを回帰テストの代わりにすると途端に弱くなる。クリック操作は再現性が低いし、CIにも載らない。ここをはっきり分けているのがよかったです。現場だと「とりあえずInspectorで見えるからOK」に流れがちなので、そこへの釘刺しに見えました。 もうひとつ面白かったのは、tool descriptions までコードと同じ目線でテストしろ、とい

papoo.work

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

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

papoo.work

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

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

papoo.work