研究所の共用機器の予約と利用の記録を毎月集計し、機器ごとの稼働率・予約の重なり・保守の時期の見込みを出して、増設と保守の計画の材料にする

処理の起点を決める

毎月1日の朝7時台に、月1回の時間主導型のトリガーで動かします。 時間主導型のトリガーは、毎分から月1回までの間隔で設定でき、時刻は1時間の幅の中で選ばれます。稼働率は月単位で見るもので、毎日動かす必要はありません。

利用の記録の入れ忘れを待つために、1日ではなく3日に動かす運用もあります。 月末に使った分を翌月の初めに入れる研究員がいるからです。どちらにするかは、入れ忘れの多さを2か月見てから決めます。

60台を1回の実行で処理しきれない場合に備えて、続きから動けるようにします。 1回の実行は6分までです。カレンダーを60回、それぞれ1か月分読むので、予定の多い機器が重なると時間がかかります。処理が終わった機器の印をシートに残し、6分に近づいたら止めて、次の実行で続きから動かします。

トリガーは研究企画室の共有の管理用アカウントで作ります。 インストール型のトリガーは作った人のアカウントで動きます。そのアカウントに、60台の予約のカレンダーを見る権限を与えておきます。 権限の無いカレンダーは取得できません。

入力データを集める

質を決めるのは、利用の記録です。 予約はカレンダーに確実に残りますが、利用の記録は研究員の入力しだいです。 入れ忘れが多い機器は、使われなかった予約の割合が高く出ます。

利用の予定は、見込みの精度を上げるために持ちます。 過去の推移だけでは、新しい研究のテーマが始まって利用が急に増えることを読めません。研究グループのリーダーに、四半期ごとに主な機器の利用の見込みを入れてもらいます。 入っていない機器は、推移だけで見込みを出します。

機器の一覧の「利用できる時間帯」が、稼働率の分母を決めます。 夜間の連続測定を受ける機器を日中だけの時間帯で数えると、稼働率が100％を超えます。逆に、日中しか使えない機器を24時間で数えると、いつも空いているように見えます。機器ごとに、実際に予約を受けている時間帯を書きます。

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

カレンダーは機器の一覧の順に1台ずつ読み、計算はスクリプトの中でまとめて行います。 フォームの回答と台帳は、範囲を1回でまとめて読みます。

計算の式は、次のように決めます。

利用できる時間 ＝ 機器ごとに決めた時間帯 × その月の稼働日
稼働率 ＝ 利用の記録の時間の合計 ÷ 利用できる時間
予約率 ＝ 予約の時間の合計 ÷ 利用できる時間
使われなかった予約の割合 ＝ 利用の記録と重ならなかった予約の時間 ÷ 予約の時間の合計
ピークの予約率 ＝ 10時〜16時の予約の時間 ÷ 10時〜16時の利用できる時間
次の3か月の見込み ＝ 直近6か月の稼働率の傾き × 経過月数 ＋ 登録された利用の予定の増分
保守の時期の見込み ＝ 前回の保守の日 ＋（周期の時間 − 累計の稼働時間）÷ 直近3か月の1日あたりの稼働時間
手配を始める期限 ＝ 保守の時期の見込み − 業者の手配にかかる日数

予定の時刻は、スクリプトのタイムゾーンで解釈されます。 カレンダーのタイムゾーンと違うことがあるので、スクリプトのタイムゾーンを研究所の所在地に合わせておきます。 ずれていると、時間帯ごとの予約率が丸ごと何時間かずれます。

AIへ渡す前に整形する

1. 月の境目での切り分け … getEvents が返した予定のうち、月をまたぐものは前月の範囲の部分だけを数えます
2. 利用できる時間帯での切り分け … 日中だけ受ける機器で夜にかかった予約は、日中の部分だけを予約率に入れ、夜の部分は別に数えます
3. 予約の重なりの検出 … 同じ機器で時間が重なる予定を拾います。カレンダーが重複した予約を受け付けてしまった件数です
4. 予約と利用の突き合わせ … 予約の時間帯と利用の記録の時間帯が重なるかで、使われた予約と使われなかった予約に分けます
5. 利用の記録の点検 … 終了が開始より前、24時間を超える、予約のない時間の利用を拾い、一覧の末尾に出します
6. 見込みの計算 … 「データの取得方法」の式で、次の3か月の稼働率と保守の時期、手配の期限を出します
7. AIに渡す材料の組み立て … 機器ごとに、当月の数字、過去12か月の推移、見込み、保守の時期を1つのまとまりにします

4番目で、使われなかった予約を「無断の取り消し」と決めつけないでください。 利用の記録の入れ忘れも、同じ形で出てきます。5番目で記録の点検を出し、入れ忘れが多い機器は、使われなかった予約の割合を参考の値として扱います。

7番目で、予約した人の名前は渡しません。 機器ごとの合計の数字だけを渡します。

AIに処理させる

させるのは、機器ごとに並んだ数字を読み、どの対応に当たるかを判定して、委員会で読める所見を書くことです。 計算と見込みは前処理で終わっています。

1台に付ける区分は、最大2つまでにします。 保守の手配と増設の検討が同時に当たる機器はあります。maintenance_due は他の区分と並べて付け、見落とされないようにします。 data_quality が付いた機器は、他の区分を付けさせません。記録が信用できないのに、増設やルールの見直しを言えないからです。

3行目が、いちばん起きやすい失敗です。 使われなかった予約の割合が高い機器について、何も言わなければ「特定の利用者による予約の確保が考えられます」と書きます。名前を渡していなくても、推測で人の問題として書きます。 所見はルールの見直しとして書かせます。

