Back to Blog
TypeSafeJevAIAPI業務効率化

LLMを使わない高速AI判断 — TypeSafe/Jevで問い合わせを担当者に自動振り分けしてみた

LLMを使わない高速AI判断 — TypeSafe/Jevで問い合わせを担当者に自動振り分けしてみた

問い合わせ内容を読んで、どの担当者に回すべきかを判断する。人間なら数秒でできるこの作業を、LLM（Claude、GPTなど）にやらせている現場は多い。ただし分類・振り分けのような単純な判断のために、対話や文章生成を前提としたモデルをフル稼働させるのは、速度・コストの両面で過剰という見方もできる。

TypeSafeは、この種の「判断」だけを高速に返すサービスとして、System Oneというモデルカテゴリを提供している。その最初のフラッグシップモデルがJevだ。今回はJevを使い、問い合わせ内容を4人の担当者の中から自動で振り分けられるかを試した。

TypeSafe/Jevとは何か

TypeSafeは、AIによる判断を「プログラミングのプリミティブ」のように扱えるサービスとして設計されている。従来のLLM呼び出しのように自由形式のテキストを受け取ってパースするのではなく、あらかじめ定義した型の答えを、確率つきで直接返してくる。

System Oneはそのモデルカテゴリ全体の名称で、テキスト生成ではなく判断（ルーティング・分類・スコアリングなど）に特化している。Jevはこのカテゴリの旗艦モデルであり、自然言語を理解した上で型付きの回答と確率分布を返す。

従来のLLMとの違いを整理すると、次のようになる。

観点 従来のLLM（Claude/GPT） TypeSafe（Jev）
レスポンス速度 数秒程度 数十〜数百ミリ秒程度
出力形式 自由形式テキスト（パースが必要） 型付きJSONを直接返却
不確実性の扱い 明示的な確信度なし 確率分布・confidenceつき
主な用途 対話・生成・複雑な推論 ルーティング・分類・スコアリング

対話や長文生成が必要な場面ではLLMに分がある一方、「AかBか」「どの担当者か」といった判断だけを大量に処理したい場面では、Jevのような型付き・確率つきの判断モデルの方が扱いやすいと言える。

なぜ「部署振り分け」ではなく「担当者振り分け」を選んだか

Jevの実力を試すユースケースとして、部署振り分け（3〜5択程度の分類）ではなく、あえて個人単位の担当者振り分けを選んだ。部署レベルの分類はキーワードマッチでもある程度対応できてしまうが、10〜50人規模の担当者から1人を選ぶには、各自のスキルセットと問い合わせ内容の意味を照合する理解力が必要になる。専門性や複合的な条件を踏まえた判断が必要になるため、確信度による自動/手動フローの分岐も自然に発生する。

今回用意した担当者データは以下の4人。

ID 名前 スキル
tanaka 田中 認証、OAuth、セキュリティ、SSO
suzuki 鈴木 API設計、バックエンド、データベース
yamada 山田 フロントエンド、React、UI/UX
sato 佐藤 決済、請求、Stripe連携

APIリクエストは、問い合わせ内容と担当者リストをstateとして渡し、choiceタイプの質問で「最も適切な担当者」を選ばせる構造にした（APIの詳細はAPIリファレンスを参照)。

{
  "state": {
    "ticket": "問い合わせ内容",
    "assignees": [
      { "id": "tanaka", "skills": ["認証", "OAuth", "セキュリティ", "SSO"] },
      { "id": "suzuki", "skills": ["API設計", "バックエンド", "データベース"] },
      { "id": "yamada", "skills": ["フロントエンド", "React", "UI/UX"] },
      { "id": "sato", "skills": ["決済", "請求", "Stripe連携"] }
    ]
  },
  "model": "jev-latest",
  "questions": {
    "assignee": {
      "type": "choice",
      "instructions": "問い合わせ内容と各担当者のスキルを照合し、最も適切な担当者を選んでください",
      "criteria": {
        "tanaka": "認証、OAuth、セキュリティ、SSOに関する問い合わせ",
        "suzuki": "API設計、バックエンド、データベースに関する問い合わせ",
        "yamada": "フロントエンド、React、UI/UXに関する問い合わせ",
        "sato": "決済、請求、Stripe連携に関する問い合わせ"
      }
    }
  }
}

結果はどうだったか

3種類の問い合わせを投げて、選ばれた担当者と確信度、確率分布を確認した。

ケース1: OAuth問題（明確なケース）

問い合わせ:「OAuth連携でトークンが更新されません。リフレッシュトークンの有効期限切れかもしれません。」

結果項目 値
選択された担当者 tanaka（田中）
確信度 1.0（100%）
確率分布 tanaka: 100%、他: 0%

OAuthの専門家である田中に、迷いなく振り分けられた。

ケース2: 請求問題（明確なケース）

問い合わせ:「請求書のPDFが文字化けしています。Stripe連携の設定を確認してほしいです。」

結果項目 値
選択された担当者 sato（佐藤）
確信度 1.0（100%）
確率分布 sato: 100%、他: 0%

こちらも決済・Stripe担当の佐藤に正しく振り分けられた。

ケース3: API + ダッシュボード（曖昧なケース）

問い合わせ:「APIからデータを取得してダッシュボードに表示したいのですが、うまく動きません」

結果項目 値
選択された担当者 suzuki（鈴木）
確信度 0.69（69%）
確率分布 suzuki: 77%、yamada: 22%、tanaka: 1%

「API側の問題」なのか「表示（フロントエンド）側の問題」なのかが問い合わせ文だけでは判断しきれず、確信度が下がる形になった。suzukiが選ばれつつも、yamadaにも一定の確率が振られている点に、判断の「迷い」がそのまま数値として表れている。

入力トークンは約600、出力トークンは約52程度で、テキスト生成を伴わない分、レスポンスも軽量だった。

何が分かったか

明確なケースでは確信度100%で正しく判定される一方、曖昧なケースでは確率分布に迷いが反映される、という挙動が確認できた。この特性を使えば、「確信度0.7未満なら上位2名を候補として人間に提示する」といったフロー設計が自然に組める。LLMの出力を都度パースして確信度を後付けで推定するよりも、最初から型付きの確率として扱える方が、コードに組み込みやすいと言える。

今回試したのは4人・1問という小さな構成だが、実際の運用を想定すると、担当者が増えた場合の精度や、複数の判断基準（専門性と負荷の両方を考慮するなど）を組み合わせたケースも試す価値がある。ドキュメントにはChoiceプリミティブ以外の判断タイプも用意されているため、スコアリングを絡めた振り分けロジックも次の検証候補になりそうだ。

Share:
View all posts