LiteTMSにおけるJev AIの活用ポイント

LiteTMSでは、TypeSafe AIのAIモデル「Jev」を複数の業務ワークフローに組み込みました。Jevは、対応が必要なドライバーからのメッセージの検出、表記の異なる地名が同じ都市を指しているかの判定、インポートファイルの読み取り方の提案、すでに読者の言語で書かれているメッセージの不要な翻訳の回避などに役立ちます。これらは運送管理システム（TMS）内部における小規模な自動判定であり、オフィス向けの新たな対話型チャットアシスタントではありません。

この名称を初めて耳にされる方は、Jevに関する最初の記事で概要をご確認いただけます。一般的な文章生成AIはプロンプトに対して回答文を作成しますが、Jevは「このメッセージには返信が必要か」といった、より限定的で的確な問いに答えるよう設計されています。LiteTMSはその判定結果を該当するワークフロー内で活用します。

要対応のドライバーメッセージを見極める

ドライバーからは、定期的な状況報告、質問、トラブル報告など様々な連絡が入ります。オフィス側がすべてのメッセージを同じ緊急度として扱う必要はありません。ドライバーチャットにおいて、Jevによるチェック機能を追加し、受信メッセージを件名ごとに分類して配車担当者が対応すべきかどうかを判定できるようにしました。テキストメッセージだけでなく、文字起こしされた音声メッセージにも対応しています。

例えば、「タイヤがパンクした」という連絡は「到着した」という報告とは対応の緊急度が異なります。要対応と判定されたメッセージは注意喚起画面に表示され、車両トラブルの場合は緊急通知を送信することも可能です。オフィス側は従来どおりやり取りを確認し、返信して対応完了のマークを付けることができます。Jev自体がドライバーに勝手に返信したり、故障への対処法を決定したりすることはありません。

パンクに関するメッセージの場合、AIによる判定は以下のようなJSON形式で処理されます。

{
  "input": { "driver_message": "I have a flat tyre and cannot continue." },
  "jev_assessment": {
    "category": "vehicle_problem",
    "needs_action_probability": 0.94
  }
}

LiteTMSは分類カテゴリとアクションスコアを読み取ります。このように高いスコアを示した車両トラブルは緊急案件として表示されるため、オフィス側は迅速に対応すべき案件だと判断できます。

運送依頼書や輸送書類における地名表記

輸送書類には「Köln（ケルン）」と記載されているのに、受注データには英語表記の「Cologne」と入力されている場合があります。文字どおりにテキスト照合を行うと、同じ都市を指しているにもかかわらず異なる単語として認識されてしまいます。そこで、AIを活用した受注入力やCMR（運送状）書類の地名照合において、この判別に特化したJevのチェック機能を導入しました。

受注入力時には、候補となる地名の選択を支援したり、一致が不確実な項目を目視確認用として保留にしたりできます。またCMRの確認時には、高精度で同一都市と判定されることで、本来なら警告対象となる地名の不一致を自動でクリアできます。書類の読み取り自体は別のAI処理が行い、Jevは地名が一致しているかどうかの判定を受け持ちます。

2つの都市名について、判定は以下のように行われます。

{
  "input": { "document_place": "Köln", "order_city": "Cologne" },
  "jev_assessment": { "same_city_probability": 0.92 }
}

同一都市である確率が高いと判定されれば、地名不一致のアラートは解除されます。CMR確認のその他の項目は別個に処理されます。

独自の見出しが付けられたインポートファイル

新しいシステムへのデータ移行は、多くの場合スプレッドシートの取り込みから始まります。あるファイルでは「車両登録番号」、別のファイルでは「ナンバー」、さらに別のファイルでは判別しにくい見出しが使われていることがあります。LiteTMSはまず通常の照合ルールを適用しますが、ルールだけでは判断できない項目について、ファイルにどのようなレコードが含まれ、どの列がどのフィールドに対応しているかをJevが推測・提案します。

提案されたマッピングにはAIによる提案であることが明示され、インポートの担当者はレコードを作成する前にその設定を確認できます。この仕組みは、汎用インポートウィザードだけでなく、CRMの案件データや貨物データのインポートにも導入されています。また関連するチェックとして、表記揺れがあっても取引先一覧に登録済みの企業を認識し、判定の確度が高い場合は重複登録を防止する機能も備えています。

例えば、インポートする車両一覧シートでナンバープレートに「Unit ref.」、社内車両コードに「Internal ID」という見出しが使われているとします。サンプル値を参照することで、Jevは両者を識別できます。通常のヘッダー照合ルールでは車両番号フィールドが空欄になってしまう場合でも、以下のような判定が行われます。

{
  "input": {
    "columns": {
      "col_0": { "header": "Unit ref.", "examples": ["WX 4821A", "PO 7619K"] },
      "col_1": { "header": "Internal ID", "examples": ["FLEET-17", "FLEET-42"] }
    },
    "field_to_match": "registration_number"
  },
  "jev_assessment": { "column": "col_0", "probability": 0.93 }
}

これにより、LiteTMSは1列目を車両登録番号として提案します。オフィス側はそのマッピング内容を確認した上でレコードを取り込めます。該当する列が存在しない場合、Jevは無理に関連付けを行わず「なし」を選択するため、ユーザー自身でマッピングを指定できます。

チャット翻訳前の細かな判定

