こんにちは！山崎です。

第1回では「触ってみる」ことをゴールにしましたが、
今回は「業務でどう組み込むか」を考える回です。

もう一歩進んで、

・実際の業務ではどう使うの？
・ExcelやQueueとはどう使い分けるの？
・設計で気をつけるポイントは？

といった 実運用の話 をしていきます。

　

---

目次

1. Data Fabricへのデータの入れ方5パターン
   • ① ロボットが自動でデータを書き込む
   • ② CSVで一括インポート（マスタの初期投入）
   • ③ UiPath Appsで人が入力・編集する
   • ④ロボットが「途中結果」を書き込む（人の確認を挟む）
   • ⑤ 外部システムを参照する（データをコピーしない）
2. じゃあ、Queueとはどう使い分ける？
3. 「全部Data Fabricに入れる」はおすすめしない
4. このデータ、ずっと溜め続ける前提？
5. まとめ：Data Fabricは「データのハブ」

---

1. Data Fabricへのデータの入れ方5パターン

前回はハンズオン用に、
ブラウザから手入力でデータを入れました。

でも実際の業務で
何千件も手で入力するわけがありませんよね。

Data Fabric は、
データ入力のパターンを業務に合わせて選べる
というのが大きな特徴です。

ここでは、
実運用で使えそうな 5つのパターン を紹介します。

　

① ロボットが自動でデータを書き込む

このパターンでは、
ロボット自身が処理の途中や結果を Data Fabric に書き込みます。

人が手で入力するのではなく、
ロボットが処理を進めながら、
必要なデータをそのまま Data Fabric に登録していくイメージです。

たとえば、Web申請を処理するロボットの場合。

ロボットは申請を1件取得したタイミングで、
申請内容を Data Fabric に登録します。

処理を開始したらステータスを「処理中」に更新し、
正常に終われば「完了」、
途中で失敗した場合は「エラー」と理由を書き込みます。

このように
処理の流れの中で、ロボットが自動的にデータを書き込む ことで、
結果として Data Fabric が「処理台帳」として使えるようになります。

Excelで手動更新していた進捗管理を、
ロボットが自動でやってくれるイメージです。

　

② CSVで一括インポート（マスタの初期投入）

社員名簿や支店マスタなど、
最初から Excel で持っているデータもありますよね。

そういったデータは、
Data Fabric の画面から CSV を指定して
まとめてインポートするのが一番手軽です。

数万件あっても問題ありません。

ポイントは、
「最初にまとめて入れるデータ」と
「日々更新されるデータ」を分けて考えること。

初期構築は CSV、
運用が始まったらロボットや Apps で更新、
という使い分けが良さそうだと思います。

　

③ UiPath Appsで人が入力・編集する

Data Fabric は、
ロボット専用というわけではありません。

人が触るデータ を扱う場面でも活躍します。

UiPath Apps の Edit Grid を使うと、
見た目も操作感もほぼ Excel な画面を作れます。

ただし、実際に Excel ファイルを開いて編集しているわけではなく、
裏側では Data Fabric のデータを直接更新しています。

そのため、
「誰かが開いていて編集できない」
「保存の競合でロボットが止まる」
といった Excel 特有のトラブルが起きません。

「現場の人に確認・修正してもらいたい」
そんなデータがある場合、
Apps と Data Fabric の組み合わせはとても相性がいいです。

　

④ロボットが「途中結果」を書き込む（人の確認を挟む）

ロボットが処理した結果を、
「最終結果ではなく、途中経過として Data Fabric に書き込む」
という使い方もあります。

たとえば、請求書処理のような業務です。

ロボットが請求書を読み取っても、
金額や取引先は人が一度確認したい、というケースはよくありますよね。

この場合、ロボットは、

・請求書の読み取り結果を Data Fabric に保存
・ステータスを「要確認」に設定

します。

人は UiPath Apps で一覧を確認し、
必要があれば修正したうえで「承認済」に更新します。

そしてロボットは、
承認済になったデータだけを拾って、
後続の処理を進めます。

このように、

ロボットが途中結果を書き込み、
人が確認し、
またロボットが続きを処理する

という流れを作れるのが、
Data Fabric の大きな強みです。

結果として、
Data Fabric は 人とロボットの「待ち合わせ場所」 になります。

※Maestroなどを使用するプロセスに向いた使い方です

　

⑤ 外部システムを参照する（データをコピーしない）

Data Fabric は、
必ずしもデータを中に「持つ」必要はありません。

Salesforce や SQL Server、Oracle などの外部システムを、
Data Fabric 経由でリアルタイムに参照するという使い方もできます。

UiPath から見ると
Data Fabric のエンティティとして扱えますが、
実際のデータは外部システム側にあります。

基幹データを二重に持ちたくない場合や、
参照だけで十分な場合に使われるパターンです。

　

2. じゃあ、Queueとはどう使い分ける？

ここはよく混乱しがちなので、
考え方だけ整理しておきます。

Queue は「処理を流す」ための仕組みで、
並列処理や再試行が得意です。

一方、Data Fabric は
「データを管理し、状態を持ち続ける」ための仕組みです。

実際の設計では、
Queue と Data Fabric を 併用するケースが多くなります。

たとえば、
Data Fabric にある未処理データを Queue に流し、
処理結果を Data Fabric に書き戻す、
という形です。

　

3. 「全部Data Fabricに入れる」はおすすめしない

ここ、けっこう大事な話です。

Data Fabric は便利ですが、
何でもかんでも入れる場所ではありません。

特に注意したいのが、

・PDF原本
・スクリーンショット画像
・添付ファイルを大量保存

こういった 重いファイル です。

Data Fabric は
「データ（文字・数値）」を扱うのが得意。

ファイルは、

・SharePoint
・Box
・OneDrive

などに置いて、
URLだけを Data Fabric に持つ
という設計が安全です。

　

4. このデータ、ずっと溜め続ける前提？

Data Fabric は、
データを「一時的にしか持てない」わけではありません。

ただし、設計としては、「いま処理に必要なデータ」や「状態を管理しているデータ」を中心に扱い、
古くなったデータは、

・ロボットでアーカイブする
・別の保管場所に移す（毎月動いて過去のデータを削除して保管場所に移すロボットを使用）

といった 運用でコントロールする のが現実的です。

溜め続けない前提で設計できるか

ここを一度考えておくと安心です。

　

まとめ：Data Fabricは「データのハブ」

Data Fabric は、全部を置くDBでもExcelの完全上位互換でもありません。

RPAで使うデータを集めて、つなぐ場所。
それが一番しっくりくる使い方です。

Excelでやっていた管理周りを、ちょうどよく整理してくれます。

次回は、

「じゃあ実際に使うとき、どこを押さえておけば安心なの？」
という話をまとめます。