指示内容を固定する

あなたは研究所の研究企画室で、共用機器の利用の状況を設備の委員会に報告する立場です。
与えられた数字だけを使って判定してください。推測で埋めないでください。

【あなたの仕事】
機器ごとに、対応の区分を最大2つ選び、根拠にした数字を挙げ、
委員会で読める所見を書いてください。

【区分の選び方】
- add_capacity .... peak_booking_rate が 0.85 以上、unused_rate が 0.15 未満、
                     forecast_3m が今月の utilization より高い
- rule_change ..... booking_rate が 0.80 以上で、unused_rate が 0.25 以上
- maintenance_due . order_deadline が来月末までにある
- consolidate ..... 過去6か月の utilization がすべて 0.30 未満で、forecast_3m も 0.30 未満
- data_quality .... record_issues が 5 件以上
- no_action ....... どれにも当たらない
data_quality を選んだときは、他の区分を選ばないでください。
maintenance_due は他の区分と並べて選んでかまいません。

【厳守事項】
- 数字は入力の値をそのまま書いてください。計算し直さないでください。
- evidence には、根拠にした項目名と値を書いてください。
- 増設すべき、廃止すべきという結論を書かないでください。「検討の対象」と書いてください。
- 研究員や研究グループを特定する書き方をしないでください。
- 不具合のメモに無い故障や劣化を推測しないでください。
- 業者名や費用を書かないでください。
- 所見は機器ごとに3文以内にしてください。

【機器ごとの入力】{equipment_json}
【対象の月】{month}

区分の条件の数字は、指示の中ではなく機器の一覧のシートに置き、指示を組み立てるときに差し込みます。 委員会で線を変えたときに、指示の文を直さずに済みます。線が変わったことは、集計の記録に残します。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "month": "2026-09",
  "items": [
    {
      "equipment_id": "EQ-017",
      "categories": ["add_capacity", "maintenance_due"],
      "evidence": [ { "field": "peak_booking_rate", "value": "0.91" } ],
      "comment": "",
      "maintenance_note": ""
    }
  ]
}

1つ目の理由は、categories を enum で絞れることです。 区分が決まった値なら、四半期の委員会の前に「3か月続けて add_capacity が付いた機器」を記録から機械的に拾えます。委員会の資料の候補が、毎月の判定から自動でそろいます。

2つ目は、evidence を入力と突き合わせられることです。 スクリプトが field の値を前処理の値と比べ、違えばその機器の所見を捨てて、数字だけを一覧に載せます。

3つ目は、maintenance_note を別の項目にすることで、保守の一覧を分けて作れることです。 委員会の資料と、担当者が毎月見る保守の手配の一覧は、読む人も読む時期も違います。

スキーマに沿わない応答に備えます。 stop_reason が refusal や max_tokens のときは、出力がスキーマに沿わないことがあります。60台を1回で渡すと出力が長くなり、max_tokens で切れやすくなるので、10台ずつに分けて呼びます。

システムへ連携する

Claude API は UrlFetchApp.fetch で呼びます。 method を post、contentType を JSON にし、headers に API キーを入れます。muteHttpExceptions を true にして、失敗の応答でも例外で止めずに応答のコードを見ます。 API キーはスクリプトのプロパティに置きます。

カレンダーにも保守の台帳にも書き込みません。 保守を手配した日、交換した日を台帳に入れるのは担当者です。スクリプトが台帳を書き換えると、前回の実施日がずれて、次の見込みが狂います。

人が確認する

担当者が毎月見るのは、maintenance_due と data_quality の機器です。 他の区分は四半期ごとに委員会の資料にまとめるときに見ます。

1. maintenance_due を最初に見る … 手配の期限と、累計の稼働時間を確かめ、業者に連絡します
2. data_quality を次に見る … 利用の記録の点検の内容を見て、その機器を使う研究員に入れ方を確かめます
3. 所見の数字を確かめる … evidence の値が、一覧の数字と合っているかを見ます
4. 四半期ごとに委員会の資料にする … add_capacity、rule_change、consolidate が続いた機器を拾い、研究グループの声と並べます

1番目を後回しにしないでください。 手配の期限は、業者の手配にかかる日数から逆算した日です。期限を過ぎると、交換が寿命の後にずれ込みます。

区分を直したときは、直した理由を一言残します。 「記録の入れ忘れだった」「研究のテーマが終わった」といった理由がたまると、どの区分の線が実態に合っていないかが見えてきます。 委員会で線を見直す材料になります。

目標は、60台をならして1台5分です。 毎月の確認は保守と記録の点検の数台に時間を使い、残りは一覧の流し見です。四半期の資料の作成の時間も、ならして含めています。

例外に対処する

上から2行目までが、最初の数か月の大半を占めます。 どれもAIの問題ではなく、カレンダーの権限と、利用の記録の入れ方の問題です。 記録の入れ忘れが多い機器は、フォームを機器の横に置く場所から見直します。

記録を残す

• 機器ごとの当月の稼働率、予約率、使われなかった予約の割合、ピークの予約率、重なりの件数
• 次の3か月の見込み、保守の時期の見込み、手配の期限
• AIに渡した入力と、返ってきたJSONの全文
• 担当者が区分を直した記録
• 保守を手配した日と、実際に交換した日
• そのときの区分の線と、利用できる時間帯の設定

保守の見込みと実際の交換の日を並べて残すのは、見込みの当たり方を確かめるためです。 見込みより早く寿命が来た機器は、1日あたりの稼働時間の見方か、周期そのものを見直す材料になります。