オフコンのクラウド化とは？富士通2031年3月の提供終了と移行方式の選び方

オフコンのクラウド化は、長らく「保守切れを避けながら既存の業務プログラムを延命する手段」として扱われてきました。その前提が変わっています。富士通グループのオフコン基盤サービス「Cloud Service for オフコン」は2026年3月31日に販売を終え、2031年3月31日でサービス提供そのものが終わります。つまり、クラウドへ逃がすという選択肢の側に期限が付きました。この記事では、ベンダー別に残された時間を一次情報の日付で押さえたうえで、リホスト・リライト・リビルド・リプレースのどれを選ぶかを、判断できる形まで落とし込みます。

まとめ

オフコンのクラウド化には、ベンダーのデータセンターへ環境ごと預ける「そのまま型」と、業務をクラウドサービスへ載せ替える「作り替え型」の2つがあります。前者の代表であるCloud Service for オフコンは2031年3月31日で提供が終わるため、いま「そのまま型」を選んでも猶予は数年です。NECのExpress5800/600シリーズは保守用部品保有期限が2020年3月末で満了、富士通のPRIMERGY 6000系も最終出荷製品の保守終了が2023年3月と、この2系統では自社設置ハードウェアの延命策がすでに尽きています。

一方で、経済産業省の総括レポートは、古い技術で構築されたシステムでも体制と仕様が整っていればレガシーではない、という立場を取っています。期限だけを理由に慌てて捨てる必要はありません。ただし2031年3月という外部から与えられた期日のほうは動かせない。IT資産の可視化と方式選定を先に済ませ、逆算した工程に載せることが実務の要点になります。以下、ベンダー別の残り時間、方式4種の選び分け、クラウド化しても残る課題の順に見ていきます。

オフコンのクラウド化が指す2つの意味

オフコン（オフィスコンピュータ）は、中小企業の受発注・在庫・会計といった基幹業務を1台でこなす専用機として普及した系統です。富士通のKシリーズからPRIMERGY 6000（OS：ASP）、NECのExpress5800/600シリーズ（OS：A-VX）、IBMのAS/400から続くIBM iが代表的な系譜にあたります。業務パッケージを部門単位でカスタマイズしながら育てる使われ方をしてきたため、その蓄積がいま移行の重さを決めています。

そして「オフコンのクラウド化」という言葉が指す内容は、性質の異なる2つに分かれます。ここを混同したまま見積もりを取ると、費用も期間も桁が変わります。

ベンダーのデータセンターへ環境ごと預ける「そのまま型」

エフサステクノロジーズはCloud Service for オフコンを「お客様のオフコンシステム環境をデータセンターで運用」するサービスと説明しています。自社の機械室からハードウェアが消え、専用OSと業務プログラムはそのまま動き続けます。プログラムの改修が不要なため、保守部品の枯渇や機械室の空調・電源といった物理面の問題だけを切り離せるのが特徴です。

ただし、これは汎用のIaaSへサーバーを載せ替える一般的なクラウド移行とは前提が違います。富士通のASPやNECのA-VXといった専用OSに対応するのは、ベンダー自身が用意した基盤です。そのためベンダーがサービスを畳むと決めれば、その基盤に留まる選択肢のほうが消えます。実際にCloud Service for オフコンは2026年3月31日で新規販売が終わりました。なお、IBM iについては事情が異なり、IBM Cloudのドキュメントは、IBMデータセンター内のPower機で稼働するPower Virtual ServerがRHEL・IBM i・AIXに対応すると記載しています。同じ「オフコン」でも系統によって移行先の選択肢が違う点は押さえておいてください。

業務をクラウドサービスへ載せ替える「作り替え型」

もう一方は、オフコン上の業務そのものをクラウド上の別の形へ移すやり方です。プログラムを新しい言語へ変換する、業務要件から作り直す、パッケージやSaaS型ERPへ置き換える、といった方式が含まれます。専用OSへの依存が切れるため期限に縛られなくなる代わりに、現行機能の保証と業務側の合意形成という負荷が発生します。

経済産業省が2025年5月28日に公表した「DXの現在地とレガシーシステム脱却に向けて レガシーシステムモダン化委員会総括レポート」は、企業規模とシステム化の度合いで自社の位置を診断する図の中で、「オフコンを早期に導入」し「業務パッケージをカスタマイズして運用中」の企業に対し「オフコン業務を段階的に廃止、クラウドサービスに順次移行」という方向性を示しました。一括の切り替えではなく段階的な廃止を前提に置いている点が、実務的な示唆です。方式ごとの定義の違いはマイグレーションとは？リプレイス・モダナイゼーションとの違いと発注判断を解説で整理しています。

ベンダー別に見たオフコンの残り時間

