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

Informixのシステム開発は、既存のデータベースと業務資産を把握し、要件整理から定着までを段階的に進めることが成功の近道です。古い4GLやESQL/Cの資産を抱えていても、いきなり全面刷新するのではなく、業務停止時間、データ連携、保守人材、将来のクラウド化を基準に進め方を選べます。

本記事では、Informixのシステム開発・移行・Web/API化を検討する担当者に向けて、要件整理、ベンダー選定、設計開発、テスト、稼働、定着の6フェーズを実務の順番で解説します。2026年時点の製品動向、概算費用、見積書で確認すべき項目、発注先へ聞く質問まで整理するため、自社が保守継続・クラウド移行・他DBへのリプレースのどれに向くか判断しやすくなります。

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

Informixのシステム開発の全体像

Informixは、リレーショナルデータ、JSON、時系列データを扱え、高可用性や組み込み用途にも対応しやすいデータベースです。受発注、在庫、製造、店舗、設備監視など、止めにくい業務を長年支えてきた実績がある一方、データベースの周辺に古い画面、バッチ、帳票、運用スクリプトが積み重なりやすい製品でもあります。

Informixは、短時間に大量のトランザクションを処理し、長時間連続稼働させたい業務に向いています。IBMの製品情報では、SQLによるリレーショナル処理に加えて、NoSQL/JSON、時系列データ、高可用性、組み込み用途、リアルタイム分析などが特徴として示されています（出典: IBM Informix製品情報、2026年確認）。たとえば店舗端末から売上を受け取りながら、在庫を更新し、夜間に集計するような構成では、既存資産を活かせることが大きな利点になります。

一方で、Informixを使っていることだけでシステムの継続が決まるわけではありません。現行のバージョン、OS、CSDK、JDBCやODBCのドライバー、アプリケーション言語、保守契約を合わせて確認する必要があります。Informix-4GLやESQL/Cのソースが残っていても、コンパイル環境や担当者が失われていれば、データベース単体を維持するだけでは業務リスクを下げられません。

HCL Informix 15.0では、容量拡張、実行中クエリのプラン取得、クラウドへのバックアップ強化、Helm ChartによるKubernetesへのデプロイなどが案内されています。15.0.1系ではライセンス方式、JDBCの配布方法、AIエージェント連携、wire listenerの認証初期値などにも変更があります（出典: HCL Informix 15.0公式ドキュメント、2026年確認）。現行環境から更新する場合は、サーバーだけでなくCSDK、JDBC、監視ツール、コンテナ、OSを組み合わせた互換性検証が必要です。

クラウド化も選択肢になりますが、クラウドへ移せば自動的に安くなるわけではありません。仮想マシンのサイズ、ストレージの性能、バックアップ世代、監視、冗長構成、ライセンス、通信費をまとめて比較する必要があります。まずは現行資産を残したままクラウドへ移すリフトまたはリホスト、次に監視やバックアップを改善するモダナイズ、その後に必要な範囲だけアプリを刷新する順番が現実的です。

Informixのシステム開発の進め方

Informixのシステム開発は、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズに分けると、抜け漏れを管理しやすくなります。特に重要なのは、設計前に現行システムの実態を調べることと、稼働前に切戻し条件を決めることです。古い業務システムでは、仕様書にない夜間バッチや手作業が本番運用を支えていることがあるためです。

最初に作る資料は、新機能の一覧ではなく現行資産台帳です。Informixのバージョン、稼働OS、サーバー構成、データベース数、DBサイズ、表とインデックス、接続元、4GL・ESQL/C・Visual Basicなどのソース、帳票、バッチ、外部連携、バックアップ、監視、障害履歴を一つの表にまとめます。担当者へのヒアリングだけでなく、ソースコードの参照、ジョブ定義、ログ、バックアップ復元の実測まで行うことがポイントです。

