AIコーディングを「より速く省トークンに」 VS Codeチームが実証、“GPT-5.5向けプロンプト”の改善効果：Microsoftが報告、“無駄な探索”を減らす実験（1/2 ページ）

Microsoftは、「Visual Studio Code」における「GPT-5.5」モデル向けシステムプロンプトのチューニング効果を、本番環境で実験、検証した結果を公式ブログで報告した。

[＠IT]

　Microsoftは2026年7月6日（米国時間）、コードエディタ「Visual Studio Code」（以下、VS Code）におけるOpenAIの「GPT-5.5」モデル向けシステムプロンプトのチューニング効果を、公式ブログで報告した。

　「コーディングエージェントに対し、探索を減らし、作業の事前検討を早めるよう促す。これにより品質を落とさずに処理の高速化と低コスト化を実現できるのか」――。この実験を、MicrosoftはOpenAIと共同で実施した。実際のユーザートラフィックを用いて、2週間の実験で検証したものだ。以降ではブログに基づき、実験の結果をまとめた。

GPT-5.5の“無駄な探索”を減らすプロンプト改善　その効果とは？

　VS Codeは、Microsoftが「コーディングハーネス」と呼ぶレイヤーを通じて、モデルをツール、コンテキスト、指示、エージェントループに接続している。ツール呼び出しや指示への反応はモデルごとに異なるため、ハーネスをモデルに合わせて調整することで、結果を改善できるという。

　Microsoftは、モデルやエージェントの料金に従量課金制が導入されたことで、トークン効率は単なるインフラ指標ではなくなったと強調する。エージェントが探索にトークンを浪費すれば、ユーザーは余計に料金を支払い、処理を待たされるはめになる。根拠のある編集操作に早く到達するエージェントは、優れた体験と請求額の削減の両方をもたらすとしている。

仮説：探索を減らし、事前検討を早める

　GPT-5.5のリリース後、MicrosoftはVS Codeのエージェントハーネス内でモデルがトークンをどのように消費しているかを分析した。その結果、有用な編集を行う前に、検索、再読、近傍パスの比較といった過剰な探索に労力を費やす傾向が明らかになった。

　この観察から、「エージェントは探索に費やす労力を減らし、証拠、行動、検証という意図的なループを回すことに労力を振り向けるべきだ」という検証可能なアイデアが導かれた。Microsoftはオフライン評価を経て、このアイデアをGPT-5.5用システムプロンプトの2つのバリエーションに落とし込み、実際のトラフィックにおいて現行のデフォルトプロンプトと比較した。

検索と読み取りを数多く繰り返す過剰探索型のエージェントと、アンカー特定→最小限のコンテキスト収集→編集→検証というループを回すエージェントの対比（提供：Microsoft）

実験の設計

　実験は2週間にわたって、GPT-5.5のエージェントトラフィックを「処理A」群、「処理B」群、コントロール（対照）群に25％ずつ割り当てて実施した。残る25％のトラフィックは、比較する群の規模をそろえるために、スコアカードの対象外として従来のデフォルトプロンプトを使い続けた。

グループ	バリエーション名	適用されるプロンプト内容	トラフィック全体に占める割合
コントロール（対照）群	PRPT_CTRL	現行のデフォルトプロンプト	25％
処理A群	PRPT_SRCH	経済的な検索と編集。行動前の探索を抑える簡潔なリマインダーを1つ追加	25％
処理B群	PRPT_LRG	大幅変更。編集と検証のループ全体を対象とする広範な再構成	25％
実験の構成

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

　処理A群のトラフィックに適用したプロンプトは、小さく焦点を絞った変更、具体的には「<economical_search_and_edit>」セクションをデフォルトプロンプトに加えたものだ。

　<economical_search_and_edit>セクションは、モデルに不要な探索を減らすよう促す。具体的なアンカーから着手し、最小限のローカルコンテキストのみを収集し、低コストの判別チェックが存在する時点で行動し、変更のないコンテキストを再読しないようエージェントに指示している。

