NATSのシステム開発の完全ガイド - ブログ

NATSのシステム開発は、Core NATSの低遅延配信とJetStreamの保存・再処理を役割で使い分け、業務システムとのイベント連携を設計することです。

「NATSのシステム」と検索すると航空管制など別の名称も表示されるため、対象はクラウドネイティブなオープンソースのNATS.ioです。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

NATSのシステムの全体像

連携先を増やしても、各サービスは相手の内部実装に依存しません。

NATSは、アプリケーション同士がメッセージを送受信する通信基盤です。イベントを介して連携するため、機能追加や一部サービスの停止に強い構成を作りやすくなります。

業務システムは、NATSのほかに正本データを保管するデータベースや業務アプリケーションを含め、役割を分けて設計します。

複数のサービスを非同期でつなぐ基盤

NATSでは、送信側がSubjectという論理的な宛先へメッセージを発行し、受信側は必要なSubjectを購読します。

採用・人材サービスでは、イベントを種類ごとに分けられます。たとえばcandidate.registered、application.received、interview.bookedがそれにあたります。

応募受付サービスは、面接サービスの内部実装を知らなくても連携できます。さらに、通知、分析、監査などの別の処理も、同じイベントを購読して追加できます。

Core NATSのPub/Sub・Request/Reply・キュー

Core NATSには、1対多のPub/Sub、要求と応答を組み合わせるRequest/Reply、Queue Groupによるワーカーの分散があります。接続中の購読者へすぐ通知する用途に適しています。

軽量なプロトコルと単一バイナリのNATS Serverは、クラウドや拠点、エッジ端末にも展開しやすい特徴があります。停止中の購読者へ後から配信する要件があれば、JetStreamを検討します。

業務データベースやATSとの役割の分担

NATSは、求人情報、候補者属性、履歴書本文、面接記録を管理する業務データベースや採用管理システムの代わりにはなりません。そのため、個人情報の正本は、アクセス制御されたRDBや既存システムに置きます。

また、NATSに送るのは、イベント名、対象ID、発生時刻、相関ID、スキーマバージョンなどです。役割の境界が曖昧だと、保持期間、再処理時のマスキング、削除請求への対応が難しくなります。

NATSの種類と主要機能の使い分け

停止中の購読者にも後から届ける要件が、選択の分かれ目です。

リアルタイム配信だけでよいか、停止中も保存して再処理するかによって、選ぶ機能が変わります。そのため、業務要件に必要な保証を基準に選びます。

Core NATS：低遅延の通知
JetStream：メッセージの永続化と再生
Key-Value：小さな状態の共有
Object Store：オブジェクトの分割保存

大規模な業務DBや長期保管用ファイル基盤は、Object Storeの代替用途として設計しません。

Core NATSの接続中イベント配信

Core NATSの接続中の配信は、目的に合わせて3つの方式を使い分けます。

Pub/Sub：同じイベントを複数の処理へ素早く届ける仕組み
Request/Reply：サービス間の照会や軽量なRPCに使う方式
Queue Group：通知送信や画像変換などの仕事を、複数のワーカーへ水平分散する仕組み

Queue Groupでは、同じグループ内の1つのワーカーが処理します。ただし、接続していない購読者への配信や、サーバー障害後の再生は自動では保証されません。

JetStreamの保存・再送・再処理

JetStreamは、NATS Serverに組み込まれた永続化エンジンです。StreamにSubjectのメッセージを保存し、Consumerが配信位置とAckを管理します。

保持期間や最大サイズ、最大件数を設定できます。破棄方法、ファイルかメモリかの保存先、レプリカ数も決められます。これにより、業務イベントを後から再生する設計が可能になります。

NATS公式ドキュメントでは、ファイル保存のレプリカ数3について、1台の障害に耐えながら性能とコストのバランスを取りやすい構成と説明されています（出典：NATS公式JetStreamドキュメント、2026年確認）。

Key-ValueとObject Storeの補助的な状態管理

Key-Valueは、サービスの設定やフラグ、軽量な状態の共有に向いています。Object Storeは、メッセージサイズの制約を避けるために、オブジェクトを分割して保存します。ただし、大規模な業務DBや長期保管用ファイル基盤の代替用途としては設計しません。

履歴書ファイルは業務ストレージに置き、参照先と検証用ハッシュをイベントに含めます。そうすると、権限管理と削除対応を整理しやすくなります。

ポイント

リアルタイム配信で足りるか、停止中の購読者へ保存して再処理するかで、使う機能が決まります。迷ったときは、業務要件に必要な保証から逆算すると判断しやすくなります。

