Pega の生成 AI 機能と利用ガバナンス｜情シスが押さえるべき統制ポイント
Pega の生成 AI 機能(Blueprint ほか)の全体像を情シス視点で整理し、データの流れの確認ポイントと利用ポリシー・統制の設計方法を解説します。
結論から：「全面禁止」でも「無条件解禁」でもなく、データの流れで層別に統制する
Pega の製品群には、Blueprint をはじめとする生成 AI 機能（Pega GenAI）が中核に組み込まれつつあります。導入企業の情シス・セキュリティ部門から最も多く受ける質問が「この AI 機能、使わせていいのか？」です。
結論を先に言うと、判断の型はシンプルです。
機能名で判断せず、「どのデータが、どの段階で、どこへ送られるのか」で判断する。設計段階の情報しか扱わない機能はルール付きで許可し、本番の業務データを扱い得る機能は審査制にする——リスク層別の段階制統制。
「生成 AI は怖いから全部禁止」は一見安全に見えますが、後述するとおり開発効率の差で競合に劣後する選択であり、統制としても機能しません。本記事では、Blueprint の設計活用そのもの（別記事で解説済み）ではなく、統制・審査の視点に特化して、機能マップ・確認観点・ポリシー設計の順で整理します。
Pega の生成 AI 機能マップ — 3カテゴリでデータの流れが違う
「Pega の生成 AI」と一括りにされがちですが、統制の観点では3つのカテゴリでデータの流れがまったく違います。ここを分けずに議論すると、ポリシーが「全部禁止」か「全部 OK」の二択に潰れてしまいます。
設計生成系（Blueprint）
業務プロセスの記述からワークフロー・データモデルなどの設計案を生成する機能です。流れるデータは「人が入力した業務要件の記述」と、任意でアップロードする資料（既存業務フロー図・要件ドキュメントなど）であり、既存システムや本番環境のデータが自動的に送られるわけではありません。裏を返せば、リスクの源泉は「人が何を書き込み、何をアップロードするか」に集中します。ここが後述する抽象度ルールの根拠になります。
統制上もう1点押さえておきたいのは、Blueprint が Pega Platform 本体とは別に提供される SaaS だという点です。執筆時点の Pega 公式 FAQ では、作成した Blueprint は既定で無期限に保持され（任意のタイミングで削除可能）、米国リージョンの Pega Cloud に保存されるとされています。「入力ルール」だけでなく「成果物がどこに・いつまで残るか」も統制の対象に含めておきましょう。
開発支援系
開発環境の中で、ルール作成・設定・テストデータ生成などを補助する機能群です。流れるデータは開発資材（ルール定義・設定情報・サンプルデータなど）です。一見安全に見えますが、「本番から抽出した実データをサンプルとして使っていないか」が盲点になります。
実行時 AI 機能
本番アプリケーションに組み込まれ、実行時に動作する生成 AI 機能です（ナレッジ応答、文章の要約・生成支援など）。処理対象が本番の業務データ・顧客データそのものになり得るため、3カテゴリの中で最もリスクが高く、統制も最も厳格にすべき領域です。なお Pega GenAI では、実行時の LLM 呼び出しはクライアントごとに用意される GenAI Gateway を経由して集約される構成のため、統制ポイントをアーキテクチャ側に寄せる設計が可能です。Infinity ‘25 以降は自社選定の LLM を持ち込む構成（Bring Your Own LLM）も段階的にサポートされており、プロバイダ選定まで含めた設計はPega GenAI の LLM プロバイダ設計を参照してください。
カテゴリ別の統制方針（早見表）
| カテゴリ | 代表例 | 主に流れるデータ | 利用段階 | 推奨する統制レベル |
|---|---|---|---|---|
| 設計生成系 | Blueprint | 人が記述した業務要件・設計情報 | 構想・設計 | 抽象度ルール付きで許可 |
| 開発支援系 | ルール作成・テスト支援 | ルール定義・設定・サンプルデータ | 開発・テスト | 入力資材を条件に許可 |
| 実行時 AI | ナレッジ応答・文章生成など | 本番の業務データ・顧客データ | 本番運用 | 審査制（個別評価） |
情シスが確認すべき4つの観点
カテゴリを分けたうえで、各機能について確認すべき観点は次の4つに集約されます。
1. 送信されるデータの範囲
その機能を使ったとき、何が・どこまで外部の AI サービスに送信されるのか。入力したテキストだけか、画面上のコンテキストやケースデータも含まれるのか。機能ごとに範囲が異なるため、「Pega の AI」と一括りにせず機能単位で確認します。
2. 学習利用の有無
送信したデータが基盤モデルの学習に使われるのか。エンタープライズ向けサービスでは学習に使わない契約形態が一般的になりつつありますが、これは「一般論」であって自社契約の保証ではありません。Pega GenAI の場合、執筆時点の公式 FAQ では「クライアントデータを Pega および LLM プロバイダのモデル学習に使わない」ことが明言されています。この公式記載を、自社の契約書・データ処理条項（後述の Pega GenAI Addendum を含む）と突き合わせて確認するのが実務です。
3. 処理リージョン
AI の推論処理がどのリージョンで実行されるのか。データレジデンシー要件（国内処理の義務など）がある業種では、アプリケーション本体のリージョンと AI 処理のリージョンが別になり得る点に注意が必要です。Pega GenAI では、執筆時点の公式 FAQ で「クライアントが選択したデプロイリージョン（米国・EU 内）に、対応する GenAI 処理リージョン（同じく米国・EU 内）をペアリングする」旨が示されており、アプリケーション本体を国内リージョンで運用していても AI 処理は国外リージョンになり得ます。国内処理を前提にできるかどうかは、必ず最新の公式情報と自社契約で確認してください。
4. オプトアウト・無効化の可否
組織として、あるいは環境単位で機能を無効化できるか。段階制の統制を敷くには「使わせない」を技術的に強制できることが前提です。Pega GenAI は執筆時点ではオプトイン型で、Pega Cloud では利用開始にあたり Pega GenAI Addendum（生成 AI 利用条件への同意）の締結と有効化の手続きが必要とされています。つまり「契約・設定として使わない」を選べる構造です。そのうえで、管理設定でどの粒度（テナント／環境／機能）まで制御できるかを確認します。
重要な注意： 生成 AI 関連の仕様・提供条件はリリースごとに変わります。本記事は「何を確認すべきか」の枠組みを示すものであり、個別の仕様は必ず現行の公式ドキュメントと自社の契約条件で確認してください。「以前のバージョンではこうだった」を根拠にポリシーを作るのが、最も危険なパターンです。
利用ポリシーの設計例 — 段階制の統制
実案件でワークするのは、機能を一律に扱うのではなく、前述の3カテゴリに対応した段階制のポリシーです。
第1段階：設計段階の機能は「抽象度ルール」を決めて許可
Blueprint のような設計生成系は、入力するのが人の書く業務記述である以上、何を書いてよいかのルールを決めれば広く許可できます。例えば次のような抽象度ルールです。
- NG： 「◯◯銀行の法人融資稟議。取引先 A 社の与信限度額は◯億円で、審査部の田中部長が最終承認」
- OK： 「金融機関の法人融資稟議プロセス。申請 → 与信審査 → 役職者承認の流れで、金額に応じて承認階層が変わる」
業務の構造は書いてよいが、顧客名・実数値・個人名・未公開の業務ノウハウは書かない——この線引きを明文化して展開します。アップロードする資料にも同じルールを適用します（既存資料には固有名詞や実数値が埋まっていることが多く、テキスト入力より見落としやすいポイントです）。設計段階で得られる生産性向上が大きい割に、ルール化でリスクを大きく下げられる領域です。
第2段階：開発支援系は「入力資材」を条件に許可
開発環境での AI 支援は、入力に使う資材を統制したうえで許可します。ポイントは1つだけ、「本番由来の実データを開発資材に混ぜない」ことです。テストデータは合成データか匿名化済みデータに限定する——これは生成 AI 以前からのテストデータ管理の原則そのもので、AI 利用がその重要性を一段引き上げた形です。
第3段階：本番データを扱う機能は審査制
実行時 AI 機能は、扱うデータ・ユースケース・出力の使われ方が案件ごとに異なるため、包括許可ではなく個別審査にします。審査項目は前述の4観点（送信範囲・学習利用・リージョン・無効化可否）に加え、出力の誤りが業務に与える影響と人によるチェックの有無、監査証跡の設計（Pega の監査証跡設計参照）です。
よくある失敗
失敗1：全面禁止にする
最も多く、最も高くつく失敗です。生成 AI を全面禁止しても開発現場のニーズは消えないため、統制外の個人アカウントで使われる「野良利用」が発生し、かえって統制不能になります。さらに、設計・開発の効率差は競合他社との差として蓄積します。Pega 自身が製品の中核に AI を組み込む方針である以上、「使わない」は年々コストが上がる選択です。禁止ではなく「安全に使える範囲の定義」に労力を使うべきです。
失敗2：機能名単位の「一度きりの承認」で終わらせる
「Blueprint は承認済み、それ以外は禁止」のような機能名ベースのポリシーは、新機能の追加や仕様変更のたびに議論が振り出しに戻ります。ポリシーの判断基準を本記事の判断フローのようにデータの流れベース（何が・どの段階で・どこへ行くか）で書いておけば、新機能が出ても同じ物差しで分類するだけで済みます。あわせて、仕様変更に追従するための定期レビュー（少なくともメジャーリリースごと）をポリシー自体に組み込んでおきます。
失敗3：「設計・開発段階だから安全」と思い込む
本番データを扱わないカテゴリでも、リスクがゼロになるわけではありません。Blueprint に顧客名や実際の与信基準を書き込めば、それは機密情報の外部送信です。開発支援に本番から抽出したデータを流せば、環境の分離は意味を失います。段階制統制が機能する前提は、各段階の入力ルールが守られていることです。ツール側の設定だけでなく、利用者教育とセットで運用します。
まとめ
- Pega の生成 AI は設計生成系（Blueprint）／開発支援系／実行時 AI の3カテゴリでデータの流れが異なる。統制はカテゴリ別に設計する
- 確認観点は4つ——送信データの範囲・学習利用の有無・処理リージョン・オプトアウト可否。仕様は変わるため、必ず現行の公式ドキュメントと自社契約で確認する
- ポリシーは段階制に：設計段階は抽象度ルール付きで許可、開発支援は入力資材を条件に許可、本番データを扱う機能は審査制
- 全面禁止は統制ではない。 野良利用と競合劣後を招くだけ。判断基準を機能名でなくデータの流れで書き、定期レビューで仕様変更に追従する
生成 AI の統制は「セキュリティ部門 vs 開発部門」の対立構図にしがちですが、正しく層別すれば両立できます。禁止か解禁かの二択を迫られる前に、リスク層別の枠組みを先に用意しておくことが、情シスの最大の打ち手です。
Pega の生成 AI 活用や利用ポリシーの設計でお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、統制設計と開発効率の両立をご支援します。
関連リンク
関連記事
Pega データページの種類とスコープ設計｜Thread / Requestor / Node の使い分け
「なんとなく Thread スコープ」で作られたデータページが、外部連携の呼び出し回数を無駄に増やしていませんか。本記事ではデータページの種類（Read-Only / Editable / Savable）とスコープ（Thread / Requestor / Node）の組み合わせを、キャッシュ範囲・データ鮮度・再読み込みの観点から使い分ける判断軸を、LSA 目線で整理します。
記事を読むPega DX API で独自フロントを作る判断｜標準 Constellation UI との使い分け
Constellation は DX API 経由で UI メタデータを受け取りクライアントで描画する。この API は独自フロントの構築にも開放されているが、わずかな見た目調整のために独自フロントへ踏み込むと保守とアップグレードの負担が跳ね上がる。どこまで OOTB で、どこから DX API か——設計判断の分岐点を扱う。
記事を読むPega 保守費はなぜ高くなるのか｜費用構造と削減の実践アプローチ
Pega 保守費の内訳を分解し、高くなる構造的要因(カスタム過多・体制固定)と、削減の実践アプローチ(標準回帰・体制見直し・部分内製化)を解説します。
記事を読む