こんにちは、MEKIKI X AIハッカソンもくもく勉強会の4日目を担当する楢府です！
最近盆栽にハマっています。
今日はAIでトラブル対応するときについて書いてみました。

AIでトラブル対応をするときはじめの一歩

バックエンドやインフラに触っていると、ECS のタスク起動失敗、ネットワーク通信エラー、RDS への接続失敗、Docker のビルドエラー……といった面倒なトラブルに出会います。

最近はAIを使って原因調査、対応を行う人も多いと思います（筆者もその一人です）。
2,3年前までは長々とプロンプトを書いていましたが、最近は推察力が向上してよりシンプルに使えるようになったと思います。
ただ、使い方を間違えるとAIは推察を暴走させて混乱することがあります。

結論から言うと、トラブル対応は
AIに極端に推察ばかりさせず、ログやパス（事実）をすべて渡す
これが圧倒的に早いと思います。

12/4のアドベントカレンダーではAIを「推察マシン」ではなく「推察できる高速エラー処理マシン」として使う方法を紹介します。

AIに適切に推察をさせる

よくあるダメな質問はこんな感じです。

アプリでこういう動作をしたらエラーを起こしました。原因わかりますか？

これを先輩に聞くと、

「これだけだとわからないな…」
「ログ見よう」
「ブラウザの開発者ツール開いてみて」

などと情報を集めて助けてくれます。
ただしAIに同じように聞くと何とかその場で回答しようとして推察を始めます。
これがハルシネーションの原因。

では実際にどう聞くか、それはこちらです。

これはhogehogeというアプリのfugafugaという機能でエラーが出たときのログです。

ログのどの行を根拠に、何にが原因か教えてください。

大事なのは全部のパス（事実）を渡すことです。
AIには高速で問題点を探してもらいそこのパス（事実）から問題点を推察してもらいます。

推察を暴走させないために

推察を暴走させないためにプロンプトを長々と書いてAIをがんじがらめにする必要はありません。
例えばこんな感じですね

もっともらしいうそ（ハルシネーション）を防ぎ、必ずその情報のソースや参照元URLを提示してください。
不明点がある場合はそれを （以下略）

毎回コピペするのも面倒ですし、この文章を考えて更新していく時間ももったいないです。
極力AIのプロンプトを考える時間は減らして出力結果を考察する時間にしたいです。

ログは全部貼る

ECS 起動失敗ログ 200 行でも、
ECR push エラー 30 行でも、
Docker ビルドログ 300 行でも全部貼る。

省略すると、AIが“足りない部分を勝手に補完して外す”ので逆効果。

前提条件を一行でいいから添える

例：

ECSはawsvpc、ALBあり、RDS PostgreSQL、アプリはGoです。

外した推察が減る。ログだけで揃わない補助情報は一行だけで十分。

問題のあった行をそのまま挙げさせる

例：

このログ全文から、どの行がどの設定ミスに対応しているか 1:1 で説明してください。

トラブル対応中はslackのスレッドに状況や調査結果をためている人もいるかと思います。
そんな時にこの一言があると非常に便利です。
「その行本当にある？」と逆照合できるのも地味に強い。

実際にあったケース

筆者はこのような環境でトラブル対応をすることが最近多いです。

ログ収集：CloudWatch / ローカルのアプリログ
AIツール：Claude
対象：AWS系のサービス（ECS, RDS, ファイルストレージ等）、Dockerビルドログ、アプリケーションログ
問い合わせ方：コピペしたログをそのまま貼るだけ

プロンプトも特別なものではなく、普段は本当にこれだけです：

以下はエラー発生時のログです。原因とログを1:1で整理してください。

Case1: 外部サービスへのアクセスでタイムアウト

あるAPIが外部の検証用サービスにHTTPSでアクセスする仕様だったのですが、
タイムアウトするようになりました。

原因候補としては、ネットワーク、DNS、証明書、プロキシ設定…と幅広く、手作業で追うと時間がかかるタイプ。

ログを貼らずに解決しようとするとこのような結果になると思います。

私：
外部サービスにアクセスしたらタイムアウトするようになりました。原因わかりますか？

AI：
これは外部サービスの証明書が期限切れの可能性があります。
証明書を更新するか、信頼ストアをアップデートすると解決します。

私：
いや、証明書期限切れってどこから判断したの…？

AI：
一般的にHTTPSのエラーは証明書が原因なので、そう推測しました。

証明書を確認しても何も問題はありません。
そこで AI には以下のように依頼します。

以下のログを確認して、
通信経路上で発生しうる可能性を優先度順で整理してください。

<ログ全文>

結果、返ってきた内容は

現象が発生している具体的な行
タイムアウト条件の発生箇所
考えられる原因（アウトバウンド通信制限、名前解決、TLS問題など）の優先度付きリスト

実際の原因は、外向き通信に関する設定の不備でした。
「推察ではなく、ログに書いてある“事実”のみで整理してもらった」 ことで調査が一気に短縮できました。

Case2:資格情報が正しく読み込まれず、外部ストレージへのアップロードが突然失敗

アプリケーションが外部ストレージにファイルをアップロードする処理で、
ある日突然認証エラーが発生しました。

ログにはこんな感じのメッセージが出ていました：

operation error: PutObject
get identity: failed to refresh cached credentials
static credentials are empty

認証情報まわりの問題は、原因の幅が広く、地味に時間がかかりがち。

ログを貼らずに解決しようとするとこのような結果になると思います。

私：
外部ストレージへのアップロードで認証エラーが出ます。原因なんでしょう？

AI：
アップロード先パスが間違っている可能性があります。

私：
いや、パスは変えてないし存在してるんだけど…？

AI：
では外部ストレージ側でAPIバージョンが更新され、旧バージョンのSDKが認証に失敗している可能性があります。
SDKをアップデートして再試行してください。

これらの指摘通りに確認をしても原因は見つかりません。
そこで AI にはこう依頼しました。

以下は外部ストレージへのアップロードが失敗した際のログです。
資格情報が取得できない原因を洗い出してください。

<ログ全文>

返ってきた内容は、

どの処理で“取得に失敗”しているか
ログ根拠行の提示
「認証情報ソースへのアクセス経路が遮断されている可能性」の指摘

などが、根拠となるログとセットで整理されていました。

実際の原因は、
実行環境のネットワーク制限により、認証情報を取得するためのエンドポイントにアクセスできていなかったこと。

一見すると“資格情報が空”という出力だけでミスリードしがちなところを、
AIが“ログに存在する事実”だけを使って通信経路の可能性まで導いてくれたことで、調査が大幅に短縮できたケースでした。

まとめ

AIはうまく使えば最速のログ解析ツールになります。
しかも難しいプロンプトをひねり出す必要はありません。

“事実を全部渡し、推察は最小限に絞らせる”

これだけでAIは一気に本領を発揮します。
ログ解析にAIを使う人が、今日より少しでも楽になりますように。