オフコンのクラウド化とは？富士通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は2018年3月末に販売を終えています。自社設置機の継続運用では、機種ごとの保守契約と部品供給の可否を確認する必要があります（第三者保守は別の検討対象です）。

富士通系で資産を残すなら、COBOL資産をLinuxやWindowsの実行環境へ移すリホストがいまも選べます。プログラムを変換するリライト、作り直すリビルド、パッケージへ置き換えるリプレースとの選び分けは、資産量と業務側の変更許容度で決まります。動かせないのは2031年3月という外部の期日です。IT資産の可視化を最初に済ませ、方式選定・変換・現新照合・切り替えを期日から逆算した工程に載せることが実務の要点になります。

オフコンとは：3系統のOS・実行環境と提供状況

オフコン（オフィスコンピュータ）は、中小企業や事業部門の受発注・在庫・会計といった基幹業務を1台でこなす業務用コンピュータです。ベンダーがハードウェアに専用OSや業務向けのミドルウェアを組み合わせて提供し、業務パッケージを自社向けにカスタマイズしながら育てる使い方が主流でした。本記事では、移行先と提供状況が異なる次の3系統を比較します。

富士通は1984年にオフコン「FACOM Kシリーズ」の国内提供を始め、40年以上にわたって販売管理や生産管理のオフコンシステムを支えてきたと2025年3月21日のプレスリリースで述べています。NECのExpress5800/600シリーズは1997年10月の発売で、Windows NTの上でオフィスサーバ資産を動かすミドルウェア「A-VXIV」を搭載していたと情報処理学会のコンピュータ博物館が記録しています。IBM iは他の2系統と事情が違い、現行のPower機とIBM Cloud上のPower Virtual Serverに移行先が残っているため、詳細はAS/400（IBM i）サポート終了はいつ？7.4終了後の延長費用と移行判断に委ねます。

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

「オフコンのクラウド化」という言葉は、性質の異なる2つを指します。ここを混同したまま見積もりを取ると、各社が想定する作業範囲が揃わず、比較ができません。

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

富士通系のそのまま型がCloud Service for オフコンです。2014年4月14日に「FUJITSU Cloud オフコンサービス」として提供が始まり、データセンター内の仮想サーバー上で専用OSのASPと業務プログラムを従来どおり動かす仕組みでした（富士通の2014年3月25日発表）。自社の機械室からハードウェアが消え、プログラムの改修は要りません。

現在のサービスメニューでは、基本サービスは必須の月額定額で、現行オフコンのモデルに合わせて300Lから900Hまでの8モデル（CPU1〜8コア、拡張サービス利用時のディスク最大3.6TB）を東日本・西日本の2リージョンで提供しています。動作OSはASP V30（ASP V28以降）で、ASPのソフトウェアはサービスとは別にライセンス商品（月額）として契約する形です。つまりASPを動かせる基盤はベンダー自身が用意したものだけで、ベンダーがサービスを畳めば、その基盤に留まる選択肢は消えます。

IBM iは例外です。IBM CloudのPower Virtual Server FAQは、IBMデータセンターのPower機で動く同サービスの対応OSとしてAIX・IBM i・Linuxを案内しており、環境ごと移す経路がいまも用意されています。

汎用の基盤へ業務を移す「載せ替え型」

もう一方は、オフコンの専用環境を離れ、IaaSやSaaSといった汎用のクラウドへ業務を移すやり方です。COBOL資産をオープン系の実行環境で動かすリホスト、別言語へ変換するリライト、要件から作り直すリビルド、パッケージやSaaS型ERPへ置き換えるリプレースが含まれます。同じ方式で移行先を自社設置のLinuxやWindowsサーバーにすればオープン化で、クラウド化とは設置形態が違います。オフコン側の終了期限からは外れますが、移行先のOS・実行環境・SaaSにもそれぞれ保守期限があり、そのライフサイクル管理は移行後も続きます。現行機能の保証と業務側の合意形成という負荷も生じます。

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

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

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

インフラ3サービスは、オフコンインフラ基本サービス、同拡張サービス、同VPNアダプターレンタルサービスを指します。

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

