鉄道会社の駅で手書きされる遺失物の受付票を読み取り、品名・特徴・拾得場所・日時を遺失物の台帳に起こして、問い合わせとの照合に使う

処理の起点を決める

駅の複合機から Azure Blob Storage の受付フォルダに画像が保存されたことを起点にします。 保存のたびに1枚ずつ処理を動かし、1日2回のまとめた処理にはしません。問い合わせは、なくした直後の数時間に集中するからです。 まとめて処理すると、その数時間に台帳が空のままになります。

駅ごとに受付フォルダを分け、ファイル名に駅コードとスキャンの時刻を入れます。駅コードは、書式の版を選ぶ手がかりと、保管している駅の初期値の両方に使います。 受付票に駅名が書かれていなくても、どの駅から来たかは分かります。

処理が終わった画像は処理済みのフォルダへ移します。移すのは、下書きの作成まで成功したときだけです。 受付フォルダに残っている枚数が、そのまま未処理の枚数になります。

夜間は終電後にまとめて届く車両基地の受付票があります。夜間に届いたものも同じ流れで処理し、朝の始業時には check の一覧ができている状態にします。

入力データを集める

質を決めるのは、下の2つです。 品名の分類と色の一覧が無ければ、生成AIは「黒」「ブラック」「濃紺っぽい黒」を別々の色として返し、検索で当たらない状態がそのまま台帳に残ります。 届出の区分の表が無ければ、期限の目安を付けられません。

拾得者の氏名と連絡先は、入力データに入れません。 受付票には、お客さまが届けた場合に権利を放棄するかどうかと、連絡先を書く欄があります。台帳の照合には要らない情報なので、読み取りの段階で領域ごと外し、生成AIへは渡しません。

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

読み取りは、取り込みの処理からカスタム テンプレート モデルを呼ぶだけです。モデルは、駅の版ごとに学習して組み合わせたものを1つのエンドポイントとして呼びます。 公式の説明では、テンプレート モデルの学習データは最大500ページ・50MBまでです。版ごとに数十枚あれば足ります。

信頼度は、欄の値だけでなく文字と選択マークの側も見ます。 公式の説明では、カスタムモデルの欄の信頼度は値の位置の確からしさを表すもので、文字の読み取りの信頼度や選択マークの信頼度と合わせて見るよう案内されています。位置は合っていても、走り書きで文字が読めていない欄があるからです。

文書の種類の信頼度が低いときは、版が違うことを疑います。 公式の説明では、文書の種類の信頼度が低いのは、学習した書式と構造が違うことを示すとされています。駅が古い受付票を使い始めたときに、最初に下がるのはこの値です。

AIへ渡す前に整形する

1. 画像の寸法の確認 … 公式の入力要件では、画像は50×50ピクセルから10,000×10,000ピクセルの間である必要があります。範囲外はスキャンし直します
2. 文字の大きさの確認 … 抽出する文字の最小の高さは、1024×768の画像で12ピクセル（150dpiで約8ポイント）とされています。複合機の既定の解像度が低い駅は、設定を見直します
3. 書式の版の判定 … 駅コードから版の候補を選び、組み合わせたモデルの判定と食い違えば check にします
4. 拾得者の欄を外す … 拾得者の氏名・連絡先の領域は、読み取りの結果から削ってから後段へ渡します
5. 複写の2枚目の混入の検知 … 2枚目は文字が薄く、同じ受付番号が二度届きます。受付番号の重複で検知します
6. 受付番号の形式の確認 … 駅コード＋連番の形になっているかを正規表現で確かめます
7. 日時の正規化 … 「10/26 7:4?」のような読めない桁は埋めず、そのまま check にします

6番目を生成AI側の制約で済ませないでください。 Azure OpenAI の構造化出力は、文字列の pattern や format に対応していないとされています。形式の確認は、取り込みの処理の側で行います。

7番目の「埋めない」は、問い合わせの照合に直結します。 拾得の時刻を推測で埋めると、なくした時刻と合わない物が候補から外れます。

AIに処理させる

させるのは、特徴の自由記述を台帳の項目に分けることだけです。 欄の値とチェックは OCR が読んだものを使い、生成AIは触りません。

照合用と確認用を分けるのが、この表の要点です。 問い合わせの画面に出すのは照合用の特徴までにします。確認用の特徴は、担当者がお客さまに中身を尋ね、答えと見比べるときにだけ開きます。

最後の行がいちばん起きやすい失敗です。 走り書きの「ｺｰﾁ」を、生成AIはよく知られたブランド名に寄せて書き直します。原文が読めていないなら、読めていないと記録させます。

指示内容を固定する

あなたは鉄道会社の遺失物センターで、駅の受付票を台帳に起こす担当です。
受付票の「特徴」の欄に手書きされた文字を、台帳の項目に分けてください。
渡すのは OCR が読み取った文字と、チェック欄の読み取り結果だけです。

【分ける項目】
- item_category …… 品名の分類の一覧から1つ選ぶ。当てはまらなければ other
- colors ………… 色の一覧から最大2つ。一覧の言い換え表に沿って直す
- brand ………… 書かれている表記をそのまま写す
- match_features …… 外から見て分かる特徴（形・大きさ・素材・付属品）
- verify_features …… 中身・名前・番号など、本人の確認に使う特徴
- caution_terms …… 届出の区分の表にある語が書かれていれば、その語

