AS/400（IBM i）サポート終了はいつ？移行の判断基準と方式の選び方

「AS/400のサポートが終了する」という言い方は、実務では誤解のもとになります。終わるのは製品ではなく、いま動いているOSの版と、そのOSが載っているPower機の保守だからです。2026年9月30日にIBM i 7.4の標準サポートが終わり、Power9のスケールアウト機はすでに2026年1月31日で標準保守を終えています。自社の期限はどちらに当たるのか。ここを確定しないまま移行の議論を始めると、期日までに終わらない方式を選びます。この記事では期限の実体、使い続けてよい条件、方式の選び方、そして繰り返される失敗の原因を、IBMのライフサイクル情報と経済産業省の2025年5月のレポートをもとに整理します。

まとめ｜期限の確定・継続可否・方式選定という順序

• IBM i 7.4の標準サポートは2026年9月30日で終了し、以降は有償の延長サポート（Service Extension）で2029年9月30日まで。7.3は2023年9月30日に標準サポートを終え、延長サポートも第1期が2026年9月30日で切れます（第2期は2028年9月30日まで）。
• 7.5と7.6は終了日が未発表です。IBMはサービスレベルの変更を12か月以上前に通知する運用のため、いま発表が無い版には少なくとも1年の猶予があります。
• ハードのほうが先に切れます。Power8は全機種が標準保守を終了（最後のS812が2025年7月31日）、Power9のスケールアウト機も2026年1月31日で標準保守が終わりました。
• 上げられる版はハード世代で決まります。IBM i 7.6はPower10とPower11のみ、Power9機は7.5が上限、Power8機は7.4が上限です。
• 古いこと自体はレガシーではありません。経済産業省の定義では、保守体制・データ連携・仕様の明確さが揃っていればメインフレームでもレガシーに当たらないとされています。

順番を守ると議論が短くなります。まず自社機のOS版と機種型番から期限を確定。次に継続の可否を判断し、そのうえで方式を選ぶ段取りです。

「サポート終了」の実体｜OS版とPower機で別々に進む期限

AS/400・iSeries・System i・IBM iという改称の系譜

AS/400は1988年6月21日にIBMが発表した製品です。その後ハードウェアの呼称はiSeries、System i、Power Systemsへと変わり、OSの呼称はOS/400、i5/OS、IBM iへと変わりました。中身が別物になったわけではなく、名前だけが変わっています。

検索して出てくる「サポート終了」の情報が食い違うのは、この改称のためです。ある記事はハードの保守終了を、別の記事はOS版の標準サポート終了を指しています。確認すべきは製品名ではなく、自社が動かしているIBM iのリリース番号（7.3・7.4・7.5・7.6）と、筐体の機種型番の2つです。この2つが分かれば、以下の表で自社の期限、または期限が未発表であることが確定します。

IBM iリリース別の標準サポート終了日と延長サポート期限

7.4の終了は2025年9月の announcement letter AD25-0894 で確定し、OSそのものの販売は2026年4月30日で終わりました。7.3の延長サポートは2期に分かれていて、第1期（IBMの表記では Service Extension）が2026年9月30日、第2期（extended Service Extension）が2026年10月1日から2028年9月30日までです。つまり7.3を延長サポートで使っている企業も、7.4の企業とまったく同じ2026年9月30日に契約更新の判断を迫られます。

ここで押さえておきたいのは、標準サポート終了はEnd of Supportであって、システムが止まるEnd of Lifeではないという点です。稼働は続きます。止まるのは新規の欠陥修正とサポートケースの受付です。セキュリティ修正もこの止まる範囲に含まれます。すでに公開済みのPTFは、基本の保守契約（SWMA）が有効なら標準サポート終了後もFix Centralから入手できます。新しい欠陥や脆弱性への修正を受け取るには、有償の延長サポート（Service Extension）契約が必要です。監査や取引先のセキュリティ要件で「修正が提供される状態」を求められている場合、この日が実質的な期限になります。

なお最新の7.6は2025年4月8日発表・同月18日提供開始で、ワンタイムパスワードによる多要素認証をOSに内蔵しました。認証強化を外部製品で賄っている環境では、版を上げること自体が構成の簡素化につながります。各リリースの正式な期日はIBMのrelease life cycleページで確認できます。

OSより先に来るPower機の保守終了日

