印章店が店頭で書く手書きの注文票から書体・材質・寸法・彫る文字を読み取り、工房への彫刻の指示書と注文の台帳を作る

処理の起点を決める

店ごとのライブラリに、注文票のスキャンが保存されたことを起点にします。 閉店後にまとめてスキャンしますが、処理は1枚ずつ動かします。どの店の注文かは、保存したライブラリで決めます。 票に印刷した店名を読むより確かです。

スキャンは 1枚1ファイルにします。複合機でまとめて1つの PDF にすると、1回の読み取りに何件もの注文が混ざり、どのチェックがどの注文のものか分からなくなります。

処理が終わったファイルは、処理済みのフォルダーへ移します。 移すのは台帳への登録が成功したときだけにします。店のライブラリに残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、学習に使う見本です。 カスタム テンプレート モデルは、様式ごとに少なくとも5枚の見本を用意するよう案内されています。見本には、きれいに書かれた票だけでなく、書き直しの跡のある票や、チェックが二つ付いた票を混ぜます。 実際に起きる崩れ方を学ばせておかないと、本番でそれが来たときに信頼度が下がります。

彫る文字のマスは、1字ずつ別の領域としてラベルを付けます。 マスをまとめて1つの欄にすると、どの字の信頼度が低いのかが分かりません。字ごとの信頼度が分かれば、「3字目だけ読めていない」という形で店長に伝えられます。 店長はその1字だけをお客様の控えと見比べれば済みます。

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

読み取りは、Power Automate からコネクタの操作を呼ぶだけです。ロケールは指定しません。 Document Intelligence の言語の案内には、文書の言語が確かでないかぎり言語の指定を渡さないこと、渡すと不完全な文字が返ることがあると書かれています。法人のゴム印などで、ローマ字や数字を彫る注文があるため、日本語に固定しません。

信頼度は1種類ではありません。 欄の信頼度は「値の位置が正しいか」の確からしさで、文字が正しく読めたかは単語の信頼度で見ます。 2024-11-30 の版から、カスタムモデルの欄の信頼度に単語の信頼度が含まれるようになりました。選択マークの欄は、欄の信頼度とチェックの信頼度を合わせて見るよう案内されています。

文書の種類の信頼度も見ます。 これが低いのは、学習した様式と違う見た目の票が来たということです。古い様式の注文票が残っていて、それを使った店があれば、ここで分かります。

AIへ渡す前に整形する

1. 形式の確認 … PDF か画像（JPG、PNG、BMP、TIFF）であることを確かめます
2. 1枚1ファイルの確認 … 2ページ以上の PDF は、ページごとに分けるか、店に戻します
3. 向きと傾き … 複合機の自動の傾き補正を使い、票の上下が逆のものは店に戻します
4. 解像度の確認 … 文字の高さの下限は、1024×768の画像で12ピクセル（150 DPI で約8ポイント）です。彫る文字のマスの字は大きいので問題になりにくく、問題は電話番号やお渡しの日の小さい字です
5. 複写の濃さ … 店の控え（1枚目）をスキャンします。2枚目以降の複写は字が薄く、チェックの印がかすれます

5番目を軽く見ないでください。 工房の控えを工房に送る運用を変えずに済むよう、スキャンするのは店に残す1枚目にします。複写の下の紙ほど、チェックの印が「付いていない」と読まれやすくなります。

AIに処理させる

AIにさせるのは、決まった欄の文字とチェックの状態を、信頼度とともに返すことだけです。 1つに決められるか、要確認にするかは、Power Automate の条件で決めます。

照らす決まりの例です。 どれも店長が表で直せるようにします。

実印の大きさと文字の決まりは、市区町村が決めています。 たとえば東京都中央区の印鑑登録の案内では、印影の一辺の長さが8ミリの正方形より大きく25ミリの正方形より小さいものが登録でき、8mm以下・25mm以上のものは登録できないとされています。氏名の振り仮名で登録する場合はカタカナで表したものに限ること、沢（澤）・辺（邊）など一般に同字として常用される字体は登録できることも書かれています。決まりは市区町村ごとに違うので、表には「お客様の住む市区町村で確かめる」とだけ書き、登録できるかの判断はこの構成ではしません。

1行目がこの構成のいちばん大きな落とし穴です。 読み取りの文字は、手書きの旧字体を見慣れた新字体で返すことがあります。それを台帳の「彫る文字」として指示書に大きく出せば、職人はそれを彫ります。 だから指示書では、読み取りの文字は検索用の小さな欄に置き、彫る字は画像で示します。

指示内容を固定する

この構成の読み取りはカスタム テンプレート モデルで、生成AIへの文章の指示はありません。指示にあたるのは、ラベルの付け方と、Power Automate の条件の設定です。

【ラベルの付け方（Document Intelligence Studio でモデルを作るとき）】
- order_no, received_date, customer_name, phone, delivery_date … 欄の値
- use_jitsuin, use_ginko, use_mitome, use_hojin, use_gomu … 選択マーク
- mat_tsuge, mat_kuro_suigyu, mat_titan, … … 選択マーク（材質ごと）
- size_105, size_120, size_135, size_150, size_165, size_180 … 選択マーク
- font_tensho, font_inso, font_koin, font_reisho, font_kaisho … 選択マーク
- dir_tate, dir_yoko, name_sei, name_mei, name_full … 選択マーク
- char_01 〜 char_08 … 彫る文字のマス（1字ずつの領域）
  領域のラベルには、マスの枠や周りの印刷の文字を含めない。
