社内システムとクラウドのサービスのログインの記録から普段と違うログインを拾い、確認すべき順に並べて本人への確認の文面を作る

処理の起点を決める

1時間ごとの定時実行を起点にします。 毎朝まとめて見る形では、夜のあいだに起きたログインに気づくのが翌朝になります。1時間ごとに取り込み、「必ず確かめる」の印が付いたものだけは、その場で担当に通知します。 それ以外は、一覧にたまったものを担当が決まった時間に見ます。

取り込みは、時間の範囲を指定して行います。 ドキュメントでは、要求が時間切れにならないよう、$filter で時間の範囲を指定して取ることが勧められています。前回取り込んだ最後の時刻から現在までを範囲にし、重複は記録の id で除きます。

入力データを集める

質を決めるのは、いちばん下の2つです。 出張の予定が無ければ、出張中の海外からのログインがすべて上位に来ます。VPNの出口のIPアドレスが一覧に無ければ、VPNにつないだ社員の場所が、出口のある都市として記録され、普段と違う場所に見えます。

3行目の在籍の状態も外せません。 退職した社員のアカウントでのログインは、普段の型と比べるまでもなく「必ず確かめる」ものです。

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

Microsoft Graph の GET /auditLogs/signIns を、アプリの権限 AuditLog.Read.All で呼びます。

1回の応答の上限は1,000件です。 ドキュメントでは、ページの大きさの既定と上限が1,000件で、新しい順に返るとされています。残りは @odata.nextLink をたどって取ります。 たどり忘れると、ログインの多い時間帯だけ取りこぼします。

記録は自分の側に貯めます。 ドキュメントでは、取り出せるのは Microsoft Entra ID の既定の保持期間の中のものだけとされています。普段の型に使う60日分は、取り込んだものを社内のデータベースに残して作ります。

v1.0 の一覧で取れるのは、対話型のサインインと、成功したフェデレーションのサインインです。 アプリが裏で行う非対話型のサインインは、この構成の対象から外します。サービス用のアカウントは別の一覧で管理し、普段の型を作りません。

AIへ渡す前に整形する

1. 時刻の変換 … createdDateTime は UTC です。日本時間に直してから時間帯を数えます
2. 自社の接続元の印 … 拠点とVPNの出口のIPアドレスの範囲に当たるものに「社内」の印を付けます
3. 端末の識別 … deviceDetail の端末IDがあればそれを、無ければOSとブラウザの組み合わせを端末とみなします
4. 認証の方式 … clientAppUsed が IMAP、POP、SMTP などの古い方式かどうかの印を付けます
5. 普段の型 … 社員ごとに、過去60日の時間帯の分布、国と都市、端末、アプリの一覧を作ります
6. 外れの特徴量 … 新しいサインインについて、その時間帯の過去の割合、初めての国か、初めての都市か、初めての端末か、管理外の端末か、直前のサインインの場所からの移動の速さ、直近1時間の失敗の回数を出します
7. 予定との突き合わせ … 出張の行き先と期間、在宅勤務の申請に合うかの印を付けます

1番目を省くと、時間帯の判定がすべて9時間ずれます。 日本時間の朝9時のログインが、UTC では0時のログインに見えるからです。深夜の警告が急に増えたら、まずここを疑ってください。

6番目の移動の速さは、場所の精度に気をつけます。 携帯電話の回線やVPNでは、記録される都市が実際の場所と離れることがあります。同じ国の中の都市の違いだけで「あり得ない移動」とせず、国が変わった場合に限ります。

AIに処理させる

この構成の判定は、規則と点数の2段で行います。 規則は「これは必ず人が見る」ものを拾い、IsolationForest は規則に当たらない外れの組み合わせを拾います。生成AIは、判定も順番も決めません。

IsolationForest の点数は score_samples で取ります。 ドキュメントでは、値が低いほど異常とされています。この点数を全社の分布の中での順位に直して、上位から並べます。 点数の絶対値は学び直しのたびに動くため、順位で扱うほうが運用が安定します。

contamination には頼りません。 既定の 'auto' のまま学習し、predict の正常・異常の2分は使いません。何件を人が見るかは、点数ではなく担当の手の空き具合で決めます。 1日に見られる件数を先に決め、その件数で切ります。

国や端末のような区分の値は、数に直してから渡します。 ドキュメントには区分の値をそのまま扱う記述が無いため、「初めての国か」「その国の過去の割合」のように、その社員の普段との比較を数にしたものを特徴量にします。国の名前そのものは渡しません。

指示内容を固定する

規則と点数の部分は次のとおりです。

from sklearn.ensemble import IsolationForest

FEATURES = ["hour_rarity", "new_country", "new_city", "new_device",
            "unmanaged_device", "travel_kmh", "fail_count_1h", "new_app"]
# 過去60日の全社員のサインインで学習（社員ごとの普段との比較を数にしたもの）
iso = IsolationForest(n_estimators=200, random_state=0).fit(hist[FEATURES])
new["score"] = iso.score_samples(new[FEATURES])      # 低いほど普段から外れている
new["rank"] = new["score"].rank(method="first")       # 低い順に1,2,3…

rules = (
    (new["legacy_auth"] & new["success"]) |           # 古い認証方式での成功
    ((new["travel_kmh"] > 900) & new["country_changed"]) |  # 国をまたぐあり得ない移動
    new["user_left"] |                                 # 退職者のアカウント
    (new["risk_during_signin"] == "high")              # P2 がある場合のみ値が入る
)
new["must_review"] = rules

