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

Remixのシステム開発では、業務内容、既製サービスとの組み合わせ、開発範囲を整理すれば、顧客管理や受発注などの業務に合わせて設計できます。

業務で使う場合は、Remixで作る範囲と既製サービスに任せる範囲を分けると、費用とリスクを抑えやすくなります。詳細は関連記事もご覧ください。

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

AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。

Remixのシステムの概要

RemixはReactを基盤に、画面表示、データ取得、フォーム処理、認証、サーバー処理を一体で設計するフルスタックWebシステムです。ブラウザ画面を作るライブラリとは異なり、サーバー側の処理までを含みます。さらに、URLに対応した画面構成から、エラー表示、ビルド、デプロイまでを一つの開発モデルで扱える点が特徴です。

Web標準を重視するフルスタックフレームワーク

RemixはHTTPのリクエストとレスポンス、フォーム、Cookie、セッションなど、Web標準の仕組みを中心にアプリケーションを組み立てます。

画面ごとにデータ取得の責任を定めて、必要な処理はサーバーで実行してから画面に返します。そのため、ブラウザ側の状態管理コードを増やしすぎずに済みます。

案件一覧なら、一覧データの取得、検索条件の受け取り、案件登録をルート単位で整理できます。画面表示と業務処理の場所が明確になり、担当者が増えても仕様を追いやすい構成です。

loaderとactionによる読み取りと更新の分担

Remixの設計を理解するには、loaderとactionの役割を分けて捉えます。

• loader：画面表示に必要なデータを読み込みます。
• action：フォーム送信を受けて登録・更新・削除を実行し、受注登録、承認、在庫引当、顧客情報の変更を扱う処理です。

安全性は、loaderとactionを分けるだけでは確保されません。actionでは、ログインしているか、対象データを変更できる利用者かを認可で確認します。

業務システムの要件として、入力値の検証、トランザクション、二重送信対策、監査ログも設計します。

Remix v2とReact Router v7の確認ポイント

Remix公式は2024年11月、React Router v7のリリース時に、既存のRemix v2利用者へ同v7へのアップグレードを推奨しました。

新規案件には、Framework Modeを含むReact Router v7が推奨されています（出典：Remix公式「React Router v7」、2024年）。

Framework Modeでは、Viteを使った開発環境やサーバーサイドレンダリングを利用できます。コード分割、データ読み込み、フォーム処理にも対応しています。

発注時には、新規開発と既存Remix v2の改修を分け、それぞれの条件を整理します。

• 新規開発：React Routerのバージョン、Framework Mode、React・Node.jsの対応版、Vite構成、更新方針を明記します。
• 既存Remix v2の改修：依存パッケージとfuture flag、移行で変わるAPIを確認してから見積もりを依頼します。

Remixのシステムに向いている業務

Remixは、ログイン後に検索・入力・承認・引き継ぎを行う業務に適しています。

公開画面と管理画面を共通の方針で運用する場合や、複数の外部サービスと連携する業務画面を作る場合にも、Remixは候補になります。

顧客・案件・問い合わせ管理

顧客や案件、問い合わせ履歴のほか、担当者、商談、見積、契約を扱うシステムでは、一覧、詳細、編集、検索、権限管理が繰り返し登場します。

たとえば、ネストされたルーティングを使うと、顧客詳細の共通レイアウトを保ちながら、案件タブや活動履歴を切り替えられます。

また、検索条件をURLに保持すれば、画面を共有した相手も同じ状態を再現できます。loaderで一覧や集計を読み込み、actionでステータスや担当者を変更する形にすると、業務単位で仕様を把握しやすくなります。

受発注・在庫・申請承認などの更新業務

更新業務では、どこまでをRemixで担い、どの処理をRemix以外の基盤へ分けるかを整理します。

• 業務ルール：状態を変える処理はactionにまとめ、受注・発注・在庫・請求・申請の入力を検証します。
• 承認条件：申請中は申請者が金額を変更でき、承認済みは管理者だけが差し戻せるといった条件です。
• 長時間処理：複雑なバッチや大量集計はジョブキューなどへ分け、画面では受付番号と進捗を表示します。

