Media > AI活用ユースケース > 営業 > 左官の会社が工務店から届く工事の依頼を Make で受け、工事の種類・面積・工期を抜き出して見積の下書きの表を作る

左官の会社が工務店から届く工事の依頼を Make で受け、工事の種類・面積・工期を抜き出して見積の下書きの表を作る

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

工務店から届く左官工事の依頼のメールと添付の PDF を読み、部位ごとに工事の種類・面積・工期を抜き出して見積の下書きの表に入れます。金額の目安と工程の日数は、自社の単価表と工程表から式で出します。

サマリー
生成AI
ChatGPT/Claude/Gemini
連携・自動化
Make/n8n/Power Automate/Zapier
対象業界
不動産/建設
対象部門
営業
対象業務
データ入力・転記/書類作成
主な課題
入力作業が多い/書類作成に時間がかかる/期限・対応漏れが起きる
AIで行う処理
抽出
主な効果
対応スピード向上/工数削減/機会損失防止
導入難易度
★★☆☆☆
実装レベル
本格構成
費用感
API連携(中)
人間の確認
必須
現在工数
60h/月
AI導入後
21h/月
想定削減
65%
年間削減
468h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 工務店の担当者が、依頼をメールで送る。本文・仕上表・見積依頼書・図面のどれで来るかは決まっていない
  2. 見積の担当がメールと添付を開き、左官の部位を探す。仕上表では、ほかの職種の行の中から左官の行を拾う
  3. 部位ごとに、工事の種類・仕上げ・下地・面積を読み、見積の表のひな形に写す。工種の名前は自社の言葉に直す
  4. 面積が書かれていなければ、図面から拾うか、工務店に聞き返す
  5. 単価表を見ながら、部位ごとに単価を入れて金額を出す
  6. 工程表を見ながら、希望の工期に収まるかを考える
  7. 社長が見積を確かめ、PDF にして工務店に送る
導入後(After)
  1. 人工務店の担当者が、これまでどおり依頼をメールで送る(見積の専用アドレス)
  2. 自動Make がメールの到着をきっかけに動き、送り主のアドレスで工務店の一覧を引く
  3. 自動本文と添付の PDF を OpenAI API に渡し、左官の部位ごとに工事の種類・仕上げ・下地・面積と、現場・工期・回答の期限を抜き出させる
  4. 自動Make が工事の種類を工種表と照らし、見積の下書きの表に部位ごとに行を足す
  5. 自動表の式が、単価表から金額の目安を、工程表から工程ごとの日数と合計を出す
  6. 自動面積が空の部位、工種表に無い工事、工程の日数の合計が希望の工期を超える依頼に印を付ける
  7. 自動回答の期限を、見積の担当の一覧に並べる
  8. 人見積の担当が、印の付いた部位の面積を図面から拾うか、聞き返しの下書きを直して送る
  9. 人社長が、金額と工期を確かめて見積を仕上げ、工務店へ送る
各工程の詳しい説明を読む
  1. 工務店の担当者が、依頼をメールで送る。本文・仕上表・見積依頼書・図面のどれで来るかは決まっていない
  2. 見積の担当がメールと添付を開き、左官の部位を探す。仕上表では、ほかの職種の行の中から左官の行を拾う
  3. 部位ごとに、工事の種類・仕上げ・下地・面積を読み、見積の表のひな形に写す。工種の名前は自社の言葉に直す
  4. 面積が書かれていなければ、図面から拾うか、工務店に聞き返す
  5. 単価表を見ながら、部位ごとに単価を入れて金額を出す
  6. 工程表を見ながら、希望の工期に収まるかを考える
  7. 社長が見積を確かめ、PDF にして工務店に送る

(a)左官の部位を探すところから時間がかかる。 仕上表には、内装・外装・建具など全部の職種の行が並んでいます。左官に関わる行は、そのうちの一部です。 「床 フローリング」「壁 クロス」の行を飛ばしながら、「土間 金ごて」「壁 漆喰」の行を拾っていきます。

