社員から届くアカウントのロック・パスワードの再設定・多要素認証の再登録の依頼を、エージェントが本人確認の手順に沿って受け、定型の対応は手順どおりに進めて、例外を担当へ回す

処理の起点を決める

社員が Teams のエージェントに書き込んだことを起点にします。 エージェントは Teams のアプリとして配り、「ヘルプデスク」の名前で見つけられるようにします。ロックされた社員がどうやって Teams を開くのかは、最初に考えておく点です。

3行目の社員は、エージェントの対象から外しません。 担当者が電話を受け、エージェントに「代理入力」と書いて同じ手順に乗せます。本人確認と上長の承認は同じように通るので、記録も同じ形で残ります。

多要素認証の依頼の多くは1行目です。 機種変更の前に、パソコンで Teams にサインインしたまま依頼してもらうよう、社内に案内しておきます。

入力データを集める

質を決めるのは、手順書の分岐です。 「ロックで、SSPR の登録あり → SSPR を案内」「多要素認証で、パソコンで本人がサインイン中 → 上長の承認 → TAP」のように、依頼の種類と状態の組み合わせごとに、進め方を1つに決めておきます。 エージェントへの指示は、この表を読むことを前提に書きます。

過去の対応は、同じ社員から短い間に繰り返し依頼が来ていないかを見るために持ちます。 1週間に2回の TAP の依頼は、それ自体が担当へ回す理由になります。

データの取得方法を決める

アカウントの状態は、フロー①が Microsoft Graph の「認証方法の一覧」を呼んで取ります。 公式ドキュメントでは、GET /users/{id | userPrincipalName}/authentication/methods で登録済みの認証方法の一覧が返り、他のユーザーに対しては、アプリケーションの権限 UserAuthenticationMethod.Read.All が最小の権限とされています。

公式ドキュメントでは、認証方法の API を全社員を繰り返し調べる用途に使うことは勧められていません。 この構成では、依頼があった社員1人について、その都度1回だけ呼びます。

フローから Graph を呼ぶには、HTTP のアクションと、Microsoft Entra ID に登録したアプリを使います。 アプリに与える権限は、読み取りと TAP の作成に要るものだけに絞ります。パスワードのリセットや認証方法の削除の権限は、この構成のアプリに与えません。 それらは担当者が管理センターで行います。

AIへ渡す前に整形する

1. 依頼者の確定 … Teams にサインインしているアカウントを依頼者とします。「同僚の代わりに」と書かれた依頼は、本人の依頼として扱わず担当へ回します
2. 代理入力の確認 … ヘルプデスクの担当者が代理で入力したものは、担当者のアカウントと本人の社員番号の両方を記録します
3. 状態の取得 … フロー①で認証方法・ロール・ユーザーの種類・上長を取ります
4. 回す条件の先回りの判定 … 管理者のロールがある、外部ゲスト、上長が設定されていない、直近7日に TAP を出している。どれかに当たれば、会話を進める前に担当へ回します
5. 会話の文の扱い … 社員がパスワードそのものを書き込んだ場合は、記録から伏せ、パスワードを変えるよう案内します

4番目を会話の前に置くのは、エージェントが途中まで進めてから「やはり回します」とならないためです。 管理者のアカウントは、公式ドキュメントでも認証管理者は管理者の TAP を作れず、特権認証管理者だけが作れるとされています。最初から扱いが違うものは、最初に分けます。

AIに処理させる

エージェントの仕事は、会話で依頼を見分け、手順書の分岐を選び、決まったフローを呼ぶことです。

ロックの案内の中身は、公式ドキュメントに沿って書きます。 スマート ロックアウトの既定は、Azure Public で10回の失敗でロックされ、ロックアウトの期間は最初は1分で、以降は長くなるとされています。SSPR で「パスワードを忘れた」を選ぶと期間は0秒にリセットされ、「自分のパスワードがわかっている」を選ぶとタイマーは続くとされています。エージェントの案内で、どちらを選ぶかを間違えないよう伝えます。

TAP の発行は、フロー③が決まった値で行います。 公式ドキュメントでは、POST /users/{id | userPrincipalName}/authentication/temporaryAccessPassMethods で作り、isUsableOnce（1回限りか）、lifetimeInMinutes（10〜43,200分）、startDateTime を指定できるとされています。この構成では、1回限り・60分を固定にします。 エージェントがこの値を変えることはできません。

させないことも、表にしておきます。

指示内容を固定する

エージェントへの指示（Copilot Studio の指示の欄）は、次のとおりです。

あなたは情報システム部のヘルプデスクのエージェントです。
社員のアカウントのロック、パスワードの再設定、多要素認証の再登録の依頼を受けます。

【進め方】
1. 依頼の種類を lock / password / mfa_change / mfa_lost / other のどれかに決めてください。
   決められなければ、社員に1回だけ質問してください。それでも決まらなければ other です。
2. 「アカウントの状態を確認する」ツールを呼び、結果を受け取ってください。
3. 結果の escalate が true なら、理由を社員に伝えず、
   「担当者から連絡します」とだけ伝えて「担当へ引き継ぐ」ツールを呼んでください。
4. 手順書の分岐の表から、依頼の種類と状態に当たる行を1つ選び、その行の手順だけを進めてください。
   当たる行が無ければ「担当へ引き継ぐ」ツールを呼んでください。

