情報の基準日：2026年11月6日（日本時間）
各社の公式発表・公式ドキュメントを基に整理しています。プレビュー機能や利用条件、価格、モデル提供状況は変更される可能性があります。
はじめに：AI駆動開発の主役が変わりつつある
少し前まで、開発でAIを使うといえば「コードを補完する」「わからない処理を質問する」という使い方が中心でした。
しかし2026年11月現在、開発環境は大きく変わっています。
- AIがリポジトリを調査し、計画を立て、複数ファイルを修正し、テストまで進める
- 同じ開発タスクを複数のモデル・エージェントで比較できる
- エージェントがクラウドや別マシンで動き、スマートフォンから作業を引き継げる
- 一方で、権限管理・情報漏えい・レビュー・コストの重要性が増している
重要なのは「どのモデルが一番賢いか」だけでなく、AIに何を任せ、どう検証し、安全に運用するかです。
本記事では、特にVS Code・GitHub Copilot・Codex・Claude Code・Geminiを使う開発者向けに、最新の動きを8つに絞って紹介します。
1. 主要AIモデルが更新。「1モデル固定」の運用を見直す時期に
2026年9〜10月にかけて、開発者向けの主要モデルが相次いで更新されました。
| 提供元 | 注目モデル | 公式発表・提供の動き | 開発で注目したい用途 |
|---|---|---|---|
| OpenAI | GPT-6.1 Sol | 9月29日のDevDayで紹介 | エージェント型コーディング、複雑な作業の遂行 |
| Anthropic | Claude Opus 5.5 | 9月22日発表 | 複雑な設計、長い工程を伴う作業の検討 |
| Anthropic | Claude Sonnet 5.5 | 9月28日発表 | 日常的な実装、バグ修正、反復作業 |
| Anthropic | Claude Haiku 5.5 | 10月7日発表 | 高頻度・軽量なタスク |
| Gemini 4 Argon | 10月13日から開発者向けに提供 | 複雑なコード移行、長期的な推論、開発ワークフロー |
OpenAIは、GPT-6.1 Solをエージェント型コーディングに強いモデルとして紹介しています。Claude 5.5シリーズは、Opus・Sonnet・Haikuの役割を分けやすい構成です。GoogleのGemini 4 Argonも、複数段階のソフトウェア開発を主な用途として打ち出しています。
なお、GoogleはGemini 4 Carbonも発表していますが、11月6日時点では限定的な事前テスト段階です。一般の開発者がArgonと同じようにすぐ利用できる、と捉えないようにしましょう。
実務ではどう選ぶ？
私は、モデルを「会社名」ではなくタスクの性質で選ぶことをおすすめします。
| タスク | モデル選択の考え方 |
|---|---|
| 単純な修正、テストケース追加、コード説明 | 速度・費用を優先し、軽量モデルから試す |
| 複数モジュールにまたがる改修 | 高性能モデルに影響範囲の調査と計画を依頼する |
| 設計判断や重大な障害の原因調査 | 強い推論モデルを使い、根拠と代替案を提示させる |
| 重要なPRのレビュー | 実装に使ったモデルとは別のモデルでも検証する |
注意： 各社のベンチマークは条件が異なります。「A社の数値がB社より高いから常に優秀」とは判断できません。自分のリポジトリから小さな代表タスクを選び、成功率・修正回数・所要時間・費用で比べるのが現実的です。
参考：OpenAI DevDay 2026／Claude Sonnet 5.5／Gemini 4 Argon
2. VS Code 1.145：エージェントを管理する開発環境へ
VS Codeは2026年11月4日に安定版1.145を公開しました。10月28日の1.144と合わせて、AI開発者にとって重要な変更が続いています。
主なポイントは次のとおりです。
- Agent Host： エージェントのセッションをエディタ画面から切り離して継続・管理する仕組み
- Agentsウィンドウ： 複数ワークスペースや実行環境のセッションを把握する場所
- モデル比較： 同じ課題を複数のモデルやエージェントで試し、結果を見比べる機能
- 異なるエージェントの混在： 1.145では、Copilot・Claude・Codexなど異なるハーネスをネストしたセッションで使い分ける機能がプレビュー提供
- 定期実行： 1.145ではローカルのエージェント自動化に5項目のcron式を指定可能
- リモートアプリのプレビュー： リモートのエージェントが起動した開発サーバーをVS Code側で確認できるプレビュー機能
「ハーネス」とは、モデルにファイル操作やコマンド実行などの道具を渡し、作業を進めさせる仕組みのことです。モデルとハーネスは別物なので、モデル名だけでなく、どの実行環境・権限で動くかも確認しましょう。
すぐ確認したいこと
- VS Codeを更新し、バージョンが
1.145以上であることを確認する。 - CopilotのAgentsウィンドウを開き、利用可能なハーネスと実行環境を確認する。
- 単独の小さなタスクでモデル比較を試す。
- リモート操作やcomputer useを試す場合は、プレビュー／実験的機能であることを理解し、権限設定を確認する。
1.145の異種ハーネス機能を試す設定例：
{
"chat.agentHost.multipleChatProviders.enabled": true
}
この設定はプレビュー機能向けです。組織ポリシーや契約により利用できない場合があります。また、cron指定はローカル自動化向けであり、クラウド自動化にも同じ指定が使えるわけではありません。
参考：VS Code 1.145 リリースノート／VS Code 1.144 リリースノート
3. Copilotは「PCの前で使うツール」から「場所をまたいで進む作業」へ
GitHubは10月28日、Copilotのクラウド体験を拡張しました。
対応する環境では、GitHub.com・GitHub Mobile・VS Code・Copilot CLIなどからクラウドの作業セッションを開始・再開できます。クラウド上で動くタスクは、自分のPCを閉じても継続できます。
例えば、次のような流れです。
- 外出中にスマートフォンからIssueの修正を依頼する。
- Copilotがクラウド環境でリポジトリを調査・変更する。
- 帰宅後、VS Codeで同じセッションの経過を確認する。
- 差分・テスト結果を確認してからPRに反映する。
ただし、ローカルセッションとクラウドセッションは同じではありません。ローカルの未コミット変更がクラウドに自動同期されるわけではなく、クラウド利用には対応プランと組織側の許可が必要です。
コスト面の注意
GitHubは、クラウドサンドボックスの課金を2026年11月に開始すると案内しています。対象の利用量は、プランに含まれるGitHub Actions系の共有コンピュート枠などと関係します。
エージェントに長時間の処理を任せる場合は、モデル利用料だけでなく実行環境の使用量や予算上限も確認しましょう。
4. 11月4日：GitHub CopilotがXcode標準のコーディング支援に対応
iOSアプリ開発者にも動きがありました。
GitHubは11月4日、Xcodeの内蔵コーディングアシスタントからCopilotを使えるパブリックプレビューを発表しています。
現時点の条件は次のとおりです。
- Xcode 27.3 betaから対応
- macOS Tahoe 26.6以降を搭載したMacが必要
- Xcodeの
Settings > Intelligenceから設定 - 従来の「GitHub Copilot for Xcode」拡張とは別の選択肢
正式版の一般提供と混同しないことが大切です。iOS開発の本番環境で採用する前には、ベータ版の制約やプロジェクトへの影響を確認しましょう。
5. 11月16日：Copilotの一部モデルが廃止予定
今月の対応期限が明確な情報です。
GitHubは、以下のモデルを2026年11月16日にCopilotの各体験で廃止予定としています。
| 廃止予定モデル | GitHubが案内する代替候補 |
|---|---|
| Claude Opus 4.8 | Claude Opus 5.5 |
| Claude Opus 5 | Claude Opus 5.5 |
| GPT-5.6 Terra | GPT-6.1 Sol または GPT-6 Luna |
ただし、Claude Opus 4.8は個人向けCopilot年間プラン加入者について例外が案内されています。代替モデルの利用可否は管理者設定にも左右されます。
特に確認したいのは以下です。
- Copilot Chatでモデルを手動固定していないか
- チームの手順書・プロンプトで旧モデルを指定していないか
- 管理者によって代替モデルが無効化されていないか
- モデル変更によってテスト結果・出力品質・利用量が変わらないか
単なる「最新モデルの紹介」ではなく、11月中に設定の棚卸しが必要なニュースです。
6. MCP・Skills・AGENTS.md：AIに渡す「開発ルール」が資産になる
モデルが強力でも、リポジトリ固有のルールを知らなければ、意図しない修正をしてしまいます。
開発環境では次の仕組みが重要になっています。
| 仕組み | 主な役割 |
|---|---|
| MCP | AIが外部ツールやサービスと連携するための仕組み |
| Skills | テスト・レビューなど、繰り返す作業の手順をまとめる仕組み |
.github/copilot-instructions.md |
GitHub Copilot向けのリポジトリ全体の指示 |
AGENTS.md |
エージェント向けに、作業規約やコマンドをリポジトリ内へ記述するファイル |
これらは互いの完全な代替ではありません。利用するIDEやエージェントによって対応範囲が異なるため、公式ドキュメントを確認してください。
AGENTS.mdの記述例
React＋DjangoのWebアプリであれば、例えば次のようにします。
# AGENTS.md
## プロジェクト概要
- frontend: React / TypeScript
- backend: Django / Python
## 変更時のルール
- 変更前に対象ファイルと影響範囲を列挙する。
- 既存APIのレスポンス形式を無断で変更しない。
- マイグレーションやデータ削除は事前に承認を求める。
- 依存ライブラリの追加理由を説明する。
## 検証
- frontend: npm run build
- backend: python manage.py test
- 実行できないテストは理由を報告する。
## 完了報告
- 変更ファイル、テスト結果、残る懸念点をまとめる。
コマンドはプロジェクトに合わせて調整してください。
これは魔法の設定ファイルではありません。しかし、毎回同じ注意事項をプロンプトに書く時間を減らし、作業の品質をチームで再現するための第一歩になります。
参考：GitHub Docs：リポジトリのカスタム指示／VS Code：AI開発のベストプラクティス
7. 自動承認より重要なのは「権限を最小化すること」
エージェントがファイルを編集し、ターミナルを操作し、外部サービスへ接続できるようになるほど、セキュリティ対策も重要です。
特に注意したいのは、プロンプトインジェクションです。これはWebページ、Issue、README、ツールの応答などに埋め込まれた悪意ある指示を、AIが本来の依頼と誤認して従ってしまう問題です。
たとえば「この不具合を直して」と依頼したAIが、参照した外部文章に含まれる偽の指示によって、不要なファイル削除や秘密情報の送信を試みるリスクがあります。
最低限守りたい5項目
-
秘密情報を隔離する：
.envやAPIキーを、不要なエージェント・ツールから読ませない。 - 権限を絞る：通常の調査・実装に本番環境の変更権限を渡さない。
- サンドボックスを利用する：対応環境でファイル・ネットワーク操作を制限する。ただし万能な防御ではない。
- 破壊的操作を承認制にする：削除、DB変更、デプロイ、外部送信は人が確認する。
- AI生成コードを検証する：テスト・静的解析・依存関係の検査・差分レビューを省略しない。
VS Codeには、ツール承認やサンドボックス、Workspace Trustなどの保護機能があります。ただし、「すべてのコマンドを自動承認」にする設定は、便利さと引き換えにリスクを大きくします。
AIに任せる範囲を広げるなら、まず権限とテストを整備する。これが実務での基本だと思います。
参考：VS Code：Secure AI-assisted development／GitHub Docs：Copilotクラウドエージェントのリスク
8. AIで実装が速くなるほど、レビューと開発基盤がボトルネックになる
意外に見落としやすいのが、AIによるコード生成のその後です。
Anthropicは10月、自社のコード変更量の増加に対応するため、新しいバージョン管理システム「Scion」を構築したと説明しました。OpenAIも11月2日、Git互換のバックエンド「Pando」によって、多数の並行作業に対応していることを公開しています。
これらは大規模組織の特殊な事例ですが、一般の開発チームにも共通する教訓があります。
コードを生成する速度だけが上がっても、レビュー・CI・競合解消・デプロイが追いつかなければ、全体の開発速度は上がりません。
個人開発でも、次のような運用が役立ちます。
- タスクを小さく切り、1PRあたりの変更範囲を絞る
- AIが書いたテストも、人が仕様と照らして確認する
- ビルド・単体テスト・静的解析をCIで自動化する
- 長期実行エージェントには、終了条件と費用上限を設ける
- 「実装したこと」より「検証できたこと」を完了条件にする
参考：Anthropic：Redesigning source control／OpenAI：Scaling Git at OpenAI
実践：明日から使えるAI開発の依頼テンプレート
モデルやツールが進化しても、依頼の組み立ては重要です。例えば次のテンプレートを使えます。
あなたはこのリポジトリの開発担当です。
【目的】
（実現したい機能・解決したい不具合）
【制約】
- 既存機能の後方互換性を維持すること
- 無関係なファイルを変更しないこと
- DB変更・データ削除・外部送信は事前承認が必要
【作業手順】
1. まず関連ファイルと影響範囲を調査する。
2. 修正方針、代替案、リスクを簡潔に提示する。
3. 方針に沿って実装する。
4. 必要なテストを追加または更新する。
5. ビルド・テストを実行する。
6. 最後に差分、検証結果、未解決事項を報告する。
【完了条件】
- 指定した要件を満たしている
- 対象のテストが通る
- 変更理由を説明できる
重要なのは、AIに**「完了」の定義を渡す**ことです。単に「実装してください」だけでは、コードを書いたところで作業が終わったと判断される可能性があります。
まとめ：2026年11月、開発者が優先してやること
最後に、今月の確認事項をチェックリストにしました。
- VS Codeを1.145に更新し、Agents関連機能を確認する
- Copilotで11月16日廃止予定のモデルを使っていないか確認する
- GPT-6.1 Sol・Claude 5.5・Gemini 4 Argonを、自分の代表タスクで比較する
- GitHub Copilotのクラウド実行に関する利用条件・課金を確認する
-
リポジトリに
AGENTS.mdやCopilot向け指示を整備する - エージェントの権限、秘密情報、破壊的操作の承認ルールを見直す
- ビルド・テスト・レビューの自動化を強化する
これからのAI駆動開発で差がつくのは、AIにコードを書かせる能力だけではありません。AIが安全かつ継続的に仕事を進められる「開発の仕組み」を作れるかどうかです。
新モデルの登場を追いかけつつ、まずは小さなタスクで比較し、運用ルールを整え、検証可能な形でAIに任せるところから始めてみましょう。
本記事は2026年11月6日時点の公開情報に基づきます。モデルの提供範囲、プレビュー機能、組織ポリシー、料金は利用時点の公式案内をご確認ください。