次の方法で共有


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

この例は、完全な構造化設計フレームワークを実際のシナリオに適用する方法を示しています。

問題:ITサポートの受信箱がメールで溢れかえっています。 ITサポート担当者が手動で各メッセージを読み、チケット番号を解析し、ServiceNowを調べ、ナレッジベースを検索し、返信します。 このプロセスは遅く、繰り返し、ミスが多いです。

望む結果:サポートメールを数秒で処理すること。 手作業を減らし、対応時間を短縮し、従業員体験を向上させます。

カテゴリ 説明の例
ゴール なぜこのエージェントが存在するのか? どんな問題を解決しているのでしょうか? 誰がそのエージェントを使うのか?
  • ITサポート用受信トレイのメールの手動トリアージを減らす。
  • 意図、チケット番号、必要な行動を自動的に検出します。
  • 人の介入なしに正確な回答を提供しましょう。
  • 応答時間を改善し、バックログを減らす。
ジョブズトゥビー・ダン フレーミング:
  • ITサポートエージェント
  • 受信メールを自動的に処理する必要があります
  • したがって 繰り返しのトリアージではなく、複雑な問題に集中できます
成功基準:
  • メールは人間の関与なしにエンドツーエンドで処理されていました。
  • 正確なチケット検索。
  • 高品質なメールの返信。
  • 手動トリアージ時間を大幅に短縮。
トリガー 新しいメールがITサポートの共有メールボックスに届きます。

データに関する考慮事項:
  • メールには機密情報が含まれている場合があります。
  • データ抽出は非構造化フォーマットに対して堅牢でなければなりません。
  • システムトークンはServiceNowへの読み書きアクセス権を持っています。
ツールと統合 エージェントが実際に行うこと:
  • 受信メールを解析し、意図を特定します。
  • チケット番号(存在する場合)を抽出または推定します。
  • ServiceNowからチケットの状況や関連情報を取得します。
  • 質問の答えを求めてナレッジベースを検索します。
  • 完全で文脈に応じた返信を作成・送信します。
  • 必要に応じてチケットを作成または更新します。
Systems: ServiceNow (重大な依存関係)、ナレッジ ベース (SharePointなど)、Outlook、Graph API
要件:システムトークン認証、APIレート制限および再試行、システム間の信頼性の高い接続
チーム間の依存関係:ServiceNow管理チーム、ITサポート運用、ナレッジベースの所有者
Channels エスカレーション用のTeams通知と監査・監視用の管理ダッシュボード。
知識とデータ エージェントが依存する情報を詳しく述べてください:
  • トラブルシューティングのための人事やITの知識ベースコンテンツ。
  • チケット履歴で返答をパーソナライズできます。
  • カテゴリマッピング(ハードウェア、ソフトウェア、パスワードリセット、ネットワーク問題)。
  • 意図分類のルール。
  • チケット抽出のパターン(#12345、INC12345など)。
品質の期待値:
  • ナレッジベースは定期的に見直す必要があります。
  • 知識には最新の保険契約が含まれていなければなりません。
  • 古くなったり使われていないトラブルシューティングの流れは避けましょう。
フローとオーケストレーション 人間の責任:
  • エージェントが意図を分類できない場合はエスカレーションに対応しましょう。
  • 高リスクの行動(例:チケット閉鎖)を承認またはレビューします。
  • ナレッジベースの内容を更新して、エージェントの回答が正確に保たれます。
  • 監査ログと業績を監視しましょう。
エージェントの責任:
  • 定型問い合わせに答えましょう。
  • チケットの状況を確認してください。
  • 検証済みの知識源を用いた返信の草案。
  • メールが曖昧な場合は、明確な質問を提案してください。
決定論的要素:
  • チケット番号検出。
  • チケットが見つかりません」というフォールバックフロー。
  • カテゴリごとに明示的なルーティング(パスワードリセット、ハードウェア問題、ソフトウェアリクエスト)。
柔軟な部品:
  • 自然言語理解によるメール解析。
  • KBの内容に基づく返信の生成プロセス。
デザインノート:
  • 返信前に構造化された手順で検索と検証を行いましょう。
  • 人間らしい会話的な表現は避けましょう。 メールは正確でなければなりません。
指示と行動 これらの高レベルの指示は、エージェントの思考と行動の仕方を定義します。
  • 抽出したチケット番号を使う前に必ず検証してください。
  • チケットが見つからない場合は、手続きを進める前に確認の質問をしてください。
  • トラブルシューティングには承認されたKBソースのみを使用してください。
  • 返信は簡潔で事実に基づいていて、プロフェッショナルにしてください。
  • 送り手が依頼者でない限り、チケットの詳細を絶対に開示しないでください。
  • 曖昧な場合は、明確な質問で答えましょう。
  • 監査のためにすべてのアクションを記録してください。
トーンとスタイル:
  • プロフェッショナルで親切です。
  • 会話の無駄なものはなし。
  • メールにふさわしいフォーマット。
エージェントのアーキテクチャと構成 潜在的な子どもエージェント:
  • 記事の検索と抽出を扱うナレッジベース回答エージェント。
  • ServiceNowとのやり取りを処理するチケットエージェント。
  • 意図を分類するための分類エージェント。
利点:
  • 職務の明確な分離。
  • メンテナンスや反復が楽です。
  • 意図しない行動のリスクが低くなります。
ガバナンスとリスク管理 考慮すべきリスク:
  • ユーザー意図の誤分類。
  • 誤ったトラブルシューティング手順で対応しています。
  • 機密性の高いチケットデータを不正利用者に漏らすこと。
  • 過剰な自動化が非準拠の行動につながること。
対応策:
  • ロールベースのアクセス制御を使いましょう。
  • 監査とトレーサビリティのためにすべてのアクションを記録しましょう。
  • 曖昧なメッセージにはフォールバック動作を含めること。
  • 最新で検証済みの知識源を維持しましょう。
  • 人間の承認なしにチケットを変更または終了する権限を制限します。
ガバナンスの考慮事項:
  • 認証:ServiceNowのシステムレベルのトークンを使用し、共有メールボックスへのアクセスに関して組織のポリシーに従います。
  • 承認:エージェントはチケットの読み取り・更新、新規チケットの作成、メールへの返信が許可されています。 エージェントはチケットを閉じたり、機密フィールドを変更したりすることは許されていません。
  • 監査可能性:すべてのアクション(解析→検索→返信)、失敗したアクションのレビューフラグ、安全性とコンプライアンスの検証を目的とした定期的な監査チェック。
評価と最適化 指標:
  • メールの完全自動化率。
  • チケット抽出の正確さ。
  • 平均応答時間と手作業処理の比較。
  • エスカレーションの回数。
  • ユーザー満足度のシグナルです。
  • 幻覚やエラー率。
テレメトリー:
  • エージェントが取る各アクション(解析→検索→応答)。
  • 失敗とフォールバックトリガー。
  • ツールはServiceNowにリクエストを送信します。
  • 生成された返信の内容(QA用)。