ちょうど検証環境で1ユーザーの Copilot Credits が上限に達したこともあり、検証がてら別のポリシーに割り当てたらどうなるのかを行ってみました。
前提条件
各Copilot支出ポリシー
| ポリシー名（仮） | グループ名 | ポリシー上限 | ユーザー上限 |
|---|---|---|---|
| 一般利用ユーザーポリシー | SEC_Cowork_Enabled_user | 5000 | 3000 |
| High利用ユーザーポリシー | SEC_Cowork_Enabled_Hiuser | 7000 | 5000 |
ユーザーの利用状況
こんな感じで「一般利用ユーザーポリシー」のユーザー上限に引っかかっています。
その結果、こんな風に3000以上いかないようになっています。
いやぁ・・・きれいな数字ですねぇ😃
課金ポリシー変更検証
検証ポイントとしては以下の4つ
- 該当ユーザーの最大Creditsはどうなるのか？？
- 該当ユーザーの現在の消費Creditsはどうなるのか？
- 移動元のポリシー全体の消費Creditsはどうなるのか？
- 移動先のポリシー全体の消費Creditsはどうなるのか？
グループの移動
下図の通り、一般利用ユーザーポリシーのグループから、High利用ユーザーポリシーのグループに移動することでどうなるかを検証します。
結果
以下のようになりました。
| 検証項目 | 移動前 | 移動後 |
|---|---|---|
| ユーザー最大値 | 3000 | 5000 |
| ユーザー現在値 | 3000 | 3317 |
| 移動元ポリシー消費Credits | 3000 | 3000 |
| 移動先ポリシー消費Credits | 0 | 317 |
つまり、ユーザーのクレジットの上限は上がったけど消費Creditsは変わらず、ポリシーの消費Creditsは変わらない（消費先は所属ポリシーに変更）という検証結果となりました。
まとめ
Copilot Credits の消費について、課金ポリシーが割と精密にできているなという印象でした。
一番危惧していたのは、ポリシーが変わることで、ユーザーの消費Creditsが0になることでした。これはさすがに違うと思っていたので、今回の結果に非常に良い仕組みだと素直に感じました。
なので、部署ごとにユーザーごとの上限値を複数段階用意しておいて、ユーザーの利用に基づいて能動的に変えるようにするといいんじゃないかなと思います。
そういう意味では、ユーザー部署でセキュリティグループの変更が可能なアプリというのを提供してもいい気がしますね！