AS/400（IBM i 7.3）で基幹システムを運用し続けるべきか、それともどこかでモダナイズに踏み切るべきか――。

サポート終了や2025年問題・2027年問題が迫る中で、多くの製造業の情シスが同じ悩みを抱えています。

本記事では、全面リプレイスではなく「分解」と「段階的移行」を軸に、AS/400基幹を現実的にモダナイズしていく考え方と具体的なステップを整理します。

1. なぜ今、製造業のAS/400基幹を見直すべきなのか

まず最初にお伝えしたいのは、AS/400 そのものが「悪者」というわけではない、ということです。

長年にわたり、安定して工場の基幹業務を支え続けてきたからこそ、今も現役で活躍しているケースが多いはずです。

しかし、AS/400 を取り巻く環境と前提条件は大きく変わりつつあります。

技術者の世代交代とノウハウ継承の難しさ

若手エンジニアが AS/400 や RPG を新しく学ぶ機会は少なくなり、ベテラン担当者に依存した状態が続きがちです。

その方が異動・退職した瞬間に、「誰も触れない基幹システム」が一気にリスクとして顕在化します。

サポート・保守コストの増加

ハードウェア保守や OS バージョンの維持、専任要員の確保など、年々「守るためのコスト」が重くなっているという声を多くいただきます。

他システムやクラウドサービスとの連携のしづらさ

工場設備や周辺システムは日々進化している一方で、AS/400 側が容易に API 連携やリアルタイム連携に対応できないケースも少なくありません。

---

現場からは、次のような具体的な悩みもよく伺います。

• 帳票改修のたびに数十万円・数週間かかる
• データが閉じていて、分析や見える化が思うように進まない
• ベンダーに聞かないと、システム全体像や影響範囲が分からない

さらに、タイムリミットという現実的な要因も見過ごせません。

IBM i 7.3（AS/400 7.3）は、すでに標準サポートが終了しており、延長サポートも 2026年9月30日までという公式なタイムラインが公表されています（詳細は IBM のサポート情報 IBM i Release Supportなどを参照）。

いわゆる「2025年問題」「2027年問題」と呼ばれるように、システムやインフラの老朽化・OS のサポート切れ・IT人材不足が一気に顕在化する時期が近づいています。

「いつまで今のままでいられるのか」 を考え、計画的にモダナイズの準備を始めるには、まさに今が適したタイミングだと言えます。

2. AS/400刷新が「一気に全面リプレイス」で失敗しがちな理由

AS/400 を刷新しようとした際によく見られるパターンが、「全部を一度に作り直す全面リプレイス」です。

しかし、製造業の基幹システムにおいては、このアプローチが失敗するリスクが非常に高くなります。

よくある失敗パターンとしては、次のようなものがあります。

• 全機能を一気に作り直そうとして、要件定義だけで数年かかってしまう
• 「現行の画面と帳票をすべて再現する」ことがゴールになり、業務改善につながらない
• 現場の協力が得られず、テストフェーズで想定外の指摘が噴出して混乱する

なぜ、こうした失敗が起きやすいのでしょうか。製造業ならではの事情を考えると、その背景が見えてきます。

生産を止められない／止めるタイミングが限られている

24時間稼働や繁忙期・棚卸など、工場には「システムを止めてよい時間」がほとんどありません。

そのため、「ある日を境に新システムに切り替える」全面リプレイスは、現実的な選択肢になりにくいのです。

長年のカスタマイズにより、誰も全容を把握できていない

その場しのぎの改修や機能追加を繰り返す中で、「なぜこの処理があるのか」を説明できる人がいない機能が少しずつ増えていきます。

こうした状態で全面リプレイスを行うと、「作り直したはずなのに、どこかで重要な抜け漏れが発生する」リスクが高くなります。

現場で「今はうまく回っている」という認識が根強い

情シス側から見ると多くの課題があっても、現場からすると「今の運用に慣れている」「変えるメリットが見えにくい」と感じられることもあります。

このギャップを埋めないまま、いきなり全面刷新プロジェクトを立ち上げても、協力を得ることは難しいでしょう。

こうした理由から、AS/400 のモダナイズは「一発勝負の全面リプレイス」ではなく、リスクをコントロールしながら進める発想が重要になります。また、モダナイズに伴って保守ベンダーを変更する場合には、現行ベンダーからのスムーズな引き継ぎや、社内合意の取り方も並行して検討する必要があります。

3. 失敗しにくいモダナイズの考え方：全面刷新ではなく「分解」と「段階的移行」

では、どのように進めればよいのでしょうか。

キーワードは、「分解」と「段階的移行」です。

