Amazon Bedrockの異なる2つの活用法：特定・生成による運用業務効率化への挑戦(ニフティ株式会社)

ツール導入前の課題

導入前は以下の流れで運用対応を実施

1. エラー発生時、Slackにアラートメッセージが送信され、Zapierを介してGitHubにチケットが自動起票
2. チケット起票後、運用担当者がGitHubのチケットを確認
3. エラーメッセージを元にNotionに存在する手順書を検索
4. Notionの手順書を元にSQLを作成しリカバリ

以上のため、以下のような問題が発生

• 手順書ページ検索の非効率
  • エラーメッセージによっては形式が定まっておらず、関連する手順書ページを探し出すために時間がかかる
• 対応工数の増大
  • エラー対応の着手から完了までに多くの手順が必要で、状況に応じた分岐も存在するため、対応工数が増加
• 人為的ミスのリスク
  • SQLを用いた調査などで、担当者による抽出漏れなどのヒューマンエラーが発生する可能性

どのような状態を目指していたか

• 手順書ページ特定の時間を削減
• エラー対応にかかる工数を削減
• 人為的ミスを減らし、対応の質を向上
• 最終的に、運用対応の負担を削減したい

• LangChain
• LhamaIndex
• Dify

• 構築のしやすさ
• コスト
• 抽出対象が読み込める情報の量と質の比率

• AWS環境で簡単に構築が可能（AWS Lambda）
• 特定の手順書に基づき、それと1対1で対応する専用のプロンプトやソースコードを作成可能
  • 手順書全体から類似性で検索する方式（例: RAG）とは異なり、対象を直接特定するため、高精度な出力を実現

改善したかった課題はどれくらい解決されたか

• AIによる手順書ページ特定：一部改善
  • 工数を削減することを達成
  • 以前のシステムでは特定が出来なかった手順書を特定可能に
• AIによる手順書生成：限定的
  • 精度に課題あり
  • 生成された手順の信頼性が低く、内容の正誤確認に追加工数が発生

どのような成果が得られたか

１ヵ月分の使用感アンケートを実施し、5点中3点を「工数が変わらない」と定義

• 定量的な効果（ユーザー評価平均）

  • AIによる手順書ページ特定
    • 対応工数の変化は 3.4 / 5点
  • AIによる手順書生成
    • 対応工数の変化は 2.6 / 5点
    • 精度評価は 2.7 / 5点
    • 使用割合は 4.0 / 10点（10点が100%）

• 定性的な効果（良かった点・便利だと感じた点）

  • エラーメッセージがコードブロック化され見やすくなった
  • 手順書特定機能により、従来検索できなかったものも含み目的の手順書へ素早くアクセスできるようになった
  • 手順書生成機能も、内容が正しい場合は手順作成が不要になり、SQL生成や置換対象の書き出しは参考程度に

• 現状の主な課題（不便・改善してほしい点）

  • AIによる手順書生成の精度が低い
    • 複数名から指摘を受けている
      • 誤った手順が出力されることがあり、その確認作業が逆に工数を増加させたり、利用をためらわせたりする原因に
  • 信頼性の問題
    • 生成された手順への信頼性が低く、結局、元の手順書を確認する手間が発生
  • 結果の不安定さ
    • 同じアラートでも日によって手順書の特定結果や生成される手順が異なる場合が存在

• Zapierのタイムアウト制限
  • 当初、Slack通知をトリガーに単一のLambda関数でNotion解析からBedrock処理までを実行しようとしましたが、処理時間がZapierの30秒制限を超過
  • 対策：処理を分割
    1. Notion解析の事前実行
       • EventBridgeで定期的にLambdaを起動し、Notionの手順書を解析してS3にMarkdown形式で保存する処理を非同期で事前に行うように
    2. Lambdaの非同期連携
       • Zapierから呼び出すLambda①は即時応答を返しつつ、メイン処理（GitHub Issue起票、Bedrock処理）を行うLambda②を非同期で呼び出す構成に変更
• Notionページ解析・S3保存処理の時間
  • 手順書の数が増えるにつれて、全ページを解析してS3に保存する処理時間が長くなる問題が発生（例: 150ページで約300秒）
  • 対策
    1. 差分更新
       • S3メタデータにNotionページの最終更新日時を記録し、更新がないページは解析をスキップ
         • 以上により、処理時間を大幅に短縮可能に（約300秒→約20秒）
    2. 対象ページの精査
       • 手順と直接関係のない情報が含まれるページはAPI連携対象から除外

精度に関与する箇所以外ですと、以下が懸念事項に上がると思われます

• 処理時間の考慮
  • BedrockのAPI呼び出しや、連携する外部サービス（Notion APIなど）の処理には時間がかかる場合があるため、Zapierのようなタイムアウト制限があるツールと連携する場合は、非同期処理や処理分割の設計を検討すること
• 事前処理の活用
  • 大量データの解析など、時間のかかる処理は、バッチ処理などで事前に済ませておき、結果をS3などにキャッシュしておき、応答性を高めること
• 不要なメモの移動
  • 取得対象のNotionページに存在する不要なメモは、ページ化し、Notion API のConnections外に配置することで参照されないようにすること
  • 手順書生成の精度向上を図る

• AI手順書生成の精度向上
  • 最重要課題
• フィードバックと再学習の仕組み導入
  • ユーザーが生成された手順の正誤を簡単にフィードバック（例: Good/Bad評価ボタン）でき、そのデータを基にAIモデルを継続的に再学習させる仕組みの構築
• 手順書自体の整備
  • AIがより正確に内容を理解・処理できるよう、既存の手順書（特に複雑なもの）の構成や記述を見直す・整備することが必要
• Notionページ解析処理の精度向上
  • 手順書内から不要な情報（ヘッダー、フッターなど）を除去することで、より重要なコンテンツのみを抽出する精度を向上
• 汎用的な情報抽出機能の追加
  • 現在はエラーコードなど形式が決まった情報を主に利用していますが、エラーメッセージごとに異なる必要な情報を柔軟に抽出・利用できるような機能を追加し、対応可能なエラーの種類を増加