(b)面積の書き漏れに、表を作り終えてから気づく。 部位を全部写し終えて金額を出そうとしたところで、面積の欄が空の部位があると分かります。 そこから工務店に聞き返すと、回答の期限に間に合わなくなることがあります。

(c)回答の期限が、本文の中に埋もれている。 期限は本文の最後に一言で書かれていることが多く、メールを開いたときに見落とすと、思い出すのは工務店から催促が来たときです。

(d)工期の確かめが、社長の頭の中にある。 「漆喰の3回塗りで、この工期は厳しい」という見立ては、社長が工程表を見ずにしています。見積の担当が1人で作ると、工期の相談が要る依頼をそのまま受けてしまうことがあります。

  1. 【人】 工務店の担当者が、これまでどおり依頼をメールで送る(見積の専用アドレス)
  2. 【自動】 Make がメールの到着をきっかけに動き、送り主のアドレスで工務店の一覧を引く
  3. 【自動】 本文と添付の PDF を OpenAI API に渡し、左官の部位ごとに工事の種類・仕上げ・下地・面積と、現場・工期・回答の期限を抜き出させる
  4. 【自動】 Make が工事の種類を工種表と照らし、見積の下書きの表に部位ごとに行を足す
  5. 【自動】 表の式が、単価表から金額の目安を、工程表から工程ごとの日数と合計を出す
  6. 【自動】 面積が空の部位、工種表に無い工事、工程の日数の合計が希望の工期を超える依頼に印を付ける
  7. 【自動】 回答の期限を、見積の担当の一覧に並べる
  8. 【人】 見積の担当が、印の付いた部位の面積を図面から拾うか、聞き返しの下書きを直して送る
  9. 【人】 社長が、金額と工期を確かめて見積を仕上げ、工務店へ送る

8番目が、この設計の分かれ目です。 担当者の時間は、面積の空いた部位と、工期の相談が要る依頼に集まります。 部位を探して写す時間が無くなる分、図面から面積を拾う時間に回せます。

6番目で工期を比べるのは、AIではなく表の式です。 AIが返すのは「着工の希望 11月10日、完了の希望 11月20日」という書かれた日付までで、工程の日数の合計と比べて印を付けるのは、工程表を持つスプレッドシートの側です。

02今回想定するシステム構成

構成図
工務店(依頼メール:本文、仕上表・見積依頼書・図面の PDF)
   ▼【トリガー】Gmail の Watch emails(見積の専用アドレスのラベル)
Make(シナリオ)
   ├──▶ Google スプレッドシート:工務店の一覧を Search Rows で引く
   ├──▶ Gmail:List email attachments and media で PDF を取り出す
   ▼
OpenAI API(HTTP の Make a request で Responses API、構造化出力)
   │   部位ごとの工事の種類・仕上げ・下地・面積、現場、工期、回答の期限
   ▼
Make ── 工種表と照合 → 見積の下書きの表に行を足す(Bulk Add Rows)
   │       式:単価表で金額の目安、工程表で工程ごとの日数と合計
   ▼ ルーター
   ├── 面積が空・工種表に無い ── 聞き返しの下書き(Create a draft email)
   ├── 工期の相談が要る ──────── 社長の確認の一覧
   └── フォールバック ────────── 見積の担当の確認の一覧
   ▼
【人】見積の担当と社長が仕上げて送る
役割想定する製品代替候補
ワークフローMake(シナリオ。Gmail、HTTP、Google Sheets、ルーター)Zapier、n8n、Power Automate
生成AIOpenAI API(Responses API、構造化出力、PDF の入力)Claude API、Gemini API
保管Google スプレッドシート(見積の下書きの表・工種表・単価表・工程表・工務店の一覧)Airtable
メールGmail(見積の専用アドレス)Microsoft Outlook

新しく作るのは、工種表です。 自社で受ける工事の種類を「モルタル下地塗り」「漆喰 3回塗り」「珪藻土 2回塗り」「土間 金ごて押さえ」「洗い出し」「掻き落とし」など20ほど並べ、工務店が使う言い方(「しっくい」「ジュラク」「土間コン押さえ」など)を言い換えの例として列に持たせます。 単価表と工程表は、この工種表の名前で引けるように並べ直します。