NATSとKafka・RabbitMQの違い

製品選びでは、遅延、保持期間、順序性、スループット、既存の運用、チームの習熟度を比べます。NATSが常に最適とは限らないため、業務上の保証を満たす製品を選びます。

NATSは、サービス間通信とイベント処理を軽量な基盤で扱い、クラウドからエッジまで同じ考え方で展開したい場合に適しています。

長期保存と大規模分析を重視する場合のKafka系

大量のイベントを長期保持し、パーティション単位で並列処理して分析基盤へ流す要件では、Kafka系が候補になります。

運用監視、スキーマ管理、データ連携、分析基盤がすでにあれば、既存の資産を活かせる可能性があります。一方で、単純なサービス間通知まで大規模な運用基盤に寄せると、構築・監視・障害対応の負担が増えることがあります。

ジョブキュー中心の場合のRabbitMQ系と処理保証

業務ジョブのルーティング、キュー、Ack、再試行を中心にする場合は、RabbitMQ系も比較対象になります。なお、NATSでもQueue GroupやJetStream Consumerを使えば、ワーカーを分散できます。

既存チームの運用経験の有無によって、実装リスクは変わります。障害時の再送判断、失敗メッセージの隔離先、再処理の開始点も確認しておきます。

比較の軸は速度より業務上の保証

まず、失われてもよい通知と、必ず処理する業務イベントを分けます。そのうえで、次の4つの軸で比べます。

配信：配信回数と、重複時の冪等性
順序・保存：並び順の範囲と保存期間
再処理：やり直しの方法と最大遅延
運用：想定メッセージ量と運用担当者

JetStream Consumerは未Ackのメッセージを再配信できます。ただし、外部への副作用を一度だけにする機能ではありません。

公式資料の基本保証はat-least-onceのため、決済や登録処理では冪等キーを設計します（出典：NATS公式JetStreamドキュメント、2026年確認）。

NATS公式の2025年の移行事例では、RabbitMQからNATSへ移行しています。この事例では、p99遅延が約150msから約40msへ改善したと報告されています（出典：NATS公式公開事例、2025年）。さらに、運用時間も週数時間から1時間未満へ改善しました。

この数値は、メッセージ量、処理内容、インフラ構成、測定方法に依存します。自社のPoCで同じ改善が保証されるわけではありません。

NATSのシステム開発の進め方

開発では、イベントと配信保証を整理し、小さく検証してから本番構築へ進みます。ATSやCRM、求人媒体などを連携する場合は、データの責任範囲と業務フローを先に定義します。

PoCでは速度だけでなく、停止や再接続への対応まで試験します。重複や再送、復旧の手順も含めて確かめます。

要件定義のイベントと配信保証

要件定義では、業務に必要なイベントと配信保証を次の4つの観点で整理します。

処理候補：同期APIでは時間がかかる処理、再試行したい処理、複数システムへ通知したい処理
イベント情報：発行元と購読者、Payloadの中身、個人情報の有無
時間条件：最大遅延と保存期間、再処理期限の一覧
配信保証：at-most-once、at-least-once、実質的なexactly-onceのうち、必要な保証を選んで合意

exactly-onceという言葉だけで合意すると、メール送信やDB更新まで一度だけ実行されると誤解しやすくなります。そのため、業務処理のトランザクション境界を具体的に決めます。

PoCの小さなイベントフロー

PoCで確かめる範囲は、候補者登録から面接予約通知までの1本のフローなどに絞り、保存、再送、負荷の3つの面を試します。

複数の購読者とJetStreamの保存の動作
ConsumerのAck、失敗時の再送、重複処理の挙動
負荷上昇時のバックプレッシャーへの対応

DockerやKubernetesで起動できたことだけでは、確認として十分ではありません。試験データには実際の個人情報を使わず、匿名化したデータを使います。

合格基準には、処理件数と遅延（p95またはp99）を置きます。加えて、再送回数、復旧時間、ストレージ増加量も決めます。

本番設計のクラスタ・ストレージ・監視

本番設計では、可用性と運用を踏まえて次の4点を決めます。

配置：NATS Serverの置き方とクラスタ間通信
アクセス：TLS、認証、認可の設定
保存：JetStreamのファイルストレージ、バックアップ、レプリカ数
取得方式：新規案件ではPull型Consumerを候補にし、処理側でバッチ数と取得タイミングを制御

リージョン障害時の復旧方法も、あらかじめ定めておきます。

監視では、接続数やエラー、Consumerの滞留、Ack待ち、再送を見ます。さらに、ストレージ使用量とクラスタのQuorum状態も監視します。アプリのログだけでは見えない遅延も把握します。

