「オフコン2026年問題」が現実に｜IBM i 7.3・POWER9・富士通オフコンの保守期限が同時に迫る中堅企業の意思決定

結論：OSとハードの保守期限が2026年に同時到来。「動いているから」の放置がいちばん危ない

2026年、基幹システムをオフコン（オフィスコンピュータ）で動かし続けてきた中堅企業に、複数の保守期限が同時にやってきます。事実から先に並べます。

• IBM i 7.3のサポートが2026年9月30日に終了します。IBMは7.3の延長サポート（新規障害修正を含む）を2023年10月1日から3年間、2026年9月30日まで提供するとしており（IBM i Support Roadmap）、これを過ぎるとOS側の欠陥修正・セキュリティ修正が標準では提供されなくなります。
• POWER9搭載機の一部モデルは標準サービス（End of Standard Service）が2026年1月31日に終了済みです。IBMは2024年9月にこの日付を告知しており（IBM Community「Power 9 reminder: End of Standard Service is 31 January 2026」）、これ以降は予防保守やマシンコード修正（セキュリティ修正含む）がIBM標準では提供されなくなります。ハードが即停止するわけではありませんが、故障時の部品・技術者の後ろ盾が細っていきます。
• 富士通は国産オフコン系サービスの新規販売を2026年3月末で終了します。「Cloud Service for オフコン」やASPソフトウェアなどの新規販売を2026年3月末に終え、保守（サービス提供）は2031年3月末まで継続すると告知しています（i Magazine「富士通、オフコン資産のモダナイゼーションサービスを体系化」、エフサステクノロジーズ「Cloud Service for オフコン サービス提供終了までのご案内」）。

つまり、IBM i（AS/400系）を使う企業も、国産オフコンを使う企業も、OS・ハード・ベンダーサービスのどこかで2026年に区切りを迎える構造になっています。ここで経営が判断すべきは「今すぐ全部止まるか」ではありません。止まりはしません。判断すべきは、保守が切れた基幹システムを、障害時にIBMや富士通の標準サポートなしで運用し続けるリスクを、あと何年抱えるかです。基幹の受発注・在庫・生産・販売管理がこの上で動いているなら、これは情シスの技術課題ではなく、事業継続の経営判断です。

この記事では、選択肢を「①IBM i継続（OS更新＋ハード更改／Power Virtual Serverへのリホスト）」「②パッケージ移行（Fit to Standard）」「③リライト・リビルドで脱オフコン」の3つに整理し、自社がどれを選ぶべきかを、資産量・業務の独自性・社内人材・移行期間の4軸で判断できるようにします。あわせて、移行で必ず出てくる地雷（文字コード・帳票・バッチ・COBOL/RPG互換・データ移行）を先に提示し、9月末から逆算した意思決定スケジュールと、ベンダーに投げるべき質問テンプレまで示します。

なお、AS/400（IBM i）の刷新費用の相場観と段階移行ロードマップの一般論は、既存記事IBM i (AS/400) モダナイゼーション 完全ガイド 2026で扱っています。本稿はそちらとは役割を分け、「2026年に保守期限が実際に迫った」という期限トリガーに絞り、継続か脱オフコンかの意思決定に落とすことに集中します。費用感の全体像はそちらを、いま何を決めるかは本稿を、と読み分けてください。

この記事を読むべき人

• 受発注・在庫・生産・販売管理などの基幹を、AS/400（IBM i）や富士通など国産オフコンで現役運用している中堅製造業・卸・流通業の経営者、役員、事業責任者
• 情シスが0〜1名、または兼任で、OS・ハードの保守期限が来ていることは薄々知っているが、「まだ動いているし、止める判断をする根拠がない」と先送りしている決裁者
• POWER9搭載機や古いIBM iのバージョンを使っており、故障・障害が起きたときに誰がどう直すのかを一度も確認していない企業
• 「オフコンを止めろ」とベンダーから言われているが、それが自社に本当に必要な提案なのか、ベンダーが売りたいだけなのかを見極めたい経営者
• 移行の見積もりを取り始めたいが、何を確認してから声をかければ「言い値」にならないかを知りたい担当者

何が2026年に起きるのか：3つの期限を正確に押さえる

まず、混同しやすい3つの期限を分けて理解します。「サポート終了」「標準サービス終了」「新規販売終了」は、意味も緊急度も違います。

ここで押さえるべき勘所を、経営の言葉で整理します。