Remixは業務システム全体を担う唯一の技術ではないため、利用者向けWebフロントとサーバー処理の核として、ほかの基盤と役割を分けて使います。

公開画面と管理画面の運用方針

公開画面と管理画面では、重視する要件が異なります。

• 公開ページ：初期表示速度、検索エンジンへの情報提供、段階的なJavaScript読み込みを重視します。
• 管理画面：検索、入力、権限、監査ログ、エラーからの復帰が中心になります。
• 領域の分離：公開・認証領域、API、バッチを分け、必要な画面だけにSSRやキャッシュを使う形です。

SSRとフォーム処理を一つのルーティングモデルで扱えます。そのため、公開画面と管理画面の両方を含むサービスでも、構成を揃えて考えられます。

SEOが不要な社内画面では、検索向けの対策を優先しなくて構いません。また、技術を採用する理由は、業務上の効果と結び付けて説明します。

Remixのシステム構成の種類

Remixを採用するかどうかに加えて、既製サービス・クラウド・スクラッチをどの範囲で組み合わせるかを決めます。標準化できる領域と、競争力や業務固有のルールがある領域を分けると、費用とリスクを抑えやすくなります。

パッケージやSaaSと組み合わせる構成

標準業務を既製サービスでまかなえるなら、すべての機能をRemixで作る必要はありません。

• 役割分担：既製サービスを基幹データ管理に使い、Remixで従業員ポータルや申請画面を構築します。
• 連携条件：API仕様、利用回数制限、データの正本、障害時の再送を確認します。
• 移行と費用：サービス終了時のデータ取り出しを確認します。標準機能に業務を合わせれば初期費用を抑えやすい一方、制約を複雑な画面処理で隠すと保守費用が膨らみます。

Remixでは、取引先向けの申請画面や、複数サービスを横断する業務フロントも構築できます。

クラウド上のRemixとデータ基盤の配置

クラウドにアプリケーション、DB、オブジェクトストレージ、監視、CI/CDを置くと、利用量に合わせて規模を変えられます。

• SSRの実行先：サーバー、コンテナ、エッジ、サーバーレスから選び、Node.js互換性などを確認します。
• 処理と費用：配置先の判断基準になるのは、長時間処理、DB接続、ログ保存、費用上限です。
• 運用要件：クラウドを選ぶ前に必要な運用項目を具体化します。

特定のホスティングに依存しすぎないよう、アプリケーションとデプロイ設定は分けておきます。認証、DB、ストレージも、交換できる境界で設計します。

クラウドを選ぶときは、料金の安さだけで決めません。個人データの保管場所や復元方法、障害通知、アクセス権限、従量課金の上限も要件に含めます。

スクラッチ開発の対象は業務の差別化部分

業務の強みになる独自ルールは、RemixをWebフロントとBFFの核にして開発します。

• 対象業務：複数拠点の在庫引当、独自の承認ルール、基幹連携などをスクラッチ開発します。
• 共通機能：ログイン、権限、ファイル保管、メール通知には、信頼できる部品やマネージドサービスを使います。

開発力は、固有ルールの部分に集中させます。

公開ECの技術動向として、2026年6月に、特定のフレームワークやランタイムに依存しないツールキットへの再構成を目指す開発者プレビューが示されました。同様に、Remixもブランド名だけで固定せず、React Router、Node.js、各種クラウドの組み合わせを将来変更できるかを確認します（出典：Hydrogen公式開発者プレビュー、2026年）。

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

現場の業務とデータを整理してから、画面と処理を段階的に作る進め方が有効です。技術の説明から入るより、業務の整理から始めるほうが進めやすくなります。

Excel、紙、FAX、メール、二重入力をそのままWeb画面に置き換えず、何を正しいデータとするかを先に決めます。

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

要件定義での業務・データ・非機能の洗い出し

要件定義では、利用者と現場業務の流れを押さえ、何を決めるべきかを項目ごとに整理します。