エフサステクノロジーズは「サービス提供終了までのご案内」で、富士通グループがオフコンのモダナイゼーションを2031年3月末までに完了するよう推進すると述べ、利用中の顧客にサービス提供終了までの移行を求めています。専用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）は時期が「未定」なので、使っている場合は個別に確認が必要です。

自社設置のハードウェアも終わっています。PRIMERGY 6000の製品一覧によると本体は2018年3月末に販売を終え、最終機種の6000/80Bは2013年4月から2018年3月までの販売でした。保守サポート期間は購入時期から5年間が標準のため、2018年3月の最終出荷分でも標準期間は2023年3月までです。個別の保守契約の終了日は契約書で確認してください。

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版と筐体で別々に進む期限

IBMのサポート終了告知はマシンタイプ・モデル単位で出るため、機種の通称だけでは期日が確定しません。OSバージョンごとの期限もそれとは別に進みます。Power Virtual ServerのFAQによると、クラウドへ移してもOSの保守・更新・管理は利用者の責任で、AIXとIBM iのライセンスは利用料に含まれます（既存のIBM iライセンスはIBM i MOLで持ち込める場合があります）。版と機種の対応はAS/400（IBM i）の解説記事で確認してください。

移行方式4種の選び分け

期日が確定したら、次は方式です。オフコンからの移行は、既存プログラムをどこまで残すかで4つに分かれます。優劣ではなく、資産の量・仕様書の有無・業務側の変更許容度で決まります。

複数の業務が混在するオフコンでは、業務単位で方式を分けるのが通例です。全業務を一つの方式に揃える必要はありません。

リホスト：ソース資産の再利用と実行環境の移行

プログラムのソースコードに極力手を加えず、実行環境を移す方式です。移し先は2通りあります。1つはCloud Service for オフコンのようなベンダー基盤で、ASPごと動かせる代わりに新規販売は終わっており、既存契約でも2031年3月31日までです。もう1つはLinuxやWindowsのオープン環境で、CECはCOBOL GプログラムやCOPY句などを再利用してオープンプラットフォームへ移す富士通製オフコン向けの移行サービスをリホスト形式と位置付けています。富士通の「NetCOBOL資産移行・技術支援サービス」も、COBOL資産をオープン系のNetCOBOLへ移すメニューです。既存資産の再利用で新規開発を減らせますが、移行期間は非互換箇所の修正量と検証範囲に左右されます。仕様を解明しないまま移せば、不明点も持ち越します。ベンダー基盤は期日までの準備期間を確保する手段、オープン系へのリホストは移行先での継続運用を前提にした移行と、目的を分けて選んでください。

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

変換ツールでソースコードを別の言語（COBOLからJavaなど）へ機械的に置き換える方式です。数千本規模のプログラムを抱え、仕様書が残っていない場合でも、変換可能なソースと現行の入出力結果を確保できれば、リライトを候補にできます。ただし変換後のコードは元の構造を引きずるため、保守性は自動的には改善しません。リホストとリライトの境界はベンダーによって呼び方が揺れるので、見積もりを比べるときは方式名ではなく、どのソースがそのまま残り、どこが変換・書き直しになるかという変換対象と成果物で揃えてください。COBOL資産の位置づけはCOBOLはなぜ廃れたと言われるのか？「オワコン」説の真相と、いまも使われ続ける理由で解説しています。

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

業務プロセスを見直し、要件を定義し直して新規開発する方式です。長年のカスタマイズで誰も全体像を把握していない状態を根本から解消できますが、対象業務が広いほど要件定義に時間がかかるため、期日から逆算すると最も早く着手が必要な方式です。資産の把握が目的なら、富士通の「設計書リバースサービス for アプリケーション資産」のように既存資産から設計書を起こすメニューもあります。工程の考え方はモダナイゼーションとは？レガシー刷新の手法と実装アプローチ・進め方を解説で扱っています。

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

自社開発の資産を手放し、業務パッケージやSaaS型ERPの標準機能に業務を合わせる方式です。富士通がプレスリリースで「標準機能に業務を合わせるアプローチ（Fit to Standard）」を掲げているとおり、ベンダー各社が推す方向でもあります。構築期間と保守負担を下げられる一方、オフコン時代に作り込んだ独自の帳票や業務ルールは削る前提です。ここで業務部門の合意が取れないと計画は止まります。選定の観点はSaaS型ERPとは？クラウドERPとの違いと更新・拡張・SLAで見る選び方を参照してください。方式の組み合わせを外部に相談する場合は、システムマイグレーション・リプレイスのように資産分析から移行まで一貫して扱う支援を選ぶと、業務ごとに方式を分ける判断がしやすくなります。

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

