カスタマーサポートでは，問い合わせに対して内容に応じたタグを付与し分類することで，タグごとに確立されたフローを用いた効率的な対応を実現するという運用がしばしば採用されるが，タグの付与は解釈と判断を伴う手作業であり負荷が高い．本稿では，こうした運用の効率化に向け，大規模言語モデルによる自動タグ付与の実現可能性を検討する．実験を通じて，タグ観点の多様性（たとえばトラブル内容を表すタグとその原因を表すタグの混在）がタグ付けを単純な多クラス分類タスクへ当てはめることを困難にすることがわかった．最後に，この性質をむしろ強みとして捉え，タグを観点別に整理し各観点からタグ付与を行うことで，問い合わせの意図を多角的に捉える枠組みを議論する．

オペレーターの負担の軽減や迅速な返信による顧客体験の改善への期待から，カスタマーサポートにおける人工知能の活用は長年にわたり検討されてきた．近年では，顧客からの問い合わせに迅速に対応するために，人手による返信対応の代替として大規模言語モデル（LLM）を用いた自動での返信文の生成なども検討されている[1,2]．しかし，LLMの生成文には事実と異なる情報や不適切表現が混入するリスクが残るため，そのまま実運用に適用することは現状では難しい．これに対し，生成された文を人手で最終確認するなどの方法も考えられるが，オペレーション上の抜本的な変更が必要となり，導入の障壁となる．そのため，当初から完全自動生成を目指すのではなく，まず既存の対応フローを活かしつつ，LLMを用いた業務の効率化を検討することが現実的となる．∗本論文において両著者は同等に貢献した．の運用．負荷が高いタグ付与を自動化することにより迅速な問い合わせへの対応を可能とすることを検討する．カスタマーサポートにおける既存の対応フローの例として，問い合わせに対して内容に応じたタグ（たとえば『ログインができない』や『パスワードを変更したい』など）を付与し分類することで，タグごとに確立されたフローを用いた効率的な対応を実現するというものが挙げられる．一方で現場では，問い合わせ内容が何を指し示しているかを解釈して適切なタグを付与する工程に多くの時間を要する．そこで我々は，問い合わせ内容を示すタグを事前定義されたタグ集合からLLMで自動付与する支援ツールに着目する（図1）．本稿では，実際のカスタマーサポートの現場における過去の問い合わせと，それに対して人手で付与されたタグからなるデータセットを用いて，LLMによる自動タグ付与の実現可能性を検討する．実験の結果，近年の高性能なLLMを用いたにもかかわらず人手で付与されたタグとの一致率は52.9%にとどまり，今回の設定のままでは人手のタグ付与をそのまま自動化することは難しいことが示された．不一致の要因を分析したところ，複数観点の併存（たとえばトラブル内容を表すタグとその原因を表すタグの混在）を含むタグ体系に対して「1件につき1タグ」という従来の多クラス分類の問題設定を適用すると，1件の問い合わせに対して妥当なタグが複数成立し得るため，人手タグとの完全一致は難しくなるという構造的な要因があることがわかった．最後に，この性質をむしろ強みとして捉え，タグを観点別に整理し各観点に沿ってタグ付与を行うことThisworkispublishedwithoutpeerreviewandislicensedbytheauthor(s)underCCBY4.0(https://creativecommons.org/licenses/by/4.0/).org/licenses/by/4.0/).準をcheatsheetとして自動生成した．なお，推論時にはデモ例を含めなかった（0-shot）．LLMのモデルパラメータの変動を伴う学習を実施せず，CheatSheetICLを採用した主な理由として以下が挙げられる．解釈性と柔軟性の担保．生成されるcheatsheetは，どのような観点・根拠（推論方針）でタグを選択すべきかを解釈可能な自然言語で明示するため，担当者が非エンジニアでもシステムの誤分類の原因分析が可能となる．さらに，仕様変更や運用ルールの更新が生じた場合でも，非エンジニアの担当者がcheatsheetを直接修正して判断基準の変更を反映できる．特定のモデルへの依存の回避．事前学習済みモデルへの追加学習は，特定のモデル仕様やバージョンに強く依存し，モデル更新のたびに再学習が必要になる可能性がある．一方でCheatSheetICLは，モデルに与える基準を設計する手法であり，同様の指示追従能力を持つ他のLLMにも移植しやすい．4.1.2評価対象とするLLM高い自然言語処理能力が報告されているGoogleGeminiAPI1のgemini-3-pro-previewをcheatsheetの作成およびタグ推論に用いるLLMとして採用した．API呼び出し時のパラメータはすべて初期値とした．4.1.3データ分割データセット（全4,855件）は，学習データと評価データでメール件数が概ね1:1となるように分割した（学習2,427件，評価2,428件）．分割にあたっては，116種類のタグそれぞれについて，学習データと評価データの双方で件数が可能な限り同数となるように層化分割を行った．学習データは，cheatsheet作成時にLLMに与えるデモ例として用いた．具体的には，学習データ中の問い合わせとそのタグを無作為に並び替えてデモ例として与えた．ただし，推論コストと入力トークン数を鑑みて，10件以上のサンプルが存在するタグのデモ例については無作為抽出した10件のみに絞り（各タグ最大10件），最終的にデモ例として用いた問い合わせ件数は404となった．評価データも同様に，推論コストを鑑みて，10件以上のサンプルが存在するタグについては無作為抽1https://ai.google.dev/gemini-api/docs出を施し各タグ最大10件とした．最終的に推論対象とした問い合わせ数は463件となった．評価データの件数が学習データの404件に比べて多い理由は，データセット全体で該当事例が1件しか存在しないタグについては評価データに優先的に含めるよう調整したためである．4.2結果実験の結果，人手で付与されたタグと一致した事例の割合は52.9%（245/463）にとどまった．誤ったタグ付与が不適切な担当者の割当や対応遅延につながりうることを踏まえると，今回用意した手法によって人手によるタグの付与をそのまま自動化することは困難であることがわかった．5分析前節の実験において一致率が低かった要因を分析したうえで，タグ付与の自動化に向けた今後の方針などを議論する．ここでは，3節で述べた本データセットの特徴であるタグ種類数の多さとタグ観点の多様性に着目した分析を行う．5.1タグ種類数の多さの影響前節の実験では，候補タグが116種類と多い状況で，LLMにタグ一覧から1つを選択させる多クラス分類を行った．一般に，クラス数が増えるほど識別境界の設計が難しくなると考えられることから，今回の一致率の低さ（52.9%）は候補となるタグの種類数の多さに支配的な影響を受けた可能性がある．この点を検証するために，現場からのヒアリングに基づき，根本的な内容が同一ではあるもののサービスごとに分割されているタグ（たとえば『ログインできない_サービス名A』と『ログインできない_サービス名B』）などについては，業務上の大きな影響なく統合できる可能性があると判断し，これらを同一タグへ集約した．その上で，学習データ・評価データは前節と同一の分割・同一事例を用いたまま，出力候補タグを67種類に集約した分類問題として同様の手法で再度実験を行った．結果として，一致率は50.3%（233/463）となり，一致率の向上は見られなかった．このことは，少なくとも本研究で用いたCheatSheetICLに基づく推論手法においては，クラス数の増加に対してある程度頑健であり，候補となるタグの種類数の多さ自体が正解率の低さを支配的に規定していない可能性を示唆する．org/licenses/by/4.0/).一致率．タググループタグ数事例数一致率発生事象1822973.8%原因148578.8%要望126889.7%案内方針204175.6%その他124065.0%5.2タグ観点の多様性の影響3節で述べたように，本データセットでは，問い合わせの内容に対して付与されるタグが単一の観点に基づき体系化されているわけではない．たとえば，タグ候補に『ユーザが抱える問題』を表すものと『ユーザが期待する対応』を表すものが混在している場合，ひとつのメールに対して観点A（問題）ではタグ𝑎を付与することが適切であり，観点B（期待する対応）ではタグ𝑏を付与することが適切である，というように複数のタグが同程度に妥当となりうる．一方で，本実験ではどの観点でタグ付与を実施するかを指定しないまま各問い合わせに対して正解タグを1つに定める従来の多クラス分類の設定を採用した．このようなデータの性質と実験設定の間の齟齬が，結果における低い一致率の一因となっている可能性がある．この仮説を確認するため，観点の異なりごとにタグをグルーピングし，タググループ内（すなわち観点が比較的揃った範囲）であれば同一手法で適切な分類が可能かを検証した．具体的には，まず前節の検証で用いた67種類のタグを，観点ごとのタググループに分割した．方法として，タグ候補一覧と各タグに該当する問い合わせ最大10件をプロンプトとしてLLMに与え，観点ごとにタグを分類させたうえで，その結果を土台として著者が統合・分割の修正を行い，最終的に5つのタググループを作成した．タググループは，『発生事象（ユーザが抱える問題）』，『原因（ユーザが抱える問題の原因）』，『要望（ユーザが期待する対応）』，『案内方針（運営側が取るべき対応）』，『その他』の5種類になった．各グループに属するタグ数および評価データ中の事例数を表1に示す．次に，それぞれのグループに属するタグが付与された問い合わせのみを学習データおよび評価データから抽出し，抽出後のデータに対して4節と同一の設定で多クラス分類を実施した．各タググループにおける人手のタグとの一致率をおける候補タグ数が小さくなったため4節や前節との単純な比較は難しいものの，全グループにおいて高い一致率となった．以上より，複数のタグ観点が含まれやすい実データに対してタグ付与を実施する観点を指定しないまま「1件につき1タグ」という従来の多クラス分類の設定を当てはめたことで，多クラス分類問題として見ると人手と完全一致しないが生じた可能性が示唆される．6議論：多観点でのタグ付与の応用前節では，多様な観点を含むタグ体系の下で各問い合わせにつき1タグという設定を採用した場合は人手タグを一意に再現することが難しくなる一方，少なくともタグ候補を同一観点に絞ったタグの付与では高い一致率が実現できることを確認した．この結果は，問い合わせ対応の実運用における多角的なタグの自動付与の実現可能性を示唆する．この知見を活かした支援システムの例として，問い合わせに対して単一のタグを付与するのではなく，観点ごとに多角的なタグ付けを行い，各観点に紐づく返信テンプレート群から最適なものを選択するシステムが挙げられる．あるいは，各観点に紐づく返信テンプレート群のそれぞれから必要な部分だけを抜き出し組み合わせていくことで，より個別の問い合わせに合った返信テンプレートを作成するといった方向性も考えることができる．7おわりに本稿では，カスタマーサポートにおける人手返信を前提とした支援技術として，実際の問い合わせログを対象に，LLMによる自動タグ付与の実現可能性を検討した．CheatSheetICLに基づき，学習データからタグ付与の判断基準を自然言語のcheatsheetとして自動生成し，推論時にはタグ一覧と問い合わせ文を入力としてタグを選択させる枠組みを用いた．検証の結果，今回の設定のままでは人手のタグ付与をそのまま自動化することが難しいことが示された．一方で，タグ観点がデータセット内で多様である場合，1件の問い合わせに対して妥当なタグが複数生じうることが本実験設定上での誤りとなってしまう点を分析し，観点ごとにタグを整理することで分類の見通しが改善する可能性を確認した．org/licenses/by/4.0/).