AI の部品は OpenAI API です。 Make の OpenAI のアプリのページには、構造化出力と PDF の入力の記載が見当たりません。そこで HTTP の Make a request で Responses API を直接呼びます。 Make a request は本文を JSON で送れ、API キーは Credentials の欄で渡し、応答を待つ時間は1〜300秒で決められます。

PDF はそのまま渡せます。 Responses API は input_file で PDF を受け、画像を読めるモデルでは、PDF の文字とページの画像の両方をモデルに渡すとされています。仕上表の表の形を崩さずに読ませられます。1ファイル50MB未満、1回の送信の合計も50MBまでです。

03どうやって実装するのか

Step1

処理の起点を決める

見積の専用アドレスにメールが届いたことを起点にします。 工務店には、見積の依頼を mitsumori@ のような専用アドレスに送ってもらいます。Gmail のフィルタでこのアドレス宛てに「見積依頼」のラベルを付け、Make の Watch emails はこのラベルと未読を条件に見ます。

取り込んだメールは既読にします。 Watch emails には取り込み時に既読にする設定があり、同じ依頼を二度取り込むことを防げます。 処理に失敗したときは、担当者が未読に戻せば次の回で取り直されます。

実行の間隔は15分ごとにします。回答の期限が「今週中」の依頼もあるので、1日1回では遅すぎます。 工務店からの追加の連絡(「2階の洗面も追加で」)は同じスレッドの返信で届くことが多いので、件名の受付番号で元の依頼に結び付けます。

Step2

入力データを集める

データ中身取得元
依頼メール送り主、件名、本文、届いた日時Gmail
添付仕上表・見積依頼書・図面の PDFGmail の List email attachments and media
工務店の一覧送り主のアドレス、工務店名、担当者、よく使う書式スプレッドシート
工種表工事の種類、言い換えの例、単位(㎡・m・か所)スプレッドシート
単価表・工程表工種ごとの㎡単価、工程ごとの日数、塗り重ねのあいだの乾燥の日数スプレッドシート

AIに渡すのは、上の4つまでです。 単価表と工程表はAIに渡しません。金額と日数は式で出すもので、AIに見せると「目安の金額」を書き足してくる余地が生まれるからです。

質を決めるのは、工種表の「言い換えの例」の列です。 工務店ごとに「ジュラク」「聚楽壁」「じゅらく」のように書き方が違います。最初の1か月は、AIが工種表に当てはめられなかった言い方を、この列に足していきます。

Step3

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

取るものどこから何に使うか
本文、送り主、件名Watch emails の出力AI に渡す本文と、工務店を引く鍵
添付の PDFList email attachments and media(ファイルのデータを含める)AI に渡すファイル
工務店の行Google Sheets の Search Rows(送り主のアドレスで絞る)工務店名と担当者
工種表の全行Google Sheets の Search RowsAI に渡す工事の種類の候補

添付は、ファイルのデータを出力に含める設定で取り出します。 List email attachments and media には、ファイルのデータを出力の束に含めるかの設定があり、含めたデータを base64 にして、Responses API の input_file に file_data として渡します。

PDF 以外の添付は、AIに渡しません。 写真(現場の壁の写真など)は、見積の下書きの行にリンクを付けて担当者が見られるようにするだけにします。Excel の見積依頼書が付いてきたときは、工務店に PDF で送り直してもらうか、担当者が PDF にしてから同じアドレスへ転送します。

Step4

AIへ渡す前に整形する

  1. 引用部分と署名の除去 … 返信のメールの過去のやり取りと、署名の住所・電話番号を落とします。署名の会社の住所を、現場の住所と取り違えないためです
  2. 受付番号の付与 … メールごとに受付番号を振り、件名に「【見積 M-1029-007】」の形で付けます
  3. 追加の連絡の判定 … 件名に受付番号があるメールは、元の依頼への追加として扱い、同じ受付番号の下書きの表に行を足します
  4. 添付の種類と大きさの確認 … PDF だけを残し、1ファイル50MB未満、合計50MBまでに収まるかを確かめます。超えるものは担当者へ回します
  5. ページ数の確認 … 図面の束のように数十ページある PDF は、左官に関わるページだけを担当者が選んでから渡します
  6. 送り主の確認 … 工務店の一覧に無いアドレスからの依頼は、AIに渡さず担当者へ回します