• 業務とデータ：業務フロー、入出力、マスタ、権限、連携先、例外処理を洗い出し、現行データも確かめます。
• 業務固有の条件：案件状態、担当者変更、失注理由、重複顧客、CSV項目などのルールです。
• 非機能要件：同時利用者数、応答・稼働時間、バックアップ、復旧目標を定めます。ログ保持や保管場所、監査ログ、脆弱性診断の条件も決めます。
• 発注側の役割：マスタ整備、データクレンジング、受入テストの担当を決めます。

現場担当者に実際の一日を説明してもらうと、画面一覧だけでは見えない手戻りに気づけます。

設計でのルート・権限・データ境界

画面遷移図やワイヤーフレームに加えて、各ルートが読むデータと、actionが変更する内容を書き出します。

たとえば、案件詳細のloaderが担当者以外の案件まで返すと、画面に表示しなくてもレスポンスから情報が漏れるおそれがあります。そのため、データ取得時に権限条件を適用し、画面の非表示だけに頼らない設計にします。

加えて、DBの正規化やIDの採番、履歴、削除と退避の方法を決めます。ファイル保存先や外部APIのタイムアウト、再送方針も決めておきます。認証方式と権限モデルは後付けせず、ルート構成と業務状態に合わせて最初から設計します。

価値の高いMVPからの段階的な実装

初回リリースでは、全社業務を一度に置き換えず、利用頻度と効果が高い範囲から選びます。

• 対象範囲：検索・登録・承認などを含め、利用者が一連の業務を試せるMVPとします。
• 顧客・案件管理の例：顧客登録、案件登録、担当者変更、活動履歴、検索、CSV出力を一つの縦切りにします。
• 開発中の確認：遅い通信、入力エラー、権限不足、外部連携の失敗、同時更新、途中離脱の場面で動きを確かめます。
• レビュー：画面を小さく分けて頻繁に確認し、要件定義書にない現場判断を記録して手戻りを防ぎます。

テスト・移行・リリース後の定着

テストや移行、運用は、本番に近い条件で確かめます。

1. 単体・結合・業務シナリオ・権限・負荷のテストに加え、脆弱性診断を行います。
2. 移行対象の重複、欠損、表記ゆれ、過去データの保持期間を整理し、リハーサルを複数回行います。
3. 問い合わせ窓口、障害時の連絡順、ログ確認、依存パッケージ更新、バックアップ復元テスト、利用状況確認を、運用手順にまとめます。

申請者、承認者、管理者、閲覧だけの利用者ごとに、見えるデータと操作を確かめます。また、CSVは、文字コード、日付、金額、タイムゾーン、端数処理の扱いを検証します。

納品後も現場が使い続けられる状態まで、開発範囲に含めます。

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

Remixはオープンソースです。そのため、フレームワークのライセンス料は開発費の中心になりません。

費用は、画面数、権限、ワークフロー、データ移行、外部連携の量で変わります。さらに、テスト、インフラ、保守の量でも変わります。

ここに示す金額は、Remix専用の統計ではなく、2026年の一般的なWeb業務システム相場と業務要件に基づく推定です。

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

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

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

ログイン・検索・登録に絞るか、部門横断の業務や基幹連携まで含めるかで、初期費用と開発期間は大きく変わります。

• 小規模PoC：ログイン、検索、登録、CSV出力に絞る場合、100万〜300万円・1〜3か月が目安です。
• MVP：部門横断の案件・受注管理に権限、通知、外部API連携を加える場合、500万〜1,000万円・3〜6か月程度です。
• 本番業務基盤：在庫・受発注・ワークフロー、複数拠点、監査ログ、移行を含むと1,000万〜3,000万円超・6〜12か月以上の可能性があります。
• 大規模開発：複雑な基幹連携、段階移行、厳格なSLA、多数利用者では3,000万円から数億円規模です。

一般的な2026年の目安は、小規模100万〜300万円、人月単価60万〜200万円程度です（出典：2026年更新のシステム開発費用相場資料、2026年）。

要件定義・開発・移行・運用ごとの費用配分

見積書では工程ごとに分けて、費用配分と前提条件を確かめます。

