問い合わせの画面で、お名前かメールアドレスで検索してください。 見つかれば、状態（未対応／対応中／返信待ち／対応済）とやり取りがそのまま残っています。

画面のいちばん上に赤い警告が出ていませんか。出ていれば、 そのお問い合わせは受け付けたのに、この画面まで届いていません（次の項目へ）。

警告も出ていなければ、そもそも送信できていなかった可能性が高いです。 お客さまに受付番号（MS- ではじまる6文字）をお持ちか聞いてください。 番号があるなら受け付けられています。無ければ、フォームを送る前に離脱されています。

迷惑メールに入っていることがあります。差出人は contact@misawa-tokokoto.com です。この名前で探してもらってください。

技術的な確かめ方

受け口は3か所に同時に流れます。①info 側の控え ②現場の対応ボード ③スプレッドシート。 ①は必ず残るので、②③に無くても本文は復旧できます。

状態を直接見るなら GET /api/inquiry?data=failures&key=…。 forwardFailed が②に届かなかった数、orphans が 「返信は来たがスレッドが無い」数です。

お客さまの連絡がこちらに届かないまま消えかけているという合図です。2種類あり、直し方が違います。

フォームは受け付けたのに、対応ボードにスレッドが立ちませんでした。 本文は info 側に30日だけ残っています。 お客さまには受付番号をお伝え済みなので、その番号で先方に連絡して、内容を聞き直してください。 30日を過ぎると控えも消えます。

スレッドを消したあとに、その番号宛の返信が届いた場合に出ます。 Gmail でその受付番号を検索して、直接お返事してください。

お客さまは「連絡したのに無視された」と受け取ります。この警告は最優先で消してください。

なぜ起きるのか

①は info → board の転送が落ちたとき（inqfail:* に30日）。 ②は受付番号は正しいのに inq:t:<番号> が無いとき（inq:orphan:* に30日）。

どちらも記録は前からしていましたが、読む画面がありませんでした（2026-08-23 に追加）。

顧客台帳の上のほう、「素材：」の行に 予約 ○○件（○○ 時点）のように、どの記録がいつ時点のものか出ています。 ここが古いままなら取り込みが止まっています。

• 名寄せ待ちかもしれません。［名寄せ候補］タブを見てください。 別々の記録のまま、まだ1人にまとまっていない可能性があります
• tripla の会員は月1回の取り込みです。直近に会員登録された方はまだ入っていません （［triplaの会員CSVを取り込む］で最新にできます）
• お名前の表記ゆれ（スペースの全角・半角など）で検索に引っかからないことがあります。 メールアドレスや電話番号で探すと見つかることが多いです

台帳の売上・宿泊回数は取り込んだ予約と一致するのが正常です。 ずれていたら二重計上を疑ってください。経営ダッシュボードの売上は別系統なので、そちらは影響を受けません。

予約データの出どころ（2026-08-23 に切り替え）

もとは解約した Notion の写しで 2026-06-21 で止まっていました。 6月下旬以降にはじめて泊まった方が台帳に載らない状態だったため、 生きている正本である PMS のデータベース（手間いらずの日次同期）から 組み直す経路に付け替えました。

この切り替えで宿泊回数の数え方も変わりました（実際に泊まった予約だけを数える）。 切り替え前後で数字を比べるときは注意してください。

送れるのはご本人が「メールを受け取る」と答えた方だけです。 その意思表示は tripla の会員登録のときにしていただいています。 泊まったことがあるだけの方には送りません。許諾がないためです。

tripla の会員が増えると宛先も増えます。月1回、会員CSVの取り込みをしてください （顧客台帳の［triplaの会員CSVを取り込む］）。

既存のお客さま全員に送れるようにするかどうかは、井上さんの判断事項です。 法律（特定電子メール法）の解釈が絡むので、こちらで勝手には変えていません。

許諾の持ち方

許諾は「人」ではなくそのメールアドレスに対して記録しています（marketingEmail）。 名寄せで1人に複数アドレスがぶら下がるため、先頭を採ると事故ります。

実例：ゲスト情報の八木澤さんの記録に、代理登録した谷山さんのアドレスが入っていました。 先頭を採っていたら谷山さんへ配信されるところでした。

取り込みは10分おきです。急いでいるときは、少し待ってから画面を再読込してください。

急いでいるときは Gmail からそのまま返信して構いません。 同じメールのスレッドで続けていれば、お客さまの返信も、こちらから直接送った文面も、 まとめてこの画面に入ります。件名を書き直しても大丈夫です。

新しいメールを一から書いて送った場合は、別のスレッドになるので入りません。 返信するときは、元のメールから返信する（新規作成にしない）ようにしてください。

