ペアーズの AWS 生成 AI 事例 : Amazon Bedrock による障害対応の自動化と効率化

本ブログは、株式会社エウレカと Amazon Web Services Japan が共同で執筆しました。

背景と概要

Pairs（ペアーズ）は、株式会社エウレカが運営する恋活・婚活のマッチングアプリです。大規模なユーザーベースを持つマッチングサービスであり、システムの安定稼働が非常に重要です。多くのユーザーにとって、マッチングした後、ペアーズが実際に会うときの唯一の連絡手段となっています。そのため、障害が発生するとユーザー同士の連絡が取れなくなるので、迅速に対応を行い、再発防止のためのナレッジを貯める必要があります。過去には、障害発生時の対応に多大な時間とリソースを費やしてきました。特に、障害対応の指揮を取るコマンダーの責務が多すぎることで、新任のコマンダーが対応に苦労する場面が多々ありました。そこで、Amazon Bedrock を活用して障害対応の一部を自動化・効率化し、コマンダーの負担を軽減することで、誰でも対応しやすい環境を整えるプロジェクトを開始しました。具体的には、社内チャットツールのメッセージを活用して中間報告書とポストモーテム文書を自動作成する機能を提供しています。

Amazon Bedrock を活用した障害対応の自動化

技術選定

Amazon Bedrock 選定の理由

他の LLM サービスではなく、Amazon Bedrock を選定した理由は以下の通りです。

Amazon Elastic Kubernetes Service (Amazon EKS)との統合が容易: ペアーズのアプリケーションをホスティングしている環境が Amazon EKS で構築されているため、IAM Roles for Service Accounts (IRSA) などを活用してきめ細かい権限設計が可能。
Managed RAG 機能が利用可能: Knowledge base for Amazon Bedrock などの Managed RAG 機能が利用可能であり、ペアーズの LLM チャットボットでの利用にも活用できる。
LLMOps のサポート: モデル評価やプロンプトマネジメントなど、LLMOps で必要な要素が網羅的に提供されている。

モデル選定

Amazon Bedrock のモデル選定に関して、今回の社内利用のユースケースではコストやレスポンス速度はあまり問題にはならないため、性能を重視して Claude 3 Haiku ではなく Claude 3.5 Sonnet を選びました。 Claude 3.5 Sonnet は、Anthropic 社が開発した大規模言語モデル(LLM)であり、自然言語処理タスクにおいて高い性能を発揮します。特に、日本語の処理能力が高く評価されています。ペアーズでは、障害対応の自動化において、高い言語処理能力が求められるため、Claude 3.5 Sonnet を採用しました。

報告書作成シーケンス

ペアーズの報告書作成シーケンスは、以下のようになっています(ポストモーテム文書作成も同様)。

従業員が社内チャットツールにて報告書作成依頼コマンドを実行し、それを Incident Bot が受け付ける
Incident Bot が LLM API を呼び出す
LLM AP Iが Amazon Bedrock を利用して、報告テンプレートと社内チャットツールのメッセージ・障害情報から障害の要約を生成する。
生成された要約を駆使して報告書が作成され、社内のドキュメント、チャットツールに投稿されるこのシーケンスでは、従業員が手動で報告書を作成する必要がなくなり、効率的な障害対応が可能になります。また、LLM を活用することで、報告書の品質も向上します。（※実際の報告書ではありません）

システムアーキテクチャ

従業員からの報告書作成依頼コマンドを受け付け、ハンドリングする Incident Bot Server が、Amazon API Gateway と AWS Lambda で構築されています。そこからリクエストを受け付ける LLM API が Amazon EKS 上に構築されており、Amazon Bedrock を用いた障害情報の要約処理が行われております。このアーキテクチャにより、スケーラビリティの高いシステムを構築することができます。

LLMを利用したAPI処理の工夫点

データ前処理

社内チャットツールのメッセージデータから Bot の発言などを取り除き、必要なメッセージに絞る処理をしています。また、メッセージデータに含まれるタイムスタンプは、対応時系列の項目などで使用したい形式にあらかじめ変換しています。このように、LLM に任せる必要のない単純なデータ処理は事前に済ませておくことで、LLM を本質的なタスクに集中させ、生成の精度を上げることにつながります。また、Claude のモデルは命令プロンプトをXML形式で記述すると生成の精度が上がる傾向にあるため、メッセージデータを XML 形式に変換して Amazon Bedrock への命令プロンプトの一部として埋め込んでいます。

リトライ機構

使用しているドキュメントツールの制約により、Amazon Bedrock を用いて XHTML 形式のデータを生成する必要があります。そのため、プロンプトで XHTML 形式のデータ生成を指示します。その際、プロンプトの最後にアウトプットが有効な XHTML かどうかを LLM 自身に再度バリデーションさせるとより効果的です。さらに、有効な XHTML であることを後処理でもバリデーションし、もし有効な XHTML でない場合は生成処理をリトライするように実装しています。LLM の出力はどんなにプロンプトを工夫しても必ずしも命令を守ってくれるとは限らないので、このようなリトライ機構は非常に重要です。リトライ機構の導入により、出力の品質が大幅に向上しました。初期の試行では、約30%の出力が XHTML の要件を満たしていませんでしたが、リトライ機構の導入後は99%以上の出力が要件を満たすようになりました。

LLM に全てを生成させない

状態が遷移しがちでハルシネーションや処理ミスが起こりやすいテンプレート項目(障害深刻度など)は、別で保存されているデータを取得しテンプレートに埋め込み、LLM に生成させないようにしています。また、静的なテンプレート部分(注意事項など)は、生成データに後処理で結合するようにしています。LLM が生成する必要がない/不得意な部分は、LLM に生成させないという考え方はどのタスクでも有効です。この工夫により、LLM に適したタスクに特化させることができ、出力の品質が向上しました。また、処理の効率化にもつながりました。

導入効果

Amazon Bedrock を導入した結果、以下の成果を得ることができました。

対応時間/コストの短縮

障害対応報告書とポストモーテム文書の自動生成により、報告や振り返りにかかる工数が約60%削減され、対応時間/コストが大幅に短縮されました。具体的には、従来は報告書作成に1人当たり平均3時間を要していましたが、自動化後は1時間程度に短縮されました。また、ポストモーテム文書作成に関しても、従来は1人当たり4時間を要していましたが、1.5時間程度に短縮されました。このように、自動化による大幅な工数削減が実現でき、障害対応にかかるコストを大きく削減することができました。

障害対応の心理的負担軽減

従来は、コマンダーが報告書やポストモーテム文書の作成を含む多くの業務を担っていたため、特に重大な障害発生時には過度の負荷がかかっていました。しかし、自動化により、これらの業務の一部が軽減されたことで、コマンダーの負担が大きく軽減されました。また、報告書やポストモーテム文書の品質も向上したことで、コマンダーが内容を確認し修正する手間も削減されました。このように、自動化による業務の効率化と品質向上により、コマンダーの心理的負担が軽減され、障害対応体制の強化につながりました。

Amazon Web Services ブログ