Hanamiのシステム開発の完全ガイド

Hanamiのシステム開発は、業務ルールの複雑さ、必要な機能、運用体制を整理してから方式を選ぶと、変更に強い構造を長く保つ目的に役立ちます。

Hanamiの設計思想、適したシステム、進め方と費用、会社選びと保守を順に見ていきます。

▼関連記事一覧
・Hanamiのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Hanamiのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Hanamiのシステム開発の見積相場や費用/コスト/値段について
・Hanamiのシステム開発の発注/外注/依頼/委託方法について

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

Hanamiのシステムの全体像

Hanamiは、コードを機能ごとに整理し、ビジネスロジックを明示的に扱うRubyフレームワークです。関心の分離とモジュール型の設計によって、アプリが大きくなっても保守しやすいことを目指します（出典：Hanakai公式「Hanami」、2026年8月確認）。

Hanamiが目指す設計思想

Hanamiの設計は、役割を明確に分けて保守しやすくする考え方です。この考え方は、次のように表れます。

• 部品を組み合わせる：Railsのように一体で提供する形とは異なり、部品ごとに役割を明確にします。
• 処理を分ける：画面表示、業務判断、データベースへの問い合わせを、それぞれ別々に扱います。
• 複雑な業務ルールに対応：承認条件、料金計算、在庫引当、契約状態などの条件を、整理して扱えます。

短期的に画面を増やすだけのシステムより、業務ルールが積み重なっていくシステムで効果を発揮します。

処理の置き場所が明確になるため、担当者が変わっても判断しやすくなります。ただし、自由度が高いぶん、開発前に責務と命名規則を合意しておかないと、実装方法がチームごとに分かれるおそれがあります。

主要コンポーネントと業務システムでの役割

業務システムの処理は、各コンポーネントが役割を分担して受け持ちます。

• Action：HTTPリクエストを受け取り、画面やAPIごとの処理に振り分けます。
• Operation：登録、承認、決済、在庫引当の処理と、成功・失敗の分岐を担当します。
• 表示とデータ：View・Templateは画面の見せ方を担い、Relation・Repo・Structは値の扱いを受け持ちます。

公式資料によると、Relationはデータアクセスの型を定義し、Repoは問い合わせを組み立て、Structは値オブジェクトを提供します（出典：Hanakai公式「Hanami」、2026年）。

たとえば受注システムでは、Actionが入力を受け、Operationが在庫確認と承認条件を実行します。そのうえで、Repoが受注・商品・在庫を更新し、Viewが結果を表示します。

処理を一つのコントローラーやモデルに詰め込まないため、承認ルールだけを変えるときも影響範囲を見極められます。

Hanamiで作れるシステムの種類と向いているケース

Hanamiは、業務Webシステムのほか、JSON API、管理画面、バッチ、外部サービス連携にも使えます。認証、帳票、監視、クラウド構成などは、要件に応じて組み合わせて使います。

採用範囲は、業務の境界と将来の変更点を見通して決めることが大切です。

相性がよい業務システム

Hanamiと相性がよいのは、業務ルールが継続的に増えていくシステムです。

• 多くの業務領域：受発注、顧客・会員管理、予約、問い合わせ、社内申請、販売・在庫管理が対象になります。
• 複数部門でのデータ利用：Sliceで顧客、受注、請求などを分け、Operationで手続きを表します。
• 段階的な導入：既存機能のAPI化や管理画面の刷新から始め、投資とリスクを抑えられます。

外部APIを組み合わせるサービスや、社内向けと取引先向けの入口を分けるシステムにも適しています。加えて、全機能を一度に作り直さず、業務上の境界が明確な部分から始められます。

別の選択肢も比較したいケース

選択肢は、業務の標準化の度合い、独自ルール、チームの経験を基準に比べます。

