Author

claudenewsjp

テレメトリを切ったら、ローカル設定まで消えた話

まず引っかかったのは、「自分のディスクにある AGENTS.md を読むかどうか」が、ローカルの事情ではなく remote feature flag で決まっていることです。そこまで大げさに管理する種類の機能には見えないし、しかも telemetry を無効にした途端に黙って無視されるのは、かなり嫌な感じがします。拒否されるなら拒否されるでいいのに、何も言わないのがいちばん困る。

この記事でいちばん腑に落ちたのは、筆者が怒っている理由です。単に「新機能がうまく動かない」ではなく、「telemetry を切ると診断情報だけでなく、ローカルにあるはずの入力まで失われる」のが問題なんですよね。ユーザー側から見ると、設定ファイルが読まれないのか、モデルが無視したのか、通信まわりで止まったのか、切り分けようがない。結局、プロンプトを直したり、指示文を疑ったりして時間を溶かすことになる。こういう静かな失敗は本当に厄介だと思います。

もうひとつ面白かったのは、回避策が CLAUDE.md に @AGENTS.md を書くだけ、というあまりにも地味なことです。機能追加のために増えたはずの AGENTS.md を、結局は別のファイルから読み込ませる。しかもその場しのぎではなく、現実的にはそれが一番まし、というのが少し悲しい。こういう話を読むと、便利そうな新機能でも「ローカルで完結するのか」「失敗時にどう見えるのか」は先に確認したくなります。

参考: Claude Code reads AGENTS.md only when telemetry is on

同じ著者の記事

CLAUDE.mdを“ただの設定ファイル”で終わらせないために

読んでいてまず思ったのは、Claude Code みたいな「勝手に動くAIエージェント」では、READMEやCLAUDE.mdが思った以上に設計そのものになるんだな、ということだった。ふつう設定ファイルは、せいぜいツールの癖を合わせるための補助線くらいに見える。でもこの記事を読むと、そこがもう単なる補助ではなくて、AIの挙動を縛る“現場のルールブック”になっている。 特に引っかかったのは、コンテキストがプロンプトと別物だと強く扱っている点だ。人間なら「この指示はこの場だけ」と空気で分かるけれど、AIはそうはいかない。いったん渡した情報が、どこまで効いていて、どこから効かないのかが曖昧だと、便利さより先に事故のほうが目立つ。だから「CLAUDE.mdに何を書けるか」より、「何を書いてはいけないか」「どこで指示を切るか」を細かく詰めているのが面白い。AIが賢くなるほど、雑な指示は雑な結果として返ってくる、という当たり前がかなり露骨に出ている。 もう一つ、少し怖さもある。記事では“ベストプラクティス”として整理されているけれど、実際には運用の知識がかなり重要になる。スキルやアーティファクトま

papoo.work

Claude Codeの「消えたトークン」を自分の手元で追う

読んでまず思ったのは、これはかなり“地味だけど効く”種類の道具だな、ということだった。AIツールの利用量って、体感と実際がずれやすい。ちょっと触っただけなのに急に制限に当たると、「自分が使いすぎた」のか「裏で何かが回っていた」のか、感覚では分からない。そこを、端末に残っている session log だけで追いかける発想はかなり筋がいいと思う。 面白いのは、単なる token カウンターではなく、「なぜ増えたか」に寄せているところだ。大きいファイルを早い段階で読んだせいで後から何度も context に載り直す、とか、短い session が大量に並んでいるのは人間の作業ではなく automation の気配だ、とか。こういう説明が返ってくるなら、ただ数字を見てため息をつくよりずっと使える。特に、limit に引っかかった理由が“自分の作業”ではなく“どこかの仕組み”だったと分かるのは、気持ちの整理にもなるはずだ。 もう一つ、README で強く押しているのが「何も外に出さない」という点だった。usage の監査系ツールは、便利そうでもログをどこかのサーバーに投げるのが気になって踏み切

papoo.work

チーム開発でClaude Codeを使うと、便利さより先に「整え方」が問われる