それでも見当たらなければ、画面のいちばん上に赤い警告が出ていないか確認してください。

どうやって同じスレッドだと判断しているか

2段構えです。

• 最初の1通は件名の [MS-○○○○○○] で見つけます
• 見つけたら Gmail のスレッドIDを覚えます。以後そのスレッドは、 件名に関係なく毎回まるごと読みに行きます

だから2通目以降で件名から番号が消えても取りこぼしません。 逆に、スレッド内のどのメールの件名にも番号が無い場合だけ取り込めません （どの相談のものか決められないため。別の相談に紛れ込ませるほうが害が大きい）。

終わったスレッド（対応済・対応不要）は見に行くのをやめます。 取り込み済みのメールには inquiry-synced のラベルが付き、二度は投げません。

• お客さまへの受付控え・返信 … contact@misawa-tokokoto.com
• 社内への通知 … no-reply@send.misawa-tokokoto.com
• メルマガ … news@misawa-tokokoto.com
• PMS の予約確認・鍵案内など … no-reply@（自動送信）

社内通知だけ差出人が違うのは、contact@ がメーリングリストで、 ML宛の通知をML自身から送ると落とされることがあるためです。

お客さまに見せる面では使いません。販売管理の事務局側だけのアドレスです。 もしお客さま向けの文面で見かけたら、それは直し漏れなので教えてください。

ドメイン認証

さくらのDNSに DKIM・MX・SPF の3件を追加して、ドメイン直下を認証済みにしています（2026-08-22）。 Google Workspace の受信には影響していません。

Resend の「確認する」ボタンは検査前の状態を返します。 DNSが正しくても「保留中」に見えるので、状態は取得側（GET）で見てください。

シミュレーターの画面のいちばん下、「料金・在庫は ○○ 時点の情報です」を見てください。 半日以上前なら取り直しが止まっています（下の「止まっているとき」へ）。

• 料金の正本は手間いらずです。tripla もシミュレーターも、手間いらずから流れてくる値を出しているだけです。 料金を直すのは手間いらず側です（予約設定のルール）
• 足したばかりのプランが出ない。新しいプランを見つけるのは毎朝 6:40 と毎晩 2:40 の回です。 最低宿泊日数が2泊以上のプランは、対応表に足すまで出ません（予約設定のルールの早見表）
• 2か月より先の日付。先の日付は4時間ごと・毎朝の回でしか取り直さないので、数時間ずれることがあります

次の回で自動的に取り直します。続けて失敗していれば、翌朝 9:00 の見回りが拾ってお知らせに出します。 急ぐときは、管理者が GitHub の misawa-simulator → Actions →「Tripla 在庫・料金の定期同期（クラウド）」→ ［Run workflow］で手動で回せます（near＝45日先まで・数分／light＝約半年先まで・約30分／full＝全部・約1時間半）。

失敗の番号（実行ページの Summary に日本語の理由が出ます）

• 2 tripla の通行証を発行できない（中で2回試し済み）
• 3 採取に失敗 → 3分おいて1回やり直す
• 4 健全性チェックで中止・6 在庫を持たないオプションが消えた → 壊れたデータは公開していません。やり直さない
• 5 デプロイに失敗（本番は前回のまま）→ 1回やり直す
• 7 取り直したデータを sync-data に積めなかった（本番は更新済み。次の回は1つ前のデータから始まる）→ 中で5回試し済みなので、やり直さない
• 8 sync-data を読めなかった → 古い土台で取ると本番を巻き戻すので、採らずに止める。1回やり直す

取り直したデータは、GitHub の misawa-simulator の「sync-data」という枝（ブランチ）に積んでいます。 プログラム本体が入っている main とは分けています。

• main は 2026-10-08 から、レビュー（PR）を通さないと書き換えられない保護が掛かっています。 自動の同期がそこへ直接書き込もうとして、10/8〜10/10 に8回続けて断られました
• 保護に「自動の同期だけは例外」を足すと、レビューを通さずに main を書き換えられる穴になります。 そこで保護はそのままにして、データの置き場所のほうを分けました（2026-10-10・井上さん判断）
• main にあるデータは 2026-10-07 で止まっています。最新を見たいときは本番のページか sync-data から読んでください

流れと置き場所（引き継ぎ・改修のとき）

