Pega 導入費用の構造｜ライセンス・開発・運用の内訳とコストを抑える設計

結論から：費用は「ライセンス・開発・運用保守」の3層で決まり、最大の変数は「作り込み度」

Pega の導入費用は公開情報が少なく、「結局いくらかかるのか」が見えにくい領域です。最初にお断りしておくと、具体的な金額は原則として個別見積もりで案件依存のため、本記事では断定しません。過去には一部製品で参考価格が公開された例もありますが（後述）、金額そのものはユーザー数や対象業務によって大きく変わるうえ、ライセンス体系の詳細は Pega 公式・営業窓口に確認すべき情報だからです。

その代わり、本記事では**費用の「構造」と「変動要因」**を解説します。構造さえ理解すれば、見積もりのどこが動きやすいのか、どの設計判断がコストに効くのかを自分で評価できるようになります。結論は次のとおりです。

Pega の導入費用は「ライセンス」「開発」「運用保守」の3層で構成される。ライセンスは利用規模の指標で決まり、開発と運用保守は「作り込み度（標準機能＝OOTB の活用度）」で決まる。つまり総コストを左右する最大の変数は、規模でも期間でもなく——設計判断である。

この構造を図にすると次のようになります。

費用を構成する3層

まず全体像です。3層それぞれの内容と、何で金額が動くのかを整理します。

層	内容	主な変動要因	設計判断で制御できるか
① ライセンス	プラットフォーム利用料（サブスクリプション）	ユーザー数・ケース数などの利用指標、対象製品の範囲	△（利用範囲の設計で間接的に）
② 開発	初期構築の費用（体制 × 期間）	対象業務の範囲、要件の作り込み度	◎（最も効く）
③ 運用保守	リリース後の維持費用	カスタム資産の量、バージョンアップ追随、改善の頻度	◎（開発時の判断が跳ね返る）

第1層：ライセンス — サブスクリプション、利用指標ベース

Pega のライセンスはサブスクリプション型で、ユーザー数やケース数といった利用規模の指標に基づいて決まるのが基本構造です。対象とする製品（Pega Platform 単体か、Customer Service 等のアプリケーション製品を含むか）によっても変わります。

この構造は Pega が過去に公開した価格資料でも確認できます。たとえば Pega Customer Service の価格エディション表（2019年8月版）では、ユーザー単価型（ユーザーあたり月額）とケース単価型（1万ケース/年のブロック単位）の2系統の課金モデルがエディション別に提示されていました。金額や体系は時期・製品によって変わるため参考に留めるべきですが、「利用規模の指標で課金する」という構造自体は公式資料と一致しています。

体系の詳細や見積もり条件は変更されることもあるため、必ず Pega 公式・営業窓口で最新情報を確認してください。ここで押さえるべきは「ライセンスは利用規模で決まる層であり、後述の作り込み度とは独立に動く」という構造だけです。

第2層：開発 — 体制 × 期間、作り込み度で大きく変わる

開発費用は本質的に「体制 × 期間」です。そして体制と期間を決めるのは、対象業務の広さと、どこまで標準機能（OOTB: Out of the Box）で済ませ、どこから作り込むかという設計判断です。

Pega はケース管理・割当・承認・SLA（ケース／ステージ／プロセス／ステップの各レベルで設定可能）・レポートといった業務アプリケーションの基本機能を標準で備えています。標準の範囲に業務を寄せられれば開発は「設定中心」になり、体制も期間も圧縮できます。逆に画面・帳票・細かな操作性まで個別要件として作り込むと、実装・テストの工数が積み上がり、同じ業務でも費用は大きく変わります。

第3層：運用保守 — カスタム資産の量に比例して重くなる

見落とされがちなのが3層目です。Pega は継続的にバージョンアップされるため、リリース後もバージョンアップへの追随と業務改善のための継続開発が発生します。

公式ドキュメント「Keeping current with Pega」によれば、Pega はおおむね9〜12か月ごとに新バージョンを、それより高い頻度でパッチをリリースしており、各リリースの標準サポート期間は GA（一般提供開始）から18か月、標準サポート期間中は四半期ごとのパッチ適用が推奨されています。つまり「追随」は一度きりのイベントではなく、恒常的な運用タスクです。

ここで効いてくるのが、開発時に作ったカスタム資産の量です。標準機能は Pega 側が後方互換性に配慮しながら進化させていきますが、カスタム部分は自分たちの検証・改修対象として残り続けます。カスタムのコストは「初期に1回払って終わり」ではなく、保守で払い続ける——これが TCO（総保有コスト）の視点です。

最大の変数は「作り込み度」— 判断は3段階で行う

3層のうち②と③を同時に左右するのが作り込み度です。実案件では、個々の要件に対して次の3段階で判断します。

1. その要件、標準機能で満たせるか？ — 満たせるなら標準一択です。「標準でできることは絶対に標準を使う」が原則です
2. 満たせない場合、業務プロセス側を標準に合わせられないか？ — Pega 導入は業務プロセスを見直す好機です。「システムを業務に合わせる」前に「業務を標準に合わせる」選択肢を必ず検討します
3. それでも作るなら、それは競争優位に直結する差別化領域か？ — 差別化にならないカスタムは、初期費用と保守費用を増やすだけの負債になります

