「〜のはず」は外れる。Claude Code と作業して、推測が外れて実測で分かったこと8件
このブログでは、Claude Code と一緒に作業して分かったことを書いています。書き終えたものを並べてみると、共通点がありました。最初に「〜のはず」と思っていたことが、数えたり測ったりすると外れていた 話が、とても多いのです。
外れた推測を8件集めました。外れ方は3種類に分けられます。
- 自分の推測：確かめずに思い込んでいた
- 確かめたつもり：確かめたが、確かめ方が足りなかった
- AI の推測：Claude が、見えていないところを推測で埋めた
自分の推測が外れた
1. 「npm 版だから更新が遅いはず」
新しいモデルがすぐ使えないのは、npm で入れた Claude Code のせいだと思っていました。ネイティブ版に移行してから公式ドキュメントを読むと、npm 版も中身は同じ実行ファイルで、自動更新もありました。
claude doctor を打つと、答えが1行で出ました。
Auto-updates: disabled (set by env: CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC)テレメトリを止めるつもりで入れた環境変数が、自動更新まで止めていました。（記事）
2. 「auto mode によく止められている」
auto mode を使っていて、「また止められた」という印象がありました。会話ログを1か月分数えると、ツール呼び出し22,526回のうち、止められたのは64回。約0.3%、350回に1回でした。
止められると作業が中断するので、記憶に残りやすかっただけでした。しかも、止められたものの大半は、本番デプロイのように自分で確認したい操作でした。（記事）
3. 「Networking は ¥0 だから、通信料はかかっていないはず」
GCP の請求をサービス別に見ると、Networking は0円でした。ところが、VM から外に出る通信は Compute Engine の項目として請求されていました。SKU 単位で内訳を見ると、外向きの通信の約4割は、圧縮されていない404応答でした。（記事）
4. 「statusLine が表示されないのは、スクリプトのロジックが悪いはず」
Claude Code の statusLine が空白になる原因を、最初はスクリプトの中身に探していました。実行時間を測ると、PowerShell 版は 1411ms。更新の間隔より長く、終わる前に次の更新でキャンセルされていました。ロジックはそのままで Node.js に移すと 143ms になり、表示されるようになりました。（記事）
確かめたつもりだった
5. 「既存の CUD は確認済み」
GCP の確約利用割引（CUD）を買う前に、既存の契約がないかを gcloud compute commitments list で確認しました。0件だったので契約したところ、請求アカウント単位の Flexible CUD がすでにあり、二重契約になりました。このコマンドは、プロジェクトに紐づく CUD しか表示しないものでした。（記事）
確かめた方法が、確かめたいものを見られる方法だったか まで確認しないと、「確認した」は当てになりません。
6. 「この環境変数を消せば、機能フラグも戻るはず」
これは、公開した記事の中で私自身が書いた誤りです。CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC を消せば、機能フラグの取得も戻ると書いていました。ドキュメントを読み直すと、残していた DISABLE_TELEMETRY でも機能フラグの取得は止まると書かれていて、2本の記事を訂正しました。
一つの変数について調べて、残した変数のほうは確かめていませんでした。
AI の推測が外れた
7. サブエージェントが、自分に起きたことを間違って説明した
サブエージェントの結果の届き方を実験していたとき、真ん中のサブエージェントが「途中の1行が最終報告として送られてしまった」と報告してきました。ログを見ると、最終報告は全文で正しく届いていました。二度目の送信を断られた理由を、サブエージェントが推測で埋めていたのです。（記事）
AI は、自分から見えないことを、もっともらしい説明で埋めます。結果の値だけでなく、経緯の説明もログで確かめる必要があります。
8. 「スキーマ違反で諦めたら、出力が欠けるだけ」
claude -p --json-schema の挙動について、以前のメモには「AI が諦めると出力が無いまま exit 0 になる」とだけ書いてありました。実験し直すと、それは正しかったうえに、差し戻しには上限（既定5回）があり、上限まで粘ると exit 1 になる ことも分かりました。ドキュメントにも環境変数として載っていました。（記事）
推測が外れたわけではありません。ただ、測ってみると、メモにない条件が見つかりました。
確かめ方
8件で使った確かめ方は、どれも特別なものではありません。
| 確かめ方 | 使った例 |
|---|---|
| 診断コマンドを打つ | claude doctor（1） |
| ログを数える | 会話ログの拒否の件数（2）、サブエージェントのログ（7） |
| 内訳を細かく見る | 請求をサービス単位ではなく SKU 単位で（3） |
| 時間を測る | statusLine のスクリプトの実行時間（4） |
| 一次資料を読み直す | 公式ドキュメント（1、6、8）、契約の一覧画面（5） |
| 小さく再現する | ダミー課題・最小スキーマで実験（7、8） |
ほかによく使うのは、git log -S です。指定した文字列が増えた・減ったコミットを探せます。たとえば、6 の訂正がいつ入ったかはこれで分かります。
git log -S "DISABLE_TELEMETRY\` でも" --oneline -- src/content/articles/コードのどこで、いつ、ある書き方が入ったのか。「前からこうだったはず」を確かめるのに便利です。
「〜のはず」で止まる
8件を見直すと、推測そのものは、だいたい筋が通っていました。npm 版の更新は遅いことがある気がするし、Networking が0円なら通信料は0円に見えます。外れるのは、推測に筋が通っているから、確かめずに先に進んでしまう ときでした。
いまは、「〜のはず」と書きかけたら、そこで止まるようにしています。数える・測る・ログを見る、のどれかで確かめられるなら、1〜2回のコマンドで終わることがほとんどです。その手間は、外れた推測の上に作業を積み上げてしまう手間よりずっと小さく済みます。
Claude Code と作業すると、この「止まって確かめる」が安くなります。ログの集計スクリプトも、実験の準備も、頼めばすぐに用意してくれます。逆に、Claude の推測も外れることがあるので、Claude が「〜のはずです」と言ったら、それも同じように確かめます。
この記事をシェア