はじめに
こんにちは。株式会社エブリーの開発1部の村上です。
この記事は every Tech Blog Advent Calendar 2025 の 19日目の記事です。
弊社では各チームでアラートやインシデントの対応をしており、発生から調査までを各エンジニアが自ら行なっています。その調査自体はナレッジが溜まりつつあるものの、この時代であればよりAIを活用して、迅速な調査やサービス復旧ができないのかという疑問は常にありました。
そんな中で、Datadogから最近GAされたBits AI SREという機能が気になったので他の機能のトライアル期間中に検証した内容を共有します。
Bits AI SREとは
Bits AI SREは、Datadogが2025年12月2日にGAした、システム障害発生時に自律的にアラートを調査し、数分以内に根本原因を特定するAIエージェントです。
特徴
迅速な根本原因特定
- 明確な根本原因を数分以内に特定・提示
- 平均修復時間（MTTR）を最大90%短縮するとも言っている
経験豊富なSREレベルの推論能力
- 複数の仮説を並行して検証
- システム全体の膨大なシグナルを数秒で分析
- Datadogの広範なデータセットと数千の実際のインシデントを基に学習
対話型のインシデント対応
- チャット形式で質問に回答
- 調査結果を明確に説明し、推奨アクションを提示
期待される効果
従来のインシデント対応では、エンジニアが深夜に大量のログやメトリクスを手動で調査する必要がありましたが、Bits AI SREの導入により以下のことが期待できます。
- エンジニアが創造的な活動（顧客価値創出、システム信頼性向上）に集中可能
- 迅速かつ自信を持ったインシデント解決
- オンコール負荷の大幅軽減
使い方
基本的にBits AI SREはmonitor設定のアラートからトリガーできるようになっており、monitor詳細画面から「Investigate With Bits AI SRE」のボタンで該当のアラートを選択することでチャット画面に移り、自動で調査を開始します。
基本的には何も指示を出さなくてもこれまでの調査履歴や学習したデータをもとに自動で調査してくれますが、対話形式でアラート調査を依頼したり、回答に対して質問を行うこともできます。Bits AI SREの特徴的な機能として、調査の思考過程が完全に透明化されています。チャット画面は以下のような構成になっています
左側: チャット欄
- ユーザーとの対話形式でのやり取り
- 日本語での指示や質問が可能
- 調査結果の要約と推奨アクションを表示
右側: 思考過程パネル
- 調査フローの可視化: AIが実行している各ステップがリアルタイムで表示
- 仮説検証プロセス: 複数の仮説を立て、それぞれを検証していく過程を表示
- データソースアクセス: どのメトリクス、ログ、トレースにアクセスしているかを明示
- 判断根拠の詳細: なぜその結論に至ったかの論理的根拠を段階的に表示
- 信頼度の表示: 各結論の確信度やさらなる調査の必要性を提示
思考過程パネルは日本語のネイティブサポートにまだなっていないため、思考過程や調査詳細を閲覧する際は英語での表示となります。ただ、技術的な内容が多いため、エンジニアであれば十分理解可能なレベルです。
料金形態
公式の料金ページには年間契約の場合は1ヶ月20調査あたり625ドルになっていました。これを高いとみるかどうかはプロダクトやチーム状況によっても変わってくると思いますが、調査単位での従量課金なので何でも見てもらうというよりは何を調査してもらうかは人間がある程度判断しないとコストが増えていきそうに思います。
調査シナリオを作って検証してみる
では、実際に実務レベルで使うことができる機能でしょうか。
AWS上に構築した検証環境で、2つの典型的な問題シナリオを意図的に作り出し、Bits AI SREの調査能力を検証しました。
① 攻撃による5xxエラー急増
検証設定
| 項目 | 内容 |
|---|---|
| 監視対象 | ALBの5xxエラー急増アラート |
| 連携データ | ALBメトリクス、ALBアクセスログ |
| 再現方法 | 複数IP・偽装UserAgentによる大量アクセス攻撃 |
Bits AI SREの調査フロー
「アクセス傾向を分析して、DDoS攻撃の可能性などを分析してください」と調査依頼を出したところ、以下のステップで分析から回答が生成されました。
Step 1: メトリクス分析
- アラート期間のアクセス数、新規コネクション数、応答時間を自動分析
- リアルタイムで調査内容を可視化し、詳細確認用のリンクも提供
Step 2: ログパターン分析
- ALBログから取得可能フィールドを自動特定
- ClientIP、User-Agentに着目したアクセスパターン解析
Step 3: 調査結果
これらの調査から実際に以下のような一次回答を出してくれました。アウトプットとしては全体で1-2分ほどで事象をよく理解した回答がもらえました。
ALBへのアクセス傾向とDDoS攻撃の可能性を分析しました。 **アクセスパターン分析結果** **リクエスト量の推移:** - アラート発生時(13:29 UTC)前後、2,200〜4,300リクエスト/分で推移 - 13:39以降、リクエストが急激に停止(0リクエスト) - アクティブ接続数は480〜650接続で安定的に推移 **エラー傾向:** - 30分間で合計43,223リクエストのうち、**41,977件(97%)が5xxエラー** - 4xxエラーはわずか13件 - バックエンドレスポンスタイムは1〜5秒で、極端な遅延は見られない - ALBレベルでの拒否接続は0件 **トラフィック送信元の特徴:** 分析したエラーログから以下の特徴が判明: 1. **少数のIPからの集中アクセス** - `xx.xxx.xxx.xx`: 頻繁に出現(最多送信元) - `xx.xx.xxx.xx`: 2番目に頻繁 - `xx.xx.xxx.xx`: 散発的 2. **User-Agentパターン** - 多様なクローラー/ボット: BLEXBot, MJ12bot, Python requests, Java, Wget, PostmanRuntime等 - 正規ブラウザを模倣したUA: Chrome, Firefox, IE等 - **単一IPから複数の異なるUser-Agentを使用** → 典型的な攻撃パターン 3. **リクエストの特徴** - すべてのリクエストがルートパス `/` への GET - 全て同一ホスト宛 - バラエティに富んだポート番号(短時間での接続・切断を繰り返す) **DDoS攻撃の可能性: 高** **根拠:** - ✅ 少数IP(3〜5個程度)からの大量リクエスト - ✅ 単一IPから複数User-Agentを使い分け(偽装) - ✅ 同一パターンのリクエスト(GET / のみ) - ✅ 97%がバックエンド5xxエラー → バックエンドが過負荷で応答できない状態 - ✅ クローラーを装った自動化ツールの使用 **攻撃タイプ:** アプリケーション層DDoS(Layer 7攻撃)の可能性が高い。少数のIPから大量のHTTPリクエストを送信し、バックエンドリソースを枯渇させる手法。 **推奨対策:** 1. 疑わしいIPアドレス(`xx.xx.xxx.xx`, `xx.xx.xxx.xx`, `xx.xx.xxx.xx`)のブロック 2. AWS WAFでのレート制限ルール設定 3. User-Agent検証ルールの追加 4. ALBアクセスログの継続監視とAmazon GuardDutyの有効化 この攻撃により `targetgroup:targetgroup/xxxxxxxx/xxxxxxxx` のバックエンドが過負荷状態になっていると判断されます。
基本的には数値的根拠をベースに、攻撃元IPの特定、User-Agentパターンの分析まで、手動調査で行う項目を過不足なくカバーしています。 対策提案についても、疑わしいIPの具体的なブロックから予防策（AWS WAF、GuardDuty）まで実行可能な内容が提示されており、解決策の検討も一緒に行うことができます。さらにここから疑わしいIP一覧や疑わしいIPアドレスごとのUser-Agent使用パターンを依頼するとそれらを列挙する形で会話を進めることができました。
基本的にはチャットでの回答の方が理解しやすく、不足もないですが右側のパネルでも結論に至った背景を見ることができます。
② データベース処理によるレイテンシー悪化
検証設定
| 項目 | 内容 |
|---|---|
| 監視対象 | APIレスポンスタイムの悪化 |
| 連携データ | ALBメトリクス、APMトレース |
| 再現方法 | DB接続数制限による接続枯渇状態での負荷テスト |
Bits AI SREの調査フロー
「レイテンシーが悪化している原因となっているエンドポイントの特定とボトルネックとなっている箇所の詳細分析をしてください」と調査依頼を出したところ、以下のステップで分析から回答が生成されました。
Step 1: エンドポイント特定
- APMトレースからレイテンシーの高いエンドポイントを自動特定
/api/*への負荷を正確に検出
Step 2: ボトルネック分析
- 最もレイテンシーが高いトレースの詳細分析
- SQLクエリやDB接続に関するエラーログを自動検索
Step 3: 調査結果
実際に一次回答ではコネクションの枯渇や接続確立の遅延を問題視している回答となり、期待に近い回答になりました。こちらもレイテンシーの悪化を単なる「遅い」という表現ではなく、具体的な処理時間の内訳まで詳細に分析してくれています。
トレース分析の結果、レイテンシー悪化の原因とボトルネックが特定できました。 **問題のエンドポイント:** - `GET /api/v1/search` - 検索APIエンドポイント **レイテンシー状況:** - 最大レイテンシー: **129ms** (通常時13-16ms) - アラート時のp95レイテンシー: **84-102ms**に急増 - 通常時の約**6-8倍**のレイテンシー **ボトルネックの詳細分析:** 完全なトレース分析により、129msのリクエストにおける処理時間の内訳: 1. **データベース接続確立: 94.3ms** (73%) - `postgres.query` (Connect) - PostgreSQLへの接続処理 - RDSインスタンス: `bits-ai-sre-postgres.cmm4mneym0sd.ap-northeast-1.rds.amazonaws.com` 2. **メインクエリ実行: 18.4ms** (14%) - 複雑なCTE (WITH句) を使用した検索クエリ - ILIKE パターンマッチング、ROW_NUMBER() ウィンドウ関数、複数JOIN 3. **トランザクション開始: 13.5ms** (10%) - `Begin` トランザクション処理 4. **その他の処理: 2.9ms** (3%) - 集計クエリ、Commit処理 **根本原因:** **データベースコネクションプールの枯渇または接続確立の遅延**が主要因です。接続確立に94ms (全体の73%) かかっており、これは明らかに異常です。通常、コネクションプーリングが適切に機能していれば、接続は再利用されるため数ms以下になるはずです。 **推奨される対策:** 1. **コネクションプール設定の見直し** - 最大接続数を増加 - アイドルタイムアウトの調整 - 接続の事前ウォームアップ 2. **SQLクエリの最適化** - 複雑なCTE + ILIKE + ウィンドウ関数の見直し - インデックスの追加 (`name`, `description`, `category`列) - フルテキスト検索エンジン(Elasticsearch等)への移行検討 3. **RDSパフォーマンスの確認** - CPU/メモリ使用率 - ネットワークレイテンシー - スケールアップまたはリードレプリカの追加
今回はアプリケーションのログまで連携できていませんが、アプリケーションのログやSentryのエラーまでもDatadogに連携できればより精度の高い問題の分析を行うことができそうです。
検証結果の所感
応答速度の速さ
今回の検証を通じて、1-2分で深い分析と具体的な対策提案まで完了するBits AI SREの応答速度には驚かされました。従来の手動調査と比較して圧倒的な時間短縮です。
データ集約による精度向上の可能性
Datadogにログを集約していけばいくほど、より広いコンテキストを共有でき、分析精度が向上していく可能性を感じました。今回はALBログとAPMトレースを中心とした検証でしたが、より細かい情報まで漏らさずに連携できれば、さらに精密な問題分析が期待できそうです。
エンジニアの調査業務への影響
人間では数十分かかる調査や、複数のメトリクスを横断して初めてわかるような見つけにくい課題を数分で解決できる可能性が見えてきました。SREがいる組織ではSRE自体のパフォーマンスを向上させるサポーターとしての役割を果たし、インフラ経験が浅いエンジニアにとっても頼れるパートナーのような存在になりえると感じます。
コスト面の課題
一方で以下のコスト面は組織によって負担が大きく、導入効果とコストバランスの慎重な検討が必要そうです。
- Datadogへの全ログ集約コスト
- AI利用コスト（月20調査で625ドル）
ただし、AIコストは技術の発展でより安価に提供される可能性もあるでしょう。
終わりに
今回は、Datadogが新しく発表したBits AI SREについてお話ししました。
生成AIによるインパクトはすでにコーディング業務においてはかなり大きいですが、今後こうしたアラート調査などのSRE領域でも大きな変化が起こりそうです。エブリーでは今後もこうした変化を柔軟に取り入れながら、より自社プロダクトの品質担保やさらなるパフォーマンス向上に努めていきたいです。
エブリーでは一緒に働く仲間を募集中です！
エンジニアブログをきっかけに少しでも興味も持っていただけたら、まずはカジュアルに面談しましょう！
