Multi-turn Conversation（マルチターン・カンバセーション）

Claude Codeに一発で完璧な指示を出そうとして空回りしている人向け

Claude Codeに最初の一発で完璧な指示を書こうとして、何分も指示文を練り直した経験はないでしょうか。「あれもこれも漏れなく書かなきゃ」と長い指示を組み立てて投げる。でも返ってきたコードはどこか的外れで、結局やり直し。これは指示の書き方が下手なのではなく、そもそも一発勝負を狙っているのが原因です。

Multi-turn Conversation は、Claude Codeとのやり取りを「一発で当てるクイズ」ではなく「何往復もして詰めていく相談」として扱う考え方です。Anthropic公式の best-practices ガイドは、この前提を一言で書いています。

Conversations are persistent and reversible. Use this to your advantage!

訳すと「会話は保存され、巻き戻せる。これを武器にしよう」。

つまり、間違えても戻せる。だから一発で決める必要はない。

そもそも「一発で完璧」を狙うと何が起きるのか

料理ブログを作っていて「レシピのお気に入り機能を作って」と頼むとします。一発で完璧を狙う人は、ここで保存先・表示方法・ログイン連携・例外処理まで全部1つの指示文に詰め込もうとします。

でも頭の中で全部の難所を先に洗い出すのは、まず無理です。

結果、書き漏らした部分をClaudeが勝手に補完して、自分のイメージと違うコードが出てくる。そこから長い会話で何度も直すうち、やり取りの記録（＝Claudeが覚えている文脈）が失敗した試行錯誤でゴチャゴチャになり、Claudeの精度自体が落ちていきます。

Multi-turn の発想は逆です。最初は雑でいい。投げて、反応を見て、ズレたら早めに直す。この往復のほうが、長い指示文を1回投げるより速くて正確、というのが公式の立場です。

噛み砕くと

新しい家を建てるとき、設計士に「いい感じの家を建てて」と1回言って図面が完璧に上がってくることはないですよね。普通は「リビングは広めで」「キッチンは対面式で」「あ、収納も足したい」と何度も打ち合わせをして、図面を描き直しながら詰めていきます。

Multi-turn Conversation はまさにこの打ち合わせです。Claude Codeを「一発で正解を出す自動販売機」ではなく「何度も相談できる担当者」として扱う。

しかもこの担当者には特殊能力があって、打ち合わせの途中で「やっぱりさっきの話、なかったことに」と言えば本当に巻き戻せます。家づくりではできない芸当です。だから安心して試して、ダメなら戻せばいい。

「料理ブログにお気に入り機能を追加」を例に、実際の往復を見る

料理レシピ投稿サイトに「レシピをお気に入り登録する機能」を足す場面で、Multi-turn のやり方を順に追います。一発で長文を投げるのではなく、短く投げて反応で詰めていきます。

ステップ1: いきなり実装させず、Claudeに面接させる

公式が大きめの機能で勧めているのが「まずClaudeに自分を面接させる」やり方です。最小限の指示だけ投げて、あとは AskUserQuestion という質問機能を使ってClaude側から質問を浴びせてもらう。

公式のプロンプト例はこれです。

I want to build [brief description]. Interview me in detail using the AskUserQuestion tool.

Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Don't ask obvious questions, dig into the hard parts I might not have considered.

Keep interviewing until we've covered everything, then write a complete spec to SPEC.md.

料理ブログの題材に置き換えると、こう打ちます。

料理ブログにレシピのお気に入り機能を作りたい。AskUserQuestion を使って詳しく面接して。
技術的な作り・見た目と操作感・例外パターン・気になる点・トレードオフを聞いて。
当たり前すぎる質問は飛ばして、私が見落としてそうな難所を掘って。
全部出そろったら SPEC.md に仕様をまとめて書いて。

するとClaudeは「お気に入りはログインユーザーごとに保存する？ それとも端末に保存？」「お気に入り一覧は専用ページ？ レシピ一覧に星マークを出すだけ？」みたいに、自分では考えてなかった所を突いてきます。公式の言葉を借りると、技術的な作り・見た目と操作感・例外パターン・トレードオフを聞いてくる、という設計です。

ステップ2: 面接が終わったら、新しい会話で実装に入る

面接で全部詰まって SPEC.md に仕様が書けたら、いったんその会話は閉じます。そして新しい会話を開いて、そこで実装をお願いする。