• 工程別の目安：要件定義10〜15%、設計25〜35%、実装・単体テスト30〜40%、結合・総合テスト15〜20%、移行・教育5〜10%です。
• 配分の変動：既存データの汚れや連携先の多さにより、移行とテストの比率が上がります。
• 初期費用以外：クラウド、監視、WAF、メールの費用が発生します。ファイル保管、CI/CD、バックアップ、脆弱性診断、保守にも費用がかかります。
• 保守費用：初期開発費の年10〜20%が目安です。対応時間帯、軽微改修、更新、セキュリティ対応の有無で変わります。

月額だけで比べず、3年程度の総保有コストで判断します。

費用が増えやすい要因

費用が増える条件は、見積もりの前提として最初に確かめておきます。

• 利用者・拠点：数が多い場合
• 権限・承認：役割ごとの権限や条件分岐する承認経路
• 既存システム：基幹システムとの双方向連携
• データ移行：紙やExcelからの大量移行
• 追加要件：変更履歴、オフライン・低速回線、多言語・多通貨対応

安価な見積もりでは、要件定義・テスト・移行・保守が別料金になる場合があります。そのため、納品物、対象外作業、変更単価、遅延時の扱い、コード・設計書の所有権、解約時の引き継ぎを確認し、予算超過を抑えます。

Remixのシステム開発会社・ベンダーの選び方

Remixの経験年数や技術名の掲載だけで発注先を決めるのは、危険です。

発注先は、業務整理、React・TypeScript・React Routerの実装、DB・認証・外部連携を評価して選びます。クラウド運用、セキュリティ、保守の体制も、同じ基準で確かめます。

Remixの実績が少なくても、React Routerや業務Webの経験を確かめます。

実績の担当範囲と技術判断の確認

実績を聞くときは、画面だけでなく、担当範囲や技術判断の根拠も確かめます。

• 技術の範囲：使用版、SSRかSPAか、loader・actionの分け方、DB・認証連携を確認します。
• 設計資料：匿名化した画面遷移図、要件定義書の目次、テスト観点、障害対応事例を確認します。
• 2026年の対応：React Router v7 Framework ModeとRemix v2移行の経験を聞きます。
• 周辺技術：React 19やViteへの対応方針も質問します。
• 担当体制：技術者が営業だけでなく、同じ責任者が要件定義からリリース後まで関与するかを確認します。

守秘義務で画面を見られない場合でも、設計上の判断を説明できるかどうかで、力量を見極められます。

提案書で比べるセキュリティと運用

個人情報を扱う案件では、安全管理措置の具体策を提案書で確かめます。

• 個人情報の保護：認証、アクセス制御、権限、通信暗号化を確認し、ログ分析、バックアップ、委託先管理まで見ます。

個人情報保護委員会の令和7年3月24日施行版ガイドラインは、技術的安全管理措置の論点として、利用者の識別・認証、不正アクセス防止、通信の暗号化、ログ分析などを示しています（出典：個人情報保護委員会「個人情報保護法ガイドライン 通則編」、2025年）。

React Router公式資料は、Framework ModeでCSPを設定する方法を説明しています。サーバーで生成するインラインスクリプトにnonceを付ける形で実装します。

IPAはSQLインジェクション、XSS、CSRF、セッション管理、認可制御の欠落などを確認項目に挙げています（出典：IPA「安全なウェブサイトの作り方」改訂第7版）。

「対応します」の一言で済ませず、どの試験をいつ行うかまで提案書に書いてもらいます。

成果物・契約・引き継ぎ条件の明文化

納品物と保守契約の対象を明確にして、引き継ぎ後も保守できる状態をつくります。

• 設計・テスト資料：要件定義、画面・API仕様、DB定義、権限一覧、テスト仕様、運用手順を確認します。
• 運用資産：ソースコード、CI/CD、インフラ構成、障害対応手順を含めます。加えて、環境変数、デプロイ、監視、復元の手順も必要です。
• 保守条件：営業時間、一次対応時間、障害優先度、修正版提供、依存パッケージ更新、軽微改修の定義を決めます。

