GitHub Copilot Projectsは、目標・リポジトリ・参考資料・エージェントの成果物を1か所にまとめ、複数の作業を継続して進めるCopilotアプリの機能です。たとえば、API変更に伴うバックエンド、フロントエンド、ドキュメントの修正を、共通の目標の下でエージェントに分担させられます。
Projectsはパブリックプレビューです。本記事は、開発責任者やテックリード向けに、使い方と法人導入の判断材料を整理しています。Projects・Copilotアプリ・課金の公式資料は2026年11月14日に再確認し、確認できた仕様と、自社環境で検証すべき事項を分けました。操作手順は公式資料に基づくもので、当協会による実機検証の結果ではありません。
この記事でわかること
- Copilot Projectsとは何か、単一リポジトリから始めるセッションとどう使い分けるか
- 作成から結果の受け取りまでの具体的な流れと、進捗画面の見方
- AIクレジットで費用を考えるときの前提と、Projectsに当てはめるときの注意点
- 導入前に組織で決める項目のチェックリスト(任せる範囲・レビュー体制・予算の上限・権限)
- 公式資料で確認できる条件と、導入前に検証すべき事項
Copilot Projectsとは？目標単位で作業をまとめる機能
Copilot Projectsは、GitHub Copilotアプリの中にある「プロジェクト」という作業単位です。目標、参考資料、複数のエージェント、成果物(PR：プルリクエストなど)を1つの場所にまとめて管理します。ステータスはパブリックプレビューで、公式ドキュメントにも仕様が変わる可能性があると明記されています。
なお、IssueやPRを表・ボードで管理するGitHub Projectsとは異なります。本記事の対象は、Copilotアプリでエージェントの作業を調整するProjectsです。
単発セッションとの違いは目標単位で作業をまとめられること
1つのリポジトリで完結する修正なら、そのリポジトリからセッションを始めれば十分です。Projectsは、複数のタスクや継続的な目標について、資料・進捗・成果物をまとめて扱いたいときに向いています。以下は、単一リポジトリのタスクを個別に依頼する運用との比較です。
Projectsでは単位が目標になります。目標を書き、リポジトリ、デザインモック、Slackスレッド、会議メモといった文脈を追加し、モデルとツールを選んで複数のエージェントを走らせます。結果はPRなどの形でレビュー用に返ってきます。進捗の確認も、判断も、次の指示も、同じ画面で済みます。
| 観点 | 単一リポジトリから個別に依頼する運用 | Copilot Projects |
|---|---|---|
| 作業の単位 | 1リポジトリ上の1タスク | 目標(複数リポジトリや資料を含められる) |
| 文脈の渡し方 | タスクごとに指示や関連資料を指定する | プロジェクトに資料を置き、依頼時に使う資料を指定する |
| 並列実行 | セッションを個別に起動して自分で管理 | 1つのプロジェクト内で複数セッションを走らせ、画面で一覧する |
| 繰り返し作業 | 都度依頼 | プロジェクトオートメーションで定期実行 |
コード作業はブランチを分け、実行環境も確認する
Copilotアプリでは、コードを扱う並列セッションを専用のGitワークツリー(作業ディレクトリ)とブランチに分離できます。ただし、変更を統合する際の競合までなくなるわけではありません。アプリはクラウドとローカルの実行環境を扱えます。クラウドセッションはGitHub側で実行されるため、手元のPCの計算資源を使いません。アプリの対応環境はmacOS、Linux、Windowsで、WindowsはWSL 2内でもセッションを実行できます。
Projectsには「リポジトリなしでも開始できる」という特徴もあります。調査や設計資料の整理のように、コードベースが前提でない作業も同じ枠に載せられます。
単一リポジトリの作業ならProjectsは必須ではない
作業範囲が1つのリポジトリで明確なら、従来どおりリポジトリから直接セッションを始められます。Projectsを使うのは、次のような場面です。
- 複数リポジトリにまたがる変更(API仕様変更とクライアント側の追従など)
- 設計資料やモックを見ながら進める、文脈の多い作業
- 毎週のメンテナンスのように、同じ作業を繰り返す運用
逆に、小さな修正まで全部Projectsに載せる必要はありません。入れ物が大きいほど、目標の絞り込みとレビューの手間が増えるからです。
Copilot Fusionとは役割が違う
Copilot Fusionは、タスクに応じてモデルを選択・組み合わせる機能で、一般提供されています。Fusionは「どのモデルをどう使うか」の話、Projectsは「どの作業を、どの単位でエージェントに任せるか」の話で、レイヤーが違います。FusionはVS Code、Copilotアプリ、CLI、JetBrainsで使え、前身の仕組みと費用の読み方はGitHub Copilot HydraFusionとは？仕組み・使い方・コストの読み方で扱っています。
他社のクラウドエージェントとの位置づけ
複数のクラウドセッションを1つのプロジェクトで束ねる構造は、Claude Codeのクラウドセッションにもあります。Claude Codeのクラウドセッションは、ブラウザ、モバイル、Desktop、CLI(claude --cloud)から並列に起動でき、Claude CodeのProjectsでは1つの目標に対して複数の作業スレッドをClaudeが起動・管理し、結果をまとめます。
比較時は、既存の開発基盤と課金条件を揃えます。Copilot ProjectsはGitHubのリポジトリやPRと連携し、費用は後述するモデル利用と実行環境に分けて確認します。Claude Codeのクラウドセッションは、GitHub接続にClaude GitHub Appなどを使い、クラウドVMに別料金はなく、プランの利用上限を共有します。CodexやCursorのバックグラウンドエージェントは、公式ドキュメントでの確認が取れていないため、ここでは機能を比較しません。Cursor側とのチーム導入の違いはCursorとGitHub Copilot比較：チーム導入の違いが参考になります。
Copilot Projectsの使い方：作成・進捗確認・レビュー
Projectsの使い方は、プロジェクトを作り、目標と資料を渡し、進捗画面で判断とレビューを繰り返す、という流れです。操作は公式ドキュメントに沿った手順です。
プロジェクトを作って最初の依頼を出す
手順は次のとおりです。
- サイドバーの「Projects」横にある「+」(Create a project)を押し、New projectページを開く
- 任意で、「Which repositories should this Project use?」に表示される提案リポジトリを選ぶ。owner/名前で検索して「Add repositories」から追加もできる。リポジトリなしでも開始できる
- プロンプト欄に、用途、最初のタスク、期待する結果、制約を書く
- 任意で、右パネルのLibraryタブから「Add > Add file…」または「Add folder…」で資料を追加する
- 送信して作業を開始する
最初のプロンプトには、制約と完了条件まで書くと依頼範囲が伝わります。以下は、3つのリポジトリにまたがるAPI変更を想定した依頼例です。
目的: 注文APIのレスポンス形式を変更し、利用側2リポジトリとAPI仕様書を追従させる。 最初のタスク: APIのレスポンス変更と、既存テストの修正。 期待する結果: テストが通る状態で、リポジトリごとに1本ずつPRを出す。 制約: 認証まわりのコードには触れない。破壊的変更は仕様書に明記する。
公式ドキュメントは、目標をプロジェクトごとに絞ること、タスクを依頼するときにどの資料を使うか明示することを勧めています。
Overviewの4分類で人間が動くべきタイミングがわかる
進捗はOverviewタブで確認します。表示は4つに分かれています。
| 分類 | 意味 | 人間がやること |
|---|---|---|
| Needs input | 判断、レビュー、権限要求が待たれている | 最優先で対応する |
| Open | オープン中のPR(状態と追加・削除行数つき) | レビューしてマージ判断をする |
| Working | エージェントが作業中 | 基本は待つ |
| Done | 完了 | 結果を確認する |
Needs inputには、人間の判断やレビューが必要な項目が並びます。該当項目を優先して確認してください。別のセッションがWorkingで動いている場合もあるため、プロジェクト全体の停止を意味するわけではありません。セッションを開くと、会話、変更内容、PR、計画を確認でき、「Steer this session」から追加の指示を出せます。方向がずれたと気づいたら、作り直す前にここから舵を切れます。
Libraryタブには、利用者が追加した資料とエージェントが生成した成果物が並びます。同じプロジェクトに戻ってフォローアップを依頼し、新しい資料を足して以前の結果と比較させることもできます。
繰り返し作業はプロジェクトオートメーションに任せる
定期実行は、プロンプトでタスク、スケジュール、期待する結果を依頼すると始まります。確認の質問に答えると、Automationsタブでスケジュールと次回実行日時を確認できます。一時停止(Pause)、スケジュールの編集(Edit schedule…)、削除(Delete…)も同じ画面です。
使いどころは、毎週の依存ライブラリ棚卸しや、定型レポートの更新のような、手順が固定された仕事です。人間の判断が毎回変わる作業は向きません。
コード変更は人間のレビューとブランチ保護で確認する
Projectsの成果物は、タスクに応じてPRや調査資料などになります。コード変更では、人間の承認とテストをマージ条件として運用しましょう。レビュー必須のルールは、ブランチ保護やルールセットで設定・検証してください。Projectsを使うだけで人間のレビューが強制されるとは限りません。AIの出力と人間のレビューをどう分担するかは、AIコードレビュー導入ガイド｜法人向けの人間とAIの役割分担・運用ルールが土台になります。
任せる側の仕様の書き方も効きます。目標、制約、完了条件を先に文書化しておく進め方は、仕様駆動開発とは？Claude Codeでの進め方とツール比較・向き不向きの考え方がそのまま使えます。
料金はAIクレジットとクラウド実行費用を分けて確認する
法人で費用を見積もる際は、契約プラン、モデル利用のAIクレジット、クラウド実行環境の費用を分けます。2026年11月14日に確認したProjectsの公式操作ガイドには、Projects専用の料金やプレビュー中の無料枠は明記されていません。無料とは判断せず、利用する機能と自社契約の条件を確認してください。
Business・EnterpriseのAIクレジットは1クレジット0.01米ドル
AIクレジットは、1クレジットが0.01米ドル(USD)です。入力・出力・キャッシュのトークン量とモデルごとの単価で消費量が決まります。消費の対象は、チャット、CLI、クラウドエージェント、Spaces、Spark、サードパーティ製コーディングエージェントです。インライン補完と次の編集候補(next edit suggestions)はAIクレジットを消費しません。
Copilot Business・Copilot Enterpriseを席単位で契約する場合、ユーザーごとの月間付与量はBusinessが1,900クレジット(19米ドル相当)、Enterpriseが3,900クレジット(39米ドル相当)です。これらは含まれる利用枠の換算額で、Projectsの月額料金ではありません。税額や為替換算は含めず、実際の請求は契約条件で確認してください。
含有クレジットは請求先の組織・企業単位で共有するプールに入り、翌月への繰り越しはなく、毎月1日0時(UTC)にリセットされます。
Projects単位の料金を並列数だけで見積もらない
一般的なCopilotのモデル利用については、AIクレジットによる課金が説明されています。一方、Projectsの操作ガイドには、1プロジェクトあたりの料金例や消費量の目安はありません。以下は公式の料金保証ではなく、試験運用で費用を把握するための進め方です。
- エージェント数だけで計算せず、モデル、入力・出力のトークン量、実行時間を記録する
- 目標が曖昧だと、やり直しの分だけ消費が増える
- 軽量モデルで足りる作業(定型の修正、資料整理)は軽量モデルに寄せる
- 小さな案件で利用前後の消費を記録する。他のCopilot利用も同時に走る場合、差分すべてをProjectsの費用とみなさない
クラウドセッションの計算資源と新契約も費用に効く
クラウドサンドボックスの課金は2026年11月開始と公式に案内されています。発表時には同様の内容が報じられています。
公式課金ガイドでは、稼働中の計算時間・割り当てメモリ・停止中のスナップショット保存が別々の計測対象です。計算時間とメモリは対象のActions利用と共通の付属枠から差し引かれ、枠を超えると追加請求されます。停止後もスナップショットの保存費用は残るため、停止と削除を区別してください。
GitHub Enterprise Cloudでは、Enterpriseライセンスに各ユーザーのCopilot利用資格を含める新しい契約形態も公式発表されています。別サブスクリプションは不要で、使ったAIクレジットに支払います。発表時点ではGitHubまたはMicrosoftの担当営業を通じた新規・移行が対象で、セルフサービスは段階的に提供される予定とされています。席ごとの月間AIクレジットは付属せず、最初のリクエストから企業予算に計上されます(gihyo.jp)。既存の契約は影響を受けず、現プランの維持も選べます。
AIクレジットとクラウド実行費用には別々の予算を設ける
AIクレジットには、ユーザー、コストセンター、エンタープライズ、組織の予算があります。ただし制限する範囲は同じではありません。ユーザー単位の予算は含有クレジットと追加利用の両方を制限し、通常のコストセンター予算はプール消費後の追加課金を制限します。共有プール内の利用も制限したい場合は、ユーザー単位の予算や含有利用量の制御を確認してください(公式の予算ガイド)。
BusinessとEnterpriseでは追加利用が既定で有効です。含有枠を超える支出を防ぐには、有料利用ポリシーと予算を確認します。さらに、クラウドサンドボックスは「Bundled AI credits」予算の対象外です。クラウド費用にも上限を設ける場合は、製品単位またはSKU(課金項目)単位の予算を別に設定し、「Stop usage when budget limit is reached」を有効にします(クラウド予算の公式説明)。
導入前に組織で決める項目をチェックリストにする
導入前に決めるのは、任せる範囲、レビュー体制、費用の上限、権限の4点です。以下は公式仕様を踏まえた運用上の提案で、Projectsの導入実績や効果測定の結果ではありません。
決めておく4つの項目
| 項目 | 決めること | 判断の目安 |
|---|---|---|
| 任せる範囲 | どのリポジトリ・どの種類の変更を載せるか | 最初は影響範囲が小さく、テストが揃っているリポジトリに限る |
| レビュー体制 | 誰が、どの粒度でPRを見るか | エージェントの出力を人間が必ず読む。並列数はレビュー担当の処理能力以下にする |
| 費用の上限 | AIクレジットとクラウド実行費用の停止条件 | 共有プールの利用制限と追加課金の予算を分け、クラウド費用にも別の予算を置く |
| 権限 | エージェントが触れるリポジトリと資料の範囲 | 本番設定や認証まわりは載せない。資料に機密を置く前にルールを決める |
公式の記載だけでは自社への適用を判断できない事項
2026年11月14日に確認したProjectsの操作ガイドには、アプリが全Copilotプラン向けであることは記載されています。ただし、それだけで自社の権限・予算・管理設定で全機能を使えるとは判断できません。以下は、記載が見当たらない事項と、実環境での確認が必要な事項を分けた確認リストです。
| 確認対象と公式資料の範囲 | 導入前にやること |
|---|---|
| 対象プラン：Projectsの操作ガイドはアプリを全Copilotプラン向けと案内 | 自社アカウントでProjectsの表示と必要機能の利用可否を確認する |
| Projects単体の管理ポリシー：操作ガイドに専用設定の記載なし | アプリとCopilot in the cloudのポリシーを確認し、必要なら管理者・GitHub窓口に確認する |
| Projects専用の料金・無料枠：操作ガイドに明記なし | 自社契約での課金条件を確認し、AIクレジットとクラウド費用を分けて記録する |
| Projectsと監査ログの対応：操作ガイドに識別方法の記載なし | 試験運用でログを出力し、プロジェクトとセッションを追跡できるか確認する |
| 自社のブランチ保護：設定に依存 | 検証用リポジトリで承認・テストが必須になり、未承認ではマージできないことを試す |
| リポジトリ権限と課金先：実行環境・所有者に依存 | クラウドセッションで複数リポジトリを扱う場合は所有者が同一か確認し、最小権限で試す |
| Projects自体の操作画面：操作ガイドはCopilotアプリを案内 | 他クライアントからのクラウドセッション操作と区別し、Projects管理はアプリで確認する |
公式に確認できる管理機能もある
BusinessとEnterpriseでは、Copilotアプリ用のポリシーが既定で有効になっており、Copilot CLIのポリシーとは別に管理されます。クラウドセッションの開始には、Copilot in the cloudポリシーも関係します。コンテンツ除外ポリシー(エンタープライズ、組織、リポジトリの各レベル)は尊重され、除外されたファイルはコンテキストになりません。
エンタープライズのエージェント監査ログは、actor:Copilot で直近180日の活動を絞り込めます。actor_is_agent、agent_session_id、user などを使えますが、agent_session_id はセッション由来のイベントにのみ含まれます。また、ローカルで入力したプロンプトなどのクライアントセッションデータは通常の監査ログの対象外です。Projectsの全操作を追跡できるとみなさず、自社で必要な記録が残るか検証してください。
エージェントが動く環境の設計は、GitHub Copilotのサンドボックスとは？法人が決める設定と管理ポイントで整理した考え方が使えます。
エージェントへの任せ方とレビューの型は組織で揃える
並列エージェントを運用するには、ツールの設定に加えて、人間側の判断基準も必要です。目標をどの粒度で書くか、どの資料を渡すか、PRのどこを見るか。この型が人によってばらばらだと、レビューの品質も消費クレジットも揃いません。
お知らせ：チームで運用の基礎を学ぶためのAI駆動開発研修では、コンテキスト設計、AI駆動のレビュー、セキュリティ、自社ルールの策定を扱います。受講形式とカリキュラムは研修ページで確認できます。
小さく始める進め方
試験運用の進め方の一例として、最初の1か月を次のように使います。
- 検証用の組織またはリポジトリで、Projectsの表示とポリシーの挙動を確認する
- 単一チーム、1〜2リポジトリの小さな案件を載せ、レビュー時間、手戻り、消費クレジット、クラウド費用を記録する
- 人間のレビューを経て完了条件を満たしたか確認し、記録をもとに並列数、予算、レビュー担当を決める
- 定期実行(オートメーション)は、手順が固定された作業だけに広げる
よくある質問
Copilot Projectsは無料で使えますか？
Projectsが無料で使えるとは断定できません。操作ガイドはアプリを全Copilotプラン向けとしていますが、Projects専用の無料枠は明記していません。モデル利用のAIクレジットと、クラウドを使う場合の計算・保存費用を別々に確認してください。
単一リポジトリの作業にもProjectsを使うべきですか？
必須ではありません。範囲が1リポジトリで明確なら、リポジトリから直接セッションを始められます。複数リポジトリや資料をまたぐ作業でProjectsの価値が出ます。
Copilot Fusionとは何が違いますか？
Fusionはタスクに応じてモデルを選択・組み合わせる仕組みです。Projectsは目標に向けた作業と資料、複数のセッションをまとめる仕組みです。モデルの選び方と作業の管理という役割が異なります。
法人で使うときに最初に確認すべきことは何ですか？
自社プランでの利用可否、管理ポリシーと権限、人間のレビュー体制、費用の上限を確認してください。クラウド利用ではAIクレジットとは別の予算も必要です。監査要件があれば、必要な操作記録が残るか検証してから展開します。
Claude Codeのクラウドセッションと比べて、どちらを選ぶべきですか？
既存の開発基盤、管理条件、利用枠で判断します。GitHub中心の運用ならCopilot Projects、Claude Codeを既に使う組織ならClaude側のProjectsやクラウドセッションが候補です。優劣を実測した比較ではないため、同じタスクでレビュー負荷と総費用を確認してください。
まとめ
Copilot Projectsは、複数リポジトリにまたがる作業を目標単位でエージェントに並列で任せる機能です。使い方そのものは難しくありません。難所は、任せる範囲、レビュー体制、予算、権限を組織で決めておくことにあります。
最初に着手するのは、検証用リポジトリでの試験運用です。Overviewの4分類を見ながらレビューの手間を測り、AIクレジットとクラウド実行費用を分けて記録してください。その実測値が、並列数と予算の決め方になります。公式に確認できない事項は、展開前の確認リストとして持ち続け、ドキュメントの更新に合わせて埋めていくのが現実的です。
