GitHub Copilot Coding Agentをプロダクト開発で使ってみて

2025年11月18日 2026年2月27日

muramotonaoki

こんにちは🖐️
AIソリューショングループの村本です。

本記事では、2025年5月に登場したAIコーディングツールGitHub Copilot Coding Agentを、Know Narrator（ノウナレーター）開発チームがどのように活用しているのか紹介します。

「AI駆動開発」、「仕様駆動開発」、「Vibe Coding」、「Agentic Coding（エージェンティックコーディング）」など様々な用語が話題になっている中で、実際のプロダクト開発の現場でどのような変化が起こっているかの参考になればと思います。

細かな活用テクニックなどは別記事で取り上げる予定なので、今回は「開発プロセスの変化」と「チーム文化への影響」に焦点を当てていきます。

GitHub Copilot Coding Agentを使ったVibe Coding会についての記事もあわせて参照ください！

Vibe Coding（バイブコーディング）とは

Vibe Codingは、開発者が「こんなものを作りたい」というイメージを自然言語でAIに伝え、AIがコードを自動生成する新しい開発スタイルです。

従来のように細かな仕様や設計を決めてから実装するのではなく、開発したいアプリケーションの雰囲気（vibe）や開発の意図を対話形式でAIコーディングツール等に入力し、コードが生成されることで開発者のよりイメージに沿ったアプリケーションを構築します。

1. AIコーディングツール「GitHub Copilot Coding Agent」とは
2. Know Narrator開発チームへの導入と活用の広がり
3. AIコーディングツールの活用方針とチームの変化
4. メリットと発生した課題
5. まとめ：AIとともに進化する開発チームへ
6. 最後に...

1. AIコーディングツール「GitHub Copilot Coding Agent」とは

GitHubは2025年5月、「GitHub Copilot Coding Agent（コーディングエージェント）」という新機能を発表しました（以下、「Coding Agent」と表記します）。

Coding Agentは、GitHub上のIssueを起点にバックグラウンドで実装タスクを遂行し、ドラフトのプルリクエスト（PR）を自動生成するよう設計された非同期型の開発支援機能です。従来のVSCode上でのコード補完やAgentモード、PR提出時のCopilotレビューとは異なる新しい仕組みです。

実際に使ってみての印象ですが、リポジトリ全体を把握したうえでのコード生成がかなり得意な傾向がありました。従来のVSCode拡張に存在していたAgentモードよりも、生成されるコードの質は高いです。

2. Know Narrator開発チームへの導入と活用の広がり

2.1 導入から現在の活用状況

Coding Agentが利用可能になった2025年5月末、私たちKnow Narrator開発チームではすぐに利用を開始しました。

電通総研の生成AI活用プラットフォーム： Know Narrator

電通総研の生成AI活用プラットフォーム Know Narrator(ノウナレーター)は、生成AIの活用業務を拡げるために電通総研が独自開発した生成AIプラットフォームです。ビジネス…

AITC | AI TRANSFORMATION CENTER

当初はプレミアムリクエスト（リクエスト可能な枠）の消費量が生成コードの量にも依存しており、すぐに上限に達するという課題がありました。しかし、7月のアップデートで「1セッション＝1リクエスト」方式に変更され状況が大きく改善。リクエスト制限をほぼ気にせず使えるようになり、活用が一気に加速しました。

参考：GitHub Copilot における要求 - GitHub Docs

Know Narratorでは月次リリースのサイクルで開発を進めており、各リリースごとのPR数を定量的な指標の一つとして観察しています。2025年9月時点では、次のような傾向が見られました。

全PRの約40〜60％がCoding Agentによって作成されたもの
（多くはその後、人による修正が加えられています）
リリースあたりのPR総数は導入前比で約1.8〜2.0倍に増加

PRは大きさや内容にばらつきがあるので絶対的な評価軸ではないですが、チーム全体でCoding Agentを日常的に利用していることを示していると感じています。

導入初期にはリクエスト失敗などの不安定な挙動もありましたが、現在は安定して動作しており、開発プロセスの一部として定着しています。

2.2 「作る→触る→直す」を重視するスタンスとの親和性

Coding Agentの活用がここまで広がった背景には、チームがもともと大切にしてきた「作る → 触る → 直す」サイクルを小さく・早く回すというスタンスもポジティブな要素となりました。

