数値で見る Microsoft MVP 〜Spec Kit と GitHub Copilot Agent で作るデータ可視化ダッシュボード〜

公開されている Microsoft MVP プロフィール情報をもとに、国別・地域別・技術領域別の傾向を可視化するダッシュボードを、仕様駆動開発（SDD）で実装した事例を紹介します。

技術スタックは .NET 8 Blazor / MudBlazor / Blazor-ApexCharts / Azure OpenAI / Azure Container Apps。データ取得における利用条件への配慮（MVP Program Support への事前確認）や、LLM に計算させず集計済みデータを「説明」させる設計など、実務で意識したポイントをまとめています。

後半では、Spec Kit を実際に運用して見えた課題として、AI Credit（従量課金）の消費、読まれないドキュメントの量産、Single Source of Truth の崩壊の3点を取り上げ、GitHub Copilot の Plan モードという選択肢と比較します。Spec Kit は SDD の手段の一つであり、クレジットを浪費せず Single Source of Truth を守り続けることが本質、というのが本資料のメッセージです。

Transcript

1. 数値で見る Microsoft MVP Spec Kit と GitHub Copilot Agent で作る データ可視化ダッシュボード 公開データの取得・可視化・インサイト生成を、仕様駆動で実装する 2026.07.25 Yutaka.Osada
2. Agenda ダッシュボー ド紹介 アーキテクチ ャ全体像 仕様駆動開発 (SDD)の実践 公開データ利 用の考え方 MVP データを「検 索」ではなく「分析 」するダッシュボー ドの全体像 データ取得から可視 化、Azure OpenAI によるインサイト生 成まで Spec Kit の活用と課 題、Plan モードとい う選択肢 技術的に取れること と、使ってよいこと は別 DO WHAT MATTERS 2
3. DO WHAT MATTERS Yutaka Osada （長田 豊） • DevOps Engineer @Avanade Japan • 業務 • Azureコンポーネントを活用したサー ビス構築 • 技術検証、パフォーマンスチューニン グを得意とし、T-SQLが好き。 • 技術スタック • C#, .NET, Azure(PaaS), Azure DevOps, GitHub • 受賞歴 • Microsoft MVP - Developer Technologies / DevOps (2026～) • GitHub Stars (2025～） • Please follow me https://github.com/yutaka-art 3
4. ダ ッ シ ュ ボ ー ド https://mvp.ante-mode.online/ DO WHAT MATTERS 4
5. なぜ「数値で見る Microsoft MVP」なのか 公開されている Microsoft MVP プロフィール情報に基づき、国別・地域別・カテゴリ別などの集計 インサイトを生成 現状の公開ページ 見えていない問いかけ • 個人プロフィールの検索・閲覧に最 適化 • 全体傾向を把握するには見えづらい 部分がある • 集計・比較・時系列分析が難しい • • • • 地域別の分布はどうなっているか Award Category ごとの人数差は Technology Area に偏りはあるか 国別・時系列でどう変化しているか 公開情報を「探す」ページから、公開情報を「読む」ダッシュボードへ DO WHAT MATTERS 公開情報：https://mvp.microsoft.com/ja-JP/search?target=Profile&program=MVP 5
6. 一般公開ページとの差別化 観点 一般公開ページ 今回のダッシュボード 主目的 MVP個人の検索・閲覧 全体傾向の分析 表示単位 個人プロフィール中心 国・地域・カテゴリ・技術領域・会社 分析 検索結果から人が読み取る 集計・比較・ドリルダウン 時系列 見えづらい 日別・月別・年別の総数推移 フィルター 検索条件中心 地域・カテゴリ・会社・技術領域など インサイト 人が解釈 Azure OpenAI で文章化 公式ページを置き換えるものではなく、公開情報を集計・分析するための別視点のダッシュボードです DO WHAT MATTERS 6
7. ダッシュボードの機能 MVP総数の表 示 会社別分類 地域別・国別 分布 日別・月別・ 年別推移 Award Category別分 布 Technology Area別分布 ドリルダウン ・フィルター Azure OpenAI インサイト生 成 性別など公開プロフィール上で明示されていない属性については、推定による分類は行わない方針です。 DO WHAT MATTERS 7
8. データ取得方式と利用条件への配慮 1 HTML クローリング検討 アクセス負荷・保守性・ 利用条件の懸念 → 2 API 候補を発見 → 事前確認を実施 MVP Program Support へ問い合わせ → 3 回答を受けて 方針を確定 集計インサイト中心の アプローチを継続 ✓ MVP Program Support からの回答（確認済み） 使用・表現NG 推奨アプローチ • • • • 当該 API は非ドキュメント・非サポート → 直接利用は非推奨 「公式 API」という表現は不可 • 現時点で公式な公開 API は存在しない 推奨表現:「公開されている Microsoft MVP プロフィール情報に基づく」 集計インサイト中心のアプローチはベスト プラクティスに沿っている 事前に確認したことで、方針の正しさが裏付けられた DO WHAT MATTERS 8
9. アーキテクチャ全体像 .NET 8 Blazor Web Appがフロ ントを担当 Azure Resource Group Container Registry Managed Id Key Vault CI/CD https://fedapp.*.japaneast.azurecontai nerapps.io Container Apps Environment 4 Container Apps(Web) http://8080 100% Container revision 1 Ingress 認 証 ・ 認 可 Container Apps ＋Dapr Cronで 定期収集 MVP 公式Web MVP datas 1 Application Insights Log Analytics Container revision 2 Container Apps(Worker) Container Apps(API) Container revision Container revision Storage account Raw data 2 サービス例 役割 定期取 得 Azure Functions / Container Apps データ取得 生デー タ保存 Azure Blob Storage Raw JSON Snapshot 構造化 データ Azure SQL Database / Cosmos DB 正規化済みデータ UI .NET 8 Blazor Web App ダッシュボード AI Azure OpenAI（ Microsoft Foundry ） インサイト生成 監視 Application Insights + Key Vault 実行状況・秘密情 報管理 Monitor Azure OpenAI SQL Database MVP datas 領域 Controller-based Web API (.NET 8) で集計 エンドポイント提供 3 Azure OpenAI には生データを丸投げせず、 C# 側で集計済みの JSON を渡す DO WHAT MATTERS 9
10. 論理データモデル（概要） マスタテーブル 設計のポイント • Snapshots テーブルで日別・ 月別・年別の MVP 総数推移を 表現 • ON DELETE CASCADE でスナ ップショット単位の管理 • 推定属性は付与しない設計 DO WHAT MATTERS 10
11. UI 構成：MudBlazor + ApexCharts 領域 ライブラリ KPIカード MudBlazor チップ・フィルター MudBlazor テーブル MudTable / MudDataGrid レイアウト MudGrid / MudPaper ドーナツチャート Blazor-ApexCharts 横棒ランキング Blazor-ApexCharts エリアチャート Blazor-ApexCharts Copilot Agent の提案に注意 • GitHub Copilot Agent が提案するラ イブラリが、常に最適とは限らない • 古い Chart.js ラッパーを提案するケ ースあり • UI・チャートライブラリは人間側で 方針を決めてから実装を委任する 技術スタックは Spec Kit の clarify / plan フェーズで先に固定しておく DO WHAT MATTERS 11
12. Azure OpenAI によるインサイト生成 やりがちな実装 今回の実装 総数・割合・順位・地域分類・Top10合計・ 未分類数を C# 側で計算 → Azure OpenAI には文章化を 依頼 「このMVPデータからインサイトを作ってく ださい。」 → 生データを丸投げ Aggregation API Insight Input JSON Azure OpenAI Insight Result Dashboard LLM に計算させるのではなく、集計済みデータを説明させる DO WHAT MATTERS 12
13. 出典：https://github.com/github/spec-kit Spec Kit とは何か AI に「いい感じに作って」と頼むのではなく、仕様・設計・タスクを 先に構造化してから実装させる、仕様駆動開発（SDD）の手段の一つ 1 specify 何を作るか・なぜ作 るかを定義 2 → clarify 曖昧な仕様を洗い出 す 3 → plan 技術スタックとアー キテクチャを固定 → 4 5 tasks → implement 実装可能な単位に分 解 GitHub Copilot Agent に実装させる 特に clarify が重要： 公開データ利用・APIの位置づけ・推定属性の扱いなど、曖昧なまま実 装すると危ない点を先に洗い出せる DO WHAT MATTERS 13
14. 今回の Spec Kit 活用ポイント 1. specify 「MVPの公開プロフィールを集計・可視化するダッシュボードを作る」 という目的を文書化 2. clarify データ取得方式・API利用可否・推定属性の扱い・更新頻度・エラー時 の挙動などを事前整理 3. plan .NET 8 Blazor / MudBlazor / Blazor-ApexCharts / Azure OpenAI の技術 スタックを確定 4. tasks データ取得・正規化・集計API・UI・AIインサイト生成を実装可能な単 位に分解 5. implement GitHub Copilot Agent に各タスクを委任し、人間はレビューと制約確認 に集中 DO WHAT MATTERS 14
15. 実践して見えた Spec Kit の課題 1 AI Credit の消費 Copilot は AI Credit の従量課金へ。多段フェーズの実行 はクレジット消費が積み上がる 2 読まれないドキュメ ント spec / plan / tasks など大量の文書が生成されるが、実装 後に読み返されにくい 3 Single Source of Truth 実装中の変更が仕様書へ反映されず、コードと文書が乖 離して「真実」が複数になる Spec Kit は SDD の手段の一つ。 クレジット消費と Single Source of Truth の観点から、手段を選び直す余地がある DO WHAT MATTERS 15
16. Plan モードという選択肢 観点 Spec Kit GitHub Copilot Plan モード 位置づけ SDD 専用のツールキット Copilot 標準の計画機能 成果物 spec / plan / tasks など多数の文 書 実装前の計画（必要最小限） クレジット 多段のエージェント実行で消費が 大きい 計画→実装のみで消費を抑えやすい SSOT 文書とコードが乖離しやすい コードの近くで計画し乖離しにくい レビュー対象 各フェーズで生成される文書 実装前の計画そのもの 向くケース 大規模・複数人・長期の仕様管理 日常の機能開発・小〜中規模 SDD の本質は「実装前に考える」こと。多くのケースは Plan モードで充分に実践できます DO WHAT MATTERS 16
17. Copilot Agent に任せる前に決めること Copilot Agent は優秀な実装者だが、優秀なアーキテクトとは限らない • • • • • • • • • • データ取得方式 利用条件への配慮 UIライブラリ チャートライブラリ データモデル 更新頻度 LLMに渡すデータ粒度 推測を許す範囲 エラー時の挙動 完了条件 だからこそ、Spec Kit で仕様・制約・タスクを先に渡す DO WHAT MATTERS 17
18. まとめ 1 公開データの価値 集計・分類・時系列化することで、検索では見えなかっ た新しいインサイトが得られる 2 Azure OpenAI の使 い方 LLM に計算させるのではなく、集計済みデータを渡して 「説明」させると安定する 3 SDD の手段の選択 仕様・制約の明確化は有効。ただし手段は Spec Kit に限 らず、Plan モードでも実践できる AI に実装を任せる時代だからこそ、 クレジットを浪費せず、Single Source of Truth を守り続けることの重要性が増している DO WHAT MATTERS 18
19. THANK YOU Yutaka.Osada union.dml@gmail.com https://github.com/yutaka-art DO WHAT MATTERS ▪合格対策Microsoft認定試験AZ-400 書籍 発売中！！ ▪今後の登壇予定 9/26 .NETラボ -クラウドAIだけでは届かない場所へ：OpenClawで開発環境を棚卸しするPoC 【通れば】9月末プラットフォームエンジニアリング会議 Agentic DevOps 19