NATSのシステム開発の発注/外注/依頼/委託方法について

NATSのシステム開発は、相談と要件整理から始め、RFPで提案を比べ、契約、PoC、本番開発、受け入れを経て、運用引き継ぎで終える流れで進めます。

各段階で必要な配信保証と運用責任を決めておくと、後の工程で迷いにくくなります。発注形態や委託先の選び方も、この流れに沿って説明します。

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

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

NATSのシステムを外注する前に知るべき全体像

NATSと業務アプリケーションを分けて、発注範囲を考えます。NATSはサービスやデバイスを非同期につなぐ通信・イベント処理基盤で、データベースや採用管理システムとは役割が異なります。

委託先には、ミドルウェアの設定に加えて、業務要件、データ整合性、セキュリティ、保守の設計も求めます。

NATS.ioの役割

ここでいうNATSは、NATS.ioが提供するクラウドネイティブなオープンソースのメッセージングシステムです。航空管制会社などとは別のものです。

NATSのメッセージは、用途に応じて届け方を変えられます。代表的な使い方は3つあり、それぞれ仕組みが異なります。

• イベント配信：Publish／Subscribeで、イベントを購読側へ届けます。
• サービス間通信：Request／Replyで、サービス同士がやり取りする仕組みです。
• ワーカー分散：Queue Groupで、処理を複数のワーカーに分けます。

軽量なサーバーと各言語のクライアントで実現でき、Go、Java、JavaScript／TypeScriptなどに対応しています。Python、C#、Rustも対象です。そのため、既存の業務システムが複数の言語で構成されていても組み込みやすい点が特徴です。

人材サービスでは、候補者登録や応募受付、面接予約をSubjectに分けて配信できます。選考結果の更新や入社確定も、Subjectとして分けられます。求人媒体や候補者管理のほか、通知や請求などのサービスへは、必要な情報だけを届けます。

候補者の氏名や履歴書の原本は、RDBや既存ATSを正本とします。一方でNATSには、候補者IDとイベント種別を送り、発生時刻や相関IDなども含める設計が基本です。

Core NATSとJetStreamの使い分け

配信方法の必要性に応じて、Core NATSとJetStreamを使い分けます。

• Core NATS：再生が不要で、接続中のサービスへの低遅延通知で足りる場合に候補です。
• JetStream：イベントやジョブを保存し、Consumer停止後に再処理する場合に使います。

JetStreamでは、Streamにメッセージを保存します。そのうえで、Consumerが配信状況とAckを管理し、未確認のメッセージを再配信します。

NATS公式ドキュメントでは、Core NATSはat most onceを提供すると説明されています。同じ資料では、JetStreamのConsumerはat least onceと説明されています。

（出典：NATS公式JetStreamドキュメント、2026年確認）

「NATS対応」とだけ書くと、必要な構成が曖昧になります。RFPには、保存の要否や再処理期限、許容できる重複を明記します。あわせて、順序性や最大遅延、障害時の復旧目標も書きます。

JetStreamを前提にする場合は、保持期間やレプリカ数に加えて、Consumerの最大再送回数も決めておきます。

過去のNATS Streaming（STAN）を新規案件の前提にしないよう注意します。そのうえで、新規設計ではJetStreamを中心に、現行バージョンの対応状況を確かめます。

NATSと業務システムの発注範囲

発注範囲は、NATSクラスタの構築から業務アプリケーション全体までの間で選べます。

• 基盤構築：NATSクラスタの構築を委託する範囲。
• サービス連携：既存サービスとの連携まで含める範囲。
• 一括委託：業務アプリケーション全体を任せる形。

NATS導入だけを外注する場合でも、Subjectの命名規則とPayloadのスキーマは成果物に含めます。認証・認可やTLSの設定も、成果物として明確にしておきます。

監視やバックアップ、アップグレードの手順も、納品後の障害対応に必要になります。これらが欠けると、自社では障害に対応できなくなります。

人材データは、履歴書や面接記録、雇用書類をメッセージに載せるか、IDだけを載せて業務DBから取得するかを、早い段階で決めておきます。

人材データの扱いでは、個人情報保護委員会も、安全管理措置と委託先の監督を確認するよう注意を呼びかけています（出典：個人情報保護委員会「人事労務管理のためのサービスをクラウド環境を利用して開発・提供する場合…」、2024年）。

NATSの技術選定と個人情報の扱いは、同じ発注の中で一緒に進めます。

NATSのシステム開発に適した発注形態

発注形態は、技術検証だけを頼むのか、既存システムとの連携まで頼むのか、企画から運用まで任せるのかで選びます。