「サポート終了＝即停止」ではない。 OSの標準サポートが切れても、システムは翌日も動きます。危険なのは、切れたあとに問題が起きたときです。セキュリティ上の脆弱性が新たに見つかっても標準では修正が出ない、障害が起きても標準の窓口では直しようがない、という状態で基幹を回し続けることになります。多くの中堅企業にとって、これは「事故が起きるまでは平気に見えるが、起きた瞬間に代替手段がない」という、最もタチの悪いリスクの持ち方です。

IBM iは「プラットフォームとして終わった」わけではない。 誤解されがちですが、IBM iというOS系列そのものは現役です。7.3のサポートが切れても、7.4・7.5という後継バージョンが提供されており、そちらに上げれば当面のサポートは継続します。つまりIBM i利用企業の最初の分岐は「IBM iを使い続けるか／やめるか」であって、「7.3のまま延命するか」ではありません。7.3にしがみつく選択肢は、原則ありません。

POWER9は「標準サービス」が終わっただけ。 ハード自体は動き続けますし、サードパーティ保守（TPM）で延命する道もあると報じられています（IT Jungle「A Year From Now, Most Power9 Systems Bite The Rust」）。ただし延命は「時間を買う」策であって、根本解決ではありません。買った時間で何を決めるか、が問われます。なお、POWER9の中でも対象モデルや細かい日付はモデルごとに異なるため、自社の機種の正確な区分は各ベンダー公式のライフサイクル情報で確認してください。

富士通オフコンは「入口が閉じ、出口に期限がある」。 新規販売が2026年3月末で終わり、保守は2031年3月末まで。つまりあと約5年で全利用企業が別のプラットフォームへ移らなければならないという時間割が引かれた状態です。5年あると聞くと余裕に見えますが、基幹の移行は要件整理・設計・移行・並行稼働・切替を含めると年単位でかかります。移行を担うベンダーの人手も、期限が近づくほど取り合いになります。富士通自身も「モダナイゼーションマイスター」による専門家アドバイザリーや生成AIを活用した資産分析・可視化サービスを2025年から提供し始めており、Fit to Standard・COBOLアプリケーション変換・SaaS組み合わせによる再構築といった移行支援を体系化しています。裏を返せば、ベンダー側も「これは移行需要が一斉に来る」と読んで動いているということです。

なお、富士通オフコンの利用企業数について「約700社」といった数字が一部で報じられていますが（日経クロステック関連報道）、これは二次報道ベースの推計であり、対象範囲の取り方で変わり得ます。自社の意思決定に使うべきは業界全体の台数ではなく、あくまで自社の1台がどの期限区分に入っているか、です。

選択肢マップ：継続・パッケージ移行・脱オフコンの3ルート

保守期限が迫ったオフコン基幹の行き先は、大きく3つに整理できます。どれが正解かは会社によって違い、ベンダーが最初に持ってくる案が自社にとっての最適とは限りません。まず地図を持ってから見積もりを取るのが、言い値を避ける唯一の方法です。

①IBM i継続（OS更新＋ハード更改／Power Virtual Serverへリホスト）

いまのRPG/COBOL資産・DB2・帳票・バッチをできるだけ活かしたまま、OSを7.4/7.5へ上げ、ハードをPOWER10世代へ更改する、あるいはクラウド上のIBM i（IBM Power Virtual Serverなど）へリホストするルートです。アプリケーションのロジックはほぼ温存できるため、業務が止まるリスクと移行コストは3つの中で相対的に小さくなります。

向いているのは、RPG/COBOL資産が大量にあり、業務が自社固有で、当面はIBM iの人材や保守を確保できる企業です。逆に弱点は、根っこにある「RPGを書ける人が減っていく」という構造課題を先送りする点で、これは時間を稼ぐ策です。稼いだ時間で人材・ドキュメント・段階的な脱依存をどう進めるかをセットで決めないと、数年後に同じ判断を、より人が減った状態で迫られます。

②パッケージ移行（Fit to Standard）

基幹をスクラッチのオフコン資産から離し、業種向けERPや業務パッケージ・SaaSへ載せ替えるルートです。自社の業務をパッケージの標準機能に合わせる「Fit to Standard」が基本思想で、カスタマイズを最小化するほど、その後の保守・バージョンアップが楽になります。

向いているのは、業務がある程度標準的で、「うちのやり方」に固執する必然性が薄い企業です。最大の落とし穴は、現行の独自運用を全部パッケージに持ち込もうとして、カスタマイズの塊になり、結局「別のブラックボックス」を作ってしまうこと。パッケージ移行の成否は、技術ではなく**「現場の独自運用のうち、どれを捨てられるか」を経営が決められるか**にかかっています。ここは情シスだけでは決められず、業務部門と経営の合意が必須です。

