0結論（3行）
① メール送信後のフリーズ
こちらの作りが原因です
送信後に「OK」を押す確認窓を出していました。人なら押せますが、自動処理には押す相手がいません。本日中に直します。
② ステータスの上書き
当社の自動処理が原因でした
犯人は当社の「差戻しパトロール」です。安全装置が無効化されたまま動いていました。止め方と正しいステータスの決定をお願いします。
③ 履歴の行が消える
Kintone本体の仕様です
カスタマイズ側では防げません。編集画面で保存しない運用に変えていただく必要があります。
①報告メール送信後のフリーズ こちらが原因
原因：送信後の処理を、すべてブラウザの標準ダイアログ（「OK」ボタンの出る確認窓）で終わらせていました。
この窓が開いている間、ページの動作は完全に止まります。人なら1回押せば進みますが、自動処理には押す相手がいないため、止まったままになります。5分以上というのは、その途中経過です。
図1｜送信基盤からの応答は数秒で返っています。止まっているのは、その後に出す確認窓です。
9/14 8:40 の SC202609110019 について
出ていたのは、おそらく「二重送信よけ」の確認窓です。
同じ案件へ同じメールを15分以内に送ろうとすると、送信基盤が送信を止めて
「直前に同じメールを送っています。本当にもう一度送りますか？」と確認します。
この確認が出た時点では、メールはまだ送られていません。送る前に止めているためです。
したがって、その試行については未送信とご判断ください。
ただし直前15分以内に1通目が送られている可能性があります。全送信に
callcenter@all-zenbu.co.jp のCCが入りますので、そちらの控えでご確認をお願いします。
ご質問(a)(b)への回答
※ なお、当社のカスタマイズJS（283行）を全文確認しましたが、待ち時間の設定・再試行・同期通信は1件もありません。
したがって「5分」という数字は当社の設定から出たものではなく、そちら側の待ち時間の上限ではないかと推測しています。
ご質問(c) Kintoneへの書き戻しについて
送信基盤に、書き戻しの機能はすでに実装済みです。アプリ306と475では稼働しています。
アプリ379だけ設定が入っていませんでした。設定を追加すれば有効になります。改修は不要です。
ただし、379側に書き戻し先として使えるフィールドが見当たりません（「送信日時」「送信状態」に相当するもの）。
新設してよろしければ、こちらで用意します。ご指示ください。
こちらの対応
- 本日中：確認窓をやめ、画面の中に結果を表示する方式へ変更します
- 本日中：あわせて、自動処理側から成否を読み取れる目印（
data-送信結果）を画面に出します
- 今週中：379への書き戻し設定（フィールドが決まり次第）
※ 自動処理側で「確認窓を自動で閉じる」設定を入れれば今日から止まらなくなりますが、
二重送信よけの確認まで自動でOKしてしまい、かえって2通送る危険があります。おすすめしません。
②FAX送信後にステータスが上書きされる 当社の処理が原因
犯人は当社の常駐処理「差戻しステータス更新＋Chatwork通知パトロール」です。
Google Apps Script版（patrol_diff_status.gs）が、Googleのサーバー上で1分おきに
アプリ475・379を巡回し、条件に合うレコードのステータスを
「大東建託様へ差戻し済(手配不可)」に書き換えていました。
当社PCのタスク一覧にもログにも出ないため、最初の確認では見つけられませんでした。
ご不便をおかけし、申し訳ありません。
なぜ、何度直しても戻るのか
この処理は「すでに『大東建託様へ差戻し済(手配不可)』になっているか」だけを見て、
違っていれば書き換えます。
「差戻し済【FAX報告済み】」はこの値と違うので、毎回かならず書き換え対象に入ります。
さらに、確定系のステータス（FAX報告済み・金額確定済など）を守るための安全装置が、
過去に意図的に無効化されたまま残っていました（コード上、常に「守らない」を返す状態）。
加えて「差戻し済【FAX報告済み】」はこの処理が作られた後に追加された選択肢で、処理側はその存在を知りません。
この2点が重なって、全件上書きになっています。
発火する条件（ご参考）
- 対象は「今月1日〜昨日23:59:59に作成された」レコードのみ。本日作成分・先月以前には触りません（日によって起きたり起きなかったりするのはこのためです）
- 業者名が入っている、または訪問日3項目のいずれかが入っていれば触りません
- 差戻しチェックボックスがON、または入電・発信履歴の本文に「差戻し」「手配不可」等の文字があると発火します。チェックを外しても、履歴に文字が残っていれば再発火します
- 100件ずつまとめて更新します（10:11に5件が同時刻だったのはこのためです）
「大東金額確定済」（9:56・10:10）は上書き事故ではありません。
こちらは別の処理で、大東建託様から届く金額確定通知書のFAXを受信して、
PDF添付・金額確定日・ステータスを書き込む正規の動作です（2分おきに稼働）。意図どおりです。
確認の裏付け：10:11に5件が同時に書き換わっています
件数・時刻ともに、パトロールの「100件ずつまとめて更新」という動きと一致します。
ご報告の「差戻し5件すべてで発生」とも合致します。
こちらの対応
- 本日中：パトロールの動作を止めます（または、確定系ステータスを守る安全装置を元に戻します）
- 今週中：新しく追加された選択肢（差戻し済【FAX報告済み】など）を尊重するよう改修します
- 今週中：無効化された安全装置が他にも無いか、同種の常駐処理を棚卸しします
それまでの間のお願い：自動処理側ではステータス（ラジオボタン）を書き換えないでください。
一覧上の判定や再処理防止は、いまお使いの「大東建託様へ報告日」の打刻と「差戻しチェックボックス」で行ってください。
この2つはパトロールが書き換えません。
現在の差戻し系ステータス（4種類あります）
③履歴の行が描画されず、保存すると消える Kintone本体の仕様
Kintoneの保存は「画面に表示されているテーブルの状態」をそのまま送ります。
そのため、まだ描画されていない行は「無い」ものとして保存されます。
これはKintone本体の動きで、カスタマイズ側で「消さない」ようにすることはできません。
図2｜Kintoneは「画面にある分」を正として保存します。描画待ちの行は削除扱いになります。
描画が遅い理由（断定はできていません）
確からしい順に3つあります。
- アプリ475のフォームそのものが非常に重い。フィールド約130個、添付ファイル欄19個（サムネイル生成あり）、
ステータスのラジオボタンは16択。編集画面は横に3,500px級の巨大なレイアウトになります。
入電・発信履歴はその中ほどに置かれており、周囲の描画に巻き込まれます
- 他社製のプラグイン・カスタマイズが編集画面で動いている可能性。475にはFAX送信やメール送信の外部サービスが入っています。
これらが編集画面で何をしているかは、権限の都合で今回確認できていません。今週中に確認します
- 添付PDFのサムネイル生成。例のレコード4885には5件のPDFが付いており、うち1件は2.88MBです
※ 当社自作の2本（帳票ボタン・メールボタン）は編集画面では一切動きません。ここは確認済みです。
あわせてお伝えします。②のパトロールが1分おきに同じレコードを更新しているため、
編集画面を開いた時点の内容は、開いている間にどんどん古くなります。
編集画面から保存する運用そのものが、行を失う危険を常に抱えた状態でした。②の修正でこの頻度は下がります。
こちらの対応とお願い
- お願い（重要）：この表を含むレコードは、編集画面で保存しないでください。
APIでの部分更新（該当フィールドのみ指定）であれば画面を経由しないため、行は消えません
- 御社側で入れていただいている「行数が一致するまで保存しない」ガードは、そのまま継続をお願いします
- 今週中：カスタマイズJSが描画を遅くしていないかを調査し、軽くできる箇所があれば直します
（ただし上記のとおり、これは「遅さ」の改善であって「行が消える」ことの根本解決にはなりません）
★佐藤様に決めていただきたいこと
決定事項 1
差戻しの正しい最終ステータスはどれですか。
現時点でパトロールが正としているのは「大東建託様へ差戻し済(手配不可)」です。
「FAXで報告まで済ませた差戻し」を別扱いにするのであれば 差戻し済【FAX報告済み】 が正しく、
パトロール側をそれに合わせて直します。
どちらを正とするかをご指示ください。無断で正の値を変えることはしません。
決定事項 2
アプリ379に、メール送信結果を書き戻すフィールドを新設してよろしいですか。
「送信日時」「送信状態（未送信／送信成功／送信エラー）」の2つを想定しています。
新設できれば、画面の状態に関係なく成否を判定できるようになります。
お願い 1
パトロール修正までの間、自動処理側ではステータス（ラジオボタン）を書き換えないでください。
「大東建託様へ報告日」の打刻と「差戻しチェックボックス」はパトロールが触りませんので、
そちらで判定してください。修正が完了したらご連絡します。
▶対応予定
FAX送信履歴アプリ484の反映遅延（レコード4895・約10分）については、承知しました。対応不要とのことですので、遅延のばらつきとして記録にとどめます。