要件が固まっていない場合は、PoCや技術アセスメントを先に行います。一方で、連携先やイベント量が明確なら、保存期間や可用性も含めて、RFPで複数社に同じ条件の見積もりを依頼できます。

PoCだけを外注する方法

PoCは、NATSが自社の要件に合うかを確かめる小規模な発注です。DockerやKubernetes上でCore NATSまたはJetStreamを構築し、1〜3個のサービスをつないで検証します。

• 負荷と再接続：高い負荷をかけた状態や、接続断からのつなぎ直しを試します。
• 再送：Consumerを止めたあとに、未処理のメッセージを届け直せるかを確かめます。
• 復旧：サーバーやConsumerを止め、バックアップから元に戻せるかを確かめます。

成果物には、検証環境や構成図、Subject一覧を含めます。加えて、メッセージスキーマとテスト結果を記し、未解決リスクと本番移行条件も明記します。

公開相場と必要工数からの推定では、費用は50万〜200万円程度、期間は2〜6週間が目安です。既存システム調査や個人情報設計を含めると増えるため、完了条件は契約書に記載しておきます。

マネージドサービスを使って外注する方法

クラスタ運用の人材が不足する場合は、Synadia Cloudのようなマネージドサービスを使い、アプリ開発と運用設計をSIerへ委託できます。

• 利用効果：冗長化や更新の負担を減らし、連携開発に集中できます。
• 検証用途：複数リージョンや拠点・エッジ連携を短期間で試せます。
• 契約条件：料金、接続数、転送量、容量を確かめます。保持期間やデータ所在地、SLA、通知、ログの条件も示させます。
• 海外利用：個人情報の越境や再委託、契約の準拠法について確かめます。

マネージドサービスを使っても、運用責任は残ります。また、無料枠や月額プランは変わるため、発注時点の公式料金で見積もります。

第三者が整理した料金例を参考にする場合は、その数字を公式料金と照らし合わせます。

既存システムとの連携・移行まで一括委託する方法

既存のATSやCRM、RDBなどと連携し、NATSを本番のイベント基盤にする場合は、要件定義から保守まで一括委託できます。通知サービスや請求システムとの連携も、この範囲に入ります。

委託先には、イベント駆動の設計や業務データの正本、トランザクションの境界を確認します。さらに、API連携と権限管理に加え、監視やインシデント対応の進め方も確かめます。

納品物が設定ファイルだけの場合、業務側の不整合を解決できない可能性があります。

• 二重配信：RabbitMQやKafkaなどの旧基盤とNATSへ、一時的に配信する方式。
• 段階切替：一部のConsumerをカナリア切替で移し、確認後に全体へ広げます。

NATS公式が紹介するSophotechの事例では、約50サービスの環境でRabbitMQから移行し、p99遅延は約150ミリ秒から約40ミリ秒になりました。

ただし、これは個別事例で、同じ改善が自社で得られるとは限りません。そのため、移行前後の測定条件とロールバック条件は、RFPに記載しておきます。

NATSのシステム開発を発注・外注する進め方

開発は、相談と要件整理から始め、RFPと提案比較を経て契約に進みます。そのあと、PoCと本番開発、受け入れを行い、運用引き継ぎで終えます。

最初から技術仕様を細部まで決めきる必要はありません。そのかわり、解決したい業務課題と、失敗したときに困る条件は発注者側で整理します。

業務課題とイベントの整理

導入する技術より先に、改善したい業務を書き出します。たとえば、応募情報の即時連携や、通知処理のピーク時の遅延抑制が挙げられます。

• 業務目的：オフライン拠点の後同期や、障害後のイベント再処理を含めて整理します。
• 技術方式：Core NATS、JetStream、既存API、バッチ処理から、適した方式を選びます。
• イベント条件：発行元や購読者、保存要否、許容遅延、再送の扱いを一覧にします。
• Subject設計：「candidate.registered」「interview.booked」のように、業務上の意味を表す名前を付けます。

個人情報を含む場合は、Payloadに値を入れず、IDと参照先だけを載せる案も比べます。Subjectには、サービス名や実装の都合だけで名前を付けないようにします。

RFPに記載する項目

見積条件をそろえるため、RFPに業務、技術、運用の前提を明記します。

• 案件情報：目的、対象業務、既存構成、連携先、イベント、利用者を書きます。データ分類、希望時期、予算、納品物、保守条件も示します。
• イベント量：毎秒数、ピーク増加率、平均・最大サイズを示します。Subject・Consumer数、保存期間、再処理件数も含めます。
• 非機能要件：復旧時間と復旧時点、停止許容時間、最大遅延を示します。通知時間やバックアップ頻度、災害時の切替も入れます。
• JetStream設定：Stream・Consumerの保存条件を明記します。
• 未確定事項：要件定義の支援や前提、追加調査、PoCで判断する項目について、提案を求めます。