③リライト・リビルドで脱オフコン

RPG/COBOLの資産を、**現代的な言語・アーキテクチャで作り直す（リライト／リビルド）**ルートです。自由度が最も高く、将来の拡張性・人材確保・他システム連携で最も有利になりますが、費用・期間・失敗リスクも最大です。

向いているのは、業務ロジックに強い独自性・競争力があり、それをデジタルの武器として作り込む価値があり、かつ移行に耐える体制と期間を確保できる企業です。注意すべきは、「オフコンが古いから作り直す」という動機だけで③に飛ぶと、要件が固まらないまま大規模開発に突入し、PoC止まり・追加費用・納期遅延の典型パターンにはまることです。③は「作り直したい」ではなく「作り直す価値がある業務が明確にある」ときの選択です。

4つの判断軸で、自社の行き先を仮決めする

3ルートのどれに寄せるかは、次の4軸で当たりをつけられます。すべてを満たす正解はなく、自社がどこに重心を置くかを言語化するための軸です。

現実には「①で時間を稼ぎつつ、業務単位で②③へ段階移行する」ハイブリッドが多くの中堅企業の着地点になります。重要なのは、最初にどれか1つに決め打ちすることではなく、業務ごとに行き先を仕分けし、期限が近い部分から順に手を打つという設計です。

移行の地雷：見積もり前に知っておくべき5つの落とし穴

どのルートを選ぶにせよ、オフコン移行には「やってみて初めて出てくる」コストが潜んでいます。これらを見積もり段階で洗い出せていないと、後から必ず追加費用として跳ね返ります。ベンダーの初回見積もりにこれらが含まれているかを、経営がチェックするための一覧です。

• 文字コード変換の地雷。 オフコンはEBCDIC系や独自の外字を使っていることが多く、オープン系（UTF-8など）へ移すと、外字・機種依存文字・半角カナ・過去データの文字化けが起きます。取引先名・品名・住所に外字が混ざっている製造・卸ほど深刻で、「1件ずつ目視で直す」羽目になりがちです。
• 帳票の地雷。 オフコン時代の専用帳票（納品書・請求書・作業指示書）は、レイアウトや連続用紙・プレプリント用紙に強く依存していることがあります。新環境で同じ帳票を再現するのは、しばしばシステム本体より手間がかかります。取引先が「この様式でないと受け付けない」ケースもあり、業務側の交渉が絡みます。
• バッチ処理の地雷。 夜間バッチ・締め処理・他システム連携が、長年の改修で誰も全体像を把握していない状態になっていることが多く、これが最大のブラックボックスです。「動いているが、なぜ動くか分からない」バッチの棚卸しは、移行工数を読む上で外せません。
• COBOL/RPG互換の地雷。 「同じCOBOL/RPGだから移せる」は幻想です。方言・独自関数・OS依存の呼び出しがあり、コンバータをかけても100%は変換されません。変換率と、変換されなかった部分の手直し工数を、見積もり時点で明示させる必要があります。
• データ移行の地雷。 現行DBの正規化が甘い、履歴データの持ち方が独特、マスタが重複している、といった「長年の垢」が、移行時に一気に噴き出します。移行対象データの範囲（何年分を移すか、履歴はどうするか）を決めるのは技術判断ではなく業務判断で、ここを曖昧にすると移行が終わりません。

これら5つに共通するのは、現行システムの中身をどれだけ正確に把握しているかで、移行の難易度も見積もりの精度も決まるという点です。逆に言えば、いきなり移行会社に「いくらでできますか」と聞く前に、自社の資産の棚卸し（RPG/COBOLの本数、帳票の種類、バッチの一覧、外字の有無、データ量）をざっとでも掴んでおくと、見積もりの言い値を避けられます。

9月末から逆算する意思決定スケジュール

IBM i 7.3のサポート終了（2026年9月30日）を最も近い明確な期限として、そこから逆算した意思決定の目安を示します。これは工事の工程表ではなく、「いつまでに何を決めておかないと、選択肢が減るか」という経営判断のカレンダーです。実際の所要期間は資産量と選ぶルートで大きく変わるため、目安として捉えてください。

