AIにコードを書かせていて、「なんだか遠回りしているな」と感じたことはないでしょうか。あれこれ検索して、ファイルを読み返して、なかなか本題の修正に入らない。その「遠回り」は、時間だけでなく、いまや請求額にも跳ね返ってきます。ではもし、AIそのものは変えずに、渡す指示書の書き方だけで、その無駄を減らせるとしたら――。VS CodeとOpenAIが2週間かけて実際に試した、その舞台裏の記録です。
VS Codeチームは2026年7月6日、OpenAIと共同で実施したGPT-5.5のシステムプロンプト調整実験を公開しました。
VS Code上で2週間、GPT-5.5エージェントのトラフィックを対照群1と処置群2に25/25/25で分割し、探索を減らし検証を早める仮説を検証しました。処置群Aは探索を抑える単一のリマインダーを加え、処置群Bはワークフローを「最初の編集の前」「最初の編集の後」に再構成しました。処置群Bはp50の最初の編集までの時間を5.68%（3.9秒）、p95を9.30%（38.8秒）短縮し、p95総トークンを7.64%、平均ツール呼び出し数を8.54%削減しました。10分生存率は0.44%低下しました（p=0.0493）。VS Codeは処置群B（LargePromptSections）をGPT-5.5のデフォルトのシステムプロンプトとして採用しました。
From: How Prompt Tuning Improved GPT-5.5 in VS Code
【編集部解説】
いま私たちがこの記事に注目するのは、そこにAI開発の「潮目の変化」が凝縮されているからです。これまでモデルの性能向上といえば、より大きな学習・より賢いモデルという話でした。しかしこの実験が示しているのは、モデルそのものには一切手を入れず、モデルへの「指示書」の書き方だけを変えて、速度・コスト・品質を同時に動かしたという事実です。舞台は本番環境、被験者は実際の開発者たちでした。
背景を押さえると、この記事の切実さが見えてきます。GitHub Copilotは2026年6月1日から、月額固定の「プレミアムリクエスト」制を廃止し、トークン消費量に応じた従量課金へ移行しました。エージェントが無駄に費やしたトークンは、そのまま利用者の請求額に跳ね返ります。VS Code側はこの転換の直前から、トークン削減の施策を矢継ぎ早に投入してきました。今回の実験は、その一連の流れの最新章にあたります。
ここで理解の鍵になるのが「ハーネス（harness）」という考え方です。同じエンジンでも、車体やサスペンションが違えば走りが変わります。ハーネスとは、モデルというエンジンを、ツールや文脈、指示、実行ループへとつなぐ「車体」に相当します。今回チューニングされたのは、その車体に貼る一枚の指示書、システムプロンプトでした。
実験の核心は、拍子抜けするほど素朴な仮説にあります。エージェントは、コードを直す前に「探しすぎ・読み返しすぎ」なのではないか、というものです。そこで「証拠を集める→行動する→検証する」という流れを意図的に踏ませ、うろつく時間を減らそうと試みました。処置群Aは一言のリマインダーを添えるだけ、処置群Bはワークフロー全体を「最初の編集の前」「最初の編集の後」という章立てに再構成する、より大がかりな改変でした。
結果として全面採用されたのは、プロンプトを長くしたはずの処置群Bでした。ここに逆説があります。指示書を増やせば、その分だけ読み込むトークンは増えます。それでも全体の消費が減ったのは、無駄なうろつきを削った効果が、指示書の増量分を上回ったからです。「構造を足して、総量を減らす」というこの結果は、プロンプト設計の常識を一つ更新するものだと言えるでしょう。
一方で、この記事を額面どおり受け取る前に、私たちが公平のために付け加えておきたい点があります。VS Code側は品質面での小さな後退にも触れています。処置群Bでは「10分後もコードが残っている率」がわずかに下がり、その動きだけは統計的な有意水準をかろうじて越えました（p=0.0493）。効率面の圧勝（p値が1e-10や1e-12という桁）に比べれば、この有意性はぎりぎりの水準です。開発元自身が「注視に値する唯一の動き」と認めており、速さと安さの裏で、コードの定着に微細な代償があった可能性は、読者として頭の片隅に置いておくべきでしょう。
この技術で何が変わるのか。最も直接的な恩恵は、AIコーディングの「体感」と「財布」の両方が軽くなることです。最初の編集が数秒早く届き、重い処理（遅い方から5%のケース）では最大で38.8秒も短縮される。待ち時間は体感の速さに、削減されたトークンは請求額に、それぞれ効きます。従量課金時代には、その両方が同時に軽くなることの意味は小さくありません。しかも、その改善は利用者が何かを設定し直す必要のない、ハーネス側の自動的なアップデートとして届けられます。
より長期的な視点で見ると、この記事は「モデルの発売日が到達点ではない」という思想の表明でもあります。VS Code側は、モデル提供元との協働をローンチ後も継続し、本番データを見ながら小さな改善を積み重ねる姿勢を明言しました。フロンティアモデルの生の性能で競う時代から、それをいかに賢く「乗りこなす」かで差がつく時代へ。競争の重心が静かに移りつつあることを、この事例は物語っています。
潜在的なリスクにも目を向けておきましょう。プロンプトによる最適化は、突き詰めればコスト削減の圧力と表裏一体です。「探索を減らせ」という指示が行き過ぎれば、本来は丁寧に調べるべき場面まで拙速になりかねません。品質指標のわずかな低下は、その微かな予兆とも読めます。効率と徹底のあいだで、どこに針を置くのか。この綱引きは、これからのAIツール設計に通底する問いになっていくはずです。
規制や業界への波及も見逃せません。トークン量が請求額に直結する構造は、AIツールを「従量制の公共インフラ」に近づけます。利用者が自分の消費量を把握できる透明性が求められる一方で、事業者が効率化を口実にサービス品質へ手を入れる余地も生まれます。今後は、性能競争だけでなく「コストの説明責任」が、ツール選定の新たな軸になっていくと考えられます。
この実験の本当の面白さは数値の勝敗ではなく、その方法論にあります。仮説を立て、まずオフラインで検証し、次に本番トラフィックで対照実験を回し、勝者だけを残す。人間が判断の主体であり続けながら、AIを賢く鍛える。この地道な反復こそ、テクノロジーが人類の進化と歩幅を合わせていくための、ひとつの誠実な作法なのではないでしょうか。
【関連記事】
Microsoft ナデラCEO「学習は外注できない」—AI独占への問いとCopilot新戦略（内部） トークン従量課金でコストが膨張する逆説を論じた記事。本記事が扱う効率化の急務という背景と直結する。
OpenAI「Codex」が示すエージェント型AIへの転換、社内トークン99.8%・非開発者137倍の衝撃（内部） エージェント型AIとトークン消費の劇的変化を数値で扱った記事。ハーネス最適化と対をなす利用実態編だ。
Visual Studio Code 1.109リリース、複数AIエージェントの並列実行が可能に（内部） VS Codeがエージェント統合基盤へ進化した前段の記事。今回の単一エージェント効率化と系譜でつながる。
【編集部後記】
この記事を読んでいて、ふと自分の仕事のことを考えてしまいました。何かを調べ始めると、つい念のためにと関連情報を広げすぎて、肝心の一歩がなかなか踏み出せない。あの感覚は、今回のAIの「探しすぎ」と、どこか地続きな気がします。
面白いのは、解決策が「もっと賢いAIを待つ」ではなく、「手元の指示の出し方を見直す」だったことです。しかも指示を増やしたほうが、かえって全体は軽くなった。足し算が引き算になるこの逆転は、道具との付き合い方を考えるうえで、けっこう示唆に富んでいるように思います。
一方で、速く安くなった裏で、コードの定着率がわずかに下がっていた点も、目をそらさずにおきたいところです。効率を求めれば、どこかで丁寧さと引き換えになる瞬間が来る。その線引きをどこに置くかは、AIに任せきりにはできない、私たち自身の判断が残る領域なのだと思います。
みなさんが日々AIに投げている指示は、探させる向きでしょうか、それとも動かす向きでしょうか。ちょっとした言い回しの差が結果を変えるなら、次に何かを頼むとき、その一行を少し工夫してみたくなります。もし試してみて発見があったら、ぜひ聞かせてください。
【用語解説】
コーディングハーネス（coding harness）
モデル（AIエンジン）を、ツール・文脈・指示・エージェントループへとつなぐ「接続層」を指す。同じモデルでも、このハーネスの設計次第で、コーディング作業の速度や精度、コスト効率が変わる。今回の記事は、このハーネスに含まれる指示書を調整した事例である。
システムプロンプト（system prompt）
モデルに対してあらかじめ与える「基本の指示書」のこと。ユーザーが打ち込む個別の指示とは別に、エージェントの振る舞い方を土台から規定する。今回チューニングの対象になったのは、GPT-5.5向けのこの指示書だった。
エージェント（agent）／エージェントループ
人間が一手ずつ指示するのではなく、モデル自身が「検索する・ファイルを読む・コードを編集する・検証する」といった行動を自律的に繰り返して作業を進める仕組みを指す。この行動の反復がエージェントループである。
トークン（token）
大規模言語モデルが入力・出力を処理する最小単位で、単語やその一部に相当する。処理するトークンが多いほど計算コストと待ち時間が増える。従量課金の下では、トークン量がそのまま費用に直結する。
従量課金（usage-based billing）
定額制ではなく、実際に消費した量（ここではトークン量）に応じて課金する方式。GitHub Copilotが2026年6月1日に移行した。エージェントの無駄な動作が請求額に反映されるため、効率化の意義が増した。
A/Bテスト／対照群（control group）・処置群（treatment group）
複数の条件を同時に走らせ、結果を統計的に比較する実験手法。変更を加えない基準が対照群、変更を加えた検証対象が処置群である。今回は対照群1・処置群2の三分割で実施された。
オフライン評価（offline evaluation）
本番環境に投入する前に、あらかじめ用意したタスク群で変更の効果を検証する工程。今回は二つの案がともにオフラインで有望と判断され、その後に本番トラフィックで検証された。
p値（P-value）
観測された差が偶然によって生じた可能性の低さを示す統計指標。値が小さいほど、その差は偶然ではない（統計的に有意である）と判断される。記事中では0.05や0.001が有意性の目安として使われている。
レイテンシ（latency）
処理の応答時間を指す。記事では「最初の編集がコードに着地するまでの時間（Time to First Edit）」として計測されている。p95は「遅い方から5%」の裾側の遅延を示す指標である。
生存率（survival rate）
AIが書いたコードが、その後も削除・書き換えられずに残っている割合。コードが実際に「定着」したかを測る品質の代理指標で、10分後の残存率と、gitコミットまで到達した率の二種類が用いられている。
グラウンデッド（grounded）な編集
「地に足のついた編集」の意。当て推量ではなく、具体的な根拠（証拠）に基づいて行われる編集を指す。記事の仮説は、うろつく探索を減らし、この根拠ある編集へ早く到達させることにあった。
【参考リンク】
Visual Studio Code（公式サイト）（外部） Microsoftが開発・提供する、無償で軽量なオープンソースのコードエディタ。本記事の発信元である。
GitHub Copilot（公式サイト）（外部） GitHubが提供するAIコーディング支援サービス。今回の課金制度変更や効率化施策の中心にある。
OpenAI（公式サイト）（外部） 今回の実験でVS Codeと協働した、GPT-5.5の開発元。モデル側の専門知見を提供した。
gpt55BasePrompt.tsx（実装ソース／GitHub）（外部） 記事が実装詳細として参照するVS Codeの公開リポジトリ。処置群A・Bのプロンプト定義を含む。
【参考記事】
Improving token efficiency for GitHub Copilot in VS Code（外部） 本実験の前提となる公式記事。総トークンをGPT-5.4で8.97%、GPT-5.5で10.92%削減したと報告する。
GitHub Copilot is moving to usage-based billing（The GitHub Blog）（外部） 2026年6月1日の従量課金移行を告知した一次発表。トークン消費に基づく課金体系を明示する。
VS Code Curbs Token Use Ahead of Copilot’s Billing Switch（Visual Studio Magazine）（外部） 第三者視点の報道。ツール検索機能だけで最大20%のトークン削減が得られると解説する。
GitHub Copilot Pricing Change: June 2026 Token-Based Billing（Sourcetrail）（外部） 月額が39ドルから800ドル超へ急増した事例に触れ、制度変更の衝撃を伝える論考である。
OpenAI GPT-5.5 Benchmark（CodeRabbit）（外部） GPT-5.5を実地検証。制約と成功基準が明確なとき最も強いという特性を裏づける記事である。
Using GPT-5.5 / Prompt guidance（OpenAI API 公式ドキュメント）（外部） OpenAI公式の運用指針。成果起点のプロンプトが有効で、少ない推論トークンで到達すると説く。
