社内の購入依頼の品目と用途から費目・勘定科目・購買の区分の候補を付け、経理の計上と購買の手配の前の仕分けを済ませる

処理の起点を決める

フォーム送信時のインストール型トリガーを、依頼台帳のスプレッドシートに1つ置きます。 依頼が1件届くたびに1回動き、その1件の候補を付けます。手配の前に候補が付いていることが、この構成の前提です。 1日1回のまとめ処理にすると、朝に届いた依頼の手配が翌日にずれます。

部門長の承認を待たずに動かします。 承認の前に候補と記載の不足が出ていれば、部門長は承認するときに「用途の記載が足りない」に気づけます。 承認の後に不足が分かると、依頼者と部門長の両方に聞き直すことになります。

同時に動いたときの書き込みの衝突を避けます。 月初の朝は依頼が続けて届き、複数の実行が同時に台帳へ書きます。スクリプトのロックを取ってから台帳に書き、書き終えたら放します。 ロックは取得を指示するまで有効にならないので、tryLock で待つ時間を決めて取り、取れなければ「候補待ち」の印を付けて終わります。

「候補待ち」は、1時間ごとの時間主導型のトリガーで拾い直します。 送信時のトリガーが失敗した依頼も、この拾い直しで候補が付きます。

入力データを集める

AIに渡すのは、品目・用途・数量・単価・購入先と、費目表と、似た品目の確定済みの依頼5件だけです。 依頼者の氏名は渡しません。部署は渡します。 同じ「撮影用の照明」でも、広報部なら広告宣伝費、開発部なら研究開発費、と自社の費目表で分けていることがあるからです。

費目表の「含めるものと含めないものの例」が、候補の質を決めます。 科目名だけを渡すと、AIは一般的な会計の知識で選び、自社の決め方と食い違います。「技術書は新聞図書費。研修の教材として配るものは研修費」のように、迷う品目の決め方を自社の言葉で書いておきます。

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

依頼の行は、フォーム送信のイベントの namedValues から取ります。設問の名前で値を引けるので、列の並びを入れ替えても壊れません。 書き込み先の行は、イベントの range から分かります。

似た品目の前例は、スクリプトの側で選びます。 品目の文字列を単語に分け、確定の記録の品目と共通する単語の多い順に5件を取ります。単純な方法ですが、「USB-C電源アダプタ」と「USB-C 充電器」が拾えれば足ります。 前例が見つからなければ、前例なしで渡します。

Claude API は UrlFetchApp で呼びます。 鍵はスクリプト プロパティに置き、x-api-key と anthropic-version のヘッダに入れます。muteHttpExceptions を true にして、失敗の状態コードでも応答を受け取り、再試行するかを決めます。

AIへ渡す前に整形する

1. 金額の正規化 … 金額欄の「¥」「円」「,」を外して数にします。「約」「〜」が付いていれば approx の印を付けます
2. 単価の計算 … 金額が合計で書かれていれば、数量で割って1単位あたりの金額を出します。単価か合計かは、フォームの設問で選ばせておきます
3. 税の扱いの確認 … フォームの「税込／税抜」の選択と、設定のシートの経理処理の方式から、判定に使う金額を決めます
4. 金額の基準の判定 … 判定に使う1単位あたりの金額が、設定のシートの線（10万円、20万円など）のどこに入るかを式で判定します
5. URLの扱い … 購入先のURLは、AIには渡さずに台帳に残します。商品ページを読みに行かせることはしません
6. 前例の取得 … 似た品目の確定済みの依頼を5件まで取ります
7. 費目表の enum の作成 … 費目表の有効な行から科目名の一覧を作り、スキーマに入れます

3番目と4番目を規則で行う理由は、国税庁の説明にあります。 少額の減価償却資産に当たるかの「10万円未満」は、法人が適用している消費税等の経理処理の方式に応じて算定した価額で判定するとされ、税抜経理方式なら税抜、税込経理方式なら税込の価額が取得価額になります。同じ107,800円（税込）のパソコンでも、方式によって10万円の線のどちら側かが変わります。 AIに任せず、会社の設定から式で決めます。

