> ## Documentation Index
> Fetch the complete documentation index at: https://docs-agents.fpt.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# サブエージェント
> 大きな Agent を役割ごとの助手に分ける。ビルド画面の詳細設定から管理します
1 つの Agent に仕事を抱えさせるほど、指示は長くなり、文脈は雑音まじりになり、回答の安定を保つのが難しくなります。すべての業務を 1 つの Agent に詰め込む代わりに、一部をサブエージェントに切り出せます。サブエージェントはそれぞれ 1 つの領域を担当し、自分の指示、自分のモデル、自分の接続を持ちます。
このときメインの Agent は取りまとめ役になります。利用者の依頼を受け、どの仕事をどのサブエージェントに渡すかを決め、必要なデータを添えて送り、結果を受け取り、最終的な回答にまとめます。外から見れば、利用者はひとりの Agent と話しているだけです。
FPT AI Console では、この機能は **ビルド** 画面の **構成** 列、**詳細設定** グループの中に **サブエージェント** として現れます。
## サブエージェントの動き
メインの Agent は、サブエージェントを仕事を任せられる同僚として扱います。
1. 利用者がメインの Agent に依頼を送ります。
2. メインの Agent は各サブエージェントの説明を読み、いまの仕事に合うものを選びます。
3. サブエージェントは独立した文脈で呼び出され、その仕事に必要なデータだけを受け取ります。
4. サブエージェントは仕事を終え、結果をメインの Agent に返します。
5. メインの Agent が結果をまとめて利用者に答えます。
手順 3 が別の文脈で動くため、サブエージェントの途中の思考がメインの会話履歴を膨らませることはありません。
## 使う理由
* **文脈が分かれる**: サブエージェントの呼び出しはきれいな文脈で動くので、メインの会話を散らかしも膨らませもしません。
* **司令塔が 1 つ**: どこに渡すかの判断はすべてメインの Agent を通るので、流れが読みやすく、追いかけやすくなります。
* **広げやすい**: 新しい領域が増えたらサブエージェントを足すだけで、メインの指示を書き直す必要がありません。
* **並行して動かせる**: 互いに依存しない仕事は同時に進められ、回答までの時間が縮みます。
* **権限を絞れる**: サブエージェントは本当に必要な接続だけを持ちます。メインの Agent がすべてのアクセス権を抱える必要はありません。
## どこで分けるか
次のようなときはサブエージェントを検討してください。
* Agent がはっきり別の領域をいくつも抱えている。たとえばデータ照会、文書作成、例外対応。
* メインの Agent の指示が長くなり、互いに矛盾するルールが混ざりはじめた。
* ある仕事だけ、別のモデル、別の口調、別の接続が必要。
* 機微な業務のアクセス権を狭く保ちたい。
分けなくてよいのは次のようなときです。
* 使うツールが少なく、指示もまだ短い。
* 仕事どうしが文脈の大半を共有していて、分けるとデータの受け渡しばかりになる。
## サブエージェントを構成するもの
サブエージェントは 5 つの要素で表されます。最初の 3 つはメインの Agent が正しく見つけて呼び出せるかを決め、残りの 2 つは呼び出されたあとの出来を決めます。
| 要素 | 必須 | 役割 |
| - | - | - |
| 名前 | はい | 一覧と実行ログの中でサブエージェントを識別する |
| 説明 | はい | メインの Agent が、いつここに任せるかを判断する材料 |
| モデル | はい | サブエージェント自身の処理の頭脳 |
| 指示 (AGENTS.md) | はい | 働き方。担当範囲、口調、制限 |
| 接続 | いいえ | サブエージェント自身の外部システムへのアクセス |
### 名前
名前は、サブエージェント一覧と、メインの Agent が誰に任せたかを追うときに現れます。
* 部署名や人名ではなく、行う動作にちなんだ名前にします。
* 小文字をハイフンでつなぎます。たとえば send-candidate-email、summarise-report、look-up-order。
* process や helper-1 のような漠然とした名前は避けてください。数が増えると見分けがつかなくなります。
### 説明
もっとも大事で、**必須** の項目です。どこに仕事を回すか決めるとき、メインの Agent は各サブエージェントの指示全文ではなく、説明だけを読みます。あいまいだと、違うサブエージェントを呼んだり、任せずに自分でやってしまったりします。
* 「〜のときに使う」という形のユースケースとして書きます。
* ほかのサブエージェントとの境目を書き、重ならないようにします。
* 200 文字までなので、短く具体的に。
よい例: 「定例レポートを経営向けの短い要約にまとめるときに使う。」
いまひとつな例: 「要約する。」- いつ使うかが書かれていないので、メインの Agent は呼び時が分かりません。
### モデル
サブエージェントはそれぞれ自分のモデルで動き、メインの Agent と同じである必要はありません。推奨モデルがあらかじめ選ばれています。
* 分類、抽出、整形のような単純で繰り返しの多い仕事は、小さいモデルのほうが速くて安く済みます。
* 分析や多段階の論証のように深い推論が要る仕事は、強いモデルのままにしてください。
### 指示 (AGENTS.md)
サブエージェント自身の指示です。メインの Agent の Instructions と同じ働きをしますが、効く範囲はそのサブエージェントの中だけです。作成時の必須項目で、エディタは Markdown に対応し、プレビュー / ソースを切り替えられます。
よい指示は 4 つに答えています。
* **入力**: メインの Agent から何を受け取るか。
* **作業**: どの手順を踏むか。
* **出力**: どんな形式で、どれくらいの長さ、どんな口調で返すか。
* **制限**: 絶対にしてはいけないこと。たとえば渡されたデータにない数字を作ること。
### 接続
このサブエージェントだけが使ってよいアカウントと外部システムです。メインの Agent の接続とは別物なので、業務ごとにアクセス範囲を絞れます。
* その仕事に本当に必要な接続だけを付けてください。
* 例: メールを送るサブエージェントには Outlook が要りますが、SharePoint は要りません。
## サブエージェントの管理
サブエージェントに関する操作はすべて、**ビルド** 画面の **構成** 列の下端、**詳細設定** グループの中の **サブエージェント** にまとまっています。詳細設定は、上にあるモデル、Skill、Guardrail から離して、使用頻度の低い設定を 1 か所に集めたものです。
サブエージェントがまだない Agent では、空の状態と案内が表示されます。見出しの横の数字が、いまいくつあるかを示します。
### サブエージェントを作る
ビルド画面で右の構成列を下までスクロールし、詳細設定グループを開いて、サブエージェントのプラスをクリックするとサブエージェント作成ダイアログが開きます。
どちらも必須です。名前は動作にちなんで付けます。説明はユースケースとして書いてください。メインの Agent はこれを頼りに、いつ呼ぶかを判断します。
推奨モデルのままでもよいですし、仕事の重さに合わせて別のものを選んでも構いません。
指示 (AGENTS.md) ブロックの編集をクリックしてエディタを開き、入力、作業、出力、制限を書きます。書き終えたら完了をクリックします。必須項目なので、空のままだと「サブエージェントの指示を入力してください。」と表示され、作成できません。
コネクタを追加をクリックし、このサブエージェントだけが使ってよいアカウントと外部システムを選びます。
「サブエージェントを追加しました」と表示され、サブエージェント一覧にすぐ現れます。初期状態は有効です。
指示のエディタは Markdown に対応し、プレビュー / ソースを切り替えられます。
### 一覧を見る
この Agent に付いているサブエージェントは、サブエージェントの見出しのすぐ下に並びます。各行には名前、有効 / 無効のスイッチ、右端のゴミ箱アイコンがあります。名前をクリックすると、そのサブエージェントの設定が開きます。
### サブエージェントを編集する
いま保存されている内容が入ったサブエージェント編集ダイアログが開きます。
名前、説明、モデル、指示 (AGENTS.md)、接続の一覧を変更できます。名前、説明、指示は空にできません。
変更は Agent の下書きに書き込まれます。取り消すならキャンセルをクリックします。
### サブエージェントを一時停止する
しばらく使わないだけなら削除する必要はありません。どの行にも右側に有効 / 無効のスイッチがあります。
スイッチが灰色になり、オフのラベルが出ます。名前も薄くなるので、止めている行がひと目で分かります。
一時停止中のサブエージェントは名前、説明、モデル、指示、接続をそのまま保ちますが、メインの Agent は仕事を回さなくなります。
スイッチを入れ直すと、設定はそのままで再び働きはじめます。作り直す必要はありません。
特定のサブエージェントなしでメインの Agent がどう動くか見たいとき、季節性のある仕事のとき、つなぎ先のシステムがメンテナンス中のときに一時停止を使ってください。削除は、もう二度と使わないと確信できるときだけに。
### サブエージェントを削除する
一覧のサブエージェントの行の端にあります。
このサブエージェントの指示と接続が下書きから取り除かれ、元に戻せないことが説明されます。
残すならキャンセルをクリックします。いまは使わないだけなら、一時停止にしてください。
削除は元に戻せません。サブエージェントの変更はすべて下書きにだけ効きます。デプロイチャネルで動いている Agent は、新しいバージョンを公開するまで、公開済みのバージョンのまま動き続けます。
## 使い方の例
### 1. 部門をまたぐ業務アシスタント
1 つのメイン Agent が全社員の窓口になり、その後ろに専門のサブエージェントを置きます。**人事**(規程、休暇、保険の照会)、**IT ヘルプデスク**(権限申請、端末の不具合)、**経理**(支払いと仮払いの手続き)。
各サブエージェントは自部門のデータと手順だけを知っていればよく、持つ接続もその部門のものだけです。回答の精度が上がり、人事規程が変わったときも、共通の指示ではなくそのサブエージェントだけを直せば済みます。
### 2. 複数の手続きがあるカスタマーサポート
カスタマーサポートの Agent が最前線で会話を受け、サブエージェントに仕事を渡します。**注文照会**(倉庫と配送システムに接続)、**クレームと返金**(CRM と返品手続きに接続)、**商品相談**(カタログと価格方針をもとに回答)。
顧客から見ればひとりの Agent と話しているだけですが、依頼の種類ごとに、適切なデータと権限を持つサブエージェントが対応します。とくに返金は、ほかに影響させずに Guardrail を厳しくできます。
### 3. 業務データの分析とレポート
業務チームが自然言語で質問し、メインの Agent が依頼をサブエージェントに割り振ります。**データ照会**(データベースや BI ツールへのクエリを書いて実行)、**レポート作成**(数字を読める文章に変える)、**可視化**(グラフを作る)。
こう分けておくと各工程が独立し、段階ごとに出力を確かめやすく、データソースやレポート要件が変わったときも 1 つのサブエージェントを差し替えるだけで済みます。
## 気をつけること
* サブエージェントは 1 つのことをするべきです。説明に「〜と〜と」が何度も要るようなら、1 か所に詰め込みすぎています。
* 説明は機能ではなくユースケースとして書いてください。メインの Agent が正しいサブエージェントを選ぶ、いちばんの手がかりです。
* 本当に必要な接続だけを付けてください。持つ権限が少ないほど、リスクも小さくなります。
* 追加や編集のあとは、**テスト** タブで実際の場面をいくつか通し、メインの Agent が正しいサブエージェントを呼ぶか確かめてください。
* 納得できたら **Publish** を忘れずに。そこではじめて、サブエージェントの設定がデプロイチャネルに届きます。
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.