Hanamiのシステム開発の完全ガイド - ブログ

Hanamiのシステムとは、Rubyで保守性の高いWebアプリケーションや業務システムを構築するためのフレームワークで、業務ロジックとデータアクセスを分離しやすい点が特徴です。

受発注、顧客管理、予約、社内申請、API連携などを検討している方に向けて、Hanamiの全体像、適したシステムの種類、開発の進め方、費用相場、開発会社・サービスの選び方、保守とセキュリティまでをまとめます。Hanamiを採用すれば自動的に安くなるわけではありませんが、長く使うシステムの責務を整理し、変更に強い構造をつくりたい場合は有力な選択肢になります。

Hanamiのシステムとは何ですか？全体像を解説します

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

Hanamiが目指す設計思想

Railsのように多くの機能を一体で提供するフルスタック寄りの考え方に対して、Hanamiは必要な部品を組み合わせ、役割を明確にする方向性が強いです。画面を表示する処理、業務上の判断、データベースへの問い合わせを別々に扱うため、担当者が変わっても「どこに何を書くべきか」を判断しやすくなります。

この設計は、短期的な画面追加だけを目的にする場合よりも、承認条件、料金計算、在庫引当、契約状態などの業務ルールが積み重なるシステムで効果を発揮します。一方で、自由度がある分、設計方針を決めずに開発を始めると、チームごとに実装方法がばらばらになるため、最初に責務と命名規則を合意することが大切です。

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

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やパッケージを中心に検討した方がよい場合があります。業務の大部分が既製機能で満たせるなら、独自開発よりも導入設定とデータ移行に予算を使う方が合理的です。逆に、独自の審査、料金計算、現場フローが競争力に直結する場合は、Hanamiを含むスクラッチ開発の価値が高まります。

Railsとの比較では、開発者の経験、利用するGem、既存資産、納期、将来の採用計画を確認します。Railsが不適切という意味ではなく、チームがRailsに強く、標準機能を多く使える場合はRailsが早いこともあります。Hanamiは、責務を明確にして長期保守したい、軽量なAPIを作りたい、複数の業務領域を境界づけたい、といった条件で比較対象にすると判断しやすいです。

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

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

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

要件定義で業務と非機能を数値化します

まず、誰が、いつ、何を判断し、次にどのデータを渡すのかを業務シナリオで整理します。たとえば「申請する」だけでなく、申請者、承認者、差し戻し条件、承認期限、通知先、監査で残す情報まで定義します。顧客、商品、組織、権限などのマスタを誰が管理するのかも、発注前に決めておく必要があります。

非機能要件は、同時利用者数、応答時間、稼働率、バックアップ頻度、障害復旧の目標、ログ保存期間、データの保管場所、サポート時間などを数値で合意します。個人情報を扱う場合は、権限、暗号化、操作ログ、脆弱性対応、委託先管理を機能要件とは別の一覧にすると、後から抜け漏れが見つかりにくくなります。

小さな縦切りで技術成立性を検証します

次に、ログインから主要業務の登録、承認、検索までを一本の流れとして試作します。Hanamiのバージョン、Ruby、データベース、認証、CI/CD、監視、メール送信をこの段階で組み合わせ、開発者が理解できるかだけでなく、本番運用に必要な仕組みが成立するかを確認します。

2026年時点のHanami 3.0では、メーラー、国際化、Minitest、改善されたログ、リクエストボディ解析などが追加されています。公式のテストアプリでは、2.3と比べて同一HTTPリクエストのスループットが約3.7倍、p99レイテンシが20msから4msになったと報告されていますが、これは特定条件での計測です（出典: Hanakai公式「Hanami 3.0: In full bloom」、2026年）。実案件では、自社のデータ量と外部連携を含めた負荷試験で判断します。

設計・開発・移行・リリースを段階化します

本開発では、Sliceの境界、ActionとOperationの責務、RelationやRepoのデータアクセス方針を設計書に残します。単体テストでは業務ルールの成功・失敗を確認し、結合テストでは外部APIやメール、権限を確認し、総合テストでは実際の業務シナリオを通します。テストデータには個人情報をそのまま使わず、マスキングや匿名化の方法も決めておきます。

データ移行は本番直前に初めて行うのではなく、サンプル移行、名寄せ、欠損補完、重複処理、移行後の照合を早く試します。リリース後は、設計書、テスト仕様書、ソースコード、Gemfile.lock、CI/CD定義、インフラ設定、運用手順、障害時の連絡ルールを納品物と保守契約に含めると、担当者や委託先が変わっても継続しやすくなります。

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