• SaaS・パッケージ：既製機能で足りる業務を、短期間で導入したい場合。
• スクラッチ開発：独自の審査、料金計算、現場フローが競争力に直結する場合。
• Rails：経験者が多く、標準機能や既存資産を活用できる場合。

SaaSやパッケージの場合は、導入設定とデータ移行に予算を使う方が合理的なこともあります。また、Railsの方が早い場合もあります。

Railsと比べるときは、開発者の経験、利用Gem、既存資産を確認します。さらに、納期と将来の採用計画も判断材料になります。

Hanamiは、責務の明確化や長期保守を条件にすると判断しやすくなります。軽量なAPIや複数業務領域の境界づけも、比べる際の条件になります。

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

開発では、画面一覧よりも先に、業務シナリオと非機能要件を揃えておきます。要件定義から運用までを一度に確定させず、主要業務を縦に通す小さな検証を早めに行うと、技術選択と見積もりの精度を上げられます。

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

要件定義での業務と非機能の数値化

要件定義では、申請や承認の流れ、マスタの責任者、非機能要件の数値、個人情報の扱いを、発注前に言葉にして揃えておきます。

• 業務シナリオ：担当者、判断時点、データの受け渡しを整理します。
• 申請手続き：申請者、承認者、差し戻し条件、期限、通知先、監査記録を定義します。
• マスタ管理：顧客、商品、組織、権限などについて、責任を持つ人を決めます。
• 非機能要件：利用者数、応答時間、稼働率、復旧目標、保存期間などを数値化します。
• 個人情報：権限、暗号化、操作ログ、脆弱性対応、委託先管理を別に整理します。

非機能要件には、バックアップ頻度、データ保管場所、サポート時間も含めます。さらに、個人情報に関する要件は、機能要件と別の一覧にすると抜け漏れに気づけます。

小さな縦切りによる技術成立性の検証

試作では、主要業務を通して、本番運用に必要な技術構成と性能を確かめます。

• 業務の縦切り：ログインから登録、承認、検索までを一通り試作します。
• 技術構成：Hanamiのバージョン、Ruby、DB、認証を組みます。CI/CD、監視、メールも加えて、開発者の理解度と本番運用の成立性を確認します。
• 実環境の負荷：データ量と外部連携を含めた試験で、採用を判断します。

2026年時点のHanami 3.0では、メーラーや国際化、Minitestが追加されています。ログの改善や、リクエストボディ解析なども加わっています。

公式テストアプリの計測では、2.3と比べて同一HTTPリクエストのスループットが約3.7倍、p99レイテンシが20msから4msになったと報告されました。ただし、特定条件での計測です（出典：Hanakai公式「Hanami 3.0: In full bloom」、2026年）。

設計・開発・移行・リリースの段階化

設計から移行・リリースまでを段階に分けて進め、成果物と運用方法を引き継げる形にしておきます。

• 設計とテスト：Slice等の責務を記録し、単体・結合・総合の各試験を行います。
• 個人情報の保護：テストデータのマスキングや匿名化の方法を決めます。
• データ移行：サンプルによる試行、名寄せ、欠損補完、重複処理、照合を早めに行います。

設計方針には、Sliceの境界、ActionとOperationの責務、RelationやRepoのデータアクセスを含めます。

テストでは、業務ルールの成否を確認するほか、外部API、メール、権限も対象にします。実際の業務シナリオに沿った確認も行います。

納品物と保守契約には、設計書、テスト仕様書、ソースコードを含めます。加えて、Gemfile.lock、CI/CD定義、インフラ設定も対象になります。

運用手順と障害時の連絡ルールも含めておくと、担当者や委託先が変わっても保守を続けやすくなります。

Hanamiのシステム開発費用の相場と内訳

Hanami固有の一律料金表はありません。費用はライセンス料ではなく、要件定義から実装、テストまでの工程と、データ移行、インフラ、運用設計の工数で決まります。

ここで示すのは、業務WebシステムをHanamiで実装する場合の推定レンジです。実際の見積もりを保証するものではありません。

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

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