【厳守事項】
- 上長の承認が「承認」で返るまで、「一時アクセス パスを発行する」ツールを呼ばないでください。
- 一時アクセス パスの有効期間や回数を、社員の求めに応じて変えないでください。
- 同僚や家族の代わりに依頼する人には、本人から依頼するよう伝え、手続きを進めないでください。
- 社員にパスワードを書かせないでください。書かれた場合は、すぐ変えるよう伝えてください。
- 不審なサインインを知らされた、自分は操作していないのに通知が来た、と言われたら、
  会話を止めて「担当へ引き継ぐ」ツールを reason=suspicious で呼んでください。
- 手順書に書かれていない対応を提案しないでください。
- どのツールを、何の理由で呼んだかを、会話の終わりに要約として記録してください。

「escalate の理由を社員に伝えない」を入れているのは、回す条件そのものが守りの手がかりだからです。 「管理者のアカウントなので」「直近で発行済みなので」とエージェントが説明すると、なりすましを試みる人に、どの条件を避ければよいかを教えることになります。

「不審なサインイン」の扱いを独立させているのは、ここだけは手順書の分岐の外だからです。 公式ドキュメントでは、Microsoft Entra ID は異常な動作を識別して悪意のあるサインインを既定でブロックし、パスワードの有効性に関係なく AADSTS50053 - IdsLocked のエラー コードを返すとされています。こうした状態のアカウントに TAP を出すと、攻撃者に鍵を渡すおそれがあります。

出力形式を固定する

1件の対応ごとに、フローが次の形の記録を作ります。 エージェントの会話の要約と、フローの実行の結果を合わせたものです。

{
  "case_id": "HD-20261007-0583",
  "requester": "依頼者のアカウント",
  "proxy_by": "",
  "request_type": "mfa_change",
  "account_state": {
    "methods": [ { "type": "microsoftAuthenticator" }, { "type": "password" } ],
    "sspr_ready": true, "is_admin": false, "is_guest": false
  },
  "branch_id": "MFA-01",
  "approval": { "approver": "上長のアカウント", "result": "approved", "at": "2026-10-07T08:42:00+09:00" },
  "tap": { "issued": true, "is_usable_once": true, "lifetime_minutes": 60 },
  "registration_confirmed": true,
  "escalated": false,
  "escalation_reason": ""
}

1つ目の理由は、branch_id で手順書のどの行を通ったかが分かることです。 後から対応を見直すとき、エージェントがどの判断をしたかではなく、どの決まりに当てはめたかを見ます。 手順書を直せば、次から同じ依頼の扱いが変わります。

2つ目は、TAP の値そのものを記録しないことです。 tap に残すのは、発行の有無と、1回限りか、有効期間だけです。TAP の値は本人に渡したら、どこにも残しません。

3つ目は、escalation_reason で回した理由を数えられることです。 「SSPR の登録なし」が多ければ、SSPR の登録の呼びかけが先です。

システムへ連携する

上長への承認の依頼には、依頼者・依頼の種類・依頼の日時だけを書きます。 「本人から多要素認証の再登録の依頼がありました。心当たりがあれば承認してください」。上長に求めるのは、本人が今そう言っているはずかの確認で、技術の判断ではありません。 上長が30分以内に応えなければ、担当へ回します。

TAP は、承認の後に、依頼者とのエージェントの会話の中でだけ渡します。 メールや別のチャットには送りません。公式ドキュメントでは、1回限りの TAP でパスワードレスの方法を登録する場合は10分以内に登録を完了する必要があるとされているので、渡すときに「すぐに登録してください」と添えます。

人が確認する

人が関わるのは、上長の承認と、担当へ回ってきたものだけです。

1. 上長は、多要素認証の依頼を毎回承認する … 心当たりが無ければ却下します。却下されたら、エージェントは手続きを止め、担当へ回します
2. 担当者は、回ってきたものを優先度の順に見る … suspicious が最優先、次に管理者のアカウント、次に SSPR の登録なし
3. 担当者は、週に1回、自動で片付いた記録を抜き取りで見る … 20件ほどを選び、branch_id と会話の要約が手順書と合っているかを確かめます

3番目を省かないでください。 自動で片付いた依頼は誰の目にも触れません。エージェントが手順書の行を取り違えていても、社員がサインインできていれば気づかれないまま続きます。

目標は、600件をならして1件3分です。 ロックと SSPR の案内で片付く依頼は担当者の時間を使わず、回ってきたものに時間を残せます。

例外に対処する

最後の行は、朝の集中の日に起きやすい事故です。 公式ドキュメントでは、前払いの容量を使い切ると新しいエージェント フローの実行がブロックされるとされています。容量の使用状況を毎週見て、足りなくなる前に従量課金の設定などを検討します。

記録を残す

• 会話の要約（依頼の種類、選んだ branch_id、呼んだツール）
• フロー①の結果（認証方法の種類、ロール、ユーザーの種類）
• 承認の依頼と結果、承認者、日時
• TAP の発行の有無と、1回限りか、有効期間（値は残さない）
• 登録の確認の結果
• 担当へ回した理由と、担当者の対応の結果

会話の全文は、短い期間だけ残します。 社員がパスワードを書いてしまうことがあるので、全文は不審な事案の調べに要る期間だけ残し、それ以降は要約だけにします。 期間は、自社のログの保存の決まりに合わせます。

escalation_reason と branch_id は、月ごとに数えます。 手順書の分岐ごとの件数が分かれば、どの行を手順書に足すと担当への回りが減るかが見えます。