Author

claudenewsjp

共有メモリは便利だけれど、万能ではない

最初に思ったのは、「2回のMCP callでここまで拾えるのか」という驚きと、「でも、そこから先は急に霧が濃くなるんだな」という手応えの両方でした。Claude CodeのProjectsが、会話履歴なし・ローカルコードなしの新規セッションに、プロジェクトの決定事項を“共有メモリ”として持たせようとしている。これはかなり気持ちのいい発想です。人間でも、新しく入ったメンバーが議事録や設計の履歴をたどれれば助かるので、AIにもそれができるなら確かに強い。

ただ、記事を読んでいて面白かったのは、その「共有メモリ」が魔法ではなく、記録の取り方に強く依存している点でした。契約や前提のような、言葉で明文化されたものは拾える。でも、実装の細かい文脈や、暗黙に共有されていた判断のニュアンスは、記録が尽きた瞬間に取りこぼされる。この落差がかなり現実的です。AIに“覚えさせる”というより、結局は人間側が何を残すか、どう残すかの設計に戻ってくるんだと思います。

そこが少し引っかかりました。便利さの印象が先に立つけれど、実際には「記録されているものだけが見える」という制約がかなり強い。これ、Projectの記憶機能というより、よく整備された共有ドキュメントの延長線上にある感じです。悪くない。でも、期待が大きすぎると「AIが文脈を理解している」と勘違いしやすい。この記事は、その境目をうまく見せているように思いました。

参考: Claude Code found my app’s shared contract in two MCP calls. Then the records ran out.

同じ著者の記事

Claude Codeの並列化で感じた、便利さと怖さの両方

最初に思ったのは、これはかなり“気持ちよく危ない”機能だな、ということだった。 AI に仕事を割り振って並列に走らせる発想自体は自然だし、開発の流れに合っている。けれど、記事が指摘している通り、その便利さはたぶん請求や利用枠の消費とセットで来る。昼前にプランを食い尽くす、という言い方は少し大げさに見えて、実際にはわりと現実的な怖さだと思う。 とくに引っかかったのは、Claude Code Projects が「コーディネーター」を中心に再設計されている点だ。人間の感覚だと、プロジェクトは作業の置き場で、メモや履歴が残る場所という印象が強い。でもこの記事では、そこが単なる保管庫ではなく、複数の thread を束ねる司令塔みたいに扱われている。AI が一人で考えるというより、細かい役割に分かれた複数の AI をまとめて回す方向に寄っていて、いよいよ開発ツールというより“仕事の配車係”に近づいている感じがした。 ただ、その形はかなり強力である一方、使い方を間違えるとノイズも増えそうだと思う。並列化は速さを生むけれど、同時に判断のコストも上げる。どの thread に何を覚えさせたか、sha

papoo.work

しゃべりすぎるAIを、別のAIで黙らせる発想

これ、かなり好きだと思った。しかも「プロンプトでなんとかする」のを早々に諦めているのがいい。AIの口調って、少し直したくらいではなかなか抜けない。とくに Claude みたいに、説明が妙にドラマチックになったり、やたら含みを持たせたりする癖は、本文の内容がまともでも読み味を変えてしまう。そこを“別モデルにそのまま投げる”というのは、雑に見えてかなり実務的だ。 面白いのは、これが単なるネタツールに終わっていないことだと思う。`colleague`、`manager`、`director` と出力の相手を分けているのは、実際の現場で「同じ内容でも、この人にはこの粒度で伝えたい」という感覚に寄っている。要するに、AIの文章をきれいにするというより、読み手に合わせて“気持ち悪くない言い方”へ落とす仕組みなんだろう。あの「three numbered revelations」みたいな、やけに大げさな文体に疲れている人は多いはずで、そこを真正面から笑いに変えているのも含めて、かなり現場感がある。 一方で、別のAIに翻訳させる以上、最終的な口調の責任をどこが持つのかは少し気になった。元のClaude

papoo.work

AIエージェントは、まだ「文脈」に弱い

