プロンプトチューニングはいかにしてVS CodeのGPT-5.5を改善したか

2026年7月6日 VS Codeチーム, @code

私たちの前回の投稿では、モデルをツール、コンテキスト、指示、およびエージェントループに接続し、モデルにコーディングタスクを実行する能力を与えるレイヤーである、VS Codeのコーディングハーネスを紹介しました。

各モデルはツール呼び出しや指示に対して異なる反応を示すため、ハーネスを適応させて結果を改善することができます。この記事では、VS CodeのGPT-5.5システムプロンプトをチューニングするためにOpenAIと共同で実施した2週間の実験について説明します。疑問はシンプルでした。エージェントが探索を減らし、より迅速に検証するように促せば、品質を落とさずに高速かつ安価にできるでしょうか？ OpenAIのモデルに関する専門知識と私たちのハーネスデータを用いて、2つの小さなプロンプトの変更をテストし、本番トラフィックでコントロール（対照群）と比較して測定し、勝者をリリースしました。

これは、従量制課金が導入されている現在、さらに重要になっています。トークンの効率性はインフラストラクチャの指標だけではありません。エージェントが迷走に費やすすべてのトークンは、あなたが支払い、待たされているトークンなのです。根拠のある編集に早く到達するエージェントは、より優れたユーザー体験とより少ない請求額をもたらします。

仮説：探索を減らし、より迅速に検証する

GPT-5.5のリリースに続き、GitHub Copilotにおけるトークン効率の改善で説明されている作業の一環として、モデルがVS Codeのエージェントハーネス内でどのようにトークンを消費しているかを調査しました。2つのパターンが際立っていました。モデルがどこでトークンを消費したか、そして行動する前にどこで過剰な探索を行ったかです。エージェントは、有用な編集を行う前に、近接するパスの検索、再読、比較に多くの労力を費やすことがあります。

それは1つの検証可能なアイデアを示唆していました。エージェントは迷走にかける労力を減らし、「証拠、行動、検証」という意図的なループを進むことに多くの労力を費やすべきであるということです。

さまざまな仮説をテストし、オフライン評価を実行した結果、私たちはそのアイデアをGPT-5.5のシステムプロンプトの2つのバリアントへと落とし込みました。どちらもオフライン評価で有望な結果を示したため、本番トラフィックで現在のデフォルトと比較してテストしました。

実験の内部

私たちはVS Codeで2週間にわたって実験を実施し、GPT-5.5のエージェントトラフィックを2つの処置グループと1つのコントロールグループに25%/25%/25%の割合で分割しました。両方の処置は同じ仮説をテストしていますが、プロンプトに追加する構造の量が異なります。

注： 実験のスコアカードでは同じサイズのグループを比較するため、割り当ての合計は75%になっています。残りのGPT-5.5トラフィックはこのスコアカードのスライスの外側で引き続きデフォルトのプロンプトを使用し、同じ種類のユーザートラフィック全体で処置とコントロールを比較できるようにしました。

処置 A：経済的な検索と編集

処置 Aは小さく焦点を絞った変更を行います。不必要な探索を減らすようモデルを促す、シンプルでコンパクトなリマインダーです。

プロンプト内の <economical_search_and_edit> セクションは、エージェントに対して、具体的なアンカーから開始し、十分な最小限のローカルコンテキストのみを収集し、広範な探索を避け、安価な識別チェックが可能になったらすぐに行動を起こし、変更されていないコンテキストの再読を避けるよう指示します。

完全な実装詳細については、gpt55BasePrompt.tsx を参照してください。

{economicalSearchAndEditEnabled && <Tag name='economical_search_and_edit'>
    - Start from the most concrete available anchor: a file, symbol, failing behavior, failing command, or nearby implementation surface.<br />
    - Gather only enough nearby context to choose one plausible local hypothesis and one cheap check that could disconfirm it.<br />
    - Prefer one targeted search or nearby read over broad repo exploration.<br />
    - Once the cheapest discriminating check is known, act.<br />
    - Do not re-read unchanged context unless a new result makes it relevant.<br />
</Tag>}

処置 B：大規模なプロンプトセクション

処置 Bは、探索を制限するという同じアイデアのより広範なバージョンをテストしました。経済的な検索に関する単一のコンパクトなリマインダーを追加する代わりに、エージェントのワークフローを明示的な <Before_the_first_edit>（初回編集前）および <After_the_first_edit>（初回編集後）セクションに再編成します。処置 Aとは異なり、これらの追加によりシステムプロンプト自体が大きくなるため、追加された構造がエージェントの動作だけでなく効率性も向上させるかどうかが重要な疑問でした。

目標は、検索ステップだけでなくループ全体を解決することでした。すなわち、編集前にローカルな仮説を立てること、広範な探索を避けること、根拠のある最初の編集を行うこと、そして最初の実質的な編集の直後に検証を行うことです。

完全な実装詳細については、gpt55BasePrompt.tsx を参照してください。

