Remixのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Remixのシステム開発は、業務の整理から始め、要件と技術の選定、設計・開発、テストを経て、移行と稼働後の定着へと進みます。各段階で業務の論点と技術の論点を分けて扱うと、判断が混ざりにくくなります。

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

Remixのシステム開発の全体像

URLルーティング、loader、action、SSRをWebアプリケーションの周囲に示した図解
データ取得と更新処理が同じ開発モデルに並びます。

Remixは、Reactで画面とサーバー処理を一体で設計できるフルスタックWebフレームワークです。たとえば、受発注や在庫、顧客管理の業務に活用できます。申請・承認やプロジェクト管理にも使えます。

開発では、利用者と業務を整理したうえで、データ、権限、利用頻度をアプリケーションと運用ルールに落とし込みます。特に社内業務では、Excelや紙、FAXなどに散らばった情報と二重入力を洗い出してから、流れを設計します。

Remixが担う業務システムの部分

Remixは、URLルーティングやデータ取得、フォーム送信、エラー処理を一つの開発モデルで扱います。さらに、SSRやビルドとデプロイも含みます。

  • データ取得:loaderで担当案件と顧客情報を読み込む処理
  • 更新処理:actionで登録・更新・承認を扱い、ルート単位で責務を整理
  • 別途設計する機能:DB、認証基盤、権限、帳票、バッチ、監視。

Remixでは、画面とAPIの状態を別々に管理する実装を減らしやすいのが特徴です。

ログインの可否と閲覧できるデータの制御は、別の要件です。部署や役職、案件担当、承認金額で操作の可否が変わるなら、認証と認可を設計書とテスト仕様書に明記します。

Remix v2とReact Router v7の選び方

利用するバージョンは、新規開発と既存案件で考え方が変わります。既存案件では、現在の資産や担当者の経験を踏まえて選びます。

  • 新規開発:React Router v7 Framework Modeが第一候補です。
  • 既存資産:担当者の経験も踏まえ、Remix v2の継続利用と比べます。
  • 保守性:Vite、SSRの実行場所、DB接続、認証、ジョブ、ログの確認

Remix公式は2024年11月、既存のRemix v2ユーザーにReact Router v7へのアップグレードを案内しました(出典: Remix公式「React Router v7」、2024年)。

見積依頼書には、採用するバージョンと、ReactとNode.jsの対応範囲を書きます。更新計画と依存パッケージの更新担当もあわせて記すと、後の更新作業で担当が迷いにくくなります。さらに、コードと設計書の納品範囲も決めておきます。

ShopifyのShop.appはRemixで開発され、2023年4月に着手して同年7月に初期の商品ページを公開した公式事例があります。ただし、短期の事例をそのまま複雑な基幹刷新に当てはめず、機能範囲と体制を比べて考えます。

ポイント

Remixは、データの読み込みと更新を同じ開発モデルで進めたい業務に向いています。DBや認証、権限などは別途設計が要るため、先に範囲を切り分けておくと、後の判断がぶれにくくなります。

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

Remix開発は6フェーズに分け、各段階の成果物と判断基準を先に合意してから進めます。要件が曖昧なまま画面開発に入ると、特に権限や移行、連携、運用の部分で追加費用が生じやすくなります。

  1. 業務と目的の整理
  2. 技術と開発会社の選定
  3. 設計と開発の小さな検証
  4. 業務シナリオと安全性のテスト
  5. 移行と稼働後の運用の整備
  6. 利用定着と継続改善

フェーズ1:業務と目的をそろえる要件整理

要件整理では、成果目標と、利用者ごとの業務フローを合わせて洗い出します。

  • 目的:入力時間の削減、承認状況の見える化、在庫ミスの削減。
  • 利用者・業務:管理者、営業、現場、取引先の登録・承認・帳票出力。
  • 資料整理:Excelや紙の列の意味、必須項目、重複、更新者、保存期間。

Excelや紙のサンプルを整理すると、データモデルの前提が見えてきます。

確認項目は、利用者数と同時利用者数、対象業務、画面・帳票・CSVです。加えて、権限と承認経路、外部APIも確認します。

