Hapiのシステム発注は、業務要件を整理し、契約と委託範囲を決め、段階ごとのレビューを重ねながら進めるのが基本です。この順で進めると、費用と運用のリスクを抑えやすくなります。
▼全体ガイドの記事
・Hapiのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Hapiのシステムを発注・外注するときの全体像
フレームワークを指定して開発会社を探すのは、発注の入口にすぎません。まず業務の目的と対象範囲を決め、Hapiを採用する妥当性を確かめてから委託先を探すのが順序です。次に、開発・移行・保守を担う体制を、発注者と委託先が契約で押さえます。
Hapi公式は、認証、認可、入力検証、リクエストライフサイクル、プラグインによる拡張性を特徴として挙げています。ただし、実際の業務機能やデータ設計は、発注者と開発会社が作り込みます。
Hapiと業務システムの違い
Hapiは、Node.js上で動くWeb APIフレームワークです。リクエストを受け取り、認証や入力検証を通したうえで、データベースや外部サービスと連携して応答します。
販売、会員、予約、在庫管理や社内申請の機能は、業務に合わせて開発会社が作ります。その際に設計・実装するのは、画面、API、データベース、権限、帳票です。さらに、通知やバッチも業務に合わせて組みます。
このため、発注者はRFPに利用者、業務フロー、データ、連携先、運用条件を書き込みます。
外注で目指す業務成果
外注で目指すのは、コードの納品ではなく、業務時間の短縮や入力ミスの削減などの業務成果です。そのため、「何ができれば成功か」を数値や受入条件に置き換えておくと、見積の比較と検収が安定します。たとえば、月次締めの短縮日数、ピーク時の同時利用者数、障害時の復旧時間を、発注者が委託先と決めておきます。
Hapiのシステムに合う発注形態
業務の範囲と受入条件が固まっている案件では一括請負が、要件を検証しながら作る案件では準委任やアジャイル型が選びやすいです。
社内に管理人材が少ない場合は、要件定義の段階から委託できます。ただし、丸投げにすると意思決定が遅れたり追加費用が生じたりするため、発注者と委託先の役割を先に分けておきます。
完成形と範囲を定義できる案件の一括請負
一括請負は、合意した範囲を、決めた金額と期間で完成させる発注形態です。
画面数、API数、帳票、権限、連携、移行対象を明確にできる業務システムの初期開発に適します。テストや納品物も含めて範囲を最初に固められる案件に、とくに合います。
予算は立てやすい一方で、契約後の変更は追加見積になりやすいため、発注者と委託先は、要件定義と変更管理の進め方を契約書に記載します。
準委任が向く、不確実性の高い案件
準委任は、専門人材と作業時間を確保したうえで、要件整理、設計、開発、レビューを進める形態です。現場ヒアリングで仕様が変わる案件や、既存データを調べてから移行方法が決まる案件に適します。
小さなPoCで業務適合性を確かめる場合にも使いやすいです。ただし、月ごとの作業範囲と稼働時間を決め、成果物やレビュー方法、品質基準を明確にしておかないと、進捗が見えにくくなります。
段階発注によるリスクの切り分け
Hapiの採用経験やデータ品質に不確実性がある場合は、調査・PoC、要件定義、MVP開発、本番展開、保守の順に、発注を分けます。
最初の段階で認証方式、主要API、データ連携、性能、運用監視を検証し、その結果を次の段階の見積に反映します。
各段階の終わりに継続・修正・中止の判断基準を設けておくと、大規模発注後に起きやすい不一致のリスクを抑えられます。
RFPと要件整理で決める内容
RFPは、開発会社に同じ前提で提案と見積を依頼する文書です。発注者は、技術名よりも業務課題、利用者、成果、制約を具体的に書きます。
Hapiを必須にする場合でも、採用理由と、代替案を提案してよいかどうかを明記しておくと、委託先の技術判断を比べやすくなります。
現状・理想・例外を含む業務要件
現行業務では、Excel、紙、メール、既存パッケージ、担当者の個人管理に分かれた作業を、発注者が洗い出します。
理想の業務では、誰がいつどのデータを登録し、誰が承認し、どの帳票を出すかを発注者が定義します。
例外として返品、取消、承認差し戻し、重複登録、月末締め、障害時の手作業も書き出します。これを後回しにすると、開発の終盤で追加の要求になり、請負契約でも費用と納期が動きかねません。
機能要件と非機能要件の分け方
機能要件には、画面、API、検索、登録、承認を含めます。このほか、帳票、通知、CSV、バッチ、外部連携、管理者機能も入れます。
非機能要件には、同時利用者数、応答時間、可用性、バックアップ、RTO・RPOを含めます。さらに、監査ログ、保持期間、監視、障害連絡、セキュリティ診断も入れます。
個人情報を扱う場合は、権限の粒度、アクセスログ、削除・訂正の手順、委託先の再委託管理を確認します。
納品物と発注者の作業分担
納品物には、要件定義書、画面・API仕様書、データモデルを含めます。テスト計画・結果と運用手順書も、同じ範囲で求めます。ソースコードとインフラ設定も納品物に入れます。脆弱性対応記録と教育資料も、あわせて求めます。
発注者には、業務ヒアリング、マスタ整備、サンプルデータ提供、受入テストを割り当てます。社内告知や移行日の業務停止承認も、発注者が受け持ちます。
納品物の権利、リポジトリへのアクセス、第三者ライブラリのライセンス、Node.jsとHapiの更新担当も、提案を依頼する時点で質問します。
契約形態と発注後の進め方の設計
契約では、委託先に任せる範囲と発注者が決める範囲を明確にします。業務ルールや既存データが分からないままでは、契約形態を選んでもリスクは固定できません。
要件定義と開発を同じ契約にまとめるか、工程ごとに分けるかは、発注者が要件の確度と社内体制を見て判断します。
工程の性質による請負と準委任の選び方
請負契約では、成果物、完成条件、検収方法、契約不適合への対応、変更手続きを定めます。準委任契約では、作業内容、稼働時間、会議体、報告方法を定めます。さらに、善管注意義務、途中解約、成果物の扱いも決めておきます。
要件定義を準委任で行い、仕様確定後の開発を請負にする組み合わせもあります。契約名称だけでなく、各工程の成果と、どこまでを誰が受け持つかを確認します。
契約書に入れる変更・検収・障害対応の条件
変更が生じたときは、影響範囲、追加工数、納期、費用を、誰がいつまでに承認するかを決めておきます。
検収では単体テストだけでなく、業務シナリオ、権限別操作、移行後の照合、ピーク負荷、障害復旧を受入条件に入れます。
リリース後は、重大障害の連絡時間、一次切り分け、復旧目標、セキュリティ修正、Node.js・Hapi・プラグインの更新、保守終了時の引き継ぎを、発注者と委託先で合意します。
発注後の週次の意思決定と段階レビュー
発注者の責任者、業務部門、情報システム担当、委託先PMが参加する定例会を設けます。週次では、進捗率だけでなく、未決事項、仕様変更、テスト結果、移行課題、リスクの期限と担当者を確認します。
要件定義、基本設計、試作、結合テスト、受入テストでレビューし、次の工程へ進む条件を合意しておくと、問題の先送りを防げます。
Hapiのシステム開発を外注する費用相場
Hapi.jsはオープンソースなので、通常は開発費にライセンス料を加えません。
要件定義、画面・API開発、データベース、クラウドには費用がかかります。連携、テスト、移行、監視、保守にも、それぞれ費用がかかります。
ここで示す金額は、2025〜2026年の国内類似相場とリサーチノートの規模別整理に基づく推定で、Hapi公式の価格表ではありません。実額は、RFPと委託先の体制によって変わります。
規模別の初期費用の目安
APIや小規模な管理画面を想定した初期費用は、規模の拡大に伴って段階的に上がります。目安は次の4区分で、PoCの150万〜400万円程度から、大規模の3,000万〜8,000万円程度までを示します。
- PoC：5〜20程度のAPI、単一データベース、基本認証に絞り、150万〜400万円程度、1〜3か月が目安。
- 中小企業向け：CRUD、権限、帳票、CSV、メール通知、基本テストと移行を含み、400万〜1,000万円程度、3〜6か月程度。
- 業務基盤：SSO、ERP・会計連携、監査ログ、複数ロール、段階移行を含み、1,000万〜3,000万円程度、6〜12か月程度。
- 大規模：複数部門の基幹連携は3,000万〜8,000万円程度。
高可用性、多拠点、多テナント、複雑なデータ移行、24時間監視まで含む場合は、8,000万円〜数億円のレンジもあります。
これらは定価ではなく、画面数、API数、連携数、性能、移行量、監査要件を積み上げた推定です。
開発費と運用費を分けた費用比較
初期費用は工程ごとに、運用費は保守やクラウドに分けて比べます。内訳の目安は次のとおりで、工程の抜けを見つけるための確認用のレンジです。確定した比率ではありません。
- 要件定義・設計費：要件定義10〜15%、基本設計15〜20%、詳細設計10〜15%。
- 開発から導入：開発・単体テスト30〜40%、結合・総合テスト15〜20%、移行・導入5〜10%。
- 保守費：初期開発費の年10〜20%程度を仮置きし、監視、障害対応、軽微な改修、脆弱性対応、依存パッケージ更新の範囲を確認。
- クラウド費：小規模で月3万〜30万円、中規模で月30万〜150万円程度を仮置きできます。
たとえば初期開発費3,000万円なら、年300万〜600万円程度、月25万〜50万円程度が推定されます。さらに、24時間対応や大規模な追加開発を含めると、費用は上振れします。なお、クラウド費は、通信量、データベース、ログ、WAF、バックアップによって変わります。
見積の根拠と変動要因
IPAのCoBRA法に基づく支援ツールは、過去実績、開発規模、工数から、変動要因とリスクを見えるようにする考え方です。
最低3件、推奨10件程度の実績データでモデルを構築できるとされています（出典：IPA「CoBRA法に基づく見積り支援ツール」、2017年）。
自社の実績が少ない場合でも、画面数、API数、連携数、移行件数、非機能要件が工数に与える影響を、委託先に説明してもらいます。
委託先の選定と見積比較の観点
委託先は、Hapiの技術ページに名前があるかどうかだけで決めず、実務を説明できるかで見ます。
具体的には、Hapiの実務経験、Node.jsのLTS対応、認証・権限、テストを一体で説明できるかを確認します。加えて、クラウド、移行、保守についても、同じ体制で説明できるかを見ます。
公開情報にHapi.jsの記載があっても、自社案件の成功や現在の担当者の在籍までは保証されません。そこで、提案の段階で実績の範囲と証跡を尋ねておきます。
Hapiと周辺技術の実務経験
委託先に、案件数、使用したHapi・Node.jsのバージョン、TypeScript、DB、コンテナ、CI/CD構成を質問します。さらに、認証・権限設計、負荷試験、障害対応の方法も確認します。
Hapi公式GitHubの2026年確認情報では、Hapi v21はNode.js v18以降とESMとの互換性が示されています。また、Node.js公式リリース一覧（2026年）ではv24とv22がLTS、v26がCurrentです。そのうえで、この状況を踏まえた更新計画も提案に含めてもらいます。
見積書の作業範囲と前提条件
見積を比べるときは、総額とあわせて、作業範囲と前提条件をそろえて確認します。作業範囲は、要件定義、設計、開発、テストの各工程について見積どうしで含有を揃えます。さらに、移行、教育、保守の含有も、同じ行で比べます。
- 作業範囲：工程の抜けがないかを、見積の行ごとに確認する。
- 見積前提：API・画面数、連携先、移行件数、同時利用者数の前提をそろえる。
- 費用条件：クラウド、ライセンス、出張、予備費を確認し、未確定分は条件と上限を尋ねる。
安い見積は、要件定義や受入テストが薄いまま、別の工程で追加費用が出ることがあります。そのため、提案書には想定ユーザー数、対応ブラウザ、外部サービス仕様、移行の責任の範囲を書いてもらいます。
また、テストデータの準備と発注者のレビュー期限も、提案書に記載してもらいます。
最後に、同じ条件で3社程度に依頼し、価格、提案の具体性、リスクの指摘、体制、納品物、保守を総合評価します。
選定評価に含めるセキュリティと保守
Hapiの認証や入力検証があっても、安全性は完成しません。そのため、セキュリティ対策、保守の分担、将来の引き継ぎ体制も、委託先の評価に含めます。
- セキュリティ：HTTPS、WAF、レート制限、Cookie属性、CSRF対策の確認。加えて、秘密情報管理、脆弱性スキャン、監査ログ、バックアップ、権限レビュー。
- 保守：Node.js、Hapi、プラグイン、コンテナイメージの更新担当、EOL前の移行方法、脆弱性情報の確認時間を決める。
- 引き継ぎ：リポジトリ、CI/CD、環境構築・テスト手順を整備し、発注者へ定期的に引き継ぐ。
IPA「TLS暗号設定ガイドライン」（2025年）は同年4月に第3.1.1版を公開し、特段の要件がなければ推奨セキュリティ型を推奨しています。そのうえで、案件の要件に合わせて設定を検討します。
コードや設計書を受け取っても、委託先にしか理解できない構成では、将来の変更費用が高くなります。
よくある質問
外注では、技術選定だけでなく、費用の根拠、契約上の責任、運用の継続性も確かめます。発注前によくある疑問を取り上げ、それぞれに答えます。
Hapiを使うとライセンス費用はかかりますか？
Hapi.jsはオープンソースのため、通常はフレームワーク利用料がかかりません。人件費、クラウド、DB、監視、セキュリティ診断の費用は別途必要です。また、保守や第三者サービスの料金もかかります。
採用するプラグインや周辺サービスのライセンス条件は、提案書で確かめます。
小規模なPoCからHapiの開発を外注できますか？
外注できます。5〜20程度のAPI、単一DB、基本認証、最小限の管理画面に絞れば、1〜3か月程度の検証として依頼できます。
成功条件、検証しない範囲、本番化で加わる認証、移行、監視、負荷試験を明示すると、PoCの成果を本番の見積につなげやすくなります。
Hapiの実績がない会社でも候補にできますか？
候補にはできますが、Node.jsやAPIの経験だけでHapiの実務経験を補えるとは限りません。発注者は、担当者と対応バージョンを確かめます。プラグイン選定と認証・入力検証も、あわせて確認します。テストや保守体制も確認します。
必要であれば、契約前に短期の技術検証を行います。将来の別フレームワーク移行も考え、業務ロジックとフレームワークを分離できる会社を選びます。
見積もりは何社から取ればよいですか？
同じRFPを前提に3社程度から取ると比較しやすいです。会社数が多すぎると質問対応や提案評価に時間がかかり、発注者側の要件整理が浅くなります。
総額だけでなく、作業範囲、前提条件、体制、リスク、納品物を、共通の評価シートで採点します。保守や追加費用も、同じシートで採点します。最終候補とは、提案内容を調整してから契約します。
まとめ
発注前に、業務目的、利用者、データ、連携、セキュリティ、運用を整理します。完成形が明確なら請負を、検証しながら進めるなら準委任や段階発注を選びます。
RFPと契約書で、範囲、納品物、検収、変更、保守について、どこまでを誰が受け持つかを明確にします。
相場のレンジと見積の前提
初期費用はPoCで150万〜400万円程度です。中小企業向け業務システムでは400万〜1,000万円程度です。さらに、SSOや外部連携を含む基盤では1,000万〜3,000万円程度が、類似案件から見た推定です。
発注者は、Hapiのライセンス料ではなく、要件定義、開発、移行、テスト、クラウド、保守の総額を、同じ条件で比べます。
最初の一歩：業務ヒアリングとRFPの作成
最初から大規模な開発を発注せず、まず業務とデータを洗い出して、必要な要件を整理します。そのうえで、発注の規模を決めます。
- 現行業務とデータの洗い出しと、API、画面、権限、連携、非機能要件の整理。
- Hapiの採用理由、代替案、PoC範囲、Node.js・Hapiの更新、コードと設計書の引き継ぎを含むRFPの作成。
- 技術と業務の両方を理解する委託先との、将来の運用まで見据えた合意。
▼全体ガイドの記事
・Hapiのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。