CRMという言葉は、もう珍しくない。
だが現場では、今でもこういう声をよく聞く。
「Excelで足りている」
「まだ早い」
「人が増えたら考える」
その判断自体が間違いだとは思わない。
問題は、何が起きてから困り始めるのかが、あまり言語化されてこなかったことだ。
案件が増えたからではない。
人数が増えたからでもない。
多くの場合、最初に壊れるのは、
- なぜその判断をしたのか
- どこで方針が変わったのか
- 誰が何を見て決めたのか
という、判断の履歴だ。
本記事では、
CRMを「流行りの業務ツール」として扱わない。
また、AI時代の必須装備として煽ることもしない。
扱うのは、もっと地味で、もっと実務的な話だ。
- Excel管理がどこで破綻するのか
- 大型CRMが重くなりがちな理由は何か
- その中間に、現実的な選択肢はあるのか
その検証対象として、EspoCRMを取り上げる。
これは導入を勧める記事ではない。
使うかどうかは、最後まで読んだ上で決めればいい。
ただし一つだけはっきりさせておく。
「知らなかった」まま選ばないための記事である。
1. CRMとは何か
CRM（Customer Relationship Management：顧客関係管理）は、
一般に「顧客管理システム」と説明されることが多い。
だが、この理解のまま導入すると、ほぼ確実に失敗する。
CRMの本質は、顧客を管理することではない。
正確には、顧客・案件・判断を“関係性として残す”ための仕組みだ。
「顧客リスト」とCRMは別物
Excelや名刺管理ソフトでも、顧客情報は管理できる。
会社名、担当者名、電話番号、メールアドレス。
これらは「点」としての情報だ。
一方、現実の仕事は点では進まない。
- どの案件で
- いつ、誰が
- 何を判断し
- なぜその結論に至ったのか
こうした経緯＝線がなければ、次の判断ができない。
CRMが扱うのは、この「線」だ。
Excelが壊れやすい理由
Excelは優秀な道具だが、関係性を持たせる設計ではない。
- 案件シートと顧客シートが分断される
- 過去の判断理由がセルの外に消える
- 「誰が決めたか」が曖昧になる
人数が増える前に、情報の意味が先に壊れる。
一人で使っていても同じだ。
過去の自分が「なぜそう判断したか」を思い出せなくなる。
CRMは「記憶の外部化装置」
CRMは、人間の記憶を補助するための道具だ。
- 顧客と案件を紐づける
- 判断の流れを時系列で残す
- 後から見返せる形で整理する
これは管理というより、思考の保存に近い。
EspoCRMを理解するために必要なCRMの定義は、ここまでで十分だ。
一般論を深掘りする必要はない。
2. EspoCRMとは何者か
EspoCRMは、CRMに分類されるオープンソースソフトウェアだ。
だが、一般的に想像されがちな「営業管理ツール」や「SFA（Sales Force Automation）」として見ると、実態を見誤る。
EspoCRMの成り立ちと立場
EspoCRMは、2011年にウクライナで開発が始まったCRMプロジェクトを起源とし、
現在は EspoCRM, Inc.（米国法人） によって運営されている。
設計の出発点は明確で、
- 大企業向けCRMの複雑さを避ける
- 小規模組織でも自前運用できる
- 機能を「足す前に削る」
という思想が一貫している。
SalesforceやERPとの決定的な違い
EspoCRMは、Salesforceの代替を狙った製品ではない。
また、ERP（Enterprise Resource Planning）のように、会計・在庫・人事までを包含する設計でもない。
EspoCRMが扱う範囲は、あくまで次の領域に限定されている。
- 顧客
- 担当者
- 案件
- そのやり取りと判断の履歴
逆に言えば、
- 請求書の発行
- 在庫数量の管理
- 会計処理や給与計算
といった業務は、最初からスコープ外だ。
これは「できない」のではなく、
やらないと決めているという設計上の選択である。
「全部入り」にしなかった理由
EspoCRMが全部入りを目指さなかった理由は単純だ。
業務の種類が増えるほど、
- 画面が重くなる
- 操作が複雑になる
- 使われなくなる
CRMは、使われなければ価値がゼロになる。
EspoCRMはこの点を強く意識しており、
日常的に入力され続けることを最優先に置いている。
なぜオープンソース（OSS）なのか
EspoCRMは、AGPLv3ライセンスで公開されているオープンソースソフトウェアだ。
これは単なる「無料配布」ではない。
- 自社サーバーで運用できる
- ベンダー都合で仕様が突然変わらない
- サービス終了でデータが人質に取られない
中小零細企業や一人親方にとって、
道具の生殺与奪を他社に握られないことは、それ自体が価値になる。
この立ち位置を理解しておかないと、
EspoCRMを「安いSalesforce」と誤解してしまう。
EspoCRMのサマリー
EspoCRMとは
オープンソース（OSS）のCRM。
顧客・担当者・案件・履歴を、関係性として一元管理できる。
提供元
EspoCRM, Inc.（米国）
※開発の起源はウクライナ（Letrium Ltd）
ライセンス
AGPLv3
ソフトウェア自体は無償で利用可能。
コスト
ソフトウェア費用 0円
必要なのはサーバー代のみ（共有レンタルサーバーでも可）
日本語対応
UIは日本語化済み
一部に翻訳の揺れや不自然な表現あり
主な用途
顧客管理
案件管理
やり取り・判断履歴の共有
引き継ぎ
向いている規模
1人〜数十人規模
Excel管理に限界を感じ始めている現場
向かないケース
請求・在庫・会計までを一体で管理したい
国産業務ソフト並みの日本語UI品質を求める
結論
EspoCRMは、
「CRMを初めて導入する段階」
「重すぎるCRMに疲れた段階」
そのどちらにも現実的な選択肢になり得る。
3. EspoCRMで「何ができるのか」（機能一覧）
EspoCRMに実装されている機能を紹介しよう。
3-1. 基本エンティティ（管理対象）
EspoCRMは、業務を次のエンティティ（管理単位）として定義している。
Account（アカウント）
会社・組織単位の情報を管理する。
法人顧客、取引先、仕入先などをここに登録する。
Contact（コンタクト）
個人単位の担当者情報。
Accountと紐づけて管理できる。
Opportunity（オポチュニティ）
案件・商談・見込み案件を表す。
金額、確度、進捗ステータスを持つ。
Lead（リード）
見込み顧客。
正式なAccount／Contactに昇格させる前段階の管理用。
Case（ケース）
問い合わせ、クレーム、サポート案件の管理。
Task（タスク）
個別作業の管理。期限・担当者を設定できる。
Meeting / Call（会議・通話）
予定・実施記録の管理。
3-2. ストリーム（履歴機能）
EspoCRMの中核にあたる機能。
各エンティティにはストリーム（時系列履歴）が自動で付随する。
- コメントの追加
- ステータス変更
- フィールドの更新履歴
- 関連エンティティの紐づけ
誰が、いつ、何を変更したかが記録される。
履歴は削除せず、上書きではなく積み重ねる設計になっている。
3-3. ダッシュボード
ログイン後に表示される集計画面。
- 案件数の推移
- ステータス別案件数
- 見込み金額の合計
- 自分のタスク一覧
ウィジェット単位で構成され、
ユーザーごとに表示内容を変えられる。
3-4. 権限・Role・チーム管理
EspoCRMは、Role（権限）とTeam（所属）で操作範囲を制御する。
- 読み取り専用
- 編集可能
- 削除可能
をエンティティごとに設定できる。
さらに、
- 自分が担当するデータのみ
- チーム内のみ
- 全社共有
といった可視範囲の制御も可能。
3-5. メール・カレンダー連携
メール機能
- IMAP/SMTPによるメール連携
- メール内容を履歴として保存
- 顧客・案件との自動紐づけ
カレンダー
- タスク・会議の予定管理
- 個人・チーム単位の表示切替
3-6. API・拡張性
EspoCRMはREST APIを標準で備えている。
- CRUD操作
- Webhook対応
- 外部システム連携
また、拡張モジュールによる機能追加も可能。
3-7. その他の標準機能
- フィールドの追加・カスタマイズ
- ステータス・選択肢の編集
- CSVインポート／エクスポート
- 通知機能
- 検索・フィルタ
4. 日本語対応の現実
EspoCRMは、日本語UIを備えている。
この点は事実だし、導入を検討する上で無視できない要素でもある。
ただし、「日本語対応」という言葉から想像されがちな快適さを、そのまま期待するとズレが生じる。
UI日本語化の現状
基本的な画面構成、メニュー、ボタン類は日本語化されている。
日常的な操作で英語が頻出することは少ない。
一方で、
- 設定画面の一部
- 管理者向け項目
- エラーメッセージや補足説明
には、翻訳が不自然な箇所が残っている。
意味が分からないほどではないが、
日本製業務ソフトの水準を期待すると違和感は出る。
翻訳精度にばらつきが出る理由
EspoCRMはオープンソースソフトウェアであり、
日本語翻訳もコミュニティベースで整備されてきた。
そのため、
- 用語の揺れ
- 文脈を無視した直訳
- IT寄りの言い回し
が混在している。
これは「手抜き」ではなく、
開発の優先順位がUI文言より機能に置かれている結果だ。
住所・郵便番号などの扱い
日本特有の入力文化には最適化されていない。
- 郵便番号からの住所自動補完はない
- 住所欄は海外フォーマット前提
- 全角・半角の配慮も最低限
ここに強い不満を感じる人はいるだろう。
一方で、CRMの本質機能とは直接関係しない部分でもある。
拒否反応が起きるかどうか
判断基準はシンプルだ。
- 「完璧な日本語UIでないと使えない」なら不向き
- 「意味が分かれば問題ない」なら十分実用
EspoCRMの日本語対応は、
拒絶されるほど悪くはないが、感動するほど良くもない。
この現実を理解した上で触るかどうか。
それだけで、導入後の評価は大きく変わる。
次章では、
実際に動かしてみて分かったことを、体験ベースで整理する。
5. 実地検証：実際に触って分かったこと
ここからは、実際にEspoCRMを動かしてみて分かった点を整理する。
特別な検証環境ではない。むしろ、よくある低スペック環境での話だ。
動作の軽さと初動の速さ
画面遷移が軽い。
クリックしてから次の画面が表示されるまでに、待たされる感覚がほとんどない。
案件一覧、顧客一覧、履歴の表示。
いずれも「業務用ツールとして十分に速い」という水準を安定して保っている。
サーバー要件の現実
EspoCRMは、PHPとMySQL（または互換DB）が動けば成立する。
実地検証では、
- HDDストレージ
- PHPメモリ 256MB
- 共有レンタルサーバー相当
という構成でも、日常操作に支障は出なかった。
もちろん、同時接続が増えれば話は変わる。
だが、1人〜数人規模の利用であれば、過剰なサーバー投資は不要だ。
入力が億劫にならない設計
CRMが定着しない最大の理由は、「入力が面倒」になることだ。
EspoCRMは、
- 画面の情報密度が過剰でない
- 必須項目が最小限
- 後から追記できる構造
になっている。
「とりあえず案件を作る」
「あとで詳細を書く」
この順序が自然に許されるため、
入力そのものが心理的な負担になりにくい。
一人で使っても成立する感覚
CRMは複数人向け、という先入観は根強い。
だが、EspoCRMは一人で使っても意味がある。
- 案件ごとに履歴が残る
- 判断理由を書き残せる
- 過去の自分を引き継げる
これは「共有」のためだけではない。
未来の自分への引き継ぎとして、十分に機能する。
触って分かる限界もある
当然、万能ではない。
- 日本向け業務フローに特化しているわけではない
- 帳票文化に寄り添ってはいない
- 会計や請求は別システム前提
だが、ここまでを理解した上で触るなら、
「思っていたのと違う」という落胆は起きにくい。
次章では、
なぜ多くの現場でExcelが限界を迎えるのかを、構造の話として整理する。
6. なぜExcelでは限界が来るのか
Excelは悪くない。
むしろ、優秀すぎる道具だ。
問題は、Excelが想定している役割と、
現実の業務が要求する役割が、いつの間にかズレていくことにある。
Excelが得意なのは「点」
Excelは、次のような情報を扱うのが得意だ。
- 数値
- 一覧
- 集計
- その時点での状態
これらはすべて「点」の情報だ。
単体で完結し、切り取っても意味が壊れにくい。
見積金額、売上、日付、顧客名。
どれもExcelで問題なく扱える。
現実の業務は「線」でできている
一方、実際の仕事は点では進まない。
- なぜこの案件を受けたのか
- なぜこの条件を飲んだのか
- なぜこのタイミングで断ったのか
こうした判断は、時間と文脈を伴う線だ。
Excelにもコメント欄やメモはある。
だが、それらは構造を持たない。
- どの判断が、どの案件に影響したのか
- その判断を、誰が、いつ行ったのか
この関係性は、表計算の枠外に落ちていく。
共有と引き継ぎで壊れる
Excelが限界を迎える瞬間は、だいたい決まっている。
- 人に渡したとき
- 時間が経ったとき
- 自分が忘れたとき
「この列、何の意味だっけ？」
「なぜこの金額になってる？」
答えは、セルの外にある。
そして、たいていもう残っていない。
これは操作ミスではない。
構造的に、残せないのだ。
Excelが悪いわけではない
強調しておきたい。
Excelは、
- 集計
- 分析
- 一覧化
には今でも最適解の一つだ。
ただし、
- 判断の理由
- やり取りの経緯
- 意思決定の流れ
を担わせると、無理が出る。
役割が違うだけだ。
CRMが補う場所
CRMは、Excelが苦手な「線」を残すための道具だ。
- 顧客と案件を結び
- 時系列で履歴を積み
- 判断を文脈ごと保存する
EspoCRMは、この役割に特化している。
次章では、
ではなぜSalesforceでは重すぎることがあるのかを整理する。
7. なぜSalesforceでは重すぎることがあるのか
Salesforceは優れたCRMだ。
この前提は崩さない。
ただし、すべての現場に最適とは限らない。
特に小規模組織や一人親方にとっては、重さが先に来ることがある。
コスト構造の問題
Salesforceはサブスクリプション型のサービスだ。
- ユーザー数に比例して費用が増える
- 機能追加は基本的に有料
- 長期利用を前提とした価格設計
規模が拡大すれば合理的だが、
最初の一歩としては負担が大きい。
「まだCRMが定着するか分からない」段階で、
固定費が発生し続ける構造は心理的な壁になる。
機能過多と定着の問題
Salesforceは「何でもできる」。
だが、現場ではこれが裏目に出ることがある。
- 画面に情報が多すぎる
- 設定項目が多い
- 使い方を覚える前に疲れる
結果として、
- 入力されない
- 一部の人しか使わない
- Excelとの二重管理に戻る
という状態に陥りやすい。
Excel二重管理が生まれる理由
Salesforceを導入したのに、
Excelが手放せない現場は少なくない。
理由は単純だ。
- Salesforceは「正しく使う」前提
- Excelは「とりあえず書ける」
入力が追いつかないと、
現場は即席のメモ帳としてExcelに逃げる。
CRMが“本番”、Excelが“現場”
という歪んだ分業が生まれる。
Salesforceが向いている場面
誤解を避けるために整理しておく。
Salesforceは、
- 人数が多い
- 業務フローが定義されている
- 専任管理者を置ける
こうした条件が揃うほど、力を発揮する。
逆に言えば、
そこに至る前段階では、重さが先に立つ。
EspoCRMとの決定的な違い
EspoCRMは、
「使い始めるまでの摩擦」を極力減らす方向で設計されている。
- 初期費用がない
- 画面が比較的シンプル
- 使わない機能は目に入らない
どちらが優れているかではない。
立っている位置が違うだけだ。
次章では、
EspoCRMの価値が最もはっきり現れる場面、
「引き継ぎ」という観点から整理する。
8. EspoCRMの真価は「引き継ぎ」に出る
EspoCRMの価値が最もはっきり現れるのは、
データが「共有」される瞬間ではない。
引き継がれる瞬間だ。
引き継ぎとは、作業ではなく判断を渡すこと
多くの現場で、引き継ぎはこう扱われている。
- 案件の状態
- 次にやる作業
- 連絡先
だが、本当に重要なのはそこではない。
- なぜこの条件で進めているのか
- なぜこの顧客を優先しているのか
- なぜこの選択肢を捨てたのか
つまり、判断の理由だ。
作業は追えば分かる。
判断の理由は、残っていなければ分からない。
ストリームが残すもの
EspoCRMのストリームは、単なるログではない。
- コメント
- 状態変更
- 方向転換
それらが時系列で積み重なることで、
「何が起きたか」ではなく
「どう考えて進んできたか」が見える。
これは、マニュアルでは代替できない。
上長と部下、両方を救う
引き継ぎが機能すると、
心理的な変化が起きる。
上に立つ側は、
- 逐一説明しなくてよくなる
- 進捗確認が監視にならない
- 判断を信頼しやすくなる
引き継がれる側は、
- いきなり結論を押し付けられない
- 背景を理解した上で判断できる
- 責任の所在が明確になる
これは効率の話ではない。
摩擦が減るという話だ。
一人親方にとっての「引き継ぎ」
引き継ぎは、他人に対して行うものとは限らない。
一人で仕事をしていても、
- 数か月前の判断
- 忙しい時期の妥協
- 感覚で決めた条件
は、簡単に忘れる。
EspoCRMは、
過去の自分から未来の自分への引き継ぎとしても機能する。
これは、Excelではほぼ不可能だ。
責任が可視化されるということ
判断が履歴として残ると、
責任も同時に可視化される。
だがこれは、責めるためではない。
- なぜその判断が合理的だったのか
- どこで前提が変わったのか
を後から検証できるようになる。
組織でも、一人でも、
これは強い武器になる。
9. ダッシュボードとRoleが効いてくる場面
EspoCRMのダッシュボードやRole（権限管理）は、
派手な機能ではない。
だが、実務では静かに効いてくる。
ダッシュボードは「管理」ではなく「把握」
ダッシュボードでできることはシンプルだ。
- いま、案件はいくつ動いているか
- どこで止まっているか
- 何が自分に関係しているか
数字を細かく分析するためのものではない。
状況を一目で把握するための道具だ。
これがあるだけで、
- 毎回一覧を開く
- 状況を頭で組み立て直す
といった無駄が減る。
見せる範囲を決められるということ
Roleとチーム設定により、
- 自分の案件だけ
- チーム内だけ
- 全体
と、見える範囲を制御できる。
重要なのは、
見えない情報があることだ。
すべてが見える環境は、一見便利に見える。
だが実際には、
- 関係ない情報に気を取られる
- 責任範囲が曖昧になる
という問題が起きやすい。
事故を防ぐためのRole
Roleは、統制のためだけに存在するわけではない。
- 誤操作を防ぐ
- 不要な編集を避ける
- 触らなくていい場所を触らせない
これは信頼の欠如ではなく、
事故防止だ。
人数が少ないほど、
一度のミスがそのまま業務停止につながる。
零細規模で「ちょうどいい」理由
EspoCRMのRoleとダッシュボードは、
- 設定が過剰にならない
- 運用ルールを厳密に決めなくても回る
という点で、零細規模と相性がいい。
「最初から完璧なルール」を作らなくていい。
必要になったところから、少しずつ締めていける。
この柔らかさは、
現場では意外と重要だ。
10. 導入の現実解（最初の一歩）
EspoCRMの導入は、構えすぎると失敗する。
最初に目指すべきは「正しい構成」ではなく、動く状態だ。
LAMPレンタルサーバーで十分始められる
EspoCRMは、特別な環境を要求しない。
- Linux
- Apache（または互換Webサーバー）
- MySQL（または互換DB）
- PHP
いわゆるLAMP構成で問題なく動く。
共有レンタルサーバーでも、条件が合えば導入できる。
最初から専用サーバーを用意する必要はない。
DockerやTrueNASは「慣れてから」でいい
DockerやTrueNASを使えば、
環境の再現性やバックアップは確かに楽になる。
だが、それは次の段階の話だ。
最初から環境構築に力を入れすぎると、
- 触る前に疲れる
- 本来の目的を忘れる
という事態になりやすい。
まずは、
「案件を1つ登録する」
「履歴を1つ残す」
そこまで到達できれば十分だ。
最初から本番を目指さない
CRM導入でよくある失敗は、
最初から“正しい使い方”を定義しようとすることだ。
- 項目を作り込みすぎる
- ルールを決めすぎる
- 例外を許さない
EspoCRMは、後から修正できる。
最初は、
- 必須項目は最低限
- 入力ルールも緩め
で構わない。
Cronやバックアップは後回しでいい理由
もちろん、
定期バックアップやCron設定は重要だ。
だが、最初の壁はそこではない。
多くの場合、
- 入力されない
- 見返されない
- 使われなくなる
ここで止まる。
「使われるかどうか」が確認できるまでは、
運用の厳密さを上げすぎないほうがいい。
最初の一歩の目標
最初のゴールは、これだけだ。
- 案件が登録されている
- 履歴が残っている
- 後から見返して意味が分かる
これが成立したなら、
EspoCRMはすでに価値を出し始めている。
11. なぜ「今」CRMなのか（AIブームとの関係）
いまCRMの話をすると、
どうしてもAIの話題と結び付けられがちだ。
だが、順序を間違えると話は空回りする。
AI以前の前提条件
AIが何かを「考える」ためには、材料が要る。
- 顧客が誰か
- どんな案件があるか
- これまで何が起きたか
この前提がなければ、
AIは推測か一般論しか返せない。
それは賢さではない。
データがないAIは役に立たない
現場でよくあるのは、こういう状態だ。
- 顧客情報はExcel
- 案件管理はメール
- 判断理由は頭の中
この状態でAIを入れても、
AIが参照できる「現実」は存在しない。
結果として、
- もっともらしいが使えない回答
- その場しのぎの要約
- 意思決定に使えない助言
が増えるだけになる。
CRMはAIのための下準備ではない
誤解しないでほしい。
CRMは、AIを使うために導入するものではない。
順番は逆だ。
- 人が判断する
- その過程を残す
- 結果としてデータが溜まる
この延長線上に、
AIが使える状態が生まれる。
EspoCRMが置かれている位置
EspoCRMは、AI機能を前面に出してはいない。
それは遅れているからではない。
- 顧客
- 案件
- 履歴
この三点を、
破綻なく積み上げることに集中している。
これは、AI時代においても無駄にならない。
「AI前夜の足場」という位置づけ
EspoCRMは、
未来の魔法を約束する道具ではない。
だが、
- 判断が残り
- 履歴がつながり
- 関係性が見える
この状態を作れる。
AIが価値を持つかどうかは、
この足場があるかどうかで決まる。
12. まとめ：EspoCRMは救世主か？
EspoCRMは、魔法の道具ではない。
導入した瞬間に売上が伸びたり、
業務が自動で整理されたりはしない。
できることと、できないこと
EspoCRMができるのは、あくまで次のことだ。
- 顧客と案件を結び付ける
- 履歴を時系列で残す
- 判断の流れを可視化する
逆に言えば、
- 営業力を代替する
- 判断を肩代わりする
- 経営を自動化する
そうしたことはしない。
過度な期待をすれば、
必ず期待外れになる。
順番を正せば、確実に効く
EspoCRMが効く条件は明確だ。
- Excelで管理しきれなくなっている
- 情報が点在し始めている
- 判断の理由が残らなくなっている
この段階で導入すれば、
効果は静かに、しかし確実に現れる。
逆に、
「何となく必要そうだから」
「流行っているから」
という理由では、定着しない。
金がないことは、言い訳にならない
EspoCRMは、OSSとして無償で使える。
必要なのは、最低限のサーバー環境だけだ。
つまり、
金がないからCRMを使えない
という言い訳は、ここでは通用しない。
残るのは、
使うか、使わないか。
残すか、忘れるか。
静かに効く道具
EspoCRMは、
目立たない。
派手なデモもない。
AIの未来を声高に語らない。
だが、
- 判断が残り
- 履歴がつながり
- 引き継ぎが成立する
その積み重ねが、
後になって効いてくる。
救世主かどうかは、
使う人の置かれた状況次第だ。
少なくとも、
順番を間違えなければ、裏切らない道具ではある。
補章：公式Docker Composeで入れるなら、ここに注意
EspoCRMは公式ドキュメントにDocker Compose例があり、そのままでも動く。
ただし「動いた」と「運用上まともに動いた」は別で、検証でハマるのはだいたい設定値のURL系だ。
1) ESPOCRM_SITE_URL は「ブラウザでアクセスしているURL」と完全一致させる
公式もここを「非常に重要」と明言している。
ズレると地味に効く。
- ログイン後のリダイレクト
- リンク生成
- メールテンプレのURL
- WebSocket周り
検証中は、アクセス方法を固定するのが正解。
例：VMに http://192.168.1.170:8080 で入るなら、ESPOCRM_SITE_URL もそれに固定。
2) WebSocketを有効にするなら、ESPOCRM_CONFIG_WEB_SOCKET_URL の “localhost” は地雷になり得る
公式のcompose例ではこうなっている。
ESPOCRM_CONFIG_WEB_SOCKET_URL: "ws://localhost:8081"
この localhost は “ブラウザ側” から見た localhost になる。
VM上で動かしていて、クライアントPCからアクセスしているなら、ブラウザのlocalhostは「クライアントPC自身」だ。結果、UIがそれっぽく動いて見えても、リアルタイム通知などが死ぬ。
検証で外さない最小修正はこれ。
ws://<VMの実IP>:8081に置き換える
将来リバプロ＋HTTPS化するなら、wss://crm.example.com/... の形に寄せるのが自然。
3) パスワード直書きは検証なら可、記事では .env に逃がすのが現実解
公式例もパスワードはyamlに直書きだが、記事としては最低限の作法を見せたほうが信頼される。
.envに退避（中小零細〜一人運用の現実解）
4) tcp://*:7777 が気持ち悪い件は「確認ポイント」として書くのが強い
公式例でも ESPOCRM_CONFIG_WEB_SOCKET_ZERO_M_Q_SUBSCRIBER_DSN: "tcp://*:7777" になっている。
普通のDockerネットワークならLANに露出しにくいが、環境によっては “広がって見える” 構成もあり得る。
- WebSocketコンテナ内で どのIFにlistenしているかを一回見る
- ホスト側から7777が見えていないことを確認する（見えるならネットワーク設計の問題）
5) daemon / websocket を分けているのは、地味だけど「運用に効く」ので褒めてよい
公式composeがそもそも espocrm-daemon と espocrm-websocket を分けている。
「画面だけ動いたCRM」ではなく、バックグラウンド処理・通知まで含めて成立させる、という意図が見える。ここは実務目線で好印象。
インストールや初期セットアップ、使い方などについては、今後記事でフォローしていく予定。
