uipath-maestro-flow

UiPath Flow — TypeScript ビルダー SDK

UiPath Flow のオーケストレーションは、@uipath/maestro-builder-sdk パッケージを使って TypeScript で作成できます。 この SDK には、Flow グラフを構築するビルダー API が用意されており、開発者は型安全な方法で入力、出力、ステップ、制御フローを定義できます。 グラフは、UiPath プラットフォームで Flow を実行するために使用する成果物である Flow JSON に「コンパイル」されます。 既存の Flow JSON を TypeScript に逆コンパイルして編集することもできます。

プロジェクトの構成

@uipath/maestro-builder-sdk はグローバルにインストールされます（npm install -g）。examples/ には作成済みの例が、references/ にはこのガイドから案内される詳細情報が含まれています。 Flow は、プロジェクトフォルダー <Solution>/<Name>/ 内の .flow-sdk/<Name>.flow.ts として作成し、パッケージを直接インポートします。

作成するファイルは .flow-sdk/ に置きます。コンパイル済みの成果物はここには置きません。 .flow-sdk/ は SDK 専用の作業ディレクトリです。ソース、bindings.json、connectors/、connectors-local/ はすべて、既定で uip を実行するディレクトリを基準として配置されます。Flow プロジェクトごとに個別のディレクトリがあるため、1 つのソリューションに複数の Flow を含められます。Studio Web はこのディレクトリを読み取りません。また、uip solution pack／upload と flow debug では除外されます。 SDK の動詞（flow check、compile、decompile、merge、registry pull／prepare、node .flow-sdk/*.pipeline.mjs）は、プロジェクトフォルダー <Solution>/<Name>/ から実行してください。 シェルでコマンド間のディレクトリが維持されない場合は、( cd <Solution>/<Name> && … ) のように実行してください。このガイドと参照資料にある .flow-sdk/ のパスはすべて、このフォルダーを基準としています。それ以外の操作は、ワークスペースのルートから実行します。 まずプロジェクトをスキャフォールドし、そこからソースの初期データを作成してから、成果物をプロジェクトに出力してください。出力先は compile -o が決定します。 <Solution> と <Name> には、リクエストで指定された名前をそのまま使用します。「同じ名前のソリューション内に」のように両方に同じ名前を指定している場合は、どちらにもその名前を使用します。Flow の名前だけが指定されている場合は、<Name> を両方に使用します。 uip solution init を実行する前に、既存のソリューションを確認してください。 find . -maxdepth 2 -name '*.uipx' を実行します。既存のソリューションが見つかり、ユーザーが回答できる場合は、どれを使うか尋ねてください（ソリューションごとに 1 つの選択肢、続いて「新しいソリューションを作成する」、最後に「その他」）。回答を得るまでは何もスキャフォールドしないでください。黙って 2 つ目のソリューションを作成してはいけません。ヘッドレスの場合は、リクエストで指定されたソリューションを使用し、それがなければ既存のソリューションが 1 つだけならそれを使用します。どちらにも当てはまらない場合は、上記のルールに従った名前で新しいソリューションを作成し、最終回答に選択内容を記載してください。

uip solution init <Solution>
( cd <Solution> && uip maestro flow init <Name> --sdk-source )
# edit <Solution>/<Name>/.flow-sdk/<Name>.flow.ts, then run the Lifecycle loop below

スケルトンを手書きしてはいけません。 --sdk-source は、flow init が書き込むトリガーのみの成果物を逆コンパイルし、プロジェクトの .flow-sdk/<Name>.flow.ts に配置してフォルダーを作成します。ソースには、製品によってすでに割り当てられたフロー ID と名前が含まれます。手書きの flow('<name>') では別の ID が生成されます。 そのため、このスタブは不要なファイルではなく、初期データとして使います。最初の compile -o で、同じ場所に上書きされます。 init は、--force を指定しない限り、既存のソースファイルがあると処理を拒否します。ソースがすでに存在する場合は、--sdk-source を省略してください。 Maestro Automate は、同じ flow init に --automate を指定します。 リクエストで製品として Maestro Automate が指定されている場合は、( cd <Solution> && uip maestro flow init <Name> --automate --sdk-source ) を実行してください。動詞としての「automate」（例：「invoice intake を自動化する」）は、通常の Flow を意味します。 init の後に行う処理は変わりません。このフラグは operate.json に runtimeOptions.profile を書き込み、.maestro_automate マーカーを作成します（Orchestrator と Studio Web はこれで両者を区別します）。compile -o は .flow だけを書き換えるため、どちらもそのまま残ります。 既存のプロジェクトでは init は不要です。最初の 2 つのコマンドを省略し、すでに存在する .flow から ( cd <Solution>/<Name> && uip maestro flow decompile <Name>.flow -o .flow-sdk/<Name>.flow.ts --no-pipeline ) でシードします（--no-pipeline はブラウンフィールド用ヘルパーをスキップします。references/brownfield.md）。ソースがすでに存在する場合は、デコンパイルを省略してください。 3 つの名前は一致させてください：.flow-sdk/<Name>.flow.ts、<Name> プロジェクトディレクトリ、その中の <Name>.flow。 出力される <Name>.flow は 1 つだけとし、<Solution>/<Name>/<Name>.flow に配置してください。ワークスペースのルートに 2 つ目のコピーを置かないでください。バリデーターやエビデンス収集ツールは、重複したファイルのどちらを使うか安全に選択できません。 ルートへの出力が正しいのは、プロジェクトをスキャフォールディングしない、パッケージ化された SDK のローカルゲートに限られます。最初にループを選択し（ライフサイクル）、両方を混在させないでください。

最初に SDK をインストールしてください。インストールはマシンごとに 1 回です： npm install -g @uipath/maestro-builder-sdk。すでにインストールされている場合は省略し、チェックと失敗時の対応については references/CLI-LOOP.md を参照してください。

UiPath 以外のシステムとの統合にはコネクタを使用します。記述する前にノードを選択してください。 外部サービスやデータ（天気、Slack、REST API）の場合、リクエストで転送方式自体が指定されていない限り（「コネクタではなく HTTP 経由」は http() を意味します）、ローカルコネクタライブラリに対して uip maestro registry search '<brand or service name>' を実行します。ヒットした場合はコネクタです。"total": 0 は見つからなかったことを示し、http() を使います。使用法エラーはライブラリがキャッシュされていないことを意味するため、先に uip maestro registry pull を実行してください。このライブラリに含まれないドキュメント抽出などのテナント機能（エージェント、プロセス）については、その機能の uip maestro flow registry search を実行します（references/ixp.md、references/agent.md）。固定値を返す script() はこの手順の代替にはなりません。また、mock() は検索で存在しないことが確認された機能にのみ使用します。 コネクタには .flow-sdk/bindings.json が必要です。 uip maestro registry pull は、参照されているコネクタごとにディスクリプターを .flow-sdk/connectors/<key>.ts に書き込み、ライブラリ自体はプロジェクトの外部にキャッシュします。 準備済みのコネクタモジュールは .flow-sdk/connectors-local/<key>.ts に配置され、ディスクリプターデータは別途 .flow-sdk/connectors-local/descriptors/<key>/ 以下に保存されます。 ソースも .flow-sdk/ にあるため、これらは ./connectors/<key>.ts および ./connectors-local/<key>.ts としてインポートします。

コネクターループ：作成 → チェック → 準備 → チェック → コンパイル

作成時に prepare を待つ必要はありません。上記の検索でノードを選んだら、ソースを書く前に追加の検索コマンドを実行する必要はありません。 タスクの文言に沿ってコネクターステップを記述します。使用するフィールド、ID 用の lookup() トークン、汎用操作には { object: '<name-as-the-task-said-it>' } を指定し、その後 uip maestro flow check .flow-sdk/<Name>.flow.ts --source を実行します。 必要なすべての準備について、正確なコマンドを使って名前をチェックします。マテリアライズされていないオブジェクトには OBJECT_UNPREPARED、テナントに依存しないスナップショットに含まれない入力には CUSTOM_FIELDS_UNPREPARED、値が記録されていないルックアップトークンには LOOKUP_UNRESOLVED、操作で宣言されていないフィールドには CONNECTOR_INPUT が表示されます。uip maestro registry prepare <connector-key> <action> を一度実行します。--object、--resolve、-f は1回の呼び出しで組み合わせられます。このコマンドは接続を自動で見つけて .flow-sdk/bindings.json に書き込み、インポート先を生成された ./connectors-local/<key>.ts 記述子に変更します。その後、check を再実行してコンパイルします。 2つのフローが同じコネクターをインポートしている場合は、推測せずにフロー名を表示し、--source の指定を求めます。 CONNECTOR_NOT_IN_LIBRARY、CONNECTOR_OBJECT_REQUIRED、CONNECTOR_OBJECT_NOT_GENERIC はソースの修正が必要なエラーであり、準備ではありません：connector-params.md。

loadByDefault、依存するドロップダウン、customFieldsRequestDetails など、スキーマに応じて動的に変化する操作では、準備前の check で必要な -f をすべて指定し、コンパイル後にキャッシュをチェックする必要があります。references/connector-params.md

Hello world Flow

import { flow, script, input, out, types } from '@uipath/maestro-builder-sdk';
export default flow('hello').name('Hello')
  .input({ name: types.string }).output({ greeting: types.string })
  .step('greet', script({ code: 'return `Hello ${$vars.start.output.name}`;' }))
  .return({ greeting: out('greet') }).build();

スクリプトは第一級の Flow ノードであり、インラインの JavaScript を実行して値を返します。 start ステップは「手動トリガー」のデフォルト名であり、フローの入力を受け取ります。 Flow には出力を設定できます。フローが正常に完了すると、その出力が呼び出し元に返されます。

ライフサイクル

ビルドコマンドを実行する前に、いずれかのループを選択してください。同じワークスペースで両方を混在させたり、一方をもう一方の調査に使ったりしないでください。ディレクトリ構成とエビデンスの要件が異なります。

• 製品 CLI ループ（出力のみ）：タスクで製品の検証／デバッグ用エビデンスが求められる場合、またはワークスペースが出力のみの場合に使用します。出力のみのワークスペースとは、{ "flowSdk": { "emitOnly": true } } を含む package.json（製品ランタイムの評価で設定されます）があるか、FLOW_SDK_EMIT_ONLY=1 が設定されている状態です。まずスキャフォールドを作成し（プロジェクト構成）、その後、以下のブロックを実行します。
• パッケージ化された SDK のローカルゲート：それ以外の場合に使用します。ソースの check、ルートへの compile、validate を実行します。references/CLI-LOOP.md

uip maestro flow コマンドは、その動作をインストール済みの @uipath/maestro-builder-sdk に委譲します。出力のみの設定はプロジェクトに属し、実行元のディレクトリには属しません。ツリーを上にたどって最初に見つかる flowSdk.emitOnly を宣言した package.json が設定を決定します。ネストされた package.json に flowSdk の記載がなければ親の設定を継承し、emitOnly: false を指定すると適用対象外になります。このモードでは compile はソースのシリアライズのみを行い、どちらの flow check モードも実行を拒否し、製品の validate が構造検証を担当します。基本パスは、出力、必要なアーティファクトのバインド、その後の検証です。

( cd <Solution>/<Name> && uip maestro flow compile .flow-sdk/<Name>.flow.ts -o <Name>.flow )
uip maestro flow validate <Solution>/<Name>/<Name>.flow --output json
# Before anything opens the emitted file (upload, debug, a designer):
uip maestro flow format <Solution>/<Name>/<Name>.flow --output json
# Only for a stated runtime-behavior claim:
( cd <Solution> && uip solution resources refresh --solution-folder . --output json )
( cd <Solution> && uip maestro flow debug <Name> --log-level error \
  --output-filter "{status:finalStatus,instance:instanceId,url:studioWebUrl,failed:elementExecutions[?status!='Completed'].{id:elementId,status:status},<Out>:variables.globals.<Out>,incidents:incidents}" \
  --output json )

<Out>：宣言された各 out 変数を指定します。variables.globals のすべてを指定してはいけません。ソースまたはバインドを最後に編集した後、compile から再実行してください。有効な結果は、トップレベルの Result が Valid であり、かつ Data.Status が "Valid" であることです。レビュー済みの共有接続に関する注意事項を除き、Data.Warnings は失敗として扱ってください。期待されるグローバル変数が揃い、failed が空の Completed は実行時のエビデンスです。終了コードだけではエビデンスになりません。デバッグ入力、添付ファイル、その他の出力、インシデントについては、references/CLI-LOOP.md を参照してください。

既存のフローの編集

既存の要素がある環境で作業する場合は、提供されたソース、ステップ名、影響を受けない配線を維持してください。ステップを挿入するには、2つ目の経路を作るのではなく、既存のエッジを新しいステップ経由にします。出力された .flow JSON しかない場合は、逆コンパイルし、変更前のベースラインをコンパイルしてから、必要な範囲だけを編集し、その差分を元のファイルにマージしてください。 これらは編集前後を比較する判断であり、最終成果物のチェッカーでは証明できません。

小規模な編集では、decompile によって .flow-sdk/<Name>.pipeline.mjs が書き出されます。このファイルは2回の実行でループを処理し、ベースラインの順序を正しく取得します。また、ベースライン、編集済み、マージ済みの .flow ファイルも .flow-sdk/ 内に保持します。

uip maestro flow decompile <Name>.flow -o .flow-sdk/<Name>.flow.ts
node .flow-sdk/<Name>.pipeline.mjs      # captures the pristine baseline
# edit .flow-sdk/<Name>.flow.ts narrowly
node .flow-sdk/<Name>.pipeline.mjs      # compiles the edit and merges it back
uip maestro flow validate .flow-sdk/<Name>.merged.flow --output json

中間の編集済みコンパイルではなく、マージ済みの成果物を検証してください。 ソースを Flow プロジェクト内に置いておく必要がある場合（たとえば、相対パスのサイドカーファイルを維持するため）は、ベースライン、編集済み、候補の .flow ファイルを外部の .flow-work/ ディレクトリに置いてください。候補を検証して正規の成果物と置き換え、プロジェクト内の .flow は1つだけにしてください。以下のリファレンスには、安全なプロジェクトで実行できる一連の手順が記載されています。

既存の要素がある環境での手順： references/brownfield.md。

ビルダーフレーム

上記のクイックスタートでは、flow(id)、宣言、ノード、.return(...)、.build() の形を示しました。次の3点は示していません。

• .var(name, types.*, default?) はフロー変数を宣言します。これは、複数のステップで書き込みまたは読み取りが行われる値です。.input と .output は呼び出し元との間のフローの契約であり、var はその間にある状態です。ステップは { updates: { name: <expr> } } で値を書き込みます。入力、出力、var には、Flow CLI と Workbench が提供する6種類の型のいずれかを使用します。types.string、types.number、types.boolean、types.object、types.array、types.file です。その他の types メンバー（integer、float、double、date、datetime、jsonSchema）は Case ビルダーと BPMN ビルダーに由来します。Flow ビルダーと validate ではエラーになりませんが、Workbench には用意されていないため、日付には types.string、整数には types.number を使用してください。

• .return(...) は PATH を終了し、.terminate(...) は RUN を終了します。 直線的なチェーンでは同じように見えますが、実際は異なります。.parallel のアーム内で terminate を使うと、実行中の兄弟アームを中断しますが、return では兄弟アームの実行が続きます。

• リテラル以外の対象をステップで指定するには、式を使います。 参照できる対象の種類ごとに、式が1つあります。

  	参照する対象
  input(name)	フロー入力
  v(name)	フロー変数
  out(step, path?)	ステップの結果全体、またはそのフィールドの1つ
  err(step, field?)	FAILED 状態のステップのエラーエンベロープ。ハンドラー内でのみ使用
  ran(step)	ステップが実行されたかどうかを示すブール値
  lit(value)	生の値では曖昧になる場合に使う定数
  js`…` / tmpl`…`	自分で記述する式、または文字列

  ran(step) は早めに紹介する価値があります。アームが合流する場合、同じ処理をアームごとに重複させるよりも、共通の後続処理を1つにまとめたほうが読みやすいことがほとんどです。その後続処理で必要な値が生成されたかどうかを確認するために、ran を使います。

API インデックス

すべてのシグネチャ、オプションの形状、フィールドは、このガイドではなく、インストール済みの @uipath/maestro-builder-sdk パッケージ内でインデックス化されています。各行のパスはパッケージのルートからの相対パスです。

対象	参照先	行に記載されている内容
フィールドまたはメソッド — outcomePorts、stepToList（通常はこちら）	dist/api-members.md	それが宣言されている形状と、宣言している行
エクスポートされたシンボル — HitlInputs、hitl、FlowBuilder	dist/api-index.md	種類、領域、宣言している行

名前を1つ検索し、どちらのファイルも最初から最後まで読まないでください。 次に、該当する範囲（例：dist/core/actions.d.ts:583-597）を読みます。ドキュメントコメントを含む宣言全体があるため、1回の確認で疑問を解決できます。.d.ts を読み、dist/*.js は読まないでください（型もコメントもありません）。どちらのインデックスにもない名前は、おそらく RUNTIME 出力キーで、ノードのリファレンスに記載されています。インデックスがパッケージに含まれている理由と、その他の検索ルールについては、references/author.md を参照してください。

サポートされているノードの種類

この表が正式なルーターです。ノードを作成する前に、その Reference を読んでください。シグネチャ、作業例、ノード固有の注意点はここではなく、そこに記載されています。Example はコピー元となる完全なフローを1つ示しています。examples/ 以下のパスは、このスキルフォルダー内を基準とします。

ノードまたはサーフェス	出力されるノードタイプ	ビルダー	リファレンス	例
手動トリガー	core.trigger.manual	.trigger(...) を省略	manual-trigger.md	examples/GreenhouseWatering.flow.ts
エントリーポイント（複数のトリガー）	追加の各ルートにトリガーノードを1つずつ配置	.entryPoint(id, trigger, { inputs?, version? }, prefixFn?)；すべてのルートで変数を共有する場合：入力 { type, shared: '<var>' }	manual-trigger.md	—
スケジュール済みトリガー	core.trigger.scheduled	scheduled(...)	scheduled-trigger.md	examples/HerbariumDispatch.flow.ts
コネクターイベントトリガー	uipath.connector.trigger.<key>.<event>	onEvent(...)	event-trigger.md	examples/DoorbellLog.flow.ts
コネクターイベント待機	uipath.connector.event.<key>.<event>	waitForEvent(...)	event-trigger.md	examples/PlanetariumConfirmation.flow.ts
フォームトリガー	core.trigger.form	formTrigger(...)	form-trigger.md	examples/BakeOffEntryForm.flow.ts
会話トリガー	core.trigger.conversation	conversationTrigger(...)	conversational.md	examples/LibraryDeskChat.flow.ts
音声トリガー	core.trigger.voice	voiceTrigger(...)	voice.md	examples/HarbourRadioLine.flow.ts
スタンドアロン HTTP	core.action.http	http({ managed: false, ... })	http.md	examples/LighthouseSignal.flow.ts
管理対象 HTTP	core.action.http.v2	http({ managed: true, ... })	http.md	examples/ObservatorySeeing.flow.ts
スクリプト	core.action.script	script(...)	script.md	examples/GreenhouseWatering.flow.ts
変換	core.action.transform	transform(...)	transform.md	examples/TrailLogSummary.flow.ts
フィルター	core.action.transform.filter	transform({ variant: 'filter', ... })	transform.md	examples/TrailLogSummary.flow.ts
マップ	core.action.transform.map	transform({ variant: 'map', ... })	transform.md	examples/TrailLogSummary.flow.ts
グループ化	core.action.transform.group-by	transform({ variant: 'group-by', ... })	transform.md	examples/TrailLogSummary.flow.ts
Integration Service アクション	uipath.connector.<key>.<action>（Data Fabric / Data Service — ネイティブファミリーにない操作：ファイルレコードのフィールド、イベント：uipath.connector.uipath-uipath-dataservice.*）	connector(...)	connector-params.md	examples/ClubDirectory.flow.ts
Data Fabric 読み取り	core.datafabric.read（resultMode: 'multiple' はその 1.4 定義を選択し、limit は 1000 件を上限とします）	dataFabricRead(...)	data-fabric.md	examples/BeeHiveLedger.flow.ts
Data Fabric 作成	core.datafabric.create	dataFabricCreate(...)	data-fabric.md	examples/BeeHiveLedger.flow.ts
Data Fabric 更新	core.datafabric.update	dataFabricUpdate(...)	data-fabric.md	examples/BeeHiveLedger.flow.ts
Data Fabric 削除	core.datafabric.delete（出力はありません）	dataFabricDelete(...)	data-fabric.md	examples/BeeHiveLedger.flow.ts
サブフロー	core.subflow	subflow(...)	subflow.md	examples/RecipeScaler.flow.ts
人間によるタスク	uipath.human-in-the-loop	hitl(...)	hitl.md	examples/GallerySubmission.flow.ts
人間によるクイックフォーム	uipath.human-in-the-loop.quick-form（結果ごとに終了先が1つあります。.stepSwitch はそれらにルーティングし、通常の .step() はすべての結果から続行します）	hitl({ variant: 'quick-form', ... })	hitl.md	examples/FieldTripQuickForm.flow.ts
人間によるアクションアプリ	uipath.human-in-the-loop.coded-action-app	hitl({ variant: 'action-app', ... })	hitl.md	examples/KilnReview.flow.ts
RPA ワークフロー	uipath.core.rpa-workflow.<key>	rpaWorkflow(...)	rpa-workflow.md	examples/WorkshopInventory.flow.ts
キューアイテム	core.action.queue.create*	queueItem(...)	queue.md	examples/HerbariumDispatch.flow.ts
要約	uipath.pattern.deep-rag	summarize(...)	summarize.md	examples/OralHistoryDigest.flow.ts
バッチ変換	uipath.pattern.batch-transform	batchTransform(...)	batch-transform.md	examples/FossilCatalogEnrich.flow.ts
分岐	core.logic.decision	.branch(...)	branch.md	examples/GreenhouseWatering.flow.ts
スイッチ	core.logic.switch	.switch(...)	switch.md	examples/BeltProgression.flow.ts
並列処理／マージ	core.logic.merge	.parallel(...)	parallel-merge.md	examples/ConcertSoundcheck.flow.ts
ループ	core.logic.loop	.loop(...)	loops.md	examples/ClubDirectory.flow.ts
Do while	core.logic.dowhile	.doWhile(...)	loops.md	examples/MeteorShowerPages.flow.ts
戻り値／終了	core.control.end	.return(...)	return.md	examples/GreenhouseWatering.flow.ts
終了	core.logic.terminate	.terminate(...)	terminate.md	examples/AquariumSafetyStop.flow.ts
プレースホルダー	core.logic.mock	mock()	placeholder.md	examples/FestivalMapScaffold.flow.ts
不明なノードタイプ	レジストリの nodeType をそのまま使用（uipath.connector.* は使用しません）	rawNode(...)	placeholder.md	—
エラーハンドラー	アクションノードの error ハンドル	.onError(...)	error-handling.md	examples/ObservatorySeeing.flow.ts
遅延	core.logic.delay	delay(...)	delay.md	examples/LighthouseSignal.flow.ts
API ワークフロー	uipath.core.api-workflow.<key>	apiWorkflow(...)	api-workflow.md	examples/BirdCountLookup.flow.ts
エージェント型プロセス	uipath.core.agentic-process.<key>	agenticProcess(...)	agentic-process.md	examples/NeighborhoodWalkPlanner.flow.ts
エージェントリソース	uipath.core.agent.<key>	agent(...)	agent.md	examples/PlantNameAdvisor.flow.ts
インラインエージェント	uipath.agent.autonomous	inlineAgent(...)	inline-agent.md	examples/PostcardCaption.flow.ts
IxP 抽出	uipath.ixp.<project>.<version>-<folder>	ixpExtract(...)	ixp.md	examples/ArchiveCardExtract.flow.ts
ドキュメント分類	uipath.document.classify	documentClassify(...)	document-pipeline.md	examples/SeedPacketReader.flow.ts
動的抽出	uipath.ixp.extract-document-builder	dynamicExtract(...)	document-pipeline.md	examples/SeedPacketReader.flow.ts
公開済み関数	uipath.core.function.<key>	publishedFunction(...)	published-function.md	examples/TideTableConverter.flow.ts
会話メッセージ待機	uipath.conversational.wait-for-message	waitForMessage(...)	conversational.md	examples/LibraryDeskChat.flow.ts
会話型エージェント	uipath.agent.conversational	conversationalAgent(...)	conversational.md	examples/LibraryDeskChat.flow.ts
会話メッセージ送信	uipath.conversational.send-message	sendMessage(...)	conversational.md	examples/LibraryDeskChat.flow.ts
音声発信	uipath.conversational.voice.create-outgoing-call	createOutgoingCall(...)	voice.md	examples/PotteryStudioCallback.flow.ts
音声エージェント	uipath.agent.voice	voiceAgent(...)	voice.md	examples/PotteryStudioCallback.flow.ts
音声通話終了	uipath.conversational.voice.end-call	endCall(...)	voice.md	examples/PotteryStudioCallback.flow.ts

フローの作成

各ノードはブランド名ではなく、レジストリ検索から選択します。依頼で有限の選択肢が未確定のまま残る場合は質問します。宣言したすべての出力を、すべての経路でバインドします（check は未設定の出力を検出しますが、実行結果は undefined になります）。依頼で対処方法が指定されている場合にのみ、エラーを処理します。各ジャーニー、ステップが指定されていない依頼に対するスコープゲート、先に計画を立てるタイミング、完了レポートについては、 references/author.md を参照してください。

デプロイ済みフローの操作

アップロード、デプロイ、デバッグ、トリガー、ジョブの確認、インスタンスのライフサイクル管理を行います。これらすべてに uip login が必要です。また、アップロード、公開、デバッグの前には必ず uip solution resources refresh を実行します。flow debug は実際の実行であり、検証ステップではありません。references/operate.md を参照してください。

失敗した実行の診断

次の順序でトリアージします。すでに取得しているデバッグレスポンス、インシデント、ランタイム変数、デプロイ済みアーティファクト、最後にトレースです。確認のために flow debug を再実行してはいけません。ビルダーによって、従来の .flow に見られる不具合のいくつかは取り除かれますが、式が実際にはリテラルである場合など、残る不具合もあります。references/diagnose.md を参照してください。

フローの評価

インラインエージェントは、評価器、評価セット、データポイント、シミュレーションを作成しません。Flow eval CLI がプロジェクトファイルとして管理します。副作用のあるコンポーネントはすべて、セットの実行前にシミュレーションしてください。また、評価ワークフローの一環として、許可なく solution upload を実行してはいけません。references/evaluate.md を参照してください。

最終エビデンス

最終確認では、パッケージングモードに適したループを使用し、最後の編集後に実行する必要があります。プロダクトリソースの正確性を示すのは、実環境から得られるエビデンスです。妥当な ID、引数名、シナリオ名が付いた任意入力、警告をテナントに照らして確認してください。機械的にチェックできる構造はすべて静的診断に委ねます。ルールをこのルーターにコピーし直すのではなく、原因を修正してください。

エビデンスを依頼の受け入れ基準に合わせてください。配線に関する疑問が1つ残っている場合、検証のみを求める基準では、プロダクト検証が成功し、必須の構造的セルフチェックに合格すれば完了です。確信を得るためだけにデバッグを追加してはいけません。基準で指定された各動作の主張については、それを確認するための、範囲を限定したプロダクトデバッグを最大1回計画してください。配線に関する疑問が1つ残っている場合は、それを判別できる範囲を限定した実験を1回実施し、その結果を反映して終了してください。スクラッチソリューションを次々と作成したり、同等のバリエーションを繰り返したりしてはいけません。