研究所の共用機器の予約を Apps Script でカレンダーから拾い、重複と講習・時間の決まりを規則で、試料の使用条件を AI で点検して、利用の時間を部門ごとに月次で集計する

処理の起点を決める

時間主導型のトリガーで、10分ごとに動かします。 公式のページでは、インストール型のトリガーは作った人のアカウントで動きます。 機器管理用のアカウントで作ります。技術職員の個人のアカウントで作ると、その人が異動したときに止まります。

10分ごとにしたのは、予約から点検までの遅れを短くするためです。 夕方に入った当日の時間外の予約も、10分以内に講習と立会人の点検が済みます。毎朝1回にすると、前夜の時間外の使用は点検の前に終わっています。

同時に2つ動かさないよう、最初にロックを取ります。 公式のページでは、LockService.getScriptLock() はどの利用者からも、そのコードの部分を同時に動かさないためのロックです。前の実行が長引いているうちに次の10分が来ると、同じ予約を2回点検し、知らせが2通届きます。 ロックが取れなければ、その回は何もせずに終えます。

月次の集計は、別の時間主導型のトリガーで毎月1日に動かします。 公式のページでは、onMonthDay() で月の日を、atHour() で時刻を決められます。分は前後15分ずれることがあります。

入力データを集める

質を決めるのは、予約の説明の書き方です。 研究員に、予定の説明を次の5行で書いてもらいます。

使用者：[email protected]
試料：Fe-Ni 合金の粉末（約0.5g）
薬品・溶媒：エタノール
目的：粒子の形状の観察
立会人：（時間外のときだけ）

行の頭の言葉を決めておけば、Apps Script が行ごとに読み分けられます。 自由に書かせると、AIに読み分けさせることになり、使用者のメールを読み違えると講習の点検そのものが誤ります。 書式に沿っていない予約は、点検をせずに予約者に書き直しを頼みます。

使用条件は、条件の番号を付けた1行1条件にします。 「真空系に入れる試料は、含水・揮発性・磁性のものを除き…」のように長い文で書かれていると、AIがどの部分に当てはまるかを示せません。 1行1条件に分けると、結果に条件の番号を返させられます。

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

syncToken は機器ごとに保存します。 24台のカレンダーは別々のトークンを持ちます。スクリプトのプロパティに「機器ID → トークン」で保存し、 カレンダーごとに増分同期をします。公式のページでは、プロパティの値は1つ9KBまでです。トークンは短い文字列なので足ります。

取消は status が cancelled の予定として届きます。 Calendar API のページでは、cancelled は取り消された（削除された）予定です。予約の記録の同じ予定IDの行に「取消」と書き、集計から外します。 取消を拾わないと、消された予約まで利用料に入ります。

作成者は creator.email で取れますが、使うのは説明の「使用者」の行です。 研究室の補助の人が代わりに予約を入れることがあるからです。使用者の行が空なら、作成者を使用者として扱い、 確認の一覧に「使用者の記載なし」と書きます。

AIへ渡す前に整形する

1. ロックを取る … 取れなければ終えます
2. 増分同期 … 機器ごとに Events.list をトークン付きで呼び、ページを最後までたどってからトークンを保存します
3. 点検済みかの確認 … 予定IDと更新の時刻（updated）で予約の記録を引き、同じ更新の時刻なら飛ばします
4. HTML を外す … Calendar API のページでは、説明は HTML を含みうるので、タグを外してから読みます
5. 書式で読み分ける … 行の頭の言葉で使用者・試料・薬品・目的・立会人に分けます
6. 規則の点検 … 重複、講習の修了、上限、時間外の立会人を確かめます
7. AIへの入力を絞る … その機器の使用条件の行と、試料・薬品・目的の3行だけを渡します

2番目で、途中で抜けないことに注意します。 公式のページの例は、取り消された予定や終日の予定を見つけると return で関数を抜ける書き方で、そのまま写すと残りの予定とトークンの保存が飛びます。 予定ごとの処理は continue で次へ進め、トークンは必ず最後に保存します。

6番目の規則は、表にして Apps Script に持たせます。

重複の比べ方は、終了の時刻を含めないで比べます。 Calendar API のページでは、開始は含み、終了は含まないとされています。10時〜12時と12時〜14時の予約は重なりません。終了を含めて比べると、続けて入った予約がすべて重複として知らせられます。

時間外の定義は、機器ごとに決まりの表に置きます。 平日の18時以降と休日、という研究所の共通の定義に、夜間に無人で動かせる機器の例外を足せるようにします。

3番目は、通知が2回届くのを防ぎます。 増分同期は、予定の色を変えただけでも変わった予定として返します。点検に関係する項目（開始、終了、説明、状態）が前と同じなら、点検をやり直しません。

AIに処理させる

させるのは、試料・薬品・目的の記述を、その機器の使用条件の行に照らして、当てはまりうる条件を挙げることだけです。

「当てはまる」ではなく「当てはまりうる」で返させます。 「Fe-Ni 合金」が磁性の試料かは、組成と状態で変わります。AIは「磁性の可能性がある記述」として挙げ、管理者が予約者に聞きます。

3行目がいちばん起きやすい失敗です。 「細胞の切片」とだけ書かれていると、AIは「固定と乾燥の処理がされていると思われるため、該当なし」と書きます。処理が書かれていなければ、情報の不足として返させます。

指示内容を固定する

あなたは研究所の共用機器の管理を手伝う立場で、予約に書かれた試料と薬品が、
その機器の使用条件に当てはまりうるかを洗い出します。
判断は機器の管理者が行います。あなたは候補と根拠を挙げるだけです。

