# チャットとメールを横断して「やること」を優先順位付きでスプレッドシートに集約する チーム用チャット（Discord / Slack 等）と共有メールボックスから、改善点・タスク・締切・決定待ちを毎日自動で抽出し、 1枚のスプレッドシートに優先順位順で積む仕組みの作り方。 **この指示書の要点は「チャットだけを見ると必ず誤報告する」こと**。実運用で計測したところ、 チャットは *着手の宣言* が流れる場で、*決着* はメールで付いていた。片方だけを見ると 「未着手に見えるが実は完了」と「本当は明日が締切なのに台帳に無い」が同時に起きる。 --- ## 1. 全体の形 ``` [チャットAPI] --活動のあったチャンネルだけ取得--> 前処理 --安いLLMで抽出--> ┐ ├--> マージ+決定的な採点+並べ替え --> スプレッドシート [メールAPI] ----直近N日の受信を取得------------> 前処理 --安いLLMで抽出--> ┘ ↓ 実行ツール（状態の書き戻し + 実行ログ） ``` - 収集は2本のスクリプトに分け、**メールを先に流す**。メールで決着済みのものを、 後続のチャット側が重複判定で吸収できる。 - 台帳は毎回 **全面書き直し**（append ではなく、既存行を読んでマージして並べ替えて書き戻す）。 そうしないと優先順位順が保てない。 --- ## 2. 絶対に外してはいけない設計判断 ### 2-1. 「活動のあったチャンネル」の判定に API 呼び出しを使わない チャンネルが数百ある組織では、全チャンネルのメッセージを毎日取得すると数百リクエストになる。 チャンネル一覧の応答に含まれる **最終メッセージID から時刻を復元**すれば、追加の API 呼び出しはゼロ。 Discord の場合、ID は snowflake なので: ```js 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 に「優先度を決めて」と言うと日によって基準がぶれ、並び順が毎朝入れ替わって信用されなくなる。 ```js 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. 「完了・受領・御礼」で終わるスレッドは起票しない ```js 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`（重複除外）を含める: ```json {"ok":true,"channelsScanned":374,"channelsActive":85,"skipped":0, "messages":372,"extracted":136,"added":133,"suppressed":3,"totalRows":133} ``` ---