AI エージェントは業務システムをどう変えるか｜Pega の Agentic AI 戦略を読む

結論から：成否を分けるのは AI の賢さではなく「自律性を置く枠」

「生成 AI の次はエージェント型 AI（Agentic AI）」——自ら考え、判断し、実行する AI が業務を変える、という話を耳にする機会が増えました。しかし基幹業務を預かる立場から先に結論を言うと、こうなります。

統制なき自律は、企業システムでは事故のもとである。エージェント型 AI を基幹業務で使う鍵は、AI の自律性を「ワークフローという統制の枠」の中に置くことにある。そして導入の第一歩は AI の選定ではなく、業務プロセスの構造化である。

これはまさに Pega が採っているアプローチです。Pega は AI エージェントを野放しに走らせるのではなく、「何をしてよいか」「どこで人が承認するか」をケース（ワークフロー）として事前に定義し、AI はその枠の中で働く——予測可能な AI（Predictable AI）という思想を打ち出しています。本記事では、なぜこの設計が基幹業務で本命なのか、そして導入する企業側は何を準備すべきかを、実装者の視点で整理します。

なぜ「自由に動く AI」は基幹業務に入れられないのか

エージェント型 AI とは、指示された目的に向かって自ら計画を立て、ツールやシステムを操作しながらタスクを完遂する AI を指します。デモを見ると魅力的ですが、企業の基幹業務にそのまま入れられない理由が 3 つあります。

1. 幻覚（ハルシネーション）が「実行」されてしまう

大規模言語モデルの出力は確率的で、もっともらしい誤りを一定の割合で含みます。チャットボットなら誤答を人が読んで捨てられますが、エージェントは誤った判断をそのまま行動に移します。「誤った回答を表示する」と「誤った送金処理を実行する」の間には、埋めがたい次元の差があります。

2. 権限の境界をプロンプトでは守れない

「返金は 1 万円まで」「顧客の個人情報は参照のみ」——こうした制約をプロンプト（自然言語の指示文）で書き連ねても、それはお願いであって強制ではありません。指示の解釈がぶれれば逸脱しますし、悪意ある入力で誘導される（プロンプトインジェクション）リスクも残ります。統制は自然言語ではなく、権限とプロセスの層で構造的に効かせる必要があります。

3. 監査に耐えられない

金融・保険・公共のような規制業務では、「なぜその判断をしたのか」を後から説明できることが必須要件です。自由に動くエージェントの判断過程は再現も説明も困難で、監査不能なシステムは、どれほど賢くても規制業務には載せられません。

Pega のアプローチ：ワークフローが AI の「職務記述書」になる

Pega の答えは明快です。AI の自律性を、ケース（ワークフロー）の枠内に置く。

Pega は 20 年以上、ケースマネジメント——業務を「ケース」という単位で捉え、ステージとステップ、担当者への割当、承認、SLA、監査証跡をモデル化する——を中核にしてきました。この資産を AI 統制の仕組みとしてそのまま使うのが Pega の Agentic AI 戦略です。

• 何をしてよいか は、ケースのステージ・ステップ・業務ルールとして事前に定義されている。エージェントは承認済みワークフローの中で動き、枠の外の行動はそもそも実行させない設計になっている
• どこで人が判断するか は、承認ステップとしてプロセスに組み込まれている。AI は提案し、人が要所で承認する
• 何をしたか は、ケースの履歴として全行動が監査証跡に残る

Pega はこれを予測可能な AI（Predictable AI）と呼び、プロンプト頼みのエージェントとの違いとして公式に打ち出しています（製品面でも「Pega Predictable AI Agents」の名称で展開されています）。実際、2025 年 6 月の PegaWorld 2025 では、社内外の AI エージェントとシステムをワークフロー経由で協調させるオーケストレーション基盤「Pega Agentic Process Fabric」が発表され、同年の Pega Infinity リリースに合わせて提供開始とアナウンスされました。あわせて、A2A（Agent2Agent：エージェント間連携）や MCP（Model Context Protocol：エージェントと外部ツール・データの接続）といった相互運用標準への対応も示されています。

設計時の AI と実行時の AI を分ける

もう 1 つ重要なのが、AI の創造性を使う場面の分離です。Pega のアプローチでは、AI が自由に発想してよいのは「ワークフローを設計する場面」（例：Pega Blueprint によるワークフロー設計支援）であり、本番の実行時には、エージェントは承認済みのワークフローを見つけて従うという役割分担になっています。この「設計時の創造的な推論と、実行時の統制された実行の分離」は、Pega が Agentic Process Fabric の発表時に公式に掲げた設計原則でもあります。創造は設計時に、実行は統制下で——ミッションクリティカルな場面から不確実性を排除する、理にかなった整理です。

なお、Pega の AI 機能は製品名・提供範囲の変化が非常に速い領域です。個別の機能名や提供状況は、検討時点で必ず pega.com の最新情報を確認してください。本記事で押さえるべきは、機能名よりもこの設計思想です。

比較：プロンプト駆動の自律 vs ワークフロー統制下の自律