次に、業務要件と非機能要件を数値化します。受注から出荷まで許容できる処理時間、同時接続数、月末や繁忙期のピーク件数、停止可能時間、目標復旧時間であるRTO、許容できるデータ損失時間であるRPOを決めます。個人情報や会計データを扱う場合は、権限、操作ログ、バックアップ暗号化、委託先管理、法令・監査の要件もこの段階に入れます。非機能要件を後付けすると、HA構成や監視の追加で設計をやり直しやすくなります。

要件整理の完了条件は、業務フロー図、現行構成図、データ連携一覧、移行対象一覧、課題一覧、優先順位、受入基準がそろっていることです。「画面を新しくしたい」という要望も、対象業務、利用者、入力項目、承認、帳票、連携先、エラー時の扱いまで具体化します。ここで対象外の機能を明記しておくと、後工程での追加要望と本来の要件を分けて管理できます。

選定では、保守継続、リホスト、モダナイズ、他DBへのリプレースを同じ評価軸で比べます。保守継続は変更が少なく停止リスクを抑えやすい一方、担当者不足や古いOSが残りやすい選択肢です。リホストは既存アプリを活かして移行期間を短くしやすく、モダナイズは監視・バックアップ・API化を改善できます。リプレースは将来の人材確保に有利なことがありますが、SQL方言、文字コード、日付、NULL、帳票、業務ルールの再検証が大きくなります。

判断では、技術の新しさよりも、業務停止リスクと保守可能性を優先します。たとえば停止可能時間が短く、現行アプリが安定しているなら、最初にInformixを維持してOSや基盤だけを更新し、API化を小さく始める方法が適しています。反対に、サポート期限、専用ハードウェア、保守人材の退職、監査要件が重なっているなら、他DB移行を含む複数年計画を作ります。

発注先の選定では、「Informixの経験があります」という説明だけで決めないことが重要です。現行解析、旧言語の読み解き、SQLチューニング、データ移行、クラウド基盤、業務テスト、切替、運用引き継ぎのどこまで担当できるかを確認します。提案書には、成果物、担当体制、前提条件、対象外、再委託先、障害対応、保守時間、追加費用の条件を具体的に書いてもらいます。

設計では、画面や機能より先にデータと接続の境界を決めます。既存のリレーショナル表をそのまま利用するのか、新しい表やJSON領域を追加するのか、時系列データを専用の構造で持つのかを判断します。Informixを残して新しいWeb画面やAPIを追加する場合は、JDBC、ODBC、.NET、RESTなどの接続方式、認証、タイムアウト、トランザクション境界、エラーコードを仕様化します。

また、既存の4GLやESQL/Cを一度に書き換える必要はありません。読み取り専用API、在庫照会、帳票出力、マスタ管理など影響範囲の小さい機能から分離し、業務の流れを止めずに新しい画面を追加できます。ただし、古いSQLと新しいアプリが同じデータを更新する場合は、ロック、分離レベル、採番、排他、文字コードの扱いを確認します。設計書には、誰がどの表をどのタイミングで更新するかを残します。

基盤設計では、CPUやメモリだけでなく、dbspace、ストレージI/O、バックアップ、監視、障害時の切替、復旧手順まで決めます。HAやEnterprise Replicationを使う場合も、構成を作るだけでは不十分です。主系障害を検知して切り替わる時間、アプリが再接続する方法、復旧後のデータ整合性、切戻しの判断者をテスト計画に落とし込みます。

テストは、単体テスト、結合テスト、性能テスト、障害・復旧テスト、業務受入テストに分けます。Informixでは、SQLが実行できるかだけでなく、既存データの件数、日付、DECIMAL、NULL、長い文字列、BLOB、文字コード、インデックス、ロック待ちを確認する必要があります。開発者が用意した少量のきれいなデータだけでは、本番の月末処理や例外データを再現できません。

