Zenn
🐥

ServiceNow(Incident)とAWSのAI系サービスを組み合わせてみた

2024/08/13に公開
ServiceNow
workato
tech

SlackとServiceNow(Incident)連携そもそもの仕組み

  • IncidentはSlackをベースに運用しています
    • SlackとServiceNowの連携はOOTBを使わずに独自で実装しています
    • Slackで「ITヘルプデスク質問用Channel」に発言して「特定のemoji」でリアクションをするとIncidentを起票

      • 起票すると投稿のThreadに通知される

      • 以降Threadに発言した内容がIncidentチケットに「コメント」として転記される

        • (Public)ITヘルプデスク質問用Channel
          • ヘルプデスクのメンバーや全質問者が入っている壮大なpublic channel
        • (Private)ITヘルプデスクAgent用Channel
          • ヘルプデスク対応者(ITメンバー)だけが入っている限定的なprivate channel
            • チケットが起票されるとAgent用Channelにも自動で投稿される
            • コメントはAgent用Channelでもthreadに投稿される
            • Agent用channelでthreadに投稿すると「Work Notes」として転記される

やったこと

すべてIncidentテーブルに関連します

起票時

「問い合わせ内容を要約」するようにした

  • 問い合わせの原文
  • 作成されたIncidentのShort Descriptionとdescription
  • 「過去にクローズした類似incident」が出るようにした
  • 内容を見て「解決する方法」をAIが生成するようにした

対応中

問い合わせ内容とコメント/ワークノートを見て「解決する方法」をAIがサポートするようにした

解決時

根本原因(Probable cause)と解決方法(Resolution notes)を自動生成するようにした

  • threadのコミュニケーション
  • 生成された内容
  • どのようにサポートされるのか
  • AIの回答は「Agent用channel」に通知されます

なぜやったのか

  • 「そもそもの仕組み」にもあるのですが、「Slackをベースに運用している」ためです
    • ある程度は「ServiceNowの画面」で操作ができたほうが望ましい
      • 画面の行ったり来たりを減らしたい
    • OOTBで提供される機能が「自分たちが本当に欲しかったもの」とは限らないので、独自に実装することで「自分たちが本当に欲しかったもの」を手に入れたい
  • 一般的なパブリッククラウドのリソースを使うことでのメリットに期待もしています
    • 金銭的コスト
    • 技術的コスト
      • 最新技術が来やすい
      • パブリッククラウドだとインターネット上に皆さんのナレッジがたくさんある
      • ServiceNowに詳しくなくてもawsを触っているエンジニアのスキルが活かせる

今回の仕組みでAIからサポートが通知される先

  • 「Agent用channel」です
  • 「ヘルプデスクへの問い合わせChannel」に通知しません
    • 「ヘルプデスクとして望ましくない回答」がユーザに案内されることを避けたい

構成

全体像

構成要素

実装

全体像で①のKendra

  • Indexは1つで実現したい

    料金はインデックスごとに適用されます

    • dev, staging, prodで3作成するとその分だけ金銭的コストがかかる（安くない）ので1つのindexで色々やりたい

  • Pricingを参照

  • 1つのindexに全環境分まとめることにした

    • データソースは各環境毎に作成するため、データソースは自ずと環境毎に分かれる
    • クエリを発行するときに「データソースでフィルタ」をすることで「検索元のチケットがあるServiceNowの環境」からデータを取得したデータソースを指定してクエリが発行できる

lambda

全体像で②のlambda

  • Kendraを検索するための処理を記述しています

    • 検索部分

      response = kendra.query(
    QueryText=query_text,
    IndexId=index_id,
    AttributeFilter={
        "AndAllFilters": [
            {
                "EqualsTo": {
                    "Key": "_language_code",
                    "Value": {"StringValue": "ja"},
                },
            },
            {
                'EqualsTo': {
                    'Key': '_data_source_id',
                    'Value': {
                        'StringValue': dataSourceId
                    }
                }
            }
        ]
    }
)

  • Kendraへの検索はQueryを使用した

    • Retrieveを使わなかった

      • 検索結果に含まれる「信頼度」が欲しかったが実装時時点では英語でしか対応していなかったため

        Confidence score buckets are currently available only for English.

      • Queryを選ぶデメリットもあるが、現時点でのユースケースや「信頼度が出ない」というデメリットを考えた結果Queryを使う実装にしている

  • 取得した結果を以下の構造で配列としてまとめることで、slackへ通知するときにチケットへのリンクを生成するなど後続処理で扱いやすい形で返却している

    extracted_results.append(
    {
        'short_descrption' : short_descrption.replace('\n', ''),
        'number' : number,
        'document_sys_id' : document_sys_id,
        'score': score
    }
)

