MVPセッションで、BPE7,5のお話を先出しで聞いてきました。
私の乏しいリスニング能力で必死に聞き取れたぶんだけですが、要点をまとめます。
リスニング力のみならず理解力も乏しいので、わからなくても聞き取れたまま書いているところもあります。
「いやそこは違うだろ」ってところがあったらコメント欄で教えてください。
BPE7.5 の大規模アップデートの要点
- 後方互換性（旧バージョンRRの共存）
- Chromium Spy Mode の大幅刷新（ブラウザ拡張依存の解消）
- Webhooks（Work Queue Items へのイベント駆動連携）
「後方互換」が今回の最大の目玉。
アップグレードのリスクと工数の劇的削減を狙っている機能改善です。
1. 後方互換性（旧バージョンRRの共存）
概要
投影されたスライドでは以下のように説明されていました。
“Reduced regression risk for future upgrades”（アップグレードの回帰試験負荷を大きく減らす）
- Upgrade with confidence
- Run multiple versions（同時に2つ以上の RR バージョンを接続）
- Staggered approach（プロセス単位で移行）
- Flexibility and control（どの RR で何を動かすか制御）
- Business continuity（回帰試験中も本番稼働継続）
- Save costs（並行環境構築の不要化）
つまり
BPE7.5のAPサーバは、7.5のRRと一緒に、7.1.2のRRをそのまま接続可能！
ってことです！
これの何がいいかというと
現行では、アップグレード時には
- まず評価環境を建てる
- 新バージョンのDBサーバ、APサーバ、IC、RRひとそろい設定
- 評価環境にプロセス全部エクスポートインポートして全部テスト
- OKになったら新バージョンにアップグレード
というような作業が必要でした。
7.5では
- まず、DBサーバ、APサーバ、API、ICを7.5にアップグレード
- 7.5のRRを新規で1個作る
この時点で、旧バージョンと新バージョンのRRが混在している状況になります。 - 新バージョンRRで回帰試験を実施
本番処理は現行どおり旧バージョンRRで実行してOK。
APサーバは両者を認識して、新旧RRに適切に処理を割り当てることができます。
本番の停止ゼロ（Zero Downtime）での移行が可能。
これこそが「安全な移行ルート」です。
評価環境を別に建てなくていい！
プロセス全部エクスポートインポートとかの手間がない！
一気にじゃなくだんだん移行できる！
現行環境を止めなくて大丈夫！
もう「アップグレードのたびに全環境入れ替え」は必要なくなります！
なんでそんなことができるのか
BPE7.5の「複数バージョンのRRが接続できる」仕組みは、APサーバ内のDLL群が各バージョンとの互換層を提供しているため。
旧バージョンはなんでもいいの？
だったらウチの6.10を一気に7.5に上げちゃおう！
と盛り上がったあなたに悲しいお知らせです。
残念ながら、後方互換性は「7.1.2以降」のみ適用です……。
これはBPE側ではなくて、ブラウザ（Chromium）側の問題です。
manifest v3などの問題。7.1.2より前のバージョンでは、ブラウザ操作の仕組みが根本的に異なるためです。
なので7.5.xとかを待ったらウチの6.10でもいけるようになるかも…！という期待はナシで。
7.1.2より前のバージョンについては、このお話は諦めてください。
7.1.2以降のバージョンだったらなんでもいいの？
投影資料には
supported version 7.1.2 initially
“extensions to follow in subsequent patch versions”
と記載されていました。
最初は 7.1.2 のみ対応ですが、後続パッチ（7.5.1、7.5.2、…）で対応範囲を広げる方針のようです。
2. Chromium Spy Mode（ブラウザ自動化の刷新）
これまでの課題
投影スライドより
- “Knowing when work is complete”（後続処理の同期問題）
- “Reliance on browser extensions”（ブラウザ拡張の配布・セキュリティ審査が重い）
- 拡張が通信のブローカーであることによる障害発生・遅延
改善内容
- ブラウザ拡張不要の自動化へ移行
- Chromium Debugger API を活用し、通信 hops を削減
- 要素認識が高速化
- double click、invoke JavaScript など高度な操作が可能
要は「アプリケーションモデラーがめっちゃ良くなる」。
投影資料に書いてあった主な強化点は
- Smart Vision / Enhanced Application Modeller の機能拡張
- Collection fields への “Update all references” 拡張
- Highlight operation（要素ハイライト）の高速化（5秒 → 2秒）
- Chromium Spy Modeとアプリケーションモデラーの統合
正直、私のオツムでは、このへんは実物デモを見ないことには、どのくらいすごいのか理解できておりません……。
少なくとも「今までのブラウザ拡張は要らなくなる→ブラウザ拡張周りのトラブルがまるっと消滅する」ということであるらしい。
Chromium Spy Modeとは
- Chrome / Edge を対象とした 新ブラウザ自動化方式
- Browser Extension を利用せず、Chrome DevTools Protocol を直接利用
- メッセージ中継のブローカーが不要になり、安定性と速度が大幅改善
移行前チェックリスト
- 現行プロセスのブラウザ操作ステージを棚卸し
- アプリケーションモデラーが「拡張ベース」かどうか確認
- Edge / Chrome のバージョンと組織ポリシー (拡張配布) を確認
- UAT環境に7.5のRRを用意する
移行時の注意点（重要）
アプリケーションモデラーは再スパイが必須
- 旧モデル（ブラウザ拡張方式、つまり7.1.2より前）は互換性なし
- Spy Mode の切替は「アプリケーションモデラーの再作成」と同義
- 特に「マッチインデックス」が変化するため要注意
ブラウザ起動パラメータ
- 既存ブラウザプロセスがいるとコマンドライン引数が無効
→ スタート時に kill → 再起動が必要
要素取得の変化
- iframe、shadow-root の扱いが改良されている
- アクション名が異なる場合がある（クリック系など）
おおよその移行手順
Step 1：Spy Mode の切替
アプリケーションモデラーは「Browser Automation using Chromium Spy Mode」を選択
ウィンドウまたは URL を指定し、要素を再スパイする
Step 2：主要操作の正常動作確認
click / double click
wait（implicit wait, explicit wait）
JavaScript 実行
navigate / refresh
Step 3：プロセスの再テスト
既存プロセスに新アプリケーションモデラーを統合
ステージ単位で再テスト
「Document Complete」 の判定が旧方式より高速である点に注意
Step 4：RR の差し替え
プロセスが新モデルで安定 → 本番 RR を順次 7.5 へ切り替え
3. Webhooks（Work Queue Items へのイベント駆動連携）
目的
既存の「Blue Prism API をポーリングする方法」は非効率で、外部システムからの状態監視に時間がかかります。
BPE7.5ではWebhooksが正式導入されます。
これにより、以下が可能になります。
- 外部システムに「キューアイテムの状態変化」などを リアルタイム通知
- API ポーリングの負荷軽減
要するに「Blue Prismから外部に通知やデータを発信できるようになる」ということです。
キューアイテムが完了したらTeamsへ通知するとか、処理が完了した後の工程をキックするとかいった構成が実現できます。
外部連携がリアルタイム化できるようになるってことですね。
Webhook 利用に必要な構成
- Webhooks は API サーバーが必要。
（Hub 認証サーバーではなく、App Server 側に API が有効であることが必須）
また企業環境で利用するには Hub 認証に依存するため、App Server 99% の構成要件を満たす必要がある。
Webhook の説明補足
- Webhook Subscription 作成後の管理は API ではなく Blue Prism Server が担当する
- 認証は Credential Manager により自動化
- payload には ID、イベント種別、timestamp など
Webhook 利用例（案）
Salesforce 連携（Experience Cloud / Service Cloud）
- フロー例
- Blue Prism が顧客ケース処理を完了
- Webhook → Salesforce Apex REST
- Salesforce側でケースのステータスを更新
- Experience Cloudユーザに自動メール通知
- メリット
Salesforce 側で「BP 処理完了」がリアルタイム反映され、「キュー投入 → 処理完了 → 顧客通知」の自動チェーンが完成
Slack 連携（オペレーション通知）
- フロー例
- Webhook で BP 処理完了イベントを受信
- Slack API を呼ぶ
- Slack の #rpa-opsチャンネルに処理完了通知を投稿
- メリット
Slack 運用と BP 運用が統合されリアルタイム化
PowerBIでリアルタイム監視ダッシュボード
- フロー例
- Work Queue Item 完了時に Webhook で JSON を送信
- （HTTP POST）→ 中間APIで受け取り整形
- Power BI REST API（Add Rows In A Dataset など）を呼び出して、対象のPush Datasetに行を追加
- Power BI レポート／ダッシュボードで即時反映
- メリット
ダッシュボードをTeamsにピン留めしておけば、Blue Prismの処理結果をほぼリアルタイムで監視できる
終わりです
たぶんこれで内容合ってると思います……。
絶対に抜け漏れがあると思うので、随時追記修正します。
現物を試してみたいかたは、こちらにトライアル版があります。
https://portal.blueprism.com/products/trial
こちらが公式の説明記事です。
SS&C Blue Prism Enterprise v7.5 - Backwards compatibility, webhooks and more