この業務は日本企業の主戦場にいちばん近い
帝国データバンクの調査（10,312社、AI を売る立場ではない）では、生成AI の用途で文章の作成・要約が 45.1% を占め、コード生成は 5.9% でした（全体像）。
自由記述を読む・まとめるのは、その 45.1% のど真ん中です。この図書館が扱う 3 ツールが得意な領域とは別ですが、実際に使われている領域としてはこちらが本流になります。
分類の軸を機械に作らせない（工程 2）
いちばんよくある失敗が、「この声を分類して」と丸投げして、出てきた分類をそのまま使うことです。
そうすると分類が毎回変わります。先月と今月を比べられません。時系列で見られない分類には、打ち手を導く力がありません。
軸は人が決めます。決め方は 2 つです。
- 既に手が打てる単位で切る — 「価格」「配送」「使い方が分からない」のように、担当部署が決まる単位
- 前回の分類を引き継ぐ — 変えるときは、いつ変えたかを記録する
軸を固定したら、その指示は毎回書き直さずに 1 コマンドにする。同じ軸で回し続けることがこの業務の価値なので、プロンプトが揺れると成果も揺れます。
スコア 0.0 は中立ではない（工程 4）
この手順で最も間違えられているところです。Google Cloud Natural Language API の公式ドキュメントが明記しています。
感情分析が返す値は 2 つあります。
| 値 | 範囲 | 意味 |
|---|---|---|
| score | -1.0（否定）〜 1.0（肯定） | 感情の向き |
| magnitude | 0.0 〜 +inf（文単位は 0.0〜1.0） | 感情の強さ |
そして、
A document with a neutral score (around
0.0) may indicate a low-emotion document, or may indicate mixed emotions
スコアが 0 付近の文書は、「感情が薄い」か「肯定と否定が打ち消し合っている」かのどちらかです。この 2 つはまったく違います。
- 感情が薄い = 事務的な問い合わせ。放っておいてよい
- 打ち消し合い = 「商品は最高だが配送が最悪」。放っておくと失う顧客
両方を「中立」として同じ箱に入れると、いちばん重要な声が消えます。
見分け方も書かれています。
truly neutral documents will have a low
magnitudevalue, while mixed documents will have higher magnitude values
score だけで仕分けてはいけない。magnitude を必ず一緒に見る。 これが工程 4 を独立させ、human_check にしている理由です。
もう 1 つの限界
the API does not identify specific positive and negative emotions
具体的な感情の種類は分かりません。 「怒っている」「困っている」「失望している」の区別はつきません。向きと強さだけです。
「顧客の感情を分析する」と言うとき、得られるのは 2 つの数字だけだと理解しておいてください。
混在を拾うなら文単位で
打ち消し合いを見つけるもう 1 つの方法が、文書単位ではなく文単位で見ることです。同 API はエンティティ単位の感情分析（entity sentiment analysis）も持っています。
「商品は最高だが配送が最悪」を文書として見ると 0 付近ですが、「商品」と「配送」に分けて見れば、それぞれ符号がはっきりします。
打ち手に落とすなら、こちらのほうが直接使えます。 担当部署が分かれるからです。
件数ではなく変化を見る（工程 5）
分類が終わると、多い順に並べたくなります。多い分類は、たいてい構造的なもので、簡単には動きません。
見るべきは増えているものです。
- 先月 3 件 → 今月 30 件 の分類は、何かが起きています
- 先月 500 件 → 今月 480 件 の分類は、去年からずっとそうです
母数の偏りにも注意が要ります。 レビューを書く人と問い合わせをする人は別の層です。工程 1 で出所を列として残しておくのは、後から出所ごとに分けて見るためです。
大量にあるとき
数千件を超えると画面での作業になりません。大量ファイルを一括処理するの形にします。特に、
- 出力の形を JSON Schema で固定する — 分類名が揺れると集計できない
confidenceに相当する欄を持たせる — 分類に迷った件を人が見る- 無作為抽出で一部を人が確認する — 確信度が高いのに間違っている系統は、それ以外の方法では見つかりません（紙の書類をデータにするの工程 4 と同じ考え方）
この分野で分かっていないこと
- 実名の事例が 0 件。 どの企業がどう顧客の声を分析して何を変えたか、という公開記録に辿り着けていない
- 日本語での感情分析の精度についての第三者検証を見つけられていない。皮肉・遠回しな否定・「結構です」のような多義表現をどう扱うかは未確認
- 他社 API を比較していない。 Amazon Comprehend、Azure の同等サービスを確認していないので、これは 1 社の仕様に基づく手順
- 分類の軸をどう決めるかの型が無い（工程 2）。ここを確度 C にしている理由で、業界別の標準的な切り方の資料を見つけられていない