長いリファクタリングをエージェントに任せている最中に、ふと別の疑問が湧くことがあります。「このエラーメッセージは何を意味しているのだろう」「このライブラリの最新版は何だったか」。個人開発で複数のプロジェクトを掛け持ちしていると、こうした脇道の質問は一日に何度も湧いてきます。私自身、つい同じ会話にそのまま打ち込んでしまい、メインの作業を進めていたエージェントが急に脱線して、それまで積み上げてきた文脈が薄まってしまう、という失敗を何度も繰り返してきました。
Antigravity 2.1.4（6/11 リリース）で追加された /btw スラッシュコマンドは、この「ついでの質問」問題に正面から効きます。会話の途中で投げた脇質問を、本筋のエージェントではなく使い捨てのサブエージェントに渡してくれる仕組みです。今回はこの機能を実際の運用に組み込んでみて気づいたことを整理します。
なぜ脇質問でメインの精度が落ちるのか
エージェントの応答品質は、その会話に積み上がった文脈に強く依存します。リファクタリングのような長いタスクでは、エージェントは対象ファイルの構造、過去の変更履歴、あなたが途中で出した方針修正などを文脈として保持しながら作業を進めています。
ここに無関係な質問を割り込ませると、二つの問題が起きます。一つは注意の分散です。直前の数ターンが脇道の話題で埋まると、エージェントは次のステップで「本来やっていた作業」より「直前に聞かれたこと」に引っ張られやすくなります。もう一つは文脈の希釈で、限られたウィンドウに本筋と無関係なやり取りが混ざるほど、肝心の作業情報の密度が下がります。大規模コードベースでこの影響が顕著になる理由は、Antigravity の Context Window 管理術 でも触れたとおりです。
これまでの回避策は「新しいタブを開いて別セッションで聞く」でした。確実ではありますが、タブの切り替えと新セッションの立ち上げが地味に手間で、結局その場の会話に打ち込んでしまう、という横着が起きがちでした。/btw は、その横着を安全な形に変えてくれます。
/btw が実際に何をするか
会話入力欄に /btw と打ってから質問を続けると、その質問はメインエージェントの履歴には残らず、独立した使い捨てサブエージェントに送られます。サブエージェントは単独で回答を返し、その役目を終えると破棄されます。メインの会話には脇質問のやり取りそのものが積み上がらないため、本筋の文脈は保たれたままです。
# メインエージェントにリファクタリングを任せている最中
/btw この TypeError: Cannot read properties of undefined はどういう状況で出る?
ポイントは、回答を受け取った後にメインのエージェントへ戻ったとき、メインはこの脇質問のことを「知らない」状態だということです。つまり脇質問の答えを本筋の作業に反映させたい場合は、得られた知見を自分の言葉でメインエージェントに明示的に伝え直す必要があります。これは欠点ではなく、むしろ意図された分離だと考えています。何を本筋に持ち込むかを自分で選別できるからです。
使いどころと、使わない方がよい場面
実際に数日使ってみて、/btw が向く質問と向かない質問がはっきり分かれました。
向いているのは、回答が一回で完結し、メインの作業に直接は影響しない調べものです。エラーメッセージの一般的な意味、コマンドのオプション、用語の確認、ライブラリの概要といった「知りたいだけ」の質問は、使い捨てサブエージェントで十分です。私はこれを「メモを取りに行く」感覚で使っています。
逆に向かないのは、その答えがメインの作業方針を左右する質問です。たとえば「いま直しているこの関数、設計ごと見直すべきか」のような問いは、メインエージェントが保持している文脈（なぜこの設計になっているか、どこを直してきたか）があってこそ意味のある答えが返ります。これを文脈ゼロの使い捨てサブエージェントに投げると、一般論しか返ってこず、かえって判断を誤ります。こうした問いは本筋の会話で聞くべきです。
判断の目安として、私は「この答えをメインに知っていてほしいか？」を自問するようにしています。知っていてほしいなら本筋で、知らなくていいなら /btw で、という単純な線引きです。
並列エージェントとの使い分け
Antigravity 2.0 以降は複数エージェントの並列実行も使えますが、/btw はそれとは目的が違います。並列エージェントは「独立した複数の作業を同時に進める」ためのもので、それぞれが自分の文脈を持って継続的に動きます。一方 /btw は「いま動いている一つの作業の流れを止めずに、一回限りの脇道に逃がす」ための軽量な仕組みです。
クォータの観点でも差があります。常駐する並列エージェントを増やすと利用枠の消費設計を意識する必要が出てきますが（この点は Antigravity 2.0 の並列エージェントでクォータを使い切らない予算設計 にまとめました）、/btw は単発で完結するため、運用の重さがまったく違います。「常に走らせておきたい作業」は並列エージェント、「一瞬だけ別のことを聞きたい」は /btw、と整理すると迷いません。
小さな習慣として定着させる
この手の機能は、知っているだけでは使わずに終わります。私は意識的に、「メインの会話に脇質問を打ち込みそうになったら、まず /btw を付けられないか考える」という一拍を入れるようにしました。最初の数回は忘れますが、一度メインの文脈が脇質問で乱れて作業をやり直す経験をすると、自然と手が /btw を打つようになります。
エージェントに長い作業を任せる時間が増えるほど、その会話の「純度」を守ることの価値は上がっていきます。/btw は派手な機能ではありませんが、一つの作業を最後まで集中して走らせきるための、地味で確かな道具だと感じています。同じように長尺タスクの脱線に悩んでいる方の参考になれば幸いです。