Hanami固有の一律料金表はありません。費用はフレームワークのライセンス料ではなく、要件定義、設計、実装、テスト、データ移行、インフラ、運用設計に必要な工数で決まります。以下は、業務Webシステムの要件をHanamiで実装する場合の推定レンジであり、実際の見積もりを保証するものではありません。

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

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

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

ログイン、数画面のCRUD、簡易管理画面、少数のAPIを備えたPoC・MVPは、300万〜800万円程度、期間は3〜5か月が一つの目安です。ユーザー・権限、申請・承認、検索・帳票、メール、外部APIを含む標準的な業務Webシステムは、800万〜2,000万円程度、期間は6〜10か月が目安になります。

複数部門、複雑なワークフロー、基幹・会計・在庫連携、データ移行、監査対応まで含む中・大規模案件は、2,000万〜5,000万円以上、期間は10〜18か月以上になる可能性があります。これらはHanamiだけの公開統計ではなく、類似する国内Ruby・Web業務システムの要件から組み立てた推定です。デジタル庁の実践ガイドブックでも、システム開発費は作業の工数と単価を分けて積算し、項目ごとの妥当性を確認する考え方が示されています。出典はデジタル庁「標準ガイドライン実践ガイドブック」（2025年）です。

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

人月単価と工数だけでなく、要件定義・基本設計、製造・単体テスト、結合・総合テスト、移行・導入、プロジェクト管理の金額を分けて確認します。2025年時点の公開相場情報では、PMクラスは月70万〜130万円、シニアエンジニアは月80万〜120万円、中堅エンジニアは月50万〜70万円程度とされる例があります。ただし、Hanamiの経験、既存Gemの調査、品質保証、セキュリティ対応によって変動するため、単価の安さだけで比較してはいけません。出典は2025年公開の国内システム開発費用情報です。

初期費用以外では、クラウド、データベース、メール配信、監視、バックアップ、脆弱性診断、Ruby・Gem・Hanamiの更新、問い合わせ対応、追加改修を分けます。スクラッチ開発の保守費は初期費用の年15〜20％程度を第一候補として試算できますが、24時間監視、SLA、緊急対応、セキュリティ診断を含めると上振れします。5年間の総保有コストで比較すると、安い初期見積もりが必ずしも有利とは限りません。

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

Hanami専門をうたう事業者は多くないため、検索結果の「Ruby対応」だけで判断しないことが大切です。Hanamiの本番経験、RubyやWeb業務システムの開発経験、設計・テスト・移行・保守の体制を分けて確認し、自社の要件に近いかを見極めます。Hanamiの直接事例が公開されていない場合は、その事実を前提に、技術検証と担当者の経験を確認します。

実績と担当者の経験を確認します

確認したいのは、会社名の数ではなく、似た業務の複雑さを扱った経験です。受発注、請求、在庫、権限、外部API、データ移行のどれに強いのか、公開できる範囲で事例の背景と担当範囲を聞きます。RubyやRailsの実績は有力な周辺証拠になりますが、Hanamiの実績とは区別して評価します。

問い合わせ時には、「Hanami 3.0とRuby 3.3以上の経験者をアサインできるか」「Action、Operation、Slice、RelationやRepoをどのように設計するか」「認証、監査ログ、バックアップ、障害対応を誰が担当するか」を質問します。口頭の回答だけでなく、匿名化した設計サンプル、テスト方針、レビュー体制を確認できると、実装力を判断しやすくなります。

提案・見積もり・契約範囲を比較します

複数の提案を比べるときは、金額の合計だけでなく、前提条件、対象外の機能、想定工数、納期、検収条件、変更管理の方法をそろえます。要件定義を低額にして後工程で追加請求する提案もあるため、何を成果物とするか、決めきれない要件をどう扱うかを確認します。準委任、請負、アジャイルのどれが適するかも、業務の不確実性と社内の意思決定速度を踏まえて決めます。

納品物には、ソースコードだけでなく、設計書、テスト仕様と結果、データ移行手順、運用手順、インフラ設定、依存ライブラリの一覧、脆弱性対応の責任範囲を含めます。ソースコードの権利、リポジトリへのアクセス、第三者Gemのライセンス、保守終了時の引き継ぎも契約書で確認します。サービスを組み合わせる場合は、障害時の責任分界とデータのエクスポート方法も重要です。

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

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