Know Narrator開発チームでは、以下の3つのルールを守っていればPRを積極的にマージし、開発環境で動作確認を行う方針を取っています。

Copilotレビューの提案内容を確認し、必要に応じて修正する
（Coding Agentとは別の機能で、PRに対して提案を行うもの）
開発メンバー1名によるレビュー承認を得る
CIテストをパスする（Linter・型チェック・ライセンス・単体テストなど）

「実際の動作環境でしか見つからない問題もある」、「PR作成者とレビュアーが等しく責任を持つべき」という考えのもと、このルールを運用しています。レビューを重厚にするのではなく、チーム全体が責任をもって触って直すことを重視しており、Coding Agent導入後もこのスタンスは変わっていません。もちろん、前提としてレビュー担当者がしっかりレビューをするのは重要です。

Coding Agentの導入によって「作る」工程は明確に早く・多くこなせるようになりました。しかし、レビューや承認プロセスがもっと厳しい場合、エージェントがいかに早くPRを出したとしても、次のステップに進むまでに時間がかかっていたでしょう。そして「レビューがボトルネックだ」と言っていたかもしれません。

私たちが現在のレビュープロセスで一定の品質を保てているのは、「比較的スモールチームでコミュニケーションの取りやすいチーム体制である」という点も大きいと感じています。

他にも、コード自体をレイヤー化していた点も導入しやすさにつながった面がありますが、機会があれば別記事で紹介しようと思います。

3. AIコーディングツールの活用方針とチームの変化

3.1 活用ルールと運用方針

Coding Agent を導入するにあたり、私たちのチームでは大きくプロセスを変えてはいません。前節でも触れていますが、PRレビューやマージの進め方など既存の開発プロセスをそのまま維持したうえで、以下の2つの方針のみ策定しました。

Coding Agent に依頼するかどうかは、各メンバーが自由に判断する
Coding Agent が作成したコードは、タスク担当者がファーストレビュアーとなる
（作成者によるファーストレビューとは別に、2.2節で述べたレビュープロセスを実施する）

なお、Coding Agentを自分たちに合った形で利用するための「カスタムインストラクション（プロジェクトの文脈やスタイルガイドを与える設定）」も併せて整備を進めています。このあたりについては別の記事で紹介する予定です。

3.2 導入後に見られたチームの変化

こうした運用方針のもとで開発を続ける中、チームの中にはいくつかの変化が見られるようになりました。

PRがより細かい単位で出されるようになった
- 生成コードの質を上げるため、作業スコープを小さく保つ意識が根付いた
  （参考：Vibe Coding(バイブコーディング)会を開催しました）
- 一方で、大規模なリファクタ提案など「超巨大PR」が発生するケースも…
  （importの整理など内容が難しくない場合は、大規模なPRも許容しています）
レビュアーの視点を持つメンバーが増えた
- 今までレビュー経験が少なかったメンバーも、Coding Agentの出力に対するファーストレビューを通してレビューを経験。「何を確認すべきか」を自然に学ぶ機会が増えた
- レビューの経験が増え、レビュー依頼先の偏りの改善につながりつつある
- レビュアーの視点を持つ必要が生まれ、自身がPRを提出する際にレビューしやすいPRを心がけるように
開発メンバーが複数の実装タスクを並行して進めるケースが増えた
- コーディングの一部をAIに任せられるようになり、メンバーが複数の実装タスクを並行で持てるように
Coding Agentに依頼する前提で着手するタスクも計画に含めるように
- Know Narratorではリリースごとに対応する機能を計画的に決めていますが、最近では「この機能ならAIでパパっと作れそうだから、やってしまおう」といった判断で、開発の“着手ハードル”を下げるケースが増加
- 今まで後回しにしていた細かな改善やUI調整なども積極的に取り組めるように

実際に利用しているタスク管理ツールにおいて、Coding Agentへの依頼を前提として作られたタスク

これらはいずれも、AIが人の仕事を置き換えるというよりも、チームの対応スピードと視野を拡張した結果として生まれた変化だと感じています。上図は、管理しているタスク管理ツール上で、Copilotに取り組ませる前提のタスクを作成している様子です。

4. メリットと発生した課題

4.1 チームにもたらした主なメリット

