オフコンで動く先代の基幹システム、いつまで使い続けられるか

オフコンで動く先代の基幹システム、いつまで使い続けられるか

結論から先に言う。オフコン（オフィスコンピュータ、代表格はIBM iこと旧AS/400）は「あと1年で必ず止まる」機械ではないが、「安心して使い続けられる根拠」は年々薄くなっている。先代が20年、30年と使い続けてきたオフコンが今日も元気に動いているという事実は、明日も動く保証にはならない。判断材料になるのは、①メーカー・OSベンダーのサポート状況、②ハードウェアの物理的な寿命、③操作・保守ができる人材の有無、という3つの軸であり、この記事ではそれぞれを一次情報とともに具体的に示す。

• メーカーのサポート撤退が進んでいる: NEC・日立・東芝といった主要メーカーがオフコン市場から相次いで撤退し、IBM i(旧AS/400)についても古いバージョンの延長サポートが2026年9月30日に終了する
• 判断軸は「壊れるかどうか」ではなく「壊れたときに直せるか」: サポート状況・機器の物理的寿命・対応できる技術者の有無という3点をチェックすれば、自社の移行の緊急度が見える
• 全面刷新以外の選択肢もある: 現状の棚卸しから始め、部分置き換え・並行稼働といった段階的な移行方法を選べる余地がある

こんな読者を想定して書いている。先代が受発注や在庫管理、給与計算のためにオフコンを導入し、以来20年以上そのまま使い続けている。担当していたメーカーの営業や保守員は代替わりし、今の担当者に聞いても「古い機種なので詳しい者が少なくて」と言葉を濁される。壊れたら会社が止まる、という漠然とした不安はあるが、何をどう調べればいいのか分からないまま承継を迎えた社長に向けて書く。なお、この記事の後半では「今すぐ全部入れ替える」以外の現実的な選択肢についても触れるので、費用面が心配な人もそのまま読み進めてほしい。

オフコンとは何か。今さら聞けない基本を整理する

オフコンとは、中堅・中小企業の基幹業務向けに専用設計された業務用コンピュータの総称で、代表格がIBM製のAS/400（現IBM i）だ。

オフィスコンピュータの略で、1970年代から日本の製造業・卸売業・小売業を中心に広く普及した。パソコンが登場する前の時代に「1台で会社の基幹業務（受発注・在庫・生産管理・給与計算など）をまとめて処理できる専用機」として設計されており、堅牢性と長期安定稼働に強みがあった。NEC「ACOS」、日立「BASIC-J/EX」、富士通「PRIMEFORCE」、東芝「TOSBAC」など各メーカーが独自機種を展開していたが、その多くは既に生産・サポートを終了しており、現在も継続的にアップデートが提供されている代表機種はIBMのIBM i（旧AS/400、通称「アイシリーズ」）にほぼ集約されている状況だ。

先代の時代にオフコンが選ばれた理由は明快で、当時のパソコンやオープン系システムに比べて故障しにくく、専用OSとハードウェアが一体設計されているため安定性が高かった。「一度導入すれば10年、20年戦える」という評判どおりに使い続けてきた会社が、承継のタイミングで「これはいつまで使えるのか」という問いに直面している、というのが今の構図だ。

なぜ今、この話をするのか

先代がオフコンを導入した当時、営業所や保守窓口はメーカー系列に何拠点もあり、「困ったら電話すればすぐ来てくれた」時代だった。ところが2026年現在、状況は大きく変わっている。

まず、NEC・日立・東芝といった国産オフコンメーカーの多くが既に当該市場から撤退・縮小しており、後継機種の新規販売や部品供給が先細りになっている。加えて、業界で唯一継続的に展開されているIBM iについても、古いバージョンのサポート期限が順に到来している。IBM i 7.3は標準サポートが既に終了しており、延長サポート（Service Extension）についても2026年9月30日に終了することが公式に告知されている（参照: IT Jungle「IBM i 7.3 Loses Standard Support」）。つまり、先代の代からIBM i 7.3系のまま運用してきた会社は、この記事を書いている2026年8月時点で「あと1年強で延長サポートも切れる」という、決して遠くない期限に直面していることになる。

