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

Ant Designのシステム開発を発注・外注するなら、UI部品の採用だけでなく、業務要件、API・データベース、認証・権限、データ移行、テスト、運用保守までを一つの計画として定義することが成功の条件です。Ant Design自体のライセンス費が開発費の中心になるわけではなく、業務を安全に動かすための設計と実装の範囲で費用と納期が決まります。

本記事では、Ant Designを使った業務Webシステムの発注形態の選び方、RFPと要件の整理方法、準委任・請負などの契約形態、2026年時点の費用相場、委託先の選定と見積書の比較方法を順番に解説します。既存Reactシステムの刷新や、社内のExcel・紙業務をシステム化したい企業が、提案内容を比較できる状態まで準備することを目指します。

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

Ant Designのシステムを発注・外注する前に知るべき全体像

Ant Designの業務システム発注を検討する担当者

Ant Designは、Ant Groupが公開するReact向けのデザインシステムおよびUIコンポーネントライブラリです。ERPやCRMの完成パッケージではなく、Table、Form、Menu、Modal、DatePicker、Upload、Statisticなどを組み合わせて、業務に合わせた画面を作るための基盤です。したがって発注先には、フロントエンドの実装力だけでなく、業務分析、バックエンド、インフラ、セキュリティまで対応する体制が求められます。

Ant Designは業務パッケージではなくUI基盤です

発注時に最初に確認したいのは、「Ant Designを使えばシステムが完成する」という誤解をなくすことです。標準部品によってフォームや一覧表の作成を効率化できますが、顧客マスタの持ち方、承認ルール、在庫の引当、CSVの文字コード、帳票、外部サービスとの連携は個別設計になります。画面に表示するデータを取得するAPI、保存するデータベース、ログインや権限の仕組みも別途必要です。

一方で、検索条件を入力して一覧を絞り込み、詳細を確認して登録・承認する業務画面は、Ant Designの標準部品と相性がよい領域です。TableとFormの組み合わせ、Pagination、Steps、Drawer、Notificationなどを共通ルールで使えるため、画面ごとのばらつきを抑えやすくなります。発注資料では「Ant Design採用」と一言で済ませず、標準部品で対応する画面と独自コンポーネントを作る画面を分けて記載します。

発注の成否はコンポーネントより業務理解で決まります

Ant Designに詳しい会社でも、現場の例外処理やデータの責任者を理解しないまま作ると、見た目は整っていても使われないシステムになります。たとえば、営業担当が同じ顧客を別名で登録している、承認者が不在のときに処理が止まる、Excelから取り込んだ日付や電話番号の形式が揃わない、といった問題はUI部品では解決できません。発注前に現状業務とデータを棚卸しし、誰が何をいつ入力し、どの条件で次の担当へ渡すのかを可視化します。

個人情報を扱う場合は、ロール別の閲覧・編集範囲、操作ログ、バックアップ、復旧手順、再委託先を要件に含めます。個人情報保護委員会の通則ガイドラインでは、漏えい・滅失・毀損を防ぐための安全管理措置に加え、取扱状況の把握と見直しも示されています(出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」、2026年確認)。

Ant Designのシステムはどの発注形態を選ぶべきですか?

システム発注形態を比較するイメージ

結論として、業務と完成像が明確なら一括請負、要件を検証しながら進めるなら準委任や段階契約が適しています。社内にIT人材がいるか、現場の意思決定を誰が担うか、既存システムを残すかで適切な形は変わります。最初から開発だけを依頼するのではなく、企画・要件定義を先行させる発注も有効です。

一括請負は完成責任を明確にしやすい発注形態です

一括請負は、合意した仕様と納期に基づいて、受託会社が成果物を完成させて納品する形です。画面一覧、機能仕様、受入条件、納期、納品物を比較的固められる場合に向いています。予算を決めやすい反面、契約後に「この画面も必要だった」「例外処理が抜けていた」と判明すると、変更費用や納期延長につながります。

請負にする場合は、Ant Designの採用だけでなく、対象画面数、画面ごとの操作、API、データ移行、ブラウザ対応、同時利用者数、テスト範囲を成果物の前提にします。完成の定義が曖昧なまま価格だけを固定すると、必要な機能が別見積もりになるためです。

