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

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

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

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

このガイダンスは、Microsoft 365 Copilotまたは Microsoft 365 Agents Toolkitで Agent Builder を使用して宣言型エージェントを作成する開発者や作成者に適用されます。 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メッセージ: たとえば、"ユーザーの電子メールで関連情報を確認する" などです。
• Teams メッセージ: たとえば、"Teams チャット履歴の検索" です。
• コード インタープリター: たとえば、"コード インタープリターを使用して棒グラフまたは円グラフを生成します。
• Peopleナレッジ: "ユーザーの知識を使用してユーザーの電子メールをフェッチする" など。

例を提供する

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

• 単純なシナリオでは、例を示す必要はありません。
• 複雑なシナリオでは、宣言型エージェントは、少数のプロンプトで最適に動作します。 つまり、さまざまな側面やエッジ ケースを示す複数の例を示します。

言い回しによる推論の制御

この文言は、モデルを適用する理由を示します。

深い推論

奥行きを上げるには:

• 明示的な推論動詞 (分析、派生、評価、正当化) を使用します。
• メタ推論キューを追加します (ステップ バイ ステップで考え、反映し、ロジックを確認します)。
• タスクを複数の依存ステップに構造化します。

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.

この方法は、GPT-5 のルーティング システムに推論トークン認識が含まれているために機能します。

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

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

• 簡潔で構造化された説明を求めます。
• 明確な制約を指定しますが、メタ推論キューは指定しないでください。

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.

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

一般的なエラーを回避するには、次の落とし穴とその解決策に注意してください。

• Overeager ツールの使用
  • 問題: モデルは、必要な入力なしでツールを呼び出します。
  • 解決策: "必要な入力が使用可能な場合にのみツールを呼び出す。それ以外の場合は、ユーザーに問い合わせください。
• 反復的な言い回し
  • 問題: モデルは、言い回しの例を逐語的に再利用します。
  • 解決策: さまざまな応答と自然言語を奨励します。 1 つだけ (少数のプロンプト) ではなく、複数の例を追加することを検討してください。 トークンに保存する例を削除して実験します。
• 詳細な説明
  • 問題: モデルが過剰に説明されているか、過剰な書式設定が提供されます。
  • 解決策: 詳細または書式設定を制限するには、制約と簡潔な例を追加します。

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

自己チェックステップにより、完全性が強化され、エージェントが応答する前に指示との整合性が確認されます。 たとえば、完了する前に、セクション A のすべての項目が概要に表示されることを確認します。

必要に応じて手ブレ補正ヘッダーを適用する

エージェントが推論ドリフトまたはステップの並べ替えの兆候 (特にモデルの更新後) を表示する場合は、命令をリテラルで解釈し、推論を回避するようにモデルに指示する短いヘッダーを追加します。 詳細については、「 宣言型エージェントの GPT 5.1 以降での変更のモデル化」を参照してください。

手順を反復処理する

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

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: 直ちに安定するためにリテラル実行ヘッダーを適用する

リテラル実行ヘッダーは、特にモデルの変更後に、既存のエージェントを一時的に安定させるのに役立ちます。 このパターンは、完全な命令セットを更新するときに中間修正として特に役立ちます。 詳細については、「 宣言型エージェントの GPT 5.1 以降での変更のモデル化」を参照してください。

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.

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

• GPT 5.1 以降にアップグレードした後、並べ替え、追加された手順、または過度の推論が観察されます。
• より深い構造改善を適用する前に、迅速な短期的な軽減策が必要です。
• 推論または命令のあいまいさが問題の原因であるかどうかを診断する必要があります。

パターン 9: 既存の宣言型エージェントの指示を評価して移行する

構造化評価プロンプトを使用して、既存のエージェントをすばやく監査し、特定の弱点を特定し、正確な修正を生成します。

You are reviewing Data Access (DA) agent instructions for 5.1 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

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

• 既存のエージェントを GPT 5.0 から GPT 5.1 以降に移行しています。
• 命令セットのどの部分が脆弱かあいまいか不明です。
• organization全体で複数の宣言型エージェントに対して反復可能な評価プロセスが必要です。
• 構造、スタイル、または安全性に関連する問題を簡単に特定する方法が必要です。

関連コンテンツ

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