【AWS re:Invent2025 ワークショップ体験記】Troubleshooting in the cloud with Kiro CLI (SPS307)

この記事は、Japan AWS Jr. Champions Advent Calendar 2025 シリーズ1・11日目の記事となります。

今回は、AWS re:Invent2025に行ってきたのてで、現地で参加したワークショップ「Troubleshooting in the cloud with Kiro CLI (SPS307)」の体験記を書きました！

セッション概要

このセッションは、AWS re:Invent の中でも「ワークショップ」と呼ばれる形式で、期間限定の AWS 環境を使用して実際にハンズオンを行う内容でした。
会場には 5～6 人ごとにテーブルが配置されており、基本的には一人ひとりが PC を使って作業を進めます。

このセッションは私にとって re:Invent 初日の一番最初に参加したワークショップで、不安もありましたが、日本人の方とテーブルを作ることができ、ハンズオン中に感想を共有したりすることができたため、安心して取り組むことができました。本当にありがとうございました。

ワークショップの内容は、簡単に言うと Kiro CLI を活用して AWS 環境で起きているトラブルの原因解明から解決までを実施する というものです。Kiro CLI はエージェント機能と統合されており、トラブルシューティングに必要な情報を自律的に取得してくれます。

セッションの紹介文は以下になります。

Learn how to troubleshoot large-scale AWS environments through an AI-first approach powered by Kiro CLI. We’ll begin with hands-on experience using Kiro CLI’s custom AI agents and Model Context Protocol (MCP) integration, demonstrating how AI transforms traditional problem-solving through contextual, automated diagnostics. The AI agents are also complemented with essential tools, including log and metrics analysis through Amazon CloudWatch, AWS Config, and AWS X-Ray. Choose your preferred domain- networking, containers, databases, or serverless/DevOps - and work on triaging real-world issues using Agentic AI and the best practices shared during the workshop. You must bring your laptop to participate.

日本語訳はこちらです。（DeepL翻訳を使用）

Kiro CLIを活用したAIファーストアプローチで、大規模AWS環境のトラブルシューティング手法を学びます。Kiro CLIのカスタムAIエージェントとModel Context Protocol（MCP）統合の実践から始め、文脈に応じた自動診断を通じてAIが従来の問題解決をどう変革するかを実演します。AIエージェントは、Amazon CloudWatch、AWS Config、AWS X-Rayによるログ・メトリクス分析など必須ツールと連動します。ネットワーク、コンテナ、データベース、サーバーレス/DevOpsから関心領域を選択し、ワークショップで共有されるベストプラクティスとAgentic AIを活用して実環境の問題をトリアージします。参加にはノートパソコンの持参が必須です。

Kiro CLI

Kiro CLIとは、 2025/11/18 にAmazon Q Developer CLI の後継としてリリースされた、ターミナルからAIと対話ができるコマンドラインツールになります。
「Kiro」はもともとAIエージェント型のIDEですが、Kiro CLIは直接ターミナルで使えるので、より導入しやすいツールになって登場した、ということです。

私が予約したときは、Kiro CLIの部分がAmazon Q Developer CLIだったのですが、リリースされたのちにタイトルが変わっていたので、さっそく新しいツールを使えるのはラッキーでした。

参加のきっかけ

私の所属会社では社内ルールにより Amazon Q Developer を業務で使用できず、AWS ワークショップや Gameday に参加した際に触れる程度の経験しかありませんでした。また、私はインフラエンジニアであるため、生成 AI の活用といえばコーディングなどアプリ開発のイメージが強く、インフラ領域での活用方法がイメージしづらい状況でした。

しかし数か月前、担当している案件のお客様環境で Amazon Q が利用可能となり、IaC の生成や QA を行う中でその便利さを実感しました。インフラ業務においても生成 AI を使いこなせるようになりたいという思いから、このセッションに参加することにしました。

ワークショップ内容

ワークショップでは、事前に AWS 環境に複数のトラブル状態が仕込まれており、Kiro CLI と対話しながら原因調査から修正まで行っていきます。

導入

最初に、Kiro CLI がトラブルシューティングにどのように貢献するのかについて説明がありました。

現代のクラウドアプリケーションは依存関係が複雑で、障害発生時にボトルネックを正確に把握するのが困難です。適切な手法やツールを使わなければ、問題の核心に到達するまでに多くの時間を要します。