受信者の言語でメッセージがすでに書かれている場合もあります。LiteTMSでは、チャット全体の翻訳を実行する前に、Jevに言語の一致確認を行わせることができます。高い確信度で一致した場合は元のメッセージをそのまま表示し、判定が不確実な場合は通常の翻訳処理に回します。これにより判断の範囲を絞り込み、システムが確信を持って省略できない場合でも、閲覧者は確実に翻訳を受け取ることができます。

例えば、ドライバーが「Jestem na miejscu, czekam na załadunek（現場に到着しました。積み込みを待っています）」と送信したとします。ポーランド語を使用している閲覧者に対しては、このチェックにより次のような判定結果が返されます。

{
  "input": {
    "message": "Jestem na miejscu, czekam na załadunek.",
    "reader_language": "pl"
  },
  "jev_assessment": { "language": "pl", "probability": 0.96 }
}

検出された言語が閲覧者の言語と一致しているため、LiteTMSは原文を表示できます。一方、英語を使用している閲覧者の場合、同じポーランド語のメッセージでも翻訳が必要です。「OK」のような短い返答は情報量が少ないため、言語を高い確信度で特定できない場合は、通常の翻訳処理が引き続き適用されます。

Jevによる判定がLiteTMSで果たす役割

JevはLiteTMSに有用なシグナルを提供しますが、業務の管理権限は常にオフィスの配車担当者・管理者が保持します。この連携機能は組み込み済みであり、企業の設定に応じてプラットフォームの判定レイヤーが有効化された際に実行されます。Jevが利用できない場合でも、チャット、書類、インポートの通常のワークフローはそのまま継続されます。

技術的な視点：TypeSafe Jev、JSON、Java

内部で何が行われているかを確認したい読者にとって、私たちが送信するクエリ（質問）が最適な出発点となります。TypeSafeのクイックスタートで解説されているように、リクエストには判定対象の情報であるstateと、実行する判定内容であるquestionsが含まれます。noul型の質問は、ある命題が成立する確率を表す0から1までの数値を返します。choice型の質問は指定された選択肢から選ぶ形式であり、メッセージのカテゴリーを分類する際にこれを使用します。

以下は、OpenRouter連携で設定されているモデル識別子を使用した、対応要否の質問単体の例です:

{
  "model": "typesafe/jev-1.13",
  "state": {
    "driver_message": "I have a flat tyre and cannot continue."
  },
  "questions": {
    "needs_action": {
      "type": "noul",
      "instructions": "The dispatcher must act on driver_message today: reply, give instructions, inform the customer or arrange help. Routine updates and thanks need no action."
    }
  }
}

レスポンスの該当部分は次のようになります。

{
  "answers": {
    "needs_action": {
      "type": "noul",
      "noul": 0.94
    }
  }
}

アプリケーションはanswers.needs_action.noulの値を読み取り、ルールを適用します。LiteTMSでは、ドライバーからのメッセージに対する注意喚起のしきい値として0.55を採用しています。JSONをデコードした後、Javaでは次のように同様のチェックを記述できます。

Double probability = 0.94; // Value from answers.needs_action.noul
boolean needsAttention = probability != null
    && Double.isFinite(probability)
    && probability >= 0.55
    && probability <= 1.0;

if (needsAttention) {
    System.out.println("Flag the message for dispatcher review");
}

このコードは、しきい値と比較する前に値が有効であるかを検証しています。LiteTMSでは、カテゴリー判定がルールのもう一方の要素を担っており、注意を要する車両トラブルは緊急アラートの対象にもなります。モデルがメッセージを評価し、アプリケーションがアクションを決定します。回答が得られない場合でも、通常のチャットワークフローが継続します。

しきい値は、その後に実行される処理の内容によって異なります。インポート時のカラム提案では、LiteTMSは確率が0.60以上の選択されたカラムを採用します。一方、翻訳のスキップには、閲覧者の言語が0.90以上の確率で選択されている必要があります。したがって、0.85というスコアは人間が確認するカラム提案には十分ですが、チャット翻訳をスキップするには不十分です。各ルールは、その個別判断がもたらす影響の大きさを反映しています。

よくある質問

Jev AIは誰が開発したのですか？

TypeSafe AIが、構造化された意思決定のためのシステム1（直感型）モデルとしてJevを開発しました。LiteTMSはこれを、ドライバーメッセージの優先度判定や地名の照合といった特定のワークフローに組み込んでいます。

LiteTMSでJev AIは何に使用されていますか？

Jevは、ドライバーメッセージのトリアージ、受注時の同一都市チェックやCMRの地名チェック、インポート提案、チャット翻訳前の同一言語チェックなどに連携されています。ワークスペースで個々の機能が有効になるかどうかは、プラットフォームおよび企業の設定によって決まります。

Jevはドライバーへの返信やCMR書類の承認を自動で行いますか？

いいえ、行いません。注意が必要なドライバーメッセージにフラグを付けたり、2つの地名が同一都市を指しているかを判定したりすることはできますが、メッセージへの対応は人間が行い、同一都市と判定された場合でもCMR書類全体が承認されるわけではありません。

Jevの判定が不確実な場合や利用できない場合はどうなりますか？

LiteTMSは既存のワークフローを維持します。例えば、言語判定が不確実な場合は通常のチャット翻訳ルートが適用され、インポートの推測が不確実な場合は人間が確認できるようにマッピングが残されます。