Next-Tomorrow ／ 製品説明
ヘルプデスク AI エージェント（SAP 発注データ突合）
ヘルプデスクに届いた問い合わせを SAP の発注データと突合し、不整合のパターンを検出して、 根拠を引用した回答ドラフトをオペレーターに提示します。 判定は決定論的なコードが行い、LLM は「本文から値を取る」ことと「確定した根拠で文章を書く」ことだけを担当します。
本デモのデータはすべて架空の想定サンプルです
K2 様・ダイキン子会社様の実データではありません。実データの受領前に納期を合わせるため、 SAP 発注データと問い合わせデータの構造、および典型的な不整合パターンを想定して作成しています。 SOP 手順書と過去対応事例も実物が未提供のため、デモ用に架空で作成したものです。 実データを同じ列構成で差し替えれば、そのまま再計測できる構成になっています。
処理の流れ（7 段）
この製品が何をするか、順に何が起きるか
- 1抽出LLM
問い合わせ本文から型番・数量・日付・発注番号・能力・ステータスと依頼種別を取り出します。SAP のデータは渡しません。モデルに正解を見せると「相違している」と判断しようとし、その判断が後段の判定と衝突するためです。
- 2伝票同定決定論
顧客が名乗った発注番号を本文優先で拾い、得意先名が合わなければ内容から探し直します。得意先名・能力・品名カテゴリ・番号一致の重み付き和で候補を採点し、上位が十分に分離しているときだけ単独候補として採用します。
- 3フィールド対照決定論
表記の揺れを正規化したうえでフィールド単位に比較します。相違したものだけでなく一致したものも根拠として残します。一致根拠が「この伝票で合っている」という説明になるためです。
- 4分類・確信度決定論
決定木で 6 パターンのいずれかに分類し、基準値に加減点して確信度を出します。確信度と検出パターンから、自動回答可・要確認・エスカレーションの 3 区分を決めます。
- 5ナレッジ検索埋め込み
SOP 手順書と過去対応事例を埋め込み検索し、パターンタグで再順位します。回答は必ず一次対応 SOP に従う必要があるため、パターンに対応する SOP は常に引用候補へ入ります。
- 6回答起草LLM
確定した根拠と SOP だけを渡して回答文を書かせます。書いてよい値の一覧を明示的に絞り、その外の数値・日付・型番が出たら機械的に検出します。3 回通らなければテンプレート生成へ切り替えます。
- 7組み立て・検証検証
推論ステップは各段の実行ログをそのまま文章化したもので、生成ではありません。最後に引用がすべて実在の文字列に解決できるかを検査し、1 つでも失敗した件はキャッシュに書きません。
構成
画面が参照している実際の件数
- SAP 発注データ
- 78 件
- 製品マスタ
- 18 型番
- 問い合わせ（検証セット）
- 8 件
- 問い合わせ（拡張サンプル）
- 52 件
- SOP 手順書
- 20 チャンク
- 過去対応事例
- 40 件
- 検証セットの正答率
- 100%
- 拡張サンプルの正答率
- 100%
- 事前計算のスナップショット
- 4936f89a3722864b
対応区分
AI が回答をどこまで引き受けるかの区分
- 自動回答可
SAP の登録値のみで回答が完結するため、下書きをそのまま送信できます
- 要確認
AI は候補を提示しますが、確定にはオペレーターまたは顧客の確認が必要です
- エスカレーション
AI は自動回答せず、担当者への引き継ぎを提案します
検出パターン
原本サンプルデータ「突合パターン一覧」の 6 分類をそのまま実装しています
- 型番相違
問い合わせに記載された型番と、SAP 登録の型番が一致しない（1〜2 文字違いなど）
- 納期・日付相違
問い合わせ側が認識している納期と、SAP 登録の希望納品日が異なる
- 数量相違
問い合わせ側の申告数量と、SAP 登録数量が異なる
- 発注番号相違（誤記）
顧客が記載した発注番号が、内容から見て別の発注番号の誤記と推定される
- 不整合なし（単純確認）
SAP との相違がなく、単純なステータス確認や状況照会
- エスカレーション対象
内容相違ではなく、納期交渉など人による判断が必要な依頼
設計の考え方
なぜこの作りにしたか
判定は決定論的に、文章生成だけを LLM に
「根拠を引用してハイライトする」という要件を満たすには、引用した根拠が実データと必ず一致していなければなりません。フィールド比較とパターン分類を LLM に任せるとこの保証が崩れます。LLM は自由文から値を取ることと、確定した根拠で文章を書くことにしか関わりません。
引用は位置ではなく文字列で扱う
文字オフセットを保存せず、本文に実在する部分文字列を保存して描画時に位置を解決します。引用が本文とずれていれば自己点検が即座に検出します。画面のハイライトは、この検査を通った引用だけで構成されています。
答えられない範囲を答えられると言わない
追跡番号のように SAP の受注伝票に項目が存在しない照会は、推測で埋めずに別システムでの確認が必要である旨を案内します。回答できる範囲とできない範囲を区別できることを、機能として実装しています。
デモは絶対に失敗しない
既定の動作は事前計算結果の再生です。キャッシュと埋め込みインデックスをリポジトリに含めているため、API キーが無い環境でも、ネットワークが切れていても全画面が動作します。
回答文の検証（5 段）
回答文が創作した値を含まないことを機械的に確かめる
- V1引用箇所が回答本文にそのまま存在するか
- V2引用先の根拠 ID が実在するか
- V3回答文の数値・日付・型番がすべて提示した値の範囲内か
- V4要確認の場合に推定である旨を明示しているか
- V5SOP の禁止事項（他社名の記載・推量表現など）に触れていないか
最大 2 回まで再生成し、3 回目で通らなければパターン別の定型文へ切り替えます。 その場合は回答ドラフトの見出しに「テンプレートで生成」と表示し、品質の違いを隠しません。
スコープ
今回の範囲と、その先
ステップ 1（今回・実装済み）
システム接続なし。サンプルデータで突合の精度を検証する段階です。 実データが届けば、同じ列構成のままデータを差し替えて再計測できます。
ステップ 2 以降
SAP の IDoc 連携、チケットツールとの双方向連携が対象です。 突合エンジンを入出力から切り離してあるため、アダプタの差し替えで移行できます。
意図的に含めていないもの
回答の自動送信は行いません。オペレーターの確認を前提とする製品のため、下書きまでが範囲です。 ベクトル DB も現在の規模では導入せず、全件のコサイン計算で処理しています。
技術構成
プロバイダに依存しないように抽象化しています
フロントエンド
Next.js（App Router）／ TypeScript ／ Tailwind CSS
突合エンジン
TypeScript の純粋関数。同じ入力に常に同じ結果を返します
LLM
Azure OpenAI を第 1 案、Google Gemini と OpenRouter を切り替え可能
検索
埋め込みインデックスをビルド時に生成しリポジトリへ同梱
回答文の生成に使ったモデル・プロバイダは、各ケースの回答ドラフト画面に表示しています。 事前計算はプロンプト版数と SAP データのハッシュを鍵にキャッシュしており、 データやプロンプトが変われば自動的に無効化されます。