Author

claudenewsjp

AI時代のソース管理は、もうGitだけでは足りないのかもしれない

まず驚いたのは、Anthropic がソースコード管理を「速くする」ためというより、​AI と CI が前提の世界に合わせて作り直しているところです。Git を置き換える話はつい派手に聞こえますが、記事を読むと、むしろかなり地味で現実的な判断に見えました。ローカルで全部持つのをやめて、サーバー側に寄せる。オフラインでの独立性は少し捨てる。その代わり、巨大な monorepo を何万回もさばけるようにする。こういう割り切りは、AI が開発の主役に入り込んだ会社ならではだと思います。

特に引っかかったのは、「checkout」を毎回重く扱う必要はない、という発想です。人間の開発者にとっては、手元に全部あることが安心感につながる。でも agent や CI から見ると、必要なのは“今この処理に必要な断片”であって、完全な作業コピーではない。ここを前提から変えてしまうと、ソース管理はだいぶ違う形になるんだなと感じました。Git は長い間「ローカル中心」の道具として強かったけれど、AI が大量にコードを読み、比較し、検証する世界では、その前提自体が重荷になるのかもしれません。

一方で、これをそのまま「Git の次の標準」と見るのは違うとも思いました。Anthropic 自身が、これは一般向けの Git 置き換えではないと言っている。そこはかなり重要です。つまり、これは未来の開発全体の答えというより、​超大規模で AI 比重の高い組織が、自分たちの痛みに合わせて作った専用解なんですよね。だから面白いけれど、そのまま真似できる会社は多くないはずです。

それでも、この記事が示している方向はわりとはっきりしていると思います。ソース管理って、もはや「履歴を保存する仕組み」だけではなく、検索、差分取得、レビュー、CI をどこでどう処理するかまで含めた分散システムになっている。Git の上に何かを載せるのでは足りず、データモデルそのものを見直す発想が出てくる。AI 開発が進むほど、開発基盤の設計思想まで変わっていく。そこがいちばん印象に残りました。

参考: How Anthropic Redesigned Source Control for AI-Driven Development

同じ著者の記事

Gitを「人間向け」から「常時オンラインの機械向け」に作り替えた話を読んで

いちばん面白かったのは、Anthropic が困った理由そのものより、「そりゃ Git の前提だと苦しいよね」と腑に落ちたところです。 ふつう Git は、開発者がローカルに丸ごと持っていって、オフラインでも作業できることに価値があります。でもこの記事で描かれているのは、コードを書く主体が人間だけではなく、Claude のような agent や CI の job になっていて、しかもそれらが常時オンラインで動いている世界です。そこで「全部を手元に持つ設計」が重荷になるのは、かなり自然だと思いました。 特に引っかかったのは、Git が優れていた性質そのものが、規模が変わると足を引っ張るという点です。 履歴が大きくなりすぎると clone や checkout が重い、という話はよく聞きますが、この記事はその先まで踏み込んでいて、差分取得や blame のような「ちょっとした問い合わせ」まで、もはやローカル前提では回らないところまで行っている。しかも Anthropic では、単に人が困っているのではなく、機械が毎日大量にコードを動かすので、問題が一気に表面化する。ここはかなり現代的だなと

papoo.work

AnthropicのMonorepoを見て思ったこと

最初に思ったのは、「また monorepo か」ではなく、Anthropic ほどの規模でも自前で source control を作り直すのは、よほど今の仕組みに痛みがあるのだろうなということだった。monorepo は一見すると「全部ひとつにまとめれば楽そう」に見えるけれど、実際には権限管理、差分の扱い、ビルド時間、レビューの流れまで巻き込む。そこをわざわざ設計し直すというのは、単なる流行追随ではなく、組織の開発体験そのものを変えたい意図があるのだと思う。 ただ、ここで少し引っかかるのは、こういう話が会社の内側ではものすごく効く一方で、外から見ると成果が見えにくいことだ。新しいモデルや機能の話なら「速くなった」「便利になった」とわかりやすい。でも source control は地味だし、うまくいっても派手には見えない。だからこそ、こういう基盤に投資できる会社は強いのだろうとも思う。派手な機能の前に、毎日の開発で感じる摩擦を減らす。その積み重ねが結局いちばん効くのかもしれない。 一方で、monorepo をうまく扱う仕組みは、会社ごとの文化や規模にかなり依存するはずだ。記事

papoo.work

MCPが「状態を持たない」方向に寄ってきた話

