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

Ant Designのシステム開発は、業務要件を整理し、技術と体制を選んだうえで、設計・開発、テスト、移行、定着へ進めると、業務で使い続けられます。全体は6つのフェーズに分かれ、フェーズごとに決めることと、費用・見積もりの要点を順に見ていきます。

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

Ant Designのシステムの全体像

Ant Designの業務画面の用途と、別途設計する認証・API・データベースを示す注釈図。
画面の共通化と周辺要件の設計を分けて考えられます。

Ant DesignはERPやCRMのような完成パッケージではなく、Reactで業務画面を組み立てるためのデザインシステムであり、UIコンポーネントライブラリです。

Ant Designでは、ButtonやFormに加え、Table、Tree、DatePickerなどを共通ルールで使えます。

Pagination、Modal、Stepsなども同じ共通ルールで扱えるため、検索から一覧、編集、処理結果までの操作を揃えやすくなります。

業務システムで向いている画面

特に相性がよいのは、顧客、商品、案件などの情報を検索して一覧表示する画面です。在庫や従業員の情報を扱う画面も、この範囲に入ります。

  • 検索・一覧:条件入力、列の並べ替え、ページング、行操作、詳細表示をそろえて組めます
  • 申請・処理:Steps、Form、Notification、Resultで、管理部門の操作を統一できます
  • CRUD画面:ProTable、ProForm、EditableProTable、ProLayoutを使って構成

ProComponentsは、画面を高い抽象度で作れる部品群です。

ProComponentsを使うと、状態管理の負担を抑えられるため、業務ロジックに集中できます。

ただし、部品だけで画面が完成するわけではありません。

ProComponentsは、初期実装と共通化を効率よく進めるために使うものです。

標準部品では解決できない範囲

Ant Designが主に担うのは、フロントエンドの表示と操作です。

認証、API、データベースに加え、既存システムとの連携、帳票、データ移行、クラウドも、周辺の要件として別途設計します。運用面では、監視、バックアップ、障害対応も別途設計します。

  • 業務ルール:Tableで表示できても、閲覧できる行、CSV出力、変更履歴は別途設計
  • 独自性が中心の画面:消費者向けサービスなど、独自表現や特殊入力が中心なら、テーマトークンや独自ラッパーを設計
  • 標準部品が合う画面:情報量が多く、操作を揃える価値が高い管理画面や社内申請

出発点では、Ant Designで何を作るかより先に、業務のどの場面を改善するかを決めます。

ポイント

Ant Designは画面部品のライブラリで、業務システム全体を担うものではありません。標準部品で作る画面と、別途設計する周辺要件を分けると、範囲を決めやすくなります。

Ant Designのシステム開発の進め方と6つのフェーズ

開発は6つのフェーズで行います。要件整理、選定、設計開発の順に進み、テスト、稼働、定着へ続きます。

各フェーズの終了条件を決め、成果物と未解決事項を確認してから次へ進むと、未解決の事項を持ち越しにくくなります。

フェーズ1:要件整理で業務とデータの流れを把握

画面一覧より先に、業務の出来事とデータの流れを整理します。画面から考え始めると、業務の流れの抜けに気づきにくくなるためです。誰が、いつ、何を入力し、誰が確認して、どの状態で完了するかを、業務フローとして書き出します。

通常の手順だけでなく、差し戻しや代理承認、取消も現場に確認します。重複登録、締め後の修正、紙やExcelとの併用も、例外として洗い出しておきます。

要件整理で書き出した内容は、次の4種類の成果物にまとめておくと、後の見積もりに使えます。

  • 業務と利用者:業務フロー、ユーザーと権限の一覧
  • 画面とデータ:画面一覧、データ項目表、入力制約
  • 連携と運用:外部連携、非機能要件、移行対象
  • 優先順位:Must、Should、Couldと初回対象外の機能

画面ごとに、検索条件や必須項目、入力制約を仮置きすると、見積もりが具体的になります。さらに、権限やCSV、操作ログも仮置きしておくと、見積もりの前提がはっきりします。

フェーズ2:技術と開発体制の選定

技術を選ぶときは、保守人材と既存資産を踏まえ、認証方式や連携先も含めて、長く運用できる組み合わせを見ます。

  • フロントエンド:ReactとTypeScriptを基本の候補とします
  • 画面部品:Ant DesignとProComponentsの採用
  • バックエンド:Node.jsやNestJS、JavaやSpring Boot、.NETなどから検討
  • 開発環境:状態管理、API通信、テスト、ビルド環境の組み合わせ

