Preactのシステム開発の発注/外注/依頼/委託方法について

Preactのシステム開発を発注・外注するなら、Preactの軽量性だけで判断せず、画面、API、認証、データ移行、テスト、運用までを含む業務システム全体の責任範囲を定義することが重要です。

PreactはERPや販売管理の製品ではなく、ブラウザ上の画面を作るJavaScript UIライブラリです。本記事では、SaaS・パッケージ・クラウド開発・スクラッチの選び方、RFPと要件整理、請負・準委任などの契約形態、2026年時点の費用レンジ、委託先と見積書の比較ポイントを、発注担当者が実務で使える順番で解説します。

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

Preactのシステムを発注・外注する前に知っておきたい全体像

Preactを使った業務システムは、ログイン、ダッシュボード、顧客・商品・案件の検索、一覧・詳細・登録・編集、CSV入出力、承認、権限別メニュー、通知、操作履歴などを持つWebシステムとして構成されます。Preactが担当するのは主にフォーム、表、チャート、モーダル、画面状態などであり、業務データを保存するデータベース、API、認証認可、バッチ、監査ログは別途設計します。

Preact公式は、Preactを「Fast 3kB alternative to React」と説明しています。ただし、ここで示される約3kBは基本ランタイムの軽量性を表す目安であり、業務システム全体の容量、API、画像、帳票、データベース、開発費が3kBになるという意味ではありません（出典: Preact公式「Preact」）。実際の初期表示や操作感は、JavaScriptの分割、API応答、画像サイズ、キャッシュ、ブラウザ端末の性能を合わせて測定します。

したがって、発注先へ「Preactで作ってください」とだけ伝えると、業務ルールや連携範囲が抜けた見積もりになりやすいです。対象業務、利用者、画面数、データ項目、外部サービス、権限、障害時の運用を先に整理し、そのうえでPreactを使う範囲を決めることが発注の出発点です。

Preactは、現場端末やモバイル回線で初期表示を軽くしたい管理画面、既存サイトに検索や予約などの機能を埋め込むウィジェット、静的ページに一部のインタラクションだけを追加する構成、複数の小さなフロントエンドへ分割する構成と相性がよいです。画面の一部だけを段階的に置き換える場合も、既存サービスとの境界を決めれば導入しやすくなります。

一方で、React専用のUI部品やチャート、Portal、CSS-in-JS、テスト環境を大量に使う場合は、preact/compatで動くかを先に確かめます。Preact公式も互換レイヤーによってReact向けライブラリを利用できると案内していますが、すべてのライブラリが無条件に動くわけではありません（出典: Preact公式「Upgrade Guide」）。社内にReactの既存資産と人材が豊富な場合は、移行・教育・保守まで含めるとReactのほうが総保有コストを抑えられることもあります。

発注形態はSaaS・パッケージ・スクラッチのどれを選びますか？

発注形態は、標準業務に合わせるか、固有業務を作り込むか、社内でどこまで運用するかで決めます。Preactを使うこと自体を目的にせず、SaaSやパッケージで足りる部分は活用し、不足する画面や連携だけをPreactで追加する構成も有力です。

顧客管理、案件管理、在庫、申請、帳票などが既製サービスの標準機能に近いなら、まずSaaSやパッケージを比較します。導入期間を短くしやすく、アップデートやバックアップを自社だけで抱えずに済むためです。Preactで独自画面を追加する場合は、SaaSのAPI、認証方式、利用規約、データエクスポート、障害時の責任分界を確認します。

2026年公開の国内相場情報では、クラウド型は無料から100万円程度、パッケージ型は100万〜300万円程度という整理があります（出典: 秋霜堂株式会社「システム開発の費用相場」、2026年更新）。ただし、これはサービス導入や設定の目安であり、個別画面、API連携、データ移行、教育、Preactの追加開発まで含む総額ではありません。

独自業務があるものの、データや認証をクラウドサービスで構築できる場合は、クラウド上のAPI・データベースとPreactのフロントエンドを分離します。画面の改修とバックエンドの改修を適切に分けられ、将来別の端末や外部サービスからAPIを利用しやすくなります。AWS、Azure、Google Cloudなどの選択は、既存の社内基盤、担当者の運用経験、監視と復旧体制を基準にします。

クラウド構成では、同時利用者数、ピーク時のAPIリクエスト、ログ保存期間、バックアップの世代数、復旧目標時間、リージョン、個人情報の保管場所をRFPへ記載します。画面が軽くても、APIが遅い、認証が切れる、連携エラーを検知できないと、現場の生産性は上がりません。

