Hanamiのシステム開発の見積相場や費用/コスト/値段について

Hanamiのシステム開発費は、機能の範囲や業務の複雑さ、品質要件によって変わります。目安は、MVPで300万〜800万円、中〜大規模の案件で2,000万〜5,000万円以上です。

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

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

Hanamiのシステム開発の全体像と費用の見方

Hanamiは、保守性の高いWebアプリケーションをRubyで作るためのフレームワークです。Railsのように機能を一体で提供する考え方とは違い、関心の分離やモジュール化を重視します。

費用を見るときは、業務をどの単位で設計し、どこまで開発するかを先に確認します。

Hanamiの構造が開発費に影響する理由

Hanamiでは、業務の役割ごとに処理を分けて設計します。

• HTTP処理：リクエストの入口を受け持つAction。
• 業務手続き：処理を担うOperation、表示を担うView。
• データアクセス：Relation・Repo・Structとして扱う部分。

顧客管理や受注、請求、APIなどは、Sliceという単位で分けられます。公式ガイドは、Sliceを独自のコンテナや設定を持ち、他のSliceと連携できる単位と説明しています（出典：Hanakai公式「App / Slices」、確認日：2026年8月）。

この構造は業務ルールを整理し、長期の保守をしやすくします。一方で、初期に業務の境界を決める設計工数が必要です。

お問い合わせフォームのように小さな機能では負担は小さくても、受注から請求まで部門をまたぐ業務になると、SliceやOperationの検討が増えます。そのため、この設計工数は初期見積もりの上流工程に反映されます。

Hanamiで作りやすいシステムの範囲

申請・承認などの業務システムからAPIまで、Hanamiは幅広いシステムの検討に使えます。

• 業務システム：申請・承認、顧客・会員、受発注・在庫、予約・問い合わせ管理。
• システム構成：業務WebにJSON API、バッチ、メール送信、管理画面を組み合わせた構成。
• Rubyの適した用途：MVP、中規模以下のWebサービス、社内業務ツール、APIバックエンド。

Rubyの開発会社による相場情報でも、これらはRubyに適した用途として挙げられています（出典：Incubation Base株式会社「Rubyでのシステム開発」、2026年確認）。

数百万人規模の同時接続や極端に短い応答時間、複雑なリアルタイム処理では、Rubyだけで要件を満たすとは限りません。

Hanami 3.0のテストアプリでは、同じHTTPリクエストで、2.3と比べて約3.7倍のスループットと、p99レイテンシ20msから4msという結果が示されています（出典：Hanakai公式「Hanami 3.0: In full bloom」、2026年6月30日）。

これはテスト環境の値です。そのため、実システムでは、DBや外部API、インフラ、クエリ設計を含む負荷試験が必要です。

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

まず業務シナリオとデータの流れを整理し、そのうえで小さく実装していく進め方が適しています。

Hanami 3.0やRuby 3.3を前提に、認証やDB、CI/CD、監視を含めて、自社で成り立つかを早めに確かめておくと、作り直しを防げます。

企画・要件定義で決める業務と非機能要件

要件定義では、業務の流れと品質条件を次の観点で整理します。

• 業務シナリオ：誰がいつ何を入力し、どの条件で承認し、次の担当者へ何を渡すか。
• 機能・品質条件：必要機能と同時利用者数、目標応答時間、稼働時間、復旧時間、バックアップ期間、監査ログの保管期間。

非機能要件が曖昧なまま進むと、開発後に追加の対応が必要になり、費用と納期が膨らみます。診断や監視、二要素認証などが、その例です。

発注側と開発会社は、フレームワークが自動で満たす要件と、アプリ・クラウド・運用ルールで設計する要件を分けて合意します。

PoCと基本設計による技術の成立性の確認

社内や発注先に経験者が少ない場合は、全機能の開発前に、次の内容を縦切りPoCで確認します。

• 業務の流れ：ログインから登録、承認、検索までを通しでつなぐこと。
• 設計と周辺機能：Action、Operation、View、Relation・Repoの責務、認証、外部API、エラー処理。
• 開発・運用：自動テストとデプロイ方法。

Hanami 3.0はRuby 3.3以上が必要なため、既存のRuby、Gem、OS、CI環境が対応しているかも確かめます（出典：Hanakai公式「Hanami 3.0: In full bloom」、2026年6月30日）。

PoC費用は、本開発の見積もりに含む場合と、技術検証として別契約にする場合があります。省けば初期費用は下がりますが、未知の依存関係が本開発中に見つかるリスクは上がります。

