LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

PowerBuilderとは？DataWindow・PowerScriptとAppeon体制で続く現行製品

PowerBuilderとは、DataWindowと呼ばれる独自のデータ表示・更新コンポーネントと、PowerScriptという専用言語を中核に据えた、クライアント/サーバー型業務アプリケーションの開発ツールです。DataWindowはDataWindowペインターと呼ばれる専用の設計画面で作成し、ウィンドウやユーザーオブジェクトに配置したDataWindowコントロールから参照する仕組みで、データベースの情報を表示・操作・更新する役割を担います^*5。

ここでまず押さえておきたいのは、PowerBuilderという製品そのものが終息・廃止されたわけではないという点です。2016年7月5日にSAPとAppeonの間で契約が締結され、以降はAppeon社が独立した企業としてPowerBuilderの開発・販売・サポートを担う体制が続いています^*4。公式製品ページでは最新版として「PowerBuilder 2025 R2」が案内されており、オンプレミスとクラウドの両方に対応した開発が可能とされています^*1。つまり多くの企業が向き合うべき課題は「ツールが消えた」ことではなく、「旧バージョンで作られた個別資産」と「それを保守できる人・体制」の側にあると整理できるでしょう。

Appeonの製品ページには、Professional・CloudProという2つのライセンス体系が案内されており^*1、クラウド対応を前提としたラインアップが公式に用意されていることが確認できます。裏を返せば、旧バージョンのまま更新を止めているPowerBuilder資産は、こうした最新のセキュリティ強化やクラウド対応の恩恵を受けられていない可能性が高いということでもあるでしょう。

クライアント/サーバー2層構成が抱える運用・セキュリティ上の制約

PowerBuilderで開発された業務アプリの多くは、クライアント端末からデータベースへ直接接続する、いわゆる2層のクライアント/サーバー構成を採用しています。Appeon公式もこの構成について、リモートアクセスにはVPNや仮想デスクトップ（VDI）を介する必要がある点や、それに伴う典型的な制約・手間があることを前提として説明しており、クラウドネイティブなPowerServerへの移行によってそうした制約を解消できるとしています^*7。

クライアント端末からデータベースへ直接アクセスする経路は、セキュリティ管理の観点でも懸念材料になりやすいところです。Appeon公式は、PowerServerを使うとSQL文とDataWindowが自動的にREST APIへ分割され、ファイアウォールの内側で実行される設計になると案内しています^*2。つまり従来のクラサバ構成のままでは、社外からのアクセスや複数拠点でのクラウド活用を進めようとしても、VDIの運用負荷や直接DB接続の管理という壁にぶつかりやすい構造だと言えるでしょう。

在宅勤務や拠点統合を進める企業にとって、この2層構成の制約は業務効率化の足かせになりがちです。特にVDI環境の維持コストやライセンス管理は、利用者数の増減に応じて調整しづらく、システム部門の負担として蓄積していく傾向があります。

継続リスクの正体―DataWindow・PowerScript技術者の高齢化と希少化

PowerScriptはDataWindowを中心に設計された専用言語であり、JavaやC#といった汎用言語と比べると、習得している技術者の絶対数がもともと限られています^*5。国内の多くのPowerBuilder資産は1990年代から2000年代にかけて構築された経緯を持ち、当時の要件定義から開発までを担った技術者が定年退職や転職の時期を迎えつつあります。

設計書が十分に整備されないまま「動いているコード」だけが残っている現場では、DataWindowの複雑な計算式やPowerScriptで書かれたビジネスロジックの意図を理解できる人材が、後任に一人もいないという状況に陥りかねません。属人化した資産は、担当者の異動や退職という一度きりの出来事によって、保守そのものが止まってしまうリスクをはらんでいます。

こうした技術者不足は、PowerBuilderという製品そのものの評価とは切り離して考える必要があります。前述の通りAppeonは開発を継続していますが^*4、市場で新規にPowerScriptを学ぶ技術者が潤沢に育っているとは言い難く、既存の有識者を確保・育成できるかどうかが、資産を延命するうえでの実務的なボトルネックになりやすいのが実情です。

Appeon公式ロードマップが示す現行PowerBuilderの開発状況

Appeonの公式ロードマップでは、現行版として「PowerBuilder 2025 R2」が案内されており、新機能や改善は10〜12ヶ月周期のアジャイルなリリースサイクルで提供され続けているとされています^*3。次期の「PowerBuilder 2025 R3」では、コード補完やDataWindow開発を支援するAI連携機能、ARMプロセッサへのランタイム対応、ASLR・DEP/NX・CFGといった実行ファイル保護機能の拡張などが計画として挙げられています^*3。

これらの計画は、PowerBuilderという製品自体が終わった技術ではなく、現在進行形で機能強化が続いていることを裏づけるものです。裏を返せば、こうしたセキュリティ強化や開発生産性の向上は最新版でのみ享受できるものであり、数世代前のバージョンに留まったままの資産では、これらの恩恵から取り残されていく点に注意が必要でしょう。バージョンそのものの是非よりも、「自社の資産がどのバージョンで止まっているか」を把握することが、リスク評価の出発点になります。

モダナイゼーションの選択肢を整理する

選択肢1：最新のAppeon PowerBuilderへアップグレードする

DataWindowやPowerScriptで書かれた既存資産を活かしたまま、開発環境そのものを最新版に更新する方法です。IDEの操作性向上やセキュリティ機能の強化を享受できる一方、クライアント/サーバー2層構成自体は基本的に維持されるため、前述したVDI運用やリモートアクセスの制約は残る点に留意が必要です。

