ixp

latest

false

Communications Mining ガイド

最終更新日時 2025年11月10日

UiPath® Automation Framework

注:

アクセシビリティの強化 - アクティビティコンテンツの移動

UiPath では、ユーザーエクスペリエンスを向上させ、UiPath のリソースをよりユーザーフレンドリーにするために継続的な改善を行っています。

開発者ガイドを再編成し、各種アクティビティを新しい Communications Mining™ アクティビティガイドに移動しました。これにより、アクセスしやすくなり、ナビゲーションが向上しました。

この変更により、ユーザーエクスペリエンスが最適化され、必要な情報をより効率的に見つけられるようになりました。

概要

Communications Mining Dispatcher Framework は、Communications Mining™ を RPA の実装と連携させる際に使用できる UiPath® Studio のテンプレートです。このテンプレートは、Communications Mining ストリームからコメントを取得し、1 つまたは複数の UiPath Orchestrator の一意の参照キューに 1 つずつ追加するために使用されます。ストリームからのデータを入力として必要とする下流工程ごとに 1 つのキューを定義する必要があります。既定では、構成ファイル内に 2 つのプロセスキュー (プロセス A と B 用) と 1 つの汎用プロセスキューが設定されていますが、必要な数だけ設定できます。

フレームワークは、Studio の [テンプレート] で「 Communications Mining Dispatcher」を検索して取得できます。

大事な：キューを作成するときは、[ 参照の重複を禁止 ] オプションを選択します。

このテンプレートは Robotic Enterprise Framework (REFramework) に基づいており、Config.xlsx ファイルによる柔軟な構成、例外処理、リトライメカニズム、意味のあるログ記録など、RPA プロジェクトに不可欠なベストプラクティスをすべて網羅しています。

メモ: Communications Mining Dispatcher に慣れていない場合は、REFramework を使用する前に公式のドキュメントを確認してください。

REFramework プロジェクトより、Communications Mining のストリームのデータを使用するときに実行する必要がある 2 つの主要な操作である fetch (フェッチ) と advance (前進) がカプセル化されています。fetch は Communications Mining のストリームからデータを取得するプロセスであり、advance　は基本的にコメントを既読としてマークし、次回フェッチ時に同じコメントが返されないようにします。これらについては、次のセクションで詳しく説明します。

既定では、フレームワークはストリームの末尾を過ぎると、つまりストリームに未読のコメントがなくなったときに、フェッチとアドバンシングのサイクルを停止します。ただし、ストリームの末尾に達した場合も継続的に実行されるようにフレームワークを構成できます。これを行うには、Config.xlsx ファイルで ExitOnEmptyStream 設定を False としてマークします。この設定を使用すると、フレームワークは無限に循環し、フレームワークのプロセスがスケジュールに従って実行されるのを待たずとも、ストリームで利用可能になった新しいデータが即座に処理されます。

最終的な目標は、利用可能な Orchestrator キューで、対応するデータ、予測されたラベル、一般フィールドも含めて、コメントを利用できるようにすることです (1 つのコメントにつきキューアイテムは 1 つ)。これにより、下流のオートメーションが予測された情報にアクセスできるようになります。

コミュニケーションが検証ルールに違反していた場合、対応するキューに追加されることはありません。フレームワークには、主に各アイテムがどのプロセスに関連するかを把握するための基本的な検証ルールがいくつか定義されていますが、コードに独自の検証アルゴリズムを追加することもできます。また、例として、Config.xlsx ファイルには、下流のオートメーションプロセスごとに個別の検証設定シート (ProcessAValidations と ProcessBValidations) があります。これらは理論的なプロセスの例として構成されており、独自のシートと設定を自由に追加できます。

重要:

構成ファイルに (たとえ異なるシート上であっても) 同じ名前の設定が複数存在しないことを確認してください。これらはすべて同じ Config ディクショナリに追加され、相互に上書きされます。

ファイル内には、役に立つ可能性のある検証設定の命名規則の例もいくつか示されています。検証ルールをチェックするワークフローのロジックも同じ規則に従っているので、変更を加えた独自のルールを実装する際は注意してください。

検証に失敗した場合、情報は人間参加型のキューに追加されます。このキューには一意の参照も必要で、人間が Action Center で検証できます。人間参加型のキューの名前を構成ファイルに追加できます。
人間参加型のキューにトリガーを定義することをお勧めします。このキューは、新しいアイテムごとに新しいオーケストレーションプロセスを開始し、Action Center でタスクを作成します。タスクには現在のアイテムに対して Communication Mining から取得したデータが含まれ、対応する下流のオートメーションプロセスのキューにデータを送信する前に、人間がデータを検証する必要があります。