JetStreamを使う場合は、Retention、ファイルまたはメモリのストレージ、レプリカ数、Ack方式を指定します。

あわせて、MaxDeliver、再配信間隔、Consumer滞留の検知方法も決めておきます。

要件が曖昧なまま固定価格を求めると、後から変更扱いになり、費用や納期が膨らむおそれがあります。

PoCから本番、受け入れまでの確認

PoCの後は、設計レビューと本番の最小構成を確かめます。そのあと、負荷試験や障害試験を行い、段階リリースへ進みます。

• 負荷試験：ピーク遅延、再送、Ack待ち、ストレージ量、再接続を確かめます。
• 障害試験：サーバー停止、ネットワーク分断、Consumerの長時間停止を試します。
• イベント試験：重複や順序が入れ替わったイベントを想定する。

受け入れ条件は、画面の動作だけでなく、RFPに書いた業務要件と非機能要件に合わせて決めます。

たとえば、候補者登録イベントが5秒以内に通知へ届くことや、未Ackのイベントが設定回数まで再送されることを、条件にできます。

このほか、冪等キーで二重処理を防ぐことや、監視でConsumerの滞留を検知すること、担当者が復旧手順を実行できることも条件に加えます。

引き継ぎでは、構成図や設定値、秘密情報の管理方法を受け取ります。さらに、監視項目や障害時の連絡先、復旧・アップグレードの手順も渡してもらいます。

NATSの外注で選ぶ契約形態

契約形態は、要件がどこまで確定しているかと、発注者がどれだけ管理できるかで選びます。実務では、初期は準委任、成果物と受け入れ条件が明確な工程は請負、継続監視や改善は保守・運用契約と分ける方法が実務的です。

契約名だけでなく、成果物や作業範囲、どこまでを誰が受け持つかを具体的に確認します。あわせて、変更手続きと障害対応も確かめます。

準委任契約が向くケース

準委任は、技術アセスメントや要件定義、設計、PoC、運用改善など、作業の遂行を委託する場面に向いています。NATSの適用範囲やJetStream設定を検証する段階では、完成形を固定しにくいため、準委任が合います。

• 契約条件：月の稼働時間、担当者、定例会、成果報告、設計レビュー回数。
• 合意事項：作業時間だけでなく、何を判断できる状態にするかを決めます。
• 意思決定体制：業務、情報システム、セキュリティ担当と委託先が会議に参加します。

発注者が十分な時間を割けない場合は、プロジェクト管理支援やPMO支援を加えた見積もりも比べます。

請負契約が向くケース

請負は、成果物と受け入れ条件を定義できる工程に使います。設計書や構成、アプリに加えて、テストやドキュメントも、その成果物にあたります。

例は、JetStreamを使った応募イベント連携を、指定の負荷試験と障害試験を通過した状態で納品する範囲です。

• 契約範囲：対象Subjectや対応サービス、テストケースを定めます。納品物、検収期限、瑕疵対応期間も明記します。
• 未確定要件：調査と変更管理、追加見積もりの対象とします。
• 追加費用：発生する条件と上限を示させます。

仕様の曖昧さを残したまま契約すると、イベント数や保存期間が決まらないまま、完成の姿がずれていきます。

保守・運用契約で決める項目

稼働後は、サーバーやマネージドサービスを監視します。監視対象は、Consumerの滞留や再送の増加、Stream容量です。加えて、接続エラーや認証失敗、処理遅延も対象になります。

• 障害対応：通知先、対応時間、一次切り分け、復旧支援、原因分析。
• 定例業務：定例報告とバックアップ確認。
• 更新管理：バージョンアップと脆弱性対応。

保守契約には、ここまで挙げた監視や対応、定例業務、更新管理を含めます。

NATS Server 2.14は2026年4月30日にリリースされ、公式ページでは2.14.3が同年6月29日付の最新です。

（出典：NATS公式リリース情報・ダウンロードページ、2026年確認）

発注時のバージョンだけでなく、アップグレードの検証環境や互換性確認、切り戻し方法も委託範囲に含めます。そうすることで、古い構成のまま放置されるのを防げます。

NATSのシステム開発費用相場と見積もりの内訳

NATSに特有の国内受託開発費を横断的に比べられる公的統計は、確認できません。そのため、以下の金額は2026年時点の一般的な開発相場と、設計、インフラ、移行、運用の工数から推定したものです。

