この記事の要点
- 会話が長くなると、過去の案や関係のない情報まで文脈に混ざり、回答がズレやすくなります。
- 作業の目的やテーマが変わった時は、同じ会話を使い続けず、新しい会話へ切り替えるのが基本です。
- 会話を区切る前に、決まったことと次に必要な前提だけをまとめておくと、スムーズに引き継げます。
どうも岩崎です。
今日は、AIとの会話を長引かせすぎない方がいいですよーって話です。
AIを使っていると、同じ会話をそのまま使い続けたくなりますよね。
前の話を覚えているし、また最初から説明し直すのも面倒です。
なので、ブログ記事を1本作ったあと、そのまま次の記事を頼む。
途中でメールの返信文も作ってもらう。
さらに別の商品の相談をして、最後に元の記事へ戻る。
こんな使い方になりやすいと思うんですね。
でも、これを続けていると、だんだん話が噛み合わなくなることがあります。
さっきまでの記事の言い回しを引きずったり、もう使わないと決めた案を再び持ち出したり、別の仕事の前提を混ぜてしまったりするんです。
AIが急に賢くなくなったというより、渡されている情報が増えすぎて、何を一番重視すればいいのかがわかりにくくなっているんですね。
人間でも同じです。
一度の打ち合わせで、広告、経理、撮影、採用、来月の予定まで全部話したら、最後には「結局、今日は何を決める会議だったんだっけ?」となりますよね。
AIとの会話も、情報をたくさん渡せば渡すほど良いわけではありません。
必要な情報が揃っていることと、関係のない情報まで大量に入っていることは、まったく別の話です。
なので私は、会話を続けることよりも、目的ごとに区切ることを意識しています。
今回は、なぜ長い会話ほどズレやすくなるのか、どのタイミングで区切ればいいのか、そして必要な情報だけを次の会話へ持ち越す方法について話します。
AIは会話の内容を文脈として使っています
まず前提として、AIは今の質問だけを見て答えているわけではありません。
同じ会話の中にある、これまでの質問や回答も文脈として使っています。
この、AIが一度に参照できる情報の範囲を、コンテキストウィンドウと呼びます。
難しい名前ですが、簡単に言えば、AIが机の上に広げて確認できる資料の量です。
会話を始めたばかりなら、机の上には今回の依頼に必要な資料しかありません。
ところが、会話を長く続けると、過去の記事、途中で出した案、修正前の文章、関係のない質問まで、机の上に積み上がっていきます。
資料が増えれば、参考になる情報も増えます。
でも同時に、今は使わない情報も増えます。
すると、AIが古い指示を拾ったり、今回とは関係のない前提を使ったりする可能性が高くなるんですね。
なので、会話が長いこと自体が悪いわけではありません。
同じ目的に向かって必要な情報を積み上げているなら、長い会話が役立つ場合もあります。
問題は、目的の違う話や、もう使わない情報まで、同じ会話に残り続けることです。
長い会話ほど利用枠も減りやすくなる
会話が長くなる問題は、答えがズレやすくなることだけではありません。
Claude Codeでは、質問をするたびに、その会話で必要な文脈も一緒に処理されます。
そのため、同じ一行の質問でも、始めたばかりの会話と、何時間も続けた会話では、扱う情報量が違います。
会話が長いほど、過去の履歴を含めて処理する情報量が増えやすくなり、その分、利用枠も減りやすくなります。
つまり、同じ会話を延々と続けることは、精度の面だけでなく、利用枠の面でも効率が悪くなりやすいんですね。
前回、単純作業は軽いモデルへ任せるという話をしました。
それと同じで、必要のない文脈を毎回持ち歩かないことも、利用枠を整理するうえで大事です。
話題ではなく、目的が変わったら区切る
では、どのタイミングで会話を区切ればいいのか。
一番わかりやすい目安は、作業の目的が変わった時です。
たとえば、ブログ記事の構成を考え、そのまま本文を書き、最後にタイトルを調整する。
これは、ひとつの記事を完成させるという同じ目的なので、そのまま続けても問題ありません。
でも、記事が完成したあとに、別の商品について調べ始めるなら、目的が変わっています。
この時は、新しい会話へ切り替えた方がいいです。
同じブログ制作でも、黒にんにくの記事と、Claude Codeの記事では、読者も前提も使う言葉も違います。
さらに、記事を書いていた会話で、急に撮影の見積もりやメール返信まで頼むと、文章の目的そのものが変わります。
なので、「話題が少し変わったか」よりも、「最終的に何を作ろうとしているかが変わったか」で判断するとわかりやすいです。
こんな状態になったら区切りどき
目的が変わっていなくても、途中で区切った方がいい場合があります。
たとえば、次のような状態です。
- すでに却下した案を何度も出してくる
- 前の記事の言い回しを引きずっている
- 別の案件の前提が混ざっている
- 同じ修正を何度伝えても直らない
- 質問に対して、少しずれた回答が続く
- 何のための作業なのか説明し直すことが増えた
こうなった時に、さらに説明を足し続けると、会話はもっと複雑になります。
間違った方向へ進んでいる地図に、注意書きをどんどん足しているような状態です。
それよりも、一度必要な情報を整理して、新しい会話から始めた方が早いことが多いです。
同じ修正を3回目に伝えようとした時は、区切りどきだと思ってもいいかもしれません。
区切る前に、引き継ぎメモを作る
ただ、新しい会話へ移るたびに、すべてを最初から説明するのは面倒ですよね。
そこで、会話を区切る前に、次の会話へ必要な情報だけをまとめてもらいます。
私は、次のように頼みます。
新しい会話へ移るので、ここまでに決まった内容を引き継ぎ用にまとめてください。
次の会話に必要な情報だけを残し、途中で却下した案や、すでに解決した話は含めないでください。
目的、決定事項、守るルール、未解決の課題、次にやることに分けてください。
この形でまとめてもらえば、次の会話の最初に貼り付けるだけで再開できます。
大事なのは、会話を全部要約してもらうことではありません。
全部を持ち越したら、不要な情報まで再び新しい会話へ入ってしまいます。
次の作業に必要なものだけを残す。
人間の引き継ぎでも、何日分もの会話をそのまま渡すより、「決まったこと」「確認待ち」「次にすること」を整理して渡した方がわかりやすいですよね。
AIへの引き継ぎも同じです。
完全に切り替えるなら「/clear」
Claude Codeで、今の会話を完全に区切って新しい会話を始める場合は、次のコマンドを使えます。
/clear
/clearを実行すると、新しいセッションとして始められます。
前の会話を引き継ぐ必要がない場合は、この方法が一番すっきりします。
たとえば、ひとつの記事が完成して、次はまったく別の記事を書く。
調査が終わり、次は別の案件に移る。
こういう場合は、古い会話を要約して残すより、新しく始めた方が早いです。
前回紹介したCLAUDE.mdに共通ルールを書いておけば、新しい会話を始めても、毎回の基本ルールは読み込まれます。
だから、会話を区切ることをそれほど怖がる必要はありません。
流れを残したいなら「/compact」
一方で、同じ作業を続けたいけれど、会話が長くなりすぎた場合もあります。
その場合は、会話を要約して文脈を圧縮する方法があります。
/compact
/compactを使うと、これまでの会話を短くまとめ、必要な流れを残したまま続けられます。
ただし、要約する時にも処理は発生します。
まったく別の仕事へ移るなら、無理に圧縮して残すより、/clearで新しく始めた方がシンプルです。
/compactは、同じ仕事を続けたい時。
/clearは、仕事そのものが変わる時。
このように使い分けるとわかりやすいと思います。
途中までの会話だけを整理する方法もある
Claude Codeには、会話を途中の地点まで戻したり、一部だけ要約したりする機能もあります。
/rewindを実行するか、入力欄が空の状態でEscキーを2回押すと、会話の履歴を選べます。
そこから、特定の地点まで会話を戻したり、その地点より前だけを要約したりできます。
たとえば、途中までは順調だったのに、別の案を試し始めてから話が崩れた場合です。
その時は、会話全体を捨てるのではなく、ズレる前の地点まで戻した方が効率的です。
写真の現像でも、調整を重ねすぎて不自然になった時に、元のデータから全部やり直すのではなく、良かった段階まで戻すことがあります。
会話も同じで、すべて捨てるか、そのまま続けるかの二択ではありません。
CLAUDE.mdとプロンプトの型があると区切りやすい
会話を区切れない大きな理由は、また説明し直すのが面倒だからだと思います。
でも、共通ルールをCLAUDE.mdへ書き、仕事別の指示をプロンプトの型として保存しておけば、その手間はかなり減ります。
たとえば、ブログ記事を新しい会話で作る時は、CLAUDE.mdから文章の共通ルールが読み込まれます。
そこへ、ブログ用のプロンプトの型を使って、今回のテーマ、読者、目的だけを入れます。
前の会話を丸ごと残しておかなくても、必要な前提は再現できるんですね。
会話履歴そのものを記憶として使うのではなく、必要なルールと型を外に出しておく。
この状態を作ると、会話をこまめに区切りやすくなります。
実際にやってみて
私も以前は、ひとつの会話でブログ記事を何本も作り続けていました。
前の記事の口調や構成を覚えているので、その方が効率が良いと思っていたんですね。
でも、何本も続けていると、後半になるほど前の記事の言い回しを引きずるようになりました。
別の記事で使った具体例が混ざったり、すでに直したはずの表現が戻ったりすることもありました。
そのたびに追加で修正を伝えるので、さらに会話が長くなります。
こちらとしては修正しているつもりなんですが、結果として新しい指示がどんどん積み重なり、さらに複雑にしていたわけです。
今は、ひとつの記事が完成したら、基本的にはそこで区切るようにしています。
続きものの記事なら、決まった方針だけを引き継ぎメモにまとめ、新しい会話へ移します。
共通する文章のルールはCLAUDE.mdに入れ、記事の構成はプロンプトの型に入れています。
なので、新しい会話を始めても、一から全部説明する必要はありません。
この形にしてから、前の記事を引きずることが減り、記事ごとの内容も安定しやすくなりました。
AIとの会話が噛み合わなくなった時に、さらに説明を足して粘る必要はありません。
一度立ち止まって、今の目的に必要な情報だけを整理する。
そして、必要なら新しい会話から始める。
会話を続けることよりも、AIが判断しやすい前提を作ることの方が大事なんですね。
最近、AIとのやり取りが少し噛み合わないなと感じているなら、一度会話を区切ってみてください。
それでは!
よくある質問
-
会話を区切るタイミングがわかりません。目安はありますか?
-
作業の目的が変わった時が、一番わかりやすい目安です。また、却下した案を繰り返し出す、別の案件の前提が混ざる、同じ修正を何度も伝えているといった状態も、会話を区切る合図です。
-
毎回区切ると、情報を伝え直すのが面倒ではありませんか?
-
共通ルールをCLAUDE.mdへ書き、仕事別の指示をプロンプトの型として保存しておけば、伝え直す内容は減らせます。前の会話からは、決定事項、未解決の課題、次にやることだけを引き継ぐとスムーズです。
-
/clearと/compactはどう使い分ければいいですか? -
別の仕事へ移る場合や、前の文脈が不要な場合は
/clearを使います。同じ仕事を続けたいけれど、会話が長くなりすぎた場合は/compactで要約して続けます。必要な流れを残したいかどうかで判断するとわかりやすいです。
P.S.
写真の現場でも、ひとつのカットにこだわりすぎると、だんだん何が良いのかわからなくなることがあります。そんな時は、一度そのカットを終わらせて、別の角度から撮り直します。AIとの会話も、粘ることより、良い区切りを作ることの方が大事なのかもしれません。