- 見本は少なくとも5枚。書き直しの跡がある票、チェックが二つ付いた票、
  チェックの無い欄がある票を混ぜる。

【Power Automate の条件】
1. 文書の種類の信頼度が 0.80 未満 → 票ごと「要確認（様式違い）」
2. 選択マークのグループごとに selected を数える
   - 1つ → その値を台帳へ
   - 0個・2個以上 → その欄を「要確認」、値は空のまま
   - selected の信頼度が 0.80 未満 → 「要確認」
3. 寸法 × 用途を「寸法の範囲の表」と照らし、範囲の外なら「要確認」
4. char_01〜08 の空でないマスを数え、彫り方と照らす
5. char_01〜08 の文字を「気をつける字の一覧」と照らし、
   含まれていれば「字体を画像で確かめる」の印を付ける
6. 値を直さない。読めた値をそのまま台帳へ入れ、要確認の欄は空のまま残す
7. 「要確認」が1つでもあれば、その店の店長に知らせる

「値を直さない」を条件の最後に置いているのは、親切な補正が誤りを隠すからです。 寸法の欄から「135」が返ったとき、「13.5の書き間違いだろう」と直して登録すると、本当に何が書かれていたかを誰も見なくなります。 直さずに要確認にすれば、店長が票を見て確かめます。

信頼度の基準の「0.80」は例です。 最初の1か月は、要確認に回る件数が多くても全部確かめ、どの欄でどの程度の信頼度のときに誤りが出たかを数えてから決めます。

出力形式を固定する

次の形で、注文の台帳に1件ずつ登録します。

{
  "order_no": "",
  "store": "駅前店",
  "received_date": "2026-10-28",
  "delivery_date": "2026-11-04",
  "customer_name": "",
  "phone": "",
  "use": "jitsuin | ginko | mitome | hojin | gomu | null",
  "material": "",
  "size_mm": null,
  "font": "",
  "layout": { "direction": "tate | yoko | null", "name_part": "sei | mei | full | null" },
  "chars_read": ["", ""],
  "chars_count": 0,
  "check_glyph": true,
  "flags": ["font_not_selected", "size_out_of_range"],
  "status": "ready | needs_check",
  "image_link": ""
}

1つ目の理由は、決められなかった欄を null のまま残せることです。 チェックの無い欄に、もっともらしい値を入れません。空であることが、店長が見るべき場所の印になります。

2つ目は、flags で、なぜ要確認なのかを店長が票を開く前に読めることです。 「書体の選択なし」「寸法が範囲の外」と分かっていれば、票の画像のその欄だけを見ます。

3つ目は、chars_read と check_glyph を分けて持つことです。 chars_read は検索用の読み取りの文字で、check_glyph が付いた注文は、指示書で字体の確認を目立たせます。 職人が彫る字は、image_link の票の画像で見ます。

工房の指示書は、この台帳の「彫刻待ち」のビューです。 列は、お渡しの日・店・材質・寸法・書体・彫り方・字体の確認の印・票の画像のリンクの順に並べ、status が ready のものだけを出します。

システムへ連携する

お客様への連絡は自動にしません。 要確認の注文について電話するかどうかは、店長が票を見てから決めます。チェックの抜けの多くは店頭の書き方の問題で、店長が票を見れば分かることも多いからです。

人が確認する

1. 店長が、要確認の注文の flags の欄だけを票の画像で確かめる … 台帳を直し、status を ready にします
2. お客様に確かめる必要があれば電話する … 書体の抜け、寸法の二重のチェックなど
3. 字体の確認の印の付いた注文は、彫る前に職人が画像を見る … マスの字形と、お客様の控えに書いた字形が同じかを確かめます
4. 工房の段取り役が、「彫刻待ち」のビューを毎朝開く … お渡しの日の近い順に職人に渡します

3番目は、check_glyph の有無にかかわらず、すべての注文で職人がマスの画像を見ます。 印を付けるのは、特に注意する注文を目立たせるためです。印の無い注文を読み取りの文字で彫ってよい、という意味ではありません。

目標は、360件をならして1件3分です。 要確認に回るのは2割前後という想定で、それより多い月は、ある店の書き方か、スキャンの濃さに理由があります。

例外に対処する

上の3行が、この構成の要確認の大半を占めます。 どれも読み取りの誤りではなく、店頭での書き方とスキャンのしかたの問題です。 店ごとの要確認の件数を毎週見て、多い店から書き方をそろえます。

記録を残す

• 注文票のスキャンと、保存した日時・店
• 読み取りの結果の全文（欄の値・選択マーク・字のマスの文字・信頼度）
• 台帳に登録した値と flags、そのときの照合の表の内容
• 店長が直した記録 … どの欄を、何から何に直したか
• お客様に電話した日時と、確かめた内容

3つ目で照合の表の内容を残すのは、表が後から変わるためです。 気をつける字を足したり寸法の範囲を変えたりすると、過去の要確認の意味が変わります。

4つ目は、見本を足す材料になります。 同じ欄で直しが続くなら、その崩れ方の票を見本に足して、モデルを作り直します。