GeneXusのシステム開発は、要件を整理し、方式と開発パートナーを選び、モデルを設計して短く反復しながら作り、段階的に稼働させて定着まで進める流れです。各フェーズで完了条件を確かめながら、業務に合う仕組みへ育てていきます。
▼全体ガイドの記事
・GeneXusのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
GeneXusのシステム開発の全体像
GeneXusは、業務項目・伝票・画面・ルールを表すユーザービュー（業務項目・伝票・画面・ルール）を基に、DBやアプリを推論して生成する「ソフトウェアを作るソフトウェア」です。
既製の業務画面を設定するだけのSaaSとは、性質が異なります。
成功の鍵は生成操作の速さだけでなく、現場の知識を矛盾なくモデル化し、変更をナレッジベースへ戻せる体制にあります。
GeneXusが自動生成する対象
GeneXusでは、業務の対象とルールを整理し、その情報を基にシステムを生成します。
- 業務のモデル化：顧客、商品、受注、在庫などについて、項目・関係・登録と更新のルール
- システムの生成：整理した情報から、データベース、画面、処理を生成
公式の製品説明でも、業務内容を記述してデータベースとプログラムを自動生成し、Webやモバイルなどへ展開できる仕組みと説明されています（出典: GeneXus公式「GeneXus」概要、2026年8月確認）。
この方式では、画面数だけで要件の大きさを見積もると、実際の作業量を読み違えます。たとえば受注画面が10画面でも、締め処理、返品、分納が加わり、さらに在庫引当、権限別の承認、会計連携まで続くと、業務ルールとテストケースは大きく増えます。
初期段階で「誰が、どのデータを、どの条件で、どの順番に処理するか」を決めておくと、後工程の手戻りを抑えられます。
GeneXusが向くシステムと向かないシステム
GeneXusを適用するかは、業務ルールの明確さ、将来の変更、サイトの要件を踏まえて判断します。
- 適用しやすい業務：販売、在庫、生産、物流、金融、自治体など、ルールが明確で制度変更や現場改善が見込まれる業務。
- 既存業務の刷新：既存DBのリバースエンジニアリングや外部サービス連携を使い、段階的にWeb化する業務。
- 別技術も検討するケース：状況によって、別技術が適する場合があります。
- 領域ごとの使い分け：非差別領域は標準SaaS、コア業務はGeneXus、周辺サービスはAPI連携で検討します。
業務が頻繁に変わるのに意思決定者が不在の場合や、例外処理をすべて個別対応する場合は、別技術が適する可能性があります。
小規模なキャンペーンサイトで見た目の表現を最優先する場合も、別技術が候補になります。
既存のC/SやAS/400も、データベースのリバースエンジニアリングや外部サービス連携を使えば、すべてを一度に捨てずに刷新できます。
実例として、公式サイトには約600画面のC/SシステムをWeb化し、生成先をC#からJavaへ変えた事例も掲載されています（出典: GeneXus公式「GeneXus」概要、2026年8月確認）。
GeneXusを採用すること自体を目的にせず、業務の再利用性と変更への対応力で評価します。
GeneXusのシステム開発の進め方｜6フェーズ
おすすめの進め方は6フェーズです。最初に要件を整理し、次に方式と開発パートナーを選びます。その後、設計開発とテストを経て稼働し、定着へ進みます。
GeneXusは動くプロトタイプを早く作りやすい一方、初期のモデルが曖昧なまま生成を繰り返すと、誤った業務ルールを速く増やしてしまいます。そのため、各フェーズに完了条件を置き、次へ進む判断を記録してください。
フェーズ1：要件整理による業務とデータの洗い出し
最初に、現行業務を担当者への聞き取りだけで済ませず、帳票やExcel、既存DBまで含めて洗い出します。また、操作ログ、規程、月次締めの手順も並べて、現場の実態を押さえます。
ここで作る成果物と確認事項は、業務情報の整合性や移行規模を見積もるための材料になります。
- 例外業務：通常処理に加えて、返品や取消を記録します。差戻し、修正、障害時の手作業も残します。
- 対象範囲：「システム化」「標準化後にシステム化」「当面は残す」に分けます。
- 成果物：業務一覧、用語集、データ項目表を作ります。権限・連携・帳票一覧、非機能要件、移行方針もまとめます。
- 定義の確認：営業と経理で「顧客」の定義がずれていないかを確かめます。コード体系と桁数、履歴の保持期間も確認します。
このフェーズの完了条件は、画面数ではなく規模を説明できる状態です。規模を示す指標は、エンティティ、トランザクション、連携本数、ユーザー数、ピーク時の処理量です。
フェーズ2：方式と開発パートナーの選定
方式を選ぶときは、適用範囲や生成先をそろえて比べます。データベース、稼働環境、開発体制も同じ条件で並べます。
- パッケージ：汎用業務を短く始められる方式
- SaaS：運用の負荷を下げやすい方式
- フルスクラッチ：自由度を確保しやすい方式
- GeneXus：既存資産を生かし、独自業務をモデルで保持しながら生成技術を更新できます。
- GeneXusの適用先：基幹刷新や標準化しにくい業務に向く中間的な選択肢です。
各社には同じRFPを渡し、要件定義から保守までの範囲、GeneXusの認定・経験年数、同規模事例、再委託先を確認します。
あわせて、生成コードのレビュー方法と、ナレッジベース・設計書の引き渡し条件も確かめます。
DB移行、API、GAM、監査ログの担当者を確かめ、性能試験と障害対応の担当も見ておきます。
PoCは2〜8週間程度で行い、技術を確かめるとともに、説明責任と引き継ぎ姿勢も見極めます。
フェーズ3：モデル設計と短い反復による開発
設計では、全画面の見た目を決めるより前に、データモデルと業務ルールの骨格を作ります。
モデル設計では、共通マスタやトランザクションを整理します。承認状態、採番、エラー処理も含めて、骨格に組み込みます。
- 優先業務で試作：優先度の高い一業務から動くプロトタイプを作ります。
- 現場で反復：操作を通じて用語や入力順を直し、ナレッジベースに反映します。
- 環境と運用：Java/.NETの生成先、DBの文字コード・照合順序、API認証を確認します。
- 拡張方針：標準オブジェクトと拡張部分を分け、拡張ルールを文書化します。
環境と運用では、バッチの再実行とログ保存期間を確かめます。あわせて、最小権限とバックアップ・復元も見ておきます。
生成コードを無条件に編集すると、再生成のたびに差分の管理が難しくなります。
フェーズ4：機能・連携・性能のテスト
テストは稼働直前にまとめて行わず、モデルとプロトタイプを作った時点から始めます。単体テストでは入力チェックや計算、結合テストでは受注から在庫・請求までの連携を確認します。総合テストでは、現場の一連の業務を通して確かめます。
同時更新で在庫が二重に引き当たらないことも、テストで確かめます。
- 連携と権限：権限外データの非表示や、APIタイムアウト後の再送を検証します。
- 例外ケース：空欄、桁あふれ、重複を含めます。取消や日付境界も検証します。締め後修正、通信断、バッチ失敗も対象にします。
りそなホールディングスではGeneXusとGXtestで約3,000件の自動テストを導入し、開発期間・コストを25％削減したと紹介されています。ただし、これは特定案件の実績であり、全案件に同じ効果が出るとは限りません。
自社の案件では、再利用するテストデータと合格基準を先に決め、効果をPoCで測ります（出典: GeneXus公式「はじめての方へ」および導入事例、2026年8月確認）。
フェーズ5：段階移行による稼働
稼働前に、準備の内容と切替範囲、並行稼働のルールを決めておきます。
全社一括で切り替えると原因の切り分けが難しくなるため、段階稼働を検討します。
- 事前準備：移行リハーサルと切り戻し条件を整えます。アカウントや権限、監視、バックアップ、問い合わせ窓口も準備します。
- 段階稼働：部門・拠点・業務を絞り、旧システムとの並行期間を設けます。
- 並行稼働の条件：正とするシステム、差分の照合担当・時期、終了条件を決めます。
- 移行の照合：件数、金額合計、在庫残高、未処理伝票、マスタの有効期間を、旧新で比べます。
- 個人情報の保護：本番データを開発環境へ不用意に複製せず、マスキングやアクセス制御を適用します。
- 当日の手順：停止時間、最終バックアップ、担当者、承認者、緊急連絡先を時系列で記録します。
当日の手順書は、実施者以外でも判断できる形にしておきます。
フェーズ6：定着と継続改善の仕組みづくり
稼働後は、使い方の問い合わせを減らすことに加え、業務標準化の状況、入力漏れ、処理時間を計測します。
改善要望は、そのまま個別に改修せず、共通ルール、部門固有ルール、将来検討に分けて扱います。
- 変更管理：要望をナレッジベースに登録し、リリース計画に載せます。
- 改善周期：週次の小改善と四半期ごとの大きな見直しを分けます。
- 引き継ぎ資産：ナレッジベース、生成コード、ビルド手順、環境定義を一覧にします。テスト資産、移行スクリプト、障害履歴、ライセンス情報も加えます。
担当者が退職しても、別の開発者がローカルでビルドし、テスト環境へリリースできるかを確かめます。
公式サイトでは、ナレッジベースやオブジェクト単位の版管理が説明されています。一方、資産の保有者は、契約で別途確認が必要です。
GeneXusのシステム開発の費用相場とコスト内訳
GeneXusのライセンス定価と開発会社の作業費は、契約形態や開発者数によって変わります。生成先、関連製品、クラウド構成によっても違います。
公開情報だけでは一律の価格を決められません。そこで、リサーチノートが参照した2026年の業務システム相場と、GeneXusの導入範囲を組み合わせた目安を示します。
これは特定案件の見積もりではなく、初期予算を置くためのレンジとして使ってください。
規模別の費用レンジと開発期間
費用は100万円程度から1.5億円以上、期間は1〜2か月から12〜24か月以上です。区分が上がるほど、対象の業務や部門の広がり、連携先、移行の複雑さが増えるため、費用と期間もそのぶん大きくなります。
- PoC・部門内アプリ：100万〜300万円程度、1〜2か月。
- 小規模業務：DB連携が少ない1業務で、300万〜800万円程度、2〜6か月。
- 中規模統合：複数部門、API、帳票、権限、移行を含み、800万〜3,000万円程度、6〜12か月。
- 大規模刷新：複数拠点、複雑な移行、高可用性が必要なら、3,000万円〜1.5億円以上、12〜24か月以上。
上記の幅は、GeneXus専用の公示価格ではありません。一方、業務システム一般の相場は、小規模300万〜1,000万円、中規模1,000万〜5,000万円、大規模5,000万〜1億円以上です。
この幅は、PoCや生成の生産性を考慮した予算検討用のものです（出典: リサーチノート「GeneXusのシステム」、2026年8月確認）。
実際に発注するときは、ライセンス、開発、移行・連携、保守の見積を分けて取得します。
費用を分解して比較する方法
見積もりは初期費用と別建て費用を分けると、内訳を比較できます。
- 初期費用：要件定義、業務整理、モデル、画面・帳票・バッチを含みます。連携、移行、テスト、教育、リリースも対象です。
- 別建て費用：ライセンス、追加製品、クラウド・運用、教育・サポート費用。
開発者ライセンスやチーム開発・バージョン管理環境を確認します。GAM、GXtest、WorkWithPlusの扱いも確かめます。
クラウド基盤と監視、バックアップ、データ転送は、別建てで確認します。教育と年間サポートも、別建ての費用として見ます。
予算比率は、次のように仮置きできます。要件整理は10〜15％、設計開発は35〜45％、連携・移行・テストは25〜35％、教育・リリース・予備費は10〜20％です。これは一般的な比較用の数字で、個別案件の確定比率ではありません。
GeneXus公式の日本語サイトでは、基本的なランタイム費用はないとしつつ、GXflowやGXqueryはランタイムが必要と説明されています。
製品や構成によって例外があるため、「ランタイム無料」の一文だけで総額を判断せず、対象機能ごとのライセンス表を取り寄せます。
保守・運用費と将来の更新費
保守・更新費は、仮置きの金額と契約範囲を分けて確認します。
- 費用の目安：初期開発費の年15〜25％程度を比較用に仮置きできます。
- 契約範囲：監視のみか、業務改善や緊急対応も含むかを確認します。
- 対応条件：平日日中・24時間対応、復旧目標、バックアップ保持、リリース回数を確かめます。
月次監視だけの契約と、改善や緊急対応を含む契約では、同じ年額でも範囲が異なります。
保守費は、法改正への対応や、OS・DB・ジェネレーターの更新によっても変わります。脆弱性や障害対応、問い合わせ、性能改善の範囲も、費用に影響します。
2025年3月公開のGeneXus 18 Upgrade 12はAndroid 15、Xcode 16、Angular 19に対応しています。
あわせて、安定性・セキュリティの強化も示されています（出典: GeneXus公式ドキュメント「GeneXus 18 Upgrade 12」、2026年8月確認）。
更新一覧にはUpgrade 15やUpgrade 16（Preview）も掲載されています。そのため、2026年時点の計画では、採用するUpgradeとサポート期限を個別に確認します。
利用するジェネレーターやDB、OSが保守対象かを確かめます。モバイルSDKやクラウドサービスも含めて確認します。更新検証の工数も予算に入れておきます。技術更新に強い仕組みであっても、検証を省略すれば業務停止のリスクは残ります。
GeneXusの見積もりを取る際のポイント
見積もりの精度は、GeneXusの知識だけでなく、発注側が業務の境界と品質基準をどこまで示せるかで決まります。
締め処理や返品、承認の扱いは、会社ごとに違います。帳票や移行、他システム連携の有無も異なります。そのため、「販売管理を作る」と伝えるだけでは、見積もりの前提がそろいません。
RFPには、対象業務、利用者、データ、連携を書きます。性能、セキュリティ、納品物、保守も、同じ様式で記載します。
RFPに必ず入れる項目
RFPには、業務範囲、規模、データ、連携、品質条件、納品物を明記します。項目ごとに具体的に書いておくと、各社の見積もりの前提がそろいます。
- 業務と規模：対象・対象外、拠点・部門、同時利用者、ピーク取引件数。
- 機能とデータ：画面・帳票・バッチ・APIの概数、DBの種類・データ量、移行履歴、外部システム名。
- 品質・運用：認証方式、権限階層、監査ログ、目標応答時間、稼働率を決めておきます。
- 納品物：ナレッジベース、生成・拡張ソース、DB・API・画面仕様が含まれます。テスト仕様書・結果、移行・運用手順、教育、環境、ライセンスも対象です。
品質・運用の項目には、障害時の復旧時間やバックアップ、保存地域も入れます。スマートフォン対応と並行期間も含めます。
成果物の形式、更新時期、受け入れ基準、権利・利用範囲も記載すると、引き継ぎのリスクを下げられます。
複数社を同じ条件で比較する方法
複数社には、同じRFPとデータサンプル、PoCの範囲を渡して比べます。
- 費用内訳：初期費用、ライセンス、クラウド、移行を比べます。連携、テスト、教育、保守、予備費も、同じ粒度で見ます。
- 見積条件：「一式」の内訳や未計上作業を確認し、自社の前提と照合します。
- 要件と設計：要件定義の具体性、業務担当者との進め方、GeneXusのモデル設計力、既存資産の移行経験。
- 品質と体制：テスト自動化、セキュリティ、保守体制、内製化支援、成果物の引き渡し。
安さだけで選ばず、公式パートナーリストや導入事例で実績を確認します。また、掲載事例が自社案件の規模・業種・品質要件にどの程度近いかも、質問しておきます。
個人情報・再委託・セキュリティの確認
人事や顧客などの個人情報を扱う場合は、見積もりに委託先管理を含めます。
- 委託と再委託：安全管理措置を事前確認し、個人データの扱いを契約で定め、取扱状況を把握します。
- アクセス環境：本番アクセス者、検証環境のマスキング、海外リージョンや再委託先を確かめます。
- セキュリティ要件：ログ保持期間、脆弱性対応者、GAM、監査ログを決めます。TLS、秘密情報、バックアップ暗号化も定めます。
再委託がある場合は、契約に、再委託先と業務内容、データの扱いを入れます。事前報告または承認、監査方法も定めておきます。
通則ガイドラインは、委託先の措置確認、契約、取り扱い状況の把握を示しています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年8月確認）。
監査や教育を費用削減のために外すと、稼働後に追加の費用とリスクが生じやすくなります。
GeneXusのシステム開発でよくある質問
相談時に特に多い疑問を取り上げ、判断材料を短く回答します。
GeneXusなら必ず開発費を下げられますか？
必ず下がるとは限りません。業務標準化やモデル・部品の再利用、テスト自動化、既存資産の活用、内製化が進めば、効率化を期待できます。反対に、複雑な移行や個別帳票、外部連携、厳しい非機能要件があれば、費用は増えます。
ライセンス、開発、移行、保守を含む総額で比較し、PoCで効果を実測してください。
PoCでは何を検証すればよいですか？
重要業務を一つ選び、業務モデルの作りやすさ、試作品の操作性、既存DBまたはAPIとの接続を検証します。
代表的な帳票や権限、ピーク性能も確かめます。また、テストの再実行やナレッジベースの引き継ぎも見ておきます。
成功条件は、「画面が表示できた」ことではなく、現場が業務を完了でき、変更後もテストと再生成ができることです。そのうえで、2〜8週間程度の範囲と成果物を先に固定しておくと、本開発へ進む判断がしやすくなります。
GeneXusの開発を内製化できますか？
内製化は可能ですが、ツール操作の研修だけでは定着しません。
まず、業務オーナー、GeneXus担当者、インフラ・セキュリティ担当者を決めます。そのうえで、モデル設計、レビュー、テスト、リリース、障害対応を、実案件で一緒に経験します。
契約には、研修やペア開発、コードとナレッジベースの引き渡しを含めます。あわせて、問い合わせ対応を縮小する計画を立て、外部会社なしで小さな変更を出せる状態を目指します。
既存のAS/400や古い業務システムから移行できますか？
移行できますが、既存データをそのまま移せるとは限りません。まず、現行DBの項目やコード、重複・欠損を調べ、履歴や締め状態も確かめます。次に、移行するデータとアーカイブするデータを分けます。
GeneXusの公式情報には、既存DBのリバースエンジニアリングや、約600画面のC/SシステムをWeb化した例があります。ただし、自社の移行難易度は、データ品質と連携仕様で決まります。
移行リハーサルは複数回行い、件数だけでなく業務上の残高も照合してください。
まとめ｜GeneXusのシステム開発の成功の鍵となる段階移行
GeneXusのシステム開発は、フェーズごとに完了条件を確認しながら進めます。要件整理から定着まで、6フェーズを順にたどります。
業務を正しくモデル化し、既存DBや外部連携を先に把握したうえで、動くプロトタイプと自動化したテストを小さく積み上げることが、納期と品質の両方を守る基本です。
発注前に確認する最終チェック
発注前には、確認する内容を分野ごとに整理しておきます。
- 業務と規模：対象・対象外業務、ユーザー数、ピーク負荷。
- データと連携：既存DB・移行、APIと帳票。
- 品質と運用：認証・認可、監査ログ、バックアップ、テスト基準、段階稼働・切り戻し条件。
- 契約と体制：ライセンス、保守、再委託、成果物の所有と引き渡し。
特に費用は、初期開発費だけでなく、3年程度の総額で比較します。その総額には、ライセンス、クラウド、教育、保守、技術更新、追加改修を含めます。
次に行うべきこと
発注準備は、業務資料の整理、PoC依頼、提案比較の順に進めます。
- 対象業務を選び、フロー、データ、例外、連携、受け入れ基準を整理します。
- 複数社に同じPoCを依頼し、理解、テスト、セキュリティ、引き継ぎ、保守を比較します。
GeneXusは業務知識を継続管理し、システムを育てる基盤として選ぶことが大切です。
▼全体ガイドの記事
・GeneXusのシステム開発の完全ガイド
▼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を創業。