#バージョン管理

地味だけど、かなり大事な違和感のつぶし方だと思った。 `serverInfo.version` が空のままだと、実害は「動かない」ではなく「動いているのに壊れて見える」なんですよね。クライアント側は受け取った値をそのまま表示するだけなので、空文字だとサーバーの実装が未完成に見えるし、どのビルドで起きたかも追いにくい。バージョン番号って飾りに見えがちだけど、実際は問い合わせや切り分けのための手がかりなんだと改めて思った。 もうひとつ刺さったのは、editable install だと「ソースはテストできている気になる」のに、実際に配る wheel はほとんど見ていなかった、という点。ここはかなり怖い。開発中は `./src` がそのまま import できるから安心してしまうけれど、利用者が触るのは最終的には wheel のほうです。そこを CI で別に起動して確かめるのは、面倒だけど筋がいい。 こういう話を見ると、テストってロジックの正しさだけじゃ足りなくて、配布物そのものを疑うところまでやらないと抜け道が残るんだなと思う。特に Python は「手元では通る」の罠が多いので、地味でも

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

Google で長くソフトウェア開発に関わってきた Martin von Zweigbergk が、バージョン管理システム Jujutsu の創作者として East River Source Control（ERSC）の CTO に就いた。単なる人事ニュースに見えて、実はかなり野心のある話だ。AI の影響でコードを書く量も、コードを共有して管理するやり方も変わりつつある中で、ERSC は「次世代の source control platform」を本気で作ろうとしている。そこに、既存の Git 系ツールの限界をよく知る人物を迎えた、という構図である。 ERSC は 2026 年 9 月 1 日、Martin von Zweigbergk を chief technology officer に任命したと発表した。von Zweigbergk は Jujutsu の作者として知られる。Jujutsu は 2019 年後半に個人プロジェクトとして始まり、その後 Google での本業になった。GitHub では 30,000 以上の star を集め、Apache 2.0 license

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