GitHub Copilotの「エージェント」は3つある——agent mode・cloud agent・custom agentsの違い
IDEの中で対話しながら直すagent modeは何をしてくれる？
室谷代表取締役まず一番身近なのが、IDEの中のagent modeなんですよね。VS Codeを開いたまま対話で「ここ直して」と投げると、その場でファイルを編集して差分を見せてくれる。
同期型で、自分の目の前で進むタイプです。
同期型で、自分の目の前で進むタイプです。
テキトー教師DotAI 認定講師現場でよく聞くのは「勝手にいろんなファイルを触られると怖い」という声です。ただ差分がその場で見えるので、違ったら戻せる。
そこが安心材料なんですよね。
そこが安心材料なんですよね。
室谷代表取締役そうそう。経営目線で言うと、レビュー待ちで人の手が止まる時間が減るのが効くんですよ。
時給で換算すると、ここって地味に大きいので。
時給で換算すると、ここって地味に大きいので。
テキトー教師DotAI 認定講師最初に戸惑うのが、普通のチャットとの線引きです。「相談する相手」から「手を動かす相手」に変わった感覚ですね。
Copilot cloud agent（旧Copilot coding agent）は何が別物なのか
室谷代表取締役で、名前が似ていて一番ややこしいのがcloud agent。こっちは非同期なんですよ。
Issueなどのタスクを委任すると、調査から実装、PR作成までバックグラウンドで進める。旧称がCopilot coding agentで、2025年9月にGAになったものですね。
Issueなどのタスクを委任すると、調査から実装、PR作成までバックグラウンドで進める。旧称がCopilot coding agentで、2025年9月にGAになったものですね。
テキトー教師DotAI 認定講師同期か非同期か、ここが体感で一番違います。前者は隣で一緒に作業、後者は出張に出す感じです。
室谷代表取締役業界構造としても、エージェントの主戦場がIDEの中からリポジトリ側に移っている流れが見えるんですよね。GitHubがそこを押さえに来ている。
テキトー教師DotAI 認定講師たしかに。待つ前提で設計されているのが、これまでのツールと違うところです。
custom agentsは「役割とツールのセット」を持たせた再利用型
室谷代表取締役3つ目がcustom agents。これは実行場所の話ではなくて、役割とツールのセットを定義して使い回す仕組みです。
.github/agents/ の下に <名前>.agent.md を置く形になる。テキトー教師DotAI 認定講師ツールを絞れるのが効くんですよ。読み取りだけ許可する、みたいに縛れるので、動ける範囲を先に決めておける。
室谷代表取締役呼び出せる場所も広くて、Copilot app、Copilot CLI、cloud agent、VS CodeやVisual Studioあたりから使えます。JetBrainsとXcodeはパブリックプレビュー扱いですね。
テキトー教師DotAI 認定講師ここまで来ると設定ファイルの話なので、最初から手を出すと疲れちゃいます。
VS CodeのAgent modeとGitHub上のcloud agent、使い方の違いはどこに出る？
室谷代表取締役動く場所が自分のマシンなのかGitHub側なのかで、依頼の出し方が変わるんですよ。VS Codeは対話で都度指示、cloud agentはIssueにアサインして任せる。
テキトー教師DotAI 認定講師現場感覚だと、急ぎの小さい修正はIDE、まとまった作業は委任、という分け方が自然に定着しますね。
室谷代表取締役同じ「agent」と呼んでいるのに、待ち時間の設計が真逆なんですよね。ここを混ぜると、後続の設定の話が全部おかしくなる。
テキトー教師DotAI 認定講師だから最初に地図を頭に入れておくのが大事です。まずIDEで触って感覚を作るのが分かりやすいと思います。
Issueに「Copilot」をアサインすると、PRが届くまで何が起きる？
IssueのAssigneesに「Copilot」を指定する
Issueに「Copilot」をアサインしてからPRが届くまでの流れ
- 01Issueを起票するリポジトリの「Issues」タブで、依頼したいタスクをIssueとして起票する
- 02Assigneesで「Copilot」を選ぶIssue右側の「Assignees」から「Copilot」を選ぶと委任が始まる
- 03調査・計画・実装が進むアサインするとCopilotが調査・計画・実装を進め、完了するとドラフトPRが作成される
- 04ドラフトPRを確認する返ってくるのはドラフトPRなので、いきなりマージせず中身を見て意図どおりか確かめる
- 05追加の指示はPRコメントで追加で直したいことは、そのPRのコメントで指示する
- リポジトリの「Issues」タブで、依頼したいタスクをIssueとして起票する
- Issue右側の「Assignees」から「Copilot」を選ぶ
- アサインすると、Copilotが調査・計画・実装を進め、完了するとドラフトPRが作成される
- 追加で直したいことは、そのPRのコメントで指示する
室谷代表取締役まず流れを押さえましょうか。Issueを書いて、右側のAssigneesで「Copilot」を選ぶ。
これだけで委任が始まるんですよね。
これだけで委任が始まるんですよね。
テキトー教師DotAI 認定講師たしかに。ただ最初に戸惑うのが「何を書けば伝わるのか」というところで。
現場感覚だと、Issueの本文がそのまま指示書になるので、ゴールと触ってほしくない範囲を書いておくと安定します。
現場感覚だと、Issueの本文がそのまま指示書になるので、ゴールと触ってほしくない範囲を書いておくと安定します。
室谷代表取締役丸投げって言いますけど、丸投げ先が読む前提でIssueを書くかどうかで結果が変わるわけですね。
テキトー教師DotAI 認定講師そうなんです。あとアサイン直後は何も起きてないように見えるので、心配になって自分で手を動かしちゃう人が多いです。
調査・計画・実装が進み、ドラフトPRが返ってくる
室谷代表取締役アサインした後は、裏で調査・計画・実装が順に進んで、最後にドラフトPRとして返ってくる。ここまでが一続きなんですよね。
テキトー教師DotAI 認定講師返ってくるのはドラフトPRなので、いきなりマージ対象ではないんですよ。まず中身を見て意図どおりか確かめる、という前提で受け取るのがいいです。
室谷代表取締役うちの現場だと、レビュー待ちの時間が一番高いので、ドラフトの段階で雑に通さない運用にしています。時給で換算すると、そこを飛ばす方が高くつくんですよね。
テキトー教師DotAI 認定講師追加で直したいときはPRのコメントで指示を出せます。Issueを書き直すより、差分を見ながらの方が伝わるので、現場ではそっちが多いです。
Agentsタブでできること——セッション管理・モデル選択・CLIへの引き継ぎ
- リポジトリ内の「Agents」タブを開く（全リポジトリ横断の専用画面だった従来のMission Controlに代わる画面）
- セッションを選ぶと作業ログを確認できる。モデルはデフォルトの「Auto」から変更できる
- 手元で続けたいときは「Checkout with GitHub CLI」→「Continue in Copilot CLI」でセッションを引き継ぐ
- 逆にCLI側からは
/delegateでリモートに戻せる。「Configure」でネットワーク・MCP、「Customize environment」でGitHub Actionsワークフローを編集できる
室谷代表取締役で、その管理画面がAgentsタブなんですよ。2026年1月に入ったもので、リポジトリの中にタブとして存在して、セッションごとのログを追える。
横断画面を置き換えた形ですね。
横断画面を置き換えた形ですね。
テキトー教師DotAI 認定講師ここが一番ハマりどころで。動いてるのか分からないまま放置、が起きにくくなるのは大きいです。
モデルも既定の「Auto」から選べますし。
モデルも既定の「Auto」から選べますし。
室谷代表取締役手元で続きをやりたくなったらCLIに引き継げるのも効きます。逆方向にも戻せるので、行き来する前提の設計なんですよね。
CLI側の基本操作はGitHub Copilot CLIの使い方で解説しています。
CLI側の基本操作はGitHub Copilot CLIの使い方で解説しています。
テキトー教師DotAI 認定講師「Customize environment」で環境のセットアップを仕込めると、依存関係のインストールで毎回つまずく、というのも減らせます。
2026年10月から始まった新しいCopilot in the cloud体験、何が変わった？
有料プランだけが新体験、無料はこれまで通り
室谷代表取締役まず起点を揃えておくと、2026年10月28日以降、GitHub.com と GitHub Mobile、それから Copilot in the cloud の新しい体験は、組織や企業のポリシーに従ったうえで有料プランのユーザーに展開されてるんですよね。
テキトー教師DotAI 認定講師そこ、最初に戸惑う人が多いんですよ。無料で触ってるのに説明と画面が違う、と。
Copilot Free は旧来の Copilot Chat 体験のままなので、同じ Copilot でも見えている世界が違うんです。
Copilot Free は旧来の Copilot Chat 体験のままなので、同じ Copilot でも見えている世界が違うんです。
室谷代表取締役つまり新機能の話を読む前に、自分がどっち側にいるかを確認しないと全部ずれる、と。ここは費用対効果の判断材料にもなりますよね。
有料プランに切り替えるかどうかで、そもそも触れる機能が変わるわけですから。
有料プランに切り替えるかどうかで、そもそも触れる機能が変わるわけですから。
テキトー教師DotAI 認定講師たしかに。まず自分のプランを確認、が最初の一歩ですね。
クライアント・セッション・環境の3つで整理する
室谷代表取締役新体験の面白いところは、概念が3つに割り切られたことなんですよ。クライアント、セッション、環境。
テキトー教師DotAI 認定講師クライアントは Web とか IDE、Copilot app、CLI、Mobile といった入り口ですね。セッションは作業そのもの。
環境はそれが実際に走る場所で、クラウドサンドボックス、GitHub Actions ランナー、リモートのカスタム環境の3種類です。
環境はそれが実際に走る場所で、クラウドサンドボックス、GitHub Actions ランナー、リモートのカスタム環境の3種類です。
室谷代表取締役入り口と作業と実行場所を分けた、と。地味ですけど、この整理ができるとどの機能をどこで使うかの判断が一気に楽になる。
仕組みの設計としてはかなり筋がいいと思います。
仕組みの設計としてはかなり筋がいいと思います。
テキトー教師DotAI 認定講師最初に戸惑うのが、この3つがごっちゃになることなんですよ。セッションを閉じることと環境を片付けることが別物、という感覚が最初はピンとこないんです。
Webで始めた作業をIDEやCLI、Mobileで続けられる
室谷代表取締役で、この分離がいちばん効くのが、同じセッションを複数のクライアントでまたげる点なんですよ。Web で投げた作業を IDE で開いて続ける。
Mobile から進み具合を見る。そういう持ち回りができる。
Mobile から進み具合を見る。そういう持ち回りができる。
テキトー教師DotAI 認定講師現場感覚で言うと、ここが一番わかりやすい変化ですね。以前はあの画面で始めた作業、に縛られていたのが、手元の道具に合わせて続きをやれる。
移動中に Mobile、席に戻って IDE、みたいな使い方が自然に成立します。
移動中に Mobile、席に戻って IDE、みたいな使い方が自然に成立します。
室谷代表取締役CLI への引き継ぎもできるので、詳しくはGitHub Copilot CLIの使い方｜インストールから料金・自動化までで解説していますけど、ターミナルに降りてそのまま詰める、という流れが現実的になってるんですよね。
テキトー教師DotAI 認定講師たしかに。ただ、続けられるのは同じセッションであって、環境まで同じとは限らないので、そこだけは意識しておきたいですね。
実行環境はクラウドサンドボックスとGitHub Actions、どっちを選ぶ？
セッション継続性・リポジトリスコープ・データ保持の比較
室谷代表取締役で、その実行環境なんですけど。大きく分けるとクラウドサンドボックスとGitHub Actionsランナーの2択になるんですよね。
テキトー教師DotAI 認定講師最初に戸惑うのがまさにそこです。「どっちが上なんですか」と聞かれがちなんですけど、優劣じゃなくて性質が違うんですよ。
室谷代表取締役項目ごとに並べると差がはっきりしますね。
| 項目 | クラウドサンドボックス | GitHub Actions |
|---|---|---|
| セッション継続 | クライアント間で共有・再開できる | GitHub Webサイトのみ |
| リポジトリスコープ | 1組織内の複数リポジトリ | 指定した単一リポジトリのみ |
| データ保持 | アカウントの有効期間中 | 28日間 |
| カスタム環境 | 対応していない | カスタムコンピューティング・セルフホステッドランナーに対応 |
テキトー教師DotAI 認定講師保持期間の差は地味に効きます。28日で消える前提かどうかで、ログや成果物の残し方が変わってきますから。
カスタムコンピューティングやセルフホステッドランナーが要るケース
室谷代表取締役逆に、Actions側じゃないと詰むのはどういう場面ですか。
テキトー教師DotAI 認定講師社内ネットワークにしかない依存を取りに行くとか、専用のマシンパワーが要るとか。あとビルドが重いリポジトリですね。
クラウドサンドボックスはカスタムコンピューティングに対応していないので、そこはActions一択になります。
クラウドサンドボックスはカスタムコンピューティングに対応していないので、そこはActions一択になります。
室谷代表取締役経営目線で言うと、セルフホステッドランナーは「タダで速くなる」選択肢ではないんですよ。立てるのも維持するのも人の時間がかかる。
時給換算すると、よほどビルドが重くない限りクラウド側で足りるという判断になりがちです。
時給換算すると、よほどビルドが重くない限りクラウド側で足りるという判断になりがちです。
テキトー教師DotAI 認定講師copilot-setup-steps.ymlで依存関係のインストールを仕込む
.github/workflows/配下にcopilot-setup-steps.ymlを作る- ジョブ名を
copilot-setup-stepsに固定する（この名前でないと読み込まれない） - 依存関係のインストールなど、エージェントの作業前に走らせたい手順をジョブの中に書く
- デフォルトブランチに置く（デフォルトブランチに存在する場合のみ読み込まれる）
室谷代表取締役この設定、要はエージェント用の下ごしらえを先に流しておく仕組みなんですよね。
テキトー教師DotAI 認定講師そうなんです。しかもセットアップが失敗しても、エージェントの作業自体は続行されるんですよ。
「失敗したら止まる」前提で身構えなくていいのが楽で。
「失敗したら止まる」前提で身構えなくていいのが楽で。
室谷代表取締役ただタイムアウトが最大59分なので、重いインストールを全部詰め込むと本番の作業に使える時間が削られます。ここは削れる手順を削る発想が要りますね。
テキトー教師DotAI 認定講師初めて触る人はこのファイルをデフォルトブランチ以外で作ってしまって「効かない」と悩むパターンがあるので、そこだけ注意してほしいです。
カスタムエージェント（.agent.md）はどう作る？
.github/agents/ に置くファイルとフロントマターの書き方
- リポジトリの
.github/agents/に<名前>.agent.mdを作る - 先頭に YAML フロントマターを書き、
descriptionは必須、nameは省略するとファイル名が使われる targetにvscodeまたはgithub-copilotを書いて利用環境を絞るtoolsを書く（省略すると全ツール有効。alias は shell / read / edit / search / web / custom-agent）modelで IDE 側の使用モデルを指定する- 本文に役割と指示を書く（プロンプトは最大30,000文字）
室谷代表取締役フロントマター、
description が必須で name は省略するとファイル名になるんですよね。ここを間違えると一覧に出てこないので、最初に疑う場所です。テキトー教師DotAI 認定講師最初に戸惑うのが
tools の扱いなんですよ。省略すると全ツールが有効になるので、何も書かずに試すと「全部触れる状態」から始まります。室谷代表取締役逆に言えば、読み取り専用にしたいなら
read と search だけ渡せばいい。alias が分かれているので、権限設計に近い感覚で組めます。テキトー教師DotAI 認定講師そこはチームに配るときに効きますね。
target で VS Code 側か GitHub 側かに絞れますし、同じファイルが Copilot app や CLI からも効くので、全体像は新機能まとめが分かりやすいです。効果的な.agent.mdに書くべき6要素と、失敗しがちな書き方
室谷代表取締役GitHub が2,500超のリポジトリを分析して出した知見として、効くのは6要素なんですよね。
- 実行可能なコマンド（フラグ込みで具体的に）
- テストの実行方法
- プロジェクト構造
- コードスタイルの具体例
- Git ワークフロー（ブランチ命名・コミット規約）
- 境界線（常に行う／確認が必要／絶対にやらない）
テキトー教師DotAI 認定講師現場でよく聞くのは「親切なアシスタントとして振る舞って」で終わってしまうパターンです。これだと判断材料がないまま動き出すので、レビュー側が疲れます。
室谷代表取締役境界線を3段階で書くのがミソで。曖昧なままツールだけ渡すのが一番怖いんですよ。
何をしてほしくないかが先に決まってないと、後から揉める。
何をしてほしくないかが先に決まってないと、後から揉める。
テキトー教師DotAI 認定講師あと過度に複雑な設計も失敗しやすいので、最小限から始めて困ったら追記するくらいでちょうどいいですね。
MCPサーバーをつないでツールの範囲を広げる
室谷代表取締役ツールの範囲は MCP で広げられます。リポジトリで設定済みの MCP ツールを
tools に並べる方法と、mcp-servers プロパティでそのエージェント専用のサーバーを書く方法の2つがある。テキトー教師DotAI 認定講師GitHub.com 側のコーディングエージェントだと、
github と playwright の MCP サーバーが最初から使えるんですよ。playwright は localhost 限定なので、そこは安心材料です。室谷代表取締役読み取り専用の
github が最初から入っているのは賢い設計だなと思います。外部ツールを足すほど、何をさせるかの線引きが先に要る。テキトー教師DotAI 認定講師順番が大事で、先に境界線を書いてから MCP を足すほうが事故が少ないですね。
インストラクション・プロンプトファイル・スキルとの使い分け
テキトー教師DotAI 認定講師ここ、ハマりやすいところで。同じ「指示を書く場所」が5つあるんですよ。
| 機能 | ファイル | 反映タイミング | ツール指定 |
|---|---|---|---|
| カスタムインストラクション | .github/copilot-instructions.md | 常に反映 | 不可 |
| パス指定インストラクション | .github/instructions/*.instructions.md | パス一致時のみ | 不可 |
| プロンプトファイル | .github/prompts/*.prompt.md | スラッシュコマンドで呼び出し | 可 |
| カスタムエージェント | .github/agents/*.agent.md | エージェント指定時のみ | 可 |
| エージェントスキル | .github/skills/*/SKILL.md | AIが必要と判断したとき | 可 |
室谷代表取締役優先度はカスタムエージェント＞パス指定＞通常のインストラクション。使い分けは、役割とツールセットを丸ごと再利用したいならエージェント、タスク固有の指示だけならスキルが軽いんですよね。
テキトー教師DotAI 認定講師プロンプトファイルはスラッシュコマンドで呼ぶ前提なので、「この作業のときだけ」の手順書を置く場所という感覚が近いです。
室谷代表取締役全部を最初から揃えなくていい。常に効かせたい規約だけインストラクションに置いて、残りは必要になってから足す。
運用コストで言えばそのほうが安く済みます。
運用コストで言えばそのほうが安く済みます。
エージェントが使える範囲と制限——59分・1ブランチ・1PR
エージェントが使える範囲と制限
最大実行時間59分
Copilot上で走るGitHub Actionsのセッションは最大59分。延長もバイパスも不可。59分で終わる粒度にタスクを分割する。
単一リポジトリのみ
タスク開始時に指定した1リポジトリ内でしか変更できない。複数リポジトリをまたぐ作業は対象外。
PR作成がブロックされる場合
リポジトリのルールセットやブランチ保護がPR作成を妨げることがある。管理者側でCopilotのバイパスを設定して解消。
1セッション1ブランチ・1PR
1セッションは一度に1ブランチ、タスクごとに開けるPRは1つ。並列実行するとレビュー待ちが積み上がる。
GitHubホストのリポジトリ限定
GitHubがホストしているリポジトリでしか動かない。社内の別基盤のものは対象外なので導入前に棚卸し。
実行時間とリポジトリスコープに掛かる制限
室谷代表取締役ここ、先に押さえておきたいんですけど、Copilot上で走るGitHub Actionsのセッションは最大実行時間が59分で、延長もバイパスもできないんですよね。
テキトー教師DotAI 認定講師現場でよく聞くのは「大きめのリファクタを任せたら途中で終わってた」というパターンです。制限というより、タスクの切り方の話なんですよ。
室谷代表取締役そうなんです。59分で終わる粒度に最初から割っておく。
MYUUUの現場でも、大きい依頼を1本で投げるより、小さく分けて並べた方が結果的に速いんですよね。見積もりが甘いと待ち時間だけ溶けます。
MYUUUの現場でも、大きい依頼を1本で投げるより、小さく分けて並べた方が結果的に速いんですよね。見積もりが甘いと待ち時間だけ溶けます。
テキトー教師DotAI 認定講師リポジトリの範囲も地味に効きます。Actionsで動かすとタスク開始時に指定した単一リポジトリの中でしか変更できないので、複数のリポジトリをまたぐ作業を頼むと「届いてない」となるんですよ。
PR作成がブロックされるケースと管理者側の設定
テキトー教師DotAI 認定講師あと初めて触る人が戸惑うのが、エージェントが動き終わったのにPRが来ないケースです。リポジトリのルールセットやブランチ保護がPR作成を妨げることがあって、ここは権限の話なんですよね。
室谷代表取締役それは管理者側でCopilotのバイパスを設定すれば通せる、と。組織で入れるなら最初に潰しておく詰まりどころなんですよ。
あと、1セッションは一度に1ブランチで、タスクごとに開けるPRは1つだけ。この前提で運用を組まないと、PRが乱立してレビューが詰まります。
あと、1セッションは一度に1ブランチで、タスクごとに開けるPRは1つだけ。この前提で運用を組まないと、PRが乱立してレビューが詰まります。
テキトー教師DotAI 認定講師たしかに。並列で走らせた分だけレビュー待ちが積み上がる構造になるので、そこは人の側の設計なんですね。
室谷代表取締役あとGitHubがホストしているリポジトリでしか動かないので、社内の別基盤に置いてあるものは対象外。ここは導入前に棚卸ししておく話です。
Copilot CLIに用意されたビルトインエージェント
室谷代表取締役自前でエージェント定義を書く前に、CLI側に何が最初から入っているかを見た方が早いんですよね。用意されているのはこのあたりです。
- explore（コードベース探索）
- task（コマンド実行）
- general-purpose（別コンテキストでの作業）
- code-review（変更レビュー）
- research（調査）
- rubber-duck（意見出し）
- security-review（セキュリティレビュー）
テキトー教師DotAI 認定講師なるほど。最初に戸惑うのが「自作しないと使えないのか」という思い込みなんですよ。
レビュー系はビルトインで足りることが多いので、まずここから当てにいく方が現実的ですね。
レビュー系はビルトインで足りることが多いので、まずここから当てにいく方が現実的ですね。
室谷代表取締役CLIの基本的な操作から入りたい場合は、GitHub Copilot CLIの使い方｜インストールから料金・自動化までの方が手順として追いやすいと思います。セッションをAgentsタブから引き継ぐ流れもそちらで説明されています。
テキトー教師DotAI 認定講師ビルトインで物足りない部分だけ自作にする、という順番が無駄がないですね。
料金はいくらかかる？プレミアムリクエストとプラン別クレジット
1セッションで消えるのは「プレミアムリクエスト1回＋Actions実行時間」
室谷代表取締役エージェントを動かすと財布に何が起きるのか、先に押さえておきたいんですよね。cloud agentは1セッションにつきプレミアムリクエストを1回消費します。
それに加えて、GitHub Actionsの実行時間ぶんのコストが乗ってくる。
それに加えて、GitHub Actionsの実行時間ぶんのコストが乗ってくる。
テキトー教師DotAI 認定講師二重取りなんですね。初めて触る人が「あれ、思ったより減ってる」となるのはまさにそこなんですよ。
書いたコードの量じゃなくて、走らせた時間に課金されてる感覚です。
書いたコードの量じゃなくて、走らせた時間に課金されてる感覚です。
室谷代表取締役しかも1セッションは59分が上限なので、重いタスクを投げるほどActions側が伸びる。時給で換算すれば安いんですけど、放っておくとじわじわ効いてくるタイプのコストなんですよ。
テキトー教師DotAI 認定講師現場でよく聞くのも「1個投げただけでこんなに減るの？」という声です。まずは小さめのIssueで1回回して、減り方を見るのが早いと思います。
プラン別のクレジット配分、ここだけ見れば分かる
プラン別クレジット配分
| プラン | 月額 | ベース | フレックス | 月間合計 |
|---|---|---|---|---|
| Free | $0 | — | — | 補完2,000回/月・autoモデルのみ |
| Pro | $10 | 1,000 | 500 | 1,500 |
| Pro+ | $39 | 3,900 | 3,100 | 7,000 |
| Max | $100 | 10,000 | 10,000 | 20,000 |
| Business | $19/付与シート | — | — | 1,900（共有プール） |
| Enterprise | $39/付与シート | — | — | 3,900（共有プール） |
室谷代表取締役その上限を決めるのが、プランごとのクレジット枠です。並べるとこうなります。
| プラン | 月額 | ベース | フレックス | 月間合計 |
|---|---|---|---|---|
| Free | $0 | — | — | 補完2,000回/月、autoモデル選択のみ |
| Pro | $10 | 1,000 | 500 | 1,500 |
| Pro+ | $39 | 3,900 | 3,100 | 7,000 |
| Max | $100 | 10,000 | 10,000 | 20,000 |
| Business | $19/付与シート | — | — | 1,900（共有プール） |
| Enterprise | $39/付与シート | — | — | 3,900（共有プール） |
テキトー教師DotAI 認定講師Freeはそもそもエージェントを回す前提の枠ではないですよね。Pro+でプレミアムモデルに手が届く、Maxは新モデルへの優先アクセスが付く、という序列なんですね。
室谷代表取締役BusinessとEnterpriseはシート課金で、しかも共有プール。ここが経営目線だと一番効くところで、部署ごとに配るというより組織で1つの財布をみんなで使うイメージなんですよ。
誰がどれだけ使ったかが見えにくい。
誰がどれだけ使ったかが見えにくい。
テキトー教師DotAI 認定講師そこは運用の設計次第ですね。まずProで自分の消費量を体で覚えてから組織に広げる、という順番が無難だと思います。
料金体系の全体はGitHub Copilotの料金を個人・法人別に整理のほうで詳しく追っています。
料金体系の全体はGitHub Copilotの料金を個人・法人別に整理のほうで詳しく追っています。
プールを超えたら1クレジット0.01ドル、判断ラインはどこか
室谷代表取締役超過分は1クレジットあたり0.01ドルで個別課金。単価だけ見ると小さいんですけど、毎日エージェントを回すチームだと読み方が変わってきます。
テキトー教師DotAI 認定講師ええ。「足りなくなったら買えばいい」で済む話ではなく、毎月の変動費として予算に載るかどうかですからね。
室谷代表取締役そうなんですよ。導入するかどうかの判断ラインは、その月に何セッション回すかを先に見積もって、Pro+やMaxの固定枠に収まるかどうかを確かめる。
収まらない前提なら、それはもう個人プランの話じゃなくて組織の予算設計の話になります。
収まらない前提なら、それはもう個人プランの話じゃなくて組織の予算設計の話になります。
テキトー教師DotAI 認定講師最初の一歩は、1〜2週間Proで回して、実際に何セッション使ったかを数えてみるのが一番確実だと思います。
どの機能から使い始める？役割分担と導入の順番
三つを並べると、どこで使うかが見えてくる
室谷代表取締役ここまでの話を踏まえて、じゃあ実際どれから触るのかという順番の話をしたいんですよね。三つ並べると役割が割とはっきりするんですよ。
テキトー教師DotAI 認定講師たしかに。初めて触る人が一番詰まるのがそこなんですよ。
「agent modeとcloud agentって別物なんですか」というのは現場でよく聞きます。
「agent modeとcloud agentって別物なんですか」というのは現場でよく聞きます。
| 機能 | 動き方 | 向いている場面 |
|---|---|---|
| agent mode | IDE内で対話しながらその場で編集 | 手元で詰めたい実装・試行錯誤 |
| cloud agent | タスクを委任→バックグラウンドで調査・実装・PR作成 | まとまった作業を任せたいとき |
| custom agents | 役割とツールを固定した再利用可能なエージェント | チームで同じ進め方を繰り返したいとき |
室谷代表取締役手元で対話しながら直すのがagent mode、投げたら戻ってくるのがcloud agent、そして「うちはこの役割で動かす」を固定するのがcustom agentsという整理なんですよね。
テキトー教師DotAI 認定講師そうですね。custom agentsは機能というより「型」なので、いきなりそこから入ると中身が分からないまま型だけ作ることになるんですよ。
順番は「手元 → 委任 → 標準化」
導入の順番は「手元 → 委任 → 標準化」
- 01agent modeで小さめの修正を対話しながら終わらせるIDE内で対話しながらその場で編集。手元で詰めたい実装・試行錯誤に向く
- 02IssueのAssigneesに「Copilot」を指定し、ドラフトPRが届くまでを体験cloud agentはタスクを委任→バックグラウンドで調査・実装・PR作成。まとまった作業を任せたいときに向く
- 03`.github/agents/` に `<名前>.agent.md` を置き、`description` と `tools` を最小限で書くcustom agentsは役割とツールを固定した再利用可能なエージェント。同じ依頼を何回か手で繰り返した後に着手
- 04困った箇所だけ後から追記して育てる最初から完成形を目指さず、問題が起きたら追記する運用
- IDEでagent modeを開き、小さめの修正を対話しながら終わらせる
- IssueのAssigneesに「Copilot」を指定して、ドラフトPRが届くまでを一度体験する
.github/agents/に<名前>.agent.mdを置き、descriptionとtoolsを最小限で書く- 困った箇所だけ後から追記して育てる
室谷代表取締役この順番が失敗しにくい理由は、1で「何ができるか」の解像度が上がってから2に進むからなんですよ。いきなりIssueに投げると、返ってきたPRの良し悪しが判断できないんですよね。
テキトー教師DotAI 認定講師現場感覚で言うと、2で一回PRが返ってくる体験をすると、その後の反応が変わるんですよ。「任せていいんだ」という感触が一度あるかどうかで。
室谷代表取締役3に入るのは、同じ依頼を何回か手で繰り返した後でいいと思います。人数が多い組織だとcustom agentsを先に作って「これに従って」となりがちなんですが、それだと誰も中身を理解しないまま運用だけ始まる・・・
テキトー教師DotAI 認定講師そこは同じ見方で、最初は最小限で書いて、困ったときに足すくらいがちょうどいいですね。
チームに広げる段階で効く判断
室谷代表取締役広げるときに効くのが、custom agentsに何を書くかなんですよね。GitHubが2,500超のリポジトリを分析した知見として、実行可能なコマンド、テストの実行方法、プロジェクト構造、コードスタイルの具体例、Gitワークフロー、境界線の6要素が挙がっているんですが、要するに新人に渡す引き継ぎ書と同じなんですよ。
テキトー教師DotAI 認定講師曖昧な定義は失敗しやすい、というのも現場でよく聞きます。「親切なアシスタント」のような書き方だと動かないんですよね。
室谷代表取締役経営目線で言うと、ここは投資対効果が出る場所で、境界線を「常に行う／確認が必要／絶対にやらない」の3段階で書いておくだけで、触ってほしくない所を触られる事故が減る。レビュー工数で戻ってくるんですよ。
テキトー教師DotAI 認定講師最初から完成形を目指さず、問題が起きたら追記する。その運用のほうが結果的に早いですしね。
よくある質問
Q1. エージェントが出したPRは、そのままマージしていい？
室谷代表取締役「アサインしてPRが届いたら、そのままマージしていいの？」って聞かれるんですけど、そこは普通のPRと同じ扱いでいいんですよね。誰が書いたかじゃなくて、何が変わったかを見る。
テキトー教師DotAI 認定講師たしかに。「エージェント製だから怪しい」も「エージェント製だから信用する」も両方外してて、見るべきは差分とテスト結果なんですよね。
室谷代表取締役責任の所在は人間から逃げないってことです。レビューを飛ばすコストの方が、よっぽど高くつきます。
Q2. 途中で失敗したり、意図と違うPRが来たらどう立て直す？
室谷代表取締役途中で止まる、意図と違うPRが来る、みたいなのは起きる前提で考えてます。で、こういうときって企業だと「じゃあもう使わない」になりがちなんですけど・・・
テキトー教師DotAI 認定講師最初に戸惑うのがまさにそこなんですよ。ブランチごと捨てて、Issueの書き方を変えてもう一度投げる。
指示が曖昧だと、エージェントは曖昧なまま突き進んじゃいます。
指示が曖昧だと、エージェントは曖昧なまま突き進んじゃいます。
室谷代表取締役新人と同じで、一回の失敗で判断しない方がいい。Issueの解像度を上げる手間は、たぶん回収できます。
Q3. Cursor や Claude Code とどう使い分ける？
室谷代表取締役Cursor とか Claude Code と何が違うの、って聞かれるんですけど、構造が違うんですよね。あっちはエディタや手元が起点で、CopilotのエージェントはIssueとPRが起点なんですよ。
テキトー教師DotAI 認定講師そうですね。隣で手を動かしながらいてほしいのか、放置して戻ってきたらPRができててほしいのか。
欲しい体験が違うと、同じ「エージェント」でも評価が真逆になります。
欲しい体験が違うと、同じ「エージェント」でも評価が真逆になります。
室谷代表取締役既にCopilotを契約してるチームなら、導入の摩擦が小さいのは効きます。ツールを増やすのって、地味に高いんですよ。
Q4. プライベートリポジトリのコードはどこまで外部に出る？
室谷代表取締役プライベートリポジトリのコードがどう扱われるか、そこは導入前に必ず確認します。エージェントは結局リポジトリを読んで動くので、権限の設計がそのままリスクになります。
テキトー教師DotAI 認定講師初めて触る人が一番不安に思うところですよね。「動くから便利」で広げる前に、誰の権限で、どこまで読めるのかを決めておく。
室谷代表取締役公式のドキュメントと、組織側のポリシー設定を突き合わせるのが先ですね。ここは雰囲気で進めると後で痛い。
Q5. 逆に、エージェントに任せない方がいいタスクは？
室谷代表取締役任せちゃいけないのは、要件がまだ固まってない設計の話とか。あれは対話しながら詰める作業なので、投げても返ってくるものが薄いんですよね。
テキトー教師DotAI 認定講師現場でよく聞くのは「調べるのは速いけど、決めるのは苦手」って体感です。Issueに落とせる粒度まで噛み砕けているかどうかが分かれ目になります。
室谷代表取締役だから、いきなり全部じゃなくて、まずは小さく切ったタスクで往復に慣れる。順番を間違えると「使えない」で終わっちゃう。
まとめ
室谷代表取締役振り返ると、agent modeは手元、cloud agentはIssue起点で放置、custom agentsはチームの型を埋め込む、という役割の違いなんですよね。
テキトー教師DotAI 認定講師そうやって整理できると、どれか一つを選ぶ話じゃなくて、分担の話になるんですよ。全部を一度に入れる必要もないですし。
室谷代表取締役コストも、プレミアムリクエストがどこで減るかを知ってから配分を決めるのが順番です。時給で考えれば、往復が一回減るだけで全然違いますから。
テキトー教師DotAI 認定講師最初の一歩は、小さめのIssueを一個投げてみる、でいいと思います。返ってきたPRの物足りなさも含めて、それが次の指示の書き方になります。
室谷代表取締役そうですね。まず一個、試してみてください。