規模別の費用と期間の目安

費用と期間は、システムの規模や含める要件によって変わります。

• PoC・MVP：ログイン、数画面のCRUD、簡易管理画面、少数API。300万〜800万円、3〜5か月。
• 標準規模：ユーザー・権限、申請・承認、検索・帳票、メール、外部API。800万〜2,000万円、6〜10か月。
• 中・大規模：複数部門、複雑なワークフロー、基幹・会計・在庫連携、移行、監査。2,000万〜5,000万円以上、10〜18か月以上。

中・大規模の推定は、複数部門や複雑なワークフローを含む場合の目安です。加えて、基幹・会計・在庫連携、データ移行、監査対応も想定しています。

金額は、類似する国内Ruby・Web業務システムから組み立てた推定で、Hanamiの公開統計ではありません。

デジタル庁の実践ガイドブックは、工数と単価を分けて積算し、項目ごとに妥当性を確認する考え方を示しています（出典：デジタル庁「標準ガイドライン実践ガイドブック」、2025年）。

見積もりで確認する費用項目

見積もりは、初期開発の金額だけで判断せず、体制や運用を含めて費用の内訳ごとに分けて比べます。

• 工程別の金額：要件定義・設計、製造・単体テスト、結合・総合テスト、移行・導入、管理。
• 人月単価の例：PM月70万〜130万円、シニア月80万〜120万円、中堅月50万〜70万円。
• 初期費用以外：クラウド、DB、メール、監視、バックアップ、診断、更新、問い合わせ、改修。
• 保守費：初期費用の年15〜20％程度を試算の第一候補にします。

単価は2025年時点の公開相場の例です。Hanami経験、既存Gem調査、品質保証、セキュリティ対応によって変わるため、単価の安さだけでは比べられません（出典：2025年公開の国内システム開発費用情報）。

24時間監視、SLA、緊急対応、セキュリティ診断を含めると、保守費は上振れします。そこで、5年間の総保有コストで比べると、初期見積もりが安くても有利とは限りません。

Hanamiのシステム開発会社・サービスの選び方

Hanami専門をうたう事業者は多くないため、「Ruby対応」だけで判断しないことが大切です。確認したいのは、Hanamiの本番経験と、設計から保守までを担う体制です。RubyやWeb業務システムの経験も、あわせて見ておきます。

Hanamiの直接事例が公開されていない場合は、その事実を踏まえて、技術検証と担当者の経験を確認します。

実績と担当者の経験の確認

会社名の数より、自社に近い業務の経験と担当者の設計力を見ます。Ruby・RailsとHanamiの実績は、分けて聞くと差が見えてきます。

• 業務経験：受発注、請求、在庫、権限、外部API、移行の事例と担当範囲。
• 技術経験：Ruby・RailsとHanamiの実績を区別して評価します。
• 設計方法：Action、Operation、Slice、RelationやRepoの組み立て方を確認します。
• 運用と品質：認証、監査ログ、バックアップ、障害対応、テスト、レビューの担当。

Hanami 3.0とRuby 3.3以上の経験者を配置できるかを、質問しておきます。匿名化した設計サンプル、テスト方針、レビュー体制があれば、実装力を判断する材料になります。

提案・見積もり・契約範囲の比較

複数の提案は、同じ基準にそろえて比べます。条件がそろっていないと、金額の差が何による差なのか分からなくなります。

• 見積もり条件：金額合計に加え、前提、対象外機能、工数、納期、検収、変更管理をそろえます。
• 契約形態：準委任・請負・アジャイルを不確実性と意思決定速度から選びます。
• 納品物：コード、設計書、テスト仕様と結果、移行・運用手順、インフラ設定、依存ライブラリ、脆弱性対応の責任範囲。
• 権利と責任：コードの権利、リポジトリ、第三者Gemのライセンス、保守終了時の引き継ぎを契約で確認します。

