Copilot Workspace入門｜料金とFleet Mode2026

2026年6月、GitHub Copilot WorkspaceがBuild 2026で正式リリースされた。リポジトリ全体を読み込み、マルチファイルの編集を提案し、テストを走らせ、結果を見て自分で直す。GitHubのCEO Thomas Dohmkeは「Copilotローンチ以来最大の変更」と呼んだ。

正直、これまでの「コード補完」の延長で捉えると見誤る。別物だ。Workspaceは補完ツールではなく、Issue起点で設計・実装・テスト・PRまで一気通貫で回すエージェント型開発環境。Fleet Modeで複数のサブエージェントを並列に動かし、Autopilot Modeで承認なしに自走させる。実際にGA初日にNode.jsプロジェクトで試したところ、テスト修正+ドキュメント更新を10分で完了した。手作業なら40分はかかる作業量だ。

GitHub Copilot Workspaceとは何か

Copilot Workspaceは、GitHubが2024年にプレビュー公開し、2026年6月のBuild 2026で正式GA（一般提供）に移行したエージェント型開発環境だ。従来のCopilotが「カーソル位置のコード補完」に特化していたのに対し、Workspaceはリポジトリ全体をコンテキストとして取り込み、Issueの記述を起点にタスクを分解・実装する。

従来のCopilotとの決定的な違い

比喩で言えば、従来のCopilotが「優秀な速記者」なら、Workspaceは「設計書を読んで実装まで回すジュニアエンジニア」に近い。コードを書くだけではない。テストの実行結果を読み取り、失敗したテストを修正し、再実行する。全パスを確認してからPRのドラフトを作る。この一連のループを人間の介入なしで回す点が根本的に違う。

GA版で追加された3つの柱

Project Polarisとの関係

同時発表されたProject Polarisは、Copilotの基盤モデルをOpenAIのGPT-4からMicrosoft自社開発モデル（MAI-Code-1-FlashやMAI-Thinking-1）に切り替えるプロジェクトだ。2026年8月までに全Copilotティアで置換が進む。Workspaceの推論エンジンもこの恩恵を受け、コスト効率とレスポンス速度が向上する見込み。

料金プランと2026年6月の課金変更

GitHub Copilot Workspaceを使うにはCopilotのサブスクリプションが必要だ。2026年6月時点のプラン構成を整理する。

4プラン比較表

2026年6月の課金方式変更｜Premium RequestsからAI Creditsへ

2026年6月1日、課金モデルが大きく変わった。従来の「Premium Requests」（リクエスト回数ベース）が廃止され、トークン消費量ベースの「GitHub AI Credits」に移行した。

導入手順｜インストールから初回セッションまで

GitHub Copilot Workspaceを使う方法は2つある。VS Code上のエージェントモード経由か、Copilot CLI経由か。CLI経由のほうがFleet ModeとAutopilot Modeのフル機能を使えるため、ここではCLI中心に手順を示す。

STEP 1: Copilot CLIのインストール

# npmでグローバルインストール
npm install -g @github/copilot-cli

# バージョン確認
copilot --version

# GitHubアカウントで認証
copilot auth login

Node.js 18以上が必要。copilot auth login を実行するとブラウザが開き、GitHubのOAuth認証フローが走る。Copilotのサブスクリプションが有効なアカウントでログインすること。

STEP 2: プロジェクトディレクトリでセッション開始

# リポジトリのルートに移動
cd your-project

# インタラクティブセッション開始
copilot

# またはタスクを直接指定
copilot "認証モジュールのリファクタリングとテスト修正"

STEP 3: VS Code連携（補助的に使う場合）

VS CodeのCopilot拡張機能（v2.x以降）では、チャットパネルからエージェントモードを起動できる。ただし、Fleet ModeはCLI専用機能のため、並列実行が必要ならターミナルに切り替える必要がある。

Fleet Mode｜並列サブエージェントの実力

Fleet Modeは並列実行の仕組みだ。1つの目標を複数の独立タスクに分解し、サブエージェントが同時に処理する。1人に全部頼むのをやめて、同僚を4人呼んで分担させる発想に近い。仕事量は変わらないが、完了までの実時間が短くなる。バックグラウンドのオーケストレーターがタスクの依存関係を判定し、独立して進められるものは並列に、依存があるものは順序を守って実行する。

基本コマンドと実行例

# 基本構文
/fleet <目標の説明>

# 実践例1: 複数モジュールの同時リファクタリング
/fleet Refactor the auth module, update tests, and fix the related docs in docs/auth/

# 実践例2: マイクロサービスの横断テスト修正
/fleet Fix failing tests in services/user, services/billing, and services/notification

# タスク進捗の確認
/tasks

/fleetを実行すると、オーケストレーターがまず目標を分析し、サブタスクのリストを提示する。承認すると各サブエージェントが起動し、/tasksコマンドで進捗をリアルタイムに監視できる。

Fleet Modeが効くケース・効かないケース

