条件分岐・分類モデル・生成AI、どれで判断する？ 3方式の選び分け
問い合わせの振り分けや入力内容の判定を自動化するときの選択肢は、大きく3つです。結論から言うと、判断基準を言葉で書き切れて入力の形も決まっているなら条件分岐（固定ルール）、同じ判定を大量に繰り返していて正解ラベル付きのデータが貯まっているなら分類モデル、基準を「こういう場合はこちら」と例でしか説明できない自由文が相手なら生成AIが向きます。そして最初に試すべきなのはほぼ常に条件分岐です。ルールで何件さばけて、どこで間違えるかを測らないと、次の方式を選ぶ基準そのものが作れないからです。
3方式の違いは「判断基準をどこに置くか」
条件分岐は、人が書いた条件式がそのまま基準です。キーワードの一致、選択フォームの値、ドメイン、金額のしきい値などで分岐します。同じ入力には必ず同じ結果が返ります。
分類モデルは、正解ラベルを付けた過去データから基準を学習します。基準はコードではなくモデルの内部にあり、人が直接読むことはできません。代わりに、各カテゴリの確からしさ（スコア）が出るため、「自信がない案件は保留して人が見る」という運用に落としやすい形式です。
生成AIは、自然言語で書いたカテゴリの定義をそのまま基準にします。学習データがなくても動き、構造化出力（JSONスキーマを指定して出力形式を固定する機能）を使えば、カテゴリ名をenumで列挙して想定外の文字列が返らないようにできます。OpenAIの公式ドキュメントも、分類やモデレーションを構造化出力の代表的な用途として挙げています。
判断の安定性：決定的か、確率的か
条件分岐は決定的です。再実行しても結果は変わらず、なぜその結果になったかを条件式で説明できます。監査や説明責任が求められる判定では、この性質自体が価値になります。
分類モデルと生成AIは確率的です。ここで誤解されやすいのが構造化出力の役割で、保証されるのは「スキーマに適合した形で返ること」であって、中身が正しいことではありません。公式ドキュメントも構造化出力は「間違いを含むことがある」と明記しています。さらに、安全上の理由で拒否（refusal）が返る場合や、トークン上限で応答が途中で切れる場合があり、スキーマと無関係な入力が来ると辻褄合わせの出力を生む可能性も指摘されています。
実装上の意味は明確です。enumで値域は守れるので「未知のカテゴリ名が流れてくる」事故は防げますが、拒否・未完了の分岐処理と、業務ルール側の検証（例：解約カテゴリなのに契約IDが空）は別途必要です。保留や既定カテゴリへのフォールバックを最初から設計に入れてください。
変更のしやすさ：増えるのは条件か、データか、プロンプトか
条件分岐の変更はコードの差分として残り、レビューもロールバックも容易です。弱点は条件が増えたときで、Googleの「Rules of Machine Learning」は、単純なヒューリスティックは製品を出すのに十分でも、複雑なヒューリスティックは保守できなくなるとして、その段階で機械学習に移ることを勧めています（Rule #1・Rule #3）。分岐が十数本を超えて相互に干渉し始めたら、方式を変える合図です。
分類モデルの変更コストはデータに乗ります。カテゴリを1つ増やすだけでもラベル付けと再学習が要るため、分類軸が頻繁に変わる業務とは相性が悪い一方、軸が固定された大量処理では推論が速く安価です。
生成AIの変更は、カテゴリの追加であればenumと説明文を足すだけで即日反映できます。ただし文章での指示は影響範囲が局所化しないため、1カテゴリの説明を直したら別のカテゴリの判定が変わることがあります。スキーマにも上限（オブジェクトのプロパティ5,000件、ネスト10階層、enum値は合計1,000件まで）があり、分類軸が巨大になるなら2段階に分ける設計が必要です。スキーマとコードの型がずれないよう、SDKのスキーマヘルパーを使うことも公式に推奨されています。
検証方法：3方式で測るものが違う
条件分岐の検証は通常の単体テストです。境界値と分岐の網羅を書けば、期待どおりかを完全に確認できます。
分類モデルは、学習に使っていないデータでの評価が前提になります。全体の正解率だけでなく混同行列を見て、どのカテゴリがどこに誤って流れているかを確認します。誤振り分けのコストは方向によって違うので、「取りこぼしたくない」のか「誤検知を避けたい」のかに応じて再現率と適合率のどちらを優先するかを先に決めておきます。
生成AIも同じ考え方で、人手でラベルを付けた評価データセットと採点ルールを用意します。OpenAIのevalsガイドは、ITサポート問い合わせを3カテゴリに分類する例で、「タスクを評価として記述する→テスト入力で実行する→結果を分析して改善する」という3段階を示し、人手ラベルと出力の完全一致を見るstring_checkグレーダーを使っています。より柔軟に採点したい場合は、文字列一致・類似度・LLMによるスコア付けやラベル付け・Pythonコードといった採点方法を選べます。判定が一語のカテゴリ名なら、まずは完全一致で十分です。
運用面で注意したいのは、採点基盤を特定のマネージドUIに依存させないことです。OpenAIは現在Evalsプラットフォームの提供終了を予告しており、既存ユーザー向けに2026年10月31日に読み取り専用化、2026年11月30日に停止予定とされ、新規にはDatasetsの利用が案内されています。評価データとグレーダーは自分のリポジトリに置き、CIから回せる形にしておくほうが安全です。
どれから試すかを決める手順
- 判定結果の使われ方を決める。自動で振り分けて終わりか、人が確認するのか。誤判定1件あたりの実害（折り返し遅延、誤った自動返信、取りこぼし）を書き出す。
- 直近の問い合わせを50〜100件取り出し、人手で正解カテゴリを付ける。これが評価データと、人間の一致率という上限の目安になる。
- その100件に対し、素朴な条件分岐（キーワード、フォームの選択値、送信元）で何件正しく振り分けられるかを数える。目標品質に届くなら条件分岐で確定。
- 届かない場合、誤りの内訳を見る。条件を数本足せば直るなら条件分岐のまま改良する。自由記述の言い回しの多様さが原因なら生成AIへ、カテゴリが安定していてデータが数百件以上あるなら分類モデルへ進む。
- 生成AIを選ぶ場合は、enumでカテゴリを固定した構造化出力にし、「判断できない」を正規のカテゴリとして用意する。拒否と未完了の処理も書く。
- 同じ100件で再評価し、ルール版との差分を確認する。以降、モデルやプロンプトを更新するたびにこの評価を回す。
運用に乗せる段階では、方式はひとつに絞らなくて構いません。確実に判定できるものはルールで先に振り分け、残りを生成AIに回し、低信頼の案件は人が見る、という多段構成が現実的です。ログが貯まればそれが学習データになり、量が増えて単価が問題になった時点で軽量な分類モデルへ寄せる判断もできます。
最初の一歩は、新しい技術の選定ではなく「過去100件のラベル付け」です。評価データさえあれば、3方式のどれを選んでも良し悪しを数字で比べられ、方式を乗り換えるときも判断に迷いません。
出典
この記事に関連するchot Inc.の支援
chot Inc.は日本初のVercel公式パートナーとして、Next.jsを中心としたWebサイト・Webアプリケーションの開発を支援しています。Vercelの導入・契約・運用の見直しはVercel公式パートナー開発支援で、Next.jsによる新規開発や既存システムからの技術移行はモダンWeb開発で紹介しています。
