2026年8月19日 • 日本ビビファイ株式会社 • 読了目安 8分
PowerBuilder からの移行ガイド — 選択肢と現実的な進め方
PowerBuilderで作られた業務システムは、いまも多くの企業で現役です。安定して動いている一方で、共通する悩みも聞こえてきます。開発を担ってきた技術者が引退の時期に入り、PowerBuilderの人材は採用が難しく、業務を支えるロジックはDataWindowの中に閉じ込められていて、誰も安易には触れない。開発元のAppeonがサポートを続けているとはいえ、「サポートが続いている」ことと「この先10年の事業を乗せる基盤として良い」ことは別の話です。
本記事では、PowerBuilderシステムを移行する現実的な選択肢と、それぞれが向くケースを率直に整理します。
PowerBuilderの移行が難しい理由
PowerBuilderの移行は、他のレガシー移行と比べても独特の難しさがあります。理由は言語そのものより、その作りにあります。
- DataWindow。 PowerBuilder特有のDataWindowは、SQL・データバッファ・入力検証・画面表示を一つのオブジェクトに束ねています。業務ロジックの多くは、整理されたクラスではなくこのDataWindowの中にあります。PowerBuilderの移行は、その大半がDataWindowの移行だと言っても過言ではありません。
- クライアントサーバー前提。 PowerBuilderのアプリは、状態を持つデスクトップクライアントがデータベースに直接つながる構成を前提にしています。Webへ移すということは、ブラウザ・API・データベースという境界を引き直すことであり、見た目だけの変更ではなく、アーキテクチャの変更を伴います。
移行の選択肢
| 選択肢 | 概要 | 期間 | リスク | 向くケース |
|---|---|---|---|---|
| 継続保守 | PowerBuilderのまま使い続ける | （つなぎ） | 年々上昇 | 短期のつなぎとしてのみ |
| Appeonでweb化 | 既存アプリをブラウザ向けにビルド | 短〜中 | 小〜中 | Web化はしたいが、PowerBuilderは離れない |
| リライト（再構築） | モダンな技術で一から作り直す | 長 | 大 | 規模が小さい、または業務を見直す |
| 自動変換 | ソースを解析しモダン技術へ機械変換 | 中 | 小〜中 | 残したい大規模システムを標準技術へ |
継続保守
計画的なつなぎとしてのみ妥当です。待つほど人材は減り、属人化のリスクは高まります。買った時間は、移行を避けるためではなく、移行を準備するために使うものです。
Appeonでweb化
AppeonのツールはPowerBuilderアプリを比較的少ない改修でブラウザに載せられます。これは「配信」の課題、つまり利用者がWebで使えるようにする問題を解決します。ただしコードはPowerBuilderのままなので、保守性や採用の課題は残ります。「とにかくブラウザで動かしたい」場合には有効ですが、標準的で自社が保有できるコードを手に入れるという意味での刷新ではありません。
リライト（再構築）
要件から作り直せば、望みどおりのシステムが手に入ります。一方で、選択肢の中では最もリスクが高く、期間も長くなります。大規模なPowerBuilderシステムでは、長年ドキュメント化されてこなかった業務ルールをDataWindowから人手で読み解くことになり、そこで再構築の期間は静かに膨らみます。規模が本当に小さい場合や、業務プロセスそのものを作り替えたい場合に向いています。
自動変換
自動変換は、PowerBuilderの実ソース（ウィンドウ、DataWindow、埋め込みSQL、PowerScript）を解析し、モダンな等価物を生成します。当社の場合は、標準的な TypeScript / React などのクリーンなコードです。ツールが人手を介さず完璧なコードを書くという話ではありません。要点は、業務ロジックを記憶からの再構成ではなく、実際のコードから引き継げることです。残して動かし続けたい大規模なPowerBuilderシステムにとって、採用可能な技術スタックへ移る、最もリスクの低い道になることが多い手法です。
自動変換が向くケース・向かないケース
公平を期すために、自動変換が万能でないことも明確にしておきます。
向くケース
- DataWindowに業務ロジックが厚く、資産として保全したい
- 仕様書が現状と乖離し、仕様復元のコストが読めない
- 業務を止められず、段階的に移行したい
向かないケース
- 画面数が少なく小規模（→ 再構築やパッケージの方が速い）
- どのみち業務を抜本的に見直す（→ 再構築で業務改革とセットに）
進め方の判断
PowerBuilderの移行は、次の3つの問いでおおむね方向が決まります。
- DataWindowに未文書の業務ロジックがどれだけあるか。 多いほど再構築で失うリスクが高く、自動変換の価値が上がります。
- 移行中もシステムを動かし続ける必要があるか。 一括の再構築と、止められない業務は相性が良くありません。
- 最終的に何が欲しいか。ブラウザか、自社が保有できるコードか。 Web化はブラウザを、自動変換や再構築は標準的なコードと通常の採用市場をもたらします。
移行を決める前に、自社のPowerBuilderシステムがモダンなコードとしてどう見えるかを確かめたい場合は、実際のコードの代表的な一部を対象に、範囲を固定したPoC（概念実証）から始めるのが定番です。DataWindow上で自動変換が実際にどう動くかを、説明ではなく実物で確認できます。Code Transformer について、お気軽にお問い合わせください。
モダナイゼーション手法の全体像はアプリケーションモダナイゼーションの主要アプローチ5選で、再構築と自動変換の比較は再構築か、自動変換かで解説しています。