©MIXI 1 Zendeskのチケットを Amazon Bedrockで 解析した 2025/08/27 CRE Camp #2 株式会社MIXI みてね事業本部 プラットフォーム部 CREグループ ⼩菅 諒( @ryokosuge ) 

2 ©MIXI ⾃⼰紹介 ⼩菅 諒（こすげ りょう） 1990/02/12 ⽣まれ（35歳） 株式会社MIXI(2024/03 ~ • 『家族アルバム みてね』CRE 3⼈家族（妻と4歳の娘） ⽣まれる前からみてねユーザー 知⼈に紹介してもらって、⼊社できました 

©MIXI 3 『家族アルバム みてね』について 

4 ©MIXI 『家族アルバム みてね』について 家族アルバム みてねはスマホで撮った⼦どもの写真や動画を家族と共有し、 コミュニケーションして楽しむ家族アルバムサービスです。 

5 ©MIXI 『家族アルバム みてね』について 〜10年の歩み〜 2015年4⽉にリリースして、ことし10周年 ● 7⾔語‧175の国と地域でサービスを提供 ● 2025年1⽉に利⽤者数が2,500万⼈を突破 

©MIXI 6 家族アルバム みてねのCRE 

7 ©MIXI Reliable Customer Experience CRE Responsibility CRE 管理ツールの開発 お問い合わせ調査 / 対応 配信ツールの開発 / 運用 お問い合わせ 対応 Marketing CS プロモ 配信 安心・安全 なUX 不正アクセス対策 ユーザーの認証強化 

8 ©MIXI 今⽇知ってもらいたいこと 

9 ©MIXI ● ユーザーからのお問い合わせのカテゴライズをLLMにさせると、とても 精度の⾼い結果がでる（はず） ● 試すにはできる限り多くのコンテンツ（≒お問い合わせ）があるとより いい ● 今⽇の話を元に、Amazon Bedrockをプロダクトで使おうと判断 ○ 現在開発中（そろそろリリース） 今⽇知ってもらいたいこと 

10 ©MIXI ● どうして解析することにしたのか ● Amazon Bedrockを使う前に調査したこと ● 解析するときにやったこと ● 解析した結果どういうネクストアクションが取れたか ● まとめ アジェンダ 

11 ©MIXI どうして解析することにしたのか 

12 ©MIXI ● CREチームの⽬標の１つに「お問い合わせを◯%、⾃動返信する」がある ○ これを達成することでCSチームのお問い合わせ対応の余裕が⽣まれるように なる ● この⽬標⾃体には去年の後半くらいから継続的に取り組んでいる ● 最初、⾃動返信できるだろうという想定のものがいくつかあった ○ 対応フローが整っているもの ○ 定型⽂を返すだけの運⽤をしているもの ● ZendeskのWebhookを受け取りチケットにある情報を使って分岐を作り、まずは プライベートコメントをチケットに残す形で運⽤を始めた どうして解析することにしたのか（背景） 

13 ©MIXI けど中々うまく進まなかった... 

14 ©MIXI ● タイトルをみて「〇〇」という⽂⾔が含まれていたらAの対応をする、みたいな形 ○ ただユーザーが解決して欲しいことは本⽂にしか書いてない ● そのため⾃動で投稿したプライベートコメントと実際のCSチームの⼈の対応が違 うということが起きた ○ 精度を上げるために、条件を厳しく（除外したり、厳格化したり）した ● 他に⾃動返信の対応ができそうなものがあるか、Zendeskチケットを⽬視で探し てみた ○ ⽬で⾒て数⼗件とかなので、良いものも⾒当たらなかった どうして解析することにしたのか（進まなかった理由） 

15 ©MIXI 結構⼿詰まりな状態になっていた... 

16 ©MIXI ● マネージャーとの1on1で⾃動返信の⽬標についての現状の課題について話をした ● 改めて、お問い合わせ内容について知らないことが多すぎるねとなった ○ チケットを⽬視で数⼗件⾒たって何もわからない ● じゃあ知れるような仕組みって何かないかとなり、LLMに要約させるのはどうかと いう話になった ● ZendeskのAPIがあることも知っていたし、開発環境でAmazon Bedrockが使える ようにSREチームが整備してくれていたので、試す環境も整っていた ● ChatGPTに相談したところ、数⼗⾏のコードでできることもわかったので、対応 を進めることにした どうして解析することにしたのか 

17 ©MIXI そうだ、LLMに解析させてみよう 

18 ©MIXI Amazon Bedrockを使う前に調査したこと 

19 ©MIXI ● お問い合わせ内容をプロンプトの中に含めるのは問題ないか ○ これは法務の⼈とも相談して、⽇本国内のユーザーのみ可とした ● どれくらいお⾦がかかるか ○ 1000件のチケットなので、1000回プロンプトを実⾏する ○ お⾦がかかりすぎるなら問題だから事前に調査 ○ ここもAmazon Bedrockにある⾦額のページをChatGPTに教えて計算しても らった ■ インプットとアウトプットを合わせた⾦額をモデルごとに出してもらう ● お⾦とモデルのスコアを照らし合わせて、最適なものを使うようにした ○ 今回は⽇本語に強いClaudeさんにお世話になりました Amazon Bedrockを使う前に調査したこと 

20 ©MIXI どういったアウトプットを求めるか 

21 ©MIXI { "inquiry_summary": "お問い合わせ内容の要約", "inquiry_type": "カテゴリ名", "response_summary": "対応内容の要約（100⽂字程度）", "data_sources": ["ソース1", "ソース2", ... または "なし"], "confidence_score": 数値（0.0〜1.0の範囲） } Amazon Bedrockを使う前に調査したこと（出⼒内容） 

22 ©MIXI ● タイトルと本⽂を使ったカテゴライズとサマライズ ● 社内ユーザーのコメントをまとめた、対応内容のサマライズ ● 参考にしているソース ○ ヘルプページのURLや管理画⾯のURLなど ● 信憑性の評価 上記の要素をLLMで解析して、Zendesk APIで取得したチケット情報をまとめることに した Amazon Bedrockを使う前に調査したこと（出⼒内容） 

23 ©MIXI 解析するときにやったこと 

24 ©MIXI ● まずはZendesk APIからチケット情報を取得する ○ できる限り多くのチケットが欲しかったので、MAXで取れる1000件 ■ 違うAPIを使うと全部取得できる情報はあったので、1000件を使って満 ⾜できなかったらチャレンジしようと思っていた ● Zendesk公式のRuby SDKを使う場合はMAX 1000件 ● チケットの情報をLLMが読みやすいようにJSONに加⼯ ○ tickets.jsonのファイルにして1000件分のチケット情報を書き込む ● tickets.jsonをパースして、プロンプトにJSONの詳細情報と1件のJSON渡して解 析する ● 解析結果とチケット情報を⾜してCSVにする ● CSVをスプレッドシートにインポートしてチームメンバーに共有 解析するときにやったこと 

25 ©MIXI 以下の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": "本⽂（テキスト）" } ] } } 解析するときにやったこと（プロンプト） ### 出⼒フォーマット（厳守） 以下の形式の**JSON⽂字列**のみを返してください。マー クダウン記法やコードブロックは使⽤しないでください。 { "inquiry_summary": "お問い合わせ内容の要約", "inquiry_type": "カテゴリ名", "response_summary": "対応内容の要約（100⽂字程 度）", "data_sources": ["ソース1", "ソース2", ... または "なし"], "confidence_score": 数値（0.0〜1.0の範囲） } チケット情報： %{ticket_json} ### ステップ1: お問い合わせ内容の要約（100⽂字程度） `subject`と`description`をもとに、お問い合わせの主旨を 簡潔に要約してください。 ### ステップ2: カテゴリ分類 次のカテゴリのうち、**最も該当する1つだけ**を選んでく ださい。なければ「その他」としてください。 - ⾊々なカテゴリ... - その他 ### ステップ3: 対応内容の要約（100⽂字程度） コメント全体（`comments`）を時系列で読み、**対応と して実施されたこと**を100⽂字程度で要約してください。 特に公開/⾮公開の区別、投稿者の種類に注意してくださ い。 ### ステップ4: 参照されたデータソースの抽出 コメントのうち、**担当者または社内ユーザー**による記 述から、対応時に参照された資料‧画⾯‧社内ドキュメント などがあれば箇条書きで抽出してください。 なければ `"なし"` と記載してください。 

26 ©MIXI 解析するときにやったこと（解析結果） 

27 ©MIXI 解析した結果どういうネクストアクションが取れたか 

28 ©MIXI ● ⾃動化できるカテゴリが複数個⾒つかった ○ CSからユーザーへメールを送信していることがわかった ■ 仕組みがあること⾃体知らなかった ■ それもDBに保存されたタイミングで⾃動送信できることがわかった ○ チケットの⾃動返信できるものが⾒つかった ■ 信憑性がとても⾼く（スコアでいうと0.9以上） ■ パブリックコメントのみ（定型⽂のみ返してる） ● 思っていた以上に、とあるカテゴリのお問い合わせが多いことがわかった ○ これは課題として前からあるやつが可視化された状態になった ● サービスからのメール（投稿されましたみたいなお知らせ）に対してコメントを 返してるおじいちゃん、おばあちゃん 解析した結果わかったこと 

29 ©MIXI ● Amazon Bedrockを使って、Zendeskのチケット作成のタイミングで解析するよう にする ○ 想像以上の成果がでたので、ほぼリアルタイムで使えるように対応を進める ○ ⼀気に乗り換えるのではなく、少しずつ対応と数字を⾒ながら進めてる ● CSチームの温かい⼿動対応を⾃動化した ○ DBに登録した後、Zendeskからユーザーへメールを送っていた ○ できそうだねとなってから、⾊々ヒアリング ○ 無事対応して、現状は⾃動送信になっている ● この仕組みを使って特定のカテゴリのZendeskチケットの解析をしたり、他チー ムの解析の協⼒ができた 解析した結果どういうネクストアクションが取れたか 

30 ©MIXI まとめ 

31 ©MIXI ● チームとして⼿詰まりな状況を打開することができた ○ 銀の弾丸はなかった ○ チームで悩みに悩んで、都度相談した結果、⾒つけられた ● CREチームはCSと隣のチームで定例もしてるのに、知らないことがまだまだ圧倒 的に多かったことがわかった ● ⽬視で1000件のチケットを⾒ることとはまた違うけど、網羅することができた まとめ 

32 ©MIXI ご清聴ありがとうございました