ハードウェア面でも状況は同様だ。IBM Power Systemsのうち、Power7はすでに2019年にサポートが終了し、Power8も2024年10月までに全モデルの純正保守が終了している。現在サポートが継続しているのはPower9以降の世代に限られる（参照: note「AS/400が2025年にサポート終了は本当か」）。先代の代に導入した機種がどの世代に該当するかを確認するだけでも、緊急度の目安になる。

先代が元気なうちは「うちのオフコンは大丈夫、メーカーの担当者に任せてある」で済んでいたかもしれない。しかし承継した今、その担当者自体が世代交代し、機種そのものの知識を持つ技術者が社内にも取引先にも減っている。相談窓口が細っていく中で老朽化した機器だけが残る、というのが承継後によく起きる構図だ。

「動いている」は安全の証明にならない

先代からオフコンを引き継いだ社長が最初にはまる罠が、「今日も止まらず動いているから大丈夫」という判断だ。しかしこの判断には見落としがある。

システムが「壊れていない」ことと、「これから起きるリスクに対応できる」ことはまったく別の話である。動作の継続性は過去の実績にすぎず、将来のハードウェア故障やセキュリティ上の脅威に対する耐性を何ら保証しない。

オフコンが今日動いているのは、単に「まだ大きな事故が起きていないから」にすぎない。ハードウェアの経年劣化、部品の供給停止、メーカーサポートの縮小といった外部要因が積み重なった先に、何の前触れもなく止まる可能性がある。これは典型的なレガシーシステム（レガシーシステム）の状態であり、承継のタイミングでこそ点検すべき対象だ。先代の時代には「壊れたら直せばいい」で済んでいたが、直す部品や技術者そのものが手に入りにくくなっている点が、当時とは決定的に違う。

見極めの軸1：メーカー・ベンダーのサポート状況

3つの見極め軸のうち、最も客観的で確認しやすいのがサポート状況だ。まず自社のオフコンがどのメーカー・どの世代の機種かを確認してほしい。

• NEC・日立・東芝など国産系オフコン: 多くが既に生産・新規販売を終了しており、保守部品の供給も限定的になっている。故障時に「同型の代替部品が手に入らない」事態が起きやすい
• IBM i（旧AS/400）: 現在も開発・サポートが継続している数少ない系統だが、バージョンごとにサポート期限が個別に設定されている。IBM i 7.3は延長サポートが2026年9月30日まで、7.4以降も順次期限が到来していく（参照: Proximity「IBM i Update: Support ending for IBM i 7.4」）
• ハードウェア世代（Power7/8/9等）: OSのバージョンとは別に、物理的なサーバー本体の保守期限も存在する。Power8は2024年10月までに純正保守が終了しており、それ以前の世代は既にサポート外である可能性が高い

社内に「うちのオフコンは何というメーカーの、何という機種で、OSは何のバージョンか」を即答できる人がいるかどうか、まずそこから確認してみてほしい。これに即答できない状態自体が、属人化（属人化）が進んでいるサインだ。

見極めの軸2：ハードウェアの物理的な寿命

サポート期限と並んで重要なのが、実際に動いている機器本体の物理的な寿命だ。オフコンは専用設計ゆえに堅牢だが、それでも永遠に動くわけではない。

厄介なのは、オフコン本体が壊れても「同じ機種の代替機」がすぐに手に入るとは限らないことだ。国産系オフコンの多くは既に生産終了しており、中古市場や部品取り用の在庫に頼らざるを得ないケースが増えている。IBM iについても、古い世代のPower Systemsは新規調達が難しく、修理対応も年々縮小傾向にある。

• 今の機種が壊れたら、同等の代替機をどこから調達できるか把握しているか
• メーカー・販売代理店との保守契約は現在も有効か、それとも先代の代で更新が止まっているか
• バックアップ用のテープ・ディスク装置は今も正常に動作するか