独自の承認、複雑な料金計算、既存ERP・会計・WMSとの連携、業界固有のデータ構造などが競争力に直結する場合は、スクラッチ開発を検討します。ただし、全社機能を一度に作る一括発注は、現場理解が不十分なまま仕様が固定されるリスクがあります。現状調査、PoC、1部門のMVP、本番展開に分ける段階発注が安全です。

PoCでは、代表画面を1〜3枚、主要APIを1本、実際に使う端末を対象にします。ログイン、一覧検索、登録、権限エラー、通信遅延、画面の初期表示を確認し、React向け部品が動くか、アクセシビリティやテストを書けるかを検証します。PoCの完了条件と本開発へ進む判断基準を契約前に決めると、技術検証だけで費用が膨らむことを防げます。

Preactのシステム発注・外注はどの順番で進めますか？

外注プロジェクトは、技術名と機能一覧だけを渡して始めると、業務ルール、例外処理、移行対象、非機能要件が抜けたまま見積もりが作られます。現状把握、要件定義、候補会社へのRFP提示、提案・見積比較、契約、設計・開発、テスト・移行、教育・稼働の順に、社内の意思決定者を置いて進めます。

最初に、利用部門、利用者数、拠点数、対象データ、1日の登録件数、既存のExcel・紙・基幹システム、連携先、利用端末を確認します。担当者へのヒアリングだけでなく、実際の入力、承認、差し戻し、検索、帳票出力を観察し、担当者が例外をどのように処理しているかを記録します。

業務をそのままデジタル化すれば効率化できるとは限りません。入力の重複、使われていない項目、部門ごとに異なるコード、手作業で補正している数値を整理し、残す業務、やめる業務、システムに任せる業務を分けます。悪いアナログ業務をそのまま移すと、使いにくいデジタル業務を増やすためです。

現状を把握したら、RFPに目的、対象業務、利用者、画面の一覧、主なデータ項目、権限、外部連携、移行対象、希望時期、予算の考え方、成果物、保守要件を記載します。機能要件は「顧客を登録する」だけでなく、「重複チェックを行い、権限のない担当者には個人情報を表示せず、登録後は操作履歴を残す」のように、条件と結果まで書くと比較可能になります。

非機能要件も省略しません。同時利用者数、画面の応答時間、対応ブラウザ、スマートフォン対応、可用性、バックアップ、復旧目標、監視、ログ保存、脆弱性診断、アクセシビリティ、秘密情報の管理をRFPに含めます。Preactの軽量性を評価するなら、初期表示、操作開始までの時間、API応答、エラー率を、対象端末と通信条件をそろえて測定する基準まで定義します。

設計では、画面だけでなくAPIのエラー形式、データの正本、認証と認可、権限マトリクス、通知、操作履歴、バックアップと復旧を決めます。Preact側でボタンを隠すだけでは認可になりません。APIやサーバー側でも権限を確認し、URLを直接呼び出されても許可されないデータを返さない仕組みにします。

テストでは、正常な登録だけでなく、通信遅延、二重送信、同時更新、権限不足、セッション切れ、CSVの不正値、連携先の停止、データ重複、ブラウザ差異を再現します。移行では、顧客・商品・案件・権限・履歴などの件数と代表データを照合し、旧システムをいつ参照専用にするか、移行失敗時にどの状態へ戻すかを決めます。

RFPと要件整理には何を盛り込めばよいですか？

RFPは、候補会社に同じ前提で提案してもらうための資料です。完成した要件定義書でなくても構いませんが、目的、対象範囲、現状の課題、優先順位、制約、希望納期、想定する発注範囲を明示します。Preactを指定する場合も、採用理由と検証したい性能を添え、React・SaaS・パッケージを含む代替案を提案できる余地を残すと、より適切な比較ができます。

業務要件では、誰が、いつ、何を入力し、誰が承認し、どのデータを次の業務へ渡すかを記載します。たとえば案件管理なら、営業が登録し、責任者が承認し、受注後に請求や生産へ連携する流れを示します。担当者ごとのメニュー、閲覧・編集・出力の権限、差し戻し、取消、代理操作、退職者のアカウント停止も対象にします。

