AS400リプレースは必要か｜IBM iを使い続ける判断と長期ロードマップ

結論から言うと、AS400 / IBM i はまだまだ使い続けられます。むしろ、会計、販売管理、在庫、出荷、請求、基幹バッチのように長年安定して動いている領域では、無理に短期リプレースするより、現行化しながら使い続ける方が安全な会社も多いです。

AS400をリプレースすべきか、先に結論を書きます

AS400 / IBM i のリプレースを検討する時、知りたいことは主に一つです。この基盤をやめるべきなのか、続けてよいのか。先に答えを書きます。

プラットフォーム名だけで、すぐにリプレースが必要だと決める必要はありません。AS400 / IBM i は現役で、IBMも更新を続けています。止まらないこと、動き続けることの価値は、基幹業務を担当したことがある人ほど分かります。25年この現場を見てきて、AS400から他へ切り替えたお客さんは少数です。刷新のタイミングでも、また IBM i を選ぶケースが多いです。

ただしリプレースを検討したほうがよい場合もあります。製品名の古さだけでは決めず、業務要件、性能、保守性、費用、移行リスクを比較します。

整理すると、業務の変化はリプレースを検討する大きな理由ですが、それだけではありません。保守の確保、セキュリティ要件、性能・可用性、連携の制約、維持費も比較します。人と体制の改善、基盤更新、部分改修で解決できるかを確かめたうえで、全面移行も含めて判断します。

作り直しても、同じ問題が戻ってくることがある

いちばん危ないのは、「誰も分からないから作り直す」という判断です。

今のシステムが分からない状態で新しく作ると、仕様を決める材料がありません。結果として今の動きをそのまま移すことになり、なぜその処理があるのかが分からないまま、新しい環境に持ち込まれます。数年後にまた同じ状態になります。

順番としては、読める状態にするほうが先です。それができていれば、リプレースするにしても、残すにしても、判断材料が揃います。ソースを読み解く作業自体は、今はAIで短縮できます。

私が保守で重視しているのは、担当者の退職や属人化に備えて、業務知識と調査手順を残すことです。これはOSや機器の制約がないという意味ではありません。後半では、人・基盤・業務の三つを分けてロードマップを考えます。

ロードマップを作る前に、現場で聞いておきたいこと

AS400を長く使うかどうかは、単に「古いから危ない」「新しいから安心」では決まりません。現場で止まると困る処理、分かる人が少ない操作、帳票やCSVの受け渡し、夜間バッチの確認方法を洗い出すと、残す部分・直す部分・教育する部分が見えてきます。

• 止められない業務、月次・年次だけ動く処理、担当者しか知らない操作を確認する
• 帳票、CSV、外部連携、5250接続など周辺の依存関係を並べる
• 研修で標準化する範囲と、外部に状況整理を依頼する範囲を切り分ける

後継者育成を先に進めるなら若手向けAS400研修カリキュラム、現状の棚卸しから相談したい場合はお問い合わせへ進んでください。法人契約・NDA前提の相談にも対応できます。

ただし、「まだ使える」は「何もしなくてよい」という意味ではありません。OSバージョン、Powerサーバー、PTF、バックアップ、セキュリティ、RPG/CLの保守体制、周辺システム連携、人材継承を計画的に整えていくことが前提です。放置したAS400は危ないですが、管理されたIBM i は長期利用に向いた基盤です。

IBM iは現在も更新されている現役の基盤

IBM公式のIBM iページでは、IBM iはミッションクリティカルなワークロードと新しい取り組みを支える統合型のアプリケーション基盤として紹介されています。OS、データベース、ミドルウェア、セキュリティ、実行環境などが統合されている点もIBM iの強みです。

また、IBM i 7.6 のデータシートでは、セキュリティ、アプリケーション開発、データベース、管理機能の強化が説明されています。MFA、Navigator、Db2 for i、IBM i Services などの改善を見ると、IBM iは過去の遺産として止まっているのではなく、現行のPower環境で使い続けるために更新されている製品だと分かります。

参考: IBM i 公式製品ページ / IBM i 7.6 データシート

計画の起点は、自社リリースのサポート期限

何年使えるかを考える時、最初に押さえるのは自社が動かしているIBM iリリースの期限です。ここが決まらないと、5年計画の起点が決まりません。

2026年7月時点でIBMが公開しているリリースライフサイクルは次のとおりです。

