社内から届く事務用品・消耗品の購入依頼をフォームで集め、Apps Script と AI でばらばらの品名を標準の品目にそろえ、在庫を差し引いて仕入先ごとの発注の一覧を作る

処理の起点を決める

1つ目は、フォームの送信です。 Apps Script のインストール型のトリガーには、Google フォーム側の送信のトリガーと、回答先のスプレッドシート側の送信のトリガーの2種類があります。スプレッドシート側を使い、回答の行が書かれた後で動かします。 送信のたびに振り分けまで済ませておくと、締めの時点では合計するだけになります。

2つ目は、締めの時間主導型のトリガーです。 毎週火曜の17時台に動かし、その週の依頼を品目ごとに合計して発注の一覧の案を作ります。公式のページでは、時間主導型のトリガーの時刻は少しずれることがあり、9時に設定すると9時から10時のあいだに動くとされています。締めの時刻をフォームに書くときは「17時まで」とし、トリガーは17時台に置きます。 17時を過ぎた送信は翌週に回します。

インストール型のトリガーは、作った人のアカウントで動くとされています。 総務の共用のアカウントで作ります。失敗したときは、まとめのメールがそのアカウントに届きます。

入力データを集める

質を決めるのは、品目の一覧の「規格」と「入り数」です。 規格が無いと、黒と青、0.5と0.7が同じ品目に見えます。入り数が無いと、「付箋5」を何パックにすればよいか、Apps Script が計算できません。

フォームでは、数量と単位を別の質問にします。 単位は「本・個・冊・枚」「箱・パック」「分からない」の選択にし、品名は自由に書けるようにします。品名を選択にすると180品目から選ぶことになり、社員が面倒がってチャットに戻ります。 品名を自由に書けることが、フォームに乗ってもらう条件です。

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

フォームの回答は、送信のイベントから受け取ります。公式のページでは、スプレッドシート側の送信のイベントは、質問の名前と値をまとめた namedValues、書き込まれた範囲を表す range、シートの並びどおりの values などを持つとされています。質問の名前で値を取る namedValues を使います。

部署の庶務担当がまとめて出す依頼は、1回の送信に10行以上が入ります。 フォームに「品名1・数量1・単位1」から「品名10」まで並べるか、庶務担当には品名と数量を改行で区切って書いてもらい、Apps Script で行に分けます。行に分けた時点で、依頼の番号に枝番を付けます。

同時の送信に備えて、台帳に書く部分を1件ずつにします。 公式のページでは、LockService はコードの一部への同時のアクセスを防ぐもので、getScriptLock() はどの利用者が動かしたかにかかわらず同時の実行を止めるとされています。締めの直前の火曜の午後は送信が重なるので、枝番を振って書き込むまでをロックで囲みます。 ロックは waitLock か tryLock を呼んで初めて取れるとされています。

AIへ渡す前に整形する

1. 行に分ける … 1回の依頼を品名ごとの行に分け、枝番を付けます
2. 表記をそろえる … 全角と半角、カタカナとひらがな、「ﾎﾞｰﾙﾍﾟﾝ」のような半角カナを、比べる前にそろえます
3. 言い換えの表を引く … そろえた品名が表にそのまま載っていれば、その番号を付けて AI を呼びません
4. 候補を絞る … 品目の一覧から、品名に含まれる語（ペン、ノート、付箋、ファイル、電池など）で分類の近い品目を30〜50に絞ります。絞れないときは全品目を渡します
5. 数量を確かめる … 数量が空、0、数字でない行は、AI に渡さず依頼者に戻します
6. 依頼者の名前を外す … AI に渡すのは依頼の番号と枝番、品名、規格、用途だけです

4番目で候補を絞るのは、列挙の値の上限のためでもあります。 公式のページでは、構造化出力の列挙の値はすべての列挙を合わせて1,000まで、1つの列挙が250を超える文字列の値を持つときは合計15,000文字までとされています。180品目なら全品目を渡しても収まりますが、品目が増える会社では、候補を絞る手順が先に要ります。

AIに処理させる

させるのは、依頼の1行を読み、次の4つのどれに当たるかを決め、標準の品目なら番号を選ぶことです。

non_standard の nearest は、置き換えの提案ではなく、総務が判断するための材料です。 「撮影用の蛍光ピンクのマーカー」に「標準品の黄色のマーカー」を近いものとして出しても、用途によっては置き換えられません。 置き換えるかどうかは、依頼者と総務が決めます。

2行目と4行目が、この構成の要です。 数量を AI に計算させると、「10個入りを5パック」と「5個」を取り違えたまま発注の一覧に入ります。番号を作らせると、存在しない商品番号で注文しようとして、通販のサイトで初めて気づきます。

指示内容を固定する

あなたは会社の総務部で、社員から届く事務用品・消耗品の購入依頼を、
社内の標準の品目に振り分ける立場です。
渡された依頼の1行と、品目の候補だけを見て判定してください。
推測で埋めないでください。

【振り分けの選び方】
- standard ....... 候補のどれかと品名・規格が同じ。item_id にその番号を入れる
- non_standard ... 事務用品・消耗品だが、候補に同じ規格の品目が無い。
                   近い品目があれば nearest にその番号を入れる
- not_supply ..... 事務用品・消耗品ではない（周辺機器、家具、什器など）。
                   route に回付の先の種類を入れる
- unreadable ..... 何の品物か分からない。question に依頼者への質問を1文で書く

【厳守事項】
- item_id と nearest には、候補の番号だけを入れてください。
  候補に無い番号を作らないでください。
- 規格（色・太さ・サイズ・枚数）が候補と違うときは standard にしないでください。
  「黒」と「青」、「0.5」と「0.7」、「A4」と「B5」は別の品目です。