クラウド環境で問題を解決するために必要な前提として、以下のスライドのような観点を挙げていました。AWSでは、様々なObservabilityサービスが提供されていますが、これらの観点を総合的に見てトラブルシューティングするには、膨大な時間と人的リソースが必要になってしまいます。

そこで AI を統合することで、問題解決を大幅に迅速化できる という話がありました。

AI の価値として挙げられた点は以下です。

• 膨大なデータを学習したモデルによる推論
• 過去のインシデント・障害レポート・構成情報などの社内データを RAG で統合
• Chain-of-thought による段階的推論
• マルチエージェントによる並行調査
• 自動診断・自動修復などの自動化
  
  そして Kiro CLI には、ファイル操作、Bash 実行、AWS CLI 実行と結果解析、インフラコード補助、コード生成、トラブルシューティング補助などの能力が標準で備わっています。しかし標準機能だけでは複雑なエンタープライズ環境では不十分なケースもあり、カスタムエージェント機能を使うことで特定ユースケースに最適化できる と説明されました。
  
  トラブルシューティング時に、すべきこと、避けるべきことにも言及がありました。
  重要な姿勢として “Trust, but verify” が強調されました。AI に任せる部分は任せつつも、結果を必ず検証することが重要です。特に本番環境での変更は人間の判断が欠かせないと述べていました。
  
  

他にも、AIが見ることのできないところに問題の原因があることもある、そういった場合には従来のトラブルシューティングの手法を組み合わせてアプローチしましょうと、AWSが実際に行っている手法の紹介もありました。

導入の説明が30分ほどあったのち、ハンズオンに関する説明が始まりました。
ハンズオンのコンテンツは以下のように分類されており、それぞれのカテゴリーで6問ずつぐらい課題がありました。1つ1つそれなりに時間がかかるのですべて取り組むのではなく、選んで取り組むように、とアナウンスがありました。

• Network/Web Service
• Serverless/DevOps
• Containers (ECS)
• Containers (EKS)
• Databases

それぞれのコンテンツに対して最適化されたカスタムエージェントが用意されており、取り組む課題に応じて活用することができました。個人的にはカスタムエージェントの設定内容が気になりました。（確認しておけばよかったと後悔しています…）

取り組んだ課題

私はNetworkの1問目と、ECSの1問目を実施できました。

本ブログではNetworkの課題を紹介します。

私が取り組んだ1問目の課題は、以下のように3台のEC2インスタンスで稼働しているとあるWebアプリにアクセスすると、504 Gateway Timeoutになってしまうため、その問題をKiro CLIで調査し修正する、という課題でした。

早速、Kiro CLIにアクセスしてやり取りを始めました。

Kiro CLIとの会話ログ（～原因解明）

[networking-agent] > WebApp-ALBというパブリックのロードバランサーがあります。このロードバランサーには3つのインスタンスが紐づいていますが、ロードバランサーにアクセスすると、504のTimeoutになります。原因を教えてください。

> WebApp-ALBで504 Gateway Timeoutエラーが発生しているとのことですね。調査を開始します。

まず、ALBのメトリクスで504エラーを確認します。
Running tool call_aws with the param (from mcp server: awslabs.aws-api-mcp-server)
 ⋮  {
 ⋮    "cli_command": "aws elbv2 describe-load-balancers --region us-east-1 --query \"LoadBalancers[?contains(LoadBalancerName, 'WebApp-ALB')]\""
 ⋮  }

Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

[networking-agent] > y

 - Completed in 0.213s

> ALBが3つのサブネット(us-east-1a, us-east-1b, us-east-1c)に配置されていることを確認しました。次にVPCフローログで
REJECTされているトラフィックを確認します。
Running tool call_aws with the param (from mcp server: awslabs.aws-api-mcp-server)
 ⋮  {
 ⋮    "cli_command": "aws ec2 describe-flow-logs --region us-east-1 --filter \"Name=resource-id,Values=vpc-0874fe95a0426a51f\""
 ⋮  }

Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

[networking-agent] > y

 - Completed in 0.498s

> フローログでREJECTされているトラフィックを確認します。
Running tool call_aws with the param (from mcp server: awslabs.aws-api-mcp-server)
 ⋮  {
 ⋮    "cli_command": "aws logs filter-log-events --region us-east-1 --log-group-name networking-base-vpc-infrastructure-stack-VPCFlowLogGroup-4z4mrLqvMTyt --filter-pattern \"[version, account, eni, source, destination, srcport, destport, protocol, packets, bytes, start, end, action=REJECT, logstatus]\" --start-time 1733073000000 --max-items 20"
 ⋮  }

Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

