Salesforceの本番障害、一次切り分けをAIに任せてみたら現場対応がどう変わったか

Salesforceの本番環境で障害が起きるたびに、デバッグログとにらめっこして原因の見当をつけるまでに時間がかかっていませんか。私はSalesforceエンジニアのマネージャーとして、月に1〜2件のペースで本番障害の一次対応に入っています。

エラーの一報を受けてから「何が起きているか」の仮説を立てるまでの時間が、対応全体のボトルネックになっていました。障害対応の間、顧客からの問い合わせ画面には「現在調査中です」という表示しか出せず、原因が分からないまま時間だけが過ぎていく感覚は、経験した人にしか分からない焦りだと思います。

この記事では、デバッグログの一次切り分けをAIに任せる運用に切り替えて、平均対応時間がどう変わったかを書きます。

結論から先に言うと、原因の仮説を立てるまでの時間は導入前の平均37分から平均16分まで縮まりました。ただし、AIに丸投げして解決するほど単純な話でもなく、仮説を鵜呑みにして痛い目を見たこともあります。

ここから先では、実際にAIへ投げているプロンプトの全文、ログを渡す前に整えておく前処理の手順、そして一次切り分けの精度を上げるために作った判定チェックリストを公開します。手元にデバッグログとSetup監査証跡の出力さえあれば、次の障害対応からそのまま使える内容です。

本番障害で一次切り分けに時間がかかっていた理由

障害対応の現場では、まず「どのレイヤーで起きているか」を絞り込む作業から始まります。Apexの例外なのか、外部連携のタイムアウトなのか、権限設定の変更が原因なのか、候補は毎回3〜4種類あり、これを人力で絞り込むのに平均で30〜40分かかっていました。

正直なところ、この絞り込み作業自体にあまり価値を感じていませんでした。原因が特定できた後の修正作業のほうがよほど頭を使う仕事で、絞り込みは経験と勘に頼った力技になっていたからです。ベテランのエンジニアなら10分で見当がつくところを、経験の浅いメンバーが担当すると1時間以上かかることもあり、対応のばらつきも課題でした。

デバッグログをAIに読ませる前処理

最初にやったのは、デバッグログをそのままAIに渡さないようにすることでした。Salesforceのデバッグログはノイズが多く、そのまま貼り付けると重要な行が埋もれてしまいます。

ログレベルをFINEST寄りに上げすぎたときは特に顕著で、1件のリクエストで数千行になることも珍しくありません。

そこで、渡す前に以下の3つを機械的に絞り込むようにしました。