|
目標 |
自分自身に問いかけてみてください、「私はどんな成果を目指しているのか？」避けるべき問い: 「どんなツールが必要か？」、「どのコネクタを呼び出すべきか？」、「どんなトピックを作成すべきか？」
エージェントが存在する理由、達成すべきこと、ターゲットが誰かを明確に説明してください。 結果に焦点を当てます。 エージェントの設計は問題に基づいて行いましょう。
明確化:- 問題または価値のギャップ
- ターゲット ユーザー
- 期待される効果
- 成功のイメージ
Jobs-To-Be-Done 形式を使用する:
-
<ユーザー>として
-
私は<作業を終わらせる必要がある>
-
これが<結果です>
|
- 新入社員として、自信を持って入社手続きを進めるためには、現地のHRポリシーを理解しておく必要があります。
- IT サポートマネージャーとして、手動によるトリアージの負担を軽減するため、サポートメールを自動的に処理する必要があります。
|
- 結果ではなく、機能から始める。
- エッジケースも考慮して設計する。
- 測定可能な成功基準を省略すること。
|
|
トリガー |
エージェント トリガーとは、エージェントがその作業やタスクを開始するよう促す、特定のイベント、条件、または入力のことです。 人間の行動や自動イベントがトリガーのきっかけとなります。
詳細については、 イベントに合ったトリガーを見つけるを参照してください。 |
- チャット内のユーザーメッセージ。
- 共有受信箱への新着メール
- システム内の新規レコード
- スケジュールされたジョブまたは定期ジョブ。
|
- 自律エージェントには明示的なトリガーが必要です。 それがなければ、エージェントは実行されません。
- トリガーが予測できないユーザーの行動に依存する場合、たとえばユーザーが特定のキーワードやフレーズを入力することに依存している場合など。
- トリガーに必要なコンテキストが欠けている例として、エージェントが開始しても、十分なメタデータ (レコードID、ユーザー識別情報) がなく、効果的に動作できない場合があります。
- トリガーがシナリオの必要以上に頻繁に発動し、無駄な実行やリソース消費を招きます。
- トリガーの設計では、プラットフォームの割り当てや制限が考慮されていないため、エージェントが使用量のしきい値に達したり、負荷がかかった際に動作しなくなったりする場合があります。
|
|
ツールと統合 |
エージェントが「何を知っているか」だけでなく、「どのような行動をとれる必要があるか」を定義してください。
ツールを使用することで、エージェントはデータの取得や更新、API の呼び出し、ワークフローの起動、メッセージの送信、トランザクション処理の完了を行うことができます。 エージェントが依存するシステムとその制約 (API、認証モデル、レート制限、および所有権/SLAの境界) を一覧にしてください。
期待される出力、成功および品質基準、フォールバック、エラー時の挙動について検討してください。 依存関係は実現可能性に大きく影響するため、早期に対応することが重要です。
章氏については、エージェントへのツール追加の仕組みを参照してください。 |
- ServiceNow コネクタ → チケット詳細の取得
- Microsoft Entra ID コネクタ → ユーザーの位置情報を取得
- Jira API → 作業項目の更新
- Outlook コネクタ → メールに返信する
|
- 監査のために操作を記録したり、出力を保存したりしていない。
- API が安定しており、常に利用可能であることを前提とする。
- ツールへの過剰な権限付与。
- ツールの呼び出しにおけるフォールバック動作を定義していない (ツール出力の検証なし、ツールが失敗した際のフォールバックなし、エスカレーション手順なし)。
- レート制限やスロットリングを無視する。
- 依存関係のマッピングが欠落している (各 API の管理責任者は誰か、サービス レベル アグリーメントの内容は何か)。
- アクションを実行する前に前提条件を検証しない。
|
|
チャネル |
チャネルとは、エージェントが展開され、ユーザーとやり取りを行う特定のプラットフォームまたはインターフェースのことです。
また、このチャネルは、遅延、発言の順番、エクスペリエンスなどに関するユーザーの期待にも影響を与えます。 |
- Microsoft Teams
- SharePoint
- Microsoft 365 Copilot
- Web チャットや音声インターフェース
|
- ユーザーが実際にどのように、どこで作業をしているかではなく、展開の利便性や簡便さを基準にチャネルを選択すること。
- ユーザーがエージェントのチャネルに合わせてくれると想定し、実際の利用環境に合わせないこと。
- 技術的な実現可能性をユーザー体験より優先した結果、エージェントが正しく動作していても採用率が低くなる。
- 実際のコミュニケーションチャネルがメールやワークフロー主導であるにもかかわらず、「チャット優先」の設計を行うこと (サポートが実際には Outlook を通じて行われているにもかかわらず、会話型の UX を構築しようとする、メールは対話型ではなく、ターン制であることを忘れてしまう)
- チャネル固有の制約を無視する (Outlook は完全な応答を要求し、確認のための質問は受け付けない、Teams はアダプティブ カードに対応しているが、メールは非対応)
|
|
知識とデータ |
エージェントが推論に必要な情報と、その知識やデータが現在利用可能な場所を記録しましょう。 データの品質や最新性、構造化・非構造化コンテンツ、アクセス権限の境界を考慮してください。
データ準備は、早期に対処しなければ、後期段階のエラーの最も一般的な原因の一つです。 |
- ドキュメント
- データベース
- Web サイト
- サポート情報
- 内部システムまたは外部システム
|
- データガバナンスの不備や一貫性の欠如。 所有権、更新頻度、更新プロセスが定義されていないと、データはすぐに古くなったり、矛盾が生じたりします。
- 「文書」と「知識」を混同している。大規模なドキュメントリポジトリを「真実の源」として挙げているが、それらのドキュメントが最新であるか、適切に構成されているか、一貫したラベル付けがなされているかといった点を考慮していない。
- サポート情報ソースによって内容が食い違っている。 ポリシー、手続き、データセットの複数のバージョンがエージェントに矛盾する指示を送ることになります。
- 権限やアクセス制御が明示的に設計されていない 機密情報が意図せず漏洩したり、エージェントがユーザーがアクセスできない情報を参照したりすることがある。
- セキュリティ境界の検証を行わずにサポート情報ソースを拡大すると、エージェントが情報を過剰に共有したり、アクセスが制限された際に機能しなくなったりする結果となります。
|
|
フローとオーケストレーション |
エージェント全体における作業の構成と順序付けを定義します。つまり、いつ決定論的なフローやトピックを使用すべきか、いつオーケストレーションに依存すべきか、そしていつ人間の関与が必要になるかを明確にします。 目標は予測可能な行動、安全な自動化、明確なエスカレーションです。
フローとトピックの使用:- 複数手順によるデータ収集
- ガイド付きトラブルシューティングや決定木
- コンプライアンス遵守または方針に基づくプロセス
- 重大なまたは取り消しできない行動
トピックは決定論的ロジックの主な仕組みです。
定義:- エージェントが自律的に実行できること
- 人による承認、レビュー、またはオーバーライドが求められる事項
- エージェントがエスカレーションまたは保留しなければならないタイミング
- 人間のフィードバックが改善プロセスに反映される仕組み
|
- 幅広い質問に対応するエージェント: 決定論的なフローは最小限に抑えられており、主にオーケストレーションと生成的推論に依存している。
- 自律型エージェント: 重要な手順において、シーケンス、検証、ガードレールを強制するために、フローやトピックを活用します。
- 承認ワークフロー: エージェントはコンテキストと推奨事項を準備し、人間が影響の大きい行動を承認または却下します。
|
- フローを過度に構造化すると、柔軟性が損なわれ、エージェントに硬直感や脆さを感じさせます。
- 構造化が不十分であるため、業務の流れが乱れ、信頼性が低下し、結果が予測不能になります。
- 決定論的論理においてトピックを明示的に使用していないため、その場しのぎ的な動作や一貫性のない動作が生じます。
- 人間とエージェントの責任が曖昧になり、エスカレーションの経路が不明瞭になります。
- 低リスクな行動に対して人間に過剰な承認を依頼することで、ボトルネックが生じ、エージェントの活用が妨げられます。
- エージェントが、特にエッジケースや高リスクの状況で、明確な「行動しない」境界線を持たずに行動してしまう。
|
|
指示と行動 |
指示では次のように定義します:- エージェントのロールと責任
- 推論および応答の方法
- いつ、どのように知識、ツール、または他のエージェントを使用すべきか
- 従うべき一連の行動
- トーン、境界、安全規則
明確な指示が知識、ツール、フローを一貫性のある予測可能なシステムに統合します。
詳細については、生成オーケストレーションのための高品質な指示を構成するおよび宣言型エージェントのための効果的な指示を作成するを参照してください。 |
- ロールと業務範囲: 「ITメールサポートエージェントとして、受信メールを確認し、チケット番号を抽出し、ServiceNow から確認済みの情報を基に返信を行うロールを担います。」
- 手順付きの行動: 「手順1: ナレッジベースで既存のポリシーや既知の問題があるか確認する。」 手順 2: 情報が見つからない、または不完全な場合は、ServiceNow ツールを呼び出してチケットの詳細を取得します。 手順 3: 必要なデータが依然として不足している場合は、『わかりません』パターンの応答を行い、エスカレーションしてください。
- ツール使用ルール: 「抽出した ID は必ずツールを呼び出して検証し、応答に使用すること。」
- 失敗処理: 「知識が不足している場合やツールコールが失敗した場合は、推測しないでください。 明確な制限と次の手順で応答してください。」
|
- 指示が曖昧です。 たとえば、「ユーザーのサポート課題を支援する」などの指示では、ドメイン、境界、許可された操作が明確に定義されていません。
- 知識、ツール、その他のエージェントをいつそれぞれ使用すべきか明確ではなく、その結果、一貫性を欠く、あるいは非効率的な行動につながっている。
- 指示には一連の行動の順序が定義されていないため、エージェントは知識とツールの出力を予測不可能な形で混在してしまいます。
- ツールの使用ルールが明確に定義されていないと、ツールが無駄に呼び出されたり、逆に全く使われなかったり、知識とツールの出力が想定外に混在することがあります。
- 「常に確認質問をする」や「最終回答のみを返す」といった相反する指示。
- 機密データの変更、内部識別子の共有、確認済み情報源なしでの法的または人事的な助言の提供など、明確な禁止事項の指示がありません。
|
|
エージェントのアーキテクチャと構成 |
次のような場合には、複数のエージェントを使用してください:
- ドメインが大規模または明確に分かれている場合
- 所有はチームごとに異なります
- アクセスや許可はさまざまです
- 専門的な推論が必要です
委譲を行うことで、モジュール性、明瞭性、長期的な保守性が向上します。
詳細については、マルチエージェントオーケストレーション パターンを確認するを参照してください。 |
- メインエージェントは、チケットの検索を IT エージェントに委任します。
- ナレッジ エージェントは文書の品質保証を担当します。
- ルーティングエージェントは、どの専門エージェントを呼び出すかを決定します。
|
- 過度な委任 (エージェントの数が多すぎる)、たとえば、些細なタスクごとに個別のエージェントを作成することなどは、アーキテクチャの肥大化を招き、エージェントの保守、デバッグ、セキュリティ対策、更新を困難にします。
- 権限委譲 (単一の巨大エージェント) —たとえば、人事関連の質問への回答、IT チケットの照会、トラブルシューティングの対応、発注書やインシデントの作成までを 1 つのエージェントに期待する場合—は、保守不可能な巨大で脆弱なエージェントを生み出す可能性があります。
- 委任の境界が定義されていません。 たとえば、メインエージェントがいつ処理を引き継ぐべきかわからない場合や、子エージェントがどのような入力を期待すべきかわからない場合、あるいは責任範囲が重複している場合 (2 つのエージェントがともにITチケットを検索しているなど) が挙げられます。
|
|
ガバナンスとリスク管理 |
エージェントがライフサイクル全体を通じて、責任ある、安全かつ予測可能な動作を行うよう、そのガバナンス、セキュリティ対策、監視の方法を定義します。
この定義には、アクセス制御、アクションの許可、安全対策、説明責任、および運用開始当初から運用上のリスクと AI 関連のリスクの両方を管理するための継続的な監視が含まれます。
詳細については、ガバナンス要件の把握および責任ある AI 原則の適用を参照してください。 |
- 認証とアクセスモデル: エージェントはユーザーレベルの ID を使用して、ユーザーが閲覧を許可されたデータのみを取得します。一方、システムレベルの ID は、明確に定義されたサービス操作に限定されます。
- アクションの権限とガードレール: エージェントは作業ノートの更新や応答の下書きはできますが、承認がない限り、チケットのクローズや外部への通信などの不可逆的な操作は行えません。
- 安全性とコンテンツ保護：機密情報や規制対象となる情報は検知され、プラットフォームの保護機能 (データ漏洩防止や安全フィルターなど) によって、その共有や利用がブロックされます。
- ログ記録、監査、トレーサビリティ: すべてのエージェントのアクション、ツールへの呼び出し、拒否、およびエスカレーションはログに記録され、コンプライアンスやレビューに向けた監査に対応します。
- 運用上の責任体制: エージェントには、責任者、スポンサー、運用管理者として明確に定められた担当者がおり、権限や動作については定期的に見直されます。
|
- ガバナンスやリスク管理策の策定が遅れ、その結果、展開が阻害されたり、運用環境への移行が遅れたりすることになります。
- 「利便性のために」エージェントに過剰権限を与えることで、データの漏洩や意図しない行動のリスクを高めます。
- 権限が不十分なエージェントは、必要なシステムやデータにアクセスできず、実行時にエラーを引き起こします。
- 責任ある AI に関する懸念を、ガバナンスの中核となる意思決定に反映させていない。
- 責任の所在が不明確である、監視計画がない、インシデント対応のプロセスが定義されていないなど、運用ガバナンスが不十分であること。
- 展開後のエージェントの挙動を監視せず、ガードレールだけで十分と考えること。
|
|
評価と最適化 |
実際の状況をシミュレートするテストを定義し、エージェントの回答の正確性、適切性、品質を測定してください。 期待される応答を提示し、エージェントの応答があなたの応答や最も標準的な応答とどのように対応付けられるかを示します。
パフォーマンスの測定と改善方法を計画しましょう。
- 正確性と関連性
- 時間の節約や効率化
- 導入と利用
- 満足度や信頼性の指標
- 引用の質
- 権限遵守
- 誤情報の検出
- 確認質問の挙動
収集する利用統計情報を定義する:
- ツールの呼び出し
- エージェント アクション
- 失敗と再試行
- ユーザー フィードバック
評価は設計の一部として扱い、後付けにしないこと。 詳細については、エージェント評価の設計と運用化を参照してください。 |
- チケット検索が、古いステータスではなく正しいステータスを返すことを確認してください。
- 引用先リンクが最新かつ承認済みのコンテンツを指していることを検証してください。
- 担当者が他人のチケットの詳細提供を拒否していることを検証してください。
- エージェントが架空のチケット番号やサポート情報を生成していないかを検証してください。
- 自律型エージェントが 1 日に処理したメールの件数と、手動による対応手段ではなくこのエージェントを選択したユーザーの割合を測定します。
|
- 展開後、評価の遅れ。
- ベースラインやベンチマークはありません。
- 実シナリオに紐付いていない評価。
- 回帰の検出なし。
- マルチターン評価なし。
- ツール使用の品質を評価する評価者もいない。
- 「正常経路」のみをチェックしています。
- テレメトリのギャップ。
|
