NATSのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

NATSのシステム開発は、業務イベントと配信保証を整理して方式を選び、要件整理から定着まで6つのフェーズを順に進めます。設計・テスト・運用まで順番に進めると、連携が失敗したときに復旧できる仕組みにつながります。各テーマの詳細は関連記事もご覧ください。

▼全体ガイドの記事
・NATSのシステム開発の完全ガイド

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

NATSのシステム開発の全体像

NATSは通信基盤で、業務データを管理するシステムとは役割が異なります。そのため、候補者や求人の正本はRDBや既存ATSに置き、NATSにはイベントと必要最小限の識別情報を流します。

ここでいうNATSの定義

「NATSのシステム」は、航空管制サービス会社や学校名を指す場合もあります。ただし、ここでは、クラウドネイティブなオープンソースのメッセージングシステムであるNATS.ioを扱います。

• 対応言語：Go、Java、JavaScript／TypeScriptのクライアントがあります。
• 対応言語：Python、C#、Rustのクライアントも用意されています。
• 既存システムと連携：複数言語で構成されたシステムにも接続できます。
• 用途：イベント配信、Request／Reply、Queue Groupによる分散、IoTやエッジとの接続です。

NATSは業務データベースの代わりを務める製品ではありません。そのため、採用したからといって業務要件が自動的に解決するとは限らず、業務側の設計も欠かせません。

Core NATSとJetStreamの使い分け

Core NATSとJetStreamは、メッセージを保存して再処理する必要があるかどうかで選び分けます。NATS公式ドキュメントでは、Core NATSは公開時点の購読者へ一度配信すると説明されており、これはat-most-onceの性質です（出典：NATS Documentation「JetStream」、2026年参照）。

• Core NATS：保存しない通知やRequest／Replyなど、接続中への低遅延配信に向きます。
• JetStream：再処理、未Ackの再配信、一定期間の保持、レプリケーションが必要な場合の候補です。
• 重複対策：JetStreamを使っても副作用が一度だけとは限らないため、冪等キーと重複処理の設計が要ります。

JetStreamは、メッセージをStreamに保存し、Consumerの進捗とAckを管理する仕組みです。

人材システムのデータ境界

求人媒体や候補者管理、面接予約は、イベントを介して疎結合に連携できます。通知や請求も、同じ仕組みでつなげます。

Subjectの例は、「candidate.registered」と「application.received」です。「interview.booked」と「selection.updated」も、Subjectの例になります。

• イベント連携：Subjectを整理し、各サービスが必要なイベントだけを購読する形にします。
• 個人情報：履歴書本文、住所、健康情報、マイナンバーのイベント搭載は、慎重な判断が必要です。
• データ境界：イベントにはID、種別、発生時刻、相関IDを置き、詳細は権限管理された業務DBから取得します。

詳細データを分けておくと、ログや再処理領域へ個人情報が広がるリスクを抑えられます。

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

まずクラスタを組む前に、業務上の待ち時間や連携の失敗を言葉にしておきます。

最小のイベントで検証しながら、次の6フェーズを順に進めます。そうすると、NATSを使う範囲が明確になり、見積もりの抜け漏れも減らせます。

フェーズ1：要件整理でのイベントと保証条件

同期APIやバッチでつながっている処理を洗い出し、どのイベントが誰から誰へ届くかを整理します。許容遅延と失敗時の担当者も、この段階で決めておきます。

• 対象業務：複数通知、面接予約の失敗後の再処理、支店が一時オフラインでもイベントを失わない要件を対象にします。
• 要件書：Subject命名、Payloadのスキーマ、保持期間、最大メッセージサイズを含めます。
• 配信条件：配信保証、順序性、重複許容、再処理期限を定めます。
• 「必ず一回」の定義：Brokerの再配信を含むat-least-onceか、業務処理の冪等性まで含むかを分けます。

特に受入条件は、数値で決めておくことが大切です。

フェーズ2：選定でのセルフホストとマネージドの比較

選定では、運用の自由度と自社に残る責任、マネージド型の契約条件を照らし合わせます。

セルフホスト型は、AWS・Azure・GCPやオンプレミスで運用する方式です。データの所在地やネットワークに加えて、バージョンやストレージも自社で管理しやすいのが特徴です。

ただし、クラスタの構築や障害対応などの責任は自社に残ります。バックアップ、更新、監視も、自社の担当になります。

Synadia Cloudなどのマネージド型は、検証や複数リージョンへの展開を早めやすい方式です。

