この例は、完全な構造化設計フレームワークを実際のシナリオに適用する方法を示しています。
問題: ITサポートの受信箱がメールで溢れています。 ITサポート担当者は、手動で各メッセージを読み、チケット番号を抽出し、ServiceNowを参照し、ナレッジベースを検索し、返信します。 このプロセスは時間がかかり、反復作業が多く、エラーが発生しやすいです。
望ましい結果: サポートメールを従来の数時間ではなく、数秒で処理すること。 手作業を減らし、応答時間を短縮し、従業員体験を向上させます。
| カテゴリ |
説明の例 |
|
目標 |
このエージェントはなぜ存在するのか？ どのような問題を解決していますか？ 誰がエージェントを利用するのか？- ITサポート受信トレイのメールの手動によるトリアージを削減する。
- 意図、チケット番号、必要なアクションを自動的に検出する。
- 人手を介さず正確な回答を提供する。
- 応答時間を短縮し、未処理案件を減らす。
ジョブ理論によるフレーミング:-
IT サポートエージェントとして
- 受信メールを自動的に処理する必要がある
- 繰り返しのトリアージではなく、複雑な問題に集中できるようにするため
成功の条件:- メールは人間の介入なしにエンドツーエンドで処理される。
- 正確なチケット検索。
- 高品質なメールの返信。
- 手動トリアージ時間を大幅に短縮。
|
|
トリガー |
新しいメールがITサポートの共有メールボックスに届きます。
データに関する考慮事項:- 電子メールには機密情報が含まれている場合があります。
- データ抽出は非構造化フォーマットに対して堅牢でなければなりません。
- システムトークンはServiceNowに対して読み書きアクセス権を持つ必要があります。
|
|
ツールと統合 |
エージェントが実際に何をするのか：- 受信メールを解析し、意図を特定します。
- チケット番号（存在する場合）を抽出または推定します。
- ServiceNowからチケットのステータスや関連情報を取得します。
- 質問への回答を求めてナレッジベースを検索します。
- 完全な文脈に応じた返信を作成・送信します。
- 必要に応じてチケットを作成または更新します。
システム: ServiceNow（重要な依存関係）、ナレッジベース（SharePointなど）、Outlook、Graph API
要件: システムトークン認証・APIのレート制限と再試行・システム間の安定した接続
クロスチーム依存関係: ServiceNow管理チーム、ITサポート運用チーム、ナレッジベース所有者 |
|
チャネル |
エスカレーションのためのTeams通知、および監査と監視のための管理ダッシュボード。 |
|
知識とデータ |
エージェントが参照する情報の詳細：
- トラブルシューティング手順に関する人事およびIT関連のナレッジベースコンテンツ。
- チケット履歴に基づいて、よりパーソナライズされた対応が可能になります。
- カテゴリマッピング（ハードウェア、ソフトウェア、パスワードリセット、ネットワークの問題）。
- 意図の分類ルール。
- チケット番号抽出のパターン（#12345、INC12345など）。
品質基準:- ナレッジベースは定期的に見直す必要があります。
- 知識には最新のポリシーが含まれていなければなりません。
- 古くなった、または非推奨のトラブルシューティング手順は避けてください。
|
|
フローとオーケストレーション |
担当者の責任:- エージェントが意図を分類できない場合は、エスカレーションに対応してください。
- 高リスクの操作（例：チケット閉鎖）を承認またはレビューしてください。
- ナレッジベースの内容を更新し、エージェントの回答が常に正確になるようにしてください。
- 監査ログとパフォーマンスを監視します。
エージェントの責任:- 通常の問い合わせに対応する。
- チケットの状況を確認する。
- 検証済みのサポート情報ソースを用いて回答案を作成する。
- メールが曖昧な場合は、明確な質問を提案する。
決定論的コンポーネント:- チケット番号の検出。
- "チケットが見つかりません" のフォールバックフロー。
- カテゴリ（パスワードのリセット、ハードウェアの問題、ソフトウェアのリクエスト）ごとに明示的なルーティングを設定します。
柔軟なコンポーネント:- メールの自然言語理解。
- サポート情報の内容に基づく応答の下書き生成。
設計メモ:- 返信前に体系的な手順で情報の取得と検証を行ってください。
- 会話風の表現は避けること。 メールは正確でなければならない。
|
|
指示と行動 |
これらの高レベルの指示は、エージェントの意思決定と行動プロセスを定義します。
- 抽出したチケット番号を利用する際は、事前に必ず検証してください。
- チケットが見つからない場合は、進める前に内容を明確にする質問をしてください。
- トラブルシューティングの手順には承認されたKBソースのみを使用してください。
- 返信は簡潔かつ事実に基づき、専門的にしてください。
- 送信者が依頼者でない限り、チケットの詳細を開示しないでください。
- 曖昧な場合は、内容を明確にするための質問をしてください。
- 監査目的で全ての処理を記録すること。
トーンとスタイル:- プロフェッショナルで親切。
- 余計な会話や表現は避けること。
- メールに適した書式。
|
|
エージェントのアーキテクチャと構成 |
潜在的な子エージェント:- 記事の検索と抽出を担当するナレッジベース回答エージェント。
- ServiceNowとのやり取りを担当するチケットエージェント。
- 意図を分類するための分類エージェント。
メリット:- 職務の明確な分離。
- メンテナンスや反復が簡単。
- 意図しない行動のリスクが低い。
|
|
ガバナンスとリスク管理 |
考慮すべきリスク:- ユーザー意図の誤分類。
- 誤ったトラブルシューティング手順で対応。
- 機密性の高いチケットデータを未承認ユーザーに漏らすこと。
- 過剰な自動化が非準拠の行動につながる。
軽減策:- ユーザー ロールベースのアクセス制御。
- 監査とトレーサビリティのためにすべてのアクションをログに記録する。
- 曖昧なメッセージにはフォールバック動作を含めること。
- 最新で検証済みのサポート情報ソースの維持。
- 人間の承認なしにチケットを変更またはクローズする権限を制限します。
ガバナンスに関する考慮事項:-
認証: ServiceNowにはシステムレベルのトークンを用い、共有メールボックスへのアクセスには組織のポリシーに従う。
-
オーソリゼーション: エージェントはチケットの閲覧・更新、新規チケットの作成、メールの返信が許可されている。 エージェントはチケットを閉じたり、機密フィールドを変更したりすることは許可されていません。
-
オーディタビリティ：すべてのアクションは記録される（解析→検索→返信）、失敗したアクションはレビュー対象としてフラグされる、安全性とコンプライアンスの検証のために定期的な監査チェックが実施されます。
|
|
評価と最適化 |
メトリックス:
- メールの完全自動化率。
- チケット抽出精度
- 平均応答時間（自動処理 vs 手作業処理）。
- エスカレーションの回数。
- ユーザー満足度のシグナル。
- 幻覚・エラー率。
テレメトリ:
- エージェントが実行する各アクション（パース → ルックアップ → 返信）。
- 失敗とフォールバックのトリガー。
- ツールによるServiceNowへの呼び出し
- 生成された返信の内容（QA用）。
|