顧問先から届くメールから期限のある依頼を拾ってタスク表に載せ、期限の近いものを毎朝担当者に知らせる

処理の起点を決める

時間主導型のトリガーを2本使います。 1本目は平日の毎時に動き、新しいメールから依頼を拾います。2本目は平日の朝8時台に1回動き、担当者ごとの一覧を送ります。

時間主導型のトリガーは毎分から月1回まで指定できますが、実行時刻は少しばらつきます。 9時のトリガーなら9時から10時の間で時刻が選ばれ、以後はその時刻で続くとされています。朝の一覧が8時ちょうどに届く必要はないので、この幅で困ることはありません。

メールが届いた瞬間に処理しないのは、顧問先がメールを続けて送ってくるからです。 「先ほどの件、期限は25日でした」と10分後に訂正が来ることがあります。1時間分をまとめて同じスレッドとして読むほうが、期限の取り違えが減ります。

1回の実行で処理するのは、最大30スレッドまでにします。 1回の実行は6分が上限です。生成AIの呼び出しを含めると1スレッドに数秒かかるため、余裕をみて件数で止め、残りは次の回に回します。 未処理のラベルで区別しているので、取りこぼしは起きません。

入力データを集める

質を決めるのは、顧問先台帳の差出人アドレスです。 顧問先の経理担当者が替わると、知らないアドレスからメールが来ます。台帳に無い差出人は、AIに回す前に「顧問先不明」として総務へ回します。 推測で顧問先を当てると、別の会社の依頼が別の担当者のタスクに載ります。

未完了のタスクを渡すのは、同じ依頼の二重登録を避けるためです。 顧問先は、返事がないと同じ依頼をもう一度送ってきます。既存の行と同じ依頼なら、新しい行を作らずに「再依頼あり」の印を付けます。 催促されたという事実は、それ自体が担当者に知らせるべき情報です。

添付ファイルは中身を読みません。名前だけを渡します。 「源泉所得税納付書.pdf」という名前は、依頼の中身を補う手がかりになります。中身を読む必要がある書類の仕分けは、UC-0072 の構成の役目です。

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

検索の条件には、Gmail の検索演算子を使います。 処理済みのラベルを除くには -label: を、期間を絞るには newer_than:2d を付けます。期間を絞るのは、ラベルの付け忘れで古いスレッドを延々と読み直さないためです。

処理が終わったスレッドには、ラベルを付けます。 ラベルは createLabel() で一度作り、以後は getUserLabelByName() で引きます。ラベルを付けるのは、タスク表への追記が成功したときだけにします。 途中で失敗したスレッドはラベルが無いまま残り、次の回にもう一度処理されます。

APIキーはスクリプトに書かず、スクリプトのプロパティに置き、 PropertiesService.getScriptProperties() で読みます。編集権限を持つ人は、専用アカウントの管理者に絞ります。

AIへ渡す前に整形する

1. 差出人で顧問先を決める … 差出人のアドレスを台帳で引き、無ければドメインで引きます。どちらにも無ければ「顧問先不明」です
2. 事務所の自分のメールを除く … スレッドの中の事務所側の返信は、依頼の取り出しには使いません。ただし「承知しました、25日までに」と返した文は、期限を確かめる手がかりとして別に渡します
3. 引用部分を落とす … 行頭の > や「〜様のメッセージ」以下の引用を落とします。落とさないと、前のメールの依頼を新しい依頼として拾います
4. 署名とあいさつを落とす … 署名の区切り線以下と、「いつもお世話になっております」のような定型の文を落とします
5. 長さを確かめる … 長すぎる本文は決めた長さで切り、「途中で切った」印を付けます

3番目を軽く見ないでください。 顧問先は返信のたびに前のメールを全文引用して送ってきます。引用を残したままにすると、1か月前に済んだ依頼が毎回「新しい依頼」として載ります。

AIに処理させる

させるのは、本文から依頼を1件ずつ取り出し、決めた項目を埋めることだけです。

