社内フィードバックが「記録は残るが誰も気づかない」で死ぬのを塞ぐ

不具合・要望フォームを作ったのに報告が放置される事故は、フォームの出来ではなく通知の設計で起きる。 この指示書は、通知経路の穴を塞ぎ、溜まった未対応を毎日押し出すところまでを型にする。

前提となる失敗（実測）

フォームは動いていて、投稿はシートに記録されていた。それでも誰も気づかなかった。原因は3つ。

1. 通知先が実質1本しかなかった。中継サーバ経由の通知だけが設定され、フォールバック用の webhook は空。中継が落ちている間の投稿は通知ゼロになる。記録は残るので障害として顕在化しない。
2. 未対応を押し出す仕組みが無かった。初回通知を見逃したら、そこで終わる。 実際に未完了1件が15日放置されていた。
3. 「未対応」の定義を間違えていた。「対応メモが空のもの」に絞ると、 メモは書いたが完了していない案件が全部こぼれる。実測ではまさにその1件だけが残っていた。

型1: 通知は多段フォールバックにし、全滅を検出可能にする

(1) 中継/API  ->  (2) 本人への DM  ->  (3) チャンネル webhook

• 先に成功した1つで止める（多重通知しない）
• 各段の失敗理由を配列に積み、全滅したときだけ via: 'none' と理由の連結を返す
• 通知が全滅しても記録は成功扱いにする（記録が本体、通知は best-effort）。 ただし全滅の理由は必ず残す。残さないと「静かに壊れている」状態が続く

var errors = [];
if (config.url && config.secret) {
  var attempt = postRelay(config, payload);
  if (attempt.ok) return { ok: true, via: 'relay' };
  errors.push('中継: ' + (attempt.error || '送信失敗'));
} else errors.push('中継: 未設定');

if (config.botToken && config.dmUserId) {
  if (postDm(config.botToken, config.dmUserId, content, blobs)) return { ok: true, via: 'dm' };
  errors.push('DM: 送信失敗');
} else errors.push('DM: 未設定');

if (config.webhook) {
  if (postWebhook(config.webhook, content, blobs)) return { ok: true, via: 'webhook' };
  errors.push('webhook: 送信失敗');
} else errors.push('webhook: 未設定');

return { ok: true, via: 'none', error: errors.join(' / ') };

導入完了の条件は「実際に着信を見たこと」。設定値を入れただけを完了と呼ばない。 疎通テスト関数（1通だけ送る）を必ず用意し、それを叩いて着信を確認する。

型2: DM は webhook では送れない（Bot トークンが要る）

Discord の webhook は生成時に紐づいたチャンネルにしか投稿できない。宛先を指定する経路が無いので、 個人 DM は Bot API を使う。2ステップ:

// 1) DM チャンネルを開く
POST https://discord.com/api/v10/users/@me/channels
headers: { Authorization: 'Bot ' + token, 'Content-Type': 'application/json' }
body:    { "recipient_id": "<ユーザーID>" }
// -> 200, レスポンスの id が DM チャンネル。type は 1 (DM)

// 2) 送る
POST https://discord.com/api/v10/channels/<id>/messages
// 画像なし: { "content": "..." }
// 画像あり: multipart/form-data で payload_json + files[0..n]

• Bot は対象ユーザーと同じサーバーに居る必要がある（居ないと DM チャンネルを開けない）
• content は 1900 文字で切る（上限 2000）
• muteHttpExceptions: true にして例外を投げない。通知の失敗で記録を巻き込まない
• ユーザーIDの取り方: クライアントのユーザー設定 → 詳細設定 → 開発者モード ON → アイコンを右クリック →「ユーザーIDをコピー」

トークンの置き場所（ここを間違えない）

Bot トークンをクラウド側（サーバレスのプロパティストア等）へ複製するのは既定にしない。 認証情報のコピーが増え、棚卸しの対象も増える。

• 即時通知は中継/webhook（クラウド側）に任せる
• DM と毎日プッシュは本人の端末で動く定期実行から送る。トークンはその端末のローカルファイルに置いたまま
• こうすると「中継が落ちて即時通知が飛ばなくても、翌朝のプッシュが記録を読んで必ず拾う」二段構えになる

クラウド側から直接 DM したい場合だけ、意識的にトークンを置く。既定にはしない。

型3: 未対応の毎日プッシュ

未対応 = 状態が done / 完了 / 対応済 / 却下 のいずれでもないもの「全部」

対応メモ（返答）が入っていても除外しない。 代わりに各行へ 未返答 / 返答済・未完了 を出して区別する。 「返答が無いものだけ」に絞ると、返事はしたが終わっていない案件が消えて放置される。

その他の要件:

• 0件のときは送らない。毎日の無意味通知はすぐ無視されるようになり、本番の通知まで死ぬ
• 1通にまとめる（1件1通にしない）。最大15件、超過は「ほか N 件」
• 各行に経過日数を出す。日付がパースできない行は 経過不明 として落とさない
• 末尾に記録シート/DB へのリンクを1本付ける
• 列は必ずヘッダー名で引く。列番号固定は壊れる（実測: 受付ID 列が後から増えて全部ズレた）

var doneStates = { done: true, '完了': true, '対応済': true, '却下': true };
var state = String(row[col['状態']] || '').trim().toLowerCase();
if (doneStates[state]) continue;                       // メモの有無では切らない
var replyState = String(row[col['対応メモ']] || '').trim() ? '返答済・未完了' : '未返答';

出力例:

🐛 未対応の不具合・要望 3 件
・[要望/返答済・未完了] 原価を集めるタスク … 経過 15 日 / 送信元: パネル
・[不具合/未返答] 印刷リストのリンクが違う … 経過 2 日 / 送信元: チェックシート / フォーム
<記録シートのURL>

定期実行

• 日次トリガー/タスクは1本だけにする。設置関数は「同名ハンドラを全削除してから1本作る」形にする （再実行で増殖する事故が多い。サーバレス側はトリガー数に上限があり、溢れると他の定期処理も止まる）
• 端末側のスケジューラで動かす場合は、ウィンドウを出さない起動方法にして、ログをファイルに残す

型4: 社内ルールとして明文化する

個別アプリで直しても次のアプリでまた同じ穴が空く。配布テンプレとルール文書の両方を直す。

• 「通知先を1つも設定しないまま導入完了にしない」を明文化する
• テンプレにはドメインや個人IDをハードコードしない。設定値（<DM先ユーザーID> <Workspaceドメイン>） として外に出す。ハードコードすると他アカウントで配布物が壊れる
• 社内グループウェアのリンクは、素の URL だとブラウザ既定の個人アカウントで開いて弾かれることがある。 ドメイン付きの形式に揃える設定を用意する

チェックリスト

• 通知経路が2つ以上あり、全滅時に理由が残る
• 疎通テストを実行して実際に着信を見た
• 未対応の定義が「状態が完了系でないもの全部」になっている
• 0件のとき送らない
• 日次トリガーが1本だけ（再実行で増えない）
• 列をヘッダー名で引いている
• テンプレに固有値がハードコードされていない
• トークンをクラウドへ不要に複製していない