- 基本情報
- Studio Web での UiPath Agents
- Agent Builder での UiPath Agents
- UiPath のコード化されたエージェント

Agents ガイド
インテリジェントなオートメーション システムを設計する際には、エージェントとワークフローを区別することが重要です。エージェントとワークフローは、異なるものでありながら補完し合うことが多い 2 つのパラダイムです。このセクションでは、それぞれの特徴と違い、およびユース ケースに適したモデルの選択方法について説明します。
このセクションを読むと、以下についての理解が深まります。
- エージェントとは何か、ワークフローとは何か
- 意思決定の基準、およびいずれかを検討する場合のユース ケースの例
エージェントは大規模言語モデル (LLM) が主体となったソフトウェア システムであり、目標に向かって推論、行動し、動的に適応することができます。従来のオートメーションのロジックとは異なり、エージェントは厳密な一連の指示には従いません。その代わりに、リアルタイムに判断を下し、ツールを選択し、結果を解釈し、現在のコンテキストとメモリに基づいてアクションを調整します。エージェントは、結果に至るまでのパスをハードコードできない場合や、ハードコードされたロジックが非常に複雑な場合に威力を発揮します。エージェントは、構造化されていないことが多い動的な入力に基づいて推論し、意思決定を行って行動します。
エージェントには、以下のようにさまざまな動作モードがあります。
- 自律型: 通常はより広範なワークフローの一部として、時間またはプログラムによるイベントによってトリガーされます。
- 会話型: 自然言語のメッセージ ダイアログを使用してユーザーの入力を解釈し、コンテキストに応じて応答し、タスクを完了したり情報を提供したりします。
- アンビエント型: コンテキストを継続的に検知する環境やデバイスに埋め込まれ、明示的にユーザー プロンプトを入力しなくても、先を見越して有用なアクションや通知を実行します。
エージェントが特に役に立つタスクは、入力が構造化されておらず、解決に至る最適なパスが事前にわかっていない、あいまいで変更の可能性があるタスクです。また、エージェントは過去の対話から学習するように設計されているため、適応性と推論が重要な環境に適しています。
主な特徴
- 自律性: 次に呼び出すツールや API を選択します。
- ステートフル メモリ: コンテキスト、前のステップ、フィードバックを記憶します。
- 動的な制御フロー: 分岐やループ処理を実行したり、その場で明確化のための質問をしたりします。
- 人間参加型のフック: 信頼度が低い場合やルールに違反した場合にエスカレーションします。
代表的な適合用途
- あいまいなタスク (サポート チケットの診断、市場の調査など)
- 変化の幅が非常に大きい入力/パス
- 各実行から学習することで価値が付加される状況
ワークフローとは、決まった順序で実行されるステップから成る構造化されたシーケンスです。多くの場合、LLM、API、または人間の入力が統合されますが、エージェントのように自律的に計画する機能はありません。ワークフローの各ステップは事前に定義されており、ステップ間の遷移は決定論的なロジックに従います。
ワークフローは、明確なビジネス ルールと予測可能な結果がある、大量で繰り返し可能なプロセスにおいて優れています。ワークフローには透明性とガバナンスが備わっており、コスト、時間、コンプライアンスに関するベンチマークが容易です。
主な特徴
- 決定論的なパス: 入力が同じであれば、どの実行も同じ分岐をたどります。
- 実行間でステートレス: 各実行は新規に開始されます (データを明示的に永続化した場合を除く)。
- コストとタイミングの透明性: ベンチマークや予算の編成が容易です。
- ガバナンスに対応: コンプライアンスと監査のニーズに合致します。
代表的な適合用途
- 大量の定型的なタスク (例: 請求書の抽出 → 検証 → ERP への入力)
- 厳格なサービス レベル アグリーメントまたは規制上の制約
- 同一の入力に対して出力が同一でなければならないシナリオ
エージェンティック ワークフローは、エージェントの適応性とワークフローの構造を融合したものです。エージェンティック ワークフローでは、エージェントは定義されたステップ内やステップ間にまたがって推論、行動、学習することができ、従来のワークフローでは実現できない動的な意思決定が可能になります。このハイブリッド アプローチは、オーケストレーションとガバナンスを維持しながら、あいまいさと可変性に対応します。Maestro の Agentic Orchestration は、この 2 つを融合した機能です。つまり、エージェントは動的な意思決定を処理してから、予測可能なワークフローにそれを引き渡して実行します。
以下の考慮事項を判断の指針にします。
- 入力の種類: 入力が構造化されていない、マルチモーダルである、またはコンテキストの理解を必要とする場合は、エージェントを選択します。入力が構造化されていて明確に定義されている場合は、ワークフローを使用します。
- 制御フロー: エージェントは、中間結果に基づいて動的にアクションを計画します。ワークフローは、設計時に決定された静的なパスをたどります。
- 適応性: エージェントはその場で適応し、学習するか、必要に応じて再プロンプトを行います。ワークフローは、変更があった場合、手動で再設計する必要があります。
- ガバナンスと予測可能性: ワークフローは、強力なコンプライアンス、コスト管理、一貫性を提供します。エージェントは実験と柔軟性を提供し、コストと結果の変動が大きくなります。
- 実行時の推論: 部分的なコンテキストや進化するコンテキストに基づいて実行時に意思決定や分岐処理を行う必要がある場合は、エージェントが最適です。
基準 | オペレーター | ワークフロー |
---|---|---|
反復的なルールベースのタスク |
|
|
非常にあいまいなタスク |
|
|
決定論的な結果 |
|
|
動的な推論と適応 |
|
|
Dimension | オペレーター | ワークフロー |
---|---|---|
制御フロー | 動的な計画とツールの選択/生成 | 定義済みのツールを使用した定義済みのシーケンス |
入力の種類 | 非構造化、マルチモーダル | 構造化されたレコード/フォーム |
適応性 | その場で学習するか、再プロンプトを実行 | 設計時の変更が必要 |
信頼性 | 可変 (ガードレールと評価に依存) | 入力が仕様範囲内の場合は高 |
ガバナンスの負担 | より高い (エージェントの無秩序状態のリスク) | 成熟したポリシー/ツールが存在 |
コストの予測可能性 | 中から低 (LLM/トークンによって変動) | 高 (High) |
標準的な ROI 期間 | 迅速な実験、不確実なスケーリング | 一度スクリプトを作成すれば安定して節減 |
スキルの壁 | ローコードおよびコードの場合と同様 |
ユースケース | オペレーター | ワークフロー |
---|---|---|
サポート チケットのトリアージ | ||
営業メールの生成 | ||
請求書の処理 | ||
従業員のオンボーディング |
マルチエージェント システムは複数の自律型エージェントで構成され、これらのエージェントが実行時に対話して連携し、共有されている目標や交渉によって決定された目的を達成します。定義済みのパスをたどる標準的なワークフローや、単独で動作する単一のエージェントとは異なり、マルチエージェント設定では、緊急の動作、タスクの柔軟な分散、動的なコラボレーションがサポートされます。
マルチエージェント システムは、共同作業可能な RAG パイプラインやサプライ チェーンへの動的な対応など、変更の可能性があり複雑度の高い目標に最適です。
次の表では、クラシック ワークフローのオーケストレーションと真のマルチエージェント システムをさまざまな重要な側面について比較しています。
Dimension | クラシック ワークフロー (エージェントを呼び出し可能) | 真のマルチエージェント システム |
---|---|---|
制御ロジック | 事前に設計: 「ステップ A →ステップ B →ステップ C」のようになります。分岐は作成者が修正します。 | 実行時に発生: エージェントが独自のステップを計画し、作業をピアに動的に再割り当てすることができます。 |
計画を行うエンティティ | ワークフロー エンジンが順序を決定します。個々のエージェント (存在する場合) は単にそのスライスを実行します。 | 各エージェントがローカルに計画します。調整レイヤー (またはピア プロトコル) が競合をその場で解決します。 |
適応性 | 人間がモデル化したデシジョン ツリーに限定されます。 | 新しいサブプランの作成、役割の分割/結合、目標の再交渉を行うことができます。マルチエージェント スワームは、タスクを再割り当てしたり、障害処理用のヘルパー エージェントを生成したりできます。 |
ステートとメモリ | 通常は実行間でステートレスです (永続化した場合を除く)。 | 各エージェントが独自のメモリを保持できます。共有メモリまたはブラックボードによって、他のエージェントのためにコンテキストを読み書きできます。 |
ガバナンスとオブザーバビリティ | 単純: 1 つのオーケストレーターと、決定論的なトレースです。 | より困難: 多数の自立型のループに、グローバルな追跡、ポリシーの適用、安全柵が必要です。 |
代表的な適合用途 | はっきりとした引き渡しを伴う反復的なプロセス (例: 「請求書を抽出 → 検証 → ERP に送信」)。 | 役割分担によるメリットがある、変更の可能性がある複雑な目標 (例: RAG の研究者 ↔ プランナー ↔ コーダーが協力してマイクロ機能を出荷)。 |