5番目を軽く見ないでください。 PDF はページの画像も一緒にモデルへ渡されるので、ページが多いほど1件あたりのやり取りが大きくなります。 図面の束をそのまま渡すと、左官に関係の無いページの読み取りに費用を使うことになります。

Step5

AIに処理させる

させるのは、左官に関わる部位を拾い、部位ごとの項目を書かれているとおりに写すことです。 工事の種類だけは、渡した工種表の中から選ばせます。

抜き出すもの抜き出し方書かれていないときの扱い
部位「1階LDK 壁」「玄関 土間」のように、書かれている場所の名前を写す-
工事の種類工種表の名前から1つ選ぶ。言い換えの例も見る当てはまらなければ 不明
仕上げと下地色・模様・塗り回数、下地(石膏ボード・ラス・コンクリート)を写す空にする
面積・長さ書かれている数字と単位をそのまま写す空にする。「図面参照」は note に写す
現場現場の名前と所在地空にする
工期着工の希望日と完了の希望日空にする
回答の期限見積を返す期限空にする
根拠その行の判断に使った本文や PDF の箇所必ず入れる

面積の扱いが、この構成でいちばん大事なところです。 面積が空のまま返ってくるから、どの部位を担当者が図面から拾えばよいかが、一覧で分かります。

させないこと理由
図面からの面積の拾い出し面積がそのまま金額になる。担当者が拾う
金額・単価の記入単価表の式で出す
工期に収まるかの判断工程表の日数と式で比べる
左官以外の職種の行を拾うことクロス・塗装は自社の見積の対象外
「今週中」を日付に直すこと何曜日を週の終わりと見るかは工務店ごと。届いた日と言葉のまま残し、担当者が決める

1行目がいちばん起きやすい失敗です。 平面図が付いていると、AIは部屋の寸法から壁の面積を計算しようとします。開口部の差し引きや天井の高さの読み違いがあっても、出てきた数字は確かそうに見えます。

左官と塗装の境目にも注意します。 外壁の「吹付け」は、塗装の会社が受けることも、左官の会社が受けることもあります。工種表に「吹付け(左官で受ける場合)」の行があるときだけ拾い、無ければ 不明 にして担当者が決めます。

Step6

指示内容を固定する

あなたは左官工事の会社の見積の担当として、工務店から届いた見積の依頼を読み、
左官に関わる部位ごとの行に分ける立場です。
本文と添付の PDF に書かれていることだけを使ってください。推測で埋めないでください。

【やること】
1. 左官に関わる部位を拾い、items の配列に1部位1要素で入れる。
   仕上表に他の職種(クロス、フローリング、塗装など)の行があっても拾わない。
2. work_type には、下の【工種表】の name から1つを選ぶ。
   言い換えの例(aliases)も見てよい。当てはまらなければ「不明」とする。
3. area_text には、書かれている面積・長さ・か所数を、数字と単位のまま写す。
   書かれていなければ空文字にする。「図面参照」とあれば note に写す。
4. finish と substrate には、仕上げ(色・模様・塗り回数)と下地を写す。
5. site、start_wish、finish_wish、reply_deadline には、
   現場、着工の希望、完了の希望、見積を返す期限を、書かれているとおりに写す。
6. evidence には、その行の判断に使った本文または PDF の箇所を写す。
   PDF の場合はページ番号も書く。

【厳守事項】
- 図面の寸法から面積を計算しないでください。面積が書かれていない部位は、
  area_text を空文字にしてください。
- 金額や単価を書かないでください。
- 工期に間に合うか、工期が短いかを書かないでください。
- 「今週中」「来週の打合せまで」は日付に直さず、そのまま写してください。
- 工種表に無い工事の名前を作らないでください。
- 吹付けは、工種表に該当する行があるときだけ拾ってください。
- 左官の見積と関係の無い相談(日程の調整、別の現場の話)は
  other_notes に写し、items に混ぜないでください。