ストリーム

Communications Mining™ でモデルのトレーニングに成功したら、新しいストリームを作成して、トレーニングした各概念のしきい値を設定することができます。ストリームは、データセット内のコメントのコレクションを定義します。これにより、特定のモデルバージョンを使用して計算された、予測されたラベルと一般フィールドを使用して、コメントを永続的かつステートフルに反復処理できます。

注:

モデルのトレーニング手順や関連するすべての概念の詳細については、Communications Mining の公式ドキュメントをご覧いただき、UiPath アカデミーで学習されることをお勧めします。

UiPath® Studio と Communications Mining の連携では、Communications Mining ストリームからの各コメントが使用されます。その後、コミュニケーションの各予測を 1 つまたは複数の下流工程で使用できます。下の図では、UiPath と Communications Mining の一般的な連携について説明しています。

この方法では、n 個のオートメーションに対して、n + 1 個のプロセス (n 個の RPA プロセスと 1 個のキューフィーダー) を UiPath で構成することを推奨しています。シングルフィーダープロセスが導入されており、Communications Mining のストリームから構造化されたコミュニケーションを読み取り、Orchestrator のキューを介して関連する RPA プロセスに配信します。Communications Mining による抽出により発生する可能性のある例外は、人間が手動で検証するためにマークできます。キューからアイテムを取得するプロセスは、キューアイテムのデータから入力データを読み取る標準の UiPath のオートメーションです。提供されているディスパッチャーフレームワークは、キューフィーダーの役割を果たします。

フェッチアドバンスのループ

ストリームからのコメントを使用するには、フレームワークはフェッチと前進のループを実装する必要があります。これは次のように説明されています。

すべてのストリームには現在のコメントがあります。
この現在のコメントから始まるコメントを取得できます。次の画像では、2 つのコメントを取得しています。
ストリームから返されるすべてのコメントには、以下の sequence_id があります。
```
{
   "comment":{
      "messages":[ ... ],
      "user_properties":{ ... },
      "id":"comment 1"
   },
   "entities":[ ... ],
   "labels":[ ... ],
   "sequence_id":"ABC123"
}{
   "comment":{
      "messages":[ ... ],
      "user_properties":{ ... },
      "id":"comment 1"
   },
   "entities":[ ... ],
   "labels":[ ... ],
   "sequence_id":"ABC123"
}
```
この sequence_id を使用して、キュー内の現在のコメントを次に進めることができます。ここで、2 を取得すると、コメント 2 と 3 が返されます。

Communications Mining フレームワークでは、このフェッチとアドバンスのループが自動的に実装されます。

ディスパッチャーフレームワークの概要

必要な設定を変更するだけで、独自のストリームからのコメントを使用するようにディスパッチャーフレームワークを構成し、実装時間を節約して、ベストプラクティスに確実に従うことができます。

このフレームワークは、REFramework と同様に、プラグアンドプレイソリューションとしてそのまま使用できます。コードを変更することなく (Excel の構成ファイルに設定を追加するだけで)、定義されたストリームから各コメントを (CommunicationsMining パッケージで定義された CommunicationsMining.Result 型のオブジェクトとして (「依存関係」セクションを参照)) 取得するためです。対応するキューにデータを追加します。または、完全にカスタマイズし、必要に応じて独自のロジック (Communications Mining™ の予測を検証するためのルールなど) を追加することもできます。

Communications Mining Dispatcher Framework では、前述のようにフェッチとアドバンスのループのアプローチを使用しており、一度に 1 つのコメントを進めることも、一度に 1 つのコメントのバッチを進めることもできます (構成ファイルでバッチのサイズを設定可能)。ディスパッチャーは 1 つまたは複数の下流工程のフィーダーとして使用されます。したがって、構成ファイルでは、これらの各プロセスに対応するキューと、アイテムをキューに追加するためのルールも定義します。

全体的な手順は以下のとおりです。

