Kiro の利用状況とコストを把握する ― Part 1: Kiro のクレジット消費量とコストはどこで確認できるか

組織で Kiro を導入すると、誰がどれだけ使い、そのコストがどこで発生しているのかを継続的に把握する必要が出てきます。

Part 1 の本記事では、Kiro の利用状況とコストを確認することのできる情報源として Kiro User Activity Report と AWS Cost and Usage Reports (CUR) 2.0 を取り上げ、その概要を紹介します。また、CUR 2.0 を Amazon Athena で分析する方法と、Kiro が標準で備えている Kiro 使用状況ダッシュボードについても紹介します。

なお、別記事となる Part 2 では、これらの情報を継続的に可視化する 2 つのダッシュボードについて紹介します。

注：本記事に記載の料金およびクレジット枠は 2026 年 10 月時点のものです。最新の情報は Kiro の料金ページをご確認ください。

1. 背景：「誰が、どれだけ使っているのか」が見えない

Kiro を数人で試している段階なら、コストの内訳はそれほど問題にはなりません。ところが組織全体へ展開し、数十人・数百人が日々 Kiro を使うようになると、話が変わってきます。

Kiro の利用量は「クレジット」という単位で測られます。各プランには月あたりのクレジット枠が含まれており、その枠内であればプランの月額料金だけで利用できます。枠を超えた分は「超過 (overage)」となり、デフォルトでは月内はそれ以上使えなくなります。Kiro の設定で超過を許可すると、クレジット単位の追加料金を払って使い続けられます。

つまり、組織で Kiro を運用する管理者は、「誰がどれだけクレジットを使い、追加料金が膨らんでいないか、プランが見合っているか」を継続的に見ていく必要があります。その際、多くの管理者が、以下のような困りごとに直面します。

• 多くのメンバーに Kiro サブスクリプションを割り当てたものの、実際に誰がどれだけ使っているのかを把握できない
• 請求額が想定を超えているものの、クレジットの超過がどのユーザーで起きているのかを特定できず、プランの見直しが必要かどうかも判断できない
• 契約したのにほとんど使っていないユーザーがいるはずだが、特定できずコストが無駄になっている可能性がある

裏を返せば、ユーザー単位で利用状況とコストが見えるようになれば、これらの問題は解消します。

2. Kiro の利用状況とコストを記録する 2 つの情報源

Kiro の利用状況とコストは、2 つの異なる情報源に記録されます。それぞれで見ている対象が異なるため、両方を知っておくことで使い分けが可能になります。

• Kiro User Activity Report：Kiro が出力する日次のレポート。ユーザーごとの利用実態を記録します。
• AWS Cost and Usage Reports (CUR) 2.0：AWS の請求・使用状況データ。請求の観点から Kiro のサブスクリプションごとの月額料金と超過料金を記録します。

まず、Kiro が何を単位として利用を記録するのかを押さえておきます。

2.1. 識別の単位：ID プロバイダーとサブスクリプション

Kiro の利用状況は、組織の ID プロバイダーで管理されるユーザー単位で識別されます。Kiro は AWS IAM Identity Center 経由、および Okta / Microsoft Entra ID の直接接続のどちらにも対応しています (注)。組織で Kiro を導入する場合、管理者が ID プロバイダー上のメンバー (またはグループ) を Kiro にサブスクライブし、プランを割り当てます。こうしてサブスクライブされたユーザーを Kiro enterprise user と呼びます。

注：本記事では、Kiro の ID プロバイダーとして IAM Identity Center を使う構成を前提としています。

一方、請求の側ではサブスクリプションを AWS アカウントごとに数えます。Kiro の管理単位である「プロファイル」は「AWS アカウント × リージョン」ごとに作成されるため、サブスクライブを管理アカウントだけで行うとは限りません (“Deployment options” を参照)。

例えば部署ごとに別のアカウントで Kiro を導入している場合、異動や兼務で同じ IAM Identity Center ユーザーが 2 つのアカウントでサブスクライブされ、二重に課金されることがあります。この場合、ユーザーとしては 1 人でも、サブスクリプションとしては 2 件になります。そして実際に使っているのが片方だけなら、もう片方は無駄なコストになります。

2.2. Kiro User Activity Report：ユーザー単位の利用実態

Kiro User Activity Report は、ユーザーごとの利用実態を日次で記録したレポートです。Kiro の設定で有効化します。

出力形式は CSV ファイルを Amazon S3 バケットに出力する方法と OpenTelemetry で送る方法の 2 つがあります。内容は同じで、どちらか一方を有効にすることも、両方有効にすることもできます。本記事では CSV を前提に説明します。

