こんにちは。@m_koshikawa です。
今年の2月にMicrosoftパートナー企業にジョインしました。GitHub Copilotが導入されている環境です。一方で、前職からClaude Codeを約1年間個人で使い続けてきました。
この記事では、Claude Codeの使い方をそのままCopilotに持ち込んで失敗した体験と、そこから見えた両者の使い分け、そしてチームへの展開に向けて今考えていることを書きます。
2日でPremium Requestsの56%を使い切った
入社直後、GitHub Copilotを本格的に使い始めました。
Claude Codeに慣れていた私は、Copilotでも同じ使い方をしました。Agent Modeで長い対話をして設計を練り、ドキュメントを生成し、複数ファイルにまたがる作業を一気に進める。いつも通りのつもりでした。
2日後、Premium Requestsの月間上限の56%を消費していました。
月の残り28日をほぼ半分のリクエストで過ごすことになります。使い方を根本的に間違えていたと気づきました。
課金モデルが違えば、使い方も違う
この失敗で体感したのは、課金モデルの違いが使い方を決めるということです。
| GitHub Copilot | Claude Code | |
|---|---|---|
| 課金モデル | リクエスト制（月間上限あり） | トークン制（時間経過でリセット） |
| 最適な使い方 | 細かい補完・提案を大量に | まとまった文脈で深い対話を |
| 1回の対話 | 短い（補完・提案・レビュー） | 長い（壁打ち・設計・生成） |
GitHub Copilotはリクエスト1回1回に課金されます。特にOpus 4.6のような高性能モデルは消費レートが高く、Agent Modeで長い対話をするとあっという間に枯渇します。コード補完やインラインサジェストのように、開発中に常時オンで細かく使う設計です。
Claude Codeはトークン制で、使用量は時間経過でリセットされます。TeamのPremium seat（$125/席/月）ならProの6.25倍の使用量があり、Copilotのように月間上限を気にする必要がありません。まとまった文脈を渡して、長い対話の中で構成を練る使い方に向いています。
「どちらが優れているか」ではなく、「何に向いているか」が違います。私は同じ使い方を持ち込んだから失敗しました。
1年間の個人利用で落ち着いた使い分け
失敗を経て、自然に落ち着いた使い分けは以下の通りです。
GitHub Copilotが活きる場面
- コード補完: エディタ上で書いている最中のインライン提案
- PRサマリ: Pull Requestの要約を自動生成
- コードレビュー: 変更差分に対する指摘
- 短い質問: 「このAPIの引数は？」のような即座に答えが欲しい場面
GitHub Copilotは開発中に常時オンで使います。意識して起動するものではなく、エディタの一部として溶け込んでいます。
Claude Codeが活きる場面
- 壁打ち: 「このテーマで記事を書きたい。構成はどうする？」のような設計の対話
- ドキュメント生成: 長い文脈を渡して、構造化された成果物を一気に生成する
- ワークフロー設計: プロジェクトの方針・ルール・プロセスを整理する
- 複数ファイルにまたがる作業: リポジトリ全体を見渡しながら横断的に作業する
Claude Codeは意図的に起動して、対話するものです。「今からこの仕事を一緒にやろう」という意識で使います。
迷ったときの基準はシンプルです。
- 数秒で終わる補完・確認 → GitHub Copilot
- 数分以上の対話・設計・生成 → Claude Code
1人でやってきたことを、チームに広げるために
ここまでは私個人の体験です。ここからは、チームへの展開に向けて今考えていることを書きます。
Claude Codeには CLAUDE.md という仕組みがあります。プロジェクトのルール・方針・判断基準を1つのファイルに書き、AIがそれを毎回読み込んで合意に沿って動きます。
CLAUDE.md ← チームの合意文書
├── プロジェクトの方針
├── コーディングルール
├── レビュー基準
└── チームの判断軸
私はこの1年間、CLAUDE.md を個人の合意文書として使ってきました。自分のルール・方針・学びを書き込み、AIとの協働の精度を上げてきました。
以前の記事「AIエージェントとの協働で差がつくのはモデル選びではなくプロセス設計」で、README.mdや設計書を「AIとの合意文書」として先に作る重要性を書きました。CLAUDE.md はその実装です。
これがチーム全体で共有されたらどうなるか。設計方針を決めるメンバーが CLAUDE.md に書き、実装を担当するメンバーのAIがそれを前提として動く。メンバーが遭遇した学びを追記すれば、チーム全体の判断基準が更新される。チーム全員が同じ言語でAIに意思を伝えられる状態が作れるのではないかと考えています。
まだ仮説です。しかし、個人で1年間やってきた実感として、CLAUDE.md による意思伝達の統一はチーム規模でも機能すると考えています。
なぜ10名で検証するのか
社内では別の事業部が先行してClaude Codeを活用しており、ACS事業部でも導入が承認されました。その際、「検証に10名は多いのでは」という指摘がありました。
確かに「Claude Codeが速いか」を確かめるだけなら2〜3名で十分です。ただ、確かめたいのは CLAUDE.md を介した意思伝達がチームの動き方に影響するかどうかです。
設計方針を書くメンバーと、それを前提に作業するメンバーが同じ仕組みの上にいなければ、合意文書は機能しません。役割の異なるメンバーを含む1チーム分の人数で検証することにしました。
モデル進化への追従
GitHub CopilotでもOpus 4.6を含むClaudeモデルを使うことはできます。しかし先述の通り、Opus 4.6はPremium Requestsの消費レートが高く、日常的に使うのは難しい状況です。Claude Codeを直接契約すれば、Anthropicの最上位モデルを制限を気にせず使えます。
AIモデルは急速に進化しています。Anthropicはモデルのアップデートを継続しており、今後さらに高性能なモデルが出てくる可能性は高いと考えています。MicrosoftパートナーとしてGitHub Copilotを推進しつつ、Anthropicのモデル進化を直接追える環境も持っておく。どちらかに寄せるのではなく、選択肢を持つことに意味があると考えています。
これからの検証で明らかにしたいこと
現在は社内検証の段階です。3ヶ月間の検証期間で以下を明らかにしたいと考えています。
-
CLAUDE.mdによる意思伝達の統一は、チームの協働を実際に改善するか - GitHub Copilotとの併用で、どのようなワークフローが最適か
- 個人で機能していた仕組みが、チームでも同じように機能するか
3ヶ月後に結果が見えてきたら、改めて記事にしたいと思います。
まとめ
| 観点 | GitHub Copilot | Claude Code |
|---|---|---|
| 課金モデル | リクエスト制（月間上限） | トークン制（時間リセット） |
| 得意な領域 | コード補完・レビュー・PR | 壁打ち・設計・ドキュメント生成 |
| 影響の範囲 | 個人の生産性 | 個人→チームの意思伝達（検証中） |
| AIへの伝達 | 都度のプロンプト | 合意文書 CLAUDE.md
|
| モデル | Opus 4.6も利用可能だが高レート | Opus 4.6を日常的に利用可能 |
私がCopilotをClaude Codeと同じように使って2日で枯渇した失敗から、両者は得意領域が違うことを体感しました。1年間の個人利用で使い分けが見え、今度はそれをチームに広げる段階に入ります。
個人でうまくいったことが、チームでも同じようにうまくいくかはわかりません。それを確かめるための検証をこれから始めます。
参考
- AIエージェントとの協働で差がつくのはモデル選びではなくプロセス設計 — 筆者の過去記事
-
Claude Code公式ドキュメント — Memory —
CLAUDE.mdの仕組みと推奨される使い方 - About premium requests（GitHub Docs） — GitHub Copilotのリクエスト制課金の仕組み
- Copilot ask, edit, and agent modes: What they do and when to use them（GitHub Blog） — GitHub Copilotの各モードの使い分け