なぜ会話を分けるのか。面接の会話には質問と回答のやり取りが大量に積もっていて、Claudeが覚えている範囲がそれで埋まっています。新しい会話に切り替えれば、頭の中が実装だけに集中したまっさらな状態になる。しかも手元には詰めた仕様書が残っている。これが公式の勧める流れです。

ステップ3: 脱線したら Esc で止める

実装中、Claudeが頼んでないファイルまで書き換え始めたり、明らかに方向がズレたりすることがあります。そのときは Esc キーを押す。動作の途中でClaudeを止められます。

大事なのは、Esc で止めても会話の記録は消えないこと。公式いわく「Context is preserved, so you can redirect」。止めても文脈は保たれるので、軌道を変えられるという意味です。止めてから「いや、星マークだけでいい。専用ページは要らない」と言い直せば、そのまま続きをやってくれます。

ステップ4: もう戻したいときは「さっきの取り消して」か Esc 2回

「さっき書き換えたやつ、丸ごと無かったことにしたい」というときは2つの手があります。1つは日本語でそのまま「さっきの変更を取り消して」と頼む。Claudeが自分で元に戻します。

もう1つが Esc を2回連打、または /rewind と打つこと。巻き戻しメニューが開いて、前の会話の状態とコードの状態を、好きな地点まで戻せます。

ここで初心者がやりがちな勘違いを1つ。この巻き戻しは「Claudeがやった変更」だけが対象です。手動で書き換えた所や別のアプリでいじった所は戻りません。バックアップの代わりにはならない、と公式も釘を刺しています。

ステップ5: 同じ所で2回直したら、潔く /clear する

「お気に入りの星マークの色がおかしい」を直させたのに、また違う色になる。もう一度直させても、まだ変。こういう「同じ問題で3回目」になったら、もう会話を続けないほうがいいです。

公式の助言がはっきりしています。

If you've corrected Claude more than twice on the same issue in one session, the context is cluttered with failed approaches.

同じ問題で2回より多く直したなら、覚えている範囲は失敗した試みで散らかっている、という意味です。

このときは /clear と打って会話の記録をまっさらに戻し、いま学んだことを盛り込んだ具体的な指示で仕切り直す。たとえば「星マークの色は #ff7043 固定。CSS変数は使わず直接指定して」のように、失敗から分かった条件を最初から書く。

公式は「きれいな会話に良い指示のほうが、直しを積み重ねた長い会話にほぼ必ず勝つ」と言い切っています。長く粘るより、早めにリセット。

ステップ6: 分からない部分はシニアエンジニアに聞くノリで質問する

実装の途中で「そもそもこのサイト、ログインってどう処理してるんだっけ」と分からなくなることがあります。Multi-turn のいいところは、こういう疑問もその場で聞ける点です。

公式の言葉では「Ask Claude questions you'd ask a senior engineer」。先輩エンジニアに聞くような質問を、そのままClaudeにぶつけろという意味です。特別な聞き方は不要で、直接こう打てばいい。

このサイトのログイン処理ってどう動いてる？
新しいAPIの作り口はどうやって増やす？
この保存処理の133行目、await はなぜここについてるの？
お気に入り削除に removeFavorite() と deleteFavorite() が両方あるけど、どっちを使えばいい？
お気に入り保存まわりで、どんな例外パターンを想定しておくべき？

公式が挙げている質問例の1つはこれです（原文）。

What edge cases does CustomerOnboardingFlowImpl handle?

「この処理はどんな例外パターンを想定している？」と、コードの一部分を名指しで聞いている例です。

新しいコードを読み解くとき、人間の先輩に聞く代わりにClaudeに聞く。これも立派な multi-turn の使い方です。

つまり Multi-turn Conversation は何をしてくれるのか

• やってくれる: 雑な最初の指示から会話で詰めていく進め方を後押しする。止める・戻す・面接させる・質問する、の往復で精度を上げられる
• やってくれない: 巻き戻しは魔法のバックアップではない。手動の変更や別アプリでの変更は戻せないので、本当の保存はGitなど別の手段が必要
• 意味が薄い場面: 誤字直し1個・ログ1行追加のような一瞬で終わる作業。往復するまでもなく、最初の1回で済む小さな修正には大げさ

使いどころ3シナリオ（料理ブログで再現）

シナリオ1: お気に入り機能を追加したいが、仕様が頭の中で固まっていないとき