移行とリリースの二重配信・段階切り替え

既存基盤や古いNATS Streaming系から移行する場合は、全トラフィックを一度に切り替えず、段階的に進めます。

まず二重配信とカナリア切り替えを行い、処理結果の照合、監視、ロールバックを確かめます。そのうえで全体切り替えを行い、最後に旧系を停止します。

新規案件では、NATS StreamingやSTANではなく、JetStreamを前提にします。クライアントライブラリとサーバーの互換性も確認します。

ポイント

要件定義で配信保証を合意し、PoCで停止・再接続・重複・再送まで試したうえで本番へ進みます。迷ったときは、業務上の保証を基準に判断します。

NATSのシステム開発費用の相場

NATSはオープンソースですが、開発費はライセンス費だけでは決まりません。見積もりを左右するのは、イベント設計、既存連携、JetStreamの保存・再処理の工数です。そのほか、認証、監視、障害訓練、移行の工数も影響します。

次の目安は、2026年時点の一般的な開発相場と、NATS導入で必要になりやすい非機能や連携の工数から推定したものです（出典：一般的なシステム開発費用相場、2026年確認）。

▶ 詳細はこちら：NATSのシステム開発の見積相場や費用/コスト/値段について

PoCは50万〜200万円、本番連携は800万〜2,000万円の目安

技術検証のPoCは、1〜3サービス、Core NATSまたはJetStream、負荷・再接続・再送の試験を含み、50万〜200万円、2〜6週間が目安です。

3〜8サービスの小規模MVPは300万〜800万円、2〜4か月程度です。5〜20サービスと既存ATSやRDBを連携する本番業務連携は、800万〜2,000万円、4〜9か月程度です。

本番業務連携には、HAクラスタ、監視、バックアップ、障害訓練を含みます。複数リージョンや大規模な移行では、1,500万〜5,000万円以上になる場合があります。

費用の内訳：人件費・インフラ・運用設計

見積もりは、開発の工程ごとに分けて確認します。前半は要件定義、イベント設計、アプリ実装、インフラ構築で、後半はテスト、移行、運用引き継ぎです。

NATS Serverの利用料を抑えられても、クラウドのコンピュートやディスク、バックアップ、転送には費用がかかります。さらに、監視や証明書、Kubernetes運用、夜間対応にも費用がかかります。

マネージドサービスでは、接続数、ストレージ、転送量、保持期間、SLAを確認します。月額のサービス費と初期の開発費は、別々に比較します。

費用を抑える方法：保証と対象範囲の絞り込み

最初から全社のイベントを移さず、失敗時の影響が限られ、効果を測りやすい1業務をPoCに選びます。たとえば、再送が不要な通知と、必ず再処理したい応募受付は分けて扱います。

必要なイベントだけをJetStreamへ保存します。さらに、個人情報のPayloadを減らし、イベントを参照型にすると、保持・監査・削除対応の工数を減らせます。

ただし、監視や復旧手順を削りすぎると、本番障害時の損失が大きくなります。削減の対象は、開発範囲と段階に限ります。

ポイント

費用は、PoC、MVP、本番連携のどの段階かで大きく変わります。見積もりでは、イベント設計や既存連携、監視、障害訓練の範囲をそろえて比べます。

個人情報を扱うNATSのセキュリティ設計

詳細情報は正本データを参照し、イベントには識別に必要な項目を載せます。

採用・人材システムは、候補者情報、履歴書、面接記録、雇用書類を扱います。NATSの認証・認可を設定するだけでなく、イベント情報、保存期間、再処理の権限も業務要件として定めます。

人事労務クラウドの安全管理では、開発段階からアクセス制御、不正アクセス対策、委託先監督を検討するよう注意喚起されています（出典：個人情報保護委員会、2024年）。

イベントに載せる情報：IDと最小限の属性

Payloadの内容と、保存先に残る情報の扱いを、次の5つの観点で整理します。

個人情報：氏名や履歴書本文はPayloadに含めない
イベント項目：候補者ID、種別、発生時刻、相関ID、スキーマバージョン、最小限の属性
詳細情報：必要な受信側が権限を確認したうえで、正本データを参照
保存先：ログ、Dead Letter Queue相当の隔離領域、JetStreamのバックアップには、同じ情報が残る可能性があります。
マスキングと保持：保存先ごとに、隠す範囲と保存期限をそろえます

TLS・NKey・JWT・Subject権限による境界の分離

TLSで通信を暗号化し、クライアントやサービスごとに認証情報を分けます。