実務で先に効くのはこちらです。Power8はサーバーがすべて標準保守を終えており、Power9のスケールアウト機も2026年1月31日を過ぎました。ここで型番の確認が要ります。同じS924でも、機種タイプが9009-42Aなら2026年1月31日で終了済み、2020年以降の9009-42Gなら終了日は未発表です。モデル名だけでは自社機の当否が判定できないので、必ず機種タイプまで見てください。なおIBMは2025年7月以降、ハードウェアのこの区切りを「End of Service」ではなく「Change of Support Level（サポートレベルの変更）」と呼んでいます。Power10は保守終了が未発表で、販売終了は2026年1月13日付の発表（AD26-0012）で告知されています。標準保守が終わると、予防保守もマシンコードの修正も提供されません。有償のHardware Service Extensionや第三者保守で延命する道は残りますが、費用は上がります。受けられるのは修理対応と提供済みの認定ファームウェアまでで、新しいマシンコードの開発は行われません。部品の枯渇と、対応できる技術者の減少が現実的な制約になります。

ハード世代が決めるOS版の上限

IBM i 7.6が動くのはPower10とPower11の機種だけです。ファームウェアの下限もあり、Power10はFW1060以上、Power11はFW1110以上が必要です。Power9機で上げられるのは7.5まで。Power8機は7.4が上限で、7.5にも7.6にも上がりません。

つまりPower8機を使い続けている企業は、OSの延命だけでは行き止まりです。2026年9月30日に7.4の標準サポートが終わったあとは、有償の延長サポートで2029年9月30日まで引っ張るか、筐体を更改するかの二択になります。筐体側の保守はとうに終わっているので、実質的な選択肢はハード更改を含む移行だけです。

7.3から7.6へ直接は上げられない2段階の経路

版を上げる場合、移行元にも制約があります。IBMが公開している7.6へのアップグレード計画では、有効な移行元はIBM i 7.4と7.5だけです。7.3以前を使っているなら、いったん7.4か7.5へ上げてから7.6へ、という2段階になります。7.5以前から上げるときは、インストール前に2GBの予約ストレージを追加で確保する必要もあります。

ここに前項のハード制約が重なります。7.3をPower8機で動かしている環境は、OSを2段階で上げたうえで筐体も更改することになり、実質は移行プロジェクトです。年内に終わる作業ではありません。なおIBMが公表しているPowerとIBM iのロードマップには7.6の後継リリースも置かれており、プラットフォーム自体が終わるわけではない点は、判断材料として押さえておいてください。

移行と継続の判断基準｜古さではなく保守可能性

経済産業省の定義におけるレガシーの条件

経済産業省 商務情報政策局 情報産業課 情報処理基盤産業室が2025年5月28日に公開した「DXの現在地とレガシーシステム脱却に向けて レガシーシステムモダン化委員会 総括レポート」は、レガシーシステムを「運用維持保守や機能改良が困難な状態に陥り、経営・事業戦略上の足枷、高コスト構造の原因となっているシステム」と定義し、その要因を5つ挙げています（p.7）。技術の老朽化、システムの肥大化・複雑化、システムのブラックボックス化、IT投資がされていない、古い制度としがらみ、の5つです。

同レポートは続けてこう書いています。現行システムがメインフレーム等の古い技術や開発手法で構築されたシステムであっても、開発・運用維持保守体制が整備され、デジタル技術の活用やデータ連携が可能で、仕様が明確で継続的な機能改良が可能な適切な作りであれば、レガシーシステムではないと言える。脱却済みのシステムが再びレガシー化しうる点にも同じページで触れています。

この定義に立てば、「AS/400だから移行する」は判断の根拠になりません。判断軸は保守可能性です。用語のより広い文脈はレガシーシステムとは何か、その意味・定義や歴史的背景、企業経営への影響を現代ビジネスの視点から詳しく解説で整理しています。

継続してよい条件と、今期中に着手すべき条件

継続してよいのは、次の4つがすべて揃っている場合です。

• OSが7.5以上
• 筐体がPower10・Power11、または保守期限が残るPower9（E980）
• RPGやCOBOLを読める要員を社内か保守契約で確保できている状態
• 改修の依頼が回っており、仕様書が現存している状態

この4つが揃っているなら、期限に追われる移行は不要です。一方、次のいずれかに当てはまるなら、今期中に着手してください。

• 筐体がPower8（全機種が標準保守終了済み）
• 7.4のまま2026年9月30日を越える計画しかない状態
• 改修を頼める相手が特定の1社・1名に依存している状態
• ドキュメントが失われ、ソースコードが唯一の仕様書になっている状態

4つのうち先に崩れるのは、たいてい要員です。前掲のレポートが技術の老朽化の説明で挙げているのも、古い要素技術に対応できる技術者が高齢化・離脱し、要員の確保が難しくなるという連鎖でした（p.7）。OSの期限は日付で動きますが、要員の期限は退職や異動で前触れなく動きます。継続を選ぶなら、後任がいつまで確保できるかを期限表と同じ精度で押さえてください。

ここははっきり書きます。「延長サポートで2029年まで持たせる」は移行の代案になりません。延長サポートは標準サポートより費用が上がり、提供されるのは修正だけで新機能はありません。しかもその間、ハード側の保守期限は別の時計で進みます。延長サポートは移行計画を実行するための時間稼ぎであって、意思決定を先送りする手段ではありません。