一方で、接続数やストレージ、転送量といった条件を確認します。SLAとデータ所在地は契約の前に見ておき、サポート時間と解約時のデータ取得条件も確かめます。

• 移行比較：RabbitMQやKafkaなど既存基盤との機能差を見ます。
• 移行計画：双発、カナリアConsumer、切替、ロールバックを提案できる会社を選びます。
• STAN：NATS Streamingは新規採用の前提にせず、JetStream対応を確認します。

フェーズ3：設計開発でのSubjectとConsumerの実装

設計では、Subject、Stream、Consumerの関係を決めます。AckやRetention、Replicaについても、同じ段階で決めておきます。

たとえば、通知・集計・監査の各Consumerが、互いに独立して読む構成が考えられます。Pull ConsumerとPush Consumerのどちらを使うかは、処理量、バックプレッシャー、即時性をもとに選びます。

• Stream設計：candidate-eventsに候補者登録と応募受付を束ねる形です。
• Payload設計：schema_version、occurred_at、correlation_idを持たせます。
• 重複防止：event_idを持たせ、Consumerで記録して二重処理を防ぎます。
• 再処理設計：Ack待ち時間、最大再送回数、隔離Subject、承認手順を定めます。

NATS Server 2.14では、高速バッチ公開や繰り返しスケジュール、Leaf Nodeの復旧性などが強化されています（出典：NATS公式「NATS Server 2.14 Release」、2026年4月30日）。採用するバージョンと更新方針も、設計書に残しておきます。

フェーズ4：テストでの消失・重複・停止復旧の確認

NATSの品質は、画面の確認に加えて、障害時の動作を確かめるシナリオを用意して判断します。確認結果は、消失や再配信の回数、処理順で記録します。復旧時間と手動操作の有無も残します。

負荷試験では、応募の集中や通知の一斉送信によるピークも再現します。

NATS公式の2025年事例にSophotechの報告があり、同社は約50サービスをRabbitMQから移行しました。その事例では、p99遅延が約150ミリ秒から約40ミリ秒に短縮しています。

• 停止・切断：Consumer停止、Ack前のプロセス停止、ネットワーク切断を試します。
• 重複・容量：同じevent_idの二重送信、ストレージ逼迫を検証します。
• クラスタ：クラスタの一台を停止し、復旧までを確認します。

また、運用時間も週数時間から週1時間未満になりました。ただし、個別環境の結果をそのまま自社の保証に使わず、PayloadサイズとConsumer数に合わせて測定します。

フェーズ5：稼働での監視・権限・切替手順の運用

稼働後は、NATSの状態を継続して見られる体制が欠かせません。アプリのエラーログでは、Broker側の滞留を見落とします。そのため、監視エンドポイントやPrometheusを使い、アラート担当者を決めます。

監視では、接続数、送受信レート、Consumerの滞留、Ack待ち、再送を見ます。加えて、JetStreamのストレージ使用量、クラスタのQuorum、Leaf Nodeの接続状態も確認します。

• 監視：接続から容量、クラスタの状態までを一覧で見られる形にします。
• 認証・認可：設計段階でSubject権限を決め、TLS、ユーザーやNKey、JWT、Accountを用います。
• Subject権限：求人、候補者、請求を、必要なサービスだけがPublishまたはSubscribeできる状態にします。

NATS公式ドキュメントによると、認証を設定していないサーバーは、到達できる接続からPublishやSubscribeを許します。そのため、初期設定のまま公開しないようにします。

フェーズ6：定着での再処理と変更管理の仕組み化

稼働後は、設定を渡して終わりにせず、現場で動かす手順まで整えておく必要があります。手順は、担当者が実際に使える形で用意し、訓練で確かめておきます。

運用担当者は、月次で滞留や再送の傾向を見て、SubjectやPayloadを整理し直します。

Vitrifiの2025年事例では、ワークフロー状態を毎分数千件処理する基盤が紹介されています。その基盤では、通信とKey-Valueに加えて、JetStreamやマルチテナント分離にもNATSを使っています。

• 運用手順：停止時の切り分け、再送前の重複確認、イベント再生の承認を定めます。
• 変更管理：保持期間、証明書、NATS Serverの更新を手順化します。
• 定着の目安：社内でSubject命名、スキーマ変更、障害訓練を続けます。

Vitrifiの事例からは、機能を増やすことより、業務の状態遷移と処理責任を一貫させることの大切さが分かります。

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

