プロンプトを長くしたら token 効率が上がった話を読む - VS Code x GPT-5.5 の 2 週間 A/B テスト
こんにちは、copilot-instructions.md を書き足すたびに「これ、逆に token 食ってない？」と自問しているアーキテクトのやまぱん！です 😅
先日 (2026/07/06)、VS Code チームが How Prompt Tuning Improved GPT-5.5 in VS Code という blog を出しました。GPT-5.5 の system prompt を 2 週間 A/B テストして、結果として default を書き換えた という話です。
面白いのは、「勝った側が明らかにプロンプトが長い」 ことでした。それでも p95 Time to First Edit -9.30% / 平均 tool call -8.54% / p95 total tokens -7.64% を強い統計的有意で叩き出している。「短い方が効率的」というのは agent prompt の直感でよく言われますが、この実験はそれを部分的にひっくり返しています。
この記事では、元 blog の要点を日本語で追いかけつつ、実装本体である gpt55BasePrompt.tsx の該当行を deep dive し、最後は自分の .instructions.md にどう転用するかまで見ていきます。
- 元記事公開日: 2026/07/06、本記事執筆日: 2026/07/08
- 対象: GPT-5.5 の VS Code 内部での default system prompt
- 実装 SHA:
56d7412 - VS Code の harness は継続的にチューニングされているため、記載の数値・実装行番号は 執筆時点のスナップショット です
前提知識として、以下 2 つの VS Code blog も同じシリーズです。本文でも要点だけ触れますが、深く読む方は先に眺めておくと入りやすいです。
- Agent Harnesses in GitHub Copilot and VS Code（2026/05/15）: coding harness とは何かの定義編
- Improving token efficiency in GitHub Copilot（2026/06/17）: prompt cache / tool 定義削減の実装編
TL;DR
- VS Code チームは 2 週間、GPT-5.5 の agent traffic に 3 つの system prompt を 25% / 25% / 25% split で流し、control と比較した。
- 仮説はひとつだけ: 「explore less, validate sooner（探索を減らし、検証を早めろ）」。
- パターン A は 5 行の
<economical_search_and_edit>tag（短い注意書き）、パターン B は<Before_the_first_edit>+<After_the_first_edit>という edit の前後を workflow として構造化した大きな 2 tag。 - 勝ったのは パターン B。
p95 Time to First Edit -9.30%（38.8 秒短縮, p=1e-10）、p95 total tokens -7.64%（p=0.0003）、平均 tool calls -8.54%（p=1e-12）を quality をほぼ落とさずに達成し、default に flip した。 -
カギは「system prompt の固定コスト増よりも、agent が探索を早く止めて edit → validate に入るほうが動的な token を大幅に節約する」 こと。同じ発想は自分の
.instructions.mdにも移植できる。
1. なぜ prompt を触るのか - 「モデルはリリースがゴールじゃない」
この章では、なぜ VS Code が「モデルのリリース後に system prompt をわざわざ書き直す」ということをやっているのかを整理します。
元 blog は冒頭で、coding harness（モデルと tool / context / instructions / agent loop をつなぐ層）の話をした前回 post (Agent Harnesses in GitHub Copilot and VS Code) を思い出させた上で、今回の post は OpenAI と組んで GPT-5.5 の system prompt を 2 週間チューニングした話 だと宣言します。要旨はそのまま引用すると次の一節に集約されます。
every token the agent spends wandering is a token you pay for and wait on.
日本語で読み直すと「agent が探索でうろついた token は、そのまま 自分が払い、自分が待たされる token だ」。ここが今回の話の出発点で、続けて blog は次のようにも書いています。
Token efficiency isn't only an infrastructure metric.
「token 効率は単なるインフラ側の指標ではない」。GitHub Copilot は 2025/06 から premium request 単位の billing に移行し（Requests in GitHub Copilot (legacy)）、2026 に入って usage-based の色をさらに強めています。ユーザー側の請求書と体感速度が、agent の探索 token 数と直接連動する構造です。
このタイミングで VS Code が「モデルはリリース後もチューニングする対象だ」という姿勢を明確にしたのがこの blog です。前提として、Agent Harnesses 記事の冒頭にある名台詞:
The model is the engine. The harness is the car.
（モデルはエンジン、harness は車体。エンジンだけを比べても走る体験は決まらない）
を思い出しておくと本記事の位置づけがスッと入ります。今回のチューニング対象はエンジン（GPT-5.5 モデル本体）ではなく、車体（system prompt = harness の一部）です。
2. 仮説 - 「Explore less, validate sooner」を分解する
この章では、VS Code チームがどんな仮説を立てて 2 週間の A/B テストに入ったのかを見ます。
GPT-5.5 の token 使用パターンを VS Code チーム側で分析したところ、agent がどこで token を使っているか（where）と、どこで act する前に over-explore しているか（over-explore）の 2 パターンが見えたそうです。そこから立てた仮説は 1 つだけ:
the agent should spend less effort wandering and more effort moving through a deliberate loop of evidence, action, and validation.
意訳すると「agent は うろつき に費やす労力を減らし、evidence → action → validation という 意図的な loop を回すことに労力を寄せるべき 」。
これを 1 文でまとめたのが blog の副題にもなっている explore less, validate sooner です。ポイントは、これが「testable な仮説」として書けている点です。
-
exploreの量は、tool call 数 / read の総 token 数として測れる -
validate soonerは Time to First Edit（agent が最初の edit をするまでの経過秒）で測れる - 品質は 10-minute survival / commit survival で守る（探索を減らしすぎると品質が落ちる可能性があるので、guardrail として置く）
この 3 軸で offline eval を先に回し、両 prompt variant が promising だったので、次に live traffic の A/B テストへ進めた、というのが実験設計の骨格です。
3. パターン A (Treatment A): <economical_search_and_edit> 5 行の解剖
（元記事内ではそれぞれ Treatment A / Treatment B と表記されています。本文では読みやすさ優先で「パターン A / パターン B」と呼び、実装名や scorecard の label としては Treatment A / Treatment B も併記します。）
この章では、控えめな側の パターン A の全 5 行を、実装ソースから引用して読んでいきます。
gpt55BasePrompt.tsx の #L172-L178 を SHA 56d7412 時点で引用します。
{
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>
);
}
5 行の役割を 1 文ずつ日本語で並べます。
- anchor 選定: まず「file / symbol / failing behavior / failing command / nearby implementation surface」といった 具体的な anchor から始めよ。抽象的な理解や repo 全体の絵から始めるな。
- context を絞る: 「1 つの局所仮説」と「それを反証できる 1 つの安価な check」を選ぶ のに足る量だけ context を集めよ。
- 探索より近傍 read: repo 全体の探索より、targeted な 1 発の read を優先せよ。
- cheap discriminating check が見えたら動け: いちばん安く仮説を切り分けられる check が決まった瞬間に、act（edit や tool call） に移れ。
- 再読しない: 「新しい結果が関連づけない限り、変わっていない context を再読するな」。同じ file を何度も開き直す agent への釘。
これだけ読むと、書いていることはごく 常識的です。「anchor から始めろ / 探しすぎるな / 見つけたら動け」。プロンプトへの増分は 5 行、tag も 1 個で最小です。「短い方が良い agent prompt」という直感通りの設計で、実際 パターン A も p50 Time to First Edit や tool call を有意に改善しています（後の scorecard 参照）。
ですが、この後で見る パターン B は、この 5 行を「注意書き」から workflow そのものに昇格させます。
4. パターン B (Treatment B): <Before_the_first_edit> / <After_the_first_edit> を読む
この章では、勝った側の パターン B の中核 8 行を選んで読みます。full の 30 行は文字数的に厳しいので、選定引用 + GitHub リンク誘導で扱います。
パターン B の実装は #L33-L62 にあり、<Before_the_first_edit> と <After_the_first_edit> の 2 tag 構成 です。以下は代表 5 行 + 3 行の抜粋で、full source は GitHub リンクを参照してください。
4.1 <Before_the_first_edit> の中核 5 行
<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. ...
<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>
パターン A の最初の 2 行と対応する部分（anchor / cheap check）から始まっていますが、そこから先が違います。
-
the next action must be a grounded edit: 4 条件（局所仮説 / 依存する code path / 反証できる cheap check / それを test する small edit）が揃った瞬間、次の action は edit で なければならない 、と言い切っている。「もっと調べてから」を許さない tone です。 -
small reversible probe: confidence が足りない場合でも「調査を続ける」ではなく「小さく戻せる probe として先に edit する 」ことを 明示的に許可 しています。types / 挙動 / control flow / validation のズレを、机上ではなく edit 起点で炙り出す という発想。 -
treat that as drift: 探索が local-routing budget を超えても止まらないなら、それは drift（漂流） だと明示的にラベル付けしている。回復策も「現時点で最良の仮説 + 現時点で最良の近傍 check + smallest plausible edit に戻れ」と行動レベルで示されています。
パターン A の「探しすぎるな」が助言だったのに対し、パターン B の Before tag は 「edit までの workflow を fixed procedure として書いている」 のがわかります。
4.2 <After_the_first_edit> の中核 3 行
<Tag name="After_the_first_edit">
- After the first substantive edit, the very next step must be one focused
validation action when one exists. - Prefer this order for that first
validation action: - The cheapest behavior-scoped check that would fail if the
change is wrong (a targeted failing test/repro, minimal script, or focused CLI
invocation). - A narrow test that covers the touched slice. - A narrow compile
/ lint / typecheck against the touched slice. - `git diff` review only when no
focused command exists. - 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.
</Tag>
validation の優先順位を日本語で整理するとこうです（上記 code block の 2 番目の bullet の入れ子 bullet に対応）。
- 最も安い behavior-scoped の failing check（失敗する test / 再現 script / focused CLI）
- 触った slice の narrow test
- 触った slice の narrow compile / lint / typecheck
-
git diffは上記どれも無いときの fallback のみ
After tag の要旨は次の 3 つです。
- edit の直後は必ず 1 つの validation: edit → 何か他のこと、ではなく edit → 必ず 1 つの focused validation。
-
validation の順序が明示: 最初に試すのは failing check、次に narrow test、次に narrow compile / lint / typecheck、
git diffは 最後の fallback 。 -
git diff does not count as sufficient validation: diff を見て「validate したつもり」になる agent への釘。実行可能な check が使えるなら、それを回してからでないと次の edit や patch に進むな。
「edit の前」と「edit の後」の両方に workflow を書いた結果、パターン B は必然的にプロンプトが長くなります。blog 本文にも次の一節があります。
a key question was whether the added structure would still improve efficiency, not just agent behavior.
「増やした構造は、agent の振る舞いだけでなく 効率まで 改善するのか」が中心の問い。ここに explore less, validate sooner の仮説を live traffic でぶつけた、というのがこの実験の骨格です。
5. 2 週間スコアカード - 「長い方が勝った」データを読む
この章では、実験の scorecard を全部 Markdown table に起こし、勝敗の中身を数字で見ていきます。
まず本題に入る前に、この scorecard で使われる metric 名を 4 つだけ短く整理しておきます。
- Agent harness: モデル外の全部（system prompt / tool 定義 / retry / memory / router）。この記事で書き換えているのはこの中の system prompt。詳細は Agent Harnesses in GitHub Copilot and VS Code 参照。
- Time to First Edit: agent が最初の substantive な edit を行うまでの経過秒。「validate sooner」の直接の指標。
- Commit survival rate: 生成された commit が git 履歴に残り続けた率。長期的な品質指標。
- 10-minute survival rate: 元記事に厳密な定義は無いが、生成コードが 10 分後に revert / overwrite されずに残っている率 と推定される短期品質指標。
5.1 実験設計
- 期間: 2 週間
- traffic split:
PRPT_CTRL（control）25% /PRPT_SRCH（パターン A）25% /PRPT_LRG（パターン B）25% = 合計 75% - 残り 25% は default prompt のまま流し、この scorecard の比較対象外
- 対象モデル: GPT-5.5
5.2 全 7 指標の scorecard
● = p<0.001（highly significant）、○ = p<0.05（statistically significant）、- = 統計的有意なし の signal legend です。原文は色で favorable / unfavorable を区別していますが、Qiita 上では色が消えるので 説明語で補います。
| Metric（集計単位） | パターン A (Treatment A): 対 control %（delta） | パターン A: p 値 | パターン A: signal | パターン B (Treatment B): 対 control %（delta） | パターン B: p 値 | パターン B: signal |
|---|---|---|---|---|---|---|
| 10-minute survival rate（by user） | -0.40%（-0.37 pp） | 0.0707 |
-（n.s.） |
-0.44%（-0.41 pp） | 0.0493 | ○ unfavorable（ぎりぎり有意） |
| Commit survival rate（by user） | -0.48%（-0.41 pp） | 0.3200 |
-（n.s.） |
+0.68%（+0.57 pp） | 0.1533 |
-（n.s.） |
| p50 Time to First Edit（by turn） | -2.88%（2.0s 短縮） | 0.0271 | ○ favorable | -5.68%（3.9s 短縮） | 2e-5 | ● favorable |
| p95 Time to First Edit（by turn） | -1.93%（8.0s 短縮） | 0.1928 |
-（n.s.） |
-9.30%（38.8s 短縮） | 1e-10 | ● favorable |
| p50 total tokens（by user） | -2.54%（0.2M 減） | 0.3429 |
-（n.s.） |
-3.25%（0.3M 減） | 0.2094 |
-（n.s.） |
| p95 total tokens（by turn） | -5.19%（0.3M 減） | 0.0157 | ○ favorable | -7.64%（0.5M 減） | 0.0003 | ● favorable |
| Average tool calls（by turn） | -3.19%（0.77 回減） | 0.0091 | ○ favorable | -8.54%（2.04 回減） | 1e-12 | ● favorable |
出典: How Prompt Tuning Improved GPT-5.5 in VS Code の scorecard を Markdown 表に再構成。原典の grouped bar chart は元記事の figure（gpt55-metrics-comparison.svg）を参照してください。
5.3 パターン B の勝ちどころ
太字にした 3 行が パターン B の主戦場です。
-
p95 Time to First Edit -9.30%（38.8s 短縮, p=1e-10）: 上位 5% の重い turn で 38.8 秒 も短くなった。p=1e-10は極めて強い証拠。 -
平均 tool calls -8.54%（2.04 回減, p=1e-12）: 1 turn あたりの tool call が平均 2 回減った。これは agent が「読んだり検索したりする往復」を大きく削れた証拠。 -
p95 total tokens -7.64%（0.5M 減, p=0.0003）: 上位 5% の重い turn で total token を 7.64% 削減。system prompt 側は増えたのに、agent 側の動的な token 消費が大きく削れて net で減った ということ。
5.4 なぜプロンプトを長くしたのに token が減ったのか（筆者解釈）
ここから先の因果解釈は、元記事本文には明示されていない 筆者の解釈 です。scorecard の数字は元記事の一次情報ですが、「why」を私なりに読み解いた部分は分けて書きます。
- system prompt を長くすると 毎ターンの固定コスト（prompt token） は必ず増える。
- 一方で agent が edit → validate loop に 早く入る ようになり、re-search / re-read / re-plan の 動的な token 消費が大きく削れる 。
-
p95側（上位 5% の重い turn）で movement が特に強いのは、「過剰探索して失敗していた重い turn」ほど短縮効果が大きい と読める。normal な turn では動的 token の削減余地が小さいので、p50 は動きが穏やか（p50 total tokens は パターン B でも p=0.2094 で有意ではない）。 - つまり 「system prompt の固定コスト増 < 探索を早く止めることで削れる動的コスト」 という不等式が、実データで成立していた、というのがこの実験の要諦、と読めます。
5.5 唯一の懸念点
パターン B で唯一の unfavorable シグナルは 10-minute survival rate -0.44%（p=0.0493） で、ここは元記事も 正直に 認めている箇所です。
We treated that as a real tradeoff to weigh, but the movement was small and the other quality guardrail did not regress.
意訳: 「そこは注視すべきトレードオフとして正直に扱った。ただし movement は小さく、もう一方の quality guardrail（commit survival）は悪化していない」。commit survival 側は +0.68%（n.s.）で むしろ微プラス だったので、guardrail としては OK と判断したようです。この扱いはあとの 6 章で少し掘り下げます。
blog は最後にこう書いています。
So we shipped it: パターン B,
LargePromptSections, is now the default GPT-5.5 system prompt.
（だから出荷した。パターン B = LargePromptSections は現在の GPT-5.5 の default system prompt になっている）
5.6 「default」の意味
ここは少し実装よりの補足です。SHA 56d7412 の gpt55BasePrompt.tsx を素直に読むと、includeLargePromptSections / includeEconomicalSearchAndEdit は base class では両方 return false（つまり base 単体では control）です。
じゃあ パターン B が default になったってどういうこと？と思って追いかけると、endpoint に付いた experimentBasedConfig の flag（EnableGpt55LargePromptSections / EnableGpt55EconomicalSearchAndEdit）を Experimentation Service が見て、Gpt55LargePromptSectionsExp / Gpt55EconomicalSearchAndEditPromptExp を選ぶ構造になっています。
つまり 「パターン B が default になった」= コード上の default 値が変わったのではなく、Experimentation Service の割当が パターン B にロールアウトされた という意味合いです。public repo の SHA だけを見ても「今この瞬間 100% ロールアウトされている」ことは断定できません。blog 本文の So we shipped it を第一根拠として読む、という距離感が正確です。
6. 統計的優位性の読み方 - この blog の p 値は本気
この章では、上の scorecard の p 値をどう読むかを短く整理します。
日本語で p<0.05 の閾値定義を確認したい場合は、BellCurve 統計WEB / 検定統計量と棄却域・採択域 が読みやすいです。かいつまむと:
有意水準5%で検定する時、統計量tが次の図のt分布の水色部分に入る場合に帰無仮説 H_0 は棄却されます。両端の水色部分の面積は合わせると全体の5%であり、統計量tがこの部分に入るということは5%以下でしか起こらない極めて珍しい事象であると判定されます。
p<0.05 は「帰無仮説の下では 5% 以下でしか起こらない事象」、p<0.001 はさらに 50 倍厳しく「1000 回に 1 回以下でしか起こらない事象」です。この基準で今回の scorecard を読み直します。
- パターン B は主要 3 指標（p95 Time to First Edit / p95 total tokens / 平均 tool calls）が
p<0.001で、p=1e-10やp=1e-12のように 0 に張り付いています。これは A/B テストとしては 極めて強い証拠 です。 - 一方 10-minute survival の
p=0.0493は「0.05 を辛うじて割った」レベル。blog がここをreal tradeoff to weighと表現するのは、この p 値の弱さと effect size の小ささを両方見た上での判断です。
実務判断として重要なのは、「有意 vs 有意じゃない」の二値でなく、p 値の強さ × effect size × guardrail の悪化有無 を並べて見る点です。VS Code の判断は「主要 3 指標は極めて強い / unfavorable 1 指標は弱い有意で movement も小さい / もう一方の guardrail は悪化なし」の 3 点セットで default flip の GO を出しています。
個人で agent prompt をチューニングするとき、「なんか速くなった気がする」で終わってしまいがちなのは自分もそうです。「感覚で speed up した気がする」は p 値には勝てない。VS Code がこの粒度で回している、という事実自体が、prompt engineering を語るときの粒度感覚を引き上げてくれます。
7. 自分の .instructions.md にどう転用するか
この章は、この記事の実務パートです。VS Code の パターン B を、個人の copilot-instructions.md / .instructions.md にどう移植するかを、diff で見ていきます。
7.1 対応関係
パターン B の構造をそのまま自分の instructions に写経すると、こんな mapping になります。
| パターン B の tag | 自分の instructions で対応する section |
|---|---|
<Before_the_first_edit> |
## Before the first edit（anchor / hypothesis / cheap check / drift 回復） |
<After_the_first_edit> |
## After the first edit（validation の優先順位 / diff-only の禁止） |
7.2 サンプル: Before the first edit
## Before the first edit
- anchor: 対象 file / failing test / エラーメッセージ / 近傍の実装 のいずれかから開始する
- local hypothesis: 1 つに絞り、それを反証できる最短の check を先に決める
- 例: `pytest tests/foo.py::test_bar -x` / `curl -sSf <endpoint>` / `Get-Item <path>`
- 3 read 以内で hypothesis が固まらないなら、smallest reversible probe（小さく戻せる edit）を先に打つ
- local-routing budget を超えても検索が止まらなかったら、それは drift として扱う
- 回復手順: 現時点で最良の仮説 + 最良の近傍 check + smallest plausible edit に戻る
7.3 サンプル: After the first edit
## After the first edit
- edit の直後は、必ず 1 つの focused validation を回す（他の作業に進む前に）
- validation の優先順位:
1. 最も安い behavior-scoped / failing check（現仮説を反証できるもの）
2. 触った slice の narrow test
3. 触った slice の narrow compile / lint / typecheck
4. 上記が無いときの fallback として `git diff`（それ以外の意味では diff-only を validate と呼ばない）
- 最初の validation が fail してもすぐ scope を広げず、同じ slice を repair して同じ check を回し直す
7.4 既存 instructions への diff 例
私が普段使っている instructions がこちらの aktsmm/Agent-Customization / agent-context-efficiency.instructions.md で、## Gather / ## Act / ## Loop の周辺に Before / After を明示する section を差し込むと自然に馴染みます。以下は差分イメージ:
## Act
- 依頼された成果に必要な最小範囲だけ触る。
- ついでの整理、リネーム、広いリファクタ、不要な生成物を増やさない。
+
+## Before the first edit
+
+- 対象 file / failing test / エラーメッセージ / 近傍の実装 のいずれかから開始する。
+- 1 つの局所仮説と、それを反証できる 1 つの安価な check を先に決める。
+- local-routing budget を超えても検索が止まらないなら drift として扱い、smallest plausible edit に戻る。
+
+## After the first edit
+
+- edit の直後は、必ず 1 つの focused validation を回す。
+- validation の順序は failing check → narrow test → narrow compile/lint/typecheck → `git diff` (fallback)。
+- diff-only は「validate した」に含めない。
自分の userdata 側の agent-context-efficiency.instructions.md を書いた当時（2026 年前半）は、Gather / Act / Tools / Loop / Delegate / Report という切り方で書いていました。今回の パターン B と並べてみると、同じ方向の思想に偶然着地していた のが分かって少し嬉しかったです。ただ、Before / After the first edit という「edit を起点にした workflow」の切り方は自分の書き方には無かったので、これは正直、真似する予定です。
8. Continuous optimization - 「モデルリリースはチューニングの入り口」
この章では、blog の締めをどう受け取るかを短く。
blog の締めの一節はこう書かれています。
This experiment is one example of how we work with model providers beyond launch day. A model release is not the end of the tuning loop.
（この実験は、私たちがリリース当日以降も model provider と協働している一例だ。モデルのリリースは、チューニングループの終わりではない）
microsoft/vscode の extensions/copilot/src/extension/prompts/node/agent/openai/ を眺めると、gpt51Prompt.tsx / gpt52Prompt.tsx / gpt53CodexPrompt.tsx / gpt54ConcisePrompt.tsx / gpt54LargePrompt.tsx / gpt55*.tsx / gpt5CodexPrompt.tsx / gpt5Prompt.tsx / defaultOpenAIPrompt.tsx が並んでいて、モデル世代 × prompt variant で細分化されているのが分かります。一方 Anthropic / Gemini / xAI などは provider 毎の単一 file にまとまっていて、OpenAI 系だけがここまで細分化されているのは A/B テストの多さの反映と読めます。
将来、Before / After the first edit 構造が Anthropic 側にも横展開されるなら、それは anthropicPrompts.tsx の diff として見えるはずです（現時点でも Claude Opus 4.7 向けの experimental な alt prompt が既に入っています）。この repo は日常的に watch しておく価値があります。
個人開発者への示唆は次のようなものかなと思います:
- 「リリース直後の一発物モデル勝負」ではなく、「harness + prompt を回し続ける組織」が勝つ 時代になっている
- ユーザー側でも、自分の
.instructions.mdを「一度書いて終わり」ではなく 「A/B で回してみるべき人工物」 として扱う目線に切り替える価値がある - そのときの評価軸は、
感覚ではなくTime to First Edit / tool call 数 / token 数のような測れる指標に寄せる
まとめ
- VS Code チームは GPT-5.5 の default system prompt を、5 行の
<economical_search_and_edit>（パターン A）ではなく、<Before_the_first_edit>/<After_the_first_edit>の 2 tag 構造（パターン B）に切り替えた。 - 2 週間の live traffic で、
p95 Time to First Edit -9.30%（38.8s 短縮, p=1e-10）、平均 tool calls -8.54%（p=1e-12）、p95 total tokens -7.64%（p=0.0003）を強い統計的有意で達成し、quality はほぼ横ばい（10-minute survival だけが ぎりぎり有意で微減）。 - 「プロンプトを長くしたのに token 効率が上がった」のは、agent が edit-and-validate loop に早く入る ようになり、動的な over-exploration token が削れたから。system prompt の固定コスト増を、動的コスト減が上回ったと読める。
- 自分の
.instructions.mdにもBefore / After the first editの構造を持ち込めば、同じ原理で agent の無駄回りを削れる可能性がある。少なくとも「anchor / hypothesis / cheap check / validation の優先順位」を workflow として明示 することの効用は、この scorecard が支えてくれる。 - 使用量課金時代の勝ち筋は「もっと強いモデル」ではなく、「モデルを wander させない harness と prompt」の運用。
補足コメントや質問、いいね、拡散、ぜひお願いします 🥺！
間違っていたら 優しく 教えてください！
参考（一次情報）
- VS Code Blog: How Prompt Tuning Improved GPT-5.5 in VS Code（2026/07/06）
- 前提: Agent Harnesses in GitHub Copilot and VS Code（2026/05/15）
- 前提: Improving token efficiency in GitHub Copilot（2026/06/17）
- 実装 (パターン A):
gpt55BasePrompt.tsx#L172-L178 - 実装 (パターン B):
gpt55BasePrompt.tsx#L33-L62 - 関連 repo: microsoft/vscode
- 統計: BellCurve 統計WEB / 検定統計量と棄却域・採択域
- Copilot billing: Requests in GitHub Copilot (legacy)
- 筆者の instructions: aktsmm/Agent-Customization / agent-context-efficiency.instructions.md