ERPNextのアーキテクチャ解説

ERPNextのアーキテクチャを徹底解説。Redis・Socket.IOによるリアルタイム通知・Workerによる非同期処理など、モダンな仕組みを図解で紹介します。

8分
最終更新: 2025年9月12日

ERPNextのアーキテクチャ解説|Redis・Socket.IO・Workerで実現するモダンERP

ERPNextのモダンアーキテクチャ

はじめに

「ERP」と聞くと、古臭くて、重くて、カスタマイズしにくいシステムを思い浮かべる人が多いかもしれません。 しかし、ERPNextはそのイメージをひっくり返すほど、モダンな技術で動いています。

中身をのぞいてみると、Redis・Socket.IO・RQ(Redis Queue)といった、モダンなWebアプリと同じ技術で動いているのです。

  • Slackみたいにリアルタイム通知の仕組み
  • ワーカーによる非同期処理
  • スケールアウトの仕組み

本記事を読むと、ERPNextの内部構造を「図解」で理解でき、導入やカスタマイズを考えるエンジニアにとって大きなヒントになります。


ERPNextの全体構成図 ― シンプルでモダンなアーキテクチャ

ERPNextの全体構成は一見複雑に見えますが、整理するととてもシンプルです。
大きく分けると次のレイヤーで成り立っています。

ERPNextの全体構成図

  • Nginx: 入口でリクエストを受け止め、静的ファイルやSSLも担当
  • Node.js + Socket.IO: リアルタイム通知をさばく
  • Gunicorn: Pythonアプリ(Frappe/ERPNext)への橋渡し
  • Redis: キャッシュ、キュー、通知を担当(ここがミソ!)
  • ERPNext: DocTypeや業務ロジックを処理
  • ワーカー: 非同期処理を担当
  • MariaDB: データを保存するRDB
  • Supervisor: 上記プロセスをまとめて監視

つまりERPNextは、FlaskやDjangoアプリを運用するときの構成に、
「Redis」と「Socket.IO」を加えた、今どきのモダンなWebアプリのような作りになっています。

🔶Redis
Redisは、キャッシュによる高速化、キューによる非同期処理、通知によるリアルタイム性を担当します。

🔶Socket.IO
Socket.IOは、通信料の増加を招くポーリングに頼らず、リアルタイム通信を担当します。

🔶ワーカー
時間のかかる処理をRedis Que→ ワーカーに実行させることで、待たされずに快適な操作性を実現

「ERP」と聞くと巨大なモノリスを想像しますが、ERPNextは今どきのWebサービスとほぼ同じ構成です。


ERPNextのリアルタイム処理 ― Slack級の通知体験をSocket.IOで実現

ERPといえば「更新したらリロードして確認」というイメージがあるかもしれません。
でもERPNextは、Slack級のリアルタイム通知を備えています。

仕組みは、

  • サーバー側:frappe.publish_realtime("event", data) で通知を発火 Redis →Node.js + Socket.IO → クライアント
  • クライアント側:frappe.realtime.on("event", handler) で即時受信

これにより、たとえば 承認フロー等の情報が更新されたら、別のユーザの画面も即反映されます。

つまり「Slackの既読通知が飛んでくる仕組み」とほぼ同じ。
ERPなのに「チャットアプリのような体験」ができるのは大きな驚きです。

ERPNextのリアルタイム処理

もちろん、ポップアップ通知も表示可能です。 ERPNextのリアルタイム処理


ERPNextの非同期処理 ― Redis QueueとWorkerでPDFやメールを効率化

PDFの生成や大量メール送信など、時間がかかる処理を「画面のレスポンスに乗せる」と遅くなってしまいます。
そこでERPNextでは Redis Queue (RQ) + Worker が登場します。

  • ユーザーの操作は enqueue() で「ジョブ」としてキューに投げられる
  • Workerが裏で処理を実行
  • 終わったら結果を保存し、ユーザーには「完了しました」と通知

これはまさに、Gmailの送信予約や、夜間バッチ処理と同じ発想です。

