表具店が手書きのふすま・障子の張替の採寸と注文の票を読み取り、枚数・寸法・紙の種類を工房の作業の指示と見積にする
客先で採寸して手書きする、ふすま・障子の張替の採寸と注文の票を読み取ります。部屋ごとの枚数・寸法・紙の種類を、工房の作業の指示と、単価表に照らした見積の下書きにそろえます。
- 生成AI
- ChatGPT/Claude/Gemini
- AIサービス
- AWS Textract/Azure AI/Google Document AI
- 連携・自動化
- Google Apps Script/Python
- 対象業界
- その他/不動産/建設
- 対象部門
- 営業
- 対象業務
- データ入力・転記/書類作成
- 主な課題
- 入力作業が多い/書類作成に時間がかかる/確認ミスが多い
- AIで行う処理
- 読み取り(OCR)
- 主な効果
- 入力漏れ削減/対応スピード向上/工数削減
- 導入難易度
- ★☆☆☆☆
- 実装レベル
- 半自動化
- 費用感
- API連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 店主か職人が客先で採寸し、票を書き、客と紙の種類を決める
- 店に戻り、票を受付の箱に入れる
- 店主が票を見て、単価表を引き、見積書を手で書くか表計算に打ち込む
- 見積を客や管理会社に送り、注文の返事を待つ
- 注文が決まったら、事務の担当者が票から工房の作業票に建具ごとの寸法と紙の種類を写す
- 週の初めに、作業票から紙の種類ごとの枚数を数え、紙の在庫の控えと見比べて発注する
- 職人が作業票を見て、建具を引き取り、張り替える
- 人店主か職人が客先で採寸し、票を書き、客と紙の種類を決める(ここは変えない)
- 人店に戻ったら、採寸した人が票を複合機でスキャンし、受付フォルダに保存する
- 自動事務の担当者がボタンを押すと Python の処理が動き、受付フォルダの票を Document AI で読み取る
- 自動建具の表の行ごとに、枚数・高さ・幅の書式と、同じ部屋の寸法のばらつきを規則で確かめる
- 自動生成AIが紙の種類の書き方を、紙の品番の一覧の候補に当てる。備考を補修の項目に分ける
- 自動大きさの区分を高さと幅から決め、単価表を引いて見積の下書きを作る
- 自動店主に、確認の要る行(寸法の疑い・品番の決まらない紙・単価表に無い組み合わせ)を一覧で示す
- 人店主が一覧を見て、必要なら採寸した人や客に確かめ、見積を確定して送る
- 自動注文が決まった票から、工房の作業の指示を紙の種類ごとに並べて作る
- 自動週の初めに、紙の種類ごとの枚数と寸法を集計し、紙の在庫の控えと並べる
- 人職人が作業の指示を見て、建具を引き取り、張り替える
各工程の詳しい説明を読む
- 店主か職人が客先で採寸し、票を書き、客と紙の種類を決める
- 店に戻り、票を受付の箱に入れる
- 店主が票を見て、単価表を引き、見積書を手で書くか表計算に打ち込む
- 見積を客や管理会社に送り、注文の返事を待つ
- 注文が決まったら、事務の担当者が票から工房の作業票に建具ごとの寸法と紙の種類を写す
- 週の初めに、作業票から紙の種類ごとの枚数を数え、紙の在庫の控えと見比べて発注する
- 職人が作業票を見て、建具を引き取り、張り替える
(a)見積を出すまでに日数がかかる。 3番は、店主が現場から戻った夕方か休みの日にまとめて行います。管理会社は次の入居者の入居日を決めていて、見積が遅れると張替の日程が詰まります。
(b)寸法を写し違える。 3番と5番で、同じ寸法を2回写します。「1760」を「1706」、「865」を「856」と写すと、見積は合っているのに作業票だけ違うということが起きます。裁つ段階で気づけばよいほうで、張った後に建具に合わずに張り直すこともあります。
(c)紙の種類の書き方がそろわない。 「鳥の子」「普及」「いつもの」「前回と同じ」。書いた人には分かっても、見積を作る店主や作業票を写す事務の担当者には、品番が1つに決まらないことがあります。 そのたびに書いた職人に聞き直します。
(d)紙の種類ごとの集計を手で数えている。 6番は、作業票を紙の種類ごとに並べ直して数える作業です。数え違えると、作業の途中で紙が足りなくなります。 問屋への追加の発注は数日かかることがあり、その間は同じ紙の建具がすべて止まります。
(e)管理会社の部屋ごとの請求が追えない。 管理会社は、物件と部屋の番号ごとに見積と請求を突き合わせます。票に部屋の番号が書かれていても、見積に写すときに抜けると、 管理会社から「どの部屋の分か」と問い合わせが来ます。見積と作業票と請求で、部屋の番号が同じ書き方でそろっていることが、管理会社との取引を続ける条件になっています。
- 【人】 店主か職人が客先で採寸し、票を書き、客と紙の種類を決める(ここは変えない)
- 【人】 店に戻ったら、採寸した人が票を複合機でスキャンし、受付フォルダに保存する
- 【自動】 事務の担当者がボタンを押すと Python の処理が動き、受付フォルダの票を Document AI で読み取る
- 【自動】 建具の表の行ごとに、枚数・高さ・幅の書式と、同じ部屋の寸法のばらつきを規則で確かめる
- 【自動】 生成AIが紙の種類の書き方を、紙の品番の一覧の候補に当てる。備考を補修の項目に分ける
- 【自動】 大きさの区分を高さと幅から決め、単価表を引いて見積の下書きを作る
- 【自動】 店主に、確認の要る行(寸法の疑い・品番の決まらない紙・単価表に無い組み合わせ)を一覧で示す
- 【人】 店主が一覧を見て、必要なら採寸した人や客に確かめ、見積を確定して送る
- 【自動】 注文が決まった票から、工房の作業の指示を紙の種類ごとに並べて作る
- 【自動】 週の初めに、紙の種類ごとの枚数と寸法を集計し、紙の在庫の控えと並べる
- 【人】 職人が作業の指示を見て、建具を引き取り、張り替える
8番目が、この設計の分かれ目です。 店主が見るのは全行ではなく、疑いの印の付いた行と、見積の合計だけです。印の無い行は、読み取った値がそのまま見積と作業の指示に入ります。
9番目は、見積と同じ行から作ります。 店主が8番で寸法を直したら、その直した値が作業の指示に入ります。写し直しの段がなくなるので、見積と作業の指示の寸法が食い違うことがありません。
02今回想定するシステム構成
採寸と注文の票(A4・1件1枚。手書きの建具の表と備考) │ 採寸した人が帰店後にスキャン ▼【トリガー】事務の担当者がボタンを押す(1日に2回が目安) Python(取り込みの処理) ├──▶ 1枚1ファイル、向きの確認 ▼ Google Document AI(Form Parser) │ 上の欄のキーと値、建具の表の行とセル、片面・両面のチェック ▼ Python ── 寸法の書式とばらつき、大きさの区分 ▼ Claude API(構造化出力)── 紙の書き方を品番の候補に当てる、備考を補修の項目に分ける ▼ Python ── 単価表を引いて見積の下書き、店主への一覧 ▼ 【店主が確かめて見積を確定】 ▼ Python ── 紙の種類ごとの作業の指示、週の集計
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| OCR | Google Document AI(Form Parser) | Azure AI Document Intelligence(レイアウト モデル)、AWS Textract(英文の書類に限る。日本語の票には使えない) |
| 生成AI | Claude API(紙の書き方の当て方と備考の分け方。構造化出力) | OpenAI API、Gemini API |
| 連携 | Python(読み取りの呼び出し、単価表の参照、一覧の作成) | Google Apps Script |
| 集計 | Python(紙の種類ごとの枚数と寸法) | Google Apps Script |
| 保管 | 店のパソコンの共有フォルダ(票の画像、見積の下書き、作業の指示) | Google ドライブ |
単価表は、いま使っているものです。 足すのは2つの表です。紙の品番の一覧(品番、呼び方、よく書かれる略し方、ふすま用か障子用か)と、客ごとの決まった紙の表(管理会社ごとの「いつもの」の品番)です。後者があると、管理会社の票の「いつもの」が品番に決まります。
土台は Document AI の Form Parser です。 公式の説明では、Form Parser はキーと値のペア、表、チェックボックスなどの選択の印を取り出し、学習済みで追加の学習はできないとされています。公式のプロセッサ一覧では、日本語(ja)は手書きに対応する言語です。票の上の欄はキーと値のペア、建具の表は表、片面・両面や引手の交換はチェックボックスとして読みます。
処理する場所に、日本のリージョンはありません。 Form Parser の対応リージョンは us・eu と、シンガポール(asia-southeast1)などです。票には客の名前と住所が載ります。国外で処理することを、店の個人情報の扱いの決まりで整理し、 管理会社の票は管理会社との取り決めに照らして確かめます。
★1にしているのは、仕組みが小さいからです。 動かすのは事務の担当者のパソコンの Python の処理1つで、ボタンを押したときだけ動きます。 常に動かしておくサーバーや、他のシステムへの書き込みはありません。
03どうやって実装するのか
処理の起点を決める
事務の担当者が、受付フォルダの票を処理するボタンを押したときに動きます。 目安は1日に2回、昼と夕方です。採寸に出た店主や職人が戻る時刻に合わせ、昼に押せば午前の採寸の見積を、その日のうちに出せます。
自動で見張る形にしないのは、押す人が結果の一覧を見る人だからです。 押してすぐに店主への一覧ができるので、事務の担当者が店主に声をかけ、その場で確かめられます。小さな店では、通知を送るより声をかけるほうが早く済みます。
スキャンは、採寸した人が店に戻ったときに自分で行います。1件1ファイルで保存し、ファイル名の先頭に採寸の日を付けます。 処理が終わった票は月ごとのフォルダへ移し、移すのは見積の下書きを作り終えたときだけにします。 受付フォルダに残っている票が、そのまま見積の済んでいない注文です。
週の初めの集計は、月曜の朝に事務の担当者が別のボタンを押して作ります。 前の週までに注文の決まった票が対象です。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 票の画像 | 採寸の日、客の名前、物件と部屋の番号、住所、採寸した人。行ごとに部屋、種類、枚数、高さ、幅、紙の種類、片面・両面、引手・縁・骨の補修。備考、希望の納期 | 受付フォルダ |
| 読み取り結果 | キーと値のペア、表の行とセル、チェックボックスの状態、文字の位置 | Document AI |
| 単価表 | 種類×大きさの区分×紙の種類の1枚あたりの単価、補修の単価 | 店の表計算ファイル |
| 大きさの区分の表 | 区分ごとの高さと幅の範囲 | 店主が単価表から作る表 |
| 紙の品番の一覧 | 品番、呼び方、略し方、ふすま用か障子用か | 店主が作る表 |
| 客ごとの決まった紙 | 管理会社ごとの「いつもの」の品番 | 店主が作る表 |
| 紙の在庫の控え | 品番ごとの残り | 店の表計算ファイル |
質を決めるのは、紙の品番の一覧の「略し方」の列です。 職人が票に書く書き方は、人ごとにほぼ決まっています。「鳥」「とりのこ」「T-」のような書き方を一覧に入れておくと、紙の書き方から品番への当て方が、生成AIに頼らなくても多くの行で決まります。 決まらない行だけを生成AIの候補探しに回します。
大きさの区分の表は、単価表から作ります。 いまの単価表が「大」「中」「小」とだけ書いてあれば、それぞれ高さと幅がいくつからいくつまでかを店主が決めて書き足します。 ここがあいまいなままだと、境目の寸法の建具で見積の単価が人によって変わります。
客の名前と住所は、生成AIへ渡しません。 紙の書き方の当て方と備考の分け方に要るのは、紙の書き方と備考の文、品番の一覧だけです。
データの取得方法を決める
読み取りは、Python から Document AI の REST の process のメソッドを呼びます。公式の説明では、リクエストの本文の rawDocument に MIME タイプと base64 にした画像を入れて送り、版を指定するなら processorVersions の下の :process に送ります。
| 取るもの | どこから | 何に使うか |
|---|---|---|
| 採寸の日・客・物件と部屋・採寸した人 | pages[].formFields | 見積の宛先と客ごとの決まった紙 |
| 建具の行 | pages[].tables[] の headerRows と bodyRows | 種類・枚数・寸法・紙の書き方 |
| 片面・両面、引手・縁・骨 | formFields の fieldValue の valueType | 見積の行と補修 |
| 備考・希望の納期 | formFields の値の文字列 | 補修の項目、納期 |
| 文字の位置 | textAnchor の startIndex と endIndex | 疑いのあるセルの画像の切り出し |
チェック欄は、印の有無を値で受け取ります。 公式の説明では、印の付いたチェックボックスは fieldValue の valueType が filled_checkbox、付いていないものは unfilled_checkbox で返ります。片面と両面の両方に印があれば、決めずに確認に回します。 両面の張替は単価が変わるので、どちらかを選んで見積に入れることはしません。
建具の表は、セルを結合しない様式にします。 公式の説明では、Form Parser の表の取り出しは行や列をまたぐセルの無い単純な表が対象です。いまの票で同じ部屋の行を縦に1つのセルでまとめていれば、部屋の名前を行ごとに書く形に変えます。 「〃」で上の行と同じことを示す書き方は残してよく、Python の側で上の行の部屋を引き継ぎます。
寸法は、高さと幅を別の列にします。 「1760×865」と1つの欄に書く形だと、「×」が読み取りで落ちて「1760865」になります。列を分ければ、桁の数で確かめられます。 なお公式の説明では、Form Parser のチェックボックスのモデルはラジオボタンの読み取りに対応していないので、片面・両面は丸で囲む形ではなく四角の欄にします。
空いたセルは、空として扱います。 公式の説明では、Form Parser は値の入っていないキーと値のペアを確実には読めないとされています。紙の種類が空の行は、上の行と同じとは見なさず、 「〃」が読めたときだけ引き継ぎます。
AIへ渡す前に整形する
- 1枚1ファイルの確認 … 2ページ以上のファイルは分けます。公式のプロセッサ一覧では、Form Parser の同期の処理は1回15ページまでです
- 向きの確認 … 横向きにスキャンされた票は、向きを直してから送ります
- 「〃」の引き継ぎ … 部屋と紙の種類の「〃」は、上の行の値で埋め、埋めたことを行に残します
- 寸法の書式の確かめ … 高さと幅が数字として読め、店の決めた範囲(建具の種類ごとの最小と最大)に入るかを見ます
- 同じ部屋のばらつきの確かめ … 同じ部屋・同じ種類の建具で、高さか幅が他と大きく違う行に印を付けます
- 枚数の確かめ … 枚数が0、または同じ部屋の他の種類と比べて極端に多い行に印を付けます
- 大きさの区分の決定 … 高さと幅から、大きさの区分の表で区分を1つに決めます。境目から一定の幅に入る寸法は、決めずに確認に回します
5番目が、写し違いを拾う確かめです。 ふすまは同じ部屋の4枚がほぼ同じ寸法で、1枚だけ「1706」なら、読み取りか書き方の誤りを疑えます。 本当にその1枚だけ違う建具もあるので、直さずに印を付けて店主に回します。
寸法を規則で直すことはしません。 「1706」を同じ部屋の他の値に合わせて「1760」にすると、本当に寸法の違う建具に合わない紙が裁たれます。 疑いの印を付け、採寸した人に確かめます。
AIに処理させる
寸法の確かめ、大きさの区分、単価の引き、集計は、Python の規則で行います。 生成AIには、品番の一覧の略し方で決まらなかった紙の書き方を候補に当てる仕事と、備考を補修の項目に分ける仕事だけを渡します。
| 規則で見るもの | 印を付ける条件 |
|---|---|
| 寸法の範囲 | 建具の種類ごとの最小と最大の外 |
| 同じ部屋のばらつき | 同じ部屋・同じ種類の他の行と大きく違う |
| 大きさの区分の境目 | 境目から一定の幅に入る |
| 紙の品番 | 略し方の一覧でも生成AIの候補でも1つに決まらない |
| 紙と建具の組み合わせ | ふすま用の紙が障子の行に書かれている、またはその逆 |
| 単価表 | 種類×区分×紙の組み合わせが単価表に無い |
| 片面・両面 | 両方に印、または両方に印が無い |
| 生成AIにさせること | 中身 |
|---|---|
| 紙の書き方の当て方 | 品番の一覧から候補を最大3つ、根拠にした語とともに返す |
| 決まったかの区別 | 候補が1つで、一覧の呼び方か略し方と同じ語が書かれているときだけ matched |
| 備考の分け方 | 引手の交換、縁の交換、骨の修理、穴のふさぎ、その他に分け、建具の行に結び付ける語(「左から2枚目」「押入」など)を写す |
「前回と同じ」「いつもの」は、生成AIに当てさせません。 客ごとの決まった紙の表に品番があれば Python がその品番を使い、無ければ決まらないものとして店主に回します。 過去の注文から推し量らせると、前回が別の部屋の別の紙だったときに誤ります。
| させないこと | 理由 |
|---|---|
| 品番の決めつけ | 書かれた語が一覧と合わなければ候補にとどめる |
| 寸法の補正 | 疑いの印を付け、採寸した人に確かめる |
| 単価や金額の計算 | 単価表から Python が出す |
| 骨の修理を引き受けるかの判断 | 店主が建具を見て決める |
| 値引きの判断 | 店主が客との関係で決める |
1行目が起きやすい失敗です。 「上級鳥の子」とだけ書かれていると、生成AIは一覧から「上級」と「鳥の子」の両方を含む品番を1つ選んで matched にしたがります。同じ語を含む品番が2つあれば、候補を2つ返させ、店主が客に確かめます。
指示内容を固定する
あなたは表具店の受付の補助です。
採寸と注文の票に書かれた「紙の種類」の書き方を、紙の品番の一覧に当ててください。
あわせて、備考の文を補修の項目に分けてください。
【渡すもの】
- 紙の書き方:票の1行に書かれた紙の種類の欄の文字
- 建具の種類:ふすま/戸襖/天袋/地袋/障子
- 品番の一覧:品番、呼び方、略し方、ふすま用か障子用か
- 備考の文
【紙の当て方】
- 一覧の呼び方か略し方と同じ語が書かれていて、候補が1つなら status を matched に。
- 候補が2つ以上、または同じ語が無ければ status を candidates にし、候補を最大3つ返す。
- 建具の種類に合わない用途の品番(障子の行にふすま用の紙など)は候補に入れない。
- 「前回と同じ」「いつもの」「同上」は status を needs_master にし、候補を返さない。
- 候補ごとに、根拠にした語を evidence に写す。
【備考の分け方】
- pull(引手の交換)、frame(縁の交換)、lattice(骨の修理)、patch(穴のふさぎ)、other に分ける。
- どの建具かを示す語(「左から2枚目」「押入」など)は target に写す。
- 修理を引き受けるべきか、費用がいくらかを書かない。
【厳守事項】
- 書かれていない品番を作らない。一覧に無い品番を返さない。
- 読めない文字は「?」のまま残す。
【紙の書き方】{paper_text}
【建具の種類】{fitting_type}
【品番の一覧】{paper_master}
【備考】{remarks}
「一覧に無い品番を返さない」を明記しないと、それらしい品番を作ります。 紙の品番は問屋の型番に似た形をしていて、一覧に無い番号でも見た目では区別がつきません。 見積に入ってから問屋に問い合わせて初めて、存在しない品番だと分かります。
構造化出力で、答えの形を固定します。 公式の説明では、Claude API の構造化出力は output_config.format に type: "json_schema" でスキーマを渡し、オブジェクトには additionalProperties: false が要ります。status と補修の項目は enum で決まった値に限ります。
出力形式を固定する
{
"paper": {
"status": "candidates",
"candidates": [
{ "code": "FS-210", "name": "上級鳥の子 無地", "evidence": "上級鳥の子" },
{ "code": "FS-215", "name": "上級鳥の子 柄入", "evidence": "上級鳥の子" }
]
},
"repairs": [
{ "kind": "pull", "target": "左から2枚目", "evidence": "引手 左2枚目 交換" }
]
}
Python は、この JSON と規則の結果を合わせて、見積の下書きの行を作ります。
| 見積の行の列 | 入る値 | 出どころ |
|---|---|---|
| 部屋・建具の種類・枚数 | 票の値。「〃」は引き継いだ印つき | 読み取り |
| 高さ・幅・大きさの区分 | 票の値と、区分の表で決めた区分 | 読み取りと Python |
| 紙の品番 | 決まった品番。決まらなければ空と候補 | 一覧とプロンプト |
| 片面・両面 | チェック欄 | 読み取り |
| 単価・金額 | 単価表 × 枚数 | Python |
| 補修 | 引手・縁・骨・穴のふさぎと単価 | プロンプトと単価表 |
| 確認の印 | 印の理由 | Python |
工房の作業の指示は、同じ行を紙の品番ごとに並べ替えて作ります。
【作業の指示】 週:10月27日〜
紙:FS-210 上級鳥の子 無地
M-1021(〇〇ハイツ 203) 和室 ふすま 4枚 1760×865 両面
K-1033(△△様) 座敷 ふすま 2枚 1760×880 片面
計 6枚
紙:SJ-01 障子紙 普通
M-1021(〇〇ハイツ 203) 和室 障子 2枚 1760×870
計 2枚
見積も作業の指示も、同じ行の値です。 店主が見積の段で直した寸法は、作業の指示にもそのまま入ります。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 受付フォルダ | ボタンを押したときに Python が読む | 未処理の票を集める |
| Document AI | REST の process | 票を読み取る |
| 単価表・区分の表・品番の一覧・客ごとの紙 | ファイルの読み取り | 単価と品番 |
| Claude API | REST | 紙の当て方と備考の分け方 |
| 見積の下書き | 見積のひな形に行を入れたファイル | 店主が確かめて送る |
| 作業の指示・週の集計 | ファイルの作成 | 工房に渡す |
見積は仕組みから送りません。 下書きを店主が開き、確かめて確定し、いまの方法で客や管理会社に送ります。値引きや、まとめて頼まれたときの調整は、店主が下書きの上で行います。
管理会社の物件と部屋の番号は、見積・作業の指示・週の集計のすべての行に同じ書き方で入れます。 票から読み取った番号を、管理会社ごとの物件の一覧と照らして書き方をそろえ、一覧に無い番号は確認に回します。 請求の段で管理会社が突き合わせるのはこの番号です。
紙の在庫の控えは、読むだけにします。 週の集計で足りない品番が分かっても、発注は店主か事務の担当者が問屋に行います。
人が確認する
店主は、ボタンを押した後の一覧だけを見ます。
- 品番の決まらない紙を先に見る … 候補が2つ以上なら、客や管理会社に確かめます。「いつもの」で客ごとの表に品番が無ければ、表に足します
- 寸法の疑いを見る … 切り出したセルの画像を見て、採寸した人に聞きます
- 大きさの区分の境目を見る … 区分を決め、境目の決め方に迷ったら区分の表を直します
- 見積の合計を見る … 値引きや調整を入れて確定します
店主が値を直したときは、直した人と理由を見積の行に残します。 票の画像はそのまま残し、直した値が作業の指示に入ったことも分かるようにします。
職人は、作業の指示を見て裁つ前に、建具に当てて寸法を確かめます。 これは今もしている作業で、仕組みを入れても省きません。
目標は、160件をならして1件3分です。 印の付いた行が1件に1行前後という想定で、それより多い月は、票の書き方か品番の一覧の略し方を職人と見直します。
例外に対処する
| 起きること | 対応 |
|---|---|
| 票が折れて表の行がずれる | 列の数が合わない行は当てはめずに確認に回す |
| 「〃」が読めない | 上の行の値で埋めず、空として確認に回す |
| 品番の一覧に無い新しい紙 | 候補を返さず、店主が一覧に足してから見積に入れる |
| 単価表に無い組み合わせ | 金額を空にして確認に回す |
| 建具の種類が書かれていない | 寸法から推し量らず、採寸した人に聞く |
| 1件の票が2枚にわたる | 2枚目を同じ注文として結び付けるよう、ファイル名で示してもらう |
| Document AI が応答しない | 受付フォルダに残し、次にボタンを押したときに再び読む |
3行目と4行目は、表を育てる機会です。 一覧に無い紙や単価表に無い組み合わせが出るたびに足していくと、半年ほどで、印の付く行が減っていきます。
記録を残す
- 票の画像と、スキャンした日時・スキャンした人
- Document AI が返した JSON の全文と、使ったプロセッサの版
- 規則の結果、生成AIの当て方と分け方、そのとき参照した単価表と品番の一覧の版
- 店主が直した記録 … どの値を、何から何に、なぜ直したか
- 送った見積の版と、注文が決まった日
- 作業の指示と週の集計を作った日時
3つ目で単価表の版を残すのは、単価が年に何度か変わるためです。 管理会社から「先月の部屋と単価が違う」と聞かれたとき、当時の単価表が残っていないと説明できません。
04実装レベルの3段階
半自動化で、1件15分が3分になります。この段階が本記事の想定です。 見積の組み立て、作業票への写し、紙の種類ごとの数え上げが無くなり、店主は印の付いた行と合計を見るだけになります。 本格構成は、管理会社とのやり取りの形がそろってからにします。 管理会社ごとに見積の様式や送り先が違ううちは、送付の準備を自動にしても、結局は店主が様式を直すことになります。 半自動化の間に、2つの数を毎週数えておきます。 品番が決まらずに店主へ回った行の数と、寸法の疑いで採寸した人に聞いた行の数です。前者が減らなければ品番の一覧の略し方が足りず、後者が減らなければ票の書き方を職人と話し合う必要があります。 どちらも、仕組みの側ではなく表と票を直すことで減っていきます。この2つが落ち着いてから本格構成に進むと、送付の準備まで自動にしても店主の確認が増えません。
05工数削減シミュレーション
導入後 160件 × 3分 ÷ 60 = 8 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 個人の住まいと、賃貸の住まいの退去のときの張替を頼む不動産の管理会社の両方から注文を受け、店主や職人が客先で紙の票に採寸を書き、店に戻ってから見積と工房の作業の指示を手で書き直している表具店。月に百件を超える注文があり、見積を出すまでに数日かかっている場合。同じ紙の種類をまとめて裁つための集計を、作業の前に手で数えている場合。
- 注文が月に数十件で、店主が見積をその場で書いて渡している店。採寸をすでにタブレットで入れ、見積と作業の指示が一続きで出ている店。掛軸や屏風の表装など、1件ごとに仕様が大きく違う仕事が中心の店。なお、建具の傷みの程度の見立て、骨の修理を引き受けるかの判断、値引きと最終の見積の金額の決定は、この構成では代替できません。
07最小構成で試す方法
- 先月の票から30枚を選ぶ(管理会社の「いつもの」の票と、紙の書き方が人によって違う票を入れる)
- その30枚について、当時の見積と作業票を出しておく
- 票の画像から客の名前と住所を黒く塗り、手元のAIサービスの画面に1枚ずつ貼り付ける
- 「この票の建具の表を、部屋・種類・枚数・高さ・幅・紙の種類・片面両面の列で書き出してください。紙の種類は、次の品番の一覧から候補を選び、決まらなければ候補を並べてください。一覧に無い品番を作らないでください」と指示し、品番の一覧も貼る
- 出てきた表を、当時の見積と作業票と1行ずつ突き合わせる
30枚は必ずやってください。 組む前に、「手書きの寸法が表として読めるか」と「紙の書き方を一覧に当てられるか」を確かめます。
| 出てきた内容 | 判断 |
|---|---|
| 寸法と紙が当時の見積と合った | Form Parser と単価表の連携に進む |
| 一覧に無い品番を作った | 指示の書き方で直る。構成は有効 |
| 「1760×865」が1つの数字になる | 様式が先。 高さと幅の列を分ける |
3行目は失敗ではありません。 いまの票の書き方が、人には読めても読み取りには向かないことが分かったということです。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 「1760×865」が1つの数字になる | 高さと幅を別の列にする |
| 丸囲みの片面・両面が読めない | ラジオボタンは読めない。 四角の欄にする |
| 同じ部屋の行を1つのセルでまとめている | 行ごとに部屋を書くか「〃」にする |
| 空いた紙の欄が上の行と同じになる | 「〃」が読めたときだけ引き継ぐ |
| 寸法を同じ部屋の値に合わせて直す | 直さない。 疑いの印を付けて聞く |
| 生成AIが一覧に無い品番を作る | 一覧に無い品番を禁じる |
| 「いつもの」を過去の注文から推し量る | 客ごとの決まった紙の表だけで決める |
| 大きさの区分が境目で人によって変わる | 区分の表を作り、境目は確認に回す |
上の5行が、この構成の失敗のほとんどです。 どれも、票の書き方と様式が読み取りに合っていないことから出ています。 直すのは仕組みより先に、票です。
下の3行は、店の決まりごとが表になっていないことから出ています。 品番の略し方、管理会社ごとの「いつもの」、大きさの区分の境目は、いまは店主と古くからいる職人の頭の中にあります。表にすると、新しく入った職人が採寸に出ても同じ見積になります。 仕組みを入れる効果の一部は、この表づくりそのものにあります。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 客の名前と住所、管理会社の物件と部屋の番号、建具の寸法と紙の種類、見積の金額です。
- 国外のリージョンで処理することを整理する … Form Parser の対応リージョンに日本はありません。店の個人情報の扱いの決まりと、管理会社との取り決めに照らしてから本番の票を回します
- 生成AIに渡す範囲を絞る … 紙の書き方と備考の文、品番の一覧だけを渡し、客の名前と住所は渡しません
- 金額と品番を仕組みで決めきらない … 金額は単価表から出し、品番が決まらなければ店主が客に確かめます。見積を送るのは店主です
- 骨の修理を引き受けるかを仕組みで決めない … 傷みの程度は、建具を見た店主と職人が判断します
- 票を元の記録として残す … 直しは見積の行の側で行い、票の画像と直した記録を両方残します
誤りが起きた場合のリスクは、頼まれていない紙で張ることと、寸法の違う紙を裁つことの2つです。 前者は品番を決めつけると起き、後者は寸法を直すと起きます。どちらも、決まらないものを決めずに店主へ回すことで防ぎます。
10まず何から始めるか
1週目:様式を直す
票の寸法を高さと幅の2列にし、片面・両面と補修の欄を四角のチェック欄にします。同じ部屋の行をまとめるセルを無くします。
2週目:30枚で試し、一覧を作る
先月の票を30枚選び、客の名前を塗ったうえで手元のAIサービスで読み取りと紙の当て方をさせます。一覧に無い品番を作っていないかを最優先で見ます。 あわせて、30枚に出てきた紙の書き方を品番の一覧の略し方に入れます。
3週目:大きさの区分の表と、客ごとの紙の表を作る
単価表の区分に、高さと幅の範囲を書き足します。管理会社ごとの「いつもの」の品番を表にします。国外で処理することの扱いも、この週に決めます。
4週目:ボタンから見積の下書きまでをつなぐ
Python で受付フォルダを読み、Form Parser を呼び、単価表を引いて見積の下書きを作るところまで作ります。この時点では店主のいまの見積と並べ、金額が合うかを見ます。
2か月目: 作業の指示と週の集計を足し、工房で使い始めます。3か月目以降: 1件15分が何分になったかを実測します。採寸の当日に見積を出せる日が週の半分を超えた時点で、この構成は運用に乗ったと言えます。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
Form Parser がキーと値のペア・表・チェックボックスを取り出すこと。日本語(ja)が手書きに対応する言語とされていること。同期の処理が15ページまでであること。対応リージョンが us・eu・asia-southeast1 などで、日本が含まれないこと | Google Cloud: Processor list | 2026-10-28 |
| Form Parser が学習済みで追加の学習ができないこと。表の取り出しが行や列をまたぐセルの無い単純な表に限られること。チェックボックスのモデルがラジオボタンに対応しないこと。値の入っていないキーと値のペアを確実には読めないこと | Google Cloud: Form Parser | 2026-10-28 |
表が headerRows と bodyRows で表されること。チェックボックスの状態が fieldValue の valueType に filled_checkbox/unfilled_checkbox で返ること。文字の位置が textAnchor で示されること | Google Cloud: Handle the processing response | 2026-10-28 |
プロセッサまたはプロセッサの版の :process に、rawDocument の MIME タイプと base64 の内容を送ること | Google Cloud: Send a processing request | 2026-10-28 |
Claude API の構造化出力が output_config.format に type: "json_schema" で指定すること。オブジェクトに additionalProperties: false が要ること。enum が使えること | Claude Platform Docs: Structured outputs | 2026-10-28 |
単価、大きさの区分、紙の品番は、店の単価表と仕入先の資料で確かめてください。 本記事は上の公式の情報で確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-2084)についてのご相談はこちらから。