要件定義を低額にして後工程で追加請求する提案もあります。そのため、成果物と未確定要件の扱いを確認しておきます。また、サービスを組み合わせる場合は、データのエクスポート方法も見ておく必要があります。

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

Hanamiのシステムで必要なセキュリティと保守

Hanamiは、アプリケーションの構造づくりを助けるフレームワークです。ただし、安全性をすべて自動で保証するものではありません。

認証・認可、監査ログ、バックアップなどの対策は、アプリ、インフラ、組織運用に分けて要件にします。ネットワーク、脆弱性管理、従業者教育、障害対応も、この3つに分けて要件に含めます。

権限・ログ・個人情報の要件化

個人情報と重要操作を扱う範囲を定めると、アクセス管理と記録の仕組みに求める内容も決まります。この段階で要件に書いておくと、開発会社ごとの提案を同じ条件で比べられます。

• 権限：部門、役職、顧客、操作ごとの閲覧・登録・承認・出力範囲。
• 操作ログ：変更者・日時・内容を記録し、改ざん防止や保存期間を定めます。
• 認証管理：二要素認証、セッション、パスワード、担当者の緊急権限。
• 組織的対策：責任者、研修、自己点検、委託先との役割分担。

ログについては、検索方法と監査時の取り出し方も決めておきます。通則編は、基本方針や取扱規律、安全管理措置、外的環境の把握などを示しています。

アクセス制御や不正アクセス対策も必要です（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年8月確認）。

バージョン更新と障害対応の運用

対応バージョンを保ち、更新や障害対応を続けられるよう、計画を作っておきます。

• 互換性：古いRuby・Gemは開発前に確認し、検証環境と切り戻し手順を用意します。
• 保守契約：窓口、切り分け、復旧目標、脆弱性確認、Gem更新を決めます。復元テスト、障害報告、軽微改修も含めます。
• 定期運用：ログ、負荷、権限、移行データの品質を確認します。

2026年7月時点のRubyGems上のHanami最新安定版は3.0.1で、Ruby 3.3以上が必要です（出典：RubyGems「hanami」、2026年7月）。

Ruby 3.3系については、通常メンテナンスの終了時期も公開されています。そのため、採用時点だけでなく次の更新計画まで見通します。

運用カレンダーにログの確認、負荷の変化の把握、権限の見直し、移行データの品質確認を入れておくと、利用後のリスクを下げられます。

Hanamiのシステム開発でよくある失敗と対策

採用理由が曖昧なまま技術から着手すると、RailsやSaaSと比較できないまま進み、開発後に運用負担が見つかることがあります。

失敗を避けるには、業務の変化やチームの技術力を基準に判断します。保守期間、利用者とデータのリスクも、判断材料に入れます。

費用と移行工数の過小評価

画面の数を基準にすると、開発や移行に必要な作業を十分に見積もれないことがあります。

• 見積もり範囲：権限や通知、帳票、例外処理を含めます。連携、移行、受入テストも対象です。
• 提示資料：機能一覧、業務シナリオ、データ項目を示します。連携先、利用者、非機能要件も渡します。
• 移行検証：サンプル変換、件数・金額照合、重複確認、現場受入を、複数回行います。

古いデータ形式が、新システムのルールに合わない場合があります。そのため、対象範囲を明記してもらい、本番移行の停止時間と切り戻し条件も決めておきます。

発注者側のマスタ整理や確認作業も工数に含めておくと、遅延を防ぎやすくなります。

担当者依存とベンダーロックインの回避

知識と運用が特定の担当者や事業者に偏ると、保守先を変えにくくなります。そこで、保守を続けられる体制を組んでおきます。

• 複数人で保守：コードレビュー、設計判断の記録、自動テストを行います。
• 発注者も管理：リポジトリとCI/CDを確認し、Sliceの責務や接続方法を文書化します。
• 資産と契約：発注者側でも管理できる形にし、保守先を変えられる契約にします。
• 役割分担：要件定義や運用設計を社内、実装や専門診断を外部に依頼する方法もあります。

