研究員が入力するテーマ別の工数を毎月集計し、計画との差が大きいテーマと理由の候補を研究開発の管理者に要約して届ける

処理の起点を決める

集計は、毎月3日の8時台に動く時間主導型のトリガーを起点にします。 ScriptApp.newTrigger() に timeBased()・onMonthDay(3)・atHour(8) を続けて作ります。動くと、前の月の1日から末日までの回答を読みます。

3日にするのは、入力の締めを待つためです。 研究員の入力は毎週金曜ですが、月末の週の分は翌月の最初の金曜まで入らないことがあります。1日に集計すると、月末の数日分が抜けた数字で差を出すことになります。 研究所の決まりとして「月末の週の分は翌月2日までに入力」と定め、3日の朝に集計します。

3日が土日に当たる月も、そのまま動かします。 集計とメールは人の手を要さず、グループ長が週明けに読めば足ります。 祝日の多い月だけ日をずらす、という運用にすると、ずらし忘れが起きます。

週が月をまたぐときの扱いを決めておきます。 フォームの「週」は週の始まりの月曜の日付で入るので、月曜が前の月なら前の月の分として数えます。日割りはしません。計画工数も同じ決まりで立てていれば、差は月の境目でずれません。

集計のやり直しは、手動の実行で行います。 入力の遅れがあとから届いたときは、研究企画がスクリプトのメニューから「前月を再集計」を実行します。再集計ではメールを送らず、一覧のシートだけを書き換えます。 同じ要約が二度届くと、どちらが新しいかで迷うからです。

入力データを集める

質を決めるのは、作業メモです。 AI が理由の候補を出せるのは、メモに手がかりがあるときだけです。メモが空の行ばかりのテーマは、「メモからは分からない」としか返りません。 第12章でも扱いますが、作業メモの欄に「予定と違ったことがあれば一言」という説明を書き添えるだけで、手がかりの量は変わります。

前の月の一覧を渡すのは、続いている差を見分けるためです。 2か月続けて同じ理由で遅れているテーマは、一時的な遅れではありません。前の月にグループ長が書いた理由を添えると、AI は「先月から続く装置待ち」のように、続いていることを要約に書けます。

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

シートは実行の最初に getValues() でまとめて読みます。 1行ずつ読むと、回答が月に1,500行を超えるこの規模では遅くなります。公式の割り当てでは、1回の実行は6分までです。読み込みと集計は数秒で終わりますが、AI の呼び出しが入るので、時間を食う処理を減らしておきます。

処理は、次の順で行います。

1. 前の月の回答を読み、テーマコードを正規化する（全角・半角、廃止コードの読み替え）
2. テーマ別に合計し、テーマ計画の計画工数と並べる
3. 差の比率と時間数の両方が閾値を超えたテーマに flag を立てる（R1）
4. 計画が0なのに実績があるテーマ、状態が「終了」なのに実績があるテーマを拾う（R2）
5. 研究員ごとの月の合計を所定の時間と比べ、少なすぎる人を入力漏れの疑いとする（R3）
6. flag の立ったテーマの作業メモを、グループごとにまとめる
7. グループごとに Gemini API を呼び、JSON を受け取る（失敗したら数字だけで送る）
8. 集計の一覧のシートに書き、グループ長ごとにメールを送る

3番目で比率と時間数の両方を見るのが、第3章の（b）への答えです。 比率だけだと小さなテーマに毎月 flag が立ち、時間数だけだと大きなテーマの小さなずれを拾います。たとえば「比率20％以上、かつ差が16時間以上」のように両方を満たすものだけにすると、研究企画が目で外していた分が規則になります。

7番目は、テーマごとではなくグループごとに呼びます。 差の大きいテーマが月に15〜20件あるとして、テーマごとに呼ぶと実行時間が6分に近づきます。グループごとなら呼び出しは6回で済みます。 それでも6分を超えそうなときは、終わったグループをスクリプトのプロパティに記録し、数分後に続きを動かすトリガーを作って残りを処理します。

7番目で AI が失敗しても、メールは送ります。 差の数字と入力漏れの疑いは規則だけで決まります。要約の欄を「生成に失敗。メモは一覧のシートを参照」として送り、研究企画にだけ失敗を知らせます。

AIへ渡す前に整形する