コメントの最初のバッチを取得します。これにより、Communications Mining ストリームからのコメントのバッチ、バッチ内の最後のアイテムの sequence_id、および現在のバッチからフィルターで除外されたアイテムの数が返されます。
例外が発生せず (ストリームに正常に接続)、ストリームの最後でない場合は、現在のバッチに処理するアイテムが残っているかどうかを確認します (Communications Mining で現在のストリームにフィルターが適用されていて、現在のバッチのコメントがいずれも該当しない場合は、コメントのないバッチを取得する場合もあります)。
処理するアイテムがある場合は、それらを 1 つずつ処理します。現在のアイテムが属するコンシューマー RPA プロセスに応じて、アイテムのデータの検証ルールを確認します。
アイテムのチェックで問題がなければ、(Excel の構成ファイルの設定に従い) 新しいキューアイテムが関連するキューに追加されます。コメントの UID がキューアイテムの参照として設定されます。検証ルールに違反していた場合は、HitL キューにキューアイテムを追加します。作成されるすべてのキューアイテムには、下流工程で使用するコメントの一般フィールドとラベルの予測がすべて含まれます。
現在のバッチの各アイテムが処理されたら、最初に (バッチの最後のアイテムの sequence_id を使用して) ストリームを前進させ、次にストリームから新しいバッチをフェッチします。
(バッチ内のコメントが何も取得されず、フィルターで除外されたコメントがないために) ストリームの最後に達した場合は、そこで自動的に処理が終了します。

構成

ディスパッチャーの構成に必要なすべての設定は、Data/Config.xlsx ファイルにあります。

メモ: 対応するアセットをすべて Orchestrator に追加します。

設定とアセットシート

名前	説明
OrchestratorProcessAQueueName	ディスパッチャーが、RPA コンシューマープロセス A で処理する VALID コメントをプッシュするキューです。
OrchestratorProcessBQueueName	ディスパッチャーが、RPA コンシューマープロセス B で処理する VALID コメントをプッシュするキューです。
OrchestratorHITLQueueNameA	ディスパッチャーが、対応するプロセスに対して定義された検証ルールに合格しなかったコメントをプッシュするキューです。HITLQueue は人間参加型のオーケストレーションプロセスで処理され、このプロセスによって、追加された各キューアイテムの検証アクションが作成されます。
OrchestratorGeneralQueueName	ディスパッチャーが、特定の RPA コンシューマープロセスに分類されていないコメントをプッシュするキューです。
Communications MiningApiTokenCredential	ストリームから取得してストリーム内を進むために必要な Communications Mining™ API トークンです。資格情報アセットに格納されます。
ExitOnEmptyStream	この設定が False の場合、ストリームの最後に達しても、フレームワークは続けて実行されます。

各プロセス検証シート

名前	説明
{ProcessName}_Label	設定の命名規則は、現在のプロセス + "_" + "Label" キーワードにより処理されるよう指定されたコメントをマークするラベルです。この値は、下流工程の名前です。例: 名前 `Policy_Label`、値 `ProcessA`。

ディスパッチャーは 1 つまたは複数の下流工程の入力キューにデータを入力できるため、プロセスごとに新しいシートを構成ファイル内に作成し、そこでそのプロセスの検証ルールを定義することをお勧めします。シートの命名規則は、「{プロセス名}Validations」とする必要があります。既定では、構成ファイルにはプロセス A とプロセス B の 2 つの検証シートが含まれます。

例外処理

各トランザクションアイテム (Communications Mining™ のコメント) の処理中に発生した例外はすべて収集され、2 つのデータテーブル (システム例外用のデータテーブルと、ビジネスルール例外用のデータテーブル) に格納されます。

[プロセスを終了] ステートでは、例外処理のための表をビジネスロジックに従って使用できます (表を含む Excel ファイルの作成、レポートメールに添付された表の送信など)。

アーキテクチャ

依存関係

Communications Mining™ と連携して UiPath® から実行できる主な操作を処理するカスタムアクティビティ ([Fetch Stream]、[Advance Stream]) を作成しました。また、フレームワークのトランザクションは CommunicationsMining.Result 型です。このデータ型はパッケージで定義されており、各コメントに対して定義されたすべての情報と、それに対応する予測されたラベルおよび一般フィールドを保持します。

You need to have the CommunicationsMining package in one of your feeds, in order for the Dispatcher Framework to load correctly, downloaded from the Marketplace: here.

ステート

フレームワークは、基本的に REFramework であるため、同じステートのステートマシンです。各ステートの詳細については、REFramework のドキュメントをご覧ください。

唯一の変更点は、Get Transaction Data State と Get Transaction Data State 間への Advance Stream Transition の追加です。フェッチされた現在のバッチに処理するアイテムがない場合は、ストリーム内をさらに進めるよう、実行ステートは Get Transaction Data State に戻ります。

