GitHub CopilotのFinOps - AI CreditのObservabilityと価値を生むためのエージェント設計

7/31のすきやねんAzureでお話しした内容です

Transcript

1. GitHub CopilotのFinOps - AI CreditのObservabilityと価値を生むた めのエージェント設計 #すきやねんAzure GitHub Copilot夏祭り Microsoft Japan Yurie Mori
2. Agenda AI Creditのobservability • AI Creditの予算管理 • 価値を生むためのエージェント設計 •
3. Who am I Carrer ◆ Microsoft Japan Software Solution Engineer ◆ Avanade Japan DevOps Engineer/Architect ◆ Plus Alpha Consulting Web Application Engineer Yurie Mori (森 友梨映) Microsoft Japan Cloud & AI Platform, Software Solution Engineer Awards ◆ Microsoft MVP for DevOps & Cloud Security 2025 ◆ Microsoft MVP for DevOps 2024 Technology stack ◆ DevOps ◆ DevSecOps ◆ Platform Engineering ◆ Developer Experience/Productivity SNS
4. お知らせ：9月にAI Creditのプロモーション期間が終了します  GitHub CopilotのUsage Based Biling (UBB)がGAした6月から8月 までの3か月間はプロモーションオファ リングとして通常より多いAI Credit が無料枠として付与されていました  9月からの無料枠は以下になります  GitHub Copilot Business: 1900 AIC  GitHub Copilot Enterprise: 3900 AIC
5. AI CreditのObservability
6. FinOpsの3ステップ 1. Inform（見える化） 2. Optimize（最適化） 3. Operate（統制）  使用量データをダッシュボードで定期チェック  予算と実績を比較し、消費パターンから無駄  予算上限に達した際のアラート設定  Token消費トップのユーザーやプロジェクトを 洗い出し  使用量の推移や傾向を可視化し、関係者 と共有 を特定  Token消費の多い操作やモデル利用を分析  開発者向けTipsやガイドラインを展開  継続的なフィードバックで運用ルールを見直し  組織全体の統制を強化 FinOpsの目的：コスト削減だけでなく、開発者の生産性向上とのバランスを保つこと
7. 組織でAI Creditをどれだけ使っているか
8. Copilot Impact Dashboard どれだけのユーザーがGitHub Copilotの活用度のどのフェーズに いるか？ Phase1: IDEだけのCopilot機能を使用 Phase2: Copilot review, Cloud agentなどGitHub.com上の agentを1つは使っている Phase3: 複数のエージェントを組み合わせて使っている
9. Copilot Impact Dashboard 各活用フェーズのユーザー数はどう推移しているか？ PRのスループット（＝マージされたPRの数は）はどう変 わったか？
10. FinOps で見るべき統合ポイント 観点 AI Usage で見るもの Copilot Impact Dashboard で見るも の 管理者の判断 利用効 率 AI Credits、モデル別消費、利 用増加の速度 PR 数、AI-assisted LoC、マージ時間 消費増が成果増に結び付いているか 投資対 効果 部門・チーム・ユーザー別のコスト cohort ごとの PR throughput、開発フロ 高コスト利用者・チームが高い価値を出しているか ー 採用の 深さ Credits を使うユーザー数・頻 度 Passive / Phase 1 / Phase 2 / Phase 3 ライセンス配布だけで終わらず、実務利用へ進んでいるか の構成 異常検 知 特定モデル・日付・ユーザーの急 PR 数低下、マージ時間悪化、採用停滞 増 コストだけ増えて成果が出ない利用を早期に調査する 予算統 制 included credits 残量、追加 利用、予算上限 成果の改善度 成果が弱い領域は拡大より先に支援・制限・再設計を行う 配賦 コストセンター・組織・ユーザー別 の消費 チーム単位の adoption と成果 Showback / Chargeback を「費用＋成果」で説明する
11. 注意点 • • • • • PRのマージのスループット（どれだけたくさんのPRがマージされたか）を生産性 の向上と同一視しない たくさんのPRがマージされていても、バグが含まれていたりしたら意味がない 価値ある変更がリリースされたかが重要 マルチエージェント活用が進んだということも生産性が向上したというわけでも ない エージェントをたくさん使っているということはGitHub Copilotの習熟度が向上 しているという風に見ることもできるが、そのエージェントが生産しているものが 価値があるかが重要
12. 観測のポイント • FinOps の観点では、AI Usage を「コストと消費の観測」、Copilot Impact Dashboard を「採用度と成果の観測」 として結び付け、AI Credits 1 単位あたりの事業・開発価値を管理することが重要 • 「Credits 増加」と「成果増加」を必ず対で見る 良い状態 注意が必要な状態 • AI Credits は増えている • AI Credits は急増している • Phase 2 / Phase 3 の利用者比率が増えている • しかし PR throughput は横ばい・低下している • PR のマージ数が増えている • マージ時間が伸びている • PR マージ時間が維持または短縮している • Passive users や Phase 1 に滞留している • AI-assisted LoC や開発者あたりのアウトプットが改善している • 一部のヘビーユーザーだけが Credits を消費している この場合、利用増は単なるコスト増ではなく、GitHub Copilotの習 熟度も上がり、多くの変更をデリバリーできていると評価できます。 この場合は、モデル選択、利用方法、プロンプト、agent のタスク設 計、レビュー工程、教育不足などを確認する。
13. AI Creditの予算管理
14. FinOpsの検討ポイント  公平な消費か、全体最適か？  公平な消費を追求する場合は、共通User Level Budgetのみを設定することで全ユーザーに一定の消費を保証することができます。し かし、ユーザー間でたくさん使用するユーザーとあまり使用しないユーザーがいる場合、共通User Level Budgetのみを設定すると、使用さ れなかったAI Creditがユーザー間でスライドされないため、全体最適の観点からは非効率になります。  予算拠出や追加課金の意思決定をどこに委任するか  従来、GitHub Enterpriseにおける請求管理はEnterprise OwnerもしくはBilling Managerの役割を持つユーザーが一括で管理していましたが、UBBの 運用においては、現場の状況に応じた柔軟な追加課金の意思決定や使用状況の追跡が必要になります。Cost Centerを利用することで、紐づけられた OrganizationやRepositoryにおけるAI Creditの追加課金の意思決定や運用を、Cost Centerの管理者に委任できます。  どのユーザーグループに重点的にAI Creditの予算を投資するか  AI Creditの予算を重点的に投資するユーザーグループを定めることも重要です。例えば、AI活用推進のPoCを実施しているユーザーグループ がある場合、そのユーザーグループに対してOrganization Level BudgetやCost Center Level Budgetを設定することで、AI Creditの予 算を重点的に投資できます。  エンタープライズとして許容できるコスト上限をどこに設定するか  エンタープライズ全体で許容できるコスト上限を定めることも重要です。これにより、意図しないコストの増大を防止できます。Enterprise Level Budgetを設定することで、エンタープライズ全体のAI Creditの使用量に上限を設けることができます。
15. 多層の予算ガードレール Enterprise Level Budget Organization Level Budget Cost Center Level Budget User Level Budget ※予算上限到達時は使用Stopのみ ※各層ごとに予算上限到達時の「使用停止」設定が可能（ULBのみ停止固定）
16. 予算設定時に適用される原則  「余剰が少ない方が優先」ルール  複数の予算ガードレールがある場合、残り予算が少ない設定が優先される  例：User Budget $350でもOrg予算$300が先に尽きれば使用停止  完全なる公平な消費を共通User Level Budgetで担保  全ユーザーに一定のAI Creditを保証（例：$30/ユーザー）  コストセンターのAI Credit Poolを有効化すると、コストセンターごとのMax消費を制限  コストセンターの人数に応じて、そのコストセンターがMax使用できるAI Creditの上限を設定することができる  AI Credit Poolの有効化ができるのはEnterprise TeamかUserに紐づけて作成したコストセンターのみ。Org, Reposに紐づけて作成し たコストセンターでは有効化することはできない  User Level Budgetの設定は共通設定（コストセンター、Enterpriseの予算設定）を上 書きする  パワーユーザーには個別で高い予算を設定可能（例：$50）
17. Cost CenterによるFinOps運用の委任 7/3の更新でCost CenterでもAI Credit Poolを有効化できるようになりました
18. User Level Budgetの設定 Cost Center（per user） Individual user Universal 選択したCost Centerの全ライセンスユーザーに、1 人あたりの上限を適用。Universalの設定を上書 きします。 選択した1ユーザーだけに個別上限を適用。Cost CenterとUniversalの両方より優先されます。 全ライセンスユーザーに共通の既定上限を適用。よ り具体的な設定がない場合のベースラインです。 User Level Budgetの適用優先順位：Individual > Cost Center > Universal — 対象ユーザーに最も具体的な設定を適用
19. 開発者向け：価値を生むためのエージェント設計
20. 参考：Tokenを消費する要素 • • • • • • • GitHub CopilotにおけるTokenを消費する要素は以下と なります。 タスク実行時に選択されるLLM 処理するコンテキストの大きさ 処理内容（抽象度が高いか/低いか） セッションの長さ（1つのセッションでどれだけ履歴がある か） GitHub Copilotが参照するCustom instruction 使用するTool
21. コスト上昇のよくある原因と対策 原因 対策 Autoモードを活用 高価なモデルの常用 Claude Opus 4.7やGPT 5.5などを常時使用 適切なLLMが自動選択され10%ディスカウント適用 タスクの実行内容ごとに適切なモデルを選択 各LLMごとに深い推論に最適化されたモデルやコーディングに特化したLLMなど性質があります。 サブエージェント全てが高価なモデル orchestrator以外は安価なLLMに変更 与えているコンテキストが膨大 #file:で必要な部分だけを指定 カスタマイズの見直し不足 Custom InstructionとToolの見直し オーケストレーション全体が高コストLLMで動作 #codebaseや大きなファイル丸ごとで入力Tokenが增大 Custom InstructionやMCPサーバーの常時起動がAICを消費 作業内容に応じてsubagentのモデルを使い分け 作業ごとに明示的に必要なコンテキストだけを与える 不要なコンテキストやMCPの常時参照を削減
22. Enterprise Managed SettingsでデフォルトをモデルをAutoに • .github-privateリポジトリに manged-settings.jsonというファ イルを作成 • デフォLLMをAutoに固定 • Marketplaceで入手できる外部 ツールを制限 • Copilot使用時の権限のバイパス を制限 • Telemetryの有効化の強制
23. AI Creditは不確実性の高い仕事へ投資し、決定的な作業は 自動化する エージェントに任せるべき作業 CIの中で自動化で解決すべき • 複数ファイルを横断する障害調査 ▪ フォーマット、Lintチェック • アーキテクチャ設計・技術選定 ▪ CI、テスト、型検査 • 大規模・相互依存なリファクタリング ▪ 静的解析・脆弱性スキャン • 仕様からの実装計画 • 実装 判断基準：原因や影響範囲が不明か／複数領域を横断するか／人の調査時間を削減できるか／客観的に検証できるか 出典: GitHub Docs「Optimizing your AI usage to maximize efficiency and reduce cost」
24. セキュリティスキャンへのAI活用はあくまで補完として使う lintチェックやテスト、セキュリティスキャンなど「必ずすべての項目がチェックされ なければならない」系のタスクは非決定論的なLLMに完全委任するのはリス クがあります。「昨日は通ってたけど今日は通ってないテスト」のような結果にな るリスクがあり、LLMに任せること自体がFlaky test（安定しないテスト）に なりかねません。 • これらの決定論的なチェックはLLMに完全委任するのではなく、CIのフェーズで 決定論的なツール(GitHub Advanced SecurityのCode Securityなど）で 担保するようにしましょう。 •
25. モデルごとの特性でタスクを割り振る 役割 主な責務 適するモデルクラス 例 1 プランナー / テックリード 問題分解、設計、リスク・ トレードオフの整理、 完了条件の定義 深い推論モデル GPT-5.5、Claude Opus 系、 Gemini Pro 系 2 リポジトリ探索担当 関連ファイル、依存関係、 既存パターン、テスト位置の 特定 中位〜軽量の エージェント向けモデル GPT-5.4 mini、 GPT-5.3-Codex など 3 実装担当 承認済み計画に沿った 限定的な変更、テスト追加、 修正 中位・汎用コーディングモデル GPT-5.3-Codex、 Claude Sonnet 系 4 レビュー担当 仕様逸脱、コーディング規約、アーキテク 仕様逸脱、回帰、 セキュリティ、保守性の確認 チャガイドラインの確認 実装担当と異なる モデル系統が望ましい Claude / GPT / Gemini を 交差利用 5 定型作業担当 小さな編集、コメント、文書、 フォーマット、単純な変換 軽量モデル GPT-5 mini、Claude Haiku 系、 Flash 系 6 決定的検証担当 テスト、Lint、型検査、ビルド、 セキュリティスキャン モデルではなくツール CI、静的解析、テストランナー 出典: GitHub Docs「AI model comparison」 / 出典: GitHub Docs「Optimizing your AI usage to maximize efficiency and reduce cost」
26. 1つのエージェントの役割をフェーズごとにわける 制約 策定 計画 探索 人間 強い推論 軽量 調査 → 計画 実装 決定 的検 証 レビュ ー マージ 判断 汎用 ツール 別モデル 人間 計画 → 実装 関連ファイル・根拠・原因仮説 手順・変更対象・受入条件・リスク 実装 → レビュー 差分・検証結果・未解決事項 重要：前フェーズの全履歴ではなく、圧縮した成果物だけを次フェーズへ渡す 出典: GitHub Docs「Optimizing your AI usage to maximize efficiency and reduce cost」
27. 必要最小コンテキストが、不要な探索と再試行を減らす 必要最小コンテキスト ＝ 目的 ＋ 制約 ＋ 関連する根拠 ＋ 完了条件 目的 何を変える／調べるのか 背景 なぜ必要か・ユーザー影響 対象範囲 repo / module / file / API / log 制約 変更禁止・互換性・性能・セキュリティ 実行権限 ツール・コマンド・ネットワーク・変更可否 完了／停止条件 必須テスト・期待動作・質問へ戻る境界 無差別なファイル添付や長大な会話履歴は、入力トークンと注意分散を増やす 出典: GitHub Docs「Optimizing your AI usage to maximize efficiency and reduce cost」
28. コンテキスト設計の見直し CIでチェックすべきことをcustom instructionに書いてないか？ • #codebaseなど膨大なコンテキストを渡しているpromptがないか？ • 野良のcustom instructionやMCPサーバーがないか？ •
29. キャッシュを守るには、1セッション中の構成を固定する 同じ問題を継続する間は固定 Model Reasoning level Context size Tool set MCP servers 切り替えが必要になったら、新しいセッションへ 作業中セッ ション 要約を作成 新規セッショ ン モデル変更・reasoning変更・ツール追加を途中で行うと、コンテキスト全体 の再処理につながる可能性があります。 サブエージェント：独立した小規模コンテキストを渡し、主セッションの履歴を引き 継がない キャッシュは「偶然効くもの」ではなく、モデル・コンテキスト・ツール構成で守る設計対象 出典: GitHub Docs「Optimizing your AI usage to maximize efficiency and reduce cost」
30. /chronicle cost tipsでコスト最適化の提案を取得 実際の使用データをベースにコスト最適化の改善案を提案 • GitHub Copilot Appで使用可能 •
31. GitHub CopilotのBYOKでAI Credit消費を逃がす？ BYOKでご自身でホストしたLLMをGitHub Copilotで利用することで、AI Creditが掛かることを回避することができる • しかし、BYOKでGitHub Copilotを利用する場合は、GitHubのTrust Centerで明記されている学習に使用しない、データを長期保存しないなどの statementが適用されない（これらの適用対象はGitHubがGitHub Copilotで提供しているLLMのみで、BYOKには適用されない） •
32. まとめ 1 AI Creditを可視化し、成果と対で評価する 使用量だけでなく、PR throughput、マージ時間、AI-assisted LoC、利用フェーズを継続的に観測します。 2 多層のガードレールで予算を統制する Enterprise／Organization／Cost Center／Userの上限と優先順位を設計し、費用と責任を適切に配分します。 3 AIは不確実性の高い仕事へ集中投資する 探索・推論が必要なタスクに強いモデルを使い、Lint・テスト・スキャンなどの決定的作業は自動化します。 4 エージェントハーネス全体を継続改善する 役割分担、必要最小コンテキスト、キャッシュ、短い検証ループ、停止条件を最適化し、同じCreditから生まれる価値 を高めます。
33. 宣伝：PEK2026で登壇します 2026/9/26（土）に開催されるPlatform Engineering Kaigi2026で登壇しま す。 Agentic AI時代にプラットフォームをどう守るか的な話をします。 ご参加お待ちしております！
34. Thank you : )