Claude Codeのセッションを分ける運用術:3つの粒度で使い分ける

Promotional hero banner with a bold Japanese headline about splitting sessions into three levels, four teal rounded topic pills (Claude Code, コンテキスト管理, 業務効率化, AI協働開発), and a teal triangular geometric background with the SIOS Tech Lab logo.

1つのセッションに何でも混ぜがち、な話

ども!Claude Code と毎日仕事している龍ちゃんです。

コード書いてる途中に「そういえばあの調査どうなったっけ」ってなって、同じセッションで聞いちゃう。気づいたら1本のセッションに、関係ない話が何本も混ざってる。正直、僕も今でもやりがちなんですよね〜。

これ、「詰め込みすぎると回答の質が落ちる」からやめた方がいいんですよ。容量がもったいないとかじゃなくて、”質”のために分けてる。本筋に関係ない文脈をメインのセッションに混ぜない、っていうのが基本の考え方です。

今回は /btw・subagent・別セッションを「どの粒度で切り出すか」で使い分ける話をします。分けたり、切ったり、ちょい聞きで逃がしたり、っていう”構え”の話ですね。コマンドの使い方は後半に出てくるんですが、先に「なぜ分けるのか」をおさえておくと、使い分けの判断がはっきりするんですよね。

じゃあ、なんで分けたほうがいいのか。まず前提の話からなんですが、コンテキストウィンドウが1Mになってから、僕、/compact をほぼ叩かなくなったんですよね。昔は膨らんでくると「そろそろ限界かな」って畳んで、また続けて…ってやってたんですが、1Mってちょっとやそっとじゃ全然埋まらないんですよ。容量を気にする時代、もう終わったかなって思ってます。

……で、ここなんですよ。区切られなくなったってことは、ほっとくと1本のセッションが延々と膨らみ続けるってことでもあるんですよね。で、体感的に「入れすぎると質が落ちる」っていうのがあって。情報を絞ると欲しい答えが爆速で帰ってきたりもするんですよ、逆に。

セッションに積むほど ▶▶▶

容量  ████████████████████  まだ全然いける(1M)
品質  ███████▓▓▒▒░░░░░░░░░░  ぼやけてくる

※あくまで体感のイメージ図です(測ったデータじゃないです)。ただ、コンテキストを積むほど精度や再現性が落ちていく現象自体は、公式ドキュメントでも“context rot” として説明されています。「容量はまだあるのに質は落ちる」って、僕の体感だけの話じゃないっぽいんですよね。(割と有名な話な気もしますね)

じゃあ「盛りすぎたな」ってどう気づくかなんですけど、会話が変なことを言い出すんですよ。もう一個は、変なものを作ってくる。この2つが来たら「あ、もう詰まってるな」っていうサインだと思ってます。

どう分けるか:「切り出す粒度」でコマンドと指示を変える

で、「分ける」と一口に言っても、粒度がいくつかあるんですよね。僕の中では、小さい順にこう並んでます。

/btw(一問)< subagent(一作業)< 別セッション(関連作業まるごと)

雰囲気で言うと、こんな差なんですよね。

  • /btw:「ちょっと聞かせて〜。答えてくれたら忘れてね〜」(聞いたら忘れる)
  • subagent:「これ読んで、これやっといて。終わったら報告ちょうだい!」(結果だけ返す)
  • セッション(普通のチャット):「これ見てこれやって。会話は覚えといてね。…長くなったら、なんとなく忘れちゃうかも〜」(覚えてる、けど長いと薄れる)

この地図を持っておくと判断が楽になります。1つずついきます。

/btw:逸れた”一問”を、残さず聞く

一番小さい粒度。/btw <question> は、会話に残らない”ちょい聞き”ができる組み込みコマンドです。いまの会話の文脈は全部見えてるんだけど、その質問と答えはメインの履歴に残らない。聞きたいことだけ聞いて、本筋はそのまま、というわけですね。

僕がよく使うのは、こんな質問です。

  • セッション中に出てきた知らない単語の意味を聞く
  • 今どういう状態だっけ」っていう現状確認・理解のための質問

どっちも共通してるのは、「その場で分かりたいだけで、後で要らない」ってこと。普通に聞いちゃうと、本筋の会話に確認のやり取りが挟まって文脈が薄まる。/btw ならそれを汚さずに済む。

By Tha Wayって直感的でいいコマンドですね!(^^)!

subagent:単発の”一作業”を投げる

/btw の一個上の粒度が subagent です。なんで /btw の隣に置くかというと、この2つ、ちょうど対になってるんですよ。/btw はツールなし・文脈フル、subagent はツールあり・文脈は空っぽ。この「文脈が空っぽ」ってのは、いまのメインの会話を何にも引き継がないで、まっさらな状態で立ち上がるってことなんですよね。で、ここがミソなんですけど、空っぽだからこそ、こっちが渡したい文脈だけを選んで持たせられる。「これとこれだけ読んで、これやっといて」って、必要なぶんだけ渡すイメージですね。つまり「この会話で既に分かってることを、汚さず聞く」のが /btw、「渡したいぶんだけ持たせて、新しいことを調べに行かせる」のが subagent ですね。僕はこの2つを「逆向きの兄弟」みたいに捉えてて、これ覚えとくと迷わなくなると思います。