CVE-2026-22030では、Framework Modeなどの条件でCSRFの影響を受けるバージョンが公表されました。修正版は@remix-run/server-runtime 2.17.3とReact Router 7.12.0です（出典：NVD CVE-2026-22030、2026年）。

CVE対応のような更新は、誰が監視し、どの期限で検証・適用するかを契約に含めます。

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

Remixのシステムに関するよくある質問（FAQ）

Remixを検討する際は、技術の向き不向きに加えて、既存システムとの関係、費用、将来の保守まで含めて判断します。

Remixは社内の受発注システムにも使えますか？

使えます。検索、登録、承認、通知、CSV出力、権限管理など、利用者がデータを操作する業務Webシステムに適しています。

複雑なバッチ、大量データ分析、基幹処理は、画面処理だけで担わず、サーバーやジョブ基盤と役割を分けます。

Remix v2とReact Router v7はどちらを選べばよいですか？

既存システムがRemix v2なら、すぐに全体を作り直さず、依存関係とfuture flagを確認して移行計画を立てます。

新規案件では、2026年時点の公式方針を踏まえて、React Router v7 Framework Modeを第一候補にします。そのうえで、必要なSSR、データ処理、デプロイ先、将来のアップデートを比べます。

RemixのシステムはSEOに強いですか？

サーバーサイドレンダリングや適切なHTML出力を使えるため、公開ページの初期表示と検索エンジンへの情報提供を設計しやすいです。

ただし、SEOの成果はフレームワークだけで決まるものではありません。タイトルや見出し、構造化された内容、表示速度に加え、内部リンクも見直します。コンテンツ品質と運用改善も進めます。

Remixのシステムはどのくらいの期間で作れますか？

小規模PoCは1〜3か月、中規模MVPは3〜6か月、本番業務基盤は6〜12か月以上が目安です。期間は画面数だけでなく、移行や外部連携、権限、テスト、利用者教育、段階リリースによっても変わります。

短納期を優先する場合も、初回に作る範囲と後から追加する範囲を明確にし、品質を落とさないようにします。

開発会社に見積もりを依頼するとき何を伝えればよいですか？

見積もりの依頼時には、画面数、利用者、現行業務、人数、データ量を伝えます。さらに、既存連携、個人情報の有無、時期、予算、保守体制も共有します。また、Excel・帳票、承認ルール、例外処理まで示しておくと、追加要件を減らせます。

技術指定は、Remixだけでなく、React Router v7との比較、SSRの要否、デプロイ先、納品物まで含めると、見積もりの精度が上がります。

まとめ

RemixはReactを使い、業務画面、データ取得、フォーム処理、サーバー処理を一つの流れで設計できるフルスタックWebシステムです。

顧客・案件管理、受発注、在庫、申請・承認など、データを読み書きする業務と相性があります。ただし、技術を採用しただけで業務が改善するとは限りません。

採用判断での業務との適合性

技術、費用、開発範囲を検討するときは、業務との適合性から判断材料を組み立てます。

• 技術選定：新規開発ではRemix v2とReact Router v7 Framework Modeを比較します。
• 予算判断：費用は小規模PoCの100万〜300万円から、大規模な基幹連携の数億円まで幅があります。権限、移行、連携、テスト、運用が金額を左右します。
• 開発範囲：現行業務とデータを洗い出し、価値の高い範囲から段階的に開発すると、予算と定着率を守りやすくなります。

React・Node.js・Vite・クラウドの対応方針は、見積書に明記します。

発注前に確認する安全性・納品物・保守

発注前には、認可テストやCSRF対策、CSP nonceを確認します。加えて、依存パッケージ更新、ログ、バックアップ、復旧も確かめます。

個人データの保管場所、ソースコードと設計書の納品、保守と引き継ぎ条件は、契約の前に押さえます。業務理解と安全な運用を任せられる体制かどうかを比べると、長く使えるシステムに近づきます。

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

▼開発を相談する前に読みたい無料ホワイトペーパー
・【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を創業。