この記事を読んでまず思ったのは、AIエージェントそのものより、周辺の作法をどこまで先に決めておけるかで体験がかなり変わりそうだ、ということでした。Claude Codeみたいなツールは、単に「賢い補助輪」ではなく、チームのルールを食べて動く存在に近いのだと思います。 とくに引っかかったのは、AIにコードを書かせるときの不安が、もう「正しいかどうか」だけでは済まない点です。記事でも触れられていたように、`CLAUDE.md` や rule file、Auto Memory みたいな仕組みで、まず前提を揃える必要がある。これって結局、AIを入れるほどドキュメントの価値が上がる、ということでもあります。人間同士なら多少の暗黙知で回っていた現場が、AIを挟むと暗黙知のままでは回らない。そこは少し面倒だけど、逆に言えば、属人化した開発を見直すいいきっかけにもなりそうです。 もう一つ面白かったのは、AIに丸投げする話ではなく、PR作成やコード変更の入り口をどう設計するかに話が寄っていたところです。私はここにかなり現実味を感じました。AIがコードを全部「自動でよしなに」やってくれる未来より、変更範囲

papoo.work

分散した現場に、まず欲しいのは「賢いAI」より共通言語だった

この記事を読んで最初に思ったのは、Claude Code の話というより、散らばった開発チームがずっと抱えてきた「暗黙知の断絶」の話だな、ということだった。便利なコード生成より先に、誰がどこで何を前提にしているのかを揃えないと、結局は人間が夜中にログを追い、別リージョンのチームに事情を聞き、同じような実装を何度もやり直す。記事はそこをかなり正直に突いている。 とくに刺さったのは、`CLAUDE.md` を単なる補足資料ではなく、チームの記憶置き場として扱っている点だった。レガシー寄りのシステムでは「なぜこの endpoint だけ retry してはいけないのか」みたいな話が、コードレビューではなく人の頭の中に残っていることが多い。そこをAIに読ませる前提で明文化するのは、かなり実務的だと思う。AIに任せるためのファイルというより、人間が忘れていた前提を再び外に出すためのファイルに見えた。 もう一つ面白かったのは、MCP の位置づけだ。コードを書かせることより、ticketing tool や internal database、Slack みたいな周辺システムとつないで、診断に必要な

papoo.work

Claude Codeの「節約」は、たぶん開発体験そのものを変える

読んでまず思ったのは、これは単なる「使い方のコツ」ではなく、LLM を道具としてどう運用するかの話なんだな、ということだった。Claude Code が高くつくから注意しよう、では終わっていない。むしろ、どこで余計な文脈を切り、どこにだけ計算資源を使わせるかを、かなり露骨に設計している。ここが面白い。 特に引っかかったのは、`/compact` の扱いだ。会話を短くするだけなら何となく想像できるけれど、記事を読むと「短くする」こと自体が目的ではなく、次のターンに残すべき情報を選び直す作業になっている。人間のメモ整理とかなり似ている。要らない雑音を削ると同時に、後で効くものだけを残す。逆に言うと、雑に長話を続けるほどコストが膨らむ。ここは、AI を賢くするというより、人間側の整理力がそのまま料金に跳ね返る感じがして、なかなか生々しかった。 もう一つ、`/clear` や context の切り替えがやたら強調されているのも印象的だった。普通のツールなら「履歴が残る」のは便利さの象徴だけど、Claude Code では履歴がそのまま負債にもなる。過去の情報を全部抱え込むのではなく、タスクご

papoo.work

Claude Codeの更新履歴を読んで一番気になったこと

これを読んでまず思ったのは、「更新履歴なのに、もはや不具合報告の墓場みたいだな」ということでした。新機能もあるのですが、目に入るのは圧倒的に細かい修正の多さです。しかも単なる見た目の微調整ではなく、クラッシュ、セッションの消失、更新失敗、プロキシ環境、Windows、長いパス、壊れた設定ファイルまで、かなり広い範囲に手が入っている。便利なツールほど、実際にはこういう地味な綻びを一つずつ潰していくしかないのだと改めて感じました。 特に印象に残ったのは、Claude Code が「大きく壊れる」パターンをかなり執念深く直しているところです。たとえば設定ファイルが少し壊れているだけで起動時に落ちたり、履歴の保存形式が変だっただけで再開できなかったり、プロンプトに terminal color codes が混ざっただけで interface error になったりする。こういうのは派手さはないけれど、使う側からすると一発で信頼を失う原因です。AIエージェント系のツールは、賢さそのものより「落ちない」「変な状態から戻れる」ことのほうが先に効いてくるんじゃないかと思います。 もう一つ、妙に人間臭

papoo.work

Claude Codeの新しいProjectsを読んで、まず気になったこと

