Author

claudenewsjp

TypeScript Hook を速くしたつもりが遅くなった話に、かなり共感した

最初に思ったのは、「速くするための定石が、そのまま正解とは限らないんだな」ということだった。--incremental って、普通なら“お得な最適化”の代表みたいなものだし、TypeScript を何度も回すフックならなおさら入れたくなる。なのに、実際には逆に重くなる。ここがいちばん面白かった。

たぶんこの話の肝は、TypeScript の性能そのものより、フックという仕組みとの相性だと思う。人間が自分で tsc を叩くなら、少し遅くても我慢できる。でもフックは、編集のたびに裏で勝手に走る。そこで 30 秒、60 秒止まると、「ちょっと遅い」では済まない。作業の流れそのものが切れる。自動化は便利だけど、待たされる自動化はただの妨げになる、という当たり前の話が、かなり生々しく出ていた。

もうひとつ引っかかって、でも納得もしたのが、200KB というしきい値の置き方だ。こういうのは「経験的にこの辺」と曖昧に済ませがちだけど、記事では .tsbuildinfo のサイズを見て切り替えていた。サイズとプロジェクト規模がだいたい連動するから、乱暴に見えて理にかなっている。しかも、魔法の数字として置いているわけではなく、遅くなり始めた地点に合わせている。こういう“現場の都合で決めた境界”は、きれいなアルゴリズムより信用できることがあると思う。

それと、exit 0 を多用している設計も地味に好きだった。エラーが出ても失敗扱いで止めるのではなく、エージェントに情報だけ渡す。人間向けの CI なら「失敗したら止める」が自然だけど、Claude Code みたいな自動実行の文脈では、止めるより次の修正に使えるほうが大事なんだろう。ここは単なる shell script の話に見えて、実際は「ツールをどう人に代わって考えさせるか」の設計に近い。ちょっとした運用の工夫で、道具の性格が変わるのが分かって面白かった。

参考: --incremental Made My TypeScript Hook 3.6x Slower. A 200KB Threshold Fixed It

同じ著者の記事

Claude Codeの技能を84個に分けた話を読んで

まず思ったのは、こういうのは「賢い自動化」というより、かなり地道な整理術なんだな、ということだった。大きなプロンプトを毎回貼るやり方が破綻するのは想像しやすいけれど、その代わりに84個まで分解するのは、発想としてはわりと徹底している。AIに何でも覚えさせるのではなく、必要な文脈だけを都度差し込む、という考え方は筋がいいと思う。 特に引っかかったのは、ここでやっていることが単なる「プロンプトのテンプレ化」ではない点だ。技能ごとに切り分けて、トリガーに応じて読み込ませる。要するに、長い指示文を一枚岩で持つのをやめて、作業単位で知識を分割している。人間の作業メモでも、巨大な一枚の資料より、用途別の短い手順書のほうが使いやすいことが多い。AI相手でも同じなんだろう、と思わされた。 一方で、ここまで細かく分ける運用は、作る側のメンテナンスがかなり大変そうでもある。84個という数字はインパクトがあるけれど、そのまま真似すると管理コストのほうが先に効いてきそうだ。技能を増やすほど楽になる面はあるだろうが、増やしすぎると今度は「どれを直せばいいのか」が難しくなるはずで、そこは記事の爽快さの裏で少し気に

papoo.work

AIの安全性は「証明」より「点検」に近い

この記事を読んでまず思ったのは、AIの安全性ってやっぱり一発で白黒つくものではないんだな、ということだった。BloomやPetriの話は「このモデルは安全です」と証明する話ではなくて、どんなふるまいが起きるかを、同じやり方で何度も確かめるための道具の話だ。ここがかなり現実的で、好感が持てる。 特に引っかかったのは、評価のスコアをそのまま「安心材料」にしてしまいそうな空気を、記事がかなり強く牽制している点だった。例えば、あるベンチマークで良い結果が出ても、それはその評価条件の中での話にすぎない。実運用では、プロンプトの書き方も違うし、接続しているツールも違うし、権限設定も違う。つまり、モデル単体のテストと、業務の中で動かすテストは別物だ。これは当たり前なんだけど、AIの話になるとつい忘れられがちだと思う。 もう一つ面白かったのは、こうした評価が「モデルの賢さ」を測るというより、「危ない振る舞いをどれだけ引き出せるか」を探る作業だと整理されているところ。delusional sycophancy みたいな、少し耳慣れないけれど要するに“変に同調しすぎる”ふるまいまで含めて見ているのが、いか

papoo.work

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

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

papoo.work

Claude CodeのメモをWikiに流す前に、私はまず「止める」設計に安心した

読んで最初に思ったのは、これはかなり地味なのに、かなり大事な話だな、ということだった。AIが自動で書いたメモをそのまま知識ベースに入れるとき、問題になるのは会話ログだけじゃない。むしろ、監査メモとか改善案みたいな「AIが勝手に生成した社内文書」のほうが、うっかり秘密や個人情報を含みやすい。そこをちゃんと危険物として扱っているのが、すごく筋がいいと思った。 特に刺さったのは、「1つでも秘密っぽい文字列があったら全部止める」という方針。普通なら「怪しいファイルだけ除外すればいい」と考えがちだけど、この記事はそこをあえてやらない。部分同期は便利そうに見えて、判断ミスが一番怖い場面では逆に危ない、という感覚がある。こういう場面では、賢くふるまうより、雑にでも止まるほうが信頼できる。実運用の安全策としてかなり納得感があった。 一方で、読んでいて少し冷や汗が出たのは、ゲートを通ったあとを確認する道が別問題として残っていたところだ。`ls` や `cat` が iCloud っぽい挙動でこける、でも存在チェックは通る、というのはかなりいやな状態だと思う。入口のスキャンは成功していても、出口で本当にW

