エージェント・エージェントチーム・ツールの設計

この章の結論

• 26C では、複数のエージェントとノードをまとめて業務を処理する単位は**ワークフロー（Workflow）**です。以前のエージェントチーム（Agent Team）に当たり、画面の一部には今も Agent Team の表記が残っています
• エージェントは Resources タブの Agents サブタブで作ると、他のワークフローでも再利用できます。ワークフローの中で直接作ったエージェントは、そのワークフロー専用です
• ツールにはビジネス・オブジェクト、ドキュメント、外部 REST、MCP、Email、Connector、Deep Link などがあります。ツールとパラメータの説明文が、LLM が「いつ・どう呼ぶか」を決める材料になります
• 事前構築（Seeded）のワークフローは直接は編集できません。View → Customize（許可された範囲だけ）か Duplicate（コピー）で調整します
• ビジネス・オブジェクト・ツールは実行ユーザーのトークンで Fusion の REST を呼びます。利用者が画面で見られないデータは、エージェントにも見えません

全体像

部品の関係

ワークフローを構成する部品（26C）

ワークフロー（Workflow：デプロイの単位。旧 Agent Team）
 ├─ Settings：Details／LLM／Security（使えるロール）／Chat Experience／Questions
 │            ／Triggers／Variables／Error Handling
 ├─ ノード：Agent、LLM、Multi Agent、Business Object Function、Code、Switch、Human Approval …
 │    └─ Agent ノード → エージェント（Agents）
 │                       ├─ Prompts（Agent Role・Prompt・Summarization）
 │                       ├─ Topics（再利用できる指示のまとまり）
 │                       └─ Tools（再利用できる道具）
 └─ Publish（公開）→ 利用者のチャット、トリガー、外部アプリから実行される

部品は再利用できるように分けます。トピックとツールは複数のエージェントで共有でき、エージェントは複数のワークフローで共有できます。

設計の目安

公式ドキュメントと公式ブログ（AI Agent Studio のプロンプトのベストプラクティス）が示す目安です。

判断ポイント	推奨
1 チームのエージェント数	3〜5。業務領域か機能で分ける
ツールの数	1 エージェントあたり 1〜5、チーム全体で 10 以内
スーパーバイザーの役割	意図の解釈と振り分けだけ。業務処理そのものはしない
ワーカーの役割	担当範囲が決まった処理を、割り当てられたツールで実行する
決まった計算・変換・検証	LLM ではなく Code ノード（規則なら Policy ノード）に任せ、LLM の呼び出しを減らす
互いに依存しない処理	Parallel ノードで並列に実行し、応答時間を短くする

作り始める前に、①手作業の業務を小さなステップに分解し、②ステップ間の依存関係を洗い出して「バックエンド処理」と「LLM が必要な処理」を分け、③各ステップのノード種類・入力・出力・変換ルールを決めます。

設定・実装の手順

1. エージェントを作る（Resources > Agents）

1. AI Agent Studio で Resources タブを開き、Agents サブタブで Add を選択します
2. Agent Settings パネルで各タブを設定します（下表）
3. Available Tools パネルで、使うツールを追加します
4. Available Topics パネルで、使うトピックを追加します
5. Create で保存します。作ったエージェントは、同じファミリー（Family）・製品（Product）のワークフローを作るときに選べるようになります

タブ	主な項目	ポイント
Details	Name（Code は自動入力）、Family、Product、Description、Maximum Interactions	Description は Generate で下書きを作れる。Maximum Interactions はトピック・ツールとのやり取り回数の上限
Prompts	Agent Role、Prompt、Summarization Mode（Default／Custom／Disabled）、Summarization Prompt	Prompt がシステム・プロンプトに当たる
LLM	既定のモデル、または選択したモデル	独自モデルを使う場合はモデルのプロパティを指定
Input Variables	変数の名前・型・説明・値	エージェントへ値を渡す
Output	エージェントの出力の構造	後続のノードが扱いやすい形に揃える

2. ワークフローを作る（Workflows > Add）

1. Workflows タブで Add を選択します
2. 設定を入力します

