入荷検品で作業者が読み上げた品番・数量・ロットを音声で記録し、入荷予定との差をその場で拾う

処理の起点を決める

作業者が端末で入荷伝票を選び、検品開始を押したときに認識を始めます。 常に聞き続ける設計にはしません。倉庫では周りの会話やフォークリフトの警告音も拾うため、検品の対象と時間を区切ったほうが、誤って記録される発話が減ります。

1行ずつの区切りは、発話の終わりです。Speech SDK は末尾の無音で発話の終わりを判断し、確定した文字を Recognized として返します。この構成では、確定した発話1つを「検品記録の1行の候補」として扱います。 途中の推定（Recognizing）は画面に薄く表示するだけで、判定には使いません。

もう一つのきっかけは、前日夜の入荷予定の取り込みです。 荷主から届いたCSVをWMSが取り込んだあと、翌日の伝票ごとに品番の一覧を作り、端末に配ります。この一覧が、翌朝のフレーズリストになります。

入力データを集める

質を決めるのは、下の2つです。 品番は、同じ「ABC-1207」でも人によって読み方が違います。読み方の一覧が無いと、文字になった「エービーシー いちにーぜろなな」が品番に戻せません。 異常の言葉の一覧が無いと、第3章の（d）がそのまま残ります。

信頼度は、Speech SDK の詳細な結果から取ります。 確定した結果には、候補の一覧と、それぞれの信頼度・表示用の文字・正規化した形が付きます。この構成では「聞き取れたか」の判断をこの数値に置きます。

データの取得方法を決める

認識は端末側で動かします。 検品アプリに Speech SDK を組み込み、ヘッドセットのマイクを入力にして、言語を ja-JP に設定して連続認識を始めます。音声をいったん録音してから送る形にしないのは、結果を数秒で作業者に返したいからです。

単語ごとの時刻は、設定で要求しないと返りません。 SpeechConfig で単語単位のタイムスタンプを要求しておきます。事務所が「この数量は本当にそう言ったか」を確かめるとき、録音の該当箇所だけを再生できます。 時刻は100ナノ秒を1とする単位で、認識を始めた時点からの位置として返ります。

入荷予定は、伝票を選んだ時点で端末に読み込みます。 前日夜に配った一覧から、その伝票の行だけを取り出し、フレーズリストにはその伝票の品番と、品番の読み方の一覧から引いた呼び方を入れます。 伝票1枚の品番は多くて数十なので、2,000語句の目安には十分収まります。

AIへ渡す前に整形する

1. フレーズリストを伝票ごとに作り直す … 伝票を切り替えるたびに、その伝票の品番と呼び方だけを入れ直します。1日分の全品番を入れると、似た品番どうしが候補に並びます
2. 読み上げの順を固定する … 「品番、数量、ロット、期限、異常」の順で読むことを決め、検品アプリの画面にも表示します
3. 数字の読み方をそろえる … 「いち、に、さん」で1文字ずつ読むのか、「じゅうに」とまとめて読むのかを品番と数量で分けて決めます
4. 英字の読み方をそろえる … ロットの「O」と「0」、「I」と「1」が混ざらないよう、英字は「オー」ではなく「アルファベットのオー」と読む、などの規則を決めます
5. 発話の文脈を付ける … 確定した発話を送るとき、伝票番号・いま検品している行の番号・直前に確定した行を一緒に付けます
6. 短すぎる発話を除く … 「えー」「よし」など、1〜2語の確定発話は項目の取り出しに回しません
7. 音声の控えを保存する … 発話ごとの音声を Blob Storage に置き、認識結果と同じIDを付けます

3番目と4番目を軽く見ないでください。 音声の認識は、聞こえた音を文字にするところまでです。「じゅうに」が「12」なのか「10と2」なのかは、読み方の規則が決まっていないと後段でも決められません。 現場で守れる規則を、最初に1枚の紙にします。

AIに処理させる

させるのは、確定した1つの発話から5つの項目を取り出し、根拠にした部分をそのまま書き出すことだけです。 予定と比べる判定はさせません。

右端の列が大事です。 取り出せなかったことを、空欄ではなく理由の付いた値で返させます。空欄と「言われなかった」は違います。 異常を言わなかった行は「異常なし」ですが、期限を言わなかった行は「記録漏れ」です。

1行目がいちばん起きやすい失敗です。 予定数量を一緒に渡すと、聞き取りが曖昧な数量を予定どおりの数に寄せて返します。その瞬間、拾いたかった差異が消えます。 項目の取り出しには予定数量を渡しません。

指示内容を固定する

あなたは物流倉庫の入荷検品で、作業者の読み上げを検品記録の項目に取り出す係です。
音声認識が返した文字だけを見て取り出してください。推測で埋めないでください。

【取り出す項目】
1. item_code（品番）… 下の【この伝票の品番の候補】から選ぶ
2. quantity と unit（数量と単位）… 単位はケース／バラ／個のいずれか
3. lot（ロット）… 下の【読み方の規則】で英数字に戻す
4. best_before（賞味期限）… YYYY-MM-DD または YYYY-MM
5. anomaly（異常）… 下の【異常の言葉の一覧】から選ぶ。言われていなければ none