フレームワークの人気だけで選ぶと、長く使う段階で保守が続くかどうか分かりません。そこで、5年程度の保守体制とアップデート方針を確かめます。

業務をSaaSや業務パッケージで標準化できるなら、スクラッチ開発が要らない場合があります。一方で、独自の業務フローや既存データとの深い連携が重要なら、準スクラッチやスクラッチが候補になります。

既存のReactシステムは、認証、共通レイアウト、一覧画面などから段階的に移行するのが現実的です。全画面を一度に置き換えるより、リスクを管理しやすいためです。

フェーズ3:画面・API・権限の設計と開発

画面設計では、標準部品で対応する範囲と、独自コンポーネントで作る範囲を分けて決めます。代表画面で先にテーマを確認しておくと、全画面に後から修正が及ぶのを防げます。

  • 見た目:Design Tokenで色、余白、角丸、文字サイズを定義
  • 画面状態:ボタン、入力エラー、読み込み、空データを設計
  • 例外状態:権限不足や通信エラーも画面仕様に含める

APIでは、画面に必要なデータだけを取得できるかを確かめます。検索条件とページングの仕様に加えて、重複更新の防止と監査ログの保存場所も定めます。

RBACの権限は、メニューの表示を制御することと、API側での操作権限の検証の両方で守ります。

開発中は、主要な2〜5画面をPoCとして先に作ります。表示速度や日本語入力、キーボード操作を確かめ、スマートフォン表示やCSV出力も確認してから、画面を増やします。

フェーズ4:業務シナリオと非機能のテスト

テストでは、部品の表示だけでなく、業務が最後まで完了するかを確かめます。工程ごとに確認する範囲は、次のとおり分けます。

  • 単体:入力規則と表示条件
  • 結合:APIと権限
  • 総合:外部連携とバッチ
  • 受入:実データに近い現場シナリオ

空欄や桁あふれ、過去日、重複といった入力の場面に加え、通信切断や同時更新も、テストケースに含めます。さらに、差し戻しや権限変更の場面も、テストケースに入れます。

非機能では、同時利用者数と応答時間、バックアップと復旧の手順を確かめます。さらに、監視とログ保存期間を定め、脆弱性スキャンやブラウザ対応も確認します。

顧客情報や従業員情報を扱う場合は、個人情報保護委員会のガイドラインにある対策を要件にします。アクセス制御や識別・認証、不正アクセス防止、漏えい防止が対象です。

操作ログは、誰がいつどのデータをどう変更したかを後から追える細かさで残します。

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

稼働の前後では、データの品質と切替手順を確かめ、業務を止めるリスクを抑えます。

  • 移行データ:Excelや旧システムから移すマスタ・過去データを整理し、リハーサルで重複、表記揺れ、必須項目の欠落、コード体系の違いを確認
  • 本番移行:責任者、凍結期間、件数照合、エラー時の戻し方、旧システムの参照期間を決定
  • 切替方法:段階稼働、並行稼働、休日切り替えから業務影響に合わせて選択

これらを決めないまま本番移行すると、業務停止のリスクが高まります。

初期運用では、問い合わせ窓口、重大障害の連絡先、復旧目標を契約と手順書に記載します。ログ確認や定例会議、追加改修の扱いも含めて、記載しておきます。

納品対象にソースコードやAPI仕様、DB定義を含めておくと、保守会社を変えるときにも引き継ぎやすくなります。さらに、UIガイドやテスト結果、依存ライブラリ一覧も納品対象にします。

フェーズ6:利用定着とアップデートの継続

稼働後は、利用率や処理時間に加え、紙やExcelに戻った業務と入力ミスを見ます。差し戻しや問い合わせ内容も、確認の対象です。

  • 改善を定着:現場代表者との定例会で要望を優先し、説明会、動画、画面内ヘルプ、マニュアルを更新
  • 機能追加の前:未使用項目や複雑な承認経路を見直す
  • 更新を管理:React要件、ブラウザ、DOM・API変更、アイコン更新、非推奨APIの確認

Ant Design公式のv5からv6への案内では、v6はReact 18以上とモダンブラウザを前提にしています。

DOM構造やAPIの変更、アイコンの同時更新も、確かめておく項目です(出典:Ant Design公式「From v5 to v6」、2026年確認)。

公式CLIを使うと、非推奨APIや利用状況を確かめられます。そのうえで、依存パッケージの更新時期、回帰テスト、緊急パッチの担当者を決め、アップデートを保守契約に含めると、長期運用が安定します。

ポイント

各フェーズの終了条件と成果物を確かめ、未解決の事項を残したまま次へ進まないことが基本です。迷ったときは、次の工程に進む前に未解決の事項が一覧になっているかを見ます。

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

