毎月のセキュリティ更新を当てていない端末の一覧から、利用者ごとに理由の候補と手順を添えた案内文を作って送り、未対応を追う

処理の起点を決める

SharePoint のライブラリに、その月の一覧のブックが置かれたことを起点にします。 担当者が書き出すタイミングは、自社の更新リングの準拠の期日を過ぎた翌営業日と決めておきます。期日の前に書き出すと、「In progress」の端末が多く、まだ入っていないだけの端末まで対象に見えます。

2回目以降の案内も、同じ形で起こします。 1週間後に担当者がもう一度書き出して置くと、フローが追跡のリストと突き合わせ、直った端末を閉じて、直っていない端末だけに案内を送ります。フローは「その月の何回目の書き出しか」をファイル名の日付と追跡のリストから判断します。

書き出しを自動にする方法もあります。Intune のレポートは Microsoft Graph の exportJobs（deviceManagement/reports/exportJobs）で書き出せるとされ、品質更新に関するレポートとして QualityUpdateDeviceStatusByPolicy が挙がっています。ただしベータ版の API で、アプリの登録と、端末の管理情報を読む権限（DeviceManagementManagedDevices.Read.All）の設定が要ります。この構成ではまず手で書き出し、運用が回ってから自動化を検討します（第9章）。

入力データを集める

一覧の列のうち、いくつかは既定の列ではありません。 「Intune last check-in time」「Primary user UPN」「Hex error code」はオプションの列で、レポートの画面で列を足してから書き出します。また、エラーコードやクライアントの状態などの補足の列は、すべての端末に表示されるとは限らず、値が入らないこともあるとされています。エラーコードが空の端末は「理由が分からない」として扱います。

質を決めるのは、対応表と手順集です。 「再起動してください」の一行でも、どこを押せば再起動の予約ができるのか、保存していないファイルはどうするのかまで書いた手順集があれば、案内文はその手順を引くだけで済みます。

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

書き出したCSVは、決まった様式のブックの表に貼ってから置きます。 Power Automate の Excel Online (Business) コネクタは .xlsx などのブックの表を読むもので、CSVのままでは読めません。

様式のブックの表の見出しは英数字にします。 コネクタのフィルター クエリ・並べ替え・列の選択のパラメーターでは英数字の列名のみがサポートされるとされています。レポートの列名は「Update status」のように空白を含むので、様式の側で UpdateStatus LastCheckIn PrimaryUserUPN HexErrorCode のような見出しにし、その下に値だけを貼ります。

改ページの設定を必ずオンにします。 このアクションは既定で最大256行を返し、すべての行を取得するには改ページ位置をオンにする必要があるとされています。月120台なら収まりますが、更新の不具合が出た月は数百台になることがあり、そのときに一部の端末だけに案内が届くことになります。

AIへ渡す前に整形する

1. 対象の絞り込み … 更新状態が「Not up to date」の行だけを残します
2. 主な利用者の確認 … UPN が空の行は、案内文を作らずに担当者へ回します。共用端末や会議室の端末に多い型です
3. 最終チェックインの経過日数の計算 … 書き出した日から何日前かを出します
4. インストール済みの更新の遅れの判定 … 対象の更新とインストール済みの更新を比べ、2か月以上遅れている端末に印を付けます
5. 理由の候補の選択 … 対応表の条件を上から順に当て、最初に当たった行の理由と手順の番号を付けます
6. 利用者ごとのまとめ … 同じ UPN の端末を1つにまとめ、1人に1通の案内にします
7. 回数の確認 … 追跡のリストから、その端末に今月何回目の案内かを引きます

5番目の対応表の例です。

3行目と4行目は、利用者に操作を頼まず担当者が見る行です。 原因の分からない端末に再起動を頼んでも直らず、利用者の手間と、直らなかったという問い合わせだけが増えます。

AIに処理させる

させるのは、規則で決まった理由の候補と手順を、利用者向けの案内文にまとめることだけです。

同じ利用者が2台持っていて、理由が違うことがあります。 1台はしばらく起動していない、もう1台は再起動待ち、という場合です。端末ごとに段落を分け、手順を混ぜないようにさせます。

2行目がいちばん起きやすい失敗です。 案内文を作らせると、「念のためディスクのクリーンアップも行ってください」のように手順集に無い操作を親切に足します。 手順は番号で渡し、本文は手順集の文をそのまま入れるように指示します。

指示内容を固定する

あなたは情報システム部の担当者として、月例のセキュリティ更新が
入っていない端末の利用者に送る案内文を作ります。

【守ること】
- 理由の候補と手順は、【端末ごとの情報】に書かれたものだけを使ってください。
  新しい理由を考えたり、手順を足したりしないでください。
- 手順の本文は【手順集】の該当する番号の文をそのまま入れてください。
  言い換えたり、要約したりしないでください。
- 理由は「〜の可能性があります」と書き、断定しないでください。
- 端末が複数あるときは、端末ごとに段落を分けてください。
- 期限は【期限】の日付をそのまま使ってください。
- 回数が2のときは前回の案内日に触れ、3のときは
  「担当者からご連絡します」と書いてください。
- 不安をあおる表現、命令口調を使わないでください。
- 件名は40字以内、本文は400字程度を目安にしてください。
- 回答に JSON マークダウンを含めないでください。