具体例を挙げます。「現行システムの承認画面と同じレイアウトにしたい」という要件はよくありますが、標準の承認 UI で業務は問題なく回ることがほとんどです。ここでレイアウト再現のためにカスタム実装を選ぶと、初期開発の工数に加え、以後のバージョンアップのたびに検証・改修の対象として残り続けます。「現行と同じ」であること自体は業務価値を生まないため、3段階の判断ではステップ2（業務側を標準に合わせる）で吸収すべき要件です。

作り込み度の違いが3層にどう波及するかをまとめると、次のようになります。

観点	OOTB 中心	カスタム過多
初期開発コスト	軽い（設定中心）	重い（実装・テストが積み上がる）
開発期間	短い	長い
運用保守コスト	軽い	重い（カスタム資産の維持）
バージョンアップ追随	追随しやすい	毎回、検証・改修コストが発生
取るべき方針	業務を標準に寄せる	差別化領域に限定して使う

MLP で小さく始める — Pega 公式デリバリー手法のコスト管理

作り込み度と並ぶもう1つのコスト管理の柱が、MLP（Minimum Lovable Product）で小さく始めて段階拡張するというアプローチです。

MLP は「最小限だが、使ったユーザーが価値を実感できる」単位で最初のリリースを絞る考え方です。対象候補の業務が10あっても、最初のリリースは効果が最も大きい1業務（1ケースタイプ）に絞り、短期間で本番稼働まで持っていく。そこで得た運用の学びを、次の拡張に反映していきます。

これは当社独自の流儀ではなく、Pega 公式のデリバリー手法 Pega Express の中核概念です。Pega Academy では MLP を「最初の本番リリース（first production release）」と位置づけ、対象を Microjourney（業務・顧客体験の最小単位）に絞ることで、60〜90日程度で MLP を本番リリースすることを目安としています。

この進め方がコスト面で効く理由は3つあります。

• 初期投資が小さく済む — 開発の第2層を最初から最大化しない
• 価値検証が早い — 投資判断を「全額コミット後」ではなく「小さく検証しながら」行える
• 要件の精度が上がる — 実運用のフィードバックで次フェーズの要件を磨けるため、使われない機能への投資（＝無駄な作り込み）を防げる

段階拡張の各フェーズでも前節の3段階判断を回し続けることで、作り込み度を低く保ったままスコープを広げられます。

よくある失敗

費用が想定を超えるプロジェクトには、共通するパターンがあります。

失敗1：現行システムの完全再現を要件にする

画面レイアウト・帳票・操作感まで「現行と同じ」を要求するパターンです。「現行と同じ」は業務要件ではなく、カスタムの山を生む最大の要因です。結果として初期開発が膨らむだけでなく、バージョンアップのたびに保守費用として跳ね返り続けます。要件定義の段階で「標準機能をまず見て、業務側を寄せられないか検討する」進め方に切り替えるべきです。

失敗2：初期構築費だけで比較する

見積もり比較を初期構築費だけで行うと、作り込みの多い構成が「機能が多くてお得」に見えることがあります。しかし前述のとおり、カスタムのコストは保守で払い続けるものです。ライセンス＋開発＋運用保守の3層合計を、複数年の TCO で比較するのが正しい評価軸です。

失敗3：最初から全業務を対象にする

ビッグバン型で全業務を一斉に載せ替えようとするパターンです。初期投資が最大化するうえ、価値検証が最後まで行えず、要件の誤りが本番稼働まで発覚しません。MLP で1業務から始め、段階拡張する構成に切り替えるだけで、投資リスクの形は大きく変わります。

まとめ

• Pega の導入費用は**「ライセンス・開発・運用保守」の3層**で構成される。具体的な金額は原則個別見積もりで案件依存のため、ライセンス体系の詳細は Pega 公式・営業窓口で確認する
• 総コストを左右する最大の変数は作り込み度（OOTB 活用度）。カスタムは初期だけでなく保守で払い続けるため、TCO で評価する
• 判断は3段階——標準で満たせるか → 業務を標準に寄せられるか → それでも作るなら差別化領域か
• MLP で小さく始めて段階拡張する Pega Express のアプローチで、初期投資を抑えつつ価値検証を早められる

費用の構造を理解したうえで残る問いは、「自社の業務のどこまでを標準に寄せられるか」という個別の設計判断です。ここは要件と Pega 標準機能の両方を知らないと答えが出ない領域なので、実装経験のあるパートナーとの早期の壁打ちをおすすめします。

---

Pega の導入検討・設計でお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、費用構造の評価から設計判断までご支援します。

関連リンク

• Pega Platform 開発支援
• Pega Constellation UI 導入支援サービス
• Pega設計の分岐点：ケースにすべきか、データインスタンスか
• 無料相談に申し込む