要件定義から結合・総合テストまで、5工程の初期見積もり配分を割合の範囲で比べる棒グラフ。
開発・単体テストの配分幅がほかの工程より大きく示されています。

Ant Designは、画面数や利用者数に応じて購入する業務パッケージではありません。そのため、費用の中心がUI部品のライセンス料になるわけではありません。

総額は、要件定義やAPI、データベースなどの作業で変わります。認証・権限、外部連携、データ移行などの作業も費用に加わり、テストやインフラ、運用保守も含まれます。UIを自作する工数が減っても、業務ルールや品質保証の分まで半額になるわけではありません。

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

規模ごとの金額と期間は、2026年の一般的な業務Webシステム相場と、Ant Designによる画面実装の効率を踏まえた概算です。

  • PoC:50万〜150万円、2〜6週間
  • 小規模な社内ツール:100万〜300万円、1〜3か月
  • 1部門の販売・在庫・申請:500万〜1,500万円、3〜6か月
  • 複数部門の基盤:1,500万〜5,000万円、6〜12か月
  • 基幹連携や大規模刷新:5,000万円〜数億円、12〜36か月

これはAnt Designの公式価格ではなく、案件レンジの推定値です。画面数やAPI、権限に加え、連携、移行、テストを含めた金額です。

公開相場では、小規模100万〜300万円、大規模1,000万円〜数千万円以上、人月単価60万〜200万円以上が目安です(出典:SIA株式会社「システム開発の費用・相場 2026年版」、2026年7月更新)。

画面数が同じでも、帳票や承認、既存データの品質しだいで、見積もりは大きく変わります。

工程別の費用の内訳

初期見積もりは工程別に分けると、抜けやすい作業が見えてきます。次の配分は、案件ごとの前提を置いた目安で、業界の固定の基準ではありません。

  • 要件定義:10〜15%
  • 基本設計:15〜20%
  • 詳細設計:10〜15%
  • 開発・単体テスト:30〜40%
  • 結合・総合テスト:15〜20%

移行・導入は5〜10%程度です。見積書に「開発一式」とだけ書かれている場合は、画面、API、テスト、移行の内訳を尋ねるとよいです。

ランニングコストには、クラウド利用料、監視、バックアップが含まれます。さらに、脆弱性対応、障害対応、問い合わせ、OSやライブラリの更新、追加改修も含まれます。

運用保守は、初期開発費の年10〜20%程度を目安とする考え方があります。24時間監視やSLA、セキュリティ診断を含めると、その分だけ費用は増えます。

保守範囲と時間外対応は初期見積もりから切り分け、月額と都度費用を比べられる形にしておきます。

ポイント

費用は画面数よりも、要件定義やAPI、データベース、認証・権限、移行の作業量で決まると考えると判断しやすくなります。見積書は工程別と保守別に分け、同じ前提で比べます。

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

開発会社の見積もり時に確認する技術と保守、担当者と設計、業務理解、契約と引継ぎの4領域を示すチェックリスト。
4領域を同じ基準で見比べると、提案の抜けを見つけやすくなります。

相見積もりでは、各社に同じ前提を渡すことが欠かせません。Ant Designを採用するとだけ伝えると、画面数やテスト範囲の解釈が会社ごとに分かれ、金額を比べられなくなります。

画面やデータ、権限に加えて、連携、非機能、納品物も、一枚の依頼資料にまとめます。

発注前にそろえる依頼資料

依頼資料には、最低限、業務の現状と希望を書き、画面やデータ、運用条件も入れておきます。

  • 業務の背景:目的とKPI、対象ユーザー、現状・理想フロー
  • 操作と連携:画面一覧、画面ごとの主な操作、データ項目、外部システム、CSVや帳票
  • 運用条件:移行件数、同時利用者数、対応ブラウザ、稼働希望日
  • 権限:「管理者と一般」だけでなく、部門、拠点、担当範囲、承認者、代理操作、CSV出力、削除、個人情報閲覧を整理
  • 移行:データの欠損率、重複率、コード変換、過去何年分を対象にするかを記載

すべてを詳細な仕様にできなくても、未確定の事項と決定期限を一覧にすると、追加費用になりやすい論点が見えてきます。

条件が決まれば、TableやFormだけでなく、APIやテストの工数も見積もりやすくなります。

開発会社の技術力と業務理解