クラウドへ移行すれば、移行対象サーバーの保守や部品調達、設置設備の維持をサービス提供者に委ねられます。自社設置のサーバーへ移す場合は、移行先でもハードウェアと設備の維持管理が必要です。SaaSへの置き換えなら業務の標準化も進みますが、仕様の不明さや保守体制の問題は、移行しただけでは消えません。

前述の総括レポートは、レガシーシステムを「運用維持保守や機能改良が困難な状態に陥り、経営・事業戦略上の足枷、高コスト構造の原因となっているシステム」と定義し、要因を技術の老朽化、システムの肥大化・複雑化、ブラックボックス化、IT投資がされていないこと、古い制度としがらみの5つに整理しました。クラウド化で消えるのは1つ目の一部です。同レポートは、古い技術で構築されたシステムでも体制が整い仕様が明確で継続的に改良できるならレガシーではないとする一方、メインフレーム等から脱却済でも運用維持保守に問題があれば再レガシー化しうると述べています。仕様が不明なままリホストした資産は、クラウド上で再びブラックボックスとして固まります。判定の軸はレガシーシステムとは？経産省の定義と5要因でわかる判定基準と刷新の判断軸で確認できます。

クラウド化を第一選択にすべきでない場面もあります。稼働中のオフコン業務が数年以内に廃止・統合される予定で、故障時の代替手段（手作業での運用や他システムでの代行）があり、停止による損失を許容できるなら、移行費用をかけずに現行環境で使い切る判断もあり得ます。また、業務ロジックを知る要員が退職済みで仕様書も無い状態でリホストだけを実行するのは、問題の先送りにすぎません。この場合は移行前の資産の棚卸しに予算を割き、不要資産の除外と非互換箇所の把握によって、変換費用や手戻りを抑える方針を取ります。

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

2031年3月31日は、Cloud Service for オフコンが止まる日であって、移行を始める日ではありません。この日から逆算し、意思決定に必要な材料をそろえる順序を決めます。

IT資産の可視化：プログラム本数・帳票・連携点・要員

オフコンの可視化の対象は、稼働プログラムの本数、実際に使われている帳票、外部システムとの連携点、仕様を説明できる要員の有無の4つです。ここが空欄のまま方式を決めると、見積もりの前提が各社で食い違い、後から追加費用が出やすくなります。富士通も2025年3月のプレスリリースで、アプリケーション構造を可視化する「資産分析・可視化サービス for アプリケーション資産」をオフコン向けに2025年度第1四半期中に提供するとしており、可視化を独立したメニューとして切り出しています。可視化の結果を総括レポートp.47の企業像と照らし、自社が「オフコン業務を段階的に廃止」する像に当たるのか、ERPの可視化と仕分けから始める像に近いのかを先に決めると、着手すべき工程が絞れます。

移行工程の具体例：CECが公表した6工程

資産を引き継ぐ移行の工程は、富士通製オフコン向けに2025年3月21日から移行サービスを提供しているCECの2025年3月21日の発表が具体的です。同社はこの移行をリホスト形式としており、次の6段で進めます。

1. 無料診断：ヒアリングシートを基に過去の実績から概算見積もりを出す
2. 資産棚卸：ツールで不要資産を洗い出し、変換対象を決める
3. 調査分析／PoC：一部の資産で変換と移行先での稼働を検証する
4. 移行診断：自動変換と手作業の範囲を決め、正式見積もりを出す
5. 変換／現新照合：変換とデータ移行を行い、新旧システムの結果を突き合わせる
6. テスト支援（オプション）：業務観点を含む結合テスト・総合テスト