1. 研究員の番号を外す … AI に渡すのは、テーマコード、週、時間数、作業メモだけです。誰のメモかは渡しません
2. メモに番号を振る … 「M-0412」のように、行ごとに番号を付けて渡します。AI には根拠をこの番号で返させます
3. 空のメモを数える … 作業メモが空の行は渡さず、空の行の数と時間数の合計だけを添えます
4. 作業名だけのメモを分けない … 「評価」「合成」のような短いメモもそのまま渡します。どの作業に時間が寄ったかの手がかりになります
5. 数字は規則で計算したものを渡す … 計画工数、実績、差、比率は、スクリプトで計算した値を渡します。AI に計算させません
6. 前の月の理由を添える … 前の月にグループ長が書き込んだ理由を、テーマごとに1つ添えます

1番目で研究員の番号を外すのは、第1章で書いたとおり、個人の評価に使わないためです。 番号を渡すと、AI は「特定の研究員の工数が他テーマに流れている」のような人に紐づいた要約を書きます。それが一覧に載れば、グループ長の手元で評価の材料になってしまいます。テーマの単位で要約させるには、人の手がかりを最初から渡さないのが確実です。

5番目は、AI に数字を作らせないためです。 差や比率を AI に計算させると、要約の中の数字と一覧の数字が食い違うことがあります。数字は規則が出し、AI はその数字を言い換えずに引用するだけにします。

AIに処理させる

させるのは、差の大きいテーマごとに、作業メモから差の理由の候補を要約し、根拠のメモと理由の区分を付けることです。

理由の区分は、研究企画が決めた語彙から選ばせます。 装置待ち、試料・材料の入荷待ち、外部の委託・分析の待ち、やり直し、他テーマの応援、計画の見込み違い、テーマの前倒し、メモからは分からない、の8つです。区分をそろえると、第3章の（d）で書いた「同じ装置待ちが3つの別々の理由に見える」問題が消えます。 運営会議では、区分ごとの件数をまず見られます。

3行目と6行目が、この構成でいちばん守るべきことです。 工数が計画を大きく下回るテーマを渡すと、AI は親切に「優先度の見直しを検討してはどうか」と書き足しがちです。テーマの継続の話は、研究の見込みや事業の都合で決まるもので、工数の差だけで出せる結論ではありません。 スキーマに提案を書く欄を作らず、指示でも禁じます。

指示内容を固定する

あなたは研究所の研究企画の担当として、研究テーマの工数が計画と大きく
ずれた理由の「候補」を、研究員の作業メモから整理する立場です。
研究の良し悪し、研究員の働きぶり、テーマを続けるべきかは判断しません。

【入力】
- 各テーマについて：テーマコード、計画工数、実績工数、差、比率（計算済み）
- そのテーマの、前の月の作業メモ（memo_id 付き）
- メモが空だった行の数と、その時間数の合計
- 前の月にグループ長が書いた理由（無い場合もある）

【してほしいこと】
1. メモの中から、計画とずれた理由の手がかりになる記述を探す
2. 理由の候補を1〜3つ、各80字以内で書く
3. 各候補に、根拠にした memo_id を必ず付ける
4. 各候補に、次の区分から1つを付ける
   equipment_wait / material_wait / outsource_wait / rework /
   support_other / plan_mismatch / ahead_of_plan / unknown
5. 前の月の理由と同じ種類の理由が今月も続いていれば continuing を true にする

【厳守事項】
- メモに書かれていない理由を推し量って書かないでください。
  手がかりが無ければ、区分を unknown にし、候補の本文は
  「メモからは理由が分かりません」としてください。
- 根拠の memo_id が付けられない候補は書かないでください。
- 数字は入力の値をそのまま使い、計算し直したり丸めたりしないでください。
- テーマを止める・続ける・人を移すなどの提案を書かないでください。
- 特定の人の働き方についての記述を書かないでください。
- メモが空の行が多いことは、空の行の数として事実だけを書いてください。
  「記録が不十分」などの評価を書かないでください。

【テーマ】{themes_json}

「根拠の memo_id が付けられない候補は書かない」が、推し量りを止める仕掛けです。 推し量りを禁じるだけでは、AI は「一般に材料系の研究では装置の確保がボトルネックになりやすく」のようなもっともらしい一般論を候補に入れます。根拠の番号を必須にすると、一般論には付ける番号が無いので、候補から消えます。

unknown の本文を決めた文言にしているのは、一覧で目に付くようにするためです。 グループ長が読むとき、メモから分からないテーマこそ自分で聞きに行くべきテーマです。言い回しが毎回変わると、読み飛ばされます。

出力形式を固定する

構造化出力で、次の形の JSON を受け取ります。

{
  "group": "",
  "themes": [
    { "theme_code": "",
      "direction": "under | over",
      "candidates": [
        { "reason": "",
          "category": "equipment_wait | material_wait | outsource_wait | rework | support_other | plan_mismatch | ahead_of_plan | unknown",
          "memo_ids": [""],
          "continuing": false }
      ],
      "empty_memo_rows": 0 }
  ]
}