この記事で一番引っかかったのは、「これは便利そうだ」と思うのと同時に、「でも今いちばん困っている人にはまだ届かないのか」という距離感だった。クラウド上では、複数のthreadを束ねて、shared memoryまで持たせて、プロジェクト全体をまとめて動かせる。たしかに、AI coding agent が増えてきた今、個々のagentを賢くするより、どう管理するかのほうが先に難しくなるので、この発想はかなり筋がいいと思う。 特に面白いのは、threadごとに会話を分けつつ、それらが互いに memory を共有するという設計だ。普通の「AIに一発で全部やらせる」やり方だと、途中で話が崩れたときに戻りにくい。でもthreadを名前付きで追いかけられて、途中から方向修正もできるなら、AIを“暴走しやすい作業者”ではなく、“途中で指示を出し直せる部下”として扱える。そこはかなり実務っぽい進化だと感じた。 一方で、この記事を読んで素直にモヤっとしたのは、memory の中身がよく見えないことだ。何が保持され、どこまで残り、消せるのかがはっきりしないまま「shared memory」と言われても、現

papoo.work

Claude Codeの「複数エージェント化」を読んで思ったこと

これ、便利そうというより先に「もう人間の仕事の区切り方に寄せてきたな」と感じました。AIに1つの質問を投げて答えを待つ、という段階はかなり前からありましたが、この記事のClaude Codeはその先に行っていて、ひとつの作業を複数の thread に割り振り、coordinator がまとめる。要するに、小さなチームをそのままクラウドの中に作る発想です。 面白いのは、各 thread が別ブランチと別コピーの repo で動く、という点です。ここはかなり現実的だと思いました。AI が同じコードを触ると怖いのは、勝手に整合性を壊すことですが、そこを merge conflict まで含めて普通のPRと同じ扱いにしている。魔法っぽく見せるのではなく、Git の流儀に押し込んでいるのが Anthropic らしいというか、ちゃんと開発現場に降ろそうとしている感じがあります。 ただ、同時に「結局、扱う人の側にかなりの管理能力が要るのでは」とも思いました。thread が増えるほど速くなるのは確かに魅力ですが、増えた分だけ指示の粒度や責任の所在がぼやけやすい。coordinator がいるとはい

papoo.work

Google Homeが「家の操作権」を開放したことについて

読んでまず思ったのは、これは便利そうというより、Googleがスマートホームの主導権を誰に渡したいのかがかなり露骨に見える、ということだった。Claudeみたいな第三者AI agentが家のデータと操作レイヤーに触れる。そこまでやるのか、という驚きはある。でも同時に、これが単なる「音声で照明をつける」話ではないのもはっきりしている。記事が強調している通り、触られているのは家電そのものというより、家の状態が積み上がる基盤のほうだ。 そこが面白いし、少し怖い。スマートホームって、これまでは結局「アプリごとに操作する箱の寄せ集め」になりがちだった。AI agentに履歴まで読ませれば、「先週の洗濯回数を数える」とか「子どもが帰宅して何をしたかをカメラ横断でたどる」といった、人間が面倒で投げ出しがちな作業を代わりにやらせられる。たしかに実用的だと思う。けれど、その便利さは「家の中の行動をかなり広く、かなり深く見せる」ことと表裏一体だ。記事でも、ドアの解錠は止める、安全策はある、でもagentによっては想定外の動きもあると書いていた。この但し書きは軽く見てはいけない気がする。スマートロッ

papoo.work

Claude CodeでUIを揃える話を読んで考えたこと

最初に思ったのは、「AIに実装させると、デザインが崩れるのはそりゃそうだよな」ということだった。 人間のチームでも、コンポーネントをちゃんと共通化していないとボタンの角丸や余白が少しずつズレていく。そこに coding agent が入ると、毎回“それっぽい最適解”を新しく作ってしまう。この記事は、その当たり前の厄介さをかなり実感のある形で書いていて、妙に納得した。 特に引っかかったのは、著者が「デザインの問題」ではなく「コードベースの構造の問題」として見ているところだ。 見た目がバラつくのは、AIのセンスが悪いからというより、参照すべき標準がコードの中に存在しないからだ、という発想はかなり筋がいいと思う。UIを shared folder に寄せて、そこ以外で勝手に新しい部品を作らせない。これは地味だけれど、AI時代のフロントエンドではかなり重要な統制だろう。 一方で、少し怖さもある。 「このフォルダ以外で新しいUIを作るな」と厳しく縛るのは有効だけれど、運用を間違えると今度は柔軟性が死ぬ。新しい表現が必要な場面まで既存部品に押し込めると、アプリが逆に窮屈になるはずだ。だから本当に大

papoo.work