マスタの管理者と変更ルールも重要です。商品コードや顧客コードに表記揺れがあると、検索、集計、外部連携、データ移行のすべてに影響します。現行データをそのまま正しいものと仮定せず、重複・欠損・廃止データを洗い出す作業を、発注者と委託先のどちらが担当するか明記します。

技術要件には、TypeScript、Vite、ルーティング、フォームとバリデーション、テーブル、状態管理、テスト、CI/CD、SSR・SSGの要否を記載します。公開Webで検索流入や初期表示が重要ならSSR・SSGを、ログイン後の業務画面なら認証後のSPAを中心に検討します。Preact公式のGetting StartedではViteや既存のビルドパイプラインを使う方法が案内されているため、委託先には採用する構成とその理由を説明してもらいます（出典: Preact公式「Getting Started」）。

preact/compatを使う場合は、React向けUIライブラリ、チャート、エディタ、テスト、Portal、Suspense、アクセシビリティの動作確認結果を成果物に含めます。Preact公式のv11移行ガイドでは、ESMの扱いなどアップグレード時に確認すべき差分が示されています（出典: Preact公式「Upgrade Guide v11」）。依存パッケージの一覧、ライセンス、脆弱性の監視担当、更新手順も納品条件へ入れます。

個人情報、従業員情報、取引データを扱う場合は、認証、多要素認証、権限、通信暗号化、秘密情報の保管、監査ログ、バックアップ、脆弱性診断、障害連絡、復旧訓練を要件にします。Preactの画面で入力値を制限しても、APIへ直接送られた値をサーバー側で検証しなければ安全とはいえません。入力の出力エスケープ、CSRF対策、Cookie属性、CSP、依存パッケージ管理を担当範囲に含めます。

IPAはWebアプリケーションのXSSやCSRFについて、原因と対策を「安全なウェブサイトの作り方」で整理しています（出典: IPA「安全なウェブサイトの作り方」）。個人情報を委託先へ渡す場合は、個人情報保護委員会のガイドラインを確認し、再委託、アクセス権、保存期間、返却・削除、漏えい時の連絡を契約へ反映します。運用開始後に誰が脆弱性を修正するかまで決めておくことが重要です。

契約形態は請負・準委任・保守をどう使い分けますか？

契約形態は、仕様が固まっているか、成果物と受入条件を決められるか、発注者が意思決定へどれだけ参加できるかで選びます。契約名だけでなく、対象業務、責任分界、変更手続き、検収、知的財産権、再委託、保守を一体で確認します。

画面、API、テスト、移行などの成果物と完成条件を定義できる部分は、請負契約が候補です。検収基準には、画面が表示されることだけでなく、対象ブラウザ、権限別の操作、APIのエラー、性能、セキュリティ試験、移行データの件数、マニュアルなどを含めます。納品後に見つかった不具合の修補範囲と期間も確認します。

ただし、要件が固まっていない段階で全機能を請負にすると、変更のたびに追加見積もりや納期延長が発生しやすいです。要件定義やPoCは準委任、仕様が確定したMVPは請負というように、工程ごとに契約を分ける方法もあります。

準委任契約は、作業時間や専門家の支援を対象とする形態です。現場調査、技術検証、要件定義、アーキテクチャ設計、優先順位付け、アジャイルのスプリントなど、実施しながら判断が変わる工程に適しています。委託先に任せきりにするのではなく、発注者側の業務責任者がレビューと意思決定を行います。

準委任では、稼働時間だけで評価せず、会議体、設計レビュー、バックログ、課題管理、検証結果、次の判断材料を成果として確認します。月ごとの作業範囲、担当者、稼働予定、経費、追加作業の承認方法を明記し、作業が増え続ける状態を防ぎます。

保守契約では、問い合わせ対応、障害一次受付、監視、バックアップ確認、依存パッケージ更新、ブラウザ検証、脆弱性対応、軽微な修正、機能追加を分けて記載します。障害の重要度ごとの連絡時間、調査開始、復旧目標、休日対応、再発防止報告の有無も確認します。

契約終了時に、ソースコード、設計書、CI/CD設定、クラウド設定、依存パッケージ一覧、ログ、データを返却できるかも重要です。担当者が変わっても運用できるよう、納品物と引き継ぎ期間を定義します。将来の保守会社変更を妨げる条件がないか、知的財産権とライセンスも確認します。

Preactのシステム開発費用・相場はいくらですか？