Coding Agent によりVibe Coodingの考え方を取り入れたことで、チーム全体の開発スタイルやスピードにさまざまな変化が生まれました。特に大きく実感しているメリットは、次の4点です。

1. 実装スピードの向上と試行回数の増加

自分の担当するタスクに関して、「じっくり考える前にまずCoding Agentに依頼する」、「できたコードを参考にしつつ仕様を検討する」、「とりあえず動くところまで持って行く」という行動が増えました。

結果として、1リリース内での「作る」→「触る」→「直す」試行回数が増え、改善サイクルが高速化していると感じています。これは後続のメリットすべてにかかわりますが、チームメンバー全員がタスクを取りやすくなった印象があります。

2. コードレビューの機会が増え、学びの機会が増えた

Coding Agentが生成したコードを読む・レビューする過程で、「この書き方もありなんだ」、「この構造なら読みやすい」といった学びや再発見が増えました。レビュアーの視点に立つ経験を経て、PRを提出する際にも読みやすいPRになるような意識付けもされています。

また、CopilotによるPRレビューも自動化しているため、自身がレビューを行う際の参考が存在しているのも効果的でした。このように、日々の開発そのものが学びの機会となっています。

3. チーム全体のアウトプット量の増加

単純な工数削減というよりも、手を動かせる人が増えたという感覚です。

Coding Agentを介してPRを作成・検証できるため、メンバー全員がより多くのタスクに同時並行で取り組めるようになりました。結果として、リリースあたりのアウトプット（機能実装量）量が底上げされています。

とくに傾向として現れたのは、軽微なUI/UXの改善系タスク・内部のリファクタタスクを取りやすくなったかなと思います。開発メンバーは目玉となるコアな機能実装を進めながら、今まで手が回らなかった細かな改修を丸ごとCoding Agentに依頼するようになりました。

もちろん、コア機能や大きな機能の実装にもCoding Agentを活用しています。ただ、既に多くの機能を備えたプロダクトでは、既存仕様や品質、運用面を考慮して進める必要があります。そのため、Coding Agentに “Vibe（雰囲気）” ですべての開発を任せるのは、現状現実的ではないでしょう。有力なツールであることは間違いなく、このツールを「いかにうまく使うか」が開発者の腕の見せ所だと考えています。

4. 開発経験にかかわらず開発メンバーの“コードを書きだす負担”の軽減

実装タスクで一番つらいのは「最初の1行をかきだすこと」だと個人的に思っています。

どこから手を付けていいのかわからない
疲れているときや集中が切れたときにはなかなか手が動かない
並列でタスクを持っているときに頭の切り替えが間に合わない

様々な理由で、最初の1行を書くハードルは高いと思っております。このコードを書きだす最初の一歩目を、Coding Agentが担ってくれるのは大きな助けになります。この傾向は、開発経験が豊富なエンジニア、浅いエンジニア全体で見られました。

また、煩雑な定義ファイルや型補完、テストコードの雛形などを自動生成してくれるため、人が集中すべき設計・意図・レビューに時間を割けるようになった点も大きなメリットです。

4.2 発生した課題と今後の取り組み

Coding Agent の導入によってまったく新しい課題が生まれたわけではありません。むしろ、従来から存在していた開発上の課題に対して「より課題感が強まった」というのが実感です。

開発サイクルが高速化し、今まで後回しにしても回っていた部分が目立つようになってきました。

1. ドキュメントの更新が今まで以上に追いつかなくなる

「ドキュメントと実装がズレる」

開発をしていれば、皆さん経験する課題だと思いますが、Coding Agent によりコード生成スピードが上がった結果、この問題がより顕著に現れました。

仕様の明文化や補足コメントをどの段階で行うかが、今後の運用上のポイントです。定期的にドキュメントを起こす時間を作る、PRの段階でドキュメントのリンクも送る、などの対策を検討してもよいかもしれません。

我々はGitHubとは別のツールでドキュメントを作成しているので、今後はMCPなどを活用してドキュメント生成をコードと同時にAIに任せていければと考えています。

2. 使う側の意識とスキルセットがより重要に

Coding Agentを “うまく使えるかどうか” は、開発者の意識とリテラシーに大きく依存します。

生成結果を鵜呑みにせず、「車輪の再発明になっていないか」、「このテストは本当に意味があるか」、「このコードは安全か」など、良し悪しを判断できるスキルが求められます。