• 動かしているもの：GitHub Actions tripla-sync.yml → tools/sync.sh。 どのモードで回すかは tools/pick-mode.py が「今日すでに何が済んだか」で決める（毎晩の回が遅れたり抜けたりしても、その日のうちに全部の取り直しに追いつく）
• 1回の流れ：sync-data のデータを重ねる → tripla から採取 → 健全性チェック（日数・プラン数が足りなければ公開しない）→ フォントを作り直す → Cloudflare Pages へデプロイ → sync-data に積む
• sync-data に積むもの：catalog.json・options.json・calendar.json・i18n.json の4つだけ。 フォント（りいクッキー）はデータのプラン名とコードの文言から作るので、積まずにデプロイのたびに作り直す。 やりとりは tools/data-branch.sh（pull／push）にまとめてある
• コードの PR をマージしたとき（deploy.yml）も、sync-data を重ねてからデプロイする。重ねないと、マージのたびに本番が 10/7 のデータへ戻る（10/8〜10/9 に実際に起きていた）
• 5分ごとの重ね：Worker misawa-sim-stock が KV SIM_LIVE の cal:near に、 PMS の pms-sync が予約の動いた日を cal:live に置き、配るときに写しの上に重ねる（functions/assets/data/calendar.json.js）
• 最新のデータを読むとき：https://simulator.misawa-tokokoto.com/assets/data/catalog.json（calendar・options も同じ）か git show origin/sync-data:public/assets/data/catalog.json。手元のフォルダと main は古い
• 保護：main は main-protection（PR 必須・削除と強制 push の禁止）。sync-data は sync-data-protection（削除と強制 push の禁止だけ）。どちらも例外は管理者だけ
• 心拍：q4h-misawa-simulator-stock（毎晩・4時間ごと）／0640-misawa-simulator・misawa-simulator-sync（毎朝）／q5m-misawa-sim-stock（5分ごと）
• 詳しい資料：misawa-simulator の README.md「データの置き場」と tools/data-branch.sh の冒頭。食い違ったらこちらが正

お問い合わせ1件ごとに発番される6文字の番号です。読み間違えやすい 0/O・1/I は使っていません。

件名の［MS-○○○○○○］が、返信を元のスレッドへ戻す唯一の手がかりです。 画面から返信すればシステムが自動で付けます。

PMS のチェックインコード（当日の本人確認に使う6桁の数字）とは別物です。混ぜないでください。

今回のものは PMS の上に重ねた層で、PMS の中身には手を入れていません。

• PMS が担当：予約の取り込み（手間いらずから5分ごと）、当日ボード、部屋割り、 事前チェックイン、宿カルテ、請求、宿泊者台帳CSV、ゲスト向けメール4通
• 今回のもの：問い合わせ窓口、顧客台帳、メルマガ
• 顧客台帳は PMS のデータを読むだけ。書き換えません

ひとつだけ PMS 側にも及んだ変更があります。メールの見た目が共通なので、 booking@ → contact@ の直しはゲスト向けメール4通にも反映されました（2026-08-23）。

• お問い合わせ：経営ダッシュボード側。添付は180日で自動的に消えます
• 顧客台帳：同上。人が下した判断は別枠で保存され、作り直しでも消えません
• メルマガ：同上。送信済みアドレスは180日残ります
• スプレッドシート：「お問い合わせフォーム（回答）」の HPお問い合わせ タブ
• 予約・宿泊者の個人情報：PMS のデータベース（公開ファイルには一切出しません）

キーの一覧

inq:index／inq:t:<番号>／inq:att:*（180日）／ inq:sig／inq:seen:*（60日）／inq:orphan:*（30日）

crm:people／crm:people:manual（人の判断）／crm:tripla

nl:index／nl:<id>／nl:sent:<id>（180日）

info 側：inq:<番号>（控え）／inqfail:<番号>（30日）／lead:*

• 設定値は入れただけでは効きません。公開し直すまで「未設定」のままです
• ドメイン認証の「確認する」ボタンは検査前の状態を返します。状態は取得側で見てください
• 販売管理ページに問い合わせの処理ファイルを作らないでください。 作った瞬間に経営ダッシュボードへの振り分けが止まり、鍵を使う経路が丸ごと死にます
• メールの文面は3リポジトリに同じコピーがあります。1か所だけ直すと届くものが場所で変わります
• 販売管理ページにページを足したら、ボード側にも入口を作ってください。 横断検索・校内マップ・転送設定の3か所すべて。忘れると「そんなページは無い」ように見えます
• 統合の記録は、消える側のすべての手がかりで持つこと。 代表1つだけ記録していたら、288組を統合したあと43組が候補に戻ってきました
• 無人プロセスに 404 を返さないこと。相手の後始末の分岐に到達せず、永久にやり直します
• 料金シミュレーターのデータを main や手元のフォルダから読まないこと。 2026-10-07 で止まっています。本番のページか sync-data から読んでください（しくみ）