はじめに
この記事はNTTドコモソリューションズ Advent Calendar 2025 18日目の記事です。
自己紹介
NTTコムウェアあらためNTTドコモソリューションズ(略称：dSOL) 技術革新本部の小西です。1年ぶりです。
去年も弊社のアドカレに参加してGitHub Copilotにまつわる記事を書かせていただきました(興味のある方はこちらからお願いします)。
去年のGitHub Copilotにまつわる記事はたくさんの方に読んでいただけていて、改めて御礼申し上げます。
また社内・社外で勉強会を開催させていただいて、記事を読んでいただいたとのお声も頂戴しまして、改めて世間のLLM、AI、GitHub Copilotに対する注目度の高さを感じます。
プライベートの方も去年からアップデートできることがあまりないのですが、妻がChatGPTに悩み相談をしているのを横目で眺めてエンジニア不要論よりも先に旦那不要論が発生しないのか自分自身のバリューについて再考する日々です。
この記事でお伝えしたいこと
GitHub Copilotを全社展開してから早いもので1年以上経ちました。1年以上経ったので、改めて
- GitHub Copilot普及をこれからやるとしたら何から手を付けるのか
- GitHub Copilotで良かったこと
- 課題感
- 今後やりたいこと
をまとめさせていただいて、同じような立場で悩まれている方の参考情報だったり、あるいはこれから導入を検討される皆さんへ向けた道しるべだったり、あるいはまた皆さんに記事を読んでいただいてワイワイ勉強会したりするきっかけにできたら嬉しいです。
GitHub Copilot普及をこれからやるとしたら何から手を付けるのか
特にエンタープライズ領域の開発をやるような組織のことを想定しています。
自分たちが何をやったのか
ざっくりと書き出すとこれです。順を追って説明するので事実の羅列だけをします。
- 自社の制度・制約に照らし合わせて都合をつける
- 開発環境を準備する上でのボトルネックにならないようにお膳立てをする
- 効果測定方法の検討をする
- 誰に向けてリーチすると使ってもらえるのかを考えてリーチする
自社の制度・制約に照らし合わせて都合をつける
多くの組織で何かしら「この手のツール」については制約が伴うものです。
「この手のツール」とはつまり「AIを利用していて」「外部に通信が発生する」「開発情報を扱う」ツールということです。
仔細な調査等は昨年度記事をご参照ください。ここでは大事なことだけを挙げます。
- すべてのFactはGitHub Copilot Trust Centerにまとまっている
- GitHub Copilotが生成したソースコードの著作権は少なくともGitHubが主張することはない
- 入力が学習に使われない
- IDE経由の入力を保存することはない
など、まずはトラストセンターの記載と自社の制度・制約等に照らし合わせて「問題ない」「リスク受容する」「対策を立てる」の3分類に課題管理をすることで導入推進に立ち向かう勇者が迷子になる可能性を確実に下げることができます。
開発環境を準備する上でのボトルネックにならないようにお膳立てをする
前述の部分にも重なりますが、この手のツールを使うことに対して個別の社内審査を要求する組織も多いです。
弊社もそうです。一方で、開発現場の気持ちとしては開発環境の立ち上げに負荷をかけたくはないです。もっといえばすでに開発が始まっているところに導入するとなってくると、やはり社内審査のために資料を作り上げてチェックを積み重ねて...というのはボトルネック化することが想像に容易いです。
そこに対する工夫として考えられることは
- 標準的なGitHub Copilot利用環境モデルを定義する→その範囲内であれば包括的に審査をする
- 自社のポリシーとして許容できるデータ保管は？
- if no then IDE only
- else if 28 days then IDE and GitHub.com and...
- 誰が作ったGitHub Copilotプラグインなら使って良い？
- if official only then Can use VSCode, Eclipse 2024-03 ↑...
- 自社のポリシーとして許容できるデータ保管は？
こういったことを積み上げていきました。
個人的にですが、今から「これが社内標準の開発環境です」と宣言するとして、GitHub Copilotを念頭に置いて検討するのであればVisual Studio Code一択という見解です。
Agentが降ってきたときも、Planモードが降ってきたときもまずはVisual Studio Codeだったことを考えると良い機能をもっともはやく使えるのはVisual Studio Codeです。
効果測定方法の検討をする
おそらく、あるいはほぼ確実にここまで読みながら導入を成功した推進する勇者のあなたはやり終えた感がすごいと思います。
私もそうだったのですが、一方で人間の欲は尽きません。
きっと経営層などから「それで効果は如何ほど？？」と聞かれるイベントが待ち受けています。
効果測定を考えていきましょう。
(少し余談) 効果測定方法のトレンドの変遷
変遷を語るほど歴史は長くないのですが...
- GitHub Copilot 黎明期(2023~2024):
- APIからのデータに基づいて提案行数/承認行数を分析
- 当時はAgentがなかったのでAIでコードサジェストを受けるのがメインシナリオ
- 例:(スタディサプリ様)「GitHub Copilot の Usage API を叩いてみた結果を味わう」https://blog.studysapuri.jp/entry/taste-of-github-copilot-usage-api
- APIからのデータに基づいて提案行数/承認行数を分析
- GitHub Copilot 普及以降(2024~現在):
- 利用者へのアンケートベースで評価
- GitHub Copilotの生産性向上効果を完璧に測定することは難しい:
- Agent活用がメインシナリオ
- まったく同じ機能をまったく同じ環境でまったく同じレベルのエンジニアがGHCP有/無で実装?
- GitHub Copilotの生産性向上効果を完璧に測定することは難しい:
- 例1:(NTTドコモ)「NTTドコモのGitHub Copilot導入事例とその成果」 https://nttdocomo-developers.jp/entry/2024/12/22/090000_3
- 例2:(日立製作所様)「日立製作所が GitHub Copilot の活用で開発生産性を向上。社内評価、開発フレームワークとの連携、コミュニティ活動を通して、さらなる生成 AI 活用を推進
」 https://www.microsoft.com/ja-jp/customers/story/22781-hitachi-github
- 利用者へのアンケートベースで評価
といった形で、評価トレンドが少し変化をしていることは知っておいて損がないと思います。
それでもやっぱり定量的な評価はしたい
トレンドの変遷を述べておいて...なのですが、それでも何かしら数値目標と達成状況をとなることは組織において往々にしてあります。そこで手段として2つあることをご紹介します。
GitHub Copilot Metrics API
特徴
- Enterprise/Organization/Teamの単位でメトリクスデータを取得できる
- JSON形式
- 最長100日分取ってくることができる
- ライン数系の数値にはAgentモード等の行数は反映されない
- 回数系の数値には少なくとも利用回数が反映される
- モデル別・言語別・IDE別のカットがある
といった特徴があります。
もし、このAPIから拾えるデータに基づいて分析するときには上記の特徴を考慮すると共に、GitHubそのものの組織構成を少しだけ考慮することをお勧めします。
組織単位をドリルダウンする手段は、GitHubの構成(Enterprise/Organization/Team)に依存するので、自社として会社全体だけが見られれば良いのか？(であればEnterpriseがEnterpriseの体をなしていれば良いですね)それとも、事業組織別にドリルダウンしたいのか？(Organizationの単位が少なくともそうなっている部分があるのか？を確認する必要がありますね)チームとされる単位までドリルダウンしたいのか？を考える必要があるからです。
Teamの単位は有効なGitHub Copilotライセンス保有アカウントが5個以上存在しないとメトリクスを記録しない点に注意してください。
GitHub Copilot Usage Dashboard/Metrics
2025年12月12日現在、この機能はパブリックプレビューです。
今後機能内容の変更・廃止等される可能性があります。
ついこの間、追加された公式ダッシュボード画面と、それに付随するメトリクスデータです。
ドキュメント
APIドキュメント
ちなみにこの機能はすべてEnterpriseの括りのみです。
公式ダッシュボード画面で見られること
出典：GitHub, Inc. Copilot Usage(筆者ローカル環境/スクリーンショット取得日：2025年12月12日）
検証用環境の画面イメージなのでほぼデータはないですが、こういうものが見られます。
- Agent adoption（エージェント利用率）
- Average chat requests per active user（1ユーザ当たりの平均チャットリクエスト数）
- Code completions（suggested / accepted）（コード補完の提示数・受諾数）
- Code completion acceptance rate（補完受諾率）
- Daily active users（日次アクティブユーザ数）
- Weekly active users（週次アクティブユーザ数）
- Total active users（月間アクティブなライセンスユーザ数）
- Language usage（使用言語の分布）
- Language usage per day（日別の言語利用）
- Model usage（利用されたモデルの分布）
- Model usage per day（日別のモデル利用）
- Model usage per chat mode（Ask / Edit / Agentごとのモデル利用）
- Model usage per language（言語ごとのモデル利用）
- Most used chat model（最も利用されたチャットモデル）
- Requests per chat mode（Ask / Edit / Agentごとのリクエスト数）
APIから取れるデータで見られること
ダッシュボードだけでも良いのですが、APIから降ってくるデータの特徴を考えると面白いことがいくつあります
- ユーザ単位でメトリクスデータを取得できる
- NDJSON形式
- 最長28日分取ってくることができる
- ライン数系の数値にはAgentモードの行数も反映される
- 回数系の数値には少なくとも各機能の利用回数が反映される
- モデル別・言語別・IDE別・モード別のカットがある
といった感じです。
ユーザレベルに落とし込めるのも良いポイントだと思います。
弊社ではこれを元にこんな感じのダッシュボードを検討しているところです。
ダッシュボードの主幹は自担当なんですが、まぁ公開するにあたって決裁の要否とか整理する時間がなかったので云々...つまるところ、ダッシュボードの詳細は別の機会になにか・・・！(記事書きながらこの手の厄介事を踏み抜いていく)
ダッシュボード含みのデータフローはこのような感じに開発をしています。
Access使うくらいならDataverseの方が良いとか色々言いたいことはあるのですが、まずは有り物でなんとか形にしています。
おそらくEnterprise向けのO365の通常のポリシーで泳げる範囲+PowerBIというミニマムな構成で可能な限りは良いデータになっているのかなと思います。
誰がGitHub Copilotを使っているのか？
ここが結構重要なポイントだったと思います。
ソフトウェア開発では自社社員だけでなく、協働者（外部委託社員）とともに開発を行うケースが多く、公開情報によると、工数比率で6割程度が外部委託という傾向があります。
（参考：PwC「ソフトウェア開発 分析データ集 2022」）
この傾向は、案件規模が大きくなるほど顕著になると考えられます。
...ということはつまり、我々が色々な使い方や情報を議論して、そのアウトプットが社内だけに閉じていてはいけないということになります。
弊社の場合、少なくとも「案件に入っていれば、その案件を支援するための情報提供である」ということを根拠にケチ臭い制限は設けず協働者の方も含めて色々な勉強会を実施して、資料を展開しています。
自分たちがやれなかったこと。やった方がよかったこと
逆に今になってみて「これもやりたかったな」ということをいくつかピックアップしてみます。
GitHub Actions, GitHub Advanced Security etc...の利用体系整理
Coding Agentsが当たり前になった今、これをどのくらいの費用感でどう使ってもらうのか？は整理しておけばよかったポイントです。
言い訳をすると、GitHub Copilotの普及展開を始めたときはCoding Agentsがそこまで一般的な存在ではなかったです。故にここまで機能拡充がこのスピード感で来るとは思ってもみなかったというのが正直なところです。
MCPとの付き合い方の整理
MCPも時系列でみれば後発で、予想もしなかったというのが正直な部分です。
機能的には非常に強力で、MCPの有無でできることに差が出るというのは事実です。一方で、強力さゆえに一定のガバナンスが必要で無尽蔵に許認可できるものではないというのも理解できます。
今日時点では、MCP リポジトリによる制限は可能ですが、誰がどんな仕組みで何をどういう基準で追加していくのか？という課題が未解決のままになっています。
やっておけばよかったと言いつつ、この辺は私も答えがないので「うちはこうしてる」みたいなのがあればぜひコメントください。
GitHub Copilotでよかったこと
色々とある(偶然に社内標準開発環境をVisual Studio Codeにしていたから相性がとか、あるいは性能がとか)のですが、今回は推進者目線で見たときのたった1個、非常に助かったポイントを取り上げます。
ゼロデータ保持契約
ゼロデータ保持契約とは「君たちがツール使ったときに入力したプロンプト、出力結果を学習に使うような真似はしないよ」という契約です。
一般的にエンタープライズ領域のAIツールはここが問題になることが多く、新しいツール、新しいモデルを使うときには非常に神経質になる領域でした。
GitHub Copilotですが、今日時点でGPT、Claude、Grok、Gemini...と色々なモデルがGitHub Copilot経由で使えます。
しかし、我々は臆することなく新しいモデルを常に利用許可しています。
これができるおかげで、世の中に新しいLLMが誕生しても我々は1個1個について精査して審査して...というプロセスを取らずに社内の利用者に新しいモデルを解放できるのでスピード感が違います。
Tips:プレリリースライセンス条項とゼロデータ保持契約
モデルについて、プレビュー版の場合にはプレリリースライセンス条項というものが適用されます。
旧来、プレリリースライセンス条項についてはデータ収集を実施することが定められていて、そこを懸念する企業は多かったかもしれません。
しかし、最近の条項でアップデートが入り下記の記載が追加されました。
AI を使用するプレリリース ソフトウェアの場合:
お客様は、ソフトウェアに入力したコードの所有権を保持します。
GitHub は、ソフトウェアからお客様に送信された出力を所有しません。
GitHub は、お客様が書面によりそうすることを指示しない限り、お客様の入力や生成された出力を
AI 言語モデルのトレーニングに使用することはありません。
出典：GitHub, Inc.「GitHub プレリリース ライセンス条項」https://docs.github.com/ja/site-policy/github-terms/github-pre-release-license-terms（参照日：2025年12月16日）
課題感
社内展開を進めて1年半、見えてきた課題感と、それについて今検討していることを簡単に記載します。
ユーザごとのプロンプト品質のブレ
どうしても発生している一方で、これという打ち手があまり思いつかないまま来ていました。
プロンプト品質のブレですが、ごく狭い範囲の編集であれば問題になることが少ない一方で、ワークスペース全体に関わる変更のレベルだと生産性と品質に結構効いてきます。
安直にいえば我々が標準的なプロンプトを展開する(なんでもかんでも「標準化」するのはやはり大企業病とも言われてしまうのでしょうか･･･(笑))というのが打ち手にはなります。
一方で、個別具体的にすべてのPJで使っている技術スタックを網羅的に担保するというのは途方もないことになります。
そこでGitHubの方からご紹介いただいたawesome-copilotをバイブルとして検討しようとしています。
つまるところ、GitHub公式リポジトリに存在する公式のプロンプト集です。
例えばjunitによるテストのプロンプトを見てみます。
内容の詳細はリンク先を見ていただくとして、構造は下記の通りです。
- 前提条件を定義
- テストの書き方を規定
- テストの種類を整理
- 品質を担保するためのルールを提示
- 運用・拡張を考慮した補助ルールを追加
他のプロンプトというのも大枠ではこれに従っているので、適切なプロンプトを発見してルール面を自組織や開発内容によりフィットさせていくことで理想的なプロンプトを作成できるという展望を持っています。
Agentモード
ちょうどこの話題を書こうとしたときに、弊社の@dsol_morishigeが最高の記事を書いていたので共有します。
GitHub Copilotにゴミ掃除を頼んだら家の一部が更地にされた話
もうタイトルからしても最高で、おそらく皆さん心拍数が上がっていると思います。
この記事の主題は「Agentモードのやることを何となくOKしたらえらいことになった」です。
実はAgentモードが出てきたときから「Agentモードが何をしようとしていて、何をしたのかがトレースできなくて辛い」という声をいただくことが多かったです。
その当時、私はAgentモードについて一定の区切りでコミット作成してもらうようにしてコミット内容をレビューすることでお茶を濁していました。一方でコマンドラインに対する制御などはやや手当が薄かった領域です。
1つ、今考えていることを共有すると「Planモードの活用」です。
端的にいうとAgentモードにタスクをお願いするときに事前に実行計画を作ってくれるモードです。
最近、社内でトレーニングを実施するときには「Planモードで作成したプランを事前に自分、チームでレビューしてタスクに誤りや怪しい箇所、抜けがないのかを確認してからAgentに実行させましょうね。かつPlanには『べからず』も書きましょう」という論調でお話をしています。
今回、実際にPlanモードの成果物をご用意しています。
元ネタはMacchinettaというJavaフレームワークのATRSというサンプルコードです。
元ネタは航空券の予約システムを模したサンプルコードです。運賃は円建てのみ表示だったので、香港ドル運賃表示機能を追加してみることにしました。
作成したPlan(最小限)です。
# Plan: 香港ドル運賃表示機能の追加
ATRSの空席照会・予約機能に香港ドル (HKD) 運賃を追加します。現行のUSD表示実装パターンを踏襲し、`FareTypeVacantInfoDto`に`fareHkd`フィールドを追加、為替換算ロジックを`TicketSharedService`に実装、JSPとREST APIの両方で表示対応します。
## Steps
1. **[`TicketSharedService.java`](atrs-domain/src/main/java/jp/co/ntt/atrs/domain/service/b0/TicketSharedService.java)にHKD変換メソッド追加** - `convertYenToHkd(int yenFare)`シグネチャを定義（84-89行目のUSDメソッドと同様のパターン）
2. **[`TicketSharedServiceImpl.java`](atrs-domain/src/main/java/jp/co/ntt/atrs/domain/service/b0/TicketSharedServiceImpl.java)にHKD変換ロジック実装** - 72-75行目に`@Value("${atrs.exchangeRateHkd}")`でHKDレート注入、359-362行目と同様の`Math.ceil()`による切り上げ処理を実装
3. **[`atrs.properties`](atrs-domain/src/main/resources/META-INF/spring/atrs.properties)にHKD為替レート追加** - 23-24行目の`atrs.exchangeRate`に続けて`atrs.exchangeRateHkd=11.65`を定義（1 HKD = 11.65 JPY想定）
4. **[`FareTypeVacantInfoDto.java`](atrs-domain/src/main/java/jp/co/ntt/atrs/domain/service/b1/FareTypeVacantInfoDto.java)に`fareHkd`フィールド追加** - 26-42行目のコンストラクタに`String fareHkd`引数を追加、フィールド定義・getterを実装（`fareUsd`と同じイミュータブル設計）
5. **[`TicketSearchServiceImpl.java`](atrs-domain/src/main/java/jp/co/ntt/atrs/domain/service/b1/TicketSearchServiceImpl.java)でHKD変換呼び出し** - 177-183行目の`convertYenToUsd()`に続けて`convertYenToHkd()`を呼び出し、`FareTypeVacantInfoDto`に`"HK$" + fareFormatter.format(fareHkd)`を渡す
6. **[`flightSearch.jsp`](atrs-web/src/main/webapp/WEB-INF/views/b1/flightSearch.jsp)にHKD表示追加** - 182行目の`fareUsd`表示の下に`<span class="fare-hkd text-muted small"><@- flightClass.fareHkd @></span>`を追加
7. **[`TicketSearchServiceImplTest.java`](atrs-domain/src/test/java/jp/co/ntt/atrs/domain/service/b1/TicketSearchServiceImplTest.java)にHKD変換テスト追加** - 686-719行目のUSDテストを参考に`testSearchFlight_正常系_HKD換算が正しい()`を実装、`when(ticketSharedService.convertYenToHkd(8000)).thenReturn(687)`のモック設定とAssertJによる`fareHkd`検証
## Further Considerations
1. **為替レートの更新頻度** - 固定値 (atrs.properties) を維持するか、外部API連携 (実装時間+30%) で動的更新するか？推奨は固定値で開始し、将来拡張
2. **通貨の拡張性** - 3通貨目以降の追加を見越して`Map<String, String> fares`方式へのリファクタリング（+50%工数）を検討するか、現行のフィールド追加方式を継続するか？
3. **小数点処理の統一** - USDと同じ`Math.ceil()`による切り上げで良いか、HKDは小数点2桁表示（例: HK$687.25）にするか？
という内容で、詳細にステップと浮いている事項が出ています。
おそらく、エンタープライズ領域で適用するときにはここに「べからず」と「ポストプロセスとしてのソースコード検査等」を追加して定義します。
これによってAgentモードによる不幸な事故を減らす...という解決をやろうと機会があれば社内で触れるようにしています。
今後やりたいこと
改めてなんですが、開発ってソースコードだけじゃないよねというモチベーションで「GitHub Copilot が活躍できる領域を左右に広げたい」ということがあります。
| ドキュメンテーションの世界 | C/UT(今の主戦場) | テストの世界 |
|---|---|---|
| 設計書・仕様書の脱オフィス文書 | 単体テストや統合テストなど | |
| AI と人に経緯を与える（ADR） | ||
| ソースコードと issue とドキュメントの隣人化 |
- MCP, AgentHQ … みたいな新機能のいち早いキャッチアップ
- 泥臭くドキュメント標準の刷新・開発環境の刷新…
- GitHub Copilot が当たり前になってきた今、もう一度、少し前の仕事に目を向け(る)たい
そんな状況です。
(ここは社内の事業計画にも関わる領域なのであまり詳しく書けないのが心苦しいですが)
おわりに
総論として、泥臭い仕事になっています。結局のところAIを導入する組織のスタートラインはそんなキラキラしたことではないのが実情だと思います。ただ、一方で開発者が元気に楽しく仕事をできるようにすること を積み上げていくことはまた開発とは別のカットで面白いし大変だなという日々です。
来年もまたぜひ読んでください。
あと、ぜひこの記事がきっかけて勉強会とか交流会とかにつなげていければ嬉しいです。
(昨年の記事経由でお声がけいただいた皆様ありがとうございました)
同じようなミッションを推進している他企業の方々ともぜひ情報交換など実施していければ良いなと思っています。ぜひご連絡ください。
記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。