靴・鞄の修理店が手書きの預かり票を Azure AI Document Intelligence で読み取り、修理の進み具合の台帳と仕上がりの連絡の一覧を作る

処理の起点を決める

店の控えのスキャンが、店ごとの SharePoint のライブラリに保存されたことを起点にします。 複合機のスキャンの保存先をライブラリにし、店ごとにライブラリを分けます。ライブラリの名前が、そのまま店を表します。 票番号は店ごとの連番なので、店を取り違えると連番の確かめが成り立たなくなります。

使うトリガーは「ファイルが作成されたとき（プロパティのみ）」です。店ごとに1つのフローにせず、 ライブラリを変えたフローを3つ作るか、1つのライブラリに店ごとの列を持たせます。どちらにするかは、店の担当がどこまで他店の控えを見てよいかで決めます。

もう1つのトリガーは、毎朝の定時（繰り返し）です。 開店の前に、台帳から連絡の一覧などを作ります。一覧は、新しい預かりの読み取りとは別の流れで作ります。 仕上がりや引き取りは、預かり票の保存とは関係なく毎日起きるからです。

入力データを集める

質を決めるのは、修理の台帳の「状態」の列です。 預かり → 修理中 → 仕上がり → 店に戻った → 引き渡し済み の5つに決め、工房と店頭のどちらが、どの状態に変えるかを決めておきます。 状態の付け方が人によって違うと、毎朝の一覧が当てになりません。

店の決まりの「保管の期間」は、引き取りの無い品物の一覧のために持ちます。 仕上がりから何日で連絡をし直すか、何日を過ぎたら店の決まりに沿って扱うかを、店の規約に合わせて入れます。

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

Document Intelligence のコネクタの操作に、次の値を渡します。

モデルの学習は、Document Intelligence Studio の画面で行います。 店の控えのスキャンを集め、欄ごとにラベルを付けて学習させます。カスタム テンプレート モデルは、ラベルを付けたキーと値、チェック欄、表、署名の欄を取り出せます。 手書きの文字の対応言語に日本語が含まれています。

コネクタの結果は JSON で返るので、Power Automate の「JSON の解析」で欄ごとの値・チェックの選択の状態・信頼度を取り出します。 解析のスキーマは、学習したモデルで1枚読み取った結果の見本から作ります。ラベルを足したり名前を変えたりしたら、スキーマも作り直します。 古いスキーマのままだと、新しい欄が黙って空になります。

チェック欄の確かさは、欄の信頼度とチェックの信頼度を合わせて見ます。 公式の説明では、チェック欄の欄は、欄の選択とチェックの信頼度を合わせたものが全体の確からしさをよく表すとされています。文字の欄も同じで、 欄の信頼度は値の位置の確からしさを表すため、単語の信頼度と合わせて見ます。

AIへ渡す前に整形する

1. 様式の改訂 … 電話番号の欄を、11桁の1桁ずつの枠に変えます。続けて書いた数字より、読み違いが大きく減ります
2. 複写の濃さ … 2枚目の控えは文字が薄くなります。店頭の担当には、ボールペンで強めに書くことを決まりにします
3. スキャンの設定 … 文字の高さの下限は、1024×768の画像で12ピクセル（150 DPI で約8ポイント）です。複合機の解像度を、店ごとにそろえます
4. 1枚1ファイル … 束で1つの PDF にすると、1枚の読み取りの失敗が束全体に及びます
5. 画像の寸法とサイズ … 画像は50×50〜10,000×10,000ピクセル、ファイルは有料（S0）のレベルで500MBまでです。1枚の預かり票なら十分に収まります
6. 学習の見本 … 様式ごとに少なくとも5枚、店ごと・複合機ごとに、薄い控えと濃い控えを混ぜて集めます
7. 1枚1品物の決まり … 靴1足と鞄1つを一緒に預かるときも、預かり票を品物ごとに分けて書きます。 1枚に2つの品物を書くと、片方だけ仕上がったときに台帳の状態が付けられません
8. 控えの向き … 複合機に控えの向きをそろえて置く決まりにします。テンプレートのモデルは位置の手がかりで値を取るため、上下が逆の控えは文書の種類の信頼度が下がり、 全欄が要確認になります

1番目の様式の改訂を、学習の前に済ませます。 テンプレートのモデルは見た目の様式に頼るため、様式を変えると精度が下がり、学習し直すことになります。 刷り直す預かり票の在庫に合わせて、切り替えの日を決めます。

AIに処理させる

Document Intelligence にさせるのは、決まった欄から値を取り出し、それぞれに信頼度を付けることだけです。 取り出した後の確かめは、Power Automate の条件で行います。

させないことも決めておきます。

1行目がいちばん起きやすい失敗です。 常連のお客様なら、氏名で過去の台帳を引けば電話番号が出てきます。しかし、同じ名字のお客様は珍しくなく、 番号を変えた人もいます。読めない番号は、控えを見て直すか、お客様の控えの票番号で問い合わせを待ちます。

指示内容を固定する

この構成には生成AIへのプロンプトがありません。AIへの指示にあたるのは、カスタム テンプレート モデルに付けるラベルの定義と、Power Automate の確かめの条件です。

