農業法人の圃場ごとの作業日誌から、月の作業・資材の使用・生育の記録を要約し、農薬の使用回数の上限に近い圃場を拾う

処理の起点を決める

2つの時間主導型トリガーを使います。 1つ目は毎日21時に動く結び付けと回数の数え上げ、2つ目は毎月1日の朝に動く月の要約です。

毎日の処理を夜にするのは、その日の日誌がそろってからにするためです。 作業員は夕方に日誌を付けるので、21時ならほぼ出そろいます。知らせのメールは処理の終わりに送り、担当が翌朝に読む形です。

時刻はちょうどにはなりません。 公式のページでは、時間主導型トリガーの時刻は少しずれることがあり、9時に設定すると9時から10時の間のどこかで動くとされています。21時に設定すれば21時台のどこかで動きます。 夜の処理なので、ずれは問題になりません。

月の要約は、60枚を1回で回しません。 公式のページでは、スクリプトの1回の実行は6分までです。1回に15枚ずつ、1日の朝に4回に分けてトリガーを作ります。 処理した圃場を記録し、同じ月に二度要約しないようにします。

トリガーは会社の共用アカウントで作ります。 インストール型トリガーは常に作った人のアカウントで動き、失敗は所有者へのメールで届くとされています。担当の個人のアカウントで作ると、退職や異動で止まります。

入力データを集める

質を決めるのは、農薬の一覧の「別名」の列です。 作業員が書く「アファ」「前と同じ」を製品に結び付けるには、どの書き方がどの製品に当たるかを書いておく必要があります。 「前と同じ」は別名にできないので、結び付けできない行として返させます。

作期のシートの「指定種苗の使用回数」は、見落としやすい欄です。 農薬を使用する者が遵守すべき基準を定める省令の第2条第1項第5号では、使用した農薬の有効成分ごとの使用回数の表示がある種苗を使う場合、総使用回数からその表示された回数を差し引いた回数を超えて使わないこととされています。購入した苗の表示を、作期の初めにこの欄へ書き写します。

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

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

農薬の一覧のうち、AIに渡すのは製品ID・製品名・別名だけです。 有効成分や回数はAIに渡しません。回数の計算に使う値は、スクリプトが一覧から直接引きます。 AIに有効成分を渡すと、結び付けの理由に成分の話を書き始め、回数の判断に踏み込むことがあります。渡す情報を絞ること自体が、AIにさせることを限る方法です。

API のキーはスクリプトのプロパティに置きます。 コードに書くと、スプレッドシートを複製した人にもキーが渡ります。スクリプトを編集できる人は、生産管理の担当に限ります。

AIへ渡す前に整形する

1. 資材の欄を行ごとに分ける … 1行に「アファーム 2000倍、展着剤」のように複数書かれていれば、読点と改行で分けた候補をAIに渡します
2. 作物で一覧を絞る … その圃場の作物に登録のある製品だけを候補にします。登録の無い作物の製品と結び付いたら、それ自体を知らせるためです
3. 作期を引く … 作期のシートに無い圃場は、結び付けまで行い、回数は数えずに知らせます
4. 帳簿の項目を確かめる … 農薬の行について、日付・圃場・作物・製品・希釈倍数か使用量がそろっているかをスクリプトで確かめます
5. 月の要約のときは、行を日付順に並べる … 1か月分を圃場ごとに日付順にし、作業・資材・メモの列だけを渡します
6. 名前を外す … 「記録した人」の列はAIに渡しません

4番の項目は、省令の第9条に並ぶものです。 農薬を使用したときは、使用した年月日・場所・農作物・農薬の種類または名称・単位面積当たりの使用量または希釈倍数を帳簿に記載するよう努めなければならないとされています。日誌がその帳簿を兼ねるので、欠けた行をその日のうちに拾います。

AIに処理させる

毎日の処理でさせるのは、資材の書き方を製品に結び付けることだけです。

3行目が、この構成でいちばん大事な線引きです。 「前と同じ」を前回の防除の製品に結び付けると、たいていは当たります。ただ、外れたときに、数えるべき有効成分が数えられず、数えなくてよい成分が数えられます。 回数の表が信じられなくなるので、結び付けません。作業員に聞き直します。

月の要約でさせるのは、圃場ごとに3つの項目をまとめることです。

指示内容を固定する

あなたは農業法人の生産管理の担当を補助する立場です。
1つの圃場の1か月分の作業日誌と、スクリプトが集計した資材の使用回数をもとに、
月報の要約を書いてください。

【書く項目】
1. work_flow: 月の作業を日付順に3〜6行で。日誌に書かれた作業だけを書く。
2. inputs: 資材の使用。集計表の数字をそのまま写す。計算し直さない。
3. observations: メモの欄から、病害虫、生育、天候の影響の記述を拾い、
   内容ごとにまとめる。同じ内容が複数回あれば、その日付をすべて並べる。
   それぞれ、根拠にしたメモの言葉を quote に写す。
4. data_gaps: 要約を書くうえで足りなかったこと
   （メモが無い週、結び付けできなかった資材の行など）。

【厳守事項】
- 日誌に書かれていない作業、資材、観察を書かないでください。
- 病害虫の原因を推定しないでください。防除の提案をしないでください。
- 農薬を使ってよいか、使用回数が上限に達しているかを書かないでください。
  回数の判断はスクリプトが別に行います。
