【ITニュース解説】Structured AI Decisions in Quote-to-Cash: Using TypeSafe's Jev Model

企業が顧客に見積もりを提示してから、契約、製品やサービスの提供、請求、そして最終的な入金に至るまでの一連の業務プロセスを「Quote-to-Cash（O2C）」と呼ぶ。このO2Cプロセスの中には、実は自動化が難しい小さな判断ポイントが数多く存在する。例えば、「この契約条項は標準的なものか、法務レビューが必要か？」「この請求書への返信は異議申し立てか、それとも支払い約束か？」「この注文は請求処理に進む前に手動承認が必要か？」といったものだ。

これまで、このような判断を自動化する一般的な方法として、厳密なルールをプログラムに組み込むか、あるいは全て人間が手動で判断するという二つのアプローチが取られてきた。しかし、ルールをプログラムで書くと、想定外のケースに対応できず、柔軟性に欠けるという問題がある。一方、人間が全て判断すれば正確性は保たれるが、業務量が増えるにつれて規模の拡張が難しくなる。

近年、大規模言語モデル（LLM）のようなAI技術の進化により、この状況は変わりつつある。テキストデータをLLMに送り、その内容を分類させるというアプローチが一般的になってきた。しかし、ここにも課題があった。一般的なLLM、特にチャットAIは、質問に対して自由形式のテキストで回答を生成する。例えば、「これは緊急か？」と質問すると、AIは「はい、この事案は特に緊急性が高いと考えられます」といった文章を返す。この自由形式のテキストから「緊急である」というYes/Noの情報をプログラムで正確に抽出するには、複雑なテキスト解析が必要になる。この方法は、AIが少し表現を変えたり、条件付きの回答をしたりすると、すぐに機能しなくなる可能性がある。また、AIがどの程度の確信を持ってそう判断したのか（信頼度）を知ることも難しい。

このような問題を解決するために特化して設計されたのが、TypeSafe社が開発した評価API「Jev（ジェブ）」モデルである。Jevは、自由形式テキストの解析が必要なステップを飛ばすことに焦点を当てている。Jevを使用する際には、評価したいテキストや構造化データ（これを「ステート」と呼ぶ）と、質問内容、そして期待する回答の型を定義したマップを送信する。すると、Jevは人間が解析する必要のない、型付きで確率スコアが付与された回答を返してくれる。

Jevは汎用的なチャットAIとは異なり、特定の繰り返し可能で、かつ監査が必要な意思決定ポイントに特化したツールだ。この「狭さ」こそが、O2Cプロセス全体に散らばる複雑な判断を自動化する上で非常に有用なのだ。Jevは、アプリケーション内部から呼び出せる「スマートなif文」のようなものだと考えると良い。さらに、Jevは高速かつ低コストで動作するため、文書が到着した瞬間にリアルタイムで呼び出し、判断を仰ぐことが可能である。

Jevがどのような回答を返すのか、具体的な質問タイプを見てみよう。Jevには主に三つの質問タイプがあり、いずれも自由形式の文章ではなく、構造化された回答が返ってくる。

一つ目は「Noul（ヌール）」というタイプで、Yes/No形式の質問に答えるものだ。回答は、0から1の間の数値で「Yesである確率」が返される。例えば、「この注文は手動レビューが必要か？」という質問に対し、Jevは「0.97」といった数値を返す。これは、97%の確率で手動レビューが必要であると判断していることを示す。

二つ目は「Choice（チョイス）」というタイプで、あらかじめ定義された複数の選択肢の中から、最も適切なものを選ぶ質問に利用する。回答は、選ばれた選択肢と、全ての選択肢に対する確率分布が返される。例えば、請求書への返信内容を「請求エラー」「サービス問題」「支払い約束」といった選択肢から分類する場合に利用する。

三つ目は「Score（スコア）」というタイプで、定義された評価基準（ルーブリック）に基づいて物事を評価し、採点する質問に使う。回答は、確率加重された値と信頼度スコアが返される。例えば、未払い金の催促の緊急度を「低」「中」「高」といった段階で評価する場合に利用できる。

金融関連の業務フローにおいて、これらの「型付きの、数値に基づいた回答」は極めて重要だ。Jevは、「AIが自信ありげに言っているから信じる」という曖昧な判断ではなく、「異議申し立ての確率が0.8を超えたら催促ルートに送る」といった、数値に基づいた明確な自動化ルールを記述し、テストし、監査することが可能になる。

JevはO2Cプロセスにおける様々な場面で活用できる。例えば、注文が標準的な支払い条件から逸脱していないか、手動レビューが必要かどうかをNoul質問で判断する。請求書への返信内容をChoice質問で自動的に分類し、適切な部署にルーティングする。未払い金の催促の緊急度をScore質問で評価し、次のアクションの判断材料にする。契約変更が収益認識の再評価を必要とするような重要な変更であるかをChoice質問でフラグ付けするといった使い方ができる。

しかし、Jevには適さない用途もある。Jevは算術計算、カウント、日付や時刻の比較を正確に行うことはできない。また、説明文を生成することも苦手だ。これらは既存のシステムやプログラムで計算し、その結果をJevに判断材料として与えるべきである。Jevは、クリーンなデータに基づいて「判断」を下すためのツールであり、クリーンなデータ自体を生成するためのツールではないのだ。

型付きの応答がこれほど重要なのは、以下の三つの理由がある。 一つは「しきい値による自動化」が可能になる点だ。確率や信頼度の数値があることで、「信頼度が0.95以上なら自動処理」「0.6から0.95の間なら人間が確認」「0.6以下なら常に人間が対応」といった、リスク許容度に応じた柔軟な自動化レベルを設定できる。自由形式の文章では、このようなルールは構築できない。 二つ目は「下流システムの安定したスキーマ」が保証される点だ。Jevからの回答は常に決められた構造を持つため、AIが回答の表現を少し変えただけで、それを受け取る下流のシステムがエラーを起こす心配がない。 三つ目は「監査証跡」が残せる点だ。金融関連の業務は監査の対象となることが多く、「AIが請求エラーと判断したようです」という曖昧な表現では監査に耐えられないが、「モデルは0.91の信頼度でdispute_reason: billing_errorを返した。このタイムスタンプで記録済み」という数値と記録があれば、その判断の正当性を説明できる。

Jevの判断も完璧ではない。Jevが返すスコアや選択肢はあくまで確率的な推定値であり、事実ではない。信頼度が低い回答は、自動実行するのではなく、人間が確認すべきである。Jevは、あくまで「意思決定を支援するツール」として活用し、人間の判断を完全に置き換えるものではないと考えるべきだ。

Jevのようなツールを導入する際には、まず既存の手動プロセスと並行してJevを「シャドーランニング」させるのが賢明である。Jevの回答と人間が実際に下した判断を比較し、その乖離を分析して基準やしきい値を調整する。そして、リスクの低い部分から、徐々に自動化を始めるべきである。特に収益認識や支払い条件に関わる業務では、お金が動く前に、しきい値の信頼性を裏付ける確固たる理由を持つことが非常に大切である。