スキーマでは category と direction を enum で縛り、memo_ids を required にします。memo_ids に入った番号が、渡したメモの番号に本当にあるかは、受け取ったあとにスクリプトで確かめます。 無い番号が返った候補は、一覧に載せる前に落とし、研究企画に知らせます。

理由の1つ目は、数字と文を別の層に置けることです。 計画・実績・差・比率は一覧のシートの列に規則が書き、AI の JSON には数字を返させません（empty_memo_rows は渡した値をそのまま返させ、照合に使います）。要約の文の中の数字と列の数字が食い違う、という事故が起きません。

2つ目は、区分で集計できることです。 category の件数をグループごと、研究所の全体で数えると、「今月は装置待ちが7テーマ」のような見出しが運営会議の資料の最初に置けます。

3つ目は、continuing で続いている差を拾えることです。 2か月以上続く装置待ちは、グループ長のレベルでは解けない問題であることが多く、研究所として装置の増設や予約の決まりを見直す材料になります。

グループ長に届くメールは、一覧の該当する行をそのまま文にしたものです。

【今月の工数の差：第2グループ（4テーマ）】
■ T-2207 計画120h／実績78h（−35.0％）
  候補1［装置待ち・先月から継続］評価装置の予約が取れず、耐久試験の開始が遅れた
       根拠：M-0412、M-0433、M-0457
  メモが空の行：6行（18h）
■ T-2215 計画40h／実績64h（+60.0％）
  候補1［やり直し］合成の収率が出ず、条件を変えて再合成を3回行った
       根拠：M-0501、M-0518
※ 理由は作業メモからの候補です。確かめて一覧の「確認した理由」に書き込んでください。

システムへ連携する

API キーは、スクリプトのプロパティに置きます。 コードに書くと、スクリプトを開ける人すべてにキーが見えます。公式の割り当てでは、URL Fetch の呼び出しはGoogle Workspace のアカウントで1日10万回、MailApp の宛先は1日1,500で、月に一度、数十通を送るこの構成では余裕があります。

回答のシートとテーマ計画には書き込みません。 書き込むのは集計の一覧のシートだけで、グループ長が理由を書き込む列は、スクリプトが上書きしない列として分けます。再集計で数字の列を書き換えても、グループ長の書き込みは残ります。

人が確認する

グループ長が見るのは、自分のグループの flag の立ったテーマだけです。 1グループあたり月に2〜4テーマです。

1. 候補と根拠のメモを読む … 根拠の番号のメモを一覧から開き、候補の要約がメモと合っているかを見ます
2. unknown のテーマは自分で聞く … テーマリーダーに直接聞きます。ここだけは、今までと同じ時間がかかります
3. 確認した理由を書き込む … 候補をそのまま使ってよいなら写し、違えば書き直します。区分も直せます
4. 入力漏れの疑いの人に声をかける … 疑いは研究企画からグループ長に届きます。数字を直すのは研究員本人です

研究企画は、確認した理由の列が埋まったかを月の5日に見ます。 埋まっていないグループにだけ声をかけ、運営会議の資料には確認した理由だけを載せます。 AI の候補のまま会議に出すことはしません。

目標は、テーマ1件をならして10分です。 flag の立たないテーマは数字を見るだけで、立ったテーマは候補の確認に数分、unknown は聞き取りで数十分です。unknown が多い月は、作業メモの書き方を見直す合図になります。

例外に対処する

4行目の注記を省かないでください。 入力漏れの人が担当するテーマは、実績が計画を下回って見えます。漏れのせいで flag が立ったテーマに、AI が「装置待ち」のような理由を付けてしまうと、二重に誤ります。 一覧には「このテーマの研究員のうち1名に入力漏れの疑い」と出し、グループ長が先に入力を確かめるようにします。

記録を残す

• 集計の一覧のシート：月ごとのタブに、テーマごとの計画・実績・差・比率、flag、AI の候補、グループ長が確認した理由
• AI に渡したメモの番号の一覧と、返った JSON の全文（月ごとのログのシート）
• その月に使った閾値（比率・時間数・入力漏れの割合）
• 再集計の実行日時と、誰が実行したか
• メールの送信日時と宛先

「その月に使った閾値」を残すのは、閾値が運営会議で変わるためです。 閾値を下げた月は flag の数が増えます。閾値の変化を残していないと、「今月は遅れたテーマが多い」のか「線を下げただけ」なのかが分かりません。

AI の候補とグループ長の確認した理由を並べて残すと、半年後に候補の当たり外れが分かります。 区分を直された割合が高い区分は、指示の書き方か区分の定義のほうを見直します。