はじめに
こんにちは、技術本部 情報セキュリティ部 CSIRTグループの川口です。
本記事は Sansan Advent Calendar 2023 20日目の記事です。
さて、私の所属する情報セキュリティ部では社内のセキュリティに関する問い合わせ対応を行っています。
今回はその問い合わせ業務に焦点を当て、効率向上のための取り組みについて紹介させていただきます。
目次は次のとおりです。
問い合わせ業務について
まずはじめに問い合わせ業務について簡単に説明します。 問い合わせでは不審事象の報告やプロダクトのセキュリティに関する相談など、ジャンルは様々です。 こうした報告をいただくことにより、情報セキュリティ部だけではなかなか把握できないインシデントやその前兆にいち早く気づき、迅速な対応が可能となります。 問い合わせ対応は Slack を活用し、次のフローで行われています。
- Slack で社員から問い合わせがポストされる
- Jira に題目やラベルを割り振る
- 問い合わせ内容から質問内容を把握し、解決策を検討する
- 問い合わせ内容に対して回答する
必要に応じて質問者にヒアリングなども行います。 各問い合わせは Jira(Atlassian（アトラシアン）が提供するプロジェクト管理ツール)) で管理しており、集計や過去事例参照のためにラベルや問い合わせの題目をつけています。 社員も増加傾向にあり、それにともない問い合わせの件数も増加しています。 限られた人数で問い合わせ対応を行うには、問い合わせ対応者がなるべくヒアリングや議論に集中できるように、業務の効率化を進めていく必要があります。
業務効率化に向けて行ったこと
上でも述べましたが問い合わせ業務は Slack 上でやり取りが行われています。 Jira への担当者のアサインやタスクのクローズなどは Slack の Bot 上で処理しています。 今回、このBotをさらに改良し、次の新たな機能を追加しました。
- 問い合わせ内容の要約・見解の生成
- ラベル分類
今回はこれらの機能を GPT を利用して、業務効率化を目指します。 なお、本機能では Azure OpenAI の GPT を利用しており、問い合わせ内容が社外へ出ることや学習に利用されることがないようにしていますv*1。 またこのBotは、Tines という SOAR（ノーコードで自動化するためのサービス） 上で実装されています。 Tines に関する詳細は以前の記事で紹介されていますので、興味があればこちらを参照してください。
問い合わせ内容の要約・見解の生成
GPT のような LLM から望ましい出力を得るためには適切なプロンプト（LLM に対して特定のタスクを実装するように要求する自然言語テキスト）を設計する必要があります。 具体的には次のテンプレートやテクニックを取り入れ、プロンプトを作成しました。
- 深津式プロンプトテンプレート*2
- Role propmpting（役割の明示）
- Chain of thought prompting （思考ステップの教示）
Role prompting（役割の明示）においては、GPT に特定の役割を与え、それに基づいて問い合わせに対する的確な回答を生成させます。 例えば、サポート担当者としての視点やエキスパートの立場からの見解を引き出すことで、ユーザーにとってより適切な情報提供が可能となります。
また、Chain of thought prompting （思考ステップの教示）では、問い合わせに対する論理的かつ段階的な分析を促進します。GPTに対して特定の思考ステップを示唆し、それに基づいて情報を整理して回答を生成させることで、より体系的かつ理解しやすい回答が生成されます。
"システム" あなたはセキュリティエンジニアの専門家であるAI、ショーアです。 問い合わせ内容を分析し、問い合わせに至った背景、質問内容、一般的な見解を生成するのがあなたの仕事です。 以下の制約条件を厳密に守ってロールプレイを行ってください。 # 制約条件 - 内容が全て英語であろうと日本語で返答する - 一般的な見解には必ず解決策を1つは提案する - 問い合わせに至った背景、質問内容、一般的な見解は複数の文章でも良いが、１文は40~60文字以内 - 一般的な見解の文章全体の文字数は１５０文字以内 "アシスタント" 私が問い合わせ内容を提供しますので、あなたはそれを段階的に分析し、問い合わせに至った背景、質問内容、一般的な見解を生成してください。わかりましたか？ "ユーザ" 素晴らしい！では、始めましょう:) 問い合わせ内容: ＜問い合わせ内容＞ 出力:
図1は、問い合わせ Bot が上のプロンプトに基づいて生成したものとなります。 この文章にはプロンプトで要求された問い合わせ内容の要約（問い合わせの背景と質問内容に分けている）と一般的な見解のタスクが実行されています。 また、プロンプトで指定されている条件が適応されていることがわかります。
ラベル分類
問い合わせ内容をもとに"問い合わせ種別"の分類を自動で行えるようにします。 実際の問い合わせ業務ではラベルの種類は次のとおりです。 このとおりにラベルの種類が多く、中々大変です。
--相談-- 相談->実装->認証 相談->実装->権限 相談->実装->アクセス制御 相談->実装->外部サービス連携 相談->実装->アーキテクチャ全体 相談->取扱->情報 相談->取扱->ソフトウェア 相談->取扱->WEBサービス 相談->取扱->機器 相談->運用->業務フロー 相談->営業->チェックシート対応 相談->営業->営業支援対応 --依頼-- 依頼->調査->不審事象調査（不審メール） 依頼->調査->不審事象調査（不審画面表示） 依頼->調査->不審事象調査（脅威検知） 依頼->調査->不審事象調査（外部からの通報） 依頼->調査->不審事象調査（不審電話） 依頼->調査->不審事象調査（訓練メール） 依頼->調査->安全性調査（WEBサイト） 依頼->調査->システム障害調査 依頼->設定->ログ転送設定 依頼->設定->センサー設定 依頼->設定->簡易脆弱性診断 --その他-- その他->該当項目なし その他->問い合わせ対象外
分類精度を向上させるために few-shot プロンプティング*3を利用して、分類させてみましたが精度*4が0.52と望ましい結果が得られませんでした。 精度向上のため、分類精度が低い原因の仮説をたててみました。
- 分類のラベルの種類が多すぎる
- few-shot プロンプティングで過去事例の知識を上手く与えられていない
1.については分類タスクを２段階に分けてみるという方法をとってみました。 つまり、最初の段階で大まかな分類（実装・取扱・運用・営業・調査・設定・その他）をし、次の段階でそれぞれの大まかなカテゴリーに対して詳細なサブカテゴリーを分類します。
2.については、プロンプトにも制限がある*5ので網羅的に例を与えるのは難しいと判断し、Embedding*6 を活用することにしました。 具体的には過去の問い合わせ内容を Embeding でベクトル化し、それをもとにデータセットを作成しました（正解ラベルは今までの業務により手動で割り振られているため、それを利用）。 作成したデータセットをもとに分類器を学習しました。
図2のTines 上で実装されたストーリーでは、青枠の部分で大枠の親ラベルを分類し、赤枠の部分で詳細な子ラベルを分類しています。 この分類器は、SageMakerエンドポイントとAWS Lambdaを活用して学習され、アクセスされています。 1と2の改良を加えたことで、精度は0.88に上がり、few-shot プロンプティングでの分類より分類精度が良くなりました。 また、図3は図1の問い合わせ内容に対しての分類結果を問い合わせ Bot が出力したものですが、問い合わせ種別が正しく分類されていることが分かります。
感想
今回開発した機能は実際の問い合わせ業務で利用されていますが、利用する中で新たな課題や改善点が見えてきました。
1つ目は生成される文章のクオリティについてです。 問い合わせでは GPT に問い合わせ内容の要約と一般的な見解を生成させています。 問い合わせ内容の要約に関しては良好な成果を上げていますが、一般的な見解に関しては、当たり障りのない回答になってしまっています。 そこで過去の問い合わせ事例や規定を活用し、GPT に問い合わせの見解を生成する必要がありそうです。
2つ目としては問い合わせ業務においてGPTを活用している際、テキスト以外のフォーマットへの対応が求められています。具体的には、Slack上での問い合わせではテキストだけでなく、画像ファイルやPDFといったデータも投稿されることがあります。 こうしたテキストだけでなく、画像やPDFなどのデータからも情報を抽出したいと感じました。
まとめ
今回、GPT を活用して問い合わせ内容の要約や見解の生成、問い合わせラベルの分類を自動化し、問い合わせ業務の効率化に取り組みました。
今後は、システムをより改良し、自動化や効率化できる部分に焦点を当てていきたいと考えています。
また、問い合わせ業務以外にも開発やセキュリティ業務にも積極的に LLM を活用していきたいです。
*1:詳細については Azure OpenAI のデータ、プライバシー、セキュリティのガイドを参照してください
*2:note株式会社のCXOである深津貴之氏によって考案されたフレームワーク
*3:例を提示することで、タスクを実行するための方法を学習させるプロンプトテクニック
*4:ここでの評価指標とは全体精度（Overall Accuracy）を指す
*5:Azure OpenAI の gpt-4 の最大トークン数は8,192となっている
*6:単語や文章等をベクトル表現に変換する操作のこと、今回は Azure OpenAI の text-embedding-ada-002を利用している
