GitHub Copilot Coding Agentを数週間にわたって試してみた。
そこで得られた知見をもとに、実務での導入を見据えた活用方法について考察した内容をまとめておきたい。

2025/07/11追記：
この記事はプレミアムリクエストの消費量が変更される前に書いたものですので、ご注意ください。

導入にあたっての関心事

投資対効果

まず結論から書くと、大半の人はプレミアムリクエストを積極的に活用してタスクを依頼すべきである。¹
プレミアムリクエストを全員がきれいに使い切らなくても、1人がフル活用すれば月額20ドルで1万円以上の効果が期待できる。
実際には5分以上かかるタスクが大半であることから、投資対効果はさらに大きくなるだろう。
まずは「各人がCoding Agentを使って月1時間くらい削減する」ことを目標に置けば、投資対効果としては十分だと考えている。

上記の前提として以下を置いており、1タスクあたりのコストはプレミアムリクエストの実測データに基づく。

• Copilot BusinessからCopilot Enterpriseへのアップグレード²：月額+20ドル
• 1か月に使用可能なプレミアムリクエスト：1000
• 1タスクあたりのコスト：プレミアムリクエストを50消費、275円

仕事を外部委託する場合と比較するため、人月単価ごとの時間単価換算表を以下に示す。

以上から試算すると、以下のことがわかる。

• 人が5分かかるタスクの場合、人月単価60万円以上であればCoding Agentを使った方がリターンがある（312.5円 > 275円）
• 人が5分かかるタスクを月20件依頼した場合、人月単価100万円なら1万円程度の効果が出る（10,420円 > 20ドル）

セキュリティリスク

GitHub Copilot Coding Agentは、セキュリティリスクがしっかりと考慮された仕様となっている。
採用する際に考慮すべき点は、主に以下の2点。

• ファイアウォール（許可するインターネットアクセス）
• 利用してよいMCPサーバ

インターネットアクセスがホワイトリスト方式で制限されているため、大企業でも導入しやすくなっている。
MCPサーバについては導入時にレビューを行うと良いだろう。³

Coding Agentが操作可能な範囲は制限がかけられており、例えば以下のような点が考慮されている。

• Coding AgentがPush可能なブランチは制限される
• PR内で作成したGitHub Actionsは、人の承認なしには実行されない
• APIキー等をプッシュされるリスクは、GitHubリポジトリの設定でシークレットスキャンやプッシュ保護で防止できる

Coding Agent活用に適するタスクの種類

ゴールが明確なタスク

Coding AgentはIssueの内容に基づいてタスクを遂行するため、ゴールが明確に提示できるタスクを依頼するのが望ましい。
手段（How）の提示は必要最小限にとどめ、完成系の状態を示すのがよいだろう。
試行錯誤しながら実装することが求められる場合は、ClineやClaude Codeといった対話型ツールで進める方が適している。

タスクの例として以下が挙げられる。

• Terraform定義の更新：宣言的な記述はゴールを明示することと同じなので、相性がよい
• デッドコードの削除：「使われていなければ消して良い」という水準が明確である

成果物の許容範囲が広く、高確率で成功が期待できるタスク

Coding Agentには、一度で期待通りの成果を出せる可能性が高いタスクを依頼するのがよい。
うまくいかなかった場合、PRで何度もコメントするとプレミアムリクエストを消費してしまう。
さらに手動での修正が必要となった場合は、かえって手間がかかることもある。

タスクの例として以下が挙げられる。

• プロトタイピング：保守性などを気にしなければコードレビューはスキップできる

独立性が高く、影響範囲が限定的なタスク

既存のソースコードとの相互作用が少なければ、検証やレビューは容易になる。
また必要に応じてコードを書き直すこともできるため、求められる保守性・可読性の水準も高くない。
これは前述の成果物の許容範囲が広いタスクと共通する特性である。

タスクの例として以下が挙げられる。

• 画面数や内部状態が少ないシンプルなフロントエンドアプリ
• GitHub Actionsのワークフロー

成果物をレビューしやすいタスク

