チャットとメールを横断して「やること」を優先順位付きでスプレッドシートに集約する

チーム用チャット（Discord / Slack 等）と共有メールボックスから、改善点・タスク・締切・決定待ちを毎日自動で抽出し、 1枚のスプレッドシートに優先順位順で積む仕組みの作り方。

この指示書の要点は「チャットだけを見ると必ず誤報告する」こと。実運用で計測したところ、 チャットは 着手の宣言 が流れる場で、決着 はメールで付いていた。片方だけを見ると 「未着手に見えるが実は完了」と「本当は明日が締切なのに台帳に無い」が同時に起きる。

---

1. 全体の形

[チャットAPI] --活動のあったチャンネルだけ取得--> 前処理 --安いLLMで抽出--> ┐
                                                                          ├--> マージ+決定的な採点+並べ替え --> スプレッドシート
[メールAPI] ----直近N日の受信を取得------------> 前処理 --安いLLMで抽出--> ┘
                                                                                  ↓
                                                                          実行ツール（状態の書き戻し + 実行ログ）

• 収集は2本のスクリプトに分け、メールを先に流す。メールで決着済みのものを、 後続のチャット側が重複判定で吸収できる。
• 台帳は毎回 全面書き直し（append ではなく、既存行を読んでマージして並べ替えて書き戻す）。 そうしないと優先順位順が保てない。

---

2. 絶対に外してはいけない設計判断

2-1. 「活動のあったチャンネル」の判定に API 呼び出しを使わない

チャンネルが数百ある組織では、全チャンネルのメッセージを毎日取得すると数百リクエストになる。 チャンネル一覧の応答に含まれる 最終メッセージID から時刻を復元すれば、追加の API 呼び出しはゼロ。

Discord の場合、ID は snowflake なので:

export function snowflakeToMs(id) {
  return Number((BigInt(String(id)) >> 22n) + 1420070400000n); // 1420070400000 = Discord epoch
}

実測: テキストチャンネル374に対し、直近24時間で活動があったのは85。289チャンネル分の取得を丸ごと省ける。

2-2. 優先度を LLM に決めさせない

LLM には 緊急度(0-3) / 影響度(0-3) / 種別 だけ返させ、点数は自前の関数で決定的に計算する。 LLM に「優先度を決めて」と言うと日によって基準がぶれ、並び順が毎朝入れ替わって信用されなくなる。

export function priorityScore(item, { now = new Date() } = {}) {
  let score = clamp(item.urgency) * 12 + clamp(item.impact) * 12;      // 最大72
  if (/^\d{4}-\d{2}-\d{2}$/.test(item.deadline || '')) {
    const days = daysUntil(item.deadline, now);
    score += days <= 0 ? 20 : days <= 3 ? 14 : days <= 7 ? 8 : days <= 14 ? 4 : 0;
  }
  // 事業のKPIに直結する語だけ加点する。重複加点しない（最初に当たった1つ）
  const target = `${item.title} ${item.action} ${item.channelName}`;
  if (/売上|受注|請求|入金|支払|見積|契約|クレーム|事故|法務/.test(target)) score += 8;
  else if (/顧客|案件|納品|施工/.test(target)) score += 5;
  else if (/改善|マニュアル|再発防止/.test(target)) score += 3;
  if (item.type === 'リスク') score += 6;
  else if (item.type === '締切') score += 4;
  return Math.min(100, Math.round(score));
}

KPI 語の一覧は自社の言葉に置き換えること。ここが唯一の「その会社らしさ」で、汎用語のままだと全部同じ点数になる。

2-3. Bot の閲覧権限が、そのまま台帳のカバー率になる

これが最大の落とし穴。Bot を招待しただけでは、非公開チャンネルは読めない。 権限が足りないと API は 403 を返し、例外にせずスキップする実装では 台帳が静かに空になり「異常なし」と誤読される。

実測: 管理者権限を持たない Bot で40チャンネルを叩いたところ、読めたのは 1つだけ（カバー率2.5%）。 管理者権限を持つ別 Bot のトークンに差し替えて 403がゼロになった。

対策を必ず入れる:

1. カバー率を実測する監査スクリプトを別に用意する（各チャンネルへ limit=1 で1回ずつ投げ、 readable / forbidden を数えるだけ）。「読めているつもり」を潰せる
2. 本体側は、権限の弱いトークンを使っているときに 警告を出す
3. 結果 JSON に skipped（403でスキップした数）を必ず含め、0件を成功と報告しない

なお Bot は自分に無い権限を自分へ付与できない（プラットフォーム側の仕様）ため、 権限不足はコードでは解決できない。管理者による付与か、権限を持つ既存 Bot の再利用が要る。

2-4. 件名だけを根拠に期日を採らない

メールの件名には 古い期日が残り続ける。 実例: 件名が 【提出期日：7月27日】…出展要項ご確認のお願い のスレッドを「38日超過の放置案件」として起票したが、 本文を読むとイベントは開催済みで、実体は請求書の受領（別の支払期日）だった。

抽出プロンプトに明示する:

件名の期日は古い可能性があるため本文の日付を優先し、件名だけが根拠なら deadline は空にする。

2-5. 「完了・受領・御礼」で終わるスレッドは起票しない

const COMPLETION_END = /(?:拝受いたしました|受領(?:いた)?しました|お振込みが完了|対応(?:が)?完了|ありがとうございました)[\s。！!]*$/u;

ただしこれは新規起票を止めるだけで、既存行は閉じない。 既存行の自動クローズは別途必要（→ 5章の「よくある失敗」）。

2-6. 近似重複を畳む

