developersIO
Kiro CLI無双。自身の利用ログ解析中に発見した異常値を調査、AWSサポート起票までやりきった話

Kiro CLI無双。自身の利用ログ解析中に発見した異常値を調査、AWSサポート起票までやりきった話

Kiroの利用ログで見つけた異常値の調査からAWSサポートケースの起票まで、Kiro CLIを使ってどこまで自動化できるか検証しました。AIによるS3ログ分析の実践から、Support APIを用いたチケット作成、boto3の落とし穴（エラー回避）まで具体的なノウハウをまとめています。
FacebookHatena blogX
2026.02.24

AWSの生成AIコーディングアシスタント「Kiro」のEnterprise向け機能として、2026年2月にユーザーアクティビティレポートが追加されました。S3バケットに user_report というプレフィックスで日次出力されるため、本記事では user_report ログと表記します。

筆者もKiro CLIを使ってこの user_report ログを分析していたところ、初日（2/10）のデータに不審な点を見つけました。

本記事では、Kiro CLIでのログ分析中にこの不審な点を発見し、Kiroからの提案をきっかけにAWSサポートケースの起票・クローズまで行った経緯を紹介します。

経緯

Kiro CLIで user_report ログの分析を進めていました。月別のクレジット消費量からチームに適切なKiroプランを検討したり、未使用ユーザーの棚卸しを行うのが本来の目的でした。

user_report には、ユーザーごとの Credits_Used（その日に消費したサブスクリプションプランのクレジット数）と Total_Messages（ユーザーのプロンプト、ツール呼び出し、Kiroの応答を含むメッセージ数）が記録されています。この2つの比率（credits/message）を見ると、通常 0.2〜0.5 程度のところ、2/10だけ 96〜105 と約200倍の値を示していました。

社内で該当ユーザーにKiroクライアントの /usage コマンドで実際のクレジット消費量を確認してもらったところ、user_report の値と大きく乖離していることがわかりました。

データソース ユーザーA（2月累計） ユーザーB（2月累計）
/usage（クライアント側） 165 credits 841 credits
user_report 2/10のみ 7,883 credits 1,353 credits

いずれも2月全体の /usage 実績が、2/10の1日分の user_report を下回っています。

Kiroにこの異常値について意見を求めたところ、AWSサービス側に起因する可能性が高く、サポートへの問い合わせが適切と判断。これを受けて、サポートケースを起票することにしました。

Kiro CLIでの調査と起票文作成

認証情報の設計

Kiro CLIにAWSリソースの調査を依頼する際、AWS SSOログイン（aws sso login）で強い権限を渡すこともできますが、今回は読み取り専用の一時認証情報を使用しました。最小権限の原則に従い、調査に必要な権限のみを付与するためです。

aws sts assume-role \
  --role-arn arn:aws:iam::XXXX:role/ReadOnlyRole \
  --role-session-name kiro-log-investigation

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...
kiro-cli chat

S3読み取りのみの権限で、誤操作でもデータ削除は不可能です。セッション名を指定しているため、CloudTrailからの監査も可能です。

認証情報の設計については、次の記事でも詳しく解説しています。

https://dev.classmethod.jp/articles/kiro-cli-custom-agent-sudo/

Kiroとの対話

Kiro CLIを起動し、user_report ログからユーザーごとのクレジット消費状況を分析してもらいました。

ユーザー: S3バケット s3://kiro-logs-XXXX/user_report/ のログを分析して。
         ユーザーごとのクレジット消費量を集計して、
         上位プランへの切替が必要なユーザーがいるか確認して。

Kiro: [S3からログを取得、分析...]

      分析の過程で、初日（2/10）のデータに不審な点を発見しました：
      - credits/message比率が 96〜105（通常は 0.2〜0.5）
      - プロンプトログの記録と突き合わせると、記録以上のクレジットが消費されている
      - 2/10に記録があるのは2名のみで、両者とも数ヶ月前から継続利用

      ダッシュボードの値とも大きく乖離しています。
      初日データは正常な日次値ではない可能性が高く、
      AWSサポートへの確認をお勧めします。

