Claude Codeに修正を頼むと動くけれど、必要以上に長くて読みづらいコードが返ってくることがある。
そんな時は同じ会話のまま「scrap this（これを捨てて）、いま分かっていることを全部使って綺麗に書き直して」と1行追加すると、Claude Codeがコードを作り直す。
「リファクタして（書き直して）」より「scrap this（一回捨てて）」のほうが効く理由まで含めて、Claude Code作者の公開投稿で出ている小ワザです。
この記事はClaude Codeを触ったことがあって、出てくるコードが長すぎて困っている人向け（CLI（文字コマンドでツールを動かす画面）の基本操作と、AIに指示を出した経験があれば読めます）。
そもそも「長すぎるコード」って何のこと？
Claude Code（Anthropic公式の、AIにコードを書いてもらうコマンドライン型ツール）に「バグを直して」と頼むと、たいてい動くコードは返ってくる。
問題はその中身です。
同じことをするのに10行で済むはずが30行書かれている。
条件分岐がやたら多い。
同じ処理が2回出てくる。
変数名が長くて読みづらい。
10行で済むはずのコードが30行になっている。
これが「ムダに長くて回りくどいコード」です。
ここが厄介。
動くから直す動機が湧きづらい。
でも放置すると、後で読み返した時に何やってるか分からなくなる。
だから書き直したい。
普通の発想だと「リファクタして（書き直して）」と頼みます。
これがあまり効かない。
次のh2でやり方の代案を書きます。
1行追加するだけのやり方（3ステップ）
Claude Code作者本人が2026年1月31日に公開した小ワザがあります。
手順は3ステップ。
STEP1. いつも通り実装させる
普通にClaude Codeに依頼します。
例:「ログインの回数制限（一定時間に何回までログイン試行を許すか）を実装して」。
Claude Codeは関連ファイルを読んで、動くコードを返してくる。
これが「動くけど長い」の状態です。
期待結果は「とりあえず動くコードが10〜30行出てくる」。
STEP2. 同じ会話のまま、この1行を投げる
Knowing everything you know now, scrap this and implement the elegant solution.
（いま分かっていること全部踏まえて、これを捨てて綺麗な実装にし直して）
日本語で投げてもいいけれど、「scrap this（これを捨てて）」の語感を残したいので私は英語のまま投げます。
「リファクタ」「書き直して」とは絶対に書かない。
これが効きを保つコツ。
詰まりどころは、つい「ちょっと整理して」と弱い言葉に直してしまうこと。
それだと小幅なお直しで終わります。
Claude Code作者本人の投稿原文がこれです。
After a mediocre fix, say: "Knowing everything you know now, scrap this and implement the elegant solution"
（イマイチな修正の後にこう言え:「いま分かっていることを全部踏まえて、これを捨てて綺麗な実装にし直せ」）
位置づけは「Level up your prompting（プロンプト力を底上げする）」セクションの Tip 6b。
プロンプトの型として中核扱いになっています。
STEP3. 出てきたコードを git diff（コードがどう変わったか比較するコマンド）で読む
2段目で出てきたコードは構造から書き直されていることが多い。
だから差分を見て確認します。
「処理が短くなりすぎてないか」「最初に拾えていた例外パターンが消えてないか」をここで人の目で見る。
30行が15行くらいに減って、意図が読める。これが期待する結果です。
詰まりどころは、短くなったのに喜んで、消えた例外処理に気づかないこと。
差分は必ず1行ずつ目で追います。
「リファクタして」じゃダメな理由
Claude Code公式ドキュメントにこう書いてあります。
A fresh context improves code review since Claude won't be biased toward code it just wrote
（新しい会話文脈にすると、Claudeはさっき書いたコードに引っ張られなくなる）
裏返すとこう。
同じ会話の中で「リファクタして」と頼むと、Claudeはさっき書いたコードに引っ張られて、ちょっとしたお直しで終わってしまう。
これが「リファクタして」が効かない正体です。
研究も後ろ盾になっています。
LLM（大規模言語モデル）の「最初の答えに引きずられる癖」を測った2024年12月の論文では、162件の比較のうち151件（93%）で、最初に与えたヒントの方向に答えが引っ張られていたと報告されています（出典: arxiv.org/abs/2412.06593）。
162件中151件、つまり93%が引っ張られた。これがちょっとやばい数字です。
強いモデルほどこの引きずられ方が大きい、とも書いてある。
だから「scrap this（これを捨てて）」と命じるのが効く。
「リファクタ」は既存コードを残して直す意味、「scrap this」は既存コードを捨てる意味。
同じ会話の中の「要件・例外・依存関係の知識」は残したまま、「書いたコードだけ捨てて作り直し」を起こせる。
これが2段プロンプトの肝です。
「リファクタして」と「scrap this」の違い
| 軸 | 「リファクタして」 | 「scrap this（これを捨てて）」 |
|---|---|---|
| 命令の強さ | 弱（既存コードを残して直す） | 強（既存コードを捨てて作り直す） |
| 引っ張られ方 | さっき書いたコードに引っ張られたまま | コードだけ切り、要件知識は残る |
| 出てくる結果 | 変数名の変更、関数を分けるくらいで止まる | 構造から書き直される |
| 会話の扱い | 同じ会話を続ける | 同じ会話を続ける（/clearはしない） |
| 裏付け | — | Claude Code作者の公開投稿 Tip 6b ／ 公式docs |
「同じ会話を続ける」が地味に大事。
新しい会話を開くんじゃなくて、要件理解が乗っている会話のまま、コードだけ捨てさせる。
私はここがリファクタとの最大の違いだと思います。
うまくいかない時の追加プロンプト
2段目で完璧に決まることは多くない、というのが正直なところ。
Claude Code公式ドキュメントもこう言っている。
Correct Claude as soon as you notice it going off track. The best results come from tight feedback loops.
（おかしいと思ったらすぐ軌道修正しろ。
最高の結果は短いやり取りの繰り返しから生まれる）
場面別に「3段目で投げる1行」をまとめました。
| こうなった時 | 3段目で投げる1行 | 狙い |
|---|---|---|
| 2段目で短くなりすぎ・例外処理が抜けた | 「Add back the edge cases from the first attempt: [拾い直したいケースを列挙]」（最初に拾っていた例外を戻して） | 1段目で扱えていたケースを再注入 |
| テストがない | 「Now write tests covering [境界値/異常系]」（テストを書いて） | 2段目のコードに穴がないか先にテストで埋める |
| 本番直前で外側を変えたくない | 「Keep the public API identical to the first attempt, only restructure internals」（外から呼ぶ部分は変えず、中身だけ作り直して） | 外向けの呼び出し方を固定して、中だけ綺麗に |
| 引き継ぎ用にコメントが欲しい | 「Add docstrings to every public function explaining intent, not implementation」（何をやっているかではなく何のためかを書いたコメントを足して） | 後で読む人向けの注釈をまとめて入れる |
| 同じ問題で2回以上失敗している | /clear して、最初から書き直す | 公式推奨。会話が失敗例で散らかった時の標準対応 |
最後の行は公式ドキュメントの推奨そのもの。
If you've corrected Claude more than twice on the same issue in one session, the context is cluttered with failed approaches. Run /clear and start fresh with a more specific prompt.
（同じ問題で2回以上修正したら、会話が失敗例で散らかっている。
/clearして、もっと具体的なプロンプトでやり直せ）
2段プロンプトは万能じゃない、という話。
同じ問題で2回ハマったら2段目に粘らず /clear。
これが公式の判断軸です。
料金の目安
2段プロンプトを使うと、トークン（AIが文字を処理する時の単位、文字数みたいなもの）の消費は単純に倍近く増えます。
1段目を作って、出力されて、2段目を投げて、また作り直す。
だから自然と消費量も倍に近づく、という話です。
Claude Code公式の費用データはこう。
| 項目 | 数値 | 注記 |
|---|---|---|
| 平均コスト | $13/開発者/稼働日 | 公式docs記載 |
| 月額の目安 | $150〜$250/開発者 | 同上 |
| 稼働日に$30未満で済む割合 | 90% | 同上 |
| 複数AI並列で動かす機能を使うと | 標準の約7倍トークン | 大量に走らせる時の注意 |
料金プラン側はこちら（出典: Claude公式 料金ページ、2026年4月時点）。
| プラン | 料金 | Claude Code |
|---|---|---|
| Free | $0/月 | 含む |
| Pro | $17/月（年払い）/ $20/月（月払い） | 含む |
| Max | $100/月〜 | Claude Codeの利用枠が増える |
| Team | $20/シート（年払い） | Claude Code + Cowork含む |
| Enterprise | $20/シート＋使用量課金 | Team機能を全部含む |
私はProプラン月20ドルの枠で2段プロンプトを多用しても、費用面で困ることはほぼないと思います。
月30ドル未満で収まる人が9割という公式データもあるので、ここはあまり神経質にならなくていい。
いつ使うか、いつやめるか
使うべき場面は3つに絞られます。
- 1段目の出力が「動くけど長い・命名が雑・何をやってるか分かりづらい」と感じた時
- 同じ会話の中に要件・制約・例外パターンの理解が乗っている時（この知識資産は捨てたくない）
- 同じ問題でまだ修正0〜1回（公式は2回以上で /clear 推奨）
逆にやめるべき場面はこちら。
- 同じ問題で2回以上修正済み（公式推奨: /clearして最初からやり直す）
- 本番直前で大胆な変更が許されない（外向けの呼び出し方を固定する3段目テンプレを使う）
- 1段目で長時間の探索が走り、会話がすでに膨大（先に /clear する判断）
Claude Code公式ドキュメントはこう明言しています。
A clean session with a better prompt almost always outperforms a long session with accumulated corrections.
（綺麗な会話＋良いプロンプトは、修正が積み重なった長い会話にほぼ常に勝つ）
2段プロンプトはこの原則の中の一手。
上位の原則は「適切なタイミングで会話を切る」。
粘らないのが正解の場面が必ずある、という話です。
私は3回目の修正に入りそうになったら、迷わず /clear します。
FAQ
Q1. 「scrap this」と「delete your fix」はどっちを使えばいい？
Claude Code作者の公開投稿で確認できる原文は「Knowing everything you know now, scrap this and implement the elegant solution」（2026年1月31日）。
「delete your fix」も同じ意味で広まっていますが、引用根拠が固いのは「scrap this」側。
本記事は原文準拠で「scrap this」を主に扱います。
Q2. 「リファクタして」と何が違う？
命令の強さが違います。
「リファクタ」は既存コードを残して直す意味、「scrap this」は既存コードを捨てて作り直す意味。
Claude Code公式が言う「さっき書いたコードに引っ張られる癖」を切る効果は、「捨てて」と命じる側の方が強く出ます。
Q3. 2段目は新しい会話を開いたほうがいい？
開かないほうが良い場面が多い、というのが公式docsの示すところ。
要件・例外・依存関係の理解は会話に乗せたまま、コードだけ捨てさせる、というのが2段プロンプトの設計思想です。
新しい会話で別Claudeにレビューさせるパターンは公式ドキュメントに別途あります。
これは目的が違う使い方。
Q4. 何回まで同じ会話で修正していい？
Claude Code公式ドキュメントは2回が境目。
「If you've corrected Claude more than twice on the same issue in one session, the context is cluttered with failed approaches. Run /clear and start fresh with a more specific prompt.」と明記されています。
3回目以降は /clear が公式推奨。
Q5. トークンの使いすぎが心配です
2段プロンプトは1段目より単純に多めに使います。
Claude Code公式の費用データは平均$13/開発者/稼働日、月$150〜$250。
90%のユーザーは稼働日$30未満で済んでいる。
Proプラン$20/月の範囲なら多用しても費用感は問題になりにくい。
複数AI並列で動かす機能を使うと標準の約7倍トークンを消費する、と公式が明示しているので、こちらは別の話です。
このページに出てきた言葉
- CLI
- コマンドラインインターフェース。文字コマンドでツールを動かす画面
- ムダに長くて回りくどいコード
- 同じことが10行で済むのに30行書いてある、条件分岐が多い、同じ処理が2回出てくる、といった読みづらい状態のコード
- 2段プロンプト
- 1段目で実装させた直後に、同じ会話で「これを捨てて綺麗に書き直して」と命じる2段階の指示の型
- scrap this
- 「これを捨てて」の意味の英語。Claude Code作者の投稿で使われている原文表現
- リファクタ
- 既存コードを残しつつ、内部だけ書き直して綺麗にすること。今回は「scrap this」より効きが弱い書き方として登場
- git diff
- コードがどう変わったかを比較表示するgitコマンド。2段目の出力レビューで使う
- /clear
- Claude Codeのコマンド。会話履歴をリセットして新しい会話で始め直す
- トークン
- AIが文字を処理する時の単位。文字数みたいなもの。プロンプトと出力の合計で課金される
- 例外パターン（境界値・異常系）
- 普段は起きないけど稀に起きる例外的なケース。境界値や異常な入力など
参考リンク
- Claude Code 公式ドキュメント（ベストプラクティス）: https://code.claude.com/docs/en/best-practices
- Claude Code 公式ドキュメント（概要）: https://code.claude.com/docs/en/overview
- Claude Code 公式ドキュメント（コスト管理）: https://code.claude.com/docs/en/costs
- Claude Code セッション管理ブログ: https://claude.com/blog/using-claude-code-session-management-and-1m-context
- Anthropic 料金ページ: https://claude.com/pricing
- Claude Code作者 公開投稿（Tip 6b 一次ソース）: https://www.threads.com/@boris_cherny/post/DUMZxTWElFm
- arXiv論文（LLMが最初の答えに引きずられる癖）: https://arxiv.org/abs/2412.06593
※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。