この3つに即答できない会社は、機器1台の故障がそのまま業務停止に直結するリスクを抱えている。これはまさに単一障害点（SPOF）（単一障害点）の状態であり、オフコン1台に受発注や在庫、給与計算までが依存している構造そのものが最大のリスクになる。

見極めの軸3：操作・保守ができる人材の有無

技術的な期限と並んで重要なのが、「人」の観点だ。オフコンの専用言語（RPGやCOBOLなど）を扱える技術者は年々減少しており、新卒や若手のエンジニアでこれらを専門的に学んでいる人はほとんどいない。結果として、既存のオフコン資産を保守できる技術者の市場価格は下がるどころか、希少性ゆえにむしろ上がっている、という逆転現象が起きている。

先代の時代には「メーカーの担当営業に聞けば何とかなった」オフコンが、承継後には「そもそも誰に頼めばいいか分からない」システムに変わっている。これは技術の問題である以上に、属人化した人間関係が承継とともに切れてしまうという、承継企業特有の脆弱性だ。

以下のチェックリストで、自社の「人のリスク」を確認してほしい。

• [ ] 導入時のメーカー・販売代理店と、今も連絡が取れる
• [ ] 保守契約が現在も有効で、対応範囲を把握している
• [ ] 社内に、オフコンの操作・簡単なトラブル対応ができる社員が最低1人いる
• [ ] その社員が退職・異動しても引き継げる操作マニュアルがある
• [ ] 過去の改修履歴やプログラム変更の記録が残っている

このうち2つ以上に該当しない（チェックが付かない）場合、すでに「直せる人がいない」状態に片足を突っ込んでいると考えたほうがよい。

古参社員との関係という、もう一つの変数

承継企業においてオフコンの扱いを難しくしているのが、その操作に習熟した古参社員の存在だ。経理・受発注担当のベテラン社員が「この画面のこの順番で入力すれば動く」という独自の手順を長年守ってきており、その暗黙知がシステムの使いにくさや癖を事実上カバーしているケースは少なくない。

これは表面的には安定稼働に見えるが、実態は属人化が二重にかかった状態だ。機種の中身が分かる技術者がいない「技術の属人化」と、そのオフコンの使い方が分かる社員が一人しかいない「運用の属人化」が同時に存在している。この社員が定年退職やケガで長期離脱した瞬間、オフコンは技術的には動いていても実質的に使えなくなる。先代の時代からこの社員に頼り切ってきた経緯がある場合、後継社長がオフコンの話を切り出すこと自体に気を遣う場面もあるだろう。しかし「あなたの仕事を奪う話ではなく、あなたしかできない状態を減らして会社を守る話だ」という説明は、古参社員の協力を得るうえで有効だ。実際に移行プロジェクトを進める際も、古参社員への丁寧なヒアリングは要件定義の質を大きく左右する。

移行を先延ばしにした場合に何が起きるか

ここまでの3つの軸（メーカーサポート、ハードウェア寿命、人材）が同時に悪化していくとどうなるか、時系列でイメージしておきたい。

経済産業省が2018年に警鐘を鳴らした「2025年の崖」は、レガシーシステムを放置した場合に発生しうる経済損失を試算したものだったが、経済産業省が2025年5月に公表した「レガシーシステムモダン化委員会総括レポート」でも、レガシーシステム刷新の課題として「他の案件に手一杯で十分な要員を割けない」という回答が最も多かったことが指摘されている（参照: 経済産業省・IPA「DXの現在地とレガシーシステム脱却に向けて」）。「崖」は一度きりのイベントではなく、対応を先延ばしにした企業に対して静かに、しかし確実に迫り続けている坂道だと捉えたほうが実態に近い。

移行タイミングを判断する3つのシグナル

では、具体的にいつ動き出すべきか。以下の3つのシグナルのうち、いずれか1つでも当てはまったら、移行の検討を始めるタイミングだと考えてよい。

シグナル1: 導入メーカーが既にオフコン事業から撤退・縮小している NEC・日立・東芝系のオフコンを使っている場合、後継機種の新規調達自体が困難になっている可能性が高い。まず現在の保守契約先に「この機種はあと何年、部品供給・保守対応が可能か」を確認することから始めたい。

