Microsoft Teams のチームに招いた社外のゲストを毎月洗い出し、最終利用日・所属・チームの用途から削除の候補を判定して、チームの所有者への確認依頼を送る

処理の起点を決める

毎月1日の朝7時に、繰り返しのトリガーで動かします。 見直しは月に1回で足ります。ゲストの最終サインインの日時は、更新に最大24時間かかることがあるとされているので、日々の細かな動きを追う意味はありません。

所有者の返事を待つ期間は14日にします。 7日目に一度だけ催促し、14日を過ぎて返事の無い組は「返事なし」として情報システムの担当の一覧に入れます。翌月の見直しが始まる前に、前の月の組を閉じておくためです。 返事を待つ間もフローは止まったままになるので、待機の部分は所有者ごとの子フローに分け、親のフローは組の表と判定を作ったところで終えます。

チームの台帳の終了予定日が過ぎたチームは、月の途中でも見直しの対象にします。 終了予定日の翌日に、そのチームの組だけで同じ処理を動かす2つ目のフローを置きます。案件の終わりは、ゲストを外すいちばん自然な時機だからです。

入力データを集める

質を決めるのは、チームの台帳の終了予定日と、取引先の一覧の取引の状態です。 この2つが空だと、判定は最終サインインの日時だけに頼ることになり、第1章で書いた読み違えがそのまま判定に入ります。

前回の見直しの記録も渡します。 先月「残す」と答えた組をまた聞くと、所有者は確認のカードを開かなくなります。前回「残す」と答えた組は、状況が変わらない限り3か月は聞きません。

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

ユーザーは、signInActivity を選んで一覧で取ります。 公式の説明では、signInActivity は既定では返らないため、ユーザーの一覧を取るときに $select=signInActivity を指定する必要があります。

GET https://graph.microsoft.com/v1.0/users
    ?$select=id,displayName,mail,userType,createdDateTime,signInActivity

ゲストへの絞り込みは、取ったあとにフローの中で行います。 signInActivity は $filter に使えますが、他の項目との組み合わせのフィルターには対応していないとされています。userType の条件と signInActivity の条件を1回の要求にまとめず、userType が Guest のものをフローのフィルターで残します。

チームのメンバーは、チームの台帳に載ったチームだけを取ります。 テナントのすべてのチームを回すと、台帳に用途の無いチームの組が大量に出ます。台帳に無いチームにゲストがいたら、それ自体を「台帳の漏れ」として情報システムの担当に知らせます。

AIへ渡す前に整形する

1. ゲストに絞る … userType が Guest のユーザーだけを残します
2. 経過日数を計算する … lastSuccessfulSignInDateTime から今日までの日数。空のときは createdDateTime からの日数を使い、「サインイン記録なし」の印を付けます
3. 招待から日の浅いゲストを外す … 招待から30日以内のゲストは、判定の対象にしません
4. ドメインを取り出す … メールの @ より後ろを取り、取引先の一覧で引きます
5. 終了予定の印を付ける … チームの終了予定日を過ぎていれば「終了予定を経過」の印を付けます
6. 前回の答えを付ける … 前回の見直しで「残す」と答えた日を付けます
7. 個人を特定する項目を落とす … プロンプトに渡す行から、表示名とメールの local part を落とします

2番目の「記録なし」を、長く使っていないことと同じに扱わないでください。 lastSuccessfulSignInDateTime は2023年12月1日より前の分がさかのぼって埋められておらず、招待されたまま一度も使われていないゲストも空になります。 空は空として、招待からの日数と組み合わせて判断させます。

3番目は、公式のアクセス レビューの考え方にも沿っています。 非アクティブの日数を決めても、それより最近に作られたユーザーは対象にしないとされており、招待したばかりのゲストが一度もサインインしないうちに消されることを防いでいます。

AIに処理させる

させるのは、ゲストとチームの組ごとに、所有者に確認を頼むべきかを判定し、その理由を所有者が読める文で書くことだけです。 数字の計算はフローで済ませ、プロンプトには結果だけを渡します。

判定を2つに絞っているのは、「削除」をAIの選択肢に入れないためです。 AIに「削除」「保留」「継続」を選ばせると、「削除」が出た組がそのまま外されるという運用に流れていきます。 選べるのは「聞く」か「聞かない」かだけにします。

理由の文が、この構成の価値の半分です。 「最終サインインから142日。チームの終了予定日（2026年6月30日）を過ぎている。所属の会社との取引は続いている」と書かれていれば、所有者は、そのゲストが別の案件で使われていると分かったうえで答えられます。

指示内容を固定する

あなたは情報システム部で、Teams のチームに招いた社外のゲストの見直しを手伝う担当です。
以下はゲストとチームの組ごとの事実です。事実だけを見て、チームの所有者に
「このゲストをこのチームに残す必要があるか」を確認すべきかを判定してください。

【判定の選び方】
- ask_owner ... 次のどれかに当たる
    ・最終サインインから {inactive_days} 日以上
    ・サインインの記録が無く、招待から {inactive_days} 日以上
    ・チームの終了予定日を過ぎている
    ・所属の会社との取引が「終了」
    ・ゲストの会社が、チームの相手先の会社と違う
    ・チームの名前や説明から、案件や共同研究が終わったと読める
- keep ........ 上のどれにも当たらない
    ・ただし前回「残す」と答えてから 90 日以内で、状況が変わっていなければ keep

