Claude Codeのバグ修正は動くが冗長になりがち、
という痛点に対して海外で広まっているのが「2段プロンプト」です。
Claude Code作成者は2026年1月31日のX/Threads投稿で「Knowing everything you know now, scrap this and implement the elegant solution」を Tip 6b として公開しています。
同じセッション内で投げる1行で、
保守的な初手コードを破棄させて再設計させる手法。
「リファクタして」では届かない領域です。
この記事はClaude Codeを触ったことがあるが出力コードが冗長で困っているWeb系/SaaS開発者向け（CLI（コマンドラインで操作するツール）の基本操作とプロンプト指示の経験があれば読めます）。
Claude Codeの2段プロンプトとは何か
Claude Codeは公式ドキュメントで「agentic coding tool that reads your codebase, edits files, runs commands」と説明されている、
コードベース全体を読んでファイル編集とコマンド実行までこなすCLIツールです（出典: code.claude.com/docs/en/overview）。
そのClaude Codeに対して、
1段目で実装させた直後に、
2段目で「これを破棄して、
いま分かっていることを全部踏まえてエレガントな解を実装せよ」と投げる。
これが2段プロンプトの骨格です。
Claude Code作成者がX/Threadsで公開しています。
After a mediocre fix, say: "Knowing everything you know now, scrap this and implement the elegant solution"
（凡庸な修正の後にこう言え：「いま分かっていることを全部踏まえて、
これを破棄してエレガントな解を実装せよ」）—— Claude Code作成者の投稿（2026年1月31日、Threads）
出典: threads.com/@boris_cherny/post/DUMZxTWElFm
位置づけは「Level up your prompting」セクションの Tip 6b。
Tip 6a は「Grill me on these changes」（変更点を厳しくレビューさせる）、
Tip 6c は「事前に詳細スペックを書く」と並んでいます。
プロンプト力を底上げする型の中核として置かれている、
ということ。
個人的には、
ここで「言葉の選び方」が地味に重い。
「リファクタして」ではなく「scrap this（これを破棄せよ）」と命じる。
同じく流通している別表現の「delete your fix」も語感は同じです。
なぜ「Delete」と「Refactor」で出力が変わるのか
Claude Code公式ドキュメントは「fresh context improves code review since Claude won't be biased toward code it just wrote」と書いています（出典: code.claude.com/docs/en/best-practices）。
直訳すると、
フレッシュなコンテキストにすればClaudeは「自分がさっき書いたコードに引きずられない」。
裏を返せば、
同じセッション内で「リファクタして」と頼むと、
自分が書いたコードに引きずられたまま局所的な手直しに収束しがち、
ということです。
これが地味にやばい。
私はここに2段プロンプトの設計の核があると見ています。
学術側の傍証もあります。
LLMアンカーバイアス論文（arXiv:2412.06593）は、
162件の分布差のうち151件（93%）でアンカーヒントに沿った方向性バイアスを確認したと報告しています（出典: arxiv.org/abs/2412.06593）。
Stronger models are consistently biased by anchor hints.
（強いモデルほどアンカーヒントによるバイアスを継続的に受ける）—— arXiv:2412.06593「Anchoring Bias in Large Language Models」（2024年12月）
つまり、
いったん書いたコードがアンカー（錨）として効き、
続く指示はその錨から離れにくい。
「Refactor（手直し）」はアンカー前提の語、
「Delete/Scrap（破棄）」はアンカーを切る語、
という語感差がここで効いてくる構造です。
この差は語彙レベル。
「破棄せよ」と命じることで、
モデル側に「いまコンテキストに乗っている知識（要件・エッジケース・依存関係）を温存しつつ、
コードだけ捨てる」という再設計モードを起動させる、
と読める構造。
Delete指示と Refactor指示の違い（仕組み起点）
| 軸 | 「リファクタして」 | 「scrap this / delete your fix」 |
|---|---|---|
| 命令語の強度 | 弱（既存コード前提の手直し） | 強（既存コード破棄＋再構築） |
| アンカーバイアス | かかったまま（自分の初手に引きずられる） | コード側だけ切る（要件知識は維持） |
| 出力傾向 | 局所的修正、変数名変更、関数分割止まり | 構造から再設計、抽象度の見直し |
| セッション扱い | 同一セッション継続 | 同一セッション継続（/clearではない） |
| 裏付け | — | Claude Code作成者 Tip 6b ／ 公式ドキュメント Writer/Reviewer パターン |
「同一セッション継続」が地味な肝。
フレッシュコンテキストではなく、
要件理解が乗ったセッションのまま「コードだけ捨てさせる」。
私はこの「知識は残してコードだけ切る」設計が、
Refactorとの最大の違いだと読んでいます。
2段プロンプトを実際に投げる手順
Claude Code公式ドキュメントと作成者投稿が示す手順を再構成すると、
以下の3ステップになります。
手順は公式記述と一次ソースに沿った形で書きます。
STEP1. 1段目で普通に実装させる
通常通りClaude Codeに依頼します。
例：「ユーザー認証のレートリミッター（一定時間内のアクセス回数を制限する仕組み）を実装してくれ」。
Claude Codeは codebase（プロジェクトのソースコード一式）を読み、
ファイルを編集して動くコードを返してきます。
動くが冗長、
というのが想定されるアウトプットです。
STEP2. 同じセッションのまま2段目を投げる
1段目の実装が終わった直後、同じセッション内で次の1行を追加します。
Knowing everything you know now, scrap this and implement the elegant solution.
日本語で投げる場合は「いま分かっていること全部踏まえて、
これを破棄してエレガントな実装にし直してくれ」。
語感を温存するなら原文英語のまま投げるのが無難。
「Refactor」「リファクタ」の語は使わない。
これが言葉の強度を保つコツです。
STEP3. 出力を git diff（変更差分の可視化コマンド）で読む
2段目の出力は構造から書き直されている可能性が高いので、
変更差分を確認します。
エッジケース漏れ・テスト不足・既存APIとの整合性を、
ここで人間がレビューする。
Claude Code公式の Writer/Reviewer パターン（別セッションでレビューさせる）を併用するなら、
ここで /clear して別セッションを開きます。
引っかかりやすいポイントは2つ。
1つは「2段目で短くなりすぎ」現象（過度な抽象化）、
もう1つは「1段目で踏んだエッジケースが2段目で抜ける」現象。
次のh2でフォロー型を解説します。
3段目以降のフォローパターン（場面別テンプレ）
2段目で完璧に決まることは多くない、
というのが正直なところ。
Claude Code公式ドキュメントも「Correct Claude as soon as you notice it going off track. The best results come from tight feedback loops.」と書いています（出典: code.claude.com/docs/en/best-practices）。
軌道修正は早く、
フィードバックループは短く。
私が場面別に整理した3段目フォローの型は以下です。
| 場面 | 3段目で投げる言葉（型） | 狙い |
|---|---|---|
| 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 JSDoc/docstrings to every public function explaining intent, not implementation」 | 意図ベースのコメントで保守性を上げる |
| 同じ問題で2回以上修正 | /clear → 学んだ前提を盛り込んだ初期プロンプトを書き直す | 公式推奨：「context is cluttered with failed approaches」を切る |
最後の行は公式ドキュメントの推奨そのもの。
「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.」（出典: code.claude.com/docs/en/best-practices）。
2段プロンプトは万能ではない、
ということ。
同じ問題で2回以上ぶつかったら2段目に固執せず /clear する。
これが公式の判断軸。
料金とコンテキスト消費の現実
2段プロンプトを使うとトークン消費は素朴に倍近くなる、
と読むのが妥当です。
1段目の実装＋出力＋2段目の指示＋再生成。
Claude Code公式の費用ページは企業導入の実績平均値を出しています（出典: code.claude.com/docs/en/costs）。
| 項目 | 数値 | 注記 |
|---|---|---|
| 平均コスト | $13/開発者/稼働日 | 公式ドキュメント記載 |
| 月額目安 | $150〜$250/開発者 | 同上 |
| 稼働日 $30未満の比率 | 90% | 同上 |
| agent teams使用時 | 標準セッションの約7倍トークン | 大規模利用時の注意 |
料金プラン側は以下です（出典: claude.com/pricing、
2026年4月時点）。
| プラン | 料金 | Claude Code |
|---|---|---|
| Free | $0/月 | 含む |
| Pro | $17/月（年払い）/ $20/月（月払い） | 含む |
| Max | $100/月〜 | Claude Code利用量増 |
| Team | $20/シート（年払い）/ $25/月（月払い） | Claude Code + Cowork含む |
| Enterprise | $20/シート＋使用量課金 | Team機能全部含む |
もう1つの注意点はコンテキストロット。
Claude Code セッション管理ブログは「model performance degrades as context grows because attention gets spread across more tokens」と書いています（出典: claude.com/blog/using-claude-code-session-management-and-1m-context）。
1Mトークンの上限はあるが、
コンテキストが膨らむほど性能は劣化する。
2段プロンプトを使う前に1段目で長大な探索ログが溜まりすぎていると、
2段目のメリットが薄れる、
と読めます。
長すぎたら /clear、
というのが公式の含意です。
2段プロンプトを使うべきケースと避けるべきケース
使うべきケース。私は公式記述と一次ソースから次の3条件で整理しています。
- 1段目の出力が「動くが冗長／命名が雑／責務が曖昧」と感じた時
- 同じセッション内に要件・制約・エッジケースの理解が乗っている時（コンテキストの知識資産は活かしたい）
- 同じ問題でまだ1回目の修正、または0回（公式は2回以上の修正で /clear 推奨）
避けるべきケース。
- 同じ問題で2回以上修正済み（公式推奨：/clear して初期プロンプトから書き直す）
- 本番直前で破壊的変更が許容されない（公開APIは固定する3段目テンプレを使う）
- 1段目で長時間の探索が走り、コンテキストが既に膨大（先に /clear する判断）
Claude Code公式ドキュメントは「A clean session with a better prompt almost always outperforms a long session with accumulated corrections.」と明言しています（出典: code.claude.com/docs/en/best-practices）。
クリーンなセッション＋良いプロンプトは、
修正の積み重なった長セッションにほぼ常に勝つ、
と。
2段プロンプトはこの原則の中の一手であって、
上位原則は「適切なタイミングで切る」という話です。
FAQ
Q1. 「scrap this」と「delete your fix」はどちらを使えばいい？
Claude Code作成者の公式投稿で確認できる原文は「Knowing everything you know now, scrap this and implement the elegant solution」（2026年1月31日、
Threads/X）。
語感は同系統ですが、
引用根拠が固いのは「scrap this」側です。
「delete your fix」も流通していますが、
本記事では原文準拠で「scrap this」を主に扱っています。
Q2. 「リファクタして」と何が違う？
命令語の強度が違う、
というのが本質です。
「Refactor」は既存コードを前提とした手直し。
「Scrap/Delete」は既存コードの破棄＋再構築。
Claude Code公式ドキュメントが言う「自分が書いたコードへのバイアス」を切る効果は、
Delete系の語の方が出やすいと読める構造になっています（出典: code.claude.com/docs/en/best-practices）。
Q3. 2段目はセッションを分けたほうがいい？
分けない方が良いケースが多い、
というのが公式の含意です。
要件・エッジケース・依存関係の知識はセッションに乗せたまま、
「コードだけ破棄させる」のが2段プロンプトの設計思想。
別セッションでレビューさせる Writer/Reviewer パターンは公式ドキュメントに別途記載されており、
こちらは目的が違います（出典: code.claude.com/docs/en/best-practices）。
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.」と明記されています（出典: code.claude.com/docs/en/best-practices）。
3回目以降は /clear が公式推奨です。
Q5. トークン消費は気にしなくていい？
2段プロンプトは1段目より単純に多めに食います。
Claude Code公式の費用データは平均 $13/開発者/稼働日、
月 $150〜$250。
90%のユーザーは稼働日 $30未満（出典: code.claude.com/docs/en/costs）。
個人開発・小規模チームのProプラン（$20/月）範囲なら2段プロンプト多用でも費用感は問題になりにくいです。
agent teams使用時は標準の約7倍トークンと公式が明示しているので、
こちらは別の話です。
このページに出てきた言葉
- Claude Code
- Anthropic公式のagentic（エージェント型）コーディングツール。コードベースを読み、ファイル編集とコマンド実行までこなすCLIツール
- CLI
- コマンドラインインターフェース。文字コマンドでツールを操作する仕組み
- codebase
- プロジェクトのソースコード一式
- 2段プロンプト
- 1段目で実装させた直後、同セッション内で「破棄して再設計」と命じる2段階指示の型
- scrap this
- 「これを破棄せよ」の意味。Claude Code作成者の投稿に登場する原文表現
- アンカーバイアス
- 最初に提示された情報（錨）に判断が引きずられる現象。LLMでも93%の設問で確認されている（arXiv:2412.06593）
- fresh context
- 新しい会話文脈。Claude Code公式が「自分の書いたコードへのバイアスを切る」と説明する手段
- git diff
- コード変更差分を表示するgitコマンド。2段目の出力レビューで使う
- /clear
- Claude Codeのコマンド。会話履歴をリセットしてフレッシュコンテキストで再開する
- Writer/Reviewer パターン
- 別セッションで実装→レビューさせる公式推奨の型。2段プロンプトとは別手法
- コンテキストロット
- 会話文脈が膨らむほどモデル性能が落ちる現象。Claude Code公式ブログ記載
- トークン
- LLMが処理する文字列の単位。プロンプトと出力の合計で課金される
- agent teams
- Claude Codeの複数エージェント並列実行機能。標準の約7倍トークンを消費する
参考リンク
- 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作成者 Threads投稿（Tip 6b 一次ソース）: https://www.threads.com/@boris_cherny/post/DUMZxTWElFm
- Claude Code作成者 X投稿: https://x.com/bcherny/status/2017742741636321619
- arXiv論文（LLMアンカーバイアス）: https://arxiv.org/abs/2412.06593
※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。