開発・テスト・リリースの品質確保

設計後は、実装からリリース準備まで次の順に進めます。

1. 実装・テスト：優先業務から作り、単体・結合・総合テストまで行う。
2. 共通機能の設計：管理画面、API、バッチを同時に作る場合でも、認証・権限・監査ログの扱いを先に決める。
3. リリース確認：受入テスト、移行リハーサル、バックアップ復元、監視通知、障害時の連絡経路の確認。

Operationで成功と失敗を明示し、ActionにHTTP処理を集めておくと、業務ルールのテストや変更がしやすくなります。

納品物には、ソースコードに加えて、Gemfile.lockやCI/CD定義、インフラ設定を含めます。テスト仕様と運用手順も含めておけば、更新を自社や別会社へ引き継げます。

Hanamiの開発費用相場と規模別の価格帯

費用は、規模、画面数、業務ルール、外部連携、データ移行、品質要件で変わります。次に示すのは税別の推定レンジで、公式料金表や特定会社の確定見積もりではありません。

要件が固まっていない段階では、価格と期間を幅で捉え、見積もりの前提条件を確かめてください。

小規模PoC・MVPの費用目安（300万〜800万円）

小規模PoC・MVPの目安は、次の条件を前提にしています。

• 費用・期間：ログイン、数画面の登録・編集・検索、簡易管理画面、少数のAPI連携なら300万〜800万円程度、3〜5か月程度。
• 対象業務：全社ではなく、効果の大きい一つの業務シナリオに絞ります。申請・承認・検索・CSV出力を縦切りで作り、反応を見て機能を足します。

期間は、既存UIへの適合や細かな権限、運用環境の整備範囲で変わります。ただし、データ移行や複雑な帳票、24時間監視を含めると、800万円を超える可能性があります。

標準的な業務Webシステムの費用目安（800万〜2,000万円）

標準的な業務Webシステムの目安は、次の機能範囲と期間です。

• 費用：ユーザー・組織・権限管理、申請・承認、複数条件検索、帳票、メール通知、外部APIを1〜3本含む場合、800万〜2,000万円程度。
• 期間：6〜10か月程度。部門数、承認経路、既存データの品質によって前後する。

公開情報によると、Rubyエンジニアの単価は、初級が月50万〜70万円、中級が月70万〜100万円、上級が月100万〜130万円以上です（出典：Incubation Base株式会社「Rubyでのシステム開発」、2026年確認）。

要件定義から品質管理まで含む開発会社では、新規開発の単価が月100万〜150万円前後という公開例もあります（出典：BPS株式会社「Ruby on Rails開発・保守・引き継ぎ」、2026年確認）。

中〜大規模の連携型システムの費用目安（2,000万〜5,000万円以上）

中〜大規模案件では、費用と期間が次の幅になることがあります。

• 費用と条件：複数部門のワークフロー、会計・在庫・基幹連携、大量移行、監査ログ、SSO、二要素認証、厳格な復旧を含む場合、2,000万〜5,000万円以上。
• 期間と工程：10〜18か月以上を見込み、要件定義、移行設計、受入テスト、教育まで計画する。

部門間の業務ルール統合や既存データの名寄せ、移行後の責任分界も、費用を左右します。加えて、関係者の意思決定にかかる時間も影響し、業務担当者の参加が必要です。

価格を固定せずに進める場合も、対象と除外範囲、追加変更の扱いを契約書に明記します。

Hanamiの見積金額を構成する費用の内訳

見積書は、「開発一式」ではなく工程と成果物に分けて確認します。

デジタル庁の標準ガイドライン実践ガイドブックでも、人件費は工数と単価の積で積算すると説明されています（出典：デジタル庁「標準ガイドライン実践ガイドブック」、2025年6月）。Hanamiの開発でも、技術名の違いより積算の前提を明確にすることが重要です。

企画・要件定義・基本設計の費用

企画・要件定義と基本設計では、次の情報や構成を決めていきます。

• 要件定義：業務フロー、画面・API一覧、権限、データ項目、外部連携、非機能要件、運用体制。
• 基本設計：Sliceの分け方、ActionとOperationの責務、データモデル、認証、ログ、エラー処理、インフラ構成。

要件定義・基本設計は、総額の10〜20%程度と仮置きすると比べられます。不確実性が高い案件では、この比率が上がります。

