こんにちは！山崎です。

第1回・第2回では、

・Data Fabric の基本操作やStudioでの使い方
・実運用では、データの入れ方にいくつかのパターンがあること

を見てきました。

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

ポイントは3つです。

・Maestro / Agentic Automation との関係
・Choice Set（チョイスセット）という便利機能
・気になるコストと容量の考え方

　

---

目次

1. Data Fabricは「人とロボットが非同期で動く」ための土台
2. Choice Setがあると「人とロボットの会話」がズレない
3. 「全部Data Fabricに入れる」はやらなくていい
4. 気になるコストと容量の話
5. まとめ：Data Fabricは「考えなくていいことを減らす仕組み」

---

1. Data Fabricは「人とロボットが非同期で動く」ための土台

最近の UiPath では、
Maestro や Agentic Automation といった言葉をよく聞くようになりました。

ざっくり言うと、

・ロボットが全部自動でやる
・人が全部判断する

のどちらかではなく、

人とロボット（とAIエージェント）が、同じプロセスの中で、それぞれのタイミングで動く

という世界観です。

ここで重要になるのが、「いま、このデータはどんな状態なのか？」を共有できる場所です。

第2回で紹介した
パターン4：ロボットが途中結果を書き込み、人が確認する
は、まさにこの前提で成り立っています。

Data Fabric は、

・ロボットが途中経過を書き込めて
・人がそれを見て判断できて
・その結果をまたロボットが拾える

という 状態管理の中心 になります。

だからこそ、Maestro や Agentic Automation の文脈でData Fabric の重要性が増している、と考えると分かりやすいと思います。

　

2. Choice Setがあると「人とロボットの会話」がズレない

ここで紹介したいのが、
Choice Set（チョイスセット） という機能です。

これは一言で言うと、

「この列に入れていい値を、あらかじめ決めておける仕組み」です。

たとえば、ステータス。Excelで管理していると、

・未処理
・未対応
・処理前
・未処理中

といった表記ブレが、いつの間にか増えていきがちです。

人にとっては同じ意味でも、ロボットにとっては 全部別の値 になります。

Choice Set を使うと、

・未処理
・要確認
・承認済
・完了
・エラー

といった 選択肢を事前に定義 できます。

そしてそのフィールドには、その選択肢の中からしか値を入れられません。

ブラウザから入力しても、Apps から編集しても、Studio から更新しても同じです。

結果として、

・表記ブレが起きない
・条件分岐がシンプルになる
・想定外の値でロボットが止まらない

という状態が作れます。

「人とロボットが、同じ言葉で会話できる」これが Choice Set の一番の価値です。

Maestro のようにプロセス全体をまたいで状態を扱う場合、
この「ズレない前提」はかなり効いてきます。

　

3. 「全部Data Fabricに入れる」はやらない

ここまで読んで、

「じゃあ、いろんなデータを
　全部 Data Fabric に入れた方がいいのでは？」

と思っている方もいるかもしれません。でも、そこまでやる必要はありません。

第2回で触れた通り、

・処理や判断に使うデータ
・状態管理や業務で参照する簡易マスタ

は Data Fabric に置き、

・PDFや画像などの原本ファイル
・すでに基幹で管理されているデータ

は、外部の置き場所をそのまま使うという設計が基本です。

Data Fabric は「何でも入れるデータベース」ではなく、業務プロセスの状態を管理するデータ層であったり、人とロボットが同じ業務状態を共有するための基盤。

この位置づけを意識すると、使いすぎて困ることはほとんどありません。

　

4. 気になるコストと容量の話

Data Fabric を使うにあたって、
「追加でライセンス費用がかかるのでは？」
「容量はどのくらい使えるの？」
といった点が気になる方も多いと思います。

まず、公式ドキュメントには次のような記載があります。

Enterprise プランの場合、
Automation Cloud アカウントでは 保有しているライセンスごとに 1 つの Data Fabric ユニット（DFU）が付与されると書いてあります。

また、1 DFU あたりの目安は以下の通りとも書いてありますね。

・データストレージ：1 GB
・添付ファイルストレージ：5 GB
・1 日あたりの最大 API 呼び出し数：10,000 回

この仕組みのポイントは、
Data Fabric の容量が Automation Cloud で持っているライセンス数に応じて増える、という点です。

そのため、開発者やロボットを多く使っている企業ほど、
自然と Data Fabric に割り当てられる容量も大きくなります。
テキスト中心の業務データであれば、容量面で問題になるケースはあまり多くありません。

具体例①：指定ライセンス を 合計20 個持っている場合

例えば、
Automation Developer ライセンスを 10 個
Attended ライセンスを 10 個
持っている企業であれば、
Data Fabric のデータストレージは 最大 20 GB 利用できます。

申請データや管理用の台帳データなど、
テキスト中心の業務データであれば、この容量は十分現実的といえます。

具体例②：Automation Developer を 1 個だけ持っている場合

逆に、Automation Developer を 1 個だけ持っている場合でも、
Data Fabric のデータストレージは 最大 1 GB 使えます。

1 GB と聞くと少なく感じるかもしれませんが、
例えばロボット処理の管理データとして、

・処理 ID
・ステータス
・エラーメッセージ（短文）
・タイムスタンプ

といった情報を保存する程度であれば、
数百万〜数千万件規模でも 1 GB に収まるケースが多いイメージです。

そのため、この規模感の使い方であれば、
容量がすぐに問題になる可能性は高くありません。

　

以上のことから、Data Fabric を使う際には、
「どんなデータを入れるか」という設計の工夫は必要になりますが、
Automation Cloud を利用している企業であれば、
Data Fabric の利用そのものに対して追加費用を強く意識するケースは少なそうです。

まずは標準で使える範囲を前提に設計し、
実際の運用状況を見ながら調整していく、
という考え方で、使用を検討してみてもいいのではないでしょうか？

　

まとめ：Data Fabricは「考えなくていいことを減らす仕組み」

ここまで見てきたとおり、Data Fabric は

・Excelのロックや表記ブレ
・Queueだけでは扱いにくい状態管理
・人とロボットが混ざるプロセス

そういった悩みを、無理なく整理してくれます。

最初からMaestro や Agentic Automation をフルで意識する必要はありません。

まずは、

・処理台帳
・マスタ管理（業務で参照する簡易なもの）
・人が確認する中間データ

といった身近なところから少しずつ使ってみる。

その延長線上に、人とロボットが自然に協調するプロセスが見えてくるはずです。