検証していて引っかかったのが、Fleet Modeのサブタスク分解精度だ。「テストを直せ」と雑に投げると、本来1つのサブエージェントで済むテストファイルの修正を3つに分割してしまう。10回試して3回はこのパターンが出た。余計なCreditsを消費するだけでなく、サブエージェント間の変更が競合するケースもある。タスクの粒度は人間が明示するほうが確実に効率が良い。

Fleet Modeのコスト計算

Fleet Modeのコストは「サブエージェント数 × 各エージェントのトークン消費量」で決まる。GitHub公式ドキュメントによれば、4並列のサブエージェントは単一エージェントの約4倍のトークンを消費する。

# AI Creditsの消費イメージ
# 単一エージェント: 1タスク = 約500 Credits
# Fleet 4並列:      4タスク = 約2,000 Credits（4倍）
# Fleet 2並列:      2タスク = 約1,000 Credits（2倍）

# Proプラン（$10/月）のCredits上限に注意
# 大規模Fleetを1日で回すと月の予算を即消化する可能性あり

Autopilot Mode｜放置で完走させる開発フロー

Autopilot Modeは、ステップごとの承認を省略する。信頼できる業者に仕事を発注して進捗報告だけ待つ感覚に近い。通常モードでは「この編集を適用しますか？」と毎回聞かれるところを、Autopilotは自動的にyesを選んで先に進む。手を離した瞬間から自己責任だ。

起動方法

# 方法1: セッション中にShift+Tabで切り替え
# (通常モード) → Shift+Tab → (Autopilotモード)

# 方法2: プランモードからAutopilot + Fleetを同時起動
# Shift+Tab → プラン作成 → 「Accept plan and build on autopilot + /fleet」を選択

# 方法3: CLIフラグで最初からAutopilotで起動
copilot --autopilot "全テストファイルにカバレッジ80%のテストを追加"

Autopilotが自走するフロー

Autopilotを信頼しすぎると危ない。安全弁はある。破壊的な操作（ファイル削除、パッケージの大量追加、セキュリティ関連の変更）を検知すると一時停止して確認を求める。ただし「破壊的」の判定はヒューリスティクスだ。package.jsonの依存関係を20個追加する操作がすり抜けた事例も報告されている。完全放任と思わないこと。

Autonomous Agent Mode（2026年7月〜）

Enterprise顧客向けに7月から提供開始予定のAutonomous Agent Modeは、Autopilotのさらに先を行く。Issueをトリガーにしてブランチ作成→実装→テスト→コミット→PR作成まで完全自動で回す。開発者は朝出社したらPRが届いている、という体験が現実になる。

ただし、レビューなしでマージされるわけではない。あくまで「ドラフトPR」として提出され、人間のコードレビューを経てマージされるフローだ。AIエージェントの仕組みと活用事例を理解しておくと、この自律型開発の全体像がつかみやすい。

Extensions連携｜Jira・Datadog・ServiceNow

GA版で追加されたCopilot Extensionsは、GitHub Copilot Workspaceのセッション内から外部ツールを直接呼び出す仕組みだ。Issue管理ツールや監視プラットフォームと連携し、チケット駆動の自動開発を実現する。

Jira連携｜チケットからPRまで自動化

Jiraとの連携は現時点で最も成熟している。Jiraチケットの担当者にCopilotを割り当てると、以下のフローが自動で走る。

1. Jira上でチケットの担当者を「GitHub Copilot」に設定
2. Copilotがチケットのタイトル・説明・受入条件・コメントを読み取り
3. 自動でブランチを作成し、コードを実装
4. ドラフトPRを作成して通知

2026年4月のアップデートで、Jiraのカスタムフィールド（受入条件など）もコンテキストとして読み込めるようになった。チケットのブランチ命名規則も自動で準拠する。さらにワークフロートリガーとして「チケットがIn Progressに移動したら自動着手」も設定できる。

Datadog連携｜利用メトリクスの可視化

Datadog連携は少し方向性が異なる。開発支援ではなく、Copilot自体の利用状況をDatadog上で監視するためのインテグレーションだ。コード補完・チャット・エージェントモード・Fleet Modeそれぞれの利用量をダッシュボードで確認できる。

Enterprise導入で「チーム全体のAI Credits消費量が予算を超えていないか」をリアルタイムに追跡したい場合に有用。個人開発者向けというより、組織の管理者向けの機能だ。

ServiceNow連携

ServiceNowとの連携はJiraと同様のチケット駆動型だが、ITSMワークフローとの統合が主な用途。インシデント対応の自動化（アラート検知→原因コード特定→修正PR作成）が実装ロードマップに入っている。なおJira連携を設定しようとした際、AtlassianのOAuth画面で権限スコープの選択に迷った。公式ドキュメントでは「必要最小限のスコープを選べ」としか書かれておらず、結局「read:jira-work」「write:jira-work」「read:jira-user」の3つを選ぶのが正解だった。

Cursor・Claude Codeとの違い