既存システムとデータ移行の扱いを確かめます。個人情報や監査ログのほか、バックアップと復旧目標、稼働時間も確認します。

マスタ整備とデータクレンジング、仕様変更の承認は、それぞれどこまでを誰が受け持つかを決めます。そのうえで、成果物として残すのは、業務一覧と現行・将来フロー、要件定義書です。非機能要件、RFP、受入条件も、あわせて残します。

フェーズ2:技術と開発会社の選定

開発会社は、次の経験領域を見て選びます。Remixを使えるかどうかは、その一部です。

  • 上流・実装:要件定義、React・TypeScript、DB、認証・認可。
  • 基盤・運用:外部連携、クラウド、CI/CD、監視、脆弱性対応。
  • 提案内容:認可、エラー処理、入力検証、監査ログ、テストを含む構成。

画面サンプルだけでは、必要な経験を同じチームが持つかどうかは分かりません。そのため、発注側は担当チームの経験を確認します。

標準的な業務は、SaaSやパッケージでまかなえる場合があります。その場合は、Remixを不足機能のポータルや業務フロント、BFFに限定すると、範囲を抑えられることがあります。

固有の承認や複数基幹との連携が競争力に直結するなら、RemixまたはReact Routerを核にしたスクラッチ開発が適しています。

提案額に加えて、担当者の経歴や類似案件の規模を確認します。納品物と保守窓口も確かめます。契約終了時の引き継ぎと、React Router v7への移行方針も確認します。

フェーズ3:設計と開発の小さな検証

設計では、画面一覧だけでなくデータ処理と運用の構成も決めておきます。

  • アプリ構成:ルート、データ取得・更新、DBテーブル、API連携。
  • 安全性・運用:認証・認可、エラー境界、ログ、ジョブ、環境分離。
  • 検証版:2〜3週間程度で、ログイン、検索、登録、権限、代表的な連携を試す。

顧客管理では、一覧検索をloader、登録・更新をactionに置き、利用者の権限と顧客の所属を確認します。認可は、画面上のボタンを隠すだけでは成り立たず、サーバー側でも制御して初めて効きます。

画面だけのモックでは、データ量や通信の失敗、権限の差を確かめられません。また、入力エラーや業務手順も、画面だけでは確認できません。

利用者レビューでは、検索後の行動や例外時の対応を確かめます。その結果を踏まえて、優先順位を更新します。

フェーズ4:業務シナリオと安全性のテスト

テストは、単体テストに加えて、結合、総合、受入のテストまで実施します。性能、セキュリティ、障害復旧も含め、テストの範囲は業務ごとに整理します。

  • 受発注:受注から在庫引き当て、承認、出荷、請求までの一連の流れ。
  • 申請:差し戻し、代理承認、退職者の扱い。
  • 異常系:二重送信、同時更新、通信切断、不正CSV、権限外URL、API停止。
  • 脆弱性:SQLインジェクション、XSS、CSRF、セッション管理、認可漏れ、クリックジャッキング。

検査対象には、ファイルアップロードと依存パッケージの脆弱性も含めます。

React Router公式は、Framework ModeでCSPを使う際、SSRのインラインスクリプトに応答ごとのnonceを設定する方法を説明しています(出典: React Router公式「Security」、2026年参照)。

IPAも、認証と認可を分けて確認するよう示しています。たとえば、利用者AがURLを変えるだけで利用者Bのデータを見られないかを、テストで確かめます。

フェーズ5:稼働前後の移行と運用の整備

本番移行後の混乱を抑えるため、データ準備、稼働判定、切り替え方法を決めます。

  • データ移行:対象、変換、重複・欠損、リハーサル、切り戻し条件。
  • マスタ準備:発注側の担当部署、締切、確認者、形式。
  • 稼働判定:不具合、性能、バックアップ、監視、問い合わせ先、緊急連絡先。

データの準備を開発会社に任せきりにすると、表記ゆれや不要な過去データが本番に入り、検索や集計、権限に影響します。

本番の切り替えは、全社一斉のほか、1部署や1業務から始める段階稼働も選べます。