[networking-agent] > y

 - Completed in 4.580s

> REJECTされているトラフィックが確認できました。次にALBのサブネットとターゲットグループを確認します。
Running tool call_aws with the param (from mcp server: awslabs.aws-api-mcp-server)
 ⋮  {
 ⋮    "cli_command": "aws elbv2 describe-target-groups --region us-east-1 --query \"TargetGroups[?contains(TargetGroupName, 'WebApp')]\""
 ⋮  }

Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

[networking-agent] > t

 - Completed in 0.133s

> ターゲットグループのターゲットとサブネットを確認します。
Running tool call_aws with the param (from mcp server: awslabs.aws-api-mcp-server)
 ⋮  {
 ⋮    "cli_command": "aws elbv2 describe-target-health --region us-east-1 --target-group-arn arn:aws:elasticloadbalancing:us-east-1:685847343827:targetgroup/WebAppTargetGroup/3978ed51699ced88"
 ⋮  }
 - Completed in 0.114s

> 原因が判明しました。

504 GATEWAY TIMEOUTエラーの根本原因

3つのターゲットインスタンスすべてが「unhealthy」状態になっています。理由は以下の通りです:

STATE: unhealthy
REASON: Target.ResponseCodeMismatch  
DESCRIPTION: Health checks failed with these codes: [299]

問題点:
- ヘルスチェックパス: /healthcheck
- ターゲットグループの設定: HTTP 200のみを正常と判定
- 実際のレスポンス: HTTP 299

ウェブサーバーはヘルスチェックに対してHTTP 299を返していますが、ターゲットグループはHTTP 200のみを正常と判定する設
定になっています。そのため、すべてのターゲットが「unhealthy」と判定され、ALBがリクエストを転送できず504エラーが発生
しています。

修正方法

ターゲットグループのMatcherを更新して、HTTP 299も正常なレスポンスとして受け入れるようにします。この変更により、ター
ゲットが正常と判定され、ALBが正常にトラフィックを転送できるようになります。

修正を実施してもよろしいですか?
 ▸ Credits: 1.24 • Time: 1m 30s

確かに3台とも「unhealthy」になっており、ヘルスチェックの成功コードは200のみが登録されていました。

修正を実行してみました。

Kiro CLIとの会話ログ（修正実行～）

[networking-agent] > 実行してください

> ターゲットグループのMatcherを更新します。
Running tool call_aws with the param (from mcp server: awslabs.aws-api-mcp-server)
 ⋮  {
 ⋮    "cli_command": "aws elbv2 modify-target-group --region us-east-1 --target-group-arn arn:aws:elasticloadbalancing:us-east-1:685847343827:targetgroup/WebAppTargetGroup/3978ed51699ced88 --matcher HttpCode=\"200,299\""
 ⋮  }
 - Completed in 0.85s

Running tool call_aws with the param (from mcp server: awslabs.aws-api-mcp-server)
 ⋮  {
 ⋮    "cli_command": "aws elbv2 modify-target-group --region us-east-1 --target-group-arn arn:aws:elasticloadbalancing:us-east-1:685847343827:targetgroup/WebAppTargetGroup/3978ed51699ced88 --matcher HttpCode=200,299"
 ⋮  }
 - Completed in 0.39s

Running aws cli command (using tool: aws):

Service name: elbv2
Operation name: modify-target-group
Parameters: 
- target-group-arn: "arn:aws:elasticloadbalancing:us-east-1:685847343827:targetgroup/WebAppTargetGroup/3978ed51699ced88"
- matcher: {"HttpCode":"200,299"}
Region: us-east-1
Label: Update target group matcher to accept HTTP 200 and 299
Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

[networking-agent] > y

 - Completed in 0.726s

> 更新が完了しました。ヘルスチェックが実行されるまで60秒待機してから、ターゲットの状態を確認します。
I will run the following command: sleep 60 (using tool: shell)
Purpose: Wait for health checks to run


Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

[networking-agent] > y

 - Completed in 60.4s