観点	統制なき自律（プロンプト駆動）	ワークフロー内の自律（Pega 型）
行動範囲の定義	プロンプト（自然言語・強制力なし）	ケースモデル（構造として強制される）
幻覚時の影響	誤判断がそのまま実行される	枠外は実行させず、要所は承認で止まる
人の関与	事故後の後始末	事前に設計された承認ポイント
監査	判断過程の再現・説明が困難	ケース履歴で全行動を追跡可能
変更管理	プロンプト修正の影響が読めない	ルール・プロセスとして版管理できる
向く用途	個人の生産性支援、下書き作成	基幹業務・規制業務の自動化

具体例：保険金請求の一次処理で考える

抽象論では判断できないので、保険金請求の一次処理を例にします。

ワークフロー統制下のエージェントは、こう働きます。請求ケースが起票されると、エージェントが提出書類から情報を抽出してケースデータに転記し、不備チェックを行い、約款と照らした一次判定案を作る——ここまでが「ワークフロー上でエージェントに割り当てられたステップ」です。そして、一定金額以下かつ低リスクの案件はストレートスルーで進み、閾値を超える案件・不正の疑いがある案件は、必ず人間の査定者への承認ステップにルーティングされる。この分岐は AI の裁量ではなく、ケースモデルに定義された業務ルールです。抽出した値も判定案も、すべてケース履歴に残ります。

同じ業務を「自由に動くエージェント」でやると、支払可否の判断根拠も金額の妥当性もプロンプトの解釈次第になり、監査で「なぜこの請求を自動承認したのか」に答えられません。業務の中身は同じでも、自律性を置く枠の違いが、監査に耐えるかどうかを分けます。

企業が今準備すべきこと：AI より先に「AI が働ける場」を作る

ここまでの整理から、導入側の準備は自然に導かれます。ポイントは、どれも AI 製品の選定より先にやるべき仕事だということです。

1. 業務プロセスのデジタル化——AI の職場を作る

エージェントがステップを担当するには、そもそも業務がワークフローとして定義されている必要があります。紙の回覧、メール往復、属人的な Excel のままでは、AI に「どのステップを任せるか」を定義する土台がありません。プロセスが構造化されていない業務に AI エージェントは配属できない——これが最も見落とされている前提です。

2. データの整備——AI の判断材料を揃える

エージェントの判断品質は、参照するケースデータとマスタデータの品質で決まります。判断に必要な情報がシステムに構造化されて存在するか、更新されているか。データが散在・陳腐化したままでは、統制の枠を用意しても中で働く AI が使いものになりません。

3. 人の承認ポイントの設計——どこまで任せるかを決める

「全部自動」でも「全部人間」でもなく、金額・リスク・影響範囲に応じて、どこからは人が最終責任を持つかを業務ルールとして定義します。これは AI の設定ではなく業務設計そのものであり、現場と管理部門を交えて決めるべき意思決定です。

つまり実務的な結論はこうです。「AI エージェント導入」の前に「業務プロセスの構造化」が先。この順番は Pega を使うか否かに関わらず成り立ちますが、ワークフローのモデル化・承認設計・監査証跡を標準機能として持つ Pega のようなプラットフォームは、この「AI が働ける場」を最短で用意できる選択肢だと言えます。

よくある失敗

失敗 1：チャットボットの成功体験を基幹業務に外挿する

社内 FAQ ボットや下書き生成で成果が出たので、同じノリで基幹業務にエージェントを入れようとするパターン。誤答しても人が読み捨てられる低リスク用途と、誤動作が実害になる基幹業務では、要求される統制のレベルがまったく違います。PoC の成功は統制設計の代わりになりません。

失敗 2：統制をプロンプトで書こうとする

「〜してはいけない」を延々とプロンプトに書き足して統制した気になるパターン。前述の通りプロンプトに強制力はなく、禁止事項が増えるほど挙動は不安定になります。統制は権限・プロセス・承認フローの層で構造的に実装すべきもので、自然言語の層でやるべきではありません。

失敗 3：プロセス未整備のまま AI から着手する

「まず AI を入れて、業務はおいおい」という順番の逆転。属人化した業務にはエージェントに割り当てるステップも承認を差し込む場所もなく、結局「何をさせるか決められない」ところで頓挫します。プロセスの構造化という地味な工程を飛ばした AI 導入は、ほぼ確実に PoC 止まりになります。

まとめ

• エージェント型 AI の基幹業務利用を阻むのは幻覚の実行・権限逸脱・監査不能の 3 点。統制なき自律は事故のもと
• Pega のアプローチは、AI の自律性をケース／ワークフローの枠内に置くこと。何をしてよいか・どこで人が承認するかをプロセスで統制する Predictable AI
• AI の創造性は設計時に使い、実行時は承認済みワークフローに従わせる分離が、ミッションクリティカル領域での要点
• 企業の準備は ① プロセスのデジタル化 ② データ整備 ③ 承認ポイント設計 の 3 つ。いずれも AI 製品選定より先
• 順番はひとつ——「AI エージェント導入」の前に「業務プロセスの構造化」

AI エージェントの時代に価値を持つのは、AI そのものよりも「AI が安全に働ける業務基盤」です。ワークフローのモデル化はその中核であり、いま業務プロセスを構造化しておくことが、そのまま Agentic AI 時代への投資になります。

---

業務プロセスの構造化や Pega Platform での AI 活用をご検討の際は、Pega Platform 開発支援 や 無料相談 をご利用ください。ワークフロー設計の実装経験にもとづき、統制設計からご支援します。

関連リンク

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