【機器】{equipment_name}
【使用条件】（1行1条件。先頭は条件の番号）
{conditions}

【予約の記述】
試料：{sample}
薬品・溶媒：{chemicals}
目的：{purpose}

【やること】
1. 使用条件の1行ずつについて、予約の記述が当てはまりうるかを見る。
2. 当てはまりうるものは matches に、条件の番号と、根拠にした予約の記述を
   そのまま写して入れる。
3. 条件を判断するのに要るのに書かれていない情報は、missing_info に入れる。
4. どれにも当てはまらず、不足も無ければ、matches と missing_info を空にする。

【厳守事項】
- 試料を機器に入れてよいか、使ってよいかを書かないでください。
- 書かれていない試料の性質（乾燥しているか、磁性か、量など）を
  推し量って補わないでください。不足は missing_info に入れてください。
- 使用条件に無い注意を新しく書かないでください。
- quote には予約の記述の文字列をそのまま写してください。言い換えないでください。
- condition_no には使用条件の先頭の番号だけを入れてください。

「使ってよいかを書かない」を最初に置きます。 書かないと、要約の最後に「以上より、使用に問題はないと考えられます」と結論を足します。管理者がその一文を読んで確認を省くと、この構成の意味がなくなります。

「推し量って補わない」と missing_info をセットで書くのも同じ理由です。 補うことを禁じるだけだと、AIは当てはまらない側に倒して「該当なし」を返します。不足を返す欄があれば、分からないことを分からないと返せます。

出力形式を固定する

次の形のJSONで受け取ります。 構造化出力のスキーマで、各オブジェクトの additionalProperties を false にします。

{
  "matches": [
    { "condition_no": "SEM-03",
      "quote": "Fe-Ni 合金の粉末（約0.5g）",
      "reason": "磁性のある試料の可能性がある記述" }
  ],
  "missing_info": ["粉末を固定する方法（カーボンテープなど）"],
  "no_concern": false
}

1つ目の理由は、condition_no で使用条件の表と結べることです。 確認の一覧に、条件の番号から条件の文を引いて並べます。AIが条件の文を言い換えても、表の原文が並ぶので誤読しません。

2つ目は、quote を予約の説明と照合できることです。 スクリプトで、quote が説明の中にそのまま含まれるかを確かめ、含まれなければ「根拠の照合に失敗」として確認の一覧に入れます。 AIが記述を書き換えたことに気づけます。

3つ目は、no_concern で確認の一覧を短くできることです。 no_concern が true で規則の違反も無ければ、確認の一覧に入れず、予約の記録に「点検済み」とだけ書きます。 管理者が見るのは、何かが挙がった予約だけです。

月次の配賦の表は、AIを通さずに予約の記録から作ります。

集計に予約の記録を使うのは、カレンダーを数え直さないためです。 点検のたびに記録へ書いているので、取消も変更も反映済みです。月初にカレンダーを全部読み直すと、6分の実行の上限にも近づきます。

システムへ連携する

カレンダーには書き込みません。 規則の違反がある予約も、消さず、動かさず、色も変えません。予約者と管理者に知らせ、直すのは予約者です。 自動で消すと、名簿の更新が遅れていただけの予約まで消えます。

メールの宛先は、研究所のドメインのアドレスに限ります。 送る前に宛先のドメインを確かめ、外のドメインなら送らずに確認の一覧に入れます。 公式のページでは、Google Workspace のアカウントのメールの宛先は1日1,500までです。規則の違反の知らせは1日に数十件なので、届きません。

人が確認する

管理者が、確認の一覧に入った予約をすべて見ます。 入るのは、AIが条件を挙げた予約、情報の不足がある予約、根拠の照合に失敗した予約、書式に沿っていない予約です。

1. 挙がった条件の原文を読む … 条件の表の文と、予約の記述の原文を並べて読みます
2. 予約者に聞くかを決める … 聞くなら、管理者がメールか電話で連絡します
3. 判断を記録に書く … 「問題なし」「前処理を依頼」「使用を見合わせ」のどれかと一言を書きます
4. 条件の表を直す … 同じ問い合わせが続くなら、条件の行を足すか書き直します

3番目の記録が、月次の集計にも効きます。 「使用を見合わせ」とした予約は、利用料の配賦から外すので、記録の値で集計を分けます。

目標は、900件をならして1件1分です。 確認の一覧に入るのは2割ほどで、1件に数分かかります。残りの8割は、予約の記録の「点検済み」を流し見るだけです。

例外に対処する

4行目の書き方に気を付けます。 名簿に無いのは、名簿の更新が遅れているか、メールの書き違いか、本当に未修了かのどれかです。知らせの文は「確認できませんでした」にします。

最後の行は、全件の同期をやり直したときに起きます。 公式のページでは、Google Workspace のアカウントで1回の実行は6分までです。機器ごとに区切ってトークンを保存しているので、途中で止まっても、終えた機器はやり直しません。

記録を残す

• 予約の記録（予定ID、機器、使用者、部門、開始と終了、更新の時刻、規則の点検の結果）
• AIに渡した使用条件の行と予約の記述、返ってきたJSONの全文
• 管理者の判断と一言、判断した日時
• 規則の違反の知らせを送った宛先と日時
• 機器ごとの同期のトークンを保存した日時
• 配賦の表と、集計に使った予約の記録の範囲

2つ目で、そのときの使用条件の行を残すのは、条件が後から変わるためです。 条件を書き直すと、前の判断がどの条件に基づいていたかが分からなくなります。

最後の行は、部門からの問い合わせに答える材料です。 「この月の利用料が多い」と聞かれたとき、どの予約を足したかを予約の記録でたどれます。