全体像で③のlambda

  • 全体像で②のlambdaを呼び出す処理を書いている
  • 将来的には「②で取得した結果をBedrockで要約する」なども考えている
    • そのため初期構築で検索を別Lambdaに切り出している
    • 現在はKendraの検索結果が信頼できるのかを検証しているフェーズでもあるため要約は未実装
      • 信頼度でフィルタするなど信頼性が担保されている状態で要約したい

全体像で④のBedrock

  • 「文章の要約」と「サポート」を目的としている

要約

問い合わせの要約

  • IncidentチケットはSlackでの発言を元に起票している
    • 挨拶や自己紹介など「IncidentのShort Descriptionとして不要」な文章が含まれるケースが多い
      • 文章でコミュニケーションするSlackとしては「不要」といえない
      • 起票時にAIを使った要約処理を入れた結果をIncidentのShort Descriptionとしている

解決時の要約

  • チケットにはSlackでのコミュニケーションが転記されるためコメントとWork Notesが大量に記録されるケースが多い
    • 解決時にそれを人が読み返してまとめていくのは大変手間のかかる作業
    • Bedrockが要約して根本原因(Probable cause)と解決方法(Resolution notes)に転記するようにした
      • 転記された内容をServiceNowの画面で確認して加筆修正は人が実施

サポート

問い合わせ発生時の初期サポート

  • Incidentの内容にもよりますが、一般的なソフトウェアの使い方や設定方法、PCの物理的なトラブルなどはインターネット上の情報で解決できることも多いです
    • ヘルプデスクの担当者が調べるならば、起票したタイミングでAIが「ヘルプデスクだけに見える場所」へサポートできるメッセージを投稿することで「ヘルプデスクメンバーが調べる手間をなくす」を目的にしたもの
      • 社の独自運用や手順がある場合などでは空振りになるが、人の手間は無なのでコストは考えなくても良いと割り切っている

問い合わせ対応中のサポート

  • 対応中にAIのサポートを得られるようにした
    • 「Agent用channel」にあるThreadで特定のSlack Appへのmentionから始まるメッセージを投稿するとサポートを受けられる
    • 1incident : 1threadになっているため、発言したthreadのincidentのデータと「サポートをお願いしたい内容」をBedrockに送っている
      • サポートをお願いしたい内容は「Slack Appへのmentionに続くメッセージ」がそれにあたる
        • ex) [at]slack_app このあとどのように案内したら良いですか？

やってみた感想

  • AIの得意な「要約」など作業自体を人の手から剥がせる作業はAIに渡すことができた
    • チェックや加筆修正は人の手で実施する必要は残る
  • クローズ済みの類似incidentについては「まだまだ」な印象
    • 主に「信頼度」に対する信頼度が低い
      • これは検索対象のリソース問題もあるので難しいところ
  • Workatoが使えることで各システムの連携は楽に実装できた
    • Bedrockコネクタがあるので要約とかはシュッとできた
    • kendraコネクタは無いのでlambdaを挟むなどは必要だった
  • AWSはやはり便利だった
    • Kendraは継続的にある程度の金額は発生するので小規模運用だとコストメリットを出しにくい
    • Bedrockでは最新のモデルが来日していないのでそこだけ us-east-1 を使うなどリージョンをまたいだ実装が必要になることは注意点
      • ap-northeast-1 だけ見てPoCや実装を進めると「なんだかイマイチ聞いてた話と違う」とかなるかもです

今後やりたいこと

  • クローズ済みの類似incidentを検索したときの「信頼度」の向上
    • 「High」で来てほしいものが「Low」で来たりしている
  • 解決する方法をサポートするときにクローズ済みの類似incidentを検索したときに「要約」して回答
    • 今だと「解決済みIncidentの検索結果をそのまま返す」ことと「AIが生成した情報を返す」になっている
      • 解決済みIncidentも含めてAIが生成した要約として返せると柔軟かも
  • 社内WikiをKendraへの取り込みとslackで検索
    • 社全体が便利になるので実装したい
    • 実装できるとKendraで運用してもコストメリットを感じられそうな気がしている
      • 社内wikiのデータも今回作成したIndexでindexする前提

Discussion