- 公開日
- 最終更新日
【Kiro CLI】AIは5分で原因を特定し、僕は5秒で判断を誤った。そこから学んだこと
この記事を共有する
目次
この記事は、AWSサポート主催のKiro CLIハンズオンイベントへの参加記です。
当イベントの実現に尽力し、楽しい時間を提供くださったみなさまに感謝いたします。
はじめに
パーソル&サーバーワークスの中山です。最近はもっぱらKiro CLIと友達になったりケンカしたりしています。
そんな折、AIエージェント×トラブルシューティングをテーマとしたゲーム形式のワークショップに参加しました。 そこで感じたAIの可能性と人間の限界、そして希望を書きます。
前提 - ゲームのルール
ゲームは2時間の競技形式でした。 Kiro CLIを使ってWebアプリケーション環境（ALB + EC2 + RDS + S3）に仕込まれたいくつかのトラブルを解決し、タスクをクリアするごとに得点を得ます。
ミソは、1つのタスククリアごとに継続的に得点を得られるというルールです。
例えば、タスク1〜10があったとして、タスク1をクリアできたら1分ごとに5点が加算され続けます。つまり各タスクを早く解けば解くほど、最終スコアが伸びる仕組みです。
トラブルシューティングにおけるAIの可能性
Kiro CLIは非常に優秀でした。
AWSのAPIを実行できる権限を与えると、ログを読み、設定を確認し、原因の特定まで一気にやってくれます。
実例
たとえば、こんな流れです：
僕のプロンプト(要約)：
my-loadbalancer-hoge経由でWebページにアクセスすると504 Gateway Timeoutになる。原因を調査して
Kiro CLIの応答（要約）：
ターゲットグループのヘルス状態を確認したところ、ターゲットが
unhealthyでした。 セキュリティグループを調査した結果、HTTPポート80のインバウンドルールが存在しません。 以下のコマンドで修正できます：
aws ec2 authorize-security-group-ingress \
--group-id sg-0123456789abcdef \
--protocol tcp \
--port 80 \
--cidr 0.0.0.0/0
実行。5分で解決です。
何がすごいのか
僕がAIに伝えたのは「ロードバランサーの名前」と「504エラーが出ている」という2つの情報だけです。
人間のエンジニアがこの問題を解くには、ALBからEC2内のサーバへ通信できる仕組みを知っている必要があります。
- ALBにはリスナーがあり、リクエストを受け付ける
- リスナーはターゲットグループにリクエストを振り分ける
- ターゲットグループはEC2インスタンスの「健康状態」を定期的にチェックしている
- EC2のセキュリティグループで通信が許可されていないと、ヘルスチェックが失敗する
この知識があって初めて「504エラー → ターゲットが応答していない → セキュリティグループを疑う」という推論ができます。
Kiro CLIは、この推論を自分でやってのけました。
衝撃的だったのは、AIがエンジニアの勘を持っているように見えたことです。Kiro CLIは、曖昧な情報から妥当な仮説を立て、調査し、解決策を提示したのです。
「今のAIならそれくらいできて当然では？」と思う方もいるかもしれません。 確かに、Web検索で情報を補いながら一般的な知識を提供することなら、現在の技術水準では当たり前になっています。 しかし、これは特に人間に言えることですが、知っていることとできることの間には大きな崖があります。この「できる」の崖をAIが既に乗り越えていたことが驚きでした。
また、人間がコンソール画面を何度も遷移するよりもずっと速いので、同じ解決策に至るならスピードで勝るAIの方が優れていると認めざるをえませんでした。
トラブルシューティングにおける人間の限界
さて、AIが優秀であればあるほど、問われるのは人間の行動規範です。 人間は条件がそろえば驚くほど簡単に易きに流れるものです。
実例
前述のとおり、このゲームでは問題を速く解くほど継続加算ポイントで有利になります。
Kiro CLIが的確な提案をしてくれることを理解した僕は、こう考えました。
――とりあえず実行して、意味はあとから理解すればよい。
こんなことがありました。
僕のプロンプト(要約)：
my-loadbalancer-fugaについて、ターゲットがunhealthyです。原因を調査してください
Kiro CLIの応答（要約）：
ファイル数の問題が認められます。 以下のコマンドで修正できます：
# 不要ファイル削除
sudo rm -rf /usr/share/doc/* /usr/share/man/* /usr/share/info/*
sudo find /usr/share/locale -mindepth 1 -maxdepth 1 -type d ! -name 'en*' -exec rm -rf {} +
ゲームでいい成績を残したい気持ちが、AIの提案に対するチェックを甘くしました。
なぜAIはこれらを不要ファイルとみなしたのか？ なぜ削除が解決策になるのか？ 削除による影響は？
立ち止まるべきポイントがいくつもあると分かっていながらコマンドをながめること5秒。僕はAIにGoを出しました。
何が起きたのか
/usr/share 配下の4つのディレクトリは、なくても影響が少なく、かつファイル数が多いためピックアップされたと推測されます。
例えば、/usr/share/man/* が消えたらサーバー上で man grep などが手元で実行できなくなり、地味に困るシーンがありそうです。また、 /usr/share/locale/* について en* 以外を消しているということは、日本語があったら日本語も消えていますね。
| ディレクトリ | 内容 | 特徴 |
|---|---|---|
| /usr/share/doc/ | パッケージのドキュメント | パッケージごとに数十〜数百ファイル |
| /usr/share/man/ | manページ | 言語別×セクション別で大量 |
| /usr/share/info/ | GNU infoドキュメント | infoコマンドで閲覧 |
| /usr/share/locale/ | 言語ファイル | 100以上の言語分 |
悪いことに、この実行で問題は解決せず、消したファイルの復元もできませんでした。原因不明のまま切り戻しも叶わずで、本番だったらと思うと肝が冷えました。 さらにこれはゲーム後に確認しましたが、トラブルの原因とは全く関係ないファイル群でした。
ゲームで好成績を取りたいという状況が実務で再現されることは少ないかもしれません。しかし、以下のような状況はどうでしょうか。
障害対応で焦っているとき。深夜対応で判断力が落ちているとき。「早く直して」とプレッシャーをかけられているとき。
人間は、状況次第で簡単に確認を怠ります。 稼働中のサービスにどんな変更を加えるのか、説明責任にどこまで向き合えるかが問われる時代になったと感じました。
トラブルシューティングにおける希望
ではAIをトラブルシューティングに使うのをやめるのか。そうはならないと思われます。大事なのは正しく恐れることです。
以下の方針でトラブルシューティングにてAIを効果的に活用できるのではないか、という仮説が僕の現在地です。
- AIには参照系の権限のみ持たせ、参照系の操作のみ実行させる
- AIにはトラブルの原因について仮説を立てさせ、人間がファクトチェックを行う
- AIには障害解消の手順を作成させ、人間が理解したうえで実行する
どこまでいっても、責任を持つのは人間です。 AIは確信を持つまでのスピードを速める、よき伴走者になってくれる。そんな未来が見えた気がしました。
おわりに
包括的な参照権があれば、AIは人間よりずっと速く原因を特定できるでしょう。 だからこそ、説明責任と実行責任が人間に求められます。AIは正しくても間違っていても、いつもそれっぽいことを言います。「AIが言っている」だけで本番環境に変更を加えてよいのか悩むのは、至って普通の感覚です。
「AIが言っているし、あの人も正しいと言っているから問題なさそうだ」と周囲から自然に思われるようになれば、生成AI時代でも大いに活躍できるのではないでしょうか。
この記事は私が書きました
中山 正哉
記事一覧2025 Japan All AWS Certifications Engineers 好きなサービスはIAMです。好きな食べ物はハンバーグドリアです。 往々にして教科書どおりにはいかない、そんな現場のペインに寄り添えるエンジニアで在るために精進の日々です。
