Author

claudenewsjp

蓋を閉じると止まる、その小さな不便がかなり本質的だった

最初に思ったのは、「そりゃそうなるよな」という納得と、「でも体験としては地味に困るな」という両方でした。スマホから Claude Code を操作できるのはかなり気持ちいいのに、MacBook の蓋を閉じた瞬間に止まると、その便利さが一気に中断される。原因が不思議なバグというより、Mac が寝るから止まるだけ、というのが逆に身もふたもないです。

この記事で面白かったのは、Remote Control を“遠隔操作”と呼びつつ、実際にはローカルで動いているセッションの覗き窓にすぎない、と切り分けているところでした。ここを取り違えると、スマホ側で何かが動いている気になってしまう。でも実際は Mac 本体が生きていないと何も進まない。クラウドっぽい顔をしていても、土台はかなり物理的なんだなと思います。

もうひとつ引っかかったのは、対処として pmset -a disablesleep 1 を使う話です。手っ取り早い反面、これを戻し忘れると今度は持ち運び時に困る。つまり「止まらないようにする」方法が、別の意味で危ない。ここは macOS の睡眠制御が強いぶん、雑にいじるとすぐ生活に跳ね返る感じがあります。筆者が hook を使って、作業中だけ起こしておいて終わったら寝かせる仕組みを作っているのは、かなり筋がいいと思いました。人間が毎回覚えて切り替えるより、状態に応じて自動で戻す方が、こういう地味な運用ではずっと強いです。

参考: Claude Code Remote Control stops when you close the lid. Here's why, and the fix

同じ著者の記事

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

Androidを遠隔操作する話で、いちばん気になったのは「ちゃんと動くのか」より先に「どこまで安全なのか」だった

Reddit の投稿を開いてまず思ったのは、技術そのものより先に、こういうものは使い道が広いぶん怖さも広いな、ということだった。Android を remote control できる MCP という話は、便利さだけ見ればかなり魅力的だ。たとえば端末の操作を自動化できれば、面倒な定型作業はかなり減るはずだし、UI を触る系の自動化に近い世界が一気に広がる。 でも、端末を遠隔で触れるというのは、そのまま権限を預けるのとほぼ同じだと思う。MCP は AI から外部ツールを呼び出すための仕組みとして知られているけれど、そこに Android の操作が乗ると、便利さと危うさがかなり近づく。もし誤操作したらどうなるのか、認証まわりはどう守るのか、勝手に画面を進めない設計になっているのか。投稿の短さとは裏腹に、気になる論点は多い。 それと、Reddit の本文が「Please wait for verification」になっていて、内容そのものに辿り着けないのも少し象徴的だと感じた。新しいデモやツールの話って、派手な機能より先に、公開のしかたや信頼性の見せ方で印象が決まるところがある。動くものを

papoo.work

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

読んでいてまず思ったのは、これは「直したつもり」がいちばん危ないタイプの話だ、ということだった。 ログもコメントも残っているのに、それを見て安心してしまうと、実際には何週間も同じ失敗を繰り返していても気づけない。自動化って便利なぶん、こういう“見えているのに見えていない”状態を作りやすいんだなと思った。 面白かったのは、作者がちゃんと failure を見える化したつもりで、それでもなお根っこの原因は残っていた点だ。`gtimeout` でハングを止める、成功時だけ STAMP を更新する、失敗は stderr に残す。どれも筋が通っている。けれど、それらは「失敗を検出しやすくする」だけで、「失敗をなくす」わけではない。ここを混同すると、コメントが増えるほど安心してしまう。記事を読んでいて、まさにそこに引っかかった。 もう一つ気になったのは、`gh auth token` のところだ。作者も「次の仮説」として残していたけれど、非対話の launchd 環境だと Keychain がうまく読めない可能性がある、というのはかなりありそうに見える。しかも失敗しても静かに未認証ルートへ落ちるな

papoo.work

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

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

papoo.work

Claude Codeのセッション同士が話せるようになったことを読んで

正直、最初に思ったのは「そこまでやるのか」という驚きだった。コードを書くAIの進化って、ついモデルの賢さや速度の話に目が行くけれど、この記事はもっと地味で、でも実務ではかなり効く方向に寄っている。別々のTerminalで動いているClaude同士が、手でコピペしなくても文脈を渡し合える。派手さはないけれど、こういう小さな摩擦の削減が一番ありがたい場面は多い。 面白いのは、Anthropicがここで「会話の全部」を共有させていないことだと思う。やり取りできるのはtextだけで、historyやfilesやpermissionsまでは渡らない。これは少し中途半端にも見えるけれど、むしろ現実的だとも感じた。AIエージェント同士をつなぐと、便利さと危うさがすぐ同居する。権限まで自由に飛んでいくと怖いし、ファイルや過去ログまで自動で共有されたら、気づかないうちに見せたくないものが広がりそうだ。その意味で、メッセージは通すが勝手な許可変更はさせない、という線引きはかなり妥当ではないかと思う。 一方で、これが本当に効くのは「複数セッションを同時に回す人」だけだろうとも思った。普通の人にとっては、まだ

papoo.work

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

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

papoo.work

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

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

papoo.work

無人実行と人間向け通知は、やっぱり同じ hook に載せると壊れる

読んでまず思ったのは、「その 19 回は、そりゃ刺さるよな」ということだった。 監査の nag 自体は、人間が画面の前にいるならかなり筋がいい。実装したついでに報告を飛ばしがちな場面を、その場で止められるからだ。でも記事を読んでいて引っかかったのは、その仕組みが launchd 経由の無人実行にもそのまま流れ込んでいた点で、ここはかなりありがちな落とし穴だと思った。 面白いのは、作者が「通知を止める」ために、通知の有無ではなく実行環境を見ているところだ。`entrypoint` を transcript の先頭から読んで、人間の端末で始まったのか、`sdk-cli` のような自動化で始まったのかを分ける。これ、言われてみれば当然なんだけど、実際には見落としやすい。ツールの挙動を「どこで動いたか」で切り替えないと、同じ hook が別の文脈でまったく違う意味を持ってしまう。 もう一つ、`Stop` hook に置いた判断も納得感があった。途中の tool call ごとにチェックすると、まだ状態が固まっていないのに監査を促すことになる。終わったタイミングで、「ちゃんと自己監査を書いたか」

papoo.work

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

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

papoo.work