基幹システム移行の方式選定｜残り時間・資産量・カスタマイズ量

6方式の適性と使い分け

それぞれのリスクは性質が違います。リホストはPower10・Power11機へ載せ替えるだけなので期日には間に合いますが、ブラックボックス化という課題は残ったままです。クラウド移行はIBM Power Virtual ServerのようにIBM iを動かせる基盤を使う経路で、筐体の調達と保守はIBM側が持ちます。ただし基盤の世代は入れ替わり、同基盤のPower9機は2027年12月31日で終わります。OS版の期限も変わりません。IBMのドキュメントは、サポートが切れたOSは基盤上で動作していてもサポート対象外であり、脆弱性や重大な問題が見つかった場合は該当インスタンスを停止しうると明記しています。古い版のまま持ち込むことはできず、現行のサポート水準へ上げてから移行する順序になります。リライトはRPGやCOBOLをJavaなどへ変換する方式で、変換後コードの可読性と、全機能を突き合わせるテスト工数が焦点になります。リビルドは期間と費用が最大、パッケージ移行はカスタマイズによる費用膨張が最大のリスクです。API連携で温存する方式は、IBM i を記録の基盤として残したまま、Webやモバイルの画面・外部システムとの連携だけを外側に作ります。作り替えないので期日には強い一方、OSと筐体の期限は解決しません。前掲の期限表と併せて、時間を買う手段として位置づけてください。オフコン資産をクラウドへ寄せる論点はオフコンのクラウド化が企業のデジタルトランスフォーメーションに与える影響で扱っています。

用語の線引きも先に合わせてください。資産を保ったまま環境を移すのがマイグレーション、作り替えて技術的負債を解消するのがモダナイゼーションです。どちらを発注するかで見積もりの前提が変わるため、マイグレーションとは？リプレイス・モダナイゼーションとの違いと発注判断を解説とモダナイゼーションとは？レガシー刷新の手法と実装アプローチ・進め方を解説で定義を揃えてから引き合いを出すと、提案の比較ができます。RPGと並んでAS/400の資産の中心にあるCOBOLについては、要員確保の見通しをCOBOLはなぜ廃れたと言われるのか？「オワコン」説の真相と、いまも使われ続ける理由で扱っています。

逆算の起点は筐体の保守終了日

最初に決めるのは方式ではなく期限です。筐体の保守終了日とOSの標準サポート終了日のうち早いほうから逆算し、その日までに完了できない方式を候補から外します。残り時間が方式を絞ってくれるので、比較検討の対象は自然に減ります。

次が資産量です。プログラム本数と、画面・帳票・バッチの依存関係が分からないなら、リビルドは見積もれません。分からないものは作り直せないからです。

最後にカスタマイズ量を見ます。前掲の経産省レポートの市場動向調査（回答数333）では、メインフレームを保有していたユーザー企業のうち52%がメインフレーム以外へ移行しており、移行先としてメインフレームやスクラッチよりも標準システム・標準パッケージを選ぶ割合が高いという結果でした（p.17）。同時に、現行システムにカスタマイズを施しているユーザー企業は移行先システムでもカスタマイズを施す割合が高い、とも報告されています。パッケージを選んでもカスタマイズは再発します。移行先にERPを検討するなら、SaaS型ERPとは何か？基本概要・仕組み、導入メリットを徹底解説で標準機能の範囲を確認したうえで、どこまで業務側を標準に寄せるかを先に合意してください。なお同調査では、移行先の形態が未決定のユーザー企業が過半数を占めています。決まっていないのは自社だけではありません。

AS/400移行プロジェクトが繰り返す4つの失敗原因

コストを膨らませる現行機能保証

経産省レポートがモダン化の障壁として挙げた項目のうち上位2つは、既存システムが複雑でモダン化が技術的に困難（データ移行やシステムの相互依存性の課題など）が31%、現行機能保証や、機能踏襲の制約が大きいが24%でした（p.26、回答数59）。標本は小さいものの、加工された自由記述コメントには「現行システムと同様の機能・操作性を移行後のシステムにも要求。カスタマイズが多くなり、導入・運用のコストが高騰」という声が挙がっています。

AS/400の5250画面に慣れた現場ほど、操作性の完全踏襲を要件に入れがちです。これを要件定義の前に外せるかどうかで、カスタマイズ本数に比例して費用が膨らみます。合意を取る相手は現場ではなく、業務プロセスの変更を決められる責任者です。基幹システム刷新が実害に至った例は基幹システム刷新の失敗事例と回避策｜出荷停止と訴訟に至った5件を工程別に分解で工程別に分解しています。

仕様のブラックボックス化と棚卸しの不足