生成AIやAgent全般に当てはまることだが、成果物をレビューしやすいタスクを依頼するのがよい。
逆にレビューしづらいタスクとは「予期しない箇所の変更」や「不適切な作業方法」が懸念されるタスクである。

例えば、CSVを編集するタスクを考えても、それぞれ以下のようにレビューのしやすさが異なる。

• レコード（行）を追加するタスク：PRの差分比較でレビューすることは容易
• カラム（列）を変更するタスク：PRの差分比較では視認性がやや低く、レビューしづらい
• 2つのカラムの内容を統合するタスク：レビューよりも自分でExcel編集した方が早くて確実かもしれない

Coding Agentの作業過程を見れば品質担保できるかもしれないが、成果物だけで品質担保できる方が認知負荷は抑えられる。
したがって成果物をレビューしやすいタスクを切り出してアサインすることが重要である。

人間がやると時間のかかるタスク

これはCoding Agentが得意かどうかというより、投資対効果の観点だ。
プレミアムリクエストの消費量が同等であるなら、人間がやると時間のかかるタスクを依頼した方がよい。
特に人間のタイピング速度では生成AIに敵わないため、この優位性を積極的に活用すべきである。
また、行数の多いファイルや複数箇所への変更が求められる作業も、画面スクロールに要する時間を考えると効果的だろう。

タスクの例として以下が挙げられる。

• フロントエンドのプロトタイピング：10回程度の依頼でも、数千行程度のソースコードを生成することができる

Coding Agent活用に向けたユースケース

プランニング：見積もりとAI駆動開発

スクラムのプランニング時などにCoding AgentへIssueをアサインし、そのPRを活用することができる。
具体的には以下のような使い方や効果が期待できる。

• 見積精度の向上: Coding Agentによって作成されたPRを見れば、そのIssueの複雑性が把握しやすくなる
• 認識齟齬の抑制: Coding Agentによる変更内容について過不足を議論することで、ゴールの認識齟齬を埋めやすくなる
• 開発効率の向上: Coding Agentが作成したPRのブランチをベースにして、開発をスタートできる

ただし、「生成AIが作成したブランチを整理する」という作業が多くなると開発者のストレスが大きくなる可能性には要注意。

フロントエンドのプロトタイピング

画面数の少ないフロントエンドであれば、Coding Agentを活用して手軽に試作できる。⁴
フロントエンドはコードを全て読まずとも操作による動作確認が可能なため、プロトタイピングには特に効果的。
VercelやNetlifyと連携し、PRごとにプレビュー環境が作成される機能を活用すると、さらに効率的になる。

ただし2025年6月現在、技術的な知識なしにCoding Agentの開発をうまくコントロールすることは難しいと感じている。
細かいタスクに分割してアサインした方がミスなく遂行できる可能性が高まるが、これには技術的な知識も求められる。

ドキュメントを定期的に更新してもらう

ソースコードなどの構成から作成できるドキュメントは、作成を依頼するのも一案。
ドキュメントにどのような内容が出力されるかは想定しづらいため、章構成だけこちらで指示するとよいだろう。

その他、Coding Agentができること

実際に使用する中で興味深かったCoding Agentの振る舞いをまとめてみた。

ツールを自律的にインストールして実行する作業

Coding Agentは、必要に応じてツールの必要性を判断し、インストールして使用することがある。
実際に確認できたのは、CIのレポートを出力するGitHub Actionsのワークフロー作成を依頼したケース。
READMEにサンプル画像が埋め込まれていたが、これはwkhtmltoimageを使ってHTMLファイルから生成されたものだった。
その作業過程を調べると、wkhtmltopdfをインストールしていた。

コンフリクトの解消作業

Coding Agentが作成したPRがコンフリクト状態になった際、コンフリクトの解消を依頼することで対応してくれた。
しかし、解消できていないのに「解消できた」と返してくるケースもしばしばあり、何度依頼しても解決できないこともあった。
このようなときはそのPRを諦めて、結局IssueにCopilotをAssignし直したほうが効果的だった。
コンフリクトの解消にCoding Agentを使用するのはプレミアムリクエストが勿体ないので、今後の改善に期待したい。

