【Web エンジニア向け PB 入門】第 2 回：PBL とは？プロジェクト構造と Git 管理の統合

テクニカルブログ

2026.07.06

第 1 回では、PowerBuilder (PB) が「データ駆動型開発」において、いかに強力なポテンシャルを持っているか、その思想的な背景をお伝えしました。

続く第 2 回では、いよいよ開発の第一歩、「開発環境の構造」に踏み込みます。VS Code や IntelliJ を使いこなし、ディレクトリ構造やパッケージ管理にこだわりを持つ Web エンジニアにとって、PowerBuilder のプロジェクト構成は初見では異質に映るはずです。

しかし、その構造の裏にあるロジックを読み解けば、大規模開発を支えるための合理的な設計が見えてきます。

1. Web エンジニアを困惑させる「PBL」というブラックボックス

Web 開発の世界では、プロジェクトの構成要素はすべて「ファイル」として可視化されています。.ts、.scss、.json といったファイルがディレクトリごとに整然と並び、それをエディタで直接編集するのが当たり前です。

一方、PowerBuilder IDE をインストールして最初に驚くのは、「ソースコードがバイナリファイルの中に格納されている」という事実でしょう。

PowerBuilder の基本単位は、PBL (ピブル：PowerBuilder Library) と呼ばれるファイルです。

Web の世界
src/components/Button.tsx (テキストファイル)
PowerBuilder の世界
common_ui.pbl というファイルの中に u_btn_search というオブジェクトが含まれている

PBL は、ソースコード、コンパイル済みのバイナリ、そしてリソースを一つにまとめた「コンテナ」のような役割を果たします。Web エンジニアからすれば「中身が見えないのは不安だ」と感じるかもしれませんが、これは PowerBuilder が「統合開発環境」として、高速な検索と増分ビルド (変更した箇所だけを即座に反映させる仕組み) を実現するために最適化された結果なのです。

とはいえ、Web エンジニアの皆さんにとってソースコードをプレーンテキストで扱えないデメリットを感じることもあるでしょう。PowerBuilder もバージョン 2025 以降ではこのようなバイナリでの管理だけでなく、プレーンテキストで管理する方式を選択することも可能になっています。

2. プロジェクトの階層構造：Web スタックとの対比

PowerBuilder の管理構造を、Web 開発でお馴染みの概念に読み替えてみましょう。階層は上から順に以下のようになっています。

PowerBuilder の概念	説明	Web 開発でのイメージ
ワークスペース (.pbw)	開発環境の最上位単位。複数の Target を束ねる。	VS Code の「マルチルート・ワークスペース」
ターゲット (.pbt)	実行単位 (exe やライブラリ)。依存関係を定義する。	package.json を持つ個別のプロジェクト
ライブラリ (.pbl)	オブジェクトを格納する物理ファイル。	src/ 配下のディレクトリ、または内部パッケージ
オブジェクト	ウィンドウ、データウィンドウ、関数などの最小単位。	React コンポーネントやモジュール、クラス

ターゲット (Target) の役割

「ターゲット」は、1 つのアプリケーションの「入り口」です。どの PBL をどの順番で読み込むか (ライブラリリスト) を定義します。Web 開発でいえば、Webpack や Vite の設定ファイルに近く、「どのモジュールを解決してビルドに含めるか」を制御する役割を担っています。

3. 「ライブラリリスト」という重要概念

PowerBuilder 開発において、Web エンジニアが最も意識すべきなのがライブラリリスト、いわゆるサーチパスの優先順位です。

PowerBuilder アプリケーションが動作する際、あるオブジェクト (例：m_main_menu) を探すとき、ターゲットに登録された PBL のリストを上から順番にスキャンします。これは、JavaScript の import における解釈順序や、CSS のセレクタ優先順位に似ていますが、より物理的です。