同じ会話から表記だけ違う同義タスクが複数できる （例:「保管用コンテナの交換依頼」/「保管用コンテナ交換の依頼」）。 完全一致のハッシュでは1件も潰せない。

タイトルから助詞と定型語（の が を に は へ と で する して 依頼 確認 対応 件）を落として 2-gram の Jaccard 係数 0.72 以上 かつ 同一チャンネルなら同一とみなす。 チャンネルが違えば別件として残す（別プロジェクトの同名タスクは本当に別件）。

2-7. 既存行の「状態」と「メモ」列は絶対に上書きしない

人が手で編集する列。台帳を全面書き直しする設計なので、マージ時にこの2列だけは既存値を保持する。 また、毎朝並べ替えるので 行番号は毎日ずれる。書き戻しツールは行番号ではなく ID で引くこと。

2-8. 書き込み後に必ず読み返して検証する

書き込み API が 200 を返しても、範囲指定を間違えれば別の場所に書かれる。 書いた範囲を読み直し、行数と先頭行のIDが一致するかを確認してから成功と報告する。 不一致なら非ゼロ終了。

---

3. 台帳の列

列	用途
ID	T-0001 形式の連番。書き戻しの鍵
起票日 / 最終更新	タイムゾーンを明示して整形
優先ランク	スコアから導出（>=75:P1 / >=50:P2 / >=25:P3 / それ未満:P4）
優先度スコア	0-100
種別	改善 / タスク / 締切 / 決定待ち / リスク
タイトル / 具体アクション	タイトル40字以内、アクションは「誰が何をするか」1文
担当 / 期限	発言や本文で明示されたものだけ。推測で埋めない
出所	チャンネル名、またはメールなら ✉ 差出人名（出所が一目で分かる）
根拠	実際の発言・本文からの抜粋120字以内（創作禁止）
リンク	元の発言・スレッドへの直リンク
状態 / 実行メモ	人が編集する列

並び順は 未完了を先 → スコア降順 → 期限昇順（空は最後）→ ID昇順。

---

4. 抽出プロンプト（そのまま使える骨格）

チャット発言（またはメール）から未完了の実行事項だけを抽出する。
雑談・アクション不要の報告・完了報告は除外する。
JSONオブジェクトのみを返し、前置き・説明・コードフェンスは禁止。
形式は {"items":[{"i":<入力番号>,"type":"改善|タスク|締切|決定待ち|リスク",
"title":"40字以内","action":"誰が何をするかを具体的に1文",
"owner":"本文で名指しされた担当者のみ。無ければ空文字",
"deadline":"YYYY-MM-DD または空","urgency":0-3,"impact":0-3,
"evidence":"実際の本文から120字以内で抜粋"}]}
「提出期限」「返信期限」「振込期日」「支払期限」「締切」を最優先で拾う。
件名の期日は古い可能性があるため本文の日付を優先し、件名だけが根拠なら deadline は空にする。
担当者を推測しない。evidence を創作しない。該当なしは {"items":[]}。

• 1リクエストあたり 30件程度に分割する
• JSON が壊れたバッチは 1回だけ再試行し、駄目なら「保留」として数えて捨てる（例外を投げない）
• モデルは分類・抽出用途なので最安のもので十分。高価なモデルを使う理由はない

---

5. よくある失敗（実際に踏んだもの）

収集は動くのに消化が無く、台帳がゴミ捨て場になる

これが最大の失敗。稼働2日で未完了が138件→361件に増え、完了は1件も無かった。 P4（スコア0-24）が208件を占め、その大半が「確認してください」（担当なし・期限なし）。 本当に急ぐP1が埋もれる。

必ず一緒に作ること:

• 既存行の自動クローズ（その後の発言・返信で決着したかを毎日判定する）。 これが無いと期限超過の件数そのものが信用できない — 実測で「超過・未着手」に見えた5件のうち4件は既に片付いていた
• P4 を起票しないか、N日で自動アーカイブする
• 担当も期限も空の行が大量に出るのは抽出漏れではなく、元の会話にそう書かれていないという事実。 無主の高優先度だけ元チャンネルへ問い返すのが現実的

「0件でした」を正常と報告してしまう

権限不足・トークン失効・フィルタの効かせすぎ、どれでも0件になる。 fetched / afterFilter / extracted / skipped を全部出力し、 skipped が多い＝権限の問題と切り分けられるようにする。

委譲先のCLIが上限に当たっても正常終了する

コード生成を外部CLIに委譲する構成では、利用上限に当たっても終了コード0で返るものがある。 「実装しました」という文言だけを見て完了と判断すると、ファイルが1つも作られていないまま先に進む。

さらに、作業ツリーに未コミット差分が常時あるリポジトリでは 「差分が空なら失敗」というガードが一度も発火しない。 実行前後のスナップショット（git diff --stat + git status --porcelain）を比べて 「この実行で変わったか」で判定する。

認証情報の配布を忘れる

スクリプトを配っても、サービスアカウント鍵やBotトークンが各端末に無ければ動かない。 コードの配布経路と資格情報の配布経路は別物。設計時に両方を決めておく。

---

6. 動かし方

日次スケジューラに メール → チャット の順で2アクション登録する。 実行時間は始業前。1回あたり数分〜十数分（本文取得が支配的）なので、実行時間制限は余裕を持たせる。

出力は必ず1行のJSONに要約し、skipped と suppressed（重複除外）を含める:

{"ok":true,"channelsScanned":374,"channelsActive":85,"skipped":0,
 "messages":372,"extracted":136,"added":133,"suppressed":3,"totalRows":133}