まず、AS/400 上のシステムを「ひとつの大きな塊」として捉えるのをやめ、業務ドメイン・機能・データに分けて整理します。

• 業務ドメインの単位で考える
  • 例：受発注管理、在庫管理、生産計画、実績収集、原価管理、請求・売掛 など
• どの機能がどのドメインに属しているか、現場の担当部門と紐づけて棚卸しする
• 「止まると致命的な領域」と「多少止まってもリカバリーしやすい領域」を切り分ける

そのうえで、次のような 段階的モダナイズのステップを検討します。

1. 現状の棚卸し

システム構成図、業務フロー、インターフェース、バッチ処理、マスタ・トランザクションのデータ構造などを整理します。

ここでは「完璧さ」よりも、「プロジェクトを前に進めるために必要な粒度」を意識することがポイントです。

2. リスク度合い・ビジネスインパクトの整理

「止まるとすぐに生産に影響が出る領域」と、「多少の不具合なら運用でカバーできる領域」を切り分けます。

併せて、「この領域を改善すると、どれくらい業務負荷が下がるか」「DX の種になりそうか」といったビジネスインパクトも評価します。

3. 周辺システム・新規要件からクラウド／オープン系に切り出す

いきなり基幹ど真ん中を置き換えるのではなく、周辺の新規システムや情報系の仕組みからモダナイズしていくのが現実的です。

例：生産実績の見える化ダッシュボード、外部とのデータ連携基盤など。

4. データ連携レイヤーを整備し、AS/400 と新システムを「共存」させる期間をつくる

データ連携の仕組みを整えることで、AS/400 と新システムが同時に稼働する「共存期間」を設けられます。

これにより、全面切替ではなく、徐々に負荷とリスクを分散しながら移行できます。

5. 基幹ど真ん中の機能を、最後に慎重に移行する

上記の準備と実績を積み上げたうえで、受発注や在庫・生産計画など、コアな機能の移行に着手します。

すでに周辺領域でモダナイズの成功体験があるため、社内の理解も得やすくなります。

このように、「すべてを一気に変える」のではなく、リスクをコントロールしながら変えられる部分から着手するのが、失敗しにくいモダナイズの基本的な考え方です。

4. モダナイズ先の選択肢：オンプレ継続 / クラウド / ハイブリッド

モダナイズを検討する際、「最終的にどのようなインフラ構成を目指すのか」も重要な論点です。

大きく分けると、次の3つの方向性があります。

(1) オンプレ継続＋局所的なモダナイズ

ハードウェアや OS を一定期間はオンプレで維持しつつ、周辺システムや情報系を少しずつ刷新していくパターンです。

メリット

• 既存運用を大きく変えずに済むため、現場の負担が小さい
• ネットワークやレイテンシの制約が厳しい工場でも採用しやすい

デメリット

• サポート終了や老朽化の根本的なリスクは残る
• 設備投資や保守コストが中長期的にかさみやすい

「何年までオンプレで持たせるつもりか」という前提を明確にしたうえで、計画的に選択することが重要です。

(2) クラウド（例：AWS）への移行

もう一つの選択肢が、AWS などのクラウド環境への移行です。

ここでも、「そのまま移す」のか「構造を見直す」のかでアプローチが変わります。

IaaS 的な「リフト」

まずはサーバーやストレージをクラウドへ移し、アプリケーション構造は極力変えないパターンです。

早期にハードウェア老朽化やデータセンター依存から脱却したい場合に検討されます。

アーキテクチャを見直す「シフト」

マイクロサービス化や API 化、イベント駆動など、クラウドネイティブな設計に踏み込むパターンです。

移行コストは増えますが、将来的な拡張性・保守性・連携性を大きく高めることができます。

製造業の現場では、次のような AWS 活用パターンがよく見られます。

• ファイルサーバーやバックアップのクラウド化
• 生産実績やセンサー情報の集約・分析基盤（データレイク・DWH）
• 外部システムやパートナー企業とのデータ連携 API 基盤

(3) ハイブリッド構成

工場現場とのネットワークやレイテンシを考慮すると、「すべてをクラウドに集約する」のが難しいケースもあります。

その場合、オンプレとクラウドを組み合わせたハイブリッド構成が現実的な選択肢になります。

• 工場近くのオンプレ設備でリアルタイム性が求められる処理を担い、集約・分析・外部連携はクラウド側で行う
• システムの特性や業務要件に応じて、「どこまでをクラウドに出すか」を段階的に検討する

いずれの選択肢を採るにしても、AS/400 からどう段階的に移行していくかをセットで考えることが重要です。

5. プロジェクトを成功させるための5つのポイント