PreactそのものはMITライセンスのオープンソースで、基本ランタイムの利用料が主な費用になるわけではありません。費用の中心は、要件定義、画面設計、API・データベース、認証、テスト、データ移行、クラウド、教育、保守です。2026年公開の国内相場では、業務システムは300万〜1,500万円、開発期間は4〜12か月という目安が示されています（出典: モカモコ株式会社「システム開発の費用相場完全ガイド 2026年版」）。以下はこの相場とリサーチノートをもとにしたPreact案件の推定レンジです。

画面中心の小規模開発は150万〜300万円程度、開発期間は2〜4か月が一つの目安です。ログイン、一覧・詳細、簡易管理画面、既存API連携を中心とし、認証やデータベースを既存基盤で使えることが前提です。新規の認証、権限、監査ログ、データ移行まで含むと、このレンジを超える可能性があります。

顧客・案件・在庫などを扱う中規模の社内業務システムは300万〜800万円程度、4〜8か月が目安です。複数のCRUD画面、権限、CSV、通知、API連携、テスト、初期移行を含む想定です。承認、帳票、複数部門、監査ログ、外部サービス連携、教育を含む標準的な業務システムは800万〜1,500万円程度、6〜12か月を見込みます。

ERP・WMS・会計・生産管理との連携、大量データ移行、高可用性、複数拠点の展開まで含むと、1,500万円から数億円まで幅があります。大規模案件ほど、PreactかReactかより、データ連携、移行、非機能、教育、運用設計が金額と期間を左右します。相場は予算を決めるための出発点であり、特定の金額を保証するものではありません。

費用内訳は、要件定義10〜15%、基本設計15〜20%、詳細設計10〜15%、開発30〜40%、結合・総合テスト15〜20%、移行・導入5〜10%程度という工程別の目安で確認できます（出典: NotebookLMリサーチノート「Preactのシステム」、業務システム全般Q&A）。これは配分の目安であり、画面数、API本数、外部連携、データ品質、検証の難しさによって変わります。

見積書では、画面一覧、API一覧、データ移行件数、外部連携本数、対応ブラウザ、テストの種類、テストデータ作成、教育回数、会議・管理工数を分けてもらいます。「開発一式」だけでは、安い見積もりが作業の抜けによるものか、効率化によるものか判断できません。画面単価だけでなく、業務シナリオを完了させるための総工数で比較します。

初期費用以外に、クラウド、監視、バックアップ、ログ保管、外部API、メール・通知、端末、脆弱性診断、問い合わせ、依存パッケージ更新、ブラウザ検証、追加改修が発生します。保守費は初期開発費の15〜20%程度を年額の仮置きにできますが、対応時間、休日対応、脆弱性対応、追加開発を含むかで変わります（出典: NotebookLMリサーチノート「Preactのシステム」）。

候補会社には、初期費用、月額・年額、5年間の保守、クラウド利用料、データ移行、教育、追加変更の単価を分けて提示してもらいます。Preactだから開発費が自動的に安くなるわけではありません。軽量化による性能上の利点を実測し、不要な画面や連携を減らす要件整理と組み合わせて、総額を最適化します。

委託先の選定と見積比較では何を確認しますか？

委託先は、Preactという単語を提案書に書けるかだけでなく、業務理解、バックエンド、セキュリティ、テスト、保守を含めて評価します。ReactやTypeScriptの公開実績があっても、Preactまたはpreact/compatの検証経験があるとは限りません。担当エンジニア、実装範囲、テスト体制、稼働後の窓口を具体的に確認します。

候補会社には、実際の業務に近い画面を使ってPoCやデモを依頼します。ログイン、検索、登録、権限エラー、一覧の大量表示、CSV出力、通信遅延、API停止、スマートフォン表示を一連のシナリオで見ます。表示速度だけでなく、エラーを利用者へ伝え、再送や復旧を管理者が行えるかも確認します。

React向けライブラリを利用する提案なら、どの部品をpreact/compatで動かし、どれを代替するかを一覧にします。コンポーネントテスト、E2Eテスト、アクセシビリティ検査、依存パッケージの更新方法、脆弱性発生時の対応担当も質問します。AdyenはCheckoutやKYC向けSDKのツールとしてPreactを採用した事例を公開しており、用途を絞って適切な技術を選んだ例として参考になります（出典: Adyen「Right tooling, Right Problem: Preact at Adyen」、2022年）。

