> ## Documentation Index
> Fetch the complete documentation index at: https://domoinc-openapi-sync-dataflows.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# エージェントの権限と説明を設定する

## はじめに

この記事では、Domoでエージェントを作成する時の［権限］フィールドと［説明］フィールドの違いと、各フィールドを効果的に使用する方法について説明します。これらのフィールドにはそれぞれ異なる目的があり、それぞれに適切な内容を指定した場合に最もうまく機能します。

***

## 各フィールドを理解する

### 権限

**［権限］では、このエージェントがどのような人かを定義します。**

エージェントのペルソナ、専門分野、視点を設定します。これは、役職名や特徴の説明のようなものだと考えてください。エージェントどのような専門性を備えているべきかをエージェントに伝える一文または短い段落です。

［権限］はユーザーのすべてのメッセージにフレームミングプレフィックスとして適用されるため、会話全体を通じてエージェントのアイデンティティを継続的に強化します。

**含まれるもの：**

* エージェントの専門分野または領域
* エージェントの視点またはプロフェッショナルな見方
* 主な目的の簡単な説明

**含まれないもの：**

* 番号付きのステップまたは手順（［説明］を使用）
* 口調またはフォーマットに関するルール（［説明］を使用）
* 条件付きロジックまたはツールガイダンス（［説明］を使用）

### 説明

**［説明］では、このエージェントがどのように動作するかを定義します。**

［説明］はエージェントの作業手順書です。つまり、エージェントが取るべき手順、従うべきルール、回答時にエージェントが行うべき動作を記載します。［説明］は、エージェントのシステムコンテキスト（すべての応答を制御する基本レイヤー）に挿入されます。

**含まれるもの：**

* 手順を踏むワークフロー（例：「最初にXをチェックしてからYを要約」）
* 口調とフォーマットのルール（例：「常に箇条書きで回答」）
* ガードレールと制約（例：「売上データに関連する質問にのみ回答」）
* ツールの使用方法のガイダンス（例：「CRMツールを使用してからパイプラインの質問に回答」）
* ダイナミックコンテンツのテンプレート変数（例：`${userName}`、`${fiscalYear}`）

**含まれないもの：**

* エージェントのペルソナまたはアイデンティティ（［権限］を使用）

## ［権限］と［説明］の違い

|              | 権限                      | 説明                   |
| ------------ | ----------------------- | -------------------- |
| **定義内容**     | このエージェントはどのような人か。       | このエージェントはどのように動作するか。 |
| **対象範囲**     | アイデンティティと専門分野           | 動作、ルール、ワークフロー        |
| **役割**       | ユーザーメッセージによるペルソナフレームミング | システムレベルの動作ルール        |
| **長さ**       | 1～3文                    | 長文も可能 — 段落またはリスト     |
| **テンプレート変数** | 使用不可                    | 使用可能                 |

## テンプレートを使用する

### ［権限］のテンプレート

```
You are a [job title or domain expert] who specializes in [specific area or domain].
Your primary goal is to help users [accomplish specific outcome].
```

**例：**

```
You are a sales operations analyst who specializes in pipeline health and forecast accuracy.
Your primary goal is to help users understand deal velocity, identify at-risk opportunities, and improve forecast reliability.
```

### ［説明］のテンプレート

```
When a user asks a question:
1. [First step — e.g., identify what data is needed]
2. [Second step — e.g., use the relevant tool to retrieve that data]
3. [Third step — e.g., summarize findings clearly]

Tone and format:
- [Formatting rule, e.g., "Always use bullet points for lists of 3 or more items"]
- [Tone rule, e.g., "Keep responses concise — no more than 3 paragraphs"]

Constraints:
- [Guardrail, e.g., "Only answer questions that can be answered using available CRM data"]
- [Guardrail, e.g., "Never speculate beyond what the data shows — say so if data is insufficient"]
```

**例：**

