Pega App Studio と Dev Studio の使い分け｜役割分担と越境の判断基準
「この設定は App Studio でやるべきか、Dev Studio に降りるべきか」——Constellation アーキテクチャでは、この線引きがアプリの保守性と Constellation 対応度を左右する。両環境の役割と、越境してよい／いけない境界を LSA 視点で解説する。
結論から：まず App Studio、足りない分だけ Dev Studio
Pega Platform では、同じアプリケーションを 2 つの異なる抽象度から構成できます。ローコード開発環境である App Studio と、ルールレベルまで踏み込める Dev Studio です。設計・実装を進めていると、「この設定は App Studio でやるべきか、それとも Dev Studio に降りるべきか」という判断が繰り返し出てきます。
結論を先に言うと、Constellation を前提とした Pega の原則は 1 つです。
可能な限り App Studio で作り、App Studio では表現できないものだけ Dev Studio に降りる。
これは Pega 自身がベストプラクティスとして明言している方針で、System Architect のような技術ロール（さらには熟練の Senior System Architect）であっても、まずは App Studio で構築し、App Studio に無い高度な機能が必要になったときだけ Dev Studio に切り替える、という順序が推奨されています。「Dev Studio のほうが何でもできるから」と最初から Dev Studio に籠もるのは、Constellation アーキテクチャでは明確なアンチパターンです。安易に降りるほど、モデル駆動性とガードレール順守が崩れ、アップグレード容易性と保守性を失っていきます。本記事では、この「越境してよい／いけない境界」を、実務で機械的に下せる判断基準として整理します。
App Studio と Dev Studio は何が違うのか
両者は「同じアプリを別の抽象度から触る 2 つの窓口」です。まず役割を整理します。
- App Studio — ローコード開発環境。Case Designer（ケースライフサイクル）、Data（データモデル）、ビュー（画面）設計などを、視覚的・宣言的に構成できます。Pega は App Studio を「コーディングスキルの有無を問わず全員が使える場」と位置づけており、対象はシチズン開発者・ビジネスアーキテクトから System Architect まで全ロールに及びます。実際、Pega のベストプラクティスは「熟練の System Architect であっても、まず App Studio で構築する」——Developer Assistant やガードレールが構成ミスを減らすためです。業務の流れ・データ・画面を「モデルとして」組み立てる場と考えてください。
- Dev Studio — 高度なルール構成を扱う技術者向けの環境。複雑な宣言的ロジック、クラス構造、外部システム連携（統合サービス）、詳細なセキュリティ・アクセス制御など、App Studio の抽象度では表現しきれない領域に踏み込めます。主な対象は System Architect（SA）／Lead System Architect（LSA） といった技術ロールです。
重要なのは、両者が扱う抽象度の非対称性です。**App Studio で組んだ構成は、その下でルールとして積み上がり、Dev Studio からも参照・編集できます。**一方、Dev Studio はそのルール層に直接触れるぶん、App Studio が抽象化している領域まで踏み込めます——言い換えると、App Studio の抽象度では、Dev Studio でできることのすべてを表現できるわけではありません（Dev Studio には 200 を超えるルールタイプがあり、App Studio はそれらをローコードのフォームに束ねています）。だからこそ「何でもできる Dev Studio」に流れやすいのですが、できることと、そこで作るべきことは別問題です。加えて Constellation では、UI（ビュー）の設計そのものが主に App Studio で行う作業であり、Dev Studio に降りる動機はさらに限定されます。
なぜ「まず App Studio」なのか
App Studio を起点にする理由は、単に「簡単だから」ではありません。
- モデル駆動性を保てる — App Studio の構成はメタデータとして宣言的に積み上がります。ケース・データ・ビューがモデルとして一貫し、Constellation はそのモデル（データモデルの定義）を起点に UI を組み立てます。Constellation ではフィールドの見え方・振る舞いがプロパティ定義に直結するため、モデルの正確さがそのまま UI の品質になります。ここを外れて命令的なルールを書き込むほど、モデルとの乖離が生まれます。
- ガードレールの中に留まれる — ガードレールとは、再利用性・保守性・システム性能を最大化するために Pega が定めた「成功するアプリのベストプラクティス」です。App Studio はこのガードレールに沿って作らせます。降りるほど、ガードレール外の実装を持ち込む余地が増えます。
- アップグレードが楽になる — 標準機能・宣言的構成に寄せておくほど、プラットフォームのバージョンアップ時に手作りのカスタム資産が壊れるリスクが小さくなります。Constellation は表示レイヤーが定型化（prescriptive）されているぶん、アップグレードがシームレスになりやすいのが利点です。
- 担い手を広げられる — App Studio で完結する範囲は、シチズン開発者・ビジネスアーキテクトも担えます。希少な SA／LSA を、高度な構成だけに集中させられます。
裏を返すと、Dev Studio に降りるたびに、これらを少しずつ手放しているという自覚が要ります。降りること自体が悪なのではありません。降りるべき理由がないのに降りることが問題なのです。
判断の順序：App Studio に留まるか、降りるか
実案件では、次の 3 つのゲートを順に通すと判断がぶれません。上の図がその流れです。
ゲート①：App Studio の標準機能で表現できるか
まず、対象の構成（ケースのステージ／ステップ、データモデル、ビュー、簡易な自動化）が App Studio の標準機能の範囲で作れるかを見ます。ケースライフサイクル・データオブジェクト・画面・簡単な自動化の多くは、App Studio で完結できます。ここで「できる」なら、Dev Studio に降りる理由はありません。
ゲート②：対象バージョンで対応しているか（版を確認する）
「App Studio では無理」と思ったとき、すぐには降りません。App Studio の機能セットはリリースごとに拡張が続いています。数バージョン前は Dev Studio が必要だった構成が、現行版では App Studio で作れるようになっている、というケースは珍しくありません。降りる前に、利用中のバージョンでの対応状況を必ず確認します。「昔できなかった」は「今もできない」の根拠になりません。
ゲート③：ガードレール内の設定・拡張で代替できるか
対象バージョンでも未対応と確認できたら、最後に「ガードレールの範囲内の設定・拡張で目的を達せないか」を検討します。標準構成の組み合わせや、推奨された拡張ポイント（たとえば Constellation の DX コンポーネントのように、App Studio のビュー設計に統合される形で提供される拡張）で代替できるなら、そちらを優先します。ここまで通してもなお表現できない場合に、初めて Dev Studio に降ります。降りるときも、降りる範囲を「表現できない部分だけ」に絞り、それ以外は App Studio 側に残します。降りる典型例としては、統合サービスの詳細設定やデータベースのクラスマッピングなど、App Studio に用意されていない高度な機能が挙げられます。
環境選択はガバナンス問題でもある
App Studio と Dev Studio の使い分けは、個々の設計判断であると同時に、チーム全体のガバナンス設計でもあります。
「誰が、どちらの環境で、何を触れるか」を役割・権限で分けておくことが、ガードレール品質とアップグレード容易性を守る鍵です。
- シチズン開発者・ビジネスアーキテクト — App Studio 中心。ケース・データ・ビューの構成を担う。
- SA／LSA — 同じく App Studio を基点にしつつ、Dev Studio に降りる判断と、降りた先の高度な構成（複雑なロジック・連携・詳細なセキュリティ）を担う。技術ロールだからといって最初から Dev Studio に常駐するのではなく、「降りる必要があるか」を見極めるゲートキーパーの役割を持つ。
この分界を曖昧にして「誰でも Dev Studio を触れる」状態にすると、ガードレール外の実装が場当たり的に増え、アップグレードのたびに壊れる負債が積み上がります。逆に役割で線を引いておけば、Dev Studio に降りる判断そのものがレビューの対象になり、越境が統制されます。
App Studio で完結できる範囲・Dev Studio が要る範囲
事前に「どこまで App Studio、どこから Dev Studio」を線引きしておくと、判断のたびに迷わず、ガバナンスも安定します。おおまかな目安を表にします（対応範囲はバージョンで広がるため、境界は版により動きます）。
| 領域 | App Studio で完結しやすい | Dev Studio が要りやすい |
|---|---|---|
| ケース | ステージ・ステップ、標準の承認・割当 | 複雑な分岐・動的なライフサイクル制御 |
| データ | データモデル、データオブジェクト、関連 | 高度なクラス構造・継承・クラスマッピングの作り込み |
| ロジック | 条件分岐、簡易な自動化 | 複雑な宣言的ロジック（宣言的ルール群） |
| UI | ビュー設計、標準コンポーネント、DX コンポーネント | 標準で表現できない高度なカスタム |
| 連携 | 用意された標準コネクタの利用 | 統合サービスの詳細設定・独自コネクタ |
| セキュリティ | ロールベースの標準設定 | 詳細・きめ細かなアクセス制御 |
この表は固定の正解ではなく、プロジェクト開始時にチームで合意する「線引きの叩き台」です。 版と要件に応じて具体化し、設計ルールとして共有しておくと、越境の判断が属人化しません。
よくある失敗
失敗1：理由なく最初から Dev Studio に籠もる
「慣れているから」「細かく制御したいから」と、App Studio で足りる構成まで Dev Studio で作ってしまうパターン。モデル駆動性が崩れ、シチズン開発者が触れなくなり、アップグレード耐性も落ちます。App Studio で作れるものは App Studio で作る——これが崩れると、Constellation の利点の大半を捨てることになります。熟練の System Architect であっても App Studio を基点にする、というのが Pega の推奨である点を思い出してください。
失敗2：版を確認せず「App Studio では無理」と決めつける
過去の経験や古い記憶をもとに「これは App Studio では作れない」と判断し、確認せずに Dev Studio へ降りるパターン。App Studio は継続的に機能拡張されているため、利用中のバージョンでの対応状況を確認せずに「無理」と断定してはいけません。降りる前の版チェックを、判断フローに必ず組み込みます。
失敗3：環境の権限分界が曖昧
誰でも Dev Studio に降りられる状態を放置し、越境がレビューされないパターン。ガードレール外の実装が個人の裁量で増え、後から棚卸しできなくなります。役割・権限で「誰がどちらを触るか」を先に決めることが、ガバナンスの前提です。
まとめ
- Constellation の原則は 「まず App Studio、足りない分だけ Dev Studio」。これは Pega 自身のベストプラクティスで、熟練の System Architect にも当てはまる。安易に降りるほど、モデル駆動性・ガードレール順守・アップグレード容易性を失う。
- 降りる判断は 3 ゲートで行う——①App Studio の標準機能で表現できるか、②対象バージョンで対応しているか（版を確認）、③ガードレール内の代替で足りるか。すべて「いいえ」になってはじめて Dev Studio に降りる。
- 降りるときも、範囲を**「表現できない部分だけ」に絞る**。
- 環境選択は ガバナンス問題。役割・権限で「誰がどちらを触るか」を先に線引きしておくと、ガードレール品質とアップグレード容易性を保てる。
- App Studio の対応範囲は版ごとに広がる。境界は固定でなく、プロジェクトごとに版と要件で合意する。
App Studio と Dev Studio の線引きは、Pega アプリケーションの保守性・拡張性・Constellation 対応度を左右する土台です。設計の初期にチームで合意しておくことが、後工程の手戻りとガバナンスの崩壊を防ぎます。
Pega の設計・実装、Constellation を前提とした App Studio／Dev Studio の役割分担でお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、環境の使い分けとガバナンス設計からご支援します。
関連リンク
関連記事
Pega 宣言的処理のコスト設計｜前方連鎖と後方連鎖の使い分け
Declare Expression は便利だが、前方連鎖のカスケードは1つのプロパティ変更が広範な再計算を引き起こす。宣言的処理は「書けば動く」半面、実行コストが見えにくい。本記事は前方連鎖と後方連鎖、宣言的と手続き的の境界線を、性能と保守性の観点で整理する。
記事を読むPega Insights と Report Definition の使い分け｜セルフサービス分析と運用レポートの線引き
「レポートは Report Definition で作るべきか、Insights でユーザーに任せるべきか」——ダッシュボード設計で必ず出る分岐です。統制と再利用が要る定型レポートはルール化し、アドホックな探索はセルフサービスに開く、が基本方針。本記事では両者のガバナンス差とデータソースの前提から、線引きの判断軸を示します。
記事を読むPega 監査証跡設計：フィールド監査・履歴・セキュリティ監査の使い分け
「何を、どこまで監査するか」は Pega のセキュリティ設計で最も判断が割れるテーマです。フィールド監査・ケース履歴・セキュリティイベントの使い分けと、監査のかけ過ぎが招く性能・容量問題の回避策を、LSA の視点で解説します。
記事を読む