考え方としては「別セッションに分ける」のともかなり近い。文脈を渡して別の場所で作業させる、という点では同じなんですよね。違いは粒度で、subagent は一つの作業を投げて、結果を受け取るイメージです。だから粒度の地図だと、ちょうど /btw(一問)と別セッション(まるごと)の真ん中に座る、という感じですね。

あと品質の話もあって。限定された文脈で作られた成果物ってクリーンなんですよ。余分な文脈が入ってないぶん、余計な影響を受けずに仕上がってくる感覚です。

別セッション:関連作業を”まるごと”引越す

そして一番大きい粒度が、別セッションです。subagent が「点」で一作業を投げるのだとしたら、別セッションは「面」。関連する一連の作業をぜんぶそっちに引越して、自分が腰を据えてやる感じですね。

僕が別セッションを立てるのは、だいたいこんなときです。

  • 応答が遅くなってきた:長くなりすぎたセッションは返信に時間がかかるので、そろそろ引越すか、と
  • 忘れないように切り出す:作業中に割り込んできた別件を、本筋に混ぜず別セッションに逃がす
  • 先にこれだけ進めたい:ここまでの内容を別の作業として切り出して、優先で片付けたいとき

で、別セッションに引越すときに大事なのが、丸投げじゃなく”お引越しプロンプト”を持たせてあげることなんですよ。引越し先のセッションは、こっちの文脈をなんにも知らない。だから「いま何をやってて、次に何をしてほしいか」をちゃんと書いて渡す。「何を引き継ぐか」を決める作業こそ、”分ける”の本体なのかなって思ってます。

ここで /clear を使うのがポイントで。前の文脈を持ったまま引き継ぎ文を書けるので、ちゃんと残せてるか確認して、納得いくまで練り直せるんですよ。/compact のほうは会話履歴を要約に置き換える動きなので、畳んだ後だと元の詳細はもう手元になくて、そこの確認がしづらいんですよね。

僕はこのお引越しプロンプトを、考え方で2種類用意してます。

  • 継続用(next)
    同じトピックをそのまま続けるための引き継ぎ。作業の温度を冷まさないように、途中経過とか決まったこと、残タスクまで、なるべくそのまま持っていく感じ。
  • 切替え用(new)
    別のタスクに頭を切り替えるための引き継ぎ。逆に、ここまでの細かい経緯はいったん捨てて、次にやることに本当に要るものだけ選び直して渡す。(途中で本筋と同時並行でできるけどコンテキストを分けたいときにも!)

「このまま続きをやるのか」「別件に移るのか」で、”何を残して何を捨てるか”がちょうど逆になるんですよね。だから最初から2つに分けてます。

お引越しプロンプトができたら、あとは新しいセッションに持っていくだけ。ここで地味に効くのが `/copy` です。直前の応答をそのままコピーして、新しいセッションに貼る。それだけ。以前はこういうの xclip を手で叩いてやってたんですが、もうこれで済みます。渡したい粒度に合わせて、応答の一部だけ選んだり、ファイルに書き出したりもできます。

compactでよくない?確かにいいけど切るほうが個人的に良い

ここまで「分ける」話をしてきましたが、1本のセッションが重くなってきたとき、やり方は2つ。

  • 切って新しく始める/clear
  • 畳んで同じセッションで続ける/compact

「重くなってきたら /compact で畳めばいいじゃん」って思う人、多いと思います。でも僕の基本方針は、切る派です。重くなる前に /clear をこまめに連発して、どんどん新しいセッションに移る。/compact が必要になるまで粘らない。

なんでかというと、そもそも /compact してまで1本で続けたい「超絶長いタスク」って、そんなにあります?ってことなんですよね。タスクを「終わる分量」で切っていれば(この話も別記事で git log を例に書いてます)、1個終わったら /clear して次にいけばいい。延命する理由がないんです。長く粘ったセッションほど文脈が盛られてさっきのサインが出てくる、というのとも地続きで、僕の中では「重くなったら畳む」より「終わったら切る」が先に来ます。

とはいえ /compact を全否定したいわけじゃなくて。どうしても途中で切れない長いタスクには、ちゃんと効きます。そのときは /compact のうしろに「何を重点的に残すか」を書けば、その方向で要約して畳んでくれる。僕の出番は正直少ないですが、”切れない長丁場”のときの逃げ道として知っておくと安心です。

おわりに

結局「セッションを分ける」って、新しい道具を覚える話じゃなくて、積み方の癖の話なんですよね。1M入るようになっても、いや、入るようになったからこそ、「これ、メインに残す意味ある?」って一回立ち止まる。残さなくていいものは残さない。終わったタスクは、粘らず切る。たったこれだけで、返ってくる答えの精度は地味に変わる気がします。

「あ、これメインに残さなくていいやつだ」と思った質問から /btw で逃がしてみてください。

ほなまた〜

ご覧いただきありがとうございます! この投稿はお役に立ちましたか?

役に立った 役に立たなかった

0人がこの投稿は役に立ったと言っています。
エンジニア募集中!

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です