hdknr blog
戻る

Boris Cherny に学ぶ Claude Code の使い方 — 設定を足すより「訂正の回数」を増やす

「便利な設定を集めれば Claude Code は使いこなせる」——これは、たぶん嘘だ。

「Claude Code 活用」で検索して出てくるのは、だいたい次のような話である。

どれも間違ってはいない。ただ、これらは手段のカタログであって、上達の因果ではない。

Claude Code の開発者である Boris Cherny 本人が公開した使い方を一つずつ並べていくと、別の形が浮かび上がる。彼がやっているのは、便利技を集めることではない。計画を実装前に何度も突き返す。訂正のたびにルールを書き換えさせる。会話を半分残したまま捨てる。古くなった指示を洗い出して削る。 この同じ作業を毎日繰り返しているだけだ。

つまり、増やしているのは設定の数ではない。間違いを直した回数である。

この記事の一次情報（Boris Cherny の 10 tips ほか）

この記事は、次の3つの公開情報を突き合わせて整理したものだ。

情報源内容
Boris Cherny の 10 tips（X）Claude Code チームから集めた 10 個の実践 tips
ykdojo/claude-code-tips上記の要約ページと、著者自身による 40+ tips
Thariq Shihipar の context engineering 記事Claude Code のシステムプロンプトを約8割削除した経緯と、そこから得た原則

以下、この3つから読み取れる論点を9つに分けて見ていく。全体をひとつのループとして並べ直すのは最後だ。

Claude Code の訂正ループを示した図。計画を突き返す、実装させる、間違いを直す、その場で CLAUDE.md へ書き戻させる、/doctor で削る、が矢印でつながり最後から最初へ戻る循環になっている。下段には訂正の行き先である3レイヤーと、コンテキストの外部化の手段が並ぶ。

図の要点をテキストでも置いておく。

1. Plan モードは方針決めではなく、実装前の関門

複雑なタスクほど、方針だけ決めて着手したくなる。Boris の方法はその逆だ。

Plan モードで、そのまま実装できるレベルの計画書を出させる。「deeply」「in great details」と明示し、ファイルパスもコード断片も書き出させて plan.md に落とす。そこへ「ここが曖昧」「この順番だと壊れない」とコメントを差し込み、こう返す。

コメント全部に対応して。まだ実装はしないで。

実装を禁じたまま何往復もする。 これが「一発で通る計画」の作り方である。ykdojo の要約では、2つ目の Claude をスタッフエンジニア役に見立て、計画のレビュー専任にする人までいるという。

実装中に詰まったときも、押し通さずに Plan モードへ戻る。詰まりは実装力の問題ではなく、計画の甘さの証拠だからだ。

セッション中は Shift+Tab でパーミッションモードを切り替える。起動時から使うなら次のように指定する。

claude --permission-mode plan

関門を1つ増やすたび、実装のやり直しが1回減る。それだけの話だ。この「やり直しが減る」効果はトークン消費にも直結する。CLAUDE.md に1行追加するだけで Claude Code のコストが 1/3 に — plan モード強制テクニック で、plan モードを常用させたときのコスト差を扱っている。

2. CLAUDE.md は人間が書かない

多くの利用者は、良いルールを思いついたときに CLAUDE.md を開く。ここでも Boris の方法は反対だ。

間違いを直したその場で、こう頼む。

同じミスを繰り返さないように CLAUDE.md を更新して。

Boris は「Claude は自分向けのルールを書くのが不気味に上手い（eerily good）」と表現している。そして、Claude のミス率が測定可能なレベルで下がるまで、これを反復する。

構成としては三分割が効くとされる。

## 常にやること
## 絶対にやらないこと
## プロジェクトの状態サマリ

設定ファイルは、思いつきの改善ではなく訂正の記録に使う。ここが最大の分岐点だ。

3. CLAUDE.md は提案、hooks は強制

ここは賛否が割れるところだが、実務上は決定的に重要だ。

「docker compose down -v するな」と CLAUDE.md に書いたのに実行された、という報告は珍しくない。データが消える種類の事故である。会話が長くなるほど、古い行の影響力は薄れていく。

したがって、安全に関わるルールは hooks で強制する方が確実だ。PreToolUse フックは終了コード 2 を返すことで、ツール呼び出しそのものをブロックできる。

設定は .claude/settings.json に書く。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": ".claude/hooks/deny-destructive.sh" }
        ]
      }
    ]
  }
}

フック本体は実行権限を付けておく（chmod +x .claude/hooks/deny-destructive.sh）。

#!/usr/bin/env bash
# .claude/hooks/deny-destructive.sh
cmd=$(jq -r '.tool_input.command // ""')
if printf '%s' "$cmd" | grep -qE 'docker compose down .*-v|rm -rf /'; then
  echo "破壊的な操作はブロックされました: $cmd" >&2
  exit 2   # exit 2 = ツール呼び出しを拒否
fi
exit 0

この階層を混ぜないことが要点になる。