正確な金額は、イベント量や連携先、可用性を明示したうえで算出します。保存期間や個人情報、保守時間も示す必要があります。なお、ライセンス費だけでなく、開発費やクラウド費、監視費用も見ます。

PoC・MVP・本番開発の費用レンジ

予算検討用の推定レンジは、開発規模によって異なります。

• PoC：50万〜200万円程度。
• 小規模MVP：300万〜800万円程度。
• 本番業務連携：800万〜2,000万円程度となるケースがあります。
• 大規模案件：1,500万〜5,000万円以上になる可能性があります。

PoCには、1〜3サービスの接続や、Core NATSまたはJetStreamの構築、負荷・再接続試験、障害復旧の確認が含まれます。既存システム調査やセキュリティ審査を含めると、金額は上振れします。

小規模MVPは、3〜8サービスと1つの業務システム連携を想定します。加えて、Subject設計や基本認証、CI/CD、監視も含みます。

本番連携では、5〜20サービスとHAクラスタを前提にします。RDBやATSとの連携、再処理、バックアップのほか、権限設定や障害訓練も含めます。

複数リージョン、Kafkaなどからの移行、24時間運用を含む場合は、大規模案件になります。

これらは、特定の金額を保証する市場価格ではありません。公開相場と必要工数から作った、予算検討用のレンジです。会社ごとの見積もりがこの範囲から外れる場合も、その理由を確かめます。

見積もりを比べるときは、イベント量や冗長化、データ移行の扱いを確かめます。セキュリティやPMO、保守についても、含む作業と含まない作業をそろえて比べます。

見積もりに含めるべき費用項目

初期費用と月額費用を分けるため、見積もり項目を整理します。

• 開発工程：要件定義、イベント設計、クラスタ構築、実装を含みます。連携、テスト、移行、文書、管理も入ります。
• JetStream設計：Stream・Consumer、Retention、レプリカ、再送、重複排除。
• JetStream検証：バックアップとリプレイ試験。
• 別途費用：クラウド、ストレージ、転送、監視、ログの費用。TLS証明書やマネージド利用料も別に見ます。
• 運用など：24時間オンコール、脆弱性診断、外部API利用料。

料金は為替やプランの変更で動くため、見積書には前提の月額と変動条件を書いてもらいます。また、開発費と月額運用費を足した数字を、初期費用と取り違えないようにします。

費用が増えやすい要因

費用を左右するのは、NATSの台数だけでなく、配信保証と業務データの整合性です。

• 処理の整合性：冪等性、順序ルール、失敗イベントの隔離、再処理承認が必要です。
• 監査と情報保護：監査ログや、個人情報を含むPayloadの暗号化、マスキングを設計します。
• 構成と移行：マルチリージョン、拠点間接続、既存基盤からの無停止移行は、設計と試験の範囲を広げます。

発注前には、月間イベント数が増えたとき、Consumerが数時間止まったとき、同じ候補者イベントが2回届いたときの対応を、委託先に尋ねておきます。

CPUやメモリの話だけで、再送や重複、監査、運用を説明しない委託先は、見積もりが安くても本番のリスクを含むおそれがあります。

NATSの委託先選定と見積比較のポイント

イベント駆動設計と本番運用を説明できる会社を選びます。公開情報にNATSの実績が少なくても、JetStreamやGo、Kubernetes、クラウドの経験があれば候補になります。分散システムや障害対応の経験も、判断の材料になります。

Dockerで起動した経験のみを挙げる会社は、本番の可用性や個人情報の設計を説明できない場合があります。そうした会社は、慎重に評価します。

委託先に確認する7つの評価項目

確認する観点は、次のとおりです。経験の有無だけでなく、規模や障害対応の実例まで尋ねます。

• JetStream運用：Stream、Consumer、Ack、Retention、レプリカ、バックアップ。
• 障害対応：再送、重複、順序、滞留の扱い。
• 基盤経験：AWS、Azure、GCP、オンプレミス、Kubernetesの対応範囲。
• セキュリティ：TLS、NKey、JWT、Account、Subject権限、監査ログの設計。

第五に、既存のATSやCRM、RDB、APIと連携した経験を確かめます。

第六に、24時間運用やオンコールの体制を確かめます。障害報告や脆弱性対応、バージョンアップの進め方も含めます。

第七に、移行時の二重配信やカナリア切替、ロールバックの進め方を尋ねます。データ整合性の確認方法も、あわせて聞きます。

実績については、利用経験だけでなく、規模や配信保証まで尋ねます。障害時の測定内容と復旧担当者も確認します。

