🗄️ NASしかない会社で顧客管理システムを設計する

中小企業の社内顧客管理システムを内製する。要件を並べていくと途中で条件がどんどん厳しくなり、最終的に「サーバプロセスを動かせる場所がこの世に一つもない」という状態に行き着いた。その制約の中で組んだ設計と、そこに至るまでに何を却下したかの記録。

最初に、動かせないものを固定しておく。ここを曖昧にしたまま設計すると「じゃあこれを買えば解決します」が無限に出てきて、いつまでも決まらない。

最初に浮かぶのは「SQLite の .db ファイルを NAS の共有フォルダに置いて、6台から直接読み書きする」だ。設定がゼロで、いますぐ動く。そして破損リスクを抱え続ける。

正確に言えば「必ず壊れる」わけではない。SMB のロックが期待どおり機能していれば、通常は直列化されるか SQLITE_BUSY が返るだけだ。問題は、SQLite がネットワークファイルシステムのロック意味論を安全だと前提にできないことにある。SQLite の公式ドキュメントがネットワーク共有上での利用を避けるよう書いているのは、この「保証がない」という一点による。

業務データを預ける判断において、「たぶん大丈夫」と「保証がある」の差は決定的だ。

「DBにこだわりはない、JSONでもいい」という話も出た。だが全データが入った1個の大きな JSON は、SQLite より危険だ。SQLite にはまだロック機構があったが、JSON にはそれすらない。

10:00  Aさん  data.json を読む（100件）
10:01  Bさん  data.json を読む（100件）
10:02  Aさん  1件追加して保存（101件）
10:03  Bさん  1件追加して保存（101件） ← Aの追加が消える

これが lost update。JSON は書くたびに全文を上書きするので構造的に必ず起きる。さらに書き込み中に固まればファイル全体が壊れて全データ消失する。

SMB でDBが壊れる原因は一つに集約できる。複数の端末が同じファイルを書き換えることだ。ならばロック機構を精巧にするのではなく、それが起きない構造にすればいい。

初稿では書き込み先フォルダを log\PC-TANAKA\ のようにホスト名で決めていた。設計レビューで、これがこの設計の一番弱い箇所だと指摘された。この設計は「書き手が常に1つ」という前提にすべてを預けているのに、その前提をホスト名という壊れやすいものに預けていた。

特に3番目と4番目が重い。IT運用を自社で握っていない（外部委託している）という前提と直接衝突する。「二重起動さえ防げば書き手は常に1つ」という主張の前提を、運用要因が静かに壊しうる。

そこで書き手の識別を、ホスト名から切り離した。

これでクローン展開・端末入れ替え・ユーザー切り替えのすべてで「書き手が1つ」が保たれる。ホスト名は表示用のラベルとして持つだけにして、識別の役割からは外した。

ログの再生結果は各端末のローカルディスクに SQLite でキャッシュする。ローカルSQLiteは1プロセスしか触らないので安全で、壊れても NAS のログから作り直せる「捨てていいキャッシュ」として扱う。画面はここから読むので高速。

{"v":1,"id":"01J8Z...","ts":"2026-08-25T10:32:11.123Z","seq":42,
 "w":"w_a3f1c2e8","pc":"PC-TANAKA","user":"tanaka",
 "entity":"customer","entityId":"c_8f3a","op":"update",
 "patch":{"phone":"03-1234-5678"}}

v はイベント形式のバージョン。アジャイルで形式は必ず変わるので最初から持たせる。seq はローカルの単調増加カウンタで、同一ミリ秒内の順序を確定させるために使う。w が writerId。

id（イベント一意ID）は必須。接続断のとき「NAS側には書き込み済みなのにクライアントは失敗と受け取る」ケースがあり、ローカル再送でイベントが重複する。読み取り側で id を見て重複を弾く（冪等化）。

async function emit(ev) {
  ev.v   = 1;
  ev.id  = crypto.randomUUID();   // 再送時の重複を弾くための一意キー
  ev.ts  = new Date().toISOString();
  ev.seq = nextSeq();
  ev.w   = MY_WRITER_ID;
  ev.user = currentUser;

  const line = JSON.stringify(ev) + '\n';
  try {
    await fs.appendFile(myLog(), line, 'utf8');  // 他に書き手がいない
  } catch (e) {
    await queueLocally(line);   // NASに繋がらない時はローカルに貯めて後で再送
  }
  applyToLocalCache(ev);        // 自分の画面には即反映
}

追記が失敗してもローカルに貯めて後で流せるので、NASが落ちていても入力作業は続けられる。「IMAPの作業は各PC上で」という要件とも噛み合う。

ただし appendFile が SMB 上で「イベント単位で原子的かつ永続的」であることは保証されない。だからこそ id による冪等化が要る。

ログは増えるだけなので、「どこまで読んだか」をバイトオフセットで覚えておけば、毎回新しい部分だけを読める。

