
はじめに
こんにちは、SREチームの植松です。
前回の記事「AWS Cost and Usage Report(CUR)でKiroのユーザー別クレジット消費量を可視化する」では、CUR(Cost and Usage Report)を使ってKiro Enterpriseのクレジット消費量をユーザー別に可視化する方法を紹介しました。
当社ではエンジニアに限らずKiroのライセンスを付与しており、およそ80名ほどが利用しています。
今回はその続編として、可視化したデータをもとに月次でプランを動的に切り替える運用を構築した話をします。
本記事は2026年6月時点の情報に基づいています。Kiroのプラン体系や課金仕様は変更される可能性があるため、最新情報は公式ドキュメントをご確認ください。
背景・課題
今回対象にしたKiro Enterpriseには、以下の4つの有料プランがあります(2026/6/24時点)。
| プラン | 月額 | 付帯クレジット | 超過単価 |
|---|---|---|---|
| Pro | $20 | 1,000 | $0.04/credit |
| Pro+ | $40 | 2,000 | $0.04/credit |
| Pro Max | $100 | 5,000 | $0.04/credit |
| Power | $200 | 10,000 | $0.04/credit |
全員をPowerにすれば超過料金は抑えられますが、月額$200×全員分のコストがかかります。一方で実際の消費量を見ると、大多数は月1,000クレジット未満のユーザーでした。そのため全員Powerは明らかに過剰です。

約7割のユーザーは月1,500クレジット未満(Proの付帯クレジットと少量の超過で十分)ですが、一部のヘビーユーザーが10,000クレジットを超える使い方をしています。
一方で、全員Proのまま運用すると、ヘビーユーザーの超過料金が膨らみます。超過単価$0.04は全プラン共通なので、上位プランの付帯クレジットで吸収した方が安くなるケースがあります。
→ 毎月の使用実績に基づいて、必要な人だけ上位プランに一時的にアップグレードする運用を作ろう。
この運用により、ユーザーごとの適正プラン候補を使用実績から自動算出し、人が確認してから変更する仕組みを構築しました。以降、設計判断・実装・初月の実績について説明します。
なお、初月の金額効果は全員Proの場合とほぼ同水準でした。本記事でいう最適化は、単月の削減額だけでなく、超過料金の上振れリスクを抑え、利用実績にもとづいてプランを見直せる状態を作ることを指しています。
プラン変更運用の全体像
方針
- CURからユーザー別クレジット消費量を取得
- 月末予測に基づき閾値判定
- IAM Identity Centerのグループ移動でプラン変更
- 月末に上位プランのユーザーをProグループに戻す(ダウングレードは翌月から適用)
使用量は月ごとに変動するため、毎月全員Proにリセットし、翌月の実績を見て改めて判断します。一度上位プランにしたユーザーを固定するのではなく、毎月フラットに評価する方針です。
月次スケジュール

