宣言型エージェントの効果的な命令を記述する

宣言型エージェントは、Microsoft 365 Copilot のカスタマイズされたバージョンであり、特定の指示、アクション、知識を宣言することで、パーソナライズされたエクスペリエンスを作成するのに役立ちます。 宣言型エージェントの効果的な手順を作成するには、次の質問を検討してください。

• エージェントはどのような目標を達成する必要がありますか?
• エンド ユーザーが通過するワークフローを想定していますか?
  • 組み込みたいビジネス ロジックはありますか?
  • 必要なエンド ユーザー エクスペリエンスを組み込む必要がありますか?
• ワークフローごとに、エージェントに詳細な手順を提供できますか?

宣言型エージェントにもアクションとして API プラグインがある場合、プラグインの OpenAPI ドキュメントは、エージェントが API を参照する指示を理解するのに役立ちます。 詳細については、「 Copilot の拡張で OpenAPI ドキュメントを効果的に作成する方法」を参照してください。

このガイダンスは、Microsoft 365 Copilot または Microsoft 365 Agents Toolkit のエージェント ビルダーを使用して宣言型エージェントを作成する開発者および作成者に適用されます。 Copilot Studio エージェントの指示を記述する方法の詳細については、「生成オーケストレーションの高品質な命令を構成する」を参照してください。

命令コンポーネント

適切に構造化された一連の命令により、エージェントはその役割、実行する必要があるタスク、およびユーザーと対話する方法を確実に理解できます。 宣言型エージェント命令の主なコンポーネントは次のとおりです。

• 用途
• 一般的な指示、トーン、制限事項を含む一般的なガイドライン
• スキル

関連する場合は、手順に次のコンポーネントも含めます。

• 詳しい手順
• エラー処理と制限事項
• フィードバックと反復
• 相互作用の例
• 非標準用語
• フォローアップとクロージング

次の図は、宣言型エージェント命令の主な構成要素を示しています。

エージェント命令のベスト プラクティス

わかりやすくわかりやすい言葉を使う

• 避けるべきことではなく、Copilot がすべきことに集中します。
• "ask"、"search"、"send"、"チェック"、"use" など、正確で具体的な動詞を使用します。
• あいまいさを最小限に抑えるために、例を挙げて補足します。
• 指示書で、非標準または organization 固有の用語を定義します。

トランジションを使用してステップ バイ ステップ ワークフローを構築する

ワークフローをモジュール式で明確で競合のない手順に分割します。 各ステップには次のものを含める必要があります。

• 目的: ステップの目的。
• アクション: エージェントが行う必要があることと使用するツール。
• 移行: 次のステップに進むか、ワークフローを終了するための条件を明確にします。

厳密な構造を使用する

構造体は、意図を解釈するために使用される最も強力なシグナルの 1 つです。

• セクションを使用して、シーケンスを暗示せずに、関連するタスクを論理カテゴリにグループ化します。
• 独立して完了できる並列タスクには 箇条書きを使用します 。 意図しない順序につながる可能性のある段落番号付けは避けます。
• 必要な順序で実行する必要があるアクションには ステップ を使用し、実際のワークフローに対してのみ予約します。

タスクをアトミックにする

マルチアクション命令を明確に区切られた単位に分割します。 このアプローチにより、あいまいさが軽減され、モデルがタスクをマージまたは再解釈するのを防ぎます。

• 代わり: メトリックを抽出し、結果を要約します。
• 個別の手順を使用します。
  1. メトリックの抽出。
  2. 結果を要約します。

トーン、詳細度、および出力形式を常に指定する

トーンと詳細レベルを指定しない場合、言語モデルがこれらの属性を推測する可能性があり、モデル間で一貫した動作が発生する可能性があります。 たとえば、次のように指定します。

• トーン: プロフェッショナルで簡潔。
• 出力: セクションごとに 3 つの箇条書き。
• 要求された形式のみを返します。説明はありません。