提案の段階では、画面部品の経験に加えて、技術、業務理解、契約上の責任範囲を見ておきます。

  • 技術と保守:Ant Design、ReactとTypeScript、バックエンド、認証、移行、障害対応の経験
  • 担当者と設計:要件整理への参加、標準・独自部品の使い分け、コードと設計書の所有者
  • 業務理解:日本語ルール、会計年度、和暦、CSV、帳票、個人情報の対応経験
  • 契約と引継ぎ:工程の責任分界、仕様変更、検収、知的財産、再委託、保守、脆弱性対応、終了時の引継ぎ

IPAの情報システム・モデル取引・契約書は、開発段階ごとのユーザー企業とITベンダーの責務を整理しています。

第二版と追補版は2025年4月8日更新です(出典:IPA「情報システム・モデル取引・契約書」、2025年更新)。

安い見積もりと高い見積もりの理由

金額に差が出る理由は、見積もりに含まれる作業と規模の要因に分けて見ます。

  • 安い見積もり:要件定義、受入支援、移行、権限テスト、マニュアル、保守が別料金かどうか
  • 提案内容:標準部品に合わせて、業務ルールを無理に変えていないかどうか
  • 高い見積もり:画面・API数、連携、移行の難しさ、利用者数、可用性、ログ、運用時間などによる増額理由

成果物と対象外の作業を一覧で比べます。プロトタイプでMust機能と将来機能を分けておくと、初期投資を抑えつつ、品質を保つ手がかりになります。

金額だけを下げるために、セキュリティ、バックアップ、復旧、受入テストを削るのは避けます。

ポイント

各社に同じ前提の依頼資料を渡せているかが、比較の出発点になります。金額の差は、含まれる作業と規模要因の違いとして読み解くのが基本です。

Ant Designのシステム開発でよくある質問

採用を迷う段階では、UI部品だけでなく、業務の複雑さや将来の保守、発注体制も見ておくと役立ちます。よくある質問を、判断の基準と合わせて紹介します。

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

部品を再利用することで、UIの初期実装や画面間のばらつきを抑えられる可能性はあります。ただし、開発費全体が自動的に安くなるわけではありません。

要件定義やAPI、DBのほか、認証、移行、テスト、保守は別に必要です。標準部品を使える画面と独自要件の画面を分けて見積もると、その効果を評価できます。

Ant Designはどのバックエンドと組み合わせられますか?

ReactのフロントエンドとAPIで接続するため、RESTやGraphQLを提供できるNode.js、Java、.NETなどと組み合わせられます。

言語の好みより、既存連携や運用担当者のスキルを優先します。認証・認可やデータベース、バッチの扱いは、API仕様とエラー処理を含む小さなPoCで確かめます。

Ant Design 5から6への移行で何を確認すべきですか?

Reactのバージョンやブラウザ、@ant-design/iconsのバージョン、非推奨APIを確認します。独自CSSが内部DOM構造に依存していないかも調べます。

公式の案内では、v6はReact 17以前には対応せず、モダンブラウザを前提にしています。DOMやAPIの変更も、確かめておく項目です。

最新のv5で警告を解消し、CLIで利用状況を調べてから、主要画面の回帰テストを行う流れが現実的です。

個人情報を扱う業務システムでAnt Designを使っても安全ですか?

Ant Designは画面部品のライブラリです。安全性は、認証やAPI、権限、インフラ、ログ、運用の設計によって決まります。

最小権限やSSO、MFA、通信中・保存時の暗号化を要件に含めます。さらに、操作ログや脆弱性対応、バックアップと復元訓練も、要件として書いておきます。

個人情報保護委員会の通則編は、リスクに応じた必要かつ適切な安全管理措置を求めています(出典:個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」、2026年確認)。

まとめ:Ant Designのシステム開発を成功させる進め方

成功させるには、UI部品を選ぶだけでなく、現場の例外とデータを把握し、保守体制を選び、標準部品と独自部品を設計することが必要です。

業務シナリオと非機能をテストし、移行、稼働、定着まで責任をもつことが重要です。

発注前に確認する5つの要点

発注前には、同じ粒度の情報を複数社に渡し、金額だけでなく、成果物や責任分界、アップデート方針も比べます。

  • 画面範囲:標準化する画面と独自設計する画面
  • 業務ルール:ユーザー、権限、承認、CSV、帳票
  • データ:API、既存連携、移行データ
  • 品質と運用:応答時間、ログ、バックアップ、復旧
  • 納品と保守:ソースコード、設計書、テスト結果、保守範囲

主要画面のPoCと要件整理から始める方針

全画面の開発会社をすぐに決めるより、代表的な検索・一覧・詳細・承認の画面を選び、現場ユーザーとPoCで確かめる方が進めやすいです。

表示速度や操作性に加えて、例外処理、権限、データ移行、受入条件まで話せる会社なら、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を創業。