最後に、AS/400 モダナイズプロジェクトを成功させるうえで、特に重要だと考えているポイントを5つに絞ってご紹介します。

経営・事業側を巻き込んだ「目的の言語化」

「OSサポートが切れるから」「ベンダーが高齢だから」といった理由だけでは、社内の合意形成は得られにくいものです。
「生産性向上」「リードタイム短縮」「新しいビジネスモデルへの対応」など、事業側の言葉で目的を定義することが大切です。

情シスだけで抱え込まないプロジェクト体制

情シス主導で進めつつも、現場部門・経営企画・場合によっては営業部門まで巻き込んだ体制づくりが、成功のカギを握ります。
担当者個人の頑張りに依存しないよう、組織としてのプロジェクトにすることが重要です。

「現場の小さな不満」を吸い上げるヒアリング

情シス主導で進めつつも、現場部門・経営企画・場合によっては営業部門まで巻き込んだ体制づくりが、成功のカギを握ります。
担当者個人の頑張りに依存しないよう、組織としてのプロジェクトにすることが重要です。

「現場の小さな不満」を吸い上げるヒアリング

「この帳票、いつも CSV に落として Excel で加工している」「この入力画面は項目が多くて大変」など、現場の小さな不満の中に、モダナイズのヒントが隠れています。
こうした声を丁寧に拾い上げることで、「変える意味」を現場と共有できます。

移行フェーズの詳細なシナリオ（切替手順・ロールバックプラン）

システムの出来そのものと同じくらい、切替・移行フェーズの設計も重要です。
どのタイミングで何を止め、どのデータをどの順番で移し、万が一のときにどうロールバックするか――これらを事前にシミュレーションしておくことで、現場の不安も軽減できます。

ベンダー／パートナー選定のチェックポイント

技術力はもちろん重要ですが、それ以上に「製造業・工場の業務をどれだけ理解しているか」「既存ベンダーとの引き継ぎを円滑に進められるか」といった観点も欠かせません。
提案内容だけでなく、プロジェクトの進め方やコミュニケーションスタイルも含めて見極めることをおすすめします。

C3index が支援できること

シースリーインデックスでは、製造業のお客さまを中心に、AS/400 を含むレガシー基幹システムのモダナイズを多数ご支援してきました。
単なるシステム更改ではなく、「現場に根付く改善」と「将来を見据えたアーキテクチャづくり」を両立させることを大切にしています。

具体的には、例えば次のような形でご支援が可能です。

• AS/400 を含むレガシー基幹の 棚卸し・現状診断
  システム構成・業務フロー・インターフェース・データ構造を整理し、「どこからどう変えていくべきか」の仮説を一緒に描きます。
• 段階的モダナイズ計画の策定支援
  全面リプレイスありきではなく、投資対効果やリスク、社内体制を踏まえた現実的なロードマップをご提案します。
• AWS などクラウド環境を活用した 新システムの設計・開発
  AWS アドバンスドティアサービスパートナーとしての実績を活かし、オンプレ／クラウド／ハイブリッドを含めた最適な構成を検討します。
• 既存ベンダーからの ドキュメント整備・引き継ぎ支援
  現ベンダー様とも連携しながら、ブラックボックス化したシステムの可視化と、スムーズな引き継ぎをサポートします。保守ベンダー変更を検討されている場合も、現行ベンダーからの引き継ぎをどう進めるかのアドバイスが可能です。
• 工場・製造業案件の経験に基づく、現場に寄り添ったプロジェクト推進
  生産現場の事情や繁忙期を考慮しながら、無理のないスケジュールと進め方をご提案します。

よくあるご質問（FAQ）

Q1. AS/400 7.3 のサポート終了までに、最低限やっておくべきことは何ですか？
A. まずは「現状の棚卸し」と「リスクの見える化」です。どの業務・どのシステムが AS/400 に依存しているのか、止まるとどの程度の影響が出るのか、代替手段はあるのか――といった観点で整理することで、「今すぐ着手すべき領域」と「中長期で計画すべき領域」を切り分けられます。

Q2. 一気に全面リプレイスする予算や体制がありません。それでもモダナイズは可能でしょうか？
A. 可能です。本記事でご紹介したように、周辺システムや情報系から段階的にモダナイズを進めるアプローチであれば、投資やリスクを分散しながら進められます。AS/400 と新システムが共存する期間を前提にロードマップを描くことがポイントです。

Q3. オンプレ継続・クラウド移行・ハイブリッド、どれを選べばよいか判断がつきません。
A. 工場のネットワーク事情や求められるリアルタイム性、既存システムとの関係性によって最適解は変わります。まずは現状と制約条件を整理したうえで、複数パターンの構成案を比較検討することをおすすめします。