ポイントは、「継続」は他ルートより短期間で打てることです。7.3のサポート終了が近い企業は、まず7.4/7.5へのOS更新や、ハード更改・クラウドリホストで「保守が切れた状態で基幹を回す期間をゼロにする」ことを優先し、そのうえで腰を据えて②③の脱オフコンを検討する、という二段構えが現実的です。逆に、期限を過ぎてから慌てて大規模刷新に飛びつくと、要件が固まらないまま予算と納期に追われ、失敗パターンにはまります。

ベンダーに投げる質問テンプレ

移行の見積もりを取るとき、「安いところ」を探すのではなく、「自社の地雷を先に見つけてくれるところ」を選ぶのが、追加費用トラブルを避ける近道です。次の質問に具体的に答えられるベンダーは、現行資産を真面目に見ています。逆に、これらを曖昧にしたまま総額だけ出してくるベンダーは、後から追加費用が出る可能性が高いと考えてよいでしょう。

• 当社のRPG/COBOL資産を、どうやって本数・複雑度を把握するのか。棚卸しの方法と、その工数は見積もりに含まれているか。
• COBOL/RPGの自動変換をかけた場合、想定される変換率はどのくらいか。変換されなかった部分の手直し工数は、どう見積もっているか。
• 文字コード変換で、外字・機種依存文字はどう扱うか。過去データの文字化けチェックは誰が、どこまでやるのか。
• 現行の帳票と夜間バッチの棚卸しは、見積もりのどの工程で行うのか。ブラックボックス化したバッチが見つかった場合、追加費用になるのか含まれるのか。
• データ移行の対象範囲（何年分・履歴の扱い）は、誰が決めるのか。移行後の突合・検証はどこまでやるのか。
• 継続（OS更新・リホスト）と脱オフコンの両方を提示できるか。それとも自社が売れる1案だけを勧めているか。
• 移行中の並行稼働・切替リハーサル・切り戻し（ロールバック）の計画はあるか。切替当日に問題が起きたらどうするか。

最後の2つは特に重要です。「継続も移行も両方フラットに提示できるベンダー」かどうかは、その提案が自社のためのものか、ベンダーが売りたいものかを見分ける試金石になります。1案しか出てこないときは、なぜその1案なのかの理由を必ず聞いてください。

塩漬けを続けた場合のリスク

「まだ動いているから」と判断を先送りし続けると、時間の経過とともに次のようにリスクが積み上がります。これは脅しではなく、期限を過ぎたシステムを抱えることの構造的な帰結です。

障害時に直せない。 保守が切れたOS・ハードで基幹を回している状態で重大障害が起きると、標準の窓口では修理・修正が受けられません。受発注や出荷が止まれば、その損失はシステム更改費用をはるかに超え得ます。しかも、こういう事故は「いちばん忙しい時期」に起きがちです。

セキュリティ修正が出ない。 サポート終了後に新たな脆弱性が見つかっても、標準では修正が提供されません。基幹に取引先情報・個人情報が乗っているなら、これは事業リスクであり、取引先からの信頼問題にもなります。

技術者の枯渇が進む。 RPG/COBOLを扱える技術者は高齢化が進み、社内でも社外でも確保が年々難しくなります。判断を先送りするほど、いざ移行するときに「移行を担える人」も「移行後に運用できる人」も減っている、という悪循環に入ります。先送りは、より条件の悪い状態で同じ判断を迫られることを意味します。

だからこそ、2026年の期限は「慌てて刷新する理由」ではなく、「腰を据えて行き先を決める最後のよいタイミング」と捉えるのが健全です。期限に追われて拙速に大規模開発へ飛ぶのも、期限を無視して塩漬けを続けるのも、どちらも失敗の入口です。まず継続で足元の保守切れを解消し、そのうえで業務単位に脱オフコンを設計する——この順序を守れるかどうかが、成否を分けます。

よくある質問（FAQ）

Q. IBM i 7.3のサポートが2026年9月30日に切れると、システムはその日に止まりますか。 A. 止まりません。翌日も動きます。危険なのは、その後に障害やセキュリティ脆弱性が起きたときに、IBMの標準サポートでは修正・対応が受けられなくなることです。基幹が乗っているなら、保守が切れた状態で運用し続ける期間をできるだけ短くする（7.4/7.5へ上げる）ことを優先してください。

Q. IBM iはもう終わったプラットフォームなのですか。移行しないとダメですか。 A. IBM iというOS系列自体は現役で、後継の7.4・7.5が提供されています。7.3のサポートが切れても、上のバージョンへ上げれば当面の保守は継続します。したがって、必ずしも脱オフコンが必要なわけではありません。最初の分岐は「7.3のまま延命する／しない」ではなく「IBM iを使い続ける／やめる」であり、7.3のまま留まる選択肢は原則ありません。