「書いたのに守らなかった」と嘆く前に、それが提案レイヤーに置かれていないかを確認したほうが早い。

ここでは PreToolUse の exit 2 しか触れていないが、hooks の種類とカスタムコマンド・サブエージェントとの役割分担は Claude Code を「自分専用の開発チーム」に変える3つの機能 — フック・カスタムコマンド・サブエージェント にまとめてある。

4. skill は増やさない — 判断基準は「1日2回以上」

skill を入れまくると、コンテキストが膨らんで判断が鈍る。よくある失敗だ。

選ぶ基準は単純で、1日2回以上やる操作だけを skill にする。Boris tips で挙がっている例はこうだ。

skill はフォルダごと git 管理すれば、チーム全員が同じコマンドを使える。これが「自分専用の便利技」と「チームの資産」を分ける線だ。

なお、かつての .claude/commands/ は Skills に統合されたが、廃止されたわけではなく後方互換で動き続ける。.claude/commands/deploy.md と .claude/skills/deploy/SKILL.md は同等に扱われる。既存の commands を慌てて移行する必要はない。

skill 化は、無闇な追加ではなく反復の削除に使う。

5. プロンプトは従わせる文章ではない — 反論を許可する書き方

指示に忠実なだけの応答は、しばしばコードモンキー化と呼ばれる。指示を聞かせるのではなく、挑ませる。

この変更について私を問い詰めて。私が合格するまで PR を作らないで。

こうすると、設計のエッジケースやテスト戦略が逆に質問として返ってくる。この「詰めさせる」やり方をスキルとして固めたのが grill-me で、grill-me — コードを1行も書く前にAIに徹底的に詰められる、最も人気の Claude Code スキル で扱っている。

出力が微妙だったときは、こう言う。

今わかっていることを全部踏まえて、これは捨てて、エレガントな実装をやり直して。

良いプロンプトとは、反論を許可するものである。

6. コンテキストは外部化する — HANDOFF.md と早めの /clear

ykdojo は自身の tips で、AI のコンテキストを牛乳に例えている。「新鮮で凝縮されているのが一番いい（best served fresh and condensed）」という趣旨だ。会話が長くなるほど、古い情報はノイズになる。

対策は難しくない。記憶を捨てるのではなく、外部化する。セッションの終わりには、こう頼む。

これまでの作業を HANDOFF.md にまとめて。
何を試して、何が効いて、何が駄目だったかを残して。

この HANDOFF.md をスキル化し、さらに複数の Codex へ並列投入するところまで発展させた例が /handoff スキルが海外でバズった理由 — Claude Code で計画して複数 Codex に並列投入する新ワークフロー にある。セッションをまたいで文脈を持ち越す設計そのものは Claude Code の「毎回ゼロスタート」問題 — CLAUDE.md・メモリ・行動ルールでセッション間の文脈を継続させる で整理した。

そのうえで、コンテキストを使い切る前に早めに /clear する。長い会話で精度が落ちていく現象と、その対処の選択肢は Claude Code のコンテキスト管理術 — Context Rot を防ぐ5つの選択肢 にまとめてある。残量を見逃さないために /statusline を設定しておくとよい。サードパーティの ccstatusline を使えば、残量やモデル名を常時ステータス行に出せる。

npx ccstatusline@latest

元の X 記事では「使用率 50% で /clear する」という具体的な閾値が示されているが、これは公式の推奨値ではなく経験則である。自分のタスクの粒度に合わせて調整したい。

7. 設定は足すものではない — Anthropic 自身が8割削った

2026年7月、Anthropic の Thariq Shihipar は「最新モデル向けに Claude Code のシステムプロンプトの約8割を削除した」と公開した。eval のスコアを落とさずに、である。

システムプロンプトから消えたコメント規則

典型例がコメントの扱いだ。以前のシステムプロンプトには、こんなハードルールが入っていた。

In code: default to writing no comments.
Never write multi-paragraph docstrings or multi-line comment blocks — one short line max.

これが、たった一文に置き換えられた。

Write code that reads like the surrounding code:
match its comment density, naming, and idiom.

Thariq の整理はこうだ。これらの制約は、かつて最悪ケースを防ぐために必要だった。しかしモデルが賢くなった今、制約は矛盾する指示と無駄なトークンを生むだけになった。だから削る。「より良い few-shot」ではなく「unhobbling（足枷を外すこと）」が答えだった。

CLAUDE.md をツリー状に分ける

同じことが、あなたの CLAUDE.md と SKILL.md にも当てはまる。

/doctor でサイズ適正化する

この作業を助けるのが /doctor だ。Thariq の記事によれば、これらのベストプラクティスは claude doctor に組み込まれており、skills と CLAUDE.md の**サイズ適正化（rightsizing）**に使える。Claude Code のセッション内でそのまま実行する。

/doctor

ただし、削りすぎには条件がある。能力の高いモデルに合わせて削ると、より小さいモデルでは指示不足になる。複数モデルを併用しているなら、最も低いモデルに合わせて残す判断が要る。

