※この記事は社内のSRE運用基盤の設計思想を、固有名を伏せて一般化したものです。サービス名・アカウント・チャネル名は「サービスA」みたいにぼかしてます。
先に結論
AIに考察はさせる。でも出力は信じない。モデルを賢くするより、グラウンディングと検証の“仕組み”で精度を担保する——という話です。
- CloudWatchの全アラートにAI(Amazon Bedrock)が一次考察を付ける基盤を作ってます
- ただ、運用にAIを出す以上、ハルシネーション(=的外れな原因断定)は普通に事故になる
その“仕組み”が3本柱👇
- マルチモデルで相互チェック
- runbook(対応手順書)で出力をグラウンディング
- 過去の対応事例(ナレッジ)を参照させる
1. なぜ作るのか
SREやってると、アラートの一次切り分けで毎回そこそこ時間が溶けるんですよね。
- アラートは飛んでくる。でも「で、これ何が起きてんの?」の判断は結局人がやる
- 経験者は速い。けどそれって裏を返せば属人化してるだけ
- 数が増えたら普通に詰む
「じゃあAIに一次考察(=たぶん何が原因か、まず何を見るべきか)を書かせればよくない?」——ここまでは誰でも思いつくし、実際Bedrockに投げればそれっぽい文章は返ってきます。
問題はこの“それっぽさ”なんですよ。
運用の現場でAIが「たぶんDBのコネクション枯渇です」とか断定して、それが嘘だったら、対応する人は普通にミスリードされます。AIの考察を人間が信じて動く前提に立つと、ハルシネーションは「精度がちょっと悪い」じゃ済まなくて、インシデントの増幅器になる。
なので最初からテーマはこれ一本でした。
AIの考察を、人間が安心して読める品質まで“仕組み”で引き上げる
2. ハルシネーションを抑え込む3層
ここが本題です。「モデルを賢くする」方向じゃなくて、そもそも嘘をつきにくい構造を3層で作ってます。
層① マルチモデルで相互チェック
単一モデルの出力って、本人(?)がどんなに自信満々でも、合ってるかは分からんのですよね。だから複数モデルに考察させて突き合わせます。
主考察は Claude(Anthropic / Bedrock経由)。具体的には本番考察 Lambda が Claude Opus 4.6、一部のパイプラインが Claude Sonnet 4.6 です。これとは毛色の違う別系統のモデル——具体的には Amazon の Nova Proでクロスチェック(Judge)する構成にしてます。同じ系統(例: Claude を2個)並べても、だいたい同じところで同じように間違えるので、あえてベンダーごと変えるのがポイントでした。
- 単一モデルがやりがちな「もっともらしい誤り」を、別系統のモデルが拾う
- モデル同士で結論が割れたら、それ自体が「断定すんな、人間が見ろ」のサイン
- リージョンやレイテンシの都合で inference profile（東京の
jp.*/ us-east-1 のus.*など）を使い分けて、安定して呼べるやつを主軸に置く
実際にいくつかの組み合わせを試して、最終的にこの構成へ落ち着きました。
| 構成 | 主考察 | クロスチェック(Judge) | 判定 |
|---|---|---|---|
| ベースライン | Claude Opus 4.6 単体 | — | 自信過剰な誤断定が残る |
| ★採用 | Claude Opus 4.6 | Amazon Nova Pro | 別系統がもっともらしい誤りを拾う |
| 補欠 | Claude Opus 4.6 | DeepSeek R1 | Nova Pro と同等精度。ただしレイテンシ +2秒 |
| 不採用 | Claude Opus 4.6 | Llama 3.3 70B | Judge としての判定能力が不足 |
図にするとこんな動き。2モデルの結論が揃えば自信を持って出す、割れたら“人間を呼ぶ”。
突き合わせるときは、だいたいこの軸で見てます。結論が一致してるか / 根拠(参照したメトリクスやログ)が一致してるか / 重大度の見立てが一致してるか。ここが割れたら無理にどっちかへ寄せず、「要人間確認」フラグを立てる。AIに「1個の正解」を選ばせるんじゃなくて、「揃ってる/揃ってない」を見てるイメージです。
🛡 防いでるもの: 単一モデルの自信過剰な誤断定
層② runbookでグラウンディングする
個人的に一番「効いた」のがこれ。
最初、Bedrockに「このアラート考察して」とだけ投げてた頃は、出力がとにかく generic(ふわっとした一般論)だったんですよ。「ネットワークやリソースの問題が考えられます」みたいな、読んでも何も判断できないやつ。
そこでアラートごとに runbook(対応手順書)を参照させて、しかも冒頭に「クイック判定表」を置いた。
## クイック判定表
| アラート | 一次判定 | 既知パターン | 詳細手順 |
|---|---|---|---|
| XxxConnections高騰 | まずReader台数を確認 | 特定時間帯の外部データ連携による正常パターン | step-3 |
| 5xx増加 | 上流API応答を確認 | 基幹API側タイムアウトの可能性 | step-7 |
これを食わせた瞬間、出力が 「一般論」から「この環境の既知パターンの具体引用」へ 変わりました。実際のビフォーアフターがこれ(DBの長時間 idle in transaction アラートを考察させた例):
Before(runbookなし / generic):
データベースで長時間の idle in transaction が検出されています。コネクションリークやアプリケーション側のトランザクション管理に問題がある可能性があります。該当クエリを確認し、必要に応じて接続をクローズしてください。
——間違ってはいない。けどどの環境でも通用する一般論なので、これ読んでも対応者は結局イチから調べ直しです。
After(runbookグラウンディングあり):
検出された長時間 idle は 特定の時間帯に集中しています。runbookのクイック判定表より、この時間帯は 外部データ連携(日次バッチ)に伴う既知の正常パターンに該当します。秒オーダーの idle は誤検知扱いのため、対応不要の可能性が高いです。判定対象は分〜時間オーダーの長時間 idle のみで、今回はそれに該当しないため経過観察を推奨します。
同じアラート・同じモデルでも、「何を根拠に喋っていいか」を渡すだけでここまで変わる。夜中に誤検知で叩き起こされる回数が減る、って意味でもコスパは一番良かったです。
これ、一発ものじゃないです。たとえば5xxが増えたときも同じでした。
Before(runbookなし / generic):
5xxエラーが増加しています。アプリケーションのバグやサーバーリソースの逼迫が考えられます。エラーログを確認し、必要に応じてスケールアウトやロールバックをご検討ください。
After(runbookグラウンディングあり):
5xxの増加はクイック判定表の既知パターンに該当。まず見るべきは自分たちのアプリじゃなく上流(基幹API)側の応答で、基幹API側のタイムアウトに連鎖して5xxが出るパターンとして手順書に載っています(step-7)。いきなりアプリのコードを疑うより、先に上流の状態を確認するのが筋、という判断に寄ります。
アラートの種類が変わっても、同じように「この環境の既知パターン」へ寄せてくれる。この再現性がデカいんですよね。
要は精度を上げにいくんじゃなく、runbookで「喋っていい範囲」を縛る。賢いモデルを探すより、こっちの方がよっぽど効きました。
🛡 防いでるもの: 環境固有の文脈を知らずに的外れな考察をする
層③ 過去の対応事例ナレッジを参照させる
runbookは「手順」だけど、現場には手順化されてない経験知があるんですよね。「このエラー、前も出たけど原因はアレだった」みたいなやつ。
これをナレッジとして貯めて、考察時に参照させます。似た事例があればAIはそれを根拠に引ける。
🛡 防いでるもの: 解決済みの事象を毎回ゼロから誤推論する
3層をまとめると
| 層 | 防ぐ失敗 |
|---|---|
| ① マルチモデル | 単一モデルの自信過剰な誤断定 |
| ② runbookグラウンディング | 環境を知らない的外れな一般論 |
| ③ 過去事例ナレッジ | 既知事象のゼロからの誤推論 |
イメージとしては、生のアラートを3枚のフィルタに通して“嘘”を削ぎ落としていく感じ。
結局、モデル単体の賢さじゃなくて「何を根拠に喋らせるか」で精度が決まる——これが作ってて一番強く感じたことです。
3. 全体像
ここまでが考え方。実装としてはシンプルで、CloudWatchのアラームをトリガーに、考察用のLambdaがBedrockを叩いて、結果をSlackに流す。それだけです。
4. なぜいきなり自動対応にしないのか
「考察できるなら自動対応までやればよくない?」ってよく言われます。やりません。理由は単純で、まだAIの誤答率を知らないから。
なので、いきなり完成形を目指さずに3段階に分けて入れてます。
| Phase | 内容 | 投稿先 | 自動対応 |
|---|---|---|---|
| Phase 1 | 全アラートをAI考察してテスト用チャネルに投稿(観察) | プライベート | なし |
| Phase 2 | 既存アラートにスレッド返信で考察を付ける | 本番 | なし |
| Phase 3 | AIによる自動対応(低リスクなものから) | 本番 | あり |
ミソは、Phase 1は「AIが当たってるか人間が黙って見てるだけ」の期間ってこと。いきなり本番チャネルには出さない。誤答がどんだけ出るかを測ってから次に行きます。
「測ってから」と言っても感覚じゃなくて、次のフェーズに上げる条件をだいたい決めてます。具体的な閾値は環境によって変わるのでここでは伏せますが、見てる軸はこんな感じ。
- 誤答率(明らかに的外れな断定の割合)が一定以下
- 人間レビューで「これは役に立った」と判定された割合
- runbook一致率(既知パターンをちゃんと既知と言えてるか)
- 危険な断定(=そのまま動いたら事故るやつ)の件数
大事なのは、「賢そうだから自動化」じゃなくて「データで誤答率が許容範囲だと確認できたから自動化」っていう順番。Phase 1のテストチャネルは、その計測のための“安全な観察箱”として置いてます。
5. 開発プロセスもAIを信じない — 多レビュア体制
ハルシネーション対策って、ランタイムだけの話じゃないんですよね。この基盤、開発プロセス自体も「AIの成果物をAIで検証する」体制にしてます。
- 実装はAIエージェント(Claude Code)が書く
- それを別のAIが独立レビューする(AWSのネイティブ仕様と矛盾してないかを厳しく見る)
- 結論が割れたら、さらに別のAIにセカンドオピニオンを求める
特に効いてるのが、PR作ったら自動でレビューサイクルが回る仕組み。
面白いのが、同じPRでもレビューの角度を変えると毎ラウンド指摘が出てくること。1回「OKです」って言われても鵜呑みにしない。複数ラウンド・複数視点で潰す。実装するAIと検証するAIを分けて、どっちにも rubber-stamp(無条件OK)させないのがコツでした。
念のため書いておくと、このAIレビューは最終判断じゃないです。マージするかを決めるのは人間で、AIレビューは「人間が見落としがちな箇所を炙り出す追加レイヤー」として置いてるだけ。「AIがOKって言ったから通す」ではない。ここを混同すると、それこそ「結局AI信じてるじゃん」になっちゃうので。
ランタイムでも開発でも、思想は一貫して「単一AIの出力を信じない」です。
6. まとめ
AIにアラート考察させる、ってアイデア自体はもう珍しくないです。差が出るのはその先、運用に出していい品質をどう担保するか。
作ってみて得た結論は3つ。
- 精度はモデル性能より「グラウンディングと検証の仕組み」で決まる。 runbookと過去事例で“何を根拠に喋るか”を縛るのが一番効く。
- 単一AIの出力は、ランタイムでも開発でも信じない。 マルチモデルと多レビュア体制で断定の偏りを潰す。
- 自動化は「賢いから」じゃなく「誤答率データが許容範囲だから」進める。 段階導入と観察期間は、遠回りに見えて近道。
全部に共通してるのは一つで、AIの出力を「正解」として扱わない。あくまで根拠付きの仮説として受け取って、最終的な判断は人間がやる。この一線さえ守れば、AIはかなり戦力になります。
次は観察データを使って、自動対応(Phase 3)を低リスクなやつから解禁していく予定。進捗あったらまた書きます。
同じく「AIをどこまで運用に出していいんだ……」で悩んでるSRE / インフラの人の参考になれば。