Q. POWER9機を使っていますが、2026年1月末を過ぎました。すぐ買い替えるべきですか。 A. 標準サービス（End of Standard Service）が終了しただけで、ハードは動き続けます。サードパーティ保守などで延命する道もあると報じられていますが、それは時間を買う策です。買った時間で、ハード更改・クラウドリホスト・脱オフコンのどれに進むかを決めるのが本筋です。自社機種の正確な期限区分は各ベンダー公式のライフサイクル情報で確認してください。

Q. 富士通のオフコンは2031年3月末まで保守があるなら、まだ急がなくてよいですか。 A. 新規販売は2026年3月末で終わり、保守は2031年3月末までです。5年あるように見えますが、基幹の移行は要件整理から並行稼働・切替まで年単位でかかり、期限が近づくほど移行を担うベンダーの人手も取り合いになります。「保守終了の5年前」は、余裕ではなく着手の目安と捉えるのが安全です。

Q. ベンダーに「オフコンを止めて全面刷新しましょう」と言われました。従うべきですか。 A. まず、その提案が「継続と移行の両方をフラットに比較したうえでの結論」かを確認してください。1案しか出てこない場合は、なぜその案なのかの理由を必ず聞き、可能なら別のベンダーからも提案を取って見比べることをおすすめします。全面刷新は費用も失敗リスクも最大のルートで、業務の独自性や体制が伴わないと、要件が固まらないまま大規模開発に突入しがちです。

Q. 何から手をつければいいか分かりません。最初の一歩は。 A. 自社の機種・OSバージョンの期限区分の確認と、「止まったら事業が止まる範囲」の特定です。次に、RPG/COBOLの本数・帳票・バッチ・外字・データ量をざっと棚卸しすれば、どのルートが現実的かの当たりがつき、見積もりの言い値も避けられます。この棚卸しは、移行会社に声をかける前にやっておくほど有利になります。

GXOに相談すべきタイミング

オフコン2026年問題は、「刷新するかどうか」よりも先に、「自社はどのルートで、どの順番で手を打つべきか」を冷静に決めることが要になります。次のような状態にあるなら、社内だけで抱えず、継続と移行の両方をフラットに見られる第三者を一度入れる価値があります。

• ベンダーから移行や全面刷新を勧められているが、それが自社にとって本当に必要な提案なのか、判断する材料が社内にない
• 情シスが0〜1名または兼任で、現行資産（RPG/COBOL本数・帳票・バッチ・外字）の棚卸しに手が回らず、見積もりの前提が作れない
• 「継続で時間を稼ぐ」のか「脱オフコンへ動く」のか、業務ごとの行き先を仕分ける設計を一緒に考えてくれる相手がほしい

GXOでは、こうしたレガシー基幹の刷新・移行の意思決定を、レガシーシステムのモダナイゼーション支援として、継続・パッケージ移行・脱オフコンをフラットに比較する立場から支援しています。移行を前提に業務システムを作り直すフェーズに入るならDX・基幹システム開発、その前に「まず自社の現行資産と着手順を第三者の目で整理したい」という段階ならAIアセスメント・現状診断から入るのが無理のない順序です。ベンダーの言い値や、期限に追われた拙速な全面刷新を避けたい段階であれば、まずはご相談・お問い合わせから現状をお聞かせください。特定の1案に誘導するのではなく、自社の資産量・業務の独自性・人材・期間に照らして、継続と移行のどちらがどの業務に合うかを一緒に見極めるところから始めます。

なお、費用相場や段階移行ロードマップの全体像を先に押さえたい場合は、IBM i (AS/400) モダナイゼーション 完全ガイド 2026もあわせてご覧ください。本稿が扱った「2026年の期限からの意思決定」と、そちらの「費用とロードマップの一般論」を組み合わせると、判断の解像度が上がります。

参考文献

• IBM「IBM i Support Roadmap and Service Extension」
• IBM Community「Power 9 reminder: End of Standard Service is 31 January 2026」
• Fresche Solutions「IBM i 7.3 end of support date」
• IT Jungle「A Year From Now, Most Power9 Systems Bite The Rust」
• i Magazine「富士通、オフコン資産のモダナイゼーションサービスを体系化して新規提供」
• エフサステクノロジーズ「Cloud Service for オフコン サービス提供終了までのご案内」
• 日経クロステック関連報道「富士通オフコンに迫る脱出期限」