Hanami経験者が一人だけだと、その人の退職後に保守できなくなる可能性があります。特定の事業者だけが扱える設定や、口頭でしか分からない運用を残さないことも大切です。

発注者側では、ソースコードや設計書、アカウント権限を管理します。監視設定、バックアップ、Gemのライセンス、障害履歴も管理対象です。

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

Hanamiを検討するときは、Railsとの違い、費用、開発会社の探し方、将来の保守が気になりやすいものです。そこで、発注前によく確認される質問に答えます。

Hanamiを使うとシステム開発費用は安くなりますか？

Hanamiはオープンソースですが、ライセンス料だけで費用が大きく下がるわけではありません。価格は、要件定義、設計、テストの工数に加えて、Ruby経験者の確保や移行、保守の工数で決まります。

不要な機能を作らず、SaaSや既存サービスと組み合わせることで、総額を抑えられる可能性があります。

HanamiとRailsはどちらを選べばよいですか？

標準機能を早く使いたい場合、チームにRails経験者が多い場合、既存のRails資産を活用したい場合は、Railsが合理的なことがあります。

一方、業務ロジックの境界を明確にしたい場合、軽量なAPIを作りたい場合、長期保守のためにデータ層と処理の責務を分けたい場合は、Hanamiを比較の候補にします。

両者を優劣だけで一律に決めず、PoCで主要業務を実装し、チームの生産性と保守性を確かめます。

Hanamiに対応できる開発会社はどのように探しますか？

Hanamiの直接実績と、RubyやRailsの業務システム実績は、分けて確認します。担当者の経験、テストと保守の体制も、同じように見ます。

Hanami 3.0とRuby 3.3以上への対応、SliceやOperationの設計方針、移行とセキュリティの責任範囲を質問します。可能なら小さな技術検証を依頼します。

公開事例の数だけでなく、自社の業務要件を理解して設計に落とし込めるかを重視します。

既存RailsシステムからHanamiへ移行できますか？

移行はできますが、全体を一度に書き換える方法はリスクが高いです。そのため、境界が明確な部分から選びます。たとえばAPIや管理画面のほか、検索や特定の業務Sliceなどが候補になります。

既存と新システムを段階的に連携させ、範囲を広げる前に検証します。特に確かめたいのは、データ整合性と認証、権限です。二重登録防止や切り替え手順、切り戻し条件も検証対象になります。

Hanamiのシステム開発完全ガイドまとめ

Hanamiは、RubyのWebアプリケーションや業務システムの責務を分け、業務ロジックを明示します。そのため、機能が増えても保守しやすい構造を目指せます。

独自の業務ルールを長く育てるシステムは、Hanamiを検討する対象になります。受発注や顧客管理、予約のほか、申請や外部API連携などが該当します。

導入判断で押さえる要点

導入時は、Hanami 3.0の機能や性能、Ruby 3.3以上への対応、チーム経験を確認します。そのうえで、費用と期間、データ移行、保守契約に加えて、認証・監査ログ・バックアップも一体で検討します。

推定費用の目安は、MVPが300万〜800万円、標準的な業務Webシステムが800万〜2,000万円、中・大規模が2,000万〜5,000万円以上です。要件と工数によって変わります。

着手前の確認事項

業務シナリオと非機能要件を整理し、主要業務を縦に通すPoCを行います。複数の提案は同じ前提で比較してください。

開発会社やサービスは、Hanamiの直接経験に加えて、業務理解や設計・テスト・移行・保守の体制を確認します。成果物と、どこまでを誰が受け持つかも見ておくと、公開実績が少なくても選びやすくなります。

▼関連記事一覧
・Hanamiのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Hanamiのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Hanamiのシステム開発の見積相場や費用/コスト/値段について
・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を創業。