エージェント設計フレームワークを活用しましょう

エージェント設計フレームワークは、トリガー、ツール、チャネル、ガバナンス要件などを含むエージェントの目的を定義するための一連の構成要素を提供します。このフレームワークは硬直したテンプレートではなく、チームが意思決定に合意し、リスクを早期に特定し、よくある落とし穴を避けるための思考補助です。

ヒント

この記事は、以下のビデオで扱われた概念に基づいています。チュートリアルとその他のコンテキストについては、「Copilot Studio ビジネスキャンバス - エージェントを設計するためのブループリント」をご覧ください>

エージェント設計の構成要素

以下の構成要素を使って、あなたのエージェントを詳しく説明してください。

ヒント

編集可能なデザインキャンバスをダウンロードして、エージェントのプロジェクトをマッピングしましょう。

トリガー、チャネル、データ、ツール、フロー、指示、アーキテクチャ、ガバナンス、評価のセクションを示すエージェント設計キャンバスのスクリーンショット。

各セクションは議論と整合を支援し、厳格なドキュメントではありません。

カテゴリ	Description	例	よくある落とし穴
ゴール	自分に問いかけてみてください。「私はどんな結果を目指しているのか?「どのツールが必要か?」「どのコネクターを呼べばいいか?」「どのトピックを作ればいいか?」という問題ではありません。エージェントが存在するべき理由、何を達成すべきか、ターゲットとなる対象が誰かを明確に説明してください。結果に集中しましょう。エージェントの設計は問題から導かれます。明確にする: 問題または価値ギャップターゲットユーザー予想される影響成功の様子ジョブからBe-Done までの形式を使う: としての<ユーザー> そうしなきゃいけないんだ<やるべき仕事> それで<結果>	新入社員として、自信を持ってオンボーディングを進めるために、地元の人事ポリシーを理解する必要があります。 ITサポートマネージャーの方が、手動のトリアージを減らすためにサポートメールを自動的に処理する必要があります。	結果ではなく特徴から始めましょう。エッジケースを考慮した設計を行う。測定可能な成功基準を飛ばすこと。
トリガー	エージェントトリガーとは、エージェントに作業やタスクを開始するための特定のイベント、条件、または入力のことです。人間の行動や自動化されたイベントがトリガーを発生させることがあります。詳しくはこちら: イベントに合ったトリガーを見つけましょう。	チャット内のユーザーメッセージ。共有受信箱に新しいメールが届きました。システムでの新記録。予定された仕事や定期的な仕事。	自律エージェントには明示的なトリガーが必要です。それらがなければ、エージェントは逃げません。トリガーは予測不能なユーザーの行動に依存し、例えばユーザーが特定のキーワードやフレーズを入力することに依存します。トリガーに必要なコンテキストが欠けている。例えば、エージェントは起動するが、メタデータ(レコードID、ユーザーID)が十分でないため効果的に動作できない。トリガーはシナリオが必要とするよりも頻繁に発動し、不要な実行やリソース消費を引き起こします。トリガー設計はプラットフォームのノルマや制限を考慮しておらず、エージェントが使用閾値に達したり負荷で失敗したりします。
ツールと統合	エージェントが知っていることだけでなく、実行すべき行動を定義してください。ツールはエージェントがデータの取得や更新、API呼び出し、ワークフローのトリガー、メッセージ送信、トランザクション操作の完了を可能にします。エージェントが依存するシステムとその制限(API、認証モデル、レート制限、所有権/SLA境界)をリストアップしてください。期待される成果、成功と品質の基準、フォールバック、エラー挙動を考慮しましょう。依存関係はしばしば実現可能性を左右します—早めに対処しましょう。詳細はこちら: エージェントにツールを追加する仕組み。	ServiceNowコネクター→チケット詳細を取得できます Microsoft Entra ID コネクタ→ユーザーの場所を取得する Jira API→作業項目を更新します Outlook コネクタ→電子メールに返信する	アクションのログや監査用の出力保存を行わないことです。 APIが安定していて常に利用可能であることを前提に。過剰な権限を持つツール。ツールコールのフォールバック動作を定義しない(ツール出力の検証なし、ツール故障時のフォールバックなし、エスカレーション経路なし)。レート制限やスロットリングを無視する。依存関係マッピング(各APIの所有者、サービスレベルアグリートが何か)が欠けています。アクションを実行する前に前提条件を検証しない。
Channels	チャネルとは、エージェントが展開され、ユーザーとやり取りする特定のプラットフォームやインターフェースのことです。また、チャネルは遅延、ターンテイキング、体験に関するユーザーの期待にも影響を与えます。	Microsoft Teams SharePoint Microsoft 365 Copilot Web Chatまたは音声インターフェイス	ユーザーが実際にどのように、どこで作業しているかではなく、利便性や展開の単純さに基づいてチャネルを選ぶこと。ユーザーがすでにいる場所で会うのではなく、ユーザーがエージェントのチャネルに適応すると仮定して。技術的な実現可能性をユーザー体験より優先し、エージェントが正しく動作しても採用率が低い結果です。 "実際のチャネルが電子メール駆動型またはワークフロー駆動型の場合の 'チャット優先' の設計 (サポートが実際にOutlook経由で行われる場合の会話型ユーザーエクスペリエンスの構築。メールのやり取りは会話型ではなくターンベースです)" チャネル固有の制約を無視する (例えば、Outlook は質問を明確にするのではなく、完全な応答が必要であり、Teams はアダプティブカードをサポートしていますが、メールはサポートしていません。)
知識とデータ	エージェントが検討すべき情報と、その知識やデータが現在利用可能な場所を記録しましょう。データの品質や新鮮さ、構造化コンテンツと非構造化コンテンツ、アクセスや権限の境界を考慮してください。データ準備は、早期に対処しなければ、後期段階の阻害要因の一般的な原因の一つです。	ドキュメント Databases Web サイトナレッジベース内部または外部システム	データガバナンスの不備または一貫性がありません。所有権、更新の頻度、更新プロセスが定義されていないと、データはすぐに古くなったり矛盾したりします。「文書」と「知識」を混同している。大規模な文書リポジトリを真実の情報源として挙げるだけで、それらの文書が最新かどうか、よく構成されているか、一貫してラベル付けされているかを考慮していません。知識源は互いに矛盾しています。ポリシー、手続き、データセットの複数のバージョンがエージェントに矛盾する指示を送ることになります。権限やアクセス制御は明示的に設計されていません。機密性の高いコンテンツが意図せず漏洩したり、エージェントがエンドユーザーがアクセスできない知識を参照したりします。セキュリティ境界を検証せずに知識ソースを拡大し、アクセス制限時にエージェントが過剰に共有したり失敗したりする結果を招きます。
フローとオーケストレーション	エージェント全体で作業がどのように構造化され、順序づけられているかを定義します。決定論的なフローやトピックをいつ使用するか、オーケストレーションに頼る場合、人間の関与が必要かを。目標は予測可能な行動、安全な自動化、そして明確なエスカレーションです。フローやトピックの使用タイミング: 多段階データ収集ガイド付きトラブルシューティングや意思決定ツリーコンプライアンスまたはポリシー駆動のプロセス高衝撃または不可逆的な作用トピックは決定論的論理の主要なメカニズムです。定義: エージェントが自律的にできること人間の承認、レビュー、またはオーバーライドが必要なものエージェントがエスカレーションまたは延期しなければならない場合人間のフィードバックが改善に逆戻りする仕組み	Ask-Me-Anything エージェント:最小限の決定論的フロー;主にオーケストレーションと生成的推論に依存しています。自律エージェント:フローやトピックを用いて、重要なステップのシーケンス、検証、ガードレールを強制します。承認ワークフロー:エージェントはコンテキストと推奨事項を準備します。人間は高影響の行動を承認または上書きします。	フローを過剰に構築し、柔軟性を制限し、エージェントを硬くもろく感じさせます。フローの構造化が不十分で信頼性が低下し、結果が予測不能になること。決定論的論理のためにトピックを明示的に使わないため、場当たり的または一貫性のない挙動を招くことはありません。人間とエージェントの責任が曖昧になり、エスカレーションの経路が不明瞭になる。低リスクの行動に対する承認を過剰に負担させ、ボトルネックを生み、薬剤の使用を抑制しています。特にエッジや高リスクの状況で、明確な「行動禁止」の境界線を持たずに行動するエージェント。
指示と行動	指示書の定義は以下の通りです: 代理人の役割と責任その論理と応答の方法いつ、どのように知識やツール、その他の要素を使うべきかその行動の順序についてトーン、境界線、安全ルール明確な指示が知識、ツール、流れを一貫性のある予測可能なシステムに結びつけます。詳細はこちら: 生成オーケストレーション用の高品質命令を構成し、宣言的エージェント向けの効果的な命令を書く。	役割と範囲:「あなたはITメールサポートエージェントで、受信メールボックスのメッセージを読み、チケット番号を抽出し、ServiceNowから検証済みの情報を返信する責任者です。」シーケンスされた行動:「ステップ1:既存のポリシーや既知の問題がないかナレッジベースを確認してください。ステップ2:情報が見つからなかったり不完全であれば、ServiceNowツールに連絡してチケットの詳細を取得してください。ステップ3:必要なデータがまだ不足している場合は、『わかりません』というパターンで対応し、エスカレーションしてください。」ツール使用ルール:「抽出したIDは必ずツールコールで検証し、応答で使用すること。」失敗処理:「知識が欠けていたり、ツールコールが失敗した場合は、推測しないでください。明確な制限と次のステップを提示して応答してください。」	説明が曖昧すぎます。例えば「サポートの問題を抱えるユーザーを助ける」にはドメイン、境界、許可された操作が明記されていません。知識を使うべきか、ツールを使うべきか、他のエージェントを使うべきかの明確さがなく、一貫性のない、あるいは非効率的な行動を招いています。命令は行動の順序を定義せず、エージェントは知識とツールの出力を予測不能な形で混同します。ツール使用ルールが明示的に定義されていないため、ツールが不要に呼ばれたり、そもそも呼ばなかったり、知識とツールの出力が予期せぬ形で混同されることがあります。「必ず確認の質問をする」や「最終的な答えのみで返答する」といった相反する指示。機密データの改変、内部識別子の共有、法的・人事的助言を検証された情報源なしに行うことなど、明確な「やってはいけない」ガイダンスはありません。
エージェントのアーキテクチャと構成	複数のエージェントを使った場合: ドメインは大きいものもあれば、明確に区別されるものもありますオーナーシップはチームごとに異なりますアクセスや許可はさまざまです専門的な推論が必要です委任はモジュール性、明瞭さ、長期的な保守性を向上させます。詳しくはこちら: マルチエージェントのオーケストレーションパターンを探る。	メインエージェントはチケット検索をITエージェントに委任します。ナレッジエージェントは文書のQAを担当します。ルーティングエージェントは、どの専門エージェントに連絡するかを決定します。	オーバーデロール(エージェント数が多すぎる)—例えば、小さなタスクごとに別々のエージェントを作成する—はアーキテクチャのスプロールを招き、エージェントの保守、デバッグ、保護、更新を困難にします。例えば、単一のエージェントが人事の質問に答えたり、ITチケットを調べたり、トラブルシューティングを行ったり、発注書やインシデントを作成したりすることを期待されると、巨大で脆弱なため維持不可能なエージェントになりかねません。委任の境界が定義されていません。例えば、メインエージェントがいつ引き継ぐべきか分からなかったり、子エージェントがどの入力を期待すべきか分からなかったり、責任が重複したり(2人のエージェントがITチケットを調べるなど)場合などです。
ガバナンスとリスク管理	エージェントがどのように管理され、安全に、監視されているかを定義し、ライフサイクル全体を通じて責任を持って安全かつ予測可能な行動を取ることを保証します。この定義には、アクセス制御、アクション権限、安全ガードレール、責任追及、運用およびAI関連リスクを初日から管理するための継続的な監督が含まれます。詳細はこちら: ガバナンス要件の捉えと責任あるAI原則の適用。	認証およびアクセスモデル:エージェントはユーザーが閲覧許可されたデータのみを取得するためにユーザーレベルのアイデンティティを使用し、システムレベルのアイデンティティは明確に定義されたサービス操作に限定されます。アクション権限とガードレール:エージェントは作業ノートや下書きのレスポンスを更新できますが、承認なしに不可逆的な操作(チケットのクローズや外部通信の送信など)を行うことはできません。安全性およびコンテンツ保護:機密情報や規制対象の情報は、プラットフォーム保護(例:データ損失防止や安全フィルター)を用いて検出され、共有や対応をブロックされます。ログ、監査、トレーサビリティ:すべてのエージェントの操作、ツール呼び出し、拒否、エスカレーションは記録され、コンプライアンスとレビューのために監査対象となります。運営所有権:エージェントには明確な所有者、スポンサー、運営管理者がおり、許可や行動は定期的に見直されます。	ガバナンスやリスク管理の設計が遅れ、導入のブロックや本番の遅延につながること。「利便性のために」エージェントに過剰権限を与え、データの漏洩や意図しない行動のリスクを高めます。権限不足のエージェントが、必要なシステムやデータにアクセスできないランタイムで障害を引き起こします。責任あるAIの懸念をコアガバナンスの意思決定に統合しないことです。明確な所有者がいない、監視計画がないこと、インシデント対応のための明確なプロセスがないなど、弱い運営ガバナンス。ガードレールだけで十分だと仮定した場合、展開後のエージェントの挙動を監視しないこと。
評価と最適化	エージェントの回答の正確性、関連性、質を測るために、実際のシナリオをシミュレートするテストを定義しましょう。期待される回答を示し、エージェントの回答があなたの回答や最も標準的な回答とどのように対応しているかを示します。パフォーマンスの測定と改善方法を計画する: 正確性と関連性節約時間や効率化採用と利用満足と信頼のシグナル引用の質許可の順守誤情報の検出質問を明確にする行動どのテレメトリを収集するかを定義します: ツール呼び出しエージェントアクション失敗と再挑戦ユーザーフィードバック評価は設計の一部として扱い、後回しにしないでください。詳細はこちら: エージェント評価の設計と運用化。	チケット検索が正しいステータスを返してくるか確認してください。古い状態ではありません。引用リンクが現在承認されているコンテンツであることを確認しましょう。担当者が他人のチケットの詳細提供を拒否していることを確認しましょう。エージェントがチケット番号やKB記事をでっち上げたかどうかを検証してください。自律型エージェントが1日に処理するメール数と、手動チャネルではなくエージェントを選ぶユーザーの割合を測定してください。	展開後、評価の遅れ。基準やベンチマークはありません。実際の状況に結びつかない評価。回帰検出もできません。複数ターンにわたる評価もありません。ツール使用の品質を評価する評価者もいません。「幸せな道」だけをチェックしています。テレメトリーデータの欠落。