移行方式を議論する前に、自社が使っている系統の期日を確定させてください。オフコンの期限は製品単位ではなく、ハードウェアの保守、専用OSの保守、クラウドサービスの提供期間がそれぞれ別に進みます。主要ベンダーの公表値は次のとおりです（状態は2026年8月時点）。

「インフラ系3サービス」はオフコンインフラ基本サービス、同拡張サービス、同VPNアダプターレンタルサービスを指します。表の日付は各社の公表資料の記載どおりですが、それぞれ意味する範囲が異なるため、次の3点は個別に読み解く必要があります。

富士通グループ：2031年3月31日でサービス提供中止

エフサステクノロジーズは「サービス提供終了までのご案内」で、富士通グループがオフコンのモダナイゼーションを2031年3月末までに完了するよう推進すると述べ、それに伴ってオフコンサービスと関連製品の提供を終了すると告知しました。対象はサービスとソフトウェアの両方にわたります。インフラ系3サービスが販売中止2026年3月31日／サービス提供中止2031年3月31日。専用OSのASPをはじめPowerRW+、PowerReplication V4.0、リモート表示ファイルサービス V5.1、PowerRDBconnector V3.0/V3.1（適用OS：Windows）、PowerRDBconnector（適用OS：Solaris）が販売中止2026年3月31日／保守中止2031年3月31日です。Kシリーズ端末エミュレータ V7.2と、同 LBPサポート V7.2、同 FAXサポート V7.2 だけは販売中止が2030年3月31日と後ろ倒しになっています。PowerRDBconnector V3.2（適用OS：Windows）は時期未定と記載されており、この製品を使っている場合は個別に確認してください。

受け皿として、富士通は2025年3月21日のプレスリリースでオフコン資産のモダナイゼーションサービスを体系化し、モダナイゼーションマイスターによる専門家アドバイザリーサービスを2025年4月から、資産分析・可視化サービス for アプリケーション資産と設計書リバースサービス for アプリケーション資産を2025年度第1四半期中に提供すると発表しました。オフコンを1984年から40年以上提供してきた同社が移行支援へ舵を切った以上、既存環境の延命を前提にした交渉は成立しないと考えるのが実際的でしょう。

NEC：保守用部品保有期限は2020年3月末で満了済み

NECのExpress5800/600シリーズは、最終受注可能日が2015年1月30日、出荷停止日が2015年3月31日、保守用部品保有期限が2020年3月末とNECの公表資料に記載されています。最終モデルはN8610-1031からN8610-1038（Express5800/V608-LからV628-H）です。部品の保有期限を過ぎているため、故障時に純正部品で復旧できる保証はすでにありません。

A-VX資産をこの状態で動かし続けている場合、それは故障が復旧不能な障害に直結する構成を受け入れているということでもあります。基幹システムの停止が受注や出荷を止めた実例は基幹システム刷新の失敗事例と回避策｜出荷停止と訴訟に至った5件を工程別に分解にまとめました。

IBM i：OS版と筐体で別々に進む期限

AS/400を源流とするIBM iは、他の2系統と事情が異なります。IBMのサポート終了告知はマシンタイプ単位で出るため、製品名や機種の通称だけでは期日が確定しません。同じ「S924」という名前でも機種タイプによって終了日が違い、OSのバージョンごとの期限もそれとは別に進みます。この系統を使っている場合は、AS/400（IBM i）サポート終了はいつ？移行の判断基準と方式の選び方で版と機種の対応を確認してください。

移行方式4種の選び分け

期日が確定したら、次は方式です。オフコンからの移行は、既存プログラムをどこまで残すかによって4つに整理できます。どれが優れているという話ではなく、資産の量・ドキュメントの有無・業務側の変更許容度で決まります。

リホスト：期限を延ばす目的に限った選択

プログラムに手を入れず、実行環境だけを移す方式です。Cloud Service for オフコンのようなベンダー基盤への移行や、オープン系サーバー上でオフコンの実行環境を再現する製品を使う移行がここに入ります。改修が不要なため最短で移れる反面、ブラックボックス化した資産はそのまま持ち越すことになる。2031年3月という期限が見えている現在、この方式は「本命の移行を設計する時間を買う」目的でのみ成立します。それ以外の目的で選ぶと、数年後に同じ判断をやり直すはめになります。

リライト：資産量が多い場合の現実解

変換ツールでソースコードを新しい言語へ機械的に置き換える方式です。数千本規模のプログラムを抱え、業務仕様のドキュメントが残っていない場合、要件定義から作り直すより現実的な着地点になります。富士通が2025年3月21日のプレスリリースで体系化したメニューにも「NetCOBOL資産移行・技術支援サービス」が含まれており、ベンダー側の標準的な受け皿として整備されている方式です。ただし変換後のコードは元の構造を引きずるため、可読性や保守性は自動的には改善しません。COBOL資産の扱いについてはCOBOLはなぜ廃れたと言われるのか？「オワコン」説の真相と、いまも使われ続ける理由で背景を解説しています。