プロンプトでS3パスと分析目的を明示したことで、Kiroが自律的にログ取得・異常値検出・他データソースとの突合・サポート照会の提案まで進めてくれました。

続けて、調査結果のまとめと起票文の作成を依頼しました。

ユーザー: この調査結果をMarkdownでまとめて。
         概要、状況、調査結果、推定原因の順で構造化して。

Kiro: investigation-summary.mdに保存しました。

ユーザー: サポートケースの起票文を作成して。

Kiro: support-case-draft.mdに保存しました。

生成された起票文は、件名・緊急度・解決したい課題・確認された現象・環境情報が構造化されており、そのままサポートケースに使える品質でした。障害報告ではなく仕様確認というトーンも適切です。

最小権限IAMの実践

起票の実行にあたり、Support API権限を追加した専用のIAMポリシーを作成しました。

KiroInvestigationPolicy（クリックで展開）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "KiroLogAnalysisS3Access",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::aws-service-logs-XXXXXXXXXXXX-us-east-1",
        "arn:aws:s3:::aws-service-logs-XXXXXXXXXXXX-us-east-1/kiro/*"
      ]
    },
    {
      "Sid": "IdentityCenterReadAccess",
      "Effect": "Allow",
      "Action": [
        "identitystore:DescribeUser",
        "identitystore:ListUsers",
        "identitystore:DescribeGroup",
        "identitystore:ListGroupMemberships"
      ],
      "Resource": "*"
    },
    {
      "Sid": "SupportCaseManagement",
      "Effect": "Allow",
      "Action": [
        "support:CreateCase",
        "support:AddCommunicationToCase",
        "support:AddAttachmentsToSet",
        "support:DescribeCases",
        "support:DescribeServices",
        "support:DescribeSeverityLevels"
      ],
      "Resource": "*"
    }
  ]
}