タブ	主な項目
Details	Agent Team Name and Code（Code は英数字とアンダースコア）、Family、Product、Description
LLM	Provider（既定のモデル、または選択したモデル）
Security	このワークフローを使えるロールを Add で追加
Chat Experience	Answer in user’s language、Enable file upload、Enable third-party file upload
Questions／Triggers／Variables／Error Handling	Starter Questions と Follow-up Questions、起動条件、全ノード共通の変数、恒久的なエラー時の通知メール先

3. ノード検索でノードを追加し、順番につなぎます。既存ノードの前・後・間にも挿入できます
4. Debug で動作を確認します（テスト・評価・デプロイ・セキュリティ）
5. Publish します。公開したワークフローは、権限のある利用者のエージェント一覧（Me > Quick Actions > Show More > AI Agent Studio > AI Agent）に表示されます

ノードは 5 つの分類で提供されます（26C）。

分類	ノード（英語 UI 名）	主な用途
AI	Agent、LLM、Multi Agent、RAG Document Tool、Workflow	推論・分類・要約。Multi Agent はスーパーバイザーがワーカーへ振り分ける
Communication	Send Email、Publish Signal	メール送信、シグナルの発行
Data	Business Object Function、Document Processor、External REST、Tool、Vector DB Reader／Writer	Fusion データの取得・更新、文書からの項目抽出（ドキュメント・スキーマを使用）、外部 API、ベクトル DB
Logic	Code、Set Variables、Policy	計算・変換・検証、変数への代入、ポリシー・モデルによる規則の判定
Workflow Control	If Condition、Switch、For Loop、While Loop、Parallel、Wait、Human Approval、Return、Reference／Reference Block	分岐、繰り返し、並列、待機、人の承認、戻り値、ロジックの再利用

3. テンプレート（事前構築）や自然言語から作る

• Seeded タグの付いたワークフローは事前構築です。View で開き、Customize が表示されれば許可された範囲を変更できます。LLM ノードと Agent ノードのプロンプトだけを変更できるものもあります。Customize が出ないものは変更できません
• 自由に変えたい場合や元を残したい場合は Duplicate でコピーします。コピーは別の Code になり、自由に編集できます
• Edit で直接編集できるのは**下書き（Draft）**のワークフローだけです。Edit ではなく View が表示される場合は、公開済みか事前構築です
• Ask Oracle 欄に業務の目的を自然言語で書くと、ワークフローやエージェント型アプリの初期構成が作られます。素早く始めたいときに使い、細部は手で詰めます
• 既存のスーパーバイザー・エージェントは Marketplace タブ（または Resources タブ）の Supervisor Agents から編集でき、Migrate でワークフローに変換できます。変換後は「変換 → 確認 → 改善」の順で、1 回に 1 か所ずつ直して結果を比べます

4. ツールを作る（Resources > Tools）

Resources タブの Tools サブタブで Add を選び、Tool Type を選択します。名前、説明、Family、Product を入力すると Code は自動入力されます。更新系の処理には Require Human Approval を有効にし、承認者が行う操作（Actions）と承認者への説明（Message）を設定できます。

ツール（Tool Type）	できること	設定・注意点
Business Object	Fusion の業務データ（REST リソース）の取得・作成・更新・削除	実行ユーザーのトークンで呼ぶ。返す項目は絞る
Document	アップロードした文書を意味検索して回答に使う（RAG）	Ready to Publish → Process Agent Documents → Published
External REST	社内外の SaaS や公開 API を呼ぶ	ORA_FND_TRAP_PRIV が必要。HTTPS のみ
MCP	外部の MCP サーバーの機能を使う	Transport Type は SSE か StreamableHTTP
Email／Connector／Deep Link	メール送信、SharePoint・Web ページ等への接続、Fusion の画面への誘導	Connector の接続は Connectors タブで作る

ツールの品揃えはリリースで変わります。公式ラーニング・パスでは、Calculator と Runtime File Processor は「26C より前」のツールとして扱われています。実際に選べる種類は環境の Tool Type 一覧で確認します。

ビジネス・オブジェクト・ツールは次の順で作ります。