Markdown の構造体命令

手順の順序を強調し明確にするには、 Markdown を使用します。

• セクション ヘッダーには #、 ##、 ### を使用します。
• 順序指定されていないリストには - を使用し、番号付きリストには 1. を使用します。 手順の順序が重要でない限り、記号付きリストを使用します。その場合は番号付きリストを使用します。
• バッククォート (''''') を使用して、ツール名またはシステム名 ( Jira、 ServiceNow、 Teams など) を強調表示します。
• ** を使用して重要な指示を太字にします。

明確な見出しと一貫したリスト構造は、モデルが意図した階層を理解するのに役立ちます。 意図しない解釈をもたらす可能性のある方法でリストの種類を混在させないでください。

ドメイン語彙を提供する

特殊な用語、数式、頭字語、データセット固有の言語を定義します。 この定義により、誤った推論が防止され、一貫した解釈が保証されます。

能力、知識、アクションを明示的に参照する

各ステップに関連するアクション、機能、またはナレッジ ソースの名前を明確に呼び出します。

• アクション: たとえば、「チケットの取得に Jira を使用してください」などです。
• Copilot コネクタの知識: たとえば、"ヘルプ記事に ServiceNow KB を使用する" などです。
• SharePoint の知識: たとえば、「SharePoint または OneDrive の内部ドキュメントを参照する」などです。
• Email messages: たとえば、「ユーザーのメールで関連情報を確認してください」などです。
• Teams メッセージ: たとえば、「Teams のチャット履歴を検索する」などです。
• コード インタープリター: 例: "コード インタープリターを使用して棒グラフまたは円グラフを生成する"
• People knowledge: たとえば、「People knowledge を使用してユーザーの電子メールを取得する」。

構成されたナレッジ ソースに対するグラウンディング応答

言語モデルには、トレーニング データからの知識が組み込まれています。 多くのエージェント シナリオでは、モデルの内部知識ではなく、構成したナレッジ ソースのみにエージェントが依存するようにする必要があります。 このアプローチにより、応答の正確性、一貫性、および組織データの追跡可能性が保証されます。

モデルが組み込みの知識を利用できないようにするには、エージェント マニフェストの special_instructions オブジェクトで discourage_model_knowledge プロパティを true に設定することをお勧めします。 有効にすると、エージェントはモデルナレッジからの応答の生成を避けるために最善を尽くし、代わりに構成されたナレッジソースに依存します。 詳細については、「 特殊命令オブジェクト」を参照してください。

例を提供する

例は、エージェントが指示を理解するのに役立ちます。

• 単純なシナリオの場合は、例を挙げる必要はありません。
• 複雑なシナリオの場合、宣言型エージェントは少数のプロンプトで最も効果的に機能します。 つまり、さまざまな側面やエッジ ケースを説明するために、複数の例を挙げます。

言い回しによって推論を制御する

文言は、モデルに適用する推論の量を示します。

深い推論

奥行きを増やすには:

• 明示的な推論動詞 (分析、導出、評価、正当化) を使用します。
• メタ推論の手がかりを追加します (ステップ バイ ステップで考え、振り返り、ロジックを検証します)。
• タスクを複数の依存ステップに構造化します。

Use deep reasoning. Break the problem into steps, analyze each step, evaluate alternatives, and justify the final decision. Reflect before answering.
Task: Determine the optimal 3-year migration strategy given constraints A, B, and C.

ディープ推論が選択されたタイミングを検出するには:

Before answering, report in one sentence whether you needed deep reasoning or minimal reasoning to solve this. Then provide the final answer only.

中程度の推論 (バランス)

推論のバランスを取るには:

• 簡潔だが構造化された説明を求めます。
• 明確な制約を提供しますが、メタ推論の手がかりは提供しません。

Provide a concise but structured explanation. Include a short summary, 3 key drivers, and a final recommendation. No step-by-step reasoning required.
Task: Explain the tradeoffs between solution X and Y.

迅速で最小限の推論

深度を減らすには:

• シグナルの簡潔さ。 短く、高速な応答を指定します。理由や説明はありません。
• 分析動詞や多ステップ構造は避けてください。
• 単一意図、単相の命令型言い回しを使用します。

Short answer only. No reasoning or explanation. Provide the final result only.
Task: Extract the product name and renewal date from this paragraph.

一般的なプロンプト エラーを回避する

一般的な障害を回避するために、次の落とし穴とその解決策に注意してください。

• 過度に熱心にツールを使用する
  • 問題: モデルは必要な入力なしでツールを呼び出します。
  • 解決方法: 命令「必要な入力が利用可能な場合にのみツールを呼び出します。それ以外の場合は、ユーザーに確認してください。"
• 繰り返される言い回し
  • 問題: このモデルでは、例のフレージングが逐語的に再利用されます。
  • 解決策: 多様な応答と自然言語を奨励します。 1 つだけでなく、複数の例を追加することを検討してください (少数ショット プロンプト)。 トークンを節約するために例を削除してみます。
• 詳細な説明
  • 問題: モデルが過剰に説明するか、過剰な書式設定を提供します。
  • 解決方法: 冗長さや書式設定を制限するために、制約と簡潔な例を追加します。

自己評価の最終ステップを追加する

セルフチェックステップは完全性を強化し、エージェントが応答する前にあなたの指示と一致していることを確認するようにします。 例: 最終決定を行う前に、セクション A のすべての項目がサマリーに表示されていることを確認します。

必要に応じて安定化ヘッダーを適用する

エージェントが推論のドリフトまたはステップの順序変更の兆候を示したら、命令を文字通り解釈し推論を避けるようにモデルに指示する短いヘッダーを追加します。 詳細については、「 パターン 8: 即時の安定性のためにリテラル実行ヘッダーを適用する」を参照してください。

指示を繰り返します

宣言型エージェントの命令の開発は、多くの場合、反復プロセスです。 通常は、次の手順で構成されます。

1. この記事で説明する構造と形式に従って、エージェントの指示と会話スターターを作成します。
2. エージェントを発行します。 責任ある AI (RAI) プラクティスは検証プロセスに統合され、エージェントが倫理基準を遵守するようにします。 詳細については、以下を参照してください:
   • RAI 検証
   • RAI ツールとプラクティス
   • 人工知能を利用したアプリ
3. エージェントをテストします。
   1. エージェントが応答時に付加価値をもたらすことを確認するには、結果を Microsoft 365 Copilot と比較します。
   2. ステップ バイ ステップ のガイダンスに従って、会話のスターターが期待どおりに機能することを確認します。
   3. エージェントが提供された指示に従って動作することを確認します。
   4. 会話の開始点以外のユーザー プロンプトが適切に処理されていることを確認します。
4. 指示を繰り返して、出力をさらに改善できるかどうかを調べます。
   • 指示を変更してエージェントの動作を変更する。
   • 必要に応じて、エージェント ツールキットまたは Copilot Studio を使用して、Web 検索、OneDrive/SharePoint、または Microsoft 365 Copilot コネクタなどの知識を追加してみてください。

次の図は、宣言型エージェント命令を作成および改良するための反復プロセスを示しています。

手順の例

以下の手順例は、一般的な IT の問題の解決に役立つエージェント向けのものです。

# OBJECTIVE
Guide users through issue resolution by gathering information, checking outages, narrowing down solutions, and creating tickets if needed. Ensure the interaction is focused, friendly, and efficient.

# RESPONSE RULES
- Ask one clarifying question at a time, only when needed.
- Present information as concise bullet points or tables.
- Avoid overwhelming users with details or options.
- Always confirm before moving to the next step or ending.
- Use tools only if data is sufficient; otherwise, ask for missing info.

# WORKFLOW

## Step 1: Gather Basic Details
- **Goal:** Identify the user's issue.
- **Action:**
  - Proceed if the description is clear.
  - If unclear, ask a single, focused clarifying question.
    - Example:
      User: "Issue accessing a portal."
      Assistant: "Which portal?"
- **Transition:** Once clear, proceed to Step 2.

## Step 2: Check for Ongoing Outages
- **Goal:** Rule out known outages.
- **Action:**
  - Query `ServiceNow` for current outages.
  - If an outage is found:
    - Share details and ETA.
    - Ask: "Is your issue unrelated? If yes, I can help further."
    - If yes, go to Step 3. If no/no response, end politely.
  - If none, inform the user and go to Step 3.

## Step 3: Narrow Down Resolution
- **Goal:** Find best-fit solutions from the knowledge base.
- **Action:**
  - Search `ServiceNow KB` for related articles.
  - **Iterative narrowing:** Don't list all results. Instead:
    - Ask clarifying questions based on article differences.
    - Eliminate irrelevant options with user responses.
    - Repeat until the best solution is found.
  - Provide step-by-step fix instructions.
  - Confirm: "Did this help? If not, I can go deeper or create a ticket."
    - If more info is provided, repeat this step.
    - If ticket needed, go to Step 4.
    - If resolved/no response, end politely.

## Step 4: Create Support Ticket
- **Goal:** Log unresolved issues.
- **Action:**
  1. Map **category** and **subcategory** from the `sys_choice` SharePoint file.
     - Use only valid pairs. Leave blank if not clear.
  2. Fetch user's UPN (email) with the people capability.
  3. Fill the ticket with:
     - Caller ID (email)
     - Category, Subcategory (if mapped)
     - Description, attempted steps, error codes, metadata
- **Transition:** Confirm ticket creation and next steps.

# OUTPUT FORMATTING RULES
- Use bullets for actions, lists, next steps.
- Use tables for structured data where UI allows.
- Avoid long paragraphs; keep responses skimmable.
- Always confirm before ending or submitting tickets.

# EXAMPLES

## Valid Example
**User:** "I can't connect to VPN."
**Assistant:**
- "Are you seeing a specific error?"
  (User: "DNS server not responding.")
- "Let me check for outages."
  (No outage.)
- "No outages. Searching knowledge base…"
  (Finds articles. Asks: "Are you on office Wi-Fi or home?")
  (User: "Home.")
- "Try resetting your DNS settings. Here's how…"
- "Did this help? If not, I can create a support ticket."

## Invalid Example
- "Here are 15 articles I found…" *(Overwhelms the user)*
- "I'm raising a ticket" *(without confirming details)*

命令テンプレートと設計パターン

このセクションでは、宣言型エージェントの手順に追加できるパターンとテンプレートについて説明します。 この例は規範的なものではありません。 それらを出発点として使用し、ユース ケースの要件に適合させます。

パターン 1: あいまいなマルチタスク要求を確定的なワークフローに変換する

このパターンを使用すると、アトミック ステップ、明示的な数式、および必要な検証を定義することであいまいさを取り除くことができます。 この方法により、モデル バージョン間で安定した再現性のある動作が保証されます。

## Task: Metrics and ROI (Deterministic)

### Definitions (Do not invent)
- Metrics to compute: [Metric1], [Metric2], [Metric3]
- ROI definition: ROI = (Benefit - Cost) / Cost
- ROI scope: [e.g., 12 months, Product X only, Region Y]
- Source of truth: Use ONLY the provided document(s) for inputs

### Steps (Sequential — do not reorder)
Step 1: Locate inputs for [Metric1-3] in the document. Quote the section/table name where each input came from.
Step 2: Compute [Metric1-3] exactly as defined above. If any input is missing, stop and ask ONE question listing what's missing.
Step 3: Compute ROI using the ROI definition above. Do not substitute other ROI formulas.
Step 4: Output ONLY the table in the format below.

### Output format
Return a single Markdown table with columns: Metric | Value | Source (section/table) | Notes

### Final check (Self-evaluation)
Before finalizing: confirm every metric has (a) a value, (b) a source, and (c) no assumptions. If assumptions exist, stop and ask the user.

パターン 2: 並列構造と順次構造の正しい

このパターンを使用することで、モデルで並列ロジックと順次ロジックが分離されるようになります。 このモデルは、ステップを追加または並べ替えることなくワークフローを正しく実行します。

Section A — Extract Data
- Extract pricing changes.
- Extract margin changes.
- Extract sentiment themes.

Section B — Build the Summary
Step 1: Integrate all findings from Section A.
Step 2: Produce the 2 page call prep summary.

パターン 3: 明示的な決定ルール

このパターンを使用すると、意図しないモデル解釈を防止し、決定論的な結果を強制する明示的な if/then ルールを追加できます。 このアプローチにより、言語モデルがあいまいな条件付き論理を自分で解決しようとするのを防ぎます。その結果、ブランチが混在したり ("両方を行う") したり、間違った条件パスが選択されたりする可能性があります。

Read the product report.
Check category performance.
If performance is stable or improving, write the summary section.
If performance declines or anomalies are detected, write the risks/issues section.

パターン 4: 出力コントラクト

出力コントラクトは、形状、構造、トーン、許可されたコンテンツを提供し、一貫性を確保します。 明示的な出力制約がないと、エージェントが過度に長い説明を生成したり、回答が過度に簡潔になったり、バージョン間で予期せず切り替わったりする可能性があります。

優れた精度:

Produce a 2-page call-prep briefing:
Page 1 → key metrics: revenue, margin, YoY deltas (calculate as needed).
Page 2 → top themes, risks, opportunities, customer signals.
Tone: Professional. Reasoning: none unless calculation required.

出力コントラクト:

## Output Contract (Mandatory)
Goal: [one sentence]
Format: [bullet list | table | 2 pages | JSON]
Detail level: [short | medium | detailed] — do not exceed [X] bullets per section
Tone: [Professional | Friendly | Efficient]
Include: [A, B, C]
Exclude: No extra recommendations, no extra context, no “helpful tips”
Example shape:
- Section 1: ...
- Section 2: ...

出力が従う必要がある場合は、このパターンを使用します。

• 正確な形式 (箇条書き、表、JSON、複数ページの要約)。
• 指定した詳細レベル (短、中、詳細)。
• コンプライアンス、監査、または顧客向けテンプレート。
• チーム全体で一貫した書式設定を必要とするビジネス プロセス。

パターン 5: マークダウン構造をクリーンにする

クリーンで意図的な Markdown により、モデルが命令を確実に解析できます。 入れ子が不十分なリスト、不明瞭なヘッダー、または一貫性のない書式設定は、ステップの結合、意図しない階層、またはセクションの折りたたみの原因になります。

## Section A — Extract Data
- Extract pricing changes.
- Extract margin changes.
- Extract sentiment themes.

## Section B — Build the Summary (Sequential)
**Step 1:** Integrate findings from Section A.
**Step 2:** Produce the 2 page call prep summary.

パターン 6: 自己評価ゲート

明示的なセルフチェック手順を追加することで、モデルが完全性を検証し、指示との整合性を確認し、応答する前に省略を修正するように促すことができます。 この手順により、一貫性と信頼性が向上します。

## Section A: Extract Data (Non-Sequential)
Perform these tasks when the user requests data extraction from the document:
- Extract pricing changes.
- Extract margin changes.
- Extract sentiment themes.
Use the **Vocabulary Reference** SharePoint document to interpret acronyms, domain specific terms, and company specific vocabulary.

## Section B: Build the Summary (Sequential)
Perform these steps **in order** when the user requests a call prep summary:
Step 1: Integrate all extracted elements from Section A.
Step 2: Produce a clear, well structured 2 page call prep summary.

## Final Check: Self Evaluation
Before finalizing the output, review your response for completeness, ensure that all Section A elements are accurately represented, check for inconsistencies or uncertainty, and revise the answer if needed.

パターン 7: ステアリング オートモードの推論

明示的な推論の手がかりにより、モデルの考え方をどの程度適用するかを制御できます。 このガイダンスがなければ、エージェントは簡単な回答を過剰に説明したり、複雑な決定を過小に説明したりする可能性があります。

ディープ推論をトリガー:

Use deep reasoning. Break the problem into steps, analyze each step, evaluate alternatives, and justify the final decision. Reflect before answering.
Task: Determine the optimal 3-year migration strategy given constraints A, B, and C.

高速で最小限の推論を強制する:

Short answer only. No reasoning or explanation. Provide the final result only.
Task: Extract the product name and renewal date from this paragraph.

ワークフローで次の必要がある場合は、このパターンを使用します。

• より深い推論 (計画、代替案の評価、マルチステップ ロジック)。
• 最小限の説明で迅速な検索または抽出。
• 高レベルの要約とより詳細な分析を切り替える。
• 複数のエージェントまたはユースケースにわたって一貫した深さ。

パターン 8: 即時の安定性を得るためにリテラル実行ヘッダーを適用する

リテラル実行ヘッダーは、既存のエージェントを一時的に安定させるのに役立ちます。 このパターンは、全命令セットを更新するときの暫定的な修正プログラムとして特に役立ちます。

Always interpret instructions literally.
Never infer intent or fill in missing steps.
Never add context, recommendations, or assumptions.
Follow step order exactly with no optimization.
Respond concisely and only in the requested format.
Do not call tools unless a step explicitly instructs you to do so.

このパターンは、次の場合に使用します。

• エージェントの応答に並べ替え、ステップの追加、または過度の推論が観察されます。
• より深い構造改善を適用する前に、迅速な短期的な緩和策が必要です。
• 推論または命令のあいまいさが問題の原因であるかどうかを診断する必要があります。

パターン 9: 既存の宣言型エージェント命令を評価する

構造化された評価プロンプトを使用して、既存のエージェントを迅速に監査し、特定の弱点を特定し、正確な修正プログラムを生成します。

You are reviewing Data Access (DA) agent instructions for stability.

INPUT
<instructions>
[PASTE CURRENT INSTRUCTIONS]
</instructions>

TASK
Concise audit. Identify ONLY issues and exact fixes.

CHECKS
- Step order: identify ambiguity, missing steps, or merged steps → propose atomic, numbered steps.
- Tool use: identify auto-calls, retries, or tool switching → add "use only in step X; no auto-retry".
- Grounding: detect inference, blending, or citation gaps → add "cite only retrieved; no inference; no cross-document stitching".
- Missing-data handling: if retrieval is empty or conflicting → add "stop and ask the user".
- Verbosity: identify chatty or explanatory output → replace with "return only the requested data/format".
- Contradictions or duplicates: resolve discrepancies; prefer explicit over implied.
- Vague verbs ("verify", "process", "handle", "clean"): replace with precise, observable actions.
- Safety: prohibit step reordering, optimization, or reinterpretation.

OUTPUT (concise)
- Header patch (3–6 lines)
- Top 5 changes (bullet list: "Issue → Fix")
- Example rewrite (≤10 lines) for the riskiest step

このパターンは、次の場合に使用します。

• 動作に一貫性のない既存のエージェントを監査しています。
• 命令セットのどの部分が壊れやすいか、あいまいな部分があるかがわかりません。
• organization全体で複数の宣言型エージェントに対して反復可能な評価プロセスが必要です。
• どの問題が構造的、スタイル的、または安全性に関連するかを簡単に識別する方法が必要です。

関連コンテンツ

• 宣言型エージェント マニフェストの例。
• Copilot Studio を使用してエージェントを作成します。
• エージェントの検証ガイドライン。