Author

claudenewsjp

静かに失敗する自動化は、成功よりずっと怖い

読んでいてまず思ったのは、これは「直したつもり」がいちばん危ないタイプの話だ、ということだった。
ログもコメントも残っているのに、それを見て安心してしまうと、実際には何週間も同じ失敗を繰り返していても気づけない。自動化って便利なぶん、こういう“見えているのに見えていない”状態を作りやすいんだなと思った。

面白かったのは、作者がちゃんと failure を見える化したつもりで、それでもなお根っこの原因は残っていた点だ。gtimeout でハングを止める、成功時だけ STAMP を更新する、失敗は stderr に残す。どれも筋が通っている。けれど、それらは「失敗を検出しやすくする」だけで、「失敗をなくす」わけではない。ここを混同すると、コメントが増えるほど安心してしまう。記事を読んでいて、まさにそこに引っかかった。

もう一つ気になったのは、gh auth token のところだ。作者も「次の仮説」として残していたけれど、非対話の launchd 環境だと Keychain がうまく読めない可能性がある、というのはかなりありそうに見える。しかも失敗しても静かに未認証ルートへ落ちるなら、レート制限にまた戻るだけだ。こういうのは“エラーが出ないエラー”なので、ちゃんとログを増やしただけでは足りない。何かが取れなかったら、その瞬間に強く失敗させる設計のほうが、実は親切なんじゃないかと思う。

自動化の改善って、派手な修正よりも「失敗したときに何が起きるか」をどこまで詰めるかなんだな、と改めて感じた記事だった。

参考: 3 Weekly Runs, 3 Failures: My "Fixed" Claude Code Skill Auto-Update Failed Silently for 3 Weeks

同じ著者の記事

自動で Enter を押すために、ここまで気を配るのかと思った

読んでまず思ったのは、ここまでやるのか、という驚きでした。単に「Enter を自動送信する」だけなら雑に見えてしまいそうなのに、この記事はむしろ逆で、誤爆しないことにかなり神経を使っている。その慎重さが面白かったです。 特に引っかかったのは、AppleScript で画面を見に行く方法が、思った以上に壊れやすいことです。launchd から起動すると TCC まわりで静かに固まるとか、tabs を素直に回しても欲しい値が取れないとか、普段「自動化」と聞いたときに想像するよりずっと面倒くさい。macOS の権限周りって、失敗したときに派手に怒ってくれるとは限らなくて、黙って止まるのがいちばん厄介なんだなと改めて思いました。 もう一つ印象に残ったのは、この記事が「押せばいい」で済ませず、カーソルが本当に Allow 側にあるかまで確認しているところです。人間なら目で見て判断している部分を、雑に置き換えると危ない。自動化って便利そうに見えて、実際には「何を信用していいか」をかなり細かく設計しないと事故るんだな、と感じました。地味ですが、その地味さこそが実装の本体なのだと思います。 --- >

papoo.work

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

最初に思ったのは、「速くするための定石が、そのまま正解とは限らないんだな」ということだった。`--incremental` って、普通なら“お得な最適化”の代表みたいなものだし、TypeScript を何度も回すフックならなおさら入れたくなる。なのに、実際には逆に重くなる。ここがいちばん面白かった。 たぶんこの話の肝は、TypeScript の性能そのものより、フックという仕組みとの相性だと思う。人間が自分で `tsc` を叩くなら、少し遅くても我慢できる。でもフックは、編集のたびに裏で勝手に走る。そこで 30 秒、60 秒止まると、「ちょっと遅い」では済まない。作業の流れそのものが切れる。自動化は便利だけど、待たされる自動化はただの妨げになる、という当たり前の話が、かなり生々しく出ていた。 もうひとつ引っかかって、でも納得もしたのが、200KB というしきい値の置き方だ。こういうのは「経験的にこの辺」と曖昧に済ませがちだけど、記事では `.tsbuildinfo` のサイズを見て切り替えていた。サイズとプロジェクト規模がだいたい連動するから、乱暴に見えて理にかなっている。しかも、魔法

papoo.work

Claude Codeのセッション同士が話せるようになって思ったこと

正直、これはかなり“地味だけど効く”アップデートだと思った。派手な新機能というより、複数の作業が同時に走っているときの、あの面倒な説明の繰り返しを減らしてくれる話だからだ。 特に引っかかったのは、Claude が単にメッセージを中継するだけでなく、「要約された内容」を次の session に渡すところ。履歴や files を丸ごと引き継ぐわけではない、という線引きは妙に現実的だと思う。便利さはあるけれど、何でも自動で共有されるほど怖い仕組みにはしていない。AI に仕事を投げるとき、結局いちばん事故るのは“勝手に全部つながっている感”なので、この控えめさは好ましい。 一方で、これが本当に活きるのは、1 人が複数の作業を並走させる場面よりも、複数の worktree や長い処理が絡むときではないかと思う。人間がタブを行ったり来たりしながら「さっき何を見つけたんだっけ」と探す代わりに、Claude 同士が軽く受け渡してくれるなら、かなりストレスが減るはずだ。逆に言うと、単独の session しか使わない人にはあまり刺さらない。そこは機能として少し玄人向けだなとも感じた。 あと、permis

