- 公開日
- 最終更新日
【Kiro】AWSサポート主催： Kiro CLI トラブルシューティング Hands-on Report （2025年12月）
この記事を共有する
目次
概要
2025年12月19日に開催したAWSサポート主催の「Kiro CLIトラブルシューティング」について、
当日の様子をレポートとしてまとめました。
※本記事の写真・画像の掲載はAWSサポートから許可をもらっています。
ハンズオンの内容
Kiro CLIを使い、障害が発生しているシステムの原因調査から解決までを体験するワークショップです。
問題解決までのスピードに応じて得点が加算されるゲーム性のある形式でした。
アジェンダ
- Workshop Studio(ハンズオン環境)の使い方
- Kiro CLIの概要及び事前準備
- Kiro CLI を使ったトラブルシューティング
- トラブルシューティング解説
事前準備
- ハンズオン環境の準備は不要
- コミュニケーションツールとして、Webex を事前にインストール
参加者は、事前にハンズオン環境を準備する必要性はありません。
ハンズオン中は、Workshop Studio アカウントを使用しました。
Kiroの設定
本ハンズオンでは、Kiro CLIのインストールから実施を行いました。
こちらに関しては、特殊な手順などがないため割愛とさせていただきます。
また、IAMPolicy設定についてはすでに設定されていたため割愛いたします。
準備の段階ですべきは、以下2点の設定です。
- ステアリングファイルの作成
- Kiro CLIクライアントから、対象EC2へのSSM接続設定
ステアリングファイルの作成
本ハンズオンでは、トラブルシューティング前にステアリングファイルを作成しました。
ステアリングファイルの概要は以下です。
ステアリングは、マークダウンファイルを通じて、ワークスペースに関する継続的な情報をKiroに提供します。チャットごとに規約を説明する代わりに、ステアリングファイルを使用することで、Kiroは確立されたパターン、ライブラリ、標準に一貫して従うことが保証されます。
要するに、ステアリングファイルを設定することによってKiroに禁止項目を伝えることが可能となります。
今回は、以下の内容のステアリングファイルを作成しました。
mkdir -p .kiro/steering/
cat > .kiro/steering/troubleshooting.md << 'EOF'
## Limitation
以下の内容を第一優先で必ず守ってください。
- EC2 上のウェブコンテンツ /var/www/html/ 配下のファイルやディレクトリは削除したり、編集したり変更を加えないでください。
- EC2 上の Apache などの各種設定については明示的に変更を依頼しない限り変更を加えないでください。
- EC2 上のシステムファイル等にも変更や削除、追加など行わないでください。
- AWS リソースに対する変更に関しても変更を行う場合には、必ずユーザーからの許可を得てください
EOF
Kiro CLIクライアントから、対象EC2へのSSM接続設定
本ハンズオンでは、トラブルシューティングをする際に、
事前にEC2へSSMログインするため、EC2のSSHキーを設定しました。
参加者がEC2内に入ってトラブルシューティングしなくても、Kiroによるトラブルシューティングが可能となりました。
Workshop Studio の実際画面
以下の画像が、今回使用したWorkshop Studioの実際の画面となります。
トラブルシューティングの概要
用意されたアーキテクチャ図をもとに、以下のAWSリソースに対して調査を行いました。
- S3
- ALB
- EC2
- RDS
感想・考察・考慮点
ハンズオンを通じてKiroに関して特質すべき点は、以下でした。
1. 日本語で自然に会話できる
Kiroは日本語でのコミュニケーションに問題はありませんでした。 当方からの指示は日本語で行い、応答も日本語で返ってきたため、迅速なやり取りが可能でした。
2. 一行の質問でKiroがアーキテクチャを理解する
Kiroに対して、例として以下のような質問をすると、自発的に問題の切り分けを行ってくれました。
「WEBページ（URL）で、404エラーが発生しています。原因は何ですか？」
このような場合、Kiroは、複数あるAWSリソースの中から該当するAWSリソースを正確に回答します。
つまり、複数のALBやEC2があった場合、どのリソースに関連しているのかをKiro自身で把握します。
これは、運用現場においてとても重要です。
アーキテクチャや大規模なAWSリソースの場合、現場に配属されたばかりのエンジニアは、瞬時に関連するAWSリソースを把握することは難しいです。
「正しい情報をベース」に調査するのでなく、「問題事象から逆算して」調査を行えることは、トラブルシューティングの時間短縮になります。
3. 最終判断者は、AWSエンジニア
こちらは、考慮点となります。
Kiroは、限りなく情報収集Toolとして優秀です。
しかし、最終的な判断は、AWSエンジニアがすべきだとハンズオンを通じて感じました。
今回、ゲーム形式でトラブルシューティングを行い、スコアを競いました。
優勝者にインタビューを行ったところ、以下のようなことを述べているのが印象的でした。
- 最初は、Kiroに対してざっくりとした質問を投げた。
- Kiroの調査結果(AWSリソースの状況）に関して、自分でも確認した。
- Kiroが提示したトラブルシューティング案が違うなと感じたら、別の箇所の調査を命じた。
つまり、上位入賞者はきちんと自分の頭で考えることによってスコアを伸ばしたということです。
4. 仕様をベースにした予防的措置の設計が必要
今回、私は、Kiroからの提案を受けて誤った判断をしてしまいました。 （内容に関しては、トラブルシューティングのゲーム内容に関連するため省略します）
なぜ誤ってしまったかを振り返ると、仕様を知らなかったという点かと考えています。
実際の現場の場合、プロジェクトごとに細かな仕様があります。
Kiroの提案は、そうした個別の仕様（意図）を踏まえた判断まではできません。
Kiroを運用する場合には、ステアリングファイルの設定だけでなく、権限設計（Role、ポリシー、EC2ならばファイル実行権限）が必要になると感じました。
この記事は私が書きました
相良 優子
記事一覧