【工種表】{work_type_table}
【工務店】{builder_info}
【依頼メールの本文】{mail_body}

「図面の寸法から面積を計算しない」を、最初の厳守事項に置いています。 平面図が添付されているとき、何も言わなければAIは計算を始めます。埋まった面積が正しいかどうかではなく、拾っていない面積が拾ったように見えることが問題です。

「今週中」を日付に直させないのも同じ理由です。 届いた日の曜日によって、AIは金曜日にも土曜日にもします。期限を1日でも後ろに読むと、見積が間に合わなくなります。

Step7

出力形式を固定する

次の形のJSONで受け取ります。

{
  "request_id": "M-1029-007",
  "builder": "",
  "site": "",
  "start_wish": "",
  "finish_wish": "",
  "reply_deadline": "",
  "items": [
    {
      "location": "1階LDK 壁",
      "work_type": "珪藻土 2回塗り | 漆喰 3回塗り | ... | 不明",
      "finish": "",
      "substrate": "",
      "area_text": "",
      "note": "",
      "evidence": ""
    }
  ],
  "other_notes": ""
}

1つ目の理由は、部位を配列で返させることで、1部位1行にできることです。 items の配列を Google Sheets の Bulk Add Rows に渡せば、部位の数だけ見積の下書きの表に行が足されます。

2つ目は、area_text を文字列にしていることです。 「45㎡」「約45平米」「L=12.5m」のように書き方がばらばらなので、文字のまま受けて、表の側で数と単位に分けます。 分けられないものは空と同じ扱いにして印を付けます。

3つ目は、構造化出力の決まりに合わせられることです。 Responses API の構造化出力では、すべての項目を required にし、additionalProperties を false にすることとされています。書かれていない項目も空文字で必ず返ってくるので、表の列がずれません。

表の式で埋める列埋め方
面積(数)area_text から数と単位を分ける。分けられなければ空
金額の目安面積 × 単価表の㎡単価。面積が空なら空
工程の日数工程表から、塗り重ねのあいだの乾燥の日数を含む日数を引く
工期の比べ部位の工程の日数の最大と、着工から完了までの日数を比べる
状態面積が空・工種が 不明・工期が足りないのどれかがあれば「要確認」

要は、AIの列と式の列を分けておくことです。 単価を改定しても、AIの列はそのままで式の列だけが変わります。

Step8

システムへ連携する

つなぎ先方式内容
GmailWatch emails(ラベル・未読)、List email attachments and media依頼と添付を受ける
工務店の一覧・工種表Google Sheets の Search Rows照合に使う行を引く
OpenAI APIHTTP の Make a request(Responses API)部位ごとの項目を抜き出す
見積の下書きの表Google Sheets の Bulk Add Rows部位ごとに行を足す
聞き返しGmail の Create a draft email下書きまでを作る

ルーターの道は、面積が空・工種表に無い、工期の相談が要る、フォールバックの3つにします。 ルーターの道は1本ずつ順に処理され、どの条件にも当たらないものはフォールバックの道に入ります。 1つの依頼が「面積が空」と「工期の相談」の両方に当たるときは、先に聞き返しの下書きを作り、続けて社長の確認の一覧にも載せます。

見積の本体は、これまでどおりのひな形で人が作ります。 下書きの表は、ひな形に写す前の材料です。見積書の PDF を自動で作って送る仕組みは置きません。

Step9

人が確認する

見積の担当が開くのは、状態が「要確認」の依頼です。 「要確認」の無い依頼も、社長が金額と工期を確かめてから送るので、全件を人が見ることは変わりません。変わるのは、見るときに表がすでにできていることです。

  1. 回答の期限の一覧を先に見る … 期限の近い順に並んでいるので、その日に手を付ける依頼が決まります
  2. 面積が空の部位を拾う … 図面から拾うか、聞き返しの下書きを直して送ります
  3. 工種が 不明 の行を決める … 言い換えの例に足すかも、ここで決めます
  4. evidence で部位の取りこぼしを見る … 仕上表の左官の行が全部拾われているかを、PDF のページと見比べます
  5. 社長が工期と金額を確かめる … 工期の比べで印が付いた依頼は、工務店と工期を相談するかを決めます

