GPT-5.5の応答を改善、VS Codeのプロンプトチューニング手法
GPT-5.5の応答が改善された技術的背景
VS Codeが提供するAIエージェント機能は、コード生成の裏側で「コーディングハーネス」と呼ばれる仕組みが動いている。これはモデルとツール、コンテキスト、指示、エージェントのループを繋ぐ層だ。モデルがコードを書くための土台となる部分といえる。
2026年7月、VS CodeチームはOpenAIと協力し、GPT-5.5向けのシステムプロンプトを改善する実験を実施した。焦点は「エージェントの探索を減らし、検証を早める」ことにある。この変更で応答速度とコストの両方を改善できるかどうかが検証された。
プロンプトチューニングの目的と仮説
GPT-5.5のリリース後、VS Codeチームはエージェントがトークンをどのように消費しているかを分析した。分析の結果、モデルが実際の編集に入る前に過剰な探索を行っているパターンが浮かび上がった。具体的には、ファイルの再読込や周辺コードの比較に多くのトークンが費やされていた。
この観察から1つの仮説が導かれた。それは「エージェントはさまよう努力を減らし、証拠、行動、検証という意図的なループに注力すべきである」というものだ。この仮説を検証するため、2種類のプロンプトが用意された。
エージェントが編集前に「考えすぎる」状態を減らし、必要最小限の探索で行動に移すよう誘導する。この考え方は、トークン消費と応答時間の両方に直接影響を与える。
実験の中身と2つのアプローチ
実験は2週間にわたって実施された。GPT-5.5のエージェントトラフィックを、対照群と2つの処置群に25%ずつ分割し、残りの25%はスコアカード外でデフォルトプロンプトが使用された。この設計により、同じ種類のユーザートラフィックで公平な比較が可能になる。
処置A「PRPT_SRCH」簡潔な探索と編集
処置Aは小規模で焦点を絞った変更だ。プロンプトに1つのコンパクトな指示を追加し、不必要な探索を減らすようモデルに促す。この指示は「economical_search_and_edit」セクションと呼ばれる。
具体的には、次の5つの行動指針が与えられた。最も具体的なアンカー（ファイル、シンボル、失敗している動作など）から開始すること。1つの仮説とそれを否定できる安価なチェックを選ぶために十分な周辺コンテキストだけを集めること。広範なリポジトリ探索より1回の対象検索を優先すること。最も安価な判別チェックがわかったら即座に行動すること。そして、新しい結果が関連性を示さない限り、変更されていないコンテキストを再読しないことだ。
economical_search_and_edit:
- 最も具体的なアンカーから開始する
- 1つの仮説とその反証チェックに十分なコンテキストだけを集める
- 広範な探索より1回の対象検索を優先する
- 最も安価な判別チェックがわかったら即行動する
- 変更されていないコンテキストは再読しない処置B「PRPT_LRG」大規模プロンプト再構成
処置Bは同じ仮説をより広範に展開したものだ。エージェントのワークフローを「Before_the_first_edit（最初の編集前）」と「After_the_first_edit（最初の編集後）」の2つの明示的なセクションに再編成する。
このアプローチの狙いは、検索ステップだけでなくループ全体を解決することにある。最初の編集前に局所的な仮説を形成し、広範な探索を避け、根拠のある最初の編集を行い、最初の実質的な編集後に即座に検証する。処置Aと異なり、プロンプト自体のサイズは大きくなるため、構造の追加が効率を改善できるかどうかが重要な論点だった。
両処置の設計思想の違いは明確だ。処置Aは最小限の介入で探索を抑えるのに対し、処置Bはエージェントの行動全体を構造化して制御しようとする。この差が実際のパフォーマンスにどう現れるかが実験の焦点になった。
2週間のスコアカードが示した結果
実験では品質、レイテンシ、効率の3つの次元で評価が行われた。品質は「コードが定着するか」、レイテンシは「最初の編集がどれだけ早く行われるか」、効率は「トークンとツール呼び出しの数」で測定される。
品質指標 10分生存率とコミット生存率
10分生存率は、AIが書いたコードのうち10分後もファイルに残っている割合を示す。コミット生存率は、さらに厳格にgitコミットまで生き残ったコードの割合だ。この2つが品質のガードレール指標となる。
結果として、コミット生存率は処置Bで+0.68%とわずかに上昇し、処置Aでは-0.48%とわずかに低下したが、いずれも統計的に有意ではなかった。10分生存率は両処置ともわずかに低下し、処置Bの-0.44%だけが統計的有意の閾値をわずかに超えた（p=0.0493）。VS Codeチームはこれを「実際のトレードオフとして考慮すべきだが、動きは小さく、他の品質ガードレールは後退しなかった」と評価している。
レイテンシ指標 初回編集までの時間
編集レイテンシでは処置Bが最も強い改善を示した。p50（中央値）の初回編集時間は-5.68%（3.9秒高速化、p=2e-5）、p95（下位5%の遅いケース）では-9.30%（38.8秒高速化、p=1e-10）といずれも高い統計的有意性を示した。
処置Aもp50で-2.88%（2.0秒高速化、p=0.0271）と改善したが、p95の改善は統計的に有意ではなかった。遅いケースでの差が特に顕著で、「なぜこれが遅いのか」というストレスを感じる場面での改善が大きかったことになる。
トークン効率とツール呼び出し回数
1ユーザーあたりの日次トークン消費量（p50）は両処置とも減少したが、統計的有意ではなかった。しかし、トークン消費の裾野（p95、特に重いリクエスト）では、処置Bが-7.64%（p=0.0003）、処置Aが-5.19%（p=0.0157）と明確な改善を示した。
平均ツール呼び出し回数も両処置で減少した。処置Bは-8.54%（1ターンあたり2.04回の呼び出し削減、p=1e-12）、処置Aは-3.19%（0.77回削減、p=0.0091）だ。処置Bの優位性は極めて高い統計的有意性で裏付けられた。
処置Bは総合的に最も強いプロファイルを示した。レイテンシの明確な勝利、裾野トークンの有意な削減、ツール呼び出しの減少、そして品質ガードレールのほぼ安定。10分生存率のわずかな低下は軽微な有意性（p=0.0493）にとどまり、レイテンシやトークン、ツール呼び出しの改善ははるかに大きく堅牢だった。
プロンプトチューニングが示す開発体験の進化
この実験の成果は数字の変化だけではない。重要なのは、プロバイダからのフィードバックに基づく検証可能な仮説を、オフライン評価で事前検証し、2週間の本番環境で確認するという一連のループが機能したことだ。
モデルのリリースはチューニングループの終点ではない。VS Code上の実際の動作を観察し、焦点を絞った改善をテストし、より速く、信頼性が高く、効率的な体験を実現する新たな方法を見つける機会となる。このプロンプトチューニングは、その1つの具体的な実例だ。
使用量ベース課金におけるトークン効率の重要性
この改善が特に重要なのは、使用量ベースの課金モデルが前提にあるからだ。トークン効率は単なるインフラ指標ではない。エージェントが探索に費やすすべてのトークンは、ユーザーが支払い、待たされる対象だ。根拠のある編集に早く到達するエージェントは、より良い体験とより小さい請求額の両方をもたらす。
VS Codeチームはこの取り組みを継続する方針を示している。モデル、プロンプト、ツール、コーディングハーネス全体にわたって改善点を探し続け、エージェントの予算が必要な作業に集中できるよう最適化していくという。
このループが示すのは、AI開発支援ツールの進化がモデルの性能向上だけに依存する段階から、プロンプト設計やツール連携の最適化を含む総合的な取り組みへと移行していることだ。モデルが高性能でも、使い方が適切でなければ本来の力を発揮できない。その橋渡しをするのがプロンプトチューニングの役割といえる。
この記事のポイント
- GPT-5.5向けのプロンプトチューニングで、エージェントの探索を抑制し検証を早める改善が実施された
- 処置B（大規模プロンプト再構成）が最も優れた結果を示し、p95の初回編集時間を9.30%短縮した
- ツール呼び出し回数は8.54%削減され、トークン消費の裾野（重いリクエスト）でも7.64%の改善が確認された
- 品質指標（コード定着率）はほぼ維持され、速度と効率の改善が品質を犠牲にしないことが実証された
- 使用量ベース課金の文脈では、トークン効率の改善がユーザーのコスト削減に直結する重要性を持つ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験