シグナル2: IBM iのバージョンサポート期限が1〜2年以内に迫っている IBM i 7.3の延長サポートは2026年9月30日までであり、この記事を書いている時点で1年強しか猶予がない。7.4以降を使っている場合も、順次サポート期限が設定されているため、今のバージョンの期限を確認しておく必要がある。

シグナル3: 機種の操作・保守が分かる人が社内外に1人もいない、または1人しかいない 最後の1人が退職・引退する前に動くべきだ。この状態で放置すると、いざというときの選択肢が「業者に丸投げでゼロから作り直す」しか残らず、時間もコストも最大化する。

「今すぐ全部作り直す」以外の選択肢もある

移行というと「全部を最新のクラウドシステムに置き換える」という大工事をイメージしがちだが、実際にはいくつかの段階的な選択肢がある。承継後の資金繰りやリソースを考えると、いきなり全面刷新に踏み切るのが正解とは限らない。

1. 延命措置: 保守契約の見直し・延長、予備機の確保、操作マニュアルの整備など、コストをかけずにリスクだけを下げる応急処置
2. 部分置き換え: 最もリスクが高い機能（例えば給与計算や在庫管理など）だけを先に新しいクラウドサービスへ移し、それ以外は当面オフコンのまま残す
3. 並行稼働: 新旧システムを一定期間並行させ、データ突き合わせをしながら段階的に移行する
4. 全面刷新: 業務フロー自体を見直しながら、最新技術でゼロから作り直す

どの選択肢を取るにせよ、最初にやるべきことは「今何が動いていて、誰が管理していて、いつまで持つのか」を一覧化することだ。承継企業の多くはこの一覧自体が存在しないため、移行の意思決定以前に、まず現状把握から始める必要があるケースがほとんどだ。この現状把握の具体的な進め方は、「先代システムの現状調査（棚卸し）のやり方」で手順を解説しているので、あわせて読んでみてほしい。

オフコンに眠る「見えない資産」という壁

移行タイミングを見極めるうえで、社長自身が意外と気づいていないのが、オフコンが抱える「見えない資産」の重さだ。パソコンの業務システムと違い、オフコンは長年の運用の中で独自の進化を遂げていることが多く、単純な置き換えでは済まないケースが目立つ。

• 独自言語で書かれた大量のプログラム資産: RPGやCOBOLといった専用言語で、何十本・何百本という業務プログラムが書かれていることが多い。1本ずつの規模は小さくても、積み重なると総量は大きく、全体像を把握している人が社内にいないケースがほとんどだ
• 改修の継ぎ足しによる複雑化: 導入時の仕様のまま使われているオフコンは少なく、その時々の業務要望に応じて改修が繰り返されてきた結果、当初の設計者本人でも全体を追いきれない「スパゲッティ化」が進んでいることがある
• 専用のデータ形式: オフコンのデータベース（DB2 for iなど）は独自の構造を持っており、単純なファイルコピーでは他システムに持ち出せない。データを新システムで使える形式に変換する作業自体が、移行プロジェクトの主要な工数を占める
• 帳票・印刷レイアウトの独自定義: 請求書や納品書のレイアウトが、オフコン専用の帳票定義ファイルで管理されているケースが多い。新システムに置き換えた際、見慣れた帳票の体裁が再現できずに現場から不満が出ることがある
• 周辺機器との連携: バーコードリーダー、ハンディターミナル、専用プリンタなど、オフコンの通信方式に依存した周辺機器と連携しているケースもある。周辺機器の更新時に接続方式ごと見直しが必要になることがある

これらの「見えない資産」は、システムの仕様書には正確に記載されていないことが多い。仕様書自体が存在しない、あるいは導入当初のバージョンのまま更新されていないケースも珍しくない。移行を検討する際は、オフコン本体だけでなく、その内部に何が蓄積されているかを実際の業務フローに沿って洗い出す作業が欠かせない。この洗い出しを怠ったまま新システムに切り替えると、「新しいシステムは動くが、いつも使っていた帳票が出せなくなった」という形で、移行後にトラブルが表面化する。

