Claude Code作者の効率アップ10ヶ条、自分のログで採点したら1位が入れ替わった
📋 この記事でわかること
✅ Claude Code作者Borisが公開した効率アップ10ヶ条の中身と、自分の実ログでの採点結果
✅ 計画を詰めさせる時に足す一言と、その一言で計画が紙芝居まで細かくなる理由
✅ 作者が「確実」と言うhooksを入れて、9日で5回環境が死んだ記録
✅ CLAUDE.mdを640字まで削って、30日後に2,232字へ戻っていた話
✅ 起動床19.5Kトークンに対して、1ターンの中央値が150Kトークンだったこと
✅ 効く習慣を、他人の推し順から自分のログの順へ並べ替える手順
Claude Codeの作者Borisが公開したtipsをまとめた動画を見た。効率アップの10ヶ条、という形で並んでいる。
見終わって最初に思ったのは「半分もうやってるな」だった。次に思ったのは「1個はこれのせいで痛い目に遭ったやつだ」だった。
だから記事にするのは紹介じゃない。答え合わせにする。手元には35日ぶんのトークン実測と、5回ぶんの障害ログと、削ったmdの文字数が残っている。それで10個を採点した。
先に結論を書く。公式の推し順は、自分の環境の推し順ではない。 実測で1位だった習慣は、動画の中では作者の一番推しではなかった。
🧭 計画は「deeply」を足すまで、シグネチャ止まりで返ってくる
10個の土台になっているのが、実装前にPlanモードで計画を詰め切る話だった。ここは動画の中で一番そのまま真似できる部分なので、手順を先に書く。
やり方はこうなっている。方針だけ渡すと、計画はシグネチャレベルで流れてくる。そこで「deeply」「in great details」を明示すると、ファイルパスもコードスニペットも書き出した、そのまま実装できる粒度まで落ちてくる。動画ではこれを紙芝居レベルと呼んでいた。
その計画を plan.md に書かせて、こちらはインラインでコメントを入れる。「ここ曖昧」「この順番だと壊れない？」と突っ込みを差し込んで、「コメント全部対応して、まだ実装しないで」と返す。実装を禁止したまま何往復かすると、一発で通る計画になっている。詰まったら押し通さずにPlanモードへ戻る、というのも作者本人の言い方だった。仕上げに、別セッションへ plan.md をそのまま渡してスタッフエンジニア役でレビューさせる。
自分は同じ結論に、別のルートで着いていた。
note記事を書く流れを7工程に切って、それぞれ別のskillにしてある。題材、初稿、本文の締め、関連記事、図、下書き保存、公開後の数字。工程を先に決めてから書き始めるので、結果としてPlanモードと同じことをしている。判断が割れた時の記録も別に残していて、今46件たまっている。
ただ、自分の実測はここで正直じゃないことを言う。計画は詰められるようになったのに、未公開の記事が41本たまっている。
計画の粒度を上げても、出荷は速くならなかった。ボトルネックは設計よりずっと後ろ、公開ボタンを押す手前の判断にあった。だからこの習慣の採点は○にしてある。効くのは効くが、自分の一番痛いところには当たらない。
🪝 作者が「確実」と言うhooksで、自分は5回環境を壊した
CLAUDE.mdに書いたルールは無視されることがあるので、絶対に守らせたい安全系のルールはhooksで強制した方が確実、という話が出てくる。理屈としては正しい。CLAUDE.mdは提案で、hooksは実行だ。動画でも「docker compose down -v するな」と書いたのに実行された、と報告が紹介されていた。
ただ、自分の手元のログは逆の証言をしている。
6月16日から6月24日までの9日間で、hooks起因の環境障害を5回記録している。症状はだいたい同じだ。Bashコマンドが command not found: _lc で落ちて出力が丸ごと消える。mdが読めない。ひどい時はmp4のようなバイナリまで読めなくなる。
原因は自分で書いたhooksではなかった。入れていたトークン削減ツールが、更新のたびに settings.json へPreToolUseフックを自動で書き戻していた。
外す。再起動する。数日後にまた復活する。これを4回繰り返して、5回目でようやく書き戻しの元を特定した。厄介なのは、フックを外してもライブセッションは古いフックをキャッシュしていることで、直後にテストすると直っていないように見える。再起動して初めて消える。
ここでの学びは、hooksが悪者だ、で終わらない。
hooksは強制力があるから効く。強制力があれば、壊れた時も強制的に壊れる。自分で書いた1本なら追える。ツールが勝手に足していく分は追えない。
この記事を書きながら、今の設定を測り直した。そこで6回目が見つかった。
$ python3 -c "import json; ..." # ~/.claude/settings.json の PreToolUse
[0] matcher=Write|Edit|MultiEdit|Bash|...
cmd: /Users/orlha/.claude/hooks/guard-launchagents.py ← 自分で書いた1本
[1] matcher=Bash|bash
cmd: /Users/orlha/.local/bin/lean-ctx hook rewrite ← 5回落とした犯人
[2] matcher=Read|Grep|Search|ListFiles|...
cmd: /Users/orlha/.local/bin/lean-ctx hook redirect ← 「md読めない」の犯人
$ ls ~/.claude/settings.json.bak* | wc -l
10
出典：evidence/20260805_pretooluse_hooks.txt
6月に5回外した2本が、そのまま戻っている。今は落ちていないので気づいていなかった。バックアップが10個あるのは、外した回数の記録がそのまま残っているからだ。
⚠️ つまり自分は、この記事で「hooksは条件つきで✕」と書いておきながら、その条件を満たした環境で1か月半すごしていた。恒久対策はまだ打っていない。
AIに任せる前に、こちら側のルールを1つ変えた話は前にも書いた。今回はそのルールが、自動で書き換えられていた側の記録になる。
採点は条件つきで✕。安全系ルールを強制するのは賛成だが、フックを自動で足すツールを同時に走らせているなら、先にそっちを止める。
📄 640字まで削ったCLAUDE.mdは、30日で2,232字に戻っていた
動画の終盤に、Anthropicがシステムプロンプトの8割以上を削除したという話が出てくる。モデルが賢くなったので細かく縛らない方針になった、と。CLAUDE.mdも1,000トークン未満に抑えることが推奨されていて、50行を1行まで削った人の例まで紹介されている。残したのは「ワークアラウンド以外でコメントを書くな」の一行だけだったらしい。
自分もこれはやった。7月6日に、常時読み込むmdをまとめて削っている。
~/.claude/CLAUDE.md は1,553字から約640字へ。ローカルLLM用の手順書は4,300字から1,820字へ縮めて、詳細は別ファイルへ退避した。記憶用の索引も4,775字から4,040字に圧縮している。計算上は毎ターン約3,180トークン減、月にすると46Mトークン相当だった。
削った当時は満足していた。
今日その同じファイルを測った。
$ wc -c ~/.claude/CLAUDE.md.bak-before-trim-20260706 ~/.claude/CLAUDE.md
1553 /Users/orlha/.claude/CLAUDE.md.bak-before-trim-20260706
2232 /Users/orlha/.claude/CLAUDE.md
出典：evidence/20260805_claudemd_regrow.txt
2,232字ある。削った直後の3.5倍で、削る前より太い。常時読み込まれるmdを全部足すと20,527字あった。
増えた行を確認したら、どれも自分が痛い目に遭って足したものだった。セッションが固まる原因と対処。ファイルパスを絶対パスで出す決まり。一度ゼロに寄せて、また必須に戻した絵文字ルール。全部、実際にやらかした後の追記だ。
つまり自分のCLAUDE.mdは、削っても戻る。戻す力の正体が失敗の記憶なので、たぶん止められない。
1,000トークン未満という基準を守り続けるより、太った時にどの行が失敗由来で、どの行が「なんとなく良さそう」で足されたのかを見分ける方が現実的だと思っている。動画で紹介されていた /doctor は、まさに後者を洗い出す道具として出てきていた。もう存在しないモデル向けのルールが残っていないかを調べるコマンドだ。
「プロンプトより作業ルールを資産にする」と前に書いたが、資産は放っておくと重くなる。
採点は△。方向は正しい。ただ削減を目標にすると、失敗から足した行まで一緒に削ってしまう。
🥛 ファイルを削っても、1ターンの2%しか動かなかった
同じ動画の中に、AIのコンテキストは牛乳と同じで新鮮で凝縮されているのが一番いい、という引用がある。会話が長くなるほど古い情報がノイズになるから、使用率50%で /clear する。残量を見逃さないために /statusline を設定して常時表示する。そういう運用が紹介されていた。
自分はこれを、mdを削る前に実測している。
起動時に必ず読まれる床は約19.5Kトークンだった。それに対して、1ターンで動くトークンの中央値は約150Kトークンあった。mdを全部削ったところで、動くのは床の一部でしかない。
実際、7月6日の削減で減ったのは毎ターン約3,180トークン。150Kに対して2%ぐらいしかない。
残りは会話そのものだ。同じセッションで話題を跨いで作業を続けると、過去のやりとりを毎ターン読み直す。長引くほど1ターンが重くなり、最後は動作そのものが固まる。自分は原因を記憶ファイルの持たせすぎだと思い込んでいたが、実際に効いていたのは1本の会話を引っぱった長さだった。
だからルールは「mdを削る」ではなく「話題が変わったら新しいセッションに移る」になった。長引いた時は引き継ぎメモを1本書いてから切る。この引き継ぎメモは今63本たまっている。
動画で紹介されていたHANDOFF.mdと同じ発想に、自分は障害対応の側から着いていた。作者に言われて入れた習慣ではない。固まって作業が飛んだ回数のぶんだけ、勝手にそうなった。
採点は◎。10個の中で、実測の効き目が一番大きかったのはここだった。
🧰 1日2回やる操作をskillにしたら、35個になった
動画では、1日2回以上やる操作はskillにしておけ、と言っている。重複コードを検出する /techdebt、テストからpushまで一気に流す /finalize のような例が出ていた。フォルダごとgitに入れればチーム全員が同じコマンドを使える、という話も添えられている。
自分の環境には今35個のskillがある。
半分ぐらいはnote記事の工程だ。1本の記事を作る流れを7工程に切って、それぞれを別のskillにしてある。残りは検証、デバッグ、画像の検品、他のAIへのセカンドオピニオンあたりに割ってある。
効いたのはコマンドが短くなったことではなかった。工程が切れたことだ。
1本まるごと書かせると、途中で失敗した時にどこからやり直せばいいか分からない。工程を切っておくと、失敗した工程だけ差し戻せる。今日で言えば、この記事は初稿の工程にいて、図と入稿はまだ通っていない。その状態が外から見える。
動画には /loop と組み合わせて、指定した間隔でskillを繰り返し実行する話も出てくる。5分おきにPRの世話をさせる例だった。自分の工場も夜と朝に自動で回している。ただ、公開ボタンと価格と画像のOKだけは人間に残してある。ここを渡すと、失敗した時に誰も気づかないまま出てしまう。
採点は◎。ただ「よく使うから」ではなく「途中で失敗するから」を基準に切った方が効く。
🌲 保留にした3つと、月3.5億トークンの皮肉
10個のうち3つは採点できなかった。試していないからだ。ここは正直にそう書く。
1つ目がgit worktreeでの並列セッションで、動画によると作者本人が一番推しているのがこれだった。3〜5個のworktreeを作って、それぞれでセッションを走らせる。同時にコミュニティから「月3億5千万トークン使う方法」と皮肉られていた、という話も紹介されている。
その数字を見て笑えなかった。
7月に、26日ぶんの自分のトークン消費を実測して記事にしている。Claude Codeが24.6億、Codexが10.4億、合計35億トークンだった。並列セッションなど組んでいない。皮肉として出てきた月3.5億の、ちょうど10倍を1人で使っていたことになる。
内訳で効いていたのはキャッシュだった。Claude側の93.4%が、自動で再読込されるcache_readだ。ツールやローカルLLMで自分が手で削った37万トークンは、全体の0.011%にしかなっていない。動画でも、worktreeを組む前にまず「use subagents」と言うだけの並列から試すのが無難だと言っていた。自分もそっちから入る。
2つ目が音声入力だ。作者本人はコーディングのほとんどを喋ってやっていて、タイプの3倍速いと言っている。一方で動画に出てくる現場の反応は「タイプの方が速い」「認識精度が95%止まり」がほとんどで、作者が全振りしているのに誰も信じていない、という状態になっていた。
この項目が一番この記事の主題を表していると思う。作者の環境で3倍速いのは、たぶん本当だ。その上で、他の人の環境では速くならない。どちらも嘘をついていない。環境が違うだけだ。
3つ目がAIに問い詰めさせる使い方で、「この変更について私を問い詰めて、合格するまでPRを作るな」と頼むと逆質問が返ってくる、という話だった。エッジケースやテスト戦略を先に聞かれる。普通に指示するだけだと従順に作業して終わるので、こちらから挑ませにいく。まだ計測していないが、これは今週すぐ試せる。
動画の最後に、逆効果になるパターンの話も出てくる。有名なルールセットをそのまま入れると、AIが異議を一切出さなくなる報告が多い、と。「最もシンプルな解決策」と「関係ないコードを触るな」を組み合わせると、目の前のテストを通す最短経路だけ選んで、3ファイル後に詰むコードを量産し始める。改良版は「明らかに良い方法があれば、トレードオフを説明してから進めて」と書くらしい。
他人のルールをコピーして自分の環境で壊す、という形が、hooksの話とここで一致した。
🧾 10個を実測順に並べ替えると、こうなった
採点を1枚にまとめた。基準は「自分の手元に、効いた or 効かなかったと言える数字があるか」だけにしてある。
1位は、作者の一番推しではなかった。セッションを切ることだった。
当たり前なことだ。
この順番は自分の環境の順番であって、読者の順番ではない。手順としては、設定をいじる前に自分の1ターンあたりのトークンと、直近1か月で作業が飛んだ回数を数える。効くのは、その数字が大きい方に対応する習慣だ。
自分の場合、飛んだ回数が多かったのはセッションが固まった時とhooksが壊れた時で、mdが長かった時ではなかった。だからmd削減は後回しになり、セッションの切り方が1位に上がった。
命令形で一行にすると、こうなる。
他人の設定は、自分のログで採点してから入れろ。
📌 まとめ：公式の正解は、自分の環境では順位が変わる
現在地はここだ。10個のうち◎が2つ、○が2つ、△が2つ、✕が1つ、保留が3つ。保留の3つは自分がまだ試していないだけで、動画の内容が間違っているという意味ではない。
次の課題は保留の消化になる。問い詰めさせるやつは今週すぐ試す。音声入力は短い指示だけで1週間使って、認識精度を自分で数える。並列は35億の内訳を見たあとなので、サブエージェントから消費量を測りつつ入れて、worktreeはその後だ。
読んでいる人に聞きたいのはここです。設定をいじる前に、自分の環境で何が一番作業を止めているか、数字で言えますか。
自分は9日で5回落ちるまで、原因がhooksだと分かっていなかった。落ちた回数を数え始めてから、直す順番が決まった。
スキを押してもらえると次を書く励みになります🌟
#ClaudeCode #AI #生産性 #開発効率化 #AI活用 #エンジニア #副業 #自動化 #note毎日更新 #作業効率化