主な内容は以下の通りです (カッコ内は実際のカラム名)：

• ユーザーの識別情報 (UserId, User_Email)
• ユーザーに割り当てられたプラン (Subscription_Tier)
• クライアントタイプ (Client_Type)　… Kiro IDE、Kiro CLI、IDE プラグインなど、どこから使ったか
• クレジットの消費と超過 (Credits_Used, Overage_Credits_Used, Overage_Cap)　… 消費したクレジット、プランの枠を超えて消費したクレジット、超過できるクレジットの上限値
• メッセージや対話の数 (Total_Messages, Chat_Conversations)
• モデル別の内訳　… 使ったモデルごとのメッセージ数 (auto_messages, claude_opus_4.5_messages など、利用したモデルに応じたカラム)

CSV ファイルは「KIRO_CLI_<accountId>_user_report_202609030000.csv」のように日付とクライアントタイプごとに分かれて出力されます。内容はおおよそ以下のようなイメージです (値はサンプル)：

ここで押さえておきたい Kiro User Activity Report の特性が 1 つあります。このレポートには、実際に Kiro を使ったユーザーの行しか含まれません。その日に Kiro を使わなかったユーザーの行は出力されず、サブスクライブしたまま一度も使っていないユーザーは、そもそもここには現れません。この点が、次に説明する CUR 2.0 との大きな違いのひとつになっています。

2.3. CUR 2.0：請求から見たサブスクリプションとコスト

CUR 2.0 は、AWS アカウントごとのコストと使用状況を明細項目 (line item) レベルで記録したレポートです。AWS Data Exports で設定することで S3 バケットに出力されます。

CUR 2.0 には、Kiro のサブスクリプションが請求の明細として記録されます。サブスクリプションは line_item_resource_id に IAM Identity Center ユーザーの ARN (例：arn:aws:identitystore:::user/<uuid>) として現れます。

Kiro の明細は、pricing_unit の値で 2 種類に分かれます (カラム名の詳細は CUR 2.0 のテーブルディクショナリを参照してください)。

どちらの明細も、数量は line_item_usage_amount、金額は line_item_unblended_cost のそれぞれのカラムに記録されます。

なお、Kiro User Activity Report を有効化していなくても、「誰がどれだけクレジットを使ったか」は CUR 2.0 だけでも把握することができます。利用がプランの枠内に収まっている場合は追加料金が発生しないため line_item_unblended_cost は 0 になりますが、消費した量そのものは line_item_usage_amount に記録されるためです。

Credits の明細は、単価の異なる 2 種類に分類されます。line_item_line_item_description カラムには、プランの枠内で消費した分は $0.00 per Credit for KiroEnterprise-Credits in US East (N. Virginia)、枠を超えた分は $0.04 per Credit for KiroEnterprise-Credits in US East (N. Virginia) のように記録されます (3.1. のクエリ結果を参照)。どちらも同じ使用タイプなので、line_item_usage_amount を合計すると消費したクレジットの総量、line_item_unblended_cost を合計すると超過料金になります。

そしてプランの月額料金は、クレジットを消費していない月でも記録されます。サブスクライブしている限り料金は発生するためです。この 2 種類の明細を組み合わせると、次の判定が可能です。

• プランの月額料金 (Count) の明細があり、クレジット (Credits) の明細もある　→ そのサブスクリプションはその月に使われている
• プランの月額料金 (Count) の明細はあるが、クレジット (Credits) の明細がない (または消費量が 0)　→ 課金されているのに使われていない

後者が、サブスクリプションの見直しの対象になります (注)。

注：ここでいう「使われていない」は、Kiro コンソールに表示されるサブスクリプションのステータス (Active / Pending / Canceled) とは別の観点です。Pending は「サブスクライブされたが、まだ有効化されていない」状態を指し、課金は発生しません。ここで問題にしているのは「課金が発生している (Active) のに、その期間は使われていない」サブスクリプションです。

2.4. 2 つの情報源の違い

Kiro User Activity Report と CUR 2.0 を整理すると、次のようになります。

注：プランと超過クレジット数から金額を推定することは原理的に可能ですが、価格表が必要で、また月途中の加入による日割りや未使用のサブスクリプションには対応できません。そのため、金額は CUR 2.0 から取るのが確実です。

また、両者は母集団が異なります。前者は「使ったユーザー」、後者は「課金対象のサブスクリプション」を数えているため、数が一致しないことがあります。どちらかが間違っているのではなく、見ているものが違うということです。