1. 対象の REST リソースを各製品の REST API ドキュメントで確認し、事前に Postman などで呼べることを確かめる
2. ビジネス・オブジェクトに関数（Function）を追加する。手動、Add from Specification（仕様から取り込み）、cURL や Postman コレクションからの取り込みが使える
3. クエリ・パラメータとヘッダーを、毎回同じ値の固定値か、会話から LLM が埋める動的値かに分ける
4. パラメータの説明に「必須かどうか・形式・許容値・制約・既定値」を書く。エージェントが API を呼ぶ前に正しい入力を集める拠り所になる
5. 返す項目を必要なものだけに絞る（fields パラメータなど）
6. Tool Type = Business Object のツールを作って関数を選び、エージェントに追加する。ワークフローでは Business Object Function ノードとして直接使える

外部 REST ツールは、Instance URL（ベースのドメインだけ。パスや末尾のスラッシュは付けない）、Authentication、Description を設定し、Add Endpoint で Name・Operation Type（HTTP メソッド）・Resource Path（相対パス）・Description を登録します。さらに Parameters、Sample Queries（このツールを呼ぶべき質問の例）、Headers を設定します。

MCP ツールは、MCP サーバーの Instance URL、Transport Type（Server Sent Events（SSE）または StreamableHTTP）、Credential Type（サーバーが求める認証方式）を設定します。REST のラッパーを作らずに外部の機能を使えます。

5. 権限とデータセキュリティ

• エージェントは利用者の ID で動く：エージェントの操作には実行ユーザーの Fusion のトークンが付きます。API はエージェントを信用するのではなく、利用者の権限を確認します。エージェントを使ってもアクセス範囲は広がりません
• データ・セキュリティはそのまま効く：画面で見られない行は、エージェントにも見えません。ビジネス・ルールで画面上だけ隠している項目は、ツールが返す項目から外します
• 作る権限と使う権限は別：作る権限は製品ファミリーとリソースの種類の単位で付きます。使う権限はワークフローごとの Security タブで付けます
• スケジュール実行は例外に注意：スケジュールで動くワークフローはサービス・アカウントで動かせますが、追加の権限が必要です。スケジュール・トリガーの設定には ORA_DR_FAI_BATCH_JOB_MANAGER_DUTY を使います
• 更新系は人の承認を挟む：POST・PATCH・DELETE のような更新は、ツールの Require Human Approval やワークフローの Human Approval ノードで、確定前に承認を求められます
• 個人情報をプロンプトに書かない：利用者の情報は実行時にツールで取得します

コード例

ワークフローの設定欄やプロンプトでは、{{...}} の式（Expressions）でノード間の値を受け渡します。入力欄の Insert Expression から挿入することもできます。

式（Expressions）の例（ノードコード getInvoice は例）

{{$context.$system.$currentDate}}                     … 実行日（ISO 形式）
{{$context.$system.$inputMessage}}                    … 利用者が入力したチャット本文
{{$context.$user.$name}}                              … 実行したユーザー
{{$context.$variables.policyVersion}}                 … ワークフロー変数（Set Variables ノードで代入）
{{$context.$nodes.getInvoice.$output.InvoiceAmount}}  … ノードの出力項目
{{$context.$nodes.getInvoice.$error.$info}}           … エラー・ハンドラで使うエラーの詳細
{{$context.$triggers.EMAIL.$input.subject}}           … メール・トリガーで起動したときの件名

ツールは画面で作りますが、設計書として項目を先に決めておくとレビューしやすくなります。

ビジネス・オブジェクト・ツールの設計シート（例）

tool:
  type: Business Object
  name: AP Invoice Status Lookup        # 例
  description: >
    買掛金請求書の状況（検証・承認・支払）を請求書番号で照会する。
    利用者が請求書の状況や支払済みかどうかを尋ねたときに使う。更新はしない。
  function:
    name: getInvoiceByNumber
    method: GET
    resource: /fscmRestApi/resources/11.13.18.05/invoices
    parameters:
      - name: q
        mode: dynamic        # 会話から LLM が値を埋める
        description: >
          必須。形式は InvoiceNumber=<請求書番号>。番号が不明な場合は
          ツールを呼ばずに利用者へ確認する。
      - name: fields
        mode: fixed          # 毎回同じ値。返す項目を絞る
        value: InvoiceNumber,InvoiceAmount,InvoiceCurrency,ValidationStatus,ApprovalStatus,PaidStatus
      - name: limit
        mode: fixed
        value: 5