4番目を省かないでください。 拾い漏れた部位は、見積に載らないまま契約になります。工事が始まってから「この壁も左官です」と言われると、見積に無い工事を受けることになります。

目標は、90件をならして1件14分です。 そのうち半分ほどは、図面から面積を拾う時間です。「要確認」が多い月は、面積を書かずに送ってくる工務店が増えているか、工種表の言い換えの例が足りていません。 どちらが原因かは、状態の列の内訳を数えれば分かります。

Step10

例外に対処する

起きること対応
送り主が工務店の一覧に無いAIに渡さず、担当者の確認の一覧へ
PDF が無く、図面の写真だけが付いているAIに渡さず、担当者へ。写真から部位を拾わない
PDF にパスワードが付いている工務店に外したものを送り直してもらう
添付が50MBを超える担当者が左官のページだけを抜き出して転送する
左官の部位が1つも拾われないitems が空。担当者が依頼を読み直す
工種が 不明 の行が多い言い換えの例が足りない。担当者が表に足す
AIの応答が拒否・途中で切れた応答の refusal や incomplete の状態を見て、メールを未読に戻し取り直す
追加の連絡が別のスレッドで届く受付番号が無いので新しい依頼として扱い、担当者が元の依頼に結び付ける
応答を待つ時間を超えたMake a request の待ち時間(最大300秒)を超えたら、未読に戻し次の回で取り直す

上から4行目までは、AIの問題ではなく依頼の送り方の問題です。 取引の多い工務店には、仕上表を PDF で、左官のページを付けて送ってもらうお願いをしておくと、この4行がほとんど起きなくなります。

Step11

記録を残す

  • 元の依頼メールと添付の PDF、受付番号、届いた日時
  • AIに渡した本文(前処理の後)と、AIが返したJSONの全文
  • 見積の下書きの表の行と、式で出した金額の目安・工程の日数。そのとき使った単価表と工程表の版
  • 人が直した記録 … 面積を図面から拾った行、工種を決め直した行
  • 聞き返しの送信日時と、工務店からの返事との対応
  • 送った見積の PDF と、送った日時。回答の期限に間に合ったか

3つ目で単価表の版を残すのは、単価を改定するためです。 材料の値上がりで単価を変えたあとに過去の見積を見返すと、当時の単価が残っていないと、なぜその金額だったかが分かりません。

最後の行は、受注の振り返りの材料になります。 回答の期限に間に合わなかった依頼と、間に合ったのに決まらなかった依頼を分けて数えると、見積の速さの問題か、金額の問題かが見えてきます。

04実装レベルの3段階

最小構成:依頼の本文と PDF を手でAIの画面に渡し、部位ごとの項目を出させる / 1件ごとの読み取り
半自動化:上記+Make でメールを受けて OpenAI API を呼び、見積の下書きの表に部位ごとに行を足す / 読み取りと表への記入
本格構成:上記+単価表と工程表の式、工期の比べ、聞き返しの下書き、回答の期限の一覧まで出す / 依頼の受付から見積の下書きまで

