AIコーディングで「回答が返るまで時間がかかる」「大量のコードを読み込ませてトークンを消費する」「修正を何度もやり直す」と悩んでいませんか。
本記事では、VS Codeチームの取り組みとして注目されているAIコーディングを高速化し、トークン使用量を抑えるプロンプト改善の考え方を解説します。特定のモデルや未確認の性能数値を断定せず、GPT-5.5向けプロンプトにも応用できる設計原則、VS Codeでの実践手順、セキュリティ上の注意点を整理します。
なお、GPT-5.5の提供状況や対応機能、VS Code側の具体的な実装、料金は環境や時期によって異なる可能性があります。利用前には各公式ドキュメントで確認してください。
結論:AIコーディングは「詳しく書く」より「必要な情報だけ構造化する」
AIコーディングを速く省トークンにする基本は、プロンプトを長文化することではありません。目的、対象範囲、制約、出力形式、検証方法を明確に分け、モデルに不要なコンテキストを渡さないことが重要です。
特に効果を期待しやすいのは、次の5点です。
- 依頼を「調査」「実装」「テスト」「説明」に分割する
- 変更対象のファイルと範囲を限定する
- 既存コードを全文ではなく必要部分だけ参照させる
- 出力形式を指定し、不要な説明を抑える
- 実装後にテストや差分確認を必須にする
この方法は、GPT-5.5向けプロンプトに限らず、ChatGPT、Claude、Gemini、GitHub Copilotなど、各種LLMを使った開発にも応用できます。
VS Code式の改善で注目すべきポイント
1. タスクを小さく分解する
「このアプリを改善して」といった大きな依頼は、AIが広い範囲を調査し、長い説明や不要な変更案を返す原因になります。
まずは、次のように作業を分けます。
- 現在の実装を確認する
- 問題の原因を候補として整理する
- 変更方針を1つ選ぶ
- 対象ファイルだけを修正する
- テストを実行し、結果を確認する
実装前にいきなりコードを書かせるのではなく、調査と実装を分けると、誤った前提で広範囲を変更するリスクを抑えられます。
2. コンテキストを必要最小限にする
AIコーディングでは、モデルに渡すコードやログなどの情報をコンテキストとして扱います。情報が多いほど、必ずしも回答品質が上がるわけではありません。
次のような情報は、目的に必要な場合だけ含めます。
- 対象ファイルの関連する関数
- 呼び出し元と呼び出し先の最小限のコード
- 再現手順とエラーメッセージ
- 使用中の言語、フレームワーク、実行環境
- 守るべきAPIやデータ形式
リポジトリ全体を毎回説明するのではなく、最初に構造を確認し、次の依頼では変更対象を限定する流れが効率的です。
3. 出力の形式と長さを指定する
AIが長い説明を返す場合は、回答の形式を具体的に指定します。たとえば、原因調査では「原因候補を3つ以内」、実装では「変更ファイル名と差分の要点」、レビューでは「重大度・該当箇所・修正案」のように整理します。
プロンプトの例は次のとおりです。
例:原因調査
「TypeScriptのビルドエラーを調査してください。対象はsrc/auth/token.tsです。まず原因候補を最大3つ、各1〜2文で示してください。コード変更はまだ行わず、追加で確認すべき情報があれば最後に列挙してください。」
例:限定的な実装
「対象はsrc/auth/token.tsのrefreshToken関数だけです。既存の公開APIと戻り値の型を変更しないでください。必要最小限の修正案を提示し、変更理由を3項目以内で説明してください。実装後に実行すべきテストも示してください。」
このように、作業範囲と禁止事項を明示すると、不要なコード生成や説明を抑えやすくなります。
GPT-5.5向けプロンプトを使うときの考え方
「GPT-5.5向けプロンプト」という表現を見た場合も、モデル名だけで特別な書式が必要だと考えるのではなく、まずモデルが正しく判断するための入力設計として捉えると安全です。
モデルの提供状況、推奨設定、コンテキスト上限、料金、VS Codeとの連携方法は、公式発表や利用環境によって変わります。確認できない仕様や性能差を前提に、固定的なテンプレートや削減率を断定することは避けてください。
汎用的に使えるテンプレートは次の構成です。
- 目的:何を実現したいか
- 対象:どのファイル、関数、画面を扱うか
- 制約:変更してはいけない仕様や依存関係
- 作業:調査、提案、実装のどこまで行うか
- 出力:回答の形式、長さ、含める項目
- 検証:テスト、型チェック、ビルド、差分確認
この構造なら、特定のLLMに依存しすぎず、ChatGPTやClaude、Gemini、GitHub Copilotにも調整して利用できます。
VS Codeで実践する手順
ステップ1:目的と成功条件を決める
最初に「何を速くしたいのか」を決めます。たとえば、応答時間の短縮、入力トークンの削減、修正回数の削減、レビュー精度の向上では、必要なプロンプト設計が異なります。
「ログイン処理を改善する」ではなく、「期限切れトークンの更新時に重複リクエストを防ぎ、既存テストを通過させる」のように、成功条件を具体化します。
ステップ2:対象範囲を確認する
VS Codeの検索機能やシンボル参照を使い、対象関数、関連する型、テストファイルを特定します。AIに依頼する前に、人間が変更範囲を仮決めすると、不要なファイルをコンテキストへ含めずに済みます。
ステップ3:調査だけを依頼する
最初のプロンプトでは「変更しない」と明示し、原因や依存関係の確認に限定します。AIの提案が既存仕様と合っているかを確認してから、実装へ進みます。
ステップ4:小さな差分で実装する
複数の機能を一度に変更せず、1つの目的に対して小さな差分を作成します。差分が小さいほど、レビュー、ロールバック、テスト失敗時の原因特定が容易になります。
ステップ5:AIの回答ではなく実行結果で検証する
AIが「問題ありません」と説明しても、それだけで正しさは保証されません。プロジェクトの手順に従って、少なくとも関連テスト、型チェック、リンター、ビルドなどを実行し、Gitの差分も確認してください。
速さと省トークンを両立する比較ポイント
| 方法 | 期待できる効果 | 注意点 |
|---|---|---|
| 対象ファイルを限定する | 入力情報と調査範囲を減らせる | 関連ファイルを見落とす可能性がある |
| 依頼を段階分けする | 誤実装や不要な出力を抑えやすい | やり取りの回数が増える場合がある |
| 出力形式を指定する | 回答を短く整理できる | 必要な説明まで省かないようにする |
| 過去の会話を整理する | 古い前提や不要な文脈を減らせる | 必要な仕様は新しい依頼に再掲する |
| テストを先に定義する | 実装のゴールが明確になる | テスト自体の妥当性も確認が必要 |
単純に入力を短くすればよいわけではありません。重要な制約を削ると、やり直しが増えて結果的に時間とトークンを多く消費することがあります。不要な情報を削り、必要な情報は残すことがポイントです。
注意点と安全な使い方
機密情報をプロンプトに貼り付けない
APIキー、アクセストークン、パスワード、個人情報、顧客データ、非公開ソースコードを、利用規約や社内ルールを確認せず外部AIへ入力してはいけません。ログを共有する場合も、識別子や認証情報をマスキングしてください。
生成コードをそのまま本番投入しない
AIが生成したコードには、認可漏れ、入力値検証不足、依存ライブラリの誤用、競合状態などが含まれる可能性があります。セキュリティに関わる処理は、手動レビューとテストを行い、必要に応じて専門担当者が確認してください。
モデルの仕様や料金を思い込みで判断しない
モデル名、利用可能な機能、コンテキスト上限、API料金、VS Code拡張機能の対応状況は変更されることがあります。導入前に、利用するサービスとプランの公式情報を確認しましょう。
省トークンだけを評価指標にしない
トークン使用量が少なくても、誤答が増えて修正回数が増えれば効率化とはいえません。チームで導入する場合は、次の指標を組み合わせて評価します。
- タスク完了までの時間
- 追加修正の回数
- テストやレビューで見つかった問題数
- 入力・出力の使用量
- 開発者が内容を理解しやすいか
よくある質問
GPT-5.5向けプロンプトは専用の書き方が必要ですか?
提供元が公式に指定している作法がない限り、専用構文が必須とは限りません。目的、対象、制約、出力、検証を明確にする基本設計を使い、実際の環境で結果を比較してください。
プロンプトを短くすればトークンを節約できますか?
必ずしもそうではありません。必要な仕様まで削ると誤答ややり直しが増えます。不要な背景説明や重複したコードを減らし、成功条件と制約は残すのが基本です。
VS CodeでAIコーディングを使うとき、最初に何を設定すべきですか?
利用する拡張機能やAIサービスの公式ドキュメントを確認し、対象ワークスペース、除外ファイル、データ共有設定、組織の利用ルールを確認してください。設定名や対応範囲は拡張機能によって異なります。
まとめ
AIコーディングを速く省トークンにするには、モデルの性能だけに頼らず、入力する情報と作業手順を設計することが重要です。
- タスクを調査・実装・検証に分ける
- 対象ファイルとコンテキストを必要最小限にする
- 出力形式と変更禁止事項を指定する
- 生成結果ではなくテストと差分で確認する
- 機密情報や未確認の仕様をプロンプトに含めない
まずは、現在使っているプロンプトを「目的・対象・制約・出力・検証」に分解してください。そのうえで1つの小さな修正を対象に、回答時間、修正回数、テスト結果、トークン使用量を比較すると、自分の開発環境に合う改善点を見つけやすくなります。


コメント