Hanamiのシステム開発会社は、Ruby/Railsでの業務Web開発、設計の分離、データ移行、保守まで確認できるかで比べます。
Hanamiは、Rubyで保守性の高いWebアプリケーションを構築するフレームワークです。比較対象は、株式会社riplaを含む実在の6社で、下の3点で比べます。
- HanamiとRuby/Railsの実績：Hanamiの直接の実績と、Ruby/Railsの業務システムの実績を分けて見る点
- 設計分離と移行：業務領域の分け方と、既存システムからの移し替えの進め方
- 費用・保守体制：見積もりの前提と、稼働後の保守を誰が受け持つか
▼全体ガイドの記事
・Hanamiのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Hanamiのシステム開発でパートナー選びが重要な理由
Hanamiは、フレームワークを導入するだけで業務システムが完成する製品ではありません。むしろ、業務ルールの境界と、どのデータを誰が扱うかを設計してはじめて、将来の変更に強いシステムになります。発注側と開発会社は、受発注から外部API連携まで、業務ごとにルールの境界を決めていきます。
- 受発注・請求：注文の受付から代金の請求までの業務ルール
- 顧客管理：顧客情報の登録・更新と、参照できる範囲
- 予約：予約の受付・変更・キャンセルの扱い
- 申請・承認：申請の内容を、誰がどこまで承認するか
- 外部API連携：外部サービスとやり取りするデータの範囲
Hanami専門会社の数より実装と保守の再現性
Hanamiの公開導入事例を、国内企業が十分に掲載しているケースは限られます。そのため、「Hanamiの本番実績が確認できる会社」と断定するより、RubyやRuby on Railsでの受託開発、業務システム、アジャイル、既存資産の移行、クラウド運用の実績を周辺の証拠として確認するのが現実的です。
候補会社には、Hanami 3.0または採用予定のバージョンを扱える担当者がいるか、Action・Operation・Sliceをどう分けるかを、提案段階で説明してもらいます。
フレームワーク以外の要件が左右するプロジェクトの成否
業務システムでは、ログインや画面表示のほかに、SSOや二要素認証、部署別権限まで決める必要があります。加えて、稼働後の運用に関わる要件も、フレームワークとは別に決めておきます。
- 操作履歴：誰が何を変更したかを追える範囲
- バックアップ：データを戻すための保存の仕組み
- 障害復旧：障害が起きたあと、業務を再開するまでの手順
- 脆弱性対応：利用しているソフトウェアの弱点を見つけて直す体制
- データ移行：既存システムのデータを新しいシステムへ移す範囲
個人情報保護委員会は、安全管理措置を事業規模や保有データの性質・量などのリスクに応じて、必要かつ適切に設計する考え方を示しています（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年）。提案を比べるときは、Hanamiの機能の有無だけでなく、アプリケーション、クラウド、運用ルール、契約上どこまでを誰が受け持つかを一体で提案できるかを比べてください。
株式会社ripla｜コンサルティングから開発まで一気通貫で支援
riplaは、コンサルティングから開発までを一気通貫で支援する会社です。IT事業会社として社内DXを推進してきた経験を活かし、事業への成果創出とシステムの定着支援に強みがあります。
営業・顧客・生産・販売管理など、幅広い基幹システムの構築・導入実績があり、企業の業務要件に合わせて柔軟に対応できる体制も整えています。
特徴と強み
riplaに相談する価値は、技術を先に決めず、業務上の成果からシステム要件へ落とし込みやすい点にあります。
Hanamiを全面採用するか、APIや独自ワークフローだけに使うか、SaaSやパッケージと併用するかは、現行業務と将来の運用体制から検討できます。PoCでは、次の範囲を小さな縦切りで検証しておくと、開発後半の大きな手戻りを抑えやすくなります。
- ログイン・権限：利用者の認証と、役割ごとの操作範囲
- 主要業務の登録・承認・検索：一連の業務を縦に通して動かす範囲
- データベース：データの保存と読み出しを実際に試す部分
- CI/CD：テストと配備を自動化する仕組み
- 監視：稼働後の状態を見守る仕組み
得意領域とHanami案件で確認したい点
業務フローが複雑で、部門ごとに承認やデータ連携が異なり、導入後の定着まで支援してほしい企業に適しています。
見積もりでは、要件定義、画面・API設計、Sliceの分割を分けて見ることが大切です。加えて、テストから保守までの作業も、どこまでを誰が担うかを切り分けておきます。
- テスト：動作を確かめる作業と、その範囲
- 移行：既存のシステムからデータや業務を移す作業
- 研修：発注側の担当者が新しいシステムを扱えるようにする作業
- 保守：稼働後の改修や障害対応を続ける作業
「Hanami 3.0とRuby 3.3の構成で対応できるか」「RailsやSaaSを併用する判断基準は何か」「ソースコード、テスト、インフラ設定、運用手順の納品範囲はどこまでか」を聞けば、提案の実行力を比べられます。
株式会社永和システムマネジメント｜Rubyとアジャイルの専門性を活かした共創型開発
株式会社永和システムマネジメントは、公式サイトでRubyとアジャイルによる受託開発、アジャイルコンサルティングを提供しています。公式情報では、ソフトウェアをビジネスの中心に据える顧客と課題を解決するRuby x Agileを掲げ、会社として45年、アジャイル事業部として10年以上の経験を紹介しています。
ただし、Hanamiそのものの公開導入実績は、依頼前に確かめます。そのうえで、設計品質と顧客との共創を重視する会社として比べられる候補です。
特徴と強み
永和システムマネジメントの公式情報では、動くソフトウェアを定期的に用意し、顧客からフィードバックを受けながら育てる開発を重視しています。さらに、読みやすく保守しやすい設計や自動テスト、仕様変更に対応しやすい進め方も重視しています。こうした進め方は、要件が変わりやすい新規事業や、発注側も開発チームに加わりたい案件と相性を見やすいです。
Rubyコミュニティとの接点も、技術の継続性を評価する材料になります。
得意領域とHanami案件で確認したい点
社内にプロダクト責任者や業務担当者がいて、短いサイクルで業務の優先順位を見直したい企業に適しています。
Hanamiでは、顧客管理や受注などのSliceをどう分けるか、Operationで承認や在庫引当をどう表すかを、ワークショップで確認する価値があります。
発注側は、契約前に、準委任型か請負型か、顧客側に必要な稼働時間、納品物と自動テストの範囲、リリース後の技術顧問や保守の有無を整理しておきます。
株式会社万葉｜Ruby・Railsの受託開発と既存資産の継続改善
株式会社万葉は、公式サイトでRuby、Ruby on Railsを使ったソフトウェアの受託開発を行い、商用サービス、社内システム、OSS、既存ソフトウェアのRuby・Railsバージョンアップに対応すると説明しています。さらに、問い合わせから納品までには、規模によって3か月以上かかることが多いという目安も公開しています。
Hanamiへの対応可否は個別に確認が必要です。ただし、Ruby資産を長く運用しながら改善したい企業にとっては、検討しやすい会社です。
特徴と強み
万葉は新規開発だけでなく、既存ソフトウェアのバージョンアップ、運用準備、アプリケーション保守、開発チームへのメンバー参加にも対応すると公開しています。Hanamiの導入を新規開発だけに限らず、既存Railsの一部をAPIやSlice単位で切り出す、あるいは古いRuby資産を段階的に更新する計画にしたい場合は、移行と保守を同じ視点で相談できる可能性があります。
得意領域とHanami案件で確認したい点
Rubyで動いている社内システムの技術的負債を減らしたい企業や、内製チームの不足を外部メンバーで補いたい企業に適しています。
提案時には、既存コードとGemを洗い出したうえで、テスト不足をどう補うか、データ移行や切り戻し方法を含めた移行計画を示せるかを確認します。Hanami 3.0へ直接移行する場合は、Ruby 3.3以上という要件や周辺Gem、認証・ジョブ処理の互換性を検証するPoCの費用と納品物を、明確にしてください。
株式会社Ruby開発｜Rubyを中心としたWebサービスとセキュリティ体制の相談
株式会社Ruby開発は、公式サイトでRuby on Railsを中心とした受託システム開発や、SPA、AI、IoT連携などの取り組みを紹介しています。さらに、会社概要では2012年設立、Ruby Association Certified System Integrator Goldの取得、ISMS認証の取得を公開しています。
Hanamiの直接実績がある会社として見るより、Rubyを中核にWebシステムとセキュリティ運用をまとめて相談できる候補として比べると分かりやすいです。
特徴と強み
Rubyに加えてフロントエンドや外部デバイス、AIなどを組み合わせる必要がある案件では、バックエンドだけでなく連携部分まで含めた体制が大切です。
個人情報や機密情報を扱う業務システムでは、認証・権限・ログ監視・脆弱性対応を、要件定義の段階から組み込みます。
ISMSを取得しているかどうかは、安全を保証するものではありません。ただし、組織的な情報管理を確認する一つの材料になります。
得意領域とHanami案件で確認したい点
Rubyを使った新規Webサービスや、外部システム・デバイスと連携する業務システムを検討している企業に合います。
Hanamiを採用する場合は、ActionとOperationのテスト方針、Relation・Repoにおけるデータアクセスの責務、APIの認証方式、クラウドと監視の担当範囲を具体的に聞いてください。
ISMSの運用範囲、委託先管理、インシデント発生時の連絡体制は、契約書や提案書の記載で確認します。
株式会社ゼネット｜既存Ruby資産の移行・保守とアジャイル開発
株式会社ゼネットは、公式サイトで2007年からRuby on Railsを用いたシステム開発と保守を行っていると説明しています。さらに、Railsのバージョンアップ、Gemの更新や代替、巨大化したWebアプリケーションのサービス単位での分離、他言語からRubyへのリプレイスなどの実績を公開しています。
Hanamiの経験は案件ごとに確認が必要です。既存のRuby資産を安全に更新したい会社にとっては、移行力を比べやすい候補です。
特徴と強み
公式情報では、2週間から1か月のイテレーションで設計と開発を進めるアジャイル支援にも対応しています。実際に動く画面を見ながら要件を絞りたい場合や、既存システムの機能追加を段階的に行いたい場合に検討しやすいです。
AWSやフロントエンド技術といった、Hanamiを載せる周辺構成も含めて、現状のシステムをどの単位で分けるかを相談できます。
得意領域とHanami案件で確認したい点
既存Railsの老朽化、Gemの保守切れ、巨大化したアプリケーション、他言語システムからの段階移行に課題がある企業に適しています。
依頼時には、現行コードの調査期間、テストを追加する順番、データベースの変更方法、並行稼働と切り戻し、旧システムを停止する条件を確認します。Hanamiへ移すこと自体が目的にならないよう、性能、保守コスト、開発者の引き継ぎやすさをKPIに置くことが大切です。
株式会社Cuon｜業務・エンタープライズアプリケーションをRubyとAWSで支援
株式会社Cuonは、公式サイトでエンタープライズアプリケーションを掲げ、Ruby on RailsやAWSを使った業務システム・Webサービスの開発事例を紹介しています。ECサイトのリプレース、顧客管理のDX化、注文状況を管理するクラウドサービスなど、業務データを扱う案件が掲載されています。
Hanami専門の実績があるというより、業務アプリケーション、クラウド、周辺サービスをまとめて検討する候補として位置づけます。
特徴と強み
Cuonの公開事例には、AWSとRuby on Railsを組み合わせた注文・管理系のシステムが含まれています。
業務システムでは、アプリケーションだけでなく、可用性、データ保護、監視、外部サービス連携、管理者権限までまとめて設計する必要があります。HanamiのSliceを業務領域の境界として使い、AWS上のデータベースやストレージ、ログ基盤とどう接続するかを提案できるかが、比較のポイントです。
得意領域とHanami案件で確認したい点
複数の業務データや外部サービスをつなぐエンタープライズ系のWebシステム、EC・顧客管理・注文管理を一体で改善したい企業に適しています。
見積もりでは、Hanami本体の開発費とAWSの構築を分けて見るのがよいです。監視、バックアップ、性能試験、障害対応、セキュリティ診断は、AWSの構築と合わせて見積もります。
2026年時点の担当者のHanami経験、Ruby 3.3以上の環境、既存Railsとの連携可否は、提案時に回答を得ておきます。
Hanamiのシステム開発会社を選ぶポイント
6社を比べるときは、会社名の知名度や単価だけでなく、Hanamiを採用した後に業務を安全に運用できるかで評価します。直接のHanami実績が公開されていない場合は、提案の具体性、担当者の経歴、テストと保守の設計を見ます。実績、技術力、見積もりと保守の3点は、同じ質問票で聞くと会社ごとの差が見えやすくなります。
Hanami、Ruby、業務領域に分けた実績の確認
実績は「Hanamiを本番運用した事例」「Ruby/Railsでの業務システム事例」「一般的なWeb制作事例」を分けて評価します。Ruby/Railsの実績は、Hanamiの直接実績ではありません。ただし、Rubyの言語特性、テスト、Gemの管理、クラウド運用を理解しているかを見る材料になります。
問い合わせの際は、実績の公開可否、担当者の役割、開発期間、利用者数、保守年数、採用した認証・監視・バックアップの考え方まで聞いてください。
構成図とコード品質の説明による技術力の見極め
技術提案では、業務シナリオごとに、Hanamiのどの構成要素が動くかを示した構成図を求めます。
- Action：リクエストを受ける入口の部分
- Operation：業務の処理をまとめる部分
- View：画面の表示を整える部分
- Relation・Repo・Struct：データの読み書きを担う部分
- Slice：業務領域ごとに分けた単位
受注SliceのActionが受付を担当し、Operationが在庫引当と承認を扱い、Relation・Repoがデータアクセスを担い、Viewが表示を整える、と説明できれば、責務分離の考え方を確認できます。
テストの種類、CI/CD、RubyとGemの更新方針、依存ライブラリの脆弱性対応、性能試験の条件は、言葉だけでなく実際のサンプルを見て確認することが大切です。
総額と、どこまでを誰が受け持つかで比べる見積もりと保守
Hanami自体はオープンソースのため、フレームワークのライセンス料だけで費用が決まるわけではありません。
2025年時点の国内システム開発の参考として、PMは月70万〜130万円、シニアエンジニアは月80万〜120万円、中堅エンジニアは月50万〜70万円程度という人月単価が紹介されています（出典：株式会社ripla「官公庁のシステム開発の見積相場や費用/コスト/値段について」、2025年）。
Hanami固有の確定価格はないため、見積もりは作業ごとに分けて見ます。要件定義、画面数、権限は一緒に見積もり、外部連携と移行は別に見積もります。テストは稼働前の作業、運用は稼働後の作業として、別々に見ます。
規模によって費用の幅は大きく変わるため、目安は規模ごとに分けて見ます。
- MVP（小規模）：ログイン、数画面のCRUD、簡易管理画面、少数APIの構成で、300万〜800万円
- 標準的な業務Webシステム：ユーザー・権限、申請・承認、検索・帳票、外部APIを含む場合で、800万〜2,000万円
- 中核業務・大規模：中核業務や会計・在庫連携、複数部門、データ移行、監査要件を含む場合で、2,000万〜5,000万円以上を想定
目安の金額は、類似するRuby/Web業務システムからの推定であり、Hanamiを採用しただけで安くなるという意味ではありません。
保守の費用は、稼働後の作業ごとに分けて見ます。クラウド利用料は稼働を続けるあいだかかり、監視とバックアップもその上で続く作業です。障害対応と軽微な改修は、発生したときや依頼があったときに都度かかります。Ruby・Gem・Hanamiの更新と脆弱性対応は、保守の中で継続して行う作業です。
初期費用1,000万円の案件なら、保守費を年150万〜200万円程度、つまり初期費用の15〜20%で仮置きする考え方があります。ただし、24時間監視、SLA、セキュリティ診断、法改正対応を含めると、この額より上振れします。
契約書では、ソースコードとGemfile.lockを成果物として明記し、CI/CD定義とインフラコードも受け取れるようにしておくと、将来のベンダーロックインを抑えられます。テスト仕様と運用手順も納品に含め、障害時の連絡時間を条件として決めておきます。
よくある質問
Hanamiのシステム開発を発注する前に、多くの企業が「本当に会社が見つかるのか」「Railsより安いのか」「将来も保守できるのか」で迷います。比較検討で特に多い3つの質問に、直接答えます。
Hanamiを専門に扱う会社はありますか？
公開情報だけで、Hanamiの本番実績を持つ国内会社を多数比較することは難しい状況です。Ruby/Railsの業務システム経験を持つ会社には、次の項目を確認してください。
- Hanamiのバージョン：採用予定のバージョンに対応できるか
- 担当者の実務経験：Hanamiでの作業経験の有無と範囲
- Action・Operation・Sliceの設計例：業務ごとの分け方を示せるか
- テストと保守の方法：テストの進め方と、稼働後の保守体制
直接実績がない場合は、PoCを先に実施して技術と体制を評価します。
HanamiならRailsより開発費用を安くできますか？
Hanamiを採用しただけでRailsより安くなるとは限りません。費用を左右するのは、主に次の項目です。
- 要件定義・設計：仕様をどこまで決め、どう組み立てるか
- 画面とAPIの数：作る画面と接続先の多さ
- 認証・権限・データ連携：利用者の制御と外部システムとのつながり
- 移行・テスト：既存データの移し替えと、動作確認の量
- インフラ・保守：稼働させる環境と、稼働後に続く作業
Hanamiの関心分離やSliceによって長期保守の手戻りを抑えられる可能性はあります。ただし、初期PoCやチームの学習に必要な工数も含めて、5年程度の総所有コストで比べるのが適切です。
Hanami 3.0を採用するときに何を確認しますか？
Hanami公式の2026年6月発表では、Hanami 3.0はRuby 3.3以上を要求し、メーラー、国際化、Minitest、改善されたログ、リクエストボディ解析などが追加されています。同発表には、テストアプリで同一のHTTPリクエストを処理した場合のベンチマークとして、2.3比で約3.7倍のスループットと、p99レイテンシ20msから4msも掲載されています（出典：Hanakai「Hanami 3.0: In full bloom」、2026年）。
ただし、実システムの性能はDB、外部API、クエリ、インフラによって変わるため、自社シナリオで負荷試験を行い、Ruby・Gem・OSの互換性も確認してください。
まとめ
Hanamiのシステム開発会社を選ぶときは、Hanami専門という表示だけで決めず、Ruby/Railsの業務実績、設計とテスト、データ移行、クラウド、保守を同じ基準で比べてください。
今回紹介した6社は、株式会社ripla、株式会社永和システムマネジメント、株式会社万葉、株式会社Ruby開発、株式会社ゼネット、株式会社Cuonです。
各社のHanami 3.0対応可否や担当者の経験は、発注時点で必ず確認します。
業務シナリオと非機能要件の1枚整理
問い合わせ前には、利用者の種類、主要業務の流れ、必要な画面とAPI、外部連携、データ移行の有無を整理します。さらに、非機能要件として次の項目も書き出しておきます。
- 想定同時利用者数：同時に使う人数の見込み
- 目標応答時間：操作に対して画面が返るまでの目標時間
- 稼働率・保守時間：システムを動かし続ける割合と、保守に充てる時間
- RPO・RTO：障害時に戻せるデータの時点と、復旧までの時間
- 監査ログ：誰がいつ何をしたかを残す範囲
見積もりの前提がそろうほど、会社ごとの価格差が工数の差なのか、対象範囲の差なのかを判断しやすくなります。また、全機能を一度に作るより、主要な登録・承認・検索を縦切りで先に検証する方法も有効です。
Hanami採用の判断と保守契約を分けた検証
Hanamiは、業務ロジックの境界を明確にしたい、長期的な保守性を重視したい、軽量なAPIや独自ワークフローを作りたい場合に検討価値があります。標準業務をSaaSやパッケージで満たせる場合は、Hanamiを独自部分に限定する方が合理的なこともあります。
そのうえで、技術選定、PoC、本開発、移行、保守を分けて契約することが、開発会社選びの最終的なポイントです。成果物として、設計書、テスト、ソースコード、インフラ設定を受け取れる体制も整えておきます。
▼全体ガイドの記事
・Hanamiのシステム開発の完全ガイド
▼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を創業。