NATS Server自体はオープンソースですが、開発費は設定の作業に加えて、周辺の工数も含めて決まります。

見積もりには、イベント設計と既存ATSやRDBとの連携を含めます。認証やクラスタの構築に加えて、バックアップや監視、障害訓練も入ります。移行と引継ぎも、見積もりの対象になります。

次に示すのは、一般的な開発相場と必要工数をもとに推定した、税別の目安です。NATS固有の公開価格を並べたものではありません。

PoCから大規模移行までの費用レンジ

一般的な開発費の公開情報では、小規模が100万〜300万円、中規模が500万〜1,000万円、人月単価が60万〜200万円程度とされています。

これを参考に、NATS特有の非機能・連携工数を加味した推定です。会社や契約条件で変わるため、要件を渡して再計算します（出典：SIA「システム開発費用相場」、2026年参照）。

• PoC：50万〜200万円程度、期間は2〜6週間程度です。DockerまたはKubernetes上で1〜3サービスを検証します。
• MVP：300万〜800万円程度で、3〜8サービス、基本認証、監視、1業務システム連携を想定します。
• 本番連携：800万〜2,000万円程度で、5〜20サービス、HAクラスタ、再処理、バックアップ、障害訓練を含みます。
• 大規模案件：複数リージョン、マルチテナント、段階移行を伴う案件では、1,500万〜5,000万円以上の場合があります。

PoCでは、Core NATSまたはJetStreamを動かして、接続と負荷、再接続を確かめます。重複や復旧も、あわせて確認します。なお、個人情報を含む実データの匿名化や既存接続が増えると、工数も増えます。

費用が増える主な要因

費用を左右するのは、イベントの数そのものよりも、保証と復旧の複雑さです。

費用は、既存システムとの整合性や、セキュリティ・運用の作業範囲によっても変わります。

• 保証・復旧：保持期間、レプリカ、再処理頻度、Consumer、DLQ、順序、重複時の業務ルールを見積もります。
• 既存連携：候補者登録・通知のトランザクション境界と、失敗時の補償処理を設計します。
• 安全・運用：TLS、権限、JWT、Account、監査、バックアップ、アラート、夜間対応、復旧訓練を見積もりに含めます。
• 見積項目：設計、実装、基盤、テスト、移行、文書、保守に分けます。

見積書で「NATS環境構築一式」のような一括の表記が続くと、何に費用がかかるのかを確かめにくくなります。

初期費用とランニングコストの分け方

初期費用と継続費用を分けて、ライセンス以外の運用工数や契約条件も比べます。

• 継続費用：コンピュート、永続ストレージ、バックアップ、監視、ログ保管、転送、証明書、サービス料です。
• セルフホスト：ライセンス費は無料でも、担当者の時間や障害対応の費用はかかります。
• マネージド型：月額に加え、接続・Consumer数、容量、転送、リージョン、サポート、バックアップ、削除条件を確認します。
• 予算比較：開発、クラウド、保守、追加開発費を分けると、初年度と2年目以降の費用を並べて見られます。

NATSのシステム開発で見積もりを取る際のポイント

相見積もりでは、単価よりも「何を保証する見積か」を比べます。提案依頼書に、イベント一覧や接続先、ピーク量を記します。

保持期間と障害時の期待動作、個人情報の分類、希望運用時間も書きます。そうすると、各社の前提がそろいます。

要件資料のイベントと非機能条件

見積資料には、前提となる条件を具体的に記します。「大量処理」「高可用性」「リアルタイム」といった言葉は、数字に置き換えてはじめて、会社ごとの見積を比べられるようになります。

• 構成・イベント：現行図、連携先、イベント、データ項目、発行者と購読者を示します。
• 再試行責任：イベントごとの再試行回数と最終判断者を記します。
• 非機能条件：ピーク量を毎秒または毎分で示し、遅延、停止許容時間、復旧目標、重複時の結果を書きます。
• データ分類：氏名等を含む、IDのみ、個人情報なしに分けます。

保持期間、可用性、利用者と権限を資料に記載します。許容遅延はp95・p99で表します。

開発会社に確認するJetStreamと障害対応

技術用語を知っているかだけでなく、障害時の判断を説明できるかを確かめます。

回答は口頭で済ませず、責任分界やSLA、検収条件、運用引継ぎの範囲として、提案書に反映してもらいます。