重要なポイント

構造化されたデザインフレームワークは、チームが問題を理性で解決し、より良い意思決定を行うのを助ける思考の補助として機能します。

特徴ではなく成果から始めましょう。
ガバナンスやデータの落とし穴を避けましょう。
より安全で信頼できるエージェントを作ろう。
規模、信頼、長期的な持続可能性を重視した設計。

設計を省略することで早期学習を加速できますが、構造化された設計は実験を持続的で信頼できる解決策に変えます。

次のステップ

構造化デザインフレームワークの適用例を振り返りましょう。

例:構造化設計フレームワークを自律型メールサポートエージェントに適用する

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-02-24

カテゴリ	Description	例	よくある落とし穴
ゴール	自分に問いかけてみてください。「私はどんな結果を目指しているのか?「どのツールが必要か?」「どのコネクターを呼べばいいか?」「どのトピックを作ればいいか?」という問題ではありません。エージェントが存在するべき理由、何を達成すべきか、ターゲットとなる対象が誰かを明確に説明してください。結果に集中しましょう。エージェントの設計は問題から導かれます。明確にする: 問題または価値ギャップターゲットユーザー予想される影響成功の様子ジョブからBe-Done までの形式を使う: としての<ユーザー> そうしなきゃいけないんだ<やるべき仕事> それで<結果>	新入社員として、自信を持ってオンボーディングを進めるために、地元の人事ポリシーを理解する必要があります。 ITサポートマネージャーの方が、手動のトリアージを減らすためにサポートメールを自動的に処理する必要があります。	結果ではなく特徴から始めましょう。エッジケースを考慮した設計を行う。測定可能な成功基準を飛ばすこと。
トリガー	エージェントトリガーとは、エージェントに作業やタスクを開始するための特定のイベント、条件、または入力のことです。人間の行動や自動化されたイベントがトリガーを発生させることがあります。詳しくはこちら: イベントに合ったトリガーを見つけましょう。	チャット内のユーザーメッセージ。共有受信箱に新しいメールが届きました。システムでの新記録。予定された仕事や定期的な仕事。	自律エージェントには明示的なトリガーが必要です。それらがなければ、エージェントは逃げません。トリガーは予測不能なユーザーの行動に依存し、例えばユーザーが特定のキーワードやフレーズを入力することに依存します。トリガーに必要なコンテキストが欠けている。例えば、エージェントは起動するが、メタデータ(レコードID、ユーザーID)が十分でないため効果的に動作できない。トリガーはシナリオが必要とするよりも頻繁に発動し、不要な実行やリソース消費を引き起こします。トリガー設計はプラットフォームのノルマや制限を考慮しておらず、エージェントが使用閾値に達したり負荷で失敗したりします。
ツールと統合	エージェントが知っていることだけでなく、実行すべき行動を定義してください。ツールはエージェントがデータの取得や更新、API呼び出し、ワークフローのトリガー、メッセージ送信、トランザクション操作の完了を可能にします。エージェントが依存するシステムとその制限(API、認証モデル、レート制限、所有権/SLA境界)をリストアップしてください。期待される成果、成功と品質の基準、フォールバック、エラー挙動を考慮しましょう。依存関係はしばしば実現可能性を左右します—早めに対処しましょう。詳細はこちら: エージェントにツールを追加する仕組み。	ServiceNowコネクター→チケット詳細を取得できます Microsoft Entra ID コネクタ→ユーザーの場所を取得する Jira API→作業項目を更新します Outlook コネクタ→電子メールに返信する	アクションのログや監査用の出力保存を行わないことです。 APIが安定していて常に利用可能であることを前提に。過剰な権限を持つツール。ツールコールのフォールバック動作を定義しない(ツール出力の検証なし、ツール故障時のフォールバックなし、エスカレーション経路なし)。レート制限やスロットリングを無視する。依存関係マッピング(各APIの所有者、サービスレベルアグリートが何か)が欠けています。アクションを実行する前に前提条件を検証しない。
Channels	チャネルとは、エージェントが展開され、ユーザーとやり取りする特定のプラットフォームやインターフェースのことです。また、チャネルは遅延、ターンテイキング、体験に関するユーザーの期待にも影響を与えます。	Microsoft Teams SharePoint Microsoft 365 Copilot Web Chatまたは音声インターフェイス	ユーザーが実際にどのように、どこで作業しているかではなく、利便性や展開の単純さに基づいてチャネルを選ぶこと。ユーザーがすでにいる場所で会うのではなく、ユーザーがエージェントのチャネルに適応すると仮定して。技術的な実現可能性をユーザー体験より優先し、エージェントが正しく動作しても採用率が低い結果です。 "実際のチャネルが電子メール駆動型またはワークフロー駆動型の場合の 'チャット優先' の設計 (サポートが実際にOutlook経由で行われる場合の会話型ユーザーエクスペリエンスの構築。メールのやり取りは会話型ではなくターンベースです)" チャネル固有の制約を無視する (例えば、Outlook は質問を明確にするのではなく、完全な応答が必要であり、Teams はアダプティブカードをサポートしていますが、メールはサポートしていません。)
知識とデータ	エージェントが検討すべき情報と、その知識やデータが現在利用可能な場所を記録しましょう。データの品質や新鮮さ、構造化コンテンツと非構造化コンテンツ、アクセスや権限の境界を考慮してください。データ準備は、早期に対処しなければ、後期段階の阻害要因の一般的な原因の一つです。	ドキュメント Databases Web サイトナレッジベース内部または外部システム	データガバナンスの不備または一貫性がありません。所有権、更新の頻度、更新プロセスが定義されていないと、データはすぐに古くなったり矛盾したりします。「文書」と「知識」を混同している。大規模な文書リポジトリを真実の情報源として挙げるだけで、それらの文書が最新かどうか、よく構成されているか、一貫してラベル付けされているかを考慮していません。知識源は互いに矛盾しています。ポリシー、手続き、データセットの複数のバージョンがエージェントに矛盾する指示を送ることになります。権限やアクセス制御は明示的に設計されていません。機密性の高いコンテンツが意図せず漏洩したり、エージェントがエンドユーザーがアクセスできない知識を参照したりします。セキュリティ境界を検証せずに知識ソースを拡大し、アクセス制限時にエージェントが過剰に共有したり失敗したりする結果を招きます。
フローとオーケストレーション	エージェント全体で作業がどのように構造化され、順序づけられているかを定義します。決定論的なフローやトピックをいつ使用するか、オーケストレーションに頼る場合、人間の関与が必要かを。目標は予測可能な行動、安全な自動化、そして明確なエスカレーションです。フローやトピックの使用タイミング: 多段階データ収集ガイド付きトラブルシューティングや意思決定ツリーコンプライアンスまたはポリシー駆動のプロセス高衝撃または不可逆的な作用トピックは決定論的論理の主要なメカニズムです。定義: エージェントが自律的にできること人間の承認、レビュー、またはオーバーライドが必要なものエージェントがエスカレーションまたは延期しなければならない場合人間のフィードバックが改善に逆戻りする仕組み	Ask-Me-Anything エージェント:最小限の決定論的フロー;主にオーケストレーションと生成的推論に依存しています。自律エージェント:フローやトピックを用いて、重要なステップのシーケンス、検証、ガードレールを強制します。承認ワークフロー:エージェントはコンテキストと推奨事項を準備します。人間は高影響の行動を承認または上書きします。	フローを過剰に構築し、柔軟性を制限し、エージェントを硬くもろく感じさせます。フローの構造化が不十分で信頼性が低下し、結果が予測不能になること。決定論的論理のためにトピックを明示的に使わないため、場当たり的または一貫性のない挙動を招くことはありません。人間とエージェントの責任が曖昧になり、エスカレーションの経路が不明瞭になる。低リスクの行動に対する承認を過剰に負担させ、ボトルネックを生み、薬剤の使用を抑制しています。特にエッジや高リスクの状況で、明確な「行動禁止」の境界線を持たずに行動するエージェント。
指示と行動	指示書の定義は以下の通りです: 代理人の役割と責任その論理と応答の方法いつ、どのように知識やツール、その他の要素を使うべきかその行動の順序についてトーン、境界線、安全ルール明確な指示が知識、ツール、流れを一貫性のある予測可能なシステムに結びつけます。詳細はこちら: 生成オーケストレーション用の高品質命令を構成し、宣言的エージェント向けの効果的な命令を書く。	役割と範囲:「あなたはITメールサポートエージェントで、受信メールボックスのメッセージを読み、チケット番号を抽出し、ServiceNowから検証済みの情報を返信する責任者です。」シーケンスされた行動:「ステップ1:既存のポリシーや既知の問題がないかナレッジベースを確認してください。ステップ2:情報が見つからなかったり不完全であれば、ServiceNowツールに連絡してチケットの詳細を取得してください。ステップ3:必要なデータがまだ不足している場合は、『わかりません』というパターンで対応し、エスカレーションしてください。」ツール使用ルール:「抽出したIDは必ずツールコールで検証し、応答で使用すること。」失敗処理:「知識が欠けていたり、ツールコールが失敗した場合は、推測しないでください。明確な制限と次のステップを提示して応答してください。」	説明が曖昧すぎます。例えば「サポートの問題を抱えるユーザーを助ける」にはドメイン、境界、許可された操作が明記されていません。知識を使うべきか、ツールを使うべきか、他のエージェントを使うべきかの明確さがなく、一貫性のない、あるいは非効率的な行動を招いています。命令は行動の順序を定義せず、エージェントは知識とツールの出力を予測不能な形で混同します。ツール使用ルールが明示的に定義されていないため、ツールが不要に呼ばれたり、そもそも呼ばなかったり、知識とツールの出力が予期せぬ形で混同されることがあります。「必ず確認の質問をする」や「最終的な答えのみで返答する」といった相反する指示。機密データの改変、内部識別子の共有、法的・人事的助言を検証された情報源なしに行うことなど、明確な「やってはいけない」ガイダンスはありません。
エージェントのアーキテクチャと構成	複数のエージェントを使った場合: ドメインは大きいものもあれば、明確に区別されるものもありますオーナーシップはチームごとに異なりますアクセスや許可はさまざまです専門的な推論が必要です委任はモジュール性、明瞭さ、長期的な保守性を向上させます。詳しくはこちら: マルチエージェントのオーケストレーションパターンを探る。	メインエージェントはチケット検索をITエージェントに委任します。ナレッジエージェントは文書のQAを担当します。ルーティングエージェントは、どの専門エージェントに連絡するかを決定します。	オーバーデロール(エージェント数が多すぎる)—例えば、小さなタスクごとに別々のエージェントを作成する—はアーキテクチャのスプロールを招き、エージェントの保守、デバッグ、保護、更新を困難にします。例えば、単一のエージェントが人事の質問に答えたり、ITチケットを調べたり、トラブルシューティングを行ったり、発注書やインシデントを作成したりすることを期待されると、巨大で脆弱なため維持不可能なエージェントになりかねません。委任の境界が定義されていません。例えば、メインエージェントがいつ引き継ぐべきか分からなかったり、子エージェントがどの入力を期待すべきか分からなかったり、責任が重複したり(2人のエージェントがITチケットを調べるなど)場合などです。
ガバナンスとリスク管理	エージェントがどのように管理され、安全に、監視されているかを定義し、ライフサイクル全体を通じて責任を持って安全かつ予測可能な行動を取ることを保証します。この定義には、アクセス制御、アクション権限、安全ガードレール、責任追及、運用およびAI関連リスクを初日から管理するための継続的な監督が含まれます。詳細はこちら: ガバナンス要件の捉えと責任あるAI原則の適用。	認証およびアクセスモデル:エージェントはユーザーが閲覧許可されたデータのみを取得するためにユーザーレベルのアイデンティティを使用し、システムレベルのアイデンティティは明確に定義されたサービス操作に限定されます。アクション権限とガードレール:エージェントは作業ノートや下書きのレスポンスを更新できますが、承認なしに不可逆的な操作(チケットのクローズや外部通信の送信など)を行うことはできません。安全性およびコンテンツ保護:機密情報や規制対象の情報は、プラットフォーム保護(例:データ損失防止や安全フィルター)を用いて検出され、共有や対応をブロックされます。ログ、監査、トレーサビリティ:すべてのエージェントの操作、ツール呼び出し、拒否、エスカレーションは記録され、コンプライアンスとレビューのために監査対象となります。運営所有権:エージェントには明確な所有者、スポンサー、運営管理者がおり、許可や行動は定期的に見直されます。	ガバナンスやリスク管理の設計が遅れ、導入のブロックや本番の遅延につながること。「利便性のために」エージェントに過剰権限を与え、データの漏洩や意図しない行動のリスクを高めます。権限不足のエージェントが、必要なシステムやデータにアクセスできないランタイムで障害を引き起こします。責任あるAIの懸念をコアガバナンスの意思決定に統合しないことです。明確な所有者がいない、監視計画がないこと、インシデント対応のための明確なプロセスがないなど、弱い運営ガバナンス。ガードレールだけで十分だと仮定した場合、展開後のエージェントの挙動を監視しないこと。
評価と最適化	エージェントの回答の正確性、関連性、質を測るために、実際のシナリオをシミュレートするテストを定義しましょう。期待される回答を示し、エージェントの回答があなたの回答や最も標準的な回答とどのように対応しているかを示します。パフォーマンスの測定と改善方法を計画する: 正確性と関連性節約時間や効率化採用と利用満足と信頼のシグナル引用の質許可の順守誤情報の検出質問を明確にする行動どのテレメトリを収集するかを定義します: ツール呼び出しエージェントアクション失敗と再挑戦ユーザーフィードバック評価は設計の一部として扱い、後回しにしないでください。詳細はこちら: エージェント評価の設計と運用化。	チケット検索が正しいステータスを返してくるか確認してください。古い状態ではありません。引用リンクが現在承認されているコンテンツであることを確認しましょう。担当者が他人のチケットの詳細提供を拒否していることを確認しましょう。エージェントがチケット番号やKB記事をでっち上げたかどうかを検証してください。自律型エージェントが1日に処理するメール数と、手動チャネルではなくエージェントを選ぶユーザーの割合を測定してください。	展開後、評価の遅れ。基準やベンチマークはありません。実際の状況に結びつかない評価。回帰検出もできません。複数ターンにわたる評価もありません。ツール使用の品質を評価する評価者もいません。「幸せな道」だけをチェックしています。テレメトリーデータの欠落。