同じ前提での見積もり比較

合計額を比べる前に、各社の見積条件をそろえておきます。

• 前提：RFPと同じイベント数、連携先、可用性、保存期間、保守時間を指定します。
• 内訳：要件定義、設計、実装、試験を同じ粒度で分けます。移行や文書、引き継ぎも、同じ細かさで分けてもらいます。
• 対象と差額：「含む・含まない・前提・追加条件」を示し、費用差の理由を確認します。

低い見積もりでは、JetStreamなどが別料金になっている場合があります。一方で、高い見積もりにはPMOなどが含まれることもあります。

内訳を確認し、初期費用と月額費用を分けて見ます。さらに、追加変更や障害対応、クラウド費用も切り分けたうえで、総額を判断します。

セキュリティとガバナンスの評価

NATSの認証・認可やTLSを設定していても、Payloadに不要な個人情報を入れていれば、漏えい時の影響は大きくなります。

• 送信情報：候補者IDとイベント種別だけを送り、ログに氏名や履歴書を出しません。
• 保持期間：JetStreamの保存期間を、目的に合わせて短く保ちます。
• 権限と秘密情報：環境ごとにAccountとSubject権限を分け、秘密情報をコードやログに残しません。

AI面接や候補者推薦を組み合わせる場合は、AIへの入力や利用目的、説明責任を要件に含めます。さらに、アクセス権、評価結果の保存、誤判定時の対応も、要件に入れます。

経済産業省などが公表するAI事業者ガイドラインは、2026年3月31日に第1.2版が案内されています（出典：経済産業省「AI事業者ガイドライン検討会」、2026年）。

NATSの性能だけでなく、データガバナンスを説明できる会社を選びます。

よくある質問（FAQ）

発注前によくある費用、技術選択、開発会社への依頼方法について、質問に答えます。

NATSは無料なので開発費も安くなりますか？

NATS Serverはオープンソースでも、開発費が下がるとは限りません。開発には、要件定義やイベント設計、構築、認証、監視の費用がかかります。テストや保守、クラウドやストレージの費用も含め、総保有コストで比べます。

JetStreamは必ず使う必要がありますか？

JetStreamは、必ず使うものではありません。接続中の購読者へのリアルタイム通知だけであれば、Core NATSが候補になります。

Consumer停止後の再処理や保存、Ackと再送が必要ならJetStreamを使います。Replayやレプリケーションまで必要かは、イベントごとに判断します。保持期間とストレージ上限を決めて、無期限の保存を避けます。

NATSに詳しい開発会社をどう見つければよいですか？

NATSの実績やJetStreamの本番経験、障害復旧、既存連携の経験を確認します。あわせて、クラウドやKubernetesの運用も見ます。選定理由や再送・重複の設計、監視、保守時間、個人情報を含むPayloadについて質問します。

実績を開示できない場合でも、匿名化した構成やテスト結果、担当者の技術経歴を見れば、判断の手がかりになります。

見積もり依頼前に何を用意すればよいですか？

業務目的や既存構成図、連携先、イベント種類、想定メッセージ量を用意します。保存期間や個人情報の有無、希望時期、予算、運用体制も、あわせて示します。

NATSの詳細設定が未確定でも、PoCで確認したいこと、許容遅延、障害時の復旧目標を示せば、提案を比べられます。

資料が不足する場合は、要件定義やアセスメントを先に発注し、そのうえでRFPを仕上げる進め方もあります。

まとめ

発注時は、サーバー構築費だけでなく、業務要件やイベント設計、配信保証まで委託範囲に含めます。さらに、個人情報の扱いや監視、復旧、保守も対象にします。

Core NATSとJetStreamはイベントごとに使い分け、STANのような古い構成をそのまま採用しないようにします。

小さなPoCとRFPによる着手

本番の一括開発を決める前に、業務イベントを整理します。そのうえで、1〜3サービスのPoCにより、配信や再送、重複、障害復旧を検証します。

結果をもとにRFPを作成し、同じ条件で複数社から提案と見積もりを取得します。費用レンジは参考値として扱い、成果物と運用条件をそろえて比べます。

技術と業務の両方を見られる委託先の選定

委託先は、NATSのキーワードや価格だけで決めず、JetStreamの運用やATS・RDBとの連携を見ます。さらに、セキュリティや障害対応、保守体制も確かめます。

発注者が判断する業務要件と、委託先に任せる技術・運用の責任を分けて、契約と受け入れ条件に記載します。そうすれば、開発を安全に外注できます。

▼全体ガイドの記事
・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を創業。