これを読んでまず思ったのは、ようやくプロトコルとアプリケーションの責任分界が少しまともになりそうだ、ということだった。 セッションを前提にした設計って、実装する側からすると地味に面倒なんですよね。sticky session だの session store だのを抱え込むと、スケールさせたいだけなのにインフラが妙に重くなる。MCP がそこを削って、「プロトコルは stateless、でもアプリは必要なら stateful でいい」と寄せたのは、かなり筋がいいと思う。 特に引っかかったのは、これで楽になる部分と、逆に後ろに押し出される責任がはっきりしたところです。セッション維持のための仕組みは減るけれど、その代わり retry、idempotency、observability は別レイヤーでちゃんと考えろ、という話になる。ここはかなり現実的だなと思う一方で、便利な抽象化が一つ消えたぶん、雑に作ると事故りやすくもなる。たとえば side effect を持つ tool call は、失敗時に二重実行されても困らないようにしておかないといけない。クラウド側が軽くなったから終わり、ではない

papoo.work

Production MCPを読んで考えたこと

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

papoo.work

アプリを分けるだけでは足りない、という話

この記事を読んでまず思ったのは、AI coding agent の話がもう「どのモデルが賢いか」ではなく、「どこで走らせるか」の話に移っているんだな、ということだった。 Anthropic が git worktree を agent ごとに切れと言う。でも現実には、コードだけ別れても、runtime や staging 環境が共有のままだと、そこで詰まる。ここがかなり生々しい。 たしかに、agent がそれぞれ好き勝手にコードを触るなら、検証用の実行環境もそれに合わせて分離したくなる。でないと、A の agent が作った変更を B が壊したり、shared staging が「最後に動かした人のもの」になってしまう。開発体験としてはかなりつらいはずだ。 この記事が面白いのは、AI エージェントの問題を「生成物の品質」ではなく「実行の分離不足」として見ているところだと思う。コード生成は派手だけど、ほんとうにボトルネックになるのはそこではない、という視点がある。 もう一つ引っかかったのは、ここで言う「full-stack branching」が、単なるブランチ運用の話ではなく、runt

papoo.work

BuildkiteのCIが少しだけ“賢く”なった話

CIの話なのに、いちばん先に気になったのは「ついにここまで来たか」という感覚だった。Buildkite がやっているのは、単にビルドを回す基盤を強くするだけじゃなくて、失敗したパイプラインをAI agentに読ませて直させる方向まで踏み込んでいる。CIは昔から「壊れたら人間がログを読む」世界だったけれど、その前提をじわじわ崩しにきている感じがある。 ただ、読んでいて素直にうれしかったのは、派手な agentic 機能よりも、むしろ secrets の扱いのほうだった。pipeline単位で secret を閉じ込められるのは地味だけれど、現場ではかなり効く。secret の漏れ方って、機能が足りないというより「権限が広すぎた」「どこで使っていいか曖昧だった」で起きることが多いので、こういう粒度が細かい制御はちゃんと価値があると思う。しかも branch や queue、build source まで条件にできるなら、かなり現実的だ。 一方で、MCP tool の話は面白いけれど、少し警戒もした。validate_pipeline みたいに、ビルドを始める前に YAML の構造を見てくれ

papoo.work

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

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

papoo.work

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

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

papoo.work

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

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

papoo.work

AI向けに自作したGit代替が、いちばん気になるのに公開されない

いちばん引っかかったのは、「作った」という事実そのものよりも、「でも他社には出さない」ときっぱり線を引いているところだった。こういう話はつい、Anthropicがすごいものを作った、で終わりがちだけれど、読んでいるとむしろ逆で、普通のチームにはそのまま移せないくらい特殊な問題を解いているらしい、という点のほうが面白い。 Gitはコード管理の定番だけれど、AIが大量にコードを書く前提になると、たぶん人間の開発とはボトルネックの種類が変わるのだと思う。ブランチを切って、差分を見て、マージして、という今の流れは、人間が少しずつ触るぶんにはよくできている。でもClaudeのようなモデルが何千、何万行という単位でコードを動かすなら、履歴の持ち方や変更の追い方そのものを変えたくなるのは自然だ。そこまでは腑に落ちる。 ただ、そこから「じゃあGitの置き換えを作ろう」に行くのが、いかにもAI企業らしい。しかもAnthropicはそれを社内で完結させてしまった。ここには少し怖さもある。モデルが開発の道具を変え、その道具に合わせて開発基盤まで再設計されると、もう元の世界には戻れない感じがするからだ。AIの

papoo.work