この記事は、Finatext Advent Calendar 2025 の9日目の記事です。
はじめに
こんにちは、Finatextのインシュアテック事業でエンジニアをしている岸です。
今回は2025年11月にAWSから発表された Kiro CLI を実際に使用してみたユースケースをご紹介します。
Kiro CLIとは？
Amazon Q Developer CLIと呼ばれていたAIエージェントがKiroというブランドに統合されたツールとなります。
Kiro CLI は Amazon Q Developer CLI の高度なエージェント機能（エージェントモード、MCP、ステアリング、カスタムエージェントを含む）をベースに、ソーシャルログイン、Haiku 4.5、そしてパフォーマンス、効率性、出力品質のバランスを自動調整する Auto エージェントを追加したツールです。プロジェクトの構築、本番環境の問題のデバッグ、インフラコードの作成など、すべてシェルを離れることなく行えます。必要なことを自然言語で説明するだけです。
https://aws.amazon.com/jp/blogs/news/introducing-kiro-cli/
Kiro CLIのユースケース
AWSをお使いの皆さんは、普段自分たちがAWS上で構築・管理しているアプリケーションのトラブルが起きたときはどうやって調査していますか？だいたい以下のような流れで問題を特定してこれらの実際の修正をしていくことになるでしょう。
- AWSコンソール or
awsコマンドで設定やログの調査 - TerraformなどのIaCコード上での設定調査
- アプリケーションコード、Dockerfileなどの調査
トラブルの原因がすぐに思い浮かんでも、その裏付け調査などを地道に行うとなると、それなりの時間と手間を取られることになることはご存知の通りのところかと思います。
また、エビデンス取得やレポーティング用の情報整理なども必要になります。
- DEV/STG/PROD環境での動作確認
- 経緯調査、場合によっては障害報告
このうち、AWS環境上の調査を中心として、その周辺のIaCコードやインフラコードまでKiro CLIが取り扱う対象とすれば、サクサクっと調査を行い、コンテキストに追加した様々なリポジトリのGitログから経緯調査なども包括的に行うことができそうです！
具体的な発生事象
実際に私が遭遇したトラブルとして、バッチアプリケーションから数十万件のデータを月次でDynamoDBに投入する処理において、数十件の登録漏れが発生していることが発覚しました。
アプリケーションが出力したログや、DynamoDB上のメトリクス、存在していればDynamoDB上のエラーログなどから登録漏れの原因を特定する必要がありました。
Kiro CLIを使用した調査方法
私は以下のようにSerena、GitHub、Kibela、BacklogなどのMCPをセットアップして、コードリーディングや背景情報へのアクセスをスムーズにできるようにしています。
$ kiro-cli
✓ github loaded in 1.33 s
✓ backlog loaded in 3.73 s
⚠ 2 of 5 mcp servers initialized. Servers still loading:
- serena
- kibela
⠀⠀⠀⠀⠀⠀⠀
AAはこんなかんじ
まずは依頼
> # 依頼内容
DynamoDBへの登録処理において、約XX万件のうちXX件程度が欠損してしまっていた。
その原因について調査してほしい
- AWS Profile: ${AWSプロファイル名}
- 日時: 2025-12-03 10:00-12:30(JST)頃
- バッチ:
- アプリケーションコード: ${パス}
- Terraform: '${バッチ名}'
- Terraformリポジトリ: ${パス}
- アプリケーションコードのリポジトリ: ${パス}
早速コードの確認から入ります
> DynamoDBへの登録でXX件程度の欠損が発生したとのこと、調査していくね。
まず状況を整理させて。バッチ処理で約XX万件をDynamoDBに登録する際に、XX件程度が欠損したということだね。
最初にバッチのコードを確認させて。
Reading file: ${パス}, all lines (using tool: read)
✓ Successfully read 3566 bytes from ${パス}
- Completed in 0.0s
> DynamoDBへの登録処理は b.hogehogeRepository.BulkCreate(hogehoge) で行われているね。この実装を見てみよう。
Reading directory: ${パス} (using tool: read, max depth: 0)
✓ Successfully read directory ${パス} (2 entries)
- Completed in 0.0s
Reading file: ${パス} all lines (using tool: read)
✓ Successfully read 6235 bytes from ${パス}
- Completed in 0.0s
> コードを見たところ、callBatchWriteItemForPut 関数でDynamoDBの BatchWriteItem を呼び出しているね。
気になる点がある。BatchWriteItem のレスポンスには UnprocessedItems というフィールドがあって、スループット制限などで処理できなかったアイテムが返されるんだけど、このコードではそれを確認していない。
いきなり核心に迫る勢いですが、会話の雰囲気を見ていただくため、実際行われた会話よりもスムーズに解決するプロンプトも別途仕込んでおります、ご容赦ください😅
次に、AWSリソースの確認に入りますが、最初のプロンプトで渡したプロファイル名を元に、 ~/.aws/config を読み取って、MFAなどのハンドリングもよしなに行ってAWSにアクセスしてくれます。
実際のレスポンスを確認してみよう。該当時刻のCloudWatch Logsを見てみる。
Running aws cli command (using tool: aws):
Service name: logs
Operation name: filter-log-events
Parameters:
- start-time: 1764723600000
- end-time: 1764732600000
- limit: 100
- log-group-name: "${ロググループ名}"
Profile name: ${AWSプロファイル名}
Region: ap-northeast-1
Label: Search for hogehoge batch logs on 2025-12-03 - Completed in 1.668s
> 良いログが取れた。HogeHogeBatchが実行されていて、XX万件のレコードを処理しているね。
(中略)
> そうだね、BatchWriteItem のレスポンスには UnprocessedItems フィールドがあって、処理できなかったアイテムが返される。
コードを見ると:
go
_, err := svc.BatchWriteItem(context.Background(), input)
レスポンスを _ で捨ててしまっている。これが問題だ。
以下のような形式の箇所がKiro CLIが実際にAWSコマンドを駆使してくれている箇所です。人間よろしくKiro CLIも引数やサブコマンドを何度か間違えたりもするのですが、ここの試行錯誤が自動で行われるのがめちゃめちゃ便利です!!
Service name: logs
Operation name: filter-log-events
Parameters:
- start-time: 1764723600000
- end-time: 1764732600000
- limit: 100
- log-group-name: "${ロググループ名}"
Profile name: ${AWSプロファイル名}
Region: ap-northeast-1
「スループット制限」と言っている箇所の裏付けも、自然言語でお願いしてみました。
> DynamoDBのメトリクスとか見た？
> ああ、そうだね。実際にスループット制限が発生していたか確認しよう。
Running aws cli command (using tool: aws):
Service name: cloudwatch
Operation name: get-metric-statistics
Parameters:
- metric-name: "UserErrors"
- dimensions: "Name=TableName,Value=HogeHoge"
- start-time: "2025-12-03T01:00:00Z"
- end-time: "2025-12-03T02:30:00Z"
- period: 300
- namespace: "AWS/DynamoDB"
- statistics: "Sum"
Profile name: ${AWSプロファイル名}
Region: ap-northeast-1
Label: Get DynamoDB throttled requests metrics - Completed in 0.977s
Running aws cli command (using tool: aws):
Service name: cloudwatch
Operation name: get-metric-statistics
Parameters:
- statistics: "Sum"
- metric-name: "WriteThrottleEvents"
- namespace: "AWS/DynamoDB"
- dimensions: "Name=TableName,Value=HogeHoge"
- end-time: "2025-12-03T02:30:00Z"
- period: 300
- start-time: "2025-12-03T01:00:00Z"
Profile name: ${AWSプロファイル名}
Region: ap-northeast-1
Label: Get DynamoDB write throttle events - Completed in 1.32s
> スループット制限が起きるのはなぜ？もっとスムーズに投入できないの？
> DynamoDBのキャパシティ設定を確認してみよう。
Running aws cli command (using tool: aws):
Service name: dynamodb
Operation name: describe-table
Parameters:
- table-name: "HogeHoge"
Profile name: ${AWSプロファイル名}
Region: ap-northeast-1
Label: Get HogeHoge table configuration - Completed in 1.861s
> 問題が見えた。WriteCapacityUnits: 5 しかない。これは秒間5回の書き込みしかできないということ。
XX万件を処理するのに、X件ずつバッチで送ってもXXリクエスト必要。秒間Xリクエストだと約X時間かかる計算だけ
ど、実際にはもっと速く送ろうとしてスロットルが発生している。
しかも、LastIncreaseDateTime: 2025-12-03T10:18:47 と LastDecreaseDateTime: 2025-12-03T12:01:42 を見ると、バッチ実行中に一時的にキャパシティを上げて、終わったら下げているね。
根本的な解決策は:
1. オンデマンドモードに変更: スループットを自動でスケールさせる
2. プロビジョニングキャパシティを上げる: バッチ実行時は高めに設定
3. Auto Scalingを設定: 負荷に応じて自動調整
現状は手動でキャパシティを上げ下げしているけど、タイミングが合わなかったり、上げ幅が足りなかったりでスロット
ルが発生している。月1回のバッチなら、実行前に十分なキャパシティを確保するか、オンデマンドモードにするのが良
さそう。
アドバイスから得られた方針を元に、コードの修正自体は会話ログをエクスポートしてClaude Codeに引き渡したりしましたが、実際に提案方法を実施したところ、スロットリングが減って内部的なエラーやリトライがゼロになり、バッチの実行時間が約45%短縮する効果が得られました✨
AWS調査におけるKiro CLIの優位性
Claude CLIやGitHub Copilot CLIなど、他のAI支援ツールも試しましたが、AWS環境との統合度でKiroが圧倒的に優位でした：
- AWS公式ツール: 認証周りが完全統合
- インフラ調査特化: CloudWatch Logs Insightsクエリ自動生成など
- MFA自動対応: セッション管理も自動
汎用AI CLIは開発タスク全般に強いですが、AWS特有の調査にはKiro CLIが優秀でした。
Kiro CLIは自動的に：
- 最初のコマンドを試行
- エラーを検知
- 代替コマンドを自動生成
- 成功するまでリトライ
基本的にはすべて自動で、ユーザーは待つだけ。
数字で見る効率化
今回の調査で実際に記録された数値：
| 項目 | 従来手法（推定） | Kiro CLI（実測） |
|---|---|---|
| 調査所要時間 | 60-90分 | 約13分 |
| コード確認 | 手動でファイル検索・読み込み | 3ファイル自動読み込み |
| AWS API呼び出し | 手動で試行錯誤 | 2回（自動リトライ含む） |
| 原因特定までのステップ | 10-15ステップ | 6ステップ |
| 手動エラー修正 | 5-10回 | 0回（自動修正） |
調査フロー
- 開始 - 調査開始「DynamoDB登録でXX件欠損、原因調査して」
-
+1分 - バッチコード確認完了
- ${パス}（約7秒）
-
dynamodb/${パス}.go（約3秒）
-
+1.5分 - 問題箇所特定
-
BatchWriteItemのレスポンスUnprocessedItemsを無視している
-
-
+2分 - CloudWatch Logs検索
- ロググループ一覧取得（約4秒）
- 該当時刻のログフィルタ（最初は2025年で失敗、約4秒）
-
+3分 - タイムスタンプ自動修正
- 「2025年はまだ来ていない」と自動検知
- 2024年に修正して再検索（約5秒）
-
+4分〜+13分 - ログ分析とDynamoDBテーブル設定確認
-
ProvisionedThroughputExceededExceptionの頻発を確認 - WriteCapacityUnits: 5 の低設定を発見
- 根本原因と修正方針の提示
-
合計: 約13分
従来の手法なら：
- コード確認（15-20分）
- CloudWatch Logs検索（10-15分、エラー修正含む）
- DynamoDB設定確認（10-15分）
- 原因特定と修正方針検討（20-30分）
で、最低でも1-1.5時間はかかっていたでしょう（とのことです by 生成AI）
もちろん、日頃からシステムと向き合って勘所などがあれば人力でもKiro CLIに肉薄するかもしれませんが、たとえ0ベースの理解のシステムでも一部の領域だけではなくシステム全体を把握したうえでトラブルと向き合ってくれるAIがいるのは非常に心強いですね💪
まとめ
Kiro CLIによる効率化のポイント
- 認証の完全自動化: MFA含めて一切手動操作不要
- 試行錯誤の削減: エラー時の自動リトライで手動修正0回
- コンテキスト保持: 調査の流れを理解して適切なコマンドを実行
- 専門的な調査: CloudWatch Logs Insightsなど高度な機能も自然言語で利用可能
生産性向上の実感
- 調査時間: 90-120分 → 13分
- ストレス: コマンドエラーとの格闘 → 対話的な調査
- 品質: 手動ミスのリスク → 自動化による正確性
今後の活用シーン
Kiro CLIは以下のような場面で特に有効だと感じました：
- 障害調査: CloudWatch Logsの検索、メトリクス確認
- リソース確認: ECS、RDS、Lambda, DynamoDB等の設定確認
- Terraform管理: コードの確認と変更の影響範囲調査
- セキュリティ監査: IAM権限、セキュリティグループの確認
インフラエンジニアにとって、Kiro CLIは単なる「便利ツール」ではなく、調査の質と速度を根本的に変えるツールだと実感しました。
AWS環境での調査・運用業務に携わる方は、ぜひ一度試してみることをお勧めします。
FinatextではAWSを使い倒して保険SaaSを一緒に作ってくれるエンジニアを大募集中です！
カジュアル面談も絶賛募集中です！
Discussion