実際に起きた課題を紹介します。 Coding Agentによって生成されたテストコードを見ると、モック中心のテストコードが生成されてパスしているだけのケースが散見されました。Coding Agentからすれば「テストをパスしている」という評価軸になっていたことが原因です。これは人間側がレビュー時点で気づくべき観点となります。

対応策として、人が意識するのは前提として、Coding Agentによる実装をCopilotレビューや自動テストでチェックするなどの取り組みも継続して行っていきます。

3. チーム内ナレッジの共有スピードの遅れ

対応できるPR量が増えた結果、PR内でやり取りされる仕様に関する内容や実装方針・テクニックの共有が遅れるようになってきました。Coding Agentの使い方や使いどころのノウハウが、よく利用する人やレビュー担当者に偏る傾向があります。

この課題に対しては、リリース毎に開発チーム向けの機能と実装を紹介する時間を用意するようにして、このあたりのナレッジ共有を行うようにしています。

4. AIコーディングツール利用の現実と周囲からの期待とのギャップ

これまで述べてきたように、私たちKnow Narrator開発チームでは、Coding AgentをはじめとするさまざまなAIツールを積極的に活用しています。開発チーム内ではAIの活用によって開発生産性が向上しているという実感があります。しかし、周囲から寄せられる期待とは少しギャップがあるのも事実です。

「AIを使えば、もっと多くの機能を実装できるのでは？」
「AIを使えば、生産性は2〜3倍になるのでは？」
「AIを使えば、リリースをもっと早くできるのでは？」

このような声に対して、実際の活用状況や効果をチームの外にも伝えていく必要があると感じています。

メリットの章でも触れましたが、実際にAIコーディングツールを使ってみると、（現状）すべてを解決してくれる“魔法のツール”ではないと分かります。一方で、すでに開発に欠かせない存在となっており、その有用性を強く感じています。ただし、こうした感覚は、実際に使ってみなければ分からない部分も多いと思います。

だからこそ、AIを活用した開発の「どこに」「どのような」効果があるのかを具体的に発信していくことが、私たち開発チームの責務だと考えています。

具体的な取り組みとして、2.1節でも触れたように、私たちは毎月のマージ済みPR数やリリースごとのベロシティ（作業量）を定期的に計測しています。これは、AI活用の効果を多角的に評価するためです。こうした定量的な情報に加え、本記事のように取り組み内容を共有していき、よりリアルな知見をチームの外にも発信していきたいと考えています。

5. まとめ：AIとともに進化する開発チームへ

GitHub Copilot Coding Agent を導入してからの数か月間、私たち Know Narrator開発チームでは、開発の進め方・考え方・スピードにさまざまな変化がありました。

導入当初はリクエスト制限や設定面の課題もありましたが、アップデートを経て安定して利用できるようになり、今では日常的な開発の一部として定着しています。AIコーディングツールにより「作る」工程が加速し、その分「触る」、「直す」といった部分により多くの時間を割けるようになりました。

結果として、実装のサイクルが早まり、アウトプット量の向上、レビュー参加者の増加といったチーム全体の開発力の底上げにつながっています。

一方で、開発サイクルが高速化した結果、もともと存在していた開発上の課題に対する課題感がより強まったとも実感しています。これらはAIが新しく生んだ課題ではなく、「早く回せるようになったからこそ、より意識せざるを得なくなった課題」です。

私たちは、この変化をポジティブに捉えています。AIコーディングツールは、開発者を置き換える存在ではなく、チームの思考と文化を加速させる協働のパートナーだと感じています。今までKnow Narratorの開発を通して培ってきたチーム文化とノウハウがあったからこそ、素早くチームに根付かせられたと考えています。

私たちはこれからも、AIをチームの一員として受け入れながら、「より楽しく、より早く、より価値のある」プロダクトを届ける開発チームを目指していきます。

6. 最後に...

AITCでは一緒に働いてくださる方を募集しています！

詳細は以下のページをご覧ください！

AITC | AI TRANSFORMATION CENTER

電通総研 AIトランスフォーメーションセンター採用情報ページ

🕒️2025年1月16日

執筆
AIソリューショングループ
村本直樹

コラムカテゴリー: プロダクト開発