【ITニュース解説】LLM Text Classification: 4 JSON Schema Invariants for Reliable CRM Tags

大規模言語モデル（LLM）が生成するテキストを、顧客関係管理（CRM）システムのような実ビジネスの自動処理に利用する場合、その出力の不確実性が大きな課題となる。LLMは人間が理解できる自然なテキストを生成する能力に優れているが、常に期待通りの厳密な形式で情報を出力するわけではない。そのため、LLMの分類結果がCRMシステムでのタスク作成やフィールド変更、緊急対応のトリガーになるような場面では、その信頼性を確保する仕組みが不可欠となる。

記事では、LLMの出力を受け取る際に、単にAIの指示（プロンプト）に従ってテキストを解析する「プロンプト解析」の限界を指摘している。例えば、「意図 | 緊急度 | 次のステップ」のように区切り文字で情報を区切るようAIに指示しても、AIが余計な一文を加えたり、区切り文字がテキスト内に含まれたりすると、情報がずれてしまい、間違った値がシステムに渡される危険性がある。これは、人間が見たときには一見正しく見えるため、さらに危険なケースだ。プロンプト解析は、単発の分析や試作、人間がレビューするメモのような、結果が多少ずれても問題ない用途には適している。しかし、自動化されたシステムが動作を決定する場合には、信頼できる境界線が必要となる。

ここで重要になるのが「JSON Schema」の活用である。JSON Schemaとは、JSON形式のデータがどのような構造をしているべきか、どのような値が許されるかを定義するルールセットのことだ。これは、LLMのモデルがJSONを「理解」するかどうかではなく、不確実なテキスト生成と、タスクの作成やフィールドの変更といったシステムが実行するアクションの間に、検証可能な「契約」を置くことを目的としている。

この「契約」を信頼性のあるものにするために、記事では特に4つの不変条件（必ず守るべきルール）を挙げている。

1. 語彙（Vocabulary）: 出力される「意図」や「緊急度」といった項目が、あらかじめ決められた選択肢（例: "quote_request", "service_issue"）の中から選ばれていることを保証する。これに反する値はレビューのために隔離する。
2. 型（Type）: 出力される値のデータ型が正しいことを保証する。例えば、「信頼度（confidence）」は0から1の間の数値であるべきで、文字列であってはならない。型が間違っていれば、そのデータを拒否する。
3. 存在（Presence）: システムが処理するために必要なフィールド（例: "follow_up_required"）が、確実に出力に含まれていることを保証する。必須フィールドが欠けていれば、そのデータを拒否する。
4. 不確実性（Uncertainty）: 分類結果の「信頼度」と、その判断に至った「根拠」がセットで提供されることを保証する。信頼度が低い場合、自動処理せずに人間のレビューに回すなど、異なる経路で処理する。

これらのルールは、AIの分類が「正しい」ことを保証するものではなく、「正しくない形式」や「契約に反する形式」の分類を明確に可視化することが目的だ。この違いは、自動生成されたタグが実際の営業タスクにつながるような場合では非常に重要である。

堅牢なシステムを構築するには、以下のような一連の流れが推奨される。まずLLMでテキストを分類し、その生の結果を受け取る。次に、その結果がJSON Schemaに定義された「契約」に合致するかを厳密に検証する。検証に通ったものだけを、必要に応じてシステムが理解できる形に変換（正規化）し、最終的にCRMシステムへの書き込みなどの実際の処理（副作用）を実行する。検証はCRMへの書き込みよりも前に必ず行われなければならない。また、元のLLMからの応答は、問題が発生した際の診断のために、信頼できるデータとは切り離して保持しておくべきである。もし結果の信頼度が低い場合は、自動的に処理せず、人間による確認が必要なキューに回すといった柔軟な対応も可能になる。

記事中には、Pythonのコード例が示されている。これは、LLMからの生の結果（JSON形式のテキスト）を読み込み、jsonschemaライブラリを使って定義済みのCLASSIFICATION_SCHEMAに対して検証を行う具体的な方法を示している。検証に失敗した場合はエラーを捕捉し、レビューのために記録する。また、信頼度が低い場合もレビューに回すという判断ロ組み込んでいる。これにより、検証とビジネスロジックの境界が明確になる。

このような厳密な仕組みは、設計作業、検証コード、テストデータの準備、そしてスキーマ変更時のデータ移行計画など、追加のコストを伴う。また、期待とは異なる形式であっても有用な情報を含んでいる可能性のある応答を拒否してしまうこともある。しかし、誤ったタスクの作成や間違ったタグ付けがビジネスに永続的な影響を与えるCRM書き込みのような場面では、そのコストは十分に正当化される。

一方で、JSON Schemaの利用が適切でないケースも存在する。例えば、人間が結果を読み取るだけで機械的なアクションに繋がらない場合や、分析後に破棄される一時的な探索用データの場合だ。また、LLMの出力が本質的に自由形式の長い記述である場合も、全ての文を厳密なスキーマに押し込めると、かえって有用性が損なわれる可能性がある。この場合は、システムが必要とするメタデータのみをスキーマで制約し、本文は自由形式のままにすることが望ましい。

システムが正しく機能しているかを確認するためには、単に全体的な成功率を見るだけでなく、拒否されたレコードをその理由ごとに分析することが重要だ。例えば、未知の意図による拒否が増えれば、定義されたラベルセットが古くなっている可能性が示唆される。フィールドの欠落が増えれば、LLMへのプロンプトや実行環境に変化があったかもしれない。信頼度の低い分類が増えれば、入力データの品質やAIの判断境界の見直しが必要なサインかもしれない。

結論として、LLMの出力をシステムに連携する際には、そのデータの「形」が信頼できるものであることを保証するためにJSON Schemaを積極的に活用すべきである。プロンプト解析は、人間が介入したり、結果が使い捨てであったりするような、曖昧さを許容できる場面でのみ利用するというのが実践的なルールとなる。物流の電話内容を分類する例では、この境界線が、単なる有用な分類と、自動化されたCRMの間違いとの決定的な違いを生み出すのだ。