NKey・JWT・Accountと、Subject別のPublish・Subscribe権限により、通知サービスの詳細な購読を制限します。さらに、認証の更新と失効、監査ログ、開発・検証・本番の分離も行います。

Leaf NodeやGatewayで拠点とクラウドをつなぐ場合は、接続先ごとの信頼境界とデータ越境の有無も確認します。

AI連携のプライバシーと説明責任

AI面接、候補者推薦、問い合わせ自動化をNATSで連携する場合は、AIの利用目的、入力データ、保存期間、出力の確認者、本人への説明方法を定義します。

AI事業者ガイドラインは、プライバシー、透明性、説明責任などを整理しています。そのうえで、採用判断に関わる処理ほど、人間の確認と監査経路を残します（出典：経済産業省「AI事業者ガイドライン」第1.2版、2026年更新）。

ポイント

個人情報はイベントに入れず、IDと最小限の属性だけを送り、詳細は正本から参照します。TLSや認証、Subject権限、保持期限も業務要件として定めます。

NATSの開発会社・ベンダーの選び方

開発会社は、NATSを知っているかどうかよりも、実運用の経験で選びます。重視するのは、JetStreamの本番運用、イベント駆動設計、既存連携、個人情報の扱い、再処理です。

開発会社については、クラウドかオンプレミスかの前提と、障害や復旧の説明力も見ます。

JetStreamの本番運用と障害対応の確認項目

Streamの保持方針、ConsumerのAck待ち、最大再送回数、失敗イベントの隔離を、開発会社に質問します。レプリカ数、バックアップ、復旧テストの実施結果も確認します。

可能であれば、匿名化した構成図や運用手順を見ます。重複時やConsumerが長時間停止した場合に、担当者と復旧手順も確かめます。

業務ドメインと既存システム連携の経験

NATSの設定だけを依頼しても、業務イベントの粒度やデータ整合性が未定なら、作り直しになります。

採用・人材領域では、求人から請求、通知までのどこをイベント化するかを整理できる体制を選びます。

既存ATSやCRM、RDB、外部APIとの連携が提案に含まれるかを確認します。さらに、段階移行、データ照合、ロールバックの方法も見ます。

見積もりの前提と保守体制の比較

相見積もりでは、「オープンソースだから安い」という説明だけで判断せず、前提と保守範囲をそろえて比べます。

見積もり範囲：PoC、MVP、本番、移行、保守ごとの人月やインフラ費
運用条件：監視、バックアップ、障害対応、更新、ドキュメントのどこまでを含むか
保守体制：NATS Server 2.14などへの追随、クライアント更新、脆弱性対応、夜間受付、復旧目標
事例の再現性：公開事例を参考にしつつ、自社PoCで検証する

公開事例は、メッセージ量や構成が自社と異なるため、数値をそのまま当てはめられません。

▶ 詳細はこちら：NATSのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：NATSのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

▶ 詳細はこちら：NATSのシステム開発の発注/外注/依頼/委託方法について

ポイント

開発会社は、JetStreamの本番運用や業務ドメインでの連携経験を見て選びます。見積もりは前提と保守範囲をそろえ、公開事例を自社のPoCで確かめて比べます。

NATS導入で起こりやすい失敗と対策

NATS導入の失敗は、性能不足よりも、保証と運用の設計不足から起こりやすくなります。Core NATSとJetStreamの選択、重複、個人情報、Subject権限、Consumerの滞留を曖昧にしたままだと、本番で復旧できないことがあります。

代表的な失敗を先に確認し、要件定義とPoCの試験項目へ落とし込みます。

Core NATSだけで再処理まで期待する失敗

接続中の購読者への通知であれば、Core NATSで足ります。停止中のサービスに復帰後のイベントを届けるには、保存と再処理の設計が必要です。

アプリごとに再送を追加すると、重複、順序、バックオフ、失敗の隔離がばらつきます。JetStreamを使う場合は、保持期間、Ack、再送回数、再処理の開始位置を決めます。

重複しない前提で外部処理を実装する失敗

DB更新の後にAckだけが失敗すると、同じメッセージが再配信されることがあります。そこで、イベントIDや業務キーを保存して二重処理を無害化し、処理済みの記録と業務更新の整合性を保ちます。

外部APIの再試行方針も、あわせて組み合わせます。送信側に重複排除用のIDを持たせ、重複の条件を監視できるようにします。

個人情報をメッセージとログへ広げる失敗

履歴書や面接記録をPayloadへ入れると、購読者、ログ、バックアップ、再処理環境へ情報が複製されます。イベントにはIDと必要な状態だけを送り、詳細は権限管理された正本から参照します。