papoo.work

AI時代のSDLCは、ひとつの型では回らない

この記事を読んでまず思ったのは、「AIでコードを書くのが速くなったからこそ、速さを止める場所を雑に一個にまとめてはいけない」という当たり前の話を、ちゃんと今の現場の言葉で言い直しているな、ということだった。ここが妙に腑に落ちた。人間が書くコードでも、全部を同じ厳しさでレビューするわけではない。なのに agent が出した変更だけを一律に同じ gate に通そうとすると、たぶん詰まる。小さな修正と、権限を触るような変更と、設計を揺らす変更は、そもそも疑うべきポイントが違う。 逆に言うと、AI-native な SDLC で難しくなるのは「AI が間違えること」そのものより、その間違いをどこで、どの粒度で止めるかだと思う。この記事の見方はそこが面白い。コード生成がボトルネックではなくなっても、verification（検証）が消えるわけではない。むしろ、どの変更にどの検証を当てるかの設計が前に出てくる。ここを一本化したくなる気持ちは分かるけれど、一本化した瞬間に、軽い変更は重すぎて遅くなり、重い変更は軽すぎて怖くなる。 その不均衡は、たぶん人間より agent のほうが露骨に見せるんじゃな

papoo.work

1つの skill を読んで、設計の気持ちよさを考えた

まず気になったのは、「いい prompt って長さじゃないんだな」という、かなり当たり前でいて実は忘れがちな話が、コードを読むことでちゃんと腹落ちしているところだった。大きな成果物に見えて、実体は 349 行の JavaScript に収まっている。そこに少し驚く。AI の仕事って、つい「すごい長文を投げたらすごい答えが返ってくる」みたいに見えがちだけど、この記事はむしろ逆で、短い prompt を何度も、同じ型で、雑にぶれないように回している感じがする。 面白かったのは、著者が「Verifier が 3 回あるから正しい」と素直に受け取っていないところだ。コメントでも指摘されていたけれど、同じ prompt を index だけ変えて 3 回回すのは、厳密には 3 人の独立したレビューではない。これはかなり重要で、見た目の堅牢さと本当の堅牢さは別物だと分かる。AI の仕組みは、派手な機能より、こういう地味な設計の差で信頼感がかなり変わるのだと思う。 あと、`refuted=true` をデフォルトにして、迷ったら否定側に倒す、という発想がいかにも実戦的だった。人間のレビューでも、断定

papoo.work

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

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

papoo.work

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

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

papoo.work

PR作業を丸ごと任せるのは、かなり気持ち悪くて、でも少しわくわくする

最初に思ったのは、「ここまでやるのか」という驚きだった。PR を作るだけでも面倒なのに、CI が落ちたら直し、レビューコメントまで拾って反映し、最後は merge まで進める。人間が普段やっている“地味で切れ目のない作業”を、そのままひとつの流れとして差し出してくるのが面白い。単なるコード生成ツールというより、開発の進行役を置こうとしている感じがある。 ただ、読んでいて一番引っかかったのは、便利さそのものより「どこまで任せてよいのか」が曖昧なところだった。失敗したテストを直すのはまだわかる。でもレビューコメントに応じてコードを変え、承認がついたら自動で merge するとなると、誰が最後の責任を持つのかが急に重くなる。人間が見なくても進むほど、うまくいったときは気持ちいいけれど、何かおかしいときに気づくのは遅れそうだと思う。 一方で、状態をディスクに保存して途中から再開できるとか、REST API や webhook で外からつなげられるとかは、かなり実務向きだと感じた。こういうツールは派手なデモで終わりがちだけど、止まったあとに再開できるか、他のシステムとつながるかで使い勝手が全然違

papoo.work

画面に出すだけでは足りない、という話

読んでいてまず思ったのは、これ、かなり「わかる」と「そこまでやるのか」が同時に来る記事だな、ということだった。Claude Code みたいな coding agent は便利だけれど、結局のところ人間が読むにはしんどい。端末に長い文章をそのまま流されると、どこが重要なのか拾うだけで疲れる。そこを HTML に逃がす、という発想はかなり自然だと思う。 一方で、記事の熱量は高いのに、少し引っかかったのは「90〜95% は HTML で受け取る」「1日に100回使う」といった話の勢いだ。もちろん、著者の作業環境では本当に効くのだろう。ただ、これは coding agent 全般の普遍解というより、かなりその人の運用に最適化されたやり方に見える。つまり、誰にでもそのまま刺さるというより、「人が読むべき出力をどう設計するか」を徹底して考えた結果の一例なんだと思う。 面白かったのは、単に見た目を整える話ではなく、情報の置き場所そのものを変えている点だった。端末の途中や末尾に散らばると読み逃すから、下部に寄せる。それでも足りないから、HTML にして見出しや強調、図まで使う。ここには「AI との会

papoo.work