大学の研究室の試薬の在庫表と使用記録から、発注が要る試薬を判定して発注依頼の下書きを作る

処理の起点を決める

毎週月曜の朝に動かします。 Apps Script の時間主導型のインストール型トリガーで、週に1回、月曜の7時に設定します。試薬係が出勤して最初に見る時間に、下書きが届いている状態にします。

時刻はちょうどにはなりません。 公式のページでは、時間主導型トリガーの時刻は少しずれることがあり、9時に設定すると9時から10時の間のどこかで動き、その時刻は日ごとに変わらないとされています。7時に設定すれば7時台のどこかで動き、8時半の始業には間に合います。

12研究室を1回で回さず、4つずつ3回に分けます。 7時、7時台の2本目、8時台の1本目という形でトリガーを3つ作り、それぞれが担当の研究室を処理します。1回の実行の6分の上限に余裕を持たせるためです。 処理した研究室と日付を発注依頼シートの別のタブに書き、同じ週に二度処理しないようにします。

トリガーは学部の共用アカウントで作ります。 公式のページでは、インストール型トリガーは常に作った人のアカウントで動きます。試薬係の個人のアカウントで作ると、その人が異動したときに止まります。 失敗は所有者へのメールで届くので、共用アカウントのメールを技術職員が毎日見ます。

入力データを集める

質を決めるのは、在庫表の「別名・略称」の列です。 学生が書く「THF」「脱水THF」「テトラヒドロフラン」を同じ試薬に結び付けるには、どの書き方がどの試薬IDに当たるかを在庫表に書いておく必要があります。 規格が違う試薬（脱水と一般、安定剤の有無）は別の行にし、それぞれの別名を書きます。

予定のシートは、試薬係が月に1回書き足します。 「11月から B4 の2人が合成を開始、THF とヘキサンを多く使う見込み」のように、期間と試薬を書きます。 予定が無ければ、判定はふだんの使い方だけで行われます。

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

AIは UrlFetchApp から Claude API を呼びます。 fetch に method を post、contentType を application/json、headers に API のキーと anthropic-version、payload に指示と材料と output_config を入れます。公式のページでは、contentType を省くと既定はフォームの形式になり、muteHttpExceptions を有効にすると失敗の応答でも例外を投げずに応答を返します。 応答の状態を見て、失敗した研究室に印を付けるために使います。

1つの研究室につき、AIを2回呼びます。 1回目は使用記録の結び付け、2回目は発注の要否の判定です。間に Apps Script の計算を挟むので、1回にまとめません。 API のキーはスクリプトのプロパティに置き、コードに書きません。

AIへ渡す前に整形する

1. 使用記録を研究室ごとに分ける … フォームの「研究室」の欄で分けます
2. 在庫表の別名の一覧を作る … 試薬名と別名・略称の列から、試薬IDと書き方の対応を作ってAIに渡します。300〜500行の全部を渡さず、試薬ID・試薬名・別名・規格だけに絞ります
3. 確定した使用量を計算する … 1回目のAIの結果のうち、量が数字で取れたものを試薬IDごとに足し、使用量のタブに書きます
4. 切れるまでの週数を計算する … 在庫（未開封の本数 × 容量 ＋ 開封中の残りの目安）を、過去8週の週あたり使用量の平均で割ります
5. 発注点と納期で印を付ける … 未開封の本数が発注点を下回る、または切れるまでの週数が標準の納期＋1週を下回る試薬に「要確認」の印を付けます
6. 発注済みで未着のものを足す … 印を付ける前に、未着の数量を在庫に足します
7. 2回目に渡す試薬を絞る … 印の付いた試薬と、予定のシートに名前が出てくる試薬だけを渡します

4番と5番は、AIに任せません。 平均と割り算は、スクリプトなら毎回同じ答えになります。AIに渡すのは計算の結果で、計算そのものではありません。

7番で絞るのは、判定の材料を見やすくするためです。 500種類すべてを渡すと、AIはほとんど使っていない試薬にも理由を書き、試薬係が読む量が増えます。

AIに処理させる

1回目にさせるのは、使用記録の1件ずつを在庫表の試薬IDに結び付け、量を見積もることです。

3行目が大事です。 「少し」を AI が勝手に 10 mL と置くと、その数字が使用量のタブに残り、次の週からの平均を少しずつ狂わせます。 あいまいな記録は言葉のまま返させ、2回目の判定の材料にだけ使います。

2回目にさせるのは、印の付いた試薬ごとに、発注が要るかを判定し、理由を書くことです。

指示内容を固定する

あなたは大学の研究室で、試薬の在庫を管理する試薬係を補助する立場です。
スクリプトが計算した在庫と使用量の数字、研究室の予定、使用記録のメモをもとに、
試薬ごとに発注が要るかを判定してください。

【判定の選び方】
- order ... 切れるまでの週数が標準の納期＋1週を下回り、予定や記録から
            その使い方が続くと読める。または、予定で使う量が増える。
- watch ... 数字の上では印が付いたが、予定や記録から今週は頼まなくて
            よいと読める（テーマの終了、他の規格への切り替えなど）。
            その根拠を必ず書く。
- check ... 使用記録があいまい、在庫表の本数と記録が食い違う、
            開封中の残りの目安が空欄など、棚を見ないと決められない。
迷ったときは check を選んでください。watch を選ぶのは根拠があるときだけです。