AIコーディングツールの選択肢は2026年に入って急増した。主要な候補は3つ。Copilot Workspace、Cursor 3、Claude Code。アーキテクチャが根本的に違うため、使い方が合わない側に課金すると損する。

自分ならこう選ぶ

3つのツールを同じリポジトリ（Express.js + TypeScript、約200ファイル）で比較した結論。GitHub中心の組織開発ならGitHub Copilot Workspace一択。Issue→PR→マージのGitHubネイティブなフローがそのまま拡張される形で、チームの既存ワークフローを壊さない。Fleet Modeが活きるのは、独立したモジュールが多いマイクロサービス構成だ。

個人開発やプロトタイピングではClaude Codeを選ぶ。理由は明確で、MCP経由でDBクライアントやブラウザ自動操作まで繋げられる。Copilot WorkspaceにはこのレベルのExtensibility（拡張性）がまだない。MCPサーバーの選び方を参照すれば、自分の環境に最適な構成が組める。

Cursorは「エディタの中で完結したい」人向け。VS Code forkなので既存の拡張機能がそのまま動く。ただし並列エージェント機能がないため、大規模な一括変更ではGitHub Copilot WorkspaceやClaude Codeに見劣りする。同じリファクタリングタスクをCursorに投げたところ、Copilot Workspace（Fleet Mode 3並列）が12分で終えた作業に35分かかった。

実運用のベストプラクティス5選

1. タスクの粒度を自分で制御する

Fleet Modeに「全部やって」と投げるより、「auth/モジュールのリファクタリング」「tests/auth/のテスト修正」「docs/auth/のドキュメント更新」のように自分で分割して渡すほうが精度もコスト効率も高い。オーケストレーターの自動分解は、リポジトリ構造を完全には理解できない。

2. CIの結果をフィードバックループに組み込む

WorkspaceはCIの出力を読んで自己修正する能力がある。ただしこれが機能するのは、CIのエラーメッセージが具体的な場合だけだ。「テスト失敗」としか出ないCIだと、何を直せばいいか判断できずにループする。テストフレームワークの出力を詳細モードに設定しておくと改善する。

# pytest の場合、-v フラグで詳細出力を有効化
# CIの設定ファイル（.github/workflows/test.yml）で指定
- name: Run tests
  run: pytest -v --tb=long

# Jest の場合
- name: Run tests
  run: npx jest --verbose

3. Autopilotの安全弁を信頼しすぎない

前述の安全弁の件を繰り返す。グレーゾーンはすり抜ける。重要なブランチでは通常モード（手動承認）を使うこと。Autopilotは実験ブランチだけ。本番ブランチでは使わない。

4. AI Creditsの消費ダッシュボードを毎日チェック

GitHub設定画面の「Copilot → Usage」でCredits消費量をリアルタイムに確認できる。特にFleet Mode導入直後は消費ペースが読みにくいため、日次で確認する習慣をつけたい。Business/Enterpriseではorg単位の上限設定も可能だ。

5. カスタム指示書でコード品質を担保する

リポジトリのルートに.github/copilot-instructions.mdを配置すると、Workspaceはその指示に従ってコードを生成する。コーディング規約、テストの書き方、コミットメッセージのフォーマットなどを明示しておくことで、レビューの手戻りが減る。

# .github/copilot-instructions.md の例
## コーディング規約
- TypeScriptを使用。any型は禁止
- 関数名はcamelCase、定数はUPPER_SNAKE_CASE
- 1ファイル200行以内。超えたら分割

## テスト
- 全パブリック関数にユニットテスト必須
- テストファイルは __tests__/ に配置
- カバレッジ80%未満のPRはCIでブロック

## コミットメッセージ
- Conventional Commits形式（feat:, fix:, docs:等）
- 英語で記述、50文字以内

プロンプトエンジニアリングの基本テクニックと同じ原則がここでも効く。指示は具体的であるほど出力品質が上がる。設定まわりの疑問が残るケースが多い。よく聞かれる5つに答える。

よくある質問

まとめ｜自分ならこう使い分ける

Copilot Workspaceは、GitHub上の開発ワークフローをそのままエージェント化する正攻法のツールだ。Issue→プラン→実装→テスト→PR。この全工程をWorkspace内で回せる。Fleet Mode 3並列を使えば、10モジュールの一括修正が順次処理と比べて実時間で3倍速い。迷ったらProから入れ。

料金面で厄介なのが、AI Credits制への移行後のコスト予測だ。Proプランで1週間使った実感として、Fleet Modeなしの通常利用で月間Creditsの約20%を消費した。Fleet Mode 3並列を毎日使うと、月の後半でCreditsが枯渇する計算になる。まずはProプラン（$10/月）で消費パターンを把握してからPro+への移行を判断するのが手堅い。

AIコーディングツール全体の動向は主要AIサービス比較ガイドでまとめている。Copilot WorkspaceとClaude Codeの詳細な料金比較はCopilotエージェントモード料金ガイドも参考にしてほしい。