同レポートは対策としてIT資産の可視化を挙げています（p.33）。ハードウェア、ソフトウェア、ネットワーク、データベース、ツールに至るすべてのIT資産と、それらの相互関係を把握することで、老朽化したシステムや保守期限が間近なソフトウェアといった潜在的なリスクを特定できる、という整理です。

長年の改修を重ねたAS/400では、どのバッチがどの帳票を作っているのかが担当者の記憶にしか残っていない例が珍しくありません。棚卸しは移行の準備作業ではなく、方式を選ぶための入力データです。順序を逆にすると、見積もりが後から膨らみます。

経営層と共有する情報の不足

同レポートの調査（p.20、回答数556）は、モダン化が順調な企業は「システムの問題・課題・リスクに留まらず、開発計画や、予算の意思決定に必要な投資対効果・見積に関する情報を経営層と共有している割合が多い」一方、停滞している企業は「レガシーシステムに関する情報を経営層と共有していない割合が多い」と整理しています。

差が出るのは稟議に載せる情報の中身です。「サポートが切れます」だけでは投資判断の材料になりません。期限、想定被害、方式ごとの費用と期間を並べて初めて判断できます。

移行後の再レガシー化

「既にメインフレーム等から脱却済であっても、運用維持保守に問題があれば再レガシー化する可能性がある」というのが同レポートp.7の指摘です。移行はゴールではありません。移行先で仕様書の更新が止まり、改修が特定の担当者に集中すれば、同じ議論を繰り返すことになります。移行計画には、移行後の保守体制と仕様管理の方法を必ず含めてください。同レポートp.47は、オフコンを運用している企業の例として、オフコン業務を段階的に廃止しクラウドサービスへ順次移行する方向性を挙げています。

よくある質問

AS/400のサポートはいつ終了しますか？

AS/400という製品単位の終了日はありません。期限はOSの版と筐体で別々に決まります。OS側はIBM i 7.3が2023年9月30日、7.4が2026年9月30日に標準サポートを終了し、7.5と7.6は終了日が未発表です。ハード側はPower8が全機種終了済み、Power9のスケールアウト機が2026年1月31日で標準保守を終えました。自社の版番号と機種型番を確認して、早いほうの日付を自社の期限としてください。

AS/400とIBM iは何が違いますか？

同じ系譜の改称で、別製品ではありません。1988年発表のAS/400を起点に、現在の正式な区分はハードがIBM Power、OSがIBM iです。AS/400という言い方は現場と検索の慣習として残っています。IBMのサポート情報は製品名ではなくIBM iのリリース番号で公開されているため、期日を調べるときは版番号で引いてください。

AS/400を使い続けることはできますか？

できます。経済産業省が2025年5月に公開したレポートは、古い技術で構築されたシステムであっても、保守体制が整い、データ連携が可能で、仕様が明確で継続的な機能改良ができるならレガシーシステムではないとしています。判断軸は古さではなく保守可能性です。ただし7.4は2026年9月30日で標準サポートが終わり、以降は有償の延長サポート契約がなければ新しい修正が届きません。筐体がPower8の場合は、ハード側の標準保守がすでに終わっています。どちらかに当てはまるなら、契約か更改の判断は先送りできません。

基幹システムをAS/400から移行するとき、どの方式を選べばよいですか？

残り時間から絞り込んでください。筐体の保守終了日とOSの標準サポート終了日のうち早いほうが期限で、その日までに完了できない方式は候補から外れます。期限が迫っていて業務を変えないならリホストかクラウド移行、基幹は変えず周辺だけ作るならAPI連携、資産量が多く仕様書が失われているならリライト、業務そのものを見直すならリビルドやパッケージ移行です。方式を先に決めてから期限を確認する順序にすると、途中で方式を変える羽目になります。

モダナイゼーションとマイグレーションはどう違いますか？

マイグレーションはデータやプログラムといった資産を保ったまま別の環境へ移すこと、モダナイゼーションは老朽化したシステムを現代の技術体系へ作り替えて技術的負債を解消することです。AS/400をPower10機やクラウド基盤へ載せ替えるだけならマイグレーション、RPG資産をJavaへ変換したり業務ごと作り直したりするならモダナイゼーションに当たります。見積もりの前提が変わるため、引き合いを出す前に発注側で定義を統一しておくと、提案の比較ができます。

関連記事

• 基幹システム刷新の失敗事例と回避策｜出荷停止と訴訟に至った5件を工程別に分解
• マイグレーションとは？リプレイス・モダナイゼーションとの違いと発注判断を解説
• モダナイゼーションとは？レガシー刷新の手法と実装アプローチ・進め方を解説
• レガシーシステムとは何か、その意味・定義や歴史的背景、企業経営への影響を現代ビジネスの視点から詳しく解説
• COBOLはなぜ廃れたと言われるのか？「オワコン」説の真相と、いまも使われ続ける理由