async function sync() {
  for (const w of await fs.readdir(LOG_ROOT)) {
    if (w === MY_WRITER_ID) continue;

    // ★ 過去の閉じた月は毎回statしない。当月＋前月だけを見る
    for (const f of activeMonths()) {          // ['2026-08.jsonl', '2026-07.jsonl']
      const file = join(LOG_ROOT, w, f);
      const key  = w + '/' + f;
      const st = await fs.stat(file).catch(() => null);
      if (!st) continue;
      const off = offsets[key] ?? 0;
      if (st.size <= off) continue;            // 変化なし＝何も読まない

      const buf  = await readRange(file, off, st.size);
      // ★ UTF-8の途中で切れても壊さない。未確定バイトはdecoder内に残る
      const text = (remainder[key] ?? '') + decoders[key].write(buf);
      const lines = text.split('\n');
      remainder[key] = lines.pop();            // 未完成の最終行は次回へ持ち越し

      for (const l of lines) {
        if (!l.trim()) continue;
        let ev;
        try { ev = JSON.parse(l); }
        catch { quarantine(key, l); continue; } // 完全な行なので再読込しても直らない
        if (seenIds.has(ev.id)) continue;       // 再送による重複を弾く
        seenIds.add(ev.id);
        applyToLocalCache(ev);
      }
      offsets[key] = st.size;                   // ★ remainderを保持するので必ずsizeまで進める
    }
  }
}

fs.watch は SMB 上で信用できないので使わない。ポーリングで十分で、変化がなければ stat を数回叩くだけなので負荷はゼロに近い。

設計が固まった段階で「リアルタイム同期ではなく、アプリ起動時に一括ロードするだけにして、以後はその端末からの変更だけをログに書く方式でどうか」という案が出た。

この案の「変更だけを書く」部分は完全に正しい。というより、それが既にこの設計の中核だ。問題は「起動時のみ読む」という部分にある。

差分読み込みの設計にした時点で、ポーリングのコストはすでに限りなくゼロになっている。切って得られるものが実質何もないのに、情報の鮮度を丸ごと失う。60秒周期を採用した。

設計レビューで最も構造的な指摘がこれだった。IMAP を「ブラウザで不可能だから Electron」というクライアント選定の理由づけにしか使っていない。「誰がいつこの顧客にメールを送り、いつ返信が来たか」という、顧客管理の中核であるはずの履歴が、イベントスキーマのどこにも設計されていなかった。

これは論点の抜けというより、扱う範囲外に最重要機能が置かれていたという構造的な欠落だった。以下は反映した設計。

{"v":1,"id":"01J8Z...","ts":"2026-08-25T11:04:02.000Z","w":"w_a3f1c2e8",
 "entity":"activity","entityId":"c_8f3a","op":"append",
 "patch":{
   "kind":"mail_in",                       // mail_in / mail_out / call / visit
   "messageId":"<CAB1x@example.co.jp>",     // ★冪等キー
   "subject":"御見積の件",
   "at":"2026-08-25T11:02:41.000Z",
   "excerpt":"お世話になっております…"
 }}

各端末の IMAP 取得結果を、顧客に紐付けて活動イベントとして追記する。冪等キーは Message-ID。同じメールを2回取得しても、別の端末が同じメーリングリストを見ていても、二重登録されない。

本文そのものはログに入れない。excerpt（先頭数十字）と Message-ID だけを持ち、全文が必要なら各自のメールクライアント側で開く。ログに個人情報を書けば書くほど、後述の「削除要求への対応」が難しくなるため。

1対1のやり取りは各端末の IMAP/SMTP、200社への一斉配信は配信サービス経由と分けている。理由は、個人の Gmail / Microsoft 365 の SMTP から一斉送信すると、レート制限とスパム判定に引っかかり、SPF/DKIM/DMARC が揃っていなければ大半が迷惑メール行きになるため。

問題は宛先リストをどこから取るか。ローカルSQLiteキャッシュから取ると、直近60秒以内の連絡先変更や配信停止指定が反映されない。配信実行の直前に必ずフル同期を走らせ、配信停止フラグを再取得してから送る。そして配信結果も活動イベントとしてログに書き戻す。ここが切れていると「配信停止と言ったのにまた来た」が起きる。

設計が固まった時点で3方向からレビューをかけた。Codex（GPT-5.6）は学習データが違うぶん同系統のレビューでは出ない指摘を拾う担当。reviewer は型とビルドの整合性。architect は設計そのものの穴を「最低3つ挙げろ」という指示で。以下はすべて実際に返ってきて、記事と設計に反映したもの。

この設計は制約の中での最善であって、万能ではない。手放したものを明示しておかないと、後で「できると思っていた」が発生する。

初稿では「10〜15人を超えたら」を挙げていたが、負荷のボトルネックは人数ではなく「端末台数 × ログ月数 × 添付ファイル数」だという指摘を受けて変数の取り方から見直した。人数は競合頻度の指標としてのみ意味を持つ。