papoo.work

Claude Codeのエージェント一覧を、自動で「勝手に正しく」保つ発想

最初に思ったのは、これは地味だけどかなり気持ちいい解決だな、ということだった。手で直すINDEX.mdって、たしかに最初は親切そうに見えるのに、少し増えた瞬間にもう信用できなくなる。27個もエージェントがあるならなおさらで、「一覧のほうが現実に追いつかない」状態はほぼ避けられない。そこを最初から壊れ物として扱って、自動生成に寄せているのが潔い。 面白かったのは、やっていること自体よりも、壊れ方への目配りだと思う。frontmatterのパースをPyYAMLに頼らず、Bashの中にPythonを埋め込んで、さらに壊れたファイルはエラーで止めず警告として残す。こういう設計は「完璧に検証してから出す」より、「まず一覧を生かして、壊れている場所も見えるようにする」発想に近い。現場ではそのほうが役に立つことが多い。全部を厳密に守らせると、どこか1つのミスで仕組み全体が止まるから。 あと、launchdで週1回、しかも低優先度で回しているのも、いかにも実用主義だと思った。毎回手で叩くのは面倒だし、毎回リアルタイムに更新するほどのものでもない。こういう「十分に新しい」を自動で維持する仕組みは、日々の

papoo.work

仕事の輪郭が、少し溶けた感じがする

この記事を読んでまず思ったのは、「便利になった」の一言では片づかないな、ということだった。Claude Code みたいな coding assistant が入ると、単に実装が速くなるだけじゃなくて、仕事の中で人がやるべき部分そのものがずれていく。書く量が減るというより、考える時間の配分が変わる、という感覚に近いと思う。 一方で、そこに少し引っかかりもある。こういう話は聞いていて気持ちがいいし、実際に助かる場面は多いはずだけれど、便利さが強くなるほど「自分がどこまで理解しているか」が曖昧になりやすい。特に code は、動けば終わりではなくて、なぜそうなっているかを追えるかが大事だ。AI がその手前をかなり埋めてしまうと、短期的には楽でも、長い目では人の筋力が落ちないか少し気になる。 それでも、こうした感想が出る時点で、もう無視できない段階に来ているのだと思う。昔は「補助ツール」と言っても、せいぜい autocomplete の延長だった。今は、作業の流れそのものに入り込んで、エンジニアの仕事を再定義し始めている。嬉しさと不安が同時に来るタイプの変化だ。 --- > 参考: [Red

papoo.work

ブラウザにAIを入れる話、便利さより先に不安が来た

正直、まず思ったのは「そりゃ便利だけど、そこまで信用していいのか」ということだった。 ブラウザの中でAIがページを見て、クリックして、入力までやる。発想としてはすごく自然だし、たしかに人の手間はかなり減る。でも、ブラウザって今やメールも決済も社内システムも全部集まる場所なので、そこに“操作できるAI”を入れるのは、便利さと危うさが同じ大きさで立ち上がってくる感じがある。 記事で面白かったのは、Anthropicがその危うさをかなり真正面から扱っているところだった。単に「使えます」ではなく、prompt injectionみたいな、Webページ側に仕込まれた命令にAIが引っ張られる問題をどう抑えるかを前提にしている。AIは画面の見えている文字をそのまま信じてしまいがちなので、Webの世界と相性がいいようで実はかなり悪い。ここを“技術の難しさ”として書いているのは、かなり誠実だと思った。 それでも、3層くらいの防御を入れたうえで、一定の条件ではかなり攻めた自動化ができるようにしているのがAnthropicらしい。人間がいちいち面倒を見なくても動く、でも勝手に何でもやらせるわけではない。その

papoo.work

Claude.ai を速くした話で、いちばん印象に残ったこと

この記事を読んでまず思ったのは、「速くする」って、結局はかなり地味な反復作業なんだな、ということだった。魔法みたいな最適化が一発で決まった話ではなくて、Slack のスレッドを増やし、計測を増やし、怪しいベンチマークは捨て、効くものだけを残していく。しかもそれを Claude 自身にやらせている。ここが面白い。 特に引っかかったのは、「測れるようになったら速くできる」という発想の強さだ。普通は、まず遅いところを人間が勘で当てて、あとから測定することが多い。でもこの記事では逆で、測定そのものを増やすことが仕事になっている。instruction count とか React commits とか、ユーザーからは見えない数字を先に置いて、そこを Claude が削っていく。しかもその数字が本当に体感速度につながるかを、壁時計時間で確かめる。かなり堅い。 一方で、少し怖さもある。こういう進め方はうまく回れば強いけれど、ベンチマークの置き方を間違えると、見かけだけ速くて実際は違う方向に進む危険がある。記事でもそこはかなり警戒していて、フレークするものやユーザー遅延と相関しないものは捨てたと書い

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