リビルド：業務ごと作り直す長期案件

業務プロセスを見直し、要件を定義し直してシステムを新規開発する方式です。長年のカスタマイズで誰も全体像を把握していない状態を根本から解消するには、もっとも確実な手段になります。ただし要件定義だけで年単位を要することも珍しくありません。なお、資産の把握という目的だけであれば、富士通の設計書リバースサービス for アプリケーション資産のように既存資産から設計書を生成するメニューもあり、作り直しが唯一の道ではありません。工程ごとの考え方はモダナイゼーションとは？レガシー刷新の手法と実装アプローチ・進め方を解説で扱っています。

リプレース：パッケージ・SaaS型ERPへの置き換え

自社開発の資産を手放し、業務パッケージやSaaS型ERPの標準機能に業務を合わせる方式です。富士通が2025年3月21日のプレスリリースで「Fit to Standard」（標準機能に業務を合わせるアプローチ）を掲げているとおり、ベンダー各社が推す方向でもあります。構築期間とその後の保守負担を大きく下げられる一方、オフコン時代に作り込んだ独自の帳票や業務ルールは削る前提になります。ここで業務部門の合意が取れないと計画は止まる。判断材料としてSaaS型ERPとは何か？基本概要・仕組み、導入メリットを徹底解説も参照してください。

資産量が多いほど左側、業務側の変更許容度が高いほど右側という並びです。複数の業務が混在するオフコンでは業務単位で方式を分けるのが通例で、全業務を一つに揃える必要はありません。

クラウド化で解決しない部分

クラウド化が確実に解決するのは、ハードウェアの保守切れ、部品枯渇、機械室の設備維持といった物理面の問題だけです。ここを取り違えると、移行後に「何も良くなっていない」という評価が返ってきます。

経済産業省の総括レポートは、レガシーシステムを「運用維持保守や機能改良が困難な状態に陥り、経営・事業戦略上の足枷、高コスト構造の原因となっているシステム」と定義し、その要因を技術の老朽化、システムの肥大化・複雑化、システムのブラックボックス化、IT投資がされていないこと、古い制度としがらみの5つに整理しました。このうちクラウド化で消えるのは1つ目の一部にすぎません。同レポートは、メインフレーム等の古い技術や開発手法で構築されたシステムであっても、開発・運用維持保守体制が整備され、デジタル技術の活用やデータ連携が可能で、仕様が明確で継続的な機能改良が可能な適切な作りであれば、レガシーシステムではないと言える、としています。オフコンだから移行する、という論法は成り立ちません。

逆方向の指摘もあります。同レポートは、既にメインフレーム等から脱却済であっても、運用維持保守に問題があれば再レガシー化する可能性があると述べています。仕様が不明なままリホストで移した資産は、クラウド上で再びブラックボックスとして固まる。レガシー化の判断軸そのものはレガシーシステムとは何か、その意味・定義や歴史的背景、企業経営への影響を現代ビジネスの視点から詳しく解説で確認できます。

そのうえで、クラウド化を第一選択にすべきでない場面を挙げます。稼働中のオフコン業務が数年以内に廃止・統合される予定なら、移行費用をかけずに現行機で使い切る判断が合理的です。また、業務ロジックを把握している要員が退職済みで仕様書も残っていない状態でリホストだけを実行するのは、問題の先送りにしかなりません。この場合は、移行前に資産の棚卸しへ予算を割くほうが結果的に安く済みます。

期限から逆算した移行計画の立て方

2031年3月31日は動かせない期日です。この日から逆算し、意思決定に必要な材料をそろえる順序を決めます。

IT資産の可視化を最初の工程に置く

経済産業省の総括レポートは、自社のシステム状況を棚卸ししてIT資産を可視化し、企業規模とシステム化の度合いに応じて自社がどの状態にあるかを自律的に判断できる状態にすることが重要だとしています。オフコンの場合、可視化の対象は稼働プログラムの本数、実際に使われている帳票、外部システムとの連携点、そして仕様を説明できる要員の有無です。ここが空欄のまま方式を決めると、見積もりが数倍ぶれます。富士通が2025年度第1四半期中に提供するとした資産分析・可視化サービス for アプリケーション資産のように、ベンダー側にも可視化を独立した工程として切り出すメニューが用意されています。

総括レポートの企業像で自社の位置を確認