既存資料が不十分な場合は、ヒアリングや業務観察、現行データの調査が増えます。逆に、画面一覧と権限表があれば、確認の時間を減らせます。業務フローやサンプルデータも役立ちます。

資料を作ること自体を目的にせず、主要な業務シナリオを操作できる形で合意します。

製造・単体テスト・結合テストの費用

製造・テスト費用は、実装範囲と品質要件を踏まえて配分します。

• 製造対象：画面・API、DB処理、認証・権限、メール、帳票、バッチ、外部連携。
• 費用配分の目安：製造・単体テストは総額の30〜40%、結合・総合テストは15〜20%と仮置きする考え方があります。

品質要件が高い業務システムでは、テストの比率を下げないよう注意します。OperationやRelation・Repoを分けておくと、業務ルールやデータアクセスを単体で検証しやすくなります。

テストを後回しにすると、仕様変更のたびに全画面を手作業で確認することになり、保守費用が増えます。初期見積もりには、テストコードの範囲とテストデータを書いてもらいます。受入担当と品質基準もあわせて記載します。

移行・インフラ・セキュリティの費用

移行・インフラ・セキュリティ費用には、次の作業や環境が含まれます。

• データ移行：顧客、商品、組織、権限、履歴の抽出・変換・名寄せ・欠損補完・リハーサル・検証。移行導入費は総額の5〜10%程度が目安です。
• インフラ：実行環境、RDB、オブジェクトストレージ、監視、バックアップ、ログ保管、CDN、CI/CD。
• セキュリティ：脆弱性診断、WAF、SSO、二要素認証、監査ログは、初期費用とランニング費用を分けて扱う。

古いデータの品質が悪い場合や複数システムを統合する場合は、特に移行費が5〜10%を超える可能性があります。

小規模なインフラは、月額数千円〜数万円程度から始められる場合があります。ただし、費用は可用性やデータ量、アクセス数で変わり、監視時間やSLAによっても変わります。

保守・運用のランニングコスト

保守費用を見積もるときは、次の費用と契約範囲を確かめます。

• 主な作業：クラウド利用料、監視、バックアップ、脆弱性対応、Ruby・Gem・Hanamiの更新、問い合わせ、軽微な改修、性能確認。
• 費用目安：スクラッチ開発費の年15〜20%程度。初期費用1,000万円なら年150万〜200万円程度。
• 契約条件：24時間監視、厳格なSLA、追加開発の有無、月の稼働時間、対応時間帯、障害優先度、脆弱性対応、更新範囲、追加改修単価。

Hanami 3.0にはRuby 3.3以上が必要です。そのため、既存環境の更新が保守契約に含まれるかどうかも、長期の費用を左右します。

Hanamiのシステム開発費用が変動する要因

同じHanamiで作るシステムでも、業務の複雑さや品質要求によって費用は変わります。画面数からは見えにくい権限や例外処理が、見積もりの差を生みます。連携や移行、非機能要件も、差の大きな要因です。

画面数より大きく費用を左右する権限とワークフロー

画面が少なくても、閲覧範囲や承認経路が役職や部門で変わると、実装とテストが増えます。取引先や拠点、金額で変わる場合も、同じ手間がかかります。

差し戻しや代理承認などの例外処理も、費用に反映されます。期限後の通知や承認後の変更禁止も、実装と確認の手間になります。

見積もりを依頼する際は、画面一覧に加えて権限表と業務フローを渡します。承認者が一人か条件で複数に分かれるかや、履歴を何年残すかも示すと、各社の見積もりの前提を揃えられます。

外部連携とデータ移行が増えると膨らむ費用

連携と移行の見積もりでは、次の条件を確認します。

• 外部連携：会計、販売管理、在庫、決済、本人確認、メール配信では、API調査、認証、再送、タイムアウト、形式変換、相手側テスト環境が必要です。
• 連携費用：連携先ごとに例外処理と運用監視が増えるため、1本を画面1枚分の費用とは単純比較できません。
• データ移行：件数より正確さが大切です。表記揺れや重複、欠損、古いコード、削除済みデータの扱いを決めておきます。
• 並行稼働：新旧システムを併用する場合、二重入力防止や差分連携が必要なため、期間と費用に余裕を持たせます。

移行データの扱いが曖昧なままだと、リハーサルの回数が増えます。

非機能要件とHanami・Rubyの経験者確保

要件と開発体制では、次の点が費用に影響します。