準委任は要件が変わるプロジェクトに向いています

準委任は、稼働する人員や作業時間に対して報酬を支払う形で、要件定義やアジャイル開発のように作業内容が変化する案件に向いています。プロダクト責任者が社内にいて、優先順位を毎週判断できる場合は、短いサイクルでTableやFormの試作を見ながら改善できます。成果物の完成責任を一括請負と同じように期待すると、契約上の認識がずれるため、役割分担を明記します。

準委任では、月ごとの稼働時間、担当者の役割、会議体、レビューの方法、進捗報告、品質指標、交代時の引き継ぎを確認します。発注側が意思決定を止めると、稼働していても開発が進みません。社内の業務責任者と現場代表を固定し、質問への回答期限も決めておくことが重要です。

企画・要件定義と開発を分ける段階発注も有効です

完成イメージが曖昧な場合は、最初に業務整理と画面PoCだけを発注し、その結果をもとに本開発を発注します。主要な2〜5画面で検索、登録、編集、エラー、権限変更を試し、実際の利用者が操作できるかを確認します。PoCを本番品質の開発と混同せず、モックAPIなのか実データ接続なのか、どこまでを納品するのかを切り分けます。

段階発注は、初期の支出を抑えながら大きな手戻りを防ぎやすい一方、企画フェーズの成果物が薄いと本開発の見積もりが安定しません。画面一覧、業務フロー、データ項目、非機能要件、優先順位、未決事項と判断期限までを企画成果物に含めると、次の見積もりを比較しやすくなります。

RFPと要件整理はどこまで準備してから依頼しますか?

RFPと業務要件を整理するイメージ

RFPは、発注先に同じ条件で提案と見積もりを出してもらうための依頼書です。すべての仕様を発注側だけで確定する必要はありませんが、解決したい業務課題、利用者、対象範囲、優先順位、既存資産、予算と希望時期は整理します。Ant Designの技術指定は手段なので、標準部品を使う理由と、画面品質・保守性に期待することも添えます。

RFPには業務・利用者・データの3点を入れます

業務については、現状の手順、困っていること、改善後のKPI、対象外の業務を記載します。利用者については、一般担当者、承認者、管理者、外部利用者などの役割と人数、利用場所、利用端末、同時利用者数を記載します。データについては、顧客・商品・案件などのマスタ、1日あたりの登録件数、保存期間、既存Excelや旧システムからの移行有無を記載します。

画面要件は「一覧画面が必要」とだけ書かず、検索条件、表示列、ソート、ページング、CSV出力、権限、空データ時の表示、エラーメッセージ、承認後の変更可否まで分解します。Ant DesignのTableやFormを使っても、1画面に表示する列が多すぎれば操作性や性能に影響します。画面数だけでなく、画面の複雑度を示すことが見積もり精度につながります。

非機能要件はRFPの段階で後回しにしないでください

非機能要件には、可用性、性能、セキュリティ、バックアップ、監視、障害対応、保守時間、拡張性を含めます。たとえば「快適に動く」ではなく、検索結果を何秒程度で表示したいか、通常時と繁忙期の同時利用者数、障害時に何時間以内に復旧したいかを示します。個人情報や人事情報を扱う場合は、SSO・MFA、最小権限、操作ログ、暗号化、脆弱性対応、再委託の扱いも確認します。

Ant Design 6はReact 18以上を必要とし、モダンブラウザを前提にCSS変数を使うため、古いブラウザ対応が必要な案件では事前検証が必要です(出典: Ant Design公式「From v5 to v6」、2026年確認)。既存システムを刷新する場合は、Reactのバージョン、ブラウザ、独自CSS、アイコンのバージョン、E2Eテストの有無をRFPに記載し、アップグレード時の回帰テスト費用を見積もりに含めます。

受入条件と未決事項を分けて書きます

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だけの公式価格表ではありません。

規模別の初期費用は100万円台から数億円まで広がります

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つに分けて見ます