ここで見落とされやすいのが、「未告知」は「もうすぐ終わる」ではないということです。IBMは標準サポートの終了日を事前に告知します。つまり7.5と7.6を使っている場合、少なくとも告知が出るまでの猶予があります。あわてて全面移行を決める必要はありません。

逆に7.4以前を動かしている場合は、期限が具体的に見えています。有償のService Extensionで延ばす選択肢もありますが、費用がかかり続けるので、いつまで払うのかを先に決めておくほうが判断しやすくなります。

自社のリリースを確認する

まず自社が何を動かしているかを確認します。名前だけで判断せず、実機で見てください。

DSPPTF
DSPSFWRSC
WRKPTFGRP

DSPPTF の画面上部、または DSPSFWRSC でリリースが分かります。WRKPTFGRP ではPTFグループの適用レベルを確認できます。最新の期限はIBM Release life cycleで確認してください。期限は変更されることがあるため、判断する時点で公式を見るのが確実です。

期限から逆算して計画を置く

OSの保守期限と、担当者・業務知識を維持できる期間は別です。どちらが先に制約になるかは会社ごとに違います。更新・教育・外部保守を同じ年表に置き、準備期間を含めて判断してください。

使い続けるかどうか、25年見てきた立場からの答え

結論から言うと、一度使うと良さが分かって、やめられなくなります。理由は安定性です。ここが大きい。

運営者が見てきた範囲では、AS400から他のプラットフォームへ切り替えるお客さんは少ないです。多くは、現行システムを刷新するタイミングでも、また AS400 / IBM i を選んでいます。市場全体の統計ではなく、あくまで25年の現場で見てきた範囲の話ですが、この傾向ははっきりしています。

ただし正直に書くと、この良さは一回使ってみないと分からないと思います。外から見ると緑画面の古いシステムに見えますし、資料を読んでも伝わりにくい部分です。実際に運用してみて初めて、止まらないことがどれだけ楽かが分かります。まだ触ったことがない場合は、無料で触れる公開環境で感触をつかむこともできます。

弱点はプラットフォームではなく、人

私の経験では、仕様を知る担当者がいなくなることは大きなリスクです。社内で誰がどの処理を調べられるか、外部保守を確保できるかを、機器・OSの保守条件と一緒に確認してください。

つまり「AS400を使い続けられるか」という問いは、実際には「読める人を確保し続けられるか」という問いです。OSの期限を心配するより、担当者が辞めた後にRPGやCLを誰が読むのかを心配したほうが、現実に即しています。

減った人数を、どう補うか

人を増やすのが難しいなら、一人あたりが読める量を増やすしかありません。運営者がCodexを使っているのはそのためです。ソース解析と資料生成が速くなれば、少ない人数でも既存システムを追えます。

ただしCodexをAS400保守で使う場合にも書いたとおり、AIは判断を代わりにやってくれる道具ではありません。出てきた結果が正しいかを見極められる人がいて初めて速くなります。だから人の代わりではなく、いる人の能力を伸ばす方向で使います。

この使い方を現場で回せるようにする研修も用意しています。御社の環境とソースを使って、RPG/CLの読解から影響調査までを実際に行う形です。内容と料金はAS400 / IBM i Codex実戦研修の研修内容・料金で確認できます。

AS400を長く使う時の基本方針

長期利用の方針は、「全部そのまま残す」でも「全部捨てる」でもありません。基幹処理は守り、古くなった部分だけ順番に現行化します。画面、帳票、外部連携、データ抽出、権限、監視、ドキュメント化を少しずつ整える進め方が現実的です。

0-1年目：まず現状を見える化する

最初にやるべきことは、リプレース検討ではなく現状把握です。AS400は長く動き続けるため、担当者が交代しても「何が動いているか」「止まると何が困るか」が曖昧になりがちです。

• IBM i のバージョン、Power機種、保守契約、PTF適用状況
• 夜間バッチ、ジョブスケジュール、MSGW（メッセージ応答待ち）、QSYSOPR、重要スプール
• バックアップ方式、復元手順、DR時の優先順位
• RPG、CL、QUERY、物理ファイル、論理ファイル、外部連携
• 退職者ID、共有ID、特別権限、監査ログ

この段階では、AS400のバージョン・PTF・サポート確認手順、AS400バックアップ・復旧チェックリスト、AS400夜間バッチ障害対応フローを先に確認しておくと、長期ロードマップの土台が作りやすくなります。

