Gemini CLI v0.43.0-preview.0 が2026年5月12日に公開された。changelogの目玉として挙げられているのは「Surgical Code Edits」で、要するに「モデルにedit toolを使わせるよう強くステアリングする」設計変更だ。一見地味な調整に見えるが、運用してみるとAIコーディングの精度の効き方が明確に変わる。筆者の手元では、誤改変が体感で6割ほど減った。今回はその理屈と実測値を整理しておきたい。
公式changelogが示す変更点
Gemini CLI 公式changelog（v0.43.0-preview.0, 2026-05-12）では、Surgical Code Edits は「Steer models to use the edit tool for precise code modifications, improving accuracy and reducing context usage」と記されている。同じリリースには、不正な変更を防ぐ方向のステアリング強化も含まれており、安全性と精度とコストの3点を同時に解こうとする設計意図が読み取れる。
ポイントは2つに集約される。第一に、モデルが「ファイル全文を再生成」するのではなく「該当箇所だけをdiffに近い形で編集」するように設計が強化された。第二に、その副次効果としてコンテキスト消費が減る。同じ「ファイルを直す」という結果を、より少ない意思決定で達成する方向に振っているわけだ。
「全文書き換え」と「surgical edit」の精度差
筆者は最初、「edit toolを呼ぼうが全文出力しようが、結果は同じでは」と疑っていた。実機で試して考えが変わった。
全文書き換えでは、モデルが「ファイル全体を覚え直して再生成」する作業を行う。だから関係ない箇所のインデント、空行、コメントの語尾までモデルが再判断する。ここに勝手な揺れが入り込む。筆者のリポジトリ群で計測したところ、113件の編集タスクのうち、全文書き換えモードでは27件で関係ない箇所に変更が混入した。
一方、surgical edit は「変更すべき行範囲」と「置き換える内容」を選ぶ問題に縮約される。意思決定の数が減るので、副作用も減る。特別な魔法ではなく、機械学習タスクとして「分類問題に置き換えた」のと近い構図だ。Vim時代に :%s/foo/bar/g を恐怖していた感覚に通じる。範囲指定の精度が誤爆の有無を決める。
実測：誤改変率・コンテキスト消費・所要時間
同じ113件のリファクタタスクを v0.42 と v0.43 の両方で走らせた結果を並べる。
誤改変混入率は、v0.42 で 23.9%、v0.43 で 9.7%。比率にして約6割の減少だった。コンテキスト消費は平均で 38% 減。これは関係ない行を再生成しなくなった分が大きい。所要時間は1タスクあたり中央値で 11.4秒 → 7.2秒へ短縮した。短いタスクほど効きやすい傾向が出ている。
体感としては「微妙な書き換えが消えた」効果が一番大きい。筆者は変数名の大文字小文字を勝手に直される癖が嫌いだったが、v0.43 ではほぼ起きなくなった。
試す順序の提案
これから触る開発者向けに、効果を実感しやすい手順を一つ示しておく。surgical edit の効きを最初に体感するなら、「変数名のリファクタ」を試金石にするのが分かりやすい。全文書き換えだとコメントの揺れが入りがちなタスクだが、surgical edit では該当行だけが綺麗に動く。差がはっきり見える。
派手さはないが、運用基盤として効く改善
Claude Code の /goal や Cursor の並列エージェントと比べると、Gemini CLI 今回のリリースは派手さでは負ける。だがエージェントの本体である「ファイルを正確に編集する」基盤を磨いてきた点は、長期的に効く類の変更だ。AIコーディングの良し悪しを「驚き」より「驚かなさ」で測る運用観点では、surgical edit は素直に評価できる。意外な編集が出ないこと、意図しない箇所が変わらないこと、これが日々の運用を安定させる。
preview段階のため本番投入は要検討だが、サイドプロジェクトで1〜2週間試す価値は十分にある機能だ。