クラウド移行・オープン化という選択肢の実際

近年、オフコンの移行先として語られることが増えているのが、クラウド上でIBM iを稼働させる方式や、オープン系システム（Windows・Linuxサーバーやクラウドサービス）へ全面的に置き換える方式だ。それぞれの特徴を大まかに整理しておきたい。

• IBM iをクラウド上で継続利用する方式: 業務プログラム資産（RPG・COBOL）をほぼそのまま活かしながら、物理的なハードウェアの老朽化・保守切れの問題だけを解消できる。既存の業務ロジックを大きく作り変える必要がないため、移行の難易度・費用を抑えやすい一方、専用言語で書かれたプログラムを保守できる技術者を確保し続ける必要がある点は変わらない
• オープン系システムへの全面移行: Webシステムやクラウドサービス（SaaS・パッケージ・フルスクラッチ開発）に置き換える方式。専用言語からの脱却により将来の技術者確保はしやすくなる一方、既存の業務プログラムをすべて作り直す必要があるため、初期費用と移行期間は長くなりやすい
• ハイブリッド構成: 基幹の一部機能はオフコン（またはクラウド化したIBM i）に残しつつ、周辺業務（勤怠管理・経費精算など）から段階的にオープン系サービスへ移行していく方式。前述の「部分置き換え」の考え方に近く、資金と人員を分散させながら進められる

どの方式が向いているかは、業務プログラムの複雑さ、資金計画、社内の技術リテラシーによって変わる。「とりあえずクラウド」「とりあえず全面刷新」と決め打ちせず、まず自社のオフコンに何が乗っているかを棚卸ししたうえで検討するのが現実的な進め方だ。

移行にかかる費用感の目安

具体的な金額は機種・規模・移行方式によって大きく変わるため断定はできないが、判断材料として一般的な費用構造を整理しておく。

• 現状棚卸し・アセスメント費用: 既存プログラムの資産量やデータ構造を調査する工程。小規模なオフコンでも数十万円〜、業務プログラムが多い場合はさらに膨らむ
• 部分置き換え: 特定業務（給与計算など）だけをクラウドサービスやパッケージソフトに置き換える場合、既製サービスの月額利用料＋初期設定費用に収まるケースが多く、全面刷新に比べて初期費用を抑えやすい
• 全面刷新（フルスクラッチ・パッケージ問わず）: 業務プログラム数・データ量・並行稼働期間の長さによって費用の幅が非常に大きい。プログラム資産が多いオフコンほど、移行工数（＝人件費）が費用の大部分を占める傾向がある
• 並行稼働期間のコスト: 新旧システムを同時に動かす期間は、旧オフコンの保守費用と新システムの運用費用が二重にかかる点を資金計画に織り込む必要がある

費用の内訳や請負・準委任といった契約形態の違いについては、外注を検討する段階で個別に確認すべき論点が多い。外注の進め方そのものについては刷新を開発会社に相談する前に、決めておきたい3つのことで扱っているカテゴリの記事群で詳しく解説しているので、実際に発注を検討する段階になったらあわせて参照してほしい。

移行の失敗パターンと回避策

オフコン移行でよくある失敗パターンをいくつか押さえておくと、同じ轍を踏まずに済む。

• 失敗パターン1: 現状調査を省いていきなり見積もりを取る

自社のオフコンに何本のプログラムが入っていて、どのデータがどう連携しているかを把握しないまま外部に見積もりを依頼すると、着手後に想定外の追加費用が発生しやすい。回避策は、簡易でもよいので社内で現状の棚卸し表を作ってから相談すること。

• 失敗パターン2: 一括の全面リプレイスだけを検討し、段階的な移行を検討しない

資金計画が整わないまま全面刷新に踏み切ろうとして頓挫するケースがある。前述のとおり部分置き換えや並行稼働という選択肢もあるため、いきなり「全部か、現状維持か」の二択で考えないほうがよい。

• 失敗パターン3: 古参社員への説明を後回しにする