初期費用のたたき台として、要件定義を10〜15%、基本設計を15〜20%、詳細設計を10〜15%、開発・単体テストを30〜40%、結合・総合テストを15〜20%、移行・導入を5〜10%程度に分けて見る方法があります。これは案件ごとの正式な基準ではなく、抜け漏れを確認するための概算配分です。要件定義を削って開発へ急ぐと、後半の仕様変更や作り直しが増え、総額が下がらないことがあります。

画面単価だけではなく、画面の複雑度を確認します。検索と一覧だけの画面、複数の権限と承認状態を持つ編集画面、大量データを扱うTable、ファイル取込とエラー訂正を含む画面では工数が異なります。さらに会計・販売・人事などの外部連携、バッチ、帳票、データ移行、受入支援を別行で示してもらうと、安い見積もりが範囲を削っているのかを判断できます。

ランニングコストとアップデート費用も初期段階で確認します

運用保守は、初期開発費の年10〜20%程度を目安に置く考え方がありますが、実際には監視、クラウド、バックアップ、問い合わせ、脆弱性対応、追加開発の範囲で変わります。たとえば監視と障害対応だけを月額に含め、機能改善や大規模なバージョンアップは別見積もりにする契約もあります。年間費用を初期費用と一緒に比較し、3年程度の総保有コストを確認します。

Ant Design 5から6への移行では、Reactの要件、アイコンパッケージ、内部DOMを対象にした独自CSS、非推奨API、ブラウザ対応を確認します。公式の移行案内にはCLIによる使用状況や非推奨APIの確認も案内されています。新規開発では、採用バージョン、更新頻度、セキュリティパッチの責任者、検証環境と本番反映手順を保守契約に含めておくと、将来の予算を立てやすくなります。

委託先の選定と見積比較で失敗しないポイント

委託先と見積もりを比較するイメージ

委託先は、Ant Designを使った経験の数だけでなく、業務システムを納品し運用へつないだ経験で評価します。提案書の見栄えや初期費用の安さだけで決めず、担当者、進め方、リスクの伝え方、ソースとドキュメントの扱い、保守体制を同じ質問で比較します。公開事例がある会社でも、自社の業務・規模・契約条件にそのまま当てはまるとは限らないため、事例の範囲を確認します。

技術力より先に業務理解とプロジェクト体制を確認します

初回の打ち合わせでは、業務責任者から話を聞くか、現場ヒアリングをどう設計するかを質問します。PMが要件を整理し、デザイナー、フロントエンド、バックエンド、インフラ、テスト担当がどの段階で参加するかも確認します。Ant Designの実装者だけが参加し、権限・移行・障害復旧の話が出ない場合は、体制の不足を疑う必要があります。

担当者の経験は、使用技術名ではなく、同程度のデータ量、同時利用者数、権限の複雑さ、外部連携、保守期間で確認します。海外事例や大規模事例を紹介された場合は、日本語での要件定義、国内法への対応、契約主体、個人情報の越境、時差、障害時の連絡体制を確認します。実装を別会社へ再委託する場合は、発注者が誰に責任を求めるのかを契約で明確にします。

見積書は金額ではなく同じ範囲で比較します

相見積もりでは、同じRFP、画面一覧、業務フロー、データ移行条件、非機能要件、受入条件を渡します。見積書では、要件定義、設計、画面、API、DB、権限、外部連携、移行、テスト、教育、リリース、保守を行単位で確認します。含まれない作業、前提条件、発注側の作業、追加料金の条件も並べ、比較表の列を揃えます。

価格差があるときは、画面数、テストレベル、PM工数、セキュリティ診断、移行リハーサル、マニュアル、保守のどこが違うのかを質問します。人月単価が低くても、必要な作業が別料金なら総額は高くなる場合があります。逆に高い見積もりでも、要件定義や受入支援が厚く、手戻りを防ぐ設計なら合理的なことがあります。

安すぎる提案と断定的な納期には注意します

要件が揃っていない段階で「数週間で完成する」「Ant Designだから大幅に安くなる」と断定する提案には注意します。標準部品で効率化できる範囲はありますが、業務ルール、データ移行、権限、テスト、運用設計がなくなるわけではありません。見積もりの前提、リスク、追加費用の発生条件を説明できる会社の方が、発注後の認識違いを減らしやすいです。

