夕方、記事の自動投稿パイプラインを直している最中に、ふと「あのフラグ、デフォルトは true だったか false だったか」が気になることがあります。手を止めて確かめれば30秒で済む話です。ところが、その30秒のあとで元の作業に戻ると、さっきまで頭の中に組み上がっていた段取りが、半分ほど崩れているのです。
私はこの「戻ってきたときの組み直し」が、ずっと地味に苦手でした。質問そのものは小さいのに、本筋から一度離れた代償だけが妙に大きい。Antigravity v2.1.4（6月11日リリース）で入った /btw というスラッシュコマンドは、この代償の正体が「時間」ではなく「文脈」だったことを、使ってみて初めて気づかせてくれました。
本筋を止める質問は、時間ではなく文脈を奪う
これまで、作業中に湧いた脇道の疑問への対処は、だいたい二択でした。
ひとつは、いま開いている会話にそのまま質問を投げる方法です。手早く答えは返ってきますが、本筋のやり取りのなかに無関係な問答が混ざり込みます。長いセッションだと、後から読み返したときに「この質問、何のためにしたんだっけ」となりますし、エージェントが参照する文脈にも余計な話題が一枚積み重なります。
もうひとつは、新しい会話を開いて聞く方法です。本筋はきれいに保てますが、今度は新しい会話のほうにいまの作業の前提が何もありません。「さっきまで何をしていたか」を一から説明し直すことになり、結局そこで集中が切れます。
どちらを選んでも、削られるのは秒数ではなく、頭の中に積み上げた作業の見取り図のほうでした。
/btw が変えたのは「聞き方」だった
/btw（by the way の略だと思われます）は、いまの会話の文脈を保ったまま、使い捨ての単発エージェントに横道の質問を投げる仕組みです。本筋の会話履歴は一切汚れません。質問と回答はその場限りで完結し、メインのスレッドはさっきの続きのまま残っています。
使い方はとてもシンプルです。
（本筋の会話を進めている途中で）
/btw このプロジェクトで使っている baseline profile の生成は、
どのGradleタスクに紐づいていたか確認したい
→ 単発エージェントが現在のプロジェクト文脈を見て回答
→ 回答を読んだら、本筋の会話に戻る。履歴には残らないポイントは、単発エージェントが「いまのプロジェクトの状態」は見られる一方で、本筋の会話の流れには書き込まないところです。文脈を読む権限はあるが、汚す権限はない。この非対称さが、ちょうど欲しかったものでした。
文脈を汚さないことが、なぜ効くのか
最初は「ただの便利コマンド」だと思っていました。けれども何日か使ううちに、効いているのは利便性ではなく、本筋のスレッドを一定の純度で保てることだと分かってきました。
エージェントに長い作業を任せるとき、私が一番気にしているのは、会話の文脈がどれだけ濁らずに保たれているかです。途中で投げた脇道の質問、言い直し、試しに聞いてみたこと——そうした断片が積もるほど、エージェントは本筋の意図を見失いやすくなります。/btw は、その濁りの一番ありふれた発生源を、本筋から物理的に切り離してくれます。
私自身、以前は脇道の疑問が湧くたびに「いまの作業を一度きれいに区切ってから確かめよう」と先送りし、結局その区切りを作るのに手間取っていました。個人開発で複数のサイトを並行して触っていると、頭の中では常に二つ三つの作業が薄く走っています。そのうちのひとつで湧いた小さな疑問を、別の作業や本筋の文脈に持ち込まずに処理できるのは、想像していたより静かな効き方をします。集中が途切れる回数そのものが減るというより、途切れたあとの復帰が軽くなる感覚です。
私の実際の使い分け
数日試して、いまはこんな基準で使い分けています。
| 状況 | 選ぶ手段 | 理由 |
|---|---|---|
| 本筋に直接関係しない確認（フラグ・コマンド名・仕様） | /btw | 答えは欲しいが履歴には残したくない |
| 本筋の判断材料になる調査 | そのまま本筋で聞く | 後から参照したい文脈なので残すべき |
| 独立した別タスクの着手 | 新しい会話 | 前提が違うので分けたほうがきれい |
線引きの軸は「この問答を、あとで本筋の文脈として読み返したいか」の一点です。読み返したいなら本筋に残す。その場で消えていいなら /btw に逃がす。この基準にしてから、長いセッションの会話履歴が以前よりずっと読みやすくなりました。
ちなみに v2.1.4 では、/btw のほかにクォータ画面の刷新や、Gemini モデルへの PDF 添付、会話ビュー内の検索（cmd/ctrl+F）なども入っています。どれも派手な機能ではありませんが、毎日同じツールを長時間触る側からすると、こうした「作業の手触り」を整える更新のほうが、結局いちばん効いてきます。
任せる範囲ではなく、聞く範囲を設計する
エージェントツールの話をするとき、私たちはつい「どこまで任せるか」を考えがちです。けれども /btw を使ってみて思ったのは、任せる範囲と同じくらい、聞く範囲を設計する余地があるということでした。何を本筋の文脈に残し、何をその場で消すか。それを選べるようになるだけで、長い作業の見通しはずいぶん変わります。
もし長いセッションで集中が削られる感覚に心当たりがあれば、次に脇道の質問が湧いたとき、それを本筋に投げる前に一度 /btw へ逃がしてみてください。失われていたのが時間ではなく文脈だったことに、たぶん気づけるはずです。
最後までお読みいただき、ありがとうございました。同じように一人で複数のプロジェクトを抱えている方の、作業の組み立ての参考になれば嬉しいです。