- 月末の5営業日前: 使用実績を集計し、閾値を超えるユーザーをPro+/Pro Max/Powerグループに移動
- 月の最終営業日: 全ユーザーをProグループに戻す
ダウングレードは翌月から適用されるため、月末にProグループへ戻しても当月中のユーザーの利用には影響しません。
仕組み
Kiro Enterpriseでは、Kiroコンソール上でIAM Identity Centerのグループにプランを紐づけることができます。
KiroProGroup → Pro割り当て KiroProPlusGroup → Pro+割り当て KiroProMaxGroup → Pro Max割り当て KiroPowerGroup → Power割り当て
ユーザーをグループ間で移動させるだけで、Kiro側が自動的にプランを切り替えてくれます。プラン変更の実体をグループ管理に寄せることで、権限管理と運用手順をAWS側に集約できます。
設計判断
閾値の考え方(損益分岐点)
判定に使う月末予測クレジットは、当月の累積クレジットをデータ取得日数で割り、月の日数を掛けて算出します。
超過単価が全プラン共通$0.04なので、上位プランの追加料金と超過料金が釣り合うポイント(損益分岐点)を計算します。
Pro → Pro+ の分岐点:
追加料金: $40 - $20 = $20 追加クレジット: 2,000 - 1,000 = 1,000 超過で$20に達するクレジット数: $20 ÷ $0.04 = 500 分岐点: 1,000(Pro付帯)+ 500 = 1,500クレジット
Pro+ → Pro Max の分岐点:
追加料金: $100 - $40 = $60 追加クレジット: 5,000 - 2,000 = 3,000 超過で$60に達するクレジット数: $60 ÷ $0.04 = 1,500 分岐点: 2,000(Pro+付帯)+ 1,500 = 3,500クレジット
Pro Max → Power の分岐点:
追加料金: $200 - $100 = $100 追加クレジット: 10,000 - 5,000 = 5,000 超過で$100に達するクレジット数: $100 ÷ $0.04 = 2,500 分岐点: 5,000(Pro Max付帯)+ 2,500 = 7,500クレジット
まとめると:
| 月末予測クレジット | 推奨プラン | 根拠 |
|---|---|---|
| 〜1,500 | Pro | 超過料金がPro+への追加料金$20未満。変更不要 |
| 1,500超〜3,500 | Pro+ | 超過料金がPro+の追加料金$20を超える。Pro+の方が安い |
| 3,500超〜7,500 | Pro Max | Pro+のまま超過料金を払うより、Pro Maxに変更した方が安い |
| 7,500超 | Power | Pro Maxのまま超過料金を払うより、Powerに変更した方が安い |
損益分岐点を超える使い方をする場合に限り、上位プランの方が安くなります。
スケジュールの根拠
なぜ月末の5営業日前なのか。詳細は後述の「運用時の注意点」で説明しますが、グループ移動によるプラン変更には最大24時間の同期遅延があります。最終営業日まで4営業日の余裕があれば、このラグを十分吸収できます。また、月末に近く月末予測の精度を確保しやすいタイミングです。
ダウングレードを最終営業日にしている理由は、Kiroの仕様上ダウングレードは翌月から適用されるためです。当月中にグループ移動さえすればいつやっても結果は同じなので、最終営業日で十分と判断しました。
なぜ Kiro CLI Skills で実装したか
「Lambda + EventBridgeで完全自動化」も検討しましたが、以下の理由でKiro CLI Skills(対話型で実行する運用スクリプト)を選びました。
- 低頻度 — 月2回しか実行しない。自動化基盤のメンテコストに見合わない
- 実行前確認が必要 — 一時的なスパイクか定常的な使い方か、リストを見て判断したい
- 例外判断が多い — 「プロジェクト完了で使わなくなる」等の判断は人がすべき
低頻度で、実行前確認が必要で、例外判断が多い処理は、完全自動化より対話型の半自動化が合います。「AIが提案し、人が承認してから実行する」というパターンです。ユーザー数が数百人〜1,000人規模になったら自動化を再検討しますが、現時点ではこちらの方が運用コスト・開発コストともに低いと判断しました。
実装
安全に実行するための設計
プラン変更はコストに直結する操作なので、安全面を重視して設計しています。
- ドライランがデフォルト: 「実行して」と明示的に指示するまでグループ変更APIは呼ばれない
- 最小権限の許可セット:
Identity Storeの GroupMembership操作のみ。Organizationsの管理アカウントの管理者権限は使わない - プロファイル分離: CUR照会用(
cur-query)とグループ操作用(kiro-subscription-manager)を分離 - IP制限: 許可セットにオフィスIP以外からの全操作Denyを付与
IAM Identity Centerのグループ構成
KiroProGroup ← 全ユーザーが通常時ここに所属(Pro) KiroProPlusGroup ← 閾値超過ユーザーを一時的に移動(Pro+) KiroProMaxGroup ← 同上(Pro Max) KiroPowerGroup ← 同上(Power)
グループ所属は排他的(1ユーザーは1グループのみ)。変更時は「旧グループから削除 → 新グループに追加」の順で実行します。
許可セットの設計方針
専用の許可セットを作成し、以下の方針で権限を絞っています:
- 最小権限: Identity Storeのユーザー/グループ参照と、GroupMembershipの作成・削除のみ許可
- IP制限: オフィスIP以外からの全操作をDeny(
aws:SourceIpとaws:ViaAWSServiceの条件キー) - プロファイル分離: CUR照会用とグループ操作用でAWSプロファイルを分け、誤操作の影響範囲を限定
Kiro CLI Skills での実装
スキルは以下のような指示で作成しました(要約):
CURからユーザー別のKiroクレジット消費量を取得し、月末予測に基づいて 閾値超過ユーザーをIAM Identity Centerのグループ間で移動させるスキルを作って。 - identitystore list-usersでユーザーマッピングを動的取得 - AthenaでCUR照会(VALUES句にマッピングを埋め込む形式) - S3からCSV直接取得して集計 - 月末予測 = 累積 ÷ データ日数 × 月の総日数 - 閾値: 1,500超→Pro+、3,500超→Pro Max、7,500超→Power - ドライランがデフォルト。明示的に承認するまで実行しない - プロファイルはkiro-subscription-manager(identitystore操作)とcur-query(CUR照会)を使い分ける
実行すると以下のようなドライラン結果が表示されます:
[ドライラン] 以下の変更を実行します: | # | ユーザー | 現在のグループ | 変更先グループ | |---|---|---|---| | 1 | user_a | KiroProGroup (Pro) | KiroPowerGroup (Power) | | 2 | user_b | KiroProGroup (Pro) | KiroProPlusGroup (Pro+) | | ... | ... | ... | ... | ※ 実際のグループ変更は行っていません ※ 実行する場合は「実行して」と指示してください
運用時の注意点
グループ同期の最大24時間ラグ
ドキュメント(Managing Kiro subscriptions)には以下の記載があります:
If it is a higher tier plan, changes will happen immediately.
この記載はKiroコンソール上でChange planを実行した場合の挙動を指していると考えられます。一方で、IAM Identity Centerのグループ移動による変更はグループ同期を経由するため、反映までにラグがあります。
AWSサポートに確認したところ、検証環境では以下の挙動を確認しました:
- グループ移動直後 → プラン変わらず
- 10時間後 → プランは変わらず
- 24時間後 → アップグレード適用
ドキュメントの別ページ(Connect your IAM Identity Center)には以下の記載があります:
Group sync delay: If you add users to a group that already has a Kiro subscription, allow up to 24 hours for the new group membership to propagate.
つまり: - Kiroコンソールでの手動Change plan → 即時適用 - グループ移動による暗黙的なプラン変更 → 最大24時間の同期遅延あり
これが「月末の5営業日前にアップグレード」としている理由です。月末直前にやると、適用が翌月にずれ込むリスクがあります。
なお、ダウングレードについてはサポートの検証で「グループ移動による下位プランへの変更は当月中に即時反映されず、翌月から適用される」ことを確認しています。当月中の即時反映を期待しないため、同期ラグの影響を受けません。最終営業日の実施で問題ありません。
初月のコスト影響
6月の実績
以下は、実際にプラン最適化を行った場合の請求確定値と、同じ利用量を全員Proのまま使った場合の試算値を比較したものです。
| 項目 | 全員Pro(試算) | プラン最適化(実績) |
|---|---|---|
| 基本料金 | $1,637 | $3,503 |
| 超過料金 | $2,531 | $692 |
| 合計 | $4,168 | $4,195 |
※ 基本料金には、月途中のプラン変更・利用開始タイミングによる日割り分を含みます。そのため、人数×月額の単純計算とは一致しません。
差し引き$27の微増。超過料金は$1,839削減されましたが、上位プランの基本料金増$1,866でほぼ相殺されました。
なぜほぼ同水準か
閾値を損益分岐点で設定しているため、分岐点ギリギリのユーザーが多いとほぼ同水準になります。これは構造的なものです。
各プランの効果は「分岐点をどれだけ超えているか」で決まります:
- 分岐点ちょうど(例: Power対象で月7,500クレジット)→ 効果$0
- 分岐点を超えるほど効果が増加 → 各プランに上限あり(Pro+ $20、Pro Max $80、Power $180)
6月はPower対象7名の平均消費が約9,000クレジット(分岐点7,500に近い)だったため、1人あたりの効果が$140程度にとどまりました。Proのままなら$20 + 8,000×$0.04 = $340かかるところ、Powerなら$200で収まるため、差額が$140です。もし平均消費が10,000を超えていれば、効果は上限の$180に近づきます。
効果が出る条件
分岐点を大きく超えて使うユーザーが多い月ほど効果が出ます。特にPower対象者の消費が10,000クレジット以上の場合、1人あたり最大$180/月の削減になります。
逆に、全員が分岐点ギリギリの使い方ならほぼ同水準になるのが、この運用の構造的な特性です。
コスト以外の効果
金銭面以上に、以下の効果がありました。
ヘビーユーザーの超過料金スパイクの抑制: 月10,000クレジット以上使うユーザーがProのまま放置されると、1人あたり$360以上の超過料金がかかります。Powerに変更することで付帯枠内に収まり、超過料金の上振れリスクを抑えられます。予測しづらい超過料金が基本料金(定額)に置き換わることで、コストの見通しが立てやすくなります。
利用状況の可視化と利用促進のきっかけ: 誰がどのプランに相当する使い方をしているかが毎月明確になります。ライトユーザーへの利用促進や、ヘビーユーザーの使い方のナレッジ共有など、コスト以外の施策につなげるきっかけになりました。
今後の運用方針
この運用を数ヶ月回すことで、ユーザーごとの利用傾向が見えてきます。毎月同じメンバーが上位プラン対象になるようであれば、そのユーザーを恒常的に上位プランに固定し、月次運用の頻度を下げる・廃止することも検討します。
現時点では「毎月フラットに判定し直す」方針ですが、データが溜まれば「固定枠 + 変動枠」のハイブリッド運用に移行できる見込みです。
おわりに
CURによる使用状況の可視化(前回)をもとに、プラン変更の運用フローを構築しました。
ポイントをまとめると:
- IAM Identity Centerのグループ移動でプランを切り替える
- 損益分岐点ベースの閾値(1,500 / 3,500 / 7,500クレジット)で判定
- グループ同期に最大24時間かかるため、月末直前は避ける
- 実行頻度が低く、事前確認と例外判断が必要な処理は、完全自動化より半自動化が合う
初月のコスト効果はほぼ同水準でしたが、使用実績にもとづいてプランを自動算出し、適正化する仕組み自体は想定通り機能しています。可視化→判断→実行→検証のサイクルを回し続けることで、コスト構造の理解と最適化を進めていきます。
単月の削減額だけを見るのではなく、利用実績にもとづいて判断し、必要なときに調整できる状態を作ることが、今回の運用改善の主な成果です。