1-3年目：止めない運用から、引き継げる運用へ変える

AS400は「止まらないから大丈夫」と思われがちですが、止まっていない時ほど運用を整える余裕があります。長期利用で怖いのは機械そのものより、誰も仕様を説明できない、障害時にジョブログを読めない、メッセージ待ちに適切に返信できない、といった人と運用の問題です。

1-3年の間に、ジョブ監視、MSGW検知、QSYSOPR確認、スプール滞留確認、月次点検、権限棚卸を定例化します。若手や兼任担当者でも追えるように、コマンドの意味、確認画面、判断基準、連絡先を残すことが大切です。

運用面は AS400保守・運用ガイド、学習順は AS400初心者向け学習ロードマップ、症状別の入口は AS400トラブル逆引き索引から見ると整理しやすいです。

3-5年目：IBM i更新と周辺システム連携を計画する

3-5年の範囲では、Powerサーバー更新、IBM iバージョン更新、PTF運用、クライアント接続、外部インターフェースを計画に入れます。古い5250画面をすべてWeb化する必要はありませんが、CSV連携、IFS、ODBC/JDBC、API、BI、帳票出力など、周辺だけを現代的にする余地はあります。

この時期に重要なのは、「リプレースするか、使い続けるか」を感情で決めないことです。会計・在庫・出荷・請求のように業務ルールが深く埋まっている場合、移行費用、テスト範囲、現場教育、並行稼働、障害時対応まで含めて比較する必要があります。

判断材料は AS400業務ヒアリングシート、現行化の進め方は AS400連携とは、RPG資産を活かす方針は AS400 RPG資産のWeb化・現代化の始め方を参考にしてください。

機種を入れ替えた後は、全機能の動作確認をしてください

AS400 / IBM i は「マシンを入れ替えても、今までのアプリはそのまま動く」と言われます。他の基盤と比べれば、実際に互換性は高いです。ただし、それを信じて事前テストを省くのは危険です。

互換性が高いといっても、バージョンの違いで動かなくなる要素はあります。

• CLに組み込んでいるコマンドのパラメーターが変わっている
• SQLで使用できる内容が変わっている

どちらも「こちらは何も変えていないのに動かない」という形で出ます。移行作業そのものが予定どおり終わっていても、業務が回らなければ意味がありません。

私が関わった更改では、切り替え後に問題が起きたことはありません。ただしそれは運が良かったからではなく、事前に全機能のテストをしていたからです。「基本的には動く」は「全部動く」ではありません。

夜間バッチ、帳票、外部連携のように普段は目に入らない処理ほど、テストの対象から漏れやすい部分です。先に機能の一覧を作ってから当たる方が確実です。なお、更改を主導していたのは情報システム部門でした。基幹側は当日の待機や、確認作業への同席という形で関わっています。

そしてテストをしておく理由がもう一つあります。更改のあとにアプリの動きが遅くなると、ハード側とアプリ側で責任のなすりつけ合いが始まります。どちらも「うちの問題ではない」と言うので、その間は誰も直しません。

これを短く済ませるには、更改の前後で同じ処理が同じくらいの時間で終わることを記録しておくのが有効です。数字があれば、どちら側の話なのかを議論ではなく事実で切り分けられます。

5年以上：基幹は残し、周辺を育てる

5年以上の長期利用では、AS400 / IBM i を「古いから残っているもの」ではなく、「会社の業務ルールが蓄積された基幹資産」として扱います。基幹処理はIBM iで安定稼働させ、周辺の参照、集計、問い合わせ、教育、ドキュメント化は外部ツールやAIも使って補完します。

この方針なら、無理に全移行して失敗するリスクを避けながら、現場が困っている調査時間、属人化、引き継ぎ、ドキュメント不足を減らせます。AS400を使い続けることは、変化しないことではありません。重要な処理を守りながら、周辺を少しずつ変えていくことです。

長期利用でやってはいけないこと

• 古いOSやPower機種のまま、保守期限を確認せず使い続ける
• バックアップは取っているが、復元テストをしていない
• 夜間バッチやMSGWを、特定の担当者の経験だけに頼る
• RPG/CLソース、テーブル、帳票、外部連携の一覧がない
• AS400を知らない人だけで、短期リプレース計画を決める
• AIにソースや顧客情報をそのまま貼り付ける

AIやCodexは「調査時間を減らす道具」として使う