【厳守事項】
- 在庫、使用量、週数を計算し直さないでください。渡した数字をそのまま使ってください。
- 「少し」「半分くらい」などの記録を数字に直さないでください。
- 渡した材料に無い予定や事情を推測しないでください。
- 予算の科目、購入先の選択については書かないでください。
- 区分が「毒物」「劇物」の試薬は、order のとき note に
  「譲受の書面が要る」と必ず書いてください。
- reason には、根拠にした数字と、予定・記録の言葉をそのまま写してください。

【発注の数量の目安】
- 標準の数量（在庫表の「標準の発注数」）をそのまま quantity に入れてください。
- 予定で使う量が増えるときだけ、標準の数量を超えてよい。そのときは
  quantity_reason に予定の言葉を写してください。

【試薬ごとの計算の結果】{calc_results}
【研究室の予定（今後8週）】{schedule}
【先週の使用記録のうち、あいまいな記録と結び付けできなかった記録】{qualitative_logs}
【発注済みで未着のもの】{pending_orders}

「迷ったときは check を選ぶ」を明記しないと、watch に寄ります。 予定のシートに少しでも関係のありそうな言葉があると、それを根拠に「今週は不要」と書きます。watch が増えると、第3章の（a）に戻ります。

「計算し直さない」を書くのは、AIが渡した数字を自分で検算して別の値を書くことがあるからです。 試薬係が読む理由の数字とスクリプトの数字が食い違うと、どちらを信じればよいか分からなくなります。

出力形式を固定する

2回目の判定は、次の形のJSONで受け取ります。 Claude API の構造化出力で、output_config.format に JSON Schema を渡します。

{
  "lab_id": "",
  "items": [
    {
      "reagent_id": "",
      "decision": "order | watch | check",
      "quantity": 0,
      "quantity_reason": "",
      "reason": "",
      "note": ""
    }
  ]
}

1つ目の理由は、decision で振り分けを機械的にできることです。 order は発注依頼シートの下書きに、check は「棚を見るもの」の一覧に、watch はメールの末尾に件数だけ書きます。試薬係は、上から順に見ればよい状態になります。

2つ目は、下書きの行を在庫表から組み立てられることです。 AIが返すのは reagent_id と数量と理由だけで、試薬名・メーカー・品番・規格はスクリプトが在庫表から引いて下書きに書きます。 品番をAIに書かせると、似た品番の別の規格を書くことがあります。

3つ目は、schema の制約に合わせられることです。 公式のページでは、構造化出力の schema では minimum・maximum のような数値の制約が使えないとされています。数量が0以下や極端に大きくないかは、スクリプトで確かめます。 additionalProperties は false にします。

1回目の結び付けも、log_id、reagent_id、match（matched ／ unmatched ／ not_in_inventory）、amount_ml、qualitative、bottles_opened、bottles_emptied の形で受け取ります。 amount_ml は記録に数字があるときだけ入れ、無いときは空にします。

システムへ連携する

在庫表には書き込みません。 本数を直すのは、試薬係が棚を見たときと、納品された試薬を棚に入れたときだけです。AIの結び付けで本数を自動で減らすと、結び付けの誤りがそのまま在庫表に残ります。

試薬係への知らせには、order の件数と試薬名、check の件数と試薬名、発注依頼シートへのリンクを書きます。 公式のページでは、MailApp の getRemainingDailyQuota でその日に送れる残りの宛先数が分かるので、送る前に確かめます。

人が確認する

試薬係が見るのは、自分の研究室の発注依頼シートの下書きと check の一覧です。

1. check を先に見る … 棚を見て、開封中の残りの目安と未開封の本数を在庫表に直します。直した後に、その試薬を頼むかを決めます
2. order の理由を確かめる … reason の数字と予定の言葉を読み、頼む数量を決めます
3. unmatched と not_in_inventory の記録を見る … 在庫表の別名を足すか、新しい試薬の行を足すかを決めます
4. 予算を決めて購買システムに入力する … 毒物・劇物は学内の手続きを行います
5. 「発注済み」の印を付ける

3番を毎週続けると、unmatched が減っていきます。 学生の書き方は研究室ごとに癖があり、別名の列に足すほど、1回目の結び付けが当たるようになります。

学生への伝え方も、確認の一部です。 unmatched の多い書き方をする学生がいれば、試薬係が「在庫表の試薬名で書いてほしい」と伝えます。フォームの試薬名の欄を、在庫表の試薬名から選ぶ形に変えるのは、記録の数がそろってからにします。 最初から選ばせると、在庫表に無い試薬を使ったときに記録が付けられなくなります。

目標は、1研究室あたり週10分です。 check の棚を見る時間が中心で、check が多い週は、在庫表の開封中の残りの目安が空いています。

例外に対処する

5行目の二重の書き足しは、意図してのことです。 譲受の書面の要否は法律の手続きなので、AIの出力だけに頼らず、区分の列という確かな情報からスクリプトが必ず書きます。

記録を残す

• 研究室ごと・週ごとの、AIに渡した材料（計算の結果、予定、あいまいな記録）
• AIが返した JSON の全文（1回目と2回目）
• 確定した使用量の週ごとの値と、その元になった記録のID
• 試薬係が下書きを直した内容と、check を棚で確かめた結果
• 発注した日、数量、納品された日
• 切れてしまった試薬の記録 … 学生からの「無い」の連絡と、その試薬の直前の判定

最後の行が、この構成の見直しの材料です。 切れた試薬の直前の判定が watch だったなら指示が、印が付いていなかったなら発注点か納期の列が合っていません。どちらの誤りかで、直す場所が変わります。