Informixのシステムは、基幹業務、エッジ・IoT、Web・API連携の3つに分けて捉えると、既存の業務を活かしながら発展させる方法を決めやすくなります。
システムの種類から費用、会社選び、セキュリティまで、各テーマの詳細は下の関連記事一覧からご覧いただけます。
▼関連記事一覧
・Informixのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Informixのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Informixのシステム開発の見積相場や費用/コスト/値段について
・Informixのシステム開発の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Informixのシステムの全体像と特徴
Informixのシステムは、受発注や在庫、製造などを支える業務基盤です。店舗や物流、設備監視も、同じ基盤で動かすことがあります。画面やバッチ、帳票、外部連携だけでなく、バックアップや監視も含めて一つのシステムとして捉えます。
同じ基盤で扱える、リレーショナルデータと柔軟なデータ
Informixでは、構造化データを表形式で管理できます。SQLやインデックスに加え、トランザクションやストアドプロシージャも使えます。
- リレーショナルデータ：受注番号、商品、数量、金額などを管理します。
- 柔軟なデータ：JSONや時系列データも扱えます。
整合性が重視される基幹業務に向いています。さらに、センサー値や設備ログ、IoTデータを既存業務と結び付ける設計も可能です。
Informix 15.0では、大容量のチャンクやフラグメント、最大256KBのページ、外部Smart Large Objectなどが案内されています（出典: Informix 15.0公式ドキュメント、2026年確認）。
不可視インデックスや、実行中クエリの実行計画の確認も利用できます。新しい機能が加わったからといって、すぐに刷新が必要とは限りません。一方で、現行環境の制約を解消できる可能性があるため、更新の判断材料になります。
システム全体の価値を左右する古いアプリケーション資産
周辺のアプリケーションには、データベース本体以上に固有の知識が蓄積されていることがあります。
- アプリケーション：Informix-4GL、ESQL/C、古いVisual Basic、独自シェルスクリプト。
- 運用資産：夜間バッチ、帳票、文字コード変換。
本番の依存関係は、設計書だけでは把握しきれないことがあります。担当者の記憶や運用手順書にしかない処理もあるため、DBを新しいサーバーへ移すだけの見積もりには注意が必要です。
画面と表の関係、バッチの実行順、帳票や外部連携が参照するデータを一覧にします。そのうえで、保守継続、段階的なモダナイズ、別DB移行を比べます。
Informixを使ったシステムの種類
Informixのシステムは、業務の目的と更新の方法によって分けられます。種類を整理すると、既存資産を残すか、どこから改修するかを判断する材料になります。
受発注・在庫・製造などの基幹業務システム
受発注や在庫、製造などの業務を、一つのDBで管理します。販売、購買、会計連携も、同じDBで扱います。
取引を正しく保存し、在庫数や売上にすぐ反映させる必要があります。そのため、整合性と安定稼働が重視されます。店舗や倉庫が多い企業では、通信が一時的に不安定でも現場で処理を続け、後から中央へ同期する設計もあります。
設計では、画面に加えて業務ルールも整理します。対象は、商品や取引先のコード、在庫引当、締めや返品・取消などです。画面だけ新しくしても、効果は限定的になりがちです。そこで、データの正しさを守りながら、画面やAPIを段階的に更新します。
店舗・工場・設備に近いエッジやIoTのシステム
工場設備や店舗端末、計測機器、物流拠点の近くでデータを集め、一時的に保存します。現場側で集計や判定を行えば、通信遅延や一時的な回線断の影響を抑えられます。
時系列データを記録し、異常値や稼働率を後から分析する用途にも向いています。一方で、機器の数が増えると、バージョン管理や接続障害、時刻のずれが課題になります。
データの再送や現地作業も考慮し、現場の運用手順から遠隔監視、通信復旧後の再同期までを設計します。
既存Informixを残したWeb・API連携システム
既存のDBと業務処理を残したまま、Web・スマートフォン画面、外部連携、分析基盤を追加します。REST APIやJDBC、ODBCで接続すれば、古いアプリを一度に置き換えずに済みます。
クラウドサービス向けの公式コネクタは、Informixのデータの選択・追加・更新・削除に対応しています（出典: Informix connector公式ドキュメント、2026年確認）。
この方法は、全面刷新に比べて初期リスクを抑えやすい一方で、新旧の処理の責任範囲があいまいになりやすい点に注意が必要です。そのため、データの更新元、エラー時の再実行、API利用者ごとの権限を設計書に明記しておきます。
Informixのシステム開発・移行の進め方
開発・移行は、要件定義と現行分析から始めます。そのあとに方式を選び、PoCで検証してから、設計・実装、テスト、切替へ進みます。最後に、運用改善を行います。
- 保守継続：現在のInformixを維持する方式。
- クラウド移行：稼働基盤をクラウドへ移す方式。
- 別DB移行：他のデータベースへの置き換え。
- 段階的モダナイズ：既存資産を活かした順次更新。
どの方式が適するかは、業務停止のリスクと将来の保守性を比べて判断します。
要件定義と現行資産の先行洗い出し
Informixのバージョンや、OS、サーバー構成を確認します。DBのサイズや表の数、インデックス、文字コードも見ます。さらに、接続方式、同時接続数、ピーク時間帯も調べます。
- 環境：DBとサーバーの構成、接続・負荷状況の一覧。
- 業務資産：画面やバッチ、外部連携と運用機能の洗い出し。
- 非機能要件：停止、復旧、性能などの条件を定める。
画面や帳票、バッチ、外部連携などを、業務単位で一覧にします。洗い出しは、ソースコードに加えて、担当者への聞き取りと本番ログを使って進めます。見落としを防ぐため、バックアップや監視、障害対応も対象に含めます。
停止可能時間や、目標復旧時間のRTO、許容データ損失時間のRPOは、数値で決めておきます。性能目標や監査ログ、権限、保守時間も、数値にしておきます。
非機能要件を後から加えると、冗長化やバックアップの改修が増え、費用と期間が膨らみやすくなります。そのため、業務部門と運用部門を早い段階から参加させます。
保守継続・クラウド移行・別DB移行の比較
移行方式は、業務の状況や今後の運用方針に合わせて選びます。
- 保守継続：業務変更が少なく、現行の安定稼働を優先する場合。
- クラウド移行：古い機器・OSへの依存を減らし、バックアップや監視を見直す場合。
- 別DB移行：人材確保やライセンス方針を重視する場合。
別DB移行では、改修の範囲が広くなりやすい点に注意が必要です。SQLやデータ型、ストアド処理などに加え、帳票や周辺アプリも改修の対象になります。
2026年公開の事例では、UNIX系基盤からLinuxのクラウドへ移行しました。移行では、Informixの更新とEnterprise Replicationに加え、監視やバックアップ、切戻しも組み合わせています（出典: Informixのクラウド移行公開事例、2026年5月）。この事例のように、同期とリハーサルを含めた移行設計が重要です。
PoCと切替リハーサルによる本番停止リスクの抑制
PoCでは匿名化した実データを使い、主要SQLの速度や文字コードを確認します。日付やNULL、DECIMAL、BLOBの扱いも見ます。さらに、ロックやトランザクション、外部連携も確かめます。
別DB移行では、結果が一致するかだけでなく、端数処理や在庫引当、締め、取消まで業務シナリオで検証します。Web画面やAPIを追加する場合は、認証と権限を含む操作テストを行います。
本番切替は、手順書にまとめたうえで、順番どおりに進めます。
- 初期バックアップを取得して、差分同期を行う。
- 最終停止後にデータを照合し、アプリの接続先を変更する。
- 業務を確認したうえで監視を始め、切戻しを判断する。
切戻しの条件は、処理時間やエラー数、データ不一致数で決めます。停止時間なども含め、事前に基準をそろえておきます。リハーサルを複数回行い、担当者と確認時刻を記録しておくと、当日の判断が安定します。
Informixのシステム開発・移行費用の相場と内訳
Informixの費用は、ライセンス料に加えて、さまざまな作業の費用を合算して決まります。作業には、現行資産の解析や要件定義、アプリ改修が含まれます。データ移行や、サーバーやクラウドの基盤、バックアップや監視も対象です。
テストや教育、保守も、費用に含めて考えます。ここで示す金額は、Informix固有の定価ではありません。公開されている業務システムの見積傾向と移行事例を踏まえた、2026年時点の概算です。
環境や要件によって大きく変わるため、正式な見積もりの前に調査工程を設けます。
▶ 詳細はこちら：Informixのシステム開発の見積相場や費用/コスト/値段について
規模別の初期費用の幅（150万円から数億円まで）
対象業務が広がるほど、初期費用の帯も大きくなります。規模ごとの目安を、次の一覧に示します。
- 接続確認・小規模PoC：環境構築等を含み150万円未満の場合があります。
- 小規模Web画面・API追加：既存Informixを使い、150万〜500万円程度。
- 複数業務連携：500万〜1,500万円程度。
- クラウド化・モダナイズ：現行解析と移行を含み1,500万〜5,000万円程度。
- 大規模基幹刷新・別DB全面移行：5,000万円超で、複数年の計画になることもあります。
金額だけで安い提案を選ぶと、対象外のバッチや帳票が後から見つかり、追加費用が生じることがあります。
見積もりは、工程ごとに分けてもらいます。調査や設計、開発、移行のほか、テストや切替、教育、保守の費用も含めます。
ライセンス・基盤・保守費の内訳
費用は、ライセンス、基盤、保守の項目に分けて整理します。ライセンス費は、エディションやコア数、利用環境で変わります。開発・検証・本番の台数やサポート契約も、費用を左右します。
そのうえで、商用ライセンスの有無、既存契約の引継ぎ、クラウド利用条件を確認します。開発者向け無償版や評価環境が使える場合でも、本番利用の条件とは異なります。
そのため、契約条件を見積もりに明記してもらいます。
- ライセンス契約：本番利用の条件まで確認
- 運用基盤：必要な設備と機能の洗い出し
- 保守範囲：必要な支援内容を見積もりに含める
基盤費には、コンピュートやストレージ、バックアップ、監視が含まれます。さらに、通信や冗長化、災害対策も対象になります。保守費は、問い合わせ対応だけか、24時間監視や障害時の復旧支援まで含むかで変わります。
バージョンアップ、SQLチューニング、運用教育を含むかも確認します。年間保守費は、初期開発費の10〜20％程度が目安になることがあります。ただし、これはInformixの契約料金を示すものではありません。
Informixの開発会社・ベンダーの選び方
開発会社やベンダーは、業務理解、旧アプリ資産の解析、移行後の運用支援で選びます。新規開発と既存保守では必要な経験が異なり、クラウド移行や別DB変換では、また別の経験が求められます。そのため、得意領域を見極めます。
Informix本体と周辺資産の実績
提案依頼では「Informixの経験がありますか」と聞くだけで終わらせず、経験や設計力まで確かめます。
- 周辺資産：旧式アプリや帳票などの対応経験。
- クラウド移行：稼働基盤から運用までを含めた設計力。
- 別DB移行：変換後の改修と検証の経験。
Informix-4GLやESQL/Cの経験を見るとともに、独自バッチや文字コードの扱いも確認します。
現行解析の成果物として、アプリと表の対応表やバッチの依存関係を出せるかも見ます。移行対象外の一覧や障害時の復旧手順も、同じように確認します。
クラウド移行では、仮想サーバーの用意だけでなく、OS変更やストレージ性能まで設計できるかを確認します。共有メモリやCPU割当、ログ、監視、バックアップも、設計の対象になります。
別DB移行では、変換率だけでなく、手修正が必要なSQLや再設計機能を聞きます。データの照合方法や並行稼働の期間も、あわせて確認します。
提案書の体制・成果物・リスクの書き方による比較
提案書には、担当者の役割とInformix担当者の稼働率を書いてもらいます。業務部門との打ち合わせ回数やレビュー方法も、記載の対象です。品質管理や障害時の連絡体制も、比べる材料になります。
合計価格だけでなく、何人月で何を作るか、前提条件と対象外作業をそろえると提案を比べられます。作ってもらう資料には、現行調査報告書や要件定義書、基本設計書があります。DB定義や移行マッピング、テスト計画なども含まれます。
切替・運用手順書や教育資料も確認します。ソースコードや設定ファイルの納品範囲、著作権・利用権は、先に決めておきます。第三者ツールのライセンスや、契約終了後の引継ぎ条件も、同じ時期に詰めます。
質問による失敗リスクの事前確認
選定の段階では、障害や情報不足が起きた場合の対応を具体的に質問します。
回答が抽象的な場合は、過去の納品資料を匿名化して示せるか、調査工程を契約に含められるかを尋ねます。また、テストデータが足りない場合は、検証方法を開発会社に確認しておきます。
2〜3社程度に絞ったら、同じRFPと前提で比べます。そのうえで、停止を抑える設計や、自社で運用を続けられるかを評価します。障害支援や人材確保も見ると、長期的な総コストを抑えやすくなります。
- 担当者の退職：引継ぎの方法を確かめる
- ソース不足：調査の進め方
- テストデータ不足：検証の進め方
- 仕様変更・切替失敗：追加費用と復旧時間
▶ 詳細はこちら：Informixのシステム開発でおすすめの開発会社/ベンダー6選と選び方
▶ 詳細はこちら：Informixのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
▶ 詳細はこちら：Informixのシステム開発の発注/外注/依頼/委託方法について
Informixのセキュリティと運用の確認事項
安全性は、DBだけでなくシステム全体で決まります。OSやクライアントSDK、JDBCといった接続部分も含まれます。
REST接続やコンテナ、ネットワーク、運用アカウントも、確認の対象です。個人情報や取引情報を扱う場合は、最小権限と暗号化、監査ログを要件に含めます。バックアップ保護や委託先の管理も、要件に加えます。
DB本体と同梱コンポーネントの同時更新
2025年7月、Informix同梱Javaの脆弱性に対し、対象バージョンの更新を案内する速報が公開されました（出典: Informix製品のセキュリティ速報、2025年7月28日）。そのため、DBサーバーの確認に加えて、周辺の部品も確認する必要があります。
- 資産管理：Java、JDBC、CSDK、REST接続、OS、コンテナを台帳にまとめる。
- 更新確認：パッチ適用の前後に接続テストを行う。
- 互換性確認：ドライバーやアプリの再コンパイル要否、認証方式、暗号スイート、バックアップ形式、SQL互換性を確認。
適用と切戻しの手順を検証してから、本番に反映します。
RESTやAPIの認証・権限・TLS・監査をセットにした設計
REST APIを加えると、既存画面以外からもデータへアクセスできるようになります。認証や権限、TLS、監査をまとめて設計します。
- アクセス管理：未認証の参照や過剰な更新権限を防ぎます。
- 通信・監査：TLSで保護し、操作を記録します。
- 本番設定：CSRF対策、セッション、接続プール、タイムアウト。
- データ保護：二重登録や途中失敗時の再実行、個人情報の返却、ログの機密情報を管理します。
本番設定の項目は、公式ドキュメントでも案内されています（出典: Informix REST接続公式ドキュメント、2026年確認）。
利用者・画面・バッチごとに権限を分けると、一つの誤りが全体に広がるのを防げます。運用中も、資産の洗い出しと脆弱性情報の確認を定期的に行います。
バックアップ・監視・復旧訓練の運用設計
バックアップは、取得するだけでなく、復元後に業務を再開できるか、必要なログもそろうかを定期的に確かめます。データ量や取得時間、保存世代は、事前に定めておきます。暗号化や別拠点での保管、復旧順位も、あわせて決めます。
少なくとも年に1回の復旧訓練を計画します。監視では、CPUやメモリに加えて、I/Oや共有メモリを確認します。論理ログやチェックポイント時間も、見ておきたい項目です。
長時間トランザクションやレプリケーション遅延、バックアップ状態、接続数も監視します。通知を受けた担当者が見るログや切り分けの順番、開発会社やベンダーへの連絡条件を、運用手順書に記しておきます。
Informixのシステムに関するよくある質問
Informixについては、「古いからすぐ移行すべきか」「クラウドなら安くなるか」「対応できる人材がいない場合はどうするか」といった質問がよく寄せられます。判断を急がず、確認点に簡潔に答えます。
Informixは古いシステムなので、すぐに別のデータベースへ移行すべきですか？
すぐに移行する必要があるとは限りません。まずは、業務の安定性や保守人材、ライセンスを見ます。OSや機器のサポート期限、将来の連携要件も洗い出します。
保守継続、段階的な更新、別DB移行を比べて判断します。
Informixをクラウドへ移行すると費用は必ず安くなりますか？
必ず安くなるわけではありません。古い機器や専門保守を減らせる可能性はありますが、クラウド費用を含めた総額で比べます。
計算資源やストレージ、バックアップ、監視の費用を合算します。さらに、冗長化や通信、ライセンス、移行費用も含めて、現行の運用費と比べます。
Informixに詳しい開発会社やベンダーを選ぶには何を見ればよいですか？
Informix本体に加えて、4GLやESQL/Cなどの周辺資産の経験を確認します。データ移行やSQL調整の経験も見ます。さらに、クラウドやバックアップ、業務テスト、運用引継ぎの経験も確かめます。
現行解析の結果や対応範囲、移行対象外を提案書に記載してもらいます。切戻し条件や担当者体制も書いてもらい、同じ前提で複数社を比べます。
Informixのシステム開発・移行で失敗しないためのまとめ
Informixは、長年の業務知識とデータを支える基盤です。全面刷新を急がず、まずは依存関係やデータ量、停止可能時間を把握します。接続方式や人材に加え、ライセンスや監査要件も確認します。
判断の基本は、洗い出し・比較・検証の順
現行資産と業務上の制約を一覧にし、複数の移行ルートを比べます。そのうえでPoCとリハーサルで検証します。技術面だけでなく、業務停止や運用負荷も判断できます。
最初の一歩となる現行システムの調査依頼
全面刷新を前提とせず、まずは現行調査から始めます。そのうえで、調査結果を実行可能な計画に落とし込みます。
- 現行調査：課題や移行候補、概算費用、リスク、次のPoCの整理。
- 方式比較とPoC：保守・Web/API化・クラウド・別DB・最新機能を比べ、性能と整合性を確認します。
- 本番移行と確認：バックアップ、同期、リハーサル、切戻しを計画し、業務テストと復旧訓練で確かめる。AIや自動変換を使う場合も、人手の確認が欠かせません。
- 費用：接続確認から大規模刷新まで幅があるため、ライセンス、開発、移行、基盤、保守を分けて見積もります。
- 会社選び：Informix知識に加え、周辺解析、要件整理、移行後運用まで一貫支援できるか見ます。
▼関連記事一覧
・Informixのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Informixのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Informixのシステム開発の見積相場や費用/コスト/値段について
・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を創業。