- 依頼に規格が書かれていないときは、最も一般的な規格の候補を選び、
  confidence を low にしてください。
- 商品名やブランド名で書かれていても、規格が同じなら standard にしてよいです。
  ブランドの違いだけで non_standard にしないでください。
- 数量と単位を計算・換算しないでください。数量はこちらで扱います。
- 標準外を買うべきか、標準品で足りるかを書かないでください。
- 費目や勘定科目を書かないでください。
- reason には、判定の根拠にした依頼の語を短く写してください。

【依頼の1行】{request_line}
【品目の候補】{candidates}
【回付の先の種類】{routes}

「ブランドの違いだけで non_standard にしない」は、会社ごとに決めることです。 標準の品目をブランドで決めている会社なら、逆に書きます。どちらにするかを決めずに始めると、AI の振り分けと総務の判断が毎週ずれます。 品目の一覧の「標準として扱う理由のメモ」に、ブランドを問うかを書いておきます。

「規格が違えば standard にしない」を具体例で書くのは、AI が近いものを同じとみなしやすいからです。 色と太さとサイズは、届いてから使えないと分かる違いなので、例を3つ並べて念を押します。

出力形式を固定する

OpenAI API の構造化出力で、次の形の JSON を受け取ります。 公式のページでは、Responses API の text.format に type: "json_schema" と strict: true を指定し、すべてのオブジェクトに additionalProperties: false を付け、すべての項目を required にすることとされています。

{
  "line_id": "",
  "category": "standard | non_standard | not_supply | unreadable",
  "item_id": "P-0023 | null",
  "nearest": "P-0031 | null",
  "route": "it | furniture | other | null",
  "confidence": "high | low",
  "question": "",
  "reason": ""
}

1つ目の理由は、item_id を列挙の値で縛れることです。 候補の番号を enum に並べ、該当しないときのために null を許します。公式のページでは、任意の項目は null との組み合わせの型で表すとされています。番号が列挙の中からしか返らないので、存在しない番号が発注の一覧に入りません。

2つ目は、振り分けを規則で印に変えられることです。 AI が返すのは category と confidence までで、総務に回すかどうかは Apps Script が決めます。

3つ目は、応答が拒否や途中切れで返ったときを見分けられることです。 公式のページでは、拒否のときは refusal が返り、出力の上限で切れたときは status が incomplete になるとされています。どちらのときも JSON として読まず、その行を「聞き直し」に回します。

システムへ連携する

発注の一覧は、仕入先の一括注文の形に合わせた列にします。 仕入先の商品番号と数量の2列があれば、多くの通販の一括注文に貼り付けられます。どの形で取り込めるかは仕入先ごとに違うので、仕入先の案内に合わせて列を決めます。 この構成は注文そのものを入れません。

OpenAI API の呼び出しは、失敗の応答でも止まらないようにします。 UrlFetchApp.fetch の muteHttpExceptions を true にすると、失敗の応答でも例外を投げないとされています。失敗した行は「聞き直し」ではなく「未判定」とし、締めの前にもう一度呼びます。 API のキーはスクリプトのプロパティに置きます。

応答は保存しない設定で呼びます。 公式のページでは、Responses API の応答は既定で少なくとも30日、アプリケーションの状態として保たれるとされています。会話を続けない1行ごとの判定なので、store を false にします。

人が確認する

総務が開くのは、印の付いた行だけです。 印なしの行は、締めの後の発注の一覧で品目ごとの合計を流し見るだけにします。

1. 聞き直しを先に見る … question を使って依頼者にチャットで聞きます。締めの前に答えが来なければ翌週に回します
2. 標準外を見る … 依頼者に用途を確かめ、標準品で足りるか、標準外で買うかを決めます。標準外で買うと決めたら、品目の一覧に足すかも決めます
3. 規格の確認を見る … 色や太さが書かれていない行です。多くは一般的な規格で足ります
4. 発注の一覧を見る … 前週と比べて大きく増えた品目がないかを見ます

判断したら、言い換えの表に1行足します。 「サラサの青 → P-0023」「蛍光ピンクのマーカー（撮影用）→ 標準外で購入」。翌週から、同じ書き方の依頼は AI を呼ばずに振り分けられます。

目標は、480行のうち総務が開くのを1割前後に抑えることです。 最初の月は言い換えの表が空なので2〜3割に上がり、表が育つほど下がります。

例外に対処する

2行目を Apps Script の推測で埋めないでください。 「付箋5」を5パックと読むか5個と読むかを機械が決めると、10倍の数が届くか、10分の1しか届きません。 分からない単位は依頼者に聞くのが最も早く終わります。

上限は、公式の表で実行時間が1回6分、トリガーの合計が Google Workspace のアカウントで1日6時間、外部への呼び出しが1日10万回です。 締めの時点の合計は表の計算だけなので、1回6分には遠く届きません。

記録を残す

• 依頼ごとの、フォームの回答の原文と受け付けた日時
• 行ごとの振り分けの結果と、AI を呼んだか、言い換えの表で決まったか
• AI に渡した候補と、返ってきた JSON の全文
• 総務が振り分けを直した記録と、言い換えの表に足した行
• 締めごとの発注の一覧の版と、実際に発注した数量
• 標準外で買った品物と、その理由

2つ目の「AI を呼んだか」は、言い換えの表が育っているかを測る数です。 締めごとに AI を呼んだ行の割合を見て、下がっていなければ、総務の判断が表に戻っていません。

最後の行は、品目の一覧を見直す材料です。 同じ標準外の品物が何か月も続けて買われるなら、標準の品目に足すほうが、毎週の判断より安く済みます。