はじめに
先日IAM Identity Center経由(Enterprise Billing)でProアカウントを有効にしました。
今回はKiroのマネジメントコンソール画面(以降マネコン画面と表記)からできることを試してみた方法の紹介と結果の共有をしたいと思います。
どんな機能があるのか、どんなことができるのか、気になっている方の参考になれば幸いです。
※注意1:この記事の内容は2026年1月現在の情報です。ご注意ください。
※注意2:本記事で紹介する Kiro のマネコン画面による管理機能は、
IAM Identity Center経由で作成したKiroアカウント(公式にはKiro Enterpriseと呼ばれる利用形態)
でのみ利用できます。個人利用のKiroアカウント(Skill Builder ID等)では、本記事で紹介する管理・可視化機能は利用できない点にご注意ください。
対象読者
- マネコン画面上でKiroの設定や使用できる機能が気になっている人
前提
今回使用している環境は以下の通りです。
- AWS Organizations:有効
- IAM Identity Center:有効(リージョン:ap-northeast-1)
- Kiro:us-east-1 を利用
- Kiro Proアカウント:有効
本記事を作成するにあたって、IAM Identity Center経由(Enterprise Billing)でProアカウントを作成した記事を以下に投稿しています。
また、KiroのIDEを使ってゲームを作ってみた記事や、Windows環境でCLIを導入してみた記事をそれぞれ以下に投稿しています。気になる方はぜひ読んでみていただければと思います!
本記事で紹介すること
IAM Identity Center経由でサブスクリプションアカウントを作成した場合にマネコン画面からできること
- プロンプトログをS3に保存する設定方法
- ユーザーアクティビティレポートをS3に保存する設定方法
- マネコン画面のダッシュボードで確認できる情報
マネジメントコンソール画面で利用できる機能
利用できる主な機能は以下です。
- 利用状況の可視化(ダッシュボード)
- ユーザー・グループ管理
- 設定
- 共有設定
- Kiroの設定
- MCP有効設定
- クレジット超過時の使用可否設定
- ダッシュボード有効設定
- プロンプトログの保存設定
- ユーザーアクティビティレポート
今回はダッシュボード、グループの管理(サブスクリプションの管理)、プロンプトログの保存設定、ユーザーアクティビティレポート機能について紹介したいと思います。
プロンプトログ、ユーザーアクティビティレポートの保存設定については有効にする際の手順も記載します。
利用状況(ダッシュボード)
ダッシュボードで確認できる情報
IAM Identity Center経由でサブスクリプションアカウントを作成すると、マネコン画面のダッシュボードで以下の情報を確認できます。
- Kiroの利用状況
- クレジット使用量
- ユーザー・グループ単位の利用傾向
利用状況の確認方法
- マネコン画面で「Kiro」と検索し、リージョンを選択するとトップページが表示されます
- その後、トップページで「設定」ボタンをクリックすると設定画面が表示されます
- 左側のメニュータブを開くと「ダッシュボード」、「ユーザーとグループ」、「設定」の3つが選択できるようになっているので、「ダッシュボード」を選択します
- 有効な状態のアカウント数や設定、使用状況が確認できるダッシュボード画面が表示されます
以下の画像のようにクレジット使用状況の推移、プランタイプ別のクレジット使用状況の推移、クライアントタイプ別のアクティブユーザー、プランタイプ別のサブスクリプション、プラットフォームごとの使用量を確認することができます。
クレジットの使用状況については、マウスオーバーすることで具体的なクレジットの消費量も確認することができます。
期間も指定できるので、指定された期間でいつどのくらいクレジットが消費されたのかであったり、一週間ごとのクレジットの消費量、使用されたアカウント数などを確認することができます。
私はプランをアップグレードした際の挙動が気になったので、画像のようにProからPro+にアップグレードした後にPro+からPowerへアップグレードしてみました。
その結果、上記のようにプランごとに色が異なるグラフになっていることがわかります。
また、複数のユーザーの場合の挙動が気になったので、一つのグループに属しているユーザーを二つ作成しました。
その後、2台の端末を使用してそれぞれ異なるアカウントを使用してIDE,CLIにログインして使用した結果、アカウント数が変化していることがわかります。
そして、一つのユーザーであっても、CLI, IDEごとにカウントされることがわかりました。
また、1台の端末で異なるアカウントを使用してログインし直した場合にアカウント数がカウントされるのかどうかも気になって試したのですが、カウントされるということがわかりました。
つまり、以下のことがわかりました
- プランタイプ別のサブスクリプション数=指定された期間に使用されたサブスクリプションアカウント数であること
- クライアントタイプ別のアクティブユーザー数=指定された期間に使用された該当のアカウント数×クライアントタイプ数であること
続いて、グループの管理画面でプランを変更する方法についてです。
グループの管理
- 設定画面の左側のメニューバーに表示されている「ユーザーとグループ」を選択します
- 「Kiro にチームを追加」という画面が表示されます
- 既存のグループを選択します
- 「プランの変更」ボタンを選択することで、プランの選択を行うことができます
アップグレードした際は、プラン変更後にIDEを表示すると、アップグレードされていることが確認できました。
逆にダウングレードした際の挙動も確認しました。月の途中でダウングレードしたとしても、即時反映はされません。翌月から変更したプランになります。
以下公式ドキュメントに記載
そのため、変更すると下の画像のように現在のプランと来月以降にダウングレードする予定のプランが表示されます。
プロンプトログ
プロンプトログをS3に保存することで、以下が可能になります。
- Kiroの利用状況を後から分析できる
- 組織内での利用傾向を把握できる
- セキュリティ・監査用途でのログ保管
管理者目線だとこれらのメリットが挙げられると思いますが、個人的には、チームで開発する際にどんなことをKiroに聞いたのか、作成した成果物がどのような経緯で作られたのかをチーム内(チーム内で使用しているKiro)に共有できるようになるのではと思っています。
例えば、IAM Identity Centerでグループを作成し、グループの中にAさんというユーザーとBさんというユーザーがいるとします。
それぞれのユーザーがKiroを使用して一つのプロダクトを開発すると何が起きるかというと、競合や認識のずれです。目的が同じであっても、細かいところで認識のずれは起こり得るため、作成した成果物が別物になる。もしくは予め手分けしていたとしてもAさん側とBさん側で重複した実装や、合わせた結果足りない実装が出てくる可能性があります。
そんな時に、このプロンプトログをチーム内で共有することができればどのような経緯で何ができたのかが共有しやすくなります。
本来の用途とは異なるかもしれないですが、そのような使い方ができればチームでの開発がしやすくなるのではないかと思いました。
以下にプロンプトログを有効化する手順を紹介します。
1. S3のバケットを作成する
Kiroは、2026年1月現在の時点では以下のリージョンでのみ動作します。
- us-east-1
- eu-central-1
そのため、ログ保存用のS3バケットも利用しているKiroと同じリージョンで作成する必要があります。
※なお、利用アカウントを作成したIAM Identity Centerのリージョン(ap-northeast-1)は関係ありません。
今回使用したS3バケットの条件は以下です。
- リージョン:us-east-1
- 暗号化:SSE-S3
- プレフィックス例:
kiro-prompt-logs/
また、有効化する際にフォルダも必要なので適当な名称で追加します。
私はs3://YOUR_BUCKET_NAME/prompt-logs/というようにprompt-logsというフォルダを作成しました。
2. バケットポリシー設定
以下のようにAmazon Q Developerの書き込み権限を許可するバケットポリシーを設定する必要があります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowQDeveloperWrite",
"Effect": "Allow",
"Principal": {
"Service": "q.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/prompt-logs/*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "YOUR_ACCOUNT_ID"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:codewhisperer:us-east-1:YOUR_ACCOUNT_ID:*"
}
}
}
]
}
このバケットポリシーが設定できていないと、プロンプトログの有効化を行おうとしても、以下のエラーが出て失敗しました。
Amazon Q Developer プロファイルを更新できませんでした。
Amazon Q doesn't have sufficient permissions to access the provided S3 bucket.
Please verify your S3/KMS permissions and retry.
3. マネジメントコンソールからプロンプトログを有効化する
Kiro の設定画面から「Kiro プロンプトをメタデータとともにログ記録」を有効にし、以下の形式で先ほど作成したS3バケットのURIパスを指定します。
s3://YOUR_BUCKET_NAME/prompt-logs/
正しく設定できると、プロンプトログの保存ができるようになります。
有効化した結果
プロンプトログを有効化すると、S3 には以下のような構造でログが保存されます。
AWSLogs/
└ {ACCOUNT_ID}/
└ KiroLogs/
├ GenerateAssistantResponse/
| └ {Region}/
| └ {year}/{month}/{day}/{ファイル名}.json.gz
|
└ GenerateCompletions/
└ {Region}/
└ {year}/{month}/{day}/{ファイル名}.json.gz
CSV形式で出力されるため、AthenaやGlueを使った分析もできそうでした。
上記のようにyear/month/dayでプレフィックスされて出力されます。
翌日に一括で出力されるのではなく、随時出力されますが、注意が必要なのはUTCのタイムゾーンであるという点です。なので、1/10の午前0時のプロンプトも1/9のフォルダに出力されます。
GenerateAssistantResponseとGenerateCompletionsの違い
先ほどの出力されたファイルの構造にあるように、実際にS3に出力されたプロンプトログを確認すると、KiroLogs 配下には少なくとも以下の2種類が出力されていました。
- GenerateAssistantResponse:チャットや指示入力に対する「アシスタントの応答」
- GenerateCompletions:CLIやエディタ補完の「補完候補(completion)」
それぞれ、json.gz の中身は records 配列になっており、1レコードの中に「リクエスト」と「レスポンス」がまとまって保存されていました。
GenerateCompletionsの中身
GenerateCompletions のログには、以下のような情報が入っていました。
-
generateCompletionsEventRequest-
leftContext/rightContext:補完に使用された前後の文脈(入力途中のテキスト) -
fileName:補完対象のファイル名(例:history.sh) -
userId:ユーザーID -
timeStamp:実行時刻(UTC)
-
-
generateCompletionsEventResponse-
completions:モデルが返した補完候補(配列で複数候補が返っていました) -
requestId:リクエスト識別子
-
GenerateAssistantResponseの中身
GenerateAssistantResponse のログには、以下のような情報が入っていました。
-
generateAssistantResponseEventRequest-
prompt:入力したプロンプト全文 -
chatTriggerType:今回のログではMANUALと記載 -
userId:ユーザーID -
timeStamp:実行時刻(UTC)
-
-
generateAssistantResponseEventResponse-
assistantResponse:生成された回答全文 -
messageMetadata/codeReferenceEvents/supplementaryWebLinksEvent:メタデータ類(今回のファイルでは空のものもありました) -
requestId:リクエスト識別子
-
このように、同じ「プロンプトログ」でも、補完系(Completions)とチャット系(AssistantResponse)で記録される内容が異なります。
特に GenerateAssistantResponse の方はプロンプト本文や回答本文がそのまま入るため、機密情報を含むプロンプトを扱う場合は参照権限の設計に注意が必要だと思いました。
その一方で、どのような用途でKiroが使われているか分析に使えそうだなと思いました。
ユーザーアクティビティレポート
Kiroには「プロンプトログ」とは別に、ユーザーアクティビティレポートという機能があります。
この機能を有効化すると、Kiroの利用状況を集計したレポートがS3に出力され、組織単位での利用状況を後から分析できるようになります。
設定方法
ユーザーアクティビティレポートの設定方法は、プロンプトログの有効化と同一です。
- Kiroが動作しているリージョン(今回はus-east-1)と同じリージョンに S3バケットを作成する
- フォルダを作成する
- S3バケットに適切なバケットポリシーを設定する
プロンプトログを保存しているS3バケットにユーザーアクティビティレポートも出力するように設定することができそうですが、公式ドキュメントによるとバケットを分けることを推奨しているようです。
そこで私は別のバケットを作成し、プロンプトログ同様の流れでバケットの作成、バケットポリシーの設定、フォルダの作成後、有効化を行いました。
有効化した結果
ユーザーアクティビティレポートは以下の構造になります。
AWSLogs/
└ {ACCOUNT_ID}/
└ KiroLogs/
by_user_analytic/
└ {Region}/
└ {year}/{month}/{day}/{hour}/{ファイル名}.csv
ユーザーアクティビティレポートは、個々のプロンプト内容ではなく、Kiroの利用状況を集計したレポートです。こちらは使用されたユーザー毎にCSV形式でS3に出力されます。
また、プロンプトログと異なり、レポートは翌日の9時(JST)以降に出力されます。
例えば、画像のように1/9分のアクティビティは1/10の9時以降に結果が出力されるようになっています。
出力されるユーザーアクティビティレポートの内容
確認できた主な項目は以下の通りです。
- レポート対象期間
- ユーザー(IAM Identity Center ユーザー)
- 実行回数
- 成功 / 失敗の件数
- 利用された機能の種別
プロンプトログと異なり、入力内容そのものは含まれません。そのため、
- 組織全体での利用状況把握
- 部署・チーム単位での利用傾向分析
といった用途に向いていると思われます。
具体的な出力内容については公式ドキュメントに記載されています。
気になる方は以下参照いただけると良いと思います。
このユーザーアクティビティレポートを有効化するにあたりつまずいた点としては、
ユーザーアクティビティレポートを有効化した状態でIDEを使用していても、レポートが出力されなかったという点です。
CLIにログインし、使用した翌日に出力されていました。アクティビティレポートにはIDE, CLI両方の結果が集計されているのでIDEだけを使用しても出力されるはずなのですが、原因は謎です。
また、一台の端末でアカウントを切り替えて使用した際に、一つのアカウントのIDのみ出力されました。その後それぞれの端末で使用した翌日に、二つのアカウントのIDごとに二行ある状態でレポートが出力されました。
その後、IDEだけを使用した場合も出力されるようになっていたので、これが正しい挙動なのか、バグなのかは分かりませんが、もし同様にユーザーアクティビティレポートが出力されないという人は、CLIにログインして実行してみることをおすすめします。
まとめ
本記事では、以下の点を中心にKiro Enterprise Billingの場合のマネコン画面でできることを紹介しました!
- マネコン画面からサブスクリプションの管理・使用状態の可視化機能が使える
- プロンプトログをS3に保存できる
- ユーザーアクティビティレポートをS3に保存できる
関連記事
参考