共有の変数

以下の変数は Main.xaml ファイルで宣言され、フレームワークで呼び出されるワークフローへの引数として共有されるか、単にフレームワーク内の実行フローを決定します。

変数名	説明
ShouldStop(Boolean)	ジョブが (Orchestrator から) 強制的に停止される場合に TRUE。
TransactionItem(CommunicationsMining.Result)	トランザクションアイテムは、Communications Mining ストリームからの 1 つのコメントで表されます。一度に 1 つのアイテムを処理し、そのデータを対応するキューに追加します。
SystemException(Exception)	ステート間の遷移中に、ビジネス例外以外の例外を表すために使用されます。
BusinessException(BusinessRuleException)	ステート間の遷移中に使用されます。自動化対象のプロセスのルールに反する状況を表します。
TransactionNumber(Int32)	トランザクションアイテムのシーケンシャルカウンターです。
Config(Dictionary(String,Object))	Dictionary structure to store configuration data of the process (settings, constants, assets and Validation properties).
RetryNumber(Int32)	システム例外の発生時に、トランザクション処理のリトライを試行する回数を制御するために使用されます。
TransactionData(IList(CommunicationsMining.Result))	最新の Fetch により現在ストリームから取得されているコメントのバッチです。
ConsecutiveSystemExceptions(Int32)	連続するシステム例外の数を制御するために使用します。
BusinessExceptionsDT(DataTable)	トランザクションの処理中に発生した BusinessRulesExceptions の詳細を含む表。1 つの行には、障害の発生した 1 つのトランザクションに関する情報が含まれます。
ApplicationExceptionsDT(DataTable)	Table with details on the System Exceptions occurred during the processing of the Transactions. One row contains info about one faulty transaction
GlobalRetryInterval(TimeSpan)	フレームワーク内のすべてのリトライスコープに既定で設定されているグローバルなリトライ間隔。
GlobalMaxAttempts(Int32)	The global number of Max Attempts set by default for every Retry Scope in the Framework.
CurrentSequenceId(String)	最新のストリームバッチの Fetch により取得されたシーケンス ID。これは、現在のストリームバッチの最後のアイテムのシーケンス ID です。
CurrentBatchFilteredResults(Int32)	Communications Mining でストリームに対して定義され、最新の Fetch により (現在取得されているバッチから) フィルターで除外された、フィルターに適合しないアイテムの数。
CommunicationsMiningApiToken(SecureString)	Communications Mining で定義されている API トークン。この値は、Orchestrator の資格情報アセットに保存する必要があります。
CurrentBatchNumber(Int32)	ストリームを複数のバッチに分割することをお勧めします (データ取得時間を短縮するため)。これにより、現在処理されているバッチがわかるようになります。
ShouldAdvanceTheStream(Boolean)	現在取得されているバッチで処理するアイテムがない場合は、ストリーム内をさらに進めるよう、実行ステートはトランザクションデータを取得に戻ります。

Communications Mining™ 固有のワークフロー