　このセクションを含む実装の詳細は、GitHubで「gpt55BasePrompt.tsx」として公開されている。このセクションの内容は以下の通りだ（日本語訳）。

{economicalSearchAndEditEnabled && <Tag name='economical_search_and_edit'>
    - 利用可能な最も具体的なアンカー（ファイル、シンボル、動作の不良、コマンドの失敗、近傍の実装領域など）から着手する。<br />
    - 1つの妥当な局所的仮説と、それを反証し得る低コストなチェックを1つ選ぶのに十分な、近傍のコンテキストのみを収集する。<br />
    - リポジトリ全体の広範な探索よりも、的を絞った1回の検索または近傍の読み取りを優先する。<br />
    - 最も低コストな判別チェックが分かったら、行動に移る。<br />
    - 新たな結果によって関連性が生じない限り、変更されていないコンテキストを再読してはならない。<br />
</Tag>}

処理B群：プロンプトの大規模変更

　処理B群のトラフィックには、探索を抑えるという同じアイデアをより広く導入したプロンプトを適用した。プロンプトに簡潔なリマインダーを1つ追加するのではなく、エージェントのワークフローを「<Before_the_first_edit>」（最初の編集の前）と「<After_the_first_edit>」（最初の編集の後）という明示的なプロンプトセクションに再編成している。

　その狙いは、検索ステップだけでなくループ全体の解決にあった。これらのセクションでは、局所的な仮説を立て、根拠のある最初の編集を行い、その直後に検証することを求めている。一方で、これらのセクションによってシステムプロンプト自体が長くなるため、追加された構造がエージェントの挙動だけでなく、効率を改善するかどうかが焦点となった。

　これらのセクションを含む実装の詳細は、GitHubで「gpt55BasePrompt.tsx」として公開されている。該当箇所の内容は以下の通りだ（日本語訳）。

{largePromptSectionsEnabled && <>
    <Tag name='Before_the_first_edit'>
        - 利用可能な最も具体的なアンカー（ファイル、シンボル、動作の不良、コマンドの失敗、近傍の実装領域など）から着手する。リクエストがアンカーを明示的に指定していない場合は、最初の的を絞った検索または近傍の読み取りによってアンカーを特定し、以降はそこから局所的に作業を続ける。<br />
        - 最初の編集を行う前に、要求された動作がどのように機能するか、あるいはなぜ失敗するのかに関する反証可能な局所的仮説を1つと、それを反証し得る低コストなチェックを1つ提示するのに十分な、近傍の証拠のみを収集する。<br />
        [...]
        - 反証可能な局所的仮説を1つ、それが依存する近傍のコードパス、その仮説を反証し得る低コストなチェックを1つ、それを試す小さな編集を1つ提示できるようになったら、次のアクションは、根拠に基づく編集でなければならない。<br />
        - 確信が不完全な場合、最初の編集は、型の欠落、動作の不一致、制御フローの欠落、検証の失敗を明らかにする、元に戻せる小規模な調査でもよい。<br />
        - それでもなお、局所的ルーティングの根拠を探し続けている場合は、それをドリフト（逸脱）とみなす。現時点で最良の仮説と、利用可能な最良の近傍チェックを選び、そのチェックによる判別を可能にする妥当な最小の編集を行うことで立て直す。<br />
    </Tag>
    <Tag name='After_the_first_edit'>
        - 最初の検証アクションでは、次の順序を優先する。<br />
        - 現在の仮説を反証できる、最も低コストな動作チェックまたはチェック失敗<br />
        - 変更した部分に対する範囲の狭いテスト<br />
        - 変更した部分に対する範囲の狭いコンパイル、リント、型チェックのコマンド<br />
        [...]
        - 環境が提供している場合は常に、編集後に実行可能な検証ステップを少なくとも1つ行って終了する。焦点を絞ったコマンドが存在しない場合や、コマンドが利用できない場合にのみ、差分のみの検証にフォールバックする。<br />
    </Tag>
</>}