Hanamiはアプリケーションの構造を整えるフレームワークであり、業務システムの安全性をすべて自動で保証するものではありません。認証や認可、監査ログ、バックアップ、ネットワーク、脆弱性管理、従業者教育、障害対応を、アプリ・インフラ・組織運用の三つに分けて要件化します。

権限・ログ・個人情報を要件に含めます

権限は「ログインできるか」だけでなく、部門、役職、担当顧客、操作種別ごとに閲覧・登録・承認・出力の範囲を定義します。重要操作には誰が、いつ、何を変更したかを記録し、ログの改ざん防止、保存期間、検索方法、監査時の取り出し方まで決めます。二要素認証、セッション管理、パスワード方針、管理者の緊急権限も、利用者の種類ごとに整理します。

個人情報を扱う場合、個人情報保護委員会の通則編では、基本方針、取扱規律、組織的・人的・物理的・技術的な安全管理措置、外的環境の把握などが示されています。アクセス制御や不正アクセス対策だけでなく、責任者、研修、自己点検、委託先との役割分担も必要です。出典は個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」（2026年8月確認）です。

バージョン更新と障害対応を運用します

2026年7月時点でRubyGemsに公開されているHanamiの最新安定版は3.0.1で、Ruby 3.3以上が必要です（出典: RubyGems「hanami」、2026年7月）。既存環境が古いRubyやGemに依存している場合は、開発開始前に互換性を確認し、アップデートの検証環境と切り戻し手順を用意します。Ruby 3.3系の通常メンテナンス終了時期も公開情報で示されているため、採用時点だけでなく、次の更新計画まで見通す必要があります。

保守契約では、問い合わせ窓口、一次切り分け、復旧目標、脆弱性情報の確認、依存Gemの更新、バックアップの復元テスト、障害報告、軽微な改修の範囲を決めます。年一回の更新だけでなく、定期的なログレビュー、負荷の変化、権限棚卸し、移行データの品質確認を運用カレンダーに入れると、使い始めてからのリスクを下げられます。

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

Hanamiは構造を整理しやすい一方で、採用理由が曖昧なまま技術から着手すると、RailsやSaaSとの比較ができず、開発後に運用負担が見つかることがあります。失敗を避けるには、フレームワークの好き嫌いではなく、業務の変化、チームの技術力、保守期間、利用者とデータのリスクを基準に判断します。

費用と移行工数を過小評価しないことです

画面数だけで費用を見積もると、権限、通知、帳票、例外処理、外部連携、データ移行、受入テストが抜けやすいです。見積もりでは、機能一覧に加えて業務シナリオ、データ項目、連携先、利用者の種類、非機能要件を渡し、含むものと含まないものを明記してもらいます。

移行では、古いデータの形式が新システムのルールに合わないことがあります。サンプルを使った変換、件数照合、金額照合、重複確認、現場による受入を複数回行い、本番移行の停止時間と切り戻し条件を決めます。発注者側のマスタ整理や確認作業も工数に含めると、スケジュールの遅れを防ぎやすいです。

担当者依存とベンダーロックインを避けます

Hanamiの経験者が一人しかいない状態で開発を進めると、その人が離れたときに保守できなくなる可能性があります。コードレビューを複数人で行い、設計判断を記録し、テストを自動化し、リポジトリとCI/CDを発注者も確認できる状態にします。Sliceごとの責務や、外部サービスとの接続方法を文書化することも引き継ぎに役立ちます。

また、特定の事業者しか触れない独自設定や、口頭でしか分からない運用を残さないことが大切です。ソースコード、設計書、アカウント権限、監視設定、バックアップ、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アプリケーションや業務システムの責務を分け、業務ロジックを明示し、機能が増えても保守しやすい構造を目指すフレームワークです。受発注、顧客管理、予約、申請、外部API連携など、独自の業務ルールを長く育てるシステムで検討しやすいです。

導入判断で押さえる要点

導入判断では、Hanami 3.0の機能や性能だけでなく、Ruby 3.3以上への対応、チームの経験、費用と期間、データ移行、認証・監査ログ・バックアップ、保守契約までを一つの計画として確認します。費用はMVPで300万〜800万円、標準的な業務Webシステムで800万〜2,000万円、中・大規模で2,000万〜5,000万円以上が推定の目安ですが、要件と工数によって変わります。

着手前に確認すること

最初に業務シナリオと非機能要件を整理し、主要業務を縦に通すPoCを行い、複数の提案を同じ前提で比較してください。開発会社やサービスは、Hanamiの直接経験だけでなく、業務理解、設計・テスト・移行・保守の体制、成果物と責任分界を確認すると、公開実績の少なさに左右されずに選びやすくなります。