二重入力を設ける場合は、正とするシステムと切替時期、差分確認の方法を決めておきます。クラウドを使う場合は、個人データの保管場所とログの保持期間、アクセス制御を契約と設定で確かめます。あわせて、従量課金の上限と復旧時間も確認します。

フェーズ6:プロジェクトに含める定着支援

稼働後も、利用支援と改善を続ける体制を整えます。

  • 利用支援:操作説明、マスタ更新、権限申請、障害連絡、FAQ。
  • 状況確認:月次確認に加え、1・3・6か月などの節目で指標を見る。
  • 改善管理:緊急不具合、法令・セキュリティ、業務効果、利便性に分類。
  • 保守:契約と追加開発の範囲を分け、依存更新を定例化。

未利用の原因には、操作の難しさや旧運用との二重作業があります。さらに、入力項目の不明確さや承認者の不在、未決定のルールも原因になります。

確認する指標は、ログイン率、登録完了率、差し戻し件数です。加えて、処理時間と問い合わせ内容も見ます。

たとえば、2026年に報告されたCVE-2026-22030のように、CSRFに関わる情報を見逃さない運用が必要です。そのため、依存パッケージの更新と脆弱性情報の確認は、定例の作業にします。

ポイント

業務と技術の論点を分けたまま、段階ごとに次へ進めるかを決めると、要件の抜けに早く気づけます。次へ進む前の確認を、発注側と開発会社で同じ基準にそろえると、認識の差も減らせます。

Remixのシステム開発にかかる費用相場とコストの内訳

小規模PoC・社内ツール、中規模MVP、本番基盤、大規模案件の初期費用を横棒で比べる図
案件の規模が上がるほど、費用の幅も大きくなります。

Remixはオープンソースなので、費用の中心は開発の工数です。工数を左右するのは、特に要件定義と画面数、業務ルールです。

権限・ワークフローや移行、連携も工数に響きます。さらに、テストとインフラ、教育、保守も費用の一部になります。

Remix固有の国内平均の見積データは少ないため、次の数字は一般的なWeb業務システムの相場とリサーチ情報からの推定です。

規模別の初期費用と開発期間の目安

初期費用と開発期間は、案件の規模が上がるほど大きくなります。小規模PoCや社内ツールから大規模案件まで、4つの区分ごとの目安を並べます。

  • 小規模PoC・社内ツール:ログイン、検索、登録、CSV出力に絞り、100万〜300万円・1〜3か月。
  • 中規模MVP:部門横断の案件・顧客・受注管理、権限、通知、外部APIを含み、500万〜1,000万円・3〜6か月。
  • 本番基盤:在庫・受発注・ワークフロー、複数拠点、監査ログ、移行を含み、1,000万〜3,000万円超・6〜12か月以上。
  • 大規模案件:基幹連携、複雑なマスタ、多数利用者、段階移行、厳格なSLAで3,000万円から数億円規模の場合もあります。

SIA株式会社が2026年に公開した情報では、小規模は100万〜300万円、中規模は500万〜1,000万円とされています。

大規模は1,000万円〜数千万円以上で、人月単価は60万〜200万円程度とされています(出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年)。

Remixだからといって費用が半額になるとは限りません。そのため、業務範囲と品質基準をそろえて比べます。

費用を構成する項目と増額要因

工程ごとの配分を見ると、どの工程に手間が集まるかが分かります。一例として、要件定義が10〜15%、設計が25〜35%、実装・単体テストが30〜40%を占めます。

  • 結合・総合テスト:15〜20%程度。
  • 移行・教育:5〜10%程度。

この配分は案件ごとに変わる概算で、固定料金の標準ではありません。画面が少なくても、複雑な承認や細かな権限があれば、設計とテストの比率は高まります。外部APIや帳票のほか、監査ログや性能要件も、設計とテストの手間を増やします。

初期費用とは別に、基盤と運用の継続費用もかかります。

  • 基盤:クラウド、DB、監視、WAF、メール、ストレージ、CI/CD。
  • 運用:バックアップ、脆弱性診断、保守。
  • 保守費:初期開発費の年10〜20%程度が予算目安です。

