はじめに
Pegaでの業務アプリ開発を、Claude CodeのInfinity AI Pluginsで効率化できないか試してみました。セットアップ手順から、実際に使ってみて分かった「できること」「できないこと」、そして開発フローに組み込む上での工夫までを共有します。検証はすべてPegaのトライアル環境上で行っています。
対象読者:
- PegaでTheme-Cosmosベースのアプリを開発している方
- Claude Code / MCPを使った開発効率化に興味がある方
- 「AIにPegaのルールを作らせる」ことの限界を先に知っておきたい方
Infinity AI Pluginsとは
Claude CodeをはじめGitHub Copilot CLI・Codexなど複数のAIコーディングエージェント向けに提供されているプラグインで、Pega InfinityのDX APIを介してルールの検索・参照・作成・更新をAIエージェントから直接行えるようにするものです（本記事ではClaude Codeで検証しています）。
ただしAPIを叩けるだけのツールではありません。プラグインには、ルールタイプごとに「どう作ればよいか」をまとめたドキュメント（命名規則、必須項目や入力形式の定義、実際の作成例）が「スキル」として同梱されています。Claudeはルールを作成・更新する前に必ずこのスキルを読みに行き、そこに書かれた形式・制約に沿って作業します。イメージとしては、経験豊富なPega開発者のノウハウをドキュメント化して同梱し、Claudeがそれをカンニングペーパーのように参照しながら手を動かす、という仕組みです。
大きな特徴は2つあります。
- 対応ルールタイプが明示的に限定されている（後述）
- 書き込みは必ずChangeRequest経由でブランチルールセットに隔離され、ベースルールセットへの直接書き込みや自動承認は行われないガードレールがある
セットアップ
プラグインを入れてから実際にPegaへ繋がるまでは、大きく4ステップです。
1. プラグインをインストールする
Claude Codeにマーケットプレイスを追加し、プラグインをインストールします（Java 17以降が前提です）。
claude plugin marketplace add https://github.com/pegasystems/infinity-ai-plugins.git
claude plugin install pega-infinity-authoring@Pega
2. 対応バージョンを確認する
繋ぎたいPega Infinity環境のバージョンが対応範囲かをここで確認しておきます。公式リポジトリには対応バージョンが明記されており、検証時点（プラグインv0.1.1）では以下の通りでした。
| Pega Infinity バージョン | 対応状況 |
|---|---|
| 26.1以降 | ○ 対応 |
| 25.1.3以降 | ○ 対応（公式ドキュメントに"consult Pega"の注記あり） |
| 24.2.5以降 | ○ 対応（同上） |
3. Pega環境に接続する
インストール後に新しいセッションを開始し、pega-setupスキルを呼び出すと接続設定が始まります（公式リポジトリのREADMEにも「プラグインをインストールしたら新しいセッションを開始し、アシスタントにpega-setupを実行するよう頼んでください」と案内されています）。トライアル環境で実際に試した体感としては、思ったよりシンプルでした。
- Claude Codeから接続先のPega環境のURLを聞かれる
- URLを入力すると、ブラウザが自動的に開いてPegaのログイン画面に遷移する
- そのログイン画面でユーザー名・パスワードを入力して認証すると、接続が完了する
トライアル環境では、利用者側でOAuthクライアントを事前に発行するような作業は不要で、URL入力とブラウザでのログインだけで完了しました。なお公式READMEによるとpega-setupはOAuthクライアントIDの設定（オプション）も案内してくれるとのことなので、環境によってはOAuthクライアントIDの設定が必要になる場合がありそうです。
4. 接続確認
接続できているかは、Claude Codeに「今つながっているPegaアプリケーションを教えて」のようにチャットで聞くだけで確認できます。裏側でget-applicationやlist-available-applicationsが呼ばれ、ケースタイプ一覧やルールセット構成が返ってくれば接続成功です。
実際に使ってみて分かったこと：できること
ルールの検索・参照
- キーワードでルールを横断検索
- 既存アプリのケースタイプ一覧、Applicationルールの依存関係（どのテーマ・フレームワークに依存しているか）を取得
- 特定ルールの詳細（フル構成）を取得
これだけでも「このアプリ、何のルールが既にあるんだっけ？」という調査作業がかなり速くなります。
ルールの作成・更新
今回トライアル環境で実際に作成まで確認できたのは、以下の4つです。
- Property
- Activity
- Validate
- When
対応しているルールタイプの正式な一覧は、プラグイン公式リポジトリのAGENTS.md（バージョンごとにフォルダあり）に載っており、Decision Table・Data Transform・Flow・REST Connector・View（Constellation）なども対応リストに含まれています。上記4つ以外は私自身まだ作成を試せていませんが、対応リスト上は同じ仕組みで作成できることになっています（未検証です）。
ポイントは、Constellation向けのView(Rule-UI-View)はMCPで触れる、という点です。ここが次の「できないこと」と直結します。
ガードレール（ChangeRequestベース）
ルールの作成・更新は必ず「ChangeRequestケース」を介して行われます。このケースの目的は、AIが作った変更をブランチルールセットに隔離し、人がレビューするまで本番に影響させないことにあります。つまり：
- 変更はすべて専用のブランチルールセットに作られる。ベースルールセットにいきなり書き込まれることはなく、エンドユーザーからも見えない
- ChangeRequestケースの承認（Reviewステージ）は自動化されておらず、必ず人間が承認する
-
承認されてもブランチは自動でベースにマージされない。 ケース自体は
Resolved-Completeで完了するが、ブランチをマージするかどうかはPegaの通常のブランチ管理機能を使って別途人が判断する - 変更後にテスト（PegaUnit）を実行し、失敗したら1つずつ切り分けて直す、というフィードバックループが前提になっている
「AIが勝手にアプリを壊す」ことを防ぐ設計思想がベースにある、という印象です。承認とマージが分離されているのは、思った以上に慎重な作りだと感じました。
できないこと・ハマりどころ
ここが一番重要なポイントでした。Theme-Cosmosを使っているアプリだと、UI周りをMCPで触れません。
具体的には：
| できないこと | 理由・代替手段 |
|---|---|
| Section / Harnessルールの作成・編集 | 対応ルールタイプ一覧に含まれていない。ConstellationのViewは対応しているが、UI-Kit系のSection/Harnessは非対応。Dev Studio/App Studioで手動編集する |
| 新規Data Objectの作成 | 非対応。Data Designerで手動作成が必要（既存Data ObjectへのProperty追加自体は、Propertyルールが対応ルールタイプに含まれるため可能と考えられますが、この記事では未検証です） |
Automation型のActivity（pyActivityType=AUTOMATION）の作成・更新 |
非対応。通常のActivity（pyActivityType=ACTIVITY）のみ対応 |
つまり、 Theme-Cosmosベースの既存アプリを拡張する場合、「業務ロジック（Decision Table・Data Transform・Flow等）はMCPに任せられるが、画面のレイアウト変更はほぼ確実に人手が必要」 というのが実態でした。これから新規にConstellationベースで作るアプリなら、View周りも含めてMCPの恩恵をより広く受けられそうです。
なお、この対応/非対応の一覧はプラグインのアップデートで変わる可能性が高いため、実運用では「毎回、最新の対応ルールタイプ一覧を確認してから着手する」運用にするのが安全です。
開発フローへの組み込み：仕様書作成を仕組み化する
上記を踏まえると、新機能を作るときのポイントは「要件を分解して、どのルールをMCPに任せ、どこを人がやるかを最初に切り分けること」だと分かります。これを毎回頭の中でやるのは属人的なので、専用のスキル（Claude Codeの再利用可能な手順書のようなもの）を自作しました。
やっていることはシンプルです。
- 要件をヒアリングする
- MCP経由でアプリの現状（ケースタイプ構成など）を確認する
- 既存の類似ルールがないか検索して重複作成を防ぐ
- 要件を「必要なルール」に分解し、命名案を出す
- 各ルールをMCP対応ルールタイプ一覧と照合し、「MCPで自動作成できる」か「手動が必要」かを判定する
- Markdownで仕様書を出力する（人がレビュー・承認してから保存）
出力される仕様書のイメージ（架空のサンプルアプリ「経費精算」ケースでの例）:
# 機能仕様書: 高額経費の上長承認フロー
## 概要
経費申請ケースで、申請金額が一定額を超える場合に上長承認ステップを追加する。
却下時は却下理由の入力を必須とし、結果を申請者に通知する。
## 必要なルール一覧
| ルール名(案) | ルールタイプ | 目的 | MCP作成可否 | 備考 |
|---|---|---|---|---|
| ExpenseAmount | Property | 申請金額 | ○ | |
| NeedsApproval | Decision Table | 閾値判定 | ○ | |
| HighAmount | When | フロー分岐条件 | ○ | |
| RejectReasonRequired | Validate | 却下理由の必須チェック | ○ | |
| （既存フロー更新） | Flow | 承認分岐の追加 | ○（update） | |
| RejectApprovalAction | Flow Action | 却下理由の入力アクション | ○ | 画面自体は下記Section依存 |
| ApprovalResultNotify | Notification | 結果通知 | ○ | 社内命名規則に該当プレフィックスがなければ要確認 |
| RejectReasonSection | Section | 却下理由入力欄の画面追加 | × （手動） | Theme-CosmosのSectionはMCP非対応。Dev Studioで手動 |
## 実行方針
- すべてChangeRequestベースで実施し、自動承認は行わない
- Section部分はDev Studioで人が対応してからマージする
この仕組みのポイントは2つです。
- 「対応ルールタイプ一覧に載っていないものは即座に手動フラグを立てる」 ようにしていること。曖昧にAIに判断させず、明示的なルールで機械的に振り分けます。
- チーム独自の命名規則がある場合、外部ドキュメント（社内Wikiなど）を都度参照するとコンテキスト（AIへの入力量）を消費するので、ローカルにMarkdownでキャッシュしておき、更新があったときだけ手動で同期する運用にしています。
なお、この仕組みも現時点ではトライアル環境の簡単な機能でしか試せていません。業務アプリで使えるようになったら、実際の要件でも試していきたいと思っています。
まとめ
- Infinity AI Pluginsは、Property・Activity・Validate・Whenの作成・更新を実際に確認できた（Decision Table・Data Transform・Flow等も公式の対応リストには含まれているが、今回は未検証）
- 一方で、Theme-Cosmosの画面（Section/Harness）や新規Data Objectの作成は非対応で、ここは引き続き人手が必要
- ChangeRequestベースのガードレールがあるため、いきなり本番が壊れる心配は少ない
- 対応バージョンは26.1以降、25.1.3以降、24.2.5以降（検証時点、公式リポジトリ記載）。それより古いバージョンの扱いは公式ドキュメントに記載がなく未確認
- 「何をAIに任せ、何を人がやるか」を最初に仕様書として切り分けるステップを仕組み化すると、属人性を減らせる
Theme-Cosmosの資産をそのまま活かしつつAIを使うなら、 「ロジックはMCP、画面は人」 という役割分担を前提に導入計画を立てるのが現実的だと感じました。
※本記事の環境情報・命名規則例は、社内固有の情報を含まないよう一般化・仮名化しています。