2行目の「やるのは誰か」が、第1章で書いた中心です。 顧問先が「月末までに送ります」と書いたものは client で、担当者の朝の一覧には入れず、「届くはずのもの」の一覧に載せます。 期限を過ぎても届かなければ、そのとき担当者に知らせます。

期限の日付化はAIにさせません。 AIには期限の原文と書かれ方だけを返させ、relative のものはスクリプトの側で受信日と休業日表から日付に直します。「月末」の解釈を毎回AIに任せると、受信日をどう扱ったかが記録に残りません。 規則で直せない言い方（「例の件の期限までに」）は、日付を空欄のまま担当者に回します。

1行目がいちばん起きやすい失敗です。 「年末調整の資料、送りました」というメールから、AIは年末調整の期限を知識で補って載せようとします。書かれていない期限が一覧に並ぶと、担当者はそれを顧問先の希望と取り違えます。

指示内容を固定する

あなたは税理士事務所で、顧問先から届いたメールを読み、
事務所や顧問先が「いつまでに何をするか」を取り出す係です。
下のメール本文だけを根拠にしてください。推測で埋めないでください。

【取り出すもの】
メールに含まれる依頼・約束を1件ずつ、requests の配列に入れてください。
依頼・約束が1件も無いメールなら、requests は空の配列にしてください。

【各項目の決め方】
- kind: submit / procedure / answer / send_material / other
- summary: 何をするのかを1文で。本文の言葉を使ってください
- actor: office（事務所に頼んでいる）/ client（顧問先が自分でやると言っている）
         / unknown（どちらか本文から決められない）
- due_text: 期限の言い方を本文からそのまま写す。書かれていなければ空文字
- due_kind: explicit（日付が書かれている）/ relative（月末・来週中など）
            / none（期限が書かれていない）
- evidence: 依頼と期限の根拠にした文を、本文からそのまま写す
- relation: new / repeat_of:{既存タスクID}

【厳守事項】
- 期限が書かれていなければ due_text は空、due_kind は none にしてください。
  手続きの種類から、法律や慣習上の期限を補わないでください。
- due_text を日付に直さないでください。「月末」は「月末」のまま写してください。
- 「よろしくお願いします」だけで何を頼んでいるか分からないものは、
  kind を other、summary に原文を写してください。
- 資料を送ったという報告だけで、事務所への依頼が無いものは取り出さないでください。
- 引用されている過去のメールの内容は、依頼として取り出さないでください。
- 既存タスクと同じ依頼なら relation を repeat_of にし、新しく作らないでください。
- 顧問先名や担当者名を本文から推測して書かないでください。

【顧問先】{client_name}（台帳で照合済み）
【受信日時】{received_at}
【添付ファイルの名前】{attachment_names}
【この顧問先の未完了のタスク】{open_tasks}
【本文】{body}

「手続きの種類から期限を補わない」を明記しないと、AIは親切に補います。 役員報酬の変更、従業員の入社といった言葉には、AIが知っている期限が結び付いています。禁じるのは、本文の外から期限を持ち込むことそのものです。

「日付に直さない」も同じ考え方です。 直すこと自体は難しくありませんが、受信日が金曜の夕方だった「来週中」をどう読むかは、事務所で決める規則です。AIの中で黙って決めさせず、スクリプトの規則に置きます。

出力形式を固定する

Gemini API の構造化出力で、次の形のJSONを受け取ります。 構造化出力では、応答の形式を application/json とし、JSON Schema を渡します。返るJSONは構文として正しいものになりますが、値はアプリケーション側で確かめるよう公式も書いています。

{
  "message_id": "",
  "client_code": "",
  "requests": [
    {
      "kind": "submit | procedure | answer | send_material | other",
      "summary": "",
      "actor": "office | client | unknown",
      "due_text": "",
      "due_kind": "explicit | relative | none",
      "evidence": "",
      "relation": "new | repeat_of:T-0000"
    }
  ]
}

