※お役に立てたらストック、いいねをよろしくお願いします！！
＜📝本記事のターゲット層＞
- GitHub Copilotで複数モデルをどう選べばよいか迷っている開発者
- VS CodeでAIコーディング支援を日常的に使っているエンジニア
- コンテキストサイズやトークンの意味を初心者向けに理解したい人
- AIモデルのコストと性能のバランスを考えたい個人開発者・チームリーダー
- 大きな実装依頼をAIに投げると結果がぶれる理由を知りたい人
🔷はじめに
GitHub Copilotでは、選択できるAIモデルがかなり増えてきました。
OpenAI、Anthropic、Google、Microsoftなど、パブリッシャーだけでも複数ありますし、その中でもさらにモデルが分かれています。たとえば、GitHub Docsでは2026年6月時点で、GPT-5.4、GPT-5.4 mini、GPT-5.5、Claude Opus 4.6、Claude Opus 4.7、Claude Sonnet 4.6、Gemini 3.1 Pro、MAI-Code-1-FlashなどがGitHub Copilotの対応モデルとして掲載されています。
ここで迷いやすいのが、「結局どのモデルを選べばいいのか？」という点です。
高性能そうなモデルを常に選べばよい、という考え方もあります。しかし実際には、軽い質問や小さな修正に毎回高コストなモデルを使う必要はありません。一方で、複数ファイルにまたがる実装や設計変更を軽量モデルだけで進めようとすると、途中で文脈を見失ったり、指示の解釈が浅くなったりすることがあります。
そこで本記事では、GitHub Copilotにおけるモデル選択と、コンテキストサイズの考え方を整理します。読み終わるころには、「この作業なら軽量モデルで十分」「この実装は大きめのコンテキストを使ったほうがよい」と判断しやすくなるはずです。
※モデルの利用可否は、Copilotのプラン、クライアント、組織設定、ロールアウト状況によって変わります。必ず自分の環境でも確認してください。
🔷1. GitHub Copilotでモデルを選ぶ時代になった
以前のAIコーディング支援は、「Copilotに聞く」という感覚で十分でした。しかし現在は、「どのモデルに聞くか」まで考える時代になっています。
GitHub Copilotの公式ドキュメントでは、モデルごとにリリース状態、利用できるモード、対応クライアント、プランごとの利用可否などが整理されています。また、GitHub Docsでは、モデルによってスピード、コスト効率、精度、推論、マルチモーダル入力への強さが異なることも説明されています。
つまり、モデル選択は単なる好みではありません。
たとえば、同じ「修正してください」という依頼でも、以下のように作業の重さはまったく違います。
- 変数名を1つ直す
- TypeScriptの型エラーを1つ直す
- 既存設計に沿ってAPIを追加する
- 既存コードを読ませてアーキテクチャ改善案を出させる
- 大量のログと複数ファイルを見ながら原因調査をする
上の2つくらいであれば、軽量で速いモデルでも十分なことが多いです。しかし、後半のような作業では、推論の深さやコンテキストサイズが効いてきます。
▸モデル選択で見るべき観点
モデルを選ぶときは、まず次の4点を見ると整理しやすいです。
- 速度: すぐに返ってきてほしい作業か
- コスト: AIクレジットやプレミアムリクエストをどれくらい使ってよいか
- 推論力: 複雑な問題を深く考える必要があるか
- コンテキストサイズ: 多くのファイルや長い会話履歴を参照する必要があるか
この4つを意識すると、「何となく強そうなモデルを選ぶ」状態から抜け出しやすくなります。
🔷2. モデル選択の基本は、速さ・コスト・難易度で分ける
GitHub Copilotのモデル選択では、最初から細かいベンチマークを暗記する必要はありません。実務では、まず「通常使い」と「難しい作業」で分けるのが一番分かりやすいです。
🔹通常使いは軽量・高速寄りのモデルを選ぶ
日常的な開発では、すべての作業が難問というわけではありません。
たとえば、以下のような作業です。
- 小さな関数の作成
- 既存コードの説明
- 単純なリファクタリング
- コメントやREADMEのたたき台作成
- 1ファイル内の軽い修正
- コード補完に近い短い依頼
このような作業では、MAI-Code-1-FlashやGPT-5.4 miniのような、軽量・高速・低コスト寄りのモデルが候補になります。
Microsoft AIは米国時間2026年6月2日に、MAI-Code-1-Flashを発表しました。公式発表では、GitHub CopilotとVS Codeでの日常的な開発ワークフロー向けに作られた軽量なコーディングモデルと説明されています。さらにGitHub Changelogでも、MAI-Code-1-FlashはGitHub Copilot向けに設計・調整されたモデルであり、VS Codeからロールアウトが始まると案内されています。
つまり、MAI-Code-1-Flashは単に「Microsoftが作った小型のコーディングモデル」ではなく、GitHub CopilotやVS Codeの中で使うことを前提に最適化されたモデルとして捉えると分かりやすいです。Microsoft AI側でも、GitHub Copilotの本番環境で使われるハーネスを前提に訓練・評価したことが説明されており、実際の開発ワークフローとの相性を重視している点が特徴です。
特徴としては、簡単な依頼では簡潔に、難しい依頼ではより深く考える「adaptive thinking」が挙げられています。
🔹難しい実装では推論とコンテキストに強いモデルを選ぶ
一方で、次のような作業では軽量モデルだけだと厳しい場面があります。
- 複数ファイルにまたがる機能追加
- 既存設計を読み取ったうえでの実装
- 原因がはっきりしない不具合調査
- テスト失敗ログを見ながら修正方針を決める
- 大きめのリファクタリング
- 仕様書、設計書、コードを同時に読ませる作業
この場合は、GPT-5.4、GPT-5.5、Claude Opus系など、推論やコンテキストに強いモデルを検討するとよいです。
ただし、「このモデルが絶対に一番強い」と断定するのは注意が必要です。モデルの性能は、ベンチマーク、言語、コードベース、作業内容、プロンプトの書き方によって変わります。さらに、Copilot上で使えるモデルは、元モデルそのもののAPI利用時とはコンテキスト上限や提供条件が異なる場合もあります。
そのため本記事では、モデルの絶対順位を決めるよりも、作業内容に合わせて選ぶ考え方を重視します。
💡Tips: 迷ったときの選び方
迷ったら、まず以下のように考えると扱いやすいです。
| 作業内容 | 選び方の目安 |
|---|---|
| 1ファイル内の軽い修正 | 軽量・高速モデル |
| 既存コードの説明 | 軽量モデルから試す |
| 複数ファイルの実装 | 推論に強いモデル |
| 大きな設計変更 | 高性能モデル + 必要なら大きなコンテキスト |
| 長いログや設計書を読む | 大きめのコンテキストを検討 |
最初から最大火力で進めるのではなく、軽い作業は軽いモデル、重い作業は強いモデルに切り替えるのが実用的です。
🔷3. コンテキストサイズとは何か
モデル選択とセットで理解したいのが、コンテキストサイズです。
コンテキストサイズとは、AIモデルが一度に参照できる情報量の上限です。プロンプト、会話履歴、参照ファイル、開いているコード、ツール実行結果などは、すべてこの枠の中に入ります。
よく「コンテキストウィンドウ」とも呼ばれます。
🔹トークンは文字数とは違う
コンテキストサイズは、基本的にトークンという単位で表されます。
トークンとは、AIが文章を処理するための単位です。日本語の1文字が必ず1トークンになるわけではありませんし、英単語1つが必ず1トークンになるわけでもありません。文字、単語、記号、空白、コードの断片などが、モデル内部で扱いやすい単位に分解されます。
そのため、「何文字まで入るか」を厳密に言い切るのは難しいです。
たとえば「256kトークンで約600ページ」というような表現を見かけることがありますが、これはあくまで目安です。資料の形式、日本語か英語か、コードが多いか、空白や記号が多いかで変わります。記事内で使うなら、「おおよその感覚」として扱うのが安全です。
🔹コンテキストサイズは作業机の広さ
初心者向けに説明するなら、コンテキストサイズは「AIが作業机に広げられる資料の量」と考えると分かりやすいです。
机が広ければ、設計書、コード、エラーログ、会話履歴を同時に置けます。これは大きなメリットです。大規模なコードベースを読ませる場合や、長い仕様書を参照しながら作業する場合には、広い机が役に立ちます。
ただし、広い机に関係ない資料を大量に置くと、かえって必要な情報を見つけづらくなります。
AIでも同じです。コンテキストサイズが大きいほど便利ですが、不要な情報を渡しすぎると、回答がぶれたり、コストが増えたりします。大事なのは「たくさん渡すこと」ではなく、「必要な情報を必要な量だけ渡すこと」です。
🔹大きなコンテキストはコストにも影響する
GitHub Copilotの公式ドキュメントでは、一部の最新モデルで100万トークンの拡張コンテキストウィンドウを選べると説明されています。また、推論レベルを設定できるモデルもあります。
これは非常に便利ですが、同時に注意点もあります。GitHub Docsでは、大きなコンテキストウィンドウや高い推論レベルを選ぶと、AIクレジット消費に影響すると説明されています。そのため、通常は標準コンテキストと標準推論を使い、複雑なタスクだけ大きなコンテキストや高い推論レベルを使うことが推奨されています。
つまり、コンテキストサイズは大きければ常に正解、というものではありません。
普段は標準設定で進め、以下のような場合だけ拡張コンテキストを検討するとよいです。
- 仕様書とコードを同時に読ませたい
- 複数ファイルの依存関係を見てほしい
- 長いログをもとに原因調査したい
- 大きな設計変更の影響範囲を見てほしい
- 長い会話の流れを保ったまま作業したい
🔷4. 長い依頼で結果がぶれる理由
AIに長い依頼をすると、途中から回答がぶれたり、前提を忘れたように見えたりすることがあります。
これは、単にAIが不真面目だからではありません。コンテキストサイズには上限があり、長い会話や大量のツール実行結果が積み重なると、すべてをそのまま保持し続けるのが難しくなるためです。
GitHub Copilot CLIのコンテキスト管理ドキュメントでは、会話がコンテキストウィンドウ容量のおよそ80%に達すると、バックグラウンドでコンテキストの圧縮が始まると説明されています。また、ツール呼び出しを続けるために約20%のバッファを残すとされています。
圧縮は、長い作業を続けるために必要な仕組みです。しかし、圧縮は要約でもあります。大まかな流れは残っても、細かな制約や一度だけ出てきた条件が薄まる可能性があります。
たとえば、最初に次のように伝えたとします。
この修正では既存のAPIレスポンス形式を変えないでください。
ただし、内部の型定義は整理しても構いません。
長い会話の途中でこの条件が圧縮されると、「型定義を整理する」という部分は残っても、「APIレスポンス形式を変えない」という重要な制約が弱くなる可能性があります。すると、AIはよかれと思ってレスポンス形式まで変更してしまうかもしれません。
このような事故を減らすには、重要な条件を短く再掲することが大切です。
❓困ったときは: AIが前提を忘れているように見える
AIが途中から前提を外してきた場合は、以下のように整理して再指示します。
前提を再掲します。
- APIレスポンス形式は変更しない
- 内部の型定義は整理してよい
- 既存テストが通ることを優先する
この前提で、いまの修正方針を見直してください。
ポイントは、怒ることではなく、必要な前提を短く戻すことです。AIは文脈を扱いますが、長くなった文脈では情報の優先順位が下がることがあります。重要な条件は、作業フェーズごとに明示しましょう。
🔷5. 大きな作業はプロンプトを分割する
コンテキストサイズを意識すると、大きな依頼を1回で投げないほうがよい理由が分かります。
たとえば、以下のような依頼は一見便利ですが、AIにとってはかなり重いです。
このリポジトリ全体を読んで、設計上の問題を見つけて、
改善方針を考えて、実装して、テストも追加してください。
やってほしいことは分かりますが、調査、設計、実装、テスト、レビューが一度に入っています。途中で方針が変わる可能性もありますし、コンテキストも大きくなりやすいです。
この場合は、次のように分けるのがおすすめです。
🔹ステップ1: 調査だけ依頼する
まず調査だけしてください。
対象は src 配下です。
設計上の問題がありそうな箇所を3つまで挙げて、
根拠となるファイル名と理由を説明してください。
まだ実装はしないでください。
最初は実装させず、情報収集に集中させます。これにより、AIがどのファイルを見て、どのように判断したのか確認できます。
🔹ステップ2: 方針を決める
調査結果のうち、1つ目の問題だけ対応します。
既存APIのレスポンス形式は変えない前提で、
実装方針を2案出してください。
それぞれのメリット・デメリットも書いてください。
ここでは、実装前に選択肢を出させます。AIにいきなりコードを書かせるより、先に方針を確認したほうが手戻りが少なくなります。
🔹ステップ3: 実装する
方針Aで実装してください。
変更対象は最小限にしてください。
既存テストがある場合は更新し、なければ必要な単体テストを追加してください。
ここで初めて実装に入ります。対象と方針が決まっているため、AIも迷いにくくなります。
🔹ステップ4: レビューする
今回の変更をレビューしてください。
特に、APIレスポンス形式が変わっていないか、
既存仕様を壊していないか、
テスト観点に漏れがないかを確認してください。
最後にレビューを依頼します。実装した本人に見直させる形になりますが、観点を明示することで、一定のチェック効果が期待できます。
💡Tips: プロンプト分割の基本形
大きな作業では、以下の順番を使うと安定しやすいです。
- 調査して
- 方針を出して
- 実装して
- テストして
- レビューして
この分け方は、GitHub Copilotだけでなく、他のAIコーディングエージェントでも使いやすいです。AIに考える余白を渡しつつ、人間が途中で軌道修正できるのがメリットです。
🔷6. 実務でのおすすめ運用
ここまでの内容を踏まえると、GitHub Copilotのモデル選択は次のように運用すると扱いやすいです。
🔹普段は軽量モデルでテンポよく進める
日常的なコード補完、軽い質問、1ファイル内の修正では、軽量・高速寄りのモデルを使います。MAI-Code-1-FlashやGPT-5.4 miniのようなモデルは、この領域に向いています。
特に、VS Code内でサクサクやり取りしたい場合は、応答速度の体感が大事です。MAI-Code-1-FlashはGitHub CopilotとVS Codeでの利用を前提に設計・調整されているため、日常的なコード作業の第一候補として試しやすいモデルです。軽い作業で毎回重いモデルを使うと、コストだけでなくテンポも悪くなることがあります。
🔹難しい作業だけ高性能モデルに切り替える
設計変更、原因調査、複数ファイルの実装では、GPT-5.4/GPT-5.5やClaude Opus系などの高性能モデルを検討します。
ただし、ここでも「全部を一度に渡す」のではなく、必要なファイル、制約、ゴールを明確にします。高性能モデルでも、関係ない情報が多すぎると判断がぶれます。
🔹大きなコンテキストは必要なときだけ使う
100万トークン級の拡張コンテキストは魅力的ですが、普段から常用するものではありません。GitHub Docsでも、大きなコンテキストや高い推論レベルはAIクレジット消費に影響すると説明されています。
標準設定で足りる作業は標準設定で進め、長い仕様書や複数ファイルを同時に扱う場面でだけ拡張コンテキストを検討しましょう。
🔹モデル評価は自分のコードベースで試す
ベンチマークは参考になりますが、最終的には自分の作業で試すのが一番です。
たとえば、同じモデルでも以下の条件で体感は変わります。
- 使用言語
- フレームワーク
- コードベースの規模
- テストの有無
- 設計書やREADMEの整備状況
- プロンプトの具体性
- Copilotのプランやクライアント
そのため、チームで使う場合は「この作業はこのモデルがよかった」という実例をメモしておくと便利です。社内の開発環境に合ったモデル選択ルールが作りやすくなります。
✅まとめ
GitHub Copilotでは、AIモデルを選べること自体が大きなメリットです。しかし、選択肢が増えるほど、どれを選べばよいか迷いやすくなります。
本記事では、モデル選択とコンテキストサイズについて、以下の考え方を整理しました。
- 軽い質問や小さな修正は、軽量・高速・低コスト寄りのモデルを使う
- 複数ファイルの実装や設計変更では、推論やコンテキストに強いモデルを検討する
- コンテキストサイズは、AIが一度に参照できる情報量の上限である
- 大きなコンテキストは便利だが、コストと情報のノイズに注意する
- 長い依頼は「調査」「方針」「実装」「テスト」「レビュー」に分ける
- 重要な制約は、作業フェーズごとに短く再掲する
- モデル評価は、ベンチマークだけでなく自分のコードベースで判断する
迷ったら、まずはこう考えるのがおすすめです。
軽い作業は軽いモデル。
重い作業は強いモデル。
長い作業は分割。
大きなコンテキストは必要なときだけ。
GitHub Copilotは、モデル選択とコンテキスト管理を意識すると、かなり使いやすくなります。単に「AIに丸投げする」のではなく、作業に合わせてモデルとプロンプトを設計することで、結果の安定感が大きく変わります。
🔹参考URL
- GitHub Docs: Supported AI models in GitHub Copilot
- GitHub Docs: Models and pricing for GitHub Copilot
- GitHub Enterprise Cloud Docs: Managing context in GitHub Copilot CLI
- GitHub Changelog: MAI-Code-1-Flash is now available for GitHub Copilot
- Microsoft AI: Introducing MAI-Code-1-Flash
※お役に立てたらストック、いいねをよろしくお願いします！！