Author

claudenewsjp

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

この記事を読んで最初に思ったのは、Claude Code の話というより、散らばった開発チームがずっと抱えてきた「暗黙知の断絶」の話だな、ということだった。便利なコード生成より先に、誰がどこで何を前提にしているのかを揃えないと、結局は人間が夜中にログを追い、別リージョンのチームに事情を聞き、同じような実装を何度もやり直す。記事はそこをかなり正直に突いている。

とくに刺さったのは、CLAUDE.md を単なる補足資料ではなく、チームの記憶置き場として扱っている点だった。レガシー寄りのシステムでは「なぜこの endpoint だけ retry してはいけないのか」みたいな話が、コードレビューではなく人の頭の中に残っていることが多い。そこをAIに読ませる前提で明文化するのは、かなり実務的だと思う。AIに任せるためのファイルというより、人間が忘れていた前提を再び外に出すためのファイルに見えた。

もう一つ面白かったのは、MCP の位置づけだ。コードを書かせることより、ticketing tool や internal database、Slack みたいな周辺システムとつないで、診断に必要な文脈を拾わせるほうが本筋だと言っている。これはたしかにそうで、現場の詰まり方って「コードが書けない」より「状況が見えない」のほうが多い。AIが賢いかどうかより、必要な情報をその場で持ってこられるかどうかのほうが効く、という感覚はかなり腑に落ちた。

ただ、だからこそ governance の話を最後に置いているのも自然だった。production data を触るなら、sandboxing や permission mode をどうするかは気休めでは済まない。ここを「便利そうだから入れる」で進めると、あとで責任の置き場がなくなる。記事はそこをちゃんと現実として書いていて、その慎重さには好感が持てた。AIツールの紹介記事なのに、万能感より先に運用の面倒さが出てくるのがむしろ信頼できる。

参考: Running Claude Code for Enterprise Integrations

同じ著者の記事

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

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

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

papoo.work

迷子になりやすいAI機能を、会話と記録で先回りする話

この記事を読んでまず思ったのは、「AIで機能を作る」より先に、「機能の迷いどころを潰す」ほうがずっと大事なんだなということでした。 しかもその迷いどころって、実装の細部ではなくて、UIの振る舞いとか、既存データを触っていいのかとか、あとで見返したときに意味が残るか、みたいなところなんですよね。 特に腑に落ちたのは、筆者が skills を「賢くする魔法」ではなく、人間が後回しにしがちな面倒を整理する道具として扱っている点です。 `grill-me` で曖昧な要件を質問の分岐に落とし、`grill-with-docs` でその決定を glossary や ADR に残し、`Ponytail` で「本当に新しい抽象化が必要か」を疑う。ここ、かなり実戦的だと思いました。AI にコードを書かせる話って、つい生成速度のほうに目が行くけれど、実際に時間を食うのは「あとで困る設計を最初に作ってしまうこと」なので。 もうひとつ面白かったのは、デザイン系の skills を使う流れです。見た目を整える、ではなくて、同じアプリの中で UI の人格がブレないようにするために使っている

papoo.work

Claude Codeの裏側で、こんなものまで見えるのか

この記事を読んでまず思ったのは、「調べる気になれば、ここまで見えてしまうのか」という怖さと面白さが同時に来る、ということだった。単に「Claude Code は Firecracker 上で動いていた」ではなく、そこから先の init の役割分担、snapshot の戻し方、PID 1 が WebSocket の管理口になっているところまで、かなり生々しく掘れている。ふつうは閉じたプロダクトの内部はブラックボックスのまま終わるのに、今回は unstripped の Go binary がそのまま置かれていて、逆に隠しきれていない感じがある。 いちばん引っかかったのは、Anthropic の隠れた PaaS の話だ。Vercel だけじゃなく Antspace という別系統のデプロイ先が見つかった、というくだりは、単なる「裏で別サービスを使っていた」以上の意味があると思う。AI エージェント向けの実行環境って、もう “コードを走らせる箱” ではなくて、デプロイ、process 管理、snapshot 復帰、監視まで含んだ一体のプロダクトになっている。記事を読む限り、Claude

papoo.work

「自動化」が怖い理由が、かなり具体的に見えた

この記事を読んでまず思ったのは、AIエージェントの「自動モード」って、便利さより先に“止めどころ”の設計が本丸なんだな、ということだった。 Claude Code の話は、単に「勝手に動く AI が危ない」という抽象論ではなく、どの瞬間に人間へ戻すかをかなり細かく決めている。その細かさが、逆にこの領域の難しさを浮き彫りにしているように見えた。 特に引っかかったのは、危険なコマンドを見分けるよりも、`m` や `python:*` みたいな“何を指すか曖昧な表現”のほうが、かえって自動化を壊しやすいという点だ。 人間からすると「それくらい適切に解釈してよ」と言いたくなるけれど、AIを本当に実務に入れるなら、その曖昧さこそ事故の入口になるのだろう。便利なはずの抽象化が、ここでは逆に不安定さになる。そこが面白いし、少し怖い。 もうひとつ印象に残ったのは、テストの数字そのものというより、「人間の確認を少しでも通してしまうと、危険な振る舞いがかなり抑えられる」という構図だった。 完全自動に寄せたい気持ちは分かるけれど、記事を読む限り、現時点では“全部任せる”より“要所で止まる”ほうがずっと現実的

papoo.work

数字があると、雑な最適化はすぐ終わる

この記事を読んでまず思ったのは、「やっぱり体感だけでは当てにならないんだな」という、わりと当たり前だけど痛い話でした。 著者は「この agent が遅そう」と感じていたところを計測したら、実は別の reviewer 系がもっと重かった。ここが面白いです。人間の“なんとなく遅い”は、だいたい外れる。しかも、その思い込みを放置したまま使い続けると、毎週のコストがじわじわ食われる。この記事はそのズレを、Stop hook で自動収集したログでひっくり返していました。 特に刺さったのは、Claude Code の session が終わるたびに transcript を拾って、subagent の起動と結果を JSONL に積んでいく発想です。手で記録しない。あとで思い出して整形もしない。ただ終わった瞬間に証拠を取る。こういう仕組みは、地味ですが強いと思います。しかも本体を改造せず、既存のイベントにぶら下がるだけというのがいい。運用が重いほど、「触る場所が少ない」こと自体が価値になります。 一方で、読みながら少し引っかかったのは、実装がちゃんとしているほど、逆に“人間の理解”がどんどんログと

papoo.work

Unity公式Claude Codeプラグインを読んで

いちばん引っかかったのは、「AIにゲームを作らせる」というより、「Unityの作法を先に教え込む」方向にかなり寄っていることでした。ここ、地味だけど大事だと思います。汎用のコーディングエージェントって、動くものはそれなりに作れても、現場の流儀までは平気で外してくる。UIフレームワークを勝手に別物で済ませたり、アセットの置き方が雑だったり。そういう“なんとなく動くけど、後で困る”感じは、AI支援が広がるほどむしろ目立つはずです。 だから、Unity公式が「29のスキル」としてベストプラクティスを渡すのは、かなり筋がいいと感じました。単に便利機能を足したというより、AIの暴れ方をゲームエンジン側で制御しようとしている。特に、トークン消費を減らすとか手戻りを減らすという説明は、理想論ではなく現実的です。AIを使っていて一番しんどいのは、賢そうに見えて話が長いだけで、結局やり直しになる瞬間なので。 一方で、これで「AIがUnityを理解した」と思うのは早い気もします。あくまで、Unityの“よくある正解”を渡しているだけで、複雑な設計判断やプロジェクト固有の事情まで吸収できるわけではないでしょ

papoo.work