Running tool call_aws with the param (from mcp server: awslabs.aws-api-mcp-server)
 ⋮  {
 ⋮    "cli_command": "aws elbv2 describe-target-health --region us-east-1 --target-group-arn arn:aws:elasticloadbalancing:us-east-1:685847343827:targetgroup/WebAppTargetGroup/3978ed51699ced88 --query \"TargetHealthDescriptions[*].[Target.Id,TargetHealth.State]\" --output table"
 ⋮  }
 - Completed in 0.121s

> 修正完了しました!

結果:

ターゲットの状態
- i-0126e19558274074e: healthy
- i-0940ca6a3722d4f5e: healthy  
- i-0d2ea5b66b7e6e46f: healthy

3つのターゲットすべてが正常(healthy)になりました。ALBは正常にトラフィックを転送できるようになり、504エラーは解消さ
れています。

実施した変更:
- ターゲットグループのMatcherをHTTP 200のみからHTTP 200,299に更新
- これによりウェブサーバーが返すHTTP 299レスポンスも正常と判定されるようになりました

今後の推奨事項:
将来的には、ウェブサービス側でヘルスチェックに対してHTTP 200を返すように変更することも検討してください。
 ▸ Credits: 1.12 • Time: 2m 13s

[networking-agent] > 
[networking-agent] > どうやってヘルスチェック299が返ってくることを確認したのですか？

> ターゲットヘルスの詳細情報から確認しました。

最初に実行したこのコマンドの結果で判明しました:

bash
aws elbv2 describe-target-health --region us-east-1 --target-group-arn arn:aws:elasticloadbalancing:us-east-1:685847343827:targetgroup/WebAppTargetGroup/3978ed51699ced88


このコマンドの出力に含まれていた情報:

TargetHealth: {
    "State": "unhealthy",
    "Reason": "Target.ResponseCodeMismatch",
    "Description": "Health checks failed with these codes: [299]"
}


ALBは自動的にヘルスチェックを実行し、ターゲットから返されたHTTPステータスコードを記録します。このDescriptionフィ
ールドに「Health checks failed with these codes: [299]」と明記されていたため、ウェブサーバーがHTTP 299を返している
ことが確認できました。

つまり、ターゲットに直接アクセスしなくても、ALB自身がヘルスチェックの結果として受け取ったステータスコードを教えてく
れていました。
 ▸ Credits: 0.20 • Time: 7s

無事に3台とも「healthy」になりました。

今回は、Webサーバーはヘルスチェックに対してHTTP 299を返しているのに対して、ターゲットグループはHTTP 200のみを正常と判定する設定をしていることで、すべてのターゲットが「unhealthy」と判定され、ALBがリクエストを転送できず504エラーが発生してしまっていた、というシナリオでした。

ログで分かる通り、私は最初に調査を依頼して以降、ただひたすらyを入力するだけでした。笑
ネットワークの問題に対して何を見るべきか、今回でいうとALB周りの設定、VPCフローログ、ヘルスチェックを見ればよい、というのを適切に判断して無駄なくトラブルシューティングをしてくれました。

ただ、本来のあるべき姿としては、Webサーバー側のヘルスチェックの成功コードを299から200に変えるのが妥当だと思います。
今回の修正はあくまで暫定対応であり、こういった問題が発生した際にエラーがなくなったからOK、ではなく、本質的な解決のためには、人間が検討し判断を行う必要がありそうです。

とはいえ、Kiro CLIも以下のように推奨事項として述べているので、あるべき姿についてはきちんと理解できているようにも思います。

今後の推奨事項:
将来的には、ウェブサービス側でヘルスチェックに対してHTTP 200を返すように変更することも検討してください。

ワークショップを通じて感じたこと

すべてのトラブルシュートが、生成AIにとって代わる、という時代はまだ先のことだと思います。しかし、生成AIを活用して効率化していくのが当たり前になってきている時代において、生成AIをそれぞれのユースケースに最適化した形で使うことができるように、Kiro CLIのカスタムエージェントのような設定ができる、というスキルは絶対に必要だと感じました。このあたりの知識が身に付いていないので、勉強したいと強く思いました。

初re:Inventワークショップ後の反省

このワークショップに限らずですが、re:Inventのワークショップはコンテンツの量が多く、結構時間が足りなかったり、やり残した部分もあったりしたので、ワークショップ中にやりきれなかった課題を取り組んだり、ログを残すために、ワークショップ後の時間には余裕を持たせておくと良かったと思いました。