「削る」を実際にやるとどうなるかは CLAUDE.md の設定を99%消したら逆にうまくいった話：AI への指示は「哲学」だけ残せ で試している。本記事は、そこで経験的に得られた結論に Anthropic 自身の一次情報が追いついた、という位置づけになる。

設定の上達とは、行を足すことではなく、行を疑うことである。

8. 音声入力は「表面の tips」でしかない

Boris はコーディングのほとんどを喋って行っており、タイプより3倍速いと述べている。macOS なら fn キー2回でシステムのディクテーションが起動する。Claude Code 自体にも /voice があり、2つのモードを持つ。

ただ、ここで重要なのは、音声入力そのものは表面的な小技に過ぎないということだ。効くかどうかは口述の速度、扱う言語の認識精度、機材性能で変わる。日本語話者にとって英語話者と同じ倍率が出るとは限らない。

したがって本質は使い分けにある。

音声入力の要点は速さではなく、思いついた指示を捨てずに投げ込めるインプットの選択肢が1つ増えることである。これは入力手段が何であっても成立する。

9. コーディング以外を任せる — SQL と社内業務への応用

開発者本人の使い方は、すでに「コード」の外へ出ている。

Boris は「6か月以上 SQL を1行も書いていない」と述べている。データを見たいときは bq などの CLI を Claude に渡して、自然言語で問いを投げる。

Anthropic 社内でも、法務チームが「適切な弁護士につなぐ」ためのフォンツリー型のプロトタイプを Claude Code で作っている。作った本人はコードを書く職種ではない。

筆者の整理としては、この観点で見たときの Claude Code の核はこうなる。ルーティン作業かどうかである。ルーティンである以上、手順として書き出せる。書き出せるなら、システムとして実装できる。

ただし、業務データを渡す前に確認すべきことはある。持ち出しが許されている情報の範囲、社内システムへの接続可否、個人情報が混じっていないかどうか。ここは「便利だから」で飛ばしてよい工程ではない。

まとめ直し：訂正ループを回す7ステップ

ここからは、公開情報から筆者が抽象化した実践モデルである。本人が公開した手順そのものではない。上の9つの論点を、実際に着手する順に並べ替えたものだ。本文の順序と違うのは、実践では足す前に削るところから始めたほうが早いからである。

  1. 削る —— CLAUDE.md と skill を開き、由来を思い出せない行を消す。/doctor でサイズ適正化する
  2. 訂正のたびに書かせる —— 自分で書き足さない。間違いを直した直後に更新を頼む
  3. 守らせたい一行だけ強制する —— 破壊的な操作は hooks へ移す。文章での禁止は提案でしかない
  4. 反復だけを skill にする —— 1日2回以上やる操作に限る。作ったが使わないコマンドは消す
  5. 実装より先に計画を突き返す —— plan.md へコメントを差し込み、実装禁止のまま往復する
  6. 見る手段と検証手段を渡す —— テストやブラウザを繋ぐ。指示を細かくする前に自己検証を用意する
  7. 会話を早めに捨てる —— HANDOFF.md へ退避してから /clear する

足すより引く。削った後に残った数行こそが、現場で実際に使えるルールである。

このループ・CLAUDE.md・Skills という組み合わせは、Anthropic 社内の設計思想としても語られている。Claude Code の社内設計を読み解く：ループ・CLAUDE.md・Skills・Dreaming と併せて読むと、個人の運用と設計側の意図がつながる。

まとめ

Claude Code の上達曲線は、設定ファイルの行数とは相関しない。相関するのは、実装前に間違いを見つけて直した回数と、その訂正を次回に持ち越せる形で書き戻した回数だ。

一度、自分の CLAUDE.md を開いてみてほしい。そのうち、自分の実際のミスから生まれた行は何行あるだろうか。

思いつきで書いた行が多いなら、まずは1行、削るところから始めるのがいい。

付録：元記事との相違点（ファクトチェック）

この記事の元になった X 記事には、公式情報と照合すると調整が必要な記述があった。同じ話を読む人のために残しておく。

元記事の記述実際
CLAUDE.md は 1,000 トークン未満を推奨公式ドキュメントの目安は1ファイルあたり 200 行未満。1,000 トークンという数値の出典は確認できなかった
/doctor で「もう存在しないモデル向けの指示」を検出できる/doctor は skills と CLAUDE.md のサイズ適正化を行うコマンド。「存在しないモデル向け指示の検出」という機能は公式に記載がない
.claude/commands/ は Skills に統一された（＝廃止）Skills に統合されたが後方互換。既存の commands ファイルはそのまま動く
「コンテキストは牛乳」は Boris tips のまとめ発言は ykdojo 自身の tips（tip 5）であり、Boris の 10 tips に含まれる記述ではない

一方、次の主張は一次情報で裏が取れた。

前の記事
「Codex 裏技」を検証 — サブエージェントのモデル指定は codex-router なしでできる
次の記事
「AI時代にテックリードは死ぬ」を検証 — 消えるのは役割ではなく「知識の独占」