【利用者の表示名】{display_name}
【端末ごとの情報】{devices}
   （端末名、準拠の期日、理由の候補、手順の番号の組）
【手順集】{procedures}
【期限】{due_date}
【回数】{notice_count}
【前回の案内日】{previous_date}
【問い合わせ先】{contact}

「手順集の文をそのまま入れる」を明記しないと、手順が要約されます。 「設定から更新を確認して再起動してください」のように短くされると、どの画面のどこを押すかという、利用者がいちばん知りたい部分が消えます。

「理由は可能性として書く」を入れているのは、規則で選んだ理由も推定だからです。 最終チェックインが古い端末も、実際には別の理由で止まっていることがあります。

出力形式を固定する

プロンプトの出力を JSON にし、形式を「カスタム」で固定します。 JSON の例を編集すると形式は Custom になり、保存すると形式がロックされ、フローではその形式が使われるとされています。

{
  "upn": "",
  "subject": "",
  "body": "",
  "devices": [
    { "device_name": "", "reason_id": "", "procedure_id": "", "included": "yes | no" }
  ],
  "uses_only_given_procedures": "yes | no"
}

1つ目の理由は、devices で漏れを確かめられることです。 入力に渡した端末がすべて included: yes で返っているかをフローが確かめ、1台でも欠けていれば送らずに担当者へ回します。 本文だけを受け取ると、2台目の段落が抜けていても気づけません。

2つ目は、uses_only_given_procedures を後段の点検に使えることです。 AIの自己申告なのでそのまま信じはしませんが、no と返ってきたものは必ず人に回す、という安全側の使い方をします。

送るかどうかの判断は、フローが規則で行います。

システムへ連携する

承認には「開始してテキストの承認を待機」を使います。 Microsoft のページでは、プロンプトの後にこのアクションを置き、推奨テキストに生成されたテキストを入れると、レビュー担当者が承認の画面でテキストを確認し、必要に応じて編集して応答できる手順が示されています。

利用者への送付は、Teams のチャットを基本にします。 Microsoft のページの手順には、Teams の「チャットまたはチャネルでメッセージを投稿する」アクションで、投稿者にフロー ボット、投稿先にフロー ボットでチャットするを選び、受信者のメール アドレスを指定してメッセージを送る例があります。メールより目に留まりやすく、利用者が返信しやすいのが理由です。ただし、フロー ボットとのチャットは担当者個人との会話ではないので、本文の最後に問い合わせ先のチャンネルかアドレスを必ず書きます。 3回目の案内と、Teams を使っていない利用者には Outlook のメールで送ります。

追跡のリストの列は、端末名・UPN・対象の更新・回数・最終送付日・状態の6つで足ります。 状態は「案内済み」「利用者対応済み・未解決」「解決」「担当者対応」の4つにします。フローが書くのは「案内済み」と「解決」だけで、残りの2つは担当者が書きます。どこまでが自動で、どこからが人の判断かが、状態の列を見れば分かるようにするためです。

様式のブックには書き込みません。 追跡はリストの側で行います。Excel のファイルは、コネクタを最後に使ってから最大6分間ロックされる場合があるとされ、担当者が開いて貼り直す作業とぶつかります。

人が確認する

人が見るのは、規則で「確認が要る」と決まった案内だけです。 運用を始めて最初の1か月だけは、全件を承認に回します。

1. 最初の1か月は全件を読む … 手順が要約されていないか、端末が抜けていないか、言い回しが社内の調子に合っているかを見ます
2. 2か月目からは確認が要るものだけ … UPN が空、理由が不明、3回目の案内などです
3. 3回目の案内の前に端末を確かめる … 利用者に3回頼んでも直らない端末は、利用者の操作ではなく端末側に原因があることが多いので、担当者が Intune の端末の画面で状態を見ます
4. 対応表に無いエラーコードを記録する … 担当者が原因を調べたら、対応表と手順集に足します

3番目で端末を見るときは、一覧の補足の列を手がかりにします。 クライアントの状態やサービスの状態は Windows Update から提供される値で、値が入っていれば、更新がどの段階で止まっているかの見当がつきます。 ただし、補足の列はすべての端末に表示されるとは限らないとされているので、値が空でも異常とは限りません。 空のときは、端末の利用者に画面を見せてもらうほうが早く分かります。

4番目が、この運用を育てる作業です。 対応表に無いコードが出るたびに人が調べ、表に足していくと、人に回る件数が月を追って減っていきます。

目標は、120件をならして1件2分です。 大半は送るだけで、人が開くのは2割前後という想定です。

例外に対処する

最後の行が大事です。 案内文が作れないときに連絡を止めると、更新の入っていない期間がそのまま延びます。AIは文面を良くするためのもので、連絡を送ることの条件にはしません。

記録を残す

• 毎回書き出した一覧のブック（日付ごと。上書きしない）
• 端末ごとに選ばれた理由の候補と手順の番号、そのとき使った対応表の版
• 送った案内文の全文、送付日、送付の経路（Teams／メール）
• 承認に回った案内と、担当者が直した内容
• 端末ごとの回数と、直った日（翌週の一覧で「Up to date」になった日）
• 理由の候補ごとの、案内の後に直った割合

最後の行で、対応表の当たり外れが分かります。 「再起動の先延ばし」と判定した端末が案内の後に直っていれば、その判定は合っています。直らない端末が多い理由は、対応表の条件か手順集のどちらかを見直します。