JSONで受け取る1つ目の理由は、タスク表の列にそのまま入れられることです。 自由文で返させると、「期限：来週中（たぶん金曜）」のような書き方が混ざり、列に分けられません。

2つ目は、actor と due_kind で振り分けを規則にできることです。

3つ目は、evidence で確認が速くなることです。 担当者はメールを開き直さなくても、根拠の文を読めば取り出しが正しいかを判断できます。

スクリプトの側では、受け取ったJSONに対して次を確かめてから書き込みます。evidence が本文に実際に含まれているか（含まれていなければAIが作った文なので「要確認」にする）、due_text が本文に含まれているか、relation の既存タスクIDがタスク表に実在するか、です。

システムへ連携する

生成AIの呼び出しは UrlFetchApp.fetch() で行い、muteHttpExceptions を true にします。 これを付けると、応答がエラーのときに例外を投げずに応答そのものを返します。応答コードを見て、待って再試行するか、そのスレッドを飛ばすかを決められます。

タスク表の列は、タスクID、顧問先コード、顧問先名、担当者、種類、依頼の中身、やるのは誰か、期限の原文、期限（日付）、期限の直し方、根拠、元メールのリンク、状態、再依頼の回数、登録日時、確認者、確認日時です。「期限の直し方」には「月末→受信月の末日」のように、規則のどれを使ったかを書きます。

タスク表への書き込みは追記だけです。 既存の行の期限や状態をスクリプトが書き換えることはしません。再依頼のときも、既存の行の「再依頼の回数」を1増やすだけにします。期限を変えるのは担当者です。

人が確認する

1. 「未確認」の行を毎日1回見る … 担当者は自分の行だけを見ます。evidence を読み、依頼の中身と期限が本文と合っているかを確かめます
2. 期限が空欄の行を埋める … 本文に期限が書かれていなくても、法定の期限や顧問先の事情から期限がある依頼は、担当者が自分の判断で期限を入れます
3. 「やるのは誰か」が unknown の行を決める … 事務所がやるのか、顧問先に頼み返すのかを決めます
4. 取り出しが誤っていたら直し、「AIの誤り」に印を付ける … 依頼でないものを拾った、期限を取り違えた、などを残します

2番目を省かないでください。 この構成は書かれていない期限を補いません。その分、空欄の行に期限を入れるのは担当者の仕事として残ります。 空欄を放置すると、朝の一覧に一度も載らないまま期日が過ぎます。そのため、期限が空欄の行は「未確認」と同じく、24時間たてば朝の一覧に出します。

目標は、1,200件をならして1件1分です。 依頼を含まないメールはタスク表に何も載らず、確認の手間がかかりません。依頼が載ったものだけ、根拠の文を読んで確かめます。

例外に対処する

上から3行目までは、AIの判断ではなく仕組みの問題です。 どれもラベルが付かないまま次の回に処理されるので、メールが失われることはありません。ラベルを付けるのは書き込みが成功したときだけ、という決まりが効いています。

記録を残す

• 処理したメールのID、スレッドID、受信日時、顧問先コード
• 生成AIへ渡した本文（前処理の後）と、返ってきたJSONの全文
• スクリプトが確かめた結果（evidence が本文にあったか、値が候補の内かなど）
• 期限の日付化に使った規則と、そのときの休業日表の版
• 担当者が取り出しを直した記録 … どの項目を、何から何に変えたか
• 朝の一覧を送った日時と、送った件数

4つ目で休業日表の版を残すのは、表が後から変わるためです。 臨時の休業日を足すと、過去の「来週中」の日付が変わります。当時どの表で直したかが残っていないと、期日がずれた理由を追えません。

5つ目は、プロンプトを直す材料になります。 「AIの誤り」の印が付いた行を月に1回集めると、引用を拾っている、顧問先の約束を事務所の依頼と取り違えている、のように誤りの型が見えます。