ERPなのに「裏方でジョブをさばくWorkerがいる」というのは、
エンジニアからすると「やっぱりモダンなWebアプリと同じじゃん!」と思えるポイントです。

ERPNextのプロダクション構成 ― 小規模導入から大規模運用までスケール自在

ERPNextは、アーキテクチャがしっかり作られているので、
最初はサーバー1台に「全部入り」で動かしても30人程度のユーザ規模なら全く問題なく使えます。
これは、スタートアップや中小企業が「まずは試してみる」に非常に便利です。

でも事業が成長して、アクセス数や処理が増えてくると「全部入り」では限界が来ます。
そこで登場するのが 役割ごとの分離 です。

  • Web系(Nginx + Gunicorn) → ユーザーからのリクエスト処理
  • Worker系(RQ Worker, Scheduler) → バックグラウンド処理担当
  • Realtime系(Node.js + Socket.IO) → 通知・チャット担当
  • DB(MariaDB) → データ保存

これらをそれぞれ別サーバーに分けるだけで、パフォーマンスが一気に改善します。

さらに、Supervisorやsystemdでプロセスを監視・再起動すれば、
安定稼働を保ちながら「クラウドネイティブっぽい柔軟さ」を手に入れられるのです。

もちろん、ERPNextはこれらのスケールアップにも柔軟に対応しています。


ERPNextのスケールと高速化 ― Redis分割とMariaDBレプリカで性能を最大化

ERPNextの良いところは、成長に合わせて自然にスケールできること。

  • Webサーバーを増やす → Nginxをロードバランサー化して水平分散
  • Workerを増やす → PDF生成やメール送信の処理を同時並行でさばく
  • Socket.IO専用サーバーを置く → 通知の遅延を防止
  • Redisを役割ごとに分割 → cache/queue/socketioを別インスタンスに分けて安定化
  • MariaDBリードレプリカ → 読み込み系を分散し、書き込みの負荷を軽減

こうしてみると「ERPNext = レガシーな一枚岩アプリ」ではなく、
中小企業から大規模利用まで“無理なく育つ”モダンな基盤だと分かります。

他のERP製品では「大規模版=別製品」になりがちですが、
ERPNextは同じアーキテクチャをそのままスケールできるのが大きな強みです。

つまりERPNextは、“小さく始めて、大きく育てられるERP” なのです。

まとめ ― ERPNextはRedisとSocket.IOで動く現代的Webアプリ基盤

ここまで見てきたように、ERPNextは「レガシーなERP」のイメージを大きく覆します。

  • Slack級のリアルタイム性:承認や更新が即時に反映される体験
  • Workerによる裏方処理:重い処理をバックグラウンドでスマートに処理
  • スケールアウト:サーバーを増やすことで負荷を分散し、スケールアウトできる仕組み

これらの仕組みは、エンジニアが日常的に触れている モダンなWebアプリの設計思想 そのものです。
つまりERPNextは、「ERP」というよりも “現代的Webアプリの集合体” と呼んだ方がしっくりきます。


MyHatchのERPNext導入支援サービス ― 小さく始め大きく育てる伴走型サポート

私たち MyHatch では、このモダンなERPNextを日本企業にフィットさせるための支援を行っています。

  • 導入相談(ERPNext駆け込み寺):無料で気軽にERPNextの可能性を相談できる場
  • 伴走型支援:要件整理からプロトタイプ構築、カスタマイズ開発までを一貫して支援
  • 業種別テンプレート:製造業・不動産・農業など、日本企業が使いやすい形にプリセット済み

単なる「ERPの導入支援」ではなく、Redis三刀流やSocket.IOによるモダンな仕組みを活かしながら、
お客様の業務に合わせて 小さく始め、大きく育てられるERP を一緒に育てていきます。


ERPNextを「ただのERP」としてではなく、モダンな基盤として理解することは、
導入やカスタマイズに挑戦するエンジニアにとって大きな力になります。

そして、その一歩をMyHatchが伴走します。


あわせて読みたい

まだ疑問が残りますか?

この記事で解決しない疑問は、無料相談でお気軽にご質問ください。ERPNext導入の専門家が直接お答えします。