移行を伴う場合は、匿名化した本番相当データでリハーサルを行います。移行前後のレコード件数、金額合計、在庫数量、日次残高、マスタの紐付けを照合し、差異が出た場合の調査方法を決めます。画面確認だけでなく、夜間バッチ、外部連携、帳票、締め処理、再実行、エラー時の手動運用まで業務担当者に確認してもらいます。

クラウド移行では、最初の同期だけでなく、切替直前の差分データ、停止時間、バックアップからの復元、監視通知、権限、ネットワーク経路を確認します。DataArtのInformixを含むAWS移行事例でも、既存構成の自動探索、Informix固有ツール、バックアップと復元の自動化、監視、下位環境での検証を組み合わせています（出典: DataArt「Migration Project to Facilitate Datacenter Exit for Trader Interactive」、2026年確認）。この事例からも、サーバーを移す作業と本番運用を検証する作業は分けて計画する必要があります。

稼働方式は、一斉切替、段階切替、並行稼働のどれかを業務単位で選びます。一斉切替は短期間で完了しやすい一方、問題が出たときの影響範囲が広くなります。段階切替はリスクを分けられますが、旧環境と新環境の二重運用が発生します。並行稼働は照合の精度を上げやすいものの、入力ルールやデータ同期をそろえる運用負荷が大きくなります。

本番切替計画には、作業開始条件、バックアップ取得、最終データ移行、業務確認、利用者への連絡、監視開始、判定会議、切戻し期限を記載します。「問題があれば戻す」という表現ではなく、エラー件数、処理時間、データ差異、連携未達、問い合わせ数などの基準を決めます。切戻しが可能な時間帯と、切戻し後に失われる入力の扱いも事前に合意します。

稼働直後の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日）。環境移行の成果は、稼働した瞬間ではなく、運用担当者が状況を把握できる状態まで含めて評価します。

定着フェーズでは、システムを納品して終わりにしません。運用担当者向けに、起動停止、バックアップ確認、障害一次切り分け、ログ確認、権限申請、復旧、ベンダーへの連絡手順を整備します。開発会社しか復旧できない状態は、担当者の退職や契約終了で再び属人化するためです。手順書は画面キャプチャだけでなく、判断条件と実行結果を残します。

利用者向けには、業務変更点を役割別に伝えます。新しい画面の操作説明だけでなく、入力ルール、エラー時の連絡先、締め処理、検索できる過去データの範囲を説明します。稼働後の問い合わせを分類し、操作教育で解決するもの、仕様変更が必要なもの、データや性能の問題を分けると、改善の優先順位を付けやすくなります。

月次または四半期ごとに、障害件数、処理時間、バックアップ成功率、問い合わせ、手作業時間、利用率を振り返ります。HCL Informix 15.0の機能を活用する場合も、AI連携やKubernetes化を目的にするのではなく、復旧時間、運用負荷、監視精度など業務上の指標で効果を測ります。改善テーマは小さく検証し、業務影響を確認してから本番へ広げます。

Informixのシステム開発にかかる費用相場

Informixのシステム開発費用は、データベースのライセンスだけでなく、現行解析、アプリ改修、データ移行、基盤、テスト、教育、保守で決まります。商用ライセンスはエディション、コア数、環境、サポート契約によって変わり、公開価格だけで一律に比較できません。以下は業務システム全般の相場とInformixの移行論点を組み合わせた概算であり、Informix固有の確定価格ではありません。

開発者版などの利用条件を確認したうえで、接続確認や小規模PoCだけを行う場合は、環境構築、接続、性能確認を含めて0万〜100万円程度が一つの目安です。既存Informixを使った小規模なWeb画面やAPI化は150万〜500万円程度、中小企業の受発注・在庫などを連携する開発は500万〜1,500万円程度が概算レンジになります。いずれも画面数、外部連携、認証、帳票、テスト範囲によって変わります。