• 非機能要件：同時利用者数、応答時間、稼働率、RPO・RTO、監査ログ、個人情報保護、脆弱性対応。厳しい条件ほど、クラウドや監視、テスト、運用費が増えます。
• 開発体制：Rubyエンジニアの人数・経験と、Hanami 3.0への対応可否は、体制と単価に影響します。
• 実績の確認：公開事例が少ない場合は、RubyやRailsでの成果とHanamiでの成果を分けて評価する。
• 不足経験への対応：必要に応じてPoCや設計レビューを設け、そのリスクを見積もりに反映します。

候補会社には、Hanamiのバージョンへの対応状況とRuby 3.3以上の経験を確かめます。Action・Operation・Sliceの経験や、テスト・保守の担当も確認します。

Hanamiのシステム開発費を抑えるコスト最適化のポイント

費用を抑えたいときは、単価の安さよりも、作り直しを減らし、開発者が迷わない情報を揃え、保守しやすく設計することが大切です。こうした取り組みが、総保有コストの抑制につながります。

MVPで業務価値の高い範囲に絞る方法

初回リリースの範囲を決めるときは、次の点を検討します。

• 対象業務：全帳票や細かな検索、例外的な承認経路は初回から含めず、売上、処理時間、入力ミス、問い合わせ数の改善に直結する業務を選ぶ。
• 既存サービスの利用：標準的なマスタ管理や通知は、すでにある仕組みを使い、独自の業務ロジックだけをHanamiで作る方法もあります。
• 組み合わせ例：勤怠、請求書、メール配信、ファイル保管はSaaSやクラウドとAPI連携し、申請・承認、顧客別ルールをHanamiで構築する。

外部サービスの月額費用や連携費用は発生します。その一方で、初期開発や法令・セキュリティ対応の負担を分散できる場合があります。

縦切りPoCによる不確実性の早期解消

縦切りPoCでは、利用者が業務を最初から最後まで完了できるかを試します。確認するのは次の点です。

• 業務の一連の流れ：認証、入力、業務ルール、保存、検索、通知、デプロイを通しでつなぎ、周辺サービスとの相性や運用上の不足を見る。
• 性能と障害対応：実データ量での検索速度と、失敗したAPIの再実行。
• 安全性と復旧：権限外のデータに届かないことと、バックアップから復旧できること。

PoCの成果物のうち本開発へ流用できる範囲は、見積もり前に合意しておきます。

自動テストと運用の標準化による保守費の抑制

保守を続けやすくするには、設計と運用を次のように整えておきます。

• 役割分担：業務ロジックはOperation、データアクセスはRelation・Repoに分け、Sliceの境界をはっきりさせる。
• 定期運用：CIでのテスト自動実行と、Gem更新、脆弱性検知、ログ確認、バックアップ検証の定期化。

テストや文書を削ると、納品後の調査や引き継ぎにかかる費用が増えます。そこで、納品物には構成図や業務ルール、権限表を含めておきます。API仕様や移行手順、テスト結果、デプロイ手順も、納品物として残します。

納品物を揃えておくと、次のSliceや追加機能の見積もりもしやすくなります。

Hanamiの見積もりを取る際のポイント

同じ前提条件に揃えて、工程、体制、成果物、除外範囲を比べます。合計額だけで決めないことが大切です。

Hanamiの経験が少なくても、Rubyの設計・テスト・保守の経験があり、PoCで不足を説明できる会社もあります。

Hanami対応をうたう会社でも、担当者やバージョンが分からなければ、確認が必要です。

見積もり前に揃える業務フローと前提資料

発注側は、まず目的と成果指標、利用者、業務フローを整理します。

見積もり依頼の前に、次の内容を揃えておきます。

• 画面・APIと権限、データ項目：前提として整えておく。
• 外部連携と移行対象：書き添える。
• 希望時期と予算上限：併せて示す。

ただし、すべてを確定する必要はありません。「必須」「できれば」「将来検討」に分けておくと、各社が同じ範囲で見積もれます。

既存の資料は、見積もりの前に開発会社へ渡す材料になります。

• サンプルデータ、API仕様書、帳票：あれば、調査の工数を抑えられます。
• 権限表、障害履歴：役立ちます。

手元にない資料は、開発会社に現状調査を依頼し、その作業を見積もりの別項目に含めてもらいます。

複数社を同じ条件で比べる方法

複数社を比べるときは、技術経験と見積もり体制を分けて確認します。

