深夜、並列で走らせたエージェントが 3 つのタスクを片付けて、会話パネルに長い diff が積み上がっていました。私はそれを上から順に読もうとして、横に折り返されたコードの行を目で追ううちに、どこを見ていたのか分からなくなりました。生成そのものは速くなったのに、私の側の「読む」速度が追いついていない。そう気づいたのが、表示設定を見直すきっかけでした。
Antigravity v2.2.1 では Appearance に Conversation Width（会話パネルの最大幅）が加わり、markdown のコード・差分ブロックで C++・Python・Protobuf の構文ハイライトが増えました。派手な機能ではありません。ただ、エージェントに実装を委ねる時間が長い私にとって、この 2 つは「読み切れるかどうか」を静かに左右する調整でした。
折り返しが起きた瞬間、レビューは分断される
エージェントが返す diff は、人が書くパッチより行が長くなりがちです。生成されたコードには説明的な変数名や型注釈が並び、1 行が 100 文字を超えることも珍しくありません。会話パネルが狭いままだと、その行が途中で折り返されます。
折り返し自体は些細に見えます。けれど差分レビューでは、これが判断を止めます。追加された行と削除された行の対応を目で取っているとき、1 行が 2 行に割れると、+ と - の縦のリズムが崩れます。私は何度も、折り返された行を「別の変更」だと一瞬誤読しました。読み直す。また誤読する。その往復が、1 タスクにつき数十秒ずつ積もっていきます。
Conversation Width を広げると、この折り返しが消えます。横に長い diff がそのまま 1 行で収まり、+/- の並びが縦にまっすぐ通る。たったそれだけで、変更の塊を「面」として一息に掴めるようになりました。
画面ごとに最適な幅は違う
とはいえ、幅は広ければよいというものではありません。私の環境では、ディスプレイのサイズと作業内容で最適値が変わりました。実際に数日試して落ち着いた設定が次の表です。
| 作業シーン | ディスプレイ | 会話幅の方針 | 狙い |
|---|---|---|---|
| diff レビュー中心 | 27インチ外部モニタ | 広め（折り返しを消す） | 長い行を 1 行で読み切る |
| 会話・計画の読み書き | 27インチ外部モニタ | 中くらい | 一行が長すぎて目が滑るのを防ぐ |
| ノート PC 単体 | 14インチ内蔵 | 狭め〜中くらい | 横スクロールを避け、要点を縦に追う |
散文と diff で、心地よい幅は逆方向に振れました。文章は幅が広すぎると 1 行の文字数が増えて、次の行の頭を見失います（新聞が段組みになっているのと同じ理由です）。一方で diff は広いほど折り返しが減って読みやすい。私は結局、diff を集中して見る夜は広め、翻訳原稿のように文章を読む昼は中くらい、と時間帯で切り替える運用に落ち着きました。
構文ハイライトは「差分の意味」を先に見せてくれる
もう一つの変更、C++・Python・Protobuf の構文ハイライト拡充は、幅とは別の角度でレビューを助けました。
色がつくと、行の中で「何が変わったか」を読む前に「何の行か」が分かります。型宣言なのか、文字列リテラルなのか、コメントなのか。とくに Protobuf のスキーマ差分は、フィールド番号や型が地の文と同じ色だと見落としやすい箇所でした。ハイライトが入ってからは、フィールド定義の追加・変更に目が自然に止まるようになりました。
私は個人開発でアプリを作りながら、その補助としてエージェントを使っています。生成された変更をそのまま信じず、必ず自分で読みます。その「読む」という工程は、色や幅といった表示の質にかなり依存していたのだと、設定を変えて初めて気づきました。エージェントの賢さを議論する前に、自分がその出力を正しく読める状態を作っておく。地味ですが、無人運用に近づくほど効いてくる部分です。
この考え方は、複数のエージェントが同時に変更を積むときにいっそう重要になります。並列運用で「後から変更を追える状態」をどう保つかは、並列エージェントの変更を、後から追えるようにする設計で別途まとめています。表示設定は、その追跡を人間の目の側から支える下ごしらえだと考えています。
設定を見直すときの順番
もし今、エージェントの出力が読みにくいと感じているなら、私が試した順番はこうです。
まず Conversation Width を一段広げて、いつもレビューする diff を開いてみます。折り返しが消えて +/- が縦に揃うかを確認します。次に、文章主体の会話に戻したとき幅が広すぎないかを見ます。広すぎたら一段戻す。最後に、扱う言語のハイライトが効いているかを、実際のコードブロックで確かめます。数分の調整ですが、以後に読むすべての diff に効き続けます。
Antigravity が IDE とエージェントを別アプリに分けた設計の話はAntigravity 2.0 で IDE とエージェントが別アプリになって最初に困ったことにも書きました。会話パネルが実装の主戦場になるほど、その 1 枚の読みやすさが 1 日の集中を左右します。
読み手の速度も、開発速度の一部
エージェントの生成が速くなるほど、ボトルネックは人間のレビューに移ります。だからこそ、幅や色のような「読む側の環境」を整えることは、遠回りに見えて実は近道でした。私自身、まだ最適な設定を探り続けている途中です。今日の diff が少しでも読みやすくなれば、明日のレビューはもう少し軽くなる。そう思いながら、小さな設定を触っています。
お読みいただきありがとうございました。表示まわりの小さな調整が、皆さんのレビューの手数を一つでも減らせたら嬉しく思います。