【厳守事項】
- 外すべきだ、削除すべきだ、とは書かないでください。判定は ask_owner か keep だけです。
- 最終サインインは、このテナントへのサインインの記録です。
  このチームを使った日と書かないでください。
- 取引の状態が「不明」のときに、取引が終わったと推測しないでください。
- reasons には、当てはまった条件を所有者が読める短い文で、日付と日数を入れて書いてください。
- チームの説明から読み取ったことを理由にするときは、説明の文を quote にそのまま写してください。
- 回答に JSON マークダウンを含めないでください。

【組の事実】{pairs_json}

「このチームを使った日と書かないでください」を入れるのは、理由の文で読み違えを広げないためです。 AIは「142日このチームを使っていない」と書きがちで、所有者はそれを読んで「使っていないなら外してよい」と答えます。 実際には別のチームで毎日使っているかもしれません。

閾値を {inactive_days} で差し込むのは、社内で決める値だからです。 公式の説明では、多くの組織で非アクティブとみなす期間は90日から180日の間とされています。まず90日で始め、所有者の「残す」の答えが多すぎるなら延ばします。

pairs_json には、1つのチームの組をまとめて渡します。 1回の実行で1チームを判定すれば、チームの説明を何度も渡さずに済み、所有者ごとのカードもチーム単位で作れます。

出力形式を固定する

次の形の JSON で受け取ります。

{
  "team_id": "",
  "results": [
    {
      "guest_id": "",
      "decision": "ask_owner",
      "reasons": [
        "最終サインインから 142 日（2026-05-19）",
        "チームの終了予定日（2026-06-30）を過ぎている"
      ],
      "quote": "",
      "notes": "所属の会社との取引は続いている"
    }
  ]
}

1つ目の理由は、guest_id で返すことです。 プロンプトには表示名を渡していないので、フローは Graph のユーザーの ID でゲストと結び直し、カードに表示名を出します。

2つ目は、reasons を配列にすることです。 確認のカードには理由を箇条書きで出し、見直しの記録には条件ごとに数えられる形で残します。 どの条件で聞いた組が「外してよい」になりやすいかが、数か月で分かります。

3つ目は、notes で「聞く理由ではないが知っておくべきこと」を分けることです。 取引が続いていることは聞く理由ではありませんが、所有者が答えるときには必要な情報です。

渡した組と返ってきた組の数が合わないときは、足りない組を ask_owner として扱います。 AIが組を1つ落としても、そのゲストが「聞かなくてよい」側に紛れ込まないようにするためです。

システムへ連携する

Graph へは読むだけで、書き込みません。 ゲストをチームから外す、アカウントを止める、といった操作はフローに持たせません。フローに書き込みの権限を渡さなければ、判定の誤りが外す操作に直結しません。

確認のカードは、Teams コネクタの「アダプティブ カードを投稿して応答を待機する」で、所有者とのフロー ボットのチャットに送ります。 コネクタの説明では、このアクションはどのユーザーの応答でも待機を終えるとされているので、チャネルに投稿すると、所有者でない人が答えてしまいます。 所有者個人のチャットに送ります。

カードの大きさには上限があります。 メッセージは約28KBが上限とされ、超えると失敗します。1枚のカードに載せるゲストは20人までにし、それを超えるチームはカードを分けます。 また、これらのアクションは Teams 管理センターで Workflows アプリが許可されている必要があります。

人が確認する

判定が ask_owner の組は、必ず所有者が答えます。

1. 所有者が答える … 組ごとに「残す／外してよい／分からない」を選びます。「残す」には一言の理由を求めます
2. 情報システムの担当が外す … 「外してよい」の組をチームから外します
3. アカウントの削除は別に判断する … すべてのチームから外れたゲストについてだけ、テナントからの削除を検討します
4. 「分からない」と「返事なし」を担当が引き取る … 所有者と話して決めます

カードには、組ごとに3つだけを載せます。 ゲストの表示名と会社、理由の箇条書き、3つの選択肢です。最終サインインの日時そのものは載せず、理由の文の中で「テナントへのサインイン」として示します。 日時だけを大きく見せると、所有者はそれだけで答えを決めてしまいます。

keep の組も、毎月1割を情報システムの担当が抜き取りで見ます。 判定の条件に漏れがないかを確かめるためで、チームの説明が空のチームの組から優先して見ます。

所有者が異動・退職していたら、台帳の所有者を直してから聞きます。 所有者がいないチームのゲストは、情報システムの担当が部署の長に確かめます。

例外に対処する

最後から2行目で ask_owner 扱いにするのは、判定が出ないことを「聞かなくてよい」と扱わないためです。 誤るなら聞くほうへ誤らせます。

記録を残す

• 毎月の組の表（ゲストの ID、チームの ID、経過日数、印、取引の状態）
• プロンプトに渡した事実と、返ってきた JSON の全文
• 所有者に送ったカードの内容と送った日時
• 所有者の答えと理由、答えた日時
• 情報システムの担当が外した日時と、外した人
• テナントから削除したゲストと、削除を決めた理由

4つ目は、監査のときに「誰がなぜ残すと決めたか」を示す記録になります。 毎月見直しているという規程を守っていることも、この記録で示せます。

5つ目と6つ目を分けて残すのは、チームから外すこととテナントから消すことが別の判断だからです。 後から「なぜこのゲストのアカウントが無いのか」と聞かれたときに、どのチームの所有者の答えを根拠に、誰が消したかを追えるようにします。

keep の抜き取りの結果も残します。 抜き取りで見つかった「聞くべきだった組」は、プロンプトの条件を足す材料になります。