なお、Builder ID による個人利用は AWS アカウントに課金されないため、どちらの情報源にも現れません (認証方式ごとの支払い方法の違いはこちらのブログが詳しく解説しています)。

3. CUR 2.0 を Athena で分析する

2 つの情報源のうち、CUR 2.0 は Amazon Athena に接続していればすぐに SQL で分析できます。既に CUR 2.0 が有効になっている組織では追加の準備なしに始められることが多いはずです。

以下のクエリでは、<your_cur_table_name> を実際の CUR 2.0 テーブル名 (例：cid_data_export.cur2) に置き換えてください。billing_period は対象の請求月です。

注：対象期間は暦月単位で指定してください。クレジット枠は請求月の開始時にリセットされ、繰り越されません。プランの月額料金も暦月単位で計上されるため、「9 月 20 日まで」のように月の途中で切ると、料金の明細がまだ計上されていないサブスクリプションが漏れて数や金額が実際より少なく出ます。また CUR のデータは請求が確定するまで更新が続くので、分析は完了した月を対象にするのが確実です。

3.1. プラン料金とクレジット消費の全体像

まず Kiro の明細がどう構成されているかを確認します。

SELECT
    line_item_usage_type,
    pricing_unit,
    line_item_line_item_description AS description,
    SUM(line_item_usage_amount)   AS usage_amount,
    SUM(line_item_unblended_cost) AS cost
FROM <your_cur_table_name>
WHERE billing_period = '2026-09'
  AND line_item_product_code = 'Kiro'
GROUP BY 1, 2, 3
ORDER BY 1;

出力例

Count の行にプランごとの月額料金が、Credits の行にクレジットの消費が現れます。後者は cost が 0 でも usage_amount に消費量が記録されていることが確認できます。この例では超過が発生しているため、Credits の行は description が $0.00 per Credit for ... の行と $0.04 per Credit for ... の行の 2 つに分かれています。

3.2. サブスクリプションごとのクレジット消費量と料金

次に、サブスクリプション単位で「いくら払って、どれだけ使ったか」を確認します。

SELECT
    line_item_usage_account_id AS account_id,
    line_item_resource_id      AS subscription,
    MAX(CASE WHEN pricing_unit <> 'Credits'
             THEN line_item_usage_type END)            AS plan,
    SUM(CASE WHEN pricing_unit <> 'Credits'
             THEN line_item_unblended_cost ELSE 0 END) AS plan_fee,
    SUM(CASE WHEN pricing_unit = 'Credits'
             THEN line_item_unblended_cost ELSE 0 END) AS overage_fee,
    SUM(CASE WHEN pricing_unit = 'Credits'
             THEN line_item_usage_amount ELSE 0 END)   AS credits_used
FROM <your_cur_table_name>
WHERE billing_period = '2026-09'
  AND line_item_product_code = 'Kiro'
  AND line_item_resource_id <> ''
GROUP BY 1, 2
ORDER BY credits_used DESC;

出力例

クレジット消費量の多い順に並ぶので、ヘビーユーザーの特定ができます。冒頭に挙げた 1 つめの困りごと (利用状況の把握) への答えです。

overage_fee に金額が入っているサブスクリプションは、プランの枠を超えて使っています。この例では 1 行目の Pro プランのユーザーが 1,011.75 クレジットを消費し、枠の 1,000 を超えた 11.75 クレジット分の $0.47 が超過料金として発生しています。冒頭の 2 つめの困りごと (利用超過ユーザーの把握) への答えです。

credits_used をプランに含まれるクレジット数と比べれば、プランが利用実態に見合っているかも判断できます。枠のごく一部しか使っていないなら下位プラン、超過が続いているなら上位プランの検討材料になります。例えば Pro ($20 / 1,000 クレジット) と Pro+ ($40 / 2,000 クレジット) の差額 $20 は、超過 500 クレジット分に相当します。毎月それ以上超過しているならば、プランを上げた方が安くなります。

plan は使用タイプをそのまま表示しています。plan_fee からも推測できますが、料金は変わり得るため明示しておくと確実です。なお、月の途中でプランを変更した場合は、その月に 2 つの使用タイプが現れます。

3.3. 課金されているが使われていないサブスクリプションを見つける

冒頭の 3 つめの困りごと (無駄なコストの把握) に答えるクエリです。

SELECT
    line_item_usage_account_id AS account_id,
    line_item_resource_id      AS subscription,
    SUM(CASE WHEN pricing_unit <> 'Credits'
             THEN line_item_unblended_cost ELSE 0 END) AS wasted_fee