S3はバケットとプレフィックスを限定（kiro/*）、Identity Centerは読み取り系のみ、Support APIは起票に必要な最小限のアクションに絞っています。

サポートケース起票の実行

サービスコードの発見

Kiroのサービスコードを確認します。

aws support describe-services --language ja --region us-east-1

service-kiro というサービスコードと、general-guidance というカテゴリコードが見つかりました。

ケース作成

aws support create-case \
  --subject "Kiro Enterprise user_report 初日データの異常値 - データ仕様の確認" \
  --service-code "service-kiro" \
  --category-code "general-guidance" \
  --communication-body "$(cat support-case-draft-v2.md)" \
  --severity-code "low" \
  --language "ja" \
  --region us-east-1

なお、最初はカテゴリコードに日本語（「一般的なガイダンス」）を指定してValidationExceptionが発生しました。カテゴリコードは英数字とハイフンのみ使用可能です。

添付ファイルのアップロード

CSVファイル2件と画像ファイル1件を添付しました。

# CSVファイルの添付セットを作成
aws support add-attachments-to-set \
  --attachments "data=fileb://user_report_202602100000.csv,fileName=user_report_202602100000.csv" \
  --region us-east-1

# 同じセットに2つ目のCSVを追加（返却されたattachment-set-idを指定）
aws support add-attachments-to-set \
  --attachment-set-id "返却されたID" \
  --attachments "data=fileb://user_report_202602110000.csv,fileName=user_report_202602110000.csv" \
  --region us-east-1

# ケースに添付コメントとして送信
aws support add-communication-to-case \
  --case-id "case-XXXX" \
  --communication-body "添付ファイル: user_report CSVファイル（2/10, 2/11）を添付します。" \
  --attachment-set-id "返却されたID" \
  --region us-east-1

画像ファイル（JPG）のアップロードでは、Kiroが生成したCLIコマンドで Invalid base64 エラーが発生しました。Kiroはすぐにboto3を使った代替スクリプトに切り替え、APIレベルではアップロードに成功しました。

import boto3, base64

with open('kiro_feb_graph.jpg', 'rb') as f:
    file_data = base64.b64encode(f.read()).decode('utf-8')

client = boto3.client('support', region_name='us-east-1')
response = client.add_attachments_to_set(
    attachments=[{'fileName': 'kiro_feb_graph.jpg', 'data': file_data}]
)

エラーが出ても自力でリカバリーしてくれるのはAIエージェントの強みです。

人間によるフォローアップ

Kiroによる起票後、筆者がAWSコンソールからケースの内容を確認しました。boto3でアップロードした画像ファイルがサポートケース上で正しく表示されなかったため、マネジメントコンソールから再送しました。原因はエンコード方式の問題と特定できたため、次回以降はスクリプト側で対処可能です。あわせて、背景・緊急度の補足も行いました。

起票プロセスで学んだこと

  • describe-services で利用可能なサービスコード一覧を取得できる
  • 添付ファイルは先にセットを作成してからケースに関連付ける
  • CSVファイルはAWS Support側で .txt 拡張子が自動付与される
  • boto3の data パラメータにはバイナリをそのまま渡す。base64.b64encode() で明示的にエンコードすると二重エンコードになりファイルが破損する

サポートケースの結果

サポートへの確認を通じて、2/10のデータは異常値として分析対象から除外する判断ができました。

回答を受けた後、裏付けとして /usage 情報もKiro CLIからAWS CLIで追加送信し、ケースをクローズしました。

aws support resolve-case \
  --case-id "case-XXXX" \
  --region us-east-1

まとめ

Kiro CLIを使って、ログの異常値調査からサポートケースの起票・追加エビデンス送信・クローズまでを効率化できました。画像添付のエラーリカバリーや背景の補足など人間の介入が必要な場面もありましたが、大部分の作業をKiro CLIに任せることができています。

AWSサポート側でも、AI機能を活用した新しいサポートプランが発表されており、サポート分野でのAI活用が進んでいます。利用者側もKiroのようなAIエージェントを活用することで、調査・起票の品質と効率を上げていけるのではないでしょうか。

環境による制約について

本記事はAIエージェントサービスの社内評価専用環境で実践しています。本番環境で実施する場合は、組織のセキュリティポリシーとSCP設定を確認してください。

おまけ：Kiro CLIからの画像添付の正しい方法

今回boto3で画像をアップロードした際、サポートケース上で画像が表示されませんでした。原因はboto3の二重エンコードです。

boto3は data にバイナリ（bytes）を渡すと、内部で自動的にBase64エンコードしてAPIに送信します。Kiroが生成したスクリプトでは base64.b64encode() で明示的にエンコードしていたため、二重にエンコードされてファイルが破損していました。

正しくはバイナリをそのまま渡します。

import boto3

with open('kiro_feb_graph.jpg', 'rb') as f:
    file_data = f.read()  # バイナリのまま渡す

client = boto3.client('support', region_name='us-east-1')
response = client.add_attachments_to_set(
    attachments=[{'fileName': 'kiro_feb_graph.jpg', 'data': file_data}]
)

Kiro CLIでサポートケースに画像を添付する際は、このパターンをプロンプトで指示するとスムーズです。

おまけ：カスタムエージェントでの起票文レビュー

Builders Flash記事を参考に、カスタムエージェント support-case-reviewer で起票文のレビューも試しました。

https://aws.amazon.com/jp/builders-flash/202602/genai-support-case-issue-skills/

~/.kiro/agents/support-case-reviewer.json
~/.kiro/prompts/support-case-reviewer.md

今回はKiroの初版の下書きが高品質だったため、大きな修正は不要でした。重要なサポートケースや複雑な調査では、情報の反映漏れや追加ヒアリングによる時間ロスを避けるため、起票前にカスタムエージェントでレビューを実施するのも有効です。

この記事をシェアする

FacebookHatena blogX

関連記事

Kiro CLIをEC2(AmazonLinux 2023)にインストールしてみた
suzuki.ryo
2025.11.18
AIによるAWS操作を安全に。Kiro CLIで作るsudo的なIAM権限昇格
suzuki.ryo
2026.02.23
誤操作でAWS CloudShellで「q」 を押すだけでKiro CLIを使えることを発見しました
小渕ヒューゴ
2026.01.07
Kiro CLIはぶっちゃけどんな場面で使えばいいか考えてみた
せーの
2026.02.19