#claudecode

546 件の記事

TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときに確認したこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときに確認したこと
この症状は、報告された2件の issue で同じエラー文字列として現れています。いずれも `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=142 messages=141 range=[118,142))` で始まり、スタックトレースは `/$bunfs/root/src/entrypoints/cli.js` を指しています。少なくとも issue 上では、別々の使い方に見える2件が同じ症状としてまとまっています。 まず切り分けの起点になるのは、Claude Code の正常な会話中にこのエラーが出て、その後の振る舞いが不自然になるかどうかです。#84467 では、スキャナーからデータを取ろうとした途中で、モデルが「lower lesser models」に勝手に切り替わると報告されています。#84140 では、本人が所有するハードウェアへのアクセス支援を求めたところ、Claude がそれを脅威のように扱った、と書かれています。どちらも、単なる表示崩れではなく、会話の
papoo.work
Workspace unavailable. The isolated Linux environment on thi で止まるときに、まず疑うこと
Workspace unavailable. The isolated Linux environment on thi で止まるときに、まず疑うこと
このエラーは、Windows 上の Claude Desktop / Cowork で isolated Linux environment が起動できなかったときに出ています。今回の症状クラスタでは、同じ文言を出す issue が 2 件ありました。ひとつは [#98613](https://github.com/anthropics/claude-code/issues/98613)、もうひとつは [#88921](https://github.com/anthropics/claude-code/issues/88921) です。 まず、あなたのケースがどちら寄りかを切り分けるのが先です。 手元で確認できている一次情報は環境情報だけです。ここから先の再現結果や回避策は、今回は実測できていません。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-10-02T08:55:02+09:00 ``` なので、現時点で確実に言えるのは次の
papoo.work
Claude Code に触らせる作業フォルダを先に決める
Claude Code に触らせる作業フォルダを先に決める
Claude Code に「とりあえず全部見ておいて」は危ない。雑に広い場所で動かすと、余計なファイルまで巻き込み、指示も散る。まずやるべきは、作業フォルダの固定、つまり触らせる範囲を狭めることだ。 これを先に決めておくと、Claude Code は仕事しやすいし、こちらも安心して見ていられる。開発用のリポジトリだけを触らせたいときも、書類整理で特定の案件フォルダだけを見せたいときも、考え方は同じだ。対象を絞るほど、意図しない変更や探索の無駄が減る。 Claude Code は、いま開いているディレクトリを起点にして動かすのが基本だ。だから、最初に「ここだけ触ってよい」というフォルダを決めて、その中で起動するのがいちばん素直で強い。 たとえば、案件ごとにフォルダを分ける。書類整理なら、年度別や案件別のフォルダを分ける。大事なのは、Claude Code に見せる範囲を最初から小さく保つことだ。 ```bash cd ~/work/project-a claude ``` この形にしておけば、少なくとも起点は `project-a` になる。逆に、ホームディレクトリや巨大な親フォルダで起
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le — このエラーが出るときに見えていたこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages le — このエラーが出るときに見えていたこと
まず、自分のケースかどうかはかなり絞れます。今回の報告に出ているのは、どちらも同じ系統のエラーです。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=688 messages=687 range=[670,688)) ``` 別の issue では、同じ文字列のまま `keys=213 messages=212` という差分で報告されています。該当するのは [#98258](https://github.com/anthropics/claude-code/issues/98258) と [#98290](https://github.com/anthropics/claude-code/issues/98290) です。どちらも open で、解決済みではありません。 この症状の中心は、`VirtualMessageList` の `itemKeys` と `messages` の件数がずれている、という点にあります。少なくとも issue の報告上は、`key
papoo.work
`Background full checkout failed: other` が出て worktree セッションが始まらないとき
`Background full checkout failed: other` が出て worktree セッションが始まらないとき
この症状は、Claude Code の worktree を使って新しいローカルセッションを起動した直後に、ブランチ切り替えの段階で止まるものです。手元の issue 報告では、ダイアログに > ブランチを切り替えられませんでした (Could not switch branch) > `Background full checkout failed: other` と出て、そのままセッションが始まりません。#86276 では、worktree 自体は片付く一方で、セッション用に作られたブランチ `claude/<name>-<hash>` が base repo 側に残ると報告されています。[#86276](https://github.com/anthropics/claude-code/issues/86276) 似た見え方をする別件もあります。#74526 では、git submodule の中で worktree セッションや background-task chip を起動すると同じ `Background full checkout failed: other` に落ち、
papoo.work
MCP server hits a 30s connection timeout on the client side: 新しい Claude Code セッションだけ MCP 接続が落ちるときの見方
MCP server hits a 30s connection timeout on the client side: 新しい Claude Code セッションだけ MCP 接続が落ちるときの見方
この症状は、同じ Claude Code の CLI を使っているのに、新しく起動したセッションだけ HTTP MCP サーバーへの接続に失敗する、という形で出ています。参照できる issue は [#86378](https://github.com/anthropics/claude-code/issues/86378) と [#86380](https://github.com/anthropics/claude-code/issues/86380) です。どちらも、長く開きっぱなしだったセッションではつながるのに、立ち上げ直した直後のセッションでは失敗すると報告しています。 この切り分けが重要です。CLI のバイナリやバージョン差ではなく、issue 本文では「セッション開始時に一度だけ評価される何か」が関係していそうだ、と書かれています。たとえばクライアント側のキャッシュ状態、あるいはサーバー側の機能フラグやロールアウトです。ただし、これは issue の報告からの推測であって、確定ではありません。 実際に確認できる事実だけを書くと、症状の核は次の通り
papoo.work
Claude Codeの“どこでも使える”感じが、ようやく本物になってきた
Claude Codeの“どこでも使える”感じが、ようやく本物になってきた
この記事を読んで最初に思ったのは、Claude Codeが「結局どこで動かすのが正解なのか」という迷いを、かなり正面から潰しにきているな、ということでした。 AIコーディング支援って、便利さより先に「どの画面で、どの粒度で、どこまで任せるか」で疲れることが多いんですが、そこをCLI、VS Code、Desktop、Webに分けて整理しているのはかなり実用的です。単に入口を増やしただけではなく、作業の性格ごとに居場所を分けているのが面白い。 特に引っかかったのは、Desktopが「何でもできる上位版」ではないところです。 GUIで見やすいし、自動確認やDispatchみたいな独自機能もある。でも、だからといって常にDesktopが最適とは限らない。むしろ、長い作業はCLIやVS Codeで始めて、必要なときだけDesktopに持っていく、という行き来のしやすさが価値なんだろうと思いました。道具が一個に収束するのではなく、作業の途中で持ち替える前提になっているのが、いかにも今っぽいです。 一方で、この記事を読んで少し気になったのは、こういう「使い分け」は便利な反面、初見の人にはかなり複雑に
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときにまず確認すること
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときにまず確認すること
このエラー文字列が出ているなら、少なくとも本文で扱う2件の issue と同じ症状に当てはまります。ひとつは [#97891](https://github.com/anthropics/claude-code/issues/97891)、もうひとつは [#97348](https://github.com/anthropics/claude-code/issues/97348) です。どちらも open で、解決済みではありません。 共通しているのは、Claude Code の内部で `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ていることです。報告されている差分は少し違いますが、少なくとも issue 上では同じ系統の壊れ方として現れています。たとえば [#97891](https://github.com/anthropics/claude-code/issues/97891) では `keys=334 messages=333 range=[294,334)`、[#9734
papoo.work
No verdict (error) が出て auto mode が止まるときに見えているもの
No verdict (error) が出て auto mode が止まるときに見えているもの
「No verdict (error)」が出る症状は、少なくとも issue 上では、Claude Code の auto mode で server-side の safety classifier が判定を返せず、処理が止められる状態として報告されています。該当する報告は [#97870](https://github.com/anthropics/claude-code/issues/97870) と [#97923](https://github.com/anthropics/claude-code/issues/97923) です。 読者が自分のケースかどうかを先に見分けるなら、まずエラー文そのものを確認するのが早いです。issue では、少なくとも次の文言が繰り返し出ています。 ```text The server-side auto mode classifier gave no verdict (error), so auto mode cannot determine the safety of Bash. ``` 別の報告では、ツール名が Bash 以外にも広がって
papoo.work
Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited" — Claude Code で見えた 429 と、issue 上で確認できたこと
Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited" — Claude Code で見えた 429 と、issue 上で確認できたこと
この症状は、Claude Code からのリクエストが 429 で落ちているケースです。今回の issue 群では、報告されたエラー文字列が一致していました。 ```text Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"},"request_id":"req_011CcQsDhT3bVPHSn3vhf3rp"} at generate (B:/~BUN/root/src/entrypoints/cli.js:11:53135) ``` issue #71503 と #71673 のどちらも、同じ 429 系のエラーを含んでいます。本文中では「Server is temporarily limiting requests (not your usage limit) · Rate limited」と書かれており、さらに別の報告では `"This request would exceed your account's rate limit. Please try
papoo.work
The server-side auto mode classifier gave no verdict (error) が出て、Auto mode の Edit/Bash が止まるとき
The server-side auto mode classifier gave no verdict (error) が出て、Auto mode の Edit/Bash が止まるとき
まず切り分けたいのは、「読めるのに、書けない」かどうかです。今回の症状は、issue 報告を見る限り、Read や Read-only 系の操作は通るのに、Edit や Bash、ブラウザ操作の一部だけが `The server-side auto mode classifier gave no verdict (error)` で止まる、という形で出ています。たとえば [#97812](https://github.com/anthropics/claude-code/issues/97812) では Edit と Bash が連続して失敗し、Read や MCP の read-only クエリは動いていました。[#97874](https://github.com/anthropics/claude-code/issues/97874) でも `mcp__claude-in-chrome__tabs_context_mcp` が同じエラーで連続失敗しています。 今回の報告群で共通しているのは、ローカルのファイルやツールが壊れているというより、Auto mode の安全判定そのものが
papoo.work
長い資料は章ごとに渡す：一気読み前提をやめる
長い資料は章ごとに渡す：一気読み前提をやめる
長い資料をそのまま丸投げして、Claude Code が全部を一気に飲み込む前提で話を進める。これ、かなり雑だ。章ごとに渡したほうが早いし、手戻りも減る。資料を分割して渡す、章ごとに入力する。呼び方は何でもいいが、やることは同じである。 Claude Code は長文を処理できる。ただし、だからといって「全部を一回で読ませれば安心」にはならない。実際は、要件の中心と枝葉が混ざって、どこに力を使うべきかがぼやける。PDF の規程集、議事録の束、引き継ぎ文書、契約書のたたき台、フォルダに散らばったメモ。こういうものを一気に投げると、見てほしい章より、どうでもいい付録に引っ張られることがある。筆者も最初は、1 本の長いメモをそのまま渡して「全体を要約して」とやり、欲しい論点が抜けた要約を返されて手戻りした。原因は単純で、指示が悪い。長い資料は、渡し方で勝負が決まる。 やることは難しくない。まず、資料の全体像をつかみたいのか、特定の章だけを処理したいのかを決める。次に、章や節ごとに切る。最後に、Claude Code に「この章だけ読んで」「この章と前章を比較して」「この章の変更点だけ拾って」
papoo.work
Claude Code に最初に出力形式を決めさせる
Claude Code に最初に出力形式を決めさせる
いきなり作業を始めさせると、あとで「やっぱり表で」「いや箇条書きで」と差し戻しが入る。あれは地味にだるい。Claude Code は、最初に返答の形を固定してから動かすだけで、手戻りがかなり減る。Markdown か表かを先に決める、返答の形を固定する、というやり方だ。 この手は、開発作業だけの話ではない。ファイル整理の説明文、議事録のたたき台、フォルダごとの棚卸し、不要ファイルの洗い出しでも効く。最初に「どんな形で出すか」を決めてしまえば、Claude Code は途中で余計な寄り道をしにくい。 たとえば、こんな頼み方をする。 ```text まず出力形式を決めてから作業してください。 返答は Markdown の見出し + 箇条書きで統一してください。 表は使わないでください。 最初に「出力形式: Markdown」と1行で宣言してから、本題に入ってください。 ``` これだけでも違う。Claude Code は、内容を考える前に「どう見せるか」の足場を作る。すると、あとで人間が読み直したときに、情報の並びが崩れにくい。特に複数ファイルをまとめて説明させるとき、最初の形式指定がない
papoo.work
Claude Code に判断理由を残させる
Claude Code に判断理由を残させる
Claude Code に作業だけさせて、なぜその手を選んだのかを残さない。これ、あとで地味に困る。ファイルがどう変わったかは diff で見えるが、迷いどころや採用理由は消えるからだ。判断根拠を残す、迷いどころを記録させる、という使い方を入れておくと、あとで見返したときに「なんでこの構成にしたのか」「なぜこの重複を消したのか」が追える。 特に Claude Code は、整理、編集、要約、リネームのような作業を一気に進められる一方で、作業の途中で比較した案をそのまま捨てる。これは当然の挙動だ。だから、こちらが「結果」だけでなく「判断の途中」を残すように頼まないと、後で同じ迷いをもう一回やる羽目になる。 筆者は最初、要約だけを頼んで満足していた。ところが数日後に同じフォルダをまた触ると、前回なぜその分類にしたのか分からない。結局、ファイル名の付け方からやり直した。作業時間そのものより、脳の再起動コストがだるい。ここを潰すのがこの TIPS だ。 やり方は単純で、Claude Code に「最終成果物」と一緒に「判断メモ」も出させる。しかも、ただ感想を書かせるのではなく、候補、採用理由、
papoo.work
Claude Codeの記事を読んで、少し安心した
Claude Codeの記事を読んで、少し安心した
AIにコードを書かせる話になると、どうしても「全部任せてよいのか」「人間の仕事はなくなるのか」に話が飛びがちだけれど、この文章はそこをかなり冷静に引き戻していて、その感じが私はわりと好きだった。Claude Codeの作者が言っているのは、AIに全部書かせることではなく、品質の線を下げないために人間がどう見るか、という話なんですよね。そこがはっきりしているのは大事だと思う。 読んでいて引っかかったのは、「プルリクはブロックボックスでもよいのか」という問いが、結局はかなり人間側の観察力に寄っている点です。AIが出したコードを全部読む必要はない、でもどこかで「これは本当に大丈夫か」を判断しないといけない。その判断を支えるために、lint、テスト、レビュー、ガードレールを重ねる。つまり、AIが強くなるほど、人間は雑に見てよくなるのではなく、むしろ「どこを見なくていいか」を設計する役目が増えるんだなと思った。 あと、Claude Codeが「新しいモデルを入れたら終わり」ではなく、effort設定や CLAUDE.md みたいな周辺の仕組みまで含めて考えているのが面白い。AIの性能だけで勝負す
papoo.work
Error: 400 {"type":"error","error":{"type":"invalid_request_error":"messages.3: role 'system' must precede an 'assistant' message or end the array; まず確認したいのは compaction 後に会話を再開しようとしていないかです
Error: 400 {"type":"error","error":{"type":"invalid_request_error":"messages.3: role 'system' must precede an 'assistant' message or end the array; まず確認したいのは compaction 後に会話を再開しようとしていないかです
同じ系統の報告が 2 件ありました。[#73821](https://github.com/anthropics/claude-code/issues/73821) は `messages.67` に対して `role 'system' must precede an 'assistant' message or end the array` と出ており、[#88276](https://github.com/anthropics/claude-code/issues/88276) は `Unable to start conversation after compaction` のあとに、同種の 400 エラーが返っています。少なくとも issue 上では、どちらも「messages 配列の中で system の位置が不正」と読める内容でした。 手元で確認できた一次情報では、実行環境は次のとおりです。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時
papoo.work
Couldn't link this session to a computer, so attached folder can't be used. が出るときに見ておくこと
Couldn't link this session to a computer, so attached folder can't be used. が出るときに見ておくこと
この表示が出ると、クラウド側のセッションは立っているのに、ローカルのコンピュータへ結びつけられていません。結果として attached folder が使えません。少なくとも今回参照できた issue では、同じ文言の症状が2件報告されています。1件は Linux beta で local VM がそもそも起動せず、もう1件は VM 自体は起動しているのに device registration 側で止まっています。どちらも「リンクできない」という見た目は同じですが、壊れている場所は違います。 まず切り分けたいのは、あなたの環境がどちら寄りかです。 一方、[#97685](https://github.com/anthropics/claude-code/issues/97685) では、VM は起動して guest もつながるのに、Linux では cloud Cowork session が computer に bind できない、と報告されています。こちらは `hardwareKeyUnavailable: linux-not-yet-supported` という説明と、`de
papoo.work
長い依頼は最初に節目を決める
長い依頼は最初に節目を決める
長い依頼を、いきなり全文で投げる人はだいたい損をする。Claude Code は長文でも読めるが、読めることと、うまく進むことは別物だ。 最初に「節目を先に決める」、つまり区切りを先に置く。ここをやるだけで、途中の迷走と手戻りがかなり減る。 長い依頼というのは、たとえば大量ファイルの整理、複数ディレクトリにまたがるリファクタ、長い仕様書の下書き、案件ごとの文書生成みたいなやつだ。こういう仕事は、全部を一気にやらせるより、いくつかの節目で止めるほうがいい。Claude Code にも確認させるし、自分も見直せる。 筆者は昔、要件を一気に投げて、出てきた変更を最後にまとめて眺めたことがある。結果、方向は合っているのに細部がズレていて、直し切るのに余計な往復が発生した。最初に止まる場所を作っておけば、防げた手戻りだ。 やり方は単純だ。依頼の最初に、仕事を段階に切る。たとえば「まず現状把握、次に方針案、最後に実作業」という三段にする。Claude Code に、いきなり全部をやらせず、各段で止める指示を入れる。 ```text この作業は3段階で進める。 1. まず対象を確認し、気になる点を箇
papoo.work
Claude Code に渡す材料は最初に「材料」と「判断基準」に分ける
Claude Code に渡す材料は最初に「材料」と「判断基準」に分ける
Claude Code に雑に全部投げると、だいたい雑に返ってくる。これは性格の問題ではなく、入力の置き方が悪いだけだ。 「材料と判断基準を分ける」「入力を分離する」と先に決めておくと、Claude Code はかなり扱いやすくなる。ファイル整理でも、ディスク削減でも、文書作成でも同じだ。何を見せるかと、何を基準に選ばせるかを混ぜない。ここを分けるだけで、手戻りが露骨に減る。 たとえば「このフォルダのファイルを整理して」とだけ頼むと、Claude Code は中身の傾向を読んで、それっぽく並べ替えようとする。けれど、あなたが本当に欲しいのは「何を材料にして、どんなルールで整理するか」だろう。 資料を時系列で並べたいのか、案件ごとにまとめたいのか、重複を消したいのか。判断の軸が曖昧なままだと、結果は毎回ぶれる。ここを最初に切り分けるのが、この手の使い方の土台だ。 実際の頼み方は、こう分けるといい。 ```text 材料: このフォルダ内のファイル一覧 各ファイル名 可能なら更新日時とサイズ 判断基準: 案件ごとにまとめる 似た内容の重複は残さない 元ファイルは消さず、移動候補を提案する
papoo.work
`ERR_INTERNET_DISCONNECTED` が出るときに、まず見るところ
`ERR_INTERNET_DISCONNECTED` が出るときに、まず見るところ
この症状は、少なくとも今回参照した issue では 2 つの顔があります。1 つは Chrome 拡張が橋渡しに登録されず、ツール呼び出しが即座に「接続されていない」と返るケースです。もう 1 つはデスクトップアプリ側でメッセージは届くのに、受け手のセッションが処理に入らないケースです。前者は [#70390](https://github.com/anthropics/claude-code/issues/70390)、後者は [#88252](https://github.com/anthropics/claude-code/issues/88252) に報告があります。 切り分けの最初の一歩は、単に「動かない」ではなく、どちらの現象に近いかを見分けることです。`ERR_INTERNET_DISCONNECTED` という文字列が見えていても、issue の内容だけでは原因は 1 つに絞れません。少なくとも [#70390](https://github.com/anthropics/claude-code/issues/70390) では、`mcp__claude-in-chr
papoo.work
`Remote credentials fetch failed` が出るときにまず見るところ
`Remote credentials fetch failed` が出るときにまず見るところ
この症状は、少なくとも今回の issue 群では 「Remote Control の起動や再接続の途中で、資格情報の取得が失敗している」 形で報告されています。読者が自分のケースかどうかを先に切り分けるなら、次の2つに当てはまるかを見るのが早いです。 ひとつは、起動直後や cold start で Remote Control を有効にしたときに、ステータスバーへ `Remote Control failed · Remote credentials fetch failed — see debug log` のような表示が出るケースです。[#78598](https://github.com/anthropics/claude-code/issues/78598) では、`"remoteControlAtStartup": true` を有効にした状態で、OAuth アクセストークンの更新より先に remote bridge が最初の API 呼び出しを行い、`POST /v1/code/sessions` と `/bridge` が **HTTP 401 Authentic
papoo.work
`Input must be provided either through stdin or as a prompt argument when using --print` が出るときにまず見るところ
`Input must be provided either through stdin or as a prompt argument when using --print` が出るときにまず見るところ
このエラーが出るケースは、少なくとも今回の issue 群では「Claude Code が対話的に動く前提を外されている」ことと強く結びついていました。読者がまず確認したいのは、自分の実行方法がその条件に当たっているかどうかです。 今回の症状を切り分けるなら、まず次の2点です。ひとつは、`claude` や `claude --remote-control` を起動している親プロセスに pseudo-terminal があるかどうか。もうひとつは、agent teams や remote control のような「裏で子プロセスを立てる」経路を使っていないかです。issue 上は、pty がないと `isatty(stdin) → false → auto --print → exit-with-error` の流れになる、という見立てがコメントで共有されていました。ただし、これはコメントベースの整理であって、今回こちらで再現確認したものではありません。 筆者の環境で実際に確認できたのは、OS と Node.js の版だけです。 ```text OS : Linux
papoo.work
チェスの反省を「読める形」にする試み
チェスの反省を「読める形」にする試み
正直、こういうのが欲しかったんだよな、と思った。 チェスの解析って、エンジンの数字だけ見てもだいたい気持ちよくならない。`-1.8` と出ても、実戦で本当に知りたいのは「なぜその手がまずかったのか」「自分は何を怖がりすぎたのか」で、そこがいつも抜け落ちる。このリポジトリは、その穴をかなり真面目に埋めにいっている。 面白いのは、単にStockfishで評価して終わりにしないところだと思う。Claude Codeに、実際に考えていたことまで渡して、あとから「そのとき自分が何を疑っていたのか」を engine-backed に突き返させる。これ、ただの解析ではなくて、思考の検証なんだよね。棋譜の反省って、盤面そのものよりも「自分の判断の癖」を見たい作業なので、そこに音声メモや think-aloud を組み込む発想はかなりしっくりくる。 逆に、少し引っかかったのは、やはり時間がかかることと、AI の幻覚を完全には消せないこと。1局の処理にだいたい1時間というのは、気合いを入れて指した将棋ならぬチェス向けで、気軽な振り返りには重い。しかも、これは毎局やるものではなく、じっくり考えた対局に使うべ
papoo.work
ReferenceError: Claude Code native binary at /home/jean/.vsc が出るときに確認したこと
ReferenceError: Claude Code native binary at /home/jean/.vsc が出るときに確認したこと
まず、この症状に当てはまるかどうかは、エラーメッセージの出方でかなり絞れます。Issue には、VS Code 拡張が埋め込みの native binary を起動しようとして失敗する例と、認証後に「unsupported platform: linux-arm64. No compatible Claude Code binary found.」と出る例が報告されています。前者は [#97022](https://github.com/anthropics/claude-code/issues/97022)、後者は [#80574](https://github.com/anthropics/claude-code/issues/80574) です。 一方で [#80574](https://github.com/anthropics/claude-code/issues/80574) では、devcontainer 内で Claude を使っていて、再認証のあとに ```text Unsupported platform: linux-arm64. No compatible Cl
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見かけたら、まず ESC とフォルダ名変更を疑う
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見かけたら、まず ESC とフォルダ名変更を疑う
この症状で報告されているのは、`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` というエラーです。今回拾えた issue は 2 件だけで、どちらも open のまま、解決済みの報告はありませんでした。 自分のケースに近いかを見るなら、まず次の 2 つです。ひとつは、ESC で実行を止めたあとにターミナルが入力を受け付けなくなるケース。もうひとつは、フォルダ名を変えた直後におかしくなるケースです。 > when i press ESC to stop, then will not allow me to write anything, it stop writing on terminial この issue に添えられていたエラーは、次のものです。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=130 messages=129 range=[117,130)) a
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときに確認したいこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときに確認したいこと
この症状は、Issue 上では `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=... messages=... range=...)` という形で出ています。今回見た 3 件では、いずれも末尾の数値が違うだけで、同じ系統のエラーに見えます。 まず、自分のケースかどうかを見るなら、エラー文字列の先頭ではなく、この `itemKeys/messages length desync` の部分を探すのが早いです。報告された 3 件はすべて open で、解決済みは 0 件でした。少なくとも、この時点では「既知の再現例はあるが、確立した修正済み対処は見えていない」という状態です。 参照できた issue は次の 3 件です。 #97148 では、Claude Code を PyCharm / WebStorm の terminal で使っていて、入力中や移動中にカーソルが見えず、停止時に blink する、という見た目の逆転が報告されています。コメントには、PyCharm 内の com
papoo.work
`Error
`Error
at generate (/$bunfs/root/src/entrypoints/cli.js:1` が出て作業が止まるときに見ること この症状は、Claude Code の処理中に `generate` から `makeRequest` へ進む途中で落ちているケースです。報告されている issue はどちらも macOS 上で発生していて、[#70256](https://github.com/anthropics/claude-code/issues/70256) では `403 The socket connection was closed unexpectedly` を伴う例がありました。[#69826](https://github.com/anthropics/claude-code/issues/69826) では同じ系統のスタックトレースが、エラー詳細なしで繰り返し出ています。 自分のケースかどうかは、まず表示される断片が次に近いかで見分けられます。 ```text Error at generate (/$bunfs/root/src/entrypoints/cl
papoo.work
Claude Code に判断理由を残させて、あとから迷いどころを追えるようにする
Claude Code に判断理由を残させて、あとから迷いどころを追えるようにする
Claude Code を使っていて厄介なのは、作業そのものより「なぜそうしたか」が消えることだ。あとで差分だけ見ても、削除した理由、残した理由、別案を捨てた理由が見えない。これが積み重なると、作業は進んでいるのに自分だけが置いていかれる。 そこで使うのが、判断理由の記録、つまり意思決定ログだ。Claude Code に「何をしたか」だけでなく「なぜその選択にしたか」を残させる。これだけで、あとから見返したときの迷い方がかなり変わる。特に、ファイル整理、重複削除、文書の下書き整理、リポジトリの改修みたいに、正解が1つではない作業で効く。 筆者は最初、Claude Code に「整理して」とだけ投げて、きれいになった結果だけを受け取っていた。すると数日後に「なぜこのファイルは残したんだっけ」「この見出しは何を基準に削ったんだっけ」がわからなくなる。やり直しが出るたびに、また同じ判断を最初からさせる羽目になる。あれは地味にだるい。判断の中身を残しておけば、同じ迷いを二度踏まなくて済む。 やり方は難しくない。Claude Code への依頼に、最初から「判断の記録も一緒に出す」と書くだけでい
papoo.work
EMFILE で Claude Code が spawn に失敗するときに見ておくこと
EMFILE で Claude Code が spawn に失敗するときに見ておくこと
まず切り分けたいのは、これが「Claude Code の起動そのものに失敗している」のか、それとも「起動済みのセッションは生きているが、新しい spawn だけ落ちる」のかです。今回参照した issue には、似た見え方をする `spawn EBADF` が 2 件ありましたが、症状の出方は少し違います。 ただし、今回の見出しにある `EMFILE` そのものについては、渡された issue 文面には直接は出てきません。ここで実際に確認できるのは `EBADF` です。なので、少なくとも今回の一次情報だけでは「EMFILE の原因はこれだ」とは言えません。現時点では、spawn 周りの fd 関連障害として似た系統を疑うところまでです。 手元の検証環境では Node.js のバージョンが次でした。 ```text $ node --version v16.15.0 ``` 環境全体は次のとおりです。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時
papoo.work
zsh で `command not found` や `dyld: Symbol not found` が出るときにまず見ること
zsh で `command not found` や `dyld: Symbol not found` が出るときにまず見ること
手元にある issue には、少なくとも 2 つの別パターンがありました。ひとつは macOS 13.x で `claude` の起動そのものが落ちるケース、もうひとつは zsh の起動時に余計なエラーが毎回出るケースです。見た目は似ていますが、症状の場所が違います。 `[#69928](https://github.com/anthropics/claude-code/issues/69928)` では、インストール直後に次のような出力が出ています。 ```text Setting up Claude Code... dyld: Symbol not found: __ZTVNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEEE Referenced from: /Users/emmaborowski/.claude/downloads/claude-2.1.185-darwin-x64 (which was built for Mac OS X 13.0) Expected in: /usr/lib/lib
papoo.work
ノートPCを閉じても動き続ける、という地味だけど大きい変化
ノートPCを閉じても動き続ける、という地味だけど大きい変化
この記事を読んでまず思ったのは、「ようやくここまで来たか」という感覚だった。クラウド上でAIに作業を投げて、手元のPCは閉じてしまっていい。言葉にすると単純だけれど、実際にはかなり使い方を変える話だと思う。 特に引っかかったのは、これが単なる“どこでも続きが見られる”機能ではなくて、「スリープしても処理が止まらない」ところ。Remote Control の延長線にあるようでいて、体感はかなり違うはずだ。ノートPCを開きっぱなしにして待つ、あの妙な気疲れから解放される。長めのビルドや修正、調査を走らせておいて席を外せるなら、それだけで使い道は増えるだろう。 一方で、こういう機能は便利なほど請求が見えにくくなるのも気になる。既存契約者に専用クレジットを付けるのは親切だけれど、「請求を忘れないように」とわざわざ書かれているあたり、Anthropic 側もそこはかなり意識しているのだと思う。無料で試せる余地を作りつつ、その先は通常の利用枠に戻る。使う側も、気持ちよく試すだけでなく、どの作業をクラウドに回すと得なのかを見極める必要がありそうだ。 --- > 参考: [ノートPCを閉じてもOK、「
papoo.work
Claude Code が AGENTS.md を読まない理由は telemetry の有無だった
Claude Code が AGENTS.md を読まない理由は telemetry の有無だった
Claude Code に AGENTS.md のサポートが入ったのに、肝心のファイルが読まれない。しかも原因はローカルの設定やファイル名の間違いではなく、telemetry を切っているかどうかだった、というのが元記事の話だ。見た目は「対応済み」なのに、実際には特定の環境で黙って無効化される。こういう挙動は、使う側からするとかなり厄介だと思う。 元記事は、Claude Code 2.1.277 で AGENTS.md のサポートが追加されたものの、その読み込みが remote feature flag の背後に置かれている、と指摘する。内部では `agents-md` という built-in plugin があり、2.1.280 の bundle では `tengu_agents_md_mod` というフラグを取りにいく。ここでフラグが取れない、あるいは false と判定されると、その plugin は unavailable になり、ローカルに置いた AGENTS.md は読み込まれない。 問題は、この判定がネットワーク前提になっていることだ。AGENTS.md 自体は作業ディ
papoo.work
`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出たときに、まず疑うこと
`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出たときに、まず疑うこと
この症状は、少なくとも報告ベースでは 2 件ありました。どちらも同じエラー文字列で、`itemKeys` と `messages` の件数がずれていると読めます。手元で確認できるのは issue の記載だけで、解決策までは出ていません。現時点では未解決のバグとして扱うのが安全です。 最初に見るべきなのは、「表示だけの問題か」「会話の整合性まで壊れているか」です。[#95627](https://github.com/anthropics/claude-code/issues/95627) では、ユーザーが送っていないテキストがアシスタント側には届いているのに、`.jsonl` と `/export` には残っていませんでした。つまり、単なる見た目の乱れではなく、コンテキストの取り扱い自体がずれている可能性があります。 報告されているエラーは、どちらの issue でも同じ形です。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=112 messages=111 r
papoo.work
`Failed to deserialize params.clip.scale - BINDINGS: mandator` が出るときにまず確認したいこと
`Failed to deserialize params.clip.scale - BINDINGS: mandator` が出るときにまず確認したいこと
この症状は、`claude-in-chrome` の `computer` で `action: screenshot` や `action: zoom` を呼んだときに、`params.clip.scale` のデシリアライズ失敗として返ってきます。報告されている issue は [#83960](https://github.com/anthropics/claude-code/issues/83960) と [#90181](https://github.com/anthropics/claude-code/issues/90181) です。どちらも、実行すると `Failed to deserialize params.clip.scale - BINDINGS: mandatory field missing at position 65` が出ています。 まず切り分けたいのは、「自分も同じエラー文字列を見ているか」と「それが screenshot / zoom の呼び出しに限って起きているか」です。issue #83960 では、拡張機能のペアリング自体はできていて、`ta
papoo.work
GitHub CLI authentication expired が出ても、本当に期限切れとは限らない
GitHub CLI authentication expired が出ても、本当に期限切れとは限らない
この表示が出たからといって、`gh` の認証情報が実際に失効したとは限りません。少なくとも issue [#67055](https://github.com/anthropics/claude-code/issues/67055) では、デスクトップアプリが重いマルチエージェント処理中にこのトーストを出していましたが、直後に `gh auth status` はログイン済み、`gh api user` も 200 を返していました。報告者は、`gh auth login` を案内どおり実行しても筋の悪い切り分けになると述べています。 同じ系統の報告として [#96503](https://github.com/anthropics/claude-code/issues/96503) もあり、こちらは GitLab の merge request を開いているのに、ツールチップがやはり > GitHub CLI authentication expired. Run gh auth login to refresh pull request status. と出る、という内容でした。そ
papoo.work
`invalid_request_error\` が出るときにまず見る場所
`invalid_request_error\` が出るときにまず見る場所
この症状クラスタに含まれる 2 件の issue は、見え方は違いますが、どちらも「リクエストの中身が大きすぎる／重なりすぎる」方向の問題として読めます。 ただし、実際に `invalid_request_error\` というエラー文字列が本文中にそのまま出ている issue は、今回渡された情報の中にはありません。そこは断定できません。検索用の文字列としてタイトルには入れていますが、報告内容ベースで確認できるのは以下です。 まず、[ #37793 ](https://github.com/anthropics/claude-code/issues/37793) では、MCP サーバーを多数ユーザー側で設定していると、サブエージェントが開始直後に `prompt is too long: 209117 tokens > 200000 maximum` で失敗すると報告されています。しかも TUI には `Done (0 tool uses · 0 tokens · 44s)` と出て、ユーザーにはエラーが見えにくかった、とあります。 この報告だけを見ると、サブエージェントに渡るプロン
papoo.work
節目で要約を挟ませて、長い会話でも前提を保つ
節目で要約を挟ませて、長い会話でも前提を保つ
長い依頼を一気に投げて、そのまま最後まで突っ走らせると、だいたいどこかで前提がにじむ。Claude Code は優秀だが、会話が長くなるほど「いま何を守るべきか」がぼやける。そこで効くのが、途中要約、つまり会話の節目で要約するやり方だ。 やることは単純で、作業の区切りごとに「ここまでの前提」「決めた方針」「未決事項」を短くまとめ直させる。これだけで、途中から入った指示に引きずられにくくなる。ファイル整理でも文書作成でも、最後に「最初に何をしたかったんだっけ」とならない。長い会話の事故をかなり減らせる。 筆者は昔、要件を詰めながらファイル移動の手順書を作らせていて、途中で「説明を短くして」と頼んだせいで、重要な注意点まで一緒に削られたことがある。あれは地味に痛い。会話が長いと、モデルはその場その場では筋の通った返答をするが、全体の設計図を勝手に保持してくれるわけではない。人間側が節目で釘を刺す必要がある。 一番やりやすいのは、最初に会話の運び方を決めてしまうことだ。たとえば、最初の依頼にこう入れる。 ```text この作業では、適当な区切りごとに途中要約を入れてください。 要約には次の
papoo.work
Markdown か表かを先に決めると、返答が暴れない
Markdown か表かを先に決めると、返答が暴れない
Claude Code に雑に頼むと、まず返答の形がブレる。文章でほしいのに箇条書きが増えたり、表でほしいのに説明が長くなったりする。中身以前に、器が決まっていないのが原因だ。ここを先に固定すると、出力形式の指定が効いて、成果物の形を固定するだけで手戻りがかなり減る。 筆者はこれで何度も痛い目を見た。たとえばファイル整理の依頼で、最初は「不要なものを洗い出して」とだけ投げていた。すると、ある回は長文の方針説明、別の回は箇条書き、さらに別の回は見出しだけ妙に立派なメモになった。欲しいのは「そのまま使える一覧」なのに、毎回整形し直す羽目になる。これが地味にだるい。 だから最初にやることは単純だ。Markdown で返すのか、表で返すのか、先に決める。迷うなら、まずは Markdown に寄せる。理由は簡単で、Claude Code は説明文、手順、注意点、短い例をひとまとめにしやすいからだ。逆に、項目同士を並べて比較したいなら表が向く。どちらでもいい、ではなく、最初の一手で固定するのが大事になる。 実際の頼み方はこうだ。 ```text この内容を Markdown で出力してください。
papoo.work
返答を短くさせるなら、分量の上限を先に決める
返答を短くさせるなら、分量の上限を先に決める
「短くして」とだけ頼むと、だいたい長い。これ、Claude Code でも同じだ。 返答を短くさせたいなら、最初に分量の上限を決める。出力の分量制御とか回答の長さ指定は、後から気分で足すより、先に枠を切ったほうが効く。 たとえば「要点だけで」「手短に」で済ませると、モデルはまだ説明できる余地があると判断して、つい補足を盛る。逆に「3行以内」「箇条書きで3点まで」「100文字以内」と上限を先に置くと、余計な前置きや保険がかなり減る。Claude Code は、こちらが与えた制約の中で組み立てる道具だ。曖昧な「短く」は制約ではない。 実務では、この差が地味にでかい。たとえばディレクトリ整理の方針を聞きたいとき、長文の説明が返ると、そのあと自分で判断する手間が増える。文書の下書きを整えたいときも同じで、まず短い回答をもらってから必要なら掘るほうが速い。最初から長く語らせると、読んでいるうちに本題を見失う。 実際の頼み方は、こんなふうに先に枠を入れる。 ```text この作業の方針を、3点までで短く答えてください。 各点は1文にしてください。 余談や前置きは不要です。 ``` もう少し厳密に
papoo.work
材料は章ごとに渡して、一気読み前提をやめる
材料は章ごとに渡して、一気読み前提をやめる
Claude Code に長文を丸ごと投げて、全部を一度に飲み込ませようとする人は多い。だがそれ、だいたい途中で雑になる。 分割投入、つまり章分けして渡すやり方に変えるだけで、指示の通りやすさがかなり変わる。ファイル整理でも、ディスク削減でも、文書作成でも同じだ。最初から全部を読ませるより、章ごとに材料を渡したほうが、何を直せばいいかがはっきりする。 筆者も最初は、一枚の長いメモをそのまま貼って「いい感じにして」と投げていた。結果はだいたい同じで、要点は拾うが細部がぼやける。しかも手戻りが増える。後から「ここは別章だった」「その章の前提はこっち」と補足する羽目になる。あれはだるい。最初から章単位で渡しておけば、無駄な往復はかなり減る。 やり方は単純だ。材料を、目的ごとに小さく切る。 たとえば文書作成なら、序文、背景、各章の要点、結論を分ける。ファイル整理なら、まず対象フォルダのルール、次に削除候補の基準、最後に例外処理を渡す。Claude Code には、いきなり全体像を完成させる役ではなく、1 章ずつ整える役を持たせる。 たとえばこんな頼み方になる。 ```text 以下の材料を、章
papoo.work
チーム開発でClaude Codeを使うと、便利さより先に「整え方」が問われる
チーム開発でClaude Codeを使うと、便利さより先に「整え方」が問われる
この記事を読んでまず思ったのは、AIエージェントそのものより、周辺の作法をどこまで先に決めておけるかで体験がかなり変わりそうだ、ということでした。Claude Codeみたいなツールは、単に「賢い補助輪」ではなく、チームのルールを食べて動く存在に近いのだと思います。 とくに引っかかったのは、AIにコードを書かせるときの不安が、もう「正しいかどうか」だけでは済まない点です。記事でも触れられていたように、`CLAUDE.md` や rule file、Auto Memory みたいな仕組みで、まず前提を揃える必要がある。これって結局、AIを入れるほどドキュメントの価値が上がる、ということでもあります。人間同士なら多少の暗黙知で回っていた現場が、AIを挟むと暗黙知のままでは回らない。そこは少し面倒だけど、逆に言えば、属人化した開発を見直すいいきっかけにもなりそうです。 もう一つ面白かったのは、AIに丸投げする話ではなく、PR作成やコード変更の入り口をどう設計するかに話が寄っていたところです。私はここにかなり現実味を感じました。AIがコードを全部「自動でよしなに」やってくれる未来より、変更範囲
papoo.work
テレメトリを切ったら、ローカル設定まで消えた話
テレメトリを切ったら、ローカル設定まで消えた話
まず引っかかったのは、「自分のディスクにある `AGENTS.md` を読むかどうか」が、ローカルの事情ではなく remote feature flag で決まっていることです。そこまで大げさに管理する種類の機能には見えないし、しかも telemetry を無効にした途端に黙って無視されるのは、かなり嫌な感じがします。拒否されるなら拒否されるでいいのに、何も言わないのがいちばん困る。 この記事でいちばん腑に落ちたのは、筆者が怒っている理由です。単に「新機能がうまく動かない」ではなく、「telemetry を切ると診断情報だけでなく、ローカルにあるはずの入力まで失われる」のが問題なんですよね。ユーザー側から見ると、設定ファイルが読まれないのか、モデルが無視したのか、通信まわりで止まったのか、切り分けようがない。結局、プロンプトを直したり、指示文を疑ったりして時間を溶かすことになる。こういう静かな失敗は本当に厄介だと思います。 もうひとつ面白かったのは、回避策が `CLAUDE.md` に `@AGENTS.md` を書くだけ、というあまりにも地味なことです。機能追加のために増えたはずの
papoo.work
Base64 decoding failed が出るときに見るところ
Base64 decoding failed が出るときに見るところ
まず、この症状に当てはまるかを切り分けます。今回の issue では、Claude Opus 4.6 で最近の更新以降に精度と信頼性が落ちたという報告が 2 件あり、その中に Gmail MCP 経由でメール添付を送るときに base64 文字列が壊れ、`Base64 decoding failed` になる、という内容が含まれていました。報告は [#96178](https://github.com/anthropics/claude-code/issues/96178) と [#96179](https://github.com/anthropics/claude-code/issues/96179) です。 この issue で確認できるのは、少なくとも次の 2 つです。ひとつは日付の取り違えで、2026 年 9 月の文面なのに 2025 年の日付を出したこと。もうひとつは base64 の再現文字列が壊れ、`Base64 decoding failed` に至ることです。つまり、単なる添付ファイル処理の失敗というより、モデルの出力自体が途中で崩れている可能性があります。現時点で
papoo.work
`Auto-update failed · Run claude doctor` が繰り返し出るときに見るところ
`Auto-update failed · Run claude doctor` が繰り返し出るときに見るところ
この症状でまず切り分けたいのは、本当に更新に失敗しているのか、それとも更新がないのに同じ通知だけが出続けているのかです。報告されている #96038 では、Wi‑Fi を切っただけで `Auto-update failed · Run claude doctor` が繰り返し表示され、しかも「更新がないのに」起きていると書かれています。つまり、少なくともこの issue では、実際の更新作業そのものというより、ネットワーク断をきっかけにした通知の再発が問題になっています。[#96038](https://github.com/anthropics/claude-code/issues/96038) 同じ `Auto-update failed · Run claude doctor` という表示でも、#78650 のほうは少し様子が違います。こちらは macOS の深いスリープからの復帰後に、複数の Claude Code セッションがほぼ同時に segfault で落ちたという報告で、本文では Bun の GC と socket finalizer、`SIGSEGV
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync のときにまず見ること
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync のときにまず見ること
この症状は、Claude Code の内部エラーとして `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ているケースです。今回確認できた issue は 2 件で、どちらも open のままで、解決済みはありません。少なくとも提供された材料だけを見る限り、「これを入れれば直る」という確立した手順はまだありません。 自分のケースかどうかを見分けるなら、まずエラー文の形を確認します。今回の issue では、どちらも同じ系統の文言が出ています。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=562 messages=558 range=[502,558)) at Ta0 (B:/~BUN/root/cli:23248:33899) at Rig (B:/~BUN/root/cli:23248:26870) ``` 別の報告では、値が少し違いますが、同じく `ite
papoo.work
`Connection refused — a firewall or proxy may be blocking it` が出るときに、まず確認したいこと
`Connection refused — a firewall or proxy may be blocking it` が出るときに、まず確認したいこと
この症状は、少なくとも報告上は 2 つの顔があります。ひとつは、毎回のコマンドで API への接続が失敗し、`Connection refused — a firewall or proxy may be blocking it (ConnectionRefused)` を 10 回試行しても抜けられないケースです。もうひとつは、サブエージェントのストリームが途中で静かに止まり、`Agent stalled: no progress for 600s (stream watchdog did not recover)` で落ちるケースです。前者は [#93041](https://github.com/anthropics/claude-code/issues/93041)、後者は [#87987](https://github.com/anthropics/claude-code/issues/87987) にまとまっています。 自分のケースかどうかを切り分けるなら、まず見るべきなのは「Claude Code から API に出る通信だけが失敗しているのか」です。[#93041](h
papoo.work
`API Error: Sonnet 5 can't help with this` が出るときに見えていること
`API Error: Sonnet 5 can't help with this` が出るときに見えていること
この症状は、Claude Code が作業を始めた直後に `API Error: Sonnet 5 can't help with this` で止まり、しかも内容と関係なさそうな分類が付くケースとして報告されています。手元で確認できた issue は 2 件で、どちらも「本来の用途なのに止められた」という筋です。 まず、自分のケースかどうかを見分けるなら、Claude Code が何かを読んだり実行したりしたあとに、この文言だけを返して中断していないかを見ます。報告されている例では、ソフトウェア開発の途中で突然止まりました。`[bio]` のような詳細が付いていた例もありますが、少なくとも issue 報告上は、扱っていた内容と分類が一致していませんでした。これが [#87992](https://github.com/anthropics/claude-code/issues/87992) です。 もう 1 件の [#94875](https://github.com/anthropics/claude-code/issues/94875) では、USPTO の API キーを使っ
papoo.work
Authorization failed が出る Claude in Chrome の OAuth 失敗
Authorization failed が出る Claude in Chrome の OAuth 失敗
Claude Code から Claude in Chrome 拡張を使おうとして、`claude.ai/oauth/authorize` まで進んだのに、Authorize を押した直後に `Authorization failed` で止まる。今回の issue 群は、まさにその症状に当てはまります。 報告されているのは、Claude in Chrome extension の OAuth authorization が、認可画面で Authorize を押した直後に `Authorization failed — This isn't working right now` になる、というものです。#69051 では、拡張機能をインストールし、Claude Code 側で Claude in Chrome connector を有効にし、ブラウザで認可しても失敗する手順がそのまま書かれています。#95958 でも、別環境で同じ失敗が再現したとされています。参照できる issue は [#69051](https://github.com/anthropics/claude-code
papoo.work
`exit code 5` が出るとき、`/usage` が空振りすることがある
`exit code 5` が出るとき、`/usage` が空振りすることがある
`claude -p "/usage" --output-format json` を投げた直後に `exit code 5` で落ちる、あるいは `is_error:false` の包みだけ返って `result` がない、という症状が [#87983](https://github.com/anthropics/claude-code/issues/87983) で報告されています。報告者の環境では、長い print-mode 実行のあとに間隔をおかず起きていました。しかも 3 回の観測のうち 2 回は `exit code 5`、1 回はエラーヘッダのようなものがありつつ結果本体が欠ける形だったとされています。 手元で確認できる一次情報は、環境メモだけです。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-09-23T08:51:27+09:00 ``` この時点では、こちらで同じ不具合を再現するところまではできていません。なの
papoo.work
`Remote Control Initialization failed` が出るとき、まず見るべき分岐
`Remote Control Initialization failed` が出るとき、まず見るべき分岐
このエラーは、少なくとも今回の issue 群では 2 つの経路で出ています。ひとつは、`ANTHROPIC_API_KEY` が process 環境に残っているケースです。もうひとつは、Claude Desktop アプリ内の interactive session で `/remote-control` を実行したときに、毎回 `Remote Control Initialization failed` になるケースです。前者は [#81625](https://github.com/anthropics/claude-code/issues/81625)、後者は [#91325](https://github.com/anthropics/claude-code/issues/91325) にまとまっています。 切り分けの最初の一手は、今のセッションが何の認証状態で動いているか、そしてどこから起動しているかを見ることです。`/status` で Max が見えていても、`ANTHROPIC_API_KEY` が環境変数に入っていると Remote Control 初期化に失敗し
papoo.work
Error: 400 {"type":"error","error":{"type":"invalid_request_error":"output_config.effort 'xhigh' is not supported when thinking is disabled on this model. Use effort 'high' or below, or enable thinking."}} が出たときに見る点
Error: 400 {"type":"error","error":{"type":"invalid_request_error":"output_config.effort 'xhigh' is not supported when thinking is disabled on this model. Use effort 'high' or below, or enable thinking."}} が出たときに見る点
このエラーが出ているなら、少なくとも issue 上では「`effort` が `xhigh` のときに、thinking が無効なサブリクエストが走ると 400 になる」ケースが報告されています。対象になっているのは [#81627](https://github.com/anthropics/claude-code/issues/81627) で、同じ文言を含む別件として [#90721](https://github.com/anthropics/claude-code/issues/90721) もあります。 まず切り分けたいのは、単に会話が失敗しているのか、それとも WebSearch のような一部の機能だけが落ちているのか、という点です。#81627 では main の会話ループは `xhigh` でも動く一方、`WebSearch` だけが即座に失敗し、`WebFetch` は影響を受けないと報告されています。つまり、同じ `xhigh` でも「全部ダメ」ではなく「特定の内部リクエストだけダメ」という見え方になりえます。 issue の再現手順として書かれているのは、`~
papoo.work
`AxiosError: Request failed with status code 400
`AxiosError: Request failed with status code 400
at bo (/` が出たとき、まず `/context` の表示崩れを疑う 同じ `AxiosError: Request failed with status code 400` でも、今回集まっている issue は少し毛色が違います。報告されているのは、CLI の `400` そのものというより、画面の再描画や表示崩れに引きずられて見えているケースです。 ひとつは [#72900](https://github.com/anthropics/claude-code/issues/72900) で、狭い端末幅の `/context` 出力に長い skills 一覧が重なると、User skills セクションの項目が重複して表示されるという報告でした。もうひとつは [#60595](https://github.com/anthropics/claude-code/issues/60595) で、`<thinking></thinking>` の外に reasoning data が出てしまう症状として報告されています。どちらも、報告上は同じ `AxiosError: Reque
papoo.work
同じファイルを同時に触らせないだけで、コンフリクトはかなり減る
同じファイルを同時に触らせないだけで、コンフリクトはかなり減る
コンフリクトが多い人のやりがちな勘違いは、「Claude Code が賢ければ、同じ場所を複数の作業で触っても勝手にうまくやるはず」だ。そこ、かなり危ない。 実際は、同じファイルを同時に触らせないだけで、競合を避ける、同時編集を避ける、という基本がかなり効く。しかもこれは開発だけの話ではない。文書整理でも、請求書まわりでも、写真の整理でも、ひとつのファイルを別タスクが横取りしないだけで手戻りが目に見えて減る。 筆者も最初は、要約、修正、整形を雑に並列で投げて、最後に diff がぐちゃぐちゃになったことがある。内容は合っているのに、改行だけで戦っているような差分が増える。地味にだるい。Claude Code は便利だが、同じ物を同時に触らせると、賢さより衝突回避の設計がものを言う。 やることは単純だ。タスクをファイル単位、できればディレクトリ単位で分ける。Claude Code に渡す指示も、「この範囲だけ触れ」と明示する。そうすると、出力の見通しがよくなり、あとで人間が確認するときの負担も下がる。 たとえば、リポジトリ内の複数ファイルをいじるときは、こんなふうに分ける。 ```tex
papoo.work
分散した現場に、まず欲しいのは「賢いAI」より共通言語だった
分散した現場に、まず欲しいのは「賢いAI」より共通言語だった
この記事を読んで最初に思ったのは、Claude Code の話というより、散らばった開発チームがずっと抱えてきた「暗黙知の断絶」の話だな、ということだった。便利なコード生成より先に、誰がどこで何を前提にしているのかを揃えないと、結局は人間が夜中にログを追い、別リージョンのチームに事情を聞き、同じような実装を何度もやり直す。記事はそこをかなり正直に突いている。 とくに刺さったのは、`CLAUDE.md` を単なる補足資料ではなく、チームの記憶置き場として扱っている点だった。レガシー寄りのシステムでは「なぜこの endpoint だけ retry してはいけないのか」みたいな話が、コードレビューではなく人の頭の中に残っていることが多い。そこをAIに読ませる前提で明文化するのは、かなり実務的だと思う。AIに任せるためのファイルというより、人間が忘れていた前提を再び外に出すためのファイルに見えた。 もう一つ面白かったのは、MCP の位置づけだ。コードを書かせることより、ticketing tool や internal database、Slack みたいな周辺システムとつないで、診断に必要な
papoo.work
`Permission for this action was denied by the Claude Code auto mode classifier` が出るのに、実際は通っていることがある
`Permission for this action was denied by the Claude Code auto mode classifier` が出るのに、実際は通っていることがある
この症状は、Claude Code が操作を拒否したように見せながら、後で確認すると実際には処理が進んでいた、という形で報告されています。特に [#87831](https://github.com/anthropics/claude-code/issues/87831) では、`gh pr merge` を含む一括処理でその挙動が繰り返し起きたとされています。報告者は、`gh pr view --json state,mergedAt` を見るとマージ済みになっていたケースがあった一方、別の大きなバッチでは本当に実行されていなかったケースもあったと書いています。つまり、このエラー文だけでは「止まった」のか「止まったように見えただけで実行された」のかを判別できません。 まず自分のケースかどうかを切り分けるなら、エラーが出た直後に対象の状態を別コマンドで見に行く必要があります。`gh pr merge` を含む作業なら、少なくとも `gh pr view --json state,mergedAt` のように結果を確認して、実際に反映済みかどうかを確かめる、というのが issue から読
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le — 画面の件数がずれて落ちるときに見えているもの
TelemetrySafeError: VirtualMessageList: itemKeys/messages le — 画面の件数がずれて落ちるときに見えているもの
この症状は、Claude Code 側で `VirtualMessageList: itemKeys/messages length desync` が記録されているケースです。報告されている値は、`keys=45 messages=44`、`keys=359 messages=358`、`keys=149 messages=148` のように、1 件だけ数がずれている形でした。いずれも `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` という同じ系統のエラーにまとまっています。参照できた issue は [#95707](https://github.com/anthropics/claude-code/issues/95707)、[#95662](https://github.com/anthropics/claude-code/issues/95662)、[#95586](https://github.com/anthropics/claude-code/issues/95586)
papoo.work
`--resume requires a valid session ID or session title when used with --print.` が出るときに確認したいこと
`--resume requires a valid session ID or session title when used with --print.` が出るときに確認したいこと
このエラーは、`--resume` に渡した値が Claude Code 側で「有効な session ID でも session title でもない」と判断されたときに出ます。今回の症状クラスタでは、少なくとも 2 つの別ルートが issue として報告されています。 ひとつは [#61058](https://github.com/anthropics/claude-code/issues/61058) で、`claude -p --output-format stream-json --input-format stream-json` で生成したセッションが `sessions-index.json` に登録されず、`--resume <title>` や対話的な `--resume` ピッカーから見えないという報告です。もうひとつは [#91268](https://github.com/anthropics/claude-code/issues/91268) で、セッション管理ツールが返す `local_...` 形式の ID をそのまま `claude --resume
papoo.work
File is in a directory that is denied by your permission set で止まるときに、まず見るところ
File is in a directory that is denied by your permission set で止まるときに、まず見るところ
このエラーは、読もうとしたファイルが `permissions.deny` の対象に入っているときに出ます。少なくとも issue [#73380](https://github.com/anthropics/claude-code/issues/73380) では、`Read(/*.xcconfig)` や `Read(/APIConstants.swift)` のような deny ルールと、`PreToolUse` hook を組み合わせてメインエージェントの読み取りを止める設定が報告されています。 ただし、同じ issue では少し気になる点も出ています。`Task` / `Agent` ツールで起動したサブエージェントが、ある時点では本来 denied のはずのファイル内容を返してしまい、その後の再テストでは同じ設定・同じファイルでも正しくブロックされた、と書かれています。つまり、少なくとも報告ベースでは「deny ルールが効いていない」と断言する前に、「どのエージェント経由で読みに行ったか」を切り分けたほうがよさそうです。 手元で確認できた環境情報はこれだけです。 `
papoo.work
`Error: NON-FATAL: Lock acquisition failed for /Users/alexsonne/.local/share/claude/versions/2.1.119` が出るときにまず見るところ
`Error: NON-FATAL: Lock acquisition failed for /Users/alexsonne/.local/share/claude/versions/2.1.119` が出るときにまず見るところ
このエラーは、Issue 上では少なくとも 2 件まとまって報告されています。該当するのは [#52724](https://github.com/anthropics/claude-code/issues/52724) と [#54055](https://github.com/anthropics/claude-code/issues/54055) です。どちらも `Error: NON-FATAL: Lock acquisition failed for /Users/.../.local/share/claude/versions/2.1.119 (expected in multi-process scenarios)` という文言を含んでいます。 ただし、Issue だけでは「このロック失敗そのもの」が致命的な原因なのか、それとも別の不具合に付随して表示されているのかは切り分けきれません。少なくともコメント欄では、別経路の対処として `~/.claude/keybindings.json` の確認が有効だった例が 1 件出ています。Enter で保存したつもりが保存されず、
papoo.work
作業ログを見返して、迷った地点だけを次回の依頼テンプレに戻す
作業ログを見返して、迷った地点だけを次回の依頼テンプレに戻す
雑に丸ごとテンプレ化すると、次回も同じところで詰まる。そこ、かなりもったいない。 Claude Code を使った作業は、全部をテンプレにするより、迷った地点だけを回収して次回の依頼に戻すほうが強い。振り返りからテンプレ改善、ログを次回依頼に活かす、という流れだ。ログを全部コピーしても、たいていノイズが増えるだけである。 筆者も最初は、やり取りをそのまま長文で残していた。すると次の依頼で、どうでもいい前提説明まで復活してしまい、指示が重くなる。しかも本当に必要だった「ここは先に確認してほしい」「このファイルは触るな」だけが埋もれる。あれはだるい。 残すべきなのは、会話の全部ではない。迷いが起きた地点だ。 作業ログを見返すときは、成果物よりも、次の3種類を探すと早い。 一つ目は、Claude Code が何度か聞き返してきた箇所だ。要件の境目がぼやけていた証拠である。 二つ目は、こちらが途中で指示を足した箇所だ。最初の依頼に抜けがあった。 三つ目は、思ったより手数が増えた箇所だ。ファイルの場所、命名、対象範囲、出力形式のどれかが曖昧だった可能性が高い。 逆に、順調だったと
papoo.work
Claude Codeの「節約」は、たぶん開発体験そのものを変える
Claude Codeの「節約」は、たぶん開発体験そのものを変える
読んでまず思ったのは、これは単なる「使い方のコツ」ではなく、LLM を道具としてどう運用するかの話なんだな、ということだった。Claude Code が高くつくから注意しよう、では終わっていない。むしろ、どこで余計な文脈を切り、どこにだけ計算資源を使わせるかを、かなり露骨に設計している。ここが面白い。 特に引っかかったのは、`/compact` の扱いだ。会話を短くするだけなら何となく想像できるけれど、記事を読むと「短くする」こと自体が目的ではなく、次のターンに残すべき情報を選び直す作業になっている。人間のメモ整理とかなり似ている。要らない雑音を削ると同時に、後で効くものだけを残す。逆に言うと、雑に長話を続けるほどコストが膨らむ。ここは、AI を賢くするというより、人間側の整理力がそのまま料金に跳ね返る感じがして、なかなか生々しかった。 もう一つ、`/clear` や context の切り替えがやたら強調されているのも印象的だった。普通のツールなら「履歴が残る」のは便利さの象徴だけど、Claude Code では履歴がそのまま負債にもなる。過去の情報を全部抱え込むのではなく、タスクご
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときに確認したいこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときに確認したいこと
この症状に当てはまるかどうかは、まず表示されているエラー文字列で切り分けられます。今回集まっている issue では、どちらも同じ系統のエラーとして `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が報告されています。ひとつは `keys=1313 messages=1312 range=[1284,1313)`、もうひとつは `keys=100 messages=99 range=[69,100)` で、`itemKeys` と `messages` の数が 1 件ずれていました。 報告元は [#95562](https://github.com/anthropics/claude-code/issues/95562) と [#95325](https://github.com/anthropics/claude-code/issues/95325) です。 この2件だけを見る限り、起きているのは「途中のメッセージ一覧を扱う処理で、キーの数とメッセージ本体の数が一致していない」状態です
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync の切り分けメモ
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync の切り分けメモ
この症状は、issue 上では同じエラー文字列として 2 件まとまっています。どちらも、表示されているのは `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=429 messages=426 range=[393,426))` で、スタックトレースも `B:/~BUN/root/cli` 配下から出ています。報告は [#95537](https://github.com/anthropics/claude-code/issues/95537) と [#95518](https://github.com/anthropics/claude-code/issues/95518) です。 まず、自分のケースかどうかはエラー文字列で見分けるのが早いです。Issue に出ている文字列は次のとおりでした。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=429 mess
papoo.work
Remote Control failed to connect: Remote Control connect timed out が出るときに見ておくこと
Remote Control failed to connect: Remote Control connect timed out が出るときに見ておくこと
この症状は、少なくとも報告上は「一度つながったはずの Remote Control が、再接続で失敗する」かたちで出ています。該当する issue は [#95609](https://github.com/anthropics/claude-code/issues/95609) と [#87720](https://github.com/anthropics/claude-code/issues/87720) です。どちらも、`Remote Control failed to connect: Remote Control connect timed out` で止まる、あるいは `connecting` のまま進まない、という流れが書かれています。 まず切り分けたいのは、「そのセッションだけがおかしいのか」「Remote Control 自体が環境全体で不安定なのか」です。#95609 では、同じアカウントでも別のセッションは claude.ai/code の Web では見えており、モバイル側だけ `連結 해제됨` 相当の状態に見えていました。つまり、アカウント全体の認証不能とい
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync のときに見えていたこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync のときに見えていたこと
この症状は、Claude Code の画面内で `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ているケースです。今回確認できた issue は 2 件だけで、どちらも open のままでした。該当するのは [#92184](https://github.com/anthropics/claude-code/issues/92184) と [#95493](https://github.com/anthropics/claude-code/issues/95493) です。 読者がまず確認したいのは、自分の表示しているエラー文が同じかどうかだと思います。少なくとも issue 側では、次の形が報告されています。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=214 messages=213 range=[147,214)) at N$t (B:/~BUN/ro
papoo.work
`disabled after repeated failures · restart to retry` が出るときに見えていること
`disabled after repeated failures · restart to retry` が出るときに見えていること
この症状は、Claude Code の Remote Control が起動時やセッション中の短い失敗をきっかけに、再試行できないまま無効化されるケースとして報告されています。少なくとも issue では、失敗後に自動で復帰しない、あるいは復帰の手がかりが利用者側から見えない、という点が共通しています。 自分のケースかどうかを最初に切り分けるなら、次の2つに当てはまるかを見ます。ひとつは、起動直後の transient な通信失敗や認証まわりの失敗のあとに Remote Control が戻らないこと。もうひとつは、背景実行や分離されたセッションでは、その失敗が表に出てきにくいことです。 手元で実際に取れている出力は環境情報だけでした。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-09-20T08:51:48+09:00 ``` なので、この段階では「特定の OS だけで起きる」とは言えません。issue だけを見る限り、少なくと
papoo.work
Error: 400 {"type":"error","error":{"type":"invalid_request_error":"自分のツール定義が JSON Schema 2020-12 に通っていないときに出る Claude Code の 400
Error: 400 {"type":"error","error":{"type":"invalid_request_error":"自分のツール定義が JSON Schema 2020-12 に通っていないときに出る Claude Code の 400
このエラーは、Claude Code 側がツール定義の `input_schema` を Anthropic API に送ったとき、JSON schema が受け付けられずに 400 で返ってきたケースとして報告されています。手元で確認できる issue は 2 件で、どちらも同じ系統の文言でした。 まず切り分けたいのは、Claude Code 本体の一般的な通信失敗ではなく、ツール定義のスキーマで落ちているかどうかです。今回の症状クラスタに含まれる実例では、エラーメッセージの中心が一貫して `custom.input_schema` になっています。`use tool` の実行時に 400 になる、という報告もありました。#86664 の環境情報は次のとおりです。 ```text Platform: darwin Terminal: iTerm.app Version: 2.1.232 Feedback ID: 0a5623a4-408d-47fb-afb1-0f3fd41d124a ``` 報告本文に含まれていたエラー断片も、そのまま載せておきます。 ```json ``` ここか
papoo.work
Error: 400 {"type":"error","error":{"type":"invalid_request_error":"messages.73.content.17.image.source.base64.data: At least one of the image dimensi… が出るときに見ておくこと
Error: 400 {"type":"error","error":{"type":"invalid_request_error":"messages.73.content.17.image.source.base64.data: At least one of the image dimensi… が出るときに見ておくこと
この症状は、少なくとも 2 件の issue で同じ系統として報告されています。手元で確認できる範囲では、どちらも画像を含むリクエストで `Error: 400 {"type":"error","error":{"type":"invalid_request_error"...` が返っており、文言の中心は「画像サイズが many-image requests の上限を超えた」というものです。 手元の実測で確認できるのは、検証環境が Linux 上の Python 3.8.13 であることだけです。今回の症状に対して、こちらで再現手順や回避策までは実測できていません。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-09-20T08:51:39+09:00 ``` なので、現時点で言えるのは「画像を含むリクエストで、少なくとも一部の画像が many-image requests の許容サイズを超えたときにこの 400 が返る」というと
papoo.work
authentication failed が出るときにまず見るところ
authentication failed が出るときにまず見るところ
`authentication failed` という表示だけでは原因は絞れませんが、今回の issue 群で確認できるのは、少なくとも 2 つの別系統があることです。ひとつはリモート制御のセッション作成で 401 が返るケース、もうひとつは Windows 上での操作中に別の経路から制御が抜けるケースです。後者は別の症状ですが、同じく認証や制御の前提が崩れているときに起きています。 まず、自分の症状がどちらに近いかを切り分けたほうが早いです。`/remote-control` を開いた瞬間に「Session creation failed — see debug log.」となるなら、[#78580](https://github.com/anthropics/claude-code/issues/78580) の系統です。そこでは `code-session` 作成エンドポイントが 401 を返し、`claude auth logout` と `claude auth login` をやり直しても失敗し続けたと報告されています。issue の本文では「stale/incorrect
papoo.work
auto mode is unavailable for your plan が出るときにまず見ること
auto mode is unavailable for your plan が出るときにまず見ること
この症状は、`auto mode is unavailable for your plan` という文言がそのまま出るケースです。今回の報告では、Claude Max で `Shift+Tab` から Plan mode に入ろうとしたとき、または `/plan` を打ったときに同じエラーが出ています。該当 issue は [#44708](https://github.com/anthropics/claude-code/issues/44708) です。 同じ文字列でも、報告内容を見る限り少なくとも 2 つのパターンがあります。ひとつは Max subscription で Plan mode を選んだのに、このエラーが出るケースです。もうひとつは Pro plan で Claude.ai OAuth でログインしているのに、Auto mode が利用不可と表示されるケースです。後者は [#66510](https://github.com/anthropics/claude-code/issues/66510) にあります。 まず切り分けたいのは、今見えているのが Plan mo
papoo.work
途中報告の頻度を決めて、黙って進みすぎないようにする
途中報告の頻度を決めて、黙って進みすぎないようにする
Claude Code でありがちな失敗は、こちらが「ちょっと整えて」と言っただけなのに、気づいたら深いところまで掘り進んでいて、最後にまとめて見せられることだ。これ、気持ちはわかるが、後から戻すのがだるい。ファイル整理でも文書作成でも同じで、途中で一回止めてくれないと、方向がずれていても気づけない。 そこで効くのが、途中報告を指定する、つまり進捗報告の粒度を決めるやり方だ。Claude Code に「何分ごとに報告してくれ」と機械的に命令するより、「どの単位で止まり、何を見せるか」を先に決めておくほうがずっと実用的である。黙って進みすぎるのを防ぐだけで、手戻りはかなり減る。 たとえば、最初の依頼にこう添える。 ```text まず、作業を小さく区切って進めてください。 各ステップの終わりで、やったこと・見つけた問題・次にやることを短く報告してください。 勝手に大きく先へ進まず、一区切りごとに私の確認を待ってください。 ``` この「一区切り」が肝だ。時間ではなく、作業単位で切る。 ファイル整理なら「重複候補の洗い出しまで」「不要そうな一時ファイルの候補抽出まで」「削除前の一覧提示まで
papoo.work
Claude Codeの更新履歴が示す、ツールとしての成熟
Claude Codeの更新履歴が示す、ツールとしての成熟
Claude Codeの changelog は、単なる修正一覧ではなく、この開発ツールがどう現場向けに育ってきたかをそのまま映しています。今回のページには 2.1.277 を中心に、細かな不具合修正から管理機能、プロキシ対応、プラグイン周りの改善まで、かなり大量の変更が並んでいました。生成AIの話題は新機能ばかりが目立ちますが、実際に使う人に効くのは、こうした地味な修正の積み重ねです。だからこそ、この changelog を読む意味があります。 この changelog は GitHub 上の `CHANGELOG.md` から生成されていて、`claude --version` で手元の版を確認できる、と案内しています。ページで最上位に出ているのは 2.1.277 で、日付は September 18, 2026 です。ここで追加されたのは、まず `CLAUDE.md` がないプロジェクトでは `AGENTS.md` を読むようにした点です。プロジェクトごとの指示ファイルの読み方を広げた形で、設定画面の “Project instructions” から切り替えられますが、Bedr
papoo.work
MCP server providing this tool may be unresponsive, crashed, or not running. が出るときに見えているもの
MCP server providing this tool may be unresponsive, crashed, or not running. が出るときに見えているもの
この症状は、少なくとも今回渡された 2 件の issue では、Claude Desktop 側の MCP クライアントが出しているメッセージとして報告されています。サーバーが本当に落ちていると断定できる材料はありません。むしろ、[#83908](https://github.com/anthropics/claude-code/issues/83908) では「チャットを切り替えた瞬間に tool/call が破棄され、サーバーには何も書き込まれない」と説明されています。つまり、見えているエラー文のわりに、原因がサーバー側とは限らない、というのが出発点です。 今回の私の環境では、再現手順やログは取得していません。手元で実際に確認できたのは環境情報だけです。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-09-19T08:51:24+09:00 ``` なので、ここでは「何を疑うべきか」を issue の報告ベースで絞ります
papoo.work
`Error: 502 <html><head><title>502 Bad Gateway</title></head><body><center><h1>502 Bad Gateway</h1></center><hr><center>cloudflare</center></body></html>` が返るときに見えているもの
`Error: 502 <html><head><title>502 Bad Gateway</title></head><body><center><h1>502 Bad Gateway</h1></center><hr><center>cloudflare</center></body></html>` が返るときに見えているもの
この症状は、少なくとも GitHub issue では 2 件とも同じ形で報告されています。どちらも Claude Code の実行中に `Error: 502` と Cloudflare の `502 Bad Gateway` HTML が返っており、スタックトレースには `generate` と `makeRequest` が出ています。該当 issue は [#67734](https://github.com/anthropics/claude-code/issues/67734) と [#66186](https://github.com/anthropics/claude-code/issues/66186) です。 まず切り分けたいのは、手元の失敗が「Claude Code からのリクエストが途中で 502 に落ちている」ケースかどうかです。提示された 2 件はいずれも、アプリ固有のメッセージではなく Cloudflare の HTML がそのまま返っています。報告内容からは、少なくとも Claude Code 側の処理が HTTP 502 を受け取って失敗していることは
papoo.work
`Error: 401 {"type":"error","error":{"type":"authentication_e` が出るときに見えていたこと
`Error: 401 {"type":"error","error":{"type":"authentication_e` が出るときに見えていたこと
まず、この件は「認証情報が無効です」という 401 で、報告されている文面はどの issue でもかなり似ています。今回の症状クラスタでは、代表 issue のエラー文が次の形でした。 ```text Error: 401 {"type":"error","error":{"type":"authentication_error","message":"Invalid authentication credentials"},"request_id":"req_011CcxEXkC4V93twN7Wd7Be7"} ``` 同じクラスタに含まれている #79249 と #79242 でも、どちらもこの 401 が出ています。`request_id` はそれぞれ違いますが、返ってきたメッセージ自体は同じです。 #79249: [#79249](https://github.com/anthropics/claude-code/issues/79249) #79242: [#79242](https://github.com/anthropics/claude-code/issues/792
papoo.work
Claude Codeの更新履歴を読んで一番気になったこと
Claude Codeの更新履歴を読んで一番気になったこと
これを読んでまず思ったのは、「更新履歴なのに、もはや不具合報告の墓場みたいだな」ということでした。新機能もあるのですが、目に入るのは圧倒的に細かい修正の多さです。しかも単なる見た目の微調整ではなく、クラッシュ、セッションの消失、更新失敗、プロキシ環境、Windows、長いパス、壊れた設定ファイルまで、かなり広い範囲に手が入っている。便利なツールほど、実際にはこういう地味な綻びを一つずつ潰していくしかないのだと改めて感じました。 特に印象に残ったのは、Claude Code が「大きく壊れる」パターンをかなり執念深く直しているところです。たとえば設定ファイルが少し壊れているだけで起動時に落ちたり、履歴の保存形式が変だっただけで再開できなかったり、プロンプトに terminal color codes が混ざっただけで interface error になったりする。こういうのは派手さはないけれど、使う側からすると一発で信頼を失う原因です。AIエージェント系のツールは、賢さそのものより「落ちない」「変な状態から戻れる」ことのほうが先に効いてくるんじゃないかと思います。 もう一つ、妙に人間臭
papoo.work
Remote Control failed が出るときに見えていたこと
Remote Control failed が出るときに見えていたこと
`Remote Control failed` という同じ文言でも、issue を読む限り中身が少し違います。少なくとも今回集めた報告では、どちらも「接続しようとした瞬間に失敗する」点は共通していますが、片方は `/bridge` エンドポイントでの 401、もう片方は `Remote Control server rejected the request (HTTP 403)` でした。 自分のケースがどちらに近いかは、まずこの出方で切り分けられます。`[#78453](https://github.com/anthropics/claude-code/issues/78453)` では、セッション作成後の remote control 接続が `401 Authentication failed at /bridge endpoint` になっています。報告文には、完全にサインアウトして入り直しても直らなかったとあります。`[#92760](https://github.com/anthropics/claude-code/issues/92760)` では、Claude Desk
papoo.work
`Error: Tool Glob not found
`Error: Tool Glob not found
at URK (/$bunfs/root/src/entr` が出るときに、まず見るべきこと この症状は、Claude Code の issue 報告では少なくとも 2 件確認できました。どちらも報告されているエラーの形は同じで、`Error: Tool Glob not found` から始まるスタックトレースが付いています。該当するのは [#67458](https://github.com/anthropics/claude-code/issues/67458) と [#67213](https://github.com/anthropics/claude-code/issues/67213) です。 ただし、今回渡された情報の範囲では、これが「何をすれば直るか」までは確定できません。代表 issue のコメントも、いずれも自動で close / lock された旨だけで、解決手順は載っていませんでした。なので、ここでは「どんなときにこのエラーに当たりやすいか」と「手元で確認できた事実」だけに絞ります。 `#67458` では、spec ファイルを解析させた流れの中で拒否が起きて
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たら、まず切り分けたいこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たら、まず切り分けたいこと
この症状は、Claude Code の issue 群で同じエラー文字列が繰り返し出ているものです。代表的には [#95229](https://github.com/anthropics/claude-code/issues/95229)、[#95224](https://github.com/anthropics/claude-code/issues/95224)、[#95210](https://github.com/anthropics/claude-code/issues/95210)、[#95109](https://github.com/anthropics/claude-code/issues/95109) で、いずれも報告されたエラーとして `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が付いています。 ただし、少なくとも今回渡された issue 群だけを見る限り、解決済みの報告はなく、根本原因も確定していません。 まず見るべきなのは、「会話内容の表示・保持がおかしい
papoo.work
ERR_CONNECTION_CLOSED が出たときに、まず見分けたいこと
ERR_CONNECTION_CLOSED が出たときに、まず見分けたいこと
`ERR_CONNECTION_CLOSED` という文字列だけを見ると、ひとつの原因に見えてしまいます。ですが、今回の issue 群を見る限り、少なくとも二つの出方があります。 ひとつは、Cowork の macOS Desktop でチャット用の webview がネットワークを失って、そのまま戻らなくなるケースです。報告では、エージェント側の処理は続いているのに、画面側だけが壊れたままになり、送ったメッセージが灰色の「ghost bubble」として残るとされています。AskUserQuestion も描画されず、自動で拒否されたように見える、と書かれています。これは [#65382](https://github.com/anthropics/claude-code/issues/65382) の報告です。 もうひとつは、Windows の auto-updater で、Electron のネットワーク層だけが `ERR_CONNECTION_CLOSED` を返すケースです。報告では、`curl` と `node https.get()` では同じ更新先に届くのに、Elec
papoo.work
`The advisor tool is unavailable. Do not try to use it again.` が出るとき、まず疑うべきこと
`The advisor tool is unavailable. Do not try to use it again.` が出るとき、まず疑うべきこと
この症状は、少なくとも [#66784](https://github.com/anthropics/claude-code/issues/66784) と [#76139](https://github.com/anthropics/claude-code/issues/76139) で報告されています。どちらも、advisor を使おうとした場面で同じ文言が返ってきます。 手元で確認できた検証環境は次の通りです。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-09-18T08:51:10+09:00 ``` まず切り分けたいのは、通常の advisor 不調ではなく、特定のモデル組み合わせで advisor が使えなくなっているケースかどうかです。 手元の資料から言えるのはここまでです。少なくとも、このエラーが出たら「advisor 自体の一時障害」と決め打ちせず、まずはメインモデル名に `[1m]` のような suffix を
papoo.work
作業中に持たせるメモは短く、決定事項だけに絞る
作業中に持たせるメモは短く、決定事項だけに絞る
長い指示を書けば、Claude Code が賢くなると思っているなら、そこがまず勘違いだ。たいていは逆で、メモが長いほどノイズが増えて、あとで自分が困る。持たせるメモは短くする。この雑なほど効くやり方が、作業中の手戻りをかなり減らす。 ここでいう「メモ」は、Claude Code に仕事を続けさせるための短い引き継ぎ文だ。たとえば一度の編集で終わらず、次の作業に移るときに「何が決まり、何が終わり、次に何をするか」を渡すためのものだと思えばいい。要するに、議事録ではなく、作業再開のための付箋である。 長文メモがだめな理由は単純だ。Claude Code は会話の文脈を読むが、文脈は無限ではない。余計な背景説明、気持ちの整理、検討途中の迷いまで全部積むと、肝心の決定事項が埋もれる。しかも人間側も、あとでそのメモを見返したときに「結局何を決めたんだっけ」となる。作業の速度を上げるつもりが、逆に確認作業を増やすわけだ。 筆者も最初はやらかした。ファイル整理の作業で、「このフォルダは請求書、こっちは契約書、さらに古いものは別の基準で…」と、経緯まで含めて延々と説明したことがある。結果、C
papoo.work
途中報告の頻度を先に決めて、黙って進みすぎないようにする
途中報告の頻度を先に決めて、黙って進みすぎないようにする
Claude Code を使うと、気持ちよく進みすぎることがある。そこが落とし穴だ。黙々と走らせたあとで、最後に「違う、そうじゃない」となる。あれはだいぶだるい。 だから最初にやるべきなのは、途中報告の頻度を決めることだ。別名でいうと「途中報告の頻度を決める」だし、要は、どのくらいの間隔で状態を返せば止めどきが見えるかを先に縛る作業である。これを入れておくと、Claude Code が勝手に深追いして、後から大きく戻す事故をかなり減らせる。 特に効くのは、リポジトリ整理、不要ファイルの洗い出し、文章の下書き、複数ファイルの一括修正みたいな作業だ。どれも「一見うまく進んでいるように見えて、実は方向がズレていた」が起きやすい。進捗が見えないまま長く走らせると、コンテキストも時間も無駄になる。 最初にこう言ってしまえばいい。 ```text 20〜30分ごとに途中報告して。今やっていること、終わったこと、次にやること、気になる点を短く返して。止めて確認が必要そうなら、その時点で止まって聞いて。 ``` もう少し作業寄りにするなら、こう書く。 ```text 途中報告の頻度を先に決める。各ファ
papoo.work
途中要約を挟ませて、前提のズレを止める
途中要約を挟ませて、前提のズレを止める
長い会話ほど、相手はちゃんと理解しているふりをする。Claude Code でもここが地味に危ない。 途中で要約を一回挟まないと、最初の前提が少しずつずれて、最後には「思ってたのと違う」が出来上がる。これ、コード修正でもファイル整理でも文書作成でも同じだ。 別名で言えば「会話が長くなったら節目で要約させる」だ。要するに、こちらが勝手に次へ進まず、途中で Claude Code に今の理解を言い直させる。すると、解釈違い、対象範囲の取り違え、やるべきことの抜けが早めに見つかる。手戻りが減る。差分も無駄に育ちにくい。 筆者は最初、これをサボって何度か痛い目を見た。大きめのリファクタリングを流しっぱなしにしていたら、途中から「古いほうのディレクトリも触るのか」「要らないキャッシュは消していいのか」が曖昧なまま進み、最後に修正のやり直しが出た。会話の後半でズレが見つかると、修正対象が増えたぶんだけコンテキストも消耗する。先に止めたほうがずっと安い。 やり方は単純だ。長い依頼を一気に投げるのではなく、節目ごとに「ここまでの理解を要約して」と挟む。Claude Code は会話の流れを読めるが、読
papoo.work
長い依頼は章立てより先に節目を決める
長い依頼は章立てより先に節目を決める
長い依頼をいきなり章立てで整えようとすると、だいたい途中で崩れる。章の名前を先に決めること自体は悪くないが、Claude Code に投げる相手が長い会話になるなら、先に決めるべきは「どこで止めて、何を要約させるか」だ。別名で言うと、会話が長くなったら節目で要約させる、である。 ここを外すと、依頼の前半で出した条件が後半で薄まる。Claude Code は会話の流れを追えるが、雑にだらだら続けると、重要な前提や制約が会話の奥に埋もれる。すると、終盤で「その条件は前に出した」とこちらが思っていても、モデル側では拾い直しが必要になる。筆者はこれで何度か手戻りした。特に、ファイル整理や文書作成のように、途中で方針が変わりやすい依頼ほど厄介だ。 だから、長い依頼ではまず章立てを作るより先に、節目を置く。節目とは、会話の途中で Claude Code に立ち止まらせて、ここまでの理解を短く要約させる地点だ。これを先に決めておくと、会話の骨が折れにくい。 たとえば、こんなふうに始める。 ```text この作業は長くなります。次の節目で必ず要約してください。 1. 現状把握が終わったら要約 2.
papoo.work
Claude Code に渡す情報は、最初に「材料」と「判断基準」に分ける
Claude Code に渡す情報は、最初に「材料」と「判断基準」に分ける
雑に「これやって」で投げると、Claude Code はだいたい余計なものまで触る。そこが一番もったいない。 Claude Code に仕事を渡すときは、最初に「材料」と「判断基準」を分ける。別名で言えば、最初に使う材料と使わない材料を分けて渡す、である。これをやるだけで、コンテキストの浪費が減るし、手戻りも減る。ファイル整理でも、コード修正でも、文章作成でも効く。むしろ非エンジニアの作業ほど効く。何を見ればいいのか、何を見なくていいのかが曖昧だと、AI はだいたい親切すぎる方向に暴れるからだ。 たとえば、フォルダ内の散らかった書類を整理したいなら、Claude Code に必要なのは「対象フォルダの一覧」「残したい条件」「消したい条件」だ。逆に、関係ない過去案件や別部署の資料まで全部渡すと、判断のノイズになる。コード修正でも同じで、修正対象のファイル、参照してよい設定、守るべき制約が材料になる。一方で、「見てもらうと迷うだけの古い実装」「今回の作業に関係ないログ」「趣旨の違うメモ」は切り離す。ここをサボると、モデルの賢さより先に入力の雑さで負ける。 実際の頼み方は、こういう形にすると
papoo.work
作業ログを見返して、Claude Code が迷った地点を次回に生かす
作業ログを見返して、Claude Code が迷った地点を次回に生かす
Claude Code に雑に丸投げして、「なんか遠回りしたな」で終わらせるのはもったいない。そこで止めると、次回も同じ場所で迷う。作業ログを見返す、迷った地点を次回に生かす。ここまでやって初めて、CLI のエージェントはただの便利ツールから、だんだん手癖の合う相棒になる。 狙いは単純だ。Claude Code がどこで止まり、何を確かめ、どこで手戻りしたかを拾って、次の指示を最初から少しだけ鋭くする。これだけで、無駄な探索、でかい diff、あいまいな修正の往復が減る。特に、ファイル整理や文書作成みたいに「正解はあるが、そこへ行く道筋がいくつもある」作業で効く。 筆者は最初、ログをほとんど見返していなかった。すると何が起きるか。前回と同じように「とりあえず全体を見てから判断します」と動き、不要な範囲まで触り、最後に「やっぱりここは触らないで」で戻る。差分は膨らむし、どこで判断が鈍ったのかも残らない。地味だが、これがいちばん痛い。 まず、作業ログは「終わったあとに読む資料」ではなく、「次回の依頼文を作る材料」だと考えると扱いやすい。Claude Code には、実行中の会話やコマンドの
papoo.work
Claude Codeの新しいProjectsを読んで、まず気になったこと
Claude Codeの新しいProjectsを読んで、まず気になったこと
この記事で一番引っかかったのは、「これは便利そうだ」と思うのと同時に、「でも今いちばん困っている人にはまだ届かないのか」という距離感だった。クラウド上では、複数のthreadを束ねて、shared memoryまで持たせて、プロジェクト全体をまとめて動かせる。たしかに、AI coding agent が増えてきた今、個々のagentを賢くするより、どう管理するかのほうが先に難しくなるので、この発想はかなり筋がいいと思う。 特に面白いのは、threadごとに会話を分けつつ、それらが互いに memory を共有するという設計だ。普通の「AIに一発で全部やらせる」やり方だと、途中で話が崩れたときに戻りにくい。でもthreadを名前付きで追いかけられて、途中から方向修正もできるなら、AIを“暴走しやすい作業者”ではなく、“途中で指示を出し直せる部下”として扱える。そこはかなり実務っぽい進化だと感じた。 一方で、この記事を読んで素直にモヤっとしたのは、memory の中身がよく見えないことだ。何が保持され、どこまで残り、消せるのかがはっきりしないまま「shared memory」と言われても、現
papoo.work
Claude Codeの「複数エージェント化」を読んで思ったこと
Claude Codeの「複数エージェント化」を読んで思ったこと
これ、便利そうというより先に「もう人間の仕事の区切り方に寄せてきたな」と感じました。AIに1つの質問を投げて答えを待つ、という段階はかなり前からありましたが、この記事のClaude Codeはその先に行っていて、ひとつの作業を複数の thread に割り振り、coordinator がまとめる。要するに、小さなチームをそのままクラウドの中に作る発想です。 面白いのは、各 thread が別ブランチと別コピーの repo で動く、という点です。ここはかなり現実的だと思いました。AI が同じコードを触ると怖いのは、勝手に整合性を壊すことですが、そこを merge conflict まで含めて普通のPRと同じ扱いにしている。魔法っぽく見せるのではなく、Git の流儀に押し込んでいるのが Anthropic らしいというか、ちゃんと開発現場に降ろそうとしている感じがあります。 ただ、同時に「結局、扱う人の側にかなりの管理能力が要るのでは」とも思いました。thread が増えるほど速くなるのは確かに魅力ですが、増えた分だけ指示の粒度や責任の所在がぼやけやすい。coordinator がいるとはい
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときにまず確認すること
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときにまず確認すること
このエラーは、今回渡された issue 報告では [#94645](https://github.com/anthropics/claude-code/issues/94645) と [#94531](https://github.com/anthropics/claude-code/issues/94531) の 2 件で確認できました。どちらも `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` で始まり、`keys` と `messages` の件数が 1 つずれていました。 まず、自分のケースかどうかを見るなら、エラー文に次の形が入っているかを確認します。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=164 messages=163 range=[132,164)) at R7t (B:/~BUN/root/chunk-te7sk2cq.js:36:2985
papoo.work
案件ごとにディレクトリを分けて、後から迷子にならない
案件ごとにディレクトリを分けて、後から迷子にならない
案件を1つの場所に雑に押し込むと、あとで自分が探す側になる。これ、かなりだるい。Claude Code を使うときも同じで、案件ごとにディレクトリを分ける、いわゆる案件単位のフォルダ分離をしておかないと、指示・出力・メモ・成果物が混ざってすぐ迷子になる。 とくに Claude Code は、その場の文脈を見ながら作業を進める道具だ。だからこそ、作業単位をフォルダで切っておくと効く。コード案件だけの話ではない。文書作成、調査メモの整理、重複ファイルの洗い出し、契約書まわりの下書き管理みたいな使い方でも、フォルダの切り方で後の楽さが全然違う。 筆者は昔、1つの作業ディレクトリに別件のメモを足していって、どのファイルがどの案件の最終版か分からなくなったことがある。Claude Code に頼むたびに古いメモまで拾われ、修正のたびに diff が太る。あれは地味に痛い。最初に分けておけば、こんな事故はかなり減る。 まず、考え方は単純だ。Claude Code を起動する前に、案件ごとに親フォルダを切る。中に必要な資料、作業用メモ、出力物をまとめる。Claude Code には、その案件フォルダ
papoo.work
`Claude Code returned an error result: No conversation found with session ID: <session-id>` が出るときに、まず見るところ
`Claude Code returned an error result: No conversation found with session ID: <session-id>` が出るときに、まず見るところ
このエラーが出るのは、VS Code の Claude Code 拡張でセッションを開き直そうとしたときです。今回の issue では、少なくとも [#79118](https://github.com/anthropics/claude-code/issues/79118) と [#79122](https://github.com/anthropics/claude-code/issues/79122) の 2 件で同じ文言が報告されています。 最初に確認したいのは、単なる表示不具合ではなく、セッションファイル側に会話本文が残っていないケースかどうかです。[#79118](https://github.com/anthropics/claude-code/issues/79118) では、`~/.claude/projects/<project-slug>/<session-id>.jsonl` 自体は存在していたものの、実際に入っていたのは会話本文ではなく、次の 2 行だけだったと報告されています。 ```json {"type":"ai-title","aiTitle":"Re
papoo.work
`Session creation failed — see debug log` が出るときに、まず切り分けたいこと
`Session creation failed — see debug log` が出るときに、まず切り分けたいこと
このエラーが出たとしても、同じ見え方で中身が違うことがあります。今回の issue 報告では、少なくとも二つのパターンがありました。ひとつは Remote Control のセッション登録が失敗するケース、もうひとつは `/remote-control` をその場で打ったときに最初の一回だけ無言で失敗するケースです。 手元で実際に確認できた環境情報はこれだけです。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-09-16T08:51:20+09:00 ``` この情報だけでは、今回の症状が issue のどちらと一致するかは断定できません。ただ、もしあなたの環境で次のどれかに当てはまるなら、報告されているクラスタにかなり近いです。 Docker やコンテナの中で Claude Code を動かしていて、Remote Control の登録だけが失敗する `/remote-control` を最初に打ったときだけ何も起きず、二回目で通
papoo.work
`MaxFileReadTokenExceededError: [REDACTED] content (34762 tok` が出るときに見えていたこと
`MaxFileReadTokenExceededError: [REDACTED] content (34762 tok` が出るときに見えていたこと
この症状に当てはまるのは、エラー文の中に `MaxFileReadTokenExceededError: [REDACTED] content (34762 tokens) exceeds maximum allowed tokens (25000)` が出ていて、しかも Claude Code 側が「長すぎる内容を一度に読もうとして失敗した」ように見えるケースです。今回参照できた issue は、まったく別の状況に見える報告も含めて 2 件ありましたが、どちらも同じエラー文字列が出ています。 1 件目は [#59827](https://github.com/anthropics/claude-code/issues/59827) で、`Goal function causes infinite loop when waiting for task completion` という報告でした。本文では、goal function が「タスク完了を待つ」場面で何度も同じ確認を繰り返し、結果として無限ループになったと書かれています。報告者は、goal evaluator が再評価を繰り返す
papoo.work
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"tools.11.model: 'claude-opus-4-8' cannot be used as an advisor when the request mo…"} が出るときに確認したいこと
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"tools.11.model: 'claude-opus-4-8' cannot be used as an advisor when the request mo…"} が出るときに確認したいこと
この症状は、Claude Code 側のリクエストで `advisor` として使われるモデルが、実行しようとしている request model と噛み合っていないときに出ています。今回集まっている issue では、メッセージの中身がかなりはっきりしています。 `[#66865](https://github.com/anthropics/claude-code/issues/66865)` では、`tools.10.model: 'claude-opus-4-8' cannot be used as an advisor when the request model is 'claude-fable-5'.` と出ています。`[#66940](https://github.com/anthropics/claude-code/issues/66940)` でも同じ構造で、`tools.11.model: 'claude-opus-4-8' cannot be used as an advisor when the request model is 'claude-fable-5'
papoo.work
案件ごとにディレクトリを分けて後から迷子にならない
案件ごとにディレクトリを分けて後から迷子にならない
ひとつの場所に何でも放り込むと、あとで必ず探し物ゲームになる。Claude Code を使うなら、案件ごとにディレクトリを掘る、つまり最初から案件単位でフォルダを切っておく運用にしたほうがいい。後から探しやすくするだけでなく、指示の混線も減るし、差分も見やすい。地味だが、ここを雑にすると手戻りがいちばん痛い。 筆者は昔、同じ親フォルダに似た名前の依頼を並べて、あとで「この修正、どっちの案件だったっけ」と迷ったことがある。Claude Code 側も、置き場が曖昧だと、こちらが出した指示の文脈を人間ほど都合よく分けてはくれない。ファイルが散らかっていると、探す時間だけでなく、確認のための会話や差分の追跡までだるくなる。案件ごとにディレクトリを分けるのは、整理術というより事故防止だ。 実際の運用は難しくない。たとえば、クライアント名や案件名で親フォルダを作り、その下に作業中の資料、出力物、メモをまとめる。 ```bash mkdir -p ~/work/client-a/2026-04-proposal/{input,output,notes} ``` こうしておけば、Claude Cod
papoo.work
引き継ぎやすい状態で終える
引き継ぎやすい状態で終える
雑に閉じると、次の Claude Code がいきなり鈍る。これは思った以上に効く。 「次回の Claude Code が速くなる終わり方」とか「作業フォルダの後始末」と呼んでもいいが、要するに、いまの作業を“次の一手が打ちやすい形”に整えてから離席する、という話だ。 Claude Code は、こちらが置いたファイル、残したメモ、差分のまとまり方にかなり引っ張られる。作業途中の断片が散らかっていると、次に開いたときにまた状況整理から始まりやすい。人間でも嫌なやつだが、CLI エージェントでも同じだ。 筆者は最初、成果物だけ急いで出して、`.tmp` や試作ファイルを放置したまま終わらせていた。すると次の実行で、古い案と新しい案が混ざり、確認に無駄な往復が増えた。地味だが、こういう手戻りがいちばんだるい。 大事なのは、全部をきれいにすることではない。次回が迷わないだけの“片づけ”をすることだ。やることは意外と少ない。 まず、終わる前に Claude Code に「いま何が残っていて、何を消してよくて、何を残すべきか」をはっきり言う。曖昧に「あとよろしく」では弱い。作業フォルダ内の中間生
papoo.work
Claude CodeでUIを揃える話を読んで考えたこと
Claude CodeでUIを揃える話を読んで考えたこと
最初に思ったのは、「AIに実装させると、デザインが崩れるのはそりゃそうだよな」ということだった。 人間のチームでも、コンポーネントをちゃんと共通化していないとボタンの角丸や余白が少しずつズレていく。そこに coding agent が入ると、毎回“それっぽい最適解”を新しく作ってしまう。この記事は、その当たり前の厄介さをかなり実感のある形で書いていて、妙に納得した。 特に引っかかったのは、著者が「デザインの問題」ではなく「コードベースの構造の問題」として見ているところだ。 見た目がバラつくのは、AIのセンスが悪いからというより、参照すべき標準がコードの中に存在しないからだ、という発想はかなり筋がいいと思う。UIを shared folder に寄せて、そこ以外で勝手に新しい部品を作らせない。これは地味だけれど、AI時代のフロントエンドではかなり重要な統制だろう。 一方で、少し怖さもある。 「このフォルダ以外で新しいUIを作るな」と厳しく縛るのは有効だけれど、運用を間違えると今度は柔軟性が死ぬ。新しい表現が必要な場面まで既存部品に押し込めると、アプリが逆に窮屈になるはずだ。だから本当に大
papoo.work
ETIMEDOUT が出るときに、再接続が止まる場合と CLI が固まる場合
ETIMEDOUT が出るときに、再接続が止まる場合と CLI が固まる場合
この症状は、少なくとも 2 つの報告に分かれていました。ひとつは、スリープ解除後に Desktop App が再接続を 3 回試したあとで止まり、それ以上の自動再試行をしなくなるケースです。もうひとつは、headless Linux 上で `claude` のサブコマンドが `--version` を除いて固まり続けるケースです。どちらも、ユーザー側から見ると「応答が返らない」「つながらない」という形で見えますが、現れ方はかなり違います。 まず、スリープ復帰まわりの報告は [#78666](https://github.com/anthropics/claude-code/issues/78666) です。報告では、クライアント機が sleep/wake したあと、ネットワークがまだ戻っていないタイミングで Desktop App が transport dead を検知し、その後に自動再接続がちょうど 3 回、約 6 秒の間に走るとされています。3 回とも `host is offline` で失敗し、その後は `Auto-reconnect exhausted` になって自動では再
papoo.work
Application Error が出るときの Claude Code: Windows 11 Settings とデスクトップアプリで起きていたこと
Application Error が出るときの Claude Code: Windows 11 Settings とデスクトップアプリで起きていたこと
最初に切り分けたいのは、壊れているのが Claude 本体なのか、Windows 11 の設定画面なのかです。今回の issue では、少なくとも 2 つの別の見え方がありました。ひとつは Windows 11 の Settings アプリが落ちるケース、もうひとつは Claude desktop app が起動後しばらくして閉じ、その後は開けなくなるケースです。 前者は [#79893](https://github.com/anthropics/claude-code/issues/79893) にあり、イベントの内容として `SystemSettings.exe` が `SettingsHandlers_Startup.dll` で失敗しています。後者は [#85797](https://github.com/anthropics/claude-code/issues/85797) で、Claude desktop app 自体が数分後に閉じ、そのあと Windows に `"This app can't be opened."` と出る、という報告です。どちらも Windows
papoo.work
`Error: Streamable HTTP error: Error POSTing to endpoint: <html>` が出るときに見えていたもの
`Error: Streamable HTTP error: Error POSTing to endpoint: <html>` が出るときに見えていたもの
この症状は、少なくとも今回渡された issue 群では、Claude Code が POST 先の endpoint に対して返ってきた HTML の `502 Bad Gateway` をそのままエラーとして見せている場面でした。報告はどちらも同じ文字列を含んでいます。 該当 issue は [#87221](https://github.com/anthropics/claude-code/issues/87221) と [#86687](https://github.com/anthropics/claude-code/issues/86687) です。 まず切り分けたいのは、あなたの画面に出ているのが「Claude Code 側の操作ミス」ではなく、POST の先で `502 Bad Gateway` が返っているケースかどうかです。今回の報告では、エラーメッセージの中に次の HTML が含まれていました。 ```html <html> <head><title>502 Bad Gateway</title></head> <body> <center><h1>502 Bad
papoo.work
This site is not allowed due to safety restrictions が出て Shopee / Lazada Seller Center に入れないとき
This site is not allowed due to safety restrictions が出て Shopee / Lazada Seller Center に入れないとき
この症状は、Claude in Chrome の安全制限でサイト遷移が止められているケースです。少なくとも issue [#82218](https://github.com/anthropics/claude-code/issues/82218) では、Shopee Seller Center と Lazada Seller Center が restricted domain として扱われ、ページが開く前に次のエラーで止まると報告されています。 > This site is not allowed due to safety restrictions. 報告されている対象は、たとえば次の URL です。 `https://seller.shopee.co.id` `https://sellercenter.lazada.co.id` 同じプラットフォームでも、別の国の TLD も影響を受ける可能性があると issue には書かれていますが、どこまで広がっているかはこの報告だけでは断定できません。 自分のケースかどうかを見分ける一番手っ取り早い方法は、Claude in Chrome
papoo.work
作業ログから、迷った地点だけを次回の依頼テンプレに戻す
作業ログから、迷った地点だけを次回の依頼テンプレに戻す
作業ログを全部テンプレに戻すのは、だいたい雑だ。しかも重い。次回に残すべきなのは「うまくいった手順」より、むしろ「そこで迷った」「判断に時間がかかった」「指示があいまいで手戻りした」地点だけである。ここを戻すと、ログの再利用、失敗の抽出、テンプレ改善が一気に実用になる。 Claude Code は、毎回の依頼をきれいに書き直す道具というより、作業の癖を次に持ち越す道具として使うほうが強い。特に、ファイル整理や文書作成みたいな用途では、毎回の作業で同じ迷いが出る。どのフォルダを触ったか、どの表現で止まったか、どこで差し戻されたか。そこだけ拾って次回の依頼テンプレに戻せば、無駄な説明が減るし、Claude Code のコンテキストも食いにくくなる。 最初に大事な線引きをしておく。戻すのは「成果物の全文」ではない。戻すのは「次回も迷う可能性が高い一文」だけだ。ここを間違えると、テンプレが日記になる。日記は読めるが、指示としては弱い。 たとえば、前回の作業ログがこんな形で残っていたとする。 ```text 依頼: 請求書フォルダの重複を整理 迷った点: 「2023_final」「2023_最新
papoo.work
長文の下書きを最後にまとめ直して、引き継げる形に整える
長文の下書きを最後にまとめ直して、引き継げる形に整える
長く書き散らしたあとに、そのまま投げるのは雑すぎる。しかも、本人には読めるのに他人には使えない、いちばん厄介な形になりやすい。そこで効くのが、仕上げの再編集、全体の整形、引き継ぎ用まとめだ。Claude Code を使うなら、最後にこれを一回かけるだけで、下書きが「自分のメモ」から「他人が次に動ける文」に変わる。 ここでやることは、文章をきれいにするだけではない。重複を削り、順序をそろえ、前提が抜けた箇所を補い、あとで別の人が見ても迷わない形に整える。会議メモ、作業ログ、調査メモ、ディレクトリごとの作業記録、ファイル整理の手順書。どれでも効く。筆者は最初、ただ長文を短くしてもらえば十分だと思っていたが、実際はそれだと筋が切れて、あとで読み返すと「で、何を決めたんだっけ？」となった。長さを削るだけでは足りない。最後の組み直しが本体だ。 まずは、Claude Code に渡す役目をはっきりさせる。ここをあいまいにすると、要約なのか整形なのかがぶれて、出力が中途半端になる。たとえば、作業メモを引き継ぎ用に変えたいなら、こんなふうに指示する。 ```text この下書きを、あとで別の人が読んで
papoo.work
Claude Code に持たせるメモは短く、決定事項だけに絞る
Claude Code に持たせるメモは短く、決定事項だけに絞る
長いメモを残して「あとで Claude Code が全部わかるはず」と思うと、だいたい逆に詰まる。 ここで効くのは、短い作業メモを残し、決定事項のみを書き、余計な経緯は落としていくやり方だ。要するに、コンテキスト圧縮である。Claude Code に渡す情報は、議事録ではない。次の一手を迷わないための手がかりだけでいい。 筆者は最初、ここを盛大に外した。要件をそのままベタ書きして、しかも途中の試行錯誤まで全部残したら、Claude Code が「どれが現在の方針か」を拾いきれず、無駄に広く触り始めた。修正差分が増え、見なくていい古い方針まで引きずる。あれは気持ちいい失敗だった。メモは増やすほど賢くなるわけではなく、むしろ鈍ることがある。 やることは単純だ。残すのは「何をやるか」「何をやらないか」「もう決めた制約」だけにする。たとえば、文書作成でもファイル整理でも、次のような短いメモで足りる。 ```text 目的: 契約書の下書きを整える 決定事項: 口調はやや硬め 見出しは3つ 参考資料Aは使う 参考資料Bは使わない 未決定: 署名欄の表記 ``` これだけで十分だ。
papoo.work
会話が長引く作業は、章立てより先に節目を決める
会話が長引く作業は、章立てより先に節目を決める
長い依頼ほど、いきなり章立てを作る人が多い。だが、そこがだるい罠だ。Claude Code に会話が長引く作業を任せるなら、先に決めるべきなのは章ではなく節目である。区切り設計、マイルストーン、進行の節目。呼び方は何でもいいが、要は「どこで止めるか」を先に固定する発想だ。 これをやると、会話の空回りがかなり減る。特に、ファイル整理、不要キャッシュの洗い出し、長い文書作成、複数ディレクトリにまたがる作業では効く。逆に、節目がないまま走らせると、Claude Code は親切に広げすぎる。確認のたびに前提を思い出し、説明が増え、差分も膨らむ。筆者はこの手の作業で、途中までうまくいっていたのに「続きも同じ調子で」と丸投げして、説明の再生成にコンテキストを食われたことがある。やることは単純なのに、会話だけ長くなる。かなりもったいない。 まずは、仕事を章ではなく節目で切る。たとえば文書作成なら、こんなふうだ。 目的の確認 素材の棚卸し 下書き 体裁の調整 最終確認 これだけを見ると、ただの手順書に見える。だが実際は違う。Claude Code に渡すべきなのは「第1章、第2章」のような見出しでは
papoo.work
調べた結果をその場で短く要約させて、次の指示に渡す
調べた結果をその場で短く要約させて、次の指示に渡す
調べっぱなしで終わると、Claude Code は平気で長文を抱えたまま次の仕事に入る。そこが雑だと、あとで「あれ、さっき何を見つけたんだっけ」となる。 そこで使うのが、その場で短くまとめさせてから次の指示に渡すやり方だ。調査サマリ、中間要約、引き継ぎメモ、と呼び方は何でもいいが、やることは同じである。見つけた事実だけを短く圧縮して、次の判断材料に変える。 これが効くのは、Claude Code が「長い調査結果」をそのまま抱え込むと、肝心の次の作業に使うコンテキストがじわじわ削られるからだ。特に、複数ファイルを見たり、候補を比較したり、不要ファイルの洗い出しをしたあとに、そのまま編集へ入る流れは危ない。筆者は最初、調べた内容を全部貼って「これで直して」と投げて、要点がぼやけたまま手戻りした。長文を読ませるより、要点を切って渡したほうが速い。これはかなりはっきりしている。 やり方は単純だ。まず調べさせる。次に、調査結果を短く要約させる。最後に、その要約だけを使って次の指示を出す。 たとえば、重複ファイルや大きすぎるファイルを見て、削除候補を絞りたいなら、こう頼む。 ```text この
papoo.work
Claude Code に判断理由を残させて、後から迷いどころを追えるようにする
Claude Code に判断理由を残させて、後から迷いどころを追えるようにする
Claude Code に作業だけさせて、あとから「なんでそこを触ったんだ」と首をかしげる。これ、かなりありがちな落とし穴だ。差分はきれいでも、判断の筋道が残っていないと、少し時間がたっただけで修正の意図が追えなくなる。結果、同じ迷いをもう一度やる羽目になる。 ここで欲しいのは、判断ログ、理由メモ、思考の記録だ。大げさな監査記録ではない。どのファイルをなぜ変えたか、何を捨てて何を残したか、迷った末にどう決めたかを、短く残しておくだけでいい。これがあると、後から差分を見返すときの速度が段違いになる。レビューも楽になるし、非エンジニアが書類整理やファイル整理に使う場面でも効く。削除した理由が残っていれば、戻すべきかの判断が一気にしやすくなるからだ。 一番手堅いのは、Claude Code に「作業そのもの」と「判断の記録」を分けて頼むやり方である。たとえば、ファイル整理ならこう書く。 ```text このフォルダを整理してください。 作業の前に、どの基準で分類するかを短く整理してください。 作業後に、変更した内容と、迷った点・判断理由を箇条書きで残してください。 判断理由は、あとで見返して
papoo.work
長い依頼の冒頭に、今の状態を短く書き出す
長い依頼の冒頭に、今の状態を短く書き出す
長い依頼でいちばん雑に扱われがちなのは、実は“今の状態”だ。 ここを省くと、Claude Code は毎回まっさらな気分で読み始める。こちらは「前提くらい分かるだろ」と思っているのに、向こうから見ると肝心の足場が見えていない。結果、手戻りが増える。地味だが、かなりだるい。 この手の依頼では、冒頭に短い現状メモを置くのが効く。途中再共有とか、前提の再掲と呼んでもいい。要するに「いま何がどうなっていて、どこで詰まっていて、何を優先したいのか」を先に一段落で書くやり方だ。Claude Code は会話の流れを読めるが、長い作業ほど途中で前提がぼやける。だから最初に短く固定する。 たとえば、ファイル整理ならこういう入り方になる。 ```text 今の状態を先に書きます。 このフォルダには請求書PDF、スキャン画像、古い下書きが混ざっている まず重複っぽいものと不要そうな一時ファイルを分けたい いきなり削除はせず、削除候補を一覧にしてから進めたい この前提で、整理の手順を提案して。必要ならコマンドも出して。 ``` これだけで、依頼の解像度がかなり上がる。Claude Code にとっての「何を
papoo.work
会話の節目で前提を 1 行に圧縮する
会話の節目で前提を 1 行に圧縮する
会話が長くなるほど、前提を抱えたまま走るのが一番だるい。Claude Code にも人間にも通じないまま話が進むと、あとで「それは最初に言ってほしかった」が必ず出る。そこで効くのが、要点の一文化、文脈サマリ、ミニ要約だ。節目ごとに前提を 1 行へ圧縮して差し込むだけで、指示のズレと手戻りがかなり減る。 Claude Code は、会話の流れで積み上がった文脈をもとに動く。だから、ファイル整理でも文書作成でも、途中で前提が変わったのに古い認識のまま作業させると、平気でズレる。たとえば「重複ファイルを消したい」の話をしていたのに、途中から「バックアップは残したい」に変わった。ここを明示せずに進めると、消してはいけないものまで整理対象に入る。そういう事故を防ぐのが、前提を 1 行で打ち直すやり方だ。 やり方は単純で、節目ごとに「今の状況」「守る条件」「この先の目的」を 1 行に畳む。長い説明は要らない。むしろ長いと、Claude Code が拾うべき核がぼやける。たとえば、こんな感じでいい。 ```text ここまでの前提: 対象は /Projects/report/ 配下、削除は不可、今回
papoo.work
再現しなかった失敗と、たまたま起きた失敗を分けて記録する
再現しなかった失敗と、たまたま起きた失敗を分けて記録する
雑に「失敗した」で片づけると、Claude Code はだいたい同じところをまた踏む。そこがまずい。再現しなかった失敗と、たまたま起きた失敗を混ぜて書くと、原因がぼやける。失敗の切り分け、偶発エラーの整理、再現性の判定を先にやるだけで、次の指示がかなり鋭くなる。 Claude Code は、曖昧な記録をそのまま信じて突っ走ると、不要な修正を広げやすい。逆に、何が毎回起きるのか、何が一度だけ起きたのかを分けて残すと、無駄なコンテキスト消費が減る。筆者は最初、エラー文をそのまま貼って「直して」と投げていたが、実際には一回しか出ていない偶発エラーまで重要扱いしてしまい、関係ない周辺ファイルまでいじられて手戻りした。あれは地味にだるい。 まずやることは単純だ。失敗ログを「再現した」「再現しなかった」「条件つきで再現した」の3つに分ける。Claude Code に頼むときも、ここを混ぜない。 たとえば、調査メモを作るならこんな書き方で十分だ。 ```text 次の失敗を整理してください。 いつ起きたか 何をしたときに起きたか 同じ操作で再現するか 1回だけの偶発エラーか その失敗が何に影響したか
papoo.work
迷子になりやすいAI機能を、会話と記録で先回りする話
迷子になりやすいAI機能を、会話と記録で先回りする話
この記事を読んでまず思ったのは、「AIで機能を作る」より先に、「機能の迷いどころを潰す」ほうがずっと大事なんだなということでした。 しかもその迷いどころって、実装の細部ではなくて、UIの振る舞いとか、既存データを触っていいのかとか、あとで見返したときに意味が残るか、みたいなところなんですよね。 特に腑に落ちたのは、筆者が skills を「賢くする魔法」ではなく、人間が後回しにしがちな面倒を整理する道具として扱っている点です。 `grill-me` で曖昧な要件を質問の分岐に落とし、`grill-with-docs` でその決定を glossary や ADR に残し、`Ponytail` で「本当に新しい抽象化が必要か」を疑う。ここ、かなり実戦的だと思いました。AI にコードを書かせる話って、つい生成速度のほうに目が行くけれど、実際に時間を食うのは「あとで困る設計を最初に作ってしまうこと」なので。 もうひとつ面白かったのは、デザイン系の skills を使う流れです。見た目を整える、ではなくて、同じアプリの中で UI の人格がブレないようにするために使っている
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の desync に当たるときに見るところ
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の desync に当たるときに見るところ
この件は、少なくとも issue 上では `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` という同じエラーでまとまっています。報告は 3 件あり、いずれも open のままで、解決済みは 0 件でした。なので、現時点では「既知の恒久的な解決策がある」とは言えません。 まず、自分のケースかどうかを切り分けるなら、エラー本文がこの形かを見ます。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=554 messages=553 range=[527,554)) at o8t (B:/~BUN/root/chunk-k298bv0z.js:36:28 ``` 同じ症状として確認できた報告は次の 3 件です。 重要なのは、少なくともこの 3 件だけを見る限り、問題の本体が「VirtualMessageList の itemKeys と messages の数がずれている」こと
papoo.work
`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出るときに見えていること
`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出るときに見えていること
この症状は、少なくとも issue 報告上では Claude Code の内部で `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ているケースとしてまとまっています。手元で確認できるのは、同じエラー文字列を含む 2 件の issue と、そこに付いた限定的なコメントだけです。現時点では、再現手順や恒久対応は issue 側でも確立していません。 まず、自分のケースかどうかを見分けるなら、エラー本文がこの文字列に一致するかを確認するのがいちばん確実です。少なくとも報告された 2 件では、`itemKeys/messages` の件数が一致していないことがログに出ています。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=101 messages=100 range=[68,101)) at Tn_ (/$bunfs/root/src/entrypoints/cli
papoo.work
`Error: Tool bash not found
`Error: Tool bash not found
at _XK (/$bunfs/root/src/entr` が出たときに見ること まず自分のケースかどうかを切り分けるなら、症状はかなりはっきりしています。Claude Code の実行中に `Error: Tool bash not found` という文言が出て、その先に `at _XK (/$bunfs/root/src/entrypoints/cli.js:4390:15288)` のようなスタックトレースが続きます。今回集まっている issue は 2 件で、どちらも closed ですが、報告内容は別の困りごとで始まりつつ、共通してこのエラーが載っています。ひとつは weekly limit の消費が想定より速いという [#66124](https://github.com/anthropics/claude-code/issues/66124)、もうひとつは AskUserQuestion の Clarify で入力した文面がモデルに渡らないという [#66224](https://github.com/anthropics/claude-code/issues/662
papoo.work
ERR_CONNECTION_REFUSED で Claude Code の OAuth が止まるときに見るところ
ERR_CONNECTION_REFUSED で Claude Code の OAuth が止まるときに見るところ
まず、この症状に当てはまるかどうかはかなりはっきりしています。issue #66332 では、Android 端末から GitHub Codespaces を使っていると、Claude Code の OAuth が `localhost:PORT/callback` に飛び、その先に接続できず `ERR_CONNECTION_REFUSED` になると報告されています。`claude setup-token` でも同じ localhost リダイレクトで失敗した、と書かれています。別件の #70415 では、ブラウザベースの Codespace（`.github.dev`）で `CLAUDE_CODE_OAUTH_TOKEN` 環境変数が無視され、ログインメニューから Claude account を選ぶとやはり localhost の OAuth callback で `ERR_CONNECTION_REFUSED` になった、という報告でした。 つまり、少なくともこの 2 件で共通しているのは、「ブラウザから localhost に戻る認証経路が使えない環境で止まる」ことです。An
papoo.work
Claude Code process terminated by signal SIGILL が出るときの切り分け
Claude Code process terminated by signal SIGILL が出るときの切り分け
この症状は、Claude Code の起動時に `SIGILL` で落ちるケースです。手元で確認できた一次情報は Linux 環境の以下の出力だけで、Claude Code 自体の実行結果は取得できていません。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-09-14T08:51:11+09:00 ``` GitHub Issue では、同じエラーが Intel Westmere 世代の CPU で報告されています。[#34481](https://github.com/anthropics/claude-code/issues/34481) と [#37065](https://github.com/anthropics/claude-code/issues/37065) のどちらも、VS Code 拡張機能側で ```text Error: Claude Code process terminated by signal SIG
papoo.work
返答を短くさせたいなら、分量の上限を伝える
返答を短くさせたいなら、分量の上限を伝える
長く返ってくるのは、Claude Code が空気を読めないからではない。こちらが「どこまで書いていいか」を渡していないからだ。 出力の長さを抑える、短く要約して返させる、分量指定。このへんを最初に言っておくだけで、返答の暴走はかなり減る。 Claude Code は、曖昧な依頼だと丁寧に埋めようとする。そこが便利でもあり、だるいところでもある。たとえば「このフォルダの内容を整理して」とだけ言うと、背景説明、手順の候補、補足、注意点まで一気に盛り込みがちだ。欲しいのが要点だけなら、最初から上限を置くのが早い。 やり方は単純で、最初の一文に分量を入れる。 ```text この内容を200字以内で要約して返して。 要点だけでいい。前置きは不要。 ``` ```text 次の手順を3点に絞って短く説明して。 各項目は1文まで。 ``` ```text この文章を短く整えて。300字以内。 重要な情報は落とさず、冗長な説明は削って。 ``` Claude Code に対しては、ただ「短くして」より「200字以内」「箇条書き3点まで」「各項目1文まで」のように、境界をはっきり切るほうが効く。人間
papoo.work
途中で要約を挟ませる：前提のズレを止める
途中で要約を挟ませる：前提のズレを止める
途中までちゃんと合っていたのに、最後の最後でズレる。Claude Code ではこれがいちばん面倒だ。たいてい原因は、最初の前提が少しずつ摩耗していることにある。定期要約、会話の棚卸し、前提の再確認を途中で挟むだけで、この手の手戻りはかなり減る。 長い作業を丸投げするときほど、モデルは「今どこまで合意済みか」を取り違えやすい。ファイル整理でも、文書作成でも、コード修正でも同じだ。最初は「不要ファイルだけ消して」と頼んだのに、途中から「似た名前のフォルダも整理しておきました」と広がっていく。ありがたいようで、実は危ない。あなたが欲しかったのは、勝手な拡張ではなく、最初の意図を保ったままの実行だ。 このズレを止める方法は単純で、途中で一回、短く要約させることだ。やっていることは、会話の棚卸しだと思えばいい。今の理解、終わったこと、未確定のことを切り分けさせる。前提の再確認まで入れればなおよい。 たとえば、Claude Code に長めの作業を頼む前に、最初からこう指示しておく。 ```text この作業は長くなるので、途中でいったん要約を挟んでください。 その時点で、 1. ここまでに確定
papoo.work
Claude Codeの裏側で、こんなものまで見えるのか
Claude Codeの裏側で、こんなものまで見えるのか
この記事を読んでまず思ったのは、「調べる気になれば、ここまで見えてしまうのか」という怖さと面白さが同時に来る、ということだった。単に「Claude Code は Firecracker 上で動いていた」ではなく、そこから先の init の役割分担、snapshot の戻し方、PID 1 が WebSocket の管理口になっているところまで、かなり生々しく掘れている。ふつうは閉じたプロダクトの内部はブラックボックスのまま終わるのに、今回は unstripped の Go binary がそのまま置かれていて、逆に隠しきれていない感じがある。 いちばん引っかかったのは、Anthropic の隠れた PaaS の話だ。Vercel だけじゃなく Antspace という別系統のデプロイ先が見つかった、というくだりは、単なる「裏で別サービスを使っていた」以上の意味があると思う。AI エージェント向けの実行環境って、もう “コードを走らせる箱” ではなくて、デプロイ、process 管理、snapshot 復帰、監視まで含んだ一体のプロダクトになっている。記事を読む限り、Claude
papoo.work
`Plan9 mount failed: invalid argument` が出たら、まず Windows 更新後かどうかを見る
`Plan9 mount failed: invalid argument` が出たら、まず Windows 更新後かどうかを見る
Claude Code の Cowork で、ホスト側は成功しているのにゲスト側だけ Plan9 のマウントが全部失敗する症状が、Windows 更新の直後にまとまって出ています。報告されている issue は [#92984](https://github.com/anthropics/claude-code/issues/92984)、[#92958](https://github.com/anthropics/claude-code/issues/92958)、[#93283](https://github.com/anthropics/claude-code/issues/93283) です。 読者がいちばん気にするのは「自分のケースかどうか」だと思うので、先に切り分けます。issue で一致しているのは、Windows 11 上の Cowork で、VM は起動するのに Plan9 share の mount だけが落ちることです。ホスト側の attach は成功扱いでも、ゲスト側では `Plan9 mount failed: invalid argument` になり、その
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の文字列が出たら見るところ
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の文字列が出たら見るところ
この症状は、Claude Code の内部で `VirtualMessageList: itemKeys/messages length desync` が起きたときのものです。今回の報告では、複数の issue で同じエラー文字列が出ています。 切り分けの起点はかなり単純で、エラー本文に次の形が入っているかどうかです。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=59 messages=58 range=[19,59)) TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=191 messages=190 range=[163,191)) TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=291 messages=290 range=[273,291)
papoo.work
`Tool result missing due to internal error` が出るときに見るべきこと
`Tool result missing due to internal error` が出るときに見るべきこと
このエラー文字列だけを見ても、同じ症状かどうかは少し分かれます。少なくとも今回の issue 群では、2 つの出方がありました。ひとつは Bash や Read の結果が 1 ターン遅れて返る、あるいは途中から消えるという報告で、[#63766](https://github.com/anthropics/claude-code/issues/63766) にあります。もうひとつは VS Code のパネル webview で AskUserQuestion が失敗し、ターミナルの TUI では動くという報告で、[#72624](https://github.com/anthropics/claude-code/issues/72624) です。 つまり、まず切り分けたいのは「ターミナルでも起きるのか」「VS Code のパネルだけなのか」です。`claude` を普通の端末で動かしたときに問題が出ないなら、[#72624](https://github.com/anthropics/claude-code/issues/72624) のように panel webview 側に寄った話
papoo.work
最後に全体をまとめ直す：引き継げる形に整える
最後に全体をまとめ直す：引き継げる形に整える
作業が終わったあとに「もう十分だろ」と放り出すと、あとで一番だるい。受け取る側が読む気を失うからだ。Claude Code を使うなら、最後にやるべき仕事は修正の上積みではない。最終要約、つまり成果物の圧縮だ。引き継げる形に整えて初めて、作業は終わる。 ここでいう「まとめ直し」は、長い説明を短くするだけではない。何をやったか、何が変わったか、残っている懸念、次に誰が触るべきかを、読み飛ばされにくい順番で並べ直す作業だ。ファイル整理でも、文書作成でも、コード修正でも効く。雑に散ったメモを、そのまま渡せる状態にする。これができると、やり直しが減る。 Claude Code に頼むときは、最初から「要約して」とだけ投げないほうがいい。あれは短くなるだけで、引き継ぎやすくはならないことがある。要点の選び方まで指示したほうが、あとで使える形になる。 たとえば、作業ディレクトリの内容を最後に整理したいなら、こう頼む。 ```bash Claude Code にこう依頼する： このフォルダ内の作業内容を、引き継ぎ用の最終要約にまとめてください。 次の順で出してください。 1. 何をやったかを3〜5行
papoo.work
返答を短くさせるなら、分量の上限を伝える
返答を短くさせるなら、分量の上限を伝える
「短くして」とだけ投げると、返ってくる文量が妙にぶれる。そこを曖昧にしたままだと、Claude Code は空気を読んでいるようで読んでいない。なら最初から上限を切る。短文指定、出力量の制御は、だいたいここで効く。 Claude Code で要点だけ欲しい場面は多い。たとえば、変更内容を一言で説明してほしいとき、長いログから異常だけ拾いたいとき、整理メモを作りたいときだ。こういうときに「短めで」と頼むだけでは弱い。短めの感覚は人によって違うし、モデル側にも余地が残る。だから、返答の長さを「感覚」ではなく「上限」で縛る。 いちばん手堅いのは、文字数か行数で切るやり方だ。たとえばこう書く。 ```text この内容を要約してください。3行以内で、箇条書きは2点まで。 ``` ```text 変更点を説明してください。120字以内で。 ``` ```text 不要ファイルの整理方針を、見出しなしで5行以内にまとめてください。 ``` この頼み方のいいところは、Claude Code が余計な前置きや保険文を足しにくくなる点だ。「短く」とだけ言うと、結局は小見出し付きのミニ解説が返ってきたりす
papoo.work
返答の形を先に固定する：Markdown か表かを決める
返答の形を先に固定する：Markdown か表かを決める
「とりあえず答えて」で始めると、あとで整形し直す羽目になる。Claude Code でもここは同じで、返答の形を先に固定するだけで手戻りがかなり減る。出力形式の指定、返答フォーマットを先に渡しておく、というやつだ。 たとえば、作業メモを整えたいのに段落だらけの文章が返ってくると、結局こちらで見出しを切り直すことになる。逆に、最初から Markdown で返させれば、見出し、箇条書き、コードブロックがそのまま使える。表が欲しいなら表に寄せる。ここを曖昧にしたまま進めるのは、箱を開けてから「やっぱりこの棚は縦じゃなく横だった」と言っているようなものだ。 Claude Code に頼むときは、まず使い道を一言で言い切る。そのうえで、返答形式を最初の条件として置く。たとえばこうだ。 ```text この作業はMarkdownで返してください。見出しは h2 相当、要点は箇条書き、最後に次の作業だけ短く書いてください。 ``` 表で欲しいなら、最初からそう言う。 ```text この内容は表で返してください。列は「項目」「内容」「補足」の3つで固定し、余計な前置きは不要です。 ``` フ
papoo.work
前提が変わったら古い指示を捨てる：言い直しで迷いを消す
前提が変わったら古い指示を捨てる：言い直しで迷いを消す
Claude Code でいちばん無駄なのは、もう変わった前提を延々と引きずることだ。昨日まで有効だった指示を、そのまま今日も抱え続けると、会話は静かに濁る。出力がズレる、修正が増える、diff が太る。地味だが、かなり痛い。 ここで効くのが、指示の更新と前提の再提示だ。要するに、「前に言ったこと」を神聖視しないで、状況が変わったら言い直す。Claude Code は長い文脈を読めるが、だからこそ古い前提をそのまま残すと、昔の依頼に引っ張られる。ファイル整理でも、文書作成でも、コード修正でも同じである。 たとえば最初は「このフォルダの重複画像を探して」と頼んだのに、途中で「いや、削除はしないで一覧だけ出して」と方針が変わったとする。このときに「さっきの続きで」などと曖昧に流すと、Claude Code は削除前提のまま手を動かし続けることがある。ちゃんと、いったん前提を上書きするのが正解だ。 実際の頼み方は、短くていい。むしろ短いほうが強い。前提を明示して、古い指示は捨てると書く。 ```text 前提を更新します。ここからは「削除しない」が正しい前提です。 重複候補は一覧だけ出してく
papoo.work
途中報告の頻度を先に決める：黙って進みすぎない
途中報告の頻度を先に決める：黙って進みすぎない
黙って最後まで走らせて、あとで「あれ、思っていたのと違う」が出る。Claude Code でもこれをやると、地味に痛い。 進捗報告、報告間隔を先に決めておくだけで、その手戻りはかなり減る。 Claude Code は、こちらが待っている間も延々と考えたり、ファイルを見たり、差分を積んだりできる。だからこそ、途中報告の頻度を先に決めておくのが効く。短い作業なら最後まで黙っていてもいいが、少しでも長引くなら、どのくらいの間隔で止まって報告するかを最初に渡しておくべきだ。これを怠ると、手元では静かでも、裏では見当違いの方向に寄っていき、最後にまとめて修正する羽目になる。 たとえば、最初の依頼文にこう書く。 ```text この作業は途中報告を入れながら進めてください。 ひと区切りごとに、今やったこと・次にやること・迷っている点を短く報告してください。 報告間隔は、作業の節目ごと、または10分ごとを目安にしてください。 大きく方針が割れそうなら、その場で止まって確認してください。 ``` ここで大事なのは、「途中で報告して」で終わらせないことだ。 それだと、Claude Code 側はどこで止
papoo.work
節目で要約を挟ませる：前提のズレを止める
節目で要約を挟ませる：前提のズレを止める
長い指示を一気に投げて、そのまま走らせる。これ、Claude Code でいちばん手戻りが増えるやり方だ。 途中で前提がズレていても、最後までそれっぽく進んでしまうのが厄介で、気づいた時には diff が太っている。そこで効くのが途中要約、つまり節目要約だ。節目ごとに「ここまでの理解」を短く言わせるだけで、ズレを早めに止められる。 Claude Code は、長い作業ほど文脈を食う。しかも人間側は「この辺で分かっているはず」と思いがちだ。だが、分かっていないまま進むことは普通にある。 要約を挟む目的は、きれいな文章を作ることではない。こちらの意図、前提、制約、残っている論点を、途中で一回棚卸しさせることだ。 たとえば、フォルダ整理でも文書作成でも同じだ。最初に雑に「整理して」「読みやすくして」と言うと、Claude Code は広く解釈する。悪気はない。むしろ素直すぎる。だから節目で止める。止めて、今どこをどう理解しているかを返させる。そこで違和感があれば、その場で直す。 実際の頼み方はこうだ。作業の最初に、途中要約のタイミングを指示しておく。 ```text この作業は段階ごとに進め
papoo.work
材料は章ごとに渡す：長文を丸ごと貼らない
材料は章ごとに渡す：長文を丸ごと貼らない
長い依頼文を一発で投げると、たいていろくなことにならない。Claude Code は賢いが、材料の山をそのまま渡せば、要点がぼやけるし、余計なところまで気を取られる。だから使うのは分割投入、つまり長文の小分けだ。 やることは単純で、長い案件文書や仕様書、整理したいフォルダの事情を、章ごとに分けて渡す。いきなり全部貼らずに、「背景」「やりたいこと」「制約」「確認したい点」を別々に処理させる。これだけで、返ってくる文章の精度がかなり変わる。ファイル整理でも同じで、巨大な一覧を丸ごと食わせるより、まず重複候補だけ、次に古いものだけ、最後に残す条件だけを渡したほうが事故りにくい。 筆者は最初、議事録の原稿を長文のまま貼って「要約して」と頼み、見出しの粒度が崩れて手戻りしたことがある。全文に対して一気に指示すると、どこが重要なのかの優先順位が曖昧になる。人間でも、20ページの資料を一度に読んで的確に直すのはだるい。同じことだ。 実際のやり方は、こんな形で十分だ。 ```text まず、次の材料はまだ要約しないで受け取ってください。 第1章: 背景 第2章: 現状の問題 第3章: 直したいこと 受
papoo.work
長い依頼は最初に区切る：一気読み前提をやめる
長い依頼は最初に区切る：一気読み前提をやめる
長い依頼をそのまま投げて、Claude Code が途中でズレる。これ、かなりありがちな失敗だ。 依頼の分割、作業の切り分けを先に入れておくと、指示の抜けや解釈違いが目に見えて減る。しかも、やり直しが起きたときの損失も小さい。長文を一発で飲み込ませる前提そのものを捨てたほうがいい。 Claude Code は、長い文章を雑に「読んでくれる」道具ではない。作業を進める相手だ。だから、最初に区切りを入れて、何を先に理解してほしいのか、何を後回しにしていいのかをはっきりさせる。これだけで、コンテキストの浪費がかなり減る。 筆者も昔、変更したいファイルの背景説明から制約から希望する書き味まで、全部を一度に貼って失敗したことがある。返ってきた内容は間違っていないのに、欲しい順番ではなかった。結果、後半の条件を見落としたまま作業が進み、差分を戻してやり直す羽目になった。あれは完全に、依頼文を一気読み前提にしたこちらの負けだ。 やることは単純だ。最初に依頼を三つくらいに切る。 たとえば、まず「何をしたいか」を渡す。次に「触っていい範囲」を渡す。最後に「出力の形」を渡す。これだけで十分な場面は多い。
papoo.work
作業ログを見返して、迷った地点を次回に生かす
作業ログを見返して、迷った地点を次回に生かす
「あとで見返せばわかる」と思って、肝心な迷い方を残していない。これがいちばんもったいない。Claude Code は作業を進める道具としては強いが、勝手に次回のための教材まで整えてくれるわけではない。だからこそ、作業ログの確認、つまり振り返りを一手間足して、迷った地点を拾い上げておくと効く。 この TIPS の狙いは、作業が終わったあとに「何をしたか」を眺めることではない。どこで詰まり、どの指示が曖昧で、どの切り分けで前に進んだかを回収して、次の依頼文にそのまま埋め込める形にすることだ。これをやると、同じ迷子を何度もやらなくて済む。特に、ファイル整理、文書作成、不要ファイルの洗い出しみたいな用途では、作業の“正解”より“迷い方”のほうが再利用しやすい。 まずやることは単純だ。Claude Code に任せた作業を終えたら、その場でログを見返し、迷った瞬間だけ抜き出す。全部読む必要はない。雑に全部読むと、ただの記録で終わる。見るべきなのは、こちらが何を曖昧に頼んだか、Claude Code がどこで確認を返したか、こちらがどの追加条件を後出ししたか、の三つだ。 たとえば、書類整理の案件で
papoo.work
「自動化」が怖い理由が、かなり具体的に見えた
「自動化」が怖い理由が、かなり具体的に見えた
この記事を読んでまず思ったのは、AIエージェントの「自動モード」って、便利さより先に“止めどころ”の設計が本丸なんだな、ということだった。 Claude Code の話は、単に「勝手に動く AI が危ない」という抽象論ではなく、どの瞬間に人間へ戻すかをかなり細かく決めている。その細かさが、逆にこの領域の難しさを浮き彫りにしているように見えた。 特に引っかかったのは、危険なコマンドを見分けるよりも、`m` や `python:*` みたいな“何を指すか曖昧な表現”のほうが、かえって自動化を壊しやすいという点だ。 人間からすると「それくらい適切に解釈してよ」と言いたくなるけれど、AIを本当に実務に入れるなら、その曖昧さこそ事故の入口になるのだろう。便利なはずの抽象化が、ここでは逆に不安定さになる。そこが面白いし、少し怖い。 もうひとつ印象に残ったのは、テストの数字そのものというより、「人間の確認を少しでも通してしまうと、危険な振る舞いがかなり抑えられる」という構図だった。 完全自動に寄せたい気持ちは分かるけれど、記事を読む限り、現時点では“全部任せる”より“要所で止まる”ほうがずっと現実的
papoo.work
Failed to start Claude's workspace - RPC error -1: SDK version 2.1.260 not verified と [Unsupported Image] が同時に出るときに見る場所
Failed to start Claude's workspace - RPC error -1: SDK version 2.1.260 not verified と [Unsupported Image] が同時に出るときに見る場所
まず切り分けたいのは、この症状が Claude Desktop 全体の不調なのか、それとも Desktop 内の Code tab だけで起きているのか、です。今回の issue [#93696](https://github.com/anthropics/claude-code/issues/93696) と [#93693](https://github.com/anthropics/claude-code/issues/93693) では、どちらも「Claude Desktop on Windows」で画像を送ると `[Unsupported Image]` になり、さらに workspace の起動に `Failed to start Claude's workspace - RPC error -1: SDK version 2.1.260 not verified` が出る、と報告されています。 ここで重要なのは、コメントでこの workspace エラーが「Claude Desktop 固有ではなく、Claude Desktop アプリ内で動く Claude Code の
papoo.work
ENOTDIR が出るときに見るべき 2 つの壊れ方
ENOTDIR が出るときに見るべき 2 つの壊れ方
まず、この `ENOTDIR` は 1 つの症状に見えて、少なくとも issue 上では 2 つの壊れ方が報告されています。どちらも「ディレクトリとして扱うはずの場所が、そう扱えない」という点は共通ですが、起きる場所が違います。 ひとつは、デスクトップアプリでセッションを fork するときです。`~/.claude/projects/<project>` がシンボリックリンクになっている環境で、`LocalSessions.forkSession` の IPC ハンドラが `ENOTDIR` を投げ、UI 側でエラーが飲み込まれてしまう、という報告でした。結果として何も起きないか、親履歴のない空の新規セッションになるようです。これは [#90931](https://github.com/anthropics/claude-code/issues/90931) に書かれています。 もうひとつは Bash tool 側です。こちらはコマンドが走る前に落ちます。issue では、セッションディレクトリを `/proc/self/fd/N/` 経由で作ろうとして `ENOTDIR` になっ
papoo.work
`OAuth session expired and could not be refreshed` が出るときにまず確認したいこと
`OAuth session expired and could not be refreshed` が出るときにまず確認したいこと
この症状は、少なくとも issue [#81937](https://github.com/anthropics/claude-code/issues/81937) と [#93521](https://github.com/anthropics/claude-code/issues/93521) で報告されています。どちらも「OAuth のセッションが期限切れで、更新できない」という同じ文言に見えますが、出方が少し違います。 ```text Failed to authenticate: OAuth session expired and could not be refreshed ``` ```text Failed to authenticate. API Error: 401 {"type":"error","error":{"type":"authentication_error","message":"OAuth access token has been revoked."},"request_id":null} ``` 一方 [#93521](https://gith
papoo.work
Claude Desktop で HTTP 503 が出るときに見えていたこと
Claude Desktop で HTTP 503 が出るときに見えていたこと
まず切り分けたいのは、「起動時や設定画面の読み込みで 503 が返っている」のか、それとも「一度サインインできたあと、裏側の認証や設定取得だけが失敗している」のかです。今回の issue では、その両方に近い報告がありました。 一方で [#93577](https://github.com/anthropics/claude-code/issues/93577) は、`app://localhost/setup-desktop-3p` を開くと常に「Unable to load configuration」になり、ログには次のように出ています。 ```text ``` この issue では、Claude-3p の profile cache は消しても改善せず、アプリは最新バージョンで、OAuth 側の `invalid_grant / session_stale_relogin` はフルログアウトと再ログインで解消済みでした。それでも 503 は残っています。コメントでは「Claude Code の issue には見えないので、必要なら新規 issue を」と案内されており、少な
papoo.work
`ERR_INVALID_ARG_TYPE` が出て Chrome / Brave の native host が落ちるときの切り分け
`ERR_INVALID_ARG_TYPE` が出て Chrome / Brave の native host が落ちるときの切り分け
最初に見ておきたいのは、これが Windows 系の issue に寄っているかどうかです。今回の報告はどちらも Windows 11 上で、Claude Code の Chrome 連携まわりの native host が起動直後に `ERR_INVALID_ARG_TYPE` で落ちる、という形でした。ひとつは [#57846](https://github.com/anthropics/claude-code/issues/57846)、もうひとつは [#76556](https://github.com/anthropics/claude-code/issues/76556) です。 この症状に当たっているかは、かなりはっきりしています。Claude Code の Chrome 連携を使った瞬間に、拡張機能が「接続されていない」扱いになる。あるいは native host 自体がすぐ死んで、`ERR_INVALID_ARG_TYPE` が見える。どちらも issue 側では Windows 上の再現例でした。少なくとも、今回集められた報告からは macOS や Linux での
papoo.work
`Failed to start Claude's workspace — Download failed. Check your internet connection and try again.` が出るときに見る場所
`Failed to start Claude's workspace — Download failed. Check your internet connection and try again.` が出るときに見る場所
この症状に当てはまるかどうかは、まず「どの画面で止まるか」でかなり絞れます。今回の issue では、Cowork の workspace 起動時にだけ `Failed to start Claude's workspace — Download failed. Check your internet connection and try again.` が出ています。通常の Chat は動いていて、workspace の開始だけ失敗する、という切り分けでした。macOS 側の報告ではダウンロードバーが 1〜2% で止まったあと失敗し、Windows 側の報告では UI 上はネットワーク失敗に見えるものの、ログでは VM バンドルの取得・展開・検証までは通っています。 つまり、このエラー文そのものをそのまま「回線不良」と受け取ると外す可能性があります。少なくとも報告されている 2 件では、見た目の文言と実際の原因が一致していませんでした。 macOS 側の issue は [#64234](https://github.com/anthropics/claude-code/issues
papoo.work
`respawn pane failed: fork failed: Device not configured` が出るときに見るところ
`respawn pane failed: fork failed: Device not configured` が出るときに見るところ
この症状は、Claude Code の Agent Teams と tmux の組み合わせで、teammate の spawn が失敗したときに報告されています。代表例は [#77559](https://github.com/anthropics/claude-code/issues/77559) です。報告文では、`Failed to send command to pane %2: respawn pane failed: fork failed: Device not configured` という形で失敗しており、別の pane `%3` でも同じエラーが出ています。Issue 本文では、`ENXIO / "Device not configured"` は「harness が tty を失った pane を指している」ことを示唆すると書かれています。 まず自分のケースかどうかを見分けるなら、次の2点が合っているかを確認するとよさそうです。ひとつは、Agent Teams の tmux セッションで teammate の spawn 時にだけ落ちること。もうひとつは、エラーメ
papoo.work
Error: CreateSession 400: {"error":{"message":"GitHub repository access check failed — re-authorize GitHub in settings" で止まる /ultrareview の見分け方と、手元で確認できたこと
Error: CreateSession 400: {"error":{"message":"GitHub repository access check failed — re-authorize GitHub in settings" で止まる /ultrareview の見分け方と、手元で確認できたこと
この症状は、`/ultrareview` 実行時に `CreateSession 400` で落ち、本文に `github_repo_access_denied` と `re-authorize GitHub in settings` が入っているものです。報告としては [#56000](https://github.com/anthropics/claude-code/issues/56000) と [#65708](https://github.com/anthropics/claude-code/issues/65708) が同じ文字列を含んでいました。 まず切り分けたいのは、`gh auth status` が通るかどうかではありません。issue 側では、`gh auth` が有効でも、Claude 側の GitHub 認証チェックで失敗しています。[#56000](https://github.com/anthropics/claude-code/issues/56000) の報告には、`gh auth status` はログイン済み、トークンの scope もあり、`gi
papoo.work
authentication expired と出るのに、gh は正しくログインしているように見えるとき
authentication expired と出るのに、gh は正しくログインしているように見えるとき
まず、この表示が自分のケースかを切り分けます。Issue [#67087](https://github.com/anthropics/claude-code/issues/67087) では、Claude Desktop が > GitHub CLI authentication expired. Run `gh auth login` to refresh pull request status. というバナーを繰り返し出していた一方で、同じセッション内で `gh auth status`、`gh api user`、`gh pr status` が成功していました。コメントでは、`main.log` にその日の `gh/auth` 関連の `[error]` がなく、`LocalSessions.getPrChecks` のポーリングも失敗していない、と報告されています。つまり、少なくともこの issue では「本当に期限切れの認証情報が壊れている」という単純な話ではありませんでした。 もう一つの issue [#84214](https://github.com/anthrop
papoo.work
数字があると、雑な最適化はすぐ終わる
数字があると、雑な最適化はすぐ終わる
この記事を読んでまず思ったのは、「やっぱり体感だけでは当てにならないんだな」という、わりと当たり前だけど痛い話でした。 著者は「この agent が遅そう」と感じていたところを計測したら、実は別の reviewer 系がもっと重かった。ここが面白いです。人間の“なんとなく遅い”は、だいたい外れる。しかも、その思い込みを放置したまま使い続けると、毎週のコストがじわじわ食われる。この記事はそのズレを、Stop hook で自動収集したログでひっくり返していました。 特に刺さったのは、Claude Code の session が終わるたびに transcript を拾って、subagent の起動と結果を JSONL に積んでいく発想です。手で記録しない。あとで思い出して整形もしない。ただ終わった瞬間に証拠を取る。こういう仕組みは、地味ですが強いと思います。しかも本体を改造せず、既存のイベントにぶら下がるだけというのがいい。運用が重いほど、「触る場所が少ない」こと自体が価値になります。 一方で、読みながら少し引っかかったのは、実装がちゃんとしているほど、逆に“人間の理解”がどんどんログと
papoo.work
Unity公式Claude Codeプラグインを読んで
Unity公式Claude Codeプラグインを読んで
いちばん引っかかったのは、「AIにゲームを作らせる」というより、「Unityの作法を先に教え込む」方向にかなり寄っていることでした。ここ、地味だけど大事だと思います。汎用のコーディングエージェントって、動くものはそれなりに作れても、現場の流儀までは平気で外してくる。UIフレームワークを勝手に別物で済ませたり、アセットの置き方が雑だったり。そういう“なんとなく動くけど、後で困る”感じは、AI支援が広がるほどむしろ目立つはずです。 だから、Unity公式が「29のスキル」としてベストプラクティスを渡すのは、かなり筋がいいと感じました。単に便利機能を足したというより、AIの暴れ方をゲームエンジン側で制御しようとしている。特に、トークン消費を減らすとか手戻りを減らすという説明は、理想論ではなく現実的です。AIを使っていて一番しんどいのは、賢そうに見えて話が長いだけで、結局やり直しになる瞬間なので。 一方で、これで「AIがUnityを理解した」と思うのは早い気もします。あくまで、Unityの“よくある正解”を渡しているだけで、複雑な設計判断やプロジェクト固有の事情まで吸収できるわけではないでしょ
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たら、まずこの2件の issue と突き合わせる
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たら、まずこの2件の issue と突き合わせる
このエラーに当たった場合、少なくとも今回渡された issue 報告では、症状の軸がかなりはっきりしています。 `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` で、`keys` と `messages` の件数がずれている状態です。該当する報告は [#88052](https://github.com/anthropics/claude-code/issues/88052) と [#87872](https://github.com/anthropics/claude-code/issues/87872) の2件でした。どちらも open で、解決済みの報告はありません。 まず、自分のケースかどうかを見るなら、次の3点です。 エラー文に `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が入っている `keys=... messages=...` のように、両者の数が1件ずれている スタックト
papoo.work
`Failed to start Claude's workspace — VM service not running.` が出たときに、まず疑うべきこと
`Failed to start Claude's workspace — VM service not running.` が出たときに、まず疑うべきこと
このエラーは、少なくとも今回読んだ issue 群では Windows 側の仮想化まわりと強く結びついています。 ただし、根っこは 1 つではなさそうです。報告を追うと、同じ文言でも原因が違うケースが混ざっています。 最初に切り分けたいのは、自分の症状がどちら寄りかです。 つまり、この系統では「Windows の仮想マシン機能が無効」「必要な機能が入っていない」側をまず疑うのが自然です。 一方で [#82688](https://github.com/anthropics/claude-code/issues/82688) では、原因がもっと単純で、`CoworkVMService` が `Stopped` になっていただけだったケースが報告されています。 この報告では、`Start-Service CoworkVMService` を通常権限で実行するとすぐ直った、とされています。アプリ側が再起動や再インストールを勧めるより先に、サービス自体を起動すべきだ、という指摘です。 この 2 件だけでも、エラー表示が同じでも対処は同じではないと分かります。 「Windows の機能が
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le で引っかかるときにまず見ること
TelemetrySafeError: VirtualMessageList: itemKeys/messages le で引っかかるときにまず見ること
この症状は、Claude Code 側で `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ているケースです。今回集められている issue は 4 件すべて open で、解決済みは 0 件でした。つまり、少なくともこの時点では「こうすれば直る」と言い切れる定番の解決策は見えていません。 最初に確認したいのは、自分のケースが報告済みのどれに近いかです。たとえば、[#93359](https://github.com/anthropics/claude-code/issues/93359) ではセッション上限に早く達したという報告があり、[#93332](https://github.com/anthropics/claude-code/issues/93332) でも短時間で使用量が 0% から 100% に跳ね上がったと書かれています。どちらも、会話量やコンテキスト消費の見え方に違和感があるという点で重なっています。 一方で、[#93492](https://github.com/
papoo.work
節目ごとに要約を挟ませて、長い会話でも前提を保つ
節目ごとに要約を挟ませて、長い会話でも前提を保つ
長い会話で詰まる人は、だいたい「最初の前提がどこかで抜ける」ことを軽く見ている。Claude Code でもこれは同じだ。作業が進むほど、会話の文脈はじわじわ重くなる。途中で条件が増え、方針が変わり、古い依頼文と今の依頼文が混ざる。そこで効くのが途中要約、つまり節目のサマリーだ。節目ごとに短く整理させておくと、後半で前提が崩れにくい。結果として、手戻りと再説明が減る。 筆者は最初、これをサボって痛い目を見た。大きめの整理作業を Claude Code に任せ、途中で「この方針のまま続けて」とだけ投げたら、会話の後半で古い判断を引きずったまま進められた。修正はできるが、戻り道を探すのがだるい。長い会話は、放っておくと「今の前提」と「昔の前提」が同居する。要約を挟むのは、その混線をほどくための地味だが強い手だ。 やり方は単純だ。大きな区切りごとに、Claude Code に「ここまでを短く整理して」と頼むだけでいい。たとえば、計画を立てたあと、数ファイルを触ったあと、方針変更を入れたあと、最後の仕上げに入る前。このあたりで途中要約を挟む。 実際の頼み方はこうだ。 ```text ここまでの
papoo.work
画面に出すだけでは足りない、という話
画面に出すだけでは足りない、という話
読んでいてまず思ったのは、これ、かなり「わかる」と「そこまでやるのか」が同時に来る記事だな、ということだった。Claude Code みたいな coding agent は便利だけれど、結局のところ人間が読むにはしんどい。端末に長い文章をそのまま流されると、どこが重要なのか拾うだけで疲れる。そこを HTML に逃がす、という発想はかなり自然だと思う。 一方で、記事の熱量は高いのに、少し引っかかったのは「90〜95% は HTML で受け取る」「1日に100回使う」といった話の勢いだ。もちろん、著者の作業環境では本当に効くのだろう。ただ、これは coding agent 全般の普遍解というより、かなりその人の運用に最適化されたやり方に見える。つまり、誰にでもそのまま刺さるというより、「人が読むべき出力をどう設計するか」を徹底して考えた結果の一例なんだと思う。 面白かったのは、単に見た目を整える話ではなく、情報の置き場所そのものを変えている点だった。端末の途中や末尾に散らばると読み逃すから、下部に寄せる。それでも足りないから、HTML にして見出しや強調、図まで使う。ここには「AI との会
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync が出るときに見えていること
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync が出るときに見えていること
この症状は、Claude Code の画面側で `VirtualMessageList: itemKeys/messages length desync` という不整合が起きている報告として上がっています。今回の範囲では、解決策が確立したとは言えません。少なくとも、参照できた issue はどちらも open のままでした。 自分のケースかどうかを先に切り分けるなら、エラー本文に `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が入っているかを見ます。報告されている差分は、`keys=25 messages=24` のように 1 件ずれている例と、`keys=192 messages=191` のように同じく 1 件ずれている例です。どちらも `range=[...,...)` を伴っていました。ここから分かるのは、メッセージ一覧の内部状態がずれたタイミングで例外が出ている、という点までです。 関連する報告は次の 2 件です。 ```text TelemetrySafeError: Vi
papoo.work
`Starting connection with timeout of 30000ms` が出るときに、まず疑うこと
`Starting connection with timeout of 30000ms` が出るときに、まず疑うこと
この文字列が出たからといって、ただちに「通信が遅い」の一言では片づきません。今回の 2 件の issue では、どちらも MCP サーバーが期待どおり起動しない、あるいは起動のしかたが想定とずれる ところまで話が進んでいました。 つまり、この症状は「接続先が遠い」よりも、「起動時にサーバーが落ちる」「同じサーバーが二重に起動する」といった、MCP 側の立ち上がり方に目を向けたほうがよさそうです。 まず見たいのは、エラーの出方です。`Starting connection with timeout of 30000ms` のあとに、`CONNECTION_CLOSED` や `Invalid Version:` が続くなら、[#93134](https://github.com/anthropics/claude-code/issues/93134) の流れにかなり近いです。少なくともその issue では、プラグインの manifest 経由で起動した `desktop-commander` の MCP サーバーが、`npm` の時点で止まっていました。 一方で、ツールがまった
papoo.work
TelemetrySafeError: task output swap refused (output is an unregistered symlink made during this session): /private/tmp/claude-501/-Users-amit-Personal-auxill-p が出るときに見えていること
TelemetrySafeError: task output swap refused (output is an unregistered symlink made during this session): /private/tmp/claude-501/-Users-amit-Personal-auxill-p が出るときに見えていること
この症状は、少なくとも GitHub Issue の報告上では、Claude Code の実行中に `TelemetrySafeError: task output swap refused (output is an unregistered symlink made during this session)` が返っているケースです。報告は2件あり、[#91435](https://github.com/anthropics/claude-code/issues/91435) は closed、[#91042](https://github.com/anthropics/claude-code/issues/91042) は open です。どちらも同じエラー文字列を含んでいますが、原因の説明や恒久的な解決策は issue 本文だけでは確定していません。 まず、あなたのケースがこのクラスタに当たるかを見るなら、エラー文に次の部分が入っているかを確認します。 ```text TelemetrySafeError: task output swap refused (output is
papoo.work
Workspace unavailable. The isolated Linux environment failed to start (VM connection timeout after 60 seconds) が出るとき、まず確認したいこと
Workspace unavailable. The isolated Linux environment failed to start (VM connection timeout after 60 seconds) が出るとき、まず確認したいこと
この症状に当てはまるかどうかは、かなりはっきりしています。Claude Cowork で `mcp__workspace__bash` を使ったときに、次のような文言が交互に出るケースです。 `Workspace unavailable. The isolated Linux environment failed to start (VM connection timeout after 60 seconds).` `Workspace still starting. The isolated Linux environment is booting in the background (usually 10–30 seconds). Try again shortly.` 報告された issue では、これが既存セッションでも新規セッションでも続いていました。[#76374](https://github.com/anthropics/claude-code/issues/76374) と、続報の [#92008](https://github.com/anthropics/clau
papoo.work
The model's tool call could not be parsed (retry also failed): first attempt で失敗して、同じ tool call の再送で通る症状
The model's tool call could not be parsed (retry also failed): first attempt で失敗して、同じ tool call の再送で通る症状
自分のケースかどうかを先に切り分けるなら、確認したいのは「ツール呼び出しが最初の1回だけ壊れるか」「同じ内容をもう一度送ると通るか」です。今回の issue 群では、その挙動がかなりはっきり出ています。 > "Your tool call was malformed and could not be parsed. Please retry." > "The model's tool call could not be parsed (retry also failed)." この issue では、Bash だけでなく Edit、Write、Read、ToolSearch、Workflow、MCP tools まで、ツール種別をまたいで起きると書かれています。つまり、特定のツール固有の入力ミスだけでは説明しきれない状況です。 > "The model's tool call could not be parsed (retry also failed)." 代表 issue のコメントでは、重複の可能性がある issue として [#64774](https://github.com
papoo.work
MaxFileReadTokenExceededError: File content (28289 tokens) exceeds maximum allowed tokens (25000). Use offset and limit parameters to read specific portions of を見たときに確認したいこと
MaxFileReadTokenExceededError: File content (28289 tokens) exceeds maximum allowed tokens (25000). Use offset and limit parameters to read specific portions of を見たときに確認したいこと
この症状でまず目に入るのは、Claude Code が大きなファイルを読み切れずに止まっている、という点です。issue では、`MaxFileReadTokenExceededError: File content (...) exceeds maximum allowed tokens (25000). Use offset and limit parameters to read specific portions of the file, or search for specific content` という文言が繰り返し出ています。報告されているのは [#73486](https://github.com/anthropics/claude-code/issues/73486) と [#68927](https://github.com/anthropics/claude-code/issues/68927) です。 ```text MaxFileReadTokenExceededError: File content (28289 tokens) exceeds maxim
papoo.work
`Host denied (verification failed)` が出るときに、まず疑うこと
`Host denied (verification failed)` が出るときに、まず疑うこと
このエラーは、少なくとも報告上は 2 つのまったく違う場面で出ています。ひとつは SSH でリモートフォルダに入るとき、もうひとつは Claude Desktop の Code タブで Cowork VM を作るところです。どちらも最終的には同じ文言ですが、引き金は同一とは限りません。 まず自分のケースに近いかを切り分けると、[#64425](https://github.com/anthropics/claude-code/issues/64425) は「同じホストでもホスト名の書き方で成否が変わる」例でした。`root@frigate.ahfp` や `root@pve.ahfp` では失敗し、`frigate.ahfp.local` や `orangepi@wait-room-kiosk.ahfp` では成功しています。つまり、少なくともこの報告では “接続先そのもの” より “ホスト名の表記” に症状が結びついています。 一方で [#64867](https://github.com/anthropics/claude-code/issues/64867) は Windows
papoo.work
EADDRINUSE が出るときに疑うこと: Claude Code の 2 つの報告
EADDRINUSE が出るときに疑うこと: Claude Code の 2 つの報告
まず切り分けたいのは、いま見ている `EADDRINUSE` が「自分の環境でも再現する、同じ系統の問題かどうか」です。今回の issue 群では、症状の出方が 2 通りあります。 ひとつは、Linux 上の daemon supervisor が control socket の `bind()` に失敗して落ちるケースです。[#72334](https://github.com/anthropics/claude-code/issues/72334) では、`EADDRINUSE` で `control.sock` を掴めず、`transient` 側の分岐がそのまま致命的終了する、という報告でした。コメントでは、同じ症状が `2.1.196` と `2.1.197` でも続いていたこと、`~52s` 間隔で supervisor が再起動し、競合が起きるときは `control.sock` まわりでレースが起きることが書かれています。実際のログ断片も示されています。 ```text ``` もうひとつは、Claude in Chrome の bridge が、同時に接続している
papoo.work
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` で止まるときに見ておくこと
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` で止まるときに見ておくこと
まず、自分のケースかどうかを絞ります。今回の症状クラスタでは、どちらの issue でも同じ系統のエラーが出ています。ひとつは [#88174](https://github.com/anthropics/claude-code/issues/88174)、もうひとつは [#87911](https://github.com/anthropics/claude-code/issues/87911) です。どちらも報告されている本体は `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` で、`keys` と `messages` の数がずれている、と読めます。 ```json ``` ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=681 messages=680 range=[632,681)) at Bpw (B:/~BUN/root/cli:23083:33891)
papoo.work
`Error: Connection error.
`Error: Connection error.
at makeRequest (/$bunfs/root/sr` が出るときに見えているもの この症状は、Claude Code の CLI 内部で `makeRequest` から `Connection error` が投げられている状態として、少なくとも 2 件の issue で報告されています。該当するのは [#83872](https://github.com/anthropics/claude-code/issues/83872) と [#82703](https://github.com/anthropics/claude-code/issues/82703) です。どちらも報告されたエラー文字列は同じで、いま手元で確認できる範囲では、このエラー文そのものだけでは原因を一つに絞れません。 見えている issue の内容はかなり違います。#83872 は、cybersecurity 系の safeguard に触れたあとで `/rewind` を実行すると、繰り返し同じエラーに落ちるという報告でした。報告者は「cybersecurity pentest のレポート作成用の
papoo.work
`Registration: Authentication failed (401): Missing Authorization header.` が出るときに見ること
`Registration: Authentication failed (401): Missing Authorization header.` が出るときに見ること
この症状は、`claude remote-control` の登録段階で止まり、401 とともに `Missing Authorization header` と出るケースです。今回の報告では、[`#83958`](https://github.com/anthropics/claude-code/issues/83958) と [`#83976`](https://github.com/anthropics/claude-code/issues/83976) のどちらも、登録フェーズで同じエラーに落ちています。 まず切り分けたいのは、「単に認証が切れている」のか、「Authorization ヘッダー自体が送られていない」のかです。issue #83958 では、当日の新しく発行された OAuth トークンでは Authorization ヘッダーが送られず、同じ CLI バージョンでも朝は古いトークンで送れていた、という観察が書かれています。つまり、少なくともその報告では、ユーザー操作のミスというより CLI 側の挙動に見えます。 issue #83976 では、同じアカウ
papoo.work
`MCP server process is running, the new files are not copied` が出るときにまず見ること
`MCP server process is running, the new files are not copied` が出るときにまず見ること
この症状は、Claude Code のプラグインを更新したのに、MCP server が古いファイルを掴んだままで新しい内容が反映されない、という報告です。参照できる報告は [#72678](https://github.com/anthropics/claude-code/issues/72678) と [#75674](https://github.com/anthropics/claude-code/issues/75674) の 2 件で、どちらも closed になっていますが、コメントを見る限り「再現手順が足りないので調査継続のために新しい issue を出してほしい」という扱いでした。 まず、自分のケースかどうかを切り分けるなら、次の見え方に一致するかを見ます。issue 本文では、プラグイン更新時に MCP server process が動いていると、新しいファイルが `~/.claude/plugins/data/<plugin>/` にコピーされず、`installed_plugins.json` だけは新しい version を指す一方で、実体の binary
papoo.work
Claude Code で `HTTP 502` が出るときに見ておくこと
Claude Code で `HTTP 502` が出るときに見ておくこと
まず、この `HTTP 502` が自分のケースかどうかは、出方でだいたい分かれます。今回集まっている報告では、`claude code` の実行時に `API Error: 502 Bad Gateway` と返るケースと、remote/cloud sandbox で GitHub へのアクセス自体が `502 Bad Gateway` に落ちるケースの 2 つがありました。前者は [#69785](https://github.com/anthropics/claude-code/issues/69785)、後者は [#73273](https://github.com/anthropics/claude-code/issues/73273) です。 もう一方の [#73273](https://github.com/anthropics/claude-code/issues/73273) は、`isolation: "remote"` の background agent で GitHub につながらない話です。ここでは、許可済みの private repo の `git clo
papoo.work
会話が長くなったら節目で要約させる：前提を保って進める
会話が長くなったら節目で要約させる：前提を保って進める
長い会話は、だいたい前提がこぼれて終わる。 Claude Code でも同じで、途中までうまく進んでいたのに、少し話が伸びただけで「最初に何を守る話だったか」が薄れる。そこで効くのが、長い会話の要約、あるいは節目要約だ。要するに、途中で一度立ち止まって「ここまでの前提・決定・未解決」を短く固め直す。これを入れるだけで、手戻りが目に見えて減る。 筆者は最初、これを面倒がっていた。すると何が起きるか。数十ターン後に、Claude Code が別の前提で続きを書き始める。ファイル名の方針、削除対象の範囲、文章のトーン、どれか一つでもズレると、修正が雪だるま式に膨らむ。特に文書作成やファイル整理では、会話が長いほど「前に決めたこと」が効いてくる。節目で要約させるのは、機能というより事故防止の作法だ。 やり方は単純だ。会話がある程度進んだところで、Claude Code にその場の状態を要約させる。ポイントは、ただの要約ではなく、次に続けるための要約にすることだ。要約の中に、目的、前提、決定事項、未解決事項、次にやることを入れる。 たとえば、こう頼めばいい。 ```text ここまでの会話を、次
papoo.work
Error: ELOOP: too many symbolic links encountered, open '/pr で止まるときに見えたこと
Error: ELOOP: too many symbolic links encountered, open '/pr で止まるときに見えたこと
この症状は、`Error: ELOOP: too many symbolic links encountered, open '/private/tmp/claude-...` で始まるエラーとして issue に上がっています。今回確認できたのは、どちらの報告も `/private/tmp/claude-...` 配下の一時パスを開く場面で `ELOOP` が出ていることです。少なくとも報告ベースでは、Claude Code の操作中に一時領域のファイルを開こうとして失敗しているように見えます。 参照できた issue は次の 2 件です。どちらも open で、解決済みではありません。 報告内容をそのまま見ると、`ELOOP` が出る直前のパスはどちらも似ています。1 件目は `competition-module` を含むパス、2 件目は `btf3k0ktq.output` を含むパスでした。完全な再現手順までは issue からは読めませんが、少なくとも「一時ディレクトリ下の対象ファイルを開くときにシンボリックリンクが絡んでいる」状態を疑うのが自然です。とはいえ、ここまでしか
papoo.work
UnexpectedApiResponseError: API returned an empty or malformed response を見たときにまず疑うこと
UnexpectedApiResponseError: API returned an empty or malformed response を見たときにまず疑うこと
この症状は、Claude Code 側が「HTTP 200 は返ってきたのに、中身が期待した応答になっていない」と判断したときに出ています。今回渡された issue はどちらも同じ系統で、非ストリーミングのリクエストに対して event-stream が返ってきた、という報告でした。 自分のケースかどうかを見分ける手がかりは、エラーメッセージの中に `content-type event-stream` や `body is an event stream` が含まれているかどうかです。[#87842](https://github.com/anthropics/claude-code/issues/87842) では「non-streaming request was answered with a stream」と明記されていましたし、[#89232](https://github.com/anthropics/claude-code/issues/89232) でも同じ文言が出ています。どちらも HTTP 200 で返ってきているのに、レスポンスの形式が合っていません。 issu
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync で止まるときに見えていたこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync で止まるときに見えていたこと
まず、自分の症状が同じかどうかは、エラーメッセージの形でかなり絞れます。今回のクラスタでは、`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ていて、`keys=... messages=... range=[...,...)` のように itemKeys と messages の件数差まで表示されています。本文で確認できたのはこの型のエラーで、少なくとも issue 報告上は別件を含めて同じクラスタとして扱われていました。 報告されていた issue は 2 件です。[#83109](https://github.com/anthropics/claude-code/issues/83109) では `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=325 messages=324 range=[279,325))`、[#81878](https://github.com/an
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync の切り分けメモ
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync の切り分けメモ
まず、自分のケースかどうかを先に見ます。今回の症状は、Claude Code の issue に `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=82 messages=81 range=[51,82))` という形で報告されています。関連する報告は [#84239](https://github.com/anthropics/claude-code/issues/84239) と [#84283](https://github.com/anthropics/claude-code/issues/84283) の 2 件で、少なくとも issue 上ではどちらも同じ種類のエラー文字列を含んでいました。 この時点で言えるのは、エラー名がかなり具体的で、`itemKeys` と `messages` の件数がずれている、という内部状態の不整合を示しているらしいことです。ただし、issue の本文だけでは、何がそのずれを起こしたのかまでは分かりません。少なくとも、報告者は「指示どおり
papoo.work
gh が出てくるのに GitHub 連携が効いているとは限らない話
gh が出てくるのに GitHub 連携が効いているとは限らない話
「Claude Code が `gh` を呼ぼうとした」という症状だけを見ると、GitHub CLI が入っている前提の話に見えます。ですが、今回の issue 群では少し事情が違います。 ```shell Bash(gh issue view 17033 --repo FreeCAD/FreeCAD --comments) ⎿ Error: Exit code 127 /usr/bin/bash: line 1: gh: command not found ``` この報告から分かるのは、少なくともその環境では `gh` が見つからず、しかもユーザーが止めたい対象は Git コマンドだけではなく GitHub 系の操作も含んでいた、ということです。報告者自身も「Claude should not run any commands that interacts with git. Including github commands.」と書いています。つまり、`git` だけ禁止しても、`gh` を使った GitHub 操作までは止め切れていません。 もう一方の [#87795](ht
papoo.work
`Error: Lock is already released
`Error: Lock is already released
at <anonymous> (/$bunfs/` が出るときに見えているもの この症状は、少なくとも報告上は Claude Code の CLI 内部で `Error: Lock is already released` が出ているケースです。Issue では、入力プロンプトの途中で短い入力が別の操作として拾われる、あるいはセッション中の処理でトークンを使い切る、といった別の現象と一緒に報告されています。該当する報告は [#65137](https://github.com/anthropics/claude-code/issues/65137) と [#76742](https://github.com/anthropics/claude-code/issues/76742) です。 ただ、ここで大事なのは「同じ文字列が出たから同じ原因」とは言い切れないことです。少なくとも今回の issue 群だけを見ると、入力まわりの誤作動と、セッション内の消費が想定外に大きくなった件が混ざっています。どちらも最終的に同じ `Lock is already released` に見えているだけか
papoo.work
Error: 400 {"type":"error","error":{"type":"invalid_request_ no low surrogate in string が出るときに見えること
Error: 400 {"type":"error","error":{"type":"invalid_request_ no low surrogate in string が出るときに見えること
この症状は、Claude Code から送ったリクエスト本文が JSON として受け付けられず、`no low surrogate in string` というエラーで 400 が返っているケースとして報告されています。今回渡された issue では、少なくとも [#60394](https://github.com/anthropics/claude-code/issues/60394) と [#68744](https://github.com/anthropics/claude-code/issues/68744) の両方で、同じ形のエラーが出ています。 まず自分のケースかどうかを見分けるには、エラーメッセージの中に次の文言があるかを確認します。 ```text Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"The request body is not valid JSON: no low surrogate in string: line 1 column 19562
papoo.work
Error: 1: Command failed with ERR_STREAM_PREMATURE_CLOSE: code --force --install-extension anthropic.claude-code が出たときに見えたこと
Error: 1: Command failed with ERR_STREAM_PREMATURE_CLOSE: code --force --install-extension anthropic.claude-code が出たときに見えたこと
この文字列が出ているなら、少なくとも報告上は `code --force --install-extension anthropic.claude-code` の実行が `ERR_STREAM_PREMATURE_CLOSE` で途中終了しています。今回の手元の出力と、同じ症状として挙がっていた issue を照らすと、これは Claude Code のインストール処理まわりで起きた失敗として読むのが自然です。 まず切り分けたいのは、自分のケースが「同じエラー文字列に当たっているだけ」なのか、「同じインストール失敗の流れ」なのかです。今回参照できた issue は 2 件で、どちらも報告されたエラーは同じでした。 どちらの issue でも、見えているエラーは次の形です。 ```text Error: 1: Command failed with ERR_STREAM_PREMATURE_CLOSE: code --force --install-extension anthropic.claude-code Premature close at cl1 (/$bunfs/root/s
papoo.work
`temporarily unavailable` が出て Bash や Edit が止まるときに見ること
`temporarily unavailable` が出て Bash や Edit が止まるときに見ること
まず、自分のケースかどうかはかなり見分けやすいです。Claude Code の auto mode で Bash か Edit を実行しようとしたとき、次のような文言が出て処理が止まるなら、今回の症状に当たっている可能性があります。 > `claude-opus-4-7 is temporarily unavailable, so auto mode cannot determine the safety of Bash right now. Wait briefly and then try this action again. If it keeps failing, continue with other tasks that don't require this action and come back to it later.` この報告は issue [#62170](https://github.com/anthropics/claude-code/issues/62170) にあり、Bash safety classifier が `claude-opus-4-7` で
papoo.work
同じファイルを同時に触らせないだけで、コンフリクトは減る
同じファイルを同時に触らせないだけで、コンフリクトは減る
「差分が悪い」のではない。たいていは、同じ場所を同時に触らせた運用が雑だ。 Claude Code でコンフリクトを減らしたいなら、まずやることは派手な自動化ではない。同じファイルを同時に触らせない。これだけでかなり効く。別名でいうなら、コンフリクトの芽を摘む、あるいは編集箇所の分離だ。 筆者も最初は、1 つの大きい指示にまとめて投げていた。すると Claude Code はちゃんと仕事をするのに、最後に差分を合わせる段階で疲れる。README、設定ファイル、サンプル、文書本文を一気にいじると、修正の意図は合っていても、競合の処理だけで手戻りが出る。そこで分けた。すると、見た目は地味だが、衝突は目に見えて減った。 要は、Claude Code に「何を直すか」だけでなく、「何を同時に直さないか」まで渡すのがコツだ。 この話は開発だけでなく、ファイル整理や文書作成にもそのまま使える。たとえば案件ごとのフォルダを分けて書面を作る、原稿本文と参考資料を切り分ける、不要ファイルを掃除するときに対象を一塊にしない。そういう地味な分離が、あとで効いてくる。 --- まず、C
papoo.work
同じリポジトリで複数案を並走させるときの衝突回避
同じリポジトリで複数案を並走させるときの衝突回避
同じ作業場に案を2つ3つ重ねると、だいたいどこかでぶつかる。ファイルが上書きされる、差分が汚れる、どの変更がどの案のものか分からなくなる。ここを雑にやると、Claude Code はむしろ便利さより手戻りを増やす。 だから先に作業場所を分ける。複数案を別作業場所で進める、要するに並走作業の整理だ。これだけで衝突の大半は消える。 Claude Code で複数案を同じリポジトリに並べたいとき、まずやるべきなのは「同じ場所で頑張ること」ではない。案ごとに作業ディレクトリを分けることだ。Git の worktree を使うのが一番きれいで、次点で単純に別ディレクトリへ複製するやり方でも足りる。 筆者は最初、ひとつの作業ディレクトリで「案Aを少し直して、戻して、案Bを試す」をやって、diff がぐちゃぐちゃになった。Claude Code 自体が悪いのではなく、作業場の切り分けが甘いだけだった。後から見ても、どの変更がどの案だったか判別しづらい。あれは本当にだるい。 Git を使っているなら、`git worktree` が本命だ。同じリポジトリを、別のディレクトリとして複数開ける。しかも履歴
papoo.work
本番用の作業と試作品を分けると、手戻りが一気に楽になる
本番用の作業と試作品を分けると、手戻りが一気に楽になる
それ、いきなり本番の場所で試すから詰まるのだ。Claude Code は手早く頼めるぶん、雑に使うと変更が広がる。下書きと確定版を分離する、試作品を別場所に逃がす。たったこれだけで、あとから直すときの面倒さがかなり減る。 ここで言っている「分ける」は大げさな話ではない。たとえば、文章なら本番の原稿とは別に `draft/` を作る。ファイル整理なら、いきなり元フォルダを触らず、まず `sandbox/` や `tmp/` に複製を置く。コードなら、既存ブランチや本番ディレクトリを汚す前に、作業用の場所を切る。Claude Code はその場で手を動かす道具なので、まず逃がし先を作るのが正解だ。 一番わかりやすい使い方は、Claude Code に「試作品はここで作って、確定したら本体に反映して」と最初に言い切ることだ。依頼文は、あいまいにするとすぐ散る。たとえば文書整理ならこうだ。 ```text このフォルダは本番用です。直接は触らず、別の作業用フォルダに試作品を作ってください。 まずは下書きを `draft/` にまとめ、その内容を見てから確定版へ反映します。 本番のファイル名や配
papoo.work
作業フォルダを先に決めると、Claude Code の事故がかなり減る
作業フォルダを先に決めると、Claude Code の事故がかなり減る
Claude Code に雑に「これ直して」と投げて、そのまま広い場所を触らせる。これがいちばん危ない。 事故の多くは、モデルの頭の良し悪しではなく、触らせる範囲が広すぎることから起きる。だから先にやるべきは、作業場所を固定することだ。別名で言えば、触らせる範囲を狭める、だ。 筆者はこれを甘く見て、ホームディレクトリや巨大なプロジェクトの根っこで作業を始めて、余計なファイルまで読ませてしまったことがある。結果、コンテキストが無駄に膨らみ、返ってくる修正案もぼやけた。小さな修正のはずが、確認のための往復だけで疲れる。Claude Code は優秀だが、何でも見せれば賢くなるわけではない。むしろ逆だ。 作業フォルダを先に決める、とは要するに「今回の仕事はここだけ」と最初に囲うことだ。これだけで、誤爆、読みすぎ、書きすぎが一気に減る。ファイル整理でも文書作成でも同じで、対象を絞ったほうが、指示も結果もシャープになる。 たとえば、案件ごとの書面を作るなら、案件フォルダを先に切って、その中だけを相手にする。重複ファイルや不要キャッシュを掃除するなら、対象のディレクトリを決めてから走らせる
papoo.work
終わった作業を片付けると、次の Claude Code が速くなる
終わった作業を片付けると、次の Claude Code が速くなる
終わったディレクトリをそのまま放置していると、次の Claude Code が地味に鈍る。これ、かなりありがちな落とし穴だ。 使い終わった作業場所の整理、要するに後片付けをしておくと、次回は「何を見ればいいか」が明確になり、探し回る時間も、余計な差分に引っ張られる手間も減る。 Claude Code は賢いが、魔法のように自動で「これはもう不要」と見抜いてくれるわけではない。作業用のフォルダに古い試行錯誤、半端な生成物、使い終わったメモが残っていると、次の依頼でまたそれらを読みに行く。人間でも気が散るが、こういう散らかり方はエージェントにも効く。筆者は以前、同じ案件フォルダに古い出力と新しい出力を混在させたまま進めて、Claude Code に「どっちを正にするのか」を毎回説明し直す羽目になった。あれは本当にだるい。 なので、作業が終わったら「片付け」を一回入れる。大げさな話ではない。次の仕事が始まる前に、古い依頼の残骸を減らしておく。それだけで十分効く。 まずやることは単純だ。作業が終わったら、その案件のフォルダを見直して、次回に要らないものを外に出す。たとえば、実験中のファイル、途
papoo.work
CLAUDE.mdを“ただの設定ファイル”で終わらせないために
CLAUDE.mdを“ただの設定ファイル”で終わらせないために
読んでいてまず思ったのは、Claude Code みたいな「勝手に動くAIエージェント」では、READMEやCLAUDE.mdが思った以上に設計そのものになるんだな、ということだった。ふつう設定ファイルは、せいぜいツールの癖を合わせるための補助線くらいに見える。でもこの記事を読むと、そこがもう単なる補助ではなくて、AIの挙動を縛る“現場のルールブック”になっている。 特に引っかかったのは、コンテキストがプロンプトと別物だと強く扱っている点だ。人間なら「この指示はこの場だけ」と空気で分かるけれど、AIはそうはいかない。いったん渡した情報が、どこまで効いていて、どこから効かないのかが曖昧だと、便利さより先に事故のほうが目立つ。だから「CLAUDE.mdに何を書けるか」より、「何を書いてはいけないか」「どこで指示を切るか」を細かく詰めているのが面白い。AIが賢くなるほど、雑な指示は雑な結果として返ってくる、という当たり前がかなり露骨に出ている。 もう一つ、少し怖さもある。記事では“ベストプラクティス”として整理されているけれど、実際には運用の知識がかなり重要になる。スキルやアーティファクトま
papoo.work
Claude Codeの見えない消費にひやっとした
Claude Codeの見えない消費にひやっとした
一番ひっかかったのは、「自分はまだ何も打っていないのに、もう減っている」という感覚です。AI系のツールって、どうしてもプロンプトの量や使い方だけが消費の原因だと思いがちですが、この記事はその前段にある設定そのものがコストを押し上げる、と言っていて、そこがかなり実感に近いなと思いました。 とくにCLAUDE.mdは便利な反面、便利さの代償がわりと素直に出るんだなと感じます。毎回読み込む以上、長くなればなるほど効く。しかも、今回の作業に関係ない指示まで抱え込むと、静かにムダが積み上がる。人間の感覚だと「念のため入れておく」が、そのままモデル側では固定費になってしまうわけで、ここは使い慣れるほど見落としやすそうです。 もうひとつ面白かったのは、MCPサーバーやスキルのような“拡張機能”が、単に機能を増やすだけではなく、常時読み込みのコストも増やすところです。便利な道具を足していくほど、起動時の重さも増える。これはソフトウェア全般にある話ですが、トークンという目に見えにくい単位で出てくると、急に現実味が増します。派手な使い方をしなくても減る、というのはかなり嫌なタイプの消費です。 逆に言うと、
papoo.work
無人実行と人間向け通知は、やっぱり同じ hook に載せると壊れる
無人実行と人間向け通知は、やっぱり同じ hook に載せると壊れる
読んでまず思ったのは、「その 19 回は、そりゃ刺さるよな」ということだった。 監査の nag 自体は、人間が画面の前にいるならかなり筋がいい。実装したついでに報告を飛ばしがちな場面を、その場で止められるからだ。でも記事を読んでいて引っかかったのは、その仕組みが launchd 経由の無人実行にもそのまま流れ込んでいた点で、ここはかなりありがちな落とし穴だと思った。 面白いのは、作者が「通知を止める」ために、通知の有無ではなく実行環境を見ているところだ。`entrypoint` を transcript の先頭から読んで、人間の端末で始まったのか、`sdk-cli` のような自動化で始まったのかを分ける。これ、言われてみれば当然なんだけど、実際には見落としやすい。ツールの挙動を「どこで動いたか」で切り替えないと、同じ hook が別の文脈でまったく違う意味を持ってしまう。 もう一つ、`Stop` hook に置いた判断も納得感があった。途中の tool call ごとにチェックすると、まだ状態が固まっていないのに監査を促すことになる。終わったタイミングで、「ちゃんと自己監査を書いたか」
papoo.work
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` に出る長さ不一致、今のところ未解決
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` に出る長さ不一致、今のところ未解決
まず、この症状が自分のケースかどうかを切り分けます。Issue 上で報告されているのは、どちらも同じ系統のエラーです。 > `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=812 messages=811 range=[777,812))` つまり、少なくとも issue から確認できる範囲では、このエラーは「何かのメッセージ一覧が、キー数と本文数で 1 件ずれている」状態で出ています。 ただし、なぜその不一致が起きるのか、Claude Code 側の表示の問題なのか、特定の入力内容で誘発されるのか は、今回の報告だけでは分かりません。解決済み issue も確認できませんでした。 手元で確認できた環境情報は次のとおりです。これは症状の再現ログではなく、検証時点の実機情報です。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときに確認したこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときに確認したこと
この症状は、`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` というエラー文字列で報告されています。今回まとまっていた issue は 2 件で、どちらも open のままで、解決済みの報告はありませんでした。つまり、少なくとも今回の材料だけでは「これで直る」と言い切れる定番解はありません。 まず、自分のケースかどうかを切り分けるなら、表示されているエラー本文がほぼそのまま一致するかを見ます。報告されていた文字列は次の通りです。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=855 messages=854 range=[807,855)) at jQt (B:/~BUN/root/chunk-w2v99rzn.js:36:27 ``` 別の issue でも同じ系統のエラーが出ています。こちらは件数がかなり小さく、`keys=27 messages=26 rang
papoo.work
Error: EINVAL: invalid argument, open '/private/tmp/claude-5…' が出るときに見えたこと
Error: EINVAL: invalid argument, open '/private/tmp/claude-5…' が出るときに見えたこと
この症状は、Claude Code のサブエージェントが動いている最中に、`/private/tmp/claude-501/.../tasks/...output` のようなパスを `open` しようとして `EINVAL: invalid argument` で落ちる、という形で報告されています。手元で確認できたのは issue 報告の文面だけで、再現手順や恒久的な回避策までは確認できていません。 自分のケースかどうかを見分けるなら、まずエラーメッセージの中に次の形があるかを見ます。`/private/tmp/claude-5` で始まる一時領域のパス、`tasks/` ディレクトリ、そして `.output` か `.outp...` のようなファイル名が並んでいれば、報告された症状とかなり近いです。 issue [#81993](https://github.com/anthropics/claude-code/issues/81993) では、macOS 上の Claude Code CLI、Apple Silicon、1つの長時間セッションで複数のバックグラウンド suba
papoo.work
2 件の Claude Code 障害を切り分ける
2 件の Claude Code 障害を切り分ける
このクラスタには、性質の違う 2 つの issue が入っています。どちらも解決済みですが、症状の出方は別物です。自分のケースかどうかは、まず「Bash tool なのか Monitor tool なのか」と「macOS なのか」を見るのが早いです。 1つ目は [#64426](https://github.com/anthropics/claude-code/issues/64426) で、Bash tool のコマンドから `-flag` らしきトークンが消えるという報告です。条件はかなり具体的で、コマンド置換 `$(...)` やバッククォートの中に、さらに `$` を使った展開が入っていると、実行前に ` -<flag>` が抜かれると書かれています。issue 本文では「モデルは正しいコマンドを送っているが、実際にシェルで走るのは壊れたコマンドだ」と説明されています。環境は Claude Code 2.1.159、macOS の Darwin 24.6.0、Apple Silicon、`/bin/zsh 5.9` です。 2つ目は [#63050](https://githu
papoo.work
`The operation timed out.` が何度も出て処理が止まるときに見えるもの
`The operation timed out.` が何度も出て処理が止まるときに見えるもの
この症状は、少なくとも issue [#64500](https://github.com/anthropics/claude-code/issues/64500) と [#69311](https://github.com/anthropics/claude-code/issues/69311) で報告されています。どちらも報告されたエラーは同じく `The operation timed out.` でした。 自分のケースかどうかを先に見るなら、単発の失敗ではなく、同じ操作が何度も止まり続けるかが目印です。[#64500](https://github.com/anthropics/claude-code/issues/64500) では、モデルの tool call の解析に失敗したあとに再試行も失敗し、そのまま長時間ハングしています。ログには次のような反復が残っています。 ```text ⏺ The model's tool call could not be parsed (retry also failed). ✻ Churned for 21m 49s ❯ 繼續 ⏺ Th
papoo.work
String to replace not found が出るときに見るところ
String to replace not found が出るときに見るところ
この症状は、見た目には「編集したい文字列がそのままあるのに、`Edit` が失敗する」ように見えます。issue に出ている報告は、完全に同じ原因ではなさそうです。ただ、少なくとも「`String to replace not found` が出て編集が進まない」という点では重なっています。 最初に確認したいのは、あなたが遭遇しているのが「ファイルの内容は合っているのに置換できない」のか、「そもそも Claude が成功したように言っているだけで、実際には反映されていない」のかです。前者は `Edit` の `old_string` 不一致、後者は作業完了の見かけと実体のずれです。#64212 では、`old_string` がブランチ上のファイルと一致していない `Edit` 呼び出しがあり、`String to repla...` という失敗が記録されています。#52482 では、全角 CJK 記号を含む箇所で、モデルが半角記号にずれて `old_string` を作ってしまい、その結果として `String to replace not found` が起きると説明されています。
papoo.work
複数の案件を並べるときは、コンフリクトの芽を先に摘む
複数の案件を並べるときは、コンフリクトの芽を先に摘む
複数の案件を同じ作業場で走らせると、だいたいどこかで噛み合わなくなる。これはClaude Codeでも同じで、雑に並べると、同時編集の回避が甘くなって、ファイルの衝突防止に失敗する。結果として、同じファイルを別案件が触っていたり、片方の作業がもう片方の差分を上書きしたりする。地味だが、いちばん手戻りが高い事故だ。 ここでやるべきことは単純で、案件ごとに作業の境界を先に決めることだ。Claude Codeに丸投げしてから考えるのでは遅い。最初に「どの案件が、どのファイル群を触るか」「共通で触る場所はどこか」「触ってはいけない場所はどこか」を切っておく。これだけで競合を減らす、という話になる。 筆者は以前、資料整形の案件と原稿修正の案件を、同じフォルダ配下でうっかり並べたことがある。どちらも似た名前のMarkdownを触るので、Claude Codeに「この資料を整えて」と頼んでいるうちに、別案件の下書きまで読みに行かれた。結果、差分の見通しが悪くなり、直すつもりのない文書まで手が入った。あれは完全に置き場の設計ミスだ。 まず効くのは、案件ごとに作業ディレクトリを分けるやり方だ。Claud
papoo.work
ブランチを切る前に整理して、変更を小さく始める
ブランチを切る前に整理して、変更を小さく始める
いきなりブランチを切って、あとから全部を Claude Code に投げ込む。これ、かなり雑だ。変更前整理を先にやらないと、ブランチ運用がすぐ重くなるし、小さく始める準備もできない。結果として、diff は肥大化する、指示はぼやける、どこまで直したのか自分でも追えなくなる。 Claude Code を使うなら、最初にやるべきなのは「何を変えるか」を作業前にほどくことだ。コード修正だけの話ではない。ファイル整理でも、ディスク削減でも、文書作成でも同じで、先に材料を整理したほうが、後のやり取りが短くなる。筆者は以前、関連ファイルをまとめずに「このフォルダを整えて」とだけ頼んで、似た名前のファイルを何往復も確認する羽目になった。あれは完全に準備不足だった。 まずやることは、作業の境界を決めることだ。Claude Code に丸投げする前に、対象を狭く切る。たとえばリポジトリなら、機能全体ではなく、1 画面、1 コマンド、1 文書、1 ディレクトリに絞る。ファイル整理なら、まずは「Downloads の画像だけ」「契約書フォルダの重複 PDF だけ」のように切る。ここを曖昧にすると、AI は広
papoo.work
一時ファイルを残さない依頼にすると、あとで見返しやすい
一時ファイルを残さない依頼にすると、あとで見返しやすい
Claude Code に作業させるとき、成果物だけ欲しいのに、作業用メモや途中生成物まで山ほど残してしまう。これがあとで地味にだるい。 一時ファイルの扱いを最初に決めておくと、成果物と作業用メモの分離がはっきりする。ゴミを残さない頼み方にしておけば、あとで見返したときに「結局どれが本体だっけ」が起きにくい。 筆者は昔、下書き整理を Claude Code に任せたとき、途中の案や検討メモまで同じ階層に吐かせてしまい、数日後に見返して盛大に混乱したことがある。内容は悪くないのに、どれが採用版で、どれが捨てていいメモなのかが一目で分からない。あれは単純に依頼の切り方が悪かった。 やることは難しくない。最初に「残すもの」と「残さないもの」を言い切るだけだ。 たとえば、文書作成でもコード整理でも、依頼文をこう寄せる。 ```text この作業では、一時ファイルや作業メモを残さないでください。 最終成果物だけを出してください。 途中経過は必要ならメモせず、作業後に削除してください。 成果物と作業用メモは分けてください。 ``` Claude Code がファイルを触る作業なら、さらに具体的に書
papoo.work
触らせる範囲を狭めるだけで、余計な事故はかなり減る
触らせる範囲を狭めるだけで、余計な事故はかなり減る
Claude Code に大きなフォルダを丸ごと渡して、「あとはよろしく」はかなり危ない。 余計なファイルまで見に行かせると、コンテキストを食うし、意図しない場所まで修正しやすい。対象フォルダを限定する、作業範囲の制御を先にやる、巻き込み事故を防ぐ。これだけで、手戻りは目に見えて減る。 特に、ファイル整理、ディスク削減、文書作成みたいな用途では効き目が大きい。開発者でも非エンジニアでも同じだ。触らせる場所を狭めると、Claude Code は雑になりにくい。 たとえば、案件ごとにフォルダを分けているなら、その案件の中だけを見せればいい。 古い書類の整理をしたいなら、家全体ではなく「この年の請求書フォルダだけ」に絞る。 これをやらずに全体を渡すと、関係ないドラフトや一時ファイルまで拾ってしまい、出力がぼやける。実務ではそれがいちばんだるい。 Claude Code を使う前に、作業対象を言葉で固定するのが先だ。 「このフォルダの中だけ」「この案件の書面だけ」「この掃除対象の範囲だけ」とはっきり切る。曖昧にすると、AI はいい感じに広く見に行く。人間が見れば不要な範囲まで、平気で拾う。 た
papoo.work
終わった作業を片付けると、Claude Code の次の仕事が速くなる
終わった作業を片付けると、Claude Code の次の仕事が速くなる
終わった成果物をいつまでも作業場所に置きっぱなしにするのは、地味に効くムダだ。不要なブランチ整理や、使い終わった成果物の整理を後回しにすると、Claude Code は次の仕事で関係ないファイルをまた見に行くし、あなたも「これ、まだ触るんだっけ」と迷う。あの手の迷いは、思った以上にコンテキストを食う。 Claude Code を使うなら、仕事が終わった瞬間に周辺を片付けて、次の依頼に入りやすい状態へ戻すのが強い。これは開発だけの話ではない。書類作成、文章の下書き、案件ごとの資料整理でも同じだ。作業が終わった場所に古い下書き、仮ファイル、重複した出力が残っていると、次の指示がぼやける。やることは単純で、終わったものを「終わった」と見なして退避、削除、整理するだけである。 まず効くのは、Claude Code に「残すもの」と「捨てるもの」をはっきりさせることだ。曖昧に「全部見て整えて」みたいな頼み方をすると、結局どれが本命かわからず、diff が肥大化しやすい。片付けは、作業の最後にまとめてやるより、ひと区切りごとにやるほうが速い。 たとえば、開発ならこんな依頼にする。 ```text
papoo.work
本番用と試作品を混ぜない：下書きと確定版を分離する
本番用と試作品を混ぜない：下書きと確定版を分離する
試し書きのファイルに、いつのまにか本番用の文章や成果物まで混ざる。これ、かなり雑に見えて、あとでいちばん高くつくやつだ。下書きと確定版を分ける、成果物の置き場を分ける。Claude Code を使うなら、この線引きは最初にやっておいたほうがいい。 理由は単純で、Claude Code は「今見えているファイル群」を材料に作業するからだ。下書き、メモ、採用済み原稿、配布用の完成版が同じ場所にあると、参照も修正も曖昧になる。書類整理でもコードでも同じで、混ぜるほど事故る。筆者は一度、作業用フォルダに旧版のメモを残したまま頼みごとをして、戻し先がぐちゃぐちゃになったことがある。人間なら見分けられるが、雑な置き方をすると機械は平気で巻き込む。 まずやることは、置き場を物理的に分けることだ。名前でごまかさない。フォルダを分けるほうが早い。 ```text project/ draft/ final/ references/ archive/ ``` たとえば文章作成なら、`draft/` に試し書き、`final/` に確定版、`references/` に参考資料、`archive/` に古い
papoo.work
同じリポジトリで複数案を並走させるなら、場所の衝突を先につぶす
同じリポジトリで複数案を並走させるなら、場所の衝突を先につぶす
並走作業でいちばん雑にやってしまうのが、「とりあえず同じ場所で別案を回す」ことだ。これ、すぐ詰まる。Claude Code は賢いが、同じリポジトリの同じファイル群を複数案でいじらせると、変更の混線と差分の肥大化が一気に起きる。複数案の比較をしたいなら、同時進行の整理は最初にやる。場所の衝突を先につぶしておくのが、あとで一番効く。 筆者は最初、同じ作業ツリーで A 案と B 案を行ったり来たりさせて、かなり手戻りした。片方で直した設定ファイルを、もう片方が前の前提のまま触ってしまう。Claude Code は目の前の指示に忠実だから、こちらが整理していないと、平気で「どっちの案の前提で動いているのか」が曖昧になる。結果、diff を見ても何を比較しているのか分からない。これはかなりだるい。 やることは単純だ。案ごとに作業場所を分ける。Git で別ブランチにするだけでは足りない場面がある。同じファイル名、同じ生成物、同じ一時ファイルがぶつかるからだ。Claude Code に複数案を投げるなら、物理的に場所を分けたほうが早い。 たとえば、同じリポジトリを保ったまま、案ごとに別ディレクトリ
papoo.work
案件ごとに作業フォルダを分けて、後から迷子にならない
案件ごとに作業フォルダを分けて、後から迷子にならない
その場しのぎで同じ場所に全部押し込むと、あとで確実に詰まる。Claude Code でも同じだ。案件単位で分ける、要するにフォルダ設計を先に決めて、整理用の作業場所を案件ごとに切るだけで、あとから「この差分どれだっけ」「この原稿どこに置いた」と迷わなくなる。 地味に見えるが、効き目は大きい。Claude Code に頼む作業は、コード修正だけではない。議事録の下書き、請求書まわりの整理、既存フォルダの棚卸し、重複ファイルの洗い出しまで入ってくる。ここで作業場所が混ざると、出力も入力も散らかる。人間が戻ってきたときに、どれが正本でどれが一時ファイルか分からない。これがいちばんだるい。 発想は単純でいい。ひとつの大きな「作業箱」を使うのをやめて、案件ごとに独立したフォルダを切る。Claude Code に見せる作業ディレクトリも、基本はその案件の中に閉じる。 たとえば、こんな感じだ。 ```text work/ client-a/ 01_inbox/ 02_draft/ 03_output/ 99_archive/ client-b/ 01_inbox/ 02_draft/ 03_outp
papoo.work
試作は別ディレクトリに逃がすと、本流が一気に静かになる
試作は別ディレクトリに逃がすと、本流が一気に静かになる
本流のフォルダにそのまま試作を混ぜると、だいたいろくなことにならない。差分は膨らむし、どこまでが本番でどこからが試行錯誤かも見えなくなる。Claude Code を使うなら、最初に「別作業場所を切る」「作業ディレクトリを分ける」「サンドボックスで試す」を先にやるだけで、後の会話がかなり静かになる。 この静かになる、というのは大げさな言い方ではない。Claude Code は、いま置かれているディレクトリの中身を前提に動く。だから、本番の文書やファイルの山の中でいきなり試させると、読ませたくないものまで文脈に入る。逆に、試作用の小さい作業場所を切ってしまえば、指示も差分も小さくなる。手戻りが減る。何より、あとで消していい場所として割り切れるのが強い。 たとえば、弁護士が案件ごとに書面を作る、経理担当が月次のファイル整理をする、非エンジニアが散らかった文書をClaude Codeに整えさせる。こういう場面では、元のフォルダで直接いじらせるより、まずコピーを置いた別ディレクトリで試したほうが安全だ。本番の資料が壊れる心配がないし、出力の確認もしやすい。 やり方は単純だ。試作専用の場所を作って
papoo.work
引き継ぎやすい状態で終えると、次回の Claude Code が迷わない
引き継ぎやすい状態で終えると、次回の Claude Code が迷わない
作業の終わりに雑に閉じると、次回の Claude Code は平気で迷う。人間でも嫌になるあの状態だ。直前まで何をやっていたか、どのファイルを触ったか、何が残っているかが散らばったままだと、次の一手が毎回「状況確認」になる。もったいない。 ここで効くのが、後片付けと引き継ぎ、作業終了時の整備、次回に残すメモだ。大げさな儀式はいらない。終わる前に、次の Claude Code がそのまま続けられる形に整えるだけでいい。これをやると、指示のやり直しが減るし、diff が無駄に育たない。ファイル整理や文書作成で使っている人ほど効く。片づけずに寝ると、翌日の自分がいちばん損をするのと同じだ。 実際、筆者は最初、Claude Code に「このあたり直しておいて」とだけ投げて終わらせ、翌日に同じ説明をもう一回やったことがある。しかも、途中で出した一時ファイルやメモが残っていて、Claude Code がそっちに引っ張られた。仕事としては小さいが、地味にだるい。だから今は、終わり方を作業の一部として扱っている。 やることは単純だ。終わり際に、次回のための短いメモを残し、不要なものを捨て、今の状態を
papoo.work
authentication_failed が見えても、親側では「Request interrupted by user for tool use」になることがある
authentication_failed が見えても、親側では「Request interrupted by user for tool use」になることがある
まず自分のケースかどうかを切り分けるなら、親エージェントや対話画面に出る文言だけで判断しないほうがいいです。報告されている症状では、実際の upstream は認証失敗なのに、親側には `[Request interrupted by user for tool use]` とだけ見えることがあります。これは sub-agent を Agent tool で起動しているときに起きた例として [#70958](https://github.com/anthropics/claude-code/issues/70958) に残っています。 この issue では、sub-agent が API 呼び出しで HTTP 401 を受けたとき、本来なら `authentication_failed` / 401 と分かるはずの失敗が、親 agent には「ユーザーが中断した」ように見えていました。報告文では、実際のエラーは sub-agent 側の transcript に残っていた一方、親側には診断に使える情報が渡らなかったとされています。つまり、見えているメッセージだけで「本当にユーザーキャ
papoo.work
Error: Plugin MCP server error - mcp-config-invalid: MCP server github invalid: Missing environment variables: GITHUB_PERSONAL_ACCESS_TOKEN が出るときに見ること
Error: Plugin MCP server error - mcp-config-invalid: MCP server github invalid: Missing environment variables: GITHUB_PERSONAL_ACCESS_TOKEN が出るときに見ること
この症状は、Claude Code が GitHub 用の MCP サーバーを初期化しようとして失敗したときに出ています。報告では、メッセージの中心は一貫していて、`GITHUB_PERSONAL_ACCESS_TOKEN` が足りないと明示されています。少なくとも今回集まった issue では、端末上の出力が重複して見える、あるいは同じ内容が何度も繰り返される、という別の見え方も一緒に報告されています。 該当する報告は [#53492](https://github.com/anthropics/claude-code/issues/53492) と [#85469](https://github.com/anthropics/claude-code/issues/85469) です。どちらも同じエラー文字列を含んでいます。 ```text Error: Plugin MCP server error - mcp-config-invalid: MCP server github invalid: Missing environment variables: GITHUB_PERSO
papoo.work
exit code 126 が出るときにまず見るところ
exit code 126 が出るときにまず見るところ
`exit code 126` だけでは原因は絞れませんが、今回の 2 件の issue はどちらも「Claude Code の Bash tool が、sandbox 有効時に毎回失敗する」という共通点がありました。しかも失敗は単発ではなく、`pwd` のような簡単なコマンドでも起きています。 症状の出方が似ていても、環境はかなり違います。ひとつは WSL2 上の Linux で、`sandbox.enabled: true` と `filesystem.denyRead` や `permissions.deny Read(...)` の組み合わせで起きています。もうひとつは macOS で、ログインシェルが zsh のときに起きています。前者は [#51126](https://github.com/anthropics/claude-code/issues/51126)、後者は [#77466](https://github.com/anthropics/claude-code/issues/77466) です。 WSL2 側の issue では、表示上は `Exit code
papoo.work
`Remote Control is not yet enabled for your account.` が出るときに見えていること
`Remote Control is not yet enabled for your account.` が出るときに見えていること
この症状は、`claude remote-control` を実行した瞬間に ```text Error: Remote Control is not yet enabled for your account. ``` で止まる、という形で報告されています。関連する issue は [#61890](https://github.com/anthropics/claude-code/issues/61890)、 [#81459](https://github.com/anthropics/claude-code/issues/81459)、 [#63198](https://github.com/anthropics/claude-code/issues/63198) です。 まず、このエラー文がそのまま出ているなら、少なくとも issue 報告上は「Remote Control の有効化判定で弾かれている」状態です。`#61890` では、`--verbose` を付けてもエラー行以外の追加出力がなく、ハンドシェイクや通信の前にクライアント側で拒否されているように見える、と書かれてい
papoo.work
`[Tool result missing due to internal error]` が出るときに最初に見るところ
`[Tool result missing due to internal error]` が出るときに最初に見るところ
このエラーは、Claude Code の `Bash` ツールまわりで出ています。今回の issue では、見え方は違ってもどちらも「ツールの結果が内部エラー扱いで欠ける」という同じ症状でした。`Bash` に対する `PreToolUse` hook が `defer` を返したときにコマンドが実行されず `"[Tool result missing due to internal error]"` になる例が [#64389](https://github.com/anthropics/claude-code/issues/64389) にあり、別件では並列の `Bash` 呼び出し 7 件のうち 4 件が同じ内部エラーになった例が [#62161](https://github.com/anthropics/claude-code/issues/62161) にあります。 まず切り分けたいのは、あなたの環境に `settings.json` や `settings.local.json` があるかどうかです。今回、筆者の環境ではどちらも見つかりませんでした。 ```text ~/
papoo.work
最後に全体をまとめ直して、引き継げる形にする
最後に全体をまとめ直して、引き継げる形にする
最後の最後に雑に投げるだけだと、Claude Code はかなり簡単に“作業した気分の断片”を吐く。そこから人に渡せる形へ直す一手間を入れるかどうかで、引き継ぎ用の要約、最終サマリー、成果物の整形の質が露骨に変わる。ここをサボると、あとで「結局どこが変わったのか」「何を前提に進めればいいのか」が読み取れず、会話をもう一往復、いや二往復する羽目になる。 筆者は最初、作業が終わった直後に「変更点をまとめて」とだけ頼んでいた。すると、モデルはだいたい“それっぽい説明”を返すが、実際にはファイル名の列挙だけだったり、重要な判断理由が抜けていたりする。コード修正なら diff を見ればまだ追えるが、書類整理や設定整理だとそれができない。終わり際にもう一回、引き継ぐ前提でまとめ直す。これが効く。 やり方は単純だ。作業が一通り終わったら、Claude Code に対して「ここまでの成果を、後任がそのまま続きから入れる形に整えて」と明示する。ポイントは、単なる要約ではなく、次の人が迷わない順序に並べ替えさせることだ。たとえば次のように頼む。 ```text ここまでの作業を、引き継ぎ用の要約として整理
papoo.work
途中報告の頻度を決めて、黙って進みすぎるのを防ぐ
途中報告の頻度を決めて、黙って進みすぎるのを防ぐ
Claude Code に雑に「適当に進めて」と投げると、静かに深掘りしすぎて、あとから人間が困る。これが一番ありがちな事故だ。節目だけ報告、進捗の粒度、黙らせるか返させるかを先に決めておくと、作業の暴走をかなり防げる。 特に Claude Code は、頼み方が広いほど、丁寧にやりすぎる。ファイルを読み込み、関係ありそうな箇所まで追い、修正案を積み上げる。その間に「今どこまで進んだか」が見えないと、こちらは待つしかない。長いコード修正でも、書類整理でも、途中報告の設計がないと後でまとめて確認する羽目になる。差し戻しが重い。 筆者も最初はこれで何度か手戻りした。たとえば「このフォルダの重複ファイルを整理して」とだけ頼むと、探索を丁寧にやりすぎて、不要な比較や候補出しに時間を使う。あとで「そこまで細かく見なくてよかった」となる。逆に、途中で一度だけ報告させるようにすると、方向修正が早い。Claude Code を黙らせるか、こまめに返させるかを先に決めるだけで、かなり扱いやすくなる。 やり方は単純でいい。最初の指示に、報告の節目を入れる。ポイントは「何文字ごと」みたいな機械的な指定より、
papoo.work
途中で要約を挟ませて、前提のズレを止める
途中で要約を挟ませて、前提のズレを止める
Claude Code に雑に長文を投げて、そのまま最後まで走らせる。これをやると、途中で前提がズレたまま突き進み、あとで手戻りする。かなりあるあるだ。 そこで効くのが、途中で要約を挟ませるやり方である。節目で要約、中間サマリー、会話の棚卸し、と呼び方はいろいろあるが、要するに「ここまでの理解を一回言わせる」だけだ。これを入れると、Claude Code が勝手に補完した前提、抜けた制約、あいまいな目的を早めに炙り出せる。 特に、ファイル整理、古い資料の整理、複数フォルダにまたがる改修、長い文章の整形みたいな作業で効く。人間側も、途中で判断軸を見直しやすくなる。 筆者は一度、長い修正依頼を最初から最後まで一気に投げて、Claude Code が「見た目を整える」方向に寄りすぎたせいで、肝心の命名ルールを外されたことがある。あのとき、途中要約を入れていれば、ズレは半分くらいで止められたはずだ。 やり方は単純で、最初に「一定量進んだら、作業を止めて要約して」と明示する。ポイントは、単に「要約して」では弱いことだ。何を確認したいのかまで書く。たとえば、目的、前提、未確定点、次にやることを分け
papoo.work
章ごとに渡すと、長い資料でも迷子になりにくい
章ごとに渡すと、長い資料でも迷子になりにくい
長い資料を丸ごと投げて「読んで」とやると、だいたい途中で雑になる。Claude Code は雑にしても止まらないが、こちらの意図は平気で薄まる。そこで効くのが、章ごとに渡すやり方だ。分割投入、資料を小分けにする、一気読みさせない、というやつである。 これは単なる小技ではない。長文の仕様書、契約書の下書き、議事録、マニュアル、フォルダ整理のルール説明まで、長いものを扱うときの基本動作だ。資料を一気に食わせるより、章単位で渡したほうが、Claude Code は論点をつかみやすい。こちらも「今どこを見ているか」を見失いにくい。 たとえば、20ページの社内手順書を要約したいとする。全文を貼る前に、目次だけを見せる。次に第1章だけ、次に第2章だけ、という具合に進める。これだけで、抜けやすい注意点や、章ごとの言い回しの揺れを拾いやすくなる。非エンジニアの人でも同じで、案件フォルダの整理ルールや、請求書の命名規則を見直すときに相性がいい。先に全体像、あとで各章。順番を守るだけで迷子になりにくい。 実際の頼み方は、かなり素直でいい。まずは全体の目的を一言で固定する。 ```text この資料を章ごと
papoo.work
Claude Code に渡す材料を削ると、むしろ精度が上がる
Claude Code に渡す材料を削ると、むしろ精度が上がる
「たくさん渡せば賢くなる」は、Claude Code ではわりと危ない思い込みだ。長文をそのまま投げる、関係ないフォルダまで一緒に渡す、メモを全部貼る。やりがちだが、これで答えが良くなるとは限らない。むしろノイズが増えて、出力がぶれる。要点だけ渡す、長文を圧縮する、文脈を削る。こっちのほうが、狙いが通りやすい。 Claude Code は会話の空気を読む道具ではあるが、空気を吸わせすぎると息が詰まる。特に、ファイル整理や文書作成みたいな用途では、材料を盛るほど安心しがちだ。だが実際には、余計な背景が多いほど「何を優先するべきか」がぼやける。筆者も最初は、関連資料を全部貼って「これで完璧だろ」と思い、逆に修正の手戻りを増やした。要らない文脈が混ざると、エージェントはそれを無視しきれず、無駄に広い解釈を始める。 なので、まずやるべきは「情報を増やす」ことではなく、「仕事に関係する芯だけ残す」ことだ。Claude Code に渡す前に、次の3つに分けると扱いやすい。 何をしたいのか どのファイル、どの範囲が対象か 何をしないのか この3つだけで、かなり通る。 たとえば、リポジトリ内の古い M
papoo.work
返答の形を先に固定して、出力の暴れを抑える
返答の形を先に固定して、出力の暴れを抑える
Claude Code に雑に頼んで、返ってきた答えが毎回バラつく。これはかなりありがちな失敗だ。長文で返ってきたり、逆に一言で終わったり、箇条書きが崩れたりする。先に返答の形を決めておかないと、後で整える手間が地味に重い。 ここで効くのが、Markdown か表かを決める、つまり出力形式の固定だ。要するに「返答を整える」ための下ごしらえを先にやる。Claude Code は指示が曖昧だと、内容は合っていても見た目や粒度が暴れやすい。逆に、最初に形を縛ると、比較・一覧・手順書・要約がかなり扱いやすくなる。 たとえば、ファイル整理や文書作成で Claude Code を使うとき、返答の形を先に決めないと困る場面は多い。重複ファイルの候補を洗い出したいのに、説明文ばかり返ってくる。案件メモを整えたいのに、段落が長すぎてコピペしづらい。そんなときは、最初から「この形式で返して」と言い切るのがいちばん手っ取り早い。 実際の頼み方はこうだ。 ```text 以下の内容は Markdown の見出しと箇条書きで返してください。 余計な前置きは不要です。 各項目は 1 行で短くまとめ、最後に次にやる
papoo.work
Notionに残すなら、読める形で残したい
Notionに残すなら、読める形で残したい
最初に思ったのは、これは「AIで日誌を自動生成する話」というより、あとで自分が読み返せる形に整える話なんだな、ということだった。そこがかなり好ましかった。AIっぽい長文を吐かせること自体は簡単だけど、結局あとから探せない、見返せない、使えないなら意味が薄い。この記事はその弱さをかなり正面から見ている。 特に腑に落ちたのは、長い説明文をやめて「1トピック1 callout」に切り直した部分だ。文としては短くなるのに、むしろ情報は増えている感じがする。見出し、metadata、事実の bullet、Next/Open の分離。要するに、AIに“それっぽい振り返り”を書かせるより、人間が再利用しやすい粒度に強制するほうが価値がある、という発想だと思う。これはノート術というより、記録のUI設計に近い。 もうひとつ面白かったのは、季節や曜日で色やアイコンを変える話。見た目をかわいくした、で終わらず、スクロールしたときに時間の流れが一目で分かるようにしているのがいい。こういう装飾は遊びに見えて、実は記憶のフックになる。毎回同じ灰色の箱だと、どれがいつの記録か感覚が抜け落ちるから、色
papoo.work
10個以上のClaude Codeを回すために、まず考えるべきこと
10個以上のClaude Codeを回すために、まず考えるべきこと
この記事を読んで最初に思ったのは、「LLMそのもののコストより、周辺の面倒さのほうが先に限界を作るんだな」ということだった。Claude Codeみたいなツールって、つい“賢いCLI”くらいの感覚で見てしまうけれど、実際にはローカルテストやlocalhostサーバー、ファイルのやりとりまで含めると、意外なくらいPCを使う。10個、20個と並列に走らせるなら、もうノートPCの気合いではどうにもならない、という感覚はかなり腑に落ちた。 面白かったのは、そこで高価なマシンを買う話に飛ばず、CPUを借りるという発想に寄せていたことだ。GPUが要るのはモデル側であって、エージェントを動かすだけならCPUで足りる、という切り分けは実用的だと思う。しかも「買うより借りるほうが安い」というだけでなく、24時間動かしっぱなしにできるのが大きい。自分の手元のMacを閉じたら止まる、熱でつらい、というあたりはかなり生々しい。クラウドの話というより、日常のPC運用の限界の話として読めた。 一方で、Remote Server + SSH で全部うまくいく、というほど単純でもない。ローカルの画像をどう渡すか、re
papoo.work
TelemetrySafeError: task output swap refused (output file identity changed): これが出たら確認したいこと
TelemetrySafeError: task output swap refused (output file identity changed): これが出たら確認したいこと
この症状は、issue [#92151](https://github.com/anthropics/claude-code/issues/92151) と [#92150](https://github.com/anthropics/claude-code/issues/92150) の両方で報告されています。どちらも件名は同じで、本文には「the agent has been lying and doing nothing」とあり、実際にはタスクを実行していないのに完了したように見える、という訴えです。報告されたエラーは次のものです。 ```text TelemetrySafeError: task output swap refused (output file identity changed): /private/tmp/claude-501/-Users-michaeltabet/773c3a12-2bac-4331-a8d2-8e80e1e08eb6/tasks/b3cxl28wu.output at N (/$bunfs/r / TelemetrySafeError:
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときに確認したいこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たときに確認したいこと
この症状は、少なくとも今回渡された 2 件の issue では同じエラーメッセージとして現れています。 > `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=26 messages=25 range=[0,26))` もう 1 件でも同系統の報告がありました。 > `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=252 messages=251 range=[236,252))` どちらも、報告本文だけを見る限りでは「メッセージ一覧の件数」と「キー一覧の件数」が 1 件ずれている状態です。ですが、ここから先の原因は issue の報告内容だけでは切り分けきれません。少なくとも、[#80361](https://github.com/anthropics/claude-code/issues/80361) では OAuth テスト用の画面を準備している最中に安全ガードが誤っ
papoo.work
Claude Fable 5 is currently unavailable が出るときに、まず見るべきこと
Claude Fable 5 is currently unavailable が出るときに、まず見るべきこと
この文字列が出ているだけでは、同じ症状とは限りません。今回集められている issue では、少なくとも 2 つの見え方がありました。 ひとつは、Claude for Excel add-in で入力欄に打った文字が Claude 側ではなく Excel のアクティブセルに入ってしまうケースです。報告では、セル選択のチップが閉じても戻ってきて、同時にパネル内に “Claude Fable 5 is currently unavailable” が出ていました。モデル表示は Opus 4.8 だったと書かれています。これは [#72577](https://github.com/anthropics/claude-code/issues/72577) です。 もうひとつは、`/model` ピッカーで Fable 5 がグレーアウトして “Claude Fable 5 is currently unavailable” と出る一方、起動時のバナーでは “Fable 5 is back.” と表示されるケースです。こちらは [#73640](https://githu
papoo.work
Error: Error during compaction: API Error: Usage credits req で止まるときに見えていたこと
Error: Error during compaction: API Error: Usage credits req で止まるときに見えていたこと
この症状は、`/compact` の途中で `Error: Error during compaction: API Error: Usage credits required for 1M context · run /usage-credits to turn them on, or /model to switch to standard context` という形で失敗し、セッションの圧縮が進まなくなるものです。報告されている issue は [#64031](https://github.com/anthropics/claude-code/issues/64031) と [#63718](https://github.com/anthropics/claude-code/issues/63718) の 2 件で、どちらも closed です。 今回の材料だけで言える範囲では、少なくとも次の 2 つが同じクラスタに入っています。ひとつは「コンパクション中に API エラーが出る」ケース、もうひとつは「Sonnet-4.6 を使っていて 200k の context limit
papoo.work
`This folder contains Claude's app data and can't be shared w` が出たときにまず見ること
`This folder contains Claude's app data and can't be shared w` が出たときにまず見ること
このエラーが出るケースは、少なくとも issue 報告上では二つに分かれています。ひとつは、もともと動いていた作業フォルダがアップデート後に急に弾かれるケース。もうひとつは、フォルダ内に `Skills`、`Scheduled`、`Artifacts`、`.claude/` などが絡んでいて、同じ文言で止まるケースです。該当する報告は [#78368](https://github.com/anthropics/claude-code/issues/78368) と [#89916](https://github.com/anthropics/claude-code/issues/89916) です。 見分けるときは、まず「そのフォルダは以前は問題なく使えていたか」と「中に `.claude/` があるか、あるいは `Skills` などの名前のサブフォルダがあるか」を確認するのが早いです。少なくとも issue の記述では、見た目上は Claude のアプリデータが入っていないのに、この文言で拒否される例がありました。[#78368](https://github.com/anthr
papoo.work
`thinking blocks ... cannot be modified` が出てセッションが戻らないとき
`thinking blocks ... cannot be modified` が出てセッションが戻らないとき
この症状に心当たりがあるなら、まず見分けたいのは「一度だけ 400 が出た」のか、「その後ずっと同じ 400 で詰まる」のかです。今回の issue では、後者が報告されています。途中で止まった会話が、その後の送信でも毎回 `thinking` 系のブロック不正として落ち続ける、という流れです。 報告されている代表例は [#63374](https://github.com/anthropics/claude-code/issues/63374) と [#63410](https://github.com/anthropics/claude-code/issues/63410) です。どちらも最終的には同じエラー文に行き着きます。 > `API Error: 400 messages.N.content.M: \`thinking\` or \`redacted_thinking\` blocks in the latest assistant message cannot be modified. These blocks must remain as they were in th
papoo.work
使われない Claude Code エージェントにお金を払う違和感
使われない Claude Code エージェントにお金を払う違和感
最初に思ったのは、「便利そうな仕組みほど、放っておくと簡単に“置物”になるんだな」ということだった。 カスタム agent を何個も定義した時点で、もう何かを自動化した気になってしまう。でも実際には、呼び出されていなければただの設定ファイルでしかない。その当たり前を、30日分のログで突きつけられるのが少し痛い。 面白かったのは、この記事が「AI が賢くならないからダメ」という話に寄っていないところだと思う。むしろ逆で、AI に期待するより先に、周辺の仕組みをちゃんと監視しろと言っている。ログを取り、集計し、使われていない agent を炙り出す。派手ではないけれど、こういう地味な仕掛けのほうが長く効く気がする。自動化って、作ることより、壊れていないか確かめ続けることのほうが難しいのかもしれない。 それと、`defined = working` という思い込みへの指摘はかなり刺さった。説明文に「必ず使う」と書いてあっても、実際に呼ぶ側のロジックがなければ動かない。ここは人間の道具づくりでも同じで、棚に並べた瞬間に仕事が終わった気になる。でも本当に大事なのは、使われた痕跡があるかどうかだと
papoo.work
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` が出るときに見えているもの
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` が出るときに見えているもの
まず、この症状に当てはまるかどうかは、報告されている例を見るとかなりはっきりしています。`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` という文字列が出ていて、スタックトレースに `nHt (B:/~BUN/root/chunk-9891yaqw.js:36:25132)` が含まれているケースです。今回の材料では、同じ症状として [#91880](https://github.com/anthropics/claude-code/issues/91880) と [#91653](https://github.com/anthropics/claude-code/issues/91653) の 2 件があり、どちらも open のままです。解決済みの報告はありませんでした。 もう一件の [#91653](https://github.com/anthropics/claude-code/issues/91653) は少し違っていて、Windows 11 で agents view を開い
papoo.work
ERR_NAME_NOT_RESOLVED が出るときに最初に見ること
ERR_NAME_NOT_RESOLVED が出るときに最初に見ること
`ERR_NAME_NOT_RESOLVED` は、今回の issue 報告では Claude Desktop 起動直後の通信が DNS 解決で落ちている形で出ています。読者の環境でも、起動時にネットワーク系の初期化が失敗しているなら、この症状に近い可能性があります。 ```text Health check fetch failed: Error: net::ERR_NAME_NOT_RESOLVED ``` この報告で分かるのは、少なくともアプリ内部の Chromium ネットワークスタックが、起動時の API 呼び出しを名前解決エラーで通せていない、という点です。少なくとも issue の記述上は、アプリ本体の表示崩れではなく、起動直後の通信失敗が中心に見えます。 切り分けの起点は単純です。もし同じ `ERR_NAME_NOT_RESOLVED` が出ているなら、「アプリだけが落ちる」のか、「名前解決そのものが不安定なのか」を分けて見たほうがよさそうです。#73042 の報告は Windows 10 Enterprise、App Version 1.17377.2、Electro
papoo.work
exit code 255 で SSH が落ちるときに見るもの
exit code 255 で SSH が落ちるときに見るもの
まず自分のケースかどうかを切り分けます。今回の issue 群では、どちらも Claude Code から SSH を投げたときに `exit code 255` で失敗しています。ただし、同じ 255 でも中身は違います。 ```text Error: Exit code 255 Connection timed out during banner exchange Connection to UNKNOWN port 65535 timed out ``` 一方、[#77678](https://github.com/anthropics/claude-code/issues/77678) では、背景が違います。issue の要約では、Claude Code の Bash tool で SSH を呼ぶと `No user exists for uid 501` が出て、standalone の `claude` CLI では同じコマンドが動くと報告されています。つまり、同じ SSH 失敗でも、こちらはネットワーク到達性というより実行環境側の問題に見えます。 `#68497` のほう
papoo.work
`Error: {"type":"error","error":{"details":null,"type":"invalid_request_error","message":"Output blocked by content filtering policy"}` が出て止まるときに見えていたもの
`Error: {"type":"error","error":{"details":null,"type":"invalid_request_error","message":"Output blocked by content filtering policy"}` が出て止まるときに見えていたもの
この症状は、Claude Code が編集や生成を進めようとした直後に、Anthropic API 側のエラーとして ```text Error: {"type":"error","error":{"details":null,"type":"invalid_request_error","message":"Output blocked by content filtering policy"},"request_id":"req_011CbWYp22Y864uHoBmCJ8hy"} ``` のような応答を返し、作業が進まなくなるものです。報告されている issue はどちらも同じエラーメッセージで、[#63572](https://github.com/anthropics/claude-code/issues/63572) と [#61565](https://github.com/anthropics/claude-code/issues/61565) です。 切り分けの入口は単純で、あなたのケースが「ファイルの中身や依頼内容に関係なく、このエラー文字列で止まる」かどうかです。
papoo.work
`Invalid OAuth Request — Missing redirect_uri parameter` が出て Claude Code の OAuth ログインが進まないとき
`Invalid OAuth Request — Missing redirect_uri parameter` が出て Claude Code の OAuth ログインが進まないとき
まず、この症状に当てはまりやすいのは、ブラウザが開いた先で `Invalid OAuth Request — Missing redirect_uri parameter` と表示され、ログイン処理が最後まで進まないケースです。Issue では、`claude auth login` のあとにブラウザが `claude.ai/cai/oauth/authorize` 側へ飛び、認証完了後に `https://claude.com/cai/oauth/authorize` 付近で同じ文言が出る流れが報告されています。`claude setup-token` や Console Anthropic の “Continue with Claude Pro” でも再現した例がありました。([#91911](https://github.com/anthropics/claude-code/issues/91911)) 同じ症状は、別の報告でも見え方がかなり近いです。`/login` の直後にブラウザで OAuth エラーになり、しかも別マシンの別ユーザーでも同じエラーが出た、という内容でした。
papoo.work
`Tell the user that these servers need to be authorized … and` が出るのに、実際は使えることがある
`Tell the user that these servers need to be authorized … and` が出るのに、実際は使えることがある
まず切り分けたいのは、MCP 接続が本当に未認証なのか、それとも「未認証だと言われているだけ」なのかです。今回の症状は後者として報告されています。`claude.ai` の OAuth connector がすでに認証済みで、同じセッション内でツール呼び出しも成功しているのに、セッション開始時の system reminder に「requires authentication before their tools can be used」と出て、さらに > “Tell the user that these servers need to be authorized … and that the capability is unavailable until they do.” という指示まで載る、という内容です。該当する issue は [#76320](https://github.com/anthropics/claude-code/issues/76320) と [#77534](https://github.com/anthropics/claude-code/issues
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見かけたときに確認したいこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見かけたときに確認したいこと
このエラーは、GitHub Issue 上では複数件まとまって報告されています。手元で見えた範囲では、いずれも同じ文言の `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ており、たとえば [#79235](https://github.com/anthropics/claude-code/issues/79235)、[#79179](https://github.com/anthropics/claude-code/issues/79179)、[#79166](https://github.com/anthropics/claude-code/issues/79166)、[#79272](https://github.com/anthropics/claude-code/issues/79272) に含まれていました。 ただし、報告内容だけでは原因はひとつに絞れません。モデルの切り替えに見えるという報告もあれば、ネットワーク試験の最中に止まったという報告もあり、Issue の本文から
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le — `keys=249 messages=248` が出たときに見ること
TelemetrySafeError: VirtualMessageList: itemKeys/messages le — `keys=249 messages=248` が出たときに見ること
まず、この症状が自分のケースかどうかは、エラー本文の形でほぼ見分けられます。今回集まっている issue では、いずれも `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` に続いて、`keys=... messages=... range=[...,...)` という不一致が出ています。たとえば #79204 では `keys=249 messages=248 range=[211,249)`、#79194 では `keys=107 messages=106 range=[84,107)`、#79182 では `keys=520 messages=518 range=[460,520)` でした。`keys` と `messages` の数が 1 ずれ、しかも `range` が終端にかかっているのが共通点です。 この共通点だけを見ると、ユーザーがやっていた作業はかなり幅があります。計算作業をしていた人もいれば、DB の fine-tuning、防御的なセキュリティ作業、通常のデプロイ作業
papoo.work
exit code 139 で `claude` が起動直後に落ちるときの見分け方
exit code 139 で `claude` が起動直後に落ちるときの見分け方
`claude` を打った瞬間に何も表示されず終わる。`claude --help` も `claude --version` も同じで、終了コードが 139 になる。今回の issue 群は、この形にかなり近い症状です。 報告されているのは、Ubuntu 26.04 LTS の VirtualBox VM 上で `claude` が即死した例と、Linux x86_64 上で 2.1.243 が起動直後に SIGSEGV で落ちる例です。どちらも、通常の対話画面が出る前に失敗しています。[#63635](https://github.com/anthropics/claude-code/issues/63635) と [#89390](https://github.com/anthropics/claude-code/issues/89390) では、少なくともその挙動が一致しています。 今回の一次情報では、私の環境で再現確認はできていません。実際に取れたのは次の環境情報だけです。 ```text OS : Linux 3.10.0-1160.76.1.el7.x8
papoo.work
1本の記事より、「攻撃側の手つき」が気になった
1本の記事より、「攻撃側の手つき」が気になった
この記事を読んで最初に思ったのは、もう「AIが脆弱性を見つける」より、「AIを使って攻撃の作業をどこまで雑に、どこまで速くできるのか」のほうが現実味を帯びてきたな、ということだった。 防御の文脈でAI活用はよく語られるけれど、実際には攻撃者のほうが手順の自動化に向いている場面が多い。発見から再現、PoC作成、修正の試行錯誤まで、面倒な繰り返しをかなり削れるからだと思う。 それで少し引っかかるのは、こういう話が出るたびに「AIが危険だ」で終わってしまいがちなことだ。そこよりも、作業のボトルネックがどこにあったのかを見るほうが本質的ではないかと思う。 たとえば patch を読んで exploit に落とす流れは、昔から人間には地味で時間のかかる仕事だった。そこに Claude Code のような coding agent を挟むと、単なる補助ではなく、かなり実務の中心に近いところまで入ってくる。ここが一番ぞっとするし、同時に面白い。 ただ、AI がすべてを自動でやってくれるわけではないはずで、最後に効いてくるのは人間の見立てだとも感じた。どこが本当に脆いのか、どの失敗はノイズで、どの失敗
papoo.work
`WorktreeRemove hook failed` が出るのに、hook 自体は悪くないことがある
`WorktreeRemove hook failed` が出るのに、hook 自体は悪くないことがある
最初に切り分けたいのは、「本当に WorktreeRemove hook が失敗したのか」と「削除経路の都合でそう見えているだけか」です。今回の issue 群では、その2通りが混ざっています。 ひとつは [#82097](https://github.com/anthropics/claude-code/issues/82097) です。ここでは、`claude agents` の agent 削除で `WorktreeRemove hook failed` が出るものの、報告者の言葉では `~/.claude/hooks/worktree-remove.sh` はどの経路でも `0` を返しており、hook が直接壊れているわけではありません。報告では、`WorktreeCreate` で作られた worktree のセッション記録に `hookBased: true` が入り、`originalHeadCommit` がないため、CLI 側が worktree 状態を検証できず削除を拒んでいる、という説明になっています。つまり、見えているエラー文と実際の原因がずれている可能性があ
papoo.work
Permission to use mcp__workspace__bash has been denied. が出続けるときに確認したこと
Permission to use mcp__workspace__bash has been denied. が出続けるときに確認したこと
この症状は、Cowork で `mcp__workspace__bash` と `mcp__workspace__web_fetch` が毎回拒否される、という形で報告されています。関連する issue は [#91582](https://github.com/anthropics/claude-code/issues/91582) と [#91561](https://github.com/anthropics/claude-code/issues/91561) です。 まず、自分のケースかどうかは次の見え方で切り分けられます。Issue 報告では、`mcp__workspace__bash` だけでなく `mcp__workspace__web_fetch` も同時に拒否され、しかも毎回すぐに ```text Permission to use mcp__workspace__bash has been denied. ``` が返るとされています。許可確認のプロンプトは一度も出ず、Read / Glob / Grep / WebSearch / remote MCP conne
papoo.work
claude が `command not found` になるのに、インストール自体は成功したように見える
claude が `command not found` になるのに、インストール自体は成功したように見える
新しいターミナルを開くたびに `claude` が見つからない。けれど、インストールの途中では成功メッセージが出ている。そんなときは、まずこの2つの issue が自分の症状に近いかを見たほうがいいです。 1つは、`install.sh` か `claude install` が「launcher と shell integration を設定した」と表示するのに、`~/.local/bin` を `PATH` に追加していないケースです。報告は macOS / zsh ですが、症状そのものは「入ったはずなのにシェルから見えない」です。該当 issue は [#76060](https://github.com/anthropics/claude-code/issues/76060) です。 もう1つは、自動更新の途中で optional dependency のダウンロードが詰まり、更新は成功扱いで終わるのに、次の起動で `claude: command not found` になるケースです。こちらは [#72690](https://github.com/anthropics/c
papoo.work
exit code 127 が出るときにまず見るところ
exit code 127 が出るときにまず見るところ
手元の issue を見る限り、`exit code 127` は少なくとも 2 つの別系統で報告されています。ひとつは macOS の Claude Desktop / Cowork まわりで、Claude Code のプロセス自体が起動できずに落ちるケースです。もうひとつは、プロジェクト内に置いたカスタム subagent が Agent tool に現れないという報告です。後者は症状の説明に `exit code 127` そのものは出ていませんが、同じ症状クラスタとして渡されているため、周辺で起動や読み込みに失敗している可能性はあります。ただし、そこは現時点では断定できません。 まず、自分のケースがどちら寄りかを切り分けます。 `exit code 127` が前面に出るのは、[#58495](https://github.com/anthropics/claude-code/issues/58495) の報告です。ここでは macOS Intel、App Store 版の Claude Desktop、native install の Claude Code CLI という構
papoo.work
Claude Code が exit code 134 で落ちるときに、まず見るべき差分
Claude Code が exit code 134 で落ちるときに、まず見るべき差分
自分のケースかどうかを先に切り分けるなら、まず「Claude Desktop に付属している Claude Code だけが落ちるのか」を確認したほうが早いです。issue には、同じ macOS 12 系の機械で、Desktop app の bundled build だけが起動直後に死に、standalone CLI は動いた例がありました。つまり、少なくとも報告上は「macOS が古いから全部だめ」という話ではありません。 issue に出ているエラーは、どれも「起動直後に dyld がシンボルを見つけられず abort する」という形です。たとえば #91381 は `_DNSServiceGetAddrInfoEx`、#75206 は libc++ の symbol not found、#91550 も `_DNSServiceGetAddrInfoEx` でした。見た目は違っても、どれも `exit code 134` に落ち着いています。 #75206](https://github.com/anthropics/claude-code/issues/75206) では、
papoo.work
thinking blocks cannot be modified が出るときに起きていたこと
thinking blocks cannot be modified が出るときに起きていたこと
まず、このエラーが出るケースかどうかを切り分けます。手元の issue 報告では、どれも `thinking` か `redacted_thinking` のブロックが、最新の assistant message に入ったあとに壊れています。しかも一度壊れると、そのセッションの続行や再開がずっと失敗し続けます。 たとえば [#63258](https://github.com/anthropics/claude-code/issues/63258) では、バックグラウンド実行した subagent が最初のターンで即座に落ちています。`Explore` agent でも一般の `Agent` でも同じで、ツール呼び出しに進む前にこの 400 が返っていました。再試行しても同じでした。 共通しているのは、単発の一時的な失敗ではなく、会話履歴のどこかにある assistant message の `thinking` 系ブロックが、送信し直す過程で「元の応答のまま」でなくなってしまっている点です。issue の本文では、`thinking` の中身が空になっているのに signature
papoo.work
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.1.content.22: `thinking` or `redacted_thinking` blocks in the latest assi を踏んだときに確認したいこと
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.1.content.22: `thinking` or `redacted_thinking` blocks in the latest assi を踏んだときに確認したいこと
この症状は、Claude Code の会話が途中から進まなくなり、API から 400 を返され続けるタイプのものです。報告されている文言はほぼ共通していて、`thinking` か `redacted_thinking` ブロックを最新の assistant message から変更できない、という内容になっています。 Issue 群を見る限り、[#63121](https://github.com/anthropics/claude-code/issues/63121)、[#63341](https://github.com/anthropics/claude-code/issues/63341)、[#63247](https://github.com/anthropics/claude-code/issues/63247)、[#63337](https://github.com/anthropics/claude-code/issues/63337)、[#63404](https://github.com/anthropics/claude-code/issues/63404)、
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le で始まる desync は、いま報告されている同型の症状です
TelemetrySafeError: VirtualMessageList: itemKeys/messages le で始まる desync は、いま報告されている同型の症状です
この症状は、`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` を含むエラーとして、少なくとも 2 件の issue に出ています。報告された環境はいずれも Windows で、Claude Code の Version は `2.1.257` でした。現時点で解決済みの issue は 0 件です。 まず、自分のケースかどうかを見分けるなら、エラー文字列がほぼそのまま一致するかを確認するのがいちばん早いです。報告内容では、`keys=115 messages=114 range=[58,115)` と `keys=370 messages=369 range=[328,370)` のように、`keys` と `messages` の件数が 1 ずれていました。つまり、見えているのは「メッセージ一覧の内部整合性が崩れた」タイプの障害で、少なくとも issue 上は入力文そのものより、表示・追跡しているメッセージ列の不整合に寄っています。 関連する報告は [#91323](https://gi
papoo.work
`Remote Control disconnected — Your terminal's Claude Code session stopped responding. Check your terminal for errors, then resend your message.` が出るときに見るところ
`Remote Control disconnected — Your terminal's Claude Code session stopped responding. Check your terminal for errors, then resend your message.` が出るときに見るところ
この症状は、少なくとも issue [#79057](https://github.com/anthropics/claude-code/issues/79057) と [#76954](https://github.com/anthropics/claude-code/issues/76954) で報告されています。 どちらも共通しているのは、Desktop 側でセッションを開き直したときに Remote Control 接続が失敗し、同じ文言のエラーが出ることです。 まず、自分のケースがこの系統かを切り分けると話が早いです。 同じ issue のコメントでは、これは cloud-sandbox の routine 実行ではなく、ローカルホストの scheduled-task session だと補足されています。つまり、セッション一覧にはアカウント単位で出てくるが、実体は最初に動いた端末側にあった、ということです。 > `Remote Control disconnected — Your terminal's Claude Code session stopped res
papoo.work
`Subprocess initialization did not complete within 60000ms — ` が出るときに見るべきこと
`Subprocess initialization did not complete within 60000ms — ` が出るときに見るべきこと
この症状は、少なくとも issue 報告上では、Claude Code の subprocess 起動後に初期化が 60 秒で打ち切られたときに出ています。該当する報告は [#72315](https://github.com/anthropics/claude-code/issues/72315) と [#91149](https://github.com/anthropics/claude-code/issues/91149) です。どちらもエラーメッセージは同じで、ホスト側は「authentication and network connectivity」を疑う文言を出しています。 まず切り分けたいのは、「認証やネットワークそのものが壊れている」のか、「subprocess は立ち上がるが、その後のホスト側 handoff で止まっている」のかです。後者は [#91149](https://github.com/anthropics/claude-code/issues/91149) の報告内容にかなり近く、そこでは IDE extension host から起動した Claud
papoo.work
Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"} で止まる Claude Code の 429
Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"} で止まる Claude Code の 429
この症状は、GitHub Issue 上では少なくとも [#71635](https://github.com/anthropics/claude-code/issues/71635) と [#71504](https://github.com/anthropics/claude-code/issues/71504) で報告されています。どちらも、`API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited` という説明と、同じ 429 系のエラー文字列が付いていました。報告内容だけを見る限り、利用者側の使用量上限ではなく、サーバー側の一時的な制限として扱われています。 実際の報告では、次のように出ています。 ```text 報告されたエラー: Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"},"request_id":"req_011CcQs8
papoo.work
`Unable to connect to API (ConnectionRefused)` が出るときにまず見ること
`Unable to connect to API (ConnectionRefused)` が出るときにまず見ること
この症状は、Claude Code が API への接続に失敗したときに出ています。今回の材料の中では、同じ文言が出ている issue は 2 件あり、Windows の報告 [#71485](https://github.com/anthropics/claude-code/issues/71485) と、macOS の報告 [#75897](https://github.com/anthropics/claude-code/issues/75897) です。どちらも「接続できない」こと自体は共通していますが、切り分けの材料は少し違います。 最初に見るべきなのは、Claude Code 以外では API に届いているかどうかです。[#71485](https://github.com/anthropics/claude-code/issues/71485) では、`claude auth status` はログイン済みで、`api.anthropic.com:443` への TCP テストも成功しています。さらに HTTPS は HTTP 401 まで返っており、少なくともネットワー
papoo.work
Claude Code で `HTTP 500` が返るときに見えていること
Claude Code で `HTTP 500` が返るときに見えていること
まず切り分けると、この症状は少なくとも 2 件の報告で同じ文言が出ています。ひとつは VS Code 拡張で Claude Code を使っているときに、もうひとつはターミナルからのリクエストで、どちらも `500 Internal server error` です。報告内容だけを見る限り、特定のファイル操作に限られた失敗ではなく、Claude Code への要求そのものが通らない状態に見えます。 該当する issue は [#70336](https://github.com/anthropics/claude-code/issues/70336) と [#59784](https://github.com/anthropics/claude-code/issues/59784) です。 ```text API Error: 500 Internal server error. This is a server-side issue, usually temporary — try again in a moment. If it persists, check https://st
papoo.work
会話が長くなったら、節目で要約させて前提を保つ
会話が長くなったら、節目で要約させて前提を保つ
長いやり取りで一番こわいのは、Claude Code が急に変な方向へ走ることではない。前提を忘れたまま、もっともらしい修正を積み増していくことだ。これで差し戻しが増える。diff は肥大化する。こっちは「何の話だったっけ」と画面を見返す羽目になる。 そこで効くのが、節目要約、途中要約だ。会話が一定の長さになったら、いったん要点を短くまとめさせて、前提を言葉に戻す。地味だが、これを入れるだけで迷走がかなり減る。 Claude Code は、ファイルを読ませて直したり、複数ステップの作業を続けたりすると、会話の流れに引っ張られる。だから「今どこをやっていて、何を変えない方針なのか」を途中で固定し直すのが大事になる。特に、リネーム、ファイル整理、文書の推敲みたいに、見た目以上に前提が崩れやすい作業で効く。 やり方は単純だ。作業がひと区切りついたら、次のように節目要約を頼む。 ```text ここまでの前提と、今確定している方針を5行で要約してください。 あわせて、まだ未確定の点を箇条書きで分けてください。 そのあと、次に触るべきファイルだけ挙げてください。 ``` この頼み方のいいところは
papoo.work
途中報告の頻度を決めて、黙って進みすぎない
途中報告の頻度を決めて、黙って進みすぎない
Claude Code は、放っておくと気持ちよく走り続ける。で、そのまま最後にまとめて見せてきて、こちらが「そこじゃない」と言う。これがいちばんもったいない。途中報告、つまり進捗頻度を先に決めておくと、この事故がかなり減る。 大事なのは、毎回こまかく監視することではない。どの区切りで一度止めるかを決めることだ。たとえば「3ファイルごと」「1つの機能の骨組みができたら」「削除候補を出したらその場で止まる」のように、報告のタイミングを先に置く。そうしておくと、Claude Code が黙って走り切ってしまう前に、方向だけ直せる。diff がふくらみすぎる前に止められるのも強い。 筆者は昔、これを甘く見て手戻りした。文書整理の下ごしらえを Claude Code に任せたとき、「古い版を探して、重複っぽいものをまとめて」とだけ投げたら、かなり進んだあとでまとめて報告してきた。整理のやり方は悪くなかったが、こちらは途中で「この分類、案件ごとに切るべきだった」と気づいていた。途中報告の合図がなかったせいで、修正が大きくなった。あれは普通にもったいない。 やることは単純だ。最初の依頼に、作業の進
papoo.work
Webページに話しかけただけで危ない、という嫌な現実
Webページに話しかけただけで危ない、という嫌な現実
いちばん引っかかったのは、「危険なコードを直接渡したからやられた」のではなく、ごく普通の“要約して”という依頼から崩れたことです。AIエージェントって、いまや「入力された文章を読む」だけじゃなく、「勝手にWebを取りに行く」「落としたファイルを展開する」「別のツールを起動する」までやる。便利さの裏で、その連鎖のどこか一つが噛み合うと、かなり遠くまで行ってしまうんだなと思いました。 面白いというか、怖いというか、特に印象に残ったのは、Claudeの安全設計そのものが抜け道になっている点です。Binaryを実行しないのは、普通ならいいことです。でもその拒否がきっかけで、Claudeが自分でdecoderを書き、その過程でローカルの `struct.py` を拾ってしまう。こういうのは、単体では小さな判断に見えるのに、つながると攻撃になる。人間が見て「まあ妥当」と思う行動の積み重ねで破られるのは、かなり厄介です。 あと、Anthropicの「working as designed」という返しも、読んでいて重かったです。たぶん会社としては、モデルの賢さと安全性を同じものとして売
papoo.work
週次上限が戻るだけでも、ちょっと安心する
週次上限が戻るだけでも、ちょっと安心する
この記事を読んでまず思ったのは、プロモーションで一度“甘やかされた”あとに恒久値へ戻すと、実質は上がっていても下がったように見えるのがやや巧妙だな、ということでした。 100が125になるのは確かに改善です。でも、直前まで150だったなら、体感としては「増えた」というより「少し締まった」に近いはずです。こういう出し方は、数字の印象がかなり効くなと思いました。 ただ、利用者から見れば、恒久的に上限が増えるのは素直にありがたいはずです。Claude Code みたいなコーディング支援は、ちょっと集中して使うとすぐ上限に触れるので、週単位の制限が少しでも緩むのは地味に効きます。AI の性能そのものより、こういう“使える量”が実際の満足度を左右する局面が増えてきたんだな、とも感じました。 一方で、プロモーションを先に大きく出しておいて、その後に少し下げる形は、今後もいろいろな AI サービスで増えそうです。機能追加よりも運用コストのほうが重いのかもしれないし、ユーザーに「前より良くなった」と納得してもらうための着地としても、かなり現実的なのだと思います。派手さはないけれど、こういう調整にサービ
papoo.work
Claude Code の Auto Mode は「便利」だが、防波堤にはならない
Claude Code の Auto Mode は「便利」だが、防波堤にはならない
Anthropic の Claude Code にある Auto Mode をめぐって、かなり嫌な実験結果が出た。見た目はただのサイト要約なのに、工夫された入力を通すと、Claude Code Opus 5 が攻撃者の用意した流れに引き込まれ、最終的にコード実行まで進んでしまうという話だ。しかも著者は、少数の試行ながら 60〜80% という攻撃成功率を観測している。この記事が面白いのは、外部評価で「0.00%」とされた同じ Auto Mode を、別の攻め方で揺さぶっている点にある。つまり、モデルの賢さだけではなく、周辺の運用や実行環境をどう切り分けるかが本当に問われている。 著者が試したのは、Claude Code Opus 5 の Auto Mode が有効な状態で、特定のWebサイトを要約させる単純なタスクだった。入力は「Summarize https://archive.<redacted>.uk/」のような形で、サイトは一見するとノートや記録のアーカイブに見える。だが実体はZIPアーカイブで、そこに攻撃用の仕掛けが埋め込まれていた。 最初の狙いは、Claude を WebFe
papoo.work
`Improved the Read tool to return a truncated first page with` が見えても、読み方によってはまだ落ちる
`Improved the Read tool to return a truncated first page with` が見えても、読み方によってはまだ落ちる
まず切り分けたいのは、`Read` が「全部読む」ときに途中まで返してくるケースなのか、`offset` や `limit` を指定したケースなのかです。今回の issue 群は同じ症状クラスタですが、挙動が少し違います。 ```text File content (84502 tokens) exceeds maximum allowed tokens (25000). Use offset and limit parameters to read specific portions of the file, or search for specific content instead of reading the whole file. ``` ここで引っかかるのは、文面だけ見ると「offset と limit を使え」と言われているのに、まさにその `offset` / `limit` 指定で失敗している点です。issue の報告では、2.1.145 で導入された「whole-file read を PARTIAL view で返す」改善は、あくまで `offset` / `li
papoo.work
Error: 401 The socket connection was closed unexpectedly. Fo で止まるときにまず見るところ
Error: 401 The socket connection was closed unexpectedly. Fo で止まるときにまず見るところ
この症状は、Claude Code 側の issue 報告では 2 件とも closed になっており、しかも両方が duplicate 扱いでした。参照できる報告は [#70557](https://github.com/anthropics/claude-code/issues/70557) と [#70753](https://github.com/anthropics/claude-code/issues/70753) です。 最初に切り分けたいのは、「同じ 401 系の文面が出ているだけ」なのか、それとも「本当に会話の流れを壊しているのか」です。issue #70557 では、`.172` 以降にほぼ毎日このエラーが出るという報告があり、メッセージは `Please run /login · API Error: 401 The socket connection was closed unexpectedly. For more information, pass \`verbose: true\` in the second argument to fetch()` でし
papoo.work
`Session creation failed` が出るときに見えているのは、たぶん「古い状態が残っている」こと
`Session creation failed` が出るときに見えているのは、たぶん「古い状態が残っている」こと
この症状に近いのは、Remote Control のセッション作成が失敗し、再接続や再登録をしてもすぐには直らないケースです。報告されている issue では、iOS の Claude app から Remote Control セッションを作ろうとすると `Session creation failed — see debug log` が出る一方で、ローカル側の `claude-remote@*` systemd サービスは healthy に見えていた、と書かれています。しかも、別のマシンから新しく Remote Control セッションを登録すると、影響を受けていた環境全体で復旧したそうです。これは [#57715](https://github.com/anthropics/claude-code/issues/57715) にある報告です。 別の報告では、macOS で `claude --remote-control ketobaza` を開始したあとに Remote Control が切断され、`Session creation failed` が出たとされています。
papoo.work
The model's tool call could not be parsed (retry also failed) が出るときに見えていたこと
The model's tool call could not be parsed (retry also failed) が出るときに見えていたこと
まず、自分のケースかどうかを切り分けるなら、実行中にこの文言で止まるかを見ます。 > `The model's tool call could not be parsed (retry also failed)` 今回の症状クラスタで参照できる issue は、どちらも Claude Code 側で tool call の構造が壊れていたケースでした。[#62467](https://github.com/anthropics/claude-code/issues/62467) では、`claude-opus-4-7` と extended thinking の組み合わせで、`tool_use` ブロックが parse できずに hard-stop していたと報告されています。[#74620](https://github.com/anthropics/claude-code/issues/74620) では、Opus 4.8 の tool call で、開始タグが `court` や `call`、`count`、`caught`、`co` のような近い文字列に崩れ、harness
papoo.work
exit code 143 が出る Claude Code の切り分けメモ
exit code 143 が出る Claude Code の切り分けメモ
まず、手元の症状がこのクラスタに当てはまるかを見るなら、出方がかなり重要です。issue #62985 では、デスクトップアプリのサイドバーでセッションを切り替えただけで、動作中の `claude` プロセスが SIGTERM で止まり、`exit code 143` になっています。`Session was interrupted` の表示が出て、実行中の agent や tool call、応答途中の処理が止まる、という報告です。参照元は [#62985](https://github.com/anthropics/claude-code/issues/62985) です。 もう一つの [#62202](https://github.com/anthropics/claude-code/issues/62202) は、Desktop app と VS Code extension でだけ、ちょうど 300 秒ごとに `exit code 143` で落ちるという報告です。terminal CLI の `claude` では起きず、ラッパー側に限って再現している、と書かれています。こ
papoo.work
HTTP 404でClaude CodeがGitHubのprivate repoを読めないときに見えること
HTTP 404でClaude CodeがGitHubのprivate repoを読めないときに見えること
まず、この症状に当てはまるかを切り分けます。Issue 上では、Claude の GitHub 連携が有効になっていても、private repository にアクセスできず HTTP 404 に見える報告が出ています。たとえば [#68517](https://github.com/anthropics/claude-code/issues/68517) では、個人アカウント配下の private repo に対して Claude GitHub App を「All repositories」でも「Only select repositories」でも許可し直し、Claude 側の GitHub integration を再接続し、さらに競合しそうな custom GitHub MCP connector まで外しても、なお読めなかったと書かれています。 同じ症状として、GitHub connector は接続済みなのに、repo の追加時にファイルの読み込みや同期が失敗する、あるいは project context には載るのに個別チャットでは失敗する、という報告もありまし
papoo.work
Claude Code が commit と PR に勝手につける Session URL、必要なら自分で選ばせてほしい
Claude Code が commit と PR に勝手につける Session URL、必要なら自分で選ばせてほしい
Claude Code が、コミットメッセージや Pull Request の説明文の末尾に session URL を自動で入れている。これに対して、GitHub の issue では「最初から有効にするのではなく、使う側が明示的に選ぶ opt-in にすべきだ」という要望が出された。見た目の問題だけでなく、開発履歴に知らないリンクが残ることへの違和感が強く、AI 補助ツールの“署名”をどこまで自動で入れるべきか、という話にもつながるので取り上げる価値がある。 問題提起をしたのは GitHub 上の `anthropics/claude-code` リポジトリに立てられた feature request だ。タイトルは「Session URL appended to commit messages and PR descriptions by default — should be opt-in」で、Claude Code が生成したコミットメッセージと PR description の末尾に、毎回 session URL が自動付与される仕様をやめてほしい、という内容になっている。
papoo.work
Error: 400 {"type":"error","error":{"type":"invalid_request_error"} で止まる Claude Code の `/goal` と stop hook
Error: 400 {"type":"error","error":{"type":"invalid_request_error"} で止まる Claude Code の `/goal` と stop hook
まず切り分けたいのは、このエラーが「会話全体」ではなく、`goal` コマンドや stop hook の実行時に出ているかどうかです。今回の報告では、`/goal` が stop hook 側で失敗している例と、stop hook evaluator から `Prompt is too long` が返る例が並んでいます。`#61759` では「1M context window を無効にした状態で 200k tokens を超えると `/goal` が失敗する」と書かれており、通常の会話は 1M までは動くが、stop hook でだけ問題が出る、という切り分けになっています。`#62560` でも同じ系統で、stop hook evaluator の API エラーとして `Prompt is too long` が返っています。いずれも [#61759](https://github.com/anthropics/claude-code/issues/61759) と [#62560](https://github.com/anthropics/claude-code/issue
papoo.work
Claude Codeの「増えたようで減る」話に引っかかる
Claude Codeの「増えたようで減る」話に引っかかる
読んでまず思ったのは、これはかなり説明の仕方がうまい、というより少し意地悪だな、ということだった。 「25%増える」と言われると普通は歓迎したくなるけれど、実際には今の一時的な上乗せが終わるだけで、足元から見ると17%減る。数字の見せ方ひとつで印象がここまで変わるのは、サブスク系の料金や利用制限ではよくあることだけど、今回みたいに開発者向けの道具でやられると、なおさら気になる。 Claude Code って、ただのチャットUIではなくて、日々の作業にかなり深く入り込む道具だと思う。だから「週あたりの利用枠」が少し削られるだけでも、体感はわりと大きいはずだ。しかも Anthropic 自身がいったん元のスレッドを消して、あとから「今日と比べると17%減る」と言い直している。最初の言い方に自信がなかったのか、あるいは炎上しそうだと判断したのか。ここは少し気になるところだった。 一方で、利用量が会話の長さや tool usage で変わる以上、週の上限を固定の回数で語れないのも分かる。だからこそ、ユーザー側は「何回使えるか」より「自分の使い方だとどれくらい余裕があるか」を見ないといけない。便
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見つけたら読むこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見つけたら読むこと
まず、自分のケースかどうかを切り分けます。この症状は、Claude Code の実行中に `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` という文字列が出て、`keys=` と `messages=` の数が一致していない形で報告されています。今回寄せられた 2 件の issue はどちらも未解決で、片方はセキュリティ監査の依頼中、もう片方は Claude Opus 5 の挙動変化を訴える内容でした。報告された場面は違いますが、出ているエラー本体は同じです。参照できる issue は [#90610](https://github.com/anthropics/claude-code/issues/90610) と [#90514](https://github.com/anthropics/claude-code/issues/90514) です。 症状の出方は、少なくとも issue 上ではかなり似ています。たとえば #90610 では、ローカルで動かしている Gitea の安全性確
papoo.work
`VM service not running. The service failed to start.` が出るときに見るところ
`VM service not running. The service failed to start.` が出るときに見るところ
このエラーは、少なくとも今回確認できた issue では、Cowork の VM サービス側で起動に失敗しているときに出ています。ユーザー向けの文言は同じでも、原因は 1 つではありません。 自分のケースかどうかを見分ける材料としては、まず「どの製品で出ているか」が重要です。[#39010](https://github.com/anthropics/claude-code/issues/39010) は Windows 10 Pro 上の Cowork で、起動時に `VM service not running. The service failed to start.` が出ています。報告者は、実体としては MSIX パッケージ配下の `AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\` に作られた VM 用の `rootfs.vhdx` や `smol-bin.vhdx` が NTFS 圧縮を引き継ぎ、Hyper-V が圧縮された VHDX をマウントできずに失敗していたと書いています。そこで見えていた HCS エラ
papoo.work
Workspace unavailable. The isolated Linux environment failed to start (VM service not running. The service failed to start.) が出るときにまず見るところ
Workspace unavailable. The isolated Linux environment failed to start (VM service not running. The service failed to start.) が出るときにまず見るところ
このエラーは、Claude の Cowork/interactive session で、隔離された Linux 環境が立ち上がらないときに出ています。少なくとも issue 報告上では、ファイル操作の機能は動くのに、shell/sandbox だけが落ちるケースがありました。 該当する報告は [#70199](https://github.com/anthropics/claude-code/issues/70199) です。 切り分けの起点はかなりはっきりしています。`Workspace unavailable. The isolated Linux environment failed to start (VM service not running. The service failed to start.)` が出ていて、しかも Read/Write/Edit のようなファイル系ツールは使える。ならば、壊れているのはワークスペース全体というより、隔離 Linux 環境の起動部分だと考えるのが自然です。 別系統の issue ですが、Cowork の周辺で「内部の実行環境や受け
papoo.work
長い作業のあとに差分を圧縮して、要点だけ残す
長い作業のあとに差分を圧縮して、要点だけ残す
長時間いじったあとに「全部見直してください」と投げるのは、だいたい破綻する。差分がでかすぎて、Claude Code も人間も本当に大事なところを見失うからだ。ここでやるべきなのは、差分圧縮と要点整理だ。作業の途中で散らかった変更を、あとから読める単位に畳み直す。変更点の量を減らす話ではない。意味の粒度をそろえる話である。 Claude Code では、ひたすら作業を続けたあとに「変更を要点だけ残す形にして」と頼むと、雑多な修正をまとめ直す助けになる。ファイル整理でも、文書作成でも、コード修正でも効く。要は、あとで自分か相手が追える状態に戻す作業だ。 最初にやることは単純だ。いったん変更を見せて、何を残し、何を捨てるかを明確にさせる。 ```text ここまでの変更を差分圧縮したい。 次の3つに分けて整理してほしい。 1. 本当に残すべき変更 2. まとめられる変更 3. 捨ててもよい一時的な変更や試行錯誤 出力は、変更点の要点を箇条書きで短くまとめて。 そのあと、必要ならコミットメッセージ案も出して。 ``` この頼み方のいいところは、Claude Code に「全部説明しろ」と言わ
papoo.work
再現しない不具合を切り分けて、勘違いを減らす
再現しない不具合を切り分けて、勘違いを減らす
「たまに起きる」「さっきは動いた」──その手の話は、だいたい不具合そのものより先に、話の組み立てが崩れている。Claude Code で詰まるのもそこだ。再現しないまま雑に修正へ飛ぶと、原因と対処がズレる。不具合切り分けと再現性確認を先に固めるだけで、勘違いはかなり減る。 Claude Code は、曖昧な状況説明をそのまま飲み込むと、もっともらしい修正案を出してくる。そこに人間側の思い込みが乗ると、別の場所を直して終わりだ。だから最初にやるべきは「直すこと」ではなく、「再現する条件を削ること」になる。 たとえば、こんな頼み方が効く。 ```text この不具合を再現したいです。まず修正はしないでください。 次の情報を整理してください。 どの操作で起きるか 毎回起きるのか、たまに起きるのか 何が起きたように見えるか 直前に変えたファイルや設定は何か 再現手順を1つずつ最小化するならどこまで絞れるか 必要なら、再現確認用のチェックリストを作ってください。 ``` この頼み方のいいところは、Claude Code を「修理係」ではなく「切り分け係」として使える点だ。いきなりコードを書かせる
papoo.work
ログと変更履歴を並べて、判断のズレを追う
ログと変更履歴を並べて、判断のズレを追う
変更を見ただけで納得した気になると、だいたい後で崩れる。差分は「何を変えたか」しか教えてくれないが、ログは「そのとき何を考えていたか」を残す。Claude Code では、この二つを並べて追う癖をつけると、作業のズレがかなり減る。作業ログ、履歴確認、どちらの感覚でも使えるやり方だ。 特に効くのは、ファイル整理や文書作成みたいに、完成物そのものより「なぜそうしたか」が重要な場面だ。最初はうまくいったように見えても、後から「この並び替えは何のためだったのか」「この削除は本当に安全だったのか」で止まる。筆者も一度、メモの整理を Claude Code に任せたあと、変更履歴だけ見て満足していたら、不要な重複を消したつもりで別の版を残していた。ログを並べていなかったせいで、判断の筋道が消えていたわけだ。 やることは単純だ。Claude Code に作業を頼むとき、最初に「作業ログを残しながら進めてほしい」と明示する。次に、区切りごとに変更内容と判断理由を短く書かせる。最後に、必要なら Git の差分やファイルの更新履歴と見比べる。これだけで、単なる「結果の確認」から「判断の確認」に変わる。 た
papoo.work
PR に載せる前に論点を整理させて、説明の芯を作る
PR に載せる前に論点を整理させて、説明の芯を作る
PR にそのまま貼る説明文を、いきなり Claude Code に書かせると、だいたい散らかる。要点が混ざる。変更の理由が薄まる。読んだ相手が「で、何を見ればいいの」となる。 ここで効くのが、先に論点整理をさせて、PR説明の芯を作ってから本文に落とすやり方だ。非エンジニアの作業でも同じで、ファイル整理でも文書作成でも、先に「何を伝えるか」を固めるだけで手戻りがかなり減る。 Claude Code は、雑に頼むと雑に広げる。これは欠点というより、指示のあいまいさをそのまま反映するだけだ。だから最初にやることは、文章を書かせることではない。論点を切ることだ。 PR説明、論点整理、この二つを先にやると、説明の芯ができる。芯ができると、後から差分を見た人が追いやすい。レビューの質も上がるし、あとで自分が読み返したときの恥ずかしさも減る。 やり方は単純だ。まず変更内容を丸ごと説明させるのではなく、論点だけを短く抜き出させる。たとえばこんな頼み方でいい。 ```text この変更について、PR説明を書く前の論点整理をしてください。 以下の観点で、重複しないように箇条書きにしてください。 変更の目的
papoo.work
コミット前に変更の見落としを洗い出させる
コミット前に変更の見落としを洗い出させる
コミット直前に「たぶん大丈夫」で流すのが、いちばん雑に事故る。差分が少ない日ほど油断するし、ファイル整理でも文書作成でも、ひとつの見落としがあとで地味に効く。 Claude Code には、コミット前確認、見落とし確認をやらせておくといい。要は、コミットする前に「何を変えたか」「消し忘れたものはないか」「別ファイルに漏れていないか」を一度洗う。人間がやると集中力が切れた瞬間に抜けるが、Claude Code は淡々と一覧化してくれる。そこが強い。 まず、作業ツリーを見せて、変更点を要約させる。これだけでも十分役に立つ。 ```bash claude ``` Claude Code が起動したら、こんなふうに頼む。 ```text 今の作業ツリーの変更を確認して、コミット前に見落としがないか洗ってください。 次を順に見てください。 変更ファイルの一覧 追加・削除・名前変更の有無 差分の要点 置き忘れた設定値、コメントアウト、デバッグコードの残り 仕様上まずい変更や、関連ファイルの更新漏れ 最後に、コミット前に人間が目で確認すべき点を短く箇条書きで出してください。 ``` この頼み方のいい
papoo.work
修正後の説明を短く要約させて引き継ぎやすくする
修正後の説明を短く要約させて引き継ぎやすくする
修正した説明を、そのまま長文で押しつけるのはだいたい失敗する。読む側は「で、何が変わったのか」だけ知りたいのに、前提や経緯まで全部読む羽目になるからだ。ここで効くのが、要約だ。さらに引き継ぎメモとしてそのまま使える形に落としておくと、次の人が拾いやすい。 Claude Code は、長い説明を短く圧縮するのが得意だ。ただし、雑に投げると要点まで薄まる。修正後の内容を、誰に渡しても同じ理解になる粒度に削るには、最初に「何のための要約か」を言い切るのがコツになる。単なる短縮ではなく、引き継ぎ用のメモにする。ここを外すと、ふわっとした文章が返ってきて終わる。 たとえば、修正した文章がこれだとする。 ```text この機能は、重複したファイル名をまとめて整理できる。対象フォルダを選ぶと、同名ファイルを一覧化し、最後にまとめて確認してから処理を実行する。誤削除を避けるため、最初はプレビューだけ表示する。 ``` これを Claude Code にそのまま丸投げするより、次のように頼むほうが使える出力になる。 ```text 次の説明を、引き継ぎメモとして使えるように短く要約してください。 条件
papoo.work
テスト結果と差分を突き合わせて、直したつもりを潰す
テスト結果と差分を突き合わせて、直したつもりを潰す
「直しました」で終わらせると、たいていどこかがまだ死んでいる。見た目は直っていても、テストは別の場所で赤いまま、あるいは差分だけ眺めると肝心の修正が抜けている。そこで効くのが、検証と照合だ。テスト結果と git diff を突き合わせる。これだけで「直したつもり」のまま次に進む事故がかなり減る。 Claude Code でも同じで、修正依頼を出して、返ってきた変更をそのまま信じるのは雑すぎる。AI はちゃんと直すこともあるが、関係ない箇所を触ったり、テストの失敗原因を外したまま別方向をいじったりもする。だから最後は、人間が「テストが指している場所」と「差分で実際に変わった場所」を重ねて見る。ここをサボると、手戻りが増える。かなり露骨に増える。 たとえば、こんな流れだ。 ```bash git diff ``` で変更点を見てから、 ```bash npm test pytest go test ./... ``` でテストを走らせる。失敗したら、そのエラーメッセージと diff を同時に見る。Claude Code に頼むときも、ただ「直して」では弱い。こう投げるといい。 ```tex
papoo.work
自分の差分を Claude Code に赤入れさせる
自分の差分を Claude Code に赤入れさせる
自分で書いた差分ほど、雑に見てしまう。そこが一番まずい。 「差分レビュー」や「レビュー依頼」を自分宛てに投げる感覚で Claude Code を使うと、勢いで書いた変更を一度外に出せる。すると、読みにくい命名、説明不足のコメント、余計なファイル変更が、かなり早い段階で見つかる。 人間の目は、実装した瞬間の文脈に引っ張られる。だから「動くしまあいいか」で流しやすい。Claude Code に赤入れさせる価値は、そこを機械的に叩ける点にある。コードの正しさだけでなく、差分の見た目、変更範囲の広さ、説明の足りなさまで見させると、後で恥をかく率が下がる。 やり方は単純だ。作業が一段落したら、未コミットの差分をまとめて見せて、レビュー観点を先に渡す。Claude Code はターミナルから使うエージェントなので、ローカルのファイルを見ながら指摘を返せる。ここで大事なのは、「直して」と丸投げする前に、まず「レビューして」と頼むことだ。いきなり修正させると、確認したい論点まで勝手に書き換えられることがある。 たとえば、こんな依頼文で十分だ。 ```text 以下の差分をレビューしてほしい。 目的はコ
papoo.work
変更前に自己レビューの観点を先に書かせる
変更前に自己レビューの観点を先に書かせる
雑にいじってから確認させると、だいたい手戻りする。Claude Code でもそこは変わらない。先にセルフレビュー、つまり事前レビューの観点を出させてから変更に入るだけで、あとから「そこじゃない」を潰しやすくなる。 この手は、コード修正だけの話ではない。ファイル整理、不要キャッシュの削除、文書の推敲みたいな作業でも効く。いきなり本体を触らせると、見た目は進んでも肝心の判断基準があいまいなまま走る。結果、差分は増えるのに、欲しかった品質には届かない。かなりもったいない。 やることは単純だ。変更を頼む前に、「何を見て自分で確認するか」を Claude Code に先に書かせる。観点を先に固定しておくと、作業中のブレが減る。人間の側も、あとからレビューしやすい。 たとえば、いきなり「この関数を直して」と投げる代わりに、こう始める。 ```text この変更を始める前に、自己レビューの観点を先に列挙してほしい。 対象は次の通り。 変更対象ファイル: src/app.ts 目的: エラーハンドリングの改善 制約: 既存の挙動を変えすぎない 出力: 先にレビュー観点、その後に変更案 観点は、機能、
papoo.work
レビュー観点をテンプレ化して、毎回の確認を速くする
レビュー観点をテンプレ化して、毎回の確認を速くする
レビューで毎回ゼロから目をこらしていると、だいたいどこかで雑になる。しかも厄介なのは、雑になる場所が毎回少しずつ違うことだ。今回たまたま見たつもりでも、次回は別の抜けが出る。これ、かなりもったいない。 Claude Code は、こういう「見る観点が毎回似ている仕事」に強い。レビュー観点テンプレ、あるいは確認テンプレとして定型を持たせておくと、何を見ればいいかを毎回考え直さなくて済む。結果として、確認が速くなるだけでなく、抜け漏れも減る。 ただし、テンプレを作れば勝手に賢くなるわけではない。雑な観点をそのまま固定すると、雑さまで恒久化する。ここを外すと、むしろ手戻りが増える。筆者は最初、「とりあえず変更点を見て」とだけ投げて、結局あとから「ここも確認して」「いや、権限まわりも見て」と差し戻しを食らった。あれはだいぶだるかった。最初から観点を固定しておけば、こんな往復は減る。 まずやることは単純だ。よく見るポイントを、短い文章で並べる。Claude Code に渡すなら、こういう形でいい。 ```text この作業のレビューでは、次の観点を毎回確認してください。 変更の目的と、実際の差分
papoo.work
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` が出るときに、まず疑うこと
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` が出るときに、まず疑うこと
この症状は、GitHub issue 上では 3 件とも同じ系統のエラー文字列として報告されています。いずれも `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` で始まり、`keys` と `messages` の数が一致していませんでした。 たとえば [#86759](https://github.com/anthropics/claude-code/issues/86759) では `keys=222 messages=221 range=[197,222)`、[#86442](https://github.com/anthropics/claude-code/issues/86442) では `keys=1139 messages=1138 range=[1078,1139)`、[#86358](https://github.com/anthropics/claude-code/issues/86358) では `keys=38 messages=37 range=[0,38)` と
papoo.work
ERR_VM_PIPE_CLOSED が出るときに見るべきところ
ERR_VM_PIPE_CLOSED が出るときに見るべきところ
この症状は、Windows 版 Claude Desktop で Cowork を起動しようとしたときに「Failed to start Claude's workspace / RPC pipe closed」と出るものです。今回参照した issue はどちらも未解決で、しかも再インストールが途中で止まる、あるいは署名検証で落ちる、という流れまで共通しています。該当する報告は [#86825](https://github.com/anthropics/claude-code/issues/86825) と [#90283](https://github.com/anthropics/claude-code/issues/90283) です。 まず、自分のケースかどうかはここで見分けやすいです。起動時に RPC pipe closed が出る一方で、VM 側のサービスは Running のまま、というパターンです。[#90283](https://github.com/anthropics/claude-code/issues/90283) では `CoworkVMService,
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync のとき、まず疑うこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync のとき、まず疑うこと
このエラー名がそのまま出ているなら、少なくとも「Claude Code のセッション内部で、保持しているメッセージ数とキー数がずれた」状態に遭遇している可能性があります。今回見ている issue では、`itemKeys/messages length desync` が複数報告されていて、しかも症状の出方が少し違います。 たとえば [#90480](https://github.com/anthropics/claude-code/issues/90480) では、リファクタリング用の orchestrator と subagent を使っている途中で safeguard penalty が出たと報告されています。本文では「理由が不明だった」「Fable5 が自分で refactoring plan を組んだ」と書かれていました。 つまり、少なくとも issue 群を見る限りでは、これは単なる表示崩れではなく、複数の会話要素を持つセッションで内部状態が食い違ったときに現れているように見えます。とはいえ、原因までは断定できません。報告された内容だけでは、Claude Code 側のバグ
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見つけたときに確認したこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見つけたときに確認したこと
まず、このエラーが自分のケースかどうかを切り分けるなら、Claude Code の画面やログに次の文言が出ているかを見ます。 `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` 今回集めた issue は 2 件で、どちらも同じ症状クラスタに入っていました。1 件は [#87704](https://github.com/anthropics/claude-code/issues/87704) で、もう 1 件は [#86637](https://github.com/anthropics/claude-code/issues/86637) です。どちらの報告でも、エラー本体はほぼ同じ形で出ています。たとえば #87704 には次のようにあります。 ```json 報告されたエラー: TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=270 messages=269 range=[237
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たら、まず確認したいこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たら、まず確認したいこと
この症状は、Claude Code の画面側で `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ているケースです。今回集まっている issue は [#90375](https://github.com/anthropics/claude-code/issues/90375)、[#90360](https://github.com/anthropics/claude-code/issues/90360)、[#90339](https://github.com/anthropics/claude-code/issues/90339)、[#90260](https://github.com/anthropics/claude-code/issues/90260) の 4 件で、いずれも open のままで、少なくともこの範囲では解決済み報告はありません。 まず、このエラーは 4 件とも同じ文言です。 ```text TelemetrySafeError: VirtualMessageLi
papoo.work
ERR_BLOCKED_BY_CLIENT が Browser pane で出るときに見ておきたいこと
ERR_BLOCKED_BY_CLIENT が Browser pane で出るときに見ておきたいこと
この症状は、Claude Code の Browser pane でトップレベルの HTML は開くのに、同一オリジンの subresource が `net::ERR_BLOCKED_BY_CLIENT` で落ちる、という形で報告されています。報告は [#86362](https://github.com/anthropics/claude-code/issues/86362) と [#89725](https://github.com/anthropics/claude-code/issues/89725) の 2 件で、どちらも「ページ自体は 200 で返るのに、CSS や JS、XHR/fetch が読めず、結果として画面が白い／素の HTML だけになる」という点が共通しています。 まず、自分のケースがこの系統かを切り分けると分かりやすいです。issue の記述で一致しているのは、次のような状況です。トップレベルの document は読み込めるのに、同じ origin の subresource だけがまとめて止まること。`http://127.0.0.1` のような li
papoo.work
Claude Codeの「消えたトークン」を自分の手元で追う
Claude Codeの「消えたトークン」を自分の手元で追う
読んでまず思ったのは、これはかなり“地味だけど効く”種類の道具だな、ということだった。AIツールの利用量って、体感と実際がずれやすい。ちょっと触っただけなのに急に制限に当たると、「自分が使いすぎた」のか「裏で何かが回っていた」のか、感覚では分からない。そこを、端末に残っている session log だけで追いかける発想はかなり筋がいいと思う。 面白いのは、単なる token カウンターではなく、「なぜ増えたか」に寄せているところだ。大きいファイルを早い段階で読んだせいで後から何度も context に載り直す、とか、短い session が大量に並んでいるのは人間の作業ではなく automation の気配だ、とか。こういう説明が返ってくるなら、ただ数字を見てため息をつくよりずっと使える。特に、limit に引っかかった理由が“自分の作業”ではなく“どこかの仕組み”だったと分かるのは、気持ちの整理にもなるはずだ。 もう一つ、README で強く押しているのが「何も外に出さない」という点だった。usage の監査系ツールは、便利そうでもログをどこかのサーバーに投げるのが気になって踏み切
papoo.work
Ptn: Insufficient scope: required "https://www.googleapis.com/auth/drive https://www.googleapis.com/auth/drive.file https://www.googleapis.com/auth/drive.resour…"` が出るときに見えているもの
Ptn: Insufficient scope: required "https://www.googleapis.com/auth/drive https://www.googleapis.com/auth/drive.file https://www.googleapis.com/auth/drive.resour…"` が出るときに見えているもの
この症状は、少なくとも issue 上では 2 件とも同じエラー文字列にぶつかっています。[#90073](https://github.com/anthropics/claude-code/issues/90073) と [#89917](https://github.com/anthropics/claude-code/issues/89917) のどちらも、報告されたエラーとして `Ptn: Insufficient scope: required "https://www.googleapis.com/auth/drive https://www.googleapis.com/auth/drive.file https://www.googleapis.com/auth/drive.resource https://www.googleapis.com/auth/drive` が挙がっていました。 ただし、この 2 件の issue だけでは、Claude Code 側のどの処理でこのエラーが起きたのか、またどう直したのかまでは分かりません。少なくとも現時点では「Google
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の desync が出るときに見えていること
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の desync が出るときに見えていること
この症状は、Claude Code 側で `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ているケースです。今回集まっている issue は 3 件で、いずれも同じ系統のエラー文字列を含んでいました。 まず、自分のケースかどうかを見分けるには、エラー本文が `itemKeys/messages length desync` を含むかを確認します。報告されているものは、たとえば `keys=215 messages=214 range=[165,215)`、`keys=22 messages=21 range=[0,22)`、`keys=267 messages=266 range=[220,267)` でした。数は違っても、`keys` と `messages` の件数が 1 ずれている点は共通しています。 実際の issue では、エラーそのものに加えて、別の症状が同時に報告されていました。[#90169](https://github.com/anthropics/claude-
papoo.work
Error: Streamable HTTP error: Error POSTing to endpoint: {"id"... を見たら最初に確認すること
Error: Streamable HTTP error: Error POSTing to endpoint: {"id"... を見たら最初に確認すること
この症状は、Claude Code から Streamable HTTP の MCP サーバーに POST したとき、返ってきたエラー本文が `Request had insufficient authentication scopes.` になっているケースです。Issue では同じ文言が複数件まとまっており、[#70638](https://github.com/anthropics/claude-code/issues/70638)、[#70627](https://github.com/anthropics/claude-code/issues/70627)、[#82461](https://github.com/anthropics/claude-code/issues/82461) のいずれにもこのエラーが含まれていました。 まず大事なのは、これが「Claude Code 全般の操作不能」というより、MCP 接続先との認証スコープ不足として報告されている点です。コメントでも、`insufficient authentication scopes` は「streamable
papoo.work
会話が長くなったら節目で要約させる
会話が長くなったら節目で要約させる
長い会話をそのまま流しっぱなしにすると、Claude Code は平気な顔で文脈を抱えたまま進む。これが曲者だ。人間は「ここまでの話、何だったっけ」となり、モデル側も要点の輪郭がぼやけてくる。そこで入れるのが途中要約、節目の要約、要点整理である。会話の途中で一度立ち止まらせ、ここまでの決定事項・未決事項・次にやることを短く並べ直させる。これだけで、手戻りがかなり減る。 筆者は以前、ファイル整理の作業を Claude Code に任せて、削除候補の洗い出しをだらだら続けたことがある。最初はよかったのに、途中から「さっきの条件」と「今回の条件」が混線して、同じフォルダを二度見させる羽目になった。最後に要約を挟んでおけば、こんな無駄はだいぶ防げたはずだ。長話は、賢さの証明ではない。たいていはコンテキストの浪費だ。 やり方は単純で、会話の節目でこう頼めばいい。 ```text ここまでの内容を、次の3点に分けて短く要約して。 1. 決まったこと 2. まだ曖昧なこと 3. 次にやること 要約は箇条書きで、各項目は1行ずつ。余計な説明は増やさないで。 ``` この依頼文の肝は、「何を要約するか」
papoo.work
前提が変わったら、古い指示を捨てて言い直す
前提が変わったら、古い指示を捨てて言い直す
Claude Code に雑に「さっきの続きで」「さっきの方針で」とだけ投げると、だいたいズレる。前提が変わったのに、古い指示を抱えたまま走らせるからだ。これが前提の更新、方針変更、そして古い前提を消すという話である。 たとえば、最初は「このフォルダを整理して」と頼んでいたのに、途中で「やっぱり削除はせず、重複候補だけ報告して」と変わったとする。ここで大事なのは、変更点だけを足すことではない。古い前提を明示して捨て、今の方針を言い直すことだ。そうしないと、Claude Code は昔の条件を混ぜたまま、半端な削除や中途半端な修正を返してくる。 筆者はこれで何度か手戻りした。最初の依頼では「不要ファイルを見つけて消したい」だったのに、途中で「実際には消さず、候補一覧だけ欲しい」に変えた。ところが、前の指示を消さずに追加だけしたせいで、削除前提の説明と一覧作成が同居した返答が返ってきた。人間なら文脈を読んで空気を直すところだが、CLI の相手にはそれを期待しないほうがいい。指示は更新ではなく置き換えとして書くのが安全だ。 やり方は単純である。まず、今の目的を一文で言い直す。次に、もう不要に
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le のエラーが出たときに見えていたこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages le のエラーが出たときに見えていたこと
このエラーは、少なくとも issue 上では 2 件とも open のままで、まだ解決済みの報告はありません。似た見え方でも、きっかけは少し違います。ひとつは null reference のデバッグ依頼で安全フィルタが過剰に反応したという報告、もうひとつは Anthropic API 側の HTTP 529 が出ていたという報告です。どちらも、本文に出ているエラー文字列は同じ系統でした。 まず、自分のケースかどうかを切り分けるなら、会話の途中でこの文字列が出ているかを見ます。issue #85965 では、`null` のボタンを調べてほしいという依頼で Fable 5 safeguards が「些細な理由で」発火したと書かれています。issue #84337 では「yesterday に 529 issues が複数回あった」とあり、同時に `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ています。つまり、見た目は同じでも、少なくとも報告上は「安全フィルタの誤検知っぽい会話」と「
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le が出たら見るところ
TelemetrySafeError: VirtualMessageList: itemKeys/messages le が出たら見るところ
この症状は、少なくとも今回の 2 件の issue では、`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` という同じエラー文字列で報告されています。該当するのは [#89889](https://github.com/anthropics/claude-code/issues/89889) と [#89307](https://github.com/anthropics/claude-code/issues/89307) です。 まず切り分けたいのは、「Claude Code が内部でメッセージ一覧の長さ不整合を起こして落ちているのか」という点です。今回の報告内容だけを見る限り、ユーザー操作そのものの失敗というより、クライアント側の実行途中で `VirtualMessageList` の `itemKeys` と `messages` の件数がずれたときに出る例外に見えます。`keys=353 messages=352 range=[298,353)` や `keys=72 messag
papoo.work
EISDIR が出る Claude Code の2つの壊れ方
EISDIR が出る Claude Code の2つの壊れ方
まず、自分のケースかどうかを切り分けます。今回の `EISDIR` は、GitHub の報告を見る限り、少なくとも 2 系統あります。ひとつは Linux arm64 で Claude Desktop が Claude Code のバイナリを落とせず、起動のたびに「binary is missing or damaged」と出る件です [#89850](https://github.com/anthropics/claude-code/issues/89850)。もうひとつは Windows の VS Code 拡張で、`\\?\` 付きのワークスペースパスを開いたときにサイドバー復元が落ちる件です [#89775](https://github.com/anthropics/claude-code/issues/89775)。 Linux 側の症状は、報告では毎回同じです。ダウンロード対象を `open()` するところで `EINVAL: invalid argument` になり、アプリ側には次の文言が出ます。 ```text Claude Code couldn't start
papoo.work
`this is the missing part.` があるのに、指示が「取り消し」に化けるときに起きていること
`this is the missing part.` があるのに、指示が「取り消し」に化けるときに起きていること
この症状は、ユーザーが不足分を示すために `this is the missing part.` と書いたあと、別のメッセージで「まだ部品が足りない」と指摘したつもりが、Claude Code 側では「その部品をキャンセルせよ」という意味に読まれてしまうケースです。報告されている issue は [#89886](https://github.com/anthropics/claude-code/issues/89886) と [#89899](https://github.com/anthropics/claude-code/issues/89899) です。 まず見分けたいのは、単なる実装漏れではなく、モデルがユーザーの追記を逆向きに解釈していないかです。今回の issue では、ユーザーがコンポーネント仕様を渡して「this is the missing part.」と伝えたのに、その後の「a11y panel and button がない」「bottom navbar がない」といった指摘が、キャンセル指示として扱われました。[#89899](https://github.co
papoo.work
`Navigation to this domain is not allowed` が出るときに、まず疑うべきこと
`Navigation to this domain is not allowed` が出るときに、まず疑うべきこと
Claude Code の Claude in Chrome connector で、`navigate` や `computer` などの操作がすぐ失敗し、エラーが `Navigation to this domain is not allowed` になる症状が報告されています。今回の issue 群では、対象ドメインは 1 つに限られず、`mail.google.com`、`google.com`、`example.com`、`riverside.com`、`riverside.fm` まで含まれていました。つまり「特定サイトだけ弾かれる」より、承認プロンプト自体が出ないまま拒否されるケースとして読むのが近そうです。 まず切り分けたいのは、これが「そのドメイン固有の拒否」なのか、「Claude in Chrome 側でドメイン承認の状態が壊れている」のかです。報告を見る限り、後者を疑う材料が多いです。[#68891](https://github.com/anthropics/claude-code/issues/68891) では、どのドメインでも即失敗し、しかも承認プ
papoo.work
Error: 413 {"error":{"type":"request_too_large","message":"Request exceeds the maximum size"} で止まるときに見えているもの
Error: 413 {"error":{"type":"request_too_large","message":"Request exceeds the maximum size"} で止まるときに見えているもの
このエラーが出ているなら、少なくとも Claude Code 側では「送ろうとしたリクエストが大きすぎる」と判定されています。報告されている2件はいずれも同じ文字列で、[#73908](https://github.com/anthropics/claude-code/issues/73908) は closed、[#77419](https://github.com/anthropics/claude-code/issues/77419) は open です。現時点では、issue だけを見る限り「何がどのくらい大きかったのか」を外から確定できません。 実際の報告では、どちらもスタックの先頭に `generate` が出ています。引用するとこうです。 ```text Error: 413 {"error":{"type":"request_too_large","message":"Request exceeds the maximum size"}} at generate (/$bunfs/root/src/entrypoints/cli.js:12:71094) ``` 別の報
papoo.work
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.7.content.0: unexpected `tool_use_id` found in `advisor_tool_result` blocks と出たときに見ること
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.7.content.0: unexpected `tool_use_id` found in `advisor_tool_result` blocks と出たときに見ること
このエラーは、Claude Code 側のトランスクリプト再構築で `advisor_tool_result` と `server_tool_use` の対応が崩れたときに出ているようです。少なくとも issue 報告では、`advisor_tool_result` の前に対応する `server_tool_use` が必要なのに、それが見つからない／ずれる、という形で説明されています。 同じ症状として報告されているのは [#62885](https://github.com/anthropics/claude-code/issues/62885) と [#89348](https://github.com/anthropics/claude-code/issues/89348) です。どちらも 400 エラーの本文に `unexpected tool_use_id found in advisor_tool_result blocks` が出ています。前者では「advisor を off にしても同じエラーが出た」とあり、後者ではセッション再開ができなくなった、と報告されています。ど
papoo.work
`ERR_CONNECTION_RESET` が出るとき、まず見るべき切り分け
`ERR_CONNECTION_RESET` が出るとき、まず見るべき切り分け
この症状は、Claude Code の cloud environment や web sandbox でブラウザ系の通信だけが落ちるときに出ています。報告されているのは、Playwright MCP の `browser_navigate` や headless Chromium の `page.goto()` が、どの URL でも `net::ERR_CONNECTION_RESET` になるケースです。対象は `https://example.com` や `www.google.com` のような一般的なサイトでも同じでした。いっぽうで、同じセッション・同じシェル内では `curl` や Node の `fetch`、`https` モジュールが成功している、というのが共通点です。これは [#85757](https://github.com/anthropics/claude-code/issues/85757) と [#73564](https://github.com/anthropics/claude-code/issues/73564) に書かれている症状です。 自
papoo.work
Claude Codeを“1件ずつ”ではなく“さばく”発想
Claude Codeを“1件ずつ”ではなく“さばく”発想
この記事を読んでまず思ったのは、発想の中心が「コードを書くこと」ではなく「大量の小さな依頼を壊さず回すこと」に完全に移っている、ということだった。そこが面白い。LLMやcoding agentの話って、つい「何でも自動化できる」方向に寄りがちだけれど、実際の現場では小さな修正が雪だるま式に増えていく。しかも、その一つ一つが地味にあいまいで、雑に投げると別の場所まで触られる。この記事はそこをかなり正直に見ている。 特に腑に落ちたのは、全部を一つのセッションに押し込まない判断だ。コンテキストが長くなると、モデルは当然つらくなるし、人間側も何がどこで決まったか追いにくくなる。だから、最初にSlackやLinearで受け皿を整えて、軽いものだけをClaude Codeの同じ流れで処理し、重いものは別スレッドに逃がす。これは派手さはないけれど、現実的だと思う。AIを入れた瞬間に「全部速くなる」はず、ではなくて、むしろ受付・仕分け・確認の設計がないと詰まる、という話に見えた。 もう一つ印象に残ったのは、HTML reportを何度も挟むところだ。人間が確認しやすい形にわざわざ整えるのは、少し回り道
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の症状を見分ける
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の症状を見分ける
まず、自分のケースかどうかを切り分けます。今回の症状は、Claude Code の画面やログで `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` という文言が出るものです。報告されている 2 件の issue は、どちらもこのエラー文字列を伴っていました。([#89631](https://github.com/anthropics/claude-code/issues/89631), [#89615](https://github.com/anthropics/claude-code/issues/89615)) ひとつ目の報告では、scaling issue を解こうとしていたら Fable 5 が誤ってフラグを立てた、と書かれています。もうひとつは、組織の monthly spend limit の表示が daily limit の状況と食い違っていて、`/usage-credits` を促す文言が出た、という内容です。つまり、少なくともこの issue 群では、まったく同じエラー表
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の件で、まず自分の症状かを見分ける
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の件で、まず自分の症状かを見分ける
この症状は、Issue に載っているエラーメッセージがかなり特徴的です。検索用にそのまま書くと、`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` です。 手元で確認できたのは、少なくとも次の 2 件の報告が同じクラスタに入っていることです。どちらも open のままで、解決済みの報告ではありません。 どちらの issue でも、報告されたエラーは同じ形です。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=1340 messages=1339 range=[1307,1340)) at kQS (B:/~BUN/root/src/entrypoints/cli.js:23006:8181) at Yrm (B:/~BUN/root ``` ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages
papoo.work
`Error: Streamable HTTP error: Error POSTing to endpoint: {"t` で止まるときにまず見ること
`Error: Streamable HTTP error: Error POSTing to endpoint: {"t` で止まるときにまず見ること
この症状で報告されているのは、Claude Code が MCP server への POST に失敗し、返ってきた応答が `403 Forbidden` になっているケースです。手元で確認できた issue はどちらも同じ断片を含んでいました。 ```text Error: Streamable HTTP error: Error POSTing to endpoint: {"type":"error","error":{"type":"permission_error","message":"MCP server returned 403 Forbidden. The request may have been blocked by a firewal ``` ```text Error: Streamable HTTP error: Error POSTing to endpoint: {"type":"error","error":{"type":"permission_error","message":"MCP server returned 403 Forbidden. T
papoo.work
`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出たときに確認したいこと
`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出たときに確認したいこと
この症状は、Issue 上では少なくとも 2 件まとまっていて、どちらも未解決です。[#85847](https://github.com/anthropics/claude-code/issues/85847) は legacy codebase の reverse engineering 中に fallback model のメッセージが出たあと、`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=36 messages=35 range=[0,36))` に落ちています。[#87169](https://github.com/anthropics/claude-code/issues/87169) でも、通常で安全なプロンプトだと報告されているセッションで同系統のエラーが出ており、`keys=50 messages=49 range=[0,50)` というズレが記録されています。 まず、この文字列が見えていて、しかも途中でセッションが不自然に止まるなら、同じ症状クラスタの可能
papoo.work
`TypeError: Cannot destructure property 'preloadScripts' of '` が出るときに見るべきこと
`TypeError: Cannot destructure property 'preloadScripts' of '` が出るときに見るべきこと
この症状は、少なくとも今回参照した 2 件の issue では、Claude Desktop の起動直後に落ちる系の話として報告されています。1 件は Windows/MSIX 版で、起動後 1.5〜10 秒ほどで main process が自分で終了し、`exit code -1 (0xFFFFFFFF)` になったというものです [#86535](https://github.com/anthropics/claude-code/issues/86535)。もう 1 件は Windows 版で、renderer の bootstrap 周りや sessions-bridge、`claude.exe` の子プロセスに関する不調が並んでいます [#79846](https://github.com/anthropics/claude-code/issues/79846)。 ただし、手元で確認できている一次情報は Windows ではありません。実際に取得できたのは Linux 上の Node.js バージョンだけです。 ```text $ node --version v16.15.
papoo.work
`auto-update failed` が消えないときに見たこと
`auto-update failed` が消えないときに見たこと
`auto-update failed` の表示が出ても、実際には壊れていないケースがあります。少なくとも issue [#82408](https://github.com/anthropics/claude-code/issues/82408) と [#89286](https://github.com/anthropics/claude-code/issues/89286) では、背景の自動更新が一度失敗したあと、その失敗表示が残り続ける挙動が報告されています。しかも `claude doctor` を実行しても「No installation issues found」と返り、表示されている警告と実態が一致しません。 読者がまず確認したいのは、今見えている `auto-update failed` が「本当に更新失敗中」なのか、「過去の失敗記録が残っているだけ」なのかです。issue の報告を見る限り、この切り分けが重要です。[#82408](https://github.com/anthropics/claude-code/issues/82408) では、失敗時の状態が `
papoo.work
`Claude Code returned an error result: No conversation found with session ID` が出るときに、まず見るところ
`Claude Code returned an error result: No conversation found with session ID` が出るときに、まず見るところ
このエラーを追っていくと、少なくとも issue 上では「どのセッションを開こうとしているか」で挙動が分かれています。 `[#61726](https://github.com/anthropics/claude-code/issues/61726)` では、Cursor の Claude Code extension で Web タブに並んだセッションをクリックすると失敗し、Local タブのセッションは開ける、と報告されています。 `[#79924](https://github.com/anthropics/claude-code/issues/79924)` では、VS Code extension の `/memory` パネルで refresh を押したときに、同じ文言のエラーが出ています。 `[#85892](https://github.com/anthropics/claude-code/issues/85892)` では、VS Code extension が閉じられて再度開かれるたびに、空の local session stub が増えていく現象が
papoo.work
`Tool execution failed` が出るとき、まず見るべき切り分け
`Tool execution failed` が出るとき、まず見るべき切り分け
`Tool execution failed` という表示だけでは、原因は1つに絞れません。今回確認できた issue 報告では、少なくとも次の2種類が混ざっています。ひとつは、MCP サーバーに tool 呼び出し自体が届いていないケース。もうひとつは、特定の tool だけが失敗するケースです。 たとえば [#79926](https://github.com/anthropics/claude-code/issues/79926) では、Claude Desktop のローカル stdio MCP サーバーで `initialize` と `tools/list` は通るのに、`tools/call` がサーバーの stdin に一切書かれないと報告されています。画面上は `Tool execution failed` あるいは `Failed to call tool` になります。一方で、同じ症状群の [#69642](https://github.com/anthropics/claude-code/issues/69642) では Gmail MCP の `search_
papoo.work
`claude native binary not installed.` が出るときにまず見るところ
`claude native binary not installed.` が出るときにまず見るところ
この症状は、少なくとも報告されている範囲では Termux / Android と、macOS 上での npm グローバルインストールまわりの2系統に分かれていました。どちらも、`claude` を起動したときに 「native binary が見つからない」 形で止まります。ただし、解決済みの共通パターンはまだ見えていません。 Android 側の報告は [#50270](https://github.com/anthropics/claude-code/issues/50270) です。ここでは、v2.1.113 以降で Claude Code が JavaScript のエントリポイントから glibc のネイティブ Linux バイナリに切り替わり、Termux では動かなくなったと書かれています。報告者は、v2.1.112 は動くが v2.1.113 と v2.1.114 は壊れると述べています。 macOS 側の報告は [#84224](https://github.com/anthropics/claude-code/issues/84224) です。こちらは別の
papoo.work
`claude-opus-4-8 is temporarily unavailable, so auto mode cannot determine the safety of Bash right now` が出たときに見えていること
`claude-opus-4-8 is temporarily unavailable, so auto mode cannot determine the safety of Bash right now` が出たときに見えていること
この文字列が出ているなら、少なくとも今の Claude Code は「auto mode で Bash の安全判定をしたいが、`claude-opus-4-8` が一時的に使えない」と判断しています。ここで大事なのは、エラーそのものよりも、Bash の扱いが auto mode による安全判定待ちで止まるという点です。 ただし、原因が一つに決まるわけではありません。公開 issue では、長いセッションやコンテキスト圧縮のあとにモデルが不自然な出力をした報告と、`ANTHROPIC_BASE_URL` 配下で auto-mode の safety classifier がその endpoint に向くという報告が別々に出ています。前者は [#74136](https://github.com/anthropics/claude-code/issues/74136)、後者は [#78372](https://github.com/anthropics/claude-code/issues/78372) です。どちらも、少なくとも「auto mode の内部で何かがうまくいっていな
papoo.work
`jq` がないと valid JSON を invalid 扱いする
`jq` がないと valid JSON を invalid 扱いする
この症状は、Claude Code の hook 開発用スクリプト `plugin-dev/skills/hook-development/scripts/test-hook.sh` を使っていて、入力 JSON は正しいはずなのに「invalid JSON」と言われるケースです。issue [#83802](https://github.com/anthropics/claude-code/issues/83802) では、`jq` がインストールされていない環境でこの誤判定が起きると報告されています。 まず切り分けたいのは、入力そのものが壊れているのか、それとも `jq` の不足が原因なのか、です。報告内容では、`jq` がないと次の判定が走ります。 ```bash if ! jq empty "$TEST_INPUT" 2>/dev/null; then echo "❌ Error: Test input is not valid JSON" ``` `2>/dev/null` によって `jq: command not found` が捨てられるため、コマンドが見つからない場合
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見つけたら、まず見るところ
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見つけたら、まず見るところ
このエラー文字列が出ているなら、少なくとも報告されている症状群は同じです。Issue では [#87283](https://github.com/anthropics/claude-code/issues/87283) と [#88158](https://github.com/anthropics/claude-code/issues/88158) の 2 件で、どちらも `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が添えられていました。前者は「最初に当たったものだけを見て止まる」「十分に確認しない」といった挙動、後者は `update_document` の patch mode が checkbox list の後ろの内容を静かに落とす、という報告です。 ただし、どちらの issue も解決済みではありませんでした。代表 issue 側に付いていたコメントは、再現手順がまだ必要で、必要なら新しい issue を開いてほしいという趣旨でした。つまり、現時点では「これで直る」と言
papoo.work
ERR_ABORTED が出るときに、まず見るべき 2 つの Claude Code 事例
ERR_ABORTED が出るときに、まず見るべき 2 つの Claude Code 事例
`ERR_ABORTED` は同じ文字列でも、報告されている中身がかなり違います。今回の issue 群では、少なくとも 2 パターンありました。ひとつは Claude Cowork 連携で artifact を作った直後に表示と共有が失敗する件、もうひとつは Claude in Chrome の `read_network_requests` が中断された通信に対して HTTP 503 を作って見せてしまう件です。 自分のケースかどうかを先に見分けるなら、最初にこの 2 点を切り分けるのが早いです。artifact 作成直後に失敗しているなら [#61571](https://github.com/anthropics/claude-code/issues/61571) に近いです。ネットワークの読み取り結果として 503 が返ってくるなら [#77841](https://github.com/anthropics/claude-code/issues/77841) に近いです。 この issue は closed ですが、本文にある通り「artifact 生成直後に表示できない」
papoo.work
`Error: 401 {"type":"error","error":{"type":"authentication_e` で止まるときに見ること
`Error: 401 {"type":"error","error":{"type":"authentication_e` で止まるときに見ること
そのエラーが出ていて、Claude Code の操作が途中で止まるなら、この件の報告とかなり近い可能性があります。Issue の本文では、ツールが指示に従わない、独自判断を始める、といった見え方で困っていましたが、実際に載っているエラーは同じでした。 引用できる一次情報は、報告されたエラー文字列です。 ```text Error: 401 {"type":"error","error":{"type":"authentication_error","message":"Invalid authentication credentials"},"request_id":"req_011CbsmtzJamMBn7jbsWoJnJ"} ``` 同じ症状として挙がっていた issue は [#68571](https://github.com/anthropics/claude-code/issues/68571) と [#68427](https://github.com/anthropics/claude-code/issues/68427) です。どちらも closed で、代表 iss
papoo.work
The socket connection was closed unexpectedly. For more info が出るときに見ておきたいこと
The socket connection was closed unexpectedly. For more info が出るときに見ておきたいこと
この症状は、少なくとも今回渡された issue では 2 つの顔を持っています。ひとつは、`--help` を付けたつもりのコマンドが実行されてしまったケース、もうひとつは、小さなファイルを読んでいる途中で CLI が長時間止まり、最後に `Request timed out.` を伴って落ちるケースです。どちらも共通して、表に出るのは `The socket connection was closed unexpectedly. For more information, pass \`verbose: true\` in the second argument to fetch()` というエラーです。 まず、自分のケースがどちらに近いかを切り分けます。 `--help` を付けたのに「説明だけ表示される」はずのコマンドが実際に動いてしまったなら、[#61285](https://github.com/anthropics/claude-code/issues/61285) が近いです。報告では `sfltool resetbtm --help` を実行したところ、`--help`
papoo.work
返答を短くさせたいなら、先に分量の上限を伝える
返答を短くさせたいなら、先に分量の上限を伝える
長文を投げておいて「要点だけ返せ」は、だいたい伝わりきらない。Claude Code でも同じで、先に分量の上限を決めておかないと、返答は平気で膨らむ。短くまとめさせる、要点だけ返させる、という使い方をしたいなら、最初に「何行まで」「何文字まで」「箇条書き何点まで」を入れておくのがいちばん効く。 これはコードの相談だけの話ではない。ファイル整理の相談でも、文書の下書きでも、ディスク削減の手順でも、先に制限を言うだけで返答の密度が上がる。逆に、あとから「もっと短く」と言い足すと、すでに出した長文を削る作業が発生して、無駄が増える。 たとえば、こう頼む。 ```text 次の内容を、3行以内で短くまとめてください。 要点だけ返してください。前置きは不要です。 ``` Claude Code にコーディングの相談をするなら、もう少し型を決めるといい。 ```text この変更案を、箇条書き3点以内で短くまとめてください。 各項目は1文まで。背景説明は不要です。 ``` 文書作成なら、分量の上限を先に置く。 ```text この文章を、200字以内で要点だけ返してください。 読者が次に取るべき
papoo.work
Markdown か表かを最初に決めると、返答が暴れない
Markdown か表かを最初に決めると、返答が暴れない
Claude Code に雑に「一覧で」「見やすく」で投げると、返答の形が毎回ぶれる。ここを甘く見ると、あとでコピペしづらい、差分が読みにくい、保存したときに壊れやすい、の三重苦になる。先に Markdown で出すのか、表で出すのかを決めておく。要するに出力形式の固定だ。成果物の形を先に決めるだけで、返答はかなり安定する。 この手の話は、エンジニアのコードレビューだけの話ではない。ファイル整理でも、議事録作成でも、請求書の確認でも同じだ。たとえば「重複ファイルの候補を拾ってほしい」と頼むときに、表で返してほしいのか、Markdown の見出し付きで返してほしいのかが曖昧だと、途中で形式が変わる。そうなると人間の目でも扱いにくいし、次の工程に渡しづらい。 筆者も最初はここで何度も手戻りした。Markdown のつもりで頼んだのに、途中から表が混ざる。逆に、表で見たかったのに箇条書きが増える。Claude Code は内容をちゃんと理解していても、出力の器が決まっていないと、返し方が揺れることがある。コンテキストを食うわけではないが、余計な往復が増える。地味にだるい。 まず、最初に器を決
papoo.work
作業中に持たせるメモは短く、決定事項だけ残す
作業中に持たせるメモは短く、決定事項だけ残す
長い経緯メモを Claude Code に持たせると、だいたいろくなことにならない。読み返すだけでコンテキストを食い、肝心の判断材料が埋もれる。残すべきなのは、途中の雑談ではなく決定事項だ。短い作業メモ、あるいは決定事項の圧縮という発想に切り替えると、作業が急に軽くなる。 Claude Code は会話の流れを踏まえて動く。だからこそ、途中で「ここまで何を決めたか」を短く固定しておくと強い。逆に、経緯をだらだら積み上げると、あとから見返したときに自分でも迷うし、Claude Code も無駄に揺れる。筆者は最初、会議の議事録みたいなメモをそのまま貼っていたが、修正のたびに話が分散して、同じ説明を何度もやり直した。あれははっきり無駄だった。 たとえば、あるフォルダ整理を頼む場面を考える。 悪いメモはこうなる。 ```text 昨日の続きで、あの資料も入っていて、こっちのファイル名も少し変えていて、最初はPDF中心だったけど途中で画像も混ざって、クライアントの都合で表紙の扱いが変わって、たしか社内共有用と提出用で分ける話もあって…… ``` これだと、何が決定で何がただの経緯か分からない。
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の文字列が出たら、まず見るところ
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の文字列が出たら、まず見るところ
この症状は、GitHub Issue 上では少なくとも 2 件まとまっていて、どちらも `[open]` のままで解決済みではありません。報告されているエラーは同じで、`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` です。 該当 issue は [#80676](https://github.com/anthropics/claude-code/issues/80676) と [#80664](https://github.com/anthropics/claude-code/issues/80664) です。 まず、自分のケースかどうかを切り分けます。issue の内容を見ると、単純な表示崩れというより、会話履歴の扱いとモデル側の応答の整合がずれたときに出ているように見えます。`#80676` では FIDO 設定の支援をモデルが拒んだと報告され、`#80664` では 1 回の planning タスクの途中でモデルが切り替わったことに困惑している、と書かれています。どちらの報告にも
papoo.work
`Permission for this action was denied by the Claude Code aut` と出るときに見分けたいこと
`Permission for this action was denied by the Claude Code aut` と出るときに見分けたいこと
この症状は、少なくとも報告上は 2 つの別パターンがあります。ひとつは、auto mode の判定が本来通してよいツール呼び出しを止めるケース。もうひとつは、コンパクション後の文脈を「まだ有効なユーザー指示」とみなしてしまい、その後の呼び出しを拒むケースです。いずれも、ユーザー操作そのものが禁止されているというより、Claude Code 側の自動判定が原因になっています。 まず切り分けの軸は、拒否が「どの場面で」出たかです。長いセッションの途中で自動コンパクションが入った直後なら [#77158](https://github.com/anthropics/claude-code/issues/77158) の報告に近いです。ここでは、auto-mode の safety classifier がコンパクション時の割り込み文を恒久的な指示として扱い、次の正当な tool call を拒否したとされています。報告本文では、`--permission-mode auto` の環境、`claude-opus-4-8` と `claude-fable-5` の両方で再現したと書かれています。
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le で止まるときに見るもの
TelemetrySafeError: VirtualMessageList: itemKeys/messages le で止まるときに見るもの
この症状は、報告されている範囲では `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` で、`keys=174 messages=173` や `keys=473 messages=472` のように、`itemKeys` と `messages` の数が 1 件ずれて落ちています。少なくとも issue [#88908](https://github.com/anthropics/claude-code/issues/88908) と [#88227](https://github.com/anthropics/claude-code/issues/88227) では、同じエラー文字列が出ています。 まず自分のケースかどうかを見るなら、エラーメッセージの中に `VirtualMessageList` と `length desync` が含まれているかを確認します。さらに、スタックトレースに `lGE` や `i8h` が見えていれば、報告された症状と一致しています。`TelemetryS
papoo.work
`Cannot find module '/Users/uditgoenka/Desktop/workspace/social/.claude/hooks/session-state.cjs'` が出るときに見るところ
`Cannot find module '/Users/uditgoenka/Desktop/workspace/social/.claude/hooks/session-state.cjs'` が出るときに見るところ
この症状は、Claude Code のフック実行時に `MODULE_NOT_FOUND` が出て、`session-state.cjs` を探しに行って失敗しているケースです。少なくとも issue [#54743](https://github.com/anthropics/claude-code/issues/54743) では、`PreToolUse:Bash`、`PreToolUse:Read`、`PostToolUse:Bash`、stop hook など複数の hook event で同じエラーが連発し、出力を埋め尽くすが、処理自体はブロックされないと報告されています。 手元で確認できた範囲では、`settings.json` のキー構造は次の状態でした。値は取れていませんが、少なくとも今回の検証環境では該当ファイルが見つかっていません。 ```text ~/.claude/settings.json: (存在しない) /mnt/vda5/git/papoo/newsbot_openai/.claude/settings.json: (存在しない) /mnt/vda5/g
papoo.work
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"The following domains are not accessible to our user agent: ['reddit.com']. Read m と出たときに起きていたこと
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"The following domains are not accessible to our user agent: ['reddit.com']. Read m と出たときに起きていたこと
このエラー文字列が見えていて、Claude Code の動きが不自然に増える、あるいは作業中にモデルが変わったように見えるなら、今回集めた issue 群とかなり近いです。対象になっているのは [#68961](https://github.com/anthropics/claude-code/issues/68961) と [#78780](https://github.com/anthropics/claude-code/issues/78780) です。どちらも報告時に、同じエラー文として `Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"The following domains are not accessible to our user agent: ['reddit.com']. Read more: ...` が添えられていました。 まず見分けたいのは、単発の失敗ではなく、同じエラーが続けて出ているかどうかです。[#68961](https://github.co
papoo.work
前提が変わったら古い指示を捨てて、言い直す
前提が変わったら古い指示を捨てて、言い直す
Claude Code に同じ話を延々と持ち込んでいると、だいたい一回はズレる。古い前提を残したまま「ちょっとだけ追加で」と積み上げるからだ。方針変更の再指示、古い前提を残さない、というのは派手なテクニックではないが、実務ではこれが効く。 たとえば、最初は「このフォルダの重複画像を整理して」と頼んでいたのに、途中で「やっぱり削除は怖いから一覧だけにして」と方針が変わったとする。ここで前の指示を引きずったまま会話を続けると、Claude Code は「削除前提の整理」と「一覧化だけ」を両方気にして、中途半端な出力を返しやすい。これは開発でも文書作成でも同じで、前提が変わったのに古い条件を残すと、やり直しが増える。 やることは単純だ。方針が変わったら、差分だけを足すのではなく、いったん前提を切り替えて言い直す。Claude Code は会話の流れを見て動くので、「さっきの続き」より「今の前提」を明確に渡したほうが強い。 たとえば、こう書き直す。 ```text ここからは前の指示をいったん忘れてください。 前提を変更します。 目的: 重複ファイルの削除ではなく、一覧化だけを行う 禁止事項:
papoo.work
節目で要約を挟ませると、長い会話でも前提が崩れにくい
節目で要約を挟ませると、長い会話でも前提が崩れにくい
長いやり取りほど、Claude Code は勝手に賢くなった気になって崩れる。実際には、途中で前提が抜ける、対象ファイルを取り違える、同じ修正を別名で繰り返す、こういう地味な事故が起きやすい。そこで効くのが途中要約だ。会話を区切って要約させる。節目で一度整理を挟むだけで、どこまで進んだか、何を決めたか、何を残したかが見えやすくなる。 Claude Code は、長い会話を続けるほど文脈をたくさん抱える。便利ではあるが、文脈が増えれば増えるほど「今なにを前提に話しているか」がぼやける。ファイル整理でも、ディスク削減でも、文書作成でも同じだ。最初は「不要ファイルの洗い出し」だったのに、いつの間にか「命名規則の話」へ飛び、最後には「手順書の整形」に話が化ける。人間が手綱を握っていないと、会話は平気で迷子になる。 だから、節目を作る。たとえば、ひとつの大きな作業を終えたら、次の指示を出す前に要約を挟む。途中要約でもいいし、会話を区切って要約させる、でもいい。要は「今までの議論を、後で読んでも使える形で短く固めておけ」ということだ。 実際の頼み方は、こんな形で十分だ。 ```text ここまでの
papoo.work
途中報告の頻度を指定して、黙って進みすぎるのを防ぐ
途中報告の頻度を指定して、黙って進みすぎるのを防ぐ
Claude Code に任せると、気づいたら最後まで走り切っていて、途中の判断材料が消えることがある。これが地味に痛い。途中報告を入れさせる、中間報告を入れさせる、進捗の粒度を決める。この3つをちゃんと使うだけで、勝手に突き進んで戻れなくなる事故をかなり減らせる。 特に、ファイル整理や文書作成みたいな「正解はあるが、途中で見たい」作業では効く。全部終わってから見せられても、そこまでの流れが雑だと手戻りがだるい。最初に報告の頻度を決めておけば、Claude Code は勝手に走る道具ではなく、区切って確認しながら進む相棒になる。 まず押さえるべきなのは、指示は「こまめに見せて」だけでは弱いという点だ。Claude Code は、曖昧な指示だと節目の定義を自分で決めがちだし、その節目があなたの感覚とズレる。だから、何回ごとに、どの単位で、何を報告するのかまで決める。 たとえば、文書のたたき台を作らせるなら、こう書く。 ```text まず作業計画を短く出してから、3段階ごとに途中報告してください。 各途中報告では、今やったこと、次にやること、迷っている点を3行で示してください。 勝手に最
papoo.work
返答の形を先に固定する：Markdown か表かを決めてから頼む
返答の形を先に固定する：Markdown か表かを決めてから頼む
Claude Code に雑に「これを整理して」と投げると、返ってくるものが妙に長い説明文になって、あとで自分が切り貼りする羽目になる。ここで先にやるべきなのは、出力形式を先に決めることだ。Markdown でほしいのか、表でほしいのか、成果物の形を固定してから頼む。これだけで手戻りがかなり減る。 たとえば、ファイル整理でも文書作成でも、欲しいのは「考え方」より「そのまま使える形」だろう。Markdown なら見出しや箇条書きをそのまま草案にできるし、表なら項目ごとの比較や一覧にそのまま流し込める。Claude Code は指示が曖昧だと、親切に見えて実は中途半端な出力を返しがちだ。そこを最初に縛るのが、このTIPSの肝である。 実務では、依頼文の冒頭に形式を明記するだけでいい。たとえばこうだ。 ```text 次の内容を、Markdown の見出し付きで整理してください。本文はそのまま貼れる形にしてください。 ``` Markdown にしたいなら、どこまで機械的に整えてよいかも添えると強い。 ```text 次のメモを Markdown で整形してください。 見出しは h2 相当
papoo.work
長い資料は章ごとに渡して、一気読み前提をやめる
長い資料は章ごとに渡して、一気読み前提をやめる
長い資料をそのまま全部投げるのは、だいたい雑だ。Claude Code は長文でも扱えるが、だからといって「最初から最後まで一気に読んで、全部を一発で直してくれ」で済ませると、要点がぼける。途中で重要な条件を落としたり、修正の軸がぶれたりして、あとで手戻りになる。 ここで効くのが、章分けして渡す、あるいは分割投入だ。資料を見出し単位、章単位、用途単位で切り、順番に渡していく。これだけで、Claude Code が今どこを見ているのかがはっきりする。長い議事録、仕様書、契約書の下書き、マニュアル、散らかった手順書。全部に効く。非エンジニアでも同じだ。ファイル整理のルール文書や、社内向けの手順書を整えるときにもかなり使える。 筆者は最初、長文を丸ごと貼って「要約して、ついでに直して」と頼んでいた。結果は悪くないのに、肝心の制約が抜ける。後から「いや、そこは残すべきだった」と気づいて、もう一回やり直しになる。あれはだるい。章ごとに渡し始めてから、話が戻りにくくなった。 やり方は単純だ。まず資料を人間が読んで、章や役割で切る。次に、各章を別々に扱わせる。たとえば、先に全体方針を固め、その後で各
papoo.work
Anthropic Quietly Moving the Goalposts Again
Anthropic Quietly Moving the Goalposts Again
The annoying part here isn’t even the experiment itself. It’s that the model apparently started interpreting the same effort label differently, server-side, with no obvious changelog note. If you’re building against Claude Code and your prompt or tooling suddenly feels “dumber,” that kind of change is exactly the sort of thing that sends you chasing ghosts in your own code. I’d be more forgiving if this were clearly documented as an experiment and easy to detect. But the whole complaint here is
papoo.work
Claude Codeに欲しかったのは「賢さ」より先にブレーキだった
Claude Codeに欲しかったのは「賢さ」より先にブレーキだった
この記事を読んでまず思ったのは、AIに本当に足りないのは推論力じゃなくて、雑に動かないための仕組みなんだな、ということだった。Claude Codeみたいなツールは頭の回転が速いぶん、こちらが「そこは触らないで」と念を押しても、平気で危ないコマンドに手を出しそうになる。その不安を、フックという形で機械的に塞ぐ発想はかなり筋がいい。 面白かったのは、これが「AIにもっと賢く振る舞ってもらう」話ではなく、「賢さとは別に、ルール違反を物理的に止める」話になっているところだと思う。プロンプトで説得するのではなく、`PreToolUse` のようなタイミングでスクリプトが割り込んで止める。ここが大事で、AIの気分に左右されない。人間のレビューより前に、そもそも危ない操作を通さない。かなり地味だけど、実務ではこの地味さが一番効くはずだ。 それと、`.env` や secrets を守る話にも妙に納得した。AIに設定ファイルをいじらせると便利な場面はあるけれど、秘密情報まで一緒くたに触らせるのは怖い。ここは「便利さの代償」をちゃんと見ている記事だと思った。Git の `push --force` や
papoo.work
`VM connection timeout after 60 seconds` が出るときに、まず見たいところ
`VM connection timeout after 60 seconds` が出るときに、まず見たいところ
この症状は、少なくとも GitHub 上では 2 件まとまっていました。ひとつは Snapdragon X 環境での報告、もうひとつは Windows 11 Home の低スペック環境で、アップデート後に Cowork guest が毎回失敗するという報告です。どちらも同じエラー文言です。検索するなら `VM connection timeout after 60 seconds` で十分です。 筆者の環境で確認できた一次情報は、以下だけです。この記事で書けるのは、これ以上でもこれ以下でもありません。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-08-22T08:50:32+09:00 ``` このため、現時点では「特定 OS 固有の不具合」「特定の更新後に増えた不具合」「低スペックや Snapdragon 系の環境で VM まわりが失敗している可能性」は疑えますが、断定はできません。少なくとも、報告済みの 2 件はどちらも「VM
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の症状が出たときに確認したいこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages le の症状が出たときに確認したいこと
この症状は、`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` という文言で報告されています。今回見つかった 3 件の issue は、いずれも open のままで、解決済みは 0 件でした。こちらで確認できた範囲では、まだ「これをやれば直る」と言い切れる情報はありません。 まず、自分のケースかどうかを見分けるなら、エラー本文がどれかに一致するかを見ます。今回の issue では、少なくとも次の形が繰り返し出ています。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=1070 messages=1069 range=[1013,1070)) at A_b (B:/~BUN/root/src/entrypoints/cli.js:14712:8188) at f8p (B:/~BUN/root/src/ ``` 別の報告でも、`keys` と `messages` の数が
papoo.work
Error: 404 {"type":"error","error":{"type":"not_found_error"… が出て Claude Fable 5 が使えないときに確認したこと
Error: 404 {"type":"error","error":{"type":"not_found_error"… が出て Claude Fable 5 が使えないときに確認したこと
この症状は、`not_found_error` の本文に `Claude Fable 5 is not available. Please use Opus 4.8.` と出ているのが手がかりです。報告された issue では、[#68683](https://github.com/anthropics/claude-code/issues/68683) と [#68735](https://github.com/anthropics/claude-code/issues/68735) のどちらも同じエラー文字列でした。どちらも closed になっており、代表 issue 側では重複候補の案内も出ています。 実際の報告文に含まれていたエラーは、少なくとも次の形でした。 ```text Error: 404 {"type":"error","error":{"type":"not_found_error","message":"Claude Fable 5 is not available. Please use Opus 4.8. Learn more: https://ww
papoo.work
This version can't be shared publicly が出るときに見えていること
This version can't be shared publicly が出るときに見えていること
「Share publicly」に切り替えた直後に、`This version can't be shared publicly. Publish a new version or change the shared version, then try again.` が返る。これが出ているなら、少なくとも issue 報告上は、Artifact の公開共有がその版で止まっている状態です。[#79824](https://github.com/anthropics/claude-code/issues/79824) では、Markdown の Artifact を公開しようとしてこの文言が即座に出ています。[#78374](https://github.com/anthropics/claude-code/issues/78374) でも、別の Artifact で同系統の共有エラーが報告されています。 この症状でまず大事なのは、単発の失敗ではなく、再公開しても続くかどうかです。[#79824](https://github.com/anthropics/claude-code/iss
papoo.work
終わった作業を片付ける
終わった作業を片付ける
終わった仕事をそのまま残す人は多い。しかも「あとで見るから」と言いながら、数日後には同じブランチ、同じ作業フォルダ、同じ不要ファイルの山にまた足を取られる。Claude Code はそこを雑に流さず、使い終わった作業場所を整理する、ブランチやフォルダの後片付けまで含めて片づけ役にできる。 ここでやりたいのは大げさな自動化ではない。作業が終わったら、残すものと捨てるものを切り分けて、コンテキストもディスクも空けることだ。これをやらないと、次の依頼で Claude Code が余計なファイルを拾ったり、古い差分に引っ張られたりして、地味に手戻りが増える。 「片付ける」と言っても、全部消せばいいわけではない。残すのは、あとで参照する必要があるものだけだ。たとえば、作業メモ、最終成果物、再利用したいテンプレート、あるいは案件の証跡になる書面だ。消すのは、途中で作った一時ファイル、古い出力、使い捨ての検証フォルダ、役目を終えたブランチだ。 Claude Code には、最初からこの判断を言葉で渡しておくといい。たとえばこんな依頼で十分だ。 ```text この作業が終わったら、後片付けまでやって
papoo.work
試し書きは別場所で済ませる
試し書きは別場所で済ませる
本番のファイルにいきなり書き始める人は、だいたいあとで自分の差分に泣く。Claude Code でも同じで、思いついた指示を確定版に直書きすると、途中の試し書きまで履歴に残って、あとから何が本筋だったのか分からなくなる。 やることは単純だ。下書き専用の場所を作る。確定版に直書きしない。これだけで、Claude Code に考えさせる内容と、最終的に残す内容を分けられる。結果として、コンテキストの無駄遣いが減り、差分も読みやすくなる。ファイル整理でも文書作成でも効く、地味だが効き目の大きい癖だ。 たとえば、案件ごとにこんな構成にしておくと扱いやすい。 ```text project/ draft/ 2026-08-21-notes.md final/ report.md ``` Claude Code には、まず下書き側だけ触らせる。 ```bash claude ``` 依頼文はこんな具合でいい。 ```text draft/2026-08-21-notes.md に、報告書の材料を箇条書きで整理して。 このファイルは下書き専用。本文の確定版には触らないで。 まだ文章は整えなくていい。
papoo.work
ブランチを切る前に整理する
ブランチを切る前に整理する
ブランチを切ってから考える人は、だいたいあとで自分の差分に殴られる。 変更を小さく始める準備、作業開始前の下ごしらえを飛ばすと、Claude Code に渡す文脈が散らかる。すると指示は長くなるし、余計なファイルまで触るし、diff もでかくなる。手戻りの回数が増えるのは、たいていここだ。 Claude Code は、雑な状態でもそれなりに進めてしまう。そこが便利でもあり、危ないところでもある。 だからブランチを切る前に、作業対象を絞り、不要物を片づけ、今から何をやるかを一度だけ言葉にしておく。これだけで、生成される提案の精度がかなり変わる。非エンジニアのファイル整理でも同じだ。案件フォルダ、請求書、原稿、重複画像がごちゃついたまま頼むと、まず整理にコンテキストを食われる。先に片づけるほうが早い。 ブランチ名を考える前に、Claude Code に見せる範囲を狭める。これが一番効く。 巨大なリポジトリ全体を相手にすると、文脈が薄まる。人間でも、机の上に関係ない紙が山ほどあると集中できない。それと同じだ。 作業前にやるのは、この三つで足りる。 1. 今回の目的を一文で書く 2. 触るファ
papoo.work
コンフリクトを増やさない進め方
コンフリクトを増やさない進め方
同じファイルを同時に触らせると、だいたい面倒になる。Claude Code でもそこは変わらない。 「同時に走らせれば速いはず」と思って並列に投げると、diff がぶつかる、指示が食い違う、片方の修正をもう片方が上書きする、で手戻りが増える。やるべきことは単純で、同じファイルを同時に触らせない、衝突しにくい分担にすることだ。 筆者も最初は、複数の作業をまとめて投げてしまっていた。たとえば README と設定ファイルとメモ類を一気に直させる。見た目は速いが、あとで差分を見たら、同じ導入文を別の依頼で微妙に書き換えていたり、設定の文言だけ先祖返りしていたりする。人間が手で整える時間が増えるだけだった。Claude Code は魔法の共有フォルダではない。分担設計が雑だと、普通に詰まる。 一番効くのは、最初に「どの作業がどのファイル群を触るか」を切ることだ。Claude Code に渡す依頼も、ここを先に固定する。たとえば文書整理なら、章の並べ替え担当と誤字修正担当を分けない。どちらも同じ本文を触るからだ。先に構成を固め、そのあとで表記や体裁を直す順番にする。 ```text この作業では
papoo.work
別作業の成果を混ぜない
別作業の成果を混ぜない
Claude Code を使っているのに、あとで「このファイル、誰の仕事の途中だっけ」となるなら、だいたい混ぜすぎだ。 一時ファイルと成果物を分離する。作業途中のゴミを残さない。ここを雑にすると、ディスクはじわじわ減るし、差分は読みにくくなるし、別件の作業まで巻き込む。筆者も最初はよくやった。資料を整えてほしいだけなのに、途中生成したメモ、抽出結果、古い版が同じ場所に積もって、どれが納品物か分からなくなった。Claude Code は賢いが、置き場が曖昧だと平気で曖昧なまま積む。そこを人間が締める必要がある。 この話は開発だけの話ではない。文書作成、議事録整理、案件ごとのファイル整頓、画像やCSVの一時処理でも同じだ。成果物は成果物、一時物は一時物。まずこの線を引く。 一番やりやすいのは、作業ディレクトリを最初から分けることだ。案件単位、目的単位でフォルダを切り、途中の派生物はその中の一時置き場に閉じ込める。たとえば、原稿を磨くなら入力、作業中、完成版を分ける。不要なら一時置き場ごと消せる。これだけで後始末がかなり楽になる。 ```text project/ input/
papoo.work
案件ごとにディレクトリを分けて後から探しやすくする
案件ごとにディレクトリを分けて後から探しやすくする
同じ場所に全部ぶち込んで、あとから「どれがどの案件の資料だっけ」と探し回る。これ、かなり雑に見えて、実は一番コストが高い整理不足だ。Claude Code を使うなら、案件フォルダを切る、整理用の置き場を分ける、という発想に早めに寄せたほうがいい。そうしておくと、後から資料を拾いやすいし、生成した文書の差し替えや見直しも楽になる。 特に、文章作成や書類整理で Claude Code を使う人は、「ひとつの作業にひとつの場所」を作るだけで手戻りが減る。フォルダ名を見れば中身の当たりがつく状態にしておく、ただそれだけで探す時間が消える。雑に見えるけれど、効く。 Claude Code でやることは単純だ。案件ごとのディレクトリを先に作り、その中で入力資料、下書き、出力を分ける。散らかった作業場を毎回片づけるより、最初から箱を分けたほうが早い。 たとえば、こんな形にしておく。 ```bash projects/ 2026-01_契約書見直し/ 00_inbox/ 01_materials/ 02_drafts/ 03_output/ notes.md 2026-01_請求書整理/ 00_in
papoo.work
同じリポジトリで複数案を並走させる
同じリポジトリで複数案を並走させる
「1つの作業場所で少しずつ直せばいい」と思っていると、だいたい途中でぐちゃる。 Claude Code でも同じで、案を分けて試すなら、同じリポジトリの中で作業場所を分けて走らせるほうが圧倒的に扱いやすい。別作業場所で比較する、案を分けて試す、というやり方だ。 ここでの狙いは単純で、A案とB案を同時に触って、あとから見比べることだ。たとえば文書の章立てを2通り試す、ファイル整理のルールを2案作る、コード修正の方針を2つ並べて判断する。ひとつの案をいじっては戻し、またいじっては戻し、をやるよりずっと速い。しかも「どっちがよかったか」を diff で見やすい。 Claude Code は会話の文脈を使って作業するので、ひとつのセッションに何案も詰め込むと、途中から話が濁る。最初は筋がよくても、後半で別の方針が混じって、結局どれも中途半端になる。筆者は以前、1つの作業場所で「案Aの文面」「案Bの文面」「やっぱり章の順番も変更」を全部口頭でやって、最後にどれが本命か自分でもわからなくなった。あれは時間の無駄だった。分けておけば済んだ話だ。 やり方は難しくない。肝は、同じリポジトリを複製して別デ
papoo.work
本番用の作業と試作品を分ける
本番用の作業と試作品を分ける
本流を汚しながら試す人は、だいたい後で自分に殴られる。Claude Code は便利だが、便利なぶん、確定版のファイルにそのまま触らせると面倒が一気に増える。試し書きと確定版を分離する、つまり本番用の作業と試作品を分けるだけで、手戻りも差分の読みづらさもかなり減る。 ここで言う「本流を汚さない作業場所」は、要するに本番の原稿やデータとは別に、試すための場所を最初から切り出しておくことだ。Claude Code に新しい案を書かせるなら、いきなり本番ファイルをいじらせず、試作品用のディレクトリや複製ファイルで先に遊ばせる。これだけで、気軽に試して、納得したものだけを本番へ戻せるようになる。 たとえば文書作成なら、こんな分け方がわかりやすい。 ```bash project/ draft/ final/ ``` `draft/` は試作置き場、`final/` は確定版だ。Claude Code に対しては、最初からこう頼めばいい。 ```text draft/ にある原稿だけを使って、見出しの整理案を3つ出してください。 final/ のファイルは触らないでください。 必要なら draf
papoo.work
Claude Code に触らせる場所を先に決める
Claude Code に触らせる場所を先に決める
Claude Code を使い始めた人が最初にやりがちな失敗は、いきなり「このへん全部見て、いい感じにやって」と雑に投げることだ。これ、かなり危ない。作業フォルダを先に固定する、触らせる範囲を狭める。たったこれだけで、コンテキストの浪費と事故の確率が目に見えて下がる。 Claude Code は賢いが、置き場所が曖昧だと平気で話が広がる。広がるだけならまだいい。関係ないファイルを読んで、関係ない変更案を出して、最後に差分がやけに大きくなる。筆者は最初、ルートディレクトリでうっかり作業を始めて、ログや生成物まで拾わせてしまい、肝心の修正に入る前にコンテキストを食い潰した。あれはだるかった。先に「ここだけ触る」を決めるだけで、かなりマシになる。 やることは単純だ。Claude Code を起動する前に、作業対象のフォルダに移動してから始める。例えば、1 つの案件だけ、1 つの文書だけ、1 つの整理対象だけを置く場所を先に決める。 ```bash cd ~/work/project-a claude ``` これだけでも効く。要は、Claude Code に見せる世界を狭めるわけだ。コードな
papoo.work
別作業場所を切って本流を汚さず試す
別作業場所を切って本流を汚さず試す
新しい指示をいきなり今の作業フォルダで試すと、だいたいろくなことにならない。差分が混ざる、途中のメモが散る、戻したいのに戻しにくい。Claude Code でやるなら、まず別作業場所を切って本流を汚さず試す。安全に試すための作業場を分ける、本番と検証を分離する、という考え方だ。 これをやると何がいいか。ひとつは、失敗しても本体を壊しにくいこと。もうひとつは、Claude Code に「この場ではこの作業だけ」と集中させやすいことだ。会話の流れも、ファイルの変更範囲も、ぐっと整理される。筆者は最初、いつものディレクトリでそのまま頼んで、関係ないファイルまで触られて手戻りした。あれは地味に痛い。作業場が分かれていないと、どこまでが試行でどこからが成果物か、すぐに曖昧になる。 やり方は単純で、元のリポジトリやフォルダをそのまま触らず、複製か別ブランチ、別ディレクトリで試す。Claude Code には、その作業場の中だけを見せればいい。 たとえばコードの修正なら、まず git の作業ツリーを複製して、そこで試すやり方が扱いやすい。 ```bash git clone /path/to/rep
papoo.work
3D制作ソフトが、ついに「人に触らせる場所」ではなくなった
3D制作ソフトが、ついに「人に触らせる場所」ではなくなった
正直、この記事でいちばん引っかかったのは、「3D editorをAI agentに渡す」という発想そのものです。コード生成だけならまだ想像しやすいのに、3D sceneの編集まで行かせるとなると、話はかなり変わる。画面上のオブジェクトを置く、動かす、見た目を変える。そういう作業は人間が手でやるもの、という感覚がまだ強いからです。 でも逆に言うと、そこまでいくと“AIに任せられる仕事”の輪郭が少し見えてくる気もしました。単に文章やコードを吐くのではなく、実際の編集環境の中で、既存の資産を理解しながら触る。MCPみたいな接続の仕組みがあると、agentは外から命令を出す存在ではなく、エディタの中に入ってくる作業者になる。これはかなり大きい変化だと思います。 ただ、便利さの裏でちょっと怖さもある。3D editorは、見た目の結果がそのまま品質に出る世界です。コードなら差分を読めば済む場面でも、3Dだと配置や光、奥行きのズレが一気に体験を壊す。つまり、agentが触れる範囲が広がるほど、検証の重要性も増すはずです。記事の文脈でも、ただ「使える」だけでなく、実際にどこまで信頼できるのかが気にな
papoo.work
AIに「代わりに書かせる」より、使い方を先に固める話
AIに「代わりに書かせる」より、使い方を先に固める話
この記事を読んでまず思ったのは、やっぱりAIコーディングは「魔法の便利機能」ではなく、運用の話になってきたんだな、ということだった。Claude Codeそのものの出来よりも、どう使うか、誰がどこまで触っていいか、どの環境に載せるかのほうが重くなっている。ここが地味だけど本質だと思う。 特に引っかかったのは、「Claude Codeが強い」という話の隣で、結局は企業が使うならガバナンスや権限管理が先に来る、という空気がはっきりしていたところ。サブエージェントとかコンテキストロットみたいな話は、個人の開発だと「へえ、賢そう」で済む。でも組織に入ると、勝手に触られたくない領域、レビューの責任、トークンやコストの扱いが一気に現実になる。AIがコードを書く速度より、その周辺の調整のほうが遅い。そこはかなり実感がある。 それと、記事の中で「2年で2か月に短縮」といった話が出てくるのも、少しだけ怖い。実際、AI導入の速度感はそういうふうに見えるのだろう。ただ、短縮されたのがPoCの立ち上げなのか、本番運用なのかで意味は全然違う。そこは記事だけでは見えにくいし、むしろ知りたかった。AIがすごい、とい
papoo.work
Claude Code が `exit code 3` で落ちるときに見えていること
Claude Code が `exit code 3` で落ちるときに見えていること
自分のケースかどうかを先に切り分けるなら、今回集められている issue はどれも「Claude Code のプロセスが途中で死んで、結果として `exited with code 3` と見える」点は共通です。ただし、落ちるタイミングと見えているクラッシュ住所が違います。 たとえば、[#78436](https://github.com/anthropics/claude-code/issues/78436) は、Windows 11 上の Claude Code desktop session が約 30 分後に死んだ報告です。本文では `Elapsed: 1817103ms` とあり、Bundled された `claude.exe` が次のように panic しています。 ```text panic(main thread): Segmentation fault at address 0xFFFFFFFFFFFFFFFF ``` この issue の報告では、「起動直後ではなく、セッションがしばらく動いたあとに落ちた」点がはっきりしています。しかも、同じ `0xFFFFFFFF
papoo.work
試し書きは別場所で済ませる：下書きと確定版を分離する
試し書きは別場所で済ませる：下書きと確定版を分離する
その場でいきなり本番ファイルを触るから、あとで余計な手戻りが出る。Claude Code を使うときは、下書き、確定版、ドラフトをちゃんと分けたほうがいい。ここを雑にすると、内容も差分も散らかるし、何を直したのか追いにくくなる。 たとえば文書作成でも、ファイル整理でも同じだ。最初の試し書きは別の場所で済ませて、固まってから本番に反映する。Claude Code は会話の流れを保ったまま編集できるので、思いつきの修正までそのまま本番へ流し込みやすい。便利だが、便利すぎるせいで事故る。 筆者も最初は、既存の原稿を開いたまま「ちょっとだけ整えて」と頼んで、気づいたら段落の順番までいじられていた。人間なら「ここはまだ仮」とわかるところでも、曖昧な指示だとそのまま確定扱いになる。下書きと確定版を分けるだけで、この事故はかなり減る。 やり方は難しくない。まず、作業用の場所を決める。たとえば案件ごとのフォルダを切って、そこに試し書き用のファイルを置く。完成したら、確定版だけを本番の場所にコピーする。Claude Code に頼むときも、最初から「このファイルはドラフト」「最後に確定版へ反映」と言い切
papoo.work
案件ごとにディレクトリを分けて、後から探しやすくする
案件ごとにディレクトリを分けて、後から探しやすくする
ごちゃつく人は、だいたい最初から全部を同じ箱に入れる。Claude Code でもそれをやると、あとで自分が掘り返す段階で詰まる。案件フォルダ、整理用フォルダ、分類ルールを先に決めておくと、ファイルが散らからないだけでなく、AI に任せるときの指示もかなり通りやすくなる。 Claude Code は会話の流れで作業を進める道具だが、見えている作業場所が曖昧だと、出力の置き場も曖昧になる。すると、レポート、下書き、画像、メモ、不要な一時ファイルが同じ階層に混ざる。これは後で探すのが面倒なだけではない。差分も見づらいし、どれを残すか判断しにくい。筆者は最初、案件名だけを雑に付けて全部ひとつのフォルダに押し込んでいたが、1か月後に「どれが最終版だっけ」で普通に迷子になった。あれは地味にだるい。 やることは単純で、案件ごとにルートフォルダを切る。中は用途で分ける。これだけでいい。たとえば文章作成なら、案件ごとに `input`、`draft`、`final`、`reference` を分ける。ファイル整理なら、`to_sort`、`keep`、`remove_candidate`、`archi
papoo.work
コンフリクトを増やさない進め方：同じファイルを同時に触らせない
コンフリクトを増やさない進め方：同じファイルを同時に触らせない
同じファイルを何人にも同時編集させて、あとでコンフリクト地獄に落ちる。これ、かなりありがちな失敗だ。Claude Code を使うときも同じで、便利だからこそ雑に並列化すると、差分が膨らみ、直す側がだるくなる。 競合回避、同時編集、衝突防止。この手の話は、結局「同じファイルに手を入れる人数を絞る」に尽きる。Claude Code に仕事を振るなら、最初からファイルの担当範囲を切っておくほうが早い。あとで diff を追いかけるより、最初の分け方に少し気を遣ったほうが、全体の時間は確実に減る。 筆者も最初は、複数のタスクを雑に並べて投げていた。結果、同じ README と設定ファイルを別々の指示でいじらせて、手戻りした。Claude Code 自体が悪いわけではない。指示の切り方が雑だと、当然こうなる。 Claude Code に頼むときは、タスクの粒度を「機能」ではなく「触るファイル」で考えると事故が減る。たとえば、ドキュメント整理なら「このフォルダ配下の Markdown だけ」「不要ファイルの洗い出しだけ」と切る。コード修正なら「このモジュールだけ」「この設定ファイルは触らない」と
papoo.work
別作業の成果を混ぜない：一時ファイルと成果物の置き場を分ける
別作業の成果を混ぜない：一時ファイルと成果物の置き場を分ける
雑に作業を始めると、あとでいちばん困るのは「何が途中で、何が完成か分からなくなる」ことだ。Claude Code でも同じで、一時ファイルと成果物を同じ置き場に放り込むと、差分は汚れるし、次の作業で前回のゴミまで拾う。地味だが、かなりだるい事故になる。 ここで分けたいのは単純だ。作業中だけ使う一時ファイル、最終的に残す成果物、そしてそれらを置く置き場。この3つを曖昧にしないだけで、Claude Code に頼む内容がはっきりするし、ディスク掃除も楽になる。非エンジニアでも効く。たとえば書類整理や文章作成でも、下書きと納品物を同じフォルダに混ぜると、あとで自分が混乱するだけだ。 まず、置き場を先に分ける。Claude Code に最初から「作業用」と「提出用」を別に扱わせるのがコツだ。 ```text この作業では、次の2つを分けて扱ってください。 一時ファイル: 作業中だけ使う下書き、途中生成物、変換途中のファイル 成果物: 最後に残すファイル、提出するファイル、保存しておく完成版 ルール: 一時ファイルは work/ に置く 成果物は out/ に置く work/ の中身は完成品とし
papoo.work
ブランチを切る前に整理する：変更を小さく始める準備
ブランチを切る前に整理する：変更を小さく始める準備
ブランチを切ってから整理しようとすると、だいたい面倒になる。差分が増え、指示があいまいになり、Claude Code に投げる文面まで雑になるからだ。先に片づける。これを事前整理、着手準備、分割開始の土台づくりとしてやっておくと、変更は小さく始めやすい。 Claude Code は、いきなり「全部直して」と投げるより、対象を絞ったほうが働きやすい。非エンジニアの作業でも同じで、フォルダの山、重複ファイル、長文の資料、散らかったメモを先に整えるだけで、次の一手がかなり軽くなる。ブランチを切る前の整理は、気合いの話ではない。後戻りを減らすための実務だ。 まずやることは単純だ。作業対象を一つに絞る。アプリのコードなら、機能追加なのか、文書修正なのか、不要ファイル削除なのかを分ける。文書作成なら、原稿を整えるのか、章立てを直すのか、語尾をそろえるのかを分ける。ここが混ざると、Claude Code への依頼が一気に濁る。 たとえば、次の順で始めるといい。 1. 触る場所を1つに決める 2. その場所にある不要物を先に外す 3. 変更したい目的を短く書く 4. そこで初めてブランチを切る、または
papoo.work
Claude Code に触らせる範囲を狭める：作業フォルダを先に決める
Claude Code に触らせる範囲を狭める：作業フォルダを先に決める
Claude Code に何でも見せると、だいたい雑になる。人間でもそうだが、道具も広すぎる作業範囲を渡すと、余計なファイルまで見に行って、指示の解像度が落ちる。 だから先に作業フォルダを決める。対象フォルダ、作業領域、作業範囲を絞る。これだけで、読み違いも、関係ない差分も、やたら長い往復も減る。 筆者は最初、リポジトリのルートをそのまま渡して「この周辺を整えて」と投げたことがある。結果は見た目以上にだるかった。README、設定ファイル、試作メモ、昔の検証コードまで混ざった場所を見せたせいで、Claude Code が「どれを本当に触るべきか」を拾うのに余計な時間を食い、修正も散った。 逆に、最初から一つのフォルダを決めておくと話が早い。触っていい場所がはっきりするので、提案も差分も小さくなる。これはエンジニア作業でも、書類整理でも、原稿整備でも同じだ。 やることは単純だ。Claude Code を起動する前に、先に作業フォルダへ移動してから始める。 ```bash cd ~/Documents/案件A claude ``` あるいは、最初の依頼文で対象をきっちり言う。 ```tex
papoo.work
同じリポジトリで複数の案を並走させる：作業場所を分けて比較する
同じリポジトリで複数の案を並走させる：作業場所を分けて比較する
それ、ひとつの作業場所で全部いじるから、あとでどれが良かったのか分からなくなるのだ。 Claude Code を使うときも同じで、雑に一案ずつ上書きしていると、比較検討どころか「前の案、どこへ行った」となる。並走作業をちゃんとやるなら、同じリポジトリでも作業場所を分ける。これだけで、複数案を並べて見比べやすくなり、手戻りも減る。 この手は、開発だけの話ではない。文書の言い回しを3案出したいとき、ファイル整理の方針を2通り試したいとき、不要ファイルの削減手順を安全側と攻め側で比べたいときにも効く。要は、Claude Code に「同じ土台で別の案を別々に育てさせる」やり方だ。 やり方は単純だ。リポジトリを複数の作業場所に分ける。Git を使っているなら、同じ履歴を保ったまま別ディレクトリを並べる `git worktree` がいちばん扱いやすい。別のフォルダにコピーしても動くが、重くなるし、うっかり片方だけ更新して混乱しやすい。比較したいなら、土台は同じで、作業場所だけ分けるほうがいい。 たとえば、メインの作業場所があるリポジトリで、2案を並走させるならこうする。 ```bash gi
papoo.work
本番用の作業と試作品を分ける：失敗しても戻しやすい置き方
本番用の作業と試作品を分ける：失敗しても戻しやすい置き方
本番の作業と試作品をごちゃ混ぜにする人は、だいたいあとで泣く。ファイルが増えたとき、どれが完成版でどれが実験用コピーなのか分からなくなり、戻したいのに戻せない。Claude Code を使うなら、ここを先に分けておくべきだ。退避先、検証用コピー、実験用コピーを最初から用意しておけば、雑に試しても本線を壊しにくい。 Claude Code は、雑にいじると便利だが、雑にいじる場所まで雑だとすぐに面倒になる。プロジェクトの本体で直接手を入れる代わりに、作業用の複製を切り出して、そこで試す。これだけで、差分の確認もしやすいし、失敗したときの引き際もはっきりする。 たとえば、文書整理ならこうだ。元のフォルダはそのまま残し、Claude Code には複製側だけを触らせる。 ```bash cp -R project project_trial cd project_trial claude ``` この形にしておくと、Claude Code に「このフォルダを整理して」「重複をまとめて」「古い下書きを退避して」と頼んでも、本体は残る。整理が気に入らなければ、試作品フォルダを捨てればいい。終わっ
papoo.work
Claude Code で別の作業場所を切る：本流を汚さず試す基本
Claude Code で別の作業場所を切る：本流を汚さず試す基本
本流のリポジトリでそのままClaude Codeを走らせて、あとで「あれ、どこまで触ったっけ」となるのは、かなりよくある失敗だ。雑に試すほど差分は太り、戻すのも面倒になる。だから最初から別の作業場所を切る。作業ブランチでもいいし、別ディレクトリでもいい。Gitのworktreeを使えば、同じリポジトリを複数の作業場所に分けて置ける。 これをやると、Claude Codeに試作を任せても本流を汚しにくい。文章修正でも、ファイル整理でも、コードの小改修でも同じだ。ひとつの場所で検討しながら、別の場所では元の状態をきれいに保てる。地味だが、後戻りの手間がかなり減る。 まず押さえるべきなのは、Claude Codeを「本番の作業場」から切り離すことだ。やり方は大きく三つある。作業ブランチを切ってそこで動かす、別ディレクトリに丸ごとコピーして触る、そしてGitのworktreeを使う。この中でいちばん扱いやすいのはworktreeだ。同じGitリポジトリを複数の作業ディレクトリとして並べられるので、片方を本流、もう片方を試作場にしやすい。 たとえば、今いるリポジトリの中身をそのまま壊したくないな
papoo.work
終わった作業を片付ける：使い終わったブランチや作業場所の整理
終わった作業を片付ける：使い終わったブランチや作業場所の整理
終わったのに、作業場所だけが残り続ける。これがいちばん地味で、いちばん効く事故だ。Claude Code を使うと、調査用の分岐や作業ディレクトリをさっと作れるぶん、片付け、後始末、不要な作業場所の整理を後回しにしやすい。すると、次に開いたときに「どれが本線で、どれが捨てていいやつだっけ」と毎回確認する羽目になる。これ、かなりだるい。 この手の整理は、気合いでやるものではない。終わった瞬間に、消すものと残すものをはっきり分けておく。Claude Code はそこを手伝える。ブランチ名や作業フォルダの一覧を見せて、要るものだけ残し、不要なものを消す。文書作成やファイル整理でも同じだ。案件ごとのフォルダ、下書き、差し替え前の版。放っておくとノイズになるものを、作業が終わった段階でまとめて片付けておくと楽になる。 まずは、Claude Code に「何を片付けたいか」をそのまま渡すのが基本だ。曖昧に「整理して」で投げると、残すべきものまで巻き込んで痛い目を見る。たとえば Git のブランチ整理なら、こう頼めばいい。 ```bash claude ``` ```text 使い終わった作業ブラン
papoo.work
意図を合わせる、という地味で大事な話
意図を合わせる、という地味で大事な話
この記事を読んでまず思ったのは、コードを書く速さそのものより、「何を作るつもりなのか」を毎回ちゃんとすり合わせるほうが、今の開発ではむしろ主戦場になってきているんだな、ということでした。Claude Code みたいな coding agent は、雑に言えば“手は速いけど、前提がずれると一気に遠回りになる”存在です。そこをかなり実感のある話として書いていて、そこは素直にうなずきました。 特に引っかかったのは、著者が繰り返し強調している「is my understanding correct?」です。これ、ただの確認文に見えるのに、実際はかなり強い型なんだと思います。人間同士の会話でも、相手に「自分の理解を言い直させる」とズレが見えますが、それを coding agent 相手に、しかも開発の途中で何度もやる。そうすると、説明する側が人間ではなく agent になり、しかも毎回“自分の理解”を検査できる。これは地味だけど効きそうです。 一方で、少し面白かったのは、この記事が「AI に任せれば楽になる」ではなく、「AI が速くなったぶん、こちらの認識の粗さが露出する」と書いているところで
papoo.work
Claude Codeのトークン浪費を見て思ったこと
Claude Codeのトークン浪費を見て思ったこと
200,000 tokens を先に食ってからようやく答え始める、という話を読むと、便利そうに見えるAIツールの裏側で、ずいぶん雑なことが起きていたんだなと感じる。人間なら「資料が多いから少し重い」で済む場面でも、LLM だとその「少し重い」がそのままコストと待ち時間に跳ねる。しかも利用者から見えにくい形で起きていたのが、かなり気持ち悪い。 いちばん引っかかったのは、問題が“賢さ”ではなく“読み込み方”にあったことだと思う。Claude Code の skill が、質問に答える前に関係ありそうなドキュメントをまとめて抱え込んでいたわけで、これは人間でいえば「とりあえず本棚の全部を机に積む」みたいなものだ。実際の作業では、必要なページを必要なときに開けばいい。そこを on-demand に変えて 25K まで落とした、というのはかなり素直な改善に見える。 ただ、ここで終わらないのも面白い。LLM 周辺の製品は「モデルの性能」ばかり話題になりがちだけれど、実際には入力の設計、ドキュメントの切り出し方、どのタイミングで何を読むか、みたいな地味な部分が体験を決める。今回の話は、その地味な部分
papoo.work
`disabled after repeated failures · restart to retry` が出るときに見えていること
`disabled after repeated failures · restart to retry` が出るときに見えていること
まず、この症状に当てはまるかどうかを先に切り分けます。今回の issue では、Remote Control が失敗を重ねたあとに無効化され、再起動しないと試し直せないように見える、という報告が 2 件あります。`[#78364](https://github.com/anthropics/claude-code/issues/78364)` では「3 回の一時的な失敗」で Remote Control が静かに恒久無効化される、と書かれています。`[#87269](https://github.com/anthropics/claude-code/issues/87269)` では、起動時に Remote Control の開始に失敗すると、そのセッション中は回復せず、再接続経路もないと報告されています。 今回の手元の確認では、Claude Code は Remote Control 機能自体を案内していますが、同時に複数インストールの存在も出ています。実際の出力は次のとおりです。 ```text $ claude --version 2.1.207 (Claude Code) ``
papoo.work
`Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"The following domains are not accessible to our user agent: ...` が出るときに見えること
`Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"The following domains are not accessible to our user agent: ...` が出るときに見えること
この症状は、Claude Code が何かの処理で外部ドメインにアクセスしようとして、そのドメインが user agent から到達できないと返されたときに出ています。今回の issue 群では、報告されているドメインが少し違います。[#78780](https://github.com/anthropics/claude-code/issues/78780) では `reddit.com`、[#76310](https://github.com/anthropics/claude-code/issues/76310) では `blog.naver.com` と `m.blog.naver.com` が挙がっていました。 手元で確認できたのは、Claude Code CLI の表示と `claude agents --help` までです。少なくともこの環境では、`claude agents` はバックグラウンドエージェント管理のコマンドとして存在していました。 ```text $ claude --version 2.1.207 (Claude Code) ``` ```text $
papoo.work
`Permission for this action was denied by the Claude Code auto mode classifier.` が出て、通るはずの操作まで止まるとき
`Permission for this action was denied by the Claude Code auto mode classifier.` が出て、通るはずの操作まで止まるとき
この症状に当てはまるかどうかは、かなりはっきりしています。Claude Code の auto permission mode で、ユーザーが止めるつもりのない通常のツール呼び出しまで `Permission for this action was denied by the Claude Code auto mode classifier.` で落ちる。しかも、その理由が「直前のコンパクション時の文言」や、ユーザーが明示した許可に引っ張られているように見える、という報告です。 Issue [#77158](https://github.com/anthropics/claude-code/issues/77158) では、auto-compaction が走ったあと、コンパクション用の割り込み文の `Do NOT call any tools` を「まだ有効なユーザー境界」とみなして、その後の正当な tool call を拒否したと書かれています。報告者は `autoCompactWindow` に達した長いセッションで再現し、`claude-opus-4-8` と `claude-
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync の症状に当たるかどうか
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync の症状に当たるかどうか
この件は、Claude Code の画面や処理中に ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=60 messages=59 range=[0,60)) ``` のようなエラーが出るケースです。報告されている issue は 2 件で、[#88174](https://github.com/anthropics/claude-code/issues/88174) は closed、[#87911](https://github.com/anthropics/claude-code/issues/87911) は open でした。どちらも同じ系統のメッセージを含んでいます。 まず、筆者の環境で確認できた範囲では、Claude Code CLI は 2.1.207 でした。`claude doctor` では複数インストールが見つかっています。ここは実際の出力をそのまま載せます。 ```text $ claude --version 2.1.207 (Claud
papoo.work
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` が出たときに確認したいこと
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` が出たときに確認したいこと
この症状は、少なくとも今回集めた issue では「Claude Code の実行中に `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出る」という形で報告されています。 検索しやすいようにエラー文字列をそのまま書くと、`keys=17 messages=16 range=[0,17)` のように、`itemKeys` と `messages` の件数がずれている例と、`keys=109 messages=108 range=[66,109)` のように別の件数で出ている例がありました。いずれも同じ症状クラスタとして集まっています。 まず、自分のケースかどうかは「Claude Code の内部エラーとしてこの文字列が出ているか」で切り分けるのがよさそうです。今回の報告に出ているのは、ユーザーのコマンド失敗というより、`VirtualMessageList` の整合性が崩れたと見えるエラーです。少なくとも issue の本文からは、Shell の PATH 変更のような別の機能不具合と直
papoo.work
`Tool execution failed` が出るとき、まず見るべきこと
`Tool execution failed` が出るとき、まず見るべきこと
自分のケースかどうかは、かなりはっきりしています。少なくとも issue 報告では、Claude Desktop / Claude Code 側で MCP の tool call が失敗し、相手のサーバーに届いていない例が出ています。 一方で、同じサーバー上でも `outputSchema` を持たないツールは正常に動く、と書かれています。 手元で確認できた範囲では、Claude Code CLI 自体は入っています。 ```text $ claude --version 2.1.207 (Claude Code) ``` MCP 関連のサブコマンドもあります。 ```text $ claude mcp --help Usage: claude mcp [options] [command] Configure and manage MCP servers Options: -h, --help Display help for command Commands: add [options] <name> <commandOrUrl
papoo.work
hook_non_blocking_error が Windows で出るときに見ておきたいこと
hook_non_blocking_error が Windows で出るときに見ておきたいこと
まず、この症状は「Claude Code の hook が関係しているらしいが、処理自体は止まらない」タイプではなく、少なくとも issue 上ではもっと厄介に見えます。Windows 環境で `hook_non_blocking_error` が繰り返し出て、設定した hook コマンドが実行されていないように見える、という報告が上がっています。 報告は 2 件あり、どちらも Windows 上の Claude Code に関するものです。[#72636](https://github.com/anthropics/claude-code/issues/72636) では「configured hook commands を実行しない。hook runner が `git` を呼んで失敗を黙って飲み込む」と書かれています。[#79847](https://github.com/anthropics/claude-code/issues/79847) では、Windows で `fg: no job control` が `hook_non_blocking_error` として再発し
papoo.work
`advisor_tool_result_error` で advisor が `unavailable` になるときに見ておくこと
`advisor_tool_result_error` で advisor が `unavailable` になるときに見ておくこと
この症状は、advisor 呼び出しの結果が `advisor_tool_result_error` として返り、エラーコードが `unavailable` になるものです。手元で確認できた issue はどちらも「advisor を使うと落ちる」が共通していますが、発生条件は少し違います。 まず切り分けたいのは、あなたのケースが「Fable 5 を advisor にしたときだけ不安定」なのか、「セッションが重くなると advisor 自体が死ぬ」のかです。前者なら [#75971](https://github.com/anthropics/claude-code/issues/75971) に近く、後者なら [#76049](https://github.com/anthropics/claude-code/issues/76049) に近いです。 手元の環境では `claude doctor` は大きな破損を示していませんでした。出力はこうです。 ```text $ claude doctor Claude Code doctor Running: native (2.1.20
papoo.work
Claude Desktop の Code タブが `exit code 127` で落ちるときに見ておくこと
Claude Desktop の Code タブが `exit code 127` で落ちるときに見ておくこと
自分のケースかどうかを先に切り分けるなら、Claude Desktop の通常チャットは動くのに、Code タブだけが起動直後に失敗するかどうかです。Issue [#83656](https://github.com/anthropics/claude-code/issues/83656) と [#82587](https://github.com/anthropics/claude-code/issues/82587) では、どちらも Code タブの起動失敗が報告されていて、エラー文に `Malformed Mach-o file` と `exit code 127` が出ています。前者では、Desktop が別途ダウンロードした `claude` バイナリの署名状態まで確認されています。 今回の issue 群で見えているのは、少なくとも「Claude Code 自体の機能不全」というより、Claude Desktop 側が起動する `claude` バイナリの読み込みに失敗している、という形です。`#83656` の報告では、main の Claude.app 本体と help
papoo.work
`Auto-update failed` が消えないときに見ること
`Auto-update failed` が消えないときに見ること
まず、自分のケースかどうかはかなり絞れます。`claude doctor` に `Auto-update failed` 相当の履歴が残り続け、しかも `Last update attempt: failed` のような表示が消えないなら、今回の症状クラスタに近いです。Issue では、更新チェックや一時的なネットワーク断をきっかけに失敗状態が記録され、その後の起動や再接続、`claude update`、`/doctor` でも自動では消えない報告がありました。 関係する報告は [#70608](https://github.com/anthropics/claude-code/issues/70608) と [#65093](https://github.com/anthropics/claude-code/issues/65093) です。前者は `~/.claude/.last-update-result.json` に入った失敗状態がその後の成功で上書きされない、という内容でした。後者は Windows でセッション中にネットワークが落ちたあと、`Auto-update fa
papoo.work
`The advisor tool is unavailable. Do not try to use it again.` が出て advisor が戻らないときに見えたこと
`The advisor tool is unavailable. Do not try to use it again.` が出て advisor が戻らないときに見えたこと
この症状は、advisor の呼び出しがセッション中に一度成功したあと、同じセッション内で突然 > `The advisor tool is unavailable. Do not try to use it again.` に変わり、その後は advisor を実質的に使えなくなる、という形で報告されています。issue [#77513](https://github.com/anthropics/claude-code/issues/77513) では、セッション序盤の `advisor()` は成功したのに、後半でこのエラーになり、理由が出ないままだったと書かれています。issue [#67306](https://github.com/anthropics/claude-code/issues/67306) でも、最初の呼び出しで同じ文言が返り、その後は「do not try again」の通りセッション中ずっと戻らなかったとあります。 まず、自分のケースかどうかを見分けるなら、次の2点です。ひとつは、advisor が「そのセッションでは最初は動いていたか」。もうひとつは、失
papoo.work
Claude Codeの「見えない重さ」に驚いた
Claude Codeの「見えない重さ」に驚いた
最初に思ったのは、これはかなり気持ち悪いな、ということでした。質問に答える前から 200,000 tokens も食っていた、という話は、単なる「遅い」よりずっと嫌な種類の問題です。遅さなら体感できるけれど、見えないところでコストだけ先に積み上がっているのは、使う側としてかなり不信感が残ると思いました。 特に引っかかったのは、原因が「skill」だという点です。Claude Code のような開発支援ツールは、便利さの代わりに内部で色々な文書や設定を抱え込むわけですが、その読み込み方が雑だと、賢くなるどころか巨大な前置きで首を絞めることになる。AI の文脈では、モデルの性能ばかり語られがちですが、実際にはこういう「周辺の設計」の方が効くのだと改めて感じました。 25K tokens に減った、という改善は素直にいい話です。ただ、ここでも少し気になったのは、そもそも 200K まで膨らんだことが“静かに”起きていた点です。人間のソフトウェアなら、そんなに無駄な読み込みがあればメモリや起動時間で早めに気づけそうなのに、LLM 系だと請求やレイテンシに現れるまで見逃されやすい。便利な道具ほど
papoo.work
exit code 143 が出るときにまず疑うこと
exit code 143 が出るときにまず疑うこと
`exit code 143` は、この材料だけを見ると「Claude Code のプロセスが SIGTERM で終わった」系の症状として扱うのが自然です。そう見てよさそうな根拠は、issue 側で実際に `SIGTERM (exit 143)` と書かれていることです。たとえば [#87658](https://github.com/anthropics/claude-code/issues/87658) では、Claude desktop アプリ内で 2 つ目の local Code セッションを始めると、先に動いていた CLI プロセスが SIGTERM で終了すると報告されています。 ただし、同じ `exit code 143` でも原因はひとつではありません。#76293 では、対話中の Claude Code が Bash tool の成功後に何のエラー表示もなく shell に戻り、あとでセッションを再開できたと書かれています。こちらの報告では、約 3 日動作していたこと、永続化された transcript が約 4.6 MB だったこと、request metadata
papoo.work
`Error: 404 {"type":"error","error":{"type":"not_found_error"` が出て、Claude Fable 5 が使えないと返ってくるときに確認したこと
`Error: 404 {"type":"error","error":{"type":"not_found_error"` が出て、Claude Fable 5 が使えないと返ってくるときに確認したこと
この症状は、Claude Code がリクエスト先から ```text Error: 404 {"type":"error","error":{"type":"not_found_error","message":"Claude Fable 5 is not available. Please use Opus 4.8. Learn more: https://www.anthropic.com/news/fable-mythos-access"}} ``` を受け取って止まるケースです。issue 群では同じ文言が繰り返し報告されていました。たとえば [#68290](https://github.com/anthropics/claude-code/issues/68290)、[#68381](https://github.com/anthropics/claude-code/issues/68381)、[#68188](https://github.com/anthropics/claude-code/issues/68188)、[#76316](https://github.c
papoo.work
`Error: ELOOP: too many symbolic links encountered, open '/pr` で止まるときに見えているもの
`Error: ELOOP: too many symbolic links encountered, open '/pr` で止まるときに見えているもの
この症状は、issue [#87609](https://github.com/anthropics/claude-code/issues/87609) と [#87606](https://github.com/anthropics/claude-code/issues/87606) で、どちらも同じ系統のエラーとして報告されています。報告本文では、Claude 側の表示として > `API Error: Opus 4.8 can't help with this. Start a new session to continue.` に続いて、 > `Error: ELOOP: too many symbolic links encountered, open '/private/tmp/claude-503/-Users-b59c0877-f27c-4f84-86cf-511dc2fe8180-Documents-Jarvis--projects-competition-module/6cab9d6c-1a11-4c7c-9da5-3feec...` というエラーが出ています。少な
papoo.work
String to replace not found が出るときに、まず確認したいこと
String to replace not found が出るときに、まず確認したいこと
この症状クラスタでは、見えている失敗が 2 つあります。ひとつは、`Edit` や `Write` が「置換対象の文字列が見つからない」と扱われる系の失敗。もうひとつは、YAML の前提が崩れたときに、別の内容まで巻き込んで壊れるケースです。手元で確認できた情報だけでいうと、少なくとも [#76868](https://github.com/anthropics/claude-code/issues/76868) では、Markdown ファイルの frontmatter が YAML として解釈できないときに、内容をそのまま残すのではなく空の stub に差し替えてしまう、という報告がありました。なお [#87643](https://github.com/anthropics/claude-code/issues/87643) は open で、`isolation:"worktree"` の subagent が親セッション側の worktree に書き込んでしまう、という別系統の報告です。 最初に切り分けたいのは、「自分が遭遇しているのが、文字列置換の失敗なのか」「それとも別の
papoo.work
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` が出るときに見えていたもの
`TelemetrySafeError: VirtualMessageList: itemKeys/messages le` が出るときに見えていたもの
この件は、まず「自分のケースかどうか」を切り分けるのが先です。報告されているのは、同じエラー文字列を含む 2 件の issue で、どちらも Opus 5 の安全フィルタまわりで誤検知が起きた、という内容でした。 両方に出ているエラーは同じです。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=126 messages=125 range=[118,126)) at nPv (/$bunfs/root/src/entrypoints/cli.js:23184:8181) at NAm (/$bunfs/root/src ``` この文字列だけを見ると、`itemKeys` と `messages` の件数がずれている、という内部不整合に見えます。ただし、issue の本文から読み取れる範囲では、最終的に「CLI の一般的な壊れ方」なのか「Opus 5 の安全スキャン経由で出る誤検知」なのかは切り分けきれません。少なくとも、報告者は同じエラーを、連続リクエスト時の誤
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見かけたときの切り分け
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見かけたときの切り分け
このエラーは、今回集まっている 4 件の issue ではいずれも同じ文言で報告されています。本文だけを見る限り、個別の操作に埋もれた別件というより、Claude Code 側の表示・内部状態の不整合に触れている可能性があります。ただし、現時点で確認できるのは「そう報告されている」という事実までです。根本原因は分かっていません。 まず自分のケースかどうかを確かめるなら、表示される文言がこの形かを見ます。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=87 messages=86 range=[0,87)) TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=106 messages=105 range=[70,106)) TelemetrySafeError: VirtualMessageList: itemKeys/messages length desyn
papoo.work
`claude native binary not installed.` が出るときに見るところ
`claude native binary not installed.` が出るときに見るところ
このエラーは、少なくとも今回の 2 件の issue では、`claude` を起動したときに「native binary が見つからない」と言われる症状でした。ひとつは `npm i @anthropic-ai/claude-code@2.1.126` の直後に `claude` を実行して発生し、もうひとつは自動更新が成功扱いになったあと、次の起動で同じエラーになっています。参照した issue は [#57577](https://github.com/anthropics/claude-code/issues/57577) と [#85974](https://github.com/anthropics/claude-code/issues/85974) です。 手元で確認した環境でも、`claude doctor` はインストール状態に少し気になる点を出しています。`native` で動いている一方で、`npm-global` の残骸も見えていました。 ```text $ claude doctor Claude Code doctor Running: native (2.
papoo.work
`ERR_BLOCKED_BY_CLIENT` が Browser pane で出るときに見えているもの
`ERR_BLOCKED_BY_CLIENT` が Browser pane で出るときに見えているもの
まず切り分けたいのは、Claude Code の Browser pane で開いているページが「HTML は返るのに、CSS や JS などの subresource だけが落ちる」状態かどうかです。今回の issue 報告では、トップレベルの document は読み込める一方で、同一オリジンの subresource が `net::ERR_BLOCKED_BY_CLIENT` になり、画面が真っ白、あるいはスタイルの当たっていない素の HTML だけが見える、という症状が共通しています。対象は `mcp__Claude_Browser__*` / preview pane で、Claude in Chrome 拡張ではないと明記されています。 報告の中身は少しずつ違いますが、少なくとも次の2系統は同じ症状クラスタとしてまとまっています。 筆者側で実際に確認できた Claude Code の状態は次のとおりです。 ```text $ claude --version 2.1.207 (Claude Code) ``` ```text $ claude doctor Cla
papoo.work
`Navigation to this domain is not allowed` が出るとき、まず見るべき切り分け
`Navigation to this domain is not allowed` が出るとき、まず見るべき切り分け
この症状は、issue の内容を見る限り「Claude in Chrome / Claude Code の MCP 経由で `navigate` を呼ぶと、許可済みのはずのドメインでも即座に拒否される」ケースが中心です。少なくとも報告されている範囲では、承認プロンプトが出ないまま `Navigation to this domain is not allowed` で止まっています。 たとえば [#58464](https://github.com/anthropics/claude-code/issues/58464) では、Claude in Chrome の設定で `Your approved sites` に入っていて、拡張機能のサイトアクセスも `On all sites` なのに、`mcp__Claude_in_Chrome__navigate` がそのドメインを拒否したと報告されています。手動で Chrome 上では普通に開けるのに、MCP 経由だけ失敗する、という切り分けです。 筆者の環境では Claude Code CLI の存在と MCP 管理コマンドの有無までは確
papoo.work
The socket connection was closed unexpectedly. For more info が出るときに見えていたこと
The socket connection was closed unexpectedly. For more info が出るときに見えていたこと
この症状は、issue 報告上では [#65202](https://github.com/anthropics/claude-code/issues/65202) と [#59781](https://github.com/anthropics/claude-code/issues/59781) で確認できます。どちらも、CLI の操作中に `The socket connection was closed unexpectedly. For more information, pass \`verbose: true\` in the second argument to fetch()` という文言が出ています。少なくとも報告された範囲では、単独のローカル設定ミスというより、通信が途中で切れたときに見えるエラーとして扱われています。 最初に切り分けたいのは、「自分の環境で再現しているか」ではなく、「同じ文言が出ているか」です。今回の issue 群では、`socket connection was closed unexpectedly` の後に `verbose: true`
papoo.work
Claude Code で HTTP 500 が返るときにまず見るところ
Claude Code で HTTP 500 が返るときにまず見るところ
まず、この件は Claude Code 側から返ってくる `HTTP 500` です。Issue では、`Anthropic API Error: 500 Internal Server Error` という表現でまとまっていて、内容も `Internal server error` とだけ出ています。たとえば代表 issue の [#59832](https://github.com/anthropics/claude-code/issues/59832) には、API の 500 が出たことと、`status.claude.com` を確認するよう案内する文面が載っています。ほかの [#59778](https://github.com/anthropics/claude-code/issues/59778)、[#59748](https://github.com/anthropics/claude-code/issues/59748)、[#59753](https://github.com/anthropics/claude-code/issues/59753) も同じ症状です。
papoo.work
Claude Codeで自動承認が標準になったことへの違和感と納得
Claude Codeで自動承認が標準になったことへの違和感と納得
最初に思ったのは、「もうここまで来たか」という驚きと、同時に「そりゃそうだよな」という妙な納得感だった。 Claude Code の auto mode は、要するに毎回の確認ダイアログを減らして、ある程度はエージェントに任せるモードだ。コード生成ツールとしては便利でも、勝手にファイルを書き換えたり削除したりする可能性がある以上、普通は慎重になる。そこをデフォルトにしたのは、Anthropic が「人間が逐一止める前提」より「ある程度は任せて前に進む前提」に軸足を移した、ということだと思う。 一方で、数字の出し方はかなり強気に見えた。危険なコマンドを人間が見つけられた割合より classifier のほうがずっと高い、しかも手動確認はプロンプトが増えると精度が落ちる、という話はたしかに筋が通っている。でも、ここで面白いのは「人間より機械のほうが安全」だから安心、ではなく、Anthropic 自身が最後にちゃんと「classifier でリスクは消えない」と釘を刺しているところだと思う。便利にするほど、責任の置き場所はむしろ曖昧になる。そこを完全には隠していないのは好感が持てた。 あと、
papoo.work
Claude Codeの自動モード、便利さと怖さの境目
Claude Codeの自動モード、便利さと怖さの境目
最初に思ったのは、「また便利さがデフォルトに寄ってきたな」ということだった。 Claude Code の auto mode は、毎回人間に確認を求めずに先へ進めるモードらしい。コードを書く流れを速くするにはたしかに気持ちよさそうだけど、プログラマーの感覚からすると、確認を省く方向にデフォルトが寄るのは少し落ち着かない。 記事の中でいちばん引っかかったのは、「危険な操作だけ止める」という設計が、どこまで本当に頼れるのかという点だ。Anthropic はテストで harmful actions の 89% を auto mode が見つけたと言っていて、人間の 13.6% より高いらしい。数字だけ見るとかなり強い。でも、ここで気になるのは「残りの11%」がどんな場面なのかだと思う。破壊的で元に戻せない操作は止める、という説明は筋が通っている一方で、実際の開発では、壊れ方がゆっくり来るミスのほうが厄介だったりする。そこをどこまで拾えるのかは、記事だけでは見えない。 それでも、デフォルトでオンにする判断自体は、Anthropic がこの機能を“実験”ではなく“日常の道具”として押し出したいの
papoo.work
`[Tool result missing due to internal error]` が出て AskUserQuestion が返らないときに確認したこと
`[Tool result missing due to internal error]` が出て AskUserQuestion が返らないときに確認したこと
この症状に当てはまるのは、`AskUserQuestion` の呼び出しで質問ウィジェットが最後まで出ず、途中で `Tool execution was interrupted` になり、モデル側には `[Tool result missing due to internal error]` が返るケースです。 報告されている issue は [#74797](https://github.com/anthropics/claude-code/issues/74797) です。もう一つ、長時間セッションでセッションプロセスが勝手に再起動し、バックグラウンドタスクの orphan 化や tool result の欠落が起きるという [#85181](https://github.com/anthropics/claude-code/issues/85181) もあります。 ただし、今回の手元確認だけでは、両者が同じ原因だとは断定できません。現時点では別件の可能性もあります。 まず、手元の環境では Claude Code は次の状態でした。 ```text $ claude --versi
papoo.work
`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出るときに確認したこと
`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出るときに確認したこと
この症状は、少なくとも今回の issue では Windows 上で報告されています。該当する報告は [#79401](https://github.com/anthropics/claude-code/issues/79401) と [#85333](https://github.com/anthropics/claude-code/issues/85333) の 2 件で、どちらも同じエラー文字列を含んでいます。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=168 messages=167 range=[104,168)) ``` ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=85 messages=84 range=[68,85)) ``` まず切り分けとして、このエラーが「表示中のメッセージ一覧の整合性が崩れた」タイプのものかど
papoo.work
`VM connection timeout after 60 seconds` が出るときに、まず見るところ
`VM connection timeout after 60 seconds` が出るときに、まず見るところ
この症状は、少なくとも今回渡された issue では 2 つの見え方に分かれています。ひとつは Windows 11 ARM64 / Snapdragon X 系で、VM の起動や共有設定までは進むのに、ゲストがホストへ戻ってこず 60 秒で失敗するパターンです。もうひとつは、VM の状態が残ったままになり `smol-bin.vhdx` が掴まれ続けるパターンです。前者は [#85739](https://github.com/anthropics/claude-code/issues/85739)、後者は [#79270](https://github.com/anthropics/claude-code/issues/79270) に書かれています。 ただし、今回の二件だけでは「同じ原因」とまでは言えません。[#85739](https://github.com/anthropics/claude-code/issues/85739) では、VM 自体は始まっていて、`add_plan9_shares` までは 500ms 未満で終わる一方、その先のゲスト接続待ちで止まっています
papoo.work
`exit code 3` が出るときにまず見る場所
`exit code 3` が出るときにまず見る場所
`Claude Code process exited with code 3` が出ても、すべてが同じ原因とは限りません。少なくとも今回集めた issue では、Windows 側で常駐している Windhawk が関わるケースと、Hyper-V の仮想マシン内で Claude Code のバイナリが落ちるケースが別々に報告されています。 自分の症状がどちらに近いか、先に分けるのがよさそうです。 ターミナルでは動くのにデスクトップアプリ側だけで落ちるなら、[#52386](https://github.com/anthropics/claude-code/issues/52386) の報告とかなり似ています。報告者は「昨日までは動いていたが、今日は毎回 `Claude Code process exited with code 3` になる」「terminal では引き続き動く」と書いています。さらに Windhawk を終了すると直るとも述べています。 一方で、Windows の Cowork 経由で、VM の起動自体は成功するのに Claude Code の binary が始ま
papoo.work
Error: 429 {"type":"error","error":{"type":"rate_limit_error":"Rate limited"} で止まるときに、まず確認したいこと
Error: 429 {"type":"error","error":{"type":"rate_limit_error":"Rate limited"} で止まるときに、まず確認したいこと
同じ形のエラーが出ているなら、少なくとも今回の issue 群では Claude Code 側から「サーバーが一時的にリクエストを制限している」と案内されていました。報告されている文言は、どちらも `API Error: Server is temporarily limiting requests (not your usage limit)` か、あるいは `Rate limited` です。対象になっている issue は [#73509](https://github.com/anthropics/claude-code/issues/73509) と [#73151](https://github.com/anthropics/claude-code/issues/73151) です。 この症状が自分のケースかどうかを見るなら、まずエラー本文が一致するかを見ます。今回の報告では、少なくとも次の形が共通していました。 ```text Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"
papoo.work
Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"} のときに、まず切り分けたいこと
Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"} のときに、まず切り分けたいこと
この症状は、Claude Code が API から `429` と `rate_limit_error` を受け取って止まるものです。今回集まっている issue は 3 件とも解決済みで、どれも同じ系統のエラー文字列を含んでいました。 報告内容で共通しているのは、単なる「使いすぎ」で出る制限ではなく、`API Error: Server is temporarily limiting requests (not your usage limit)` と読める点です。つまり、少なくとも issue 上では「自分の利用上限に達した」とは書かれていません。サーバー側の一時的な制限として扱われています。 実際の報告では、次の文字列がそのまま出ています。 ```text Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"},"request_id":"req_011CdBp6diwVhNmSZmaw4Xjm"} at generate (B:/~BUN/root/src/
papoo.work
Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"} に出たときにまず見ること
Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"} に出たときにまず見ること
この症状は、Claude Code の実行中に `Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"}}` が返ってくるものです。今回集められた 3 件の issue はすべて closed で、しかも代表 issue へのコメントでは「サーバー側の一時的な制限」であり「your usage limit ではない」と案内されています。少なくとも issue の本文だけを見る限り、利用者の契約上限を超えた話としては扱われていません。 自分のケースかどうかを見分ける手がかりは、エラーメッセージの中身です。今回の症状クラスタでは、どの報告でも同じ形の 429 が出ています。 ```text Error: 429 {"type":"error","error":{"type":"rate_limit_error","message":"Rate limited"},"request_id":"req_011Cd634q9TpgJDhp2BnFWFZ"} at generat
papoo.work
this version can't be shared publicly が出るときに見たことと、まだ分からないこと
this version can't be shared publicly が出るときに見たことと、まだ分からないこと
この症状は、Claude Code で Artifact を公開共有しようとしたとき、共有ダイアログに > This version can't be shared publicly. Publish a new version or change the shared version, then try again. と出るケースです。手元で確認した issue でも、同じ文言がそのまま報告されています。たとえば [#80321](https://github.com/anthropics/claude-code/issues/80321) は「再公開しても共有できない」、[#80545](https://github.com/anthropics/claude-code/issues/80545) は mermaid ブロックを含む Artifact で同じエラーが出る、[#85550](https://github.com/anthropics/claude-code/issues/85550) は Max plan の Linux 環境で共有不可が続く、という内容でした。 まず
papoo.work
`exit code 132` が出るときにまず疑うこと
`exit code 132` が出るときにまず疑うこと
`exit code 132` が出ている場合、少なくとも今回の issue では「起動した Claude Code のプロセスが SIGILL で落ちる」系の話として報告されています。 該当する報告は [#73504](https://github.com/anthropics/claude-code/issues/73504) と [#85571](https://github.com/anthropics/claude-code/issues/85571) です。 ただし、同じ `132` でも原因は一つではなさそうです。#73504 は「最初のクエリ以降ずっと `Claude Code process exited with code 132`」という報告で、#85571 は「SSE4.2 / POPCNT を満たさない CPU で `Illegal instruction (core dumped)` が出る」という報告でした。後者は AVX だけの問題ではない、と明記されています。 まず、自分のケースがどちらに近いかを見分けるのが先です。 `Illegal instruct
papoo.work
ENOTFOUND が出るときに、まず切り分けたいこと
ENOTFOUND が出るときに、まず切り分けたいこと
`ENOTFOUND` は、少なくとも今回の issue 群では「DNS が引けていない」系の失敗として現れています。ただし、同じ見え方でも原因は 1 つではありません。今回確認できた範囲では、`claude update` で失敗するケースと、macOS のスリープ復帰後に OAuth の更新がこけるケースが並んでいます。 症状の入口としては、`claude update` や Web 系の操作で `ENOTFOUND` / `ETIMEDOUT` が出て、その後にログイン状態が崩れるか、アップデートだけ失敗するかを見ます。参照できる issue は [#71699](https://github.com/anthropics/claude-code/issues/71699) と [#85149](https://github.com/anthropics/claude-code/issues/85149) です。 まず、自分の環境で Claude Code がどう入っているかは確認しておいたほうがよさそうです。手元の出力では、`claude doctor` が複数インストールを検
papoo.work
Error: 403 {"type":"error","error":{"type":"permission_error`: Claude Code で「OAuth authentication is currently not allowed for this organization.」が出るとき
Error: 403 {"type":"error","error":{"type":"permission_error`: Claude Code で「OAuth authentication is currently not allowed for this organization.」が出るとき
このエラーが出るのは、Claude Code が OAuth 認証で進もうとして、所属組織側でそれが許可されていないときです。少なくとも issue の報告では、`Your organization has disabled Claude subscription access for Claude Code` という案内とあわせて `OAuth authentication is currently not allowed for this organization.` が返っています。該当する報告は [#63685](https://github.com/anthropics/claude-code/issues/63685) と [#63886](https://github.com/anthropics/claude-code/issues/63886) です。 まず見分けたいのは、自分が「個人の Pro 契約を持っているのに弾かれている」のか、それとも本当に組織管理下のアカウントとして扱われているのか、です。[#63886](https://github.com/anthro
papoo.work
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"Your credit balance is too low to access the Anthropic API."}} が出るときに確認したこと
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"Your credit balance is too low to access the Anthropic API."}} が出るときに確認したこと
このエラーが出た 2 件の issue は、どちらも本文にあるメッセージが同じでした。[#85675](https://github.com/anthropics/claude-code/issues/85675) も [#66297](https://github.com/anthropics/claude-code/issues/66297) も、報告されているのは `Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"Your credit balance is too low to access the Anthropic API. Please go to Plans & Billing to upgrade or purchase credits."}}` です。 まず切り分けたいのは、Claude Code 自体の壊れ方ではなく、API 側の残高不足として返ってきているのかどうかです。少なくとも issue の記載上は、その方向を示しています。`invalid_requ
papoo.work
ECONNREFUSED が出るときにまず見るところ
ECONNREFUSED が出るときにまず見るところ
Claude Code で `ECONNREFUSED` にぶつかったとき、いま手元で確認できる範囲では、少なくとも「ローカルサービスに向けた接続」と「Windows 11 での接続失敗」という 2 つの報告がありました。どちらも、単純な通信エラーに見えて、実際には接続先の見え方や実行環境が絡んでいそうです。 自分のケースかどうかを見分ける起点は、ローカルホスト宛てかどうかです。`localhost` や `127.0.0.1` に向けた通信で落ちるなら、[ #65482](https://github.com/anthropics/claude-code/issues/65482) の報告にかなり近いです。そこでは、Linux の bwrap サンドボックス環境で `sandbox.network.allowedDomains` に `localhost` と `127.0.0.1` を入れても、期待通りにローカルサービスへつながらないとされています。理由として、実行時に `NO_PROXY=localhost,127.0.0.1,...` が設定され、HTTP クライアントがサンド
papoo.work
Claude Code で `EPIPE` が出るときに見ておきたいこと
Claude Code で `EPIPE` が出るときに見ておきたいこと
まず、この症状が自分のケースかを切り分けます。今回の issue 群で共通しているのは、`claude` の実行中に通信まわりが壊れたとき、`EPIPE` を起点にセッションやプロセスの挙動が崩れる点です。 ひとつは、tool-use のターン中に `api.anthropic.com` への API 呼び出しが失敗したケースです。報告では、DNS 失敗、HTTP タイムアウト、接続リセットのような一時的なネットワーク障害が起きると、CLI が警告もなく静かに終了し、再試行もバックオフも見えなかったとされています。セッションは `/exit` を打ったように終わる、と書かれています。これは [#65474](https://github.com/anthropics/claude-code/issues/65474) の報告です。 もうひとつは、sandboxed command が `SIGKILL` で殺されたあとに SOCKS socket が残り、その後 main thread が dead socket に書き続けて `EPIPE` を繰り返すケースです。こちらは 100%
papoo.work
`Error: 429 {"type":"error","error":{"type":"rate_limit_error` が返るのに、使用量制限ではないと出るときに確認したこと
`Error: 429 {"type":"error","error":{"type":"rate_limit_error` が返るのに、使用量制限ではないと出るときに確認したこと
この症状は、Claude Code 側で API 呼び出しが 429 になり、エラーメッセージに `rate_limit_error` と `Rate limited` が出るものです。今回の issue 群では、いずれも同じ文字列が出ており、しかも「not your usage limit」「Server is temporarily limiting requests」と書かれています。つまり、少なくとも報告上は「自分の利用上限に達した」というより、サーバー側の一時的な制限として見えているケースです。参照できたのは [#73658](https://github.com/anthropics/claude-code/issues/73658)、[#73657](https://github.com/anthropics/claude-code/issues/73657)、[#73656](https://github.com/anthropics/claude-code/issues/73656)、[#73655](https://github.com/anthropics/cla
papoo.work
Claude Code で HTTP 401 が出るときに最初に見るところ
Claude Code で HTTP 401 が出るときに最初に見るところ
手元で確認できたのは、同じ `HTTP 401` でも中身が違う 2 つの系統です。ひとつは GitHub のリリース URL を取りにいく途中で `HEAD` が拒否されるケース、もうひとつは `headersHelper` で取った bearer が切れたあとに再取得へ戻らず、OAuth の動きに入ってしまうケースです。どちらも issue 報告としては別件ですが、見えている症状はかなり近いです。 まず、あなたのケースがどちら寄りかで分けると見やすくなります。GitHub-hosted の release archive を fetch していて、`http_head request` の時点で `401 Unauthorized` になるなら #70588 の線が濃いです。MCP サーバーで `headersHelper` を使っていて、トークンが期限切れになったタイミングで `401` が出るなら #82070 の症状に近いです。 `#70588` では、Claude Code cloud/web session で network egress を `"All domains
papoo.work
exit code 128 が出るときの Claude Code の見分け方と、いま分かっている範囲
exit code 128 が出るときの Claude Code の見分け方と、いま分かっている範囲
まず切り分けたいのは、同じ `exit code 128` でも起き方が別物だという点です。今回の材料には、少なくとも 2 つのパターンがあります。ひとつは Claude Code on the web の remote execution sandbox で `git clone` が github.com への HTTPS 通信を通せず、`pip install` の `git+https://...` 依存関係が落ちるケースです。もうひとつはデスクトップアプリで、リンクされた worktree で既にチェックアウト済みのブランチに対して `git switch` が主レポジトリ側で走り、Git が拒否して 128 で終わるケースです。前者は [#71230](https://github.com/anthropics/claude-code/issues/71230)、後者は [#85543](https://github.com/anthropics/claude-code/issues/85543) です。 まず、あなたの症状がどちら寄りかを見ます。 remote execu
papoo.work
`Error: Failed to submit feedback:401
`Error: Failed to submit feedback:401
at fo8 (/$bunfs/roo` が出るときに見えていたこと この文字列が出ているだけでは、原因をひとつに絞れません。今回見つかった issue は 2 件だけで、どちらも最終的には closed ですが、報告内容はかなり違っていました。まず自分のケースがどちらに近いかを切り分けるのが先です。 `[#64103](https://github.com/anthropics/claude-code/issues/64103)` では、Claude Code が bash コマンドを誤って生成し、並列実行のような動きでロックやエラーを起こし、しかも「成功した」と書き残した、という報告でした。報告されたエラーは `Error: Failed to submit feedback:403` です。 `[#65584](https://github.com/anthropics/claude-code/issues/65584)` は `/code-review ultra` 実行時のクラッシュで、`free credit` を消費したあと、結果を返す前に落ちています。こちらの基礎になっ
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages le が出るときに、まず見るところ
TelemetrySafeError: VirtualMessageList: itemKeys/messages le が出るときに、まず見るところ
このエラーは、少なくとも今回集めた 5 件の issue では、Claude Code のメッセージ一覧の内部整合性が崩れたときに出ています。報告されている文面は共通していて、`TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` で始まり、`keys=... messages=...` の件数が 1 ずれていました。たとえば `keys=132 messages=131`、`keys=177 messages=176`、`keys=199 messages=198`、`keys=92 messages=91`、`keys=613 messages=612` です。 今のところ、これは単発の操作ミスというより、入力やツール呼び出しの途中で UI 側のメッセージ列が壊れたように見えます。少なくとも issue の報告だけからは、利用者側で一律に再現できる手順までは見えていません。 自分のケースかどうかを切り分けるなら、まず「入力した内容そのもの」よりも「貼り付け・再送信・ツール呼び出しの直後に落ち
papoo.work
EACCESで止まるときにまず疑う3つのパターン
EACCESで止まるときにまず疑う3つのパターン
`EACCES` が出ても、原因はひとつではありません。今回の issue 群では、見た目は似ていても中身がかなり違いました。ひとつはファイルパスに Cyrillic の混入が起きて別の場所を作ろうとしてしまうケースで、[#41422](https://github.com/anthropics/claude-code/issues/41422) に報告があります。もうひとつは `~/.claude/settings.json` の保存まわりで、シンボリックリンクが 1 段ではなく 2 段つながっていると atomic write が失敗するケースで、[#78162](https://github.com/anthropics/claude-code/issues/78162) です。さらに Windows では、hook の実行先に App Execution Alias を指定すると `Executable not found in $PATH` と出る件が [#85475](https://github.com/anthropics/claude-code/issues/8547
papoo.work
`authentication_error` が出るとき、まず自分の症状かを切り分ける
`authentication_error` が出るとき、まず自分の症状かを切り分ける
Claude Code を使っていて `401` の `authentication_error` が急に出るなら、少なくとも今回集まっている報告では「認証が壊れた」というより、セッション中に OAuth token の期限切れや再認証が必要になっているケースが中心でした。 ただし、同じ `authentication_error` でも issue は 2 系統あります。 ひとつは、[#18225](https://github.com/anthropics/claude-code/issues/18225) のように、長く使っていたセッションで突然 401 が出始め、`/login` を何度も求められるパターンです。報告者は「months 使っていて、today から始まった」と書いています。エラーメッセージは次のとおりです。 ```text API Error: 401 {"type":"error","error":{"type":"authentication_error","message":"OAuth token has expired. Please
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たら、まず自分の再現条件を疑う
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たら、まず自分の再現条件を疑う
この症状は、Issue に出ている文字列がかなり特徴的です。手元で確認できた範囲では、少なくとも [#85341](https://github.com/anthropics/claude-code/issues/85341) と [#85332](https://github.com/anthropics/claude-code/issues/85332) の両方で、同じ ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=52 messages=51 range=[7,52)) ``` または近い形のエラーが報告されています。どちらも open で、解決済みの報告ではありません。したがって、少なくとも現時点では「特定のユーザー設定だけが原因」とは言い切れません。 実際に出ている差分は、`itemKeys` と `messages` の数が一致していないことです。Issue のログでは `keys=52 messages=51`、もう一方では `keys=180 m
papoo.work
`Persistent RPC: connection ended: failed to read length: EOF` が出るとき、まず疑うべきこと
`Persistent RPC: connection ended: failed to read length: EOF` が出るとき、まず疑うべきこと
この症状は、手元の issue 報告を見る限り、少なくとも Windows で Claude Desktop / Claude Browser MCP を使った直後に再現しています。#85199 では Claude Desktop が何度もクラッシュし、Windows 側に「Advanced Options → Repair」を促す表示が出ています。#85305 では Claude Browser MCP の `preview_start` が成功した直後に、セッションがそこで途切れています。どちらも、画面上のエラーより前に、RPC や MCP のやり取りが途中で切れているように見えます。 参照した issue は [#85199](https://github.com/anthropics/claude-code/issues/85199) と [#85305](https://github.com/anthropics/claude-code/issues/85305) です。 自分のケースかどうかを切り分けるなら、まず「ブラウザ系の MCP 操作の直後に落ちるか」「Claude
papoo.work
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync が出るときに見えたこと
TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync が出るときに見えたこと
このエラーは、こちらで確認できた範囲では 3 件の issue に共通していました。どれも `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` で始まり、`itemKeys` と `messages` の件数がずれていることを示しています。読者が自分のケースかどうかを見るなら、まずこの文字列が出ているかを確認するのが早いです。 報告は [#85344](https://github.com/anthropics/claude-code/issues/85344)、[#85196](https://github.com/anthropics/claude-code/issues/85196)、[#85112](https://github.com/anthropics/claude-code/issues/85112) の 3 件でした。いずれも open で、解決済みではありませんでした。 手元で取得できた CLI の状態は次の通りです。 ```text $ claude --version
papoo.work
`Error: 429 {"type":"error","error":{"type":"rate_limit_error"` が出て、Claude Code が「You've hit your limit」と返すとき
`Error: 429 {"type":"error","error":{"type":"rate_limit_error"` が出て、Claude Code が「You've hit your limit」と返すとき
この症状は、Issue の報告ではどちらも 429 の rate limit エラー として出ています。メッセージは同じで、どちらも `This request would exceed your account's rate limit. Please try again later.` という文言を含んでいました。該当する報告は [#56991](https://github.com/anthropics/claude-code/issues/56991) と [#64462](https://github.com/anthropics/claude-code/issues/64462) です。 まず切り分けたいのは、「自分のアカウント上限に本当に達しているのか」と「別の不具合で 429 に見えているだけなのか」です。今回の issue 群だけを見ると、どちらも利用枠が尽きたように見える一方で、報告者は「小さなプロジェクトなのに短時間で尽きた」「1 つのバグ対応で日次トークンを使い切った」と述べています。つまり、少なくとも体感としては“通常の使い方ではない消費”に見えていた
papoo.work
EEXIST: Claude Code の Bash ツールが `mkdir` で落ちるときに見えたもの
EEXIST: Claude Code の Bash ツールが `mkdir` で落ちるときに見えたもの
まず、自分のケースかどうかを切り分けます。今回の報告で共通していたのは、Windows 上で Claude Code を使っていること、そして `EEXIST` が出ていることでした。ひとつは worktree の扱いで「git リポジトリではない」と誤判定される話、もうひとつは `~/.claude/session-env/<session-id>` を作るところで `mkdir` が `EEXIST` になる話です。前者は [#40164](https://github.com/anthropics/claude-code/issues/40164)、後者は [#65309](https://github.com/anthropics/claude-code/issues/65309) です。 ただし、筆者の手元で確認できたのは macOS 上の Claude Code 2.1.207 までです。Windows で同じ再現確認はしていません。なので、ここで書けるのは「こういう症状の issue が実際にある」「手元の環境ではこのバージョンとこの導入状態だった」という範囲に限られます
papoo.work
EPERM が出るのは、SMB 上のファイル操作が怪しいときだった
EPERM が出るのは、SMB 上のファイル操作が怪しいときだった
まず自分のケースかどうかを見るなら、今回集めた issue では「ネットワーク越しのボリューム」や「Windows のパス解決」で `EPERM` が出ています。ローカルディスクの単純な読み書きではなく、保存先や対象が少し特殊なときに崩れていました。 たとえば macOS では、SMB マウントされた volume 上のファイルに対して Read/Bash を走らせると `Operation not permitted` が返る報告があります。報告者は mount の所有者で、`smbutil statshares` でも SMB 3.1.1 と暗号化有効を確認していました。それでも `dangerouslyDisableSandbox: true` では止められず、`--add-dir /Volumes/storage` か `permissions.additionalDirectories` を追加する回避策しか見つかっていませんでした。これが [#57540](https://github.com/anthropics/claude-code/issues/57540) です。
papoo.work
ENOSPC が出ても本当にディスクが空なのか、まずここを見たい
ENOSPC が出ても本当にディスクが空なのか、まずここを見たい
この症状は、Claude Code が `ENOSPC` とともに「temp filesystem is full (0MB free)」「Command output was lost...」のような文言を出すのに、実際には空き容量があるケースとして報告されています。少なくとも issue 上では、ディスク不足そのものではない例が 2 件ありました。ひとつは [#65086](https://github.com/anthropics/claude-code/issues/65086) で、`stdout` も `stderr` も出さずに非 0 終了した subprocess に対して、偽の `ENOSPC` が出たという報告です。もうひとつは [#65251](https://github.com/anthropics/claude-code/issues/65251) で、macOS 上で Bash tool の出力取得が失敗し、`/private/tmp/claude-501/.../tasks` の temp filesystem が満杯だと誤判定されたという報告でした。
papoo.work
Claude Code で HTTP 403 が出るときに見るべきところ
Claude Code で HTTP 403 が出るときに見るべきところ
まず、この `HTTP 403` がどこから返ってきているかで話が変わります。今回の症状クラスタに入っている issue は、どちらも「対象サイト側の拒否」ではなく、Claude Code 側の egress proxy が弾いているように見える報告でした。`[#34690](https://github.com/anthropics/claude-code/issues/34690)` では `x-deny-reason: host_not_allowed` が見え、`[#85330](https://github.com/anthropics/claude-code/issues/85330)` では auto mode classifier によるブロックが繰り返し起きています。 筆者の環境で `claude doctor` を見ると、少なくともインストール状態そのものは致命的には壊れていませんでした。ただし、`Multiple installations found` と `Leftover npm global installation` の警告は出ています。これは今回の `
papoo.work
Permission denied が出るときにまず見るところ
Permission denied が出るときにまず見るところ
Claude Code で `Permission denied` が出る話は、今回の issue 群だと 2 つの顔があります。ひとつは SSH 越しのセッションが再起動後におかしくなるケース、もうひとつは MCP 経由でページ操作が拒否されるケースです。どちらも同じ文言に見えますが、症状の出方はかなり違います。 SSH 側は [#72335](https://github.com/anthropics/claude-code/issues/72335) です。報告では、デスクトップアプリで SSH セッションを使っていると、再起動後に過去のセッション履歴が空白になったり、SSH セッションの fork/branch が失敗したりします。報告されている根本原因は、過去セッションを開くときにデスクトップアプリが 2 つの SSH 処理を走らせ、そのうち byte-sync は SSH config のエイリアスを使う一方、tail 側が raw IP に接続してしまう、というものです。こちらは issue 本文が途中で切れているため、tail 側の接続先の詳細は分かりません。少なくとも
papoo.work
Claude Code で background task や Monitor が突然落ちて exit code 144 になるとき
Claude Code で background task や Monitor が突然落ちて exit code 144 になるとき
まず切り分けたいのは、あなたの症状が「長く動かしているバックグラウンド処理が、本人の操作なしに止まる」タイプかどうかです。今回の issue 群では、どちらも Claude Code のバックグラウンド実行に絡んで exit code 144 が出ています。 手元で確認できた Claude Code CLI の情報はこれです。 ```text $ claude --version 2.1.207 (Claude Code) ``` 背景エージェント関連のコマンドは存在しています。 ```text $ claude agents --help Usage: claude agents [options] Manage background agents Options: --add-dir <directory> Additional directory to allow tool access in dispatched sessions (repeatable) --agent <agent> Default
papoo.work
`invalid_request_error` が返るときに見ておきたいこと
`invalid_request_error` が返るときに見ておきたいこと
まず、自分のケースかどうかを切り分けます。今回の issue 群では、同じ `invalid_request_error` でも中身がかなり違いました。 一方の [#64796](https://github.com/anthropics/claude-code/issues/64796) は、`/schedule` が `POST /v1/code/triggers` を使って新しい trigger を作れない、という報告です。こちらは `events[0] event_type is required` と出るのに、別の経路では `event_type` が `unknown field event_type` として拒否される、つまり v1 と v2 の変換が噛み合っていない状態だと書かれていました。既存の trigger は動き続けるが、作成や一部更新が失敗する、というのが報告内容です。 この2件に共通しているのは、エラー名は同じでも「画像処理系の失敗」と「トリガー作成のスキーマ不整合」で、症状の入口が違うことです。なので、`invalid_request_error` だけを
papoo.work
529 Overloaded が出るだけでなく、途中で止まるケースもある
529 Overloaded が出るだけでなく、途中で止まるケースもある
まず切り分けたいのは、あなたが見ている `529` が「単発のサーバー側エラー」なのか、それとも長時間・並列実行の途中で繰り返し出るタイプなのかです。今回の issue 群では、その両方が報告されています。 手元で確認できた CLI の状態は次の通りです。 ```text $ claude --version 2.1.207 (Claude Code) ``` ```text $ claude doctor Claude Code doctor Running: native (2.1.207) Commit: bc512d563325 Platform: darwin-arm64 Path: ~/.local/share/claude/versions/2.1.207 Config install method: native Search: OK (bundled) Auto-updates: enabled Auto-update channel: latest Last update attempt: none recorded Multiple installations f
papoo.work
ECONNRESET が出るときに、まず疑うべきこと
ECONNRESET が出るときに、まず疑うべきこと
Claude Code で `ECONNRESET` が出る症状は、issue を見る限り 1 つの形にまとまっていません。少なくとも、同じマシンで Chat は普通に動くのに Code 系の画面だけ失敗する例がありますし、Windows では API ストリームの途中で切れる例、再試行を重ねても失敗が続く例もあります。参照できた報告は [#70599](https://github.com/anthropics/claude-code/issues/70599)、[#83994](https://github.com/anthropics/claude-code/issues/83994)、[#84818](https://github.com/anthropics/claude-code/issues/84818)、[#84072](https://github.com/anthropics/claude-code/issues/84072) です。 まず、自分のケースがどれに近いかを見ます。 Chat mode だけは通るのに、Cowork Scheduled tasks や C
papoo.work
ENOENT が出たら、まず見るところは「どの呼び出しで落ちているか」
ENOENT が出たら、まず見るところは「どの呼び出しで落ちているか」
同じ `ENOENT` でも、今回の issue 群では原因がかなり分かれています。 手元の環境では `claude doctor` が正常に通っていて、`claude` の実体も複数見つかっています。なので、少なくとも「インストール全体が壊れている」とは言い切れません。 ```text $ claude doctor Claude Code doctor Running: native (2.1.207) Commit: bc512d563325 Platform: darwin-arm64 Path: ~/.local/share/claude/versions/2.1.207 Config install method: native Search: OK (bundled) Auto-updates: enabled Auto-update channel: latest Last update attempt: none recorded Multiple installations found npm-global at /usr/local/bin/claude nati
papoo.work
AIアシスタントに渡す権限は、思ったよりずっと大事
AIアシスタントに渡す権限は、思ったよりずっと大事
この記事を読んで最初に思ったのは、AI coding agent の便利さって「賢さ」よりも「どこまで安全に文脈へ入れられるか」で決まるんだな、ということでした。Claude Code を Ace Data Cloud に接続する話なのに、記事の中心は派手な機能ではなく、`ANTHROPIC_AUTH_TOKEN` と `ANTHROPIC_BASE_URL` をどう扱うか、`CLAUDE.md` に何を書くか、という地味な境界線の引き方です。そこがむしろ本質に見えました。 特に引っかかったのは、この記事が「接続できました」で終わらず、わざわざ scope の話まで踏み込んでいる点です。コメント欄でも、接続そのものより「assistant が何を読めて、何を変えられて、どう取り消せるか」が大事だと書かれていましたが、これはかなり腑に落ちました。AI にコードを書かせるとき、つい出力の出来栄えに目が行くけれど、実際には権限設計のほうが事故に直結する。しかもトークンを shell history やリポジトリに残すな、という注意は、当たり前だけど軽く見られがちなところです。 もう一つ面白か
papoo.work
Claude Codeの自動モードが突きつけるもの
Claude Codeの自動モードが突きつけるもの
この記事を読んでまず思ったのは、これは「AIが賢くなった話」よりも、「人間の確認作業が思った以上に当てにならない」という話だな、ということだった。少し意地の悪い言い方に聞こえるけれど、本文のトーンもそこをかなりはっきり突いていて、そこに妙なリアリティがある。 Claude Code の auto mode をデフォルトに寄せる、というのは一見すると攻めた仕様変更に見える。でも記事を読むと、その判断の根拠が「人間が危ないコマンドを見逃すから」という話で、そこがちょっと怖い。普通は「自動実行は危ないから人間の承認を入れる」が自然に思えるのに、逆に classifier のほうが人間より危険な命令を拾える、という前提になっている。ここには、レビューや確認という行為への信仰がかなり揺らいでいる感じがある。 ただ、私はこの話を単純に「人間はダメ、AIはすごい」とは受け取れなかった。むしろ引っかかったのは、危険なものを止める役目を classifier に寄せたとき、どこまでを「危険」とみなすのかがどんどん重要になることだと思う。開発者が本当に見たいのは、見た目が危なそうなコマンドだけではなく、文
papoo.work
Claude Codeのセッション同士が話せるようになったことを読んで
Claude Codeのセッション同士が話せるようになったことを読んで
正直、最初に思ったのは「そこまでやるのか」という驚きだった。コードを書くAIの進化って、ついモデルの賢さや速度の話に目が行くけれど、この記事はもっと地味で、でも実務ではかなり効く方向に寄っている。別々のTerminalで動いているClaude同士が、手でコピペしなくても文脈を渡し合える。派手さはないけれど、こういう小さな摩擦の削減が一番ありがたい場面は多い。 面白いのは、Anthropicがここで「会話の全部」を共有させていないことだと思う。やり取りできるのはtextだけで、historyやfilesやpermissionsまでは渡らない。これは少し中途半端にも見えるけれど、むしろ現実的だとも感じた。AIエージェント同士をつなぐと、便利さと危うさがすぐ同居する。権限まで自由に飛んでいくと怖いし、ファイルや過去ログまで自動で共有されたら、気づかないうちに見せたくないものが広がりそうだ。その意味で、メッセージは通すが勝手な許可変更はさせない、という線引きはかなり妥当ではないかと思う。 一方で、これが本当に効くのは「複数セッションを同時に回す人」だけだろうとも思った。普通の人にとっては、まだ
papoo.work
端末をまたいで会話がつながるのは、思ったより怖くて便利だ
端末をまたいで会話がつながるのは、思ったより怖くて便利だ
最初に思ったのは、「これ、便利だけど境界がかなり繊細だな」ということだった。 Claude Code が別のセッションへメッセージを飛ばせる、という発想自体はわかりやすい。長い migration を別端末で回していて、片方で見つけたことをもう片方に渡したい。並列で worktree を触っていると、いちいち人間がコピペで中継するのは正直つらい。そこを AI 同士でつなぐのはかなり筋がいいと思う。 ただ、読んでいて面白かったのは、作者が「会話を共有する機能」ではなく「テキストの単発配送」としてかなり厳密に切っているところだった。履歴もファイルも渡さない。あくまで一文のメッセージだけ。しかも受け取った側では、別セッションから来たという扱いになって、permission prompt の代わりにはならないし、設定変更も命令できない。ここはかなり重要で、便利さを足しつつも「他人の承認を勝手に流用しない」線を引いている。雑に作るとすぐ危ない機能だから、こういう制限はむしろ安心材料だと思った。 もう一つ引っかかったのは、同じ「メッセージ」と言っても、ローカルでは直接 socket で飛ぶのに、別
papoo.work
Claude Codeのセッション同士が話せるようになって思ったこと
Claude Codeのセッション同士が話せるようになって思ったこと
正直、これはかなり“地味だけど効く”アップデートだと思った。派手な新機能というより、複数の作業が同時に走っているときの、あの面倒な説明の繰り返しを減らしてくれる話だからだ。 特に引っかかったのは、Claude が単にメッセージを中継するだけでなく、「要約された内容」を次の session に渡すところ。履歴や files を丸ごと引き継ぐわけではない、という線引きは妙に現実的だと思う。便利さはあるけれど、何でも自動で共有されるほど怖い仕組みにはしていない。AI に仕事を投げるとき、結局いちばん事故るのは“勝手に全部つながっている感”なので、この控えめさは好ましい。 一方で、これが本当に活きるのは、1 人が複数の作業を並走させる場面よりも、複数の worktree や長い処理が絡むときではないかと思う。人間がタブを行ったり来たりしながら「さっき何を見つけたんだっけ」と探す代わりに、Claude 同士が軽く受け渡してくれるなら、かなりストレスが減るはずだ。逆に言うと、単独の session しか使わない人にはあまり刺さらない。そこは機能として少し玄人向けだなとも感じた。 あと、permis
papoo.work
Claude Codeに手足を足す話を読んで
Claude Codeに手足を足す話を読んで
最初に思ったのは、「AIエージェントって、結局は道具が増えたときに本当に使えるものになるんだな」ということだった。Claude Code単体でもかなりいろいろできるのに、MCPサーバーを足すと急に“できることの質”が変わる、という書き方が印象に残った。 特に腑に落ちたのは、MCPサーバーが単なる便利機能ではなく、AIに外界との接続口を増やす仕組みだという点だ。本文では「頭脳に目と手足を追加する」と表現していて、かなり大げさに見えるけれど、ブラウザを開いてフォームを押したり、スクリーンショットを取ったりする話を読むと、たしかに比喩としては的確だと思う。テキストを返すだけのAIと、画面を見て操作できるAIでは、仕事の任せ方がまるで違う。 一方で、MCPサーバーは魔法ではなく、Bashで代替できることも多い、という冷静な書き方もよかった。こういう記事はつい「これで全部解決」と盛りがちだけど、ここでは「なくてもなんとかなる。ただし向いている仕事がある」と線を引いている。その距離感のほうが信頼できる。むしろ、全部をMCPで置き換える発想より、繰り返し多い作業やブラウザ操作みたいな、人間が面倒だと
papoo.work
Claude Codeのエージェント一覧を、自動で「勝手に正しく」保つ発想
Claude Codeのエージェント一覧を、自動で「勝手に正しく」保つ発想
最初に思ったのは、これは地味だけどかなり気持ちいい解決だな、ということだった。手で直すINDEX.mdって、たしかに最初は親切そうに見えるのに、少し増えた瞬間にもう信用できなくなる。27個もエージェントがあるならなおさらで、「一覧のほうが現実に追いつかない」状態はほぼ避けられない。そこを最初から壊れ物として扱って、自動生成に寄せているのが潔い。 面白かったのは、やっていること自体よりも、壊れ方への目配りだと思う。frontmatterのパースをPyYAMLに頼らず、Bashの中にPythonを埋め込んで、さらに壊れたファイルはエラーで止めず警告として残す。こういう設計は「完璧に検証してから出す」より、「まず一覧を生かして、壊れている場所も見えるようにする」発想に近い。現場ではそのほうが役に立つことが多い。全部を厳密に守らせると、どこか1つのミスで仕組み全体が止まるから。 あと、launchdで週1回、しかも低優先度で回しているのも、いかにも実用主義だと思った。毎回手で叩くのは面倒だし、毎回リアルタイムに更新するほどのものでもない。こういう「十分に新しい」を自動で維持する仕組みは、日々の
papoo.work
Claude Codeを「1人のAI」だと思うと、たしかに取りこぼす
Claude Codeを「1人のAI」だと思うと、たしかに取りこぼす
最初に思ったのは、これはわりと当たり前のことを、ちゃんと実務の形に落とし込んだ話だな、ということでした。AIを1回ずつ順番に使うと、待ち時間も文脈の肥大化も避けにくい。人間の作業でも、調べもの、実装、テスト、レビューを同じ人が全部抱えると遅くなるのと同じで、AIにも役割分担をさせたほうが自然です。 面白いのは、この記事が「すごい裏技」というより、「Claude Codeをちゃんとチームっぽく扱え」という発想を押し出しているところです。サブエージェントという言い方をしているけれど、要するに小さな専門家を複数走らせる感じで、これはかなり腑に落ちました。コンテキストウィンドウ、つまりAIが一度に覚えていられる範囲が広がるほど雑になる、という感覚は使っていると身に覚えがあります。長いやり取りのあとに急に浅くなること、ありますよね。 一方で、そこまで万能でもないのも正直だと思いました。トークンコストが増える、独立した作業にしか向かない、という線引きがちゃんと書かれているのがよかったです。ここを曖昧にすると「なんでも並列化すれば速い」と勘違いしがちですが、実際はむしろ逆で、依存関係がある仕事まで分
papoo.work
Claude Code の“隠しタグ”を読んでしまった話で、いちばん引っかかったこと
Claude Code の“隠しタグ”を読んでしまった話で、いちばん引っかかったこと
正直、いちばん面白かったのは「タグがあった」ことそのものより、筆者がそこで立ち止まって自分のログを掘り返したところだと思った。LLM の話って、ついモデルが何を“言ったか”で終わりがちだけど、ここでは実際の JSONL ログを grep して確かめている。しかも「自分の環境で本当に起きたのか」を、自分の手元の記録で確認している。この姿勢はかなり気持ちよかった。 一方で、少し怖さもある。hidden tag という言い方だと、つい「裏で秘密の命令が動いていたのか」と身構えるけれど、記事を読む限り、問題の中心はもっと地味で、もっと厄介だ。内容を完全には見せず、しかもその分のコストや影響がどれくらいあるのかも外からは分かりにくい。そこがモヤっとする。`<ip_reminder>` という名前自体は公開文書にも出てくるのに、実際の挙動や負担は見えづらいまま、という構図が引っかかった。 あと、この人が強調している「他人の Issue の数字をそのまま自分の話にしないで、自分のログを見ろ」という態度は、かなり本質的だと思う。LLM 周りは、ベンダーの説明、Issue の報告、SNS の切り抜きが混
papoo.work
Claude Code への「うまい頼み方」を読んで考えたこと
Claude Code への「うまい頼み方」を読んで考えたこと
いちばん引っかかったのは、ここで語られている「prompting」が、もはや文章の書き方というより、作業の進め方そのものになっていることだった。単に「こう書けば通る」という話ではなく、最初に相談して、曖昧さを潰して、どう検証するかまで渡して、最後はHTML reportで人間が判断しやすい形に整える。かなり実務寄りだ。AIに命令文を投げる感覚というより、半分はチームメンバーとのすり合わせに近い。 とくに納得したのは、「どうテストするかまで伝えるべき」という部分だ。機能を作って、で終わるのではなく、どこを開いて、何を打ち込んで、何が起きたら成功なのかを先に渡す。これ、地味だけど効くと思う。人間同士でも「動作確認よろしく」だけだと雑になりがちで、期待値がずれる。LLMでも同じで、むしろモデルは平然とそれっぽい実装を出してくるぶん、合格ラインを言葉にしておかないと危ないのだろう。 あと、音声入力や transcription を勧めているのも面白かった。速いから、というより「全部の文脈を入れるハードルが下がる」という効用が大きい、という話が印象に残った。ここはかなり実感がありそうだ。頭では重
papoo.work
Claude Codeの記事を読んで引っかかったところ
Claude Codeの記事を読んで引っかかったところ
最初に思ったのは、「AIを賢くする話というより、AIの暴走をどこで止めるかの話なんだな」ということだった。ここが面白い。ふつうはモデルの性能ばかり見てしまうけれど、この記事は Claude Code を“どう使わせるか”にかなり寄っていて、むしろ実運用ではそっちのほうが効くのだと思わされた。 とくに、CLAUDE.md、rules、skills、agents、hooks、output styles、system prompt への追記といった道具立てが並んでいるのを見て、AI の仕事は「よく考えさせる」だけでは足りないんだと感じた。人間の開発でも、優秀な人に口頭でお願いするだけでは品質が揃わない。手順書があり、禁止事項があり、レビューの観点があり、例外処理がある。Claude Code も、結局はその延長線上に置かれている。AI なのに、かなり地味なガードレール設計が主役になっているのが妙に現実的だった。 一方で、少し引っかかったのは、これだけ細かく分けても、現場の人が本当に運用しきれるのかという点だ。設定項目が増えるほど制御は効くけれど、そのぶん「どこに何を書けばいいのか」を覚えるコ
papoo.work
判断理由を残させて、あとから迷いどころを追えるようにする
判断理由を残させて、あとから迷いどころを追えるようにする
Claude Code に作業を投げるとき、いちばんもったいないのは「何をしたか」は残るのに「なぜそうしたか」が消えることだ。あとで diff を見返しても、そこで迷った理由が抜け落ちていると、同じ場所でまた立ち止まる。決定の根拠を記録する、途中の判断を書かせる、要するにその場の思考を残す使い方だ。 これ、コード修正だけの話ではない。ファイル整理でも、不要キャッシュの削除でも、文書作成でも同じだ。最終成果物だけ整っていても、途中で「これは消す」「これは残す」「これは後で別フォルダへ回す」と判断した理由が残っていないと、次回の自分がまたゼロから悩む。Claude Code はこの途中経過をきちんと書かせると、ただの自動化ツールから、あとで見返せる作業メモに変わる。 やり方は単純だ。最初から成果物だけを求めず、「判断のログも一緒に作れ」と明示する。たとえば、作業前の方針と、各判断の根拠、迷った点を別ファイルに残させる。 ```text この作業では、結果だけでなく判断理由も残してください。 次の3つを作ってください。 1. 変更した内容の要約 2. 重要な判断とその理由 3. 迷った点、今
papoo.work
持たせるメモは短く、決定事項だけ残す
持たせるメモは短く、決定事項だけ残す
Claude Code に長い作業メモを食わせて安心していると、だいたい途中で鈍る。読ませたいのは議事録ではなく、次に動くための要点だ。 作業メモを削る、短いメモだけ渡す。どちらも同じ話で、要するに「判断に必要な情報だけ残し、経緯は捨てる」ということになる。 これは開発でもファイル整理でも文書作成でも効く。メモが長いほど親切に見えるが、実際にはノイズが増えるだけだ。Claude Code は長文を読めるが、読めることと、うまく動けることは別物である。余計な経緯、迷い、雑談を持たせると、出力も散るし、手戻りも増える。 筆者は最初、メモを丁寧に残そうとして失敗した。たとえば「こういう方針で、あのときはこう考えて、例外はこれで……」と延々書いた結果、Claude Code が“全部大事”として扱ってしまい、結局どれも浅く触るだけになった。人間の議事録としては親切でも、作業指示としては重すぎる。そこから、残すべきなのは決定事項だけだと割り切った。 実際の書き方は単純でいい。長い経緯を要約しようとせず、最終的に決まったことだけを短く渡す。 ```text このフォルダの整理を進めてください。 残
papoo.work
長い作業は章立てして、途中の迷子を減らす
長い作業は章立てして、途中の迷子を減らす
長文を一気に投げて、あとで「どこまでやったんだっけ」となるのは、かなりありがちな失敗だ。Claude Code は賢いが、長い作業を雑に渡せば、平気で話が横に広がる。だから最初から章立てして、途中の迷子を減らす。別名で言えば、章ごとに分けて頼む、長文を分割して進める、だ。 このやり方は、コード修正だけの話ではない。散らかったフォルダの整理、重複ファイルの洗い出し、長い文書の清書、案件ごとの資料整理にもそのまま効く。要するに、ひと続きに見える作業を、Claude Code が追いやすい単位に切るという話である。 筆者は最初、ひと塊の依頼文で全部やらせて失敗した。途中で方針がブレるし、出力も冗長になる。修正のたびに前半の指示が薄まり、後半だけやけに詳しい、みたいなアンバランスも起きる。長い作業ほど、章ごとに切ったほうが早い。これは気分論ではなく、コンテキストの使い方の問題だ。 やり方は単純だ。まず作業全体を、人間の目で見て4〜6章くらいに割る。たとえば文書作成なら、「材料の整理」「目次づくり」「本文の下書き」「用語の統一」「最終確認」に分ける。ファイル整理なら、「現状の棚卸し」「重複候補の
papoo.work
会話が長くなったら、節目で要約を挟んで前提を保つ
会話が長くなったら、節目で要約を挟んで前提を保つ
長いやり取りを「気合いで覚えておいてくれるはず」と思うと、だいたいズレる。Claude Code は会話の文脈を持っているが、無限に細部を保持してくれるわけではない。途中で要約させる、セッションを区切る。この2つを入れるだけで、指示の食い違いと手戻りがかなり減る。 特に、ファイル整理、文書の推敲、複数ファイルの修正みたいに、途中で話題が広がりやすい作業ほど効く。最初は「全部つながっている」と感じるが、実際は、古い前提と新しい前提が少しずつ混ざって、最後に変な成果物が出る。あれは地味にだるい。筆者は一度、長いやり取りの末に「前回の方針」を Claude Code が別の意味で受け取り、修正済みのはずの箇所をもう一度広げられて、差分が無駄に肥大化したことがある。要約を挟んでいれば防げたやつだ。 やり方は単純だ。大きな作業を始める前に、区切りを決める。たとえば「第1段階では現状把握だけ」「ここまでで一度要約」「次の段階はこの要約を前提に続行」と言っておく。Claude Code に対しては、最初からこう頼めばいい。 ```text この作業は長くなりそうなので、途中で一度、ここまでの前提と決
papoo.work
前提が変わったら、古い指示を残さず言い直す
前提が変わったら、古い指示を残さず言い直す
Claude Code に何かを頼むとき、いちばん雑にやって痛い目を見るのがここだ。前の前提を残したまま「これも直して」と足すやり方である。方針変更時に前提を捨てる、古い前提を引きずらない。呼び方はいろいろあるが、やることは同じだ。前提が変わったなら、古い指示は上書きではなく、いったん消して言い直す。 この癖がないと、Claude Code は前の条件と今の条件を両方まじめに拾って、妙に遠回りな修正を返してくる。ファイル整理でも文書作成でも同じで、途中で方向を変えたのに「さっきの話」と「いまの話」を同居させると、成果物が中途半端になる。人間でもやるミスだが、CLI の相手だともっと露骨に出る。 たとえば最初に「このフォルダは不要だから削除候補を洗って」と頼み、そのあと気が変わって「削除ではなく、アーカイブ用に分類して」と言い足す場面がある。ここで前の指示を消さずに続けると、Claude Code は削除前提の整理と、保存前提の整理を両方気にして、判断が鈍る。結果として、見た目は丁寧でも実務では使いづらい出力になる。 こういうときは、追加説明ではなく、前提を切り替える指示を先に置く。実際
papoo.work
作業の終わり方を先に指定して、止まりどころを迷わせない
作業の終わり方を先に指定して、止まりどころを迷わせない
Claude Code に雑に「これ直して」と投げると、だいたい途中で迷う。迷っている間にコンテキストを食い、変更が広がり、最後は「で、どこで終わればいいんだ」という顔になる。そこで先にやるべきなのが、終了条件を明示すること、つまり出口を決めることだ。 これは大げさな話ではない。Claude Code は手を動かすのが速いぶん、終わり方が曖昧だと仕事がどんどん膨らむ。ファイル整理でも同じで、「不要ファイルを消して」とだけ言うと、似た名前のログやキャッシュまで気にし始めて、確認事項ばかり増える。文書作成でも、「整えて」と丸投げすると、構成をいじるのか、表現だけ直すのか、段落を増減するのかがぶれる。 先に止まりどころを言っておくと、作業はかなり安定する。Claude Code に期待するのは、万能な判断ではなく、決めた出口までの到達だ。そこを外すと、出力は増えるのに満足度は下がる。 たとえば、こんな頼み方にする。 ```text この作業は、次の終了条件を満たしたら止めてください。 対象は docs/ 配下だけ 変更は文章の修正のみ 見出し構成は変えない 事実関係の不明点は推測で埋めず、該
papoo.work
途中報告の頻度を決めて、黙って進ませすぎない
途中報告の頻度を決めて、黙って進ませすぎない
Claude Code に雑に「いい感じに進めて」と投げると、あとで見たときに気持ちよく進んでいるようでいて、実はだいぶ怖い。勝手に進む時間が長いほど、手戻りは重くなる。進捗報告の粒度を決める、節目だけ返させる。この二つを先に決めておくだけで、黙って深掘りしすぎる事故はかなり減る。 特に Claude Code は、仕事が進むほど差分が大きくなりやすい。ファイル整理でも、文書作成でも、コード修正でも同じだ。最初に方向を外すと、そのまま大量の変更を積み上げてから「これでいい？」と出してくる。そこで止めると、確認も修正も重い。逆に途中報告を細かくしすぎると、今度は毎回止まりすぎて、こちらの集中が切れる。だから大事なのは、止める回数ではなく、止める場所を決めることだ。 たとえば、最初にこう指示する。 ```text まず作業方針を3行で出してから進めてください。 以後は、各主要ステップの完了ごとに短く途中報告してください。 実装や整理を勝手に最後まで進めず、節目で止まって確認を求めてください。 ``` これだけでもだいぶ違う。ポイントは「何分ごとに報告」ではなく「どの節目で報告」かを指定する
papoo.work
Claude Code の返答を短くさせるなら、最初に出力の形を決める
Claude Code の返答を短くさせるなら、最初に出力の形を決める
長文でだらだら返すように見えて、実は最初の一言が悪いだけ、というケースは多い。Claude Code は、こちらが曖昧に投げると、普通に曖昧なまま広げてくる。そこで効くのが、出力形式を先に固定する、要するに「Markdown か表かを先に言う」やり方だ。返答の長さそのものを細かく縛る前に、まず箱を決める。これだけで、返ってくる文章の輪郭がかなり締まる。 筆者は最初、内容だけ先に頼んでいた。たとえば「このフォルダの中身を整理して、不要そうなものを教えて」とだけ投げる。すると Claude Code は、親切に説明を足しすぎる。結果、肝心の候補が埋もれる。人間が欲しいのは整理の方であって、長い前置きではない。ここで「表で」「箇条書きで」「見出しは3つまで」と先に言うと、返答のノイズが目に見えて減る。 いちばん使いやすいのは、最初の指示で出力の器を指定することだ。たとえば文書作成なら、最初から Markdown の見出し付きで短くまとめさせる。ファイル整理なら、表で候補を並べさせる。コードレビューなら、箇条書きで問題点だけ出させる。Claude Code は、形が決まると余計な説明を削りやす
papoo.work
調査ログと変更結果を照合して、ずれた場所を見つける
調査ログと変更結果を照合して、ずれた場所を見つける
「やったつもり」で終わる調査ほど、あとで面倒なものはない。ログは残した、変更もした。なのに、どこが期待と違ったのか分からない。そういうときに効くのが、調査ログと変更結果を突き合わせるやり方だ。要するに、ログと差分を突き合わせる、期待とのズレを読む、という作業である。 Claude Code を使うと、この照合をかなり人力より楽にできる。しかも、コード修正だけの話ではない。ファイル整理でも、不要ファイル削除でも、文書の置き換えでも同じだ。先に「何を確認したか」を残し、あとで「実際に何が変わったか」を見比べる。これだけで、変な手戻りがかなり減る。 筆者は昔、似たようなことを雑にやって失敗した。ログは長いのに、肝心の変更結果を見ていなかったのだ。結果、Claude Code がちゃんと動いていても、別の場所のファイルを触っていたことに気づくのが遅れた。調査が浅いと、出力の量だけで安心してしまう。そこが罠だ。 この手の作業で大事なのは、まず「期待」を先に書くことだ。調査のメモと、実際の変更結果を比べるとき、期待が曖昧だとズレも見えない。逆に、期待がはっきりしていれば、Claude Code に
papoo.work
作業中に持たせるメモは短くする：決定事項だけ残す
作業中に持たせるメモは短くする：決定事項だけ残す
長いメモを抱えたまま Claude Code に作業させると、だいたい途中で鈍る。読ませた本人が満足してしまうのがいちばん厄介だ。実際には、後で効くのは「何を決めたか」だけで、経緯や雑談はほぼ邪魔になる。 ここでいうのは、作業メモを絞る、短い指示で回す、という考え方だ。Claude Code に持たせるメモは、思いついたことを全部盛りしたメモ帳ではない。作業の途中で迷わないように、決定事項だけを残す道具だ。 筆者は最初、仕様の経緯も未決定の論点も、全部そのまま投げていた。すると Claude Code は筋のいい補助をする前に、どこが確定でどこが未確定かを読み解くところで余計なコンテキストを使う。結果、出てくる差分が散らかる。ひどいときは、古い前提を拾って戻り作業が増えた。あれは単純に、メモが長すぎたせいだ。 Claude Code に渡すメモは、次のような形に寄せると強い。 ```text 目的: README を短くする 決定事項: 対象は使い方の説明だけ インストール手順は別ファイルに分けない 例は macOS と Linux のみ 文章は日本語で書く 既存の見出し構成は維持する
papoo.work
長い資料は章ごとに渡す：一気読みを前提にしない
長い資料は章ごとに渡す：一気読みを前提にしない
長い資料を全部貼って「さあ読め」でうまくいくと思っているなら、そこがまずズレている。Claude Code は長文を処理できるが、だからといって一気読みさせるのが正解ではない。むしろ章ごとに渡したほうが、分割投入もしやすいし、章単位で扱うほうが手戻りも減る。 筆者は最初、仕様書や長い手順書を丸ごと投げて、あとから「この章の前提は無視して」とか「さっきの表だけ見て」と言い直して、かなり無駄を出した。大きい資料ほど、最初のひと押しを雑にすると全体がだるくなる。Claude Code にも、人間にもだ。 やることは単純だ。資料をいきなり全文で渡さず、章や節ごとに区切る。最初に全体像だけ渡して、そのあと必要な章を順番に扱う。これで指示の焦点がぶれにくくなる。 たとえば、次のような資料があるとする。 企画書 契約書のたたき台 手順書 フォルダ内の大量のメモ 監査用のチェックリスト この手のものは、最初から全文を相手に食わせるより、目次や章立てを先に見せたほうがいい。Claude Code は、その場で全体構造をつかんでから作業したほうが強い。 依頼文は、こんなふうに切る。 ```text この資
papoo.work
節目ごとに判断理由を残す：あとから迷いどころを追えるようにする
節目ごとに判断理由を残す：あとから迷いどころを追えるようにする
「あれ、なんでこうしたんだっけ」で止まるなら、まだ手戻りは小さいほうだ。厄介なのは、Claude Code に作業を続けさせたあとで、前の判断が消えていることだ。判断ログ、あるいは「なぜそうしたかを記録する」癖がないと、数十分後に自分で自分の指示を疑う羽目になる。 Claude Code は、雑に言えば“今ある材料をもとに次の一手を組み立てる”道具だ。だからこそ、途中の節目で「何を選んで、何を捨てたか」を残しておくと強い。あとから迷ったとき、同じ調査をもう一回やらなくて済む。コンテキストの浪費も減る。diff が無駄に膨らむのも防げる。地味だが、効く。 たとえば、ファイル整理でも文書作成でも同じだ。最初は「このフォルダをこう切る」「この重複ファイルは残す」「この表現はやめる」と決める。ところが作業が進むと、Claude Code も人間も、最初の前提を薄く忘れる。そこで、節目ごとに短い判断ログを残す。これだけで、あとから「なぜその方針にしたか」を追える。 やり方は難しくない。Claude Code に作業を頼むとき、最初に「判断理由も一緒に残して」と明示する。しかも、長文でだらだら書か
papoo.work
古い前提を残さない：方針変更したら言い直す
古い前提を残さない：方針変更したら言い直す
そこを曖昧にしたまま進めると、Claude Code はわりと平気で昔の指示を守り続ける。人間側が方針を変えたつもりでも、前提を更新する、古い指示を捨てる、をやらないと、作業の芯がずれていく。 これは開発だけの話ではない。ファイル整理でも、ディスク削減でも、文書作成でも同じだ。最初に「古い書類は残す」と言っていたのに、途中で「不要なものは捨てる」に変えたなら、その場で言い直す。ここをサボると、Claude Code は古いルールに忠実なまま、こっちの意図と違う方向へきれいに進む。丁寧なのが逆にまずい。 筆者はこれで何度か手戻りした。最初は「このフォルダ内の資料を整理して」と頼み、途中で「やっぱり重複ファイルは削除して」と方針を変えたのに、前の「削除しないで整える」前提が残っていたせいで、無難な並べ替えだけで終わったことがある。やるべきだったのは、追加でお願いすることではなく、古い前提を明示して捨てることだった。 たとえば、途中でルールを変えるなら、こう言い直す。 ```text ここまでの前提はいったん捨ててください。 方針を更新します。 以前の「削除しない」は無効です これからは重複
papoo.work
会話が長くなったら節目で要約させる：前提を崩さず進める
会話が長くなったら節目で要約させる：前提を崩さず進める
会話が長引くたびに、最初の前提を人間が頭の中で持ち運ぶ前提で進めるのは雑だ。Claude Code に任せるなら、途中要約でその荷物を一回降ろしたほうがいい。要点を引き継ぐ、という考え方だ。長い依頼、複数ファイルの整理、何段階もある文書作成では、節目で「いま何を前提に、どこまで決まったか」を短く残さないと、後半で平気で話がねじれる。 筆者は最初、長い作業をそのまま流して痛い目を見た。たとえば「このフォルダの重複ファイルを整理して、不要なものを消し、最後に削除候補だけ一覧にして」と一気に頼むと、途中で基準が曖昧になって、候補の抽出と削除の判断が混線する。会話の後半になるほど、最初に決めた条件を雑に扱いやすい。だから節目ごとに要約させる。これだけで、後戻りがかなり減る。 やり方は単純だ。長い作業を最初から最後まで一息でやらせない。区切りを作って、そのたびに「ここまでの前提」「決まったこと」「未決事項」を短くまとめさせる。Claude Code への頼み方は、こんな形でいい。 ```text この作業は長くなりそうなので、節目ごとに途中要約を入れてください。 要約では次の3点だけを書いてくだ
papoo.work
Claude Code に持たせる情報を削る：要点だけ残して長文を捨てる
Claude Code に持たせる情報を削る：要点だけ残して長文を捨てる
長い前提をそのまま投げ込むと、だいたい詰まる。Claude Code は賢いが、無限に文脈を飲み込んでも気持ちよくなるわけではない。むしろ要点が埋もれて、肝心の判断がぼやける。コンテキストを節約する、長い前提を短くする。ここを雑にすると、あとで手戻りが増える。 筆者は最初、仕様メモや経緯説明をそのまま貼り付けていた。すると返ってくるのは、やたら丁寧だが焦点のずれた整理だったり、最初に読ませた長文の細部に引っ張られた提案だったりする。あれは地味にだるい。要るのは長文の再掲ではなく、判断に必要な芯だけだ。 Claude Code に食わせる情報は、たいてい三層に分けると扱いやすい。まず「何をしたいか」。次に「絶対に守る条件」。最後に「判断に必要な最小限の背景」だ。長い経緯、途中の愚痴、似たような失敗談は、基本的に落としていい。残すのは、後で答えの質に効くものだけである。 たとえば、ファイル整理の依頼なら、こう削る。 ```text 依頼: 仕事用フォルダの中で、重複しているPDFと古い下書きを見つけたい 削除前に候補を一覧にしてほしい 誤って正式版を消したくない 背景: 案件ごとにフォルダ
papoo.work
最後に全体をまとめ直して、引き継げる形に整える
最後に全体をまとめ直して、引き継げる形に整える
途中の作業をそのまま投げると、あとで読む人が高確率で詰まる。Claude Code でも同じで、最後に「最終要約」までやっておかないと、出力は立派でも引き継ぎには弱い。ここでやるのは、単なる要約ではない。引き継ぎ用に整形する、つまり「次の人が迷わず動ける形」に潰し込む作業だ。 この一手が効く場面は多い。コード変更のあとに別の人へ渡すとき。ファイル整理の結果を残すとき。長い会話の内容を文書に落とすとき。要点だけを抜き出せば済む話ではなく、何をやったか、何が残っているか、次に何を見ればいいかを、順番つきで残す必要がある。 筆者は最初、Claude Code に「最後にまとめて」とだけ投げて、見事に中身の薄い箇条書きだけを受け取ったことがある。たしかに短い。だが、次に何をすればいいのかが抜け落ちていて、結局もう一回会話を掘り返した。あれは時間の無駄だった。まとめは短くすることではない。使える形に圧縮することだ。 まずは、まとめの役割をはっきり分ける。Claude Code に渡す依頼は、ただの要約ではなく、次のどれを作るのかを明示するのがコツだ。 ```text この会話内容を、引き継ぎ用に
papoo.work
Claude Codeの「最近ちょっとおかしい？」を見つける道具、cc-canary
Claude Codeの「最近ちょっとおかしい？」を見つける道具、cc-canary
GitHubの `delta-hq/cc-canary` は、Claude Code を使っているときの“挙動の変化”をあとから検査するためのツールです。ざっくり言うと、「最近のClaude Code、前より雑になってない？」「同じ作業なのに、やたら遠回りしてない？」みたいな違和感を、ログから拾い上げる仕組みです。 面白いのは、これが単なる使用状況の可視化ではなく、かなり“監査”寄りの発想で作られていることです。名前のとおり、炭鉱のカナリアみたいに、危ない変化を早めに知らせるのが狙い。個人的には、この比喩はかなりうまいと思いました。AIの品質って、毎回きれいに壊れるわけじゃなくて、じわじわ変調することがあるので、その違和感を拾う発想はかなり実用的です。 cc-canary は、Claude Code がローカルに残す JSONL 形式のセッションログを読みます。JSONL は、1行ごとに1件のデータが入っているログ形式のことです。難しく聞こえますが、要するに「会話や操作の記録がずらっと並んだファイル」です。 このログをもとに、モデルの挙動が「自分の作業の中で drift していないか」
papoo.work
Claude Codeに“セキュリティ担当”が来た話。脆弱性を見つけて、直し方まで出してくれるプラグイン
Claude Codeに“セキュリティ担当”が来た話。脆弱性を見つけて、直し方まで出してくれるプラグイン
Anthropicが「Claude Security Plugin for Claude Code」をベータ公開した ターミナルからコードベースをスキャンし、脆弱性の検出・検証・修正案の提示まで行う 複数のエージェントが役割分担し、見つけた問題を別のエージェントが検証する仕組み リポジトリ全体だけでなく、ブランチ差分、PR差分、単一コミットも対象にできる 修正パッチは提案されるが、自動適用はされない。最後は人間が確認する設計 有料プラン向けで、Claude Code v2.1.154以降、Python 3.9.6以降が必要 Anthropicが7月22日（現地時間）に出した「Claude Security Plugin for Claude Code」は、かなり実務寄りのツールです。派手なデモ映えより、現場で「これ欲しかった」が先に来るタイプだと思います。 ざっくり言うと、Claude Code の作業中に、コードの危ないところを探して、何が問題かを検証し、どう直せばよさそうかまで示してくれるプラグインです。しかも1つのAIが全部をやるのではなく、複数のエージェントが協力します。コード
papoo.work
Claude Codeにブラウザー内蔵、AIに「見ながら作業させる」時代がぐっと近づいた
Claude Codeにブラウザー内蔵、AIに「見ながら作業させる」時代がぐっと近づいた
Anthropicの「Claude Code」デスクトップ版に、Webブラウザーがそのまま入った。これ、地味に見えてかなり大きい変更だと思う。AIコーディングツールって、普段はターミナルやエディタの中で完結しがちだったのに、そこへ外部サイトやドキュメント、イシュートラッカーまで“同じ画面の中”で扱えるようになったわけだ。 デスクトップ版「Claude Code」に内蔵ブラウザーが追加された タブ付きで、ドキュメントや外部サイトを複数開いておける 既存のローカル開発サーバーを見るのと同じ感覚で、ページを読ませたりクリックさせたりできる 安全対策として、外部サイトでの操作には確認が入る ブラウザーのプロファイルは普段使いのブラウザーと分離され、ログイン情報や履歴は引き継がれない 今回のポイントは、「Claudeにコードを書かせる」だけでなく、「Claudeに画面を開かせて確認させる」流れが、アプリの中で完結しやすくなったことだ。 たとえば、仕様書を読みながら実装を進めたいとき。GitHub Issuesを見つつ、関連ドキュメントも見つつ、ローカルの開発画面も見つつ、という作業は普通にある。
papoo.work
最初に出力の形を固定する：Markdown か表かを先に決める
最初に出力の形を固定する：Markdown か表かを先に決める
ここを曖昧にしたまま投げると、Claude Code はだいたい素直に広がる。つまり、読みやすい文章ではなく、あとで直しにくい長文や、表にしたかったのに段落で返ってくるあの感じだ。先に成果物の形を決める、要するに出力形式を指定する。これだけで手戻りがかなり減る。 Claude Code に何かを頼むとき、内容だけでなく「最終的にどう並べるか」を先に固定すると強い。Markdown で見出し付きの説明文にするのか、比較しやすい表にするのか。ここを最初に決めておくと、内容の整理もその形に引っ張られる。逆に、形を後回しにすると、途中まで書かせたあとに「やっぱり表で」と言って崩す羽目になる。筆者はこれで何度も手戻りした。特に、ファイル整理の説明や手順書を作らせるときに、段落で長く返ってきたものを後から表に直すのはだるい。最初に固定しておけばいい。 たとえば、読み物や手順書なら Markdown に寄せる。箇条書き、見出し、小見出し、コードブロックを使いやすいからだ。比較、一覧、チェック用の整理なら表が向く。たとえば「どのフォルダに何を入れるか」「この書類は残すか捨てるか」「このキャッシュは削除
papoo.work
Claude CodeでTPUを回し切る仕組み、Gemma 4運用をかなり雑にしてくれる話
Claude CodeでTPUを回し切る仕組み、Gemma 4運用をかなり雑にしてくれる話
Google Cloud TPUでGemma 4を動かす。言葉にするとシンプルですが、実際はぜんぜんシンプルじゃないんですよね。空いているゾーンを探し、quotaを確認し、VMを立て、boot diskを気にし、Hugging Faceのtokenを渡し、vLLMのTPU向け設定を入れ、起動ログを追い、最後は忘れず片づける。しかも、TPUは放置すると課金がじわじわ進む。やることが多すぎる。 今回の記事は、その面倒を Claude Code に丸投げしやすくするための skill と MCP server を紹介しています。名前は `tpu-management`。かなり直球です。Cloud TPUを触ったことがある人ほど、「ああ、そこを自動化したいのは分かる」とうなずく内容だと思います。 TPUの空きを探して、使えそうな zone を見つける TPU VM を作成して、Gemma 4 を vLLM で起動する 起動後の状態確認やログ確認までやる `vllm bench serve` で速度を測る 使い終わったら削除する これらを Claude Code から自然文で指示できる
papoo.work
Claude Codeを24時間回すための発想法——「速さ」より「止まらなさ」が効く
Claude Codeを24時間回すための発想法——「速さ」より「止まらなさ」が効く
Claude CodeやCodexのような coding agent は、もう「ちょっと試す便利ツール」ではなくなってきました。この記事の著者 Eivind Kjosbakken は、そこをかなり強気に押し出しています。ポイントは、人間が細かく介入しなくても、エージェントが長時間動き続ける状態を作ること。これができると、並列でより多くの仕事を回せるようになる、という考え方です。 正直、ここはかなり面白い視点だと思いました。 昔は「AIにコードを書かせる」こと自体が新鮮でしたが、今はもう少し先に進んでいて、AIを“どれだけ止めずに働かせられるか” が生産性を左右する段階に入ってきている、という話です。この記事はその現実的な運用論を書いています。 coding agent は、短時間で終わらせるより「長く走り続ける」ほうが価値が出る ボトルネックは実装そのものより、人間のレビュー時間になりつつある 権限を細かく止めないことで、無駄な中断を減らせる agent 自身にテストや確認をさせると、人間の確認コストが下がる コードレビューまで agent に寄せると、さらに回転率が上
papoo.work
Claude CodeがiOS Simulatorに対応　Apple向けアプリを作って試せる時代に
Claude CodeがiOS Simulatorに対応　Apple向けアプリを作って試せる時代に
Anthropicの「Claude Code」が、AppleのiOS Simulatorと連携できるようになりました。しかも公開ベータです。 これ、地味に見えてかなり面白い動きです。AIがコードを書くのはもう珍しくありませんが、「書いたあとに実際のiPhoneアプリっぽい画面で動かして、触って、直す」ところまで入ってきたのは、開発の流れを一段変える話だと思います。 MacRumorsによると、Claude Code for desktop が iOS Simulator を扱えるように更新されました。 Claude Code に「build」「run」「check」などを指示すると、作業中のアプリを iOS Simulator の中で開き、実際に動いている様子を見ながら操作し、必要なら修正を繰り返して完成まで持っていけるそうです。 しかも、開発者はその間も普通に iOS Simulator を使い続けられます。AIに作業を任せていても、自分で動作確認を並行できる。ここはかなり実用的です。AIが勝手に画面をいじって、こっちは何も触れない、みたいな窮屈さがないのはいいですね。 今回のポイン
papoo.work
作業記録をもとに、次回の依頼テンプレを作り直す
作業記録をもとに、次回の依頼テンプレを作り直す
依頼テンプレを「一回作って終わり」にしていると、だいたい次の依頼でまた同じ手戻りを食う。そこを放置して、毎回ゼロから雑に投げ直すのはかなりもったいない。Claude Code は一発で完璧な代物を出す道具ではないが、作業記録を見ながら依頼テンプレ改善を回すと、次回の指示精度が目に見えて上がる。再発防止メモとしても効く。 ここで言う作業記録は、長大なログのことではない。Claude Code に何を頼んだか、どこで迷走したか、どの出力がそのまま使えたか、そこだけ拾えばいい。雑に見えるが、ここを残さないとテンプレは劣化する。人間の記憶はだいたい都合よく丸くなるので、実際に詰まった箇所を次回へ渡せない。 たとえば、ファイル整理なら「重複候補を見つけて」と頼んだのに、判定基準が曖昧で候補が多すぎた。文書作成なら、章立てはよかったのにトーンが硬すぎて直しが増えた。コード修正なら、対象ファイルの範囲を絞らずに話を始めたせいで、差分が肥大化した。こういうズレは、記録を元にテンプレへ戻せばかなり減る。 やり方は単純だ。まず、その作業の終わりに短い記録を残す。次に、その記録から「次回も固定したい条件」と
papoo.work
調査だけのやり取りを残して、修正作業に混ぜない
調査だけのやり取りを残して、修正作業に混ぜない
これを混ぜる人は、だいたいあとで自分の首を絞める。 調べた結果のメモと、実際の修正を同じ流れで雑にやると、何を根拠に直したのか分からなくなるし、Claude Code のコンテキストも無駄に食う。調査記録を残して、修正分離する。たったそれだけで、後から見返したときの説明力がまるで違う。 Claude Code では、まず「調べるだけ」の往復を終わらせ、その内容を独立した記録として残してから、別のやり取りで修正に入るのが強い。 このやり方にすると、判断の履歴が消えにくい。ファイル整理でも文書作成でも同じだ。調査の途中でいじり始めると、いつの間にか「何を直していたのか」が溶ける。筆者は昔、原因調査のつもりで会話を続けながらそのまま修正まで頼み、どの変更が診断で、どの変更が本命か分からない差分を抱えたことがある。あとから戻すのが面倒で、かなりだるかった。 やり方は単純だ。まず Claude Code に調査だけを頼み、最後に「修正はまだしない」と釘を刺す。たとえば、こんな流れにする。 ```text このリポジトリについて、次の点だけ調べて。 1. どのファイルが関係しているか 2. どこで
papoo.work
再現できる失敗と、たまたま起きた失敗を分けて見る
再現できる失敗と、たまたま起きた失敗を分けて見る
同じ失敗に見えても、直すべき場所はぜんぜん違う。そこを混ぜると、Claude Code に何を頼むべきかが毎回ぼやけて、手戻りだけが増える。 ここで分けたいのは、再現できる失敗と、たまたま起きた失敗だ。言い換えると、再現性の確認と偶発エラーの切り分けである。 たとえば、ある文書を並べ替えたら毎回同じファイル名で衝突するなら、それは再現できる失敗だ。入力と手順が同じなら、同じところでつまずく。逆に、たまたま一度だけ同期が遅れてファイルが見えなかった、ネットワークの瞬断でコマンドが落ちた、ディスクが一杯の瞬間だけ保存に失敗した、という類は偶発エラーだ。ここを同じノリで扱うと、Claude Code に「とりあえずもう一回試す」を延々やらせる羽目になる。 筆者は最初、この区別を雑にしていた。ログを見ずに「なんか失敗した」で片づけ、Claude Code に同じ修正を何度も投げたことがある。結果、差分だけが太り、原因は残ったまま。あれはかなりだるい。以後は、まず「再現するのか、しないのか」を先に決めるようにしている。 Claude Code を使うなら、最初の依頼でこの切り分けを明示したほうが
papoo.work
Claude Code の出力と自分の期待がずれた場所を読む
Claude Code の出力と自分の期待がずれた場所を読む
Claude Code でいちばん無駄が出るのは、ちゃんと動いているのに「なんか違う」とだけ感じて、そこを言語化できないときだ。 期待との差分、つまり出力のズレを読めないと、同じ依頼を少しずつ言い換えては手戻りする。これが地味にだるい。しかも、ズレている場所は毎回同じではない。要件の理解が浅いのか、対象ファイルの見方が違うのか、やり方は合っているのに粒度だけ外したのか。そこを切り分けるだけで、Claude Code はかなり扱いやすくなる。 まず押さえるべきなのは、Claude Code の出力は「答え」ではなく「解釈の結果」だという点だ。だから、期待と違ったときに見るべきなのは、出力の文章そのものだけではない。どのファイルを見たのか、どこを変更対象だと思ったのか、何を省いたのか。その読み取りが要る。 たとえば、フォルダ整理を頼んで、古い画像だけ消してほしかったのに、関連しそうなファイルまで候補に上げてきたとする。ここで「違う」で終わると、次もまた似たズレを踏む。見るべきは、Claude Code が「古い画像」という言葉をどう解釈したかだ。更新日時で見たのか、ファイル名で見たのか、拡
papoo.work
貼ったログと実際の変更を照合して、見落としを潰す
貼ったログと実際の変更を照合して、見落としを潰す
貼ったログをそのまま信じて進むと、あとで「そこ、直ってないじゃん」で止まる。いちばんだるいのは、直したつもりの差分と、実際に変わったファイルがズレていることだ。 ここで使うのがログ照合、つまり貼ったログと実際の変更を突き合わせるやり方である。Claude Code に作業を振ったあと、返ってきた説明と、リポジトリ上の実ファイルや `git diff` を並べて見る。これをやるだけで、見落とし、やり残し、説明だけ立派な変更をかなり潰せる。 筆者はこれをサボって、README の説明は更新されたのに設定ファイルの例が古いまま、という半端な状態を何度も踏んだ。見た目はそれっぽいのに、実行すると壊れる。ああいう事故は、照合を省いたときに起きる。 まず、Claude Code には「作業後に変更内容を要約して」と頼む。大事なのは、要約だけで終わらせず、実際の差分と照合する前提を最初から入れることだ。たとえばこんな頼み方でいい。 ```text この作業で変更したファイルを一覧にして、各ファイルで何を変えたかを短く要約してください。 そのうえで、実際の差分と照合して、説明と食い違う点や見落としがあ
papoo.work
長い作業の節目ごとに要点を残して、後追いの確認を楽にする
長い作業の節目ごとに要点を残して、後追いの確認を楽にする
長い作業を丸ごと一気にClaude Codeへ投げて、そのまま最後まで追いかけようとする。これ、かなり詰まる。途中で何を決めたかが消えるから、後から「なぜこの構成にしたんだっけ」「どのファイルを触ったんだっけ」が毎回発生する。 そこで効くのが、途中要約、つまり節目メモだ。作業の区切りごとに、今の判断・変更点・未完了を短く残しておく。これだけで、後追い確認、再開、レビュー、差し戻しが一気に楽になる。Claude Codeにとっても、人間にとってもだ。長丁場の文書作成、ファイル整理、不要データの洗い出し、ディスク削減、コード修正まで、全部に効く。 やることは単純だ。大きな依頼を小分けにして、各段階の終わりで「ここまでの要点」を必ず出させる。さらに、その要点を次の依頼の前提として使う。これで会話の流れが細くならない。 たとえば、案件フォルダを整理して報告書の下書きを作るなら、最初から全部を一気にやらせない。まずは現状把握、次に整理方針、最後に実作業だ。そのたびに要点を残す。 ```text この作業は3段階で進めてください。 1. 現状把握 フォルダ内の主要なファイル種類 重複しそうなもの
papoo.work
途中で何を判断したかを記録させて、あとから説明できる形にする
途中で何を判断したかを記録させて、あとから説明できる形にする
Claude Code に仕事を投げておいて、あとから「なんでそうしたんだっけ」と困る人は多い。 出力がそれっぽく終わると満足しがちだが、実務で痛いのはそこではない。途中で何を見て、何を捨てて、何を採ったかが残っていないことだ。これがないと、数日後に見返した瞬間に意味が死ぬ。 ここで効くのが、判断メモ、つまり意思決定ログだ。 Claude Code に「結果だけでなく、途中の判断も短く残せ」と最初から頼む。そうすると、あとから説明しやすい形で残る。ファイル整理でも文書作成でも同じで、最後の成果物だけ作らせると、なぜその構成になったのかが消える。消えた説明は、だいたい再現できない。ここがだるい。 たとえば、文書を整えるなら、Claude Code にこう頼む。 ```text この作業では、最終結果だけでなく判断メモも残してください。 各ファイルについて、以下を短く記録してください。 何を基準にその判断をしたか 迷った案があれば何だったか 最終的に採用した理由 後で見返したときに説明に使える一文 本文の中に長く混ぜ込まず、最後に「判断メモ」としてまとめてください。 ``` ファイル整理な
papoo.work
失敗した依頼を会話の流れから洗い出して、次の指示に直す
失敗した依頼を会話の流れから洗い出して、次の指示に直す
雑に投げた指示がそのまま通ると思っているなら、そこが一番あぶない。Claude Code は空気を読んで勝手に名案をひねり出す道具ではないので、失敗した依頼はその場で拾って、次の指示に直すほうがずっと強い。ここで使うのが、手戻り分析とやり直しポイントの洗い出しだ。会話のどこでズレたかを見つけて、同じ事故をもう一回起こさない形に変える。 このやり方のうまみは単純だ。失敗を「なかったこと」にせず、次の依頼文に変換できる。Claude Code にやり直しをさせるたびに、曖昧な言い方が減り、余計な探索や無駄な diff も減る。ファイル整理でも文書作成でも、ここをサボると、あとで「なんでここを触った？」みたいな修正が増える。地味だが、効く。 まずやることは、失敗した依頼をそのまま見返すことだ。Claude Code との会話ログの中で、結果がズレた返答、余計な修正、期待外れの要約、触ってほしくないファイルへの変更を拾う。重要なのは、結果だけを見るのでなく、その前の自分の依頼文も一緒に見ることだ。たいてい問題は、モデルの気まぐれではなく、依頼のどこかが曖昧だったり、前提が抜けていたりする。 た
papoo.work
作業ログを見返して、Claude Code がどこで迷ったかを特定する
作業ログを見返して、Claude Code がどこで迷ったかを特定する
Claude Code に雑に任せて「なんか遅い」「なんか遠回りした」で終わらせるのは、かなりもったいない。迷いはだいたい作業ログに出る。会話ログ、作業履歴を見返せば、どこで前提を取り違えたか、どの指示が弱かったか、どこで無駄な探索を始めたかが見えてくる。 ここを拾えるようになると、同じ依頼を次回からずっと軽くできる。コード修正でも、ファイル整理でも、文書作成でも同じだ。Claude Code が迷う瞬間を特定できれば、指示の出し方が一段よくなる。人間側の手戻りも減る。 まず見る場所は、単純でいい。Claude Code の作業中に残る会話ログや出力を、ひとまとまりの履歴として読む。やることは「何をしたか」を追うことではなく、「どこで方針が揺れたか」を探すことだ。 たとえば、こんな依頼を出したとする。 ```text このリポジトリ内の古い設定ファイルを整理して、重複しているものをまとめてください。 削除してよい候補も出してください。 ``` この手の依頼で迷いが出るとき、ログにはこういうサインが出やすい。 似た名前のファイルを何度も行き来している 先に削除候補を出すはずが、比較だけを
papoo.work
非エンジニアの整理作業で、処理の前後を比較して確認する
非エンジニアの整理作業で、処理の前後を比較して確認する
整理作業でいちばん危ないのは、きれいになった気がして終わることだ。削ったはずのファイルが残っていたり、直したつもりの文書が別の場所で壊れていたりする。こういうときに効くのが、整理前後比較、棚卸し確認だ。Claude Code に処理の前と後を見比べさせると、何を減らしたのか、どこが変わったのか、逆に何が残っているのかを落ち着いて追える。 非エンジニアの整理でこれが役に立つ場面は多い。たとえば、案件フォルダの重複書類を減らす、古い下書きをまとめる、写真やPDFの置き場を整える、不要なキャッシュや一時ファイルを洗う。人間が目で追うと、どうしても「たぶん大丈夫」で済ませがちだ。そこを比較で締める。雑に見える作業ほど、前後差分を残したほうが後で助かる。 やり方は単純だ。Claude Code に「処理前の一覧を保存して、処理後と比べて報告して」と頼む。ファイル整理なら、対象フォルダの状態を作業前に記録しておき、処理後にもう一度見比べる。たとえば、こんな依頼で十分だ。 ```text このフォルダの整理をしたいです。まず処理前の状態を記録してください。 対象はこのディレクトリ配下のファイル一覧、
papoo.work
SPICEとオシロスコープをClaude Codeにつないで、回路検証を自動化する話
SPICEとオシロスコープをClaude Codeにつないで、回路検証を自動化する話
Claude Codeをハードウェア開発に使う。これだけ聞くと、ちょっと夢が大きすぎる気もします。けれど、Lucas Geradsさんのこのデモは「AIに回路を丸投げする」のではなく、「AIにちゃんとフィードバックを返せる環境を渡す」とうまく回り始める、というかなり筋のいい話でした。 元記事でやっているのは、SPICEシミュレーション、オシロスコープ、Claude Codeをつないで、回路の確認作業を一段ラクにする試みです。SPICEは電子回路をPC上で動かすシミュレータ、オシロスコープは実際の電圧波形を見る計測器です。つまり、机上の計算と現物の計測を行き来しながら、Claude Codeに「ここは合っているか」を一緒に見てもらう、という発想です。 Claude Codeを回路設計に使うときは、自然言語だけで回路を作らせるより、計測結果を見せて検証させる方が強い SPICEシミュレーションとオシロスコープを組み合わせると、机上と実機のズレを見つけやすい 解析では、時間軸の正規化やデータの位置合わせのような地味な作業がかなり重い Claudeには、**物理配線を勝
papoo.work
Claude Codeを安く使う裏ワザ、deepclaudeがかなり面白い
Claude Codeを安く使う裏ワザ、deepclaudeがかなり面白い
GitHubで見つけた `deepclaude` は、ひとことで言うと「Claude Codeの見た目と操作感はそのままに、裏側のモデルだけを安いものへ差し替える」ためのツールです。 発想がかなり気持ちいいです。高い道具の“外側”はそのまま使って、頭脳だけ別のエンジンに載せ替える感じ。こういうやり方、地味だけど実用性が高いんですよね。 Claude Codeの自律的な開発ループを、そのまま使える 裏のモデルを DeepSeek V4 Pro、OpenRouter、Fireworks AI、Anthropic に切り替えられる 使い勝手はほぼ同じで、コストはかなり下げられる 端末上で動くプロキシがAPIを横取りして、バックエンドを差し替える仕組み 途中で再起動せず、セッション中にモデルを切り替えられる ただし画像入力やMCPなど、いくつか弱い部分もある 元記事の主張はわかりやすいです。Claude Code は「自律型のコーディングエージェント」としてかなり優秀だけれど、月額 $200 と高い。そこで `deepclaude` は、Claude Code の CLI やツールループ、ファ
papoo.work
Claude CodeがiOSアプリの実機テストに近いことをMac上でできるようになった話
Claude CodeがiOSアプリの実機テストに近いことをMac上でできるようになった話
Claude CodeのMacアプリに、かなり面白い新機能が入りました。iOSアプリを、ClaudeがSimulator上で実際に動かしながらテストできるようになったんです。しかも会話画面の横にシミュレーター用の表示が出て、コードを書かせて、そのまま動作確認までつなげられる。これは開発体験としてかなり気持ちいいと思います。 Anthropicが公開ベータとして、Claude Code DesktopにiOSアプリのテスト機能を追加しました。対象はPro、Max、Teamプランのユーザーです。使えるのはClaude Desktop v1.24012.0以降。そして前提条件として、XcodeにiOS platformが入っていることが必要です。 ここでいうSimulatorは、iPhoneやiPadの代わりにMac上でアプリを動かす仕組みです。実機そのものではありませんが、起動して、画面をタップして、スワイプして、UIの確認をするにはかなり便利です。開発者なら「毎回本物のiPhoneをつないで試すの、地味に面倒だよね」と思ったことがあるはずで、そこをClau
papoo.work
Claude Codeに「見える進捗」がやってきた。アーティファクト対応でチーム共有がかなり楽になる
Claude Codeに「見える進捗」がやってきた。アーティファクト対応でチーム共有がかなり楽になる
Claude Codeに、アーティファクト（Artifacts）対応が入った。これ、地味に見えてかなり面白い機能です。なぜなら、AIとのやり取りって、本人には見えていても周りからは見えにくいからです。「いま何を調べているのか」「どこまで進んだのか」「途中経過をみんなでどう確認するか」。そのモヤモヤを、Claude CodeがWebページとして“見える化”してくれるわけです。 Claude CodeがArtifactsに対応し、作業進捗をWebページとして表示できるようになった 対応環境はClaude Code CLIとデスクトップアプリ 当初はTeam/Enterprise向けのベータ提供だったが、後にPro/Maxにも広がった 生成されるページは、プルリクエスト解説、デバッグタイムライン、システム図、ダッシュボード、チェックリストなどに使える URLは固定で、チーム内で共有するとリアルタイム更新される バージョン履歴も残り、必要なら過去の版に戻せる 7月15日追記で、共有や共同編集にも対応。Slack経由で使うこともできる Claude Codeを使ったことがある人ならわかると思いま
papoo.work
Claude Codeに“自動の目”を足す、Anthropicの無料セキュリティ監査プラグイン
Claude Codeに“自動の目”を足す、Anthropicの無料セキュリティ監査プラグイン
Anthropicが、コードを書いている途中で脆弱性を見つけて警告してくれる「security-guidance」というプラグインを、Claude Code向けに無償提供しました。しかも対象は特定プランだけではなく、すべてのClaude Codeユーザー。こういう「便利だけど高そう」な機能を最初から広く配るのは、かなり攻めた打ち方だと思います。 Claude Code向けの新しいプラグイン「security-guidance」が公開された コード編集の流れの中で、リアルタイムに脆弱性を検出して警告する 仕組みは「Hook」を使った自動実行で、手動で毎回呼び出す必要はない 監査は3段階で行われる - ファイル編集時 - ターン終了時 - コミット時 危険なライブラリの誤用、危ないデシリアライズ、DOM操作、認証バイパスなどを検出対象にしている Anthropicの内部テストでは、プルリクエストへのセキュリティコメントが30〜40％減ったという インストールにはClaude Code CLI v2.1.144以降とPython 3.8以降が必要 今回の話で面白いのは、セキュリティチェックを
papoo.work
Claude CodeがRust版Bunを使い始めた話
Claude CodeがRust版Bunを使い始めた話
Claude Code v2.1.181以降は、JavaScriptランタイムのBunを「Rustで書き直した版」で動かしている。 きっかけはBun作者Jarred Sumnerの投稿で、起動がLinuxで10%速くなったが、見た目の変化はほとんどないという話だった。 Simon Willisonは実際に自分の環境を調べ、Claude Codeの中にBunのバージョン文字列やRustのソースファイル名が埋め込まれているのを確認した。 つまり、かなり多くの端末で、Rust版Bunが静かに本番投入されているらしい。 “Boring is good” という一言が、この話のいちばん面白いところだと思う。派手な新機能より、地味でも速くて安定しているほうが現場では強い。 この話、派手さはないのに妙におもしろいです。 Claude CodeはAnthropicの開発補助ツールで、要するに「AIにコード作業を手伝わせるための道具」です。その内部で動く仕組みのひとつに Bun という runtime が使われています。runtime というのは、JavaScriptやTypeScriptを動かすための
papoo.work
Claude Codeに「動的ワークフロー」が来た。大きな作業を、途中で潰しながら進める新しいやり方
Claude Codeに「動的ワークフロー」が来た。大きな作業を、途中で潰しながら進める新しいやり方
ClaudeがClaude Codeに追加した「dynamic workflows」は、ひと言でいうと、ひとつのAIに全部やらせるのではなく、たくさんの小さなAI作業を同時並行で走らせて、最後にまとめて点検する仕組みです。Anthropicはこれを、特に大きくてややこしい仕事向けに出してきました。 個人的にかなり面白いと思ったのは、単なる「速くなる機能」ではなく、AIの使い方そのものを変えようとしているところです。雑に答えを出すのではなく、途中で反証させたり、別の角度から検証させたりして、最終的に人の前に出す前にチェックを重ねる。ここがいちばん“らしい”進化だと感じます。 Claude Codeで、複数のsubagentを並列に動かす「dynamic workflows」が使えるようになった ひとつのAgentが順番に考えるのではなく、10〜100単位の並列作業で大きな問題を分解する バグ探し、セキュリティ監査、大規模な移行作業、仕様のレビューのような仕事に向いている 実行前に確認が入り、途中結果もチェックされるので、最終結果の信頼性を上げる設計になって
papoo.work
Claude Codeのroutinesで何が変わるのか——“放置して回る”自動化の本気度
Claude Codeのroutinesで何が変わるのか——“放置して回る”自動化の本気度
Claude Code Docs の新しい機能「routines」は、ひと言でいうとClaude Code をスケジュール実行・API起動・GitHubイベント連動で自動運転させる仕組みです。 しかも、ただの「定期実行」ではありません。Anthropic 管理のクラウド上で動くので、手元のPCを閉じても止まりません。ここがかなり大きい。ローカルで動く自動化は、結局「PCをつけっぱなしにする人が勝つ」世界になりがちですが、routines はその弱点をかなりきれいに消しています。 routines は、Claude Code の保存済み設定を自動実行する仕組み 実行場所は Anthropic 管理のクラウドなので、PCを閉じても動く トリガーは Schedule / API / GitHub の3種類 1つの routine に複数トリガーを組み合わせられる 使えるのは Pro / Max / Team / Enterprise かつ Claude Code on the web が有効な場合 研究プレビュー段階なので、**挙動や制限は変わる可能性
papoo.work
返答が長すぎるときは、出力の形を先に固定する
返答が長すぎるときは、出力の形を先に固定する
Claude Code に「要点だけ頼む」と言っても、返ってくる文章が妙に長い。あれはツールが悪いというより、こちらが出力の型を渡していないことが多い。出力制約とか成果物の型を先に決めておくと、返答の長さはかなり扱いやすくなる。 雑に頼むと、Claude Code は親切に広げる。しかも、説明が増えるほどタスクは見失いやすい。ファイル整理でも文書作成でも同じで、「何をどの形で返すか」を先に縛ったほうが、あとで読む側が圧倒的に楽だ。筆者は以前、3 ファイルだけ確認したいのに、背景説明つきで長文を返され、結局自分で見直した。あれは地味にだるい。最初から形式を指定していれば済んだ話だった。 まず効くのは、指示文の頭で「長さ」と「形式」を固定することだ。たとえば、こんな頼み方にする。 ```text 次の条件で返答してください。 3項目だけ 各項目は1文 余計な前置きは不要 箇条書き以外は書かない 対象: ... ``` この手の制約は、単に短くさせるためだけのものではない。何を出力してほしいかの輪郭をはっきりさせるために入れる。Claude Code は、曖昧な依頼に対しては補足や説明を足し
papoo.work
途中で方針が変わったら、古い前提を捨てて言い直す
途中で方針が変わったら、古い前提を捨てて言い直す
途中で話が変わったのに、前の指示を引きずったまま走る。これが一番だるい。Claude Code でも同じで、最初の前提のまま作業を続けさせると、見当違いの差分や、やたら長い説明を生む。ここで効くのが前提更新、つまり指示のリセットだ。 たとえば「このフォルダの画像だけ整理して」と頼んだあとに、「やっぱり古いPDFも対象にして」「いや、削除じゃなく一覧化だけで」と方針が変わる場面がある。こういうときは、前の依頼を上書きする感覚で言い直す。曖昧に「それも含めて続けて」ではだめだ。古い前提を捨てて、今の目的をはっきり言い直すほうが速い。 実際の頼み方は、こういう形でいい。 ```text ここまでの前提は一度忘れてください。 目的は「重複ファイルの削除」ではなく、「重複候補の一覧作成」に変わりました。 削除はしないでください。 出力は、重複の可能性があるファイル名、サイズ、保存場所を表でまとめてください。 ``` この言い方の肝は、単に「変更です」と伝えるだけで終わらせないことだ。何を捨てて、何を残すかを明示する。Claude Code は会話の流れを参照するので、前の指示が残ったままだと、意
papoo.work
大量のファイル整理は、まず分類ルールだけ決める
大量のファイル整理は、まず分類ルールだけ決める
ファイル整理で一番まずいのは、いきなり中身を見始めることだ。そこからやると、分類がその場の気分でぶれて、あとで自分でも意味が分からなくなる。Claude Code を使うなら、先に決めるのは「何をどう分けるか」だけでいい。分類基準を先に決める、仕分けルールを固定する、ここを飛ばすと、整理はほぼ確実にぐだる。 Claude Code は、散らかったフォルダを人間みたいに眺めて「これ重要そうですね」と曖昧に気を利かせる道具ではない。こちらがルールを渡すと、かなり素直に動く。逆に言えば、ルールが曖昧だと、曖昧なまま大量のファイルを処理して、後で確認地獄になる。筆者は最初、フォルダを見せて「いい感じに分類して」と頼み、戻ってきた結果を見て手が止まった。基準がない分類は、作業が速いぶんだけ修正がだるい。 まずやるべきことは、ファイルそのものではなく、分類の軸を決めることだ。たとえば案件書類なら「案件名」「種別」「日付」、写真なら「イベント名」「日付」「仮置きか確定か」、ダウンロード済みの雑多なファイルなら「残す」「アーカイブ」「削除候補」の三択にする。ここで大事なのは、軸を増やしすぎないことだ。
papoo.work
長文の下書きは章ごとに作らせる
長文の下書きは章ごとに作らせる
長文を一気に書かせて、あとで整えればいい——このやり方、たいてい途中で崩れる。Claude Code は便利だが、雑に丸投げすると、前半で決めた言い回しが後半で勝手にズレたり、同じ話を二度書いたりする。長い文章ほど、分割執筆、章立て執筆に切り替えたほうがいい。 これは開発の話だけではない。仕様書、手順書、社内向けの案内文、案件ごとのメモ整理、重複した文章の圧縮まで、長文を扱う場面は多い。章ごとに作らせると、各パートの狙いがぶれにくくなるし、直しやすい。全文を一発で出させるより、最後まで読める下書きになりやすい。 やり方は単純だ。最初に全体構成を作らせ、そのあとで章単位に書かせる。ここで大事なのは、「最初から完成文を求めない」ことだ。完成品を一気に欲しがると、Claude Code は広い文脈を抱えたまま無難な文章を量産しがちになる。結果、どこかで力尽きる。筆者はこれで、序盤は切れ味があるのに後半だけ急に総論っぽくなる下書きを何度も踏んだ。あれは直すのがだるい。 たとえば、こんな流れにする。 ```text この文章を章ごとに分けて下書きしたい。先に全体の章立てを提案して。 条件: 読者
papoo.work
調べた内容をその場で要約させて、次の指示に渡す
調べた内容をその場で要約させて、次の指示に渡す
調べものをしたあとに、そのまま長文を抱えて次の指示を投げると、Claude Code のコンテキストはあっさり太る。ここで雑に進めると、必要な事実よりも、読み込んだメモやログのほうが邪魔になる。だから一度、中間要約で調査の圧縮を挟む。これだけで、次の一手がかなり安定する。 たとえば、ファイル整理でも文書作成でも同じだ。散らかったフォルダ一覧、重複候補、PDF の抜き書き、議事メモ。これらを全部そのまま次の依頼に放り込むと、指示がぼやける。Claude Code は「何を見たか」より「何を判断材料にするか」を短く渡したほうが強い。 要は、調べた直後にこう使う。 ```text ここまでに調べた内容を、次の指示に渡しやすい形で短く要約して。 目的、重要な事実、迷いどころ、次に決めるべきことを分けて書いて。 余計な説明は削って、後続の作業に必要な情報だけ残して。 ``` この一文だけでもかなり効くが、もう少し実務向けに詰めると使いやすい。筆者は最初、調べた内容をそのまま貼って次の指示を出していた。すると、要約すべき箇所まで毎回読み直すことになり、コンテキストが無駄に消える。し
papoo.work
一度にやることを減らして、見失いを防ぐ
一度にやることを減らして、見失いを防ぐ
雑にまとめて一気に投げると、Claude Code はわりと簡単に見失う。人間のほうもだが、出力のほうもだ。 ここで効くのが、単一タスク化、あるいは集中実行という考え方である。やることを一度に1個に絞る。すると、指示が短くなり、差分が小さくなり、途中で何を直しているのか分からなくなる事故が減る。 これはコード修正だけの話ではない。ファイル整理でも、不要ファイルの削除でも、文書作成でも同じだ。 「このフォルダを片付ける」「この文章の冗長さだけ削る」「この1本のスクリプトの失敗原因だけ追う」と分けるだけで、かなり安定する。 筆者は最初、欲張って「このディレクトリの整理、重複削除、README更新、ついでに不要な設定も見て」と一気に頼んで手戻りした。返ってきた結果は悪くないのに、どこに何を置いたか、何を触ったか、こちらが追えない。差分がでかくなると、レビューもつらい。Claude Code は優秀でも、曖昧で広い依頼を丸ごと飲み込ませると、だいたい散る。 要は、作業を「目的」で切るのではなく、「一回の実行単位」で切ることだ。 たとえば次のようにする。 ```text この作業は3段階に分けた
papoo.work
長い依頼は途中で区切って、返答を挟ませる
長い依頼は途中で区切って、返答を挟ませる
長い依頼を一息で投げて、そのまま全部を抱えさせる。これ、いちばん雑に見えて、いちばん手戻りが増えるやり方だ。Claude Code は長文も受けるが、だからといって一発で正解を取りにいく道具ではない。むしろ、段階実行や途中確認を挟んだほうが、速いし、壊れにくい。 特に Claude Code では、ファイルをまたぐ変更、削除候補の洗い出し、文書の下書き、リネーム方針の整理みたいな作業で効く。最初に方針だけ固めて、次に実作業、最後に差分確認。これだけで、変な前提のまま大量変更される事故がかなり減る。 筆者は昔、ひとつの依頼文に「古い資料を整理して、重複を消して、命名規則も直して、READMEも整えて」と全部詰め込んで痛い目を見た。途中で返答を挟まなかったせいで、こちらの意図と違う削除候補まで広げられ、最後に確認してから戻す羽目になった。最初から二段三段に切っていれば済んだ話だ。 長い依頼の最初から作業を始めさせない。先に、見立てと手順を返させる。ここでの目的は、Claude Code に仕事をさせることではなく、こちらの意図を固定することだ。 たとえば、こんなふうに頼む。 ```text
papoo.work
作業中に持たせるメモは短く、決定事項だけにする
作業中に持たせるメモは短く、決定事項だけにする
長いメモを投げると、Claude Code は「読む側」ではなく「解釈する側」に回る。ここで雑に経緯や愚痴まで積むと、作業ノートはすぐ肥大化して、肝心の指示が埋もれる。進行メモは短く、作業ノートは決定事項だけ。これだけで手戻りがかなり減る。 Claude Code を使っていると、つい「背景も含めて全部書けば親切だろう」とやりたくなる。だが実際には、背景が長いほど判断がぶれる。特に、ファイル整理や文書作成のように“何を残し、何を捨てるか”が大事な作業では、余計な文脈がノイズになる。 作業中に持たせるメモは、あとで見返して意味が残るものだけに絞るのが正解だ。 たとえば、こんなふうに書く。 ```text このフォルダ内の重複候補を洗い出して、削除してよいものだけ一覧にしてください。 判断基準は次のとおりです。 同一内容の重複ファイル 明らかな一時ファイル 既に別名で保存済みの下書き 迷うものは削除しないで、保留として分けてください。 最後に、削除候補と保留を分けた一覧を出してください。 ``` これで十分だ。背景説明を足すなら、必要最小限でいい。 「3年前の移行で残った」「メール添付用に
papoo.work
最初に「使う材料」と「使わない材料」を分けて渡す
最初に「使う材料」と「使わない材料」を分けて渡す
Claude Code に雑に「このフォルダ見ていい感じにやって」と投げると、だいたい遠回りになる。 参照範囲を絞る、つまり材料の選別を先にやるだけで、出力の精度もスピードもかなり変わる。無関係なファイルまで読ませてコンテキストを浪費するより、使う材料と使わない材料を分けて渡したほうが、Claude Code は迷いにくい。 これは開発コードだけの話ではない。案件フォルダの整理、重複ファイルの洗い出し、議事録から要点だけ抜く作業でも同じだ。最初に「見るべきもの」と「見なくていいもの」を分ける。これが一番効く。 たとえば、リポジトリの中に `src/`、`docs/`、`node_modules/`、`dist/` があるとする。ここで全部まとめて渡すと、必要のない生成物や依存関係まで拾ってしまう。逆に、作業対象を `src/` と `docs/` に絞り、`node_modules/` と `dist/` は明示的に除外すれば、Claude Code は本筋に集中しやすい。ファイル整理でも同じで、`請求書` と `契約書` だけ見てほしいのに、昔の画像やキャッシュまで混ぜると、出力がぼ
papoo.work
最後に全体を短くまとめ直して、引き継げる形にする
最後に全体を短くまとめ直して、引き継げる形にする
長く作業したあとに、ただ「終わりました」で投げるのは雑だ。Claude Code でも同じで、最後に全体を短くまとめ直しておかないと、あとで自分が困る。引き継ぎメモ、あるいは仕上げ要約を残しておくと、何を変えたのか、何が未完了なのか、次にどこから触ればいいのかが一発で見える。 このひと手間は、開発者だけの話ではない。ファイル整理でも、原稿作成でも、ディスク削減でも効く。途中で Claude Code に細かい作業を任せるほど、最後の要約がないと成果物が散らばる。差分はあるのに意図が残っていない。これがいちばんだるい。 実際、筆者は一度、長い整理作業のあとに要約を作らせず、そのまま別日に続きを見て手戻りした。変更点は散らかっているのに、どのファイルをなぜ触ったのかが分からない。結局、ログを掘り返して再確認する羽目になった。最後に短くまとめるだけで避けられた無駄だ。 Claude Code に頼むとき、最後のまとめは「長文の報告書」を作らせる場面ではない。必要なのは、引き継げる最小単位の整理だ。目的は三つある。何をやったか、何が残っているか、次に何を見ればいいか。この三点が入っていれば十分
papoo.work
作業の入口と出口を明示して、終わり方を迷わせない
作業の入口と出口を明示して、終わり方を迷わせない
Claude Code で詰まる人の多くは、指示が雑だからではない。終わり方が曖昧だから詰まるのだ。 どこから始めるか、何が終わりか、終わったとみなす条件は何か。ここを先に固定しておかないと、Claude Code はそれなりに動くのに、最後に「で、これで完了なのか？」という微妙な空気が残る。人間のほうも迷うし、再依頼でコンテキストを無駄にする。地味だが、これが一番だるい。 この話をするときは、開始条件、完了条件、着地条件の3つを分けて考えるといい。入口は「何を見て作業を始めるか」、出口は「何をもって終わりにするか」、着地条件は「終わったあとにどの形で返すか」だ。名前は違っても、やることは同じである。 たとえば「README を直して」とだけ投げると、Claude Code は古い説明を直すのか、足りない章を足すのか、文体を整えるのか、判断に幅が出る。結果として、修正の方向がブレる。逆に、入口と出口を明示すると、作業が急に締まる。差分が小さくなるし、戻りも減る。筆者は最初、ここを甘く見て、文章修正を何度も往復した。悪いのは Claude Code ではなく、こっちの終点設計だった。 た
papoo.work
確認してから次へ進める：Claude Code にゲートを置く
確認してから次へ進める：Claude Code にゲートを置く
勢いで全部やらせると、たいてい後で面倒になる。Claude Code でも同じだ。 修正、整理、削除、要約。どれも便利だが、いきなり最後まで走らせると、思っていたものと違う場所まで触られることがある。だからこそ、承認ゲート、段階的確認、次工程への進行条件を置く。要するに「ここまでは進めていい、ここから先は止まれ」を先に決めるやり方だ。 この手の制御は、開発作業だけの話ではない。ファイル整理でも、ディスク削減でも、文書作成でも効く。Claude Code に「まず候補を出せ」「差分を見せろ」「削除前に止まれ」と言わせるだけで、手戻りがかなり減る。筆者は最初、全部まとめて任せて、あとから「そこは残したかった」と何度かやり直した。あの手戻りは地味にだるい。ゲートを置くと、その無駄が消える。 まず押さえるべきなのは、Claude Code に「最終実行」ではなく「確認用の下ごしらえ」をやらせることだ。たとえば不要ファイルの整理なら、いきなり削除させず、候補一覧を出させる。文書作成なら、いきなり全文を書かせず、章立てと論点を先に確認する。コード変更なら、いきなり大改修ではなく、影響範囲と変更方針
papoo.work
前提が崩れたら止めるよう指示して、暴走を防ぐ
前提が崩れたら止めるよう指示して、暴走を防ぐ
Claude Code に雑に「進めて」と投げると、案外まっすぐ突っ走る。で、いちばん痛いのは、前提が途中で壊れているのに走り続けることだ。前提崩れ時の停止、前提確認、暴走防止を最初から入れておくと、手戻りが目に見えて減る。 たとえばファイル整理でも文書作成でも同じで、最初に置いた条件が崩れた瞬間に止まらせるほうがいい。勝手に「たぶんこうだろう」で埋められると、あとで大量に直す羽目になる。筆者は、削除候補を洗い出すはずが、曖昧な指示のせいで想定外の範囲まで候補を広げられ、確認に余計な時間を食ったことがある。こういう事故は、最初の一文でかなり防げる。 効くのは、作業そのものより「止まり方」を先に決めることだ。Claude Code に渡す指示に、前提が崩れたら勝手に補完せず、必ず止まって確認する、と書く。これだけで、暴走しやすい場面の多くは抑えられる。 まずは、依頼文にこう入れる。 ```text 前提が崩れたら作業を止めてください。 不明点を推測で埋めず、前提確認をしてから続けてください。 変更前に、何が前提で、どこが崩れたのかを短く示してください。 ``` もう少し実務向けにするなら
papoo.work
止めてほしい条件を先に書く：安全なブレーキのかけ方
止めてほしい条件を先に書く：安全なブレーキのかけ方
Claude Code に雑に「やっといて」と投げると、速いぶんだけ派手に外す。特に危ないのは、何を止めればいいかを書かずに走らせるやり方だ。中断条件、失敗時の停止、ブレーキ条件を先に置く。これだけで、暴走した修正を途中で止めやすくなり、あとから手で戻す量がかなり減る。 この話は開発だけの話ではない。ファイル整理でも、文書作成でも、ディスク掃除でも同じだ。たとえば「重複ファイルっぽいものを探して」と頼んだとき、何を重複扱いにするか、どこまで削除していいか、どの条件で止めるかが曖昧だと、あとで痛い目を見る。Claude Code はこちらの意図を汲んでくれる場面もあるが、止めどころまで自動で空気を読む道具ではない。 だから最初に書くべきなのは、作業内容より先にブレーキだ。 たとえばこうだ。 ```text この作業では、次の条件に当てはまったら必ず止まって確認してほしい。 変更対象に .git 配下、node_modules、vendor、バックアップ、キャッシュが含まれるとき 既存ファイルの削除や上書きが発生するとき 影響範囲が 10 ファイルを超えるとき 依存関係やビルド設定を直す必
papoo.work
途中報告の粒度を決める：黙らせるか、節目だけ返させるか
途中報告の粒度を決める：黙らせるか、節目だけ返させるか
途中報告がうるさい。だから全部止める。これ、かなり雑なやり方だ。 Claude Code の進行中出力は、進捗報告、節目の報告、途中経過の出し方をきちんと決めないと、静かすぎて不安になるか、逆に細切れすぎて読めないかのどちらかになる。 大事なのは「黙らせる」か「節目だけ返させる」かを、作業の種類ごとに切り分けることだ。ファイル整理でも、文書作成でも、コード修正でも同じで、途中経過を全部見たい場面は少ない。見たいのは、止まったのか、方向がずれたのか、もうすぐ終わるのか、その三つだけである。 筆者も最初は、途中の考えごとまで全部見せてもらうほうが安心だと思っていた。だが実際は、出力が増えるほどコンテキストが汚れる。人間が「いま何してるんだっけ」と往復し始める。しかも、細かい進捗を逐一返させる頼み方は、成果物より実況にトークンを食う。地味にだるい。 Claude Code で粒度を決めるときは、まず仕事を二種類に分けるといい。ひとつは、黙って最後まで走らせる仕事。もうひとつは、節目だけ返させる仕事だ。 黙って走らせるのは、たとえば単純な移動、重複ファイルの洗い出し、既存文書の整形、指定フォル
papoo.work
大きい変更は「この順でやる」と先に並べる
大きい変更は「この順でやる」と先に並べる
大きい依頼を雑に投げて、「いい感じにやって」で済むと思っていると、だいたい途中で崩れる。Claude Code も人間と同じで、やる順番が曖昧だと、先に触るべきでない場所まで手を出して、あとで戻す羽目になる。 ここで言うのは、実行順の指定、手順の固定、処理順の話だ。要するに、「何を先にやり、何を後に回すか」を最初に並べるだけである。これを入れると、大きい変更でも迷いが減る。コンテキストの浪費も少ない。差分も妙に膨らみにくい。 筆者は最初、この順番を省いて何度も手戻りした。たとえば、古い文章ファイルを整理してから命名規則をそろえたいのに、いきなりリネームに入られて、あとで参照先がずれる。あるいは、不要ファイルを消す前に集計を始めてしまい、残すべきものまで候補に混ざる。順番を決めないと、作業そのものより、修正のほうが面倒になる。 Claude Code に頼むときは、最初に「全体の段取り」を明文化するのが効く。いきなり本作業を命じるより、先に分解させるほうが安定する。 たとえば、フォルダ整理ならこう書く。 ```text 次の順で進めてください。 1. まず対象フォルダを確認し、残すものと
papoo.work
調査・編集・確認を分けて頼むと、途中の迷いが消える
調査・編集・確認を分けて頼むと、途中の迷いが消える
ありがちなのは、「これまとめてやって」と一気に投げて、そのまま手戻りの山を作るやり方だ。Claude Code は雑に使うとかなり賢いが、指示の粒度が荒いと、途中で迷う。調査と実行の分離、段階依頼、確認フェーズを分けるだけで、その迷いはかなり減る。 特に、ファイル整理、ディスク削減、文書作成みたいな作業は、この分け方が効く。先に情報を集め、次に編集し、最後に確認する。順番を切るだけで、Claude Code の出力が安定するし、こちらも「今どの段階の話をしているのか」を見失いにくい。 筆者は最初、ひとつの依頼文に全部詰め込んでいた。たとえば「このフォルダを見て、重複を探して、不要なものを消して、最後にレポートして」と一息で頼む。すると、探索も削除も説明も同時に走るせいで、どこまで事実確認済みなのかが見えにくい。しかも diff が肥大化しやすい。あとから「その削除は本当に要るのか」と見返すのがだるい。そこで段階を分けたら、かなり扱いやすくなった。 やり方は単純だ。最初は調査だけ頼む。次に、調査結果をもとに編集や削除を頼む。最後に、変更後の確認を頼む。 たとえば、不要ファイルの整理ならこ
papoo.work
まず成果物の形を固定する：Markdown なのか表なのかを先に言う
まず成果物の形を固定する：Markdown なのか表なのかを先に言う
それ、たぶん最初にぼかしているせいで詰まる。 Claude Code に「いい感じにまとめて」と投げると、出力形式の指定、つまり成果物の型やフォーマット指定が曖昧なまま進みやすい。すると、文章がほしいのに箇条書きが返ってきたり、表がほしいのに長文の説明が混ざったりする。結果として、こちらが後で整形し直す羽目になる。 先に「Markdown で出す」「表で並べる」「見出し付きの箇条書きにする」と固定しておくと、手戻りが減る。これは開発の話だけではない。ファイル整理でも、議事録でも、契約書のたたき台でも同じだ。最初に成果物の形を決めるだけで、Claude Code が何を優先すべきかがかなりはっきりする。 たとえば、フォルダ内の書類を整理したいなら、こう言えばいい。 ```text このフォルダ内のファイルを整理して、結果を Markdown の表で返してください。 列は「ファイル名」「種類」「処理方針」「理由」にしてください。 本文の説明は最小限でいいです。 ``` これだけで、少なくとも「長い感想文」にはなりにくい。 逆に、あとでそのままメモに貼りたいなら、こう寄せる。 ```text
papoo.work
一発で終わる依頼を捨てる：最初に作業の切り方を決める
一発で終わる依頼を捨てる：最初に作業の切り方を決める
Claude Code に雑に「これやっといて」と投げると、だいたい一回で終わらない。むしろ、そこで作業の切り方を決めていないせいで、途中からコンテキストを食い、diff がふくらみ、最後に人間が手で戻す羽目になる。ここを外すと、便利なはずの道具が一番だるい道具になる。 この話で大事なのは、細かい命令文のテクニックではない。最初に「どこまでを Claude Code にやらせるか」「どの粒度で区切るか」を決めることだ。別名でいうなら、作業の切り方、進め方の設計、段取りである。ここが決まると、ファイル整理でも、ディスク削減でも、文書作成でも、頼み方が急に安定する。 筆者も最初はやった。ひと息で終わる気がして、長い依頼をそのまま投げた。結果は見事に散った。調査、修正、確認、微調整が全部ひとつの依頼に入って、Claude Code は便利に働くが、こちらは何を確認すればいいのか見失う。あとで見る diff はでかいし、どこから崩れたのか追いにくい。あれは気持ちが悪い。最初に切らないと、最後に手戻りで払うことになる。 やることは単純だ。最初に「一発で終わる依頼」を捨てる。代わりに、次の3つを分
papoo.work
最後にまとめ直させる：途中の断片を成果物に整える
最後にまとめ直させる：途中の断片を成果物に整える
途中で出たメモや断片を、そのまま成果物だと思って放置するとだいたい崩れる。Claude Code はそこを最後にまとめ直させるのがうまい。仕上げの再構成、最終整形、まとめ直し、呼び方はいろいろあるが、やることは単純だ。バラけた素材を、提出できる形に整える。 この使い方のいいところは、最初から完璧な指示を出さなくていい点にある。先に雑に集めさせて、最後に「この断片を一つの成果物に仕上げて」と頼む。人間の下書きでもよくやる流れだが、Claude Code はこの手の再構成がかなり得意だ。逆に、最初から完成形を一発で作らせようとすると、抜けや重複が出やすい。筆者も昔、仕様メモ、箇条書き、途中のコード断片を別々に投げて、最後の整形を省いたせいで、同じ説明が二重に入った文書をそのまま使いかけた。あれは地味にだるい。 たとえば、ファイル整理なら、散らかったメモやログを「削除候補」「残すもの」「後で確認するもの」にまとめ直させる。文書作成なら、章ごとに作った断片を、読み物として通る順番に並べ替えさせる。開発なら、試行錯誤のメモから、最終的な手順書や README に変換させる。ここで大事なのは、ただ
papoo.work
Claude Code を最初に動かすまで：インストールから初回の依頼まで
Claude Code を最初に動かすまで：インストールから初回の依頼まで
最初のつまずきはだいたい決まっている。Claude Code を「入れたのに動かない」と言いながら、実は入れ方と起動場所を外しているだけだ。ここを雑に済ませると、最初の 10 分で気持ちが折れる。逆に言えば、そこさえ通せばあとはかなり素直に使える。 Claude Code 入門とか Claude Code 使い方を探しているなら、まずは「何ができるか」を盛る前に、起動して最初の依頼を通すところまでを一気にやるのがいい。コードを書く人だけの道具に見えるが、実際はファイル整理、文書の下書き、散らかったディレクトリの棚卸しにも使える。最初に必要なのは、派手な設定ではなく、ちゃんとした足場だ。 Claude Code は、チャット画面を開いて雑談するものではない。ターミナル、つまり黒い画面から呼び出して、ローカルのファイルや作業ディレクトリを相手にする CLI ツールだ。ここを勘違いすると、いつまでたっても「どこで使うのか」が見えない。 なので最初にやることは単純だ。自分のPCで端末を開き、Claude Code を入れて、作業したいフォルダの中で起動する。それだけでよい。 逆に、ホーム画面や
papoo.work
Claude Code に何を頼めるか：得意なこと・苦手なことの線引き
Claude Code に何を頼めるか：得意なこと・苦手なことの線引き
それ、なんでも丸投げできる道具だと思っているなら最初に一度つまずく。Claude Code は万能ロボットではなく、手元のファイルを読ませて、編集させて、確認させるのが得意な CLI エージェントだ。だからこそ強い。逆に、曖昧な気分相談や、外部の事実確認を雑に任せると、平気で手戻りする。 ここで大事なのは、「何を頼めるか」を機能名で覚えることではない。何を渡すと速いか、何を渡すと危ないかを線引きすることだ。これがわかると、コード修正だけでなく、書類整理、不要ファイルの洗い出し、文章のたたき台作りまで、かなり現実的に使えるようになる。 Claude Code が強いのは、すでにあるファイルやディレクトリを読んで、そこから作業を進める場面である。たとえば、こんな依頼は相性がいい。 ```text このディレクトリ配下を見て、README を実態に合わせて直して。 古い手順、存在しないファイル名、曖昧な説明を消してほしい。 変更前に、どこをどう直すつもりか要約してから進めて。 ``` これはコードでも文書でも同じだ。実在するファイルを読ませて、そこから整える。Claude C
papoo.work
プロジェクトを開いて最初にやるべき3つの設定
プロジェクトを開いて最初にやるべき3つの設定
最初にやるべきことを飛ばして、いきなりClaude Codeに「これ直して」と投げる人は多い。で、あとからコンテキストが足りない、差分が広がりすぎる、同じ説明を何度も繰り返す、となって手戻りする。もったいない。 Claude Codeは、ただ起動して雑に命令する道具ではない。最初にプロジェクトの輪郭を整えると、以後のやり取りがかなり軽くなる。ここでやるべき設定は、細かい小技ではない。`CLAUDE.md` を置くこと、作業対象をきちんと閉じること、そして危ない自動実行を避けることだ。この3つを先に固めるだけで、迷走がかなり減る。 Claude Codeは、毎回ゼロから空気を読むわけではない。プロジェクトのルール、よく使うコマンド、触ってはいけない場所を先に書いておくほうが強い。これが `CLAUDE.md` だ。リポジトリのルートに置くのが基本になる。 たとえば開発案件なら、こんな内容で十分だ。 ```markdown このプロジェクトでは次のルールに従う。 既存のコードスタイルに合わせる 変更は必要最小限にする 依存関係の追加は事前確認する テストは `npm test` で実行する
papoo.work
Claude Code のセッションを上手に区切る：いつ /clear すべきか
Claude Code のセッションを上手に区切る：いつ /clear すべきか
コンテキスト管理を雑にすると、Claude Code はすぐ「前の話」を背負い込んで重くなる。これを放置してから「なんか話がズレるな」と首をひねるのは、だいたい手遅れだ。`/clear` は失敗の後始末ではなく、作業を切り替えるための道具として使う。 Claude Code のセッションは、ひとつの長話にしすぎるとだるい。依頼の文脈が積み上がり、関係ない前提まで抱えたまま応答する。コード修正でも文書作成でも同じで、「今やっている仕事」と「さっきまでの仕事」が混ざった瞬間に精度が落ちる。だから、`/clear` は気分転換ではなく、仕事の区切りを明示するために入れる。 まず感覚だけ先に言う。次のどれかに当てはまるなら、ほぼ ` /clear` でいい。 一つ目は、作業の目的が変わったときだ。たとえば、最初はバグ修正を頼んでいたのに、途中から仕様の相談に変わる。あるいは、ファイル整理をしていたのに、急に文案の推敲を始める。これは同じ仕事ではない。前の前提を持ち越すメリットがないので、切ったほうが早い。 二つ目は、別のディレクトリ、別の案件、別の対象に移るときだ。Claude Code は作
papoo.work
ファイルを丸ごと貼らずに済ませる：Claude Code に探させる頼み方
ファイルを丸ごと貼らずに済ませる：Claude Code に探させる頼み方
その長いファイル、わざわざ貼らなくていい。むしろ貼るな、である。 Claude Code に仕事をさせるときは、内容を全部コピーして投げるより、「どのファイルの、どこを、どう見ればいいか」を指示したほうが速いし、手戻りも少ない。コンテキストを無駄食いしないので、あとから本題の会話が崩れにくい。ファイル整理でも、仕様確認でも、議事録からの文書作成でも、この差は地味に効く。 筆者は最初、雑に本文を貼り付けていた。で、すぐ詰まった。長文のせいで肝心の指示が薄まり、返ってくる答えも広く浅い。しかも、途中で「この表だけ見れば足りたのに」と気づく。あれは本当にだるい。Claude Code は「探させる」ほうが強い。 やり方は単純だ。最初から全文を渡さず、ファイル名、場所、探してほしい観点をセットで渡す。たとえば、こんな感じだ。 ```text プロジェクト内の仕様書を見て、 「ログイン失敗時のエラーメッセージ」がどこで定義されているか探して。 関連するファイル名と該当箇所を挙げて、要点だけ説明して。 全文の要約は不要。 ``` もう少し実務っぽくすると、こうなる。 ```text /Users/
papoo.work
Claude Code の権限モードを理解する：自動承認はどこまで許すか
Claude Code の権限モードを理解する：自動承認はどこまで許すか
「全部おまかせ」で回すと、だいたいどこかで余計なものまで触る。Claude Code の権限モードは、その事故をどこで止めるかを決める仕組みだ。ここを雑に扱うと、ファイル整理のつもりが思わぬ上書きになったり、コード修正のつもりが確認なしで広範囲の変更に進んだりする。 権限モードで見るべき本質は単純だ。Claude Code に何を自動で許し、何を必ず止めるかを先に決めることだ。自動承認は便利だが、便利さの裏には「止めどころを失う」危険がある。特に、削除・移動・上書き・外部コマンド実行のあたりは、最初から雑に広く許可しないほうがいい。 Claude Code には、作業を進める前に都度確認を挟むか、ある程度まとめて承認するか、といった権限の扱いがある。呼び方や細かな表示は環境で違うことがあるが、考え方は同じだ。普段の編集は流し、壊れやすい操作だけ人間が止める。これが基本線になる。 たとえば、文章作成やファイル整理で使うなら、こう考えるといい。下書き作成やリネーム案の提示はかなり自由に任せる。だが、実際の移動・削除・上書きは一段慎重にする。開発でも同じで、コードの提案や差分
papoo.work
プランモードで「やる前に方針を確認」する使い方
プランモードで「やる前に方針を確認」する使い方
いきなり実行させてから「違う、そうじゃない」と止めるのは、だいたい一番高くつく。Claude Code のプランモードは、その手戻りを先に潰すための道具だ。作業を走らせる前に、方針・手順・危ない点を一回紙に出させる。これを挟むだけで、コンテキストの無駄食いも、雑な一括変更も、かなり減る。 プランモードは「何をするか」を先に固めるために使う。実行そのものを急がない。ここを逆にすると、便利な機能がただの遠回りになる。筆者も最初は、いきなり修正を走らせて、あとから「その前に依存関係を整理してほしかった」と気づいてやり直した。差分が肥大化すると、どこから崩れたのか追うのがだるい。だから先に方針確認だ。 使い方は単純で、最初に「変更はまだしないで、計画だけ出して」と頼む。たとえばコード修正なら、こんなふうに始める。 ```text この作業はまだ実行しないでください。 まず方針を確認したいです。 目的: 既存のログ出力を整理したい ただし振る舞いは変えすぎたくない やってほしいこと: 1. 関係するファイルを洗い出す 2. 変更方針を3案くらい出す 3. それぞれのメリット・リスクを書く 4.
papoo.work
差分を小さく保つ：大きな変更を安全に進めるための区切り方
差分を小さく保つ：大きな変更を安全に進めるための区切り方
大きな作業を一気に投げると、だいたいロクなことにならない。Claude Code でも同じで、広い範囲をまとめて触らせるほど、意図しない変更が混ざるし、あとから差分を読むのも地獄になる。 ここでやるべきなのは、仕事を小さく切ることだ。Claude Code に「全部やって」で渡すのではなく、変更の境界を先に決める。そうすると、差分が読みやすくなるだけではない。途中で止めて確認しやすいし、手戻りしても被害が小さい。ファイル整理でも、文章修正でも、コード修正でも、この考え方が効く。 筆者は最初、ひとまとまりの依頼をそのまま投げて、関係ないファイルまで巻き込まれたことがある。修正点そのものは合っているのに、差分が太りすぎてレビューで疲れるやつだ。あれはかなりだるい。以後は「どこまでやるか」を先に決めてから頼むようにしている。 差分を小さくするコツは、作業を結果で分けるのではなく、工程で分けることだ。 たとえば、ひとつの大きな改修があったとする。いきなり完成版を作らせるより、こう分ける。 1. 既存の構成を確認する 2. 変更対象を絞る 3. 最小の修正を入れる 4. 差分を見て、余計な変更を
papoo.work
Claude Code が間違えたときの戻し方：作業を捨ててやり直す
Claude Code が間違えたときの戻し方：作業を捨ててやり直す
Claude Code が変な方向に進んだとき、いちばん危ないのは「少し直せば戻るだろう」と粘ることだ。そこから先は、直すための指示がさらに増えて、コンテキストも汚れて、結局もっと面倒になる。 この手の CLI コーディングエージェントは、雑に言えば「今ある作業状態」を読んで次を決める。だから、間違えたときは作業を抱えたまま修正会議を続けるより、いったん捨てて、まっさらな状態でやり直したほうが早い場面が多い。 筆者も最初はこれで何度かやらかした。小さな修正のつもりで指示を重ねたら、diff が妙に広がって、元の意図から外れた変更まで混ざる。あとから人間が見て「これはどこから来た？」となるやつだ。 なのでこの話では、Claude Code が迷走したときに何を捨て、何を残し、どうやって再出発するかを、実務寄りに整理する。 まず押さえるべきなのは、戻し方は1つではないという点だ。 すでにファイルを書き換えたあとなら Git で戻す。まだファイルを触っていないなら、セッションを切って、依頼文を作り直す。途中までの成果に価値がないなら、未練なく捨てる。ここを曖昧にすると、いつまでも半端な状態が
papoo.work
ターミナルが苦手でも使える：Claude Code の最小限の操作だけ覚える
ターミナルが苦手でも使える：Claude Code の最小限の操作だけ覚える
「ターミナルは怖いから触らない」は、Claude Code を使うときだけはかなり損だ。 ただし、だからといって黒い画面の達人になる必要はない。覚えるのは本当に少しでいい。`cd` で場所を変える、`claude` を起動する、終わるときは `exit`。まずはこれだけで回る。 Claude Code は Anthropic の CLI コーディングエージェントだが、名前に反してエンジニア専用ではない。フォルダの中身を整理したい、散らかった文書をまとめたい、不要ファイルを減らしたい。そういう用途でもかなり使える。大事なのは、ターミナルを「操作する」ことではなく、Claude Code に「そのフォルダで何をしてほしいか」を短く伝えることだ。 最初にやることは単純だ。作業したいフォルダに移動して、Claude Code を起動する。 ```bash cd ~/Documents/案件A claude ``` ここで `cd` は「そのフォルダに入る」コマンド、`claude` は Claude Code を立ち上げるコマンドだ。フォルダ名のところは自分の環境に合わせればいい。たとえば書類
papoo.work
Claudeの「超過課金」は自動発生しない——note記事の補足と2026年6月の仕様変更
Claudeの「超過課金」は自動発生しない——note記事の補足と2026年6月の仕様変更
先日、[「Claudeは weekly limit や 5hours limit を突き破ったときのペナルティ料金が半端ない」](https://note.com/modern_ferret431/n/n821d3055d109) という記事が話題になった。Claude CodeやOpusでコードベース解析を回していると、10分足らずで従量課金が発生し得るという警告は実体験として貴重だが、エンジニアが実際に運用判断をする上で誤解しやすいポイントがいくつかある。本記事はその補足として、Anthropic公式ドキュメントに基づき仕組みを整理する。 最大の誤解ポイントはここ。Claude Pro/Maxで週次・5時間の利用上限に達しても、Usage credits（超過課金）を明示的に有効化していない限り、追加料金は一切発生しない。上限に達した場合の既定動作は「リセットまで待つ」だけで、勝手にAPI従量課金へ切り替わることはない。 有効化するには以下の手順が必要: `Settings > Usage` から Usage credits セクションで Enable をクリック
papoo.work
非エンジニアのための最小ターミナル入門：Claude Code に任せる前提で
非エンジニアのための最小ターミナル入門：Claude Code に任せる前提で
「ターミナルはエンジニアの武器」みたいな顔をしているが、Claude Code を使うなら、非エンジニアこそ最低限だけ覚えておいたほうが速い。全部を理解する必要はない。だが、入口と出口を知らないまま突っ込むと、ファイルの置き場所が分からず詰む。そこで止まるのはもったいない。 ここでいうターミナルは、黒い画面そのものをいじり倒す話ではない。Claude Code に「このフォルダで作業して」「このファイルを見て」「この名前に直して」と頼むための、最低限の足場だと思えばいい。要るのは、移動する、見る、戻る、そして作業前に退避する、の4つだけである。 まず覚えるのは、たったこれだけで足りる。 ```bash pwd ls cd フォルダ名 cd .. ``` `pwd` は今いる場所を表示する。`ls` はその場所にあるファイルやフォルダを見る。`cd フォルダ名` は移動、`cd ..` はひとつ上の階層に戻る。これで家の中をうろつくくらいのことはできる。深い仕組みは要らない。 Mac ならターミナル、Windows なら PowerShell を開いて、まず自分がどこにいるかを見る。思っ
papoo.work
フォルダの中身を棚卸しして「何が入っているか」を一覧化する
フォルダの中身を棚卸しして「何が入っているか」を一覧化する
フォルダを見て「何が入っているか」を口で説明できないなら、だいたい整理は崩れている。ファイル名を眺めるだけでは足りないし、サブフォルダが深いと、人間の頭ではすぐ抜け落ちる。Claude Code は、その見落としを雑に埋める道具としてかなり使える。 やることは単純だ。指定したフォルダの中身を洗い出し、階層ごとに一覧にする。必要なら、種類ごとに分ける。重複っぽいものや、でかいファイルが混じっていないかまで見える。ディスク整理でも、案件フォルダの把握でも、書類の棚卸しでも効く。 最初に大事なことを言うと、Claude Code に「このフォルダを見て要約して」とだけ投げるのは雑すぎる。そうすると、見出しだけのふわっとした返事になりやすい。欲しいのは要約ではなく、一覧だ。しかも、後で自分が再利用できる粒度の一覧である。 たとえば、こういう頼み方をする。 ```bash claude ``` プロンプトでは、まず目的をはっきり書く。 ```text このフォルダの中身を棚卸しして、何が入っているかを一覧にしてください。 人間が後で整理しやすいように、次の順で出してください。 1. 直下のフォル
papoo.work
PDF や議事録の山から必要な情報だけ抜き出して表にまとめる
PDF や議事録の山から必要な情報だけ抜き出して表にまとめる
PDF を全部読んでから表を作る、あれは一番だるい。しかも大抵、読み落としが出る。Claude Code の出番はそこだ。ファイルの山を丸ごと相手にして、必要な項目だけ拾い、CSV か Markdown の表に整える。人力で目を通す仕事を、最初のふるい分けだけでもかなり減らせる。 ここで大事なのは、いきなり「全部まとめて」と投げないことだ。雑に頼むと、抜き出し対象がぶれたり、表の列が途中で増えたりする。筆者は最初、会議議事録を一気に食わせて「決定事項だけ表にして」と頼み、欲しかったのは案件名・担当者・期限だったのに、Claude Code が空気を読んで論点まで拾い始めたことがある。悪くはないが、欲しい形ではない。こういう手戻りが一番もったいない。 まずは対象を狭く決める。PDF や議事録の置き場をひとつのフォルダに寄せて、何を抜き出したいのかを列ごとに言葉で固定する。たとえば、案件ごとの一覧なら「ファイル名、日付、案件名、決定事項、担当者、期限」で十分だ。全部を要約させるより、表にしたい項目だけ指定したほうが強い。 実際の頼み方はこんな感じでいい。 ```bash claude ``
papoo.work
大量のファイルを内容で分類してフォルダに振り分けてもらう
大量のファイルを内容で分類してフォルダに振り分けてもらう
ファイル名だけ見て振り分けようとするのは、だいたい雑に終わる。`final_2` とか `新規` とか `scan0007` みたいな地獄を、名前だけで救えるわけがない。こういうときは、Claude Code に「中身を読ませて分類させる」ほうが早い。 やりたいことは単純だ。大量の PDF、テキスト、Markdown、メモ、書類を、内容を見て「契約」「請求」「議事録」「レシート」「未分類」みたいなフォルダへ振り分ける。人間がやると面倒だし、疲れると判断がブレる。Claude Code なら、ルールをきっちり渡せば、かなり機械的に回せる。 ただし、ここを雑に頼むとすぐ詰まる。分類基準があいまいだと、よくわからないフォルダが増えるだけだし、元ファイルの移動を先にやらせると取り返しがつかない。まずは「コピーで試す」「ルールを固定する」「例外を作る」の三つを押さえるのが筋だ。 最初に、分類の軸を人間側で決める。Claude Code は賢いが、勝手にあなたの仕事の流儀を理解してくれるわけではない。たとえば、法務書類ならこんな切り方が現実的だ。 契約書 見積書 請求書 受領書・領収書 議事録 仕
papoo.work
重複ファイルと不要キャッシュを洗い出してディスクを大幅に空けた話
重複ファイルと不要キャッシュを洗い出してディスクを大幅に空けた話
ディスクが足りないとき、多くの人はまず「大きいフォルダ」を探す。だが、実際に効くのはそこじゃない。見落としやすい重複ファイルと、放置された不要キャッシュだ。ここを片付けると、ディスク整理とストレージ削減の効き方が一段違う。 Claude Code は、こういう“散らかった証拠集め”に向いている。ファイル一覧を読ませて、重複候補を洗い出し、消してよさそうなものと残すべきものを切り分ける。自分で全部目視するとだるい作業を、かなり前まで持っていける。 ただし、雑にやると普通に痛い目を見る。筆者も最初は「大きいファイルだけ見ればいいだろ」と思って進め、あとで同じ画像の複製や、文書生成ツールのキャッシュをまとめて抱えていたことに気づいた。そこから先は、Claude Code に“見つける役”をやらせるようにした。 まずやることは単純だ。Claude Code に、対象フォルダの一覧を見せて、サイズ順に怪しいものを拾わせる。重複はファイル名だけでは当てにならない。よくあるのは、`final`、`final2`、`final_revised` みたいな半端な複製だし、画像なら見た目が同じでも保存形式
papoo.work
弁護士が案件ごとにフォルダを掘り、関連書類から書面の下書きを作る
弁護士が案件ごとにフォルダを掘り、関連書類から書面の下書きを作る
案件フォルダが散らかっていると、書面づくりはただの手作業地獄になる。士業でも書類整理でも同じで、探す時間が長いほど、肝心の中身を考える時間が削れる。 Claude Code はコードを書く道具だと思われがちだが、実は「フォルダを掘って、関連ファイルを拾い、下書きを作る」作業にかなり向いている。弁護士の案件管理みたいな使い方でも効く。やることは単純で、案件ごとにディレクトリを切り、そこに集めた PDF、メモ、メール書き出し、下書きテキストをまとめて読ませる。すると、論点の整理や書面のたたき台づくりが一気に楽になる。 ただし、雑に使うとすぐ詰まる。フォルダが深すぎる、指示が曖昧、関係ない資料まで全部入れる。この三つで平気で手戻りする。筆者も最初は「案件名だけ投げれば何とかなる」と思って失敗した。実際には、何を優先して読ませるかを先に決めないと、出てくる下書きがぼんやりする。これはかなり重要だ。 まず、案件の単位で作業用フォルダを切る。たとえばこうだ。 ```text 案件A/ 00_依頼内容/ 10_証拠/ 20_相手方書面/ 30_メモ/ 90_下書き/ ``` 番号を付けるのは見た目の
papoo.work
写真や書類のファイル名を内容に沿って一括リネームする
写真や書類のファイル名を内容に沿って一括リネームする
「IMG_4839.jpg」を100枚並べて、あとで中身を見てから直そうとする。あれ、だいたい破綻する。写真でも書類でも、名前が意味を持っていないと、探すだけで時間を食う。Claude Code は、その手の雑な山を一気に片づけるのに向いている。 ただし、いきなり「全部いい感じにリネームして」と投げるのは危ない。ファイル名は短いのに、中身は長い。だから先にやるべきことは、Claude Code に内容を読ませる前提を整えて、命名ルールを決めることだ。ここを飛ばすと、出力はそれっぽいが、あとで人間が直す羽目になる。筆者は最初、このあたりを雑に頼んで、日付形式がバラけたファイル群を量産してしまった。見た目は整っているのに、並び順がぐちゃぐちゃで、結局やり直しだ。痛い。 まず大事なのは、Claude Code に「何を材料にして、どういう名前にするか」をはっきり渡すことだ。写真なら撮影日、場所、被写体。書類なら日付、相手先、案件名、文書種別。この4つのどれを優先するかで、後の検索性が変わる。 たとえば、写真整理ならこういう指示でいい。 ```text このフォルダ内の画像ファイルを見て、内容
papoo.work
Claude Code に自分の作業を検証させる：思い込みを潰す確認の頼み方
Claude Code に自分の作業を検証させる：思い込みを潰す確認の頼み方
人は、自分で直したコードや片づけたファイルをいちばん雑に見てしまう。見たつもりで見落とすし、「たぶん合ってる」で突っ走る。Claude Code を使う場面でも、ここが一番まずい。 この手の失敗は、派手なバグより地味に痛い。ファイル整理なら不要データを残したまま「空いた気になる」。文書作成なら、参照漏れや表記ゆれを見逃す。開発なら、テストが通っただけで安心して、実は境界条件を壊している。だから Claude Code には「作って」と頼むだけでなく、「自分の作業を疑え」と頼むのが効く。 要は、Claude Code を作業者ではなく、検査役として使う発想だ。しかも、ただ「チェックして」と投げるだけでは弱い。どこを、何と照合し、何をもって問題なしとするかを、先に決めておく必要がある。 一番ありがちな失敗は、作業のあとにこう言うことだ。 ```text これ、確認して。 ``` これでは甘い。Claude Code は広く見られるぶん、広く見て終わる。見る範囲が曖昧だと、確認の密度が下がる。確認役にしたいなら、検証対象をはっきり切るべきだ。 たとえば、コードなら「変更した関数だけ」「テスト
papoo.work
エラーログを貼って原因を切り分けてもらう頼み方
エラーログを貼って原因を切り分けてもらう頼み方
ログを貼らずに「動きません」だけ投げるのは、ほぼ自爆だ。Claude Code に原因切り分けを頼むなら、症状の説明より先に、エラーログをそのまま渡したほうが速い。これは開発作業でも、ファイル整理でも、書類の自動生成でも同じである。曖昧な依頼は、余計なやり取りを増やしてコンテキストを食い、最後に「それ、最初に出してくれれば済んだのに」になる。 Claude Code は、端末上で見えているエラー文や関連ファイルを手がかりに、何が壊れているかをかなり実務的に絞れる。だが、こちらの頼み方が雑だと、関係ない方向を見始める。筆者も最初は「なんか失敗する」で投げて、延々と見当違いの説明を掘らせたことがある。ログを最初から貼っておけば、あの無駄な往復はかなり減ったはずだ。 まず、頼み方の基本形はこれでいい。 ```text 次のエラーログを読んで、原因候補を優先度順に切り分けてください。 不明な点は、追加で見るべきファイルやコマンドも挙げてください。 推測だけで断定せず、ログから読める事実と推測を分けてください。 ``` これだけでも十分使えるが、実際には少し足したほうが強い。Claude Cod
papoo.work
失敗するテストを先に書いてもらい、それを通す形で直す
失敗するテストを先に書いてもらい、それを通す形で直す
「直してから確認する」は、だいたい遠回りだ。Claude Code にも同じで、まず壊れるテストを作らせてから、その赤を消す形でコードを直すほうが、手戻りが少ない。 このやり方の良さは単純だ。何を満たせばいいかが先に固定される。しかも、Claude Code が勝手に話を広げにくい。いきなり実装をいじらせると、見た目は動いても境界条件を落とすことがある。先に失敗するテストを書かせれば、「何を守るべきか」をコードより先に置ける。 筆者も最初は、仕様を口で説明してそのまま直させていた。すると、動くけれどテストが増えない。次に同じ不具合が出たとき、また同じ説明を繰り返す羽目になる。そこで先にテストを書かせるようにしたら、会話の焦点が一気に締まった。曖昧な依頼が減るし、差分も追いやすい。かなり地味だが、効く。 やり方はこうだ。Claude Code に最初から「壊れているテストだけを作れ」と頼む。実装はまだ触らせない。たとえば Python なら pytest、JavaScript なら既存のテストランナーに合わせて書かせる。非エンジニアが文書整理やファイル整理に使う場合でも同じで、たとえば「
papoo.work
「再現手順」を渡してバグを再現させてから直してもらう
「再現手順」を渡してバグを再現させてから直してもらう
「壊れてるから直して」で投げると、だいたい遠回りになる。Claude Code みたいなCLIエージェントは、雰囲気で当てるより、再現できる条件を渡したほうがずっと強い。 バグ修正で本当に効くのは、症状の説明を増やすことではない。再現手順を切り分けて、同じ失敗をもう一度起こさせることだ。そこまでできれば、Claude Code はログやコードを追いやすくなるし、修正後の確認まで一気通貫で進められる。逆に、あいまいな「なんか動かない」は、コンテキストを食うだけ食って、外す。筆者も最初はこれで手戻りした。変更箇所を広げすぎて diff が膨らみ、直したいバグより副作用の確認に時間を取られた。あれはだるい。 まずやることは単純だ。Claude Code に「原因を探して」と丸投げする前に、こちらで再現条件を短く固める。たとえばこうだ。 ```text 次の不具合を再現してから修正してほしい。 症状: ファイル名に日本語が入っていると、出力先のリネームが失敗する 再現手順: 1. sample/ に「議事録 2024-01.txt」を置く 2. そのファイルを対象に変換コマンドを実行する 3.
papoo.work
定型作業をスクリプト化させて手作業を消す
定型作業をスクリプト化させて手作業を消す
毎回同じ名前でフォルダを掘って、同じ文言で文書を整えて、同じゴミを消しているなら、もう人間がやる仕事ではない。そこを Claude Code に渡すと、作業そのものよりも「抜け漏れを気にしている時間」がごっそり減る。 Claude Code は、指示された処理を実行する CLI のコーディングエージェントだ。コードを書くためだけの道具だと思われがちだが、実際にはファイル整理、レポート生成、命名の統一、不要ファイルの洗い出しみたいな定型作業にもかなり使える。要は、手で何度もやっていた手順を、毎回同じ形で再現させればいい。 ただし、ここで雑に「このへん片付けて」と投げると、だいたい薄い返答が返る。筆者も最初はそのやり方で何度か手戻りした。理由は単純で、作業の目的と入力と出力が曖昧だと、エージェントは余計な確認にコンテキストを食うし、こちらも差し戻しに時間を取られるからだ。定型作業のスクリプト化は、気合いではなく設計で決まる。 まずやることは、作業を「手順」に分解することだ。Claude Code に任せたいのは、漠然とした片付けではない。たとえばこういう粒度に落とす。 あるフォルダの中から
papoo.work
長時間かかる処理を Claude Code に任せて結果だけ受け取る
長時間かかる処理を Claude Code に任せて結果だけ受け取る
それ、途中で画面を見張っているからだるくなるのである。長時間かかる処理は、手を止めて待つより、Claude Code に投げて終わった結果だけ拾う形にしたほうがいい。ファイルの棚卸し、重複の洗い出し、ログの整理、文章の下書き、リポジトリ内の一括確認みたいな作業は、特に相性がいい。 ただし、雑に「これやっといて」で放り投げると、あとで手戻りが出る。筆者は最初、指示を薄くしたまま大きめのディレクトリを一気に見させて、要らないはずのものまで候補に上がってきて差し戻した。人間に丸投げするのと同じで、終わり方を先に決めておかないと、待ち時間だけ増えて得るものが薄くなる。 やり方の基本は単純だ。長い処理を「探索」「判断」「結果の保存」に分けて、Claude Code には判断と保存までやらせる。あなたは途中経過を逐一見る必要はない。最後にファイルや要約ができていればいい。 たとえば、プロジェクト内の不要ファイル候補を洗って、結果をレポートに残したいなら、こう頼む。 ```bash claude ``` 対話を始めたら、指示はこんな感じで十分だ。 ```text このディレクトリ以下を調べて、容量を
papoo.work
Claude Code から外部 API やデータベースを安全に触らせる勘所
Claude Code から外部 API やデータベースを安全に触らせる勘所
雑に「API叩いておいて」「DB見ておいて」と投げると、Claude Code はだいたい困る。困るだけならまだいいが、権限が広すぎると余計な変更まで手を出す。ここでやるべきことは単純で、触れる範囲を狭く切り、危ない操作は人間の確認を挟み、あとで検証できる形にしておくことだ。 Claude Code は Anthropic の CLI ベースのコーディングエージェントで、ローカルのファイルだけでなく、外部 API やデータベースに対する作業にも使える。とはいえ、何でも自由にやらせると事故る。たとえば、調査だけのつもりが更新系の SQL を流す、一覧取得だけのつもりが大量データを吸い上げてコンテキストを食い潰す、認証情報を雑に置いて別の用途まで届いてしまう。こういう手戻りは、最初の設計でかなり減らせる。 まず押さえるべきは、「Claude Code に直接本番の権限を持たせない」ことだ。これは大げさでも何でもない。外部 API なら読み取り専用のトークンを分ける、DB なら参照専用ユーザーを作る、変更系は別の手順に分ける。Claude Code に渡すのは、最小権限の資格情報だけにする。
papoo.work
どの MCP を入れるべきか：入れすぎない選び方
どの MCP を入れるべきか：入れすぎない選び方
MCP は、入れれば入れるほど便利になるものではない。むしろ逆で、雑に増やすと Claude Code の中身が散らかって、何を頼むにも余計な確認が増える。ここを外すと、最初は賑やかでも、そのうち「結局どれを使えばいいんだ」となる。 Claude Code を使っていて本当に効くのは、数を増やすことではなく、仕事に直結する少数を選ぶことだ。ファイル整理でも、コード修正でも、文書作成でも同じで、よく使う保管場所と、よく触るサービスだけをつなぐほうが強い。MCP は武器庫ではなく、工具箱だと思ったほうがいい。 まず前提を揃える。ここでいう MCP は、Claude Code が外部のツールやデータに安全にアクセスするための接続口だ。たとえばファイルシステム、GitHub、Google Drive、Slack、ブラウザ操作系の連携がある。名前が似たものを片っ端から入れる必要はない。むしろ、何をどこまで見せるかを絞るのが先だ。 筆者は最初、便利そうな MCP をまとめて入れたことがある。結果どうなったかというと、Claude Code に頼むたびに「それはローカルファイルなのか、GitHub
papoo.work
MCP サーバを 1 つ追加してみる：最初の連携の始め方
MCP サーバを 1 つ追加してみる：最初の連携の始め方
最初の失敗はだいたい決まっている。いきなり何個も MCP サーバを足して、どれが何をしているのか分からなくなるやつだ。これをやると、Claude Code の便利さより先に、設定の面倒くささだけが残る。まずは 1 つだけ足す。これがいちばん速い。 MCP は Model Context Protocol のことだが、名前を覚える必要は薄い。要するに、Claude Code に外部の道具を 1 つずつつなぐ仕組みだ。たとえばファイルを読む、ディレクトリをたどる、特定の情報源に触る、といった作業を Claude Code に任せやすくなる。開発用の道具だと思われがちだが、実際はファイル整理や文書作成にも効く。むしろ最初の 1 個は、コード補完より「手元の資料をどう扱うか」で入れるほうが失敗しにくい。 たとえば「このフォルダの中から古い重複書類を見つけたい」「案件ごとの資料を見ながら要約を書かせたい」「作業用ディレクトリだけ見せて、そこから整理させたい」といった用途だ。Claude Code 単体でもできることはあるが、見える範囲を絞って外部の情報源をつなぐと、やり取りがかなり楽になる。 ま
papoo.work
MCP とは何か：Claude Code に外部ツールをつなぐ仕組みを噛み砕く
MCP とは何か：Claude Code に外部ツールをつなぐ仕組みを噛み砕く
「Claude Code に何でもやらせたい」と言いながら、結局は会話欄に手作業でコピペしている。そこ、かなりもったいない。 MCP はその手間を減らすための仕組みだ。正式には Model Context Protocol。Claude Code に外部ツールや外部データをつなぎ、必要なときに呼び出せるようにする共通の口だと思えばいい。 ここで大事なのは、MCP は“AI を賢くする魔法”ではなく、“Claude Code が触れる道具を増やす配線”だという点である。 たとえば、ローカルのファイル、社内のドキュメント、GitHub、DB、チケット管理、検索インデックス。こういうものを Claude Code が見に行ったり、更新したりできる。毎回、人間がコピペで橋渡ししなくてよくなる。 ただし、雑に足すと逆に詰まる。 筆者も最初は「とりあえず便利そうだから」とあれこれつなぎ、どのツールが何をしているのか分からなくなって、結局コンテキストを食い散らかした。外部ツールは増やせば勝ちではない。必要なものだけを、役割を決めて入れるのが正解だ。 MCP は、Claude Code と外部ツールの
papoo.work
個人設定とプロジェクト設定を使い分ける：settings.json の置き場所
個人設定とプロジェクト設定を使い分ける：settings.json の置き場所
設定ファイルを1か所にまとめれば楽だと思っていると、だいたいあとで詰まる。Claude Code の settings.json も同じで、全部を個人設定に押し込むと、別プロジェクトで余計な癖が出る。逆にプロジェクト側に何でも書くと、今度は毎回同じ説明を繰り返す羽目になる。 この話の肝は単純だ。自分の作業スタイルに関わるものは個人設定、案件やリポジトリ固有のルールはプロジェクト設定に置く。これだけで、コンテキストの無駄打ちが減るし、指示の取り違えも減る。筆者は最初、案件ごとのルールまで個人側に寄せてしまい、別プロジェクトでも古い前提を引きずって手戻りした。あれは地味にだるい。設定の置き場所を雑にすると、AIの賢さ以前に運用が崩れる。 まず押さえるべきなのは、Claude Code が読む settings.json は大きく「個人」と「プロジェクト」の2系統で考えることだ。個人設定は、その人のマシン全体で効かせたいもの。プロジェクト設定は、そのリポジトリだけで効かせたいものだ。チーム作業ならなおさら、この分け方が効く。自分専用の好みと、みんなで守るルールを混ぜると、あとで誰かが
papoo.work
サブエージェントに調べ物を任せて本流の文脈を汚さない
サブエージェントに調べ物を任せて本流の文脈を汚さない
調べ物を全部ひとつの会話に押し込むと、すぐに文脈が死ぬ。これ、かなりありがちな失敗だ。Claude Code にはサブエージェント、英語で subagent と呼ばれる仕組みがあり、重い調査や周辺確認を分離して、本題の流れをきれいに保てる。うまく使うと、メインの作業は設計や編集に集中できるし、調べ物の途中で話が散らからない。ファイル整理でも、文書作成でも、コード修正でも効く。 筆者は最初、ひとつの会話の中で「このフォルダの重複ファイルも見て、不要キャッシュも見て、ついでに命名ルールも考えて」と全部投げた。結果、会話履歴が調査メモで埋まり、本題の指示がどんどんぼやけた。出てきた差分も読む気が失せる。あれはだるい。サブエージェントに分ければ、そういうムダな汚れをかなり減らせる。 やり方は単純だ。まず本流では「何を決めたいか」だけをはっきり書く。調べ物そのものは、サブエージェントに切り出す。たとえば、Claude Code にこんなふうに頼む。 ```text この案件では、メインの会話は意思決定と最終編集に使いたいです。 調査が必要な作業はサブエージェントに分けてください。 調べたいこと:
papoo.work
hooks で「保存したら自動でフォーマット」を仕込む
hooks で「保存したら自動でフォーマット」を仕込む
保存のたびにフォーマットを走らせたいのに、毎回「あとで Claude Code に整えて」と頼んでいるなら、かなり遠回りだ。フック、つまり hooks を使えば、その面倒な一手を先回りできる。 やりたいことは単純で、ファイルを保存した瞬間に Claude Code がフォーマット用の指示を受け取り、見た目や表記ゆれを整える流れを作ることだ。コードでも文章でも、雑に保存しても最後は同じ型に寄せたい。ファイル整理でも、Markdown の文書整形でも、この発想は効く。人間が毎回「整えて」と言うより、保存後の処理に吸わせたほうが圧倒的にだるくない。 ただし、ここで雑にやると逆に荒れる。保存のたびに全文をいじる、曖昧な指示で毎回違う結果になる、差分がでかくなって見直しづらくなる。この手の手戻りは、筆者も最初にかなり踏んだ。便利そうだからと丸投げすると、保存のたびに余計な修正が増えて、かえって手作業より面倒になる。だから最初から「何を直すか」を狭く決めるのがコツだ。 Claude Code には hooks がある。要するに、あるタイミングで決まった処理を差し込む仕組みだ。保存後にフォーマット、
papoo.work
権限の許可リストを整えて確認ダイアログを減らす
権限の許可リストを整えて確認ダイアログを減らす
毎回「これ許可していい？」を踏ませてくるなら、だいたい整理の仕方が悪い。Claude Code は便利だが、むやみに広い権限を渡すより、よく使う場所だけを先に許可リストへ入れておいたほうが、手が止まらない。 ここでいう権限の許可リストは、Claude Code が操作してよいディレクトリやファイルの範囲を、あらかじめ絞っておく考え方だ。リポジトリの中だけ、作業用フォルダだけ、あるいは特定の案件フォルダだけ。こうしておくと、余計な確認ダイアログが減る。結果として、ファイル整理でも文書作成でも、流れが途切れにくくなる。 筆者は最初、作業範囲を広く取りすぎて、ちょっとした編集でも確認が挟まっていた。これが地味にだるい。逆に絞りすぎると、今度は毎回止まる。中途半端な広さがいちばん使いにくい。Claude Code は「どこまで触っていいか」を先に決めてやると、急に扱いやすくなる。 まず押さえるべきなのは、許可リストを「便利設定」だと思わないことだ。これは安全のための境界線であり、同時に作業の段取りでもある。たとえば案件ごとにフォルダを分けているなら、その案件フォルダだけを作業範囲にする。会計資
papoo.work
よく使う頼みごとをスラッシュコマンド（カスタムコマンド）にする
よく使う頼みごとをスラッシュコマンド（カスタムコマンド）にする
毎回同じお願いをベタ打ちしているなら、そこがいちばんムダだ。Claude Code は「よく使う頼みごと」をスラッシュコマンドに落としておくと、指示の抜け漏れが減るし、毎回の入力もかなり軽くなる。 たとえば「このフォルダをざっと整理して」「この文章を読みやすく直して」「この差分を短く要約して」といった定番の頼み方は、手で打つほど雑になりやすい。急いでいると条件を書き忘れるし、長い依頼文はコピペのたびに少しずつ崩れる。そうなると、Claude Code 側は毎回あいまいな指示を受けて、手戻りが増える。筆者も最初はここでだいぶ損をした。頼みごとをそのまま繰り返していたせいで、出力の粒度が毎回ぶれて、結局もう一回やり直す羽目になった。 スラッシュコマンドは、その定番依頼を短い呼び出し名にまとめるやり方だ。Claude Code ではカスタムスラッシュコマンドをファイルとして置いておける。公式の扱いに沿って使うなら、まずは `CLAUDE.md` のような指示ファイルに毎回の前提を書き、個別の頼みごとはスラッシュコマンド化しておく、という分け方がしっくりくる。 たとえば、ドキュメントを毎回この
papoo.work
CLAUDE.md に書くと効くこと・書いても効きにくいこと
CLAUDE.md に書くと効くこと・書いても効きにくいこと
CLAUDE.md を「雑に長文で埋める箱」だと思っていると、だいたい損をする。効くのは、毎回ブレると困る前提だけだ。逆に、巨大な社内規約や操作マニュアルを丸ごと押し込んでも、Claude Code はそこを丁寧に読み上げる執事にはならない。 Claude Code でいう CLAUDE.md は、リポジトリや作業フォルダに置く指示メモだ。Claude Code がその場所で作業するときの癖付けに使う。ここに何を書けば手戻りが減るか、何を書いても効きが鈍いかを分けておくと、コンテキストの無駄食いがかなり減る。 まず効くのは、「この場所では何を優先するか」を短く固定することだ。たとえば、出力の形式、触ってよい範囲、依頼が曖昧なときの確認順、勝手に壊してはいけないもの、よく使うコマンドやディレクトリ構成などだ。逆に効きにくいのは、毎回変わる具体的な作業指示、長すぎる背景説明、抽象的なお作法の羅列である。そこを混ぜると、肝心のルールが埋もれる。 最初に押さえるべきなのは、CLAUDE.md は「長い説明書」ではなく「現場の癖」を書く場所だという点だ。たとえば、こんな書き方はかなり効く。 ``
papoo.work
CLAUDE.md にプロジェクトの作法を書いて毎回の説明を省く
CLAUDE.md にプロジェクトの作法を書いて毎回の説明を省く
毎回同じことを口で説明しているなら、その時点でもう負けである。Claude Code に仕事を頼むたびに「このフォルダは何のためのものか」「どのファイルを触っていいか」「何を勝手に変えないでほしいか」を打ち直していると、コンテキストも時間もじわじわ溶ける。そこで使うのが `CLAUDE.md` だ。別名でプロジェクトメモリとも呼べる。要するに、プロジェクト固有の作法を置いておくメモである。 これをちゃんと置いておくと、毎回の依頼が短くなる。しかも短くなるのは言葉だけではない。Claude Code が前提を取り違えにくくなるので、手戻りも減る。筆者は最初、都度の指示だけで回そうとして、同じ注意を書いては消し、また書いては消しを繰り返した。結果、依頼文が肥大化して、肝心の作業指示が埋もれた。あれはだるい。`CLAUDE.md` はその無駄を消すための置き場だ。 やることは単純だ。リポジトリのルートに `CLAUDE.md` を置き、そこに「このプロジェクトでは何を大事にするか」「どう編集するか」を書く。Claude Code は作業中にその内容を参照するので、毎回プロンプトに長文で貼らな
papoo.work
大規模な置換を一気にやらない：段階コミットで巻き戻せるようにする
大規模な置換を一気にやらない：段階コミットで巻き戻せるようにする
置換を1回で全部終わらせようとして、あとで何が起きたか分からなくなる。これ、かなりありがちな失敗だ。Claude Code に大量の修正を投げると、ファイルのあちこちを同時に触れて、差分がでかくなり、どこで壊れたのか追いにくくなる。巻き戻したいのに、戻す単位すら見えない。そこで効くのが段階コミットだ。小さく直して、小さく確かめて、小さくコミットする。これだけで手戻りの痛さがかなり減る。 たとえば、プロジェクト内の文言を「旧サービス名」から「新サービス名」に置き換える、フォルダ名を整理する、説明文の表記ゆれを直す、不要ファイルをまとめて消す。こういう作業を Claude Code に任せるとき、いきなり「全部やって」で済ませると危ない。実際、筆者は過去に、似た名前のファイルをまとめてリネームさせたあとで、関連参照の修正まで一気に走らせてしまい、どの変更がどの影響を生んだのか見えなくなったことがある。diff が肥大化して、結局、途中まで戻してやり直しだ。あれはだるい。 やり方は単純だ。ひとつの巨大タスクを、意味のある小片に分ける。Claude Code には、その都度「この範囲だけ」「こ
papoo.work
「なぜこのコードがあるのか」を git 履歴から説明させる
「なぜこのコードがあるのか」を git 履歴から説明させる
そのコード、ただ動くだけで満足していないか。いちばん厄介なのは「何のために残っているか誰も覚えていない行」だ。消すと壊れそうで怖い、残すと読みづらい。こういうときに Claude Code に git 履歴を当たらせると、ただの謎コードが「いつ、誰が、どの意図で入れたか」に変わる。意味が見えるだけで、保守のストレスはかなり減る。 この手の調査でやることは単純だ。コード片を見せて、「このコードが入った経緯と目的を、git 履歴から説明して」と頼む。うまくやれば、変更を入れたコミット、関連しそうな差分、前後の文脈をたどって、なぜそこにその実装があるのかを整理してくれる。非エンジニアなら、たとえばファイル整理ツールの不思議な判定条件や、ドキュメント生成用のスクリプトがなぜその保存先を使うのかを理解するのに使える。弁護士や事務職でも、案件フォルダの命名ルールや不要ファイル削除の条件を追うときに役立つ。 やり方は、まず対象を小さく切るのがコツだ。巨大なファイル丸ごとを投げると、履歴の説明より表面の要約に逃げやすい。むしろ「この関数」「この定数」「この if ブロック」のように、意味を知りたい単位
papoo.work
コンフリクトの解消を手伝ってもらうときの渡し方
コンフリクトの解消を手伝ってもらうときの渡し方
コンフリクトを見つけた瞬間に、雑に「直しといて」と投げるとだいたい余計にこじれる。Claude Code もそこは人間と同じで、何を残すべきか、どこまで触っていいかが曖昧だと、無難そうな修正を広げてしまう。結果、差分が太る。あとで自分が読むと、何を直したのか分からない。これが一番だるい。 この手の場面で大事なのは、解決作業そのものより、渡し方だ。コンフリクトの前後関係、残したい意図、触ってよい範囲を小さくまとめて渡すだけで、手戻りがかなり減る。開発でも文書整理でも同じで、片方だけ見せて丸投げするのが一番危ない。 まず押さえるべきなのは、Claude Code に見せる情報を「衝突したファイルそのもの」だけに絞らないことだ。コンフリクトは、たいてい前後の変更履歴や目的が分からないと解けない。たとえば設定ファイルなら、「新しい値にしたい」のか「既存の値を残したい」のかで答えが変わる。文書なら、片方の修正が表現の整理で、もう片方が事実の追加かもしれない。そこを切り分けずに渡すと、見た目は直っても意図が死ぬ。 実際の渡し方は、こういう形が使いやすい。 ```text このコンフリクトを解消して
papoo.work
プルリクエストの説明文を Claude Code に下書きさせる
プルリクエストの説明文を Claude Code に下書きさせる
プルリクの説明文を、毎回ゼロからひねり出しているなら、その時間はかなりもったいない。差分は読めるのに、説明だけが薄っぺらい。あれはだいたい、頭の中にある変更点をそのまま文章化していないのが原因だ。 Claude Code はここでかなり使える。コードの差分、変更したファイル、作業メモを拾わせて、PR のたたき台を一気に作らせればいい。自分で書くのは最後の調整だけになる。説明文の骨組みが先に出るので、抜け漏れも減る。 ただし、雑に「PR説明文を作って」で投げると、ふわっとした要約が返ってきて終わる。これがいちばんつまらない。人間が欲しいのは、読む相手がそのまま判断に使える文章だ。なので、最初から「何を見て、どの形式で、何を入れて、何を省くか」まで指定する。 まずは、作業中の変更があるリポジトリを開いた状態で、Claude Code にこう頼めばいい。 ```text 変更内容をもとに、プルリクエストの説明文を日本語で下書きしてください。 次の構成で出してください。 変更の要約 背景と目的 主な変更点 動作確認 レビュー時に見てほしい点 補足 重要: 変更差分を読んだうえで書くこと 推測で
papoo.work
安全にリファクタする：テストを足してから直す段取り
安全にリファクタする：テストを足してから直す段取り
テストもないのに手を入れて、あとで「何が壊れたか分からない」と泣く。これ、かなりありがちな事故だ。Claude Code を使うときも同じで、いきなり大工事を頼むより、先に“壊してはいけない形”をテストで囲ってから直したほうが圧倒的に安全になる。 ここで言うのは、大規模な自動テスト体制の話ではない。まずは、今ある挙動を固定するための最小限のテストを足す。それからリファクタする。Claude Code は差分を追いながら作業できるので、この段取りと相性がいい。指示の出し方さえ間違えなければ、雑に直して戻し作業を増やすより、ずっとましだ。 筆者も最初は「どうせ小さい変更だし」と思って直し始めて、関連ファイルまで連鎖的に触ってしまい、どこで壊したか探す羽目になった。特に Claude Code に曖昧な依頼をすると、要点を広く拾おうとして diff が膨らむ。だから順番が大事だ。先にテスト、次に修正。これで迷子になりにくい。 まず押さえるべきなのは、リファクタの前に「守るべき振る舞い」を1つでもいいから言葉にすることだ。関数の入力と出力、ファイルの生成結果、表示文言、削除してよい条件。何を固
papoo.work
変更内容をレビューしてもらう：自分の差分にツッコミを入れさせる
変更内容をレビューしてもらう：自分の差分にツッコミを入れさせる
差分をそのまま見せて「レビューして」と投げるだけでは甘い。だいたい見落とされる。Claude Code にやらせたいのは、単なる読み上げではなく、変更の穴を突かせることだ。 この使い方が効くのは、コード修正だけではない。設定ファイルの整理、文章の推敲、不要ファイル削除の前後確認、README の手直しみたいな作業でも同じだ。自分では「まあこんなもんか」で流しがちな差分に、第三者の目を入れる。しかも人間に頼む前に、まず機械に荒く突っ込ませる。これだけで手戻りが減る。 最初にやることは単純だ。変更したファイルを見せて、目的と合わせてレビューさせる。雑に「見て」では弱い。何を重点的に見てほしいかを言う。 ```bash claude ``` ```text この差分をレビューしてほしい。 目的は「検索しやすいようにファイル名を整理すること」だ。 次の観点で厳しめに見てください。 変更の意図と結果がずれていないか 例外ケースを壊していないか 命名が一貫しているか 余計な変更が混じっていないか もっと安全で単純なやり方があるか 指摘は重要度順に並べてください。 「問題なし」で終わらせず、気になる
papoo.work
Claude Code にコミットメッセージを書かせる：粒度と作法を揃える
Claude Code にコミットメッセージを書かせる：粒度と作法を揃える
コミットメッセージを「それっぽく一行で」済ませると、あとで自分が困る。Claude Code に任せるなら、そこを雑にしないほうがいい。粒度がバラついたメッセージは、履歴を読めなくするだけでなく、変更の単位まで崩す。逆に、作法を先に揃えておくと、コミットはただの作業ログではなく、あとから効くメモになる。 Claude Code は、雑に「コミットメッセージ書いて」と頼んでも一応それなりに出す。だが、その「それなり」は危ない。人間の頭の中にある意図が曖昧なままだと、AI は平気で広くまとめすぎるし、逆に細かすぎる差分を無理に1本へ寄せることもある。筆者は最初、ここを軽く見ていた。結果、1コミットに「UI の文言修正」と「不要ファイル削除」と「README 更新」が混ざり、あとで戻すときにかなり面倒だった。履歴が説明になっていない。あれは地味に痛い。 やるべきことは単純だ。Claude Code に「何を、どの粒度で、どういう型で」書かせるかを先に決める。 たとえば、こんな方針にする。 1コミット1目的に寄せる 変更の要約は命令形か現在形でそろえる 本文が必要なときだけ理由を書く 変更の範
papoo.work
「説明して」と「直して」を混ぜない：依頼の粒度を揃える
「説明して」と「直して」を混ぜない：依頼の粒度を揃える
「これ、何をしてほしいのか曖昧なまま投げているな」と思ったら、だいたい当たっている。Claude Code への依頼で一番もったいないのは、説明と修正を一度に混ぜることだ。読み解きと編集は別作業で、同じ呼びかけに押し込むと、返ってくる結果が中途半端になる。 たとえば「この Python スクリプトの処理を説明して、ついでに変数名も直して」と一息で頼むと、Claude Code は説明も修正もやろうとする。すると、説明は浅くなるか、修正は小さくなる。コンテキストも食うし、diff も散る。筆者は以前、文章校正を頼みながら「意図の説明も」と混ぜてしまい、返ってきた修正を見てから改めて説明を求める羽目になった。最初から分けていれば、やり取りは半分で済んだはずだ。 コツは単純で、依頼の粒度を揃えることだ。 「説明して」は理解の仕事、「直して」は変更の仕事。どちらか一方に寄せると、Claude Code の出力はかなり安定する。 たとえばコードを見せる場面なら、まずはこう分ける。 ```text このスクリプトの処理の流れだけ説明して。 変更はしないで、箇条書きで要点を整理して。 ``` そのあ
papoo.work
例を 1 つ見せる：少ない指示で意図を伝える few-shot 的な頼み方
例を 1 つ見せる：少ない指示で意図を伝える few-shot 的な頼み方
「ちゃんと考えて」とだけ投げて、思った通りになるはずがない。Claude Code も同じで、雑な依頼は雑な結果を呼ぶ。ここで効くのが、長々と説明するより、たった 1 つの例を見せるやり方だ。 few-shot という呼び方をすることもあるが、要するに「こういう出力がほしい」と例示してから頼む方法である。Claude Code ではこれがかなり強い。特に、ファイル整理、文書作成、リネーム、要約、コメント整形みたいに、正解の形がある程度わかっている作業で効く。逆に、言葉だけで曖昧に指示すると、こちらが想像していた粒度とズレやすい。筆者も最初はここで何度か手戻りした。説明を盛るほど伝わる気がして、結局はコンテキストを食うだけだった。 たとえば、README を整えたい。いきなり「読みやすくして」では弱い。こう頼む。 ```text この README を、次の例のようなトーンと構成に寄せて整えてください。 例: 冒頭で何をするプロジェクトかを 2 行で説明する 見出しは短くする 手順は 1, 2, 3 の順で並べる 冗長な言い回しは消す コマンドはコードブロックのまま残す 対象ファ
papoo.work
長い作業を ToDo に分解させてから進めてもらう
長い作業を ToDo に分解させてから進めてもらう
長い仕事をそのまま投げると、Claude Code はだいたい雑に走る。で、あとから「それ先に必要だったのはこっちだった」と気づいて手戻りする。ここを避けるなら、最初にやることは単純だ。いきなり本作業に入らせず、先にToDoへ割らせるのである。 この一手で、作業の抜け、順番違い、コンテキストの無駄遣いがかなり減る。ファイル整理でも、ディスク掃除でも、文書作成でも効く。長い依頼ほど効き目が大きい。 たとえば「このフォルダ内の重複を洗って、不要なものを消して、最後に要約して」と一気に頼むと、途中で判断がぶれる。何を先に確認するか、どのファイルを触るか、削除の前に何を残すかが曖昧なまま進むからだ。 こういうときは、まずClaude Codeに「作業手順をToDoとして出せ」と命じる。そこで出てきた項目を見て、人間が順序と危険箇所を潰してから進ませる。 実際の頼み方はこうだ。 ```bash この作業を、まず実行用のToDoに分解してください。 まだ変更は加えず、次の形式で出してください。 1. 調査 2. 判定 3. 実行 4. 確認 各項目には、何を確認するか、どのファイルやディレ
papoo.work
やってほしくないことを明示する：禁止事項の伝え方
やってほしくないことを明示する：禁止事項の伝え方
「やってほしいこと」だけ書いて、やってほしくないことを放置する。これ、Claude Code への依頼でかなり危ない。余計な編集、勝手な要約、触ってほしくないファイルの改変まで一気に起きる。禁止事項は、気を使ってぼかすより、先に切っておいたほうが早い。 Claude Code は、雑に言えば「範囲が広いほど働きすぎる」タイプだ。だからこそ、禁止事項の伝え方が効く。 たとえばファイル整理なら、「古いものを片付けて」と言うだけでは、思い切りよく削除されて困ることがある。文書作成なら、「読みやすくして」と頼んだだけで、表現をいじられすぎて意図がずれる。開発なら、関連しない設定ファイルまで手を入れて差分が肥大化する。筆者も最初はこの手の依頼で何度か戻した。うまくいくときより、余計なことをして手戻りが出るときのほうが面倒だ。 コツは単純で、「何をしてほしいか」と同じ熱量で「何をしてほしくないか」を書くことだ。しかも、あいまいにではなく、対象を切って書く。 たとえば、こう書く。 ```text このフォルダ内の文書を整理してほしい。 ただし、次は触らないでほしい。 元の本文の意味を変える書き換え
papoo.work
既存コードの作法に合わせさせる：スタイルを真似させる頼み方
既存コードの作法に合わせさせる：スタイルを真似させる頼み方
新しいコードをいじらせる前に、まず既存コードの空気を読ませろ。ここを雑にやると、動くけど場違いな差分が増える。名前の付け方も、関数の切り方も、コメントの濃さも、ぜんぶちぐはぐになる。Claude Code でも同じで、「このリポジトリの作法に合わせて」と丸投げするより、見本を渡して真似させたほうがずっと安定する。 Claude Code は、渡した文脈の中でかなり素直に動く。だからこそ、既存コードの一部を「これと同じ調子で」と見せるのが効く。要するに、スタイルを抽象論で説明するのではなく、実例を食わせるやり方だ。ファイル整理や文書作成でも同じで、「このフォルダの命名規則に合わせて」「この報告書の文体に寄せて」と言い換えれば使える。 いちばん簡単なのは、対象のコードと、その周辺の見本を一緒に渡すことだ。たとえば新しい関数を追加したいなら、既にある似た関数を指定して、その流れを踏襲するよう頼む。 ```text このリポジトリでは、既存の `src/users/*` の書き方に合わせてください。 特に次のファイルのスタイルを真似してください。 `src/users/create-user.
papoo.work
「まず調べて、次に直して」と段階で頼むと精度が上がる理由
「まず調べて、次に直して」と段階で頼むと精度が上がる理由
雑に「これ直して」で投げると、Claude Code はだいたい手広く動きすぎる。調べるべきことと、直すべきことが頭の中で混ざるからだ。 先に調べさせ、あとで直させる。この順番に分けるだけで、無駄な修正、見当違いの変更、差分の膨張がかなり減る。ファイル整理でも文書作成でも同じで、いきなり“完成形”を頼むより、まず現状を見せたほうが話が早い。 実際、筆者も最初は「このフォルダを整理して」「この文章を直して」と丸投げして、あとで手戻りした。Claude Code は賢いが、前提が曖昧だと遠慮なく広く動く。削除していいものまで候補に入れるし、文書なら表現だけでなく構成までいじってくる。悪気はない。だからこそ、段階を切る。 やり方は単純だ。最初の依頼では、変更禁止で調査だけさせる。次の依頼で、調査結果を前提に修正を指示する。 たとえばコードなら、こういう頼み方にする。 ```text まず調べてください。変更はしないで、次を出してください。 何が原因候補か どのファイルを触る可能性があるか 修正方針を2〜3案 それぞれのリスク まだ編集しないで、調査結果だけ返してください。 ``` この一段目
papoo.work
ゴールと制約を先に伝える：手戻りを減らす依頼テンプレ
ゴールと制約を先に伝える：手戻りを減らす依頼テンプレ
「とりあえず直して」でうまくいくと思っていると、だいたい手戻りする。Claude Code は空気を読んで全部やってくれる便利屋ではない。何を終点にしたいのか、何を触ってよくて何を触るな、ここを先に渡したほうが速い。 特に Claude Code は、こちらの依頼文そのものを仕事の設計図として読む。だから、ゴールがぼんやりしていると、出力もぼんやりする。逆に、先に制約を渡すだけで、不要な調査や修正、でかい diff をかなり減らせる。ファイル整理でも文書作成でも同じだ。何を残し、何を捨て、どこまでやれば終わりかを先に言っておくのが効く。 筆者も最初は「このフォルダを見て適当に整えて」で頼んで、見事に遠回りした。見た目は整ったが、欲しかったのは重複ファイルの退避であって、構成変更ではなかった。指示が曖昧だと、エージェントは丁寧に暴れる。そこを抑えるのがこの TIPS だ。 まずは、依頼文の骨格を固定してしまうのが早い。Claude Code には、最初にこう投げる。 ```text 目的: 何を完成形とするかを先に決める 変更は最小限にする 既存の命名や構成は極力維持する 制約: 触って
papoo.work
曖昧な依頼をやめる：Claude Code に「何を・どこまで」を渡すコツ
曖昧な依頼をやめる：Claude Code に「何を・どこまで」を渡すコツ
「いい感じにやって」で済むと思っていると、だいたい遠回りになる。Claude Code も例外ではない。 雑に投げると、広く見に行きすぎる。触ってほしい範囲がぼやけるから、無駄にファイルを読み、無駄に大きな差分を作り、あとで「そこじゃない」を直す羽目になる。筆者も最初はこれで何度か手戻りした。頼み方が曖昧だと、エージェントは親切に広く動く。親切さが、そのままコンテキストの浪費になるわけだ。 Claude Code に渡すべきなのは、ふわっとした願望ではない。「何を」「どこまで」「何は触らないか」だ。これを先に切るだけで、作業の速さが変わる。コード修正だけの話ではない。ファイル整理、重複削除の候補出し、文章の整形、案件フォルダの整理でも同じだ。 たとえば、こういう投げ方は弱い。 ```text このプロジェクトを見て、使いやすくして。 ``` これでは広すぎる。何を直すのか分からない。UIなのか、READMEなのか、不要ファイルの削除なのか、テスト追加なのか、全部あり得る。Claude Code は勝手に範囲を解釈するが、その解釈があなたの頭の中と一致する保証はない。 代わりに、最初の一
papoo.work
ターミナルが苦手でも使える：Claude Code の最小限の操作だけ覚える
ターミナルが苦手でも使える：Claude Code の最小限の操作だけ覚える
Claude Code は、ターミナルの玄人向けツールに見えて、実際は「最小限だけ覚えて雑に使う」ほうが向いている。ここを勘違いして、最初から bash を全部理解しようとして止まる人が多い。そんな気合はいらない。必要なのは、起動する、依頼を書く、承認する、終わる。この4つだけだ。 しかもこれは開発者だけの話ではない。フォルダの中身を整理したい、散らかった文書を直したい、同じ内容のファイルをまとめたい、ディスクを空けたい、そういう用途でもかなり使える。大事なのは「Claude Code に何をしてほしいか」を、短く具体的に伝えることだ。ターミナル操作そのものは、ほぼ付け足しでいい。 まず、最低限の入り口だけ押さえる。インストール方法は公式案内に従うのが安全だが、使い方の芯は単純だ。作業したいフォルダに移動して、Claude Code を起動する。だいたいの流れはこうなる。 ```bash cd /path/to/your/project claude ``` ここで `claude` を実行すると、対話モードに入る。あとは普通の会話と同じように、やってほしいことを書けばいい。たとえば文
papoo.work
Claude Code が間違えたときの戻し方：作業を捨ててやり直す
Claude Code が間違えたときの戻し方：作業を捨ててやり直す
やりがちなのは、Claude Code が変な方向に進んだのに、そのまま修正させ続けることだ。これ、たいてい泥沼になる。少し直したつもりが別のファイルまで触られ、diff が膨らみ、どこから壊れたのか分からなくなる。そんなときは、粘るより一度捨てたほうが早い。 Claude Code は CLI の作業エージェントなので、手元のファイルを実際に書き換える。つまり、間違えたときに大事なのは「どう直すか」より「どこまでを無かったことにするか」だ。ここを間違えると、コンテキストも時間も無駄に食う。筆者も最初は、ズレた指示のまま会話を続けて手戻りした。結局、途中成果を捨ててやり直したほうが速かった、という場面がかなり多い。 いちばん手堅いのは、まず差分を確認して、必要なら作業ツリーをそのまま戻すことだ。Git を使っているなら話は早い。Claude Code に触らせる前にコミットしておけば、戻す先がはっきりする。これだけで事故率がかなり下がる。 ```bash git status git diff git restore . ``` `git restore .` は、未コミットの
papoo.work
差分を小さく保つ：大きな変更を安全に進めるための区切り方
差分を小さく保つ：大きな変更を安全に進めるための区切り方
一気に全部やろうとすると、だいたい雑になる。Claude Code でも同じで、でかい変更をひと塊で投げると、途中で文脈があふれて、直したい箇所まで巻き込んで壊しやすい。差分を小さく保つコツは、気合いではなく区切り方だ。 Claude Code は、ローカルのファイルを読んで、変更案を返して、そのまま編集まで進められる。だからこそ、最初の依頼文で「何を1回分の仕事にするか」をはっきり切るだけで、手戻りがかなり減る。開発でも文書整理でもファイル整理でも効く。むしろ非エンジニアほど、この区切りが効く。 たとえば、フォルダ整理で「重複っぽい書類を見つけて、年別に分けて、ファイル名も整えて、不要キャッシュも消して」と全部まとめて頼むと、途中で迷う。先にやるべきなのは、検出だけなのか、移動までなのか、削除までなのかを分けることだ。Claude Code に任せる単位を小さくすると、確認もしやすいし、戻すのも楽になる。 まずは、頼み方を「調べる」「提案する」「実行する」に分ける。これだけで事故率が下がる。 ```bash Claude Code に以下を依頼する: 「このフォルダ内で重複していそう
papoo.work
プランモードで「やる前に方針を確認」する使い方
プランモードで「やる前に方針を確認」する使い方
勢いで走らせると、だいたいあとで直す羽目になる。Claude Code でもそこは同じで、いきなり実行させるより、先に方針だけ確認させたほうがずっと事故が少ない。 プランモードは、作業を始める前に「何をどう進めるつもりか」を先に出させる使い方だ。コード修正でも、フォルダ整理でも、文章のたたき台作りでも効く。しかも、単に相談するだけではなく、こちらが許可した筋道で進ませやすい。やる前に地図を見せる、という感覚に近い。 筆者は最初、普通に「これ直して」「これ整理して」とだけ投げていた。すると、意図は合っていても手順が遠回りだったり、無関係なファイルまで触りそうになったりする。小さな修正ならまだいいが、ディレクトリ全体をまたぐ整理や、文章ファイルの一括整形になると、確認なしで走らせるのはけっこう怖い。そこで先に方針を出させると、手戻りが目に見えて減る。 Claude Code でこれをやるコツは、最初の依頼で「実行」ではなく「計画」を求めることだ。たとえば次のように頼む。 ```text この作業を始める前に、方針だけ先に出してください。 目的、変更対象、進める順番、危ない点、確認したい点を
papoo.work
Claude Code の権限モードを理解する：自動承認はどこまで許すか
Claude Code の権限モードを理解する：自動承認はどこまで許すか
「自動承認にしておけば全部ラク」みたいな雑な使い方をすると、だいたいどこかで痛い目を見る。Claude Code は便利だが、便利さの芯にあるのは“どこまで勝手にやってよいか”の線引きだ。ここを曖昧にしたまま走らせると、ファイルを思った以上に触られたり、確認待ちで手が止まったりする。 権限モードを理解する意味は単純で、Claude Code に任せる作業と、人間が止める作業を分けることにある。ファイル整理でも、文章作成でも、コード修正でも同じだ。雑に広く許すより、最初に少しだけ考えておいたほうが、後でやり直しが減る。 まず押さえるべきなのは、Claude Code は「提案だけする」道具ではない、という点だ。ターミナル上で実際にコマンドを走らせ、ファイルを読むだけでなく、書き換えもする。だから権限モードは、AI の賢さとは別に、実行の自由度を調整するための装置だと思っておけばいい。 ざっくり言うと、考え方はこうなる。 何も考えずに広く許可する 危ない操作だけ確認を挟む ほぼ毎回止めて、人間が承認する この三段階をどう使い分けるかが本題だ。Claude Code には、自動承認の強さを変
papoo.work
ファイルを丸ごと貼らずに済ませる：Claude Code に探させる頼み方
ファイルを丸ごと貼らずに済ませる：Claude Code に探させる頼み方
「このファイル全部読んで」。その頼み方、だいたい雑だ。Claude Code に丸ごと貼る前に、まず探させればいい。これだけでコンテキストの無駄食いが減るし、長い設定ファイルや複数の文書を相手にするときの手戻りもかなり減る。 Claude Code は、ただ貼られた文章を読むだけの道具ではない。リポジトリや作業ディレクトリの中を見て、該当箇所を探して、必要な部分だけを扱うほうがずっと向いている。特に、設定ファイル、議事録、契約書の下書き、案件フォルダのように「どこに何があるか分かっていないが、探せば見つかる」場面で効く。 最初にやるべきは、いきなり本文を貼ることではなく、「探す条件」を先に渡すことだ。たとえばこう書く。 ```text このリポジトリの中から、APIキーの設定に関係する箇所を探して。 ファイル名、該当行、周辺の文脈を短く抜き出して、何を直せばよいか説明して。 全文の貼り付けは不要。見つかった部分だけで十分。 ``` これで十分なことが多い。要するに、Claude Code に「答えそのもの」ではなく「答えを見つける作業」をやらせるわけだ。人間でも、まず検索して、見つかっ
papoo.work
Claude Code のセッションを上手に区切る：いつ /clear すべきか
Claude Code のセッションを上手に区切る：いつ /clear すべきか
長く雑に話し続けるほど賢くなる、なんて思っていると痛い目を見る。Claude Code は会話の文脈をちゃんと使うが、使い続ければ使い続けるほど、今やっている作業に不要な前提まで抱え込む。これがコンテキスト管理の話だ。 `/clear` は「会話を捨てるためのボタン」ではない。作業の単位を切り替えるための道具である。ここを外すと、指示はだんだん鈍るし、差分はでかくなるし、直したい場所と違う場所を触り始める。筆者は最初、便利だからと同じセッションを延々引っ張って、最後には「その話、もう前の前提だよね」とこちらが補足し直す羽目になった。あれはだるい。 `/clear` を入れるべきタイミングは、だいたい次の三つだ。 ひとつ目は、話題が変わったとき。たとえば「このディレクトリを整理してほしい」の次に「別の案件の資料を要約してほしい」を続けるなら、同じ会話に載せないほうがいい。 ふたつ目は、ひとつの作業が終わったとき。実装、修正、整理、要約。完了したら一度切る。 みっつ目は、返答が妙に回りくどくなったときだ。前の指示や途中経過を引きずって、同じ説明を繰り返し始めたら、会話が長すぎるサインである
papoo.work
プロジェクトを開いて最初にやるべき3つの設定
プロジェクトを開いて最初にやるべき3つの設定
最初に何も決めずに Claude Code を走らせると、だいたい雑に広がる。コンテキストは無駄に食うし、差分はでかくなるし、あとで「それじゃない」を言い直す羽目になる。あれは地味にだるい。 プロジェクトを開いたら、まずやるべき設定は3つだけだ。 「作業範囲を固定する」「出力の粒度を揃える」「触ってほしくないものを先に塞ぐ」。この3つを最初に入れておくと、Claude Code が勝手に遠回りしにくくなる。非エンジニアでも同じで、たとえば書類整理やフォルダ整備を頼むときほど効く。何を見て、何を見ないかが曖昧だと、ツールはすぐ迷子になる。 Claude Code は、プロジェクト内の指示を置いておくとそれを読みやすい。ここでやるべきなのは、毎回口頭で説明していた前提を `CLAUDE.md` に逃がすことだ。 コードベースなら「どのディレクトリを主に触るか」「テストの走らせ方」「命名の癖」。文書作成なら「書式」「表記ゆれの方針」「触ってはいけない原本」。この手の話は、毎回チャットで打つには細かすぎるし、打ち忘れやすい。 たとえば、こんな感じで置く。 ```md 変更は最小限にする 既存の
papoo.work
Claude Code に何を頼めるか：得意なこと・苦手なことの線引き
Claude Code に何を頼めるか：得意なこと・苦手なことの線引き
Claude Code に何でも押しつけると、だいたい最後にしわ寄せが来る。雑に投げると、長い説明を読ませたわりに成果物が中途半端、しかも人間が後で直す羽目になる。そこを先に切り分けておくと、Claude Code はかなり使える道具になる。 Claude Code は、Anthropic の CLI コーディングエージェントだが、ここでの本質は「端末から指示して、作業をまとめて任せる相手」だという点にある。コードを書かせるだけの道具ではない。ファイルを探す、差分をまとめる、文書を整える、不要なものを洗い出す、そんな地味だが面倒な仕事に向いている。 逆に、曖昧な判断、最後の責任が重い決定、見通しの甘い大工事は苦手だ。ここを間違えると、コンテキストを無駄食いし、diff が膨らみ、手戻りが増える。筆者も最初は「全部まとめてやって」と投げて、あとで細部を直すほうが面倒になる失敗を何度かやった。便利だが、万能ではない。 Claude Code が強いのは、手元のファイルや既存の文脈を読みながら、具体的な作業に落とす場面だ。人間が「どこにあるのか」「何を直せばいいのか」を探す時間を削れる。 た
papoo.work
Claude Code を最初に動かすまで：インストールから初回の依頼まで
Claude Code を最初に動かすまで：インストールから初回の依頼まで
「入れたのに何を頼めばいいか分からない」で止まる人が多い。そこが一番もったいない。Claude Code は、起動した瞬間から小さく使い始めるのが正解だ。最初の一回で大仕事をさせる必要はない。むしろ、ファイルの中身を読ませて、整理や要約、簡単な修正を一つ通すところから始めると、使い方の勘所が一気につかめる。 Claude Code 入門としても、Claude Code 使い方の最初の一歩としても、まずは「インストールして、起動して、短い依頼を出す」までを通す。ここで詰まる人は、だいたい準備を広げすぎる。Node.js の確認、認証、作業フォルダの選び方、この3つだけ押さえれば十分だ。 まず前提をそろえる。Claude Code は Anthropic の CLI コーディングエージェントで、ターミナルから動かす。なので、普段 GUI しか触らない人でも、最初だけはコマンドを打つ必要がある。Node.js が入っていない環境では動かないので、そこだけは先に済ませる。インストール方法は環境で少し変わるが、基本は Node.js を入れて、Claude Code を公式手順どおりに入れる流れ
papoo.work
Sonnetがついに「Opusでいいじゃん」って言われ始めた件、実際どうなのか集めてみた
Sonnetがついに「Opusでいいじゃん」って言われ始めた件、実際どうなのか集めてみた
2026年6月末にSonnet 5が出て以来、あちこちで「もうOpusいらないんじゃないか」という声を見るようになった。正直、この手の「新型は前世代を食う」論は毎回出てくるので話半分に聞いてたんだけど、今回は言ってる人の顔ぶれが違う。エンタープライズの導入事例から個人ブロガーの生々しい愚痴まで、実際にClaude Codeで両方回した人たちの声を拾ってみたら、思ったより解像度の高い話が出てきたので整理する。 まず数字。SWE-bench Proのエージェント型コーディングでSonnet 5は63.2%、Opus 4.8は69.2%。これだけ見ると6ポイント差はまだ結構ある。一方でHumanity's Last Examにツールを持たせた条件だとSonnet 5が57.4%、Opus 4.8が57.9%とほぼ同着。知識労働系のGDPval-AA v2に至ってはSonnet 5の1,618に対してOpus 4.8が1,615で、数字上はSonnet が上回っている場面すらある。 つまり「全部の指標で肉薄した」んじゃなくて、タスクの種類によって差の出方がバラバラというのが実態に近い。
papoo.work
で、CLAUDE.mdで英語で書かせるのと日本語で書かせるの、どっちが良いの？
で、CLAUDE.mdで英語で書かせるのと日本語で書かせるの、どっちが良いの？
結論から言うと、どっちでもいい。日本語で書いて全然問題ない。 ネットで「CLAUDE.mdは英語が正義」みたいなの見るけど、あれ半分は雰囲気で言ってるだけだと思う。Claude は普通に日本語の指示を読むし、ちゃんと従う。「英語じゃないと精度ガタ落ち」みたいなことは起きない。 ただ「どっちでもいい」で終わると記事にならないので、ぶっちゃけどこで差が出るのか、正直なところを書く。 CLAUDE.md っていうのはプロジェクト直下に置いとくと Claude Code が自動で読んでくれる指示書ファイル。「このリポジトリではこうしてね」を書いとくやつ。 ここに日本語で「テストは npm test で回して」「コミットメッセージは日本語で」とか書いても、ちゃんと効く。Claude は多言語モデルだから、指示の言語が日本語か英語かで「言うこと聞かなくなる」みたいなことはまず無い。だから読めるか読めないかで悩む必要はゼロ。ここを勘違いして「英語じゃなきゃダメなんだ…」って無理して英語で書くのは、正直いちばんもったいない。 差が出るとしたら、だいたいこの3つ。全部「精度」じゃなくて「
papoo.work
Claude Codeで「ループ」を作ると何が変わるのか
Claude Codeで「ループ」を作ると何が変わるのか
Claude Code を使うとき、つい「いいプロンプトを書けば何とかなる」と考えがちです。私もその感覚はよくわかります。1回きりの質問なら、それで十分なことも多い。でも、同じような作業を何度も回す、途中の結果を確認する、前回の状態を覚えておく、となると話は変わります。そこで必要になるのが、単発の指示ではなく「loop」という考え方です。 元記事は、Youssef Hosni氏が Medium の Level Up Coding に書いたもので、Claude Code を使った agentic automation、つまり「AI にある程度の自律性を持たせて作業を進める仕組み」をどう設計するかを扱っています。面白いのは、AI をいきなり全自動にするのではなく、まずは安全で नियंत्र可な形で回し、少しずつ賢くしていく発想にあると思います。 この記事の主題は、Claude Code を「1回答えるAI」ではなく「繰り返し動く仕組み」として使うこと loop は、実行のきっかけ、読むべき文脈、できること、検証方法、状態の保存場所、停止条件まで含めて設計する 最初は `TASK.md`、
papoo.work
Claude Code, “Vibe Coding,” and Why the Phrase Is Starting to Grate
Claude Code, “Vibe Coding,” and Why the Phrase Is Starting to Grate
From a Claude / Claude Code developer’s perspective, this story is interesting less because of any one product update and more because it highlights a real tension in the current AI-dev conversation: the language around coding assistants is getting noisy. Even the people building these tools can get tired of the slogans that spring up around them, especially when those slogans start to flatten the actual work. The source is a Reddit post titled “Please wait for verification.” The referenced disc
papoo.work
Claude Codeの新機能「dynamic workflows」とは？ たくさんのAIを並列で走らせて、難題を一気にさばく仕組み
Claude Codeの新機能「dynamic workflows」とは？ たくさんのAIを並列で走らせて、難題を一気にさばく仕組み
ClaudeがClaude Codeに dynamic workflows という新機能を追加しました。ざっくり言うと、1つのAIが順番に考えるのではなく、たくさんの“子エージェント”を同時に動かして、最後に結果をまとめる仕組みです。 これ、かなり面白いです。AIエージェントの話は最近よく聞きますが、ここまで「並列処理」と「検証」を前面に出しているのは印象的だと思います。単に“速い”というより、大きくて面倒な仕事を、壊れにくい形で進める方向に踏み込んでいるのがポイントです。 Claude Codeに dynamic workflows が追加された 1つのAIではなく、10〜100規模の並列 subagents を使って作業する 結果をチェックしてからユーザーに返すため、精度重視の作業に向く バグ調査、セキュリティ監査、大規模移行、長いレビュー作業などで強い research preview として提供され、Max / Team / Enterprise などで利用可能 **通常のClaude Codeより多くのtokensを消費
papoo.work
Claude Code’s Dynamic Workflows Aim to Make Multi-Agent Coding Practical
Claude Code’s Dynamic Workflows Aim to Make Multi-Agent Coding Practical
Claude’s new dynamic workflows feel like Anthropic trying to push Claude Code from “helpful coding assistant” into “orchestrator for serious engineering work.” For developers, the interesting part isn’t the marketing language about speed — it’s the claim that Claude can now plan, fan out, verify, and keep state across large jobs instead of choking on them in a single pass. Anthropic has introduced dynamic workflows in Claude Code as a research preview. The feature is meant for **hard
papoo.work
Undocumented Claude Code Config: What the Source Reveals
Undocumented Claude Code Config: What the Source Reveals
For Claude Code users and builders, this is the kind of article that makes you realize the product is a lot more programmable than the official docs suggest. André Figueira’s read-through of the source code surfaces a pile of hidden hooks, frontmatter fields, and agent settings that can change how Claude behaves at runtime, sometimes in surprisingly powerful ways. Claude Code’s hook system can do more than the docs admit: hooks can return JSON that rewrites inputs, alters permission decisions, i
papoo.work
Claude Code Routines Put the Agent on Autopilot
Claude Code Routines Put the Agent on Autopilot
Claude Code routines are an interesting step toward making Claude feel less like an interactive assistant and more like an always-on workflow engine. For developers, the big shift is that Claude can now react to schedules, API calls, and GitHub events from Anthropic-managed cloud infrastructure, so the laptop no longer has to be open for the work to happen. Routines are a research preview feature, so behavior, limits, and the API surface may change. A routine is a saved Claude Code configuration
papoo.work