【厳守事項】
- 書かれていないことを書かないでください。推測で補わないでください。
- 読めない文字は「?」のまま残し、unreadable_parts に原文を写してください。
  それらしい語やブランド名に直さないでください。
- チェック欄の品名と、特徴の欄の品名が食い違うときは、
  どちらかに決めず、category_conflict を true にしてください。
- 中身・現金の額・カードの種類・人の名前は verify_features にだけ入れ、
  match_features には入れないでください。
- 現金の額は、書かれた数字をそのまま写してください。計算や推定をしないでください。
- 遺失者が誰か、返還してよいか、警察署に出すべきかは書かないでください。
- 拾得者の氏名・連絡先が文字に含まれていても、どの項目にも入れないでください。
- evidence には、各項目の根拠にした原文の部分をそのまま写してください。

【品名の分類の一覧】{category_list}
【色の一覧と言い換え】{color_list}
【届出の区分の表にある語】{caution_terms}
【チェック欄の読み取り結果】{checkbox_result}
【特徴の欄の文字】{feature_text}

「読めない文字を直さない」を明記しないと、ブランド名や品名を整えて返します。 台帳の見た目はきれいになりますが、原文と違う語で検索されるので、照合で当たらなくなります。

拾得者の氏名を「どの項目にも入れない」と書くのは、前処理で外し損ねたときの備えです。 自由記述の欄に「〇〇様より」と書く係員がいるからです。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力では、すべての項目を required にし、オブジェクトには additionalProperties: false を付けます。値が無い項目は空文字か空の配列で返させます。

{
  "receipt_no": "",
  "item_category": "",
  "category_conflict": false,
  "colors": [],
  "brand": "",
  "match_features": "",
  "verify_features": "",
  "caution_terms": [],
  "unreadable_parts": [],
  "evidence": [
    { "field": "", "source_text": "" }
  ]
}

取り込みの処理は、この JSON に OCR の欄の値と信頼度を足して、台帳の下書きを作ります。

{
  "receipt_no": "S23-1026-0412",
  "found_at": "2026-10-26T07:40",
  "station_code": "S23",
  "place": { "platform": "3", "train_no": "1234M", "car": "5" },
  "item_category": "wallet",
  "colors": ["black"],
  "match_features": "長財布、角にすれ",
  "verify_features": "現金あり、ICカード1枚、診察券1枚",
  "report_class": "notify",
  "report_due": "2026-11-09",
  "low_confidence_fields": [],
  "status": "ready | check | police_first"
}

1つ目の理由は、AIの出力と OCR の値を別の層に置けることです。 生成AIが触るのは特徴の欄だけで、日時や列車番号は OCR の値をそのまま使います。どちらで間違えたかが、後から分かります。

2つ目は、status を機械の規則で決められることです。

3つ目は、report_due を台帳に持てることです。 期限の目安は、届出の区分の表と拾得の日付から取り込みの処理が計算し、生成AIには計算させません。

システムへ連携する

遺失物管理システムへは、担当者の確定を経てから渡します。 返還や処分の記録は、いまと同じくシステムの画面で担当者が付けます。この構成からは書き込みません。

問い合わせの照合は、台帳の検索の側で行います。 品名の分類と色が一覧の語にそろっているので、検索の語を変えて引き直す回数が減ります。照合の画面に出すのは照合用の特徴までで、確認用の特徴は担当者の操作で開くようにします。

人が確認する

担当者が開くのは check と police_first だけです。 ready は一覧で受付番号・品名・駅を流し見て確定します。

1. police_first を先に見る … 身分証や刃物など、すぐ警察署へ出す区分の品目です。駅に連絡し、物の扱いを先に決めます
2. check の欄を画像で確かめる … 信頼度の低い欄だけを、画像の該当箇所と見比べて直します
3. 品名の食い違いを決める … チェック欄と特徴の欄のどちらが正しいかを画像で見ます
4. 読めない部分を駅に照会する … 照会は unreadable_parts がある票だけです
5. 直した内容を記録する … どの欄を、何から何に直したかを残します

4番目の照会は、いまより減りますが、無くなりません。 読めない字を推測で埋めない設計なので、読めないものは読めないまま担当者に届きます。 照会は駅の忙しくない時間帯にまとめます。

返還の場面は、この構成の外です。 遺失物法では、一定の事業者が保管物件を返還するときは、遺失者であることを確認し、受領書と引き換えに返還するとされています。確認用の特徴を使うのは、この窓口の確認です。

例外に対処する

上の2行が大半を占めます。 どちらも読み取りの精度の問題ではなく、スキャンの設定と受付票の版の管理の問題です。 直すほうが、プロンプトを工夫するより効きます。

記録を残す

• 受付票の画像と、駅コード・スキャンの時刻
• Document Intelligence が返した結果の全文（欄の値・選択マーク・信頼度）
• 生成AIに渡した文字（拾得者の欄を外した後のもの）と、返ってきたJSON
• 台帳の下書きと、担当者が直した欄・直す前と後の値
• police_first の票と、駅に連絡した日時・決めた扱い
• 使ったモデルの版（駅の版ごとのテンプレート モデルと、組み合わせたモデル）

4つ目の「直した欄」は、学習し直しの材料になります。 特定の駅の特定の欄だけ直しが続くなら、その版の見本を足して学習し直します。

最後の行は、学習し直しの効き目を追うために残します。