FROM <your_cur_table_name>
WHERE billing_period = '2026-09'
  AND line_item_product_code = 'Kiro'
  AND line_item_resource_id <> ''
GROUP BY 1, 2
HAVING SUM(CASE WHEN pricing_unit = 'Credits'
                THEN line_item_usage_amount ELSE 0 END) = 0
   AND SUM(CASE WHEN pricing_unit <> 'Credits'
                THEN line_item_unblended_cost ELSE 0 END) > 0
ORDER BY wasted_fee DESC;

出力例

「プラン料金は発生しているが、クレジットを 1 つも消費していない」サブスクリプションが、金額の多い順に並びます。この例では Pro プランの 1 か月分がそのまま無駄になっています。これが見直しの候補です。

該当するものがなければクエリ結果は空になります。その月に課金されているすべてのユーザーが Kiro を使っていた、ということです。

3.4. Kiro User Activity Report を Athena で分析する場合

もう 1 つの情報源である Kiro User Activity Report も、CUR 2.0 と同じように Athena で分析できます。S3 に出力されたファイルを AWS Glue でテーブル化すれば、CUR 2.0 では取れないユーザーごとのメッセージ数、モデル別やクライアントタイプ別の内訳を SQL で集計できます。

ただし、すぐに SQL を実行できる状態になるわけではありません。CUR 2.0 は Athena 連携用の AWS CloudFormation テンプレートが用意されていますが、Kiro User Activity Report にはそうした仕組みが (2026 年 10 月時点では) 提供されておらず、日々出力されるファイルの収集とテーブル定義を自分で用意することになります。Part 2 では、この部分も含めて可視化する方法を紹介しています。

4. Kiro 使用状況ダッシュボード：追加のデプロイなしで見る

ここまでは情報源とその取り出し方を見てきました。一方、何もデプロイせずに概況を見る手段もあります。Kiro コンソールに組み込まれた Kiro 使用状況ダッシュボードです。

Kiro の設定で「Kiro 使用状況ダッシュボード」を有効化すると、Kiro コンソールから以下の情報を確認できます。

• サブスクリプション数：保留中 / アクティブ / 合計 (それぞれプラン別の内訳も確認可能)
• 消費されたクレジット：クライアントタイプ別とプラン別の推移
• アクティブユーザー数：クライアントタイプ別とプラン別の推移

グラフは日次・週次・月次を切り替えられます。また、画面上部にはプロファイル名や IAM Identity Center のリージョンといった設定に加えて、クレジット超過が有効になっているかどうかも表示されます。

図 1: Kiro 使用状況ダッシュボード

メトリクスは概ね 1 時間ごとに更新されます (アクティブユーザーのウィジェットのみ日次)。鮮度という点では Kiro User Activity Report や CUR 2.0 よりも高いと言えます。

一方で、誰がどれだけ使ったかというユーザー単位の内訳や、モデル別の利用状況は表示されません。また、表示されるのは基本的に現在サインインしている AWS アカウントの情報です。例外は管理アカウントでサインインし、設定で「メンバーアカウントのサブスクリプション」を有効にしている場合で、このときはサブスクリプションの合計数にメンバーアカウントの分も含まれます。

このことから、まず全体の傾向をつかむには、手軽に利用可能な Kiro 使用状況ダッシュボードが適していると言えます。一方、ユーザー単位まで詳細な分析が必要な場合は Kiro User Activity Report や CUR 2.0 を使うことになります。

5. まとめ

Part 1 では、Kiro の利用とコストがどこに記録され、どう取り出せるのかを見てきました。

• Kiro の利用は ID プロバイダーのユーザー単位で識別され、請求は AWS アカウントのサブスクリプション単位で計上されます。
• 情報源は 2 つあります。Kiro User Activity Report はユーザーごとの利用実態 (メッセージ数、モデル別、クライアントタイプ別) を、CUR 2.0 は請求の観点からサブスクリプションごとの月額料金と超過料金を記録します。クレジット消費量は両方から取得できます。
• CUR 2.0 を Athena で分析すれば、ヘビーユーザーの特定や、課金されているのに使われていないサブスクリプションの洗い出しができます。

ただし、これらの 2 つの情報源はいずれも、そのままでは継続的に複数アカウントを横断して眺めたいという要求には応えられません。Kiro User Activity Report では CSV や OpenTelemetry の出力を確認する必要がありますし、CUR 2.0 では Athena でクエリを実行する必要があります。そこで Part 2 では、CUR 2.0 と Kiro User Activity Report をダッシュボードとして可視化するための 2 つの方法を紹介します。

著者について