保守費は、問い合わせ対応だけか、機能改善まで含むかで変わります。さらに、障害・脆弱性対応や夜間監視を含むかどうかでも変わります。

見積書では、月額や年額の利用料と、将来増える従量課金を分けて確認します。

ポイント

費用は、要件の複雑さや権限、連携、移行の範囲で大きく変わります。見積もりは、業務範囲と品質基準をそろえてから比べると、金額差の理由が見えやすくなります。

Remixのシステム開発で見積もりを取る際のポイント

見積もりで確認する性能・運用、データ保護、技術構成、進行・品質の4領域を示した図
同じ要件領域を各社の提案で照らし合わせられます。

合計額を比べる前に、各社が同じ前提で見積もっているかを確認します。要件の粒度がそろっていないと、安く見える提案にデータ移行や受入支援、監視、セキュリティ試験が含まれないことがあります。

発注側は、RFPと受入条件をそろえたうえで、追加費用が発生する条件を開発会社に明示してもらいます。

RFPに書く業務・データ・非機能要件

RFPには、開発の目的と業務、利用者数、困りごとを記します。対象外の業務も、あわせて書きます。

画面・帳票・CSVや承認、権限に加えて、連携と移行対象も書きます。さらに、時期と予算も記します。

  • 性能・運用:同時利用者数、応答時間、稼働時間、バックアップ、復旧時間、ログ、監視。
  • データ保護:保管場所、個人情報、アクセス制御、通信の暗号化。
  • 技術構成:Remix v2かReact Router v7 Framework Mode、SSRの有無、Vite、React・Node.js、DB、認証。

「高速」「安全」「使いやすい」といった言葉は、判断できる条件に言い換えておきます。

技術欄では、React・Node.jsのバージョンやクラウド、CI/CDを尋ねます。あわせて、ログ構成と採用理由、代替案も確かめます。ただし、特定のサービスへの固定が目的ではありません。

個人情報を扱う場合は、個人情報保護委員会のガイドラインに沿って要件を決めます。具体的には、アクセス制御や識別・認証、不正アクセス防止を要件に含めます。暗号化、ログ分析、委託先監督も、あわせて要件にします。

開発会社の見極め:Remixの経験と上流・運用の経験

コード例よりも、上流から定着までの経験を確認します。

  • 進行・品質:業務ヒアリング、現場レビュー、変更管理、テスト計画。
  • 移行・運用:リハーサル、障害対応、教育、保守体制。
  • 技術経験:React・TypeScript、サーバー処理、認証、DB、監視。

Remixの公開実績がなくても、これらの経験は評価の材料になります。ただし、公開情報にない実績や人数は推測せず、提案の際に確かめます。

担当予定者が打ち合わせに参加するかどうかと、設計・実装・テストの役割分担も確認します。

納品物は、コードと設計書、テスト仕様書、運用手順書を確認します。あわせて、React Router v7への移行影響と依存更新、脆弱性時の対応時間を質問します。

未確定事項と検証方法を明示している提案は、認識の違いを抑えやすくなります。

安い見積の前提条件とリスク

低価格の見積もりでは、範囲と責任分担、セキュリティ対応を確認します。

  • 範囲・責任:対象外、画面・帳票数、移行責任、外部サービスの契約者。
  • 運用条件:テストの種類、教育時間、保守受付時間。
  • 前提条件:「データ支給」「権限は標準機能」「本番クラウド費は別途」など。
  • 脆弱性対応:依存固定、更新担当、緊急対応、CSRF・Origin検証。

こうした前提は、金額の差を生みます。そのため、見積の備考だけでなく、契約書や要件定義書にも反映します。

セキュリティリスクも、見積の段階で確認します。たとえば、NVDのCVE-2026-22030は、Framework Modeのactionを使う構成などでCSRFの影響を説明しています。

なお、修正版はReact Router 7.12.0とRemixサーバーランタイム2.17.3とされています(出典: NVD「CVE-2026-22030」、2026年)。公開後に状況が変わることもあるため、契約前に対応内容を確認します。

