Informixのシステム開発は、現行の資産と業務を調べて方式を選び、設計、テスト、切替、定着へと進みます。この流れを踏むと、停止リスクを抑えた刷新につながります。
費用は、接続確認のような小さな検証から大規模な刷新まで、ケースごとの概算で見ます。
▼全体ガイドの記事
・Informixのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Informixのシステム開発の全体像
Informixは、リレーショナルデータ、JSON、時系列データを扱えるデータベースです。また、高可用性や組み込み用途にも対応しやすいのが特徴です。
受発注、在庫、製造、店舗、設備監視など、止めにくい業務を長年支えてきました。一方で、周辺には古い画面、バッチ、帳票、運用スクリプトが残りやすい製品です。
Informixが向いているシステムの特徴
Informixの適性は、業務の処理量や稼働条件、保守環境をあわせて見て判断します。
- 処理特性：大量処理と長時間の連続稼働を求める業務
- 製品機能：SQL、NoSQL/JSON、時系列、高可用性、組み込み、リアルタイム分析（出典: IBM Informix製品情報、2026年確認）
- 継続条件：バージョン、OS、CSDK、JDBC・ODBC、言語、保守契約
店舗端末の売上を受け取りながら在庫を更新し、夜間に集計する構成では、既存資産を活用できます。ただし、システムの継続は、Informixを使っていることに加えて、周辺の資産や担当体制でも決まります。
4GLやESQL/Cのソースがあっても、コンパイル環境や担当者が欠けていれば、DBの維持だけでは効果が限られます。
2026年に先に確認したい製品と環境の変化
HCL Informix 15.0には、Helm ChartによるKubernetesデプロイも含まれます。
15.0.1系でも、複数の部分で変更があります（出典: HCL Informix 15.0公式ドキュメント、2026年確認）。
- 15.0：容量拡張、クエリのプラン取得、クラウドバックアップ強化
- 15.0.1系：ライセンス、JDBC配布、AI連携、認証初期値が変更
- 移行の進め方：リフトまたはリホスト後、運用改善と必要範囲の刷新
更新では、サーバーだけでなく、CSDKやJDBCなど周辺の組み合わせも検証します。
クラウド移行で自動的に安くなるとは限りません。仮想マシンやストレージ性能、バックアップ世代を比べます。監視や冗長構成、ライセンス、通信費も、同じ条件で見ます。
Informixのシステム開発の進め方
開発は6フェーズに分けると、抜け漏れを管理しやすくなります。6フェーズは、要件整理から定着まで順に進みます。
設計の前に現行システムを調べ、稼働の前には切戻しの条件を決めておきます。特に古い業務システムでは、仕様書に載っていない夜間バッチや手作業が、本番運用を支えている場合があります。
フェーズ1：要件整理による現行資産と業務実態の把握
まず、現行資産台帳を作ります。担当者への聞き取りに加えて、ソースやジョブ定義、ログを確かめます。
- 環境：Informixの版、OS、サーバー構成、DB数とサイズ
- データと接続：表、索引、接続元、外部連携
- 業務資産：4GL・ESQL/C・Visual Basic、帳票、バッチ
- 運用：バックアップ、監視、障害履歴、復元実測
業務要件と非機能要件は、数値にして決めておきます。決める項目は、処理時間と同時接続数、繁忙期の件数、停止可能時間です。
障害からの復旧では、目標復旧時間をRTO、許容データ損失時間をRPOとして定めておきます。
個人情報や会計データを扱う場合は、権限や操作ログ、暗号化などの対策が要ります。さらに、委託先の管理や法令・監査要件も決めておきます。
要件整理では、業務フロー図と構成図、連携・移行対象の一覧をそろえます。
課題と優先順位、受入基準も、資料にまとめます。
「画面を新しくしたい」という要望は、開発の範囲を決めるには具体化が必要です。そのため、対象業務と利用者、入力、承認を明らかにし、帳票や連携先、エラー時の扱いまで書き出します。
対象外の機能も明記します。
フェーズ2：保守継続・クラウド移行・リプレースの選定
選定では、4つの方式を停止リスクと保守のしやすさから比べます。
- 保守継続：変更と停止リスクを抑えやすい一方、人材不足や古いOSが残りやすい
- リホスト：既存アプリを活用し、移行期間を短くしやすい
- モダナイズ：監視・バックアップ・API化を改善できる
- 他DB移行：人材確保に有利な場合がある一方、業務ルールの再検証の負担が大きい
他DB移行では、SQLの方言と文字コード、日付やNULLの扱いを再検証します。
帳票と業務ルールも対象です。
停止可能時間が短く、現行アプリが安定しているなら、Informixを維持したままOSや基盤を更新し、API化は小さく始めます。
サポート期限や専用ハードウェア、人材の退職が重なる場合は、他DB移行を含む複数年の計画を作ります。
監査要件が絡むときも、同じ計画に含めます。
発注先には、現行解析と移行、業務テストの担当範囲を確かめます。
旧言語や切替、運用引き継ぎなどの作業も、どこまで発注先が受け持つかを確認します。
提案書には、成果物や体制、前提、対象外の範囲を明記してもらいます。
再委託先と障害対応、保守時間、追加費用の条件も、あわせて示してもらいます。
フェーズ3：データ・接続・運用を含めた設計開発
設計では、先に境界を決めておきます。データと接続、既存資産、基盤の境界が対象です。
- データ：既存表、新しい表やJSON領域、時系列データの構造
- 接続：JDBC、ODBC、.NET、RESTと認証・タイムアウト等
- 既存資産：読み取り専用APIや照会など小さな機能から分離
- 基盤・復旧：CPUやメモリ、dbspace、ストレージI/O、バックアップ、監視、HA等
4GLやESQL/Cは、一度にすべて書き換えなくても構いません。影響の小さい機能から、順に分けられます。
古いSQLと新しいアプリが同じデータを更新する場合は、ロックや分離レベル、採番を確かめます。
排他と文字コードも含めて確認したうえで、表の更新者と時点を設計書に残します。
HAやEnterprise Replicationを使う場合は、テスト計画に、障害検知から切替までの時間とアプリの再接続を含めます。
復旧後の整合性と、切戻しの判断者も計画に入れます。
フェーズ4：実データに近い条件でのテスト
テストは、段階ごとに分けて進めます。単体と結合、性能に加え、障害・復旧と業務受入を見ます。Informixでは、SQLの実行に加えて、データと処理条件も確かめます。
- データ：件数、日付、DECIMAL、NULL、長い文字列、BLOB、文字コード
- 処理：インデックス、ロック待ち、月末処理、例外データ
- 移行：レコード件数、金額、在庫、日次残高、マスタ紐付けの差異
- 業務：夜間バッチ、連携、帳票、締め、再実行、エラー時の手動運用
少量のテストデータでは、本番の月末処理や例外を再現しきれません。そのため、移行時は匿名化した本番相当のデータで、リハーサルを行います。
差異が出たときの調査方法は、あらかじめ決めておきます。画面の確認だけでなく、業務担当者にも処理を見てもらいます。
クラウド移行では、初回同期と切替直前の差分を確かめます。停止時間と復元、監視通知も対象です。権限とネットワーク経路も、あわせて確認します。
DataArtのAWS移行事例では、構成の自動探索やInformix固有ツールを組み合わせています。
DataArtは、バックアップと復元の自動化、監視、下位環境での検証も取り入れています（出典: DataArt「Migration Project to Facilitate Datacenter Exit for Trader Interactive」、2026年確認）。
サーバー移行と本番運用の検証は、分けて計画します。
フェーズ5：切替と稼働直後の安定化の管理
切替の方式は、一斉切替、段階切替、並行稼働から、業務単位で選びます。
- 一斉切替：短期間で終えやすいが、問題時の影響が広い
- 段階切替：リスクを分けられるが、旧新環境の二重運用が生じる
- 並行稼働：照合しやすいが、入力ルールと同期の運用負荷が大きい
切替計画には、開始条件、バックアップ、最終移行を書きます。業務確認と利用者連絡、監視開始、判定会議、切戻し期限も、同じ計画に含めます。
切戻しの基準は、エラー件数や処理時間、データ差異などで決めます。連携の未達や問い合わせ数も、基準に含めます。切戻しの可能時間と、失われる入力の扱いは、関係者と合意します。
稼働後の1〜2週間は、通常の保守とは分けて、安定化の期間にします。この期間は、性能やバックアップ、エラーを日次で確かめます。バッチや連携、問い合わせも、同じ頻度で見ます。
Claranetの2026年5月の事例では、Solaris/SPARC上のInformixを、Ubuntu LinuxとAWSへ移しています。
事例では、バージョン更新やEnterprise Replication、監視、調整も実施しています（出典: Claranet「From Solaris to the cloud: lessons from a real Informix migration」、2026年5月6日）。
暫定対応と恒久対応は、分けて扱います。
運用担当者が状況を把握できるところまでを、移行の成果として評価します。
フェーズ6：運用と利用者の定着までの仕組みづくり
運用手順や利用者支援、改善の確認項目を決めておくと、納品後の定着につながります。
- 運用手順：起動停止、バックアップ、障害対応、復旧、連絡
- 利用者支援：役割別の変更説明、操作教育、問い合わせ分類
- 定期確認：月次または四半期ごとに障害、処理時間、バックアップ成功率、問い合わせ、手作業時間、利用率を確認
- 継続改善：効果を測り、小さく検証してから本番に反映
開発会社でしか復旧できない状態のままだと、担当者の退職や契約終了で、運用が特定の人に頼ることになります。そのため、手順書には、画面操作だけでなく判断条件と実行結果も残しておきます。
利用者には、入力やエラー時の連絡先、締め処理を説明します。過去データの検索範囲も、あわせて伝えておきます。
問い合わせを操作教育、仕様変更、データや性能の問題に分けておくと、改善の優先順位を決める手がかりになります。
HCL Informix 15.0のAI連携やKubernetes化も、導入が目的にならないよう、復旧時間や運用負荷、監視精度で効果を測ります。小さく検証し、業務への影響を確かめてから、本番に広げます。
Informixのシステム開発にかかる費用相場
費用は、ライセンスに加えて、現行解析や改修、移行の作業で決まります。
基盤やテスト、教育、保守も、費用に含まれます。
商用ライセンスの価格は、エディションやコア数、環境、サポート契約で変わります。そのため、各社の価格は、公開価格だけでなく条件をそろえて比べる必要があります。
下の数字は、業務システム全般の相場と移行の論点を組み合わせた概算です。Informix固有の確定価格ではありません。
ケース別の概算レンジ
開発者版などの利用条件を確かめ、相場を基にした概算を示します。
- 接続確認または小規模PoCのみ：0万〜100万円程度
- 既存Informixの小規模Web画面・API化：150万〜500万円程度
- 中小企業の受発注・在庫などの連携：500万〜1,500万円程度
- モダナイズ・クラウド移行：1,500万〜5,000万円程度
- 大規模刷新・他DB移行：5,000万円〜数億円の場合もある
PoCの費用には、環境構築や接続、性能確認が含まれます。
開発費は、画面数や外部連携、テスト範囲によって変わります。認証や帳票の扱いも、費用に響きます。
モダナイズ・クラウド移行の金額は、4GLや旧VBを残す段階的なモダナイズや、クラウド移行の目安です。
この金額には、現行解析や移行設計、アプリ改修が含まれます。HAやレプリケーション、バックアップ、監視、教育も含みます。
これらの金額は、業務システム相場を基にした推定です（出典: NotebookLM「業務システム全般」Q&A、2026年確認）。
実際の費用は、要件定義が終わってから見積もります。
費用を左右する工数とランニングコスト
見積もりでは、開発工数と稼働後の費用の両方を確かめます。
- 開発工数：DBサイズ、表・索引数、SQLの複雑さ、旧言語の量、バッチ、帳票、外部連携
- 検証条件：文字コード、データ品質、接続数、性能、テストデータ
- 稼働費用：ライセンス、基盤、保存、監視、通信、OS、証明書、セキュリティ、保守
- 保守費：一般的な業務システムでは、初期開発費の年10〜20%の場合もある。24時間監視、駆け付け、更新、移行支援で変動
- 段階開発：在庫照会やマスタ管理から始めると抑えられる場合がある
仕様書に載っていない手作業や夜間処理を見落とすと、開発の後半で追加費用が生じやすくなります。
初期費用が1,000万円でも、年間の保守費が100万〜200万円になるとは断定できません。そのため、保守の契約範囲は、初期開発とは分けて考えます。
初期費用は、読み取り専用APIなどで抑えられる場合があります。ただし、ライセンスや停止できない時間帯、データ量、接続数は、初期費用とあわせて見ます。HA・DRやバックアップ世代、教育も含めます。
仮想マシンやストレージ、バックアップは、3年間の総保有コストで比べます。監視や通信、OS、証明書、セキュリティ、保守も、同じ期間で確かめます。
Informixの見積もりを取る際のポイント
見積もりは、総額だけでなく、調査、開発、検証、運用支援の範囲に分けて見ます。
現行調査を済ませてから開発費を比べると、各社の前提がそろい、安さの理由を読み取りやすくなります。RFPには、環境や業務、目標を書き、制約や期限、成果物、受入基準も含めます。
要件と前提条件をそろえた依頼
分からない項目は、そのまま明記します。そのうえで、ベンダー調査で決める事項と、発注者が決める事項を分けておきます。
対象ユーザーと処理件数、締め処理の流れを整理します。帳票や承認、外部システムとの関係も明らかにします。
- 環境：版・エディション、OS、台数、DBサイズと増加量
- 性能・復旧：接続数、ピーク時間、バックアップ、RTO・RPO
- アプリ：接続方式、言語、ソースコードの有無
- 業務・移行：処理、帳票、承認、連携、手作業、保存期間、照合方法
移行の対象期間と、データの削除・保管の方針を決めておきます。旧環境の保管や切替後の照合方法も、整理します。
クラウド化では、リージョンやネットワーク、保存先を前提に決めておきます。監視や障害通知、運用時間、セキュリティ審査も、前提として扱います。
複数社の提案の比べ方
各社には、同じ現行資料と質問を渡します。そのうえで、担当者の役割や成果物、時期、前提、追加費用の発生条件まで確かめます。
- 技術：Informix版、旧言語、DB移行、クラウド、性能
- 運用・安全：HA・DR、セキュリティ、保守
- 導入：テスト、切替、教育
技術や運用の提案は、新しい機能を使うこと自体を目的とせず、自社の課題に合うかを見ます。
Helm Chartを使うなら、Kubernetesの体制や版、永続ストレージを確認します。バックアップと復旧の手順も、あわせて見ます。
AIエージェント連携では、業務の範囲や入力データ、権限を明確にします。監査や誤操作時の人手確認も含め、効果と運用責任の両面で評価します。
追加費用と切替リスクの条件の決め方
追加作業が必要になる条件や単価、承認の方法、納期への影響は、契約の前に確かめておきます。
- 未記載の処理：現行資料にないバッチが見つかった場合
- データ差異：不整合が一定件数を超えた場合
- 性能：要件を満たさない場合
- 互換性：未サポートOSやドライバーが判明した場合
調査や受入テストが別料金であれば、一式の見積もりも、総額で比べる必要があります。
セキュリティの対象は、DBに加えて、JDBCやJava、REST listenerにも及びます。OS、コンテナ、監視ツールも含みます。
REST APIでは、TLSや認証、権限の設定に加えて、CSRF対策や監査ログも含めます。ネットワーク制限と秘密情報の保管も、あわせて確かめます。
パッチの責任範囲や脆弱性の連絡時間、暗号化、復元テストの頻度は、見積もりと保守契約に記します。
発注の前に、切替の判断者と業務受入の責任者、データ差異の許容基準を合意しておきます。
Informix移行には、現場の業務知識も欠かせません。そのため、現行担当や情報システム、開発会社の役割を、基盤やセキュリティ担当と合わせてRACIなどで整理しておくと、判断の遅れを防げます。
Informixのシステム開発でよくある質問
既存資産の扱いやクラウド移行、旧版の更新について、発注や稟議の前に確かめたい点を紹介します。
Informixのシステムはクラウドへ移行できますか？
移行はできますが、方式は、OSやInformixの版、ライセンス、接続方式、停止可能時間で決まります。まず仮想マシンへリホストし、そのあとに監視やバックアップ、冗長化、API化を改善する段階移行は、停止リスクを抑えやすい方法です。
Informixのシステム開発費用はいくらですか？
既存Informixの活用から大規模な移行まで、開発内容ごとの概算を示します。
- 接続確認・小規模PoC：0万〜100万円程度
- 既存Informixの小規模Web/API化：150万〜500万円程度
- 中小企業の業務連携：500万〜1,500万円程度
- 旧資産のモダナイズ・クラウド移行：1,500万〜5,000万円程度になることがあります
金額は、DBサイズより、旧言語や連携、帳票の範囲で変わります。データ品質やテスト、切替、保守の範囲も影響します。
調査費と開発費は、分けて見積もります。
Informixを扱える開発会社は何を基準に選べばよいですか？
経験年数に加えて、解析や4GL・ESQL/Cの保守、SQL調整、移行まで対応できるかを確かめます。
提案書には、成果物や担当者、対応版、対象外を記載してもらいます。追加費用や障害体制も書いてもらうと、同じRFPで2〜3社を比べたときに判断しやすくなります。
公開事例は、同じ業界でなくても、技術や運用の課題が似ているかを見ます。
まとめ
Informix開発で大切なのは、最新技術への一括置換より、業務を止めずに進めることです。
まず現行資産と業務を調べ、そのうえで、保守継続やクラウド移行、モダナイズ、他DBへの移行を比べます。
方式を選ぶ際は、停止リスクや費用、保守人材、将来性を基準にします。
6フェーズを順番に進める条件と各段階の役割
要件整理で資産や業務、非機能要件を数値にそろえ、選定で保守やリホスト、モダナイズ、移行を比べます。
設計開発では、データや接続、権限を仕様として決め、バックアップと復旧の仕様も書きます。そのうえで、実データに近い条件で、性能や連携、帳票、障害復旧を確かめます。
稼働時は切戻しと安定化を管理します。定着の段階では、手順や教育を運用に組み込み、監視と改善も続けます。
最初の一歩は現行資産台帳と小さなPoC
最初は、現行環境の調査から始め、小規模な検証を経て、発注先への相談へ進みます。
- 版、OS、DBサイズ、言語、接続、バッチ、帳票、バックアップ、停止可能時間を一覧にし、不明点を明らかにする。
- 読み取り専用APIや接続確認のPoCで、性能、文字コード、データ整合性、運用手順を確かめる。
- 調査後、2〜3社へ同じ条件で相談し、費用とロードマップを比べる。
番号どおりに進めると、根拠のある費用と実現可能なロードマップを作りやすくなります。
▼全体ガイドの記事
・Informixのシステム開発の完全ガイド
▼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を創業。