【厳守事項】
- 品番は候補の中から選んでください。候補に無い場合は item_code を空にし、
  status を not_in_list として、聞き取った文字を heard に残してください。
  似ている品番に寄せないでください。
- 数量は言われた数字だけを入れてください。計算や換算をしないでください。
  単位が言われていなければ unit を空にし、status を unit_unknown にしてください。
- 期限の年が言われていなければ、年を補わずに status を partial にしてください。
- 異常が一覧に無い言葉なら anomaly を other とし、聞き取った言葉を heard に残してください。
- 1つの発話に2行分が含まれている場合は、lines に2つ並べてください。
- 検品と関係のない発話（「えー」「次いきます」など）は lines を空にしてください。
- evidence には、その項目の根拠にした部分を、認識結果からそのまま写してください。
- 予定と合っているか、受け入れてよいかは書かないでください。

【音声認識の結果】{recognized_text}
【この伝票の品番の候補と呼び方】{item_candidates}
【読み方の規則】{reading_rules}
【異常の言葉の一覧】{anomaly_terms}

「似ている品番に寄せない」を明記しないと、候補の中で最も近いものを選びます。 候補を渡す以上、AIはその中から答えようとします。候補に無いということ自体が、誤配送や荷主の予定の漏れを見つける手がかりです。

予定数量をプロンプトに入れていないのも同じ理由です。 比較の材料を渡さなければ、比較のしようがありません。

出力形式を固定する

Azure OpenAI の構造化出力で、次の形のJSONを受け取ります。 構造化出力は、呼び出しのときに渡したJSONスキーマに出力を従わせる機能で、型の合わない値や項目の抜けで後段の突き合わせが止まることを防げます。 スキーマではすべての項目を必須にし、additionalProperties を false にする必要があります。

{
  "utterance_id": "",
  "lines": [
    {
      "item_code": "",
      "heard": "",
      "quantity": 0,
      "unit": "case | piece | each | ",
      "lot": "",
      "best_before": "",
      "anomaly": "none | crushed | wet | label_mismatch | other",
      "status": "ok | not_in_list | unit_unknown | partial | unclear",
      "evidence": ""
    }
  ]
}

1つ目の理由は、AIの取り出しと規則の判定を別の層に置けることです。 lines はAIが埋め、予定との突き合わせは Azure Functions が規則で行います。

unheard を先に判定するのが要です。 信頼度が低い発話は、数量が予定と違って見えても qty_diff にしません。聞き取りの問題を、差異として記録しないためです。 しきい値は、最初の1か月の結果を見て決めます。

2つ目の理由は、端末の画面を項目ごとに組み立てられることです。 作業者には「品番 ABC-1207 ／ 12ケース ／ ロット A0315 ／ 期限 2027-03」と項目で返し、違う項目だけ色を変えます。自由文で返すと、どこが違うかを作業者が読み取らなければなりません。

システムへ連携する

WMSへは直接書き込みません。 事務所が確認した検品記録だけを、既存の取り込み機能で入れます。音声の誤認識が、そのまま在庫数に入る経路を作らないためです。

端末への返却は、1つの発話ごとに行います。 伝票の全行が終わってからまとめて返すと、差異が分かるのは最後の箱を置いた後になり、数え直しのために荷を探し直すことになります。

人が確認する

作業者は、画面と通知音で全行を見ます。 ただし見るのは、match 以外の行だけで足ります。match の行は画面に緑で並ぶだけで、手を止める必要はありません。

1. unheard は言い直す … 画面に聞き取った文字が出るので、どこが違うかを見て、その項目だけ言い直します
2. qty_diff と lot_diff は数え直す … 荷がまだ目の前にあるうちに数え直し、同じなら「差異確定」と読み上げます
3. not_in_plan は荷札を確かめる … 伝票違いの荷が混ざっていないかを見ます

事務所が見るのは、差異の確定した行と、異常の記録だけです。

1. 差異の確定した行を見る … 必要なら単語ごとの時刻から録音の該当箇所を再生し、本当にその数を言ったかを確かめます
2. 異常の記録を見る … other で残った言葉を一覧の語に直します
3. 取り込みを承認する … 確認が済んだ伝票だけをWMSに入れます

4番目を省かないでください。 数量の差異は、荷主への報告と請求に直結します。言い間違いや聞き間違いを差異として報告した1件は、荷主との次の月に残ります。

例外に対処する

上から2行目までが、運用の初めの大半を占めます。 どちらもAIの問題ではなく、マイクと話し方の問題です。 判定の精度を上げるより、読み上げの規則を現場で守れる形にするほうが効きます。

記録を残す

• 発話ごとの音声と、確定した文字・信頼度・単語ごとの時刻
• 項目の取り出し結果（lines）と、そのときに渡した品番の候補
• 予定との判定（match／qty_diff／lot_diff／unheard／not_in_plan）
• 言い直しと数え直しの記録 … どの行で、何回、どう変わったか
• 事務所が直した項目と、取り込みの承認者
• 作業者ごと・時間帯ごとの unheard の発生率

4つ目で「どう変わったか」を残すのは、差異の確定の重みが変わるからです。 数え直して同じ数だった差異と、言い直して消えた差異は、荷主への報告の確からしさが違います。

最後の行は、マイクと配置を見直す材料になります。 特定の検品場所や時間帯だけ unheard が続くなら、理由は声ではなく周りの音にあります。