4GLや旧VBを残した段階的なモダナイズ、またはクラウド移行を伴う場合は、現行解析、移行設計、アプリ改修、HAやレプリケーション、バックアップ、監視、教育を含めて1,500万〜5,000万円程度が目安になります。大規模基幹システムの刷新や他DB移行では、5,000万円〜数億円のレンジになることもあります。これらはNotebookLM「業務システム全般」Q&A（2026年確認）で示された業務システム相場を基にした推定であり、Informix固有の確定価格ではないため、実際には要件定義後の見積もりが必要です。

見積もりの工数を左右するのは、DBサイズだけではありません。表やインデックスの数、SQLの複雑さ、旧言語のソース量、バッチ本数、帳票、外部連携、文字コード、データ品質、同時接続数、性能要件、テストデータの準備状況が影響します。特に仕様書にない手作業や夜間処理を見落とすと、開発後半に追加費用が発生しやすくなります。

ランニングコストには、商用ライセンスとサポート、クラウドの仮想マシン、ストレージ、バックアップ、監視、通信、OS、証明書、セキュリティ対応、保守契約が含まれます。一般的な業務システムでは年間保守を初期開発費の10〜20%程度と見ることがありますが、24時間監視、障害時の駆け付け、バージョンアップ、移行支援を含むかで変動します。たとえば初期費用1,000万円の場合も、年間100万〜200万円と断定せず、契約範囲を分けて確認します。

費用を抑えるには、最初のリリース対象を在庫照会やマスタ管理などに絞り、読み取り専用APIから始める方法があります。一方で、ライセンス、停止できない時間帯、データ量、同時接続数、HA・DR、バックアップ世代、教育を後から追加すると、安い初期見積もりが大きく膨らみます。初期費用だけでなく、3年間の総保有コストで比較することが重要です。

Informixの見積もりを取る際のポイント

Informixの見積もりは、総額だけでなく、何を調べ、何を作り、何を検証し、どこまで運用を支援する金額なのかを分解して確認します。現行調査が含まれないまま開発費だけを比較すると、提案会社ごとの前提が違うため、安さの理由を判断できません。RFPや相談資料には、現行環境、対象業務、目標、制約、期限、成果物、受入基準を記載します。

依頼前に、Informixのバージョンとエディション、稼働OS、サーバー台数、DBサイズ、増加量、同時接続数、ピーク時間、バックアップ方式、RTO・RPO、接続方式、アプリ言語、ソースコードの有無を整理します。すべて分からなくても、分からない項目を明記することが大切です。ベンダーが調査して確定する項目と、発注者が決める項目を分ければ、見積もりの不確実性を管理できます。

業務面では、対象ユーザー、処理件数、締め処理、帳票、承認、外部システム、手作業、過去データの保存期間を整理します。移行なら、移行対象期間、削除・アーカイブ方針、旧環境の保管、切替後の照合方法を決めます。クラウド化なら、リージョン、ネットワーク、バックアップ保管先、監視、障害通知、運用時間、セキュリティ審査も前提に含めます。

比較する会社には、同じ現行資料と同じ質問を渡します。比較項目は、Informixの対応バージョン、旧言語の解析力、DB移行方式、クラウド基盤、性能検証、HA・DR、セキュリティ、テスト、切替、教育、保守の12項目です。各項目について、経験の有無だけでなく、担当者の役割、成果物、実施時期、前提条件、追加費用の発生条件まで確認します。

提案の技術選択が自社の課題に合っているかも見ます。HCL Informix 15.0のHelm Chartを提案された場合は、Kubernetesの運用体制、対応バージョン、永続ストレージ、バックアップ、障害時の復旧を確認します。AIエージェント連携を提案された場合は、対象業務、入力データの範囲、権限、監査、誤操作時の人手確認を明確にします。新機能を使うこと自体を目的にせず、業務上の効果と運用責任を評価します。

