Ant Designを使うシステムの発注は、業務の整理、要件と契約の明確化、委託先との範囲比較の順に進めると、現場に定着する開発につながります。
全体像は、下記の完全ガイドの記事もご覧ください。
▼全体ガイドの記事
・Ant Designのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Ant Designのシステムを発注・外注する前に知るべき全体像
Ant Designは、Ant Groupが公開するReact向けデザインシステムとUIコンポーネントライブラリです。ERPやCRMのような完成パッケージとは異なり、業務画面を組み立てる部品として使います。
Table、Form、Menu、Modalなどの部品を組み合わせて、業務画面を作ります。DatePickerやUpload、Statisticも、こうした部品に含まれます。発注先には、フロントエンドの実装力に加え、業務分析、バックエンド、インフラ、セキュリティまでの体制が求められます。
業務パッケージではなくUI基盤という位置づけ
発注側は、Ant DesignがUI基盤であることを理解したうえで、発注範囲を決めます。
- 個別設計：顧客マスタ、承認ルール、在庫引当、CSVの文字コード、帳票、外部連携
- 別途用意：画面データ取得API、データベース、ログイン、権限。Ant Designだけではシステムは完成しません
- 適した画面：検索・一覧から詳細、登録、承認へ進む業務画面
- 部品の共通化：Table、Form、Pagination、Steps、Drawer、Notificationを共通ルールで使い、画面のばらつきを抑える
- 発注資料：標準部品を使う画面と、独自コンポーネントを作る画面を分けて記載する
発注の成否を決める業務理解
Ant Designに詳しい会社でも、現場の例外処理やデータの責任者を理解しないまま作ると、画面の見た目が整っていても使われないことがあります。
- 業務上の例外：顧客の別名登録、承認者不在、Excel取込時の日付・電話番号の不統一は、UI部品だけでは解決できません
- 業務とデータ：発注前に、誰が何をいつ入力し、どの条件で次の担当者へ渡すかを洗い出して一覧にする
- 個人情報：ロールごとの閲覧・編集範囲、操作ログ、バックアップ、復旧手順、再委託先を要件に含める
個人情報の扱いについては、個人情報保護委員会の通則ガイドラインが、漏えい・滅失・毀損を防ぐ安全管理措置と、取扱状況の把握・見直しを示しています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。
Ant Designのシステムの発注形態の選び方
業務と完成像が明確なら一括請負、要件を検証しながら進めるなら準委任や段階発注が候補になります。
社内のIT人材や意思決定者の体制、既存システムの扱いによって、適切な形は変わります。
開発だけをすぐ依頼せず、企画や要件定義を先に進める方法もあります。選ぶときは、完成責任と社内の意思決定体制を合わせて考えます。
一括請負の完成責任と発注形態の特徴
一括請負は、合意した仕様と納期で完成品を納める形です。そのため、契約前に固める内容が費用と納期を左右します。一括請負を検討する際は、契約条件、費用と変更、開発範囲、完成条件の4つの観点で契約内容を整理します。
- 契約条件：合意した仕様と納期で完成させて納品する形。画面一覧、機能仕様、受入条件、納期、納品物を固められる場合に適する
- 費用と変更：予算を決めやすい一方、画面や例外処理の不足が契約後に分かると、変更費用や納期の延長につながる
- 開発範囲：画面数、操作、API、データ移行を前提にする。ブラウザ対応、同時利用者数、テスト範囲も示す
- 完成条件：定義が曖昧なまま価格を固定すると、機能が別見積もりになることがあります。納品物と受入条件は、契約前にそろえます
要件が変わるプロジェクトに向く準委任の特徴と発注側の体制
準委任は、稼働人員や作業時間に対して報酬を支払う形で、要件定義やアジャイル開発のように作業内容が変わる案件に向いています。ただし、進行には発注側の判断体制も必要です。
- 優先順位：社内のプロダクト責任者が毎週決め、TableやFormの試作を見ながら改善していく
- 契約と稼働：請負とは異なる役割、月ごとの稼働時間、担当者の役割を明記する
- 進行管理：会議体、レビュー、進捗報告、品質指標、担当交代時の引き継ぎを取り決める
- 発注側の体制：業務責任者と現場代表を固定し、質問への回答期限を決めておく
請負と同じ完成責任を期待すると、契約上の認識がずれてしまいます。さらに、発注側の意思決定が止まると、稼働中でも開発は進みません。
企画・要件定義と開発を分ける段階発注
完成像が曖昧なときは、業務の整理と画面PoCを先に行い、そのあとで本開発へ段階的に進めます。PoCでは利用者の操作を確かめ、企画では本開発の前提になる内容をそろえます。
- 主要な2〜5画面で検索、登録、編集、エラー、権限変更を試し、利用者の操作を確かめる
- PoCを本番品質の開発と区別し、モックAPIか実データ接続か、納品範囲を明確にする
- 画面一覧、業務フロー、データ項目を企画に含める。非機能要件、優先順位、未決事項と判断期限も加える
段階発注は、初期の支出を抑えつつ大きな手戻りを防ぎやすい方法です。一方で、企画の内容が薄いと、本開発の見積もりが安定しません。
RFPと要件整理の準備範囲
RFPは、発注先に同じ条件で提案と見積もりを求めるための依頼書です。なお、仕様をすべて発注側で確定しておく必要はありません。
RFPには、業務課題と利用者、対象範囲、優先順位を整理して書きます。既存資産、予算、希望時期も含めます。さらに、Ant Designを指定する理由と、画面品質や保守性への期待も書きます。
RFPに入れる業務・利用者・データの3点
提案条件をそろえるには、業務、利用者、データのそれぞれを具体的に書きます。
- 業務：現状の手順、課題、改善後のKPI、対象外の業務
- 利用者：担当者、承認者、管理者、外部利用者などの役割と人数、利用場所と端末、同時利用者数
- データ：マスタ、1日あたりの登録件数、保存期間、移行の有無
データの例は、顧客・商品・案件のマスタです。既存のExcelや旧システムからの移行の有無も書いておきます。
画面要件には、検索条件、表示列、ソート、ページング、CSV出力を含めます。さらに、権限、空データ表示、エラーメッセージ、承認後の変更可否も書きます。列が多すぎると操作性や性能に影響するため、画面数に加えて複雑さも示します。
RFPの段階で決める非機能要件
非機能要件は、利用環境や情報の扱いに合わせて、具体的な条件として書きます。
- 運用品質：可用性、バックアップ、監視、障害対応、保守時間、拡張性
- 性能：検索結果を何秒で表示するか、通常時と繁忙期の同時利用者数、障害時に何時間以内に復旧するか
- 認証・権限：個人情報や人事情報を扱う場合のSSOとMFA、必要最小限の範囲に絞った付与
- 保護・委託：操作ログ、暗号化、脆弱性対応、再委託の扱い
「快適に動く」だけでは条件が曖昧なので、RFPでは性能を具体的な条件で示します。
Ant Design 6は、React 18以上とCSS変数に対応したブラウザを前提としています。古いブラウザでは、事前に検証します（出典: Ant Design公式「From v5 to v6」、2026年確認）。
既存システムを刷新する場合は、ReactとブラウザのバージョンをRFPに書きます。独自CSS、アイコン、E2Eテストの有無も記載します。また、アップグレード時の回帰テスト費用も見積もりに含めます。
受入条件と未決事項の書き分け
受入条件はRFPに記載し、画面の見た目だけでなく、データの整合性と業務結果も基準にします。
- 主要な業務シナリオが完了する
- 権限のないデータは表示されない
- CSVの入出力が指定の形式で動く
- 重大な不具合がなく、操作説明と設計書が納品される
未決事項は、決める人と期限を一覧にしておきます。特に、税計算、締め処理、承認者変更は、開発途中の判断で影響が大きくなりやすい項目です。ほかにも、過去データ修正、通知メール、帳票印刷が、開発途中の判断で影響が大きくなりやすい項目です。
提案会社には、未決事項が費用・納期・品質に与える影響と、先に検証すべき内容を示してもらいます。
契約形態と納品物の確認事項
契約書には、開発範囲、役割分担、変更管理、検収を含めます。知的財産権、秘密保持、再委託、障害対応、契約終了時の引き継ぎも、同じ契約書に定めます。
IPAの契約書は、開発段階でのユーザー企業とITベンダーの責務を整理しています。受託開発や保守運用のモデルも公開しています（出典: IPA「情報システム・モデル取引・契約書（第二版）」、2025年更新）。
仕様変更の承認方法と追加費用
仕様変更の影響を管理するには、受付から承認までの流れを決めておきます。
- 受付窓口と影響調査の期限を決めておく
- 追加費用の算定方法と、納期変更の承認者を定める
- 受託会社が影響を説明し、発注側の承認を得てから着手する
- 軽微な文言修正、仕様の明確化、機能追加に分け、契約書と変更管理表で定義をそろえる
新画面を追加するときは、UIだけでなくAPIやDBまで変わるかを確認します。権限、帳票、テストへの影響も、あわせて見ておきます。
請負でも、要件定義のあとに変更が起きないとは限りません。無償対応を広げすぎれば品質を圧迫し、すべてを追加請求にすれば協力関係が崩れます。
ソースコード・設計書・権利の納品条件
契約が終わったあとも運用や改修を続けられるよう、納品物と権利、管理アカウントを納品条件に含めます。
- 設計・開発：ソース、画面仕様書、UIガイド、デザイントークン、API・DB定義、インフラ構成
- 運用・検証：テスト仕様と結果、操作マニュアル、依存ライブラリ一覧、リリース手順
- 共通部品：Ant Designの共通コンポーネントの使い方と変更履歴
- 権利・契約：著作権、利用許諾、OSS表示、生成AIコードの確認責任、第三者サービスの契約名義
- 引き継ぎ：発注側がリポジトリ、クラウド、ドメイン、証明書、監視設定を所有し、終了時にアクセス権とデータの返還を定める
ビルド方法や環境変数の説明がなければ、コードを受け取っても引き継げません。
保守契約の障害対応と改善対応の切り分け
保守契約では、障害対応に加えて、更新や業務改善をどこまで含めるかを明確にしておきます。
- 保守範囲：受付時間、一次回答・復旧目標、監視、バックアップ確認、脆弱性対応を含めます。依存パッケージ更新、問い合わせ、軽微な改修も範囲に入れます
- アップグレード：更新作業を、月額に含めるか別見積もりにするかを決める
- 改善の準委任：月の稼働時間と優先順位、未消化時間、担当者が継続して関われるか
- 作業の分類：障害、法改正、セキュリティ、業務改善に分け、それぞれの予算と効果を管理する
Ant DesignやReactの更新では、独自CSSや非推奨APIの確認、回帰テストが必要になる場合があります。
Ant Designのシステム開発費用の相場
Ant Designはオープンソースのため、画面数や利用者数に応じたライセンス費は、開発費の中心になりません。
費用は、要件定義、画面設計、フロントエンド、API・DBの合計で考えます。認証・権限、外部連携、データ移行、インフラも含みます。テストや教育、保守も費用に入ります。
次の金額は、一般的な業務Webシステムの相場をもとにした目安です。Ant Designの公式な価格表ではありません。
規模別の初期費用の目安
検証用の小さなPoCから基幹刷新まで、初期費用は規模と実装範囲によって異なります。
- UI検証・PoC：主要2〜5画面、モックAPI、テーマ確認で50万〜150万円程度
- 小規模ツール：ログイン、CRUD、検索・一覧、CSV、簡易権限で100万〜300万円程度
- 1部門の業務システム：販売・在庫・申請で500万〜1,500万円程度
- 複数部門の業務基盤：SSO、監査ログ、複数連携、移行を含み1,500万〜5,000万円程度
- 基幹刷新・ERP連携：5,000万円〜数億円になる場合があります
2026年の公開相場では、人月単価はスキルや地域によって60万〜200万円程度とされています（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年）。
これはAnt Designの単価ではなく、PM、要件定義、デザイナー、フロントエンドの人員に対する一般的な目安です。バックエンド、インフラ、テストなどの人員も含みます。
作業範囲は会社ごとに異なるので、単価だけで高い安いを判断しないようにします。
工程・画面・連携の3つの観点で見る見積もり
初期費用は工程ごとに分けて見ると、抜け漏れを確かめる手がかりになります。工程の概算配分は、要件定義から移行・導入まで4つの区分で見られます。
- 要件定義：10〜15%
- 基本設計：15〜20%、詳細設計：10〜15%
- 開発・単体テスト：30〜40%
- 結合・総合テスト：15〜20%、移行・導入：5〜10%
これは正式な基準ではなく、概算の配分です。要件定義を削って開発を急ぐと、後半の変更や作り直しが増え、結果として総額が下がらないことがあります。
画面単価だけで見ると、複雑さを見落とすことがあります。たとえば、検索・一覧、複数の権限と承認状態を持つ編集、大量データのTable、ファイル取込とエラー訂正では、工数がそれぞれ異なります。
会計・販売・人事などの外部連携は、見積もりで別の行にします。バッチ、帳票、データ移行、受入支援も、別々の項目として扱います。範囲をそろえておけば、安い見積もりが作業を除いていないかを判断できます。
ランニングコストとアップデート費用
初期費用だけでなく、年間の運用保守と更新費用を合わせて見積もります。
- 保守費の目安：初期費用の年10〜20%程度。監視、クラウド、バックアップ、問合せの費用と、脆弱性対応、追加開発によって変わる
- 契約範囲：監視や障害対応を月額に含め、機能改善や大規模更新は別見積もりとする例もある
- 移行確認：Ant Design 5から6へ移るときは、React要件、アイコン、独自CSS、非推奨API、ブラウザの条件を確かめる
- 移行ツール：内部DOM向けのCSSを確かめたうえで、公式CLIで利用状況や非推奨APIを調べる
- 更新計画：採用バージョン、更新頻度、パッチの責任者、検証環境、本番反映の手順を保守契約に含める
年間費用を初期費用と合わせて、3年程度の総保有コストで比べると、将来の予算を立てやすくなります。
委託先の選定と見積比較で失敗しないポイント
委託先は、Ant Designの経験だけでなく、業務システムを納品して運用につないだ経験で評価します。初期費用や提案書の見栄えだけで決めないよう、同じ質問をそろえて比べます。
比べる観点は、担当者と進め方、リスクの伝え方、ソースと文書の扱い、保守体制です。公開事例は自社の業務・規模・契約条件に当てはまるとは限らないため、事例の対象範囲も確かめます。
技術力より先に確認する業務理解とプロジェクト体制
初回の打ち合わせでは、業務責任者への聞き取りや現場ヒアリングの進め方を尋ねます。担当者の分担と参加時期も確かめます。
- 進行：PMが要件を整理する段取り
- 開発：デザイナー、フロントエンド、バックエンドの参加時期
- 運用準備：インフラ、テスト担当の関与と障害対応の体制
Ant Designの実装者だけが参加し、権限・移行・復旧の話が出てこない場合は、体制が足りないおそれがあります。
経験は技術名ではなく、同程度のデータ量や同時利用者数、権限の複雑さ、外部連携、保守期間で確かめます。
海外や大規模な事例では、日本語での要件定義、国内法、契約主体を確かめます。個人情報の越境、時差、障害連絡についても、取り決めを確認します。再委託する場合は、どの相手に責任を求めるかを、契約で明確にしておきます。
見積書を同じ範囲で比べる方法
相見積もりでは、同じRFPと画面一覧、業務フローを各社に渡します。移行条件、非機能要件、受入条件も、同じ条件で示します。見積書は、工程や機能を行単位で見比べます。
- 開発範囲：要件定義、設計、画面、API、DBを含むか。権限と外部連携も対象に入るかを見る
- 導入範囲：移行、テスト、教育、リリース、保守
- 契約条件：除外作業、前提、発注側の作業、追加料金の条件
価格差がある場合は、画面数、テストレベル、PM工数の違いを質問します。セキュリティ診断、移行リハーサル、マニュアル、保守の違いも尋ねます。
人月単価が低くても、別料金の作業を加えると総額が高くなることがあります。一方で、高い見積もりでも、要件定義や受入支援が厚く手戻りを防ぐなら、合理的な場合があります。
安すぎる提案と断定的な納期
提案の前提とリスクが説明されているかを見て、安さや納期の言い切りだけで判断しないようにします。
- 費用と納期：「数週間で完成」「Ant Designだから大幅に安い」と、要件が未確定のまま言い切る提案には注意する
- 見積もり範囲：標準部品で効率化できても、業務ルール、移行、権限、テスト、運用設計は必要になる
- 事前確認：確認すべき質問、PoCで試す画面、開発を止めるおそれのある未決事項を、候補会社に挙げてもらう
現場確認を省いて、トップ画面だけで合意すると、後から例外処理を加える際に権限やデータ構造を直すことがあります。そのうえで、前提、リスク、追加費用を説明できる会社かどうかも確かめ、提案の誠実さを評価します。
よくある質問（FAQ）
発注では、ライセンス、費用、技術選定、既存システムとの連携について疑問が生じやすいので、提案を依頼する前に確認しておきたい質問へ答えます。
Ant Designを使うとライセンス費用はいくらですか？
Ant DesignはオープンソースのUIライブラリで、画面数や利用者数に応じた一般的な製品ライセンス料はありません。ただし、OSSのライセンス表示や依存パッケージの条件は確認しておく必要があります。
開発費は、要件定義や実装、API、データの工数で決まり、テスト、インフラ、保守の工数も加わります。ライセンスが無料でも、開発まで無料になるわけではありません。
Ant Designを採用すればシステム開発費は安くなりますか？
フォームや一覧表は標準部品で作りやすく、UIの初期実装やデザインルールの検討を効率化できる可能性があります。
バックエンドや移行、権限の費用は別に発生します。外部連携、テスト、保守にも、別の費用がかかります。標準部品で作る画面と独自要件の画面を分けて、作業項目ごとに削減効果を確かめます。
既存のReactシステムをAnt Designへ移行できますか？
移行は可能ですが、認証、共通レイアウト、一覧画面などから段階的に進めると、リスクを管理しやすくなります。
既存の状態管理、API、CSS、独自コンポーネントを調べ、テストやブラウザ要件も確かめたうえで、Ant Design 5か6を選びます。
古いReactや内部DOM向けのCSSがある場合は、移行の前にPoCと回帰テストを行います。
発注前に最低限そろえる資料は何ですか？
発注前には、業務目的と課題、現状フロー、利用者と権限、画面一覧をそろえます。加えて、主要データ、外部連携、移行対象、非機能要件を示し、希望時期と予算の考え方も伝えます。
すべての仕様を完成させる必要はありませんが、未決事項と判断期限は明示します。同じ資料を複数社に渡すと、提案と見積もりの前提がそろいます。
委託先を選ぶときに最も重視すべきことは何ですか？
実装経験に加え、業務要件、移行、権限、セキュリティ、受入テスト、保守まで説明できる体制を重視します。リスクや未決事項を示し、担当者と納品物を明確にできる会社は、認識のずれを減らせます。
価格だけでなく、3年間の総保有コストと、契約終了時に引き継げる状態かどうかも比べます。
まとめ
発注では、UIライブラリの知名度や初期見積もりの安さだけでなく、業務を正しくシステムにできるかを確認します。
仕様が固まっていれば請負、変化を前提にするなら準委任、曖昧さが大きければ企画・PoCと本開発を分ける方法が候補になります。
発注前に確認する項目の一覧
RFPには、業務課題、利用者、画面と操作、権限を記載します。データ移行、外部連携、同時利用者数、性能も書き込みます。さらに、セキュリティ、バックアップ、受入条件、納品物、保守範囲も含めます。
見積もりを比べるときは、工程と前提をそろえ、追加費用や更新費用、再委託、ソースコードと設計書の権利を確かめます。TableやFormの数だけでなく、例外処理や承認フローの複雑さも伝えます。
小さく検証してから進める本開発
全画面を開発する前に、検索・一覧・登録・承認の代表的な画面を試し、操作性、権限、既存データを確かめます。そのうえで、Ant Designの効果と独自開発の範囲を、一目で分かる形にまとめます。
将来の更新や保守まで含めた提案を比べられれば、手戻りを減らしながら、業務に定着するシステムを目指せます。
▼全体ガイドの記事
・Ant Designのシステム開発の完全ガイド
▼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を創業。