Pega 連携は同期か非同期か｜コネクタ直呼びとキュープロセッサの使い分け
外部連携をすべてケースフロー内で同期呼び出しにしていると、相手システムが遅い・落ちているだけでケースが止まります。本記事では、同期コネクタとキュープロセッサ（非同期）の使い分けを、ユーザー応答性・障害分離・スループットの観点から整理し、どの連携をバックグラウンドへ逃がすべきかの判断軸を示します。
結論から：即時結果が要る呼び出しだけ同期、それ以外は非同期に逃がす
Pega で外部システムと連携するとき、多くの現場が最初は「ケースフローの中にコネクタ（Connect-REST / Connect-SOAP など）を置いて、そのまま呼ぶ」という素直な作りから始めます。これは動くのですが、連携先が増えて負荷が上がってくると、ある共通の症状が出ます。相手システムが遅い、あるいは落ちているだけで、こちらのケースが進まなくなるという症状です。
結論を先に言うと、判断軸はシンプルです。
その呼び出し結果を、そのステップの中でユーザーや後続処理が即座に使う必要があるものだけを同期にする。即時結果が要らない、相手障害からケースを切り離したい、スループットを制御したい——このいずれかに当てはまるなら非同期（キュープロセッサ）へ逃がす。
「外部を呼ぶから」「重要な連携だから」という理由で全部同期にするのは誤りです。重要かどうかと、同期にするかどうかは別の軸です。本記事では、この判断を 3つの軸に分解し、非同期化の手段の選び分け、そして非同期にしたときに必ず設計し直すべきエラー処理まで、実装観点で落とし込みます。
Pega のコネクタは既定で同期 — それが意味すること
まず前提を正確に押さえます。Pega のコネクタ（Connect-REST / Connect-SOAP など）は、既定で同期実行です。ケースのフローの中でコネクタを呼ぶステップに来ると、Pega は相手システムへリクエストを送り、応答が返ってくるまでそのスレッドで待ちます。応答が返って初めて、次のステップへ進みます。
これは裏を返すと、次のことを意味します。
- 相手の遅延がそのままケースの遅延になる。 連携先の応答が 5 秒かかれば、ユーザーは 5 秒待たされます。
- 相手の停止がそのままケースの停止になる。 連携先がダウンしていれば、タイムアウトまで待たされ、その後は例外処理に落ちます。連携先の障害が、こちらの業務進行に直接波及します。
- 同時実行数が相手に引きずられる。 遅い連携をフロー内で同期呼び出ししていると、待ちのスレッドが積み上がり、リクエスタやスレッドプールを圧迫します。
同期実行そのものが悪いわけではありません。呼び出し結果をその場で使いたいケース——たとえば「入力された住所を外部の住所検証 API で確認し、その結果を画面に返して次の入力に進む」ような場面では、同期でなければ成立しません。ユーザーは結果を待っていて、その結果が次の判断に直結するからです。
問題は、結果をその場で使う必要がない連携まで同期にしてしまうことです。「基幹システムへ実績を登録する」「外部の通知サービスへメールを投げる」といった、成否を後で確認すれば十分な連携をフロー内で同期実行していると、相手が遅い・落ちているだけでケースが止まる、という冒頭の症状に直行します。
非同期化の選択肢 — 手段は目的で選ぶ
「非同期にする」といっても手段は一つではありません。目的に応じて使い分けます。混同すると、要件に合わない手段を選んでしまいます。
| 手段 | 何をするか | 向いている目的 |
|---|---|---|
| キュープロセッサへのオフロード | 呼び出しをメッセージとしてキューに積み、バックグラウンドのプロセッサが処理する | 相手障害からのケース分離、スループット・流量の制御、回数・間隔を設定できる自動リトライ |
| コネクタの並列実行（子リクエスタ） | 複数のコネクタ呼び出しを子リクエスタで同時に走らせ、Connect-Wait で結果を待ち合わせる | 独立した複数の外部呼び出しを、フロー内で速く終わらせたい |
| データページの非同期ロード | データページの読み込みをバックグラウンドで先行させ、必要になった時点で待ち合わせる | 画面表示に要る参照データを、待ち時間を隠して取得したい |
本記事の主題である「相手障害からケースを切り離す／スループットを制御する」という目的に最も効くのは、キュープロセッサへのオフロードです。呼び出しを一度キューに積んでしまえば（Queue-For-Processing メソッドや Run in background シェイプ経由）、ケースフローはその場で先へ進めます。実際の外部呼び出しは、キューを消化するバックグラウンドのプロセッサが担い、相手が遅くても落ちていても、ケースの進行とは切り離されます。
一方、コネクタの並列実行やデータページの非同期ロードは、コネクタを子リクエスタで走らせて Connect-Wait で合流する仕組みで、あくまで「フロー内・画面内の待ち時間を短くする」ための手段です。結果は最終的にその場で待ち合わせます。障害分離やスループット制御が目的なら、これらではなくキュープロセッサを選びます。目的が「複数の同期呼び出しを速くしたい」なのか「そもそも切り離したい」なのかを、最初に言語化しておくことが肝心です。
補足： コネクタ自体にも「実行モード＝キュー（Queuing）」という古くからの非同期モードがありますが、これは
Pega-IntSvcsのProcessConnectQueueエージェントが処理する旧来の仕組みです。新規設計では、Queue-For-Processing＋ キュープロセッサ（後述の Kafka ベース）でオフロードする構成を基本に考えると、リトライや隔離の設定が扱いやすくなります。
判断の3軸 — 同期のままか、非同期へ逃がすか
キュープロセッサへ逃がすべきかどうかは、次の3つの軸で判断すると迷いません。いずれか一つでも「はい」なら非同期を検討する、という型です。
軸1：即時結果が要るか
その呼び出し結果を、同じステップの中でユーザーや後続処理が即座に使うか。
- 使う（画面に返す、次の判断の条件にする） → 同期が必要
- 使わない（成否は後で反映・通知すれば十分） → 非同期の候補
これが最も基本の軸です。ユーザーが結果を待っていて、その結果で次の画面や分岐が決まるなら、同期以外に選択肢はありません。逆に「登録できていればよい、結果は後で分かればよい」なら、そこは非同期に逃がせます。
軸2：相手障害からケースを分離したいか
連携先の遅延・停止が、こちらのケース進行を止めてよいか。
- 止まってはいけない（相手が落ちていてもケースは進めたい） → 非同期
- 止まってよい／そもそも結果が要る → 同期でよい
基幹システムや外部 SaaS など、自分たちの管理外にあり、可用性を保証できない相手ほど、この軸で非同期に倒す価値が高くなります。キューに積んでしまえば、相手の障害はキューの滞留として現れ、ケースそのものは止まりません。
軸3：スループット・流量制御が要るか
大量の呼び出しが発生し、相手が受けきれる速度に合わせて流したいか。
- 要る（ピークを平準化したい、相手のレート制限を守りたい） → 非同期
- 要らない（呼び出し頻度が低く、相手も十分速い） → 同期でよい
同期のフロー内呼び出しには、流量を調整する仕組みがありません。発生した分だけ即座に相手へ投げます。キュープロセッサを挟むと、瞬間的なピークはキューが吸収し、相手へ出ていく流量はプロセッサのスループット設定（スレッド数など）で頭打ちになります。結果として、相手のレート制限を超えにくくなり、過負荷を防ぎやすくなります。
判断早見表
| 観点 | 同期コネクタ（フロー内） | 非同期（キュープロセッサ） |
|---|---|---|
| 即時結果 | 必要（画面・次の判断に使う） | 不要（後で反映・通知で十分） |
| 相手障害時のケース | 相手に引きずられて止まる | 切り離される（キュー滞留として現れる） |
| スループット・流量制御 | できない（発生分を即投げ） | できる（プロセッサのペースで消化） |
| エラーの伝わり方 | その場で例外として即伝播 | フロー外で扱う（別設計が必要） |
| 実装のシンプルさ | シンプル（呼んで待つだけ） | エラー・結果反映・再試行の設計が要る |
| 向いている場面 | 住所検証・与信照会など即答が要る呼び出し | 実績登録・通知・大量バッチ連携など |
3軸のいずれも「いいえ」なら、素直に同期にする——これが実務での判断の型です。非同期は強力ですが、後述するエラー設計のコストを払う価値がある場面に限って使います。
Standard か Dedicated か — キュープロセッサの選び分け
非同期にすると決めたら、次は「どのキュープロセッサで処理するか」という分岐が来ます。Pega のキュープロセッサには Standard と Dedicated の 2 種類があります。
- Standard キュープロセッサ — プラットフォームが標準で備える共有のキュープロセッサ（
pzStandardProcessor）。専用ルールを作らずに、軽量・非クリティカルな非同期処理を手軽に相乗りさせるためのもの。共有のトピックにメッセージを積むため、スループットやリトライの設定も共有の既定に従います。 - Dedicated キュープロセッサ — 連携ごとに専用で定義するキュープロセッサ。専用の Kafka トピックを持ち、独立したスループット設定・リトライ設定を持たせられます。すぐに処理する「即時（immediate）」と、指定時刻まで待たせる「遅延（delayed）」を選べるのも Dedicated 側です。重要度が高い連携や、高負荷で他の処理と混ぜたくない連携に向きます。
判断のポイントは「その連携が、独立した設定と隔離を必要とするか」です。
| 判断ポイント | Standard | Dedicated |
|---|---|---|
| 位置づけ | 共有・汎用（pzStandardProcessor） | 専用に定義（専用の Kafka トピック） |
| スループット/リトライ設定 | 共有の既定に従う | 連携ごとに独立して持てる |
| 他処理との隔離 | 相乗り（互いに影響しうる） | 隔離できる |
| 実行タイミング | 即時 | 即時／遅延（delayed）を選べる |
| 向いている連携 | 軽量・非クリティカルな非同期処理 | 重要／高負荷／独自のリトライ方針が要る連携 |
たとえば「一日数万件が流れ、相手のレート制限に厳密に合わせたい基幹連携」を Standard に相乗りさせると、他の非同期処理まで巻き込んで滞留させかねません。こうした重要で高負荷な連携は Dedicated に分離し、その連携専用のスループットとリトライを設定するのが定石です。逆に、頻度が低く失敗しても致命的でない処理まで Dedicated を量産すると、管理対象がいたずらに増えます。既定は Standard、独立設定・隔離が必要になったら Dedicated、という順で考えると過不足がありません。
バージョン依存の注意： キュープロセッサは Pega Platform 8.1 で Job Scheduler とともに導入された Stream（Kafka ベース）の仕組みで、Infinity ‘25 時点でも標準の非同期処理基盤です。処理には最低 1 つの Stream サービス（ノード）が必要で、旧来の Agent とは構成も設定も異なります。設定項目・既定値・上限などの挙動はバージョンによって差があるため、実装時は必ず対象環境の公式ドキュメントで確認してください。
非同期化で失う「即時エラー伝播」をどう補うか
非同期化の設計で最も見落とされるのが、ここです。同期でコネクタを呼んでいたとき、呼び出しの失敗はその場で例外として返り、フローの例外処理で拾えていました。ユーザーにもすぐエラーを見せられました。非同期にすると、この即時のエラー伝播が消えます。呼び出しはフローの外（バックグラウンドのプロセッサ）で走るため、失敗しても、その瞬間にケースフローへ戻ってきてはくれません。
したがって、非同期にした連携では、同期のときに暗黙に得ていた3つのことを明示的に設計し直す必要があります。
- 結果の反映 — 呼び出しが成功したら、その結果をどうケースへ書き戻すか。ケースのステータスを進めるのか、フラグを立てるのか。処理が完了したことを、どうやってケース側が知るか。
- エラー通知 — 呼び出しが失敗したとき、誰にどう知らせるか。担当者に差し戻すのか、監視用のワークキューに積むのか、運用へアラートを飛ばすのか。放置すると「キューの中で静かに失敗し続けている」状態になり、誰も気づきません。
- リトライ — 一時的な失敗（相手の瞬断など）を何回・どの間隔で再試行するか。キュープロセッサ側には最大試行回数（Max attempts）や再試行間隔・遅延係数（delay factor）の設定があり、上限まで再試行しても失敗したメッセージは broken item（壊れたキュー項目）として退避されます。これをどう検知し、どう再投入するかまで含めて設計します。
キュープロセッサはリトライの仕組みを備えていますが、「何回リトライして、それでも駄目なら何をするか」までを含めて設計するのは開発側の責任です。ここを設計せずに非同期化だけ進めると、「相手が落ちてもケースは止まらないが、失敗した連携が誰にも気づかれないまま broken item に溜まり続ける」という、同期時代とは別の事故に置き換わります。非同期化は、障害分離というメリットと引き換えに、エラーの可視化を自前で作る義務を負う、と理解してください。
よくある失敗
外部連携の設計で繰り返し見る失敗は、だいたい次の4つに集約されます。
失敗1：何でもフロー内で同期呼び出し
最も多い失敗です。結果を即使わない連携（実績登録、通知、ログ送信など）まで同期でフロー内実行しているため、相手が遅い・落ちているだけでケースが止まる。まさに冒頭の症状です。軸1〜3で見直し、即時結果が要らないものはキュープロセッサへ逃がすのが対処です。
失敗2：非同期にしたが、エラー設計を怠る
同期を非同期に置き換えたはよいものの、結果反映・エラー通知・リトライを設計していないパターン。ケースは止まらなくなった一方で、失敗した連携がキューの中で静かに滞留・消失（broken item 化）し、業務データの不整合として後日発覚します。前節のとおり、非同期化とエラー設計はセットです。
失敗3：重い連携を Standard に相乗りさせる
高負荷・重要な連携を Standard キュープロセッサに相乗りさせ、他の非同期処理まで巻き添えで詰まらせるパターン。独立したスループット・リトライが要る連携は Dedicated へ分離します。
失敗4：Agent 時代の感覚のまま設計する
旧バージョンの Agent の構成・チューニング感覚のまま、Pega 8.1 以降のキュープロセッサ（Stream/Kafka ベース）を設計してしまうパターン。両者は仕組みが異なり、設定項目も挙動も違います。対象環境のドキュメントで前提を確認してから設計・チューニングしてください。
まとめ
- 同期は「結果をその場で使う呼び出し」に限定する。 重要かどうかは判断軸ではない
- 判断は 3軸（即時結果が要るか／相手障害から分離したいか／スループット制御が要るか）で行い、いずれか一つでも「はい」なら非同期を検討する
- 非同期化の手段は目的で選ぶ。障害分離・流量制御ならキュープロセッサ、フロー内の待ち短縮なら並列実行やデータページの非同期ロード
- キュープロセッサは 既定は Standard、独立設定・隔離が要るなら Dedicated（Dedicated は即時／遅延を選べ、専用トピックを持つ）
- 非同期化は 即時エラー伝播を失う。結果反映・エラー通知・リトライ（Max attempts と broken item の扱い）を必ず別設計する
- キュープロセッサは Pega 8.1 以降の Stream（Kafka）機能で旧 Agent とは異なる。挙動は版によるため対象環境で確認する
外部連携の同期／非同期は、Pega アプリケーションの応答性・堅牢性・スループットの土台になります。「結果をその場で使うか」をフィールドごと・呼び出しごとに最初に言語化しておくだけで、後工程の障害対応と性能問題を大きく減らせます。
Pega の連携設計・実装でお困りの際は、Pega Platform 開発支援 や 無料相談 をご利用ください。Pega 認定資格の最高位 LSA（Lead System Architect）を保有するコンサルタントが、同期／非同期の設計判断からご支援します。
関連リンク
関連記事
Pega 宣言的処理のコスト設計｜前方連鎖と後方連鎖の使い分け
Declare Expression は便利だが、前方連鎖のカスケードは1つのプロパティ変更が広範な再計算を引き起こす。宣言的処理は「書けば動く」半面、実行コストが見えにくい。本記事は前方連鎖と後方連鎖、宣言的と手続き的の境界線を、性能と保守性の観点で整理する。
記事を読むPega Insights と Report Definition の使い分け｜セルフサービス分析と運用レポートの線引き
「レポートは Report Definition で作るべきか、Insights でユーザーに任せるべきか」——ダッシュボード設計で必ず出る分岐です。統制と再利用が要る定型レポートはルール化し、アドホックな探索はセルフサービスに開く、が基本方針。本記事では両者のガバナンス差とデータソースの前提から、線引きの判断軸を示します。
記事を読むPega 監査証跡設計：フィールド監査・履歴・セキュリティ監査の使い分け
「何を、どこまで監査するか」は Pega のセキュリティ設計で最も判断が割れるテーマです。フィールド監査・ケース履歴・セキュリティイベントの使い分けと、監査のかけ過ぎが招く性能・容量問題の回避策を、LSA の視点で解説します。
記事を読む