生産日報の稼働・停止・不良の記録を月次で集計し、設備ごとの稼働率と停止理由の上位、前月からの変化を説明するコメントの下書きを工場長への報告にする

処理の起点を決める

毎月2日の6時台に、月1回の時間主導型のトリガーで動かします。 ScriptApp.newTrigger で作るトリガーに、onMonthDay(2) と atHour(6) を指定します。時刻は1時間の幅の中で選ばれます。 9時のトリガーなら9時から10時の間のどこかで動き、その時刻が毎回保たれるとされています。月報の締め切りに対して分単位の正確さは要らないので、この幅で足ります。

1日ではなく2日にするのは、月末の夜勤の日報を待つためです。 2直の工場では、月末の夜勤の日報が翌月1日の朝に入ります。1日の朝に動かすと、最後の夜勤が集計から漏れます。 入力の遅れが多い工場なら、3日にずらします。

60台を1回の実行で処理しきれない場合に備えて、続きから動けるようにします。 1回の実行は6分までです。集計そのものは数十秒で終わりますが、Gemini API を60回呼ぶと、応答の待ち時間で6分を超えることがあります。 設備ごとに「処理済」の印を集計のシートに残し、5分を過ぎたら止めて、10分後に動く1回限りのトリガーを作って続きから動かします。 全台の処理が終わったら、その1回限りのトリガーを消します。

トリガーの実行時間には、1日の合計の上限もあります。 個人の Google アカウントでは1日90分、Google Workspace では1日6時間です。月1回の処理なので上限には遠いのですが、同じアカウントで毎日動く別のスクリプトがあれば、合わせた時間で考えます。

入力データを集める

質を決めるのは、停止の自由記述です。 コードが「設備故障」だけでは、AIは「設備故障が増えた」としか書けません。「ヒーターの温度が上がらず再起動」と書かれていれば、同じ症状が何回あったかを拾えます。 班長に、症状・処置・再発かどうかの3つを書く書き方の例を配っておきます。

前月の集計は、スクリプトが毎月書く集計のシートから読みます。 前月の月報のコメントを読み返す必要はありません。比べるのは数字だけで、前月のコメントはAIに渡しません。 前月のコメントを渡すと、その言い回しを引き継いで、今月の記述に無い理由を書くことがあります。

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

日報の回答のシートを SpreadsheetApp で開き、前月の1日から末日までの行だけを、日付の列で絞って読みます。 月に約2,400行なので、シートの値をまとめて読み、スクリプトの中で設備ごとに分けます。

稼働率と良品率は、スクリプトの1か所で計算します。

この表の決め方は、自社の定義に合わせて書き換えてください。 大事なのは、決め方がスクリプトの1か所にあり、毎月同じ式で計算されることです。担当者ごとに分母が違う、という第3章（a）の問題は、ここで消えます。

API キーは、スクリプトのプロパティに置きます。 スクリプトのプロパティは、そのスクリプトの利用者全員が読める、アプリ全体の設定の置き場です。スクリプトの編集者を生産管理課の管理者に限り、コードの中にキーを書きません。

AIへ渡す前に整形する

1. 入力漏れの確認 … 設備×日×直で日報が無い組み合わせを数え、集計のシートに書きます
2. 時間の矛盾の確認 … 停止の時間の合計が計画の稼働時間を超える行は、集計から外して印を付けます
3. 未定義のコードの確認 … コード表に無い理由のコードは「その他」にまとめ、件数を残します
4. 自由記述の絞り込み … AIに渡すのは、計画停止以外の停止の記述だけにします。1台あたり最大60件、長いものは先頭の200字にします
5. 知らせる幅の判定 … 稼働率の前月との差が、設備の一覧の幅を超えたかどうかを、スクリプトで決めておきます

1番目の結果は、AIにも渡します。 日報の入力漏れが多い設備は、稼働率が上がって見えることがあります。 停止の記録が無ければ、停止が無かったことになるからです。入力漏れの数を渡し、「入力漏れが多く、数字の比較に注意」と書けるようにします。

5番目をスクリプトで決めるのは、AIに「大きな変化かどうか」を判断させないためです。 同じ3ポイントの低下を、AIは設備によって「大きく低下」とも「わずかに低下」とも書きます。幅を超えたかどうかの印をスクリプトが付け、AIはその印に合わせて書きます。

AIに処理させる

させるのは、設備ごとに、計算済みの数字の動きと、停止の記述から読み取れる理由を、3文以内のコメントに要約することです。

2行目がいちばん起きやすい失敗です。 「設備故障」の停止が増えた設備を渡すと、AIは「経年による劣化が進んでいる可能性があります」と書き足します。それらしい推し量りは、工場長が保全の順番を決めるときの材料にされてしまいます。 記述に無いことは書かせず、根拠の記述が無い理由は、理由の欄を空にさせます。

指示内容を固定する

あなたは工場の生産管理課で、工場長への月報に載せる設備ごとのコメントを書く立場です。
次の集計の数字と、停止の記述だけを根拠に書いてください。推測で補わないでください。

【設備】{equipment_name}（{plant}・{equipment_type}）
【集計（前月 → 今月）】
稼働率：{availability_prev}% → {availability}%（差 {availability_diff} ポイント）
良品率：{yield_prev}% → {yield}%（差 {yield_diff} ポイント）
停止の理由の上位（今月）：{top_reasons}
停止の理由の上位（前月）：{top_reasons_prev}
知らせる幅を超えたか：{over_threshold}
日報の入力漏れ（設備×日×直）：{missing_reports}件

