はじめに
8月27日に以下のイベントで「ZendeskのチケットをAmazon Bedrockで解析した」のタイトルで登壇しました。
以下は登壇で使ったスライドになります。
この記事では、登壇内容の技術的な部分について詳細に説明します。
解析をするに至った背景等を詳しく知りたい場合はスライドを参照してください。
この記事を読んでわかること・わからないこと
この記事では以下の内容について扱っています。
わかること
- Amazon Bedrockを使う前に調べたこと
- ユーザーからのお問い合わせの解析に使ったプロンプト
わからないこと
- 具体的な金額
- 生成AIによる計算方法を記載しているので、そちらを参考にしてください
- 解析結果
- お問い合わせ内容が含まれているため公開を控えています
主にAmazon Bedrockの導入準備、実装方法、運用結果についてまとめています。
Amazon Bedrockを使う前に調査したこと
個人情報の取り扱い
お問い合わせ内容や、その中に含まれている情報をLLMに送信することの可否について検討しました。
各社の規約を収集し、法務とも検討を重ねながら慎重に進めました。
コスト試算
解析実行時に想定外の金額になることを避けるため、プロンプトを作成し、想定トークン数を算出した後、ChatGPTにAmazon Bedrockの料金ページを渡して試算を依頼しました。
このページにモデルごとのinputとoutputの金額が書かれているので、それに合わせて計算を依頼しました。
使用するモデル
コストの計算が完了した後、モデル選定を行いました。
今回は試算の結果、コストが非常に低いことが確認できたため、日本語に強いAnthropicのClaudeを採用することにしました。
どのようなアウトプットを出すか
{
"inquiry_summary": "お問い合わせ内容の要約",
"inquiry_type": "カテゴリ名",
"response_summary": "対応内容の要約（100文字程度）",
"data_sources": ["ソース1", "ソース2", ... または "なし"],
"confidence_score": 数値（0.0〜1.0の範囲）
}
この形式での出力を設定しました。
お問い合わせのサマライズとカテゴライズ、CSチームの対応のサマライズ、対応に使用したソース（管理画面やヘルプページのリンクなど）、そして生成AI自体のアウトプットに対する信頼性スコアを出力する設計にしました。
解析時の実装内容
実装した内容
- Zendesk APIを使って条件にあるタグがついているチケットを1000件取得
- Zendesk公式のRuby SDKを使った場合は1000件が上限
- 他のAPIを使用すると全件取得可能でしたが、1000件で十分な結果を得ることができました
- 取得したチケットの情報をLLMが読みやすいようにJSONに加工
- tickets.jsonという形で1000件分のチケット情報を1つのファイルにまとめる
- tickets.jsonをパースして、1件ずつプロンプトに含めて解析
- 解析した結果とticket情報をCSVに追加する
- 1000行のCSVをスプレッドシートにインポートしてチームメンバーに共有
プロンプト
以下のZendeskチケット情報を分析し、以下の手順に従って解析してください。
入力されるJSONの形式は以下の通りです（読み取り専用）：
{
"ticket": {
"id": 数値（チケットID）,
"subject": "件名",
"created_at": "UTC形式の日時",
"status": "状態",
"tags": ["タグ1", "タグ2", ...],
"to": "宛先メールアドレス",
"description": "本文（テキスト）",
"comments": [
{
"author_type": "お客様/担当者/社内ユーザー",
"created_at": "日時",
"is_public": true/false,
"body": "本文（テキスト）"
}
]
}
}
### ステップ1: お問い合わせ内容の要約（100文字程度）
`subject`と`description`をもとに、お問い合わせの主旨を簡潔に要約してください。
### ステップ2: カテゴリ分類
次のカテゴリのうち、**最も該当する1つだけ**を選んでください。なければ「その他」としてください。
- [ログイン関連]、[決済関連]、[アカウント関連]など
- その他
### ステップ3: 対応内容の要約（100文字程度）
コメント全体（`comments`）を時系列で読み、**対応として実施されたこと**を100文字程度で要約してください。特に公開/非公開の区別、投稿者の種類に注意してください。
### ステップ4: 参照されたデータソースの抽出
コメントのうち、**担当者または社内ユーザー**による記述から、対応時に参照された資料・画面・社内ドキュメントなどがあれば箇条書きで抽出してください。
なければ `"なし"` と記載してください。
### 出力フォーマット（厳守）
以下の形式の**JSON文字列**のみを返してください。マークダウン記法やコードブロックは使用しないでください。
{
"inquiry_summary": "お問い合わせ内容の要約",
"inquiry_type": "カテゴリ名",
"response_summary": "対応内容の要約（100文字程度）",
"data_sources": ["ソース1", "ソース2", ... または "なし"],
"confidence_score": 数値（0.0〜1.0の範囲）
}
チケット情報：
%{ここにチケット情報を載せたjsonデータを入れる}
このプロンプトをチケット1件ずつ実行しました。
1回の実行に数秒を要すること、さらにリクエスト過多を避けるため間隔を空けて実行していたため、全件解析を完了するまでに相当な時間を要しました。
解析結果
解析の結果、以下の知見を得ることができました。
- 自動返信が可能であることがわかったカテゴリ
- 定型文の返信だけで問題が解決しているもの
- ユーザー起因ではない、別のオペレーションフロー
- 条件もわかり、自動化対応が可能
終わりに
Amazon Bedrockを使った解析により、次にどのような対応をするかを決めることができました。
お問い合わせ対応における同様の課題を抱えている人や組織の方々の参考になれば嬉しいです。
最後にイベントについて
今回参加したCRE Campでは、社内向けのAI導入事例やCREのチーム評価に関する発表などがあり、内容も多岐にわたって非常に興味深いイベントでした。
またCRE Campの特徴として、懇親会で各社のCRE / CSエンジニアとの活発な議論が行われます。
次の開催も決まっている（イベントページは準備中です）ので、参加を検討している方がいらっしゃいましたら、ぜひ参加してみてください。
以上です。
Discussion