作業の追加指示への対応作業

Coding Agentが起動した直後に追加コメントした場合、一度の起動で両方の指示を参照して対応してくれることがあった。
これは5月の利用時には確認できなかった挙動で、サービスのアップデートによるものか、タイミングによるものかは不明。
一度の起動でそれなりのプレミアムリクエストを消費することになるため、追加指示ができるのはありがたい。

ただし現状のUIでは「作業中のCoding Agentの様子を見て、追加で指示を出す」といった使い方はあまり想定されていない。
あくまで「IssueをアサインしたりPRでコメントした後、しばらく待ってから確認する」という使い方が基本となる。

curlでAPIを叩いて動作確認

Next.jsのアプリ開発を依頼する際、curlコマンドを使ってAPIの動作を確認していた。
これは他のCoding Agentでもよくある振る舞いなのかもしれないが、初めて見たため興味深く感じた。

RAGを使ったタスク遂行に必要なコンテキストの理解

Coding AgentのRAGの仕組みで分析したように、ベクトル検索を活用してリポジトリ内の関連ファイルを参照している。
そのため、タスクの前提説明が多少不足しても補うことができるし、関連のあるファイルにもある程度辿り着くことができる。

IssueやPRコメントに添付された画像ファイルの参照

IssueやPRコメントはテキストだけでなく、添付された画像ファイルも参照することができる模様。
そのため、具体的に修正してほしい箇所を説明する際、スクリーンショットを添えることもできる。

Commitハッシュを参照する作業

PRコメントでハッシュ値を指定してRevertを実行したり、他ブランチのハッシュ値を指定してcherry-pickも実行できた。
コメントで修正を指示してイマイチな構成になってしまった場合、ハッシュ値を指定して指示できるのは便利。

Copilot Chatから依頼を受けて作業する

Issueを作成せずに、Copilot Chatから直接Coding Agentに作業を依頼することも可能。
ただ個人的な意見としては、Issueを作成してアサインした方が依頼内容も記録に残るため好ましいと感じている。

Tips

PRを作り直してもらう

CopilotをIssueから外して再度アサインすると、新たにPRを作成して作業してくれる。
もし追加指示でPRがカオスになってしまったら、PRを破棄してゼロからやり直すことも一案。

Coding AgentがPRのコメントに反応しないようにする

PRでコメントすると、Coding Agentは修正したり返答したりしてくれる。
しかしメンションせずに感想をコメントしただけで反応することがあり、過剰反応と感じることがある。
Coding Agentの作りかけを開発メンバーで引き取ったりレビューするときには、特に困るだろう。

こういうときは、PRのAssigneeからCopilotを外せば反応しなくなるようだ。
ただし1度外すと再アサインできず、メンションしても反応しなくなるので注意。（2025/06/22時点）

アンチパターン

すべてのタスクをCoding Agentでこなそうとしてしまう

プレミアムリクエストの枠がある以上、GitHub Copilot Coding Agentに任せるタスクは選別した方がよい。
プレミアムリクエストの追加購入ができる場合でも、できるタスク・できないタスクは見極める必要がある。
PRでコメントすると修正もしてくれるが、何度かコメントしてもバグがうまく直らないときは、諦めるのも一つの選択肢。

またIssueテンプレートやMCPサーバは整備していくとよいが、本質的でないプロンプトは作り込みすぎる必要はない。
数ヶ月ごとにモデルはアップデートされるため、時間が解決する可能性があるならそこに任せるのも一案だろう。

学習・学びに繋がるタスクをCoding Agentに依頼してしまう

ここを誤ると「ソフトウェアを理解しない人が外注する」時代に逆戻りすることになる。
内製開発する組織であるならば、理解が不十分な技術や試行錯誤が必要な領域は、自分で取り組んだ方がよいだろう。
和田卓人氏の言葉を借りるなら「労力は外注できるが、能力は外注できない」。