最小構成では件数がさばけません。 1件ずつ渡すので、月90件には使えません。確かめるための段階です。 半自動化で、1件40分が25分程度になります。 部位を探して写す作業は自動になりますが、単価と工程の日数を引く作業と、期限の書き留めが残ります。本格構成で14分になり、この段階が本記事の想定です。 残る14分の多くは、図面から面積を拾う時間と、社長の確認の時間です。 段階を飛ばさないでください。 半自動化の表を1か月見ると、不明 になりやすい言い方と、拾い漏れの起きやすい工務店の書式が先に分かります。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
2 名
月間件数
90 件
1件あたり現在時間
40 分
1件あたり導入後時間
14 分
現在  90件 × 40分 ÷ 60 = 60 時間/月
導入後 90件 × 14分 ÷ 60 = 21 時間/月
月間削減時間
39h
削減率
65%
年間削減時間
468h
年間金額換算(時間単価3,000円)
140万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 住宅や店舗の内外装の左官工事を、複数の工務店・リフォーム会社から下請で受けている左官の会社。見積の依頼がメールの本文と仕上表・見積依頼書の PDF で届き、社長や見積の担当が読み直して見積の表に写している場合。工種ごとの単価表と、乾燥の期間を含む工程の日数の目安を自社で持っている場合。
向いていない
  1. 依頼のほとんどが電話や現場での口頭で、書いたものが残らない場合。公共工事の積算のように、決まった基準で数量を拾う必要がある見積の場合。図面から面積を拾う作業そのものを省きたい場合(この構成は書かれた面積を写すだけで、図面から数量を拾いません)。なお、見積の金額と工期の可否の判断は会社の担当者が行うもので、この構成は代替しません。

07最小構成で試す方法

  1. 先月届いた見積の依頼から20件を選ぶ(仕上表の PDF だけのもの、面積に「図面参照」とあるもの、「今週中」の期限があるものを必ず入れる)
  2. その20件について、当時の見積の部位と面積、聞き返したことを並べておく
  3. 工種表を、言い換えの例の列も含めて1枚のテキストにする
  4. 手元のAIサービスの画面に工種表と依頼の本文・PDF を渡し、「左官の部位ごとに工事の種類・仕上げ・下地・面積・工期・回答の期限を抜き出してください。面積は図面から計算しないでください」と指示する
  5. 出てきた結果を、当時の見積と突き合わせる

20件は必ずやってください。 シナリオを組む前に、「仕上表から左官の行だけを拾えるか」と「面積を計算せずに空けるか」を確かめます。

出てきた内容判断
当時の見積と同じ部位が拾われ、書かれていない面積が空になっているMake とのつなぎに進む
図面から面積を計算して埋めた指示の書き方で直る。構成は有効
左官の行の拾い漏れが多い工種表の言い換えの例が先。 AIの問題ではない

3行目が出ることは珍しくありません。 社長が頭の中で行っていた「ジュラクは聚楽壁の塗り」という読み替えが、表に書き出されていなかったと分かったということです。 拾い漏れた言い方を工種表に足し、同じ20件で取り直してください。拾い漏れが減ったところで、Make とのつなぎに進みます。

08実装時につまずきやすいポイント

問題対策
図面から面積を計算して埋める最初の厳守事項で禁じ、area_text が evidence の中の文字と合うかを後段で確かめる
「今週中」が日付に直される言葉のまま写させ、担当者が決める
仕上表のクロス・塗装の行まで拾う工種表の中から選ばせ、当てはまらないものは 不明 に
署名の住所が現場になる前処理で署名を落とす
図面の束を全部渡して費用がかさむ左官のページだけを担当者が選ぶ。工務店にもお願いする
構造化出力で項目が足りず400になるすべての項目を required に、additionalProperties を false に
応答の拒否・途中切れを JSON として読もうとして止まるrefusal と incomplete を先に確かめてから読む
吹付けを塗装の工事まで拾う工種表に左官で受ける行があるときだけ拾う
単価を変えたら過去の見積の説明がつかない単価表の版を残す
見積を自動で送ってしまう下書きの表までにする。 見積書は人が作る

