20251025_GitHub Copilot活用度を“計測できる”にする-Cron×Dapr×Cosmos DBで作るバックエンド

.NETラボ 勉強会 2025年10月 登壇資料

生成AIの実運用では「どれだけ使われ、成果に結びついているか」を継続的に測ることが不可欠です。本セッションでは、GitHub Copilotの利用データを定期収集し、Azure Cosmos DBへ永続化、APIで配信するバックエンド実装に焦点を当てます。Cron（Dapr）で収集を自動化し、最小構成のAPIでOSSのGitHub Copilot Metrics Viewerへ供給。Acceptance RateやActive Usersなどの指標を、DevOps視点で“継続改善に使える数字”へと転換する設計・運用の勘所を、アーキテクチャと実装の両面から解説します。

■アジェンダ
- Introduction
- 導入／背景
- 可視化の全体像と指標の定義
- リファレンス・アーキテクチャ
- バックエンドの実装ポイント（Cron/Dapr）
- まとめ

Transcript

1. GitHub Copilot活用度を“計測できる”にする Cron×Dapr×Cosmos DBで作るバックエンド 2025.10.25 Yutaka.Osada
2. Agenda • Introduction • 導入／背景 • 可視化の全体像と指標の定義 • リファレンス・アーキテクチャ • バックエンドの実装ポイント • まとめ DO WHAT MATTERS 2
3. Yutaka Osada（長田 豊） • Manager (DevOps Engineering) @Avanade Japan • Solution Architect (AI assisted SDLC & DevOps) • エンタープライズへのDevOpsソリューション（ Azure DevOps/GitHub Enterprise ）の導入・構築 • Azure PaaS × GitHub Enterpriseのオファリング開発 • 個人活動 • Zennでの記事投稿（IaC、CI/CD Pipelines Azure DevOps Rest API等） • 登壇（各種ユーザコミュニティ、および、DevOps Days Tokyo 2025） • 書籍執筆(AZ-400の試験対策本) • GitHub Stars (Sep 2025–) 受賞 • 技術スタック • C#, .NET, Azure(PaaS), Azure DevOps, GitHub • Please follow me https://github.com/yutaka-art 3 DO WHAT MATTERS
4. 導入／背景 • 生成AI（GitHub Copilot）は導入＝ゴールではない • 活用度・成果への寄与を継続計測し、改善ループに乗せる必要 • だが現場では断片的な可視化になりがち：期間不整合、指標定義のズ レ、データ保全・再現性の欠如 • 本セッションの焦点：バックエンドの“永続化とAPI化” DO WHAT MATTERS 4 収集 • Cron/Daprで定期的に指 標を取得（冪等／再取得 戦略込み） 永続 • Azure Cosmos DBに正規 化・ウィンドウ管理 提供 • Acceptance Rate、 Active Users、Turns な どを“改善に使える数字” へ ねらい：導入効果の見える化 → 育成／設定見直し／ガバナンスを継続駆動
5. GitHub Copilot Metrics Viewer（既存OSS） • GitHub Copilot Metrics Viewer は、GitHub 組織またはエンタープライ ズ アカウント向けに、Copilot に関連する各種メトリクスをグラフで表示 するアプリです。Metrics API を利用し、Copilot の導入効果や採用状況 を直感的に把握できます。 • 2023-12-19 に OSS として公開され、過去 100 日間 の利用実績（提案さ れたコード行数・受け入れられたコード行数など）を取得できます。 DO WHAT MATTERS 5 Azure Resource Group GitHub Organization Azure PaaS (Web Apps, Container Apps, AKS 等) GitHub Packages GitHub Container Registry Personal Environment Personal Access Token （Packages） Personal Access Token （Copilot） GitHub Apps Organization permissions - GitHub Copilot Business(Read-only) Authorize ユーザー GitHub 認 証 ・ 認 可 GitHub Copilot Metrics Data GitHub 認 証 ・ 認 可 https://zenn.dev/yutakaosada/articles/22c5c17ea055b0
6. 可視化の全体像と指標の定義 DO WHAT MATTERS 6 • 収集データ（イベント/提案/承認/ユーザ） ├─ 提案(Total Suggestions) ├─ 承認(Total Acceptances) ├─ 提案行(Total Lines Suggested) ├─ 承認行(Total Lines Accepted) └─ 利用ユーザ(Total Active Users) ＋ Turns(28d) / Acceptances(100d) • KPI定義 • Acceptance Rate = Accepted Lines / Suggested Lines • Usage Activity = Total Active Users • Volume Balance = (Suggestions vs. Acceptances) • Engagement Trend = Cumulative Turns (28d) [指標→意思決定のマッピング：2軸で抽出（例）] Active 低 Active 高 高 ① ニッチ高品質 ・受入率は高いが利用者少 → 展開/横展開候補 ② 理想ゾーン ・受入率も高く利用も多い → 維持/拡大、成功事例共有 低 ③ 未活用/学習不足 ・利用も少＆受入率低 → 導入/教育/オンボーディ ング ④ ノイズ/設定不一致 ・利用は多いが受入率低 → プロンプト/拡張設定見直し [量の観点：提案量×承認量のバランス] 承認量 高 ▲ │ (良) 高提案×高承認 → “機会最大化” 承認量 低 ◄──┼───► (要調整) 高提案×低承認 → ノイズ/質低下の疑い │ (潜在) 低提案×高承認 → 設定/利用機会の拡大余地 ▼ 低提案×低承認 → 導入/周知不足
7. Slack リファレンス・アーキテクチャ（今回作ったもの） DO WHAT MATTERS Azure Resource Group Container Apps Environment Container Apps(可視化) Container Apps(収集) Container Revison 1 Container Revison 2 Container Revison Ingres s http://8080 100% Cosmos DB Metrics Data Container Registry Log Analytics Managed Id Key Vault Application Insights CI/CD Monitor https://fed- app.*.japaneast.azurecontai nerapps.io 認 証 ・ 認 可 GitHub Metrics Data 1 2 7 Container Apps(API) Container Revison 3 GitHub Copilot Metrics Viewer（OSS） がフロ ントを担当 Container Apps＋Dapr Cronで定期収集 Controller-based Web API (.NET 8) で集計エン ドポイント提供 通知
8. Azure コンポーネント価格感（実測） DO WHAT MATTERS 8 コンポーネント 備考 コスト(月額) Container Apps(収集) Workload Profiles:Consumption ¥907 Container Apps(API) 〃 ¥907 Container Apps(可視化) 〃 ¥904 Cosmos DB capacityMode:Serverless ¥62 Container Registry SKU:Basic ¥771 Key vault SKU:standard family 'A' ¥1 Log Analytics SKU:PerGB2018 ¥61 Storage Account SKU:Standard_LRS ¥10 TOTAL ¥3,623 ※最小構成（仮想ネットワークなどが非導入）
9. Dapr とは DO WHAT MATTERS 9 https://dapr.io/ https://keda.sh/ ポイン ト Azure Container Apps では、これらがマネージドで統合され ているため、Kubernetes の知識がなくても導入が簡単 モダンなマイクロサービス / イベントドリブンアーキテクチャ へのステップアップが容易 KEDA KEDAとはマイクロサービスにおけるスケーリング機構 •イベントに応じた自動スケーリング (CPU, メッセージキュー、カスタムイベン トなど) •コンテナ単位でスケールを管理できる Dapr Daprとはインフラストラクチャの抽象化 •分散アプリケーションランタイム •サービス間通信 / PubSub / バインディング / シークレット管理など •コードに大きな変更を加えずにマイクロサービス化がしやすい
10. リポジトリ構成 DO WHAT MATTERS 10 サブモジュールを設定し、OSS側の 「copilot-metrics-viewer」のmain ソースが常にCloneされるように設定
11. バックエンドの実装ポイント DO WHAT MATTERS 11 • 収集周期 • 冪等化と重複排除（upsert＋自然キー：org/date/metric） • 失敗時再試行・レート制御
12. バックエンドの実装ポイント - 収集周期 DO WHAT MATTERS 12 • 周期は日次の00:05にて、Dapr bindings.cron を選択 • IaCの実行順序は、ACE作成→ContainerイメージPush→ACA作成→ACEにDapr設定を付与 apiVersion: dapr.io/v1alpha1 kind: Component metadata: name: ghcp-metrics-cron spec: type: bindings.cron version: v1 metadata: - name: schedule value: "5 15 * * *" - name: direction value: "input"
13. バックエンドの実装ポイント - 冪等化と重複排除（upsert） DO WHAT MATTERS 13 • データバインディング、 bindings.azure.cosmosdb を検討したが重複データを排除できない・・・ // Dapr のバインディングを受け取るエンドポイント app.MapPost("/save", async (HttpContext context) => { using var reader = new StreamReader(context.Request.Body); var rawData = JsonConvert.DeserializeObject<ExpandoObject>(await reader.ReadToEndAsync()); // createしかサポートしていない。重複している場合409 Conflictエラーとなる // https://docs.dapr.io/reference/components-reference/supported-bindings/cosmosdb/ await daprClient.InvokeBindingAsync("savebind", "create", rawData); Console.WriteLine($"Data Saved to State Store: osada05"); }); • そのため、state.azure.cosmosdb を利用することで、Upsert処理を実現。 • Upsertの数が多すぎると429が返却…しきい値を見極めてチャンク処理。 apiVersion: dapr.io/v1alpha1 kind: Component metadata: name: statestore-metrics spec: type: state.azure.cosmosdb version: v1 metadata: - name: url value: "<your-cosmosdb-uri>" - name: masterKey value: "<your-cosmosdb-key>" - name: database value: ghcp-metrics-db - name: collection value: metrics-cntr const int BatchSize = 50; foreach (var batch in stateItems.Chunk(BatchSize)) { await this.DaprClient.SaveBulkStateAsync("statestore-metrics", batch.ToList()); }
14. バックエンドの実装ポ イント - 失敗時再試 行・レート制御 • GitHub Rest APIのRate Limitに注意 (PAT:1h/5,000件, GitHub Apps:1h/15,000 件) • レスポンスの Headersで何件リクエス ト可能か確認可能 • GitHub Appsを利用する場合のシーケンスは 左図のとおり • 再試行については • HttpClient を拡張し、リトライロジック やエラーハンドリングを行うメソッドを 実装 • ライブラリを色々試したが、結局 HttpClientで実装したほうが痒いところ に手が届いた。 DO WHAT MATTERS 14
15. バックエンドの実装ポ イント - APIエンドポイント • フロントエンドのベースURLはなぜかオンコーディ ングになってる・・・ • フロントエンドのベースURLを書き換えるだけで動 作するように DO WHAT MATTERS 15
16. バックエンドの実装ポイント - クラス分割 DO WHAT MATTERS 16 • 拡張性や保守性を考慮しクラス分割は肝要。IaCリソースについてもルールに則って要整備
17. まとめ • 目的 • Copilot活用を測定→解釈→改善のループに乗せる • 方針 • フロントはOSS（Copilot Metrics Viewer）、不足はバックエンド（収集・API）で補完 • 指標 • Acceptance Rate / Suggestions / Acceptances / Lines（S&A）/ Active Users / Turns • 要点 • データの再現性（Cron/Dapr・Cosmos設計）と意思決定の接続（象限分析・時系列） DO WHAT MATTERS 17 DevOps Transformation “見える化”を“継続改善”へ
18. THANK YOU DO WHAT MATTERS Yutaka.Osada union.dml@gmail.com https://github.com/yutaka-art 18 ▪合格対策Microsoft認定試験AZ-400 書籍 11/12 発売！！ ▪今後の登壇予定 11/11 GitHub Dockyard - キャリア系の話 11/26 GitHub Universe Recap - AI-Native時代のDevOpsとGitHub活用