- 収穫の時期や可否について書かないでください。
- 「少し」「ちらほら」などのメモの量の表現は、言い換えずにそのまま写してください。
- work_flow は1行40字以内。です・ます調は使わず、体言止めで書いてください。

【圃場と作物、作期の開始日】{field_info}
【1か月分の作業日誌（日付順）】{diary_rows}
【スクリプトが集計した資材の使用回数と量】{input_summary}
【結び付けできなかった資材の行】{unmatched_rows}

「同じ内容が複数回あれば、その日付をすべて並べる」が、第3章の（c）への対策です。 「アブラムシちらほら」が3回あれば、月報の所見に3つの日付が並びます。1回だけのメモと、続いているメモの違いが、担当に一目で分かります。

「原因を推定しない」を書くのは、生成AIが「黄化は窒素不足の可能性」のように続けがちだからです。 その一文が月報に残ると、確かめていない見立てが栽培の記録として取引先に出ていくことになります。

出力形式を固定する

月の要約は、次の形のJSONで受け取ります。 Claude API の構造化出力で、output_config.format に JSON Schema を渡します。

{
  "field_id": "",
  "month": "",
  "work_flow": [""],
  "inputs": [
    { "product_id": "", "times": 0, "amount": "" }
  ],
  "observations": [
    { "topic": "pest | growth | weather | other",
      "summary": "", "dates": [""], "quote": "" }
  ],
  "data_gaps": [""]
}

1つ目の理由は、inputs をスクリプトの集計と照らせることです。 AIが写した回数と、スクリプトの集計が1つでも違えば、その圃場の月報に「要確認」の印を付けます。 AIが数字を書き換えたことを、機械的に見つけられます。

2つ目は、observations の dates で繰り返しが分かることです。 日付が3つ以上並んだ所見は、月報の先頭に出します。

毎日の結び付けは、row_id、product_id、match（matched ／ unmatched ／ ambiguous ／ not_pesticide）、dilution、amount の形で受け取ります。 公式のページでは、構造化出力の schema では minimum・maximum のような数値の制約が使えないとされているため、希釈倍数が一覧の範囲に入っているかはスクリプトで確かめます。

回数の表は、AIを通さずスクリプトが作ります。

残りが1以下の行は、翌朝の知らせの先頭に出します。 製品ごとの使用回数も同じ形の表にします。

システムへ連携する

日誌の資材の欄そのものは書き換えません。 作業員が書いた元の文字は残し、結び付けた製品は別の列に書きます。 担当が作業員に確かめて直すときも、別の列を直します。

翌朝の知らせには、3つの一覧を書きます。 残りが1回以下の圃場と有効成分、結び付けできなかった行、帳簿の項目が欠けた行です。何も無い日は「該当なし」と1行だけ送ります。 送られてこない日があれば、処理が止まっていることが分かります。

人が確認する

1. 翌朝、結び付けできなかった行を作業員に確かめる … 「前と同じ」が何だったかを聞き、結び付けた製品の列を直します。その日のうちに聞けば、本人が覚えています
2. 残りが1回以下の圃場を責任者に伝える … 次の防除で使う製品を、有効成分が重ならないものに変えるかを責任者が決めます
3. 帳簿の項目が欠けた行を直す … 希釈倍数や使用量を作業員に聞いて書き足します
4. 月報の要約を読む … inputs の「要確認」の印と、observations の繰り返しを先に見ます
5. 所見を直して責任者に渡す … 現場で見たことを足し、取引先に出す版を作ります

1番を翌朝に行うのが、この設計の要です。 月末にまとめて聞くと、（d）のとおり本人も覚えていません。毎日の結び付けは、聞き直しを早めるための仕組みでもあります。

目標は、月報1枚あたり10分です。 要約を読む時間、回数の表と未確認の行を見る時間、所見を直す時間が中心です。observations の繰り返しが多い圃場は、所見を直す時間が長くなります。 逆に、作業が少なくメモの無い月の圃場は数分で終わります。

作業員への聞き直しは、責めない形で行います。 「前と同じ」と書くのは、忙しい夕方に急いで付けているからです。聞き直しが続く作業員には、よく使う製品の別名を一覧に足すか、フォームの資材の欄に例を書いておくほうが効きます。

農薬の一覧の値は、担当が年に数回見直します。 登録の内容は変わることがあり、一覧が古いと、スクリプトの回数の表も古い基準で数えられます。

例外に対処する

3行目は、頻度は低くても見落とせない行です。 登録の無い作物に使った可能性があるので、数え上げの結果より先に、担当と責任者が確かめます。 多くは圃場の番号か作物の書き間違いですが、それを確かめるのも人の仕事です。

記録を残す

• 日誌の元の行（作業員が書いたまま）
• 結び付けの結果（製品ID、match、希釈倍数）と、担当が直した記録
• 回数の表の日ごとの写し（作期の初めから）
• 月の要約の JSON の全文と、担当が直した月報
• 農薬の一覧の版（いつ、どの値を直したか）
• 翌朝の知らせの写し

回数の表を日ごとに残すのは、後から「その日の時点で何回だったか」を示すためです。 取引先から栽培の記録を求められたとき、ある防除の時点での回数を、そのときの一覧の版とあわせて出せます。