{largePromptSectionsEnabled && <>
    <Tag name='Before_the_first_edit'>
        - Start from the most concrete anchor available: a file, symbol, failing behavior, failing command, test, or nearby implementation surface. If the request does not name one explicitly, use the first targeted search or nearby read to identify that anchor, then continue locally from there.<br />
        - Before the first edit, gather only enough nearby evidence to state one falsifiable local hypothesis about how the requested behavior should work or why it is failing, and one cheap check that could disconfirm it.<br />
        [...]
        - Once you can state one falsifiable local hypothesis, the nearby code path it depends on, one cheap check that could disconfirm it, and one small edit that would test it, the next action must be a grounded edit.<br />
        - If confidence is incomplete, the first edit may be a small reversible probe that exposes missing types, behavior mismatches, control-flow gaps, or validation failures.<br />
        - If you find yourself still searching after that local-routing budget, treat that as drift. Recover by choosing the best current hypothesis and the best available nearby check, then make the smallest plausible edit that will let that check discriminate.<br />
    </Tag>
    <Tag name='After_the_first_edit'>
        - Prefer this order for that first validation action:<br />
        - the cheapest behavior-scoped or failing check that can falsify the current hypothesis<br />
        - a narrow test for the touched slice<br />
        - a narrow compile, lint, or typecheck command for the touched slice<br />
        [...]
        - Finish with at least one post-edit executable validation step whenever the environment provides one. Only fall back to diff-only validation when no focused command exists or commands are unavailable.<br />
    </Tag>
</>}

2週間のスコアカードが示した結果

私たちは、品質（コードが定着するか）、レイテンシ（最初の編集が反映される速さ）、効率性（トークンとツール呼び出し）の3つの次元で処置を追跡しました。各処置は、以下の表でコントロールグループと比較されています。

シグナルの凡例：● 良好かつ非常に有意（p < 0.001）、○ 良好かつ統計的に有意（p < 0.05）、● 不利かつ非常に有意、○ 不利かつ統計的に有意、- 統計的に有意ではない。

• 品質：ガードレールの指標は概ね健全な状態を維持しました。コミット生存率は、処置 Bでわずかに上昇し（+0.68%）、処置 Aでわずかに低下しましたが（-0.48%）、どちらも統計的に有意ではありませんでした。10分生存率は両方の処置でわずかに低下しました。処置 Bで-0.44%、処置 Aで-0.40%です。非常に有意な効率性の改善とは異なり、統計的有意水準を超えたのは処置 Bの変動のみであり、それもごくわずか（p=0.0493）でした。私たちはこれを考慮すべき実際のトレードオフとして扱いましたが、変動は小さく、他の品質ガードレールは後退していませんでした。

• レイテンシ：処置 Bは最も強力な編集レイテンシの改善をもたらし、どちらも極めて統計的に有意でした。初回編集までの時間 p50 は -5.68% 改善し（3.9秒高速化、p=2e-5）、初回編集までの時間 p95 は -9.30% 改善しました（38.8秒高速化、p=1e-10）。処置 Aも正しい方向に動いたものの、編集レイテンシの効果はより弱く、初回編集までの時間 p50 は -2.88%（2.0秒高速化、p=0.0271）、初回編集までの時間 p95 は -1.93%（有意ではない）でした。

• トークン効率：両方の処置で1ユーザーあたりの総トークン中央値が減少しましたが、それらのp50の変動は統計的に有意ではありませんでした（処置 Bで-3.25%、処置 Aで-2.54%）。上位テールにおいては、処置 Bがp95総トークン数を -7.64% 削減し、極めて統計的に有意でした（p=0.0003）。処置 Aもp95総トークン数を -5.19% 削減し、統計的に有意でした（p=0.0157）。両方のバリアントでターンあたりの平均ツール呼び出し回数が減少しました。処置 Bでは -8.54%（2.04回減）で極めて統計的に有意（p=1e-12）、処置 Aでは -3.19%（0.77回減）で統計的に有意（p=0.0091）でした。

処置 Bは全体的に最も優れたプロファイルを示しました。明確なレイテンシの改善、上位テールの大幅なトークン削減、ツール呼び出しの減少、そして概ね安定した品質ガードレールです。注目すべき唯一の変動である10分生存率のわずかな低下は、わずかに有意であるにとどまった一方（p=0.0493）、レイテンシ、トークン、およびツール呼び出しの改善はより大きく、はるかに堅牢でした。処置 Aもいくつかの指標を正しい方向に動かしましたが、VS Codeにとって最も重要な測定項目全体でより一貫性があったのは処置 Bでした。

そのため、私たちはこれをリリースしました。処置 Bである LargePromptSections（大規模プロンプトセクション）が、現在のデフォルトの GPT-5.5 システムプロンプトとなっています。

ここでの教訓は、数値が変動したということだけではありません。その変動は、プロバイダーからのフィードバックに基づく具体的で検証可能なハーネスの仮説に結びついており、最初にオフラインで検証され、その後2週間の本番稼働期間を通じてオンラインで確認されました。私たちが回し続けたいのは、まさにこのループなのです。

継続的な最適化

この実験は、ローンチ日を過ぎてもモデルプロバイダーとどのように協力しているかの一例にすぎません。モデルのリリースはチューニングループの終わりではありません。実際のVS Codeの動作を観察し、焦点を絞った改善をテストし、体験をより高速で、信頼性が高く、効率的にするための新しい方法を見つけるための新たなチャンスなのです。

モデル、プロンプト、ツール、およびVS Codeのコーディングハーネス全体にわたってこうした改善を引き続き探し求め、エージェントのリソースの大部分が不必要な探索ではなく、重要な作業に費やされるようにしていきます。

VS Codeのエージェントを試し、モデルを切り替えて、異なるモデルが同じタスクにどのようにアプローチするかを比較してみてください。私たちのGitHubリポジトリでフィードバックを共有してください。それは私たちが体験を改善し続ける助けとなります。

ハッピーコーディング！💙