4番目の判定は、あくまで「確認が要るかの印」です。 取得価額は通常1単位として取引される単位ごとに判定し、応接セットならテーブルと椅子の1組で、カーテンなら部屋ごとの合計で見る、と国税庁は例を挙げています。何を1単位と見るかは品目しだいなので、組で判定が要りそうな依頼にはAIに印を付けさせ、経理担当が決めます。

AIに処理させる

させるのは、品目と用途の記載を読んで、費目表と購買の区分の中から候補を1つずつ選び、根拠の語句と、記載の不足を返すことです。

前例は「参考」として渡し、前例と違う候補を選ぶことも許します。 似た品目でも用途が違えば科目が変わるからです。前例と違う候補を選んだときは、その理由を note に書かせます。 経理担当は、前例との違いが書かれた依頼から先に見ます。

いちばん起きやすい失敗は、1行目です。 依頼に「モニター 3台 270,000円」とあると、AIは「27万円なので固定資産」と書きがちです。1台9万円で、しかも税込か税抜かで線の位置が変わります。 判定はスクリプトが済ませ、AIの出力に金額の判定を書く欄そのものを作りません。

指示内容を固定する

あなたは管理部で、社内の購入依頼を仕分ける立場です。
依頼の品目と用途を読み、費目表と購買の区分の中から候補を選んでください。
候補は担当者が確かめてから確定します。迷ったときは確信が低いと示してください。

【費目表】{account_table}
（科目名、説明、含めるものの例、含めないものの例）

【購買の区分】
- catalog ...... 購買サイトで買える備品・消耗品・書籍
- quotation .... 取引先から見積を取って買うもの（製作物、什器、大量の購入）
- software ..... ソフトウェアのライセンス、クラウドサービス、購読（情報システム部の確認が要る）
- outsourcing .. 人や会社に作業を頼むもの（制作、研修の実施、翻訳）
- fixed_asset .. 固定資産の申請が先に要るもの（金額の判定は別に済んでいる。下の判定結果を使う）

【この依頼】
部署：{department}
品目：{item}
用途：{purpose}
数量：{quantity}　1単位あたりの金額（判定に使う額）：{unit_price}
金額の判定結果（規則で済み）：{amount_rule_result}

【似た品目の前例（確定済み）】{precedents}

【厳守事項】
- 勘定科目は費目表にある名前からだけ選んでください。新しい科目名を作らないでください。
- 金額が基準を超えるかどうかを判断しないでください。判定結果はすでに渡しています。
- 固定資産にするか費用にするかを決めないでください。
- evidence には、候補を選んだ語句を品目と用途からそのまま写してください。
- 用途が「業務用」「仕事で使う」など、何に使うかが分からない書き方なら、
  missing_info に purpose_vague を入れ、依頼者に聞く内容を question_draft に書いてください。
- テーブルと椅子のように組で取引されるもの、複数を組み合わせて機能するものは、
  set_judgement_needed を true にしてください。
- 前例と違う候補を選んだときは、理由を note に書いてください。
- URLの先の内容を推測しないでください。

「判定結果はすでに渡しています」と書くのが要点です。 金額の判定を禁じるだけだと、AIは「27万円のため固定資産の可能性」と note に書いてきます。判定が済んでいることを伝えると、金額に触れずに品目と用途だけで選ぶようになります。

question_draft は、依頼者への問い合わせの下書きです。 購買担当がチャットで聞くときに、そのまま使える文にします。「何に使いますか」より「どの業務で、誰が使いますか（例：新人研修の教材、開発チームの検証用）」のように、答えやすい形で書かせます。

出力形式を固定する

次の形のJSONで受け取ります。 output_config.format の type を json_schema にし、account と account_alt は費目表の科目名を、procurement は5つの区分を enum で列挙します。

{
  "request_id": "PR-2026-10-0412",
  "account": "新聞図書費",
  "account_alt": "研修費",
  "procurement": "catalog",
  "confidence": "high",
  "set_judgement_needed": false,
  "missing_info": [],
  "question_draft": "",
  "evidence": "技術書 TypeScript入門 チームの勉強会で輪読",
  "note": ""
}

