Magic xpaのシステム開発は、業務とデータの整理、段階的な設計と移行、稼働後の改善を順に進めると、現場に定着しやすくなります。
進め方は、要件整理から定着までの6段階に分かれます。段階ごとに判断基準と成果物を決めながら、順に進めます。
▼全体ガイドの記事
・Magic xpaのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Magic xpaのシステム開発の全体像
Magic xpaは、企業向けの業務アプリケーションをローコードで開発するアプリケーション・プラットフォームです。
販売管理や顧客管理、在庫管理、生産管理などの業務で、長く使うシステムの開発基盤として利用されます。校務や現場向けモバイル業務にも使われます。
公式情報では、デスクトップやWeb、モバイルへの展開が案内されています。あわせて、主要なリレーショナルデータベースとの接続や、REST APIを含む連携も示されています。
5つの層で見るMagic xpaのシステム構成
全体構成は、役割の異なる5つの層に分けると把握できます。
- 開発環境：Magic xpa Studioで画面や業務ロジックを設計する場。
- 実行環境：端末や同時接続数に合わせて選ぶ方式。
- データ層：既存DBを使い続けるか、移行するかの判断。
- 連携層：周辺システムとAPIやファイルで接続する仕組み。
- 運用層：監視や権限、更新、問い合わせ、教育を受け持つ部分。
設計の対象は、画面や帳票、データアクセス、イベント処理、業務ロジックです。実行環境は、クライアント／サーバーやRIA、WebClientなどから選びます。
実行方式は、利用端末と同時接続数、ブラウザ利用の要否に合わせて決めます。データ層では、SQL ServerやOracle Databaseのほか、PostgreSQLやIBM Db2を使い続ける案も検討します。
連携先には、ERPや会計、販売管理、SFAがあります。MAやEC、EDIのほか、帳票やOCRも連携の対象です。接続には、APIやファイル、データベース連携を使います。
運用層には、バックアップや権限、監査ログのほか、障害監視やバージョン更新も含まれます。問い合わせ窓口や教育も、この層に含めます。
ローコードでも欠かせない業務整理と移行計画
ローコードは画面や処理の組み立てを短くしやすい一方で、業務上の問題そのものは解消しません。入力項目や帳票が複雑だと、部門間の表記の違いや古いデータの欠損が残ったままになります。
- 業務とデータの基準づくり：整理しないまま開発すると、不統一な仕組みを引き継ぐことになります。
- 営業・顧客データの統一：顧客、担当者、接点履歴、案件、見積、受注見込み、キャンペーン反応の定義をそろえること。
- データ品質の改善：AIのスコアリングや自動化を加える場合でも、重複顧客や退職者情報、入力ルールの不統一を先に直しておく。
業務とデータをそろえておくほど、Magic xpaの柔軟性を改善に生かしやすくなります。
Magic xpaのシステム開発の進め方｜6つのフェーズ
Magic xpaの開発は、代表業務を小さく検証しながら段階的に広げる進め方が合っています。要件整理から定着までを6段階に分け、段階ごとに判断基準と成果物を決めます。
フェーズ1：要件整理と業務・データの基準の決定
要件整理では、誰が、いつ、何を入力し、どの判断に使うのかを業務ごとに洗い出します。
営業・顧客管理では、顧客登録と商談作成、訪問記録を起点に、見積承認と受注予測までを一連の流れで確認します。失注理由や問い合わせ対応も、同じ流れの中で見ます。
現行画面をそのまま再現する前に、業務を「残す」「廃止する」「標準化する」「将来追加する」に分けます。
- 残す業務：今後も新システムで続ける業務。
- 廃止する業務：新システムでは行わない業務。
- 標準化する業務：部門間の差をそろえる業務。
- 将来追加する業務：後から加える業務。
要件整理の成果物には、業務一覧や利用者・権限一覧、画面一覧があります。帳票一覧と外部連携一覧、データ項目定義を作ります。移行対象表と非機能要件も、この段階で文書にします。
判断基準は、毎日使う代表業務を3〜5個に絞れるかどうかです。顧客や商品を一意に識別できるか、必須項目を説明できるかも確かめます。許容停止時間と目標稼働時間も決めておきます。
この基準が曖昧なまま見積もりを依頼すると、後から追加費用が発生しがちです。
フェーズ2：製品・実行環境・開発会社の選定
実行環境は、利用端末や同時利用者数、既存データベースを踏まえて選びます。ブラウザ利用や外部連携、社内の運用体制も判断材料になります。
- オンプレミス：既存ネットワークや社内規程に合わせやすい傾向。
- クラウド：拠点追加、バックアップ、災害対策を設計しやすい傾向。
- ハイブリッド：通信制約や工場・店舗のオフライン業務があれば比較の対象。
開発会社は、Magic xpaの取扱いだけで決めず、どの業務を担当できるかを確認します。
- 要件・移行：要件定義と既存Magic・Access・RPGからの移行。
- 開発・データ：API連携、モバイル、データクレンジング。
- 稼働後：利用者教育と保守。
国内のMagic xpaパートナーは、公式サイトで800社以上と案内されています。ただし、登録数の多さと自社の案件への適合性は別の問題です。
候補となる会社には、同じ業務範囲を書いたRFPを渡します。そのうえで、前提条件や担当範囲をそろえ、成果物と保守窓口も含めて提案を比べます。
フェーズ3：プロトタイプによる確認と設計・開発
全画面を一気に作る前に、現場の利用者と代表業務を試作して確かめます。
- 試作する業務：顧客検索、案件登録、次回アクション、一覧・帳票。
- 利用者の確認：入力項目の量、検索結果の十分さ、スマートフォンやタブレットでの操作性。
- 業務効果：Excelへの二重入力が減り、業務の流れが短くなるか。
画面の見た目より、業務の流れが短くなるかどうかを優先して判断します。
設計書には、画面遷移や権限、データ項目を残します。採番やエラー処理、帳票の扱いも書いておきます。
外部連携やバックアップの扱いも同じ書類に残し、ログや性能目標も記しておきます。
開発中の判断を口頭だけで済ませると、担当者が替わったとき、改修に必要な経緯が残りません。
Magic xpa Studioで開発した資産については、納品の範囲も先に合意しておきます。ソースや設定、データベース定義に加えて、ビルドやリリースの手順も含めます。
フェーズ4：機能・データ・連携・業務受入のテスト
テストでは、画面の表示だけでなく、テストの工程ごとの確認と業務上の連携まで見ます。
- テスト工程：単体、結合、システム、移行リハーサル、性能、障害復旧、利用者受入。
- 業務連携：案件から見積への引き継ぎ、受注確度変更の集計反映、会計・販売管理連携の二重計上。
テストデータは、本番データをそのままコピーせず、個人情報をマスキングしたものや十分に匿名化したものを使います。
移行テストでは件数だけでなく、データ同士のつながりも照合します。顧客名と担当者、日付と金額、履歴と添付ファイルの関係が対象です。
受入条件は、合否を判定できる形で合意しておきます。例として、重大障害がゼロであることや、主要業務の処理時間が目標以内であること、手順書だけで利用者が登録できることが挙げられます。
フェーズ5：段階稼働と切り替えの安全な実施
稼働方式は、業務を止められるかどうかや、切り替えの方法に応じて選びます。
- 全社一斉切り替え：全社をまとめて新システムへ移す方式。
- 段階稼働：部門ごとに切り替える方式。受注や請求を止められない場合は、参照系や一部拠点から始め、実績を見て対象を広げます。
- 並行稼働：旧システムと併用する方式。二重入力と照合作業が増えるため、期間、終了条件、正とするシステムを決めます。
切り替えの前には、移行リハーサルとバックアップ、復旧手順を確かめます。連絡網や権限発行、利用者教育も確認します。さらに、問い合わせ窓口と当日の責任者も決めておきます。
移行後に問題が出たときに備え、旧システムへ戻せるかを決めておきます。戻せる場合は、どの時点までかも決めます。
稼働判定会議では、未解決の課題を「稼働前必須」「稼働後対応」「対象外」に振り分けます。現場の不安を残したまま切り替えないことも大切です。
フェーズ6：教育と運用改善によるシステムの定着
利用者が入力しなければ、顧客情報や案件情報は蓄積されません。そのため、利用者、管理者、営業現場それぞれの役割を決めておきます。
- 利用者への支援：役割別研修、短い操作動画、よくある質問、問い合わせ方法。
- 管理者への引き継ぎ：ユーザー追加、権限変更、マスタ更新、障害の一次切り分け。
- 営業現場への説明：登録で見積作成や上長レビューが楽になる利点。
定着後は、月次か四半期ごとに、利用率や未入力率、重複登録を確認します。案件更新の遅れや問い合わせ件数、処理時間も、同じ周期で見ます。
改善要望は、法令対応や障害、業務効率、分析の高度化などに分けて、優先順位を付けます。
製品保守やクラウド基盤は、別々に管理します。監視や機能改修、問い合わせ対応も、分けて扱います。
費用を分けて把握しておくと、保守の妥当性や将来投資の検討がしやすくなります。
Magic xpaのシステム開発費用相場とコストの内訳
費用は、ライセンス、開発、インフラに分けて考えます。データ移行、教育、保守も、別の費用として見ておきます。Magic xpa固有の全国統一相場や案件別の公開見積もりは、まだ少ない状況です。
ここで示す開発費は、公式製品価格や一般的な業務システム開発の相場、移行・試作の事例を組み合わせた編集上の推定です。金額は、画面数や帳票数、利用者数に応じて動きます。連携数やデータ品質、要件の複雑さによっても、差が出ます。
ライセンス費の契約形態と利用規模の確認
公開価格や事例は、範囲や条件がそれぞれ異なるため、確認項目を分けて見ます。
- 開発環境：製品ごとの価格と対象範囲。
- 契約と別費用：永続ライセンスに年間保守が付く構成と、サブスクリプション価格があります。実行環境、DB、サーバー、開発作業、教育費は別途です。
- 公開価格表：製品とユーザー数で掲載価格が変わる表。
- 比較条件：価格表の版やエディション、ユーザー数、サーバー構成、保守の有無をそろえること。
- テンプレート事例：2025年に物流向けHTモバイルテンプレートが15万円から販売されました。追加画面、連携、移行、教育を含む総額ではありません。
Magic xpa Studioの定価は60万円、Studio RIA Editionは18万5,000円です。いずれも開発環境の価格です（出典：マジックソフトウェア・ジャパン公式FAQ、2026年8月確認）。
Enterprise Studio Web Editionは32万円です（税別、出典：Magic xpa 4Plus価格表、2024年3月版）。RIA Serverは5ユーザーが26万7,000円、10ユーザーが48万5,000円です（税別、同価格表）。Web Client Server 5ユーザーは26万7,000円です（税別、同価格表）。
開発案件の規模別レンジ
開発規模に応じて、PoCから複数拠点の刷新まで、費用と期間の推定レンジを見積もります。
- PoC：代表画面とDB接続の確認は50万〜150万円、1〜2か月。
- 小規模：顧客・案件管理は300万〜800万円、2〜5か月程度。
- 中規模：営業・CRMや基幹アドオンは800万〜3,000万円、4〜10か月程度。
- 複数拠点の刷新：レガシー刷新は3,000万円〜1億円超、10〜24か月以上。
各レンジは、画面数や帳票、連携のほか、移行対象とテスト範囲が前提です。
費用配分の仮置きは、要件定義が10〜15%、設計が25〜35%、開発が30〜40%です。テストは15〜20%、移行・導入は5〜10%程度です。
これは営業・CRMなど一般的な業務システムの目安で、Magic xpaの案件価格を保証しません。
ローコードでも、データ整備と連携を削ると品質に響きます。受入テストや教育を削れば、定着の面で影響が出ます。
ランニングコストの保守・基盤・改善の内訳
運用費は、内訳と保守水準に分けて見ると、契約条件を比べやすくなります。
- 費用項目：製品のソフトウェア・メンテナンス、クラウドやサーバー、バックアップ、監視、障害対応、問い合わせ、軽微な改修。
- 保守費の仮置き：初期開発費の年10〜20%程度を置く場合もありますが、一般的な目安にすぎません。
保守の範囲に24時間監視や休日対応が含まれるかで、費用は変わります。連携監視やセキュリティ更新の扱いでも、差が出ます。
月額や年額だけでなく、問い合わせ時間や障害の優先度、対応時間を確認します。改修単価やバージョンアップ支援、バックアップ保持期間も確認します。契約終了時のデータ返却も見ておきます。
初期費用を抑えても、仕様変更のたびに追加費用が発生することがあります。そのため、3年程度の総保有コストで比べると判断しやすくなります。
Magic xpaの見積もりを取る際のポイント
見積もりの精度は、発注者が用意する情報の粒度で変わります。「顧客管理を作りたい」とだけ伝えると、画面やデータ、連携の範囲が定まらず、移行や教育も含めて前提をそろえられません。
候補会社には同じ条件を示し、価格だけでなく、作業の抜けや将来の変更しやすさ、現場の利用支援まで比べます。
RFPに入れる画面・データ・連携・非機能の条件
RFPや要件メモには、見積もりの前提をそろえるために、業務の範囲とシステムの条件を書き出します。
- 業務・利用規模：対象部門、利用者数、同時接続数、端末、拠点、対象業務。
- システム範囲：画面・帳票の概数、外部システム、権限、監査ログ、バックアップ、復旧目標、稼働希望日。
- 移行条件：既存データの件数・期間、移行対象年数、重複・欠損を直す担当、移行後の照合方法。
個人情報を扱う場合は、利用目的とアクセス権限、管理者権限の分離を要件に含めます。認証や通信・保存時の暗号化、操作ログも要件に入れます。
退職者アカウントの無効化や委託先の監督、事故発生時の報告手順も、あらかじめ定めておきます。
個人情報保護委員会の通則編は、データの正確性・最新性や保存期間を示しています。さらに、組織的・人的・物理的・技術的安全管理や委託先の監督にも触れています（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年4月施行版）。
Magic xpaを選ぶことは、法令対応の完了を意味しません。法令対応は、製品を選んだあとも、サーバーやデータベース、ネットワーク、運用ルールまで確認して進めます。
複数社の同じ前提と成果物による比較
同じ前提と成果物で比べるには、見積もりと契約の内容をそろえておく必要があります。
- 見積もり項目：要件定義、基本・詳細設計、開発、テスト、移行、教育、稼働支援、保守。
- 担当範囲・適合度：ライセンス販売のみか業務整理も担うか。既存資産や同業移行の経験も確認。
- 契約条件：成果物、検収、仕様変更、著作権・改修権、ソース・設定納品、脆弱性対応、SLA、障害連絡。
既存システムのソースや設計書を読めるか、現場の利用者と試作を繰り返せるかも、適合度を見る材料になります。
担当が替わったときの引き継ぎや、契約終了時のデータ返却も確認します。「標準機能」「追加開発」「将来対応」の境界が曖昧だと、稼働直前に費用と納期が膨らみやすくなります。
見積書と提案書は、前提条件と対象外の範囲を併せて保管しておきます。
失敗を防ぐためのリスクの見積もりへの反映
見積もりに反映するリスクと確認策、導入目標を、あらかじめ整理しておきます。
- 想定リスク：データ品質、業務差、帳票例外、外部API制約、性能、権限設計、現場教育。
- 事前検証：実データに近いサンプル、例外業務、代表拠点での試作。
- 連携確認：連携先と確かめる仕様、レート制限、障害時の再送、重複防止策。
- 測定目標：「古い画面を新しくする」だけで終えず、入力時間や案件更新率、月次集計の日数などを定める。
導入目標が明確であれば、機能の優先順位や、将来追加する機能の範囲を判断しやすくなります。
よくある質問（FAQ）
Magic xpaのシステム開発を検討する企業から、よく寄せられる質問にお答えします。
ライセンス、開発期間、既存システムとの関係は、案件の規模や構成によって変わります。そのため、自社の前提条件に置き換えて確認してください。
Magic xpaのシステム開発は何円からできますか？
代表画面を試すPoCは、編集上の推定で50万〜150万円程度が目安です。顧客・案件管理の小規模開発は300万〜800万円程度です。
中規模の営業・CRMや基幹アドオンは800万〜3,000万円程度を想定します。いずれも公式価格ではなく、画面や連携、移行、教育の範囲から算出した推定レンジです。
ライセンスやサーバー、データベース、保守の費用は、別に確認します。
Accessや古いMagicからMagic xpaへ移行できますか？
移行できる可能性はありますが、既存の資産をすべて自動で変換できるとは限りません。まずは、画面や帳票、DB、外部連携のほか、独自処理も洗い出します。
洗い出した結果は、変換する部分と作り直す部分、廃止する部分に分けます。業務を止められない場合は、参照系や一部拠点から段階的に移行します。
移行では、データ照合と並行稼働の終了条件を先に決めておく方法が現実的です。
ローコードなら開発期間は必ず短くなりますか？
画面や定型処理は短くしやすい一方で、要件整理やデータ移行には別の工数がかかります。複雑な帳票や外部連携、権限は、さらに手間がかかります。性能テストや教育も、見込みに入れておく必要があります。
ローコードだからといって完成までの月数を断定せず、画面数や帳票数、連携数に加えて、移行件数やテスト範囲を基に期間を見積もります。
小さなプロトタイプを先に作ると、現場との認識差を早く見つけられます。
開発会社はMagic xpaの認定や導入社数だけで選べばよいですか？
認定や導入社数は参考になります。そのうえで、近い業種の業務理解や既存資産の移行、データクレンジングを確かめます。API連携やモバイル対応も確認します。
教育や稼働後の保守も確かめます。同じRFPを候補会社へ渡し、担当範囲や成果物、前提条件を比べます。対象外の範囲、変更時の料金、契約終了時のデータ返却も比べます。
まとめ｜6フェーズで区切るMagic xpa導入の進め方
要件整理から定着までの6段階に区切ると、判断と責任の所在が見えやすくなります。
ローコードの開発速度だけでなく、現行業務やデータ品質を含めて計画することが重要です。連携や権限、移行の計画に加え、教育や保守まで含めて考えます。
現場での試作と範囲を分けた見積もり
顧客検索や案件登録といった代表業務を試作し、現場で使えるかを確かめます。製品ライセンスや開発の費用は、移行や教育、運用と分けて比べます。
Accessや既存Magicを活かす場合も、残す処理と廃止する処理を決めておきます。データの重複や欠損を直す担当は、発注者と開発会社で分けます。
最初の一歩は業務一覧と見積もり条件の作成
発注前には、対象業務や利用者、画面・帳票を1枚にまとめます。外部連携と移行データ、セキュリティの条件も書きます。稼働時期や成果物、保守範囲も、この1枚に入れます。
資料を複数社へ渡し、同じ条件で提案と見積もりを受けます。改修や内製化まで見据えてパートナーを選ぶことが、長期活用の前提になります。
▼全体ガイドの記事
・Magic xpaのシステム開発の完全ガイド
▼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を創業。