また、発注側が判断を急ぎ、現場の確認を省くこともリスクです。トップ画面だけで承認を得て、後から例外処理を足すと、権限やデータ構造の作り直しが発生します。候補会社には、最初に確認すべき質問、PoCで検証すべき画面、開発を止める可能性がある未決事項を挙げてもらい、提案の誠実さを評価します。

よくある質問(FAQ)

Ant Designのシステム発注に関するよくある質問

Ant Designの発注では、ライセンス、費用、技術選定、既存システムとの連携について疑問が生じやすいです。ここでは、提案依頼の前に確認しておきたい質問へ直接回答します。

Ant Designを使うとライセンス費用はいくらですか?

Ant DesignはオープンソースのUIライブラリであり、画面数や利用者数に応じた一般的な製品ライセンス料を支払う形ではありません。ただし、利用するOSSのライセンス表示や依存パッケージの条件確認は必要です。開発費は要件定義、実装、API、データ、テスト、インフラ、保守の工数で決まるため、ライセンス無料イコール開発無料ではありません。

Ant Designを採用すればシステム開発費は安くなりますか?

フォームや一覧表などの共通画面を標準部品で作りやすくなるため、UIの初期実装やデザインルールの検討を効率化できる可能性はあります。しかし、バックエンド、データ移行、権限、外部連携、テスト、保守の費用は別に発生します。標準部品を使える画面と独自要件の画面を分けて見積もり、採用による削減効果を作業項目単位で確認します。

既存のReactシステムをAnt Designへ移行できますか?

移行できますが、一括で画面を置き換えるより、認証・共通レイアウト・一覧画面などから段階的に進める方がリスクを管理しやすいです。既存の状態管理、API、CSS、独自コンポーネント、テスト、ブラウザ要件を調べ、Ant Design 5または6の採用バージョンを決めます。古いReactや内部DOMを対象にしたCSSがある場合は、移行前にPoCと回帰テストを実施します。

発注前に最低限そろえる資料は何ですか?

業務の目的と課題、現状業務フロー、対象利用者と権限、画面一覧、主要なデータ項目、外部連携、移行対象、非機能要件、希望時期、予算の考え方をそろえます。すべての仕様を完成させる必要はありませんが、未決事項と判断期限を明示します。同じ資料を複数社へ渡し、提案内容と見積もりの前提を揃えることが大切です。

委託先を選ぶときに最も重視すべきことは何ですか?

Ant Designの実装経験に加え、業務要件を整理し、データ移行、権限、セキュリティ、受入テスト、保守まで説明できる体制を重視します。提案時にリスクや未決事項を指摘し、担当者と納品物を明確にできる会社は、発注後の認識違いを減らしやすいです。価格だけでなく、3年間の総保有コストと、契約終了時に引き継げる状態かも比較します。

まとめ

Ant Designのシステム発注を成功させるまとめ

Ant Designのシステム開発を発注・外注するときは、UIライブラリの知名度や初期見積もりの安さだけでなく、業務を正しくシステムへ落とし込めるかを確認します。発注形態は、仕様が固まっているなら請負、変化を前提にするなら準委任、曖昧さが大きいなら企画・PoCと本開発を分ける段階発注が候補です。

発注前に確認する項目を一枚にまとめます

RFPには、業務課題、利用者、画面と操作、権限、データ移行、外部連携、同時利用者数、性能、セキュリティ、バックアップ、受入条件、納品物、保守範囲を記載します。見積比較では、同じ範囲で工程と前提をそろえ、追加費用、更新費用、再委託、ソースコードと設計書の権利を確認します。特にTableやFormの数だけでなく、例外処理や承認フローの複雑さを伝えることが重要です。

小さく検証してから本開発へ進めます

最初から全画面を作り始めるのではなく、代表的な検索・一覧・登録・承認画面で、利用者が迷わず操作できるか、権限が正しく働くか、既存データを扱えるかを検証します。Ant Designの採用効果と独自開発の範囲を見える化し、将来のバージョンアップや保守まで含めた提案を比較できれば、発注後の手戻りを減らしながら業務に定着するシステムを目指せます。

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

会社紹介

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

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

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

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

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

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