見積もりには、「現行資料にないバッチが見つかった場合」「データ不整合が一定件数を超えた場合」「性能要件を満たさない場合」「サポート対象外のOSやドライバーが判明した場合」の扱いを明記してもらいます。追加作業が必要になる条件、単価、承認方法、納期への影響を契約前に確認します。安い一式見積もりでも、調査や受入テストが別料金なら、総額で比較する必要があります。

セキュリティでは、DB本体だけでなく、JDBCやJava、REST listener、OS、コンテナ、監視ツールも対象にします。REST APIを本番利用するなら、TLS、認証、権限、CSRF対策、監査ログ、ネットワーク制限、秘密情報の保管を要件に入れます。パッチ適用の責任分界、脆弱性発生時の連絡時間、バックアップの暗号化、復元テストの頻度も、見積もりと保守契約の両方に書いてもらいます。

発注前には、最終的な切替判断を誰が行うか、業務側の受入責任者は誰か、データ差異をどの基準で許容するかを合意します。Informixの移行は技術担当だけで完了せず、現場の業務知識が必要です。現行担当者、情報システム部門、開発会社、インフラ担当、セキュリティ担当の役割をRACIなどで整理すると、問題が起きたときの判断遅れを防げます。

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

Informixの開発では、既存資産をどこまで残すか、クラウドへ移せるか、古いバージョンを更新すべきかという質問が多くあります。ここでは、発注や社内稟議の前に確認したい代表的な疑問へ、判断の軸を直接回答します。

Informixのシステムはクラウドへ移行できますが、移行方式は現行OS、Informixのバージョン、ライセンス、アプリの接続方式、停止可能時間によって決まります。まずは既存環境を仮想マシンへ移すリホストを検討し、その後に監視、バックアップ、冗長化、API化を改善する段階移行が、停止リスクを抑えやすい方法です。

小規模な接続確認やPoCは0万〜100万円程度、既存Informixを使った小規模Web/API化は150万〜500万円程度が概算の目安です。中小企業の業務連携は500万〜1,500万円程度、旧資産のモダナイズやクラウド移行は1,500万〜5,000万円程度を見込むことがありますが、Informix固有の一律価格ではありません。DBサイズよりも、旧言語、連携、帳票、データ品質、テスト、切替、保守の範囲で大きく変わるため、調査費と開発費を分けた見積もりを依頼します。

Informixの経験年数だけでなく、現行資産の解析、4GL・ESQL/Cの保守、SQLチューニング、データ移行、クラウド基盤、業務テスト、切替、運用教育まで一貫して対応できるかを確認します。提案書に成果物、担当者、対応バージョン、対象外、追加費用、障害時の体制を書いてもらい、同じRFPで2〜3社を比べると判断しやすくなります。公開事例が自社と同じ業界でなくても、技術課題と運用課題が似ているかを確認します。

まとめ

Informixのシステム開発は、最新技術へ一気に置き換えることが目的ではありません。現行資産と業務の実態を調べ、保守継続、クラウド移行、モダナイズ、他DBへのリプレースを、停止リスク、費用、保守人材、将来性で比較することが出発点です。

要件整理では現行資産、業務フロー、非機能要件を数値化し、選定では保守継続・リホスト・モダナイズ・リプレースを比べます。設計開発ではデータ、接続、権限、バックアップ、復旧を仕様化し、テストでは実データに近い条件で性能、連携、帳票、障害復旧を確認します。稼働では切戻し条件と安定化期間を管理し、定着では手順書、教育、監視、改善を運用に組み込みます。

まずはInformixのバージョン、OS、DBサイズ、アプリ言語、接続方式、バッチ、帳票、バックアップ、停止可能時間を一覧化し、分からない項目を明らかにします。そのうえで、読み取り専用APIや接続確認など影響範囲の小さいPoCを実施し、性能、文字コード、データ整合性、運用手順を確認します。調査結果をもとに2〜3社へ同じ条件で相談すれば、根拠のある費用と実現可能なロードマップを作りやすくなります。

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

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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