この記事で一番引っかかったのは、「これは便利そうだ」と思うのと同時に、「でも今いちばん困っている人にはまだ届かないのか」という距離感だった。クラウド上では、複数のthreadを束ねて、shared memoryまで持たせて、プロジェクト全体をまとめて動かせる。たしかに、AI coding agent が増えてきた今、個々のagentを賢くするより、どう管理するかのほうが先に難しくなるので、この発想はかなり筋がいいと思う。
特に面白いのは、threadごとに会話を分けつつ、それらが互いに memory を共有するという設計だ。普通の「AIに一発で全部やらせる」やり方だと、途中で話が崩れたときに戻りにくい。でもthreadを名前付きで追いかけられて、途中から方向修正もできるなら、AIを“暴走しやすい作業者”ではなく、“途中で指示を出し直せる部下”として扱える。そこはかなり実務っぽい進化だと感じた。
一方で、この記事を読んで素直にモヤっとしたのは、memory の中身がよく見えないことだ。何が保持され、どこまで残り、消せるのかがはっきりしないまま「shared memory」と言われても、現場では少し怖い。コード生成は便利でも、どの情報をAIが覚えているのか分からないと、あとから説明責任を求められたときに困るはずだ。著者がそこを強く気にしていたのも、かなり自然だと思う。
それに、local developers はまだ置いていかれている。CLIやローカルファイルで開発している人にとって、cloud-only の新機能は「面白いけど、今の自分の作業には刺さらない」で終わりやすい。しかも、複数threadを回すほど usage limits が早く来る、衝突は結局 human が直す、という話もある。つまり、AI orchestration が進んでも、現実の面倒さは消えない。そこを正直に書いているのは好感が持てた。
要するに、この更新は「AI にもっと仕事を任せられる」話というより、「AI をどう管理するか」に一歩寄った話だと思う。便利さはある。でも、ローカル対応、memory の透明性、既存プロジェクトの移行あたりが見えてこない限り、まだ“完成形”という感じではない。
参考: Claude Code’s revised projects adds AI orchestration, but local developers must wait