• 技術者と設計：Hanami 3.0・Ruby 3.3以上の経験者、Action・Operation・Sliceの設計例、テストとレビューの担当者。
• 実績の見方：RubyやRailsの経験は参考情報とし、Hanamiの本番での経験とは限らない点を踏まえて評価する。
• 体制と工数：PM、リード、開発者、QA、デザイナー、インフラ担当の人数・期間、工程工数、会議時間、再見積もり条件。

要件定義や受入支援が除外されると、あとで追加費用が発生します。

移行や運用設計も含め、発注側が各社の見積もりに含まれる範囲を照合します。

契約・納品・保守のリスク確認

契約と運用の役割を明確にするため、次の点を確認します。

• 契約条件：請負・準委任、仕様変更、検収、遅延連絡、第三者サービス障害、コード・設定の権利、再委託範囲。
• 更新と脆弱性対応：Hanami・Gemの更新担当と、脆弱性が見つかったときの対応時間・費用を契約書に記載する。
• 発注者側の作業：移行や切り替えは、開発会社だけでは完了しません。マスタデータや受入テスト、社内教育、旧システム停止の判断者を決めておきます。

役割分担が見積書に書かれているかを確かめ、発注者側の作業を含めた総額と日程で判断します。

Hanamiのシステム開発費用に関するよくある質問

Hanamiの費用について、発注前によく寄せられる質問は、採用の妥当性、開発期間、保守費用などです。価格だけでなく、これらも合わせて判断します。

Hanamiを使うとRailsより開発費用は安くなりますか？

Hanamiを採用すれば、必ずRailsより安くなるとは限りません。フレームワーク自体は無料でも、設計や周辺Gemを理解する人材が必要で、テストや認証、運用設計の工数もかかります。

業務の境界が明確で長期の保守を重視する案件では、Hanamiの構造が活きやすくなります。

標準機能を早く揃えたい案件では、RailsやSaaSとの比較が必要です。

Hanamiのシステム開発にはどのくらいの期間がかかりますか？

小規模PoC・MVPは3〜5か月、標準的な業務Webシステムは6〜10か月、中〜大規模の連携型は10〜18か月以上が目安です。

期間は、準備の状況や意思決定の速さによって変わります。移行や外部API、受入体制も影響します。ただし、期間を短くする場合も、テストや移行リハーサルは省かず、初回の機能を絞るのが安全です。

Hanamiの保守費用は毎月どのくらい見込めばよいですか？

保守費用は、初期開発費の年15〜20%程度を仮の目安にし、監視やバックアップ、脆弱性対応などの範囲で調整します。

初期費用が1,000万円なら、年150万〜200万円程度が検討の目安になります。24時間対応やSLA、追加開発を含む場合は上振れし、クラウド利用料も別途必要です。

Hanamiの開発会社には何を確認すればよいですか？

発注側は、次の点を開発会社に確認します。

• 技術経験：Hanami 3.0とRuby 3.3以上の経験。
• 設計と体制：Action・Operation・Sliceの設計、テスト・レビュー体制。
• 移行と運用：移行実績、クラウド・監視の範囲。
• 納品範囲：設計書、テスト仕様、ソースコード。CI/CDやインフラコードを含むかどうか。
• 保守：脆弱性対応、バージョンアップ、担当交代時の引き継ぎ。

RubyやRailsの実績と、Hanamiでの実績を分けて説明できる会社は、提案の前提が明確です。

まとめ

Hanamiの開発費用は、MVPで300万〜800万円、標準的な業務Webシステムで800万〜2,000万円が目安です。中〜大規模では、2,000万〜5,000万円以上が推定の幅になります。

金額は、ライセンス料金ではなく工数と体制で決まります。工数は工程ごとに積み上がり、インフラやセキュリティ、保守も含まれます。

費用だけでなく業務価値と将来の保守で比べる視点

必須機能と将来機能を分け、主要業務を縦切りPoCで確かめます。そのうえで、権限や連携の条件、移行、非機能要件を見積もりに反映します。

複数社を同じ条件で比べ、Hanami 3.0やRuby 3.3以上への対応を確かめます。テストや納品の範囲、保守と更新の責任範囲も確認すると、初期費用と長期コストを適正化できます。

最初にやること：要件整理と小さな検証

採用に迷う場合は、確定見積もりを急がず、業務フローやサンプルデータ、非機能要件を整理します。そのうえで、PoCまたは要件定義から相談するとよいです。

独自の業務はHanamiで作り、標準機能や周辺サービスはSaaSやクラウドと組み合わせる案も比べると、費用と保守性のバランスを取れます。

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

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