VS Code チームが、GPT-5.5 向けのエージェント指示を調整した実験記事を公開しました。テーマは、エージェントに「探索を減らし、早く検証させる」と何が起きるかです。参考: How Prompt Tuning Improved GPT-5.5 in VS Code
一読すると、「エージェントは探索しすぎるから、最初から狭く調べて、すぐ編集して、すぐテストせよ」という運用が正解のように見えます。
ただ、私はこの読み方には少し注意が必要だと思っています。
記事の実験結果は、主に 速さ、トークン量、ツール呼び出し数の改善を示しています。一方で、品質指標は明確に向上したというより、ほぼ維持された、または一部で小さな悪化も観測された、という結果です。
つまり、この記事から得るべき教訓は「探索を常に削れ」ではありません。
探索を制御し、検証に早く接続する。だが、必要な探索まで禁止しない。
これが実務向けの読み方だと思います。
何を検証した実験か
公式記事によると、VS Code チームは OpenAI と共同で、GPT-5.5 のシステムプロンプトを 2 週間実験しました。対象は VS Code のエージェント実行基盤で、モデルがツール、コンテキスト、指示、実行ループを通じてコーディング作業を進める層です。
実験群は次の 3 つです。
| グループ | 公式の識別子 | 内容 | 配分 |
|---|---|---|---|
| 対照群（Control） | PRPT_CTRL |
現行の既定プロンプト | 25% |
| 実験条件 A（Treatment A） | PRPT_SRCH |
探索を減らすための短い注意書き | 25% |
| 実験条件 B（Treatment B） | PRPT_LRG |
初回編集前後の行動を明示する大きめのプロンプト節 | 25% |
残りの GPT-5.5 利用分は評価表の外で既定プロンプトを使い続け、比較対象は同じ種類の利用データに揃えたと説明されています。
実験条件 A は、かなり小さい指示追加です。
- 具体的な手がかりから始める
- 近くの文脈だけ読む
- 対象範囲を絞った、反証可能な仮説を作る
- すぐ試せる確認方法が見えたら行動する
- 変わっていない文脈を読み直さない
実験条件 B は、同じ方向性をもっと大きく構造化したものです。公開されている実装を見ると、Before_the_first_edit と After_the_first_edit という大きな節を追加し、初回編集前に仮説と負担の小さい検証方法を作り、初回編集後はすぐ対象を絞った検証に進むよう指示しています。参考: gpt55BasePrompt.tsx
数値を見ると、改善したのは効率
公式記事の評価表では、実験条件 B がもっとも強い結果を出しています。
特に目立つのは、待ち時間とコスト寄りの指標です。
| 指標 | 実験条件 B の変化 | p 値 | 読み方 |
|---|---|---|---|
| 初回編集までの時間 p50（p50 Time to First Edit） | -5.68%（3.9 秒短縮） | 2e-5 | 中央値で初回編集が早くなった |
| 初回編集までの時間 p95（p95 Time to First Edit） | -9.30%（38.8 秒短縮） | 1e-10 | 遅いケースの待ち時間が改善 |
| 消費トークン量 p50（p50 total tokens） | -3.25%（0.3M トークン削減） | 0.2094 | 中央値では有意差なし |
| 消費トークン量 p95（p95 total tokens） | -7.64%（0.5M トークン削減） | 0.0003 | 重い依頼のトークン消費が改善 |
| 平均ツール呼び出し数（Average tool calls） | -8.54%（2.04 回分の呼び出し減） | 1e-12 | ツール呼び出しが明確に減った |
| 10 分後生存率（10-minute survival rate） | -0.44%（-0.41 ポイント） | 0.0493 | 小幅悪化。有意だが差は小さい |
| コミット生存率（Commit survival rate） | +0.68%（+0.57 ポイント） | 0.1533 | 上がっているが、統計的有意差はない |
ここで出てくる指標は、普段の開発指標とは少し違います。公式記事の説明に沿って、日本語に寄せると次のように読めます。
| 指標 | 日本語での意味 |
|---|---|
| 10 分後生存率（10-minute survival rate） | AI が書いたコードのうち、10 分後にも削除・書き換えされずファイルに残っている割合。短期的に「その変更がすぐ捨てられなかったか」を見る品質の代替指標。 |
| コミット生存率（Commit survival rate） | AI が書いたコードのうち、最終的にコミットまで残った割合。10 分後生存率より厳しめで、「本当に採用される変更になったか」を見る指標。 |
| 初回編集までの時間（Time to First Edit） | ユーザーが依頼してから、モデルが実際にコードへ最初の変更を入れるまでの待ち時間。 |
| 消費トークン量（total tokens） | モデルが読んだ入力と書いた出力の合計に近く、コストやコンテキスト消費の代替指標。 |
| 平均ツール呼び出し数（Average tool calls） | ファイル検索、読み取り、ターミナル実行、編集などを 1 つの依頼で何回使ったか。少ないほど効率的だが、少なすぎると確認不足の危険もある。 |
| p50 / p95 | p50 は中央値、つまり典型的なケース。p95 は上位 5% の遅い・重いケースで、待ち時間やコストが大きく膨らむ外れ値を見るための値。 |
| p 値（p-value） | 差が偶然で説明できるかを見る統計値。小さいほど「偶然ではなさそう」と言いやすい。ただし、有意でも差分が小さければ実務上の重みは別に見る必要がある。 |
この表から素直に言えることは、次の 2 つです。
- 実験条件 B は、初回編集までの時間、p95 の消費トークン、ツール呼び出し数をかなり改善した。
- 品質指標は、少なくとも「明確に向上した」とは言いにくい。
VS Code チーム自身も、品質を見張るための指標は「おおむね安定（mostly stable）」と読んでいます。コミット生存率（Commit survival rate）は実験条件 B で +0.68% ですが、p 値は 0.1533 なので有意ではありません。一方、10 分後生存率（10-minute survival rate）は -0.44% で、p 値は 0.0493 と統計上は有意な小幅悪化です。
この差は重要です。
「速くなった」「安くなった」と「品質が上がった」は、同じ意味ではありません。
今回の実験は、より正確にはこう読むべきです。
品質を大きく崩さずに、待ち時間、トークン消費、ツール呼び出しを減らした。
ユーザー仮説は、どこまで検証できるか
今回の議論で出てきた仮説は、かなり実務的です。
すべてにおいてこの指示が有効とは限らない。品質が崩れないのであって、向上はしない。余裕があるなら、探索も OK にした方が良いのではないか。
私は、この仮説はかなり妥当だと思います。ただし、公式データから検証できる範囲と、まだ検証できていない範囲を分ける必要があります。
まず、「品質が向上したわけではない」という部分は、記事内データからかなり支持されます。
品質指標として出ているのは、10 分後生存率とコミット生存率です。実験条件 B のコミット生存率は上がっていますが、有意差はありません。10 分後生存率は小さいながら悪化しています。したがって、この実験を「品質改善の実験」と読むのは強すぎます。
次に、「すべてのタスクで有効とは限らない」という部分も、妥当な注意です。
今回の公開評価表は実利用データの平均的な比較であって、タスク種別ごとの内訳は出ていません。小さな UI 修正、明確なテスト失敗、既知パターンの反映のようなタスクでは、探索を削る効果は大きそうです。一方で、アーキテクチャ変更、セキュリティ、データ移行、仕様の曖昧な依頼、未知の外部 API 調査では、最初の探索を削りすぎると誤った局所解に寄る危険があります。
ただし、「余裕があるなら探索した方が品質が上がる」までは、このデータだけでは証明できません。
なぜなら、今回の実験には「探索を多めに許可する」実験条件がありません。比較しているのは、現行の既定プロンプト、探索削減の小さい指示、探索削減と検証ループを強めた指示です。探索を増やした場合に品質が上がるか、手戻りが減るか、人間レビュー時間が短くなるかは別実験が必要です。
したがって、現時点の結論はこうです。
ユーザー仮説のうち、「品質向上ではなく品質維持」「万能ではない」は公式データで支持される。一方、「余裕があれば探索を増やすと品質が上がる」は、実務上はあり得るが、この実験だけでは未検証。
実務では「探索禁止」ではなく「探索予算」にする
エージェント指示に落とすなら、私は「探索を減らせ」とだけ書くより、探索予算を明示した方がよいと考えています。
探索そのものは、問題ではありません。
悪いのは、目的のない探索、読み直し、隣接ファイルの比較を続けて、いつまでも仮説と検証に入らないことです。
逆に、良い探索には条件があります。
- 何を確かめるために読むのかがある
- どの判断に影響するのかが明確である
- どこまで読んだら止めるかが決まっている
- 次に実行する検証が見えている
つまり、探索は「多い/少ない」ではなく、「予算と停止条件があるか」で見るべきです。
エージェント指示に落とすなら
今回の実験を、実務用の AGENTS.md やエージェントスキルに入れるなら、私は次のように書きます。
通常ループ:
- 失敗コマンド、対象ファイル、関数名、URL、テスト、近い実装など、最も具体的な手がかりから始める。
- 反証可能な仮説を 1 つと、すぐ試せる検証を 1 つ言えるところまでだけ読む。
- 仮説、責務を持つコードパス、検証方法が見えたら、根拠のある最小変更を入れる。
- 変更後はすぐに、その仮説を否定できる対象を絞った検証を実行する。
探索予算:
- 影響範囲が大きい、責務境界が曖昧、セキュリティ/個人情報リスクがある、データ移行を伴う、公開 API 互換性に関わる、外部事実が曖昧な場合だけ探索範囲を広げる。
- 探索を広げる前に、何を確かめるのか、どこで止めるのか、次に何で検証するのかを書く。
- リポジトリ全体を漫然と眺めるより、2-4 個の具体的な手がかりを優先する。
- 追加で読んでも次の編集や検証計画が変わらなくなったら、探索を止める。
禁止:
- 対象テスト、型チェック、静的検査（lint）、プレビュー、再現コマンドがあるのに、差分確認（git diff）だけを検証扱いしない。
- 最初の対象を絞った検証の前に、隣接領域へ修正を広げ続けない。
- 新しい証拠がないのに、変化していない文脈を何度も読み直さない。ポイントは、通常ループでは VS Code の実験条件 B に近い動きを採用しつつ、探索予算で例外条件を明示することです。
この形なら、小さな修正では速く進み、大きな判断では必要な探索を確保できます。
AI仕様駆動開発に当てはめる
AI仕様駆動開発に当てはめるなら、タスクごとに「探索を絞る場面」と「探索予算を明示して広げる場面」を分けるのが現実的です。
| タスク | 推奨する始め方 | 理由 |
|---|---|---|
| 明確なビルド / テスト失敗 | 手がかり起点 | 失敗コマンドが手がかりになる |
| 小さな UI / 文言修正 | 手がかり起点 | 近い実装とプレビューで検証できる |
| 仕様の曖昧な実装 | 探索予算あり | 要件、責務境界、既存制約を先に確認したい |
| 外部 API / SDK 連携 | 探索予算あり | 仕様、互換性、制限事項は一次情報確認が必要 |
| 認証、権限、個人情報 | 探索予算あり | 誤った局所解のリスクが高い |
| 大きなリファクタリング | 探索予算あり | 責務とテスト境界を先に見たい |
| プルリクエスト（PR）レビュー対応 | 手がかり起点で開始 | 指摘行が手がかり。広げるのは再発範囲だけ |
| 本番リリース、公開作業 | 検証優先 | 統合、デプロイ、本番確認の境界が重要 |
この記事自体も、手がかり起点だけでは足りません。
VS Code の公式記事、公開されている gpt55BasePrompt.tsx、既存ブログの書式、Content Collection のスキーマ、画像の扱いを確認する必要があります。外部記事を扱う以上、探索を削りすぎると、数字や引用の扱いが危うくなります。
一方で、探索を広げ続ける必要もありません。今回必要だったのは、公式記事の評価表、公開プロンプト実装、リポジトリの記事作成ルール、既存記事の文体です。そこまで揃えば、次は執筆と検証に進むべきです。
これが「探索を制御する」という意味です。
まとめ
VS Code の GPT-5.5 プロンプトチューニング実験は、とても参考になります。
実験条件 B は、初回編集までの時間、p95 の消費トークン、ツール呼び出し数を明確に改善しました。従量課金の時代には、この差は実務上かなり大きいです。
ただし、品質指標は「向上」と言うより「ほぼ維持」です。10 分後生存率には小さな悪化も出ています。
だから、エージェント指示に落とすときは、「探索を減らせ」をそのまま全面採用するのではなく、次の形がよいと思います。
通常は、具体的な手がかりから始め、近い範囲の仮説を立て、すぐ試せる検証に早く入る。
ただし、影響範囲が大きい作業、仕様が曖昧な作業、外部事実確認が必要な作業では、目的と停止条件を決めたうえで探索予算を使う。
これは、速さと品質のどちらかを選ぶ話ではありません。
エージェントに、探索、編集、検証の順番と予算を持たせる話です。
参照元
- How Prompt Tuning Improved GPT-5.5 in VS Code（公式） (Visual Studio Code)
- VS Code の GPT-5.5 プロンプト実装 (
gpt55BasePrompt.tsx) (GitHub) - Improving token efficiency in GitHub Copilot（公式） (Visual Studio Code)