現場の合意形成を後回しにしたまま移行を進めると、稼働直前になって「聞いていない」「今のやり方でないと困る」という反発が噴出し、スケジュールが崩れる。早い段階から古参社員に「なぜ変えるのか」を丁寧に説明する時間を確保したい。

• 失敗パターン4: データ移行のテストを軽視する

長年運用してきたオフコンのデータには、表計算では見えない不整合や例外処理が蓄積していることが多い。移行前のデータクレンジングとテスト移行を省略すると、本番切り替え後に数字が合わないというトラブルにつながりやすい。

専門家がいない孤独をどう埋めるか

株式や登記の承継であれば、税理士・司法書士・弁護士といった専門家が当然のように付いてくる。ところがオフコンの承継については、相談する専門家の存在自体が知られていない。先代から「あのシステムのことはメーカーの営業さんに任せてある」とだけ伝えられ、実際にその担当者がどこまで信頼できる相手なのか、他の選択肢はないのかを検証する術がないまま何年も過ぎていく社長は多い。

先ほど触れた冒頭の疑問——「壊れたら何が止まるのか」を自分の言葉で説明できるか——に立ち返ると、この孤独感の正体が見えてくる。何が分からないのかすら分からない状態で、業者から出てくる説明を鵜呑みにせざるを得ない。この状態を脱する最初の一歩は、専門用語を丸暗記することではなく、「今のオフコンはいつまでの寿命なのか」「壊れたら何が止まるのか」という、経営判断に直結する問いに答えを持つことだ。本記事で挙げた3つの見極め軸は、その問いに答えるための最低限のチェックポイントとして使ってほしい。

承継直後だからこそ動きやすい理由

逆説的だが、承継直後というタイミングは、オフコン移行を切り出すには実は好都合な時期でもある。先代の時代には「今のままでいい」という空気が長年の慣性で維持されてきたかもしれないが、新社長が交代のタイミングで「会社の仕組みを一度点検する」と説明すれば、古参社員や取引先にも自然に受け入れられやすい。

また、承継のタイミングで金融機関や取引先との関係を見直す会社も多く、その延長でIT投資の相談を切り出しやすい面もある。設備投資・システム投資を後押しする公的な補助制度が用意されている年度もあるため、利用できる制度がないか商工会議所や顧問税理士に確認してみる価値はある。オフコンからの刷新にIT導入補助金が使えるかどうかはデジタル化・AI導入補助金（旧IT導入補助金）は先代からのシステム刷新に使えるかで詳しく扱っているので、資金面で二の足を踏んでいる場合は参考にしてほしい。

なお、費用面がネックで最初の一歩を踏み出せずにいるなら、いきなり外部に相談する前に、今日ひとりでもできることがある。まずは自社のオフコンのメーカー名・機種名・導入年を紙かスマホのメモに書き出してみてほしい。それだけで、次に誰に何を聞けばいいかが見えてくるはずだ。

オフコンからの移行後によく発生するのが、新旧システム間の二重入力問題だ。二重入力をなくす。先代の紙台帳とシステムをつなぐ連携の基礎で解消の考え方を整理している。

まとめ：この記事で持ち帰れること

この記事を読んで判断できるようになることは、大きく3つある。

• 自社のオフコンが「今どのくらい危険な状態か」を、メーカーサポート・ハードウェア寿命・人材の3軸で自己診断できるようになった
• 「今すぐ全部作り直す」以外にも、延命・部分置き換え・並行稼働という段階的な選択肢があることが分かり、資金計画に応じた現実的な一歩を選べるようになった
• 移行でよくある失敗パターン（現状調査を省く・全面リプレイス一択で考える・古参社員への説明を後回しにする・データ移行テストを軽視する）を避けるための具体的な回避策が分かった

先代が20年、30年と守ってきたオフコンには、会社の歴史そのものが刻まれている。それを乱暴に切り捨てる必要はないが、いつまでも「先代がそう決めたから」で思考を止めてしまうと、判断の主導権を握れないまま機器の寿命に振り回されることになる。まずは自社の機種とサポート期限を確認するところから、静かに一歩を踏み出してみてほしい。