【ラベルの定義（Document Intelligence Studio で付ける）】
ticket_no ...... 欄：票番号（印刷済みの連番。6桁）
received_date .. 欄：預かり日
due_date ....... 欄：仕上がりの予定日
customer_name .. 欄：氏名（手書き）
phone .......... 欄：電話番号（11桁の枠をまとめて1つの欄にする）
item_* ......... チェック欄：紳士靴／婦人靴／ブーツ／スニーカー／鞄／財布／その他
repair_* ....... チェック欄：かかと／つま先／ソール／中敷き／ファスナー／持ち手／
                 縫い／色／クリーニング／その他
repair_note .... 欄：修理の内容の手書きの補足
estimate ....... 欄：見積の金額
deposit ........ 欄：前金
contact_* ...... チェック欄：電話／SMS／連絡不要
staff_sign ..... 署名の欄（周りの印刷の文字を含めずに囲む）

【学習の見本の集め方】
- 3店舗それぞれから、少なくとも5枚ずつ
- 薄い控え、濃い控え、補足の欄が長い控えを混ぜる
- 電話番号の枠に変えた新しい様式だけで学習する

【確かめの条件（Power Automate の条件）】
1. phone を数字だけにして、10桁か11桁で 0 から始まる → でなければ要確認
2. phone の欄の信頼度と単語の信頼度が基準以上 → でなければ要確認
3. 同じ店・同じ ticket_no が台帳にある → 登録せず、重なりとして記録する
4. ticket_no が店の票番号の範囲にない → 要確認
5. item_* のチェックが0個、contact_* のチェックが0個か2個以上 → 要確認
6. due_date が received_date より前 → 要確認
7. 文書の種類の信頼度が基準より低い → 全欄を要確認
8. 読めない欄を、ほかの欄や過去の台帳から埋めない

8番の「埋めない」が、この条件の中でいちばん大事です。 Power Automate では、過去の台帳から値を引いて埋める流れも簡単に作れます。作れるからこそ、作らない決まりとして書いておきます。

基準の値は、最初の1か月で決めます。 最初は低めの基準から始めて「要確認」を多めに出し、店頭の担当が直した欄と、そのときの信頼度を並べて、 誤りが出なくなる信頼度を探します。

出力形式を固定する

台帳（SharePoint のリスト）の1行に、次の列を持たせます。

「読み取りの状態」と「状態」を別の列にしているのが、この形の要です。 読み取りの確かさと、修理の進み具合は別のことです。要確認の票でも修理は進むので、 工房は状態を変えられ、店頭の担当は空いたときに読み取りを直します。

毎朝の一覧は、台帳を絞り込んで店ごとに作ります。

票番号の抜けの一覧が、預かったのに台帳に無い品物を見つけます。 書き損じで破棄した票は、店頭の担当が台帳に「破棄」として登録しておき、抜けから外します。

システムへ連携する

お客様への連絡は、この構成から自動で送りません。 一覧は店頭の担当に届き、電話か SMS は担当が送ります。 仕上がりの連絡は、品物が本当に店に戻っているかを棚で確かめてから出すものだからです。

Document Intelligence のコネクタには、1つの接続あたり60秒に1,200回という呼び出しの上限があります。 1日20〜30枚の預かり票なら届きませんが、溜まった控えをまとめてスキャンし直すときは、 間をあけて保存します。

人が確認する

1. 翌朝、「要確認」の票を見る … 台帳の行から控えのファイルを開き、理由の欄を直します。電話番号は、控えの枠を1桁ずつ見て直します
2. 票番号の抜けを見る … 控えの束を探し、スキャンし直すか、破棄として登録します
3. 仕上がりの連絡の前に、棚の品物を確かめる … 状態が「店に戻った」でも、棚に無ければ連絡しません
4. お客様から問い合わせが来たら、票番号で台帳を引く … 状態と予定日で答えます

1番目の電話番号の直しを省かないでください。 読み取りが確かでない番号のまま連絡すると、別の人に「修理が仕上がりました」と届きます。 店の信用に直接響く失敗です。

4番目の問い合わせは、電話番号でも引けるようにします。 お客様が控えをなくしていても、電話番号で台帳の行が見つかれば、状態と予定日をその場で答えられます。 工房に電話して確かめ、かけ直す流れがなくなり、接客の途中で受けた電話も短く済みます。台帳の検索の画面で電話番号の列を探せるよう、リストの表示を店頭向けに1つ作っておきます。

目標は、600枚をならして1枚1分です。 「要確認」になる票が1割前後という想定で、それより多い店は、複写の濃さかスキャンの設定がそろっていません。

例外に対処する

上の2行は、運用を始めて最初の数週間によく出ます。 古い様式の票が残っていることと、複写の2枚目が薄いことが理由です。どちらも用紙と書き方の問題で、 様式の切り替えが終わると減っていきます。

記録を残す

• 店の控えのスキャン（ライブラリに残す）
• 読み取りの結果と、使ったモデルの ID
• 台帳の各行の変更の記録（SharePoint のリストの版の履歴）
• 店頭の担当が「要確認」の票で直した記録 … どの欄を、何から何に直したか
• 連絡した日と方法、引き渡した日
• 店ごとの「要確認」の割合の推移

4つ目の記録が、信頼度の基準を決める材料になります。 直した欄と、そのときの信頼度を並べると、どの信頼度より下で誤りが出ているかが分かります。