• 技術経験：JetStream運用、滞留・再送対応、クラスタ復旧、Subject権限の経験を尋ねます。
• 基盤と安全：TLS、ユーザー・NKey、JWT、Account、Kubernetesなどの扱いを確認します。
• 業務連携：ATS、CRM、RDB、通知との連携や、Go以外の言語での経験の有無を確かめます。
• 運用体制：24時間保守の体制、ログ保管、個人情報を開発環境へ持ち込まない手順。

見積に含める個人情報と移行リスク

人材システムでは、履歴書や面接記録、雇用書類などを扱う場合があります。

特に、個人情報保護委員会は、安全管理措置、アクセス制御、委託先監督の確認を促しています（出典：個人情報保護委員会「人事労務管理のためのサービスをクラウド環境を利用して開発・提供する場合及び当該サービスを利用する場合における留意点」、2024年）。

見積書に「移行は別途」とだけある場合は、対象範囲と追加条件を確認してから契約します。

• 保存情報と閲覧者：Subject・JetStreamに置く情報と、ログ等の閲覧者を決めます。
• 移行リスク：二重通知、順序差、旧Consumer停止忘れ、ロールバック不能を考慮します。
• 移行費用：変換、リプレイ、カナリア、監視追加、業務確認期間を含めます。

よくある質問（FAQ）

採用判断では、無料かどうかよりも、業務に必要な保証と運用体制を満たせるかを確かめます。発注前によくある疑問に、ここで答えます。

NATSは無料でシステム開発できますか？

NATS Serverはオープンソースですが、開発費や運用費まで無料になるわけではありません。クラスタや永続ストレージ、バックアップには工数がかかります。

監視やTLS、障害対応、既存連携も、工数の対象になります。

マネージドサービスの料金や転送量、ストレージ、サポートは、公式の契約条件で確認します。

Core NATSとJetStreamはどちらを選べばよいですか？

通知やオンラインのRequest／Replyなど、接続中の相手へ低遅延で届ける処理には、Core NATSが候補になります。

送受信の両方が同時にオンラインでなくても配信したい場合や、再起動後の再処理、Ack、保持期間の管理が必要な場合には、JetStreamを選びます。

判断では、メッセージ量よりも、消失したときの業務への影響と復旧方法を基準にします。

NATSはKafkaやRabbitMQの代わりになりますか？

要件に合えば代替候補になります。製品名より中身で判断するため、イベント保持、Consumerのスケール、順序を比べます。

再処理や運用者のスキルを比べます。既存クライアントやデータ転送、SLAも、同じ基準で確認します。

移行時は、双発やカナリアConsumer、ロールバックを含むPoCを行います。段階切替と監視も、そこで確認します。性能に加えて、障害時の操作性も検証します。

履歴書や候補者情報をNATSに保存してもよいですか？

技術の可否だけでなく、利用目的や権限、保持期間を決めます。委託先の管理や監査、漏えい時の対応も含めて決める必要があります。

安全側の設計は、候補者IDやイベントIDだけをNATSへ送り、詳細は権限管理された業務DBに置くことです。

保存する場合は、暗号化やマスキング、Subject権限を要件に入れます。ログとバックアップの閲覧者、削除・再処理の手順も要件に含めます。

まとめ

NATSの開発は、サーバーを立ち上げることより、業務イベントを届け、失敗時に復旧できる仕組みを作ることです。要件整理では、配信保証と保持期間、個人情報の境界を決めます。そのうえで、運用方式と移行方法を比べます。

発注前に確認する6フェーズの成果物

発注前に、要件整理のイベント一覧、選定の運用責任表、設計開発のSubject・Stream・Consumer設計を確認します。

テストの障害シナリオ、稼働の監視・切替手順、定着の再処理・更新手順も、確認の対象です。

6つの成果物が見積書と契約範囲に含まれていれば、運用担当が決まらないまま進むことや、障害時に再送できない事態を防げます。

小さなPoCで作る判断材料

まずは影響範囲を限定した1〜3サービスでPoCを行い、全社の求人・候補者・請求を一度に移す前に判断材料を作ります。

PoCでは、Core NATSとJetStreamの適合性や実測性能を確かめられます。重複時の処理、復旧時間、運用負担も確認できます。

PoCの結果をもとに本番連携の費用と期間を更新し、業務設計と定着支援まで説明できる開発会社へ相談します。

▼全体ガイドの記事
・NATSのシステム開発の完全ガイド

▼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を創業。