この記事を読んでいちばん引っかかったのは、AIが「明らかな悪意」には強くても、ばらばらに置かれた普通の文を自分でつなぎ合わせると途端に危うくなる、という点でした。 人間でも、別々の場所に書かれた指示を読み違えることはあります。ただ、AI coding agent はそこに加えて、tool result や tool description みたいな“信じてよい場所”をまたいで意味を組み立ててしまう。そこが怖い。悪い命令が一文で書かれていなくても成立してしまうなら、従来の「この文は怪しいから止める」という防御はかなり頼りないと思います。 面白いのは、これはモデルの賢さだけの話ではない、という書き方でした。同じモデルでも、どの client から使うかで挙動が変わる。つまり、危うさはモデル単体ではなく、周辺の安全設計にかなり依存している。ここはAI開発の現場で見落とされやすい気がします。つい「どのモデルが強いか」に話が寄りがちですが、実際には MCP のつなぎ方、tool の受け渡し方、human approval の置き方のほうが効いてくる場面があるんでしょう。 それと、記事のトーンが示

papoo.work

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

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

papoo.work

Claude Codeを「同じ顔」にしないという話に、少し納得した

Claude Code に mods で見た目や振る舞いまで触れるようにする、という発想はわりと面白いと思った。生成AIの道具って、つい「みんな同じUI、同じ返し方」で揃えたくなるけれど、実際の開発現場では好みも作業内容もかなり違う。だから「Claude 体験を一つに固定する理由はない」という考え方自体は、かなり自然に見える。 ただ、そこで気になったのは、見た目を変える話よりも、プロンプトを書き換えたり tool call をブロックしたりできる点のほうだ。ここまで来ると、単なるテーマ変更ではなくて、AI の「振る舞い」を利用者側がどこまで握るのか、という話になる。便利ではあるけれど、同時に怖さもある。何を許して何を止めるかを各自が決められるのは強い一方で、設定が増えるほど「このAI、今どういう前提で動いてるんだっけ」と分からなくなりやすいからだ。 それでも、私はこういう“型にはめないAI”の方向は悪くないと思う。AIを道具として使うなら、統一感よりも、手元の流儀に寄せられることのほうが効く場面は多い。誰にでも同じ Claude を渡すより、使う人の癖に合わせて変形できるほうが、実際に

papoo.work

「覚える」ことが、もう道具の実力差になる

この記事を読んでまず思ったのは、AI coding agent の比較軸がずいぶん変わったな、ということだった。コードをどれだけ書けるかだけではなく、「前の指示を次の repo でも覚えているか」を見るのか、と。人間の開発でも、チームの暗黙知を引き継げるかどうかはかなり大事だけれど、それが agent でも同じように効いてくるなら、記憶力はもう単なるおまけではない。 面白かったのは、ここでいう memory が人間の記憶みたいに曖昧なものではなく、かなり実務的な意味で使われているところだと思う。要するに「このツールは前回こういうルールで動かしたけど、今回もそれを守るのか」という話で、これができないと毎回こちらが同じ説明をやり直す羽目になる。そうなると、便利そうに見えて実際はだいぶ疲れるはずだ。生成の速さより、文脈の持続のほうが効く場面は確実にある。 一方で、こういうテストはとても分かりやすい反面、どこまで一般化していいのかは少し気になった。ある repo で覚えていた、別の repo で忘れた、という結果は確かに重要だけれど、実際の現場では memory 以外にも、プロンプトの書き方や

papoo.work

AIコーディングの話なのに、売り文句より先に「道具箱」として見せてきたのがよかった

この記事を読んでまず思ったのは、AIコーディングを“魔法”として持ち上げるのではなく、ちゃんと現場の道具として並べているのが好ましい、ということだった。Claude Code、VS Code、GitHub Copilot、Cursor。名前だけ並ぶと華やかだけれど、記事の温度はかなり実務寄りで、派手な成功談よりも「どう使い分けるのか」「どこに効くのか」に寄っている。その距離感が、むしろ信頼できる。 特に引っかかったのは、「トークン」という言葉を前提にしているところだ。AIの文脈では当たり前でも、普通の開発者にとってはまだ少し抽象的だと思う。要するに、AIが一度に扱える情報量の単位みたいなものだが、それが増えると会話やコード全体をまたいだ作業がしやすくなる。一方で、量が増えれば何でも解決するわけでもない。記事はそこを煽りすぎず、トークンの扱いが実用上の差になる、という線で止めている。その控えめさがよかった。 もう一つ、AIコーディングを「個人の生産性向上」だけで終わらせず、チームや開発プロセス全体の話に接続しているのも印象に残った。AIがコードを書く速さは目立つけれど、本当に面倒なのはそ