機微情報を送る場合は、暗号化、マスキング、アクセスログ、保存期限、削除手順、委託先の責任範囲を設計書に明記します。加えて、テストデータに実データを使わない運用も徹底します。

NATSのシステムに関するよくある質問

NATS導入前には、料金、JetStreamの要否、既存連携、障害時のメッセージ、個人情報について質問が集まります。

判断を誤りやすい点を、一問ずつ短く答えます。

NATSは無料で使えますか？

NATS Serverはオープンソースですが、システム全体が無料になるわけではありません。サーバー、ストレージ、バックアップ、監視の費用が発生します。さらに、TLS証明書の更新や障害対応にも費用がかかります。

マネージドサービスでは、契約プラン、接続数、転送量、保持容量、SLAを確認します。

開発費と月額費を分けて予算化します。

JetStreamは必ず導入する必要がありますか？

接続中のサービスへの通知だけで、取りこぼしが業務上許容されるなら、Core NATSで足りる場合があります。

停止中のイベント保存、Ackに応じた再送、後からの再生、処理状況の追跡には、JetStreamを選びます。

イベントごとに保存要否を分けられるため、すべてを一律にJetStreamへ入れる必要はありません。

NATS StreamingやSTANは今から使えますか？

新規開発と既存環境の保守では、確認事項が異なります。

新規開発：NATS StreamingやSTANを前提にせず、後継のJetStreamを検討
既存環境：サーバー、クライアント、保存データ、Consumerの挙動の確認
移行計画：二重配信と段階切り替えを組み合わせる方法
コードと互換性：古いサンプルコードを避け、現行の公式資料とクライアントの対応バージョンを確認

NATSはKafkaやRabbitMQより優れていますか？

NATSが優れているかは、優劣ではなく、要件と運用体制に合うかどうかで決まります。低遅延のサービス間通信、軽量な構成、クラウドからエッジへの展開を重視するなら、NATSが候補になります。

長期保存と分析、既存の運用ノウハウ、特定のルーティング機能を重視する場合は、他の基盤もPoCで比較します。

障害が起きたらNATSのメッセージは消えますか？

Core NATSは接続中の購読者へ配信し、停止中の購読者向けの保存を標準では提供しません。JetStreamでは、保持期限、容量、破棄方針、ストレージ種別、レプリカ数を設定できます。

設定した期間や容量を超えると削除されます。そのため、バックアップ、レプリケーション、再処理手順、復旧試験まで設計し、保存していれば絶対に消えないとは考えません。

開発会社への見積もり依頼に何を準備すればよいですか？

準備するのは、システム構成図と、連携したい業務の一覧です。加えて、1日または1分あたりのメッセージ量、許容遅延、保存期間、復旧目標を示します。さらに、個人情報の有無と、クラウドやオンプレミスの制約も伝えます。

イベント例を3〜5件、成功・失敗時の業務フロー、保守の受付時間も添えると、会社ごとの条件を揃えやすくなります。要件が未確定なら、本番の見積もりを急がず、PoCの範囲と合格基準から相談します。

NATSのシステム開発を成功させるためのまとめ

NATSは、マイクロサービス、採用・人材システム、IoT、AI連携などを非同期でつなぐ基盤です。Core NATSは低遅延通知、JetStreamは保存・Ack・再送・再処理、Key-ValueとObject Storeは補助的な状態管理に向きます。

NATS Server 2.14では、JetStreamへの高速バッチ公開やサーバー側のスケジュールなどが強化されています。

今後もバージョン更新と運用設計を合わせて考えます（出典：NATS Server 2.14リリース、2026年）。

導入前の確認項目

導入前には、発行元と購読者、Core NATSかJetStreamかを決め、配信保証と冪等性を確かめます。保持期間と再処理、個人情報の最小化、TLS・認証・Subject権限も見ておきます。さらに、監視やバックアップ、障害訓練の計画も確認します。

費用はPoC、MVP、本番、移行、保守に分けて、速度だけでなく復旧時間と運用責任も比べます。加えて、NATSを業務DBの代わりにせず、正本データとイベント連携の境界を明確にします。

1つの業務イベントから始めるPoC

導入を検討する場合は、効果を測りやすい業務イベントを1つ選び、匿名化データでPoCを実施します。処理量、遅延、重複、再送、停止復旧、監視の合格基準を決めます。

その基準を踏まえて、本番の対象範囲と見積もりを段階的に広げます。相談時は、技術名だけでなく、障害時にどこまでを誰が受け持つか、運用手順も確認します。

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。