マイグレーションの新たな選択肢――フロントエンドだけ今どきのUIに刷新

近年、AS/400などの基幹システムについて「そろそろ何とかしないと」「でも、全部を一気に刷新するのは現実的ではない」といった声を、お客様からいただく機会が増えています。
実際のところ、AS/400は今でも、安定して動き続けているケースも少なくありません。
運用コストもそれほどかからず、「止めたくない」「できれば活かしたい」というのが本音ではないでしょうか。

一方で、こんな課題もよく耳にします。
画面がいまだに黒ベース・キーボード操作中心で、新人がなかなか慣れてくれない。
操作を覚えるのに時間がかかり、教育コストが高い。
他のクラウドサービスや社内Webシステムと比べて、UIが古く感じられる。

そこで私たちが今、強くおすすめしているのが、
「バックエンド（AS/400）は活かしつつ、フロントエンドだけ今どきのUIに刷新する」
というアプローチです。これが、私たちが現時点で最も現実的な選択肢としてご提案している方法です。

バックエンドはそのまま、フロントエンドだけリッチなUIへ

AS/400などの基幹システムをご利用中のお客様とお話ししていると、次のようなご要望をよく伺います。データベースやバッチ処理といった基幹部分は、これまで通りAS/400のまま使い続けたい。一方で、日々ユーザーが触れる画面については、ブラウザで動く「今どきのUI」に変えたい。また、初めてシステムに触れる新人であっても、分厚いマニュアルを読み込まなくても、ある程度は直感的に操作できるようにしたい――といったものです。

こうしたニーズに応えるために、私たちはシステム全体を次のように役割分担して考えます。まず、ユーザーが直接触れるフロントエンド（画面／UI）は、ReactなどのWeb技術を用いて、直感的に操作できるモダンな画面へと置き換えます。一方で、その裏側で業務ロジックやバッチ処理を担っているバックエンドは、AS/400上のRPGやデータベースをこれまで通り稼働させる構成です。

このようにフロントエンドとバックエンドの役割を切り分けることで、現場の使い勝手や新人教育コストといった「ユーザー体験（UX）」の課題に対応しながらも、長年かけて作り込んできた業務ロジックやバッチ処理といった「システム資産」は、大きなリスクを取らずにそのまま活かし続けることができます。全面刷新か現状維持かという二者択一ではなく、リスクと効果のバランスが取れた刷新の形として、有力な選択肢です。

課題は「どこまでがフロントエンドで、どこからがバックエンドか」が見えないこと

ここで必ずぶつかるのが、「そもそも今のシステムは、どこまでが画面側で、どこからがバッチ処理なのか」という疑問です。典型的なAS/400システムでは、1つのRPGプログラムの中に、画面表示や入力チェック、データ更新ロジック、さらには後続バッチの呼び出しまで、あらゆる処理が混在しています。加えて、画面単位の業務フローや、他プログラムとの連携関係がドキュメントとして整理されていないケースも少なくありません。

このような状態では、「フロントエンドだけReactにしよう」「バックエンドはAPI化しよう」といった方針を掲げても、実際にはどこからどこまでをフロントエンドとして切り出し、どこから先をバックエンドとして分離すればよいのかが判然とせず、設計作業がなかなか前に進みません。

ここで力を発揮するのが、既存資産を解析して構造を見える化できるRe : structure AIなどのAI可視化ツールです。

AI可視化ツールで「フロントエンド／バックエンド」を棚卸しする

私たちはレガシーシステムのマイグレーションにおいて、AIを使ったコードの「可視化」と「構造化」を、最初のステップとして位置づけています。

具体的には、まず既存のソースコードをAI可視化ツールに読み込ませます。対象となるのは、RPGなどのプログラムだけでなく、画面定義やバッチジョブ定義など、システムを構成するさまざまな資産です。ツールはそれらを解析し、画面ごとの処理フローを自動的に抽出していきます。たとえば、「どの画面からどのプログラムが呼ばれているのか」「どのテーブルを参照・更新しているのか」「どの箇所でどのようなバリデーションや分岐処理が行われているのか」といった情報が、構造として整理されていきます。

そのうえで、「フロントエンド」と「バックエンド」の候補を仕分けます。画面表示や入力の受付といった部分はフロントエンド候補として、裏側で動く業務ロジックやバッチ処理はバックエンド候補として分類されます。AIが出力した結果をたたき台として、人間が業務の視点からレビューし、必要な補正を行います。たとえば、実際の運用でよく使われるパターンや、ドキュメント化されていない例外処理、担当者の判断に依存している業務ロジックなど、人間にしか分からない前提を踏まえて見直していきます。

ここで重要なのは、AIはあくま「見える化」し、議論の出発点となる「たたき台」を作る役割にとどめ、最終的な境界の引き方や設計上の判断は人間が行う、という役割分担です。このプロセスを踏むことで、本来であれば人手だけでは数カ月かかるようなシステム全体構造の棚卸しが、短期間で済みます。また、フロントエンド刷新の対象範囲も、感覚や思い込みではなく、可視化された構造に基づいて客観的に検討できるようになります。

おわりに：資産は残し、UIだけを変えるという現実的な一歩

AS/400などの基幹システムとしてはまだ十分に使える一方で、UIや操作性の面では時代とのギャップが大きくなりつつあります。しかし、全面刷新に踏み切るにはコストやリスクが大きすぎる――こうしたジレンマを抱えているケースも少なくありません。

「そろそろ何とかしないと」と感じながらも、どこから手を付けるべきか迷っているのであれば、まずは可視化や棚卸しを行い、フロントエンドだけの刷新も有効です。

AS/400やRPGなどの業務ロジックは、簡単には代替できない貴重な資産です。その資産を大切に守りながら、ユーザー体験と開発生産性を次の世代の水準へと引き上げていく――そのための具体的な一歩として、「フロントエンド刷新＋AI可視化」という選択肢を検討してみてはいかがでしょうか。