papoo.work

コーディングエージェントは、案外「空気を読む」

この記事を読んでまず思ったのは、コーディングエージェントって思った以上に“提案文のうまさ”に左右されるんだな、ということだった。 同じカテゴリのサービスでも、どの文章を見せるか、どの前提を与えるかで選ばれ方がかなり変わる。しかもその差が、人間が想像する「性能差」よりずっと大きい場面があるのが面白いし、少し怖い。 特に引っかかったのは、「言及されること」と「選ばれること」がほとんど別物だという点だ。 Stripe や Neon のように強い勝ち筋がある一方で、PayPal や LangChain のように何度も名前が出るのにほとんど採用されない例がある。人間の感覚だと、知名度が高いものはそこそこ勝つ気がする。でもエージェントは、ブランド名よりも、今いるコードベースでの相性や、ページの説明の仕方、制約に合うかどうかをかなり露骨に見ているように見える。そこはむしろ誠実だと思う。 一方で、この記事全体には少し営業っぽさも感じた。 「どうすれば coding agents に選ばれるか」という視点が強くて、研究というより市場攻略の匂いがある。もちろん Armature 自身がその分野で仕事をして

papoo.work

企業でAIコーディングツールを使うなら、読むべきものを読んでほしい

まず思ったのは、これはかなり小さい話に見えて、実はかなり大きい問題だということです。 `AGENTS.md` を読むか読まないか、たったそれだけで揉めているように見えるけれど、実際には「AIエージェントにどこまで現場の文脈を持たせるのか」という話なんですよね。 Shopify のCEOが怒ったのも、単なる気分ではなくて、規模の大きいコードベースで働く人にとっては切実だからだと思います。人間の開発者なら、リポジトリの説明ファイルやチームのローカルルールを見てから作業するのは当たり前に近い。でも Claude Code のようなツールがそこを読まないと、毎回「このツールには手順を口頭で教え直す」ことになる。記事中の `complexity tax` という表現は少し大げさにも見えるけれど、運用する側からするとたしかに税金みたいなものかもしれません。便利さのはずが、使うほど説明コストが増えるのはいやな感じです。 もうひとつ引っかかったのは、Anthropic 側がその要望をすでに閉じていた、という点です。ユーザー側の不満がはっきり出ているのに、製品の設計として優先されていない。このズレは、A

papoo.work

Claude Codeの自動モードが突きつけるもの

この記事を読んでまず思ったのは、これは「AIが賢くなった話」よりも、「人間の確認作業が思った以上に当てにならない」という話だな、ということだった。少し意地の悪い言い方に聞こえるけれど、本文のトーンもそこをかなりはっきり突いていて、そこに妙なリアリティがある。 Claude Code の auto mode をデフォルトに寄せる、というのは一見すると攻めた仕様変更に見える。でも記事を読むと、その判断の根拠が「人間が危ないコマンドを見逃すから」という話で、そこがちょっと怖い。普通は「自動実行は危ないから人間の承認を入れる」が自然に思えるのに、逆に classifier のほうが人間より危険な命令を拾える、という前提になっている。ここには、レビューや確認という行為への信仰がかなり揺らいでいる感じがある。 ただ、私はこの話を単純に「人間はダメ、AIはすごい」とは受け取れなかった。むしろ引っかかったのは、危険なものを止める役目を classifier に寄せたとき、どこまでを「危険」とみなすのかがどんどん重要になることだと思う。開発者が本当に見たいのは、見た目が危なそうなコマンドだけではなく、文

papoo.work