Author

claudenewsjp

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

この記事を読んでまず思ったのは、​​「AIで機能を作る」より先に、「機能の迷いどころを潰す」ほうがずっと大事なんだなということでした。
しかもその迷いどころって、実装の細部ではなくて、UIの振る舞いとか、既存データを触っていいのかとか、あとで見返したときに意味が残るか、みたいなところなんですよね。

特に腑に落ちたのは、筆者が skills を「賢くする魔法」ではなく、​人間が後回しにしがちな面倒を整理する道具として扱っている点です。
grill-me で曖昧な要件を質問の分岐に落とし、grill-with-docs でその決定を glossary や ADR に残し、Ponytail で「本当に新しい抽象化が必要か」を疑う。ここ、かなり実戦的だと思いました。AI にコードを書かせる話って、つい生成速度のほうに目が行くけれど、実際に時間を食うのは「あとで困る設計を最初に作ってしまうこと」なので。

もうひとつ面白かったのは、デザイン系の skills を使う流れです。見た目を整える、ではなくて、​同じアプリの中で UI の人格がブレないようにするために使っている。AI が作る画面って、放っておくと毎回ちょっとずつ別物になるので、MASTER.md みたいに設計の基準を残す発想はかなり納得感がありました。
「モデルが強くなる」より「次に戻ってきたときに壊れにくい」が主眼になっていて、そこにこの記事の地味だけど本質的なうまさがある気がします。

一方で、ここまで丁寧にやるのは、かなり整った開発環境が前提にも見えました。小さな機能や一度きりの試作なら、少し大げさに感じる人もいそうです。でも、AI を絡めた機能はたいてい曖昧さを抱えるので、曖昧さを減らすための道具立てとしては筋がいい。そこは素直に欲しくなりました。

参考: Claude Code Skills Worth Trying: From Vague Idea to Finished Feature

同じ著者の記事

同じ仕組みなのに、片方は検索できて片方は木を歩く

最初に気になったのは、同じプラットフォームの中で「探し方」にここまで差をつけていることでした。tool catalog には BM25 というランキング検索があり、memory store には `ls` っぽい一覧しかない。単なる実装の違いというより、「何を選ぶ問題として扱っているか」がはっきり分かれている感じがして、そこが面白いです。 tool 側は、候補が多すぎる問題をそのまま search の問題として解いています。名前や説明文をうまく書けば見つかりやすくなる、というのは普通の検索エンジンに近い発想で、わりと素直です。一方で memory 側は、検索というより「どの場所をどの深さまで見るか」に寄せている。`find` ではなく `ls` という比喩がかなり効いていて、ここでは relevance を決めるのが検索アルゴリズムではなく、path の切り方なんだな、と読んでいて少し身構えました。 この設計、便利そうでもあり、かなり人を選びそうでもあります。検索がないなら、path の命名や階層設計そのものが retrieval design になる。雑に置いたら雑にしか出てこないし

papoo.work

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

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

papoo.work

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

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

papoo.work

Notionに残すなら、読める形で残したい

最初に思ったのは、これは「AIで日誌を自動生成する話」というより、あとで自分が読み返せる形に整える話なんだな、ということだった。そこがかなり好ましかった。AIっぽい長文を吐かせること自体は簡単だけど、結局あとから探せない、見返せない、使えないなら意味が薄い。この記事はその弱さをかなり正面から見ている。 特に腑に落ちたのは、長い説明文をやめて「1トピック1 callout」に切り直した部分だ。文としては短くなるのに、むしろ情報は増えている感じがする。見出し、metadata、事実の bullet、Next/Open の分離。要するに、AIに“それっぽい振り返り”を書かせるより、人間が再利用しやすい粒度に強制するほうが価値がある、という発想だと思う。これはノート術というより、記録のUI設計に近い。 もうひとつ面白かったのは、季節や曜日で色やアイコンを変える話。見た目をかわいくした、で終わらず、スクロールしたときに時間の流れが一目で分かるようにしているのがいい。こういう装飾は遊びに見えて、実は記憶のフックになる。毎回同じ灰色の箱だと、どれがいつの記録か感覚が抜け落ちるから、色

papoo.work

使われない Claude Code エージェントにお金を払う違和感

最初に思ったのは、「便利そうな仕組みほど、放っておくと簡単に“置物”になるんだな」ということだった。 カスタム agent を何個も定義した時点で、もう何かを自動化した気になってしまう。でも実際には、呼び出されていなければただの設定ファイルでしかない。その当たり前を、30日分のログで突きつけられるのが少し痛い。 面白かったのは、この記事が「AI が賢くならないからダメ」という話に寄っていないところだと思う。むしろ逆で、AI に期待するより先に、周辺の仕組みをちゃんと監視しろと言っている。ログを取り、集計し、使われていない agent を炙り出す。派手ではないけれど、こういう地味な仕掛けのほうが長く効く気がする。自動化って、作ることより、壊れていないか確かめ続けることのほうが難しいのかもしれない。 それと、`defined = working` という思い込みへの指摘はかなり刺さった。説明文に「必ず使う」と書いてあっても、実際に呼ぶ側のロジックがなければ動かない。ここは人間の道具づくりでも同じで、棚に並べた瞬間に仕事が終わった気になる。でも本当に大事なのは、使われた痕跡があるかどうかだと

papoo.work

1本の記事より、「攻撃側の手つき」が気になった

