背景
AI Creditに移行まで GitHub Copilot のライセンス申請は、Redmine によるチケット申請方式（1チケットに1人のサポート担当が付く）で運用していました。
しかし、以下のような課題がありました。
- 人手対応のため、チケット処理完了まで時間がかかる（最悪1日以上）
- 承認後の作業漏れが発生しやすい
- ライセンス種別や AI Credit 上限設定のミスが発生しやすい
また、AI Credit はプレミアムリクエストと違い消費が激しいため、利用枠を拡大する方や細かく利用枠を変更する方が続出することは容易に想像できました。
この人手によるタイムラグで利用者さんの作業を止めるわけにはいかないため、全て自動化することに踏み切りました。
基本方針
- ID 基盤は Entra ID を利用
- アクセス制御を細かく実施したいため Microsoft 365 を中心とした構成を採用
- 全従業員が Microsoft 365 E3 ライセンスを保有しているため
主な利用サービス
| 項目 | サービス |
|---|---|
| ライセンス管理 | Entra グループ |
| 受付フォーム | Microsoft Lists フォーム |
| 申請データ保存 | SharePoint Lists |
| 承認処理 | Power Automate |
| タスク実行・通知 | Azure Logic Apps + GitHub Actions |
全体アーキテクチャ
利用者が直接触れるのは Microsoft 365 の領域のみです。
GitHub や Azure 側は処理基盤として切り離されているため、将来的な置き換えや他業務への横展開が可能な構成になっています。
実装期間は 2週間程度です（営業日だともっと短い）。
ライセンス管理
Entra グループを採用した理由
- 全従業員が Entra ID を保有している
- GitHub Enterprise Managed Users の IdP グループ連携を利用できる
工夫
- Business / Enterprise と AI Credit 上限ごとに Entra グループを作って運用しています。
- 弊社ではGitHub EnterpriseのEMU機能を使っており、EntraグループとGitHubユーザーを同期しています。
- 一方で、GitHubの予算設定はIdPグループ非対応のため、AI Creditの上限設定はREST API叩いて同期させています。
- Entra グループを正として毎日 GitHub 設定と同期することで整合性を維持しています。
受付フォーム
利用者向け申請画面には Microsoft Lists のフォーム機能を利用しています。
採用理由
- ユーザー/グループ列があり、ユーザーを Entra ID ベースで指定できる
- 利用者がユーザーを指定しやすい
- Lists 自体への編集権限を利用者へ付与しなくても、フォーム経由なら Lists にアイテムを登録できる
- Microsoft 365 の認証基盤をそのまま利用できる
申請内容管理
申請情報は SharePoint Lists に保存しています。
採用理由
- Entra ID ベースの柔軟な権限管理が可能
- 全社員が利用可能なため追加ライセンス不要
- 監査対応が容易
工夫
申請者・承認者など関係者に対して、申請アイテム単位で閲覧権限を付与しています。
SharePoint Lists には、1行ずつ細かくアクセス権限を付与できます。
実装方法は以下の記事をご参照ください。
これにより、利用者自身が申請状況や過去の申請履歴を確認できます。
今後の課題
SharePoint Lists にはいわゆる「5000件問題」があります。
現在の申請件数では問題ありませんが、将来的には四半期・半年・年単位でアーカイブすることを検討しています。
承認フロー
承認処理には Power Automate の承認機能を利用しています。
採用理由
Logic Apps では利用できない標準承認機能を利用するためです。
課題
- Power Automate（Power Platform）は IaC 化が困難 (我々のライセンス事情によるものです)
- Pull Request ベースの変更管理ができない
現在は以下の方法でデプロイフローを整備しています。
タスク実行基盤
Logic Apps の役割
- SharePoint Lists の変更検知
- ステータス更新
- Teams / Outlook 通知
- GitHub Actions の起動
GitHub Actions の役割
- Entra グループへのメンバー追加
- GitHub 側の AI Credit 設定反映
採用理由
- プレミアムリクエスト時代から GitHub Actions でライセンス付与を実施していた
- チームとして GitHub Actions に長けているため
- Logic Apps は IaC 化でき、Microsoft 365 サービスとの連携も強力
工夫
Power Automate → Logic Apps の呼び出し
Power Automate ではプレミアムコネクタが必要になるため、Logic Apps を経由しています。(お金をケチってすいません)
Power Automate から Logic Apps を直接呼ぶのは癖があるため、トリガー用 SharePoint Lists（個別処理リスト）を間に挟んでいます。
Logic Apps → GitHub Actions の呼び出し
Logic Apps から GitHub Actions を起動する際には GitHub App を利用しています。
そのため、JWT 発行用の Azure Functions を別途用意しました。
Azure Functions は管理対象サービスが増えるため、本来は使いたくありませんでしたが、今回は必要な構成でした。
ステータス駆動の通知
SharePoint Lists のステータス列を監視し、
- 成功通知
- 失敗通知
を Logic Apps で実装しています。
また、GitHub Actions から直接 SharePoint Lists を更新できないため、Logic Apps 経由でステータスを書き戻しています。
※ Sites.Selected 権限を利用すれば将来的には GitHub Actions から直接更新する構成も可能です。
条件付きアクセスの回避
弊社では1週間に1回の再認証が必須で設定されていますが、Azure Logic Apps や Power Automate は、毎週の再認証を考慮する必要がありません。内部的にトークンをリフレッシュしているようです。
冪等性
GitHub Actions は同じ申請に対して複数回実行しても結果が変わらないよう実装しています。
これにより、
- 利用者の重複申請
- 管理者による再実行
にも対応できます。
自動化による効果
2026年6月は想定通りたくさんの申請がきました（生々しい値は伏せます）
人手でやっていた頃は1件あたり20分程度の見積もりでしたが、現在は全工程が自動化されているためこの作業工数を大幅に削減できています。また、ライセンス付与までの待ち時間も短縮され、利用者が迅速に GitHub Copilot を利用できるようになりました。
まとめ
GitHub Copilot の申請受付から承認、ライセンス付与、AI Credit 設定、通知までを Microsoft 365、Azure、GitHub Actions を組み合わせて自動化しました。
今回の構成では GitHub Actions を利用していますが、他の CI/CD サービスへ置き換えることも可能です。
また、Lists フォームと SharePoint Lists を利用した申請フローは GitHub Copilot に限らず、
- 各種サービスデスク業務
- 各種申請業務
- 非エンジニア向けの実行依頼フォーム
などにも応用できる汎用的なアーキテクチャだと考えています。