travel_kmh のしきい値は、旅客機の速さを目安に置いた値です。 国が変わったうえで、直前のサインインの場所からその速さを超えて移動したことになる場合に印を付けます。国内の都市の違いには使いません。

本人への確認の文面は、Claude API に次の指示で作らせます。

あなたは会社の情報システム部で、社員に自分のログインかどうかを確かめる連絡を書く立場です。
渡された情報だけを使って、社内チャットで送る短い文面を作ってください。

【渡す情報】
- ログインの日時（日本時間）
- ログインしたサービスの名前
- おおよその場所（国と都市）
- 端末の種類（OS とブラウザ）
- 普段と違う点（外れの理由の一覧）

【書き方】
- 1行目に、情報システム部からの確認の連絡であることを書いてください。
- 次に、日時・サービス・場所・端末を箇条書きで書いてください。
- 「このログインはご本人によるものですか」と聞き、
  「はい」か「いいえ」で返事をもらうようお願いしてください。
- 心当たりが無い場合は、このチャットに返事をするだけでよいことを書いてください。
- 全体を200字以内にしてください。

【厳守事項】
- 「不正」「攻撃」「乗っ取り」など、本人を疑う言葉を使わないでください。
- リンクを書かないでください。パスワードや認証コードの入力を求めないでください。
- IPアドレスの全桁、端末ID を書かないでください。
- 普段と違う点の一覧に無いことを書かないでください。
- 点数や順位を書かないでください。
- 渡された情報が足りない場合は、文面を作らず missing に足りない項目を書いてください。

【ログインの情報】{signin}
【普段と違う点】{reasons}

「リンクを書かない」「パスワードを求めない」がいちばん大事な2つです。 確認の連絡が、ふだん社員に注意を呼びかけているフィッシングのメールと同じ形をしていると、本物の確認の連絡と偽物の区別を社員に求めることになります。 返事は、社内チャットに「はい」か「いいえ」と書くだけにします。

出力形式を固定する

次の形のJSONを、サインインごとに作ります。 score から reasons までは Python が埋め、message_draft を Claude API の構造化出力（output_config.format に type: "json_schema"）で受け取ります。

{
  "signin_id": "66ea54eb-....",
  "user": "[email protected]",
  "jst_time": "2026-10-06T02:14",
  "app": "Office 365 Exchange Online",
  "country": "SG",
  "city": "Singapore",
  "device": "Windows / Edge",
  "managed": false,
  "client": "Browser",
  "success": true,
  "must_review": false,
  "score": -0.61,
  "rank": 3,
  "reasons": ["初めての国", "初めての端末", "普段ログインしない時間帯"],
  "travel_plan_match": false,
  "message_draft": { "text": "", "missing": [] },
  "review": { "action": null, "by": "", "at": "" },
  "user_reply": null
}

1つ目の理由は、reasons を判定の結果と同じ行に置けることです。 担当は理由を読むだけで、記録を開き直さずに判断できます。文面も reasons から作るので、担当が読んだ理由と本人に伝える内容が一致します。

2つ目は、travel_plan_match を別の項目にすることです。 出張の予定に合うからといって、点数や理由を消しません。予定に合っていても、初めての端末で古い認証方式なら見るべきものです。 消すかどうかは担当が決めます。

3つ目は、review と user_reply です。 担当がどう扱い、本人が何と答えたかが残るので、後から「閉じたものの中に本人でないものが無かったか」を確かめられます。

システムへ連携する

本人への送信は担当が行います。 下書きを自動で送ると、点数の誤りで多くの社員に確認が届き、確認の連絡そのものが読まれなくなります。

生成AIに渡すのは、上位のものの日時・サービス・場所・端末の種類と理由だけです。 氏名やメールアドレス、IPアドレスは渡しません。宛先は送る段階で担当のチャットの側で決まります。

人が確認する

1. 「必ず確かめる」の印から見る … 通知が来たら、その場で理由を読みます。古い認証方式での成功と退職者のアカウントは、本人の返事を待たずに対応を始めることがあります
2. 上位から理由を読む … 出張の予定や在宅の申請で説明できるかを見ます
3. 確認するか閉じるかを決める … 確認するものは下書きを直して送ります。閉じるときは理由を一言書きます
4. 返事を記録する … 「はい」なら閉じ、「いいえ」か返事が無いものは手順に沿って対応します

3番目で閉じる理由を書くことを省かないでください。 同じ理由で閉じたものが続くなら、その理由は普段の型か規則に入れるべきものです。

目標は、900件をならして1件2分です。 下位のものは一覧で流し見て閉じ、上位と印の付いたものに時間を使います。

例外に対処する

4行目の新しく入社した社員は、点数が当てにならない典型です。 過去の記録が無いため、何をしても「初めて」になります。この期間に点数で警告を出すと、新しい社員に確認の連絡が集中します。

記録を残す

• 取り込んだサインインの記録と、取り込んだ時刻の範囲
• 社員ごとの普段の型の更新の記録
• サインインごとの特徴量、規則の印、点数、順位、理由、そのときのモデルの版と規則の版
• 担当の判断（確認したか、閉じたか、閉じた理由）と、本人の返事
• 本人でなかったものへの対応の記録（いつ、誰が、何をしたか）
• 閉じたものからの抜き取りの確認 … 月に1回、閉じたものの一部を見直した結果

最後の行が、この構成を守る記録です。 閉じたものの中に本人でないものが混じっていないかを確かめないと、流す判断が正しいかどうかは誰にも分かりません。 現状の（d）と同じ状態に戻ります。