上の2行が、この構成の失敗のほとんどです。 どちらも、書かれていないことを「それらしいもの」で埋める同じ型の失敗です。書かれていないものを空けたまま返させる設計が守られているかで、見積の担当が何を確かめればよいかが決まります。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 工務店の担当者の名前とアドレス、現場の名前と所在地、施主の名前が書かれた図面や仕上表、そして自社の単価です。

  1. 施主の個人情報を外部へ渡す範囲を考える … 仕上表や図面の表題欄には、施主の名前が書かれていることがあります。見積に要るのは部位と仕上げなので、施主の名前を AI の出力に入れさせない指示にし、工務店にも表題欄の扱いを相談します
  2. 単価表を AI に渡さない … 自社の単価は、取引先に知られたくない情報です。金額は式で出し、単価表はスプレッドシートの外へ出しません
  3. 見積を自動で送らない … 出すのは下書きの表と聞き返しの下書きまでです。金額の誤りは、そのまま契約の金額になります
  4. この構成は工期の可否を判断しない … 建設業法は、通常必要な期間に比べて著しく短い工期での請負契約を禁じています。工程の日数の比べは目安で、工期を受けるか相談するかは社長が決めます
  5. 見積書の記載の努力義務を意識する … 建設業法第20条は、工種ごとの材料費・労務費などの内訳と、工程ごとの作業と準備に要る日数を記載した見積書を作るよう努めることとしています。下書きの表の工程の日数の列は、その材料として使えます
  6. OpenAI API のデータの扱いを確かめる … 図面と施主の情報を含むので、導入前に利用規約とデータの保持の扱いを確かめます

誤りが起きた場合のリスクは、拾い漏れた部位が見積に載らないことと、面積や期限を読み違えることの2つです。 前者は evidence の見比べで、後者は書かれていないものを空けたまま返させる設計で守ります。

10まず何から始めるか

1週目:工種表を作る

自社で受ける工事の種類を20ほど並べ、過去3か月の依頼から工務店の言い方を集めて言い換えの例の列に入れます。 単価表と工程表を、工種表の名前で引けるように並べ直します。

2週目:20件で試す

先月の依頼から20件を選び、手元のAIサービスに工種表と依頼を渡して部位ごとの項目を出させます。当時の見積と突き合わせ、図面から面積を計算していないか、左官の行の拾い漏れが無いかを最優先で見ます。

3週目:工期の比べ方を決める

工程表の日数と希望の工期を、どう比べたら「工期の相談が要る」とするのかを、社長と決めます。 乾燥の日数は季節で変わるので、冬の日数の列も持たせます。

4週目:メールから下書きの表までをつなぐ

Make で専用アドレスのラベルを見張り、PDF を取り出して OpenAI API を呼び、見積の下書きの表に部位ごとに行を足すところまで作ります。この時点では式の列を足さず、AIの列だけを見ます。

2か月目: 単価表と工程表の式、ルーター、聞き返しの下書きを足し、「要確認」の件数を毎週数えます。3か月目以降: 回答の期限の一覧を足し、1件40分が何分になったかを実測します。取引の多い工務店に送り方のお願いをし、不明 と拾い漏れが減った時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-29/最終更新:2026-10-29
確認した内容情報源確認日
Gmail の Watch emails がラベル・未読の条件で監視でき、取り込み時に既読にする設定があること。List email attachments and media でファイルのデータを出力に含められること。Create a draft email で下書きを作れることMake: Gmail modules2026-10-29
HTTP の Make a request が JSON の本文を送れ、API キーを Credentials の欄で渡し、応答の待ち時間を1〜300秒で決められることMake: HTTP2026-10-29
Google Sheets の Search Rows・Bulk Add Rows (advanced) があることMake: Google Sheets modules2026-10-29
ルーターの道が1本ずつ順に処理され、どの条件にも当たらないものをフォールバックの道が受けることMake Help: Router2026-10-29
Responses API の構造化出力を text.format の json_schema で指定し、すべての項目を required、additionalProperties を false にすること。拒否のときに refusal が返り、incomplete で出力が途中で切れうることOpenAI: Structured outputs2026-10-29
PDF を input_file で渡せ(file_data・file_id・file_url)、画像を読めるモデルでは文字とページの画像の両方が渡されること。1ファイル50MB未満、1回の合計50MBまでであることOpenAI: File inputs2026-10-29
建設業者が工種ごとの材料費・労務費などの内訳と、工程ごとの作業と準備に要る日数を記載した見積書を作るよう努めること(第20条)。著しく短い工期の請負契約の禁止(第19条の5)。2025-12-12 施行の版e-Gov 法令API: 建設業法2026-10-29

見積の金額と工期の可否は、自社の担当者と社長が判断してください。 本記事は上の公開情報で確認できた範囲だけを扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-2279)についてのご相談はこちらから。

AI活用について相談する
目次