ポイント

金額の比較は、前提がそろってからにします。安く見える提案ほど、含まれていない作業や前提条件を先に見ておく必要があります。

よくある質問(FAQ)

Remixのシステム開発では、費用やセキュリティについての質問を受けます。既存システムとの連携や社内定着、技術の将来性についても挙がります。発注前に判断しやすいよう、各質問では結論を先に示します。

Remixは社内の受発注や在庫管理システムに向いていますか?

向いていますが、業務の性質と周辺システムを確かめてから採用します。検索や登録、更新、承認が多い業務では、loaderとactionをルート単位で整理しやすい点が利点です。

会計や人事のように標準機能が中心なら、SaaSやパッケージを基盤にする選択もあります。その場合、Remixは不足するポータルや連携画面に限ると、総費用と運用負担を抑えられることがあります。

Remixのシステム開発費用はどのくらいかかりますか?

一般的なWeb業務システムの相場からの推定では、小規模PoC・社内ツールは100万〜300万円、中規模MVPは500万〜1,000万円です。

本番業務基盤は1,000万〜3,000万円超、大規模連携や複数拠点への移行は3,000万円から数億円規模になる可能性があります。

金額はライセンス料ではなく、要件やデータ、権限で変わります。連携やテスト、保守の範囲によっても変わるため、同じ条件で複数社へ依頼します。

Remixのシステムで個人情報を安全に扱えますか?

扱えますが、Remixを採用するだけで安全になるわけではありません。認証に加えて、データ単位と操作単位の認可を実装します。

設計と受入テストには、入力検証やCSRF対策、Cookie属性を含めます。加えて、通信の暗号化やCSP nonce、監査ログも対象にします。さらに、バックアップや脆弱性更新、アクセス権レビューも盛り込みます。

個人情報保護委員会の令和7年3月24日施行版ガイドラインや、IPAの安全なWebサイトの作り方を参照します。あわせて、委託先の監督と、インシデント時の連絡手順も決めておきます。

既存のJavaやSpringのシステムと連携できますか?

連携できますが、Remixからすべてを作り直すのではなく、既存システムのAPIやファイル連携、認証を整理します。更新頻度やエラー時の再送も、あわせて確認します。

Remixを業務フロントやBFFとして使い、既存の基幹処理を残す構成も選べます。

APIがない連携先では、CSVやバッチによる運用も検討します。その場合、二重登録やタイムラグの影響を受入条件に記載します。

ポイント

各質問の答えは、業務の性質や周辺システム、見積もりの範囲と合わせて読むと、発注前の判断に使いやすくなります。特に費用は、同じ条件で複数社に依頼してから比べると、判断の材料がそろいます。

まとめ

Remix開発は、要件整理から定着までの6段階で進めます。段階ごとに技術と業務の論点を分けると、管理しやすくなります。

2026年の新規案件では、React Router v7 Framework Modeも比べたうえで、採用するバージョンと更新方針を見積や契約に含めます。さらに、認証・認可とクラウド、監視、脆弱性対応の条件も、契約に含めます。

採用判断の基準:フレームワークより業務との適合性

Remixは、公開画面とログイン後の管理画面を、データの読み込みや更新まで同じ開発モデルで扱いたい案件に適します。

標準化やマスタ整備を省けば低価格・短納期になるわけではありません。移行やセキュリティ、保守も含めて考える必要があります。

現場の流れを確認したうえで、Remixで作る範囲と、SaaSや既存基幹に残す範囲を決めます。そうすると、過剰なスクラッチ開発を防げます。

最初に作る資料と次のアクション

Excelや紙、FAX、二重入力の情報を集め、1枚の資料に整理します。資料には、利用者と業務フロー、マスタを入れます。さらに、連携先や個人情報、課題指標も書き込みます。

資料をもとに、PoC、MVP、本番基盤のどこから始めるかを決め、同じRFPで複数社へ相談します。そのうえで、要件から保守までの範囲と成果物を確認します。さらに、追加費用の条件やReact Router v7の更新計画、定着支援も見ます。

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

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。