活用例
共通ライブラリ core.pbl にある機能を、特定のプロジェクト用 PBL (custom.pbl) で「上書き」したい場合、custom.pbl をリストの上位に配置します。
注意点
同じ名前のオブジェクトが複数の PBL に存在すると、意図しない方がロードされる「名前衝突」が発生します。この仕様により「オブジェクトの修正が反映されていない？」という勘違い (優先順位の低い、同名のオブジェクトを修正してしまう) が発生することもあり得ます。
PowerBuilder IDE では同名オブジェクトの検出が難しいため、Web 開発以上に、命名規則 (プレフィックス) の徹底が求められます。

4. モダンな開発に不可欠な「Git 管理」

「バイナリファイル (PBL) の中にソースがあるなら、Git で差分管理ができないのでは？」

これは過去の PowerBuilder における最大の弱点でしたが、PowerBuilder 2022 R3 (および近年のバージョン) では、その懸念は払拭されています。

現在の PowerBuilder には、標準で「ソース管理統合機能」が備わっており、これを利用することにより IDE 上でオブジェクトを保存すると、PowerBuilder は内部的に以下の処理を自動で行います。

PBL 内のバイナリを更新する。
同時に、プレーンテキスト形式のソースファイル (.srw (ウィンドウ)、.srd (データウィンドウ) など) を物理ディレクトリに書き出す。

Git でコミットするのは、PBL 本体ではなく、この書き出されたテキストファイル群です。しかし通常、開発者は Git コマンドを叩く必要はありません。Push/Pull/Commit などの操作は PowerBuilder IDE の UI で行うことができます。

5. IDE のレイアウトと効率的なナビゲーション

PowerBuilder IDE は、一見するとクラシックですが、その機能は強力です。

システムツリー

プロジェクトの全構造を俯瞰する「エクスプローラー」。Git 等のソース管理でのステータスもアイコンで判別できる。
ライブラリペインタ
PBL の中身を管理し、オブジェクトの移動やコピーを行う「ファイルマネージャー」。
オブジェクトブラウザ

オブジェクトの継承関係の把握やオブジェクト種類ごとにブラウズ可能、またシステム関数や各オブジェクトのメソッド等、「API リファレンス」としても機能。

Web エンジニアが「シンボルへ移動 (F12)」や「全検索 (Ctrl+Shift+F)」を多用するように、PowerBuilder では 「検索」機能を使って、PBL を横断して文字列を検索します。検索結果から直接エディタを開くフローは、モダンな IDE に引けを取りません。

実践へのヒント：PBL の分割戦略

中堅のエンジニアであれば、コードのモジュール化の重要性は身に染みているはずです。PowerBuilder でも「1 つの巨大な PBL」を作るのはアンチパターンです。そこで…

common.pbl

全体で使う基底クラスや関数。
master.pbl

マスタメンテナンス関連の画面。
order.pbl、shipping.pbl 等

受注・出荷などの業務ロジック画面。

このように、「業務ドメイン」や「レイヤー (UI/ロジック)」ごとに PBL を分けることで、ビルド時間の短縮と、チーム開発におけるコンフリクトの低減が可能になります。

第 2 回のまとめ

PowerBuilder のアーキテクチャは、「PBL というコンテナによるカプセル化」と「テキストベースのソース管理」のハイブリッドで成り立っています。

PBL は「ディレクトリ兼パッケージ」と考える。
ターゲットの「ライブラリリスト」で依存関係と優先順位を制御する。
IDE に統合された Git 管理でモダンなフローを維持できる。

この構造さえ理解してしまえば、「どこにコードを書けばいいのか分からない」という状態からは脱却したと言えるでしょう。

次回、第 3 回では、いよいよ PowerBuilder の真骨頂に迫ります。Web 開発における「ORM ＋フロントエンド・フレームワーク」をたった一つのオブジェクトで代替する、その技術の仕組みを解き明かします。

次回に向けてのメモ

.pbw (ワークスペース): 全体の設定。
.pbt (ターゲット): アプリケーションの実行定義。
.pbl (ライブラリ): オブジェクトの入れ物 (バイナリ)。
.sr* (ソース): Git 管理対象となるテキスト形式のソースコード (例：.srw = ウィンドウ、.srd = データウィンドウ、.srf = 関数)。