```
When a user asks about pipeline or forecast data:
1. Use the CRM tool to retrieve relevant deals or metrics.
2. Filter by the user's current quarter unless they specify a different time range.
3. Summarize the findings in plain language, leading with the most important insight.

Tone and format:
- Use bullet points for any list of 3 or more items.
- Lead with a one-sentence headline before providing detail.
- Keep responses under 200 words unless the user requests more detail.

Constraints:
- Only answer questions related to sales pipeline, forecasting, and deal health.
- If data is unavailable or ambiguous, say so explicitly rather than guessing.
- Never reference internal system names or tool IDs in your response.
```

## ベストプラクティスに従う

\*\*［権限］の記述は短くします。\*\*1～3文で十分です。エージェントのアイデンティティがひと目で分かるようになっている必要があります。［権限］フィールド内に説明の段落を記述していることに気づいた場合は、このコンテンツを［説明］に移動します。

**［説明］は実行可能なものにする必要があります。**「役に立つ」などの不明瞭なガイダンスでは、動作が制約されません。「常に回答にデータソースを引用する」などの具体的なルールが有効です。

\*\*ワークフローには番号付きのステップを使用します。\*\*エージェントが一連のアクションを実行する必要がある場合は、番号付きのリストの方が、文章による説明よりもモデルがアクションを実行しやすくなります。

\*\*コンテキスト注入にはテンプレート変数を使用します。\*\*エージェントが現在のユーザー、会計年度、またはその他の実行時の値を知る必要がある場合は、ハードコーディングするのではなく、［説明］でテンプレート変数を使用します。ご利用の環境で使用できる変数については、Domo管理者にお問い合わせください。

**［権限］フィールドと［説明］フィールドは一緒にテストします。**［権限］フィールドと［説明］フィールドは相互に影響し合います。具体的すぎる［権限］と過度に広範な［説明］を組み合わせると、矛盾した動作になる可能性があります。エッジケース（特に、エージェントの意図した対象範囲に近くはあるが、対象範囲外である質問）をテストして、ガードレールが期待どおりに機能することを確認します。

\*\*アイデンティティは手順から分離します。\*\*よくある間違いは、エージェントの設定全体を1つのフィールドに記述することです。アイデンティティと手順を分離することで、エージェントのチューニングが容易になります。つまり、口調またはワークフローのステップを調整するのに、ペルソナを書き換える必要がなくなります。逆も同様です。

## よくある間違いを避ける

| 間違い             | 問題になる原因                                                            | 解決策                                        |
| --------------- | ------------------------------------------------------------------ | ------------------------------------------ |
| ［権限］内に手順を記述する   | 手順は、ユーザーのメッセージごとに補強されます。これにより、前置きが冗長になったり繰り返されたりする可能性があります         | 手順を詳細に記述する内容は［説明］に移動する                     |
| ［説明］を空白にする      | 動作ルールがない場合、エージェントはデフォルトで汎用的な動作を取りますが、この動作はユーザーのユースケースに合わない可能性があります | 少なくとも口調、フォーマット、および1つまたは2つの制約を追加する          |
| あいまいな制約を使用する    | 「プロフェッショナルに」や「役に立つ」などの言葉を使用しても、モデルの動作に実質的な変化はありません                 | 具体的でテスト可能なルールを使用する：「詳細を求められない限り、3文以下で回答する」 |
| ［説明］内に［権限］を複製する | コンテンツを冗長にすると、エージェントのメンテナンスが難しくなり、1つのコピーが更新された場合に矛盾が生じる可能性があります     | 必ず［権限］にはアイデンティティのみを設定し、［説明］には動作のみを設定する     |
| ガードレールをスキップする   | 対象範囲に含まないものを設定する制約がなければ、ユーザーはエージェントを意図しない領域に導く可能性があります             | エージェントが回答すべきことと回答すべきではないことを設定する明示的な制約を追加する |