選択肢2：Appeon PowerServerでWeb・クラウド化する

Appeon PowerServerは、既存のPowerBuilderアプリをコード変換の手間をほぼかけずに、クラウドネイティブなアーキテクチャへ自動変換する製品です。ASP.NET Coreをベースにしたステートレス設計でREST APIを介した実行に対応し、DataWindowを含む「ほぼすべての既存機能」を自動的に変換すると案内されています^*2。開発・保守はPowerBuilderのIDEを使い続けられるため、新しい言語や環境を一から習得する必要がなく、既存のPowerScript資産と開発スキルを活かせる点が特徴です^*7。

選択肢3：.NETやWebへ全面リライトする

DataWindowやPowerScriptの資産を土台にせず、要件を洗い出したうえで.NETやJava、Webアプリケーションとしてゼロから再構築する方法です。Appeonは以前、PowerScriptのビジネスロジックをC#へ移植する自動変換ツール「PowerScript Migrator」を提供していましたが、公式サイトではバージョン2025での提供終了が案内されています^*6。全面リライトを選ぶ場合は、自動変換ツールの提供状況が変わり得ることを踏まえ、移行方式やパートナーの選定を個別に確認する必要があるでしょう。

3つの選択肢は、それぞれ「資産の再利用度」と「クラサバ構成からの脱却度合い」のバランスが異なります。業務の継続性を優先するのか、将来的な拡張性を優先するのかによって、最適な選択肢は変わってくるはずです。

内製と外注のコスト構造比較

PowerBuilder資産のモダナイゼーションを内製で進める場合と、外部パートナーへ委託する場合とでは、必要なスキルとリスク対応の重心が異なります。以下の表に主な違いを整理しました。

移行を進める3ステップ

STEP1：現状棚卸し

まず着手すべきは、現行資産の棚卸しです。使用中のPowerBuilderバージョン、DataWindowオブジェクトの数と複雑度、PowerScriptで書かれたビジネスロジックの範囲、外部システムとの連携有無を洗い出します。この段階で属人化している箇所や、ドキュメントが失われている画面を可視化しておくと、後続のリスク評価がしやすくなります。

STEP2：移行方式の選定

棚卸しの結果をもとに、最新版へのアップグレード、Appeon PowerServerによるWeb・クラウド化、全面リライトのいずれかを選びます。業務要件の変化が少なく資産を活かしたい場合はPowerServer、業務プロセス自体を刷新したい場合は全面リライトというように、目的に応じた判断軸を持つことが重要です。

STEP3：段階移行・検証

全画面を一斉に切り替えるのではなく、利用頻度や重要度の低い画面から段階的に移行し、DataWindowの表示・更新ロジックが意図どおりに動作するかを個別に検証します。段階移行を踏むことで、万一の不具合が業務全体に波及するリスクを抑えながら、本番切替へと進めていけます。

外注先選定で確認すべきポイント

外部パートナーを選ぶ際は、まずDataWindow・PowerScriptの実務経験があるかどうかを確認する必要があります。PowerBuilder特有の仕様を理解していないパートナーでは、DataWindowの計算式やエラー処理の意図を読み解く工程に想定以上の時間がかかることがあります。

加えて、Appeon PowerServerの導入実績、REST API設計や.NET/C#といった移行先技術への知見、そして移行後の運用・保守まで一貫して対応できる体制があるかも重要な確認事項です。移行プロジェクトは本番切替がゴールではなく、その後の安定運用まで見据えたパートナー選びが求められるでしょう。

まとめ：PowerBuilder資産刷新の3つの判断軸

本稿では、PowerBuilder資産が抱える継続リスクとモダナイゼーションの選択肢を、Appeon公式の製品情報・ロードマップに基づいて整理しました。要点は次の3つに集約されるでしょう。第一に、PowerBuilderはAppeonが開発・販売・サポートを継続する現行製品であり^*4、リスクの本体は製品の存続ではなく老朽化した資産とDataWindow・PowerScript技術者の高齢化にあります。第二に、モダナイゼーションにはアップグレード・PowerServerによるWeb/クラウド化・全面リライトという3つの選択肢があり、資産の再利用度とクラサバ構成からの脱却度合いのバランスで選定します^*2。第三に、クライアント/サーバー2層構成の運用・セキュリティ制約を踏まえ、現状棚卸しから始める3ステップと、内製・外注の判断軸を早期に定めることが移行を成功させる鍵になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Appeon公式「PowerBuilder」製品ページ（https://www.appeon.com/products/powerbuilder）
2. *2　出典：Appeon公式「PowerServer」製品ページ（https://www.appeon.com/products/powerserver）
3. *3　出典：Appeon公式Developers Roadmap（https://www.appeon.com/developers/roadmap）
4. *4　出典：Appeon公式ニュース「Appeon Signs Agreement with SAP to Bring Major Innovations to PowerBuilder」（https://www.appeon.com/company/news/appeon-signs-agreement-sap-bring-major-innovations-powerbuilder.html）
5. *5　出典：Appeon公式ドキュメント「DataWindow control」（PowerBuilder 2025）（https://docs.appeon.com/pb2025/objects_and_controls/DataWindow_control.html）
6. *6　出典：Appeon公式「PowerScript Migrator」製品ページ（https://www.appeon.com/products/powerscript-migrator）
7. *7　出典：Appeon公式「PowerServer FAQs」（https://www.appeon.com/products/powerserver-faqs.html）

Tweet