長い指示が、総作業量を減らすこともある
AI開発支援のコストを減らす方法は、指示文を短くすることだけではない。VS CodeチームがOpenAIと実施したGPT-5.5の実験は、編集前の調査と編集後の検証を明確に指示すると、最初の変更までの時間とツール呼び出しを減らせることを示した。一方、品質を測る指標の一つは小さく低下しており、単純な全面改善とは読めない。
7月6日のVS Code公式技術記事は、モデルをツール、文脈、指示、反復処理につなぐ実行環境を対象としている。モデル自体の学習し直しではなく、同じモデルへ渡すシステムプロンプトの変更である。イノベトピアの報道を起点に、実験条件と現場への示唆を整理する。
二つの変更を同じ大きさの集団で比較
実験期間は二週間。従来のプロンプトを使う対照群、探索を抑える短い注意書きを加えたA群、編集前後の行動を広く整理したB群を比較した。各群にはGPT-5.5のエージェント利用の25%が割り当てられた。残り25%も従来設定で動いていたが、この集計の対照群には含めていない。75%という合計を見て、利用者全体を三等分した実験と解釈しないようにしたい。
A群は、具体的なファイルや不具合から調べ、必要以上に周囲を探索せず、確かめる手段が得られたら行動へ移るという簡潔な指示だった。B群は、最初の編集前と編集後を分け、局所的な仮説、反証できる確認、最小限の変更、直後の検証という一連の流れを明示した。
B群の指示自体は長くなる。それでも全体の消費が下がる可能性があるのは、毎回の指示に使う分より、迷走による再検索や読み直しを減らす効果が大きくなり得るからだ。これはあらゆる長文プロンプトが有利という主張ではない。何の無駄を取り除くかを絞った変更だった。
最初の編集と、完成までの時間は別
公式集計では、B群の最初の編集までの時間は中央値で5.68%、3.9秒短くなった。遅い側の95パーセンタイルでは9.30%、38.8秒の短縮だった。この38.8秒は全件の最大短縮でも、完成までの平均短縮でもない。入力してから最初の実変更が入るまでを測った値である。
ツール呼び出しは一回の依頼当たり平均8.54%、2.04回減った。重い依頼側の95パーセンタイルでは総トークンが7.64%減少した。ただし利用者単位の中央値におけるトークン減少は統計的に有意ではなかった。重い処理で効果が出たことと、すべての利用者の料金が同じ割合で安くなることは区別する必要がある。
A群にも改善傾向はあったが、B群の方が一貫して強い結果となり、チームはB群を標準設定へ採用したと説明している。ここで一般化できるのは、探索量を減らせば必ず速くなるという法則より、運用データから仮説を作り、限定した比較で確かめる方法である。
品質の小さな低下も判断材料にする
10分後に生成コードの文字がどれだけ残っているかという指標では、B群は相対0.44%、絶対0.41ポイント低下した。有意確率は0.0493だった。コミットまで残る割合は上向いたが、有意な差ではない。公式説明も、この短期残存率の低下を検討すべきトレードオフとして扱っている。
コードが残る割合は利用者の採用を近似する指標であり、機能の正しさや脆弱性のなさそのものではない。編集が速くなっても、後から人が修正する負担が増えていないか、テストを省いていないかは別途確認したい。業務システムでは、最初の編集の速さだけを目標にすると、調査すべき認証やデータ境界まで削る誘因になり得る。
日本の開発チームで試すなら
以下は当サイトの考察である。まず繰り返し発生する小さな修正を選び、開始時刻、最初の変更、確認の実行、レビュー完了を分けて記録する。改善前後で、モデル、作業の難しさ、利用できるツールまで同時に変えると、何が効いたか分からなくなる。
次に、調査を打ち切る条件と、必ず確認する条件を用意する。既知の関数の表示修正なら、近傍の実装と一つの動作確認で判断できることもある。権限を変更する処理なら、呼び出し元、対象データ、失敗時の挙動まで読む必要がある。「調査を少なくする」を一律の回数制限へ置き換えると、リスクの違いを失ってしまう。
最初の変更は仮説を検証する手段にもなる。取り消せる小さな変更を入れ、狙った挙動を試し、結果が違えば仮説を直す。実行できないときは、確認できた範囲と残った不確実性をレビューへ渡す。終了報告だけを整えても、変更後の動作が確かめられたことにはならない。
エージェントの改善は、文章の巧拙だけでなく、確認できる仕事の区切り方に依存する。今回の実験は、速さ、消費、品質を一緒に測る価値を示している。当サイト運営のRO合同会社では、AIを組み込む開発・確認工程の設計について相談を受け付けている。
PR
ElevenLabs →