# 属性名は REST API for Oracle Fusion Cloud Financials の Invoices リソースで確認する

エージェントの Output タブで定義する出力構造の例（書式の詳細は公式ドキュメントで確認）

{
  "type": "object",
  "properties": {
    "answer": { "type": "string", "description": "利用者への回答本文" },
    "invoiceNumber": { "type": "string", "description": "照会した請求書番号" },
    "needsHumanCheck": { "type": "boolean", "description": "担当者の確認が必要か" }
  },
  "required": ["answer", "needsHumanCheck"]
}

落とし穴とベストプラクティス

よくあるミス

• ワークフローの中で直接エージェントを作る：そのワークフロー専用になり、再利用できません。共通で使うエージェントは Resources > Agents で作ります
• Family・Product を適当に選ぶ：エージェントやツールは、同じファミリー・製品のワークフローで選べるようになります。権限も製品ファミリー単位で効きます
• 説明文が曖昧：ツールが呼ばれすぎる、または呼ばれない原因になります。「何をするか・いつ使うか・前提・返す内容」を書きます
• ツールの戻り値をすべて返す：トークンが増えて遅くなり、画面で隠している項目まで LLM に渡ります。必要な項目だけ返します
• Seeded のワークフローを直接直そうとする：Edit はできません。Customize の範囲を確認し、足りなければ Duplicate します

• ツールを呼ぶ順番に依存関係があるときは、プロンプトに明記します（例：「請求書を照会する前に、必ず利用者の所属 BU を取得する」）
• 必須の入力がそろわないうちはツールを呼ばず、利用者に聞き返すよう指示します
• 外部 REST ツールの認証情報は、環境を移行したあとに再設定が必要です（テスト・評価・デプロイ・セキュリティ）
• 新しいオーケストレーションはワークフローで作り、LLM の判断が必要な箇所だけ Agent／LLM ノードにします。決まった処理を Code ノードに寄せると、速く・安く・テストしやすくなります

試験対策ポイント

• 対応する試験：AI Agent Studio 模擬テスト の「エージェントの構築」「AI Agent Studio の構成要素の理解と設定」「ロールとアクセス権限の作成・割当」
• エージェントの Details／Prompts／LLM／Input Variables／Output タブと、Maximum Interactions・Summarization Mode の意味を押さえます
• ワークフローの Settings（Security、Chat Experience、Questions、Triggers、Error Handling）の役割を区別します
• ノードの分類と代表的なノード（Multi Agent、Code、Policy、Human Approval、Switch、Parallel、Return）を覚えます
• ツールの種類ごとの設定（外部 REST の Instance URL・Endpoint、MCP の Transport Type、ドキュメントの状態遷移）と、必要な権限を区別します
• Seeded ワークフローの扱い（View → Customize、Duplicate）と、再利用できるエージェントの作り方がよく問われます

公式ドキュメント

• Create and Configure AI Agents
• Create Workflows
• Nodes in Workflows
• Edit a Workflow
• Choose How to Create Workflows and Agentic Applications
• Add External REST Tool
• Add MCP Tool
• Variables Specific to Workflows
• Can I use any agent in my workflow?
• Business Object Tool in AI Agent Studio（Oracle ブログ）
• Identity and Security in AI Agent Studio（Oracle ブログ）
• From Supervisor to Workflow（Oracle ブログ）

関連ページ

• Fusion の AI と AI Agent Studio の全体像
• プロンプト設計とナレッジ（ドキュメント）活用
• テスト・評価・デプロイ・セキュリティ
• REST API の基本（URL・クエリパラメータ・ページング）
• 認証・認可（Basic・OAuth・JWT・統合ユーザー）
• セキュリティ設計（カスタムロール・データアクセス・監査）