ワークフロー名	説明
GetNextStreamBatch	次の Communications Mining™ のストリームバッチのコメントの取得を試みます。[Fetch Stream] アクティビティは Communications Mining に接続し、Fetch 出力オブジェクトに次の情報を提供します。- (要求したサイズの) 結果のコレクション - 現在のバッチのシーケンス ID (取得したバッチの最後のコメントのシーケンス ID) - フィルターで除外されたコメントの数 (Communications Mining ストリームにフィルターを適用した場合) フィルターに一致しないコメントはスキップされます)、[Fetch] アクティビティは、Communications Mining に対する HTTPS 要求を実行します。
AdvanceStreamBatch	Communications Mining のコメントのストリームを前進させるよう試みます。[Advance Stream] アクティビティは、Communications Mining に接続し、ストリーム内のいずれかのコメントのシーケンス ID を入力として使用して、次回のストリームからのフェッチ時に同じコメントが返されないよう、(指定されたシーケンス ID のコメント以前の) コメントをストリームで既読としてマークします。ストリームを前進させずに連続して何度もフェッチを実行すると、毎回同じメールを取得します。[Advance] アクティビティは、Communications Mining に対する HTTPS 要求を実行します。
GetTransactionData	配列のコメントからトランザクションアイテムを取得します。複数のトランザクションがあるため、引数 in_TransactionNumber をインデックスとして使用して、処理する正しいトランザクションを取得します。現在のバッチにトランザクションが残っていない場合は、ストリームを前進させて次のバッチを取得する必要があります。ストリームを前進させずに連続して何度も取得を実行すると、毎回同じ結果が得られます。バッチにアイテムがあり、処理するアイテムがまだいくつか残っている場合は、バッチ内の次のトランザクションアイテムのインスタンスを取得します。それ以外の場合は、現在のバッチで処理するアイテムが残っておらず、ストリームを前進させる必要があることを示すフラグを立てます。フレームワーク全体の処理が停止してしまい、次のバッチにまだアイテムが残っている可能性もあるため、ここでは io_TransactionItem に何も設定しません。STOP 条件は、トランザクションデータを取得ステートで設定されます。
CheckValidationRules	これは、現在のアイテムに対して予測されたラベルの数に対してのみ予測が有効かどうかを判断する基本的な検証アルゴリズムの例です。ラベルが 1 つの場合は、検証に成功したことになり、構成ファイルから下流工程の名前を取得するだけで済みます。ラベルが複数ある場合は、自動検証が失敗として設定されます。コンシューマープロセスの名前と、アイテムの予測が有効か、それとも人間による検証が必要かを判断するための、独自のロジックを追加します。現在のアイテムに対して予測されるラベルが 1 つしかない場合は、対応するプロセスの名前を取得する必要があります。現在のアイテムに対して予測されたその 1 つのラベルに基づいて、構成ファイルから下流 (コンシューマー) 工程の名前を取得します。構成ファイルでは、プロセス名を設定する際の命名規則は、コメントのラベル + "_" + "Label" キーワードです。現在のアイテムに複数のラベルが付けられていると予測された場合は、下流のオートメーションをどう進めるかを人間が決める必要があります。したがって、自動検証の成功が false としてマークされ、現在のアイテムが後で手動で検証されるよう、人間参加型のキューに追加される必要があります。
CreateDictionaryFromCommunicationsMiningItem	Communications Mining から取得された現在のアイテムに関する情報をキューに追加できるよう、その情報に基づいたディクショナリを作成します。このディクショナリを使用して、新しいキューアイテムの定義プロパティが追加されます。
AddTransactionItemToQueue	キューに新しいアイテムを追加します。そのすべてのプロパティが in_QueueItemProperties ディクショナリで設定されている必要があります。キューの [参照の重複を禁止] チェックボックスがオンになっていることを確認します。
プロセス	ディスパッチャーは、Communications Mining™ で取得した各アイテムの情報を対応するキューに取り込み、下流のオートメーションのコンシューマープロセスで処理できるようにします。このワークフローでは、現在のアイテムを対応するキューに追加する必要があります。ステップ:1.TransactionItem に基づいてディクショナリを作成します。このディクショナリを使用して、新しいキューアイテムの定義プロパティを追加します。2.Communications Mining で現在のアイテムに対して取得した情報に基づいて、対応するコンシューマープロセスを決定し、予測されたデータを検証ルールに照らしてチェックします。3.検証に成功すると、コンシューマープロセスのキューにアイテムが追加されます。そうでない場合は、人間が検証し場合によっては処理するために、人間参加型のキューに追加します。現在のトランザクションの場合、ビジネスルール例外がスローされると、トランザクションはスキップされます。別の種類の例外が発生した場合は、現在のトランザクションをリトライできます。
ExceptionsHandler	このワークフローは、フレームワークの最後の例外ハンドラーとして使用される必要があります。入力データテーブルが入力されている場合、それらのテーブルには、現在のプロセスの実行中に発生したすべてのアプリケーションまたはビジネスルールの例外の詳細が含まれます。

フレームワークを使用する

フレームワークを使用する前に、以下を実行します。

必要なすべてのアセットを Orchestrator で設定し (「設定とアセット」セクションを参照)、データ/Config.xlsx ファイル内で必要な変更を加えます。
アイテムを追加するキューが Orchestrator に存在し、[参照の重複を禁止] チェックボックスがオンになっていることを確認します。キューに重複したアイテムが追加されたり、下流のオートメーションで同じアイテムが何回も処理されたりしないようにするためです。
Communications Mining/CheckValidationRules.xaml に独自の検証ルールを追加します。現時点では、現在のアイテムに予測されたラベルが複数あるかどうかのみがチェックされます。ある場合、検証は失敗します。なければ、ラベルに基づいて、現在のアイテムに対応するプロセス名が取得されます。