同レポートの自己診断図は、企業規模とシステム化の度合いで企業像を並べています。オフコン利用企業に当たるのは「オフコンを早期に導入」し「業務パッケージをカスタマイズして運用中」という像で、方向性は「オフコン業務を段階的に廃止、クラウドサービスに順次移行」。隣接する像には「ERPの導入とカスタマイズ多数」で情報システム部門がモダン化に苦慮している企業があり、こちらは「レガシーシステム（ERP）の可視化と仕分け、モダン化の計画を策定し実行」とされています。自社がどの像に近いかを先に決めると、着手すべき工程が絞れます。

2031年3月から逆算した工程配置

移行の実作業だけでなく、その前段に方式選定と業務部門との合意形成が入ります。リプレースを選ぶなら標準機能に合わせる業務側の判断が必要で、これは情報システム部門だけでは決められません。並行稼働と切り替え、旧環境の廃棄までを工程に含めたうえで、期日の手前に余白を残す配置にします。Cloud Service for オフコンを現在利用している場合、2031年3月31日はサービスが止まる日であって、移行を始める日ではありません。また販売中止（2026年3月31日）は到来済みで新規契約はできないため、現行が自社設置のハードウェアであればリホスト以外の方式を軸に検討することになります。

よくある質問

オフコンクラウドとは何ですか？

オフコンの実行環境をベンダーのデータセンターへ移し、ハードウェアを自社に置かずに既存の業務プログラムを動かし続ける形態を指します。エフサステクノロジーズのCloud Service for オフコンが代表例で、同社は「お客様のオフコンシステム環境をデータセンターで運用」するサービスと説明しています。業務をクラウドサービスへ載せ替える移行とは別物です。

富士通のオフコンはいつまで使えますか？

Cloud Service for オフコンは2031年3月31日でサービス提供が中止され、専用OSのASPほか関連ソフトウェアの保守中止も同日です。自社設置のPRIMERGY 6380B/6580B/6780B/6980Bは保守終了時期が2023年3月と公表されていますが、これは最終出荷製品の日付で、実際の保守サポート期間は購入時期から5年間（2002年3月以前の購入は6年間）とされています。自社の購入年月で確認してください。

オフコンとメインフレームの違いは何ですか？

規模と用途が異なります。メインフレーム（汎用機）は大企業の全社基幹を大量トランザクションで支える大型機で、オフコンは中小企業や部門単位の基幹業務を1台でまかなう小型機として発展しました。オフコンは業務パッケージを自社向けにカスタマイズして育てる使い方が主流で、その蓄積が移行の難易度を左右しています。

オフコンとPCサーバーの違いは何ですか？

ハードウェアと専用OSが一体で設計され、業務アプリケーションまで含めてベンダーが動作を保証する点がオフコンの特徴です。ASPやA-VXはその系統のハードウェアで動くことを前提に作られています。対してPCサーバーはWindows ServerやLinuxを載せて任意の用途に使う汎用機材で、この一体設計を前提にしません。オフコンの移行が単純なサーバー更改にならないのは、この違いによります。

NECのオフコンの保守はいつ終了しましたか？

最終受注可能日2015年1月30日、出荷停止日2015年3月31日、保守用部品保有期限2020年3月末とNECが公表しています。保有期限を過ぎているため、故障時に純正部品での復旧を前提にした運用はできません。

オフコンをそのままAWSなどのクラウドに移せますか？

系統によって答えが変わります。富士通のASPやNECのA-VXは、ベンダーが対応する基盤の上で動くことを前提に作られているため、汎用クラウドへ移す場合はリライトやリビルド、パッケージへのリプレースといった作り替えを伴います。一方IBM iは、IBM Cloudのドキュメントによると、IBMデータセンター内のPower機で稼働するPower Virtual ServerがRHEL・IBM i・AIXに対応しており、環境ごと移す経路が用意されています。IBM i の詳細はAS/400（IBM i）サポート終了はいつ？移行の判断基準と方式の選び方を参照してください。

オフコンのクラウド化の費用はどう決まりますか？

資産量と方式の組み合わせで決まります。見積もりを左右するのは、稼働プログラムの本数、帳票とマスタの数、外部システムとの連携点、そして仕様書がどこまで残っているかです。仕様が不明な資産が多いほど調査工程が膨らみ、同じ本数でも金額が変わります。方式別ではプログラムを触らないリホストが低く、業務要件から作り直すリビルドが高くなります。複数社に相見積もりを取るなら、資産の可視化結果を先に共有すると条件がそろいます。

関連記事

• AS/400（IBM i）サポート終了はいつ？移行の判断基準と方式の選び方
• マイグレーションとは？リプレイス・モダナイゼーションとの違いと発注判断を解説
• モダナイゼーションとは？レガシー刷新の手法と実装アプローチ・進め方を解説
• 基幹システム刷新の失敗事例と回避策｜出荷停止と訴訟に至った5件を工程別に分解
• SaaS型ERPとは何か？基本概要・仕組み、導入メリットを徹底解説