以下の記事では、実際の業務を想定したハンズオンを通じて、Agent Builder のイメージをつかんでいただけたかと思います。
本記事では、Agent Builder における開発用のコアコンポーネントとその役割・使い方について紹介します。
これらのコアコンポーネントを理解することで、エージェントをより効率的に開発できるようになります。
一般的なAI エージェント全体構成
UiPath Agent Builder を紹介する前に、まずは一般的な AI エージェントの構成を確認しておきましょう。
上記の記事で紹介したように、AIエージェントとは、人工知能（AI）を活用してユーザーの指示や意図を理解し、自律的にタスクを遂行するソフトウェア型のエージェントです。
以下の図は、AIエージェントの思考・行動モデルを示したものです。
- 感知（Perception）：環境から情報を受け取る
- 脳（Brain）：状況を理解・記憶・判断・計画
- 行動（Action）：アプリケーションやツールを操作して、実際の処理を行う
（出典：Park et al., “Generative Agents: Interactive simulacra of human behavior”）
UiPath AI エージェント全体構成
UiPath Agent Builder では、具体的に、エージェントがどのように情報を受け取り、思考し、行動に移すのかを、以下の図のような構成でとらえることができます。
以下は、UiPath Agent Builder におけるエージェントの情報処理とアクションの流れを示したものです。
エージェントは、ユーザーの指示を受け取り、思考・判断を経て、必要に応じて人間に確認しながらアクションを実行します。
UiPath Agent Builderにおける開発用のコアコンポーネント一覧
上記のUiPath AI エージェント全体構成図では示したようなコンポーネント(オレンジ色の楕円形)は、エージェントがユーザーの指示を理解し、適切に判断・行動するための土台となるものです。
以下がUiPath AI Builderの画面です：
それぞれのコンポーネントの機能を一覧で整理します。
| コンポーネント名 | 説明 |
|---|---|
| 1️⃣ LLM（大規模言語モデル） | プロンプトをもとに自然言語を理解・生成し、エージェントの「思考」部分を担う中核コンポーネント。 システムプロンプトやコンテキスト、エージェントメモリをもとに柔軟な判断や応答を行う。 |
| 2️⃣ 引数（Arguments） | エージェントが受け取る入力情報や、処理結果として返す出力値。 外部（他のプロセスやユーザー入力など）から情報を受け取ったり、出力を別のプロセスへ連携したりできる。 |
| 3️⃣-1 システムプロンプト（System Prompts） | エージェントの役割・目的・制約を自然言語で定義。どのツールや文脈・エスカレーションを使うかの指針も含められる。 |
| 3️⃣-2 ユーザープロンプト（User Prompts） |
入力引数をどのようにエージェントに渡すかの構造を定義。 システムプロンプト内で引数をどう参照するかも明示できる。 |
| 4️⃣ ツール（Tools） | エージェントがデータを取得・処理するために使用する手段。 UiPathのアクティビティやプロセスの実行により、判断やアクションを支援する。 |
| 5️⃣ コンテキスト（Context） | 文書やナレッジをインデックス化し、エージェントが必要に応じてクエリし、判断に役立つ情報を取得するための仕組み。 |
| 6️⃣ エージェントメモリ（Agent Memory） | エージェントの判断履歴や人とのやり取り を記録し、次回以降に活かすための記憶機能。 |
| 7️⃣ エスカレーション（Escalations） | Action Centerを活用して、人間の判断（Human-in-the-Loop） を組み込む仕組み。 自動化では判断が難しい場面に人の介入を可能にする。 |
ここからは各コンポーネントの役割や設計上のポイントについて、もう少し詳しく見ていきましょう。
1️⃣ LLM（大規模言語モデル）
LLM（大規模言語モデル）は、プロンプトに基づいて自然言語を理解・生成し、エージェントの「思考」を担う中核コンポーネントです。
現時点（2025年4月9日）において、UiPath Agent Builder では GPT-4o 系の3種類のモデルおよび Claude がデフォルトで利用可能となっています。
また、UiPath AI Trust Layer および UiPath Integration Service を通じて設定・拡張を行えば、Google や Amazon など他社の LLM、さらには 自社でホストしている独自LLM（例: ローカル環境のLlama 2など）も組み込めます。
この機能の詳細については、UiPath 社からの公式な技術情報はまだ公開されていないため、導入を検討されている方は、自社の UiPath 担当者を通じて、最新情報をご確認ください。
UiPath Agent Builder では、エージェントに組み込む LLM（大規模言語モデル）の動作を柔軟に調整できるよう、いくつかの設定項目が用意されています。
この設定画面では、出力の正確さと創造性のバランス（温度）、および1回の応答で返す最大トークン数を調整できます。
- 温度: LLMの「出力のランダム性」や「多様性」をコントロールするパラメータです。
| 値が低い場合（0.0〜0.3） | 値が高い場合（0.7〜1.0） |
|---|---|
| ・出力が安定し、より事実に基づいた定型的な内容になる | ・出力が柔軟で、創造的・多様な言い回しが増える |
| ・FAQ、仕様説明、技術文書向き | ・ストーリー生成、コピーライティング向き |
- 回答あたりの最大トークン数: LLMが1回の回答で返す最大文字数に相当する制限。1トークンは、日本語で約1〜3文字、英語では1語程度に相当します（※LLMによって異なる場合があります）。
2️⃣ 引数（Arguments）
引数（Arguments）は、エージェントが扱うデータの入出力を定義するものです。
具体的には、ユーザーや他システムからの入力データや、処理結果として返す出力データが該当します。
ユーザープロンプトでは引数の使い方を構造化し、システムプロンプトではその意味や目的を説明することで、エージェントが文脈を正しく理解し、適切に動作できるようになります。
以下の図の通りに、入力引数と出力引数のスキーマを定義することができます。
[ルート プロパティを追加]をクリックすると、画面に従って [名前]・[型]・[説明]・[必須] などを設定できます。設定時には、以下の点にご留意ください。
- 出力引数: [出力スキーマ]を定義することで、エージェントは期待される出力構造を理解し、より安定した形式で結果を返すことができます。
- 説明: [説明]欄に引数の目的や使い方を明確に記述することで、エージェントがその値を文脈に沿って正しく活用できるようになります。
- 生のスキーマを編集: [生のスキーマを編集]トグルを有効化することで、スキーマを JSON 形式で直接編集することも可能です。
型がString（文字列）やNumber（数字）の時に、そのまま設定できますが、型がArray（配列）の時に、以下のような形で定義してください。
例えば、以下のサイトより、配列型の未対応設備一覧を入力引数に渡す必要があります。
"未対応設備一覧": [
{
"設備名": "タービン発電機 TG-1000EX",
"保守期限": "2023-12-31",
"ステータス": "未対応"
},
{
"設備名": "産業用ロボット IR-300MZ",
"保守期限": "2024-01-05",
"ステータス": "未対応"
},
{
"設備名": "風力発電機 1型",
"保守期限": "2024-03-12",
"ステータス": "未対応"
}
]
UiPath Agent Builderの引数スキーマでは、以下のように定義することになります。
定義した引数は、ユーザープロンプト内で {{引数名}} の形式で記述する必要があります。
このように記述することで、エージェントはその引数の値をプロンプト文の一部として認識し、文脈に沿った応答や判断ができるようになります。
出力スキーマでも同じように、出力引数のアサイン結果一覧を定義します。
3️⃣ システムプロンプトとユーザープロンプト
1. システムプロンプト
システムプロンプトは、エージェントに対してその役割・目的・制約を自然言語で明確に伝えるものです。
あわせて、以下のような実行時の判断材料も定義します：
- 従うべきルール
- ツールの使用タイミング
- 人へのエスカレーションの条件
- コンテキスト（外部知識や文書など）を参照するべき場面
これにより、エージェントは与えられたタスクに対して計画的に行動し、必要に応じて柔軟に対応できるようになります。
また、ツール・ロボット・人・知識ベースとの連携を通じて、エージェントは徐々に最適な振る舞いを学び、改善していくことができます。
良いシステムプロンプトは、次の要素を含みます：
- ステップバイステップの手順
- 想定されるケースへの対応方針
- いつ・どのような場面でツール／人／コンテキストを活用するかの判断基準
2. ユーザープロンプト
ユーザープロンプトは、エージェントに入力引数（Arguments）を渡すための構造を定義する部分です。
引数の値をテンプレート構文（例：{{引数名}}）で埋め込むことで、エージェントがその情報を文脈として理解できるようにします。
また、システムプロンプトの中でどのようにその引数を参照するかも、ユーザープロンプトを通じて明示できます。
実践例
本エージェントは、「未対応設備一覧」の入力と、「保守要員一覧」のコンテキスト情報(後ほど紹介)をもとに、
各設備に最適な保守要員ペア（A・B）を選定し、アサイン結果を出力します。
参照：保守要員一覧
| 保守要員 | 保守資格を持っている設備名 | 備考欄 |
|---|---|---|
| 田中 太郎 | タービン発電機 TG-1000EX, 送配電システム TDS-5000X | 技術力が高く、リーダーシップあり。吉田真由美とは過去に衝突したことがある。 |
| 松本 玲奈 | 産業用モーター IM-750AX, 産業用ロボット IR-300MZ | 慎重な性格で、安全管理に優れる |
| ... | ... | ... |
以下に、実際にこのエージェントを設計・動作させるための システムプロンプト および ユーザープロンプト の例を示します。
この設計により、設備ごとのスキルマッチ・人間関係・過去実績を総合的に考慮したアサイン判断が可能になります。
システムプロンプト例
あなたは保守設備のアサインを担当するエージェントです。
以下の <未対応設備一覧> に記載された各設備に対して、
「保守要員一覧」（コンテキスト情報）を参照し、適切な保守要員A・Bを選定してください。
【選定ルール】：
1. 保守要員A・Bともに、その設備に対して「保守資格を持っている設備名」に含まれている必要があります。
2. AとBは別の人物としてください。
3. 人間関係の衝突（備考欄の内容）を考慮し、相性の悪いペアは避けてください。
4. 適任者が複数いる場合、技術力・協調性・過去の実績などを考慮して判断してください。
5. 必ず「アサイン理由」を簡潔に記載してください（例：「経験豊富」「相性が良いため」など）。
【出力形式】：
[
{
"設備名": "〇〇設備",
"保守要員A": "氏名A",
"保守要員B": "氏名B",
"アサイン理由": "ペアを選んだ理由"
},
...
]
必要に応じて、備考欄の人間関係情報も活用しながら、適切な保守体制を構築してください。
ユーザープロンプト例
<未対応設備一覧>
{{未対応設備一覧}}
</未対応設備一覧>
ユーザープロンプトでは、入力引数（例えば 未対応設備一覧）の中身を <未対応設備一覧> {{未対応設備一覧}} 未対応設備一覧> のようにタグ形式で構造化して記述します。
このようにタグ＋引数展開 {{引数名}} を使うことで：
- 動的かつ文脈に沿ったデータの差し込みが可能になります
- 同じプロンプト構造でも、実行ごとに異なる入力に対応できます（ハードコード不要）
- LLM（大規模言語モデル）がデータの意味を理解しやすくなり、誤判断を減らせます
- 入出力の一貫性や再利用性が高まり、エージェントの柔軟性・効率・精度が向上します
4️⃣ ツール
ツールは、エージェントが必要な情報を取得したり、タスクを実行したりするための手段です。
現在使用できるツールには、Activities と Processes があり、
いずれもエージェントが外部と連携して判断・行動を自律的に行うことを可能にします。
アクティビティ
アクティビティは、Agent Builder 内で追加・設定できる外部サービスとの連携アクションです。
Salesforce や Microsoft Teams、Zoom など主要な業務ツールに対応しており、エージェントが情報をやり取りしたり、処理を実行したりする際に活用されます。
エージェントは必要な引数やデータを自動で判断してアクティビティを使うため、設定は最小限で済み、柔軟に動作します。
また、必要に応じてフィールドに静的な値や説明を指定することで、より正確な制御も可能です。
UiPath Agent Builderでは、以下の種類のアクティビティがツールとして利用可能です。
📝 補足：
システムプロンプトやユーザープロンプトには、アクティビティとどう連携すべきかの指示を明記しておくことが重要です。
また、アクティビティの各フィールドにカスタム説明を設定することで、エージェントがその目的をより正しく理解し、状況に応じた使い方ができるようになります。
例えば、最後のアサイン結果一覧をSlack経由で管理者に連絡するとしたら、Slack種類から[Send Message To Channel]アクティビティを利用して送信します。
上記のような追加動作がある場合は、システムプロンプトには、以下のような文を追加する必要になります。
アサイン処理が完了したら、最後に出力した「アサイン結果一覧」を、Slackの[Send Message To Channel]アクティビティを使って設備管理チャンネル（#Infra）に送信してください。
送信メッセージには、各設備に対する保守要員A・Bの割り当て内容とアサイン理由を簡潔にまとめてください。
例：
「アサイン結果をお知らせします。
・設備A：担当Aさん／担当Bさん（理由）
・設備B：...」
Slackへの投稿が完了したら処理終了です。
プロセス
プロセスは、エージェントがより複雑な業務処理や社内のビジネスフローを実行するためのツールです。
アクティビティだけでは実現できない処理や、既存のRPAプロセスを再利用したい場合に有効です。
プロセスを使うことで、エージェントが他の自動化と連携しながら、より高度で実用的な業務遂行を行えるようになります。
アクティビティの利用と同じように、プロセスの起動条件をシステムプロンプト内に明記することも重要です。
5️⃣ コンテキスト
コンテキスト グラウンディング は、エージェントが参照可能な文書や知識のインデックスを作成し、
実行中に必要な情報を検索・活用できるようにする仕組みです。
📝主な役割と特徴
- ビジネス文書や手順書などをインデックス化し、エージェントが自然言語で検索できるようにする
- 各インデックスは、特定の業務プロセスや部門に紐づく情報群として機能する
- 実行中、エージェントはこれらのインデックスから関連情報を動的に取得して判断に活用
- Agent Builder の設定により、検索対象や精度・関連性のコントロールも可能
エージェントが参照可能なインデックスを作成するには、以下の2つのステップが必要です。
この2つのステップを踏んで、指定のフォルダにインデックスを作成すると、UiPath Agent Builder からそのインデックスを利用できるようになります。
前述の通りに、Agent Builder の以下の設定により、検索の精度や関連性もコントロール可能です。
-
🎯関連性スコアのしきい値
定義：
コンテキスト グラウンディング で取得した情報のうち、類似度スコアがこのしきい値を下回るものは除外される設定です。
使い方：
この値を上げるほど、より関連性の高い情報のみが使用されるようになります。
つまり「ベストな回答だけを使う」ためのフィルターとして機能します。 -
🎯生成される結果の最大数
定義：
ユーザーのクエリに対して、コンテキスト グラウンディング が返すチャンクの数を指定します。
これはLLMへの入力トークン数（負荷）や応答精度に影響を与えます。
使い方：
この数を増やすと、より多くの文書チャンクが返され、コンテキストの幅が広がります。
ただし、関連性スコアのしきい値と併用することで、件数と品質のバランス調整が可能です。
コンテキスト情報を活用するためには、システムプロンプトにその旨を明記する必要があります。
今回の例では、以下のように記述しています。
....
....
「保守要員一覧」（コンテキスト情報）を参照し、適切な保守要員A・Bを選定してください。
...
...
6️⃣ エージェントメモリ
エージェントメモリは、各エージェントに内蔵された「記憶の仕組み」であり、実行中に得た事実や観察結果を記録します。
また、エスカレーション情報を保持し、長期的な知識として活用できます（コンテキストグラウンディングと補完関係）。
📝 仕組みと特徴
- 解決されたエスカレーションは、**質問（キー）と文脈情報（値）**のペアで記録されます
- キーは最大80文字
- 保存期間（TTL）は3か月(注)
- これらのペアは意味的類似性で、後続のユーザーの質問と自動照合されます
注：より長期的な知識参照が必要な場合は、コンテキスト グラウンディングを併用して、保存済み文書をインデックス化し、エージェントが実行中に検索できるように設定できます。
Agent Builder の [エスカレーションとエージェントメモリ] パネルでエージェントメモリを有効化することができます。
有効にすると、公開済みエージェントの最新版にメモリが紐づけられ、実行時に Action Center からのエスカレーション結果が自動保存されます。
このように、エージェントメモリは対話の履歴や過去の判断の再利用を可能にし、エージェントの対応力と判断精度を高める重要な機能です。
7️⃣ エスカレーション
エスカレーションとは、エージェントの実行中に人間の判断（Human-in-the-Loop）を組み込むための仕組みです。
UiPathの Action Center を基盤としており、次のような場面で活用されます：
- ビジネス上の重要な判断を人に確認・承認してもらいたいとき
- ツールの実行や文脈理解に問題がある場合に、手動で支援を受けたいとき
- 業務プロセスの中で、例外処理や承認フローを組み込みたいとき
エスカレーション用画面の開発は、UiPath の Apps を使用して行います。
詳細な開発手順については、Apps 開発とデプロイ：保守要員確認ページをご参照ください。
作成した Apps をデプロイすると、以下の画面の [アプリ テンプレート] から選択できるようになります。
また、コンテキストを利用する場合と同様に、システムプロンプトにもエスカレーションの条件を明記する必要があります。
たとえば、以下のような指示文をシステムプロンプトに追記します。
...
...
【補足】：
もし、いずれかの保守要員（AまたはB）が見つからない場合は、
<保守要員の手動確認> エスカレーションを実行し、対象設備名とアサイン結果を記載してください。
...
...
🔚 最後に
本記事では、UiPath Agent Builder を用いた AI エージェント開発の基礎として、エージェントの全体構成と開発に必要な各コアコンポーネント（LLM、引数、プロンプト、ツール、コンテキスト、エージェントメモリ、エスカレーション） について解説しました。
これらの要素を理解し、適切に組み合わせることで、より柔軟かつ信頼性の高いエージェントを効率的に構築できるようになります。
次回の記事では、作成したエージェントの品質をどう評価し、どのように運用・改善していくか に焦点を当てます。具体的には、
- エージェントのパフォーマンス評価方法
- 実行結果のトレースとモニタリング
- 開発・運用におけるベストプラクティス
について詳しく紹介します。