歯科技工所に歯科医院から届く手書きの技工指示書を読み取り、補綴物の種類・部位・材料・色・納期を受注台帳に転記して、指示の書き漏れを医院への確認に回す
歯科医院から模型と一緒に届く手書きの技工指示書を、受付の日に読み取ります。補綴物の種類・部位・材料・色・納期を受注台帳の項目にそろえ、書き漏れと読めない欄を拾って、医院への確認の下書きを作ります。
- 生成AI
- ChatGPT/Claude/Gemini
- AIサービス
- Azure AI/Google Document AI
- 連携・自動化
- Google Apps Script/Python
- 対象業界
- 医療/製造
- 対象部門
- 生産
- 対象業務
- データ入力・転記/内容確認・チェック
- 主な課題
- 入力作業が多い/期限・対応漏れが起きる/確認ミスが多い
- AIで行う処理
- 読み取り(OCR)
- 主な効果
- 入力漏れ削減/対応スピード向上/工数削減
- 導入難易度
- ★★☆☆☆
- 実装レベル
- 本格構成
- 費用感
- API連携(中)
- 人間の確認
- 必須
01導入前 / 導入後の業務フロー
- 集配の担当が、医院から箱と指示書を受け取って技工所に戻る
- 受付の担当が箱を開け、指示書と模型・印象が合っているかを見る
- 指示書を見て、受注台帳に医院・歯科医師・患者・補綴物の種類・部位・材料・色・納期を打ち込む
- 部位・色・材料の書き漏れや読めない字があれば、付箋に書いて医院に電話する
- 製作の担当を決め、指示書の写しを模型と一緒に製作の工程に回す
- 指示書の原本を、医院ごと・月ごとに綴じて保管する
- 人受付の担当が箱を開け、指示書を複合機でスキャンして受付フォルダに保存する
- 自動保存をきっかけに、Form Parser が見出しの欄・チェック欄・表・読み取りの信頼度を返す
- 自動生成AIが、読み取った欄を受注台帳の項目にそろえる。部位と色は書かれた形のまま写す
- 自動医院の一覧と照らし、記載事項と製作に要る項目の書き漏れ、部位の書き方、納期の日付を規則で確かめる
- 自動同じ医院・同じ患者の直近の受注を受注台帳から探し、再製作の疑いに印を付ける
- 自動書き漏れのある指示書について、医院への確認の下書きを作る
- 人受付の担当が、印の付いた指示書だけを画像と並べて確かめ、医院に連絡する
- 人確かめた行を受注台帳に移し、製作の担当と納期を決める
各工程の詳しい説明を読む
- 集配の担当が、医院から箱と指示書を受け取って技工所に戻る
- 受付の担当が箱を開け、指示書と模型・印象が合っているかを見る
- 指示書を見て、受注台帳に医院・歯科医師・患者・補綴物の種類・部位・材料・色・納期を打ち込む
- 部位・色・材料の書き漏れや読めない字があれば、付箋に書いて医院に電話する
- 製作の担当を決め、指示書の写しを模型と一緒に製作の工程に回す
- 指示書の原本を、医院ごと・月ごとに綴じて保管する
(a)打ち直しが毎日ある。 午前と午後の集配で箱が届くたびに、受付の担当が指示書を打ち込みます。集配の多い曜日は、打ち込みが終わるまで製作の担当に箱が回りません。
(b)書き漏れに気づくのが製作に入ってから。 急いで打ち込むと、色の欄が空いている、部位の歯式の印が1本ずれて見える、といったことを見落とします。製作の担当が模型を見て気づいたときには、医院の診療時間が終わっていることもあります。 答えが翌日になれば、納期が1日縮みます。
(c)医院ごとの書式で見る場所が決まらない。 書式を覚えている担当なら見落としませんが、新しく入った担当は、部位の書き方の癖を医院ごとに覚えるまで時間がかかります。
(d)同じ患者の再製作と新規を取り違える。 以前に作ったものの作り直しや調整で届く指示書もあり、新規の受注として入れてしまうと、請求と製作の記録が二重になります。
- 【人】 受付の担当が箱を開け、指示書を複合機でスキャンして受付フォルダに保存する
- 【自動】 保存をきっかけに、Form Parser が見出しの欄・チェック欄・表・読み取りの信頼度を返す
- 【自動】 生成AIが、読み取った欄を受注台帳の項目にそろえる。部位と色は書かれた形のまま写す
- 【自動】 医院の一覧と照らし、記載事項と製作に要る項目の書き漏れ、部位の書き方、納期の日付を規則で確かめる
- 【自動】 同じ医院・同じ患者の直近の受注を受注台帳から探し、再製作の疑いに印を付ける
- 【自動】 書き漏れのある指示書について、医院への確認の下書きを作る
- 【人】 受付の担当が、印の付いた指示書だけを画像と並べて確かめ、医院に連絡する
- 【人】 確かめた行を受注台帳に移し、製作の担当と納期を決める
7番目で人が見るのは、印の付いた指示書だけです。 部位が決めきれない、色が空いている、材料が書かれていない、納期が読めない、といった指示書に印が付き、それ以外は一覧で流し見て台帳に移します。
部位だけは、印が無くても画像で見ます。 部位の取り違えは作り直しに直結するので、読み取った部位と指示書の画像を並べた欄を、確認の一覧の先頭に置きます。 ここだけは全件を人が見ても、1件数秒で済みます。
02今回想定するシステム構成
技工指示書(手書き。模型・印象と一緒に集配で届く) │ 受付で複合機スキャン ▼【トリガー】受付フォルダへの保存 Python(取り込みの処理) ├──▶ 1枚1ファイル、向き・解像度の確認 ▼ Google Document AI(Form Parser) │ 見出しの欄、チェック欄(歯式・材料)、表、信頼度 ▼ Claude API(構造化出力)── 受注台帳の項目にそろえる(部位・色は書かれた形のまま) ▼ Python ── 記載事項・製作に要る項目の確認、部位の書き方の確認、納期の日付、再製作の疑い ▼ 確認の一覧(部位の画像を先頭に)→ 医院への確認の下書き ▼ 【受付の担当が確かめて受注台帳に移す】
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| OCR | Google Document AI(Form Parser) | Azure AI Document Intelligence |
| 生成AI | Claude API(項目の対応づけと確認の下書き) | OpenAI API、Gemini API |
| 連携 | Python(フォルダの監視、API の呼び出し、確認の一覧の作成) | Google Apps Script |
| 差異計算 | Python(記載事項の確認、納期の日付、直近の受注との照合) | Google Apps Script |
| 保管 | 社内のファイルサーバー(指示書の画像と読み取りの結果) | クラウドのストレージ |
受注台帳には書き込みません。 この構成が出すのは確認の一覧と、確認の済んだ行を台帳に貼れる形の書き出しまでで、台帳に移すのは受付の担当です。 製作の担当と納期を決めるのも、いまと同じく人です。
土台は Document AI の Form Parser です。 公式のプロセッサ一覧では、OCR のテキストに加えてキーと値のペア(項目とチェックボックス)、表、一般的な項目を取り出すとされ、言語の一覧で日本語(ja)は手書きに対応する言語として示されています。指示書の「医院名」「患者名」はキーと値のペアとして、材料の□や歯式の図の□はチェックボックスとして読めます。
Form Parser は学習済みで、追加の学習はできないとされています。 医院ごとの書式に合わせて精度を上げるのではなく、どの書式でも読める欄を読み、決めきれない欄を人に回す設計にします。 技工所の書式を使う医院を増やすほど、印の付く指示書は減ります。
処理する場所に、日本のリージョンはありません。 プロセッサ一覧では、Form Parser の対応リージョンは us・eu と、シンガポール(asia-southeast1)などの単一リージョンです。指示書には患者の氏名と治療の内容が書かれているので、第13章のとおり取引先の医院と取り決めます。
03どうやって実装するのか
処理の起点を決める
受付の担当が指示書をスキャンし、受付フォルダに保存したことを起点にします。 集配の箱は午前と午後に分かれて届くので、届いた箱から順にスキャンし、1日の終わりにまとめる形にはしません。 書き漏れを医院の診療時間のうちに確かめるには、届いた時点で読み取っておく必要があります。
スキャンは1枚ずつではなく、集配1回分の指示書をまとめて複合機の自動給紙で読み込みます。ファイル名には日付と集配の回(午前・午後)を入れます。 箱と指示書の対応は、箱に付けた受付の番号を指示書の余白にも書いておき、読み取った番号で結びます。
Python のスクリプトは受付フォルダを数分おきに見に行き、新しいファイルを処理します。処理が終わったファイルは処理済みのフォルダへ移し、移すのは成功したときだけにします。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 指示書の画像 | 集配1回分のPDF。日付と集配の回、受付の番号 | 受付フォルダ |
| 読み取りの結果 | テキスト、見出しの欄、チェック欄の状態、表、信頼度 | Google Document AI |
| 医院の一覧 | 医院名、所在地、歯科医師の氏名、連絡先、使っている指示書の書式 | 受付で管理する一覧 |
| 書式の対応表 | 書式ごとの、部位・材料・色・納期の欄の名前とチェック欄の並び | 受付で作る一覧 |
| 材料と補綴物の一覧 | 技工所で受けている補綴物の種類と材料の名前、略称 | 受付で作る一覧 |
| シェードの記号の一覧 | 医院と取り決めたシェードガイドの記号 | 受付で作る一覧 |
| 受注台帳(直近) | 直近3か月の医院・患者・補綴物・部位 | 受注台帳の書き出し |
質を決めるのは、書式の対応表です。 医院の書式ごとに、どの欄名が部位で、どの欄名が色かを並べておきます。「シェード」「色調」「色」のように、同じ項目が書式ごとに違う名前で書かれているからです。 医院の一覧に「使っている書式」の列を持たせ、書式の対応表を引けるようにします。
材料と補綴物の一覧には、略称も入れます。 指示書では「Cr」「Br」「In」「CAD」のような略称がよく使われます。一覧に無い略称は、推測で当てずに印を付けます。
データの取得方法を決める
読み取りは、Python から Form Parser のプロセッサを呼んで行います。返ってくる Document から、見出しの欄・チェック欄・表・信頼度を取り出します。
| 取るもの | どこから | 何に使うか |
|---|---|---|
| 全テキスト | text | ほかの欄が startIndex・endIndex で指す原文 |
| 見出しの欄 | pages[].formFields(fieldName と fieldValue) | 医院名・歯科医師・患者名・発行日・納期・色 |
| チェック欄 | 値の種類(filled_checkbox / unfilled_checkbox) | 補綴物の種類、材料、保険・自費、歯式の図の□ |
| 表 | pages[].tables(headerRows と bodyRows) | 部位ごとに補綴物を並べた書式 |
| 信頼度 | 各要素の信頼度 | 確認の要る欄の印 |
技工所の書式では、歯式を□の図にしておきます。 上下左右の象限ごとに歯の番号を並べ、指示する歯の□にチェックを付ける形です。Form Parser はチェックボックスを filled_checkbox / unfilled_checkbox として返すので、どの□に印が付いたかで部位を読めます。 文字で書かれた部位より、取り違えが起きにくくなります。
医院の独自の書式で、象限の線と番号で部位を書いたものは、文字だけが返ってきます。 象限を示す縦線と横線は OCR のテキストに残らないので、「6」だけが読み取られ、右上か左下かが分かりません。 この形の部位は、読み取ったテキストを生成AIに渡しても決めきれないので、最初から人の確認に回します。
Form Parser の説明では、ラジオボタンは読まず、見つかったチェックボックスに対応するキーが無いこともあるとされています。 歯式の□は番号の文字とセットで読ませるために、□のすぐ横に番号を印刷しておきます。
医院の一覧と受注台帳は、毎朝書き出したものを読みます。医院の照合は、受付の番号と集配の回から先に決め、指示書の医院名はその確認に使います。 医院名の手書きの字から医院を決めると、似た名前の医院を取り違えます。
AIへ渡す前に整形する
- 1枚1ファイルに分ける … 集配1回分のPDFを、指示書1枚ずつに分けます。同期の要求のページ数の上限は15です
- 向きと傾き … 自動給紙で斜めに入ったものの傾きを直します
- 解像度 … 歯式の□とシェードの記号は小さいので、複合機の既定より高い解像度でスキャンします
- 書式の判定 … 受付の番号から医院を決め、医院の一覧から書式を引いて、書式の対応表を選びます
- 裏面と添付の除去 … 指示書の裏の白紙や、同封された写真・メモのページを分けます
- 重複の検知 … 同じ受付の番号で二度スキャンされたものに印を付けて止めます
3番目を軽く見ないでください。 シェードの記号の「3」と「3.5」、歯式の□のチェックは、解像度が足りないと潰れます。潰れた記号は、書かれていないのか読めなかったのかの区別がつきません。
AIに処理させる
生成AIにさせるのは、読み取った欄を受注台帳の項目にそろえることと、書き漏れの確認の下書きを作ることです。
| 見るもの | させること | 判断できないときの扱い |
|---|---|---|
| 見出しの欄 | 書式の対応表をもとに、受注台帳の項目に当てる | 当てられない欄は unknown |
| 補綴物の種類・材料 | チェックの付いた欄と略称を、一覧の名前に当てる | 一覧に無い略称は unmapped |
| 部位 | 歯式の□のチェックを歯の番号として返す。文字の部位は書かれた形のまま写す | 象限が決まらなければ tooth_unresolved |
| 色 | 書かれた記号をそのまま写す | 一覧に無い記号は shade_unlisted |
| 納期 | 書かれた文字をそのまま写す | 日付に直さない |
| 確認の下書き | 書き漏れの項目を並べた、医院への確認の文 | 書き漏れが無ければ作らない |
納期を日付に直させないのは、「来週火曜」「○日セット」のような書き方が多いからです。 日付への換算は、発行の年月日と照らして Python の側で行い、換算できないものは印を付けて人に回します。
| させないこと | 理由 |
|---|---|
| 部位の推測 | 補綴物の種類や模型の見込みから歯を決めると、作り直しになる |
| 色の補い | 前回の同じ患者の色で埋めると、指示の変更が消える |
| 材料の選び直し | 保険・自費の区分や補綴物から材料を決めるのは歯科医師 |
| 書き漏れの項目の埋め | 書かれていないことを、医院への確認に回すのが目的 |
| 指示の妥当性の判断 | 設計や材料の適否は、歯科医師と技工士が話して決める |
1行目がいちばん起きやすい失敗です。 「Cr 6」とだけ書かれた指示書を渡すと、生成AIは同じ医院の過去の受注や一般的な例から、ありそうな象限を選んで返すことがあります。部位は、読み取った根拠が無ければ空にさせ、空の部位には必ず印を付けます。
指示内容を固定する
あなたは歯科技工所の受付で、技工指示書の読み取り結果を受注台帳の形にそろえる担当です。
OCRが返した欄だけを見てください。推測で埋めないでください。
【受注台帳の項目】
clinic_name(医院名)、dentist_name(歯科医師)、patient_name(患者の氏名)、
issue_date(発行の年月日)、prosthesis(補綴物の種類)、material(材料)、
insurance(保険/自費)、teeth(部位)、shade(色)、due_text(納期の書き方)、
design_note(設計・作成の方法の記載)、remarks(備考)
【厳守事項】
- 書式の対応表に従って、各欄を項目に当ててください。当てられない欄は unknown_fields に入れてください。
- 補綴物の種類と材料は、チェックの付いた欄(filled_checkbox)と、
【材料と補綴物の一覧】にある略称だけから決めてください。
一覧に無い略称は、書かれたまま unmapped に入れてください。
- 部位は、歯式の□のチェックがあれば、その□の歯の番号を teeth に入れてください。
文字で書かれた部位は、書かれた形のまま teeth_text に写してください。
象限が分からない番号を、補綴物や過去の受注から推測して決めないでください。
決められなければ teeth を空にし、flags に tooth_unresolved を入れてください。
- 色は書かれた記号をそのまま写してください。前回の色や一般的な色で埋めないでください。
- 納期は書かれた文字のまま due_text に写してください。日付に直さないでください。
- 読めない字は空にし、その項目を unreadable_fields に入れてください。
- 書き漏れや読めない欄があれば、clinic_query に医院への確認の文を作ってください。
確認する項目だけを箇条書きにし、材料や部位の候補を挙げないでください。
- 設計や材料が適切かどうかの意見は書かないでください。
【書式の対応表】{form_map}
【OCRの見出しの欄】{form_fields}
【OCRのチェック欄】{checkboxes}
【OCRの表】{tables}
【材料と補綴物の一覧】{catalog}
【シェードの記号の一覧】{shade_list}
「象限が分からない番号を推測しない」を、理由の分かる形で明記します。 単に「推測しない」と書くだけだと、過去の受注から選んだものを「推測ではなく根拠がある」として返すことがあります。補綴物と過去の受注を名指しして禁じます。
医院への確認の文で候補を挙げさせないのも、同じ理由です。 「右上6番でよろしいでしょうか」と書いた確認は、医院が忙しいと「はい」で返ってきます。何が書かれていないかだけを伝え、答えは医院に書いてもらいます。
出力形式を固定する
次の形のJSONで受け取ります。
{
"receipt_no": "",
"clinic_name": "",
"dentist_name": "",
"patient_name": "",
"issue_date": "",
"prosthesis": [""],
"material": [""],
"insurance": "insurance | private | unknown",
"teeth": [""],
"teeth_text": "",
"shade": "",
"due_text": "",
"design_note": "",
"remarks": "",
"unmapped": [""],
"unreadable_fields": [""],
"unknown_fields": [""],
"flags": ["tooth_unresolved | shade_unlisted | material_missing"],
"clinic_query": ""
}
Claude の構造化出力では、オブジェクトに additionalProperties: false を設定する必要があり、数値の minimum・maximum や文字列の長さの制約は使えないとされています。 歯の番号が範囲内かどうかは Python で確かめます。
後段の確認は、この出力に対して規則で行います。 法令で定められた記載事項と、製作に要る項目を分けて持ちます。
| 確認 | 外れたとき |
|---|---|
| 患者の氏名・発行の年月日・歯科医師の氏名が空でない | legal_item_missing。医院へ確認 |
| 設計・作成の方法・使用材料のいずれかの記載がある | legal_item_missing。医院へ確認 |
部位が決まっている(teeth が空でない) | tooth_unresolved。医院へ確認 |
| 色が空でなく、シェードの記号の一覧にある | 空なら医院へ確認。一覧に無ければ印 |
| 納期の書き方を、発行の年月日から日付に換算できる | 換算できなければ印 |
| 納期までの日数が、補綴物ごとの標準の製作日数より短い | due_tight。工程管理の担当へ |
| 同じ医院・同じ患者・同じ部位の受注が直近にある | possible_remake。再製作か新規かを人が確かめる |
| 信頼度が基準を下回る欄がある | 欄ごとに印 |
医院の所在地と技工所の名称は、指示書から読めなくても一覧で補えますが、記載の有無は別に記録します。 補えることと、書かれていることは別の事実です。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 受付フォルダ | Python のフォルダ監視 | 新しいファイルを見つける |
| Google Document AI | API呼び出し | 見出しの欄・チェック欄・表・信頼度を返す |
| Claude API | API呼び出し | 項目の対応づけと確認の下書き |
| 医院の一覧・書式の対応表 | 表計算の読み取り | 書式と医院の照合 |
| 受注台帳 | 毎朝の書き出しファイル | 直近の受注との照合 |
| 確認の一覧 | 社内の共有の表計算ファイル | 印の付いた指示書を画像へのリンクと並べる |
医院への確認は、下書きまでです。 電話で聞くか、FAX で送るかは医院ごとの取り決めに従い、送るのは受付の担当です。 答えが返ってきたら、確認の一覧の該当の欄に書き、台帳に移します。
人が確認する
人が見るのは、部位の欄と、印の付いた指示書です。
- 部位の欄を全件見る … 読み取った部位と指示書の画像の部位の欄を並べ、1件数秒で見ます
legal_item_missingとtooth_unresolvedを先に医院へ確認する … 診療時間のうちに電話できるよう、午前の集配の分は昼までに確認を出します- 色・材料・納期の印を確かめる … 一覧に無い記号や略称は、医院の癖なら一覧に足し、分からなければ医院に聞きます
possible_remakeを確かめる … 再製作か新規かを、箱の中の模型と以前の記録で確かめます- 台帳に移す … 確かめた行を受注台帳に移し、製作の担当と納期を決めます
1番目は省かないでください。 部位は、印が付かなくても誤りうる唯一の項目です。□のチェックが隣の□にはみ出していても、読み取りの結果としては正しく見えるからです。
目標は、900件をならして1件1.2分です。 印の無い指示書は部位を見て台帳に移すので数十秒、印の付いた指示書は医院への確認があるので数分かかります。
例外に対処する
| 起きること | 対応 |
|---|---|
| 象限の線で部位が書かれている | tooth_unresolved。画像を見て人が決め、決められなければ医院へ |
| 歯式の□のチェックが隣にはみ出す | 部位の欄の全件確認で拾う |
| 一覧に無い略称・記号 | unmapped・shade_unlisted。医院の癖なら一覧に足す |
| 納期を日付に換算できない | 印を付けて人が決める。医院に確かめる |
| 受付の番号が読めない | 箱と指示書の対応を人が確かめる |
| 指示書の無い箱が届く | 製作に回さず、医院へ指示書を求める |
| 1枚に複数の患者の指示がある | 患者ごとに行を分けて印を付ける |
| 写真やメモのページが混ざる | 書式の判定で分け、読み取りに回さない |
| Document AI が応答しない | フォルダに残し、受付の担当がいまの手順で打ち込む |
6行目は、この構成の外の話に見えて重要です。 歯科技工士法の第18条は、歯科医師の指示書によらなければ業として歯科技工を行ってはならないとしています(病院・診療所内で歯科医師の直接の指示に基づく場合を除く)。指示書が届いていない箱は、読み取る以前に製作に回しません。
記録を残す
- 指示書の画像と、日付・集配の回・受付の番号
- OCR が返した
Documentの全文(text、formFields、tables、信頼度) - 生成AIの出力(台帳の項目、
flags、clinic_query)と、規則の確認の結果 - 人が直した欄の記録 … どの指示書の、どの欄を、何から何に直したか。直した担当と日時
- 医院への確認の内容と、返ってきた答え、答えを受けた日時
医院への確認と答えの記録は、作り直しの原因を追うときの材料になります。 装着のときに合わなかった補綴物について、指示書に何が書かれていて、何を医院に確かめ、何と答えが返ってきたかが1か所でつながります。
04実装レベルの3段階
最小構成では枚数がさばけません。 1枚ずつ貼るので、月900件には使えません。医院ごとの書式が読めるかを確かめる段階です。 半自動化で、1件4分が2分程度になります。 打ち込みは自動になりますが、書き漏れの確認と医院への確認の準備を人が行います。本格構成で1.2分になり、この段階が本記事の想定です。 差が大きいのは、書き漏れの確認が規則で行われ、人が見るのが部位の欄と印の付いた指示書だけになるからです。 段階を飛ばさないでください。 半自動化の一覧を1か月見ると、読めない書式の医院と、一覧に足りない略称が見えます。そこを直してから本格構成に進むほうが、印の付く指示書が減ります。
05工数削減シミュレーション
導入後 900件 × 1.2分 ÷ 60 = 18 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 数十の歯科医院と取引し、集配で届く手書きの技工指示書を受付の担当が受注台帳に打ち直している歯科技工所。月に数百件の指示書があり、部位や色の書き漏れに気づくのが製作に入ってからで、医院への確認が納期を圧迫している場合。医院ごとに指示書の書式がばらばらで、受付の担当によって確かめる項目が違う場合。社内に Python を動かせる PC かサーバーがある場合。
- 取引する医院の多くが、デジタルの印象とWebの発注の仕組みで指示を送ってくる技工所。指示書が月に数十件で、受付の担当が見て足りる場合。なお、補綴物の設計や材料の適否、部位と補綴物の組み合わせが妥当かの判断、指示の内容の変更は、この構成では代替できません。指示の内容を決めるのは歯科医師です。
07最小構成で試す方法
- 先月の指示書から30枚を選ぶ(医院の独自の書式、象限の線で部位を書いたもの、色が空いていたもの、略称の多いものを入れる)
- その30枚について、受注台帳に入っている値を書き出しておく
- 指示書の画像を、手元の生成AIの画面に1枚ずつ貼る
- 「この指示書の医院名・患者名・補綴物・材料・部位・色・納期を表にしてください。部位が読み取れなければ空にし、推測しないでください。書き漏れの項目を挙げてください」と指示する
- 出てきた表を、台帳の値と1欄ずつ比べる
30枚は必ずやってください。 Form Parser とプログラムを組む前に、医院ごとの書式で部位と色が読めるのかを確かめます。
| 出てきた内容 | 判断 |
|---|---|
| 台帳とほぼ同じ表が出た | OCR の API と確認の一覧に進む |
| 象限の分からない部位を推測で埋めた | 指示で直る。部位の全件確認は必ず残す |
| 色や納期を前回の値や一般的な値で埋めた | 指示と、後段の空欄の確認で止められる |
| 独自の書式の部位がほとんど読めない | 書式が先。 技工所の書式を医院に勧める |
4行目が出ることは珍しくありません。 失敗ではなく、受付で部位の読み違いが起きていた理由が1つ分かったということです。 取引の多い医院から、歯式の□のある書式に切り替えてもらう相談を始めてください。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 象限の分からない部位を推測で埋める | 補綴物と過去の受注を名指しして禁じ、部位を全件確認する |
| 色を前回の値で埋める | 書かれた記号のまま写させ、空なら医院へ確認 |
| 確認の文に候補を書く | 候補を挙げさせず、何が無いかだけを伝える |
| 象限の線が OCR に残らない | 技工所の書式に歯式の□の図を入れる |
| □のチェックが隣にはみ出す | 部位の欄だけは全件を人が見る |
| 欄の名前が書式ごとに違う | 書式の対応表を医院の一覧から引く |
| 略称を一般的な意味で当てる | 一覧に無い略称は印にして、医院の癖を一覧に足す |
| 納期を生成AIが日付に直す | 書かれた文字のまま受け、換算は Python で |
| 再製作を新規として入れる | 同じ医院・患者・部位の直近の受注に印 |
| 国外で処理されることを医院と取り決めていない | 日本のリージョンは無い。 委託の取り決めに入れる |
上の3行が、この構成でいちばん重い失敗です。 どれも、生成AIが「親切に」埋めた値が医院の指示として製作に回る経路です。書かれていないことを、書かれていないとして医院に返します。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 患者の氏名、補綴物の種類と部位、材料、保険・自費の区分、医院と歯科医師の情報です。患者の治療の内容が分かる情報で、医院から預かっているものです。
- 医院との取り決めに入れる … 指示書の画像を外部のサービスで読み取ることを、取引の取り決めに書き、医院の了解を得ます。医院の側でも、患者の情報の取り扱いを患者に説明しているはずなので、その範囲に収まるかを医院と確かめます
- 処理の場所を確かめる … Form Parser の対応リージョンに日本はありません。
us・euかシンガポールなどから選びます。生成AIの API も国外で処理されうるので、両方を取り決めに書きます - 生成AIに渡す範囲を絞る … 生成AIには読み取った欄と一覧だけを渡し、受注台帳の過去の記録は渡しません。直近の受注との照合は Python の側で行います
- 指示書の原本を保存する … 歯科技工士法の第19条は、歯科技工所の管理者が、指示書を歯科技工が終了した日から2年間保存しなければならないとしています。画像を残すようになっても、紙の原本の保存をやめてよいかは、所管の保健所などに確かめます
- 指示の内容を変えない … この構成は、書かれていない項目を医院に返すだけです。材料や部位の選び直し、設計の変更は、歯科医師の指示によります
- 受注台帳に書き込まない … 台帳に移すのは受付の担当です
誤りが起きた場合のリスクは、部位や色を誤って製作することと、書き漏れが製作に入るまで見つからないことの2つです。前者は推測の禁止と部位の全件確認で、後者は記載事項と製作に要る項目を規則で確かめ、受付の日に医院へ返すことで防ぎます。
10まず何から始めるか
1週目:書式の対応表を作る
取引の多い医院から順に、指示書の書式ごとに部位・材料・色・納期の欄の名前を並べます。医院の一覧に「使っている書式」の列を足します。 材料と補綴物の略称、シェードの記号の一覧も作ります。
2週目:30枚で試す
先月の指示書から30枚を選び、最小構成で台帳の形の表にさせて、台帳の値と比べます。象限の分からない部位を推測で埋めていないかを最優先で見ます。
3週目:書式を見直し、医院と取り決める
技工所の書式に歯式の□の図と版の番号を入れ、取引の多い医院に切り替えを相談します。あわせて、指示書の画像を外部のサービスで読み取ることを、医院との取り決めに入れます。
4週目:受付フォルダから一覧までをつなぐ
指示書をスキャンすると Form Parser が動き、台帳の項目の一覧に書き出すところまで作ります。この時点では確認の規則を入れず、読み取りの結果だけを見ます。
2か月目: 書式の対応表、記載事項と製作に要る項目の確認、部位の全件確認の欄を足し、印の付いた指示書だけを詳しく見る運用にします。3か月目以降: 納期の換算、再製作の疑い、医院への確認の下書きを足し、1件4分が何分になったかを実測します。製作に入ってから見つかる書き漏れが月を追って減ったことを確かめた時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
Form Parser がキーと値のペア(項目とチェックボックス)、表、一般的な項目を OCR のテキストに加えて取り出すこと。言語の一覧で日本語(ja)が手書きに対応する言語として示されていること(原文の HTML で確認)。対応リージョンが us・eu・asia-southeast1 などで日本が無いこと。同期の要求のページ数の上限が15であること | Google Cloud: Processor list | 2026-10-14 |
| Form Parser が学習済みで追加の学習ができないこと。チェックボックスがキーと値のペアとして返ること。ラジオボタンを読まないこと、見つかったチェックボックスに対応するキーが無いことがあること | Google Cloud: Form Parser | 2026-10-14 |
text が認識されたテキストの元であり、ほかの欄が startIndex・endIndex で指すこと。formFields が fieldName と fieldValue を持つこと。チェックの有無が filled_checkbox・unfilled_checkbox で示されること。表が headerRows と bodyRows に分かれること | Google Cloud: Handle the processing response | 2026-10-14 |
構造化出力が output_config.format に JSON スキーマを指定して有効になること。オブジェクトに additionalProperties: false が必要なこと。数値の minimum・maximum や文字列の minLength・maxLength が非対応であること | Claude Docs: Structured outputs | 2026-10-14 |
| 歯科技工士法第18条で、歯科医師の指示書によらなければ業として歯科技工を行ってはならないとされ、病院・診療所内で歯科医師の直接の指示に基づく場合が除かれていること。第19条で、歯科技工所の管理者が指示書を歯科技工が終了した日から2年間保存しなければならないとされていること(法令APIで条文を確認) | e-Gov 法令API: 歯科技工士法 | 2026-10-14 |
| 歯科技工士法施行規則第12条で、指示書の記載事項が、患者の氏名/設計/作成の方法/使用材料/発行の年月日/発行した歯科医師の氏名と勤務する病院・診療所の所在地/歯科技工所の名称・所在地・歯科技工所番号(歯科技工所で行う場合)と定められていること(法令APIで条文を確認) | e-Gov 法令API: 歯科技工士法施行規則 | 2026-10-14 |
指示書の記載が足りているか、紙の原本の保存の扱い、患者の情報を外部のサービスで処理することの可否は、医院と所管の保健所などに確かめて判断してください。 本記事は、上記の公開情報で確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-1523)についてのご相談はこちらから。