AS400の長期利用では、AIやCodexを「IBM iを置き換えるもの」と考えるより、調査時間を減らす道具として使う方が現実的です。ジョブログの読み解き、RPG/CLの処理説明、影響調査の観点出し、障害報告書の下書き、引き継ぎ資料の整理には向いています。

一方で、実データ、会社名、ユーザーID、ライブラリ名、顧客名、取引先情報をそのまま入れる運用は避けるべきです。AI活用は、マスキング、レビュー、承認、社内ルールを決めてから始めます。詳しくは AS400のRPGソースをAIに読ませる時の注意点 と AS400のRPGソースをAIに読ませる時の注意点｜本番データ・機密情報を守る考え方を確認してください。

最初に見るべき判断軸

継続利用が向いているケース

AS400を使い続ける価値が高いのは、販売管理、在庫、出荷、請求、会計、製造、物流など、会社独自の業務ルールが深く入っている場合です。長年の改修で現場に合っているシステムは、単純なパッケージ置き換えでは再現できないことがあります。

• 現場業務がAS400の処理順に沿って安定している
• 夜間バッチ、締め処理、帳票、マスター更新が業務に合っている
• 短期リプレースするとテスト範囲が広すぎる
• 周辺だけWeb化、CSV化、BI連携すれば不満を減らせる
• 既存RPG/CL資産を読める担当者が残っている

この場合は、全部を捨てるより、AS400長期ロードマップに沿って、現行化、監視、ドキュメント化、人材継承を進める方が現実的です。

リプレース検討を強めるケース

一方で、AS400を残すことが目的化している場合は注意が必要です。保守期限が不明、バックアップから戻せない、担当者が退職予定、連携仕様が分からない、改修のたびに障害が出る、といった状態なら、継続利用にもコストとリスクがあります。

• IBM iのバージョンやPower機種の保守状況が不明
• 復元テストを何年もしていない
• RPG/CLの影響調査ができず、小変更でも怖い
• 現場がExcel二重入力や手作業で補っている
• 外部システム連携の責任範囲が曖昧

この状態では、継続するにしても先に棚卸が必要です。いきなり移行プロジェクトを始めるのではなく、対象業務、プログラム、ファイル、帳票、連携、権限、バックアップを整理してください。

まとめ：AS400はまだ使える。だからこそ計画が必要

AS400 / IBM i は、保守体制と更新計画を整えることで継続利用を検討できる基盤です。ただし、長期利用の実現条件は「何も変えないこと」ではありません。OS、Power、PTF、バックアップ、権限、監視、人材、ドキュメント、周辺連携を計画的に整え、基幹処理を守りながら現場の負担を減らすことです。

まずは現状棚卸から始め、1-3年で運用を引き継げる形にし、3-5年でIBM i更新と周辺連携を計画し、5年以上は基幹を残しながら周辺を育てる。この進め方なら、AS400は「古いシステム」ではなく、会社の業務を支える長期資産として活かせます。

AS400を長く使い続けるための実務ロードマップ

AS400 / IBM i は、保守体制と更新計画を整えることで継続利用を検討できる基盤です。ただし「古いまま放置する」のではなく、止められない業務、保守体制、更新計画、周辺改善を分けて整える必要があります。

長期利用の判断では、リプレースするかどうかを急ぐ前に、今のAS400がどの業務を守っているかを棚卸しします。特にEDI、締め処理、在庫、売上、請求のように相手先や月次業務へ影響する処理は、安易に置き換えるより、まず止めない設計と引き継ぎを整える方が現実的です。

長期利用で次に確認すること

周辺システムを入れ替える時は、移すデータそのものの品質も見ておきます。AS400データ移行の品質チェックで、文字コード・桁・日付・マスター不整合の見方を整理しています。

AS400を使い続けるかどうかは、古い・新しいだけでは判断できません。業務に合っているか、止めた時の影響が大きいか、保守できる人と手順を残せるか、移行より周辺改善の方が効果的かを分けて見ます。

• AS400はあと何年使えるのかを確認する
• AS400サポート終了はいつ？｜IBM i 7.4・7.5・7.6の保守期限と確認手順
• AS400連携とは｜IBM iをWeb API・外部システムにつなぐ考え方
• AS400保守会社に相談する前のチェックリスト｜障害・小改修・データ抽出・リプレースで整理すること

外部の製品情報を確認する場合は、現在の製品名である IBM i公式ページ もあわせて確認してください。