はじめに：単価表の敵は「入力」と「止まりやすさ」
工務店の単価表って、気づくとこうなりません？
- 仕入れ請求書の単価が、どこにも”残らない”
- Excelはあるけど最新版が分からない
- 分類ルールが複雑で、入力できる人が限られる
- 値上げ履歴が消えて、見積りがブレる
僕がやりたかったのはシンプルで、
「入力を減らして、ミスを減らして、履歴を残す」 こと。
そこで作ったのが、ChatGPT（うちでは「チャッピー」と呼んでます）を使った
単価表運用専用の マイGPT（Custom GPT） です。
この記事では、
- マイGPTの作り方（ざっくり最短ルート）
- 単価表向けのプロンプト設計の型
- チャッピーに書かせたのにActionsがエラー出しまくった苦労話
この3つを、現場目線で書きます。
先に全体像を見たい人は、こちらからどうぞ。
単価表×AI連携で「入力」を減らす考え方（手順つき）
1. マイGPTって何ができる？
マイGPTは、ChatGPTに「役割」と「手順」と「判断基準」を仕込んだ、自分専用の作業員みたいなものです。
単価表で言うと、こんなことを担当させられます。
- 請求書の明細を読んで、登録用に整形する
- 表記ゆれや怪しい単価を見つけて、確認ポイントとして出す
- 分類候補を出して、人がOK/NGだけ判断できる状態にする
ポイントは「入力担当」じゃなくて、確認担当に寄せること。
2. マイGPTの作り方（最短ルート）
やることはシンプルで、順番もだいたい固定です。
手順
- 1.GPTエディタで新規作成
- 2.構成（Configure）で
- 名前・説明
- 指示（Instructions） ここが心臓
- 会話のきっかけ（Prompt Starters） 会話の開始例
- 必要なら 知識（Knowledge/資料の添付）
- アクション（Actions） API連携
- 3.公開範囲を選んで作成する（あとで変更もできます）
まずはアクションなしで形を作って、動きが固まってから足すと転びにくいです。
3. プロンプト設計：単価表GPTは「人を雇う」気持ちで作る
プロンプト設計って言うと難しそうだけど、やってることは
新人さんに「この仕事、こう進めてね」って渡す手順書づくり
に近いです。
効いたのはこの3点。
- 目的（ゴール）
- 手順（どの順で処理するか）
- 出力の型（この形で出してね）
あと、指示（Instructions）は読みやすく。
見出し、箇条書き、段落を使うと安定します。
4. 単価表GPT用 指示（Instructions) コピペOKテンプレ
※ここで載せるのは公開できる範囲のテンプレです。実運用では、社内ルールやAPI仕様に合わせてもう少し細かくしています（さすがに全部は出せない笑）
あなたは工務店の「単価表登録」運用アシスタントです。
目的
請求書/見積書（PDF・画像）をOCRで読み取り、明細行を単価表システムに登録する。
その際に既存品目に紐付け、または新規品目を作成し、税抜単価を履歴として残す。
✅ 絶対ルール（破ると事故る）
1) 登録時の単価は必ず price（税抜）
- OCR内部で unitPrice を使ってもよいが、登録時は price に変換する
- unitPrice のまま送らない
2) カテゴリは固定一覧から選ぶ（新カテゴリは作らない）
- 不明なら候補を出してユーザーに選んでもらう
3) 品目ID（内部コード）は勝手に作らない
- まず照合（match）で既存候補を探す
- 新規作成が必要なら、カテゴリ確定後に採番して作る（採番ルールは運用側）
4) 仕入先が違う場合は「更新」ではなく「追加」
- 同じ品目でも仕入先違いの単価は履歴として追加して残す
✅ 品名の正規化ルール
- 寸法がある場合は先頭に統一表記（例：12×303×1818 …）
- 単位が無い場合は空でOK（勝手に作らない）
- 金額は税抜で扱う
✅ 実行フロー（毎回これ）
Step1 OCR → 行データ化
- description（原文）
- normalizedName（正規化後）
- vendorCode（品番があれば）
- unit（あれば）
- unitPrice（税抜単価）
- supplier（業者名）
- invoiceDate（請求日）
Step2 照合（match）を実行（必須）
- 既存候補（内部コード）とカテゴリ候補を得る
- 自信が低い場合はカテゴリ候補を提示してユーザーに選んでもらう
Step3 登録
- 既存に紐付く：単価履歴として追加（price必須）
- 新規作成：カテゴリ確定後に作成（price・supplier等を必須にする）
以上のルールを必ず守って処理すること。5. 知識(Knowledge 資料アップロード)で”迷い”を減らす
マイGPTには「知識」という、資料を持たせる機能があります。 分類ルールや表記ゆれのメモをここに入れておくと、会話で毎回説明しなくても済みます。
単価表運用だと、例えばこんな資料が効きます。
- 固定カテゴリ一覧
- 品名の正規化ルール（寸法表記など）
- よく出る品名の表記ゆれメモ
- 仕入先名の略称や呼び方の統一
6. アクション（Actions）：GPTに「手を動かさせる」…はずが、ここで転ぶ
Actionsを使うと、外部APIを叩いて
- 単価表データの検索
- 登録・更新
- 仕入先ごとのマスタ参照
みたいな「実作業」までやれます。…が、ここが一番転びました😅
6-1. 「チャッピーに書かせたOpenAPI、なぜか動かない問題」
アクション（Actions）はOpenAPIスキーマが命なんですが、ここがちょっとでも曖昧だと、
- そもそもActionを呼ばない
- 変な引数で呼んで爆発する
- 期待したレスポンス形式じゃなくて詰む
が起きます。
特に効いたのはこれ。
- operationId（名前）は、短く・明確に
- パラメータ名は、迷わない日本語か英語で統一
- レスポンスは「最低限」だけ返す（盛ると壊れる）
6-2. よく出がちなエラーたち（僕の”転びポイント”）
Actionsまわりで引っかかりやすいのは、だいたいこのへん。
-
認証まわり（401系）
API Keyの付け忘れ、ヘッダ名違い、期限切れ。地味に多い。 -
スキーマのズレ
requiredの指定ミス、型が曖昧、配列なのにオブジェクトで返してる…など。 -
デバッグしづらい
ここがつらい。何が悪いか当てクイズになりやすい。
「エラーの図鑑」ができる勢いで増えました。笑
6-3. 結論：指示（Actions）は「小さく刻む」（結局チャッピーにまかせたけどね笑）
僕が落ち着いたのはこの方針。
- 指示（Action）は1つの責務にする（検索、登録、更新を分ける）
- レスポンスは”薄く返す”（必要十分な項目だけ）
- 変換や判断はGPT側に寄せる（API側でやりすぎない）
つまり、指示（Actions）は「重機」じゃなくて、
ボタン付きの工具くらいに扱うと安定します。
……とか言いつつ、結局チャッピーにまかせたけどね笑
（でも”任せ方”を決めるのは人間の仕事だった）
7. 単価表運用は「検索→候補→確認→登録」が回れば勝ち
4章のフローで書いた「OCR→照合→登録」、これを実務の言葉に置き換えるとこうなります。
- 明細を貼る
- GPTが候補を出す
- 人がOK/NGだけ判断
- 登録
単価表って、完璧に自動化しようとすると沼ります。
でも、この流れが回れば実務は大幅に楽になります。
「入力」を減らすって、ただ楽をする話じゃなくて、
ミスの発生源を減らすってことなんですよね。
※請求書の読み取り精度でつまずいているなら、こちらも参考になります。
スキャンした請求書はPDFより画像の読み取りが強い理由と実運用ルール（失敗談あり）
最後に：作って終わりじゃなく、運用しながら強くなる
マイGPTは、作って一発で完成…にはならないです。
- 迷ったやつはメモして足す
- ミスりやすいところはルールにする
- 例（見本）を増やして「この形で出して」を覚えさせる
これを少しずつ足していくと、だんだん自分のやり方に寄ってきて、使い物になります。
Actionsでエラーが出たときは、僕も普通に
「おい！自分で書いといてなんで動かん！」ってなりました😅
でも、処理を小さく分けて、順番に確認していけば、ちゃんと安定して動くようになります。
