メインのエージェントに実装を任せている最中、「あ、この関数の仕様どうなってたっけ」と横道に逸れて、結局スレッドがぐちゃぐちゃになる。これ、Cursor を使っている人なら一度はやった失敗だと思います。
2026年7月10日にリリースされた Cursor 3.11 で追加された Side Chats(サイドチャット) は、まさにこの問題への回答です。私も直後から1週間ほど使い倒してみて、想像以上に「本線を汚さない」効き方をしました。この記事では、有効化から実務での使いどころ、落とし穴までを手順として残しておきます。
結論:Side Chatsはメインチャットを止めずに調査できる分岐スレッド
先に結論から書きます。Side Chats は、走っているメインのエージェント会話を止めずに、横で別スレッドを開いて質問・調査・代替案検討ができる機能です。Anthropic 公式ではなく Cursor 公式のチェンジログによると、/side、/btw、またはチャットパネル上部の「+」ボタンから起動できます。
ポイントは3つ。
- 起動した Side Chat にはメインチャットのコンテキストが引き継がれる
- デフォルトでは読み取り・検索・回答に絞られる(=勝手にコードを書き換えない)
- 使い捨てではなく永続的なスレッドとして残り、後で at-mention で本線に引き戻せる
要するに、Git でいう「作業中に気になったことを別ブランチで確認して、必要ならマージする」感覚に近いです。私はこの比喩で腹落ちしました。
なぜSide Chatsが必要か:本線を汚す”横やり質問”の代償
従来の Cursor だと、エージェントが長いタスクを回している最中に「ちなみにこの型定義どこから来てる?」と割り込むと、
- エージェントの現在の思考が中断され
- 質問への回答で本題のコンテキストが薄まり
- 場合によっては勝手にファイルを触ってしまう
という事故が起きがちでした。特に Composer 2.5 のような長時間タスクに強いモデルで数十分回している時に、この中断コストは馬鹿にならない。
私は先月、Astro サイトのリファクタを Composer 2.5 に任せていたとき、途中で「ところで tailwind の設定は v4 系だっけ?」と聞いてしまい、エージェントがリファクタを一旦止めて設定を書き換え始めて肝を冷やしたことがありました。あれが Side Chats があれば防げていた事故です。
Cursor Side Chatsの使い方:3つの起動方法と基本操作
Cursor 3.11 以降にアップデート済みであれば、追加設定なしで使えます。まずは Cursor を最新版に上げてください。
3つの起動方法
公式チェンジログに載っている起動方法はこの3つです。
/sideコマンド:チャット入力欄で叩く。明示的に「今から横道に逸れる」宣言/btwコマンド:「by the way」の略。ちょっとした確認質問向け- チャットパネル上部の「+」ボタン:マウス派向けの選択肢
私はキーボードから手を離したくないので /btw を一番よく使っています。「btw なんでこの関数変えたの?」みたいに、そのまま質問文が続く形で自然に打てるからです。
コンテキストは自動で引き継がれる
ここが地味に重要なんですが、Side Chat にはメインチャットの文脈が最初から入っている。だから「今エージェントがやっている作業について」を前提に質問できます。ゼロから状況説明する必要がありません。
本線に戻すときは at-mention
Side Chat で得た結論をメインに戻したい時は、メインチャット側で Side Chat を at-mention で参照します。「@さっきのSide Chatの結論に従って進めて」という指示ができる。使い切りではなく、あくまで永続的なブランチとして残るのがミソです。
実務で効く3つの使いどころ
1週間試して、明確に効いたシーンを3つに絞ります。
1. 代替案の”下見”をしたいとき
公式ドキュメントでも触れられている典型例が、「pivot する前に代替案を検討する」ケースです。メインで React Query での実装を進めさせつつ、Side Chat で「SWR に切り替えたらこの実装どう変わる?」と聞く。答えを見て、乗り換えるほどではないと分かったら Side Chat を閉じて本線を続行。本線には一切傷がつきません。
2. 直近の変更の意図確認
エージェントが直近で変えた関数について、「なぜこう変えた?」と聞きたい場面。従来はメインで聞くとエージェントが「修正します!」と勘違いして手を出すことがありました。Side Chat はデフォルトで読み取り中心なので、この事故が構造的に起きにくい。私はここが一番助かっています。
3. 設計判断のセルフチェック
重めのアーキテクチャ判断を下す前に、Side Chat で「この設計、5年後の保守性で問題ある?」と一人壁打ちする用途。メインエージェントは実装を続けたまま、こちらは静かに設計レビューを受けられる。二画面開発の感覚に近いです。
Agents Windowのトランスクリプト検索も同時に強化された
3.11 のもう一つの目玉が、Agents Window でのエージェント会話ログの検索です。コマンドパレット(Cmd+K)からトランスクリプト全文を検索できるようになりました。
公式によると、Cursor がローカルに検索インデックスを構築するので、数千件規模の会話でも高速に引けるとのこと。私の手元では会話数が少なすぎて速度検証にならなかったんですが、少なくとも「あのバグ、先週どのチャットで直したっけ?」を PR 番号やチャット名に頼らず本文から探せるのは実務でかなり効きます。
Side Chats と組み合わせると、「本線を汚さず調査 → 永続化 → あとで検索して再利用」という一連の流れが成立する。これが 3.11 の本質だと私は理解しています。
使う前に知っておきたい3つの落とし穴
触ってみて気になった点も正直に書きます。
1. Side Chatも通常のクレジットを消費する
当然ですが、Side Chat も裏で普通にモデルを呼びます。「無料で気軽に聞ける横口」ではありません。Pro プラン($20)で回している人は、乱発するとメインのクレジットを圧迫します。目安として、私は1つのメインタスクにつき Side Chat は2〜3本までに抑えています。
2. デフォルトが”読み取り中心”であることに油断しない
公式が「デフォルトでは読み取り・検索・回答に絞られる」と書いている通り、あくまでデフォルトの話です。プロンプト次第で書き込み系のツールが動く余地はあるので、「Side Chat だから安全」と過信して雑な指示を投げるのは危険。私は Side Chat 用の .cursor/rules を1枚追加して、「file edit は明示指示があるまで禁止」と書いています。
3. コンテキストが引き継がれる=情報漏れの経路にもなる
メインチャットの内容が Side Chat に自動で流れます。Team プランで機密情報を扱っている場合、Side Chat を後から誰かに共有する運用にしていると、意図せず情報が広がる可能性がある。ここは組織のガバナンス設計とセットで考えたほうがいい部分です。
Composerタスクとの棲み分け:サブエージェントとどう違うか
「それってサブエージェントで良くない?」という質問をもらったので補足します。
サブエージェントはメインのタスクを分割して並列実行するための仕組み、Side Chats はメインのタスクを止めずに横で人間が別軸の会話をするための仕組みです。目的が違います。
- タスクを分割したい → サブエージェント /
/worktree - 人間側の疑問を解消したい → Side Chats
私の運用ルールでは、コードを書く必要があるならサブエージェント、書かないで済むならSide Chats、と使い分けています。
まとめ:今日から試す3つのアクション
Side Chats は派手な新機能ではありません。でも「本線を汚さない」というのは、長時間タスクを回すエージェント時代の開発体験を静かに底上げする変更だと感じました。
今日からできることを3つに絞ります。
- Cursor を 3.11 以降にアップデートし、
/btwを1回打ってみる - 次に長時間タスクを回すとき、割り込み質問はすべて Side Chat 経由にルール化する
- .cursor/rules に Side Chat 用のガードレール(書き込み禁止など)を1枚追加する
この3つを1週間続けるだけで、メインチャットが”雑談で汚れて回復不能”になる事故は激減するはずです。私の場合、Composer 2.5 の長時間セッションを再実行する回数が体感で減りました。
次に検討したいのは、Side Chats と Cursor Memories を組み合わせて、Side Chat で得た知見をプロジェクト知識として永続化する運用です。ここは別記事でまた検証したら書きます。
参考リンク
- Cursor Changelog(公式) — 3.11 Side Chats と検索の仕様
- Cursor 公式サイト — 3.11 リリース情報の掲載元
- Cursor Docs — Commands — スラッシュコマンドの公式ドキュメント