【今月の停止の記述（計画停止を除く）】
{downtime_notes}

【書き方】
- category は improved / worsened / flat / caution のどれか1つ。
  over_threshold が false なら flat、入力漏れが5件以上なら caution にしてください。
- summary には、動いた数字を上の値のまま書いてください。数字を計算しないでください。
- reason には、停止の記述に2回以上出てくる症状や処置を書いてください。
  当てはまるものが無ければ空にしてください。
- evidence には、reason の根拠にした記述を、日付・直・本文のまま3件まで写してください。
- コメント全体は3文以内。

【厳守事項】
- 停止の記述に書かれていない原因を書かないでください。
  「劣化」「老朽化」「可能性があります」のような推し量りをしないでください。
- 保全の方法、部品の交換、生産計画の変更などの対策を書かないでください。
- 日報を記録した人や班を評価しないでください。

「上の値のまま書く」と「計算しない」を両方書くのは、AIが差を計算し直すからです。 「82.4%から78.9%へ」と渡すと、自分で引き算をして「3.6ポイント低下」と書くことがあります。差もスクリプトが計算した値を渡し、そのまま写させます。

「2回以上出てくる」を条件にしているのは、1回きりの出来事を月の傾向として書かせないためです。 1回の停電が理由として書かれると、工場長は毎月の問題と受け取ります。

出力形式を固定する

response_format の schema に、次の形を指定します。

{
  "equipment_id": "M-12",
  "category": "worsened",
  "summary": "稼働率が82.4%から78.9%に下がり（差 -3.5ポイント）、停止の理由の1位が金型交換から設備故障に変わった。",
  "reason": "中旬以降、ヒーターの温度が上がらず再起動した記述が4回ある。",
  "evidence": [
    { "date": "2026-09-14", "shift": "2直", "note": "ヒーター温度上がらず再起動 40分" }
  ]
}

1つ目の理由は、category を enum で4つに絞れることです。 月報の表で区分ごとに色を付け、工場長は worsened の設備から読めます。

2つ目は、summary の数字を照らし直せることです。 スクリプトが summary から数字を取り出し、集計の値と一つずつ比べます。集計に無い数字が1つでも入っていれば、そのコメントに「数字の不一致」の印を付けます。

3つ目は、evidence で根拠をすぐに確かめられることです。 担当者は日報のシートを開かずに、どの記述から理由が書かれたかを読めます。

月報のシートは、次のような並びにします。

システムへ連携する

Gemini API の呼び出しは UrlFetchApp.fetch で行います。 method を post、contentType を application/json にし、headers に API キーのヘッダー（x-goog-api-key）を入れます。muteHttpExceptions を true にすると、失敗の応答でも例外を投げずに応答を返すので、応答コードを見て再試行するかどうかを決められます。

複数の設備をまとめて呼ぶなら、UrlFetchApp.fetchAll を使えます。 複数のリクエストを配列で渡し、それぞれの応答を配列で受け取ります。10台ずつまとめると、6分の上限の中で処理できる台数が増えます。 1日の URL Fetch の回数の上限（個人のアカウントで2万回、Workspace で10万回）には、月60回では遠く及びません。

工場長へのメールは、課長が「確認済」にした後にだけ送ります。 月報のシートの確認の列がすべて埋まったことを、毎日動く小さなトリガーで確かめ、埋まった日に1回だけ送ります。送ったら、送った日を集計のシートに書き、二度送らないようにします。 メールの1日の送信先の数にも上限があり、個人のアカウントで100、Workspace で1,500です。

人が確認する

生産管理課の担当は、月報のシートの印の付いた行から見ます。

1. 「数字の不一致」の印 … コメントの数字を集計の値に直します。直せないほど食い違うなら、コメントを書き直します
2. worsened の設備 … evidence の記述を読み、理由が設備の実情と合っているかを確かめます。保全の担当に一言聞けば分かることは聞きます
3. caution の設備 … 入力漏れの多い設備です。数字そのものを信じてよいかを、班長に確かめます
4. flat と improved の設備 … 流し見て、違和感があるものだけ開きます

2番目を省かないでください。 工場長は、悪化した設備のコメントを読んで保全の順番を決めます。日報の記述に書かれた症状が、本当の原因の手前の症状であることは珍しくありません。 設備を知っている人の一言を足すだけで、コメントの重みが変わります。

直した内容は、確認の列の横に「直した」と残します。 月に何件直したか、どの区分で直したかを見れば、指示のどこを直すべきか、日報の書き方のどこを直すべきかが分かります。

例外に対処する

最後の行を軽く見ないでください。 トリガーの失敗の知らせは、トリガーを作ったアカウントに届きます。 共有の管理用アカウントのメールを誰も見ていないと、月報が作られていないことに締め切りの日まで気づきません。

記録を残す

• 実行した日時、対象の月、処理した設備の数と、処理できなかった設備
• 設備ごとの集計の数字（集計のシート。翌月の比較に使う）
• Gemini API に送った内容と、返った JSON の全文
• 数字の照らし直しの結果と、付けた印
• 担当者が直した内容と、確認した人
• 工場長へ送った日時

2つ目の集計のシートは、消さずに積み上げます。 翌月の比較の元になるだけでなく、半年分の稼働率の推移を、いつでも同じ定義で見返せます。