見積比較表には、初期費用、月額・年額、期間、体制、画面数、API本数、外部連携、データ移行件数、テスト範囲、教育回数、保守時間、追加変更の単価を並べます。低い見積もりには、要件定義、権限、エラー処理、移行、受入支援、脆弱性診断が対象外になっていないかを確認します。高い見積もりには、標準機能の活用や段階導入で減らせる作業を質問します。

提案書の前提条件も比較します。発注者が用意するデータ、会議への参加者、意思決定の期限、テスト担当、クラウド契約者、既存システムのAPI仕様、端末、写真や帳票の素材を確認します。これらの前提が違うと、同じ1,000万円という数字でも含まれる範囲が異なります。候補各社へ同じ質問を行い、回答の具体性とリスクの説明力を評価します。

提案時の営業担当だけでなく、要件定義担当、Preactの実装担当、API・インフラ担当、QA担当、運用担当を確認します。提案に参加したエンジニアが本番まで担当するか、再委託があるか、担当者が交代した場合に設計意図と障害履歴をどう引き継ぐかを聞きます。会社の規模より、必要な役割を継続して確保できるかが重要です。

納品物は、要件定義書、画面・API設計書、データ定義、権限一覧、テスト仕様と結果、移行手順、操作マニュアル、ソースコード、CI/CD設定、依存パッケージ一覧、監視・バックアップ設定、障害時の手順を確認します。ソースコードだけ受け取っても、ビルドやデプロイの方法が不明なら保守を引き継げません。稼働後の改善会議と追加改修の見積ルールも明記します。

Preactのシステム発注・外注でよくある質問

最後に、Preactを使ったシステムの発注前に相談されやすい質問をまとめます。技術の軽さ、既存資産との互換性、業務の複雑さ、費用、保守体制を分けて考えると、候補会社へ具体的な質問をしやすくなります。

初期表示の軽さや埋め込み性を重視し、必要な部品をPoCで確認できるならPreactが候補です。React専用ライブラリ、社内資産、人材、運用基盤を広く使う場合はReactが適する可能性があります。発注時は技術名だけでなく、主要画面、利用端末、互換性、性能測定、保守担当を同じ条件で比較します。

画面中心なら150万〜300万円程度、社内業務の中規模開発なら300万〜800万円程度、複数部門の標準的な業務システムなら800万〜1,500万円程度が推定レンジです。ERP連携、大量移行、高可用性、複数拠点展開を含む場合は1,500万円から数億円まで広がります。Preactのライセンス料ではなく、要件、API、移行、テスト、運用を含む範囲で見積もります。

「Preact対応」と書かれているだけで判断せず、Preact単体またはpreact/compatを使った実案件、担当エンジニア、採用したライブラリ、テスト結果、保守担当を確認します。実績を公開できない場合でも、匿名化した画面やPoCで互換性を示してもらいます。契約には、成果物、検収条件、ソースコード、依存関係、知的財産権、再委託、脆弱性対応、終了時の引き継ぎを記載します。

APIやデータエクスポートが用意され、認証と利用規約で外部画面が許可されていれば可能です。既存SaaSを正本として、Preactでは不足する検索、入力、ダッシュボードだけを作ると、全機能をスクラッチするより範囲を絞れます。ただし、API制限、仕様変更、障害時の責任分界、データ同期の遅延を確認してから発注します。

まとめ

Preactのシステムを発注・外注するときは、Preactを業務システム全体と捉えず、画面を担うフロントエンド技術として位置づけます。SaaSやパッケージで標準化できる範囲、クラウド上でAPIと画面を分ける範囲、スクラッチで作る固有業務を切り分け、必要なら1〜3画面のPoCから始めます。

RFPには、業務フロー、画面とAPI、権限、データ移行、外部連携、性能、セキュリティ、バックアップ、テスト、教育、保守を盛り込みます。請負と準委任を工程ごとに使い分け、見積書は初期費用だけでなく、作業範囲、除外事項、クラウド、保守、追加変更を同じ前提で比較します。Preactの実績は、技術名ではなく、実装者と検証結果、納品後の保守体制で確認します。

Preactの軽量性は、初期表示や埋め込み性を改善する選択肢ですが、業務改善を自動的に約束するものではありません。AdyenのSDK事例やITANDIのPreact活用事例も、技術を使う範囲と目的を絞っている点が参考になります。業務データの品質、認証・権限、APIの信頼性、テスト、教育、障害時の復旧まで含めて委託先と合意できたとき、Preactの利点を生かしたシステムになります。

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

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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