1つ目の理由は、enum で費目表の外の科目を出させないことです。 候補が会計の仕組みに無い科目名だと、経理担当は結局一から選び直します。選択肢に閉じ込めておけば、候補をそのまま確定できる依頼が増えます。

2つ目の理由は、account と account_alt を分けて持てることです。 技術書のように2つの科目で迷う品目では、次点が見えるだけで経理担当の判断が速くなります。

3つ目は、出力を確かめる手順がはっきりすることです。 公式の説明では、stop_reason が refusal のときは出力がスキーマに合わないことがあり、max_tokens のときはJSONが途中で切れるとされています。スクリプトはまず stop_reason を見て、end_turn 以外ならその依頼を「候補待ち」に戻します。 そのうえで account が費目表の今の有効な行にあるかを確かめます。費目表を直した直後は、古い科目名が返ることがあるからです。

台帳には、AIの出力に加えてスクリプトの判定を並べます。

システムへ連携する

台帳への書き込みは、候補の列と判定の列だけにします。 依頼者が書いた列と、部門長の承認の列には書きません。確定の列も、スクリプトは空のまま残します。 候補を確定の列に先回りして書くと、人が確かめたかどうかが見分けられなくなります。

Chat への知らせは、1件ごとではなく、まとめて送ります。 投稿はスペースあたり毎秒1回までなので、送信時のトリガーでは知らせる内容を台帳の印にとどめ、15分ごとの時間主導型のトリガーで印の付いた依頼をまとめて1件で知らせます。

人が確認する

1. 購買担当が区分の候補を確かめる … 部門長の承認が済んだ依頼について、候補の区分で手配してよいかを見て、確定の列に区分を書きます
2. 記載の不足を聞く … question_draft を見て、依頼者に聞きます。送るのは人です
3. 組で判定が要る依頼を経理に回す … set_judgement_needed が true のものは、手配の前に経理担当が1単位の数え方を決めます
4. 経理担当が科目の候補を確かめる … 請求書や領収書が届いて計上するときに、候補の科目でよいかを見て、確定の列に科目を書きます
5. 前例と違う候補を先に見る … note に理由が書かれた依頼は、費目表の決め方が足りていない可能性があります

4番目で候補と違う科目を確定したら、その依頼は次から前例として効きます。 確定の記録に入るので、似た品目が来たときにAIへ渡る前例が変わります。人が直した分だけ、次の候補が自社の決め方に寄っていきます。

目標は、600件をならして1件1分です。 候補をそのまま確定できる依頼は購買・経理とも数秒で済み、記載の不足と組の判定と前例と違う候補の分だけ時間を使う、という想定です。

例外に対処する

いちばん多いのは、5行目と6行目です。 「一式」「合計約30万」のような書き方や、1つの依頼にモニターとケーブルと椅子が並ぶ書き方です。どちらもAIの問題ではなく、フォームの設問の問題です。 単価と数量を別の設問にし、1依頼1品目を案内に書くほうが、候補の精度を上げようとするより効きます。

記録を残す

• 依頼番号、送信日時、処理した日時、処理の結果（候補あり／候補待ち／要確認）
• 判定に使った単価、税の扱い、経理処理の方式、金額の判定
• AIの出力の全文（account、account_alt、procurement、confidence、evidence、note など）と、そのとき渡した前例の依頼番号
• 確定した区分と科目と、候補と違ったかどうか
• そのときの費目表の版

4つ目は、候補の当たり方を測る材料です。 科目の候補がそのまま確定された割合を、科目ごとに毎月数えます。当たらない科目は、費目表の「含めるものと含めないものの例」が足りていません。

3つ目で前例の依頼番号を残すのは、候補が前例に引っ張られたかを後から見るためです。 前例の科目が誤って確定されていた場合、その誤りが似た品目の候補に広がります。どの前例を見て選んだかが残っていれば、広がった範囲を追えます。