AWS さんにお越しいただいて Kiro CLI を使用するトラブルシューティングのワークショップを実施いただきました

記事タイトルとURLをコピーする

みなさん、こんにちは。AWS CLI が好きな AWS サポート課の市野です。

12月19日に AWS Support のクラウドサポートエンジニアの皆様が弊社へお越しくださり、Kiro CLI を活用したトラブルシューティングのワークショップを開催していただきました。

その内容を開示可能な範囲でつづってみました。

また、掲載している画像や画面キャプチャについては AWS Support のクラウドサポートエンジニアのみなさまや、ご参加者のみなさまに許諾いただいたものを使用しています。

そもそも Kiro CLI とは

従来、Amazon Q Developer for CLI と呼ばれていた製品に近いですが、2025年11月18 日の Kiro のGA(一般提供開始)に伴って Kiro に統合されました。

IDE と統合されている製品を Kiro IDE、CLI 環境で実行できるものが Kiro CLI という位置付けです。

aws.amazon.com

Kiro CLI だと何が良いか

私はコミュニティ運営や参加をよくしていて、Amazon Q Developer for CLI だった頃からいくつか LT 登壇の場などで紹介をしたことがあります。

その中で、世の中には多くの AI や AI Agent が存在するため、現 Kiro よりも賢い製品はあり得ることを伝えています。
ただ、ターミナルの中での壁打ちをしつつ、設定さえされていれば AWS CLI を用いたシームレスな調査や修復が行えることに大きなメリットを感じている点をお伝えしています。

ただ、AWS CLI を実行するエンティティが持つ権限によっては「意図せず修復を試みてしまう」「意図せず修復に成功してしまう」ことの懸念があるとも感じています。

それらの怖さも感じつつ、サポート対応の中でうまく活かせないか、うまく活かす際にどのような点を配慮すれば良いか、をチーム内でも模索しています。

先日、同じテクニカルサポート部門の同僚である森本さんが模索している現在地点をブログに書いてくれているので、合わせてご覧ください。

blog.serverworks.co.jp

ワークショップの概要

AWS GameDay のようなゲーム要素があり、得点を積み上げて順位判定があるゲーム要素もあったため、内容を開示してしまうとネタバレになってしまうため詳細は伏せます。

ただ、さまざまな問題を抱える 3 つの課題・環境に対して、Kiro CLI を活用しながら問題を発見し、修復を試みるものとなっていました。

得られた学び

ステアリングファイルの作成による制御

ワークショップの事前準備部分で、以下のような操作により禁止事項の定義をしてました。

mkdir -p .kiro/steering/
cat > .kiro/steering/troubleshooting.md << 'EOF'
## Limitation
以下の内容を第一優先で必ず守ってください。
- EC2 上のウェブコンテンツ /var/www/html/ 配下のファイルやディレクトリは削除したり、編集したり変更を加えないでください。
- EC2 上の Apache などの各種設定については明示的に変更を依頼しない限り変更を加えないでください。
- EC2 上のシステムファイル等にも変更や削除、追加など行わないでください。
- AWS リソースに対する変更に関しても変更を行う場合には、必ずユーザーからの許可を得てください
EOF

これにより、OS 内部の調査中に判明した不備を修復するために、ファイルの作成・設置をしても良いかの承認を得たいと Kiro が申し出る場面もありました。

ただし、ステアリングファイルだけでは危険作業を回避できない可能性がある

3 つの課題のうち最後の課題はなかなかの難問で、至る所に罠(不備)が仕掛けられていて難解な問題を抱えている課題でした。 30 人ほどいた参加者で結局最後まで完遂できたメンバーがいなかったほどですが、上位 3 名のメンバー含め複数の方でアプリを破壊してしまった報告がありました。

焦りからどこかのタイミングで t を押してしまい trust してしまって意図せず進められてしまった、Kiro の回答や提案を読み飛ばしてしまったなどが要因だと思われます。
それでも本番環境での出来事だったと考えると、冷や汗では済まない事態です。

やはり壁打ちをしながら原因調査を行えるメリットは大きい

アプリを壊してしまった点は大変怖いですが、複数のツールを横断せずに 1 つのターミナル内で完結するメリットは大きいと感じました。

ワークショップ後にクラウドサポートエンジニアさんと会話する機会があり、担当エンジニアとしては、ステアリングファイルを信じすぎず、以下のような順位で、多段で防御策を講じておくことが望ましいと伺いました。

  1. 内包する AWS CLI 実行エンティティの適切な権限設定
  2. カスタムエージェント設定
  3. ステアリングファイル

おわりに

今回、弊社へデリバリーいただいた Kiro CLI を活用したトラブルシューティングのワークショップはオフラインでのデリバリーでした。

オンラインでは 2 度ほど開催されていて、X のポストを見かけられたことのある方もいらっしゃるかと思います。

今後もオンラインでの開催や AWS のユーザーコミュニティである JAWS などの勉強会の場での開催も考えられているとのことですので、機会があればぜひご参加してみてください。

この記事がどなたかの参考になれば幸いです。

ではまた。

市野 和明 (記事一覧)

マネージドサービス部・AWS サポート課

お客様から寄せられたご質問や技術検証を通じて得られた気づきを投稿していきます。

情シスだった前職までの経験で、UI がコロコロ変わる AWS においては GUI で手順を残していると画面構成が変わってしまって後々まごつくことが多かった経験から、極力変わりにくい AWS CLI での記事が多めです。

X(Twitter):@kazzpapa3(AWS Community Builder)