「お気に入り機能を作りたい。でも保存方法も一覧の見せ方も決めきれてない」。この状態でいきなり実装を頼むと、Claudeが勝手に決めた仕様で動くものが出てきて、後で総入れ替えになりがちです。

ここで面接プロンプトを投げる。Claudeが「端末保存かアカウント保存か」「一覧は専用ページか星マークか」を次々聞いてくるので、答えながら自分の頭も整理されます。30個くらい質問に答えると、自分でも気づいてなかった抜けが埋まり、SPEC.md に仕様が1枚でまとまる。実装はそのあと新しい会話で。

シナリオ2: 実装中にClaudeが暴走して、関係ないファイルまで触り始めたとき

星マークのCSSだけ直してほしいのに、Claudeがレシピ表示の本体まで書き換え始めた。よくある光景です。

すかさず Esc で止める。会話の記録は残ったままなので「CSSだけでいい。レシピ表示は触らないで」と言い直せば軌道修正できます。もう書き換えられた後なら「さっきの変更を取り消して」か /rewind で巻き戻す。暴走を1回ごとに小さく潰せるのが multi-turn の強みです。

シナリオ3: 同じバグを2回直してもらってもまだ直らないとき

「お気に入りを連打すると同じレシピが2回登録される」というバグ。1回直させても再発、もう一度直させてもまだ再発。3回目に突入しそうなら、もう会話を続けないほうが速いです。

/clear で会話をリセットして、学んだことを全部盛り込んだ指示で仕切り直す。「お気に入り登録の前に、すでに登録済みかどうかを必ずチェックする。重複時は何もしない。連打対策にボタンを押した直後は無効化して」のように、失敗から分かった条件を最初から渡す。きれいな会話＋具体的な指示のほうが、散らかった会話で粘るより結局は速い。これが公式の結論です。

初心者が踏みやすい落とし穴

• 最初の指示を完璧に書こうとして時間を溶かす。頭の中で全部の難所を洗い出すのは無理。雑に投げて反応で詰めるほうが速い、が multi-turn の前提です。
• ズレに気づいても止めずに見続ける。公式Tipは「Correct Claude as soon as you notice it going off track（脱線に気づいたらすぐ直せ）」。早く止めるほど後の手戻りが減ります。
• 同じ問題を3回も4回も会話で直し続ける。直しが積もるほど会話の記録が失敗例で散らかり、Claudeの精度が落ちます。2回直してダメなら /clear へ。
• 巻き戻しをバックアップ代わりに使う。戻せるのはClaudeがやった変更だけ。手動の変更や別アプリの変更は戻りません。本当の保存はGitなど別手段で。
• 面接させずに大きな機能をいきなり実装させる。仕様が固まってない機能こそ、先にClaudeに面接させて SPEC.md に落とすと手戻りが激減します。
• 面接の会話のまま実装に突入する。質問のやり取りで覚えている範囲が埋まっているので、実装は新しい会話で。頭をまっさらにしてから動かすのが公式の勧めです。
• 分からないコードを自分で抱え込む。「このログイン処理どう動いてる？」と先輩に聞くノリで直接質問していい。特別な聞き方は要りません。

書き方

（コマンドではなく考え方。会話で使う合図の例）
Esc          ← 動作の途中で止める
Esc を2回    ← 巻き戻しメニューを開く
さっきの取り消して  ← 直前の変更を元に戻す
/clear       ← 会話の記録をまっさらに戻す

やってみるとこうなる

入力

料理ブログにレシピのお気に入り機能を作りたい。AskUserQuestion を使って詳しく面接して。技術的な作り・見た目と操作感・例外パターン・気になる点・トレードオフを聞いて。当たり前すぎる質問は飛ばして、私が見落としてそうな難所を掘って。全部出そろったら SPEC.md に仕様をまとめて書いて。

出力例

Claudeが「お気に入りはログインユーザーごとに保存しますか、それとも端末に保存しますか」「一覧は専用ページにしますか、それともレシピ一覧に星マークを出すだけにしますか」のように、自分では考えていなかった点を次々と質問してくる。答え終わると詰めた内容が SPEC.md に1枚の仕様として書き出され、その仕様を持って新しい会話で実装に入れる。

関連項目

• Effective Prompting（エフェクティブ・プロンプティング）
• Pipe Input（パイプ・インプット）
• Explore → Plan → Implement（エクスプロア・プラン・インプリメント）
• Context Window（コンテキストウィンドウ）
• /rewind（リワインド）

公式ドキュメント

https://code.claude.com/docs/en/best-practices