各工程は個別にも依頼でき、価格は個別見積もりです。対象はCOBOL GプログラムやCOPY句、CL、画面定義・帳票定義、データベースです。資産棚卸で使っていない資産を変換対象から外せば変換と検証の量が減り、現新照合で新旧の結果を突き合わせて変換の正しさを確かめ、業務としての正しさは結合・総合テストで確かめます。SaaSへのリプレースでは、変換の代わりにデータ移行と業務の標準化が工程の中心になります。どの方式でも、現新照合と切り戻し手順の確認はCloud Service for オフコンや保守契約が終わる前に済ませる必要があるため、検証の完了を終了日の手前に置いて工程を組みます。

費用の決まり方と二重払いの扱い

移行費用は、方式に加えて、変換対象の本数、非互換箇所の修正量、データ移行、連携改修、テストと並行稼働の範囲を積み上げて個別に見積もられます。過去の公表価格の例としては、富士通が2014年3月25日の発表で示したオフコンクラウドの価格があり、税別で基本サービスが月額3万5,000円より、資産移行支援サービスが一括180万円より、運用支援サービスが月額12万円でした。新規販売を終えたサービスの当時の価格なので、現在の見積もりの基準にはなりません。

見落としやすいのが新旧システムの二重払いです。現新照合と並行稼働の期間は、旧環境の利用料と新環境の構築費が重なります。富士通はこの課題に向けて、高額な初期費用の一括払いや新旧システム費用の二重支払いを対象にした「モダナイゼーションファイナンスサービス」を用意しています。複数社から相見積もりを取るなら、可視化の結果（プログラム本数・帳票数・連携点）を先に共有すると、各社の前提がそろって比較できるようになります。

よくある質問

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

オフコンの実行環境をベンダーのデータセンターへ移し、ハードウェアを自社に置かずに既存の業務プログラムを動かし続ける形態です。富士通系のCloud Service for オフコンが代表例で、専用OSのASPをそのまま動かします。業務をクラウドサービスへ載せ替える移行とは別物です。

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

Cloud Service for オフコンは2031年3月31日でサービス提供が中止され、ASPほか関連ソフトウェアの保守中止も同日です。自社設置のPRIMERGY 6000は2018年3月末に販売を終えており、保守サポート期間は購入時期から5年間が標準のため、最終出荷分でも標準期間は2023年3月までです。

Cloud Service for オフコンは今から契約できますか？

できません。2026年3月31日で新規販売を終了しており、サービス提供は既存の利用者向けに2031年3月31日まで続きます。自社設置の富士通オフコンから同サービスへ移ることはできないため、COBOL資産をオープン系へ移すリホストを含めて、載せ替え型の方式から選ぶことになります。

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

規模と用途が違います。メインフレーム（汎用機）は大企業の全社基幹を大量トランザクションで支える大型機で、オフコンは中小企業や部門単位の基幹業務を1台でまかなう小型機として発展しました。どちらも総括レポートでは、古い技術であること自体ではなく、保守や改良が困難な状態かどうかでレガシーと判定されます。

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

オフコンは、ベンダーがハードウェアに専用OSや業務向けのミドルウェアを組み合わせ、業務パッケージと一緒に提供してきた機種群です。PCサーバーはWindows ServerやLinuxを載せて任意の用途に使う汎用機材です。オフコンの資産はその系統の実行環境を前提に作られているため、移行が単純なサーバー更改になりません。

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

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

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

系統によります。富士通のASPはベンダーが用意した基盤でしか動かないため、ASPごとAWSなどへ移すことはできません。ただしCOBOL資産をLinuxやWindowsの実行環境へ移すリホストなら、既存ソースを再利用して汎用のクラウドやサーバーへ移す道があります。ただし、COBOLの方言、CL、画面・帳票、データベース、外部連携の変換や修正範囲を事前に確認します。NECのA-VX資産は、移行サービス各社の対応範囲を確認してから方式を決めます。IBM iは、IBM CloudのPower Virtual ServerがIBM iを対応OSとして案内しており、環境ごと移す経路があります。

関連記事

• AS/400（IBM i）サポート終了はいつ？7.4終了後の延長費用と移行判断
• マイグレーションとは？リプレイス・モダナイゼーションとの違いと発注判断を解説
• モダナイゼーションとは？レガシー刷新の手法と実装アプローチ・進め方を解説
• 基幹システム刷新の失敗事例と回避策｜出荷停止と訴訟に至った5件を工程別に分解
• SaaS型ERPとは？クラウドERPとの違いと更新・拡張・SLAで見る選び方