GitHub Copilot in Visual Studio CodeのGPT-5.5プロンプト変更は、GPT-5.5のモデル本体やプロジェクトの仕様を変える更新ではありません。VS CodeがAgentへ渡すシステムプロンプトの既定動作を調整し、広範囲を調べ続けるよりも、根拠のある編集を早く行い、直後に検証するよう促す変更です。
通常の利用者は、既存コードの修正や設定移行を行う必要は基本的にありません。一方、GPT-5.5のAgentを使った社内評価、カスタム指示、MCPツール、自動承認を含むワークフローを運用している場合は、ツールの呼び出し順序や編集タイミングが変わる可能性があります。代表的なタスクを使った再テストが必要です。
VS Code Teamは2026年7月6日、OpenAIと実施した2週間の本番実験を基に、LargePromptSectionsと呼ばれる変更をGPT-5.5の既定システムプロンプトとして採用したと発表しました。狙いは「探索を減らし、検証を早める」ことです。(Visual Studio Code)
2026年7月6日のGPT-5.5プロンプト変更で何が変わったのか
今回の変更を理解するには、「モデル」と「コーディングハーネス」を分けて考える必要があります。
GPT-5.5は、受け取った情報を基に応答を生成する言語モデルです。一方、VS Codeのコーディングハーネスは、次のような処理を担当します。
- ワークスペースや会話履歴、カスタム指示をモデルへ渡す
- ファイル検索、編集、ターミナル、MCPなどのツールを提示する
- モデルのツール呼び出しを実行する
- 実行結果をモデルへ戻し、次の判断を促す
- Agentの思考、操作、観察というループを管理する
つまり、同じGPT-5.5でも、ハーネスがどのような指示とツールを渡すかによって、調査範囲、編集の速さ、テストの実行順序は変わります。今回変更されたのは、このハーネス内にあるGPT-5.5向けシステムプロンプトです。(Visual Studio Code)
新しい基本的な流れは、次のように整理できます。
具体的な手掛かりを探す → 局所的な仮説を立てる → 小さく編集する → すぐに狭い範囲で検証する
単に「深く考えない」ようにしたわけではありません。広範囲の探索を続ける代わりに、反証可能な仮説と検証方法を早い段階で決め、編集と検証を短いループで繰り返す設計です。
2つのプロンプト案を本番トラフィックで比較
実験では、GPT-5.5のAgentトラフィックを対照群と2つの変更案に分けています。
| グループ | 名称 | 変更内容 | 割り当て |
|---|---|---|---|
| 対照群 | PRPT_CTRL | 当時の既定プロンプト | 25% |
| Treatment A | PRPT_SRCH | 探索と編集を簡潔に行う短い指示を追加 | 25% |
| Treatment B | PRPT_LRG | 編集前と編集後の行動を明示的に再構成 | 25% |
残りの25%は、スコアカードの外で従来の既定プロンプトを使用しました。Treatment Aは、不要な探索を減らす短い注意書きを追加する方式です。Treatment Bは、最初の編集前と編集後を別々のセクションとして定義し、編集から検証までの流れ全体を制御します。(Visual Studio Code)
最終的に採用されたのはTreatment Bです。
旧プロンプトと新プロンプトの仕様差分
公開された実装を基に整理すると、主な差分は次のとおりです。
| 観点 | 従来の既定動作 | 新しいTreatment B | 実務への影響 |
|---|---|---|---|
| 調査の開始点 | 必要に応じて周辺を広く探索 | ファイル、シンボル、失敗したテストなど、最も具体的な手掛かりから開始 | 曖昧な依頼では最初の手掛かりが重要になる |
| 編集前の調査 | 編集に必要な情報を比較的広く収集する場合がある | 局所的な仮説と、それを否定できる安価な確認方法が決まるまでに限定 | リポジトリ全体の読み込みが減りやすい |
| 最初の編集 | 調査を続けてから編集することがある | 仮説、対象コード、確認方法、小さな修正案が決まったら編集へ進む | 最初の編集が早く表示されやすい |
| 確信が持てない場合 | 追加調査へ進みやすい | 元に戻しやすい小さな試験的変更も許容 | 小さく変更し、結果から判断する動きが増える |
| 編集直後の行動 | 追加調査や別箇所の編集へ進む場合がある | 最初の実質的な編集後、可能なら直ちに検証 | 誤りを早い段階で発見しやすい |
| 検証の優先順位 | タスクや状況によって変化 | 失敗条件の確認、狭いテスト、限定的なコンパイル・Lint・型チェックの順に優先 | 全体ビルドより対象範囲のテストを選びやすい |
git diffの位置付け | 変更内容の確認として利用 | 実行可能な検証がない場合の代替手段 | テスト可能なのに差分確認だけで終えることを避ける |
| 調査範囲の拡大 | 周辺の関連実装まで広がる場合がある | 局所的な経路を使い切るまでは広範囲へ戻らない | 横断的な問題では指示側で対象範囲を明示する必要がある |
公開実装では、具体的な手掛かりから反証可能な局所仮説を作り、最小限の編集を行うことが明示されています。最初の編集後は、利用できる場合に限り、対象を絞ったテストや型チェックなどを優先し、追加の探索より先に実行する構成です。(GitHub)
「すぐ編集する」ことと「無計画に編集する」ことは違う
新しいプロンプトは、根拠がない状態で編集を急がせるものではありません。編集へ進むために、少なくとも次の要素をそろえるよう促します。
- 対象となるファイル、シンボル、テストなどの具体的な手掛かり
- 不具合や期待動作に関する局所的な仮説
- 仮説が間違っていると判断できる確認方法
- 結果を観察できる小さな編集案
たとえば、ログイン障害についてリポジトリ全体を検索し続けるのではなく、失敗しているテストと認証処理の呼び出し元を確認し、対象関数を小さく修正して該当テストを再実行する流れです。
一方、複数パッケージにまたがるAPI変更や、フレームワークの大規模移行では、局所的な修正だけでは不十分な場合があります。そのようなタスクでは、利用者が最初から対象範囲と横断的な確認項目を指定する必要があります。
2週間の本番実験で確認された効果
Treatment Bと対照群の比較結果は、次のとおりです。マイナスは、時間、トークン、ツール呼び出しについては削減を表します。
| 指標 | Treatment Bの変化 | 統計的な評価 |
|---|---|---|
| 10分後のコード残存率 | -0.44%（-0.41ポイント） | p=0.0493 |
| コミット時のコード残存率 | +0.68%（+0.57ポイント） | 有意差なし |
| 最初の編集までの時間・p50 | -5.68%（3.9秒短縮） | 高い有意性 |
| 最初の編集までの時間・p95 | -9.30%（38.8秒短縮） | 高い有意性 |
| 総トークン・p50、ユーザー単位 | -3.25% | 有意差なし |
| 総トークン・p95、ターン単位 | -7.64%（約50万トークン削減） | 高い有意性 |
| 1ターン当たりの平均ツール呼び出し | -8.54%（2.04回削減） | 高い有意性 |
特に効果が大きかったのは、処理時間が長くなりやすい上位5%のタスクです。最初の編集までのp95時間は38.8秒短縮され、p95総トークンは7.64%、平均ツール呼び出しは8.54%減少しました。(Visual Studio Code)
コスト削減率として固定値を使わない
「GPT-5.5の利用コストが常に7.64%下がる」と解釈するのは適切ではありません。
7.64%の削減が確認されたのは、トークン消費量が大きい上位側のターンです。ユーザー単位の中央値は3.25%減少したものの、統計的な有意差は確認されていません。
そのため、予算計画で一律の削減率を見込むのではなく、長時間化しやすい大規模タスクの改善として捉えるべきです。GitHub Copilotの利用料金はモデルとトークン数からAIクレジットへ換算されるため、実際の効果はタスクの規模、コンテキスト長、推論設定によって変わります。(GitHub Docs)
プロンプトが長くても、総トークンは減らせる
Treatment Bでは、システムプロンプト自体に編集前・編集後の詳細な指示が追加されています。それでもp95総トークンが減少した点は重要です。
コストや速度を左右するのは、最初に渡すプロンプトの長さだけではありません。不要なファイル検索、同じコードの再読込、関連箇所の比較、繰り返されるツール出力もトークンを消費します。
今回の結果からは、最初の指示を多少詳しくしても、その後のAgentループを短くできれば、セッション全体では効率化できると読み取れます。
品質が全面的に向上したわけではない
コードのコミット残存率は0.68%上昇しましたが、統計的な有意差はありませんでした。一方、10分後のコード残存率は0.44%低下し、p=0.0493と有意水準をわずかに下回っています。
したがって、妥当な評価は「速度と効率は明確に改善し、品質指標はおおむね維持されたが、小さなマイナス信号は残っている」です。
最初の編集が速くなったことだけを成功基準にせず、テスト結果、修正のやり直し、変更範囲の妥当性も確認する必要があります。
既存実装との互換性
今回の変更では、インターフェース上の互換性とAgentの行動上の互換性を分けて判断することが重要です。
公開情報で示されている変更対象は、GPT-5.5用のシステムプロンプトとその選択処理です。プロジェクト形式、ソースコードの構文、拡張機能API、MCPの仕様変更は発表されていません。公開実装でも、GPT-5.5のエンドポイントを判定して専用プロンプトを選択する構成になっています。(GitHub)
| 対象 | 直接的な影響 | 対応 |
|---|---|---|
| 既存のソースコード | 低い | 移行作業は基本的に不要 |
| ビルド・テスト設定 | 低い | コマンド自体の変更は不要 |
| GPT-5.5のAgentセッション | 高い | 編集時期、検索範囲、検証順序を再確認 |
| GPT-5.5以外のモデル | 原則として低い | モデル固有の変更なので直接対応は不要 |
| インラインコード補完 | 直接影響しない | Agentとは別のモデル経路として扱う |
| Autoモデル選択 | 選ばれたモデルによる | GPT-5.5を検証するときは手動選択 |
| カスタム指示 | 挙動が変わる可能性あり | 代表タスクで再テスト |
| MCP・外部ツール | 呼び出し順序や回数が変わる可能性あり | ツール依存の処理を再テスト |
| BYOK・カスタムエンドポイント | 同一挙動とは限らない | 実際のプロバイダーとモデル識別を確認 |
| Agentの評価テスト | 基準値が変わる可能性あり | 旧結果と新結果を分けて管理 |
インラインコード補完には直接影響しない
公式発表の対象は、GPT-5.5のAgentトラフィックとAgent用システムプロンプトです。
GitHubの公式ドキュメントでも、Copilot Chatで選択するモデルを変更しても、インライン候補に使用されるモデルには影響しないと説明されています。コード入力中に表示される補完候補だけを利用している場合、今回の変更による直接的な対応は不要です。(GitHub Docs)
Autoを使った比較ではGPT-5.5に固定できない
Autoモデル選択では、タスクの複雑さやモデルの利用状況に応じて、リクエストごとに使用モデルが決まります。
2026年7月確認時点の公式Auto対応モデル一覧にはGPT-5.5が含まれていません。そのため、今回のプロンプト変更を検証するときは、AutoではなくモデルピッカーからGPT-5.5を明示的に選択する必要があります。Autoで生成された回答は、回答欄へマウスを合わせることで実際のモデルを確認できます。(GitHub Docs)
カスタム指示との組み合わせは再確認する
VS Codeのコーディングハーネスは、システムメッセージだけでなく、ユーザーの依頼、ワークスペース情報、会話履歴、ツール結果、カスタム指示なども組み合わせてモデルへ渡します。(Visual Studio Code)
たとえば、既存のカスタム指示に次のような内容がある場合は注意が必要です。
- 編集前にリポジトリ全体を調査する
- 関連ファイルをすべて読み終えるまで変更しない
- 最初に詳細な実装計画を作成する
- すべてのパッケージを比較してから修正する
新しいGPT-5.5プロンプトは、局所的な根拠がそろった段階で編集へ進むよう促します。カスタム指示との組み合わせによっては、以前より早く編集を始めたり、探索対象を絞ったりする可能性があります。
横断的な調査が必要なタスクでは、「対象パッケージをすべて列挙してから編集する」「公開APIへの影響を確認する」など、必要な工程を依頼文や受け入れ条件へ明記してください。
MCPや自動化はツールの順序を基準にしない
今回の実験では、1ターン当たりの平均ツール呼び出しが8.54%減少しました。
そのため、MCPツールを利用するAgentでは、次のような変化が起こる可能性があります。
- リポジトリ検索ツールを呼ぶ回数が減る
- 最初のファイル編集が早くなる
- 編集後すぐにテストツールを呼ぶ
- 周辺情報を取得するMCPツールが呼ばれなくなる
- 同じ目的でもツールの実行順序が変わる
ツール呼び出しの回数や順序を固定したテストは壊れやすくなります。「特定ツールを3回呼ぶ」といった実装依存の評価ではなく、「必要なテストを実行した」「指定した成果物を生成した」といった結果ベースの評価へ移行するのが安全です。
BYOKではCopilot標準経路と同一とは限らない
VS Codeでは、独自のAPIキーやカスタムエンドポイントを使ってモデルを追加できます。BYOKでもチャットやツールを利用できますが、モデルの識別方法、プロバイダー、対応API、Agent機能によって挙動は異なります。(Visual Studio Code)
今回の本番実験が対象としたのは、VS Code内のGPT-5.5 Agentトラフィックです。OpenAI互換のカスタムエンドポイントへ「GPT-5.5」という表示名を付けただけで、Copilot標準経路と同じプロンプトや挙動になるとは断定できません。
BYOKを利用している場合は、モデルピッカーの表示名だけでなく、実際のプロバイダー、モデルID、Agent対応、ツール呼び出し対応を確認してください。
GPT-5.5プロンプト変更の利用条件
GPT-5.5を明示的に使い、今回の変更を検証するための条件は次のとおりです。
| 確認項目 | 条件・注意点 |
|---|---|
| VS Codeのバージョン | GPT-5.5の最小バージョンとしてv1.117以降が案内されている |
| Copilotの利用環境 | GPT-5.5を選択できるプランとアカウントが必要 |
| モデルの公開状態 | GPT-5.5はGAとして掲載されている |
| モデル切り替え | 組織のポリシーで許可されている必要がある |
| ワークスペース | Restricted ModeではモデルピッカーがAutoのみになる |
| 利用モード | 今回の直接的な対象はAgent |
| モデル選択 | 検証時はAutoではなくGPT-5.5へ固定する |
| カスタムモデル | BYOKや拡張機能経由では挙動を別途確認する |
GitHubのモデル対応表では、VS CodeでGPT-5.5を利用するための最小バージョンとしてv1.117以降が示されています。ただし、この表はロールアウト状況により変わる可能性がある暫定的な情報です。実際の利用では最新の安定版へ更新するのが確実です。(GitHub Docs)
また、Copilot FreeとCopilot StudentはAutoモデル選択のみです。現在のAuto対応モデル一覧にGPT-5.5がないため、GPT-5.5を指定した検証には、手動でモデルを選べる利用環境が必要です。組織アカウントでは、管理者によるモデル利用やモデル切り替えの制限も確認してください。(GitHub Docs)
VS CodeでGPT-5.5を確認する手順
- VS Codeを
v1.117以降へ更新します。 - 検証用のブランチまたはGit worktreeを用意します。
- 内容を確認済みのワークスペースを開きます。
- Copilot Chatを開き、Agentを選択します。
- 入力欄のモデルピッカーを開きます。
GPT-5.5を明示的に選択します。- 推論レベルやコンテキスト長を検証中は固定します。
- ツール、MCP、承認設定を確認してからタスクを実行します。
- Changesビューや差分エディターで変更内容を確認します。
- 対象テストに加えて、必要な統合テストを実行します。
モデルピッカーにGPT-5.5が表示されない場合は、Manage Language Modelsからモデルの表示状態、プロバイダー、Agent対応、課金情報を確認できます。未信頼ワークスペースではモデル一覧がAutoだけになるため、信頼する前にプロジェクトの内容を確認してください。(Visual Studio Code)
公式発表では、Treatment Bを利用者が個別にオンにする設定は案内されていません。GPT-5.5の既定システムプロンプトとして採用されたため、一般利用者が旧プロンプトと新プロンプトを切り替えてA/Bテストすることは想定されていません。
比較する場合は、過去に保存した評価結果やログを基準にするか、同じタスクを他モデルでも実行して違いを確認します。
テスト時に固定すべき条件
Agentの応答は毎回完全に同じにはなりません。プロンプト変更の影響を調べるときは、モデル以外の条件を可能な限り固定してください。
| 条件 | 固定方法 |
|---|---|
| ソースコード | 同じコミットから検証を開始する |
| 作業状態 | 各試行で変更のないクリーンな状態へ戻す |
| 会話履歴 | 試行ごとに新しいチャットを作る |
| モデル | GPT-5.5へ明示的に固定する |
| 推論設定 | Thinking Effortを同じ値にする |
| コンテキスト長 | 通常または拡張のどちらかへ統一する |
| Agent権限 | 同じPermission Levelを使う |
| ツール | 有効な組み込みツールとMCPを統一する |
| カスタム指示 | 同じ指示ファイルを使用する |
| 開いているファイル | 可能な限り同じ状態にする |
| 依存関係 | 同じロックファイルとインストール状態を使う |
| テストデータ | 同じ初期データを使用する |
| ユーザー依頼 | 文面を一字一句そろえる |
推論レベルを高くすると、思考用のトークンとAIクレジット消費量が増える可能性があります。プロンプト変更の効果を比較するときに推論レベルまで変えると、時間やコストの差を切り分けられません。(Visual Studio Code)
評価で記録すべき指標
公式実験の指標をそのまま再現する必要はありません。チーム内の検証では、次の項目を記録すると実務上の変化を判断しやすくなります。
| 指標 | 確認する内容 |
|---|---|
| 最初の編集までの時間 | Agent開始から最初の差分が出るまで |
| タスク完了時間 | 依頼から最終回答まで |
| 検索・読込回数 | 不要な探索が減っているか |
| ツール呼び出し回数 | 効率化と調査不足の両方を確認 |
| 編集ファイル数 | 意図せず範囲が広がっていないか |
| 最初の検証内容 | 編集直後に対象テストを実行したか |
| 単体テスト | 変更対象の機能が動作するか |
| 統合テスト | 局所修正が周辺機能を壊していないか |
| Lint・型チェック | 静的な問題がないか |
| 差し戻し量 | Agentの変更をどの程度Undoしたか |
| 追加修正回数 | 人間による手直しが増えていないか |
| AIクレジット | 長いタスクの消費量が減っているか |
1回の実行だけで良否を判断しないことも重要です。実用的な社内確認であれば、バグ修正、機能追加、リファクタリングなどの分類ごとに5～10件程度の代表タスクを用意し、中央値と失敗例を確認します。
新しいプロンプトで失敗しやすい場面
| 失敗例 | 起こり得る原因 | 対策 |
|---|---|---|
| 最初の編集は速いが修正箇所が違う | 依頼に具体的な手掛かりがない | 対象ファイル、関数、失敗テストを指定する |
| 単体テストは通るが別パッケージが壊れる | 局所的な検証だけで完了した | 受け入れ条件に統合テストを含める |
| 関連実装の一部を見落とす | 広範囲の探索を抑えた | 対象ディレクトリや公開APIの調査を明示する |
git diffだけで完了する | 実行可能な検証方法が見つからない | 実行すべきテストコマンドを依頼文へ書く |
| 不要な修正が残る | 小さな試験的編集を元に戻していない | 最終差分と不要コードの確認を指示する |
| 検証コマンドが外部環境へ影響する | 編集後の検証を早く実行する | テスト環境、dry-run、承認制御を利用する |
| MCPツールが呼ばれない | 近傍情報だけで編集へ進んだ | 必須ツールと取得すべき情報を明示する |
| コスト削減が確認できない | 中央値では有意差がなく、設定も異なる | 推論設定を固定し、長時間タスクを分けて分析する |
公式スコアカードでも、ツール呼び出しが少ないことは効率化を示す一方、少なすぎる場合は調査不足になる可能性があると説明されています。回数だけで評価せず、必要な検証が完了したかを確認してください。(Visual Studio Code)
GPT-5.5へ渡す依頼文の改善例
新しいプロンプトでは、具体的な手掛かりと検証方法を与えるほど、意図した局所仮説を作りやすくなります。
次のような依頼は、対象と完了条件が曖昧です。
ログイン時のエラーを直してください。より再現性を高めるには、次のように指定します。
src/auth/refresh.ts の refreshSession() を調査してください。
アクセストークンの期限が切れた直後、リフレッシュトークンが有効でも
401が返る問題があります。
tests/auth/refresh.test.ts の
「expired access token with valid refresh token」が失敗しています。
要件:
- 既存の公開APIは変更しない
- 関係のないファイルは編集しない
- 修正後に該当テストを実行する
- npm run typecheck も実行する
- 最後に変更ファイルと検証結果を示す大規模な変更では、局所化しすぎないように調査範囲も指定します。
packages配下にある認証APIの利用箇所をすべて確認してから編集してください。
公開API、型定義、テスト、ドキュメントへの影響を一覧化し、
変更計画を提示した後に実装してください。「探索を減らす」という新しい既定動作に任せきるのではなく、必要な探索を受け入れ条件として明文化することがポイントです。
Agentの検証を安全に行うための管理策
新しいプロンプトでは、最初の編集と検証コマンドの実行が早まる可能性があります。編集の高速化に合わせて、承認と隔離の設定も確認してください。
VS Codeの公式セキュリティガイドでは、未信頼プロジェクトをRestricted Modeで開くこと、変更を差分で確認すること、権限をセッション単位に限定すること、MCPサーバーを信頼前に確認することが推奨されています。(Visual Studio Code)
本番に近い環境では自動承認を避ける
ターミナルやMCPの自動承認を広く許可すると、Agentが編集後すぐに次の操作を実行できます。
特に注意が必要なのは、次のようなコマンドです。
- データベースのマイグレーション
- クラウド環境へのデプロイ
- ファイルの一括削除や置換
- パッケージの公開
- 外部APIへの書き込み
- 実データを使用する統合テスト
- 認証情報や環境変数を読み取る処理
通常の検証ではDefault Approvalsを使用し、ターミナルやMCPの許可はセッション単位に限定します。危険性のある処理を含む場合は、コンテナやAgent sandboxingを利用してください。
VS Codeはファイル変更、ターミナル、MCP、URLアクセスについて承認機能を提供していますが、全体自動承認やAutopilotでは手動確認が省略されます。自動承認のコマンド解析はベストエフォートであり、複雑なシェル構文やエイリアスには限界があります。(Visual Studio Code)
チームでは段階的に適用する
組織でGPT-5.5 Agentを利用している場合は、次の順序で確認すると安全です。
- 代表的なリポジトリを1つ選ぶ
- バグ修正、リファクタリング、横断変更の評価タスクを用意する
- GPT-5.5へモデルを固定する
- カスタム指示とMCPを本番と同じ構成にする
- 人間による差分確認を必須にする
- テスト成功率、差し戻し、AIクレジットを記録する
- 問題がなければ対象チームを段階的に広げる
評価基準を更新するときは、以前の結果を上書きしないでください。「旧既定プロンプト」「2026年7月以降の既定プロンプト」のように期間を分けて保存すると、バックエンド側の変更による差を追跡できます。
対応が必要かを判断する基準
| 利用状況 | 対応要否 | 推奨する対応 |
|---|---|---|
| Copilotのインライン補完だけを使っている | 原則不要 | 通常どおり利用する |
| GPT-5.5以外のAgentを使っている | 低い | モデル固有の更新として経過を確認する |
| GPT-5.5 Agentで一般的な開発をしている | 軽微 | 最新版へ更新し、代表タスクを数件確認する |
| GPT-5.5の評価結果をKPIにしている | 必要 | 変更前後の基準値を分けて再測定する |
| カスタム指示を多用している | 必要 | 探索範囲と編集タイミングを再確認する |
| MCPや社内ツールを組み込んでいる | 必要 | ツールの必須実行と成果物を結果ベースで検証する |
| ツール呼び出し順序をテストしている | 必要 | 回数・順序ではなく完了条件による評価へ変更する |
| 自動承認やAutopilotを利用している | 優先度が高い | 権限、サンドボックス、機密ファイル保護を見直す |
| インフラやDB変更をAgentへ任せている | 優先度が高い | dry-run、手動承認、隔離環境を必須にする |
| Copilotのコストを管理している | 必要 | 平均値だけでなく長時間タスクの上位側を監視する |
| BYOKや独自エンドポイントを使っている | 必要 | 標準Copilot経路と分けて検証する |
まとめ：最初に行うべき3つの対応
GitHub Copilot in Visual Studio CodeのGPT-5.5プロンプト変更は、既存コードやAPIを移行するための更新ではありません。GPT-5.5 Agentの探索、編集、検証の順序を調整する行動上の変更です。
通常利用では、次の3つを実施すれば十分です。
- VS Codeを
v1.117以降へ更新し、GPT-5.5を手動で選択する - 同じコミットと同じ依頼文で、代表的なタスクを複数回テストする
- 最初の編集速度だけでなく、テスト結果、変更範囲、差し戻し、ツール実行を確認する
カスタム指示、MCP、自動承認を利用しているチームは、移行作業ではなく「行動回帰テスト」が必要です。特に、広範囲の調査を前提とするタスクでは、対象範囲、必須ツール、統合テストを依頼文へ明示してください。
今回の更新は、Agentが長く考えること自体を減らすのではなく、根拠のある小さな編集と実行可能な検証へ早く到達させるものです。必要な安全策と受け入れ条件を整えれば、GPT-5.5の速度向上を活かしながら、調査不足や局所最適化のリスクを抑えられます。
コメント