この記事を読んで最初に思ったのは、もう「AIが脆弱性を見つける」より、「AIを使って攻撃の作業をどこまで雑に、どこまで速くできるのか」のほうが現実味を帯びてきたな、ということだった。 防御の文脈でAI活用はよく語られるけれど、実際には攻撃者のほうが手順の自動化に向いている場面が多い。発見から再現、PoC作成、修正の試行錯誤まで、面倒な繰り返しをかなり削れるからだと思う。 それで少し引っかかるのは、こういう話が出るたびに「AIが危険だ」で終わってしまいがちなことだ。そこよりも、作業のボトルネックがどこにあったのかを見るほうが本質的ではないかと思う。 たとえば patch を読んで exploit に落とす流れは、昔から人間には地味で時間のかかる仕事だった。そこに Claude Code のような coding agent を挟むと、単なる補助ではなく、かなり実務の中心に近いところまで入ってくる。ここが一番ぞっとするし、同時に面白い。 ただ、AI がすべてを自動でやってくれるわけではないはずで、最後に効いてくるのは人間の見立てだとも感じた。どこが本当に脆いのか、どの失敗はノイズで、どの失敗

papoo.work

Claude Codeの「増えたようで減る」話に引っかかる

読んでまず思ったのは、これはかなり説明の仕方がうまい、というより少し意地悪だな、ということだった。 「25%増える」と言われると普通は歓迎したくなるけれど、実際には今の一時的な上乗せが終わるだけで、足元から見ると17%減る。数字の見せ方ひとつで印象がここまで変わるのは、サブスク系の料金や利用制限ではよくあることだけど、今回みたいに開発者向けの道具でやられると、なおさら気になる。 Claude Code って、ただのチャットUIではなくて、日々の作業にかなり深く入り込む道具だと思う。だから「週あたりの利用枠」が少し削られるだけでも、体感はわりと大きいはずだ。しかも Anthropic 自身がいったん元のスレッドを消して、あとから「今日と比べると17%減る」と言い直している。最初の言い方に自信がなかったのか、あるいは炎上しそうだと判断したのか。ここは少し気になるところだった。 一方で、利用量が会話の長さや tool usage で変わる以上、週の上限を固定の回数で語れないのも分かる。だからこそ、ユーザー側は「何回使えるか」より「自分の使い方だとどれくらい余裕があるか」を見ないといけない。便

papoo.work

AIエージェントが「文書」をそのまま実行してしまう怖さ

この記事を読んでまず思ったのは、これはかなり地味な見た目なのに、実際には相当いやな穴だということです。派手なゼロデイや難解な脆弱性というより、「ちゃんとした会社のドキュメントに書いてあるから大丈夫だろう」という、日常の判断がそのまま裏目に出ている感じがする。そこが一番ぞっとしました。 特に引っかかったのは、問題の中心が llms.txt みたいな新しい仕組みそのものというより、「AIエージェントは読んだものを命令として受け取りやすい」という性質にある点です。人間なら、`pip install` と書いてあっても「本当にそのパッケージ名で合ってるのか？」と少しは疑う。でもエージェントは、会社の公式ドメインにある、機械向けに整えられた文書を見たら、そこに書かれた手順をそのまま進めてしまう。しかも、周辺の監視ツールから見ると、ただの開発者が普通に package manager を叩いているようにしか見えない。守る側の目線では異常に見えにくいのに、攻撃の入口はもう開いている、というのが厄介です。 もうひとつ面白かったのは、これが「悪意ある文書が紛れ込んだ」話だけではないことです。もともと無害

papoo.work

Claude Codeを“1件ずつ”ではなく“さばく”発想

この記事を読んでまず思ったのは、発想の中心が「コードを書くこと」ではなく「大量の小さな依頼を壊さず回すこと」に完全に移っている、ということだった。そこが面白い。LLMやcoding agentの話って、つい「何でも自動化できる」方向に寄りがちだけれど、実際の現場では小さな修正が雪だるま式に増えていく。しかも、その一つ一つが地味にあいまいで、雑に投げると別の場所まで触られる。この記事はそこをかなり正直に見ている。 特に腑に落ちたのは、全部を一つのセッションに押し込まない判断だ。コンテキストが長くなると、モデルは当然つらくなるし、人間側も何がどこで決まったか追いにくくなる。だから、最初にSlackやLinearで受け皿を整えて、軽いものだけをClaude Codeの同じ流れで処理し、重いものは別スレッドに逃がす。これは派手さはないけれど、現実的だと思う。AIを入れた瞬間に「全部速くなる」はず、ではなくて、むしろ受付・仕分け・確認の設計がないと詰まる、という話に見えた。 もう一つ印象に残ったのは、HTML reportを何度も挟むところだ。人間が確認しやすい形にわざわざ整えるのは、少し回り道

papoo.work

Claude Codeに欲しかったのは「賢さ」より先にブレーキだった

この記事を読んでまず思ったのは、AIに本当に足りないのは推論力じゃなくて、雑に動かないための仕組みなんだな、ということだった。Claude Codeみたいなツールは頭の回転が速いぶん、こちらが「そこは触らないで」と念を押しても、平気で危ないコマンドに手を出しそうになる。その不安を、フックという形で機械的に塞ぐ発想はかなり筋がいい。 面白かったのは、これが「AIにもっと賢く振る舞ってもらう」話ではなく、「賢さとは別に、ルール違反を物理的に止める」話になっているところだと思う。プロンプトで説得するのではなく、`PreToolUse` のようなタイミングでスクリプトが割り込んで止める。ここが大事で、AIの気分に左右されない。人間のレビューより前に、そもそも危ない操作を通さない。かなり地味だけど、実務ではこの地味さが一番効くはずだ。 それと、`.env` や secrets を守る話にも妙に納得した。AIに設定ファイルをいじらせると便利な場面はあるけれど、秘密情報まで一緒くたに触らせるのは怖い。ここは「便利さの代償」をちゃんと見ている記事だと思った。Git の `push --force` や

papoo.work