社内PCの SMART 情報とイベントログを毎日集め、ディスク故障の予兆を予測して交換の優先順位をつける

処理の起点を決める

端末の側は、Remediations の割り当ての「毎日」で、毎日決まった時刻に動かします。 予定の時刻にPCが動いていなかったときは、オンラインになった後、できるだけ早く動きます。 ノート型でも、1日のどこかで値が集まります。

ただし、結果が毎日 Intune に届くとは限りません。 繰り返し動くスクリプトの結果は、最初の6日のあいだは変化があったときだけ報告され、7日ごとには変化が無くても報告されます。 そのため、検出スクリプトが返す1行は、変化が意味を持つ値だけに絞ります。 毎回変わる時刻や温度をそのまま入れると、毎回が「変化」になり、Microsoft もそうした値を避けるよう勧めています。

サーバー側の Python は、毎朝7時に動かします。 前日の結果を取り、届いていないPCは「前回の値のまま」として扱います。届かない日が続いたPCは、別に数えます。 休職者のPCや、倉庫に置かれた予備機が多く含まれるので、端末の台帳と照らして、使われているPCだけを見込みの対象に残します。

入力データを集める

質を決めるのは、いちばん下の修理・交換の記録です。 モデルが学ぶ「故障」は、この記録から作ります。交換の理由が「遅いので念のため」と「ディスクの故障を確認」で分かれていないと、 故障していないディスクを故障として学ばせることになります。

イベントは、日ごとの数ではなく累計で返します。 日ごとの数は毎日変わり、報告の仕組みと合いません。PCの中に前回までの累計を小さなファイルで持ち、新しく出た分を足して返します。 1日ごとの増え方は、サーバー側で前の日の累計との差から計算します。

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

検出スクリプトは、値を集めて1行のJSONを書き出し、exit 0 で終わります。 修復のスクリプトは、検出のスクリプトが exit 1 を返したときだけ動くので、exit 0 なら何も直しに行きません。 書き出した1行は、検出のスクリプトの出力として Intune に残ります。

Graph のこの資源は beta の版です。 Microsoft は Intune の beta の API を支えていますが、変更がより頻繁で、v1.0 を使えるならそちらを勧めるとしています。変わったときに気づけるよう、取れた件数が前日から大きく減ったら止まるようにします。Intune の管理センターからも、結果を .csv に書き出せるので、API が使えない日はそれで代えます。

AIへ渡す前に整形する

1. 出力を読む … 1行のJSONを読み、読めないもの・2,048文字で切れたものを分けます
2. PCとディスクを結ぶ … PCの名前と、ディスクの型番・番号の組で、日ごとの行にします。ディスクだけを交換したPCは、交換の日で別のディスクとして扱います
3. 届かなかった日を埋める … 報告の無い日は前回の値をそのまま使い、「埋めた」印を付けます
4. 増え方を作る … 訂正できなかった誤り、読み取りの誤りの合計、各イベントの累計について、7日と30日の差を作ります
5. 年数を作る … 製造の年と週から、ディスクの経過の週数を作ります
6. 答えを作る … 交換の記録で「ディスクの故障を確認」となったものについて、交換の日の前30日のあいだの各日を1、それ以外を0にします
7. 学ばせる期間と確かめる期間を分ける … 日付で分け、後の期間で確かめます

4番目が、この構成の中心です。 値の大きさだけを特徴にすると、昔一度だけ誤りが出て、その後は落ち着いているディスクが上位に並びます。増え方を並べると、いま動いているディスクが上に来ます。

3番目の埋めた値は、増え方の計算では0として扱います。 届かなかった日に値が増えていたかは分からないので、次に届いた日に、空いた日数分の増加がまとめて出ます。 ノート型を長く持ち出していたPCは、戻った日に急に増えたように見えるので、埋めた日数を特徴の列に足して区別します。

6番目で、交換の理由を確かめないまま答えにしないでください。 「念のため交換」を故障として学ばせると、問い合わせが多い部署のPCほど故障しやすい、という偏りを学びます。

AIに処理させる

させるのは、規則で replace_now にならなかったディスクについて、30日以内に故障で交換が要る見込みを出すことだけです。

右下の「埋めない」には理由があります。 HistGradientBoostingClassifier は、欠けた値を、分かれ目ごとに左右どちらへ送るとよいかを学びます。 欠けていること自体が「値を返さない型のディスク」という情報なので、0や平均で埋めると、それが消えます。

129と153を確実な兆しに入れないのも、意図してのことです。 Microsoft の手引きでは、153はストレージの仕組みが過負荷で、要求が時間切れになったことを示し、129も同じく過負荷を示します。ディスクの故障だけでなく、負荷やドライバーでも出ます。 そのため、出たら交換ではなく、増え方をモデルの材料にします。

2行目を最初に決めておいてください。 兆しが出たPCに検査と修復を自動でかけると、壊れかけたディスクに負荷をかけ、取り出せたはずのデータが取り出せなくなることがあります。

指示内容を固定する

この構成は生成AIを使わないので、プロンプトの代わりに、検出スクリプトの出力の決まりと、モデルと規則の設定を書いておきます。

【検出スクリプトの出力（1行のJSON、2,048文字以内）】
- v: 出力の形の版
- disks: ディスクごとに
    id, media(SSD|HDD), model, rd_unc, wr_unc, rd_total, wear, temp_max,
    poh_bucket（使われてきた時間を500時間ごとに丸めた値）, mfg（製造の年と週）
- ev: { "55": 累計, "98": 累計, "129": 累計, "153": 累計, "157": 累計 }
- 入れない値：今の温度、時刻、利用者の名前、ファイルの名前
- 管理者の権限で動かす（利用者の資格情報で動かさない）
- 必ず exit 0 で終わる（修復のスクリプトを動かさない）

【規則（replace_now）】
- ev の 55・98・157 が前日より増えた
- rd_unc または wr_unc が 7日で 1 以上増えた

【モデル】
- HistGradientBoostingClassifier(class_weight="balanced")
- 答え = 交換の理由が「ディスクの故障を確認」の交換の、前30日に入る日なら 1
- categorical_features = ["media", "model"]
- 欠けた値は埋めずに渡す

【優先順位】
- 順位の点 = predict_proba の 1 の確率 × 業務への影響の区分の重み（高 3 ／ 中 2 ／ 低 1）
- 一覧に出すのは replace_now と、点の上位 30 台

「今の温度と時刻を入れない」を明記しないと、毎日すべてのPCが報告を返します。 報告の仕組みは変化を前提にしているので、毎回変わる値は、意味のある変化を埋もれさせます。 温度は、最高温度だけを入れます。

class_weight="balanced" を付けるのは、故障の日が全体のごく一部だからです。 付けないと、すべてを0と答えるモデルが見かけ上よく当たります。この指定で、少ない側の重みが、件数に反比例して重くなります。

出力形式を固定する

ディスクごとに、次の形のJSONを作り、一覧とチケットへの添付にします。

{
  "device_name": "",
  "disk_id": "",
  "media": "SSD | HDD",
  "verdict": "replace_now | ranked | low_history | stale",
  "fail_prob_30d": 0.0,
  "priority_score": 0.0,
  "impact_class": "high | mid | low",
  "signals": [ { "name": "", "value_now": 0, "delta_7d": 0, "delta_30d": 0 } ],
  "last_report": "",
  "model_version": ""
}

1つ目の理由は、verdict で規則とモデルを分けて見せられることです。 replace_now は規則が出したもので確率は付かず、ranked はモデルの見込みです。担当者は、どちらの理由で一覧に出たかを最初に分かります。

2つ目は、signals で増え方を並べられることです。 確率だけでは、遠隔でつなぐべきか判断がつきません。どの値が7日・30日でどれだけ増えたかが並べば、つながずに判断できるPCが増えます。

3つ目は、stale で届いていないPCを分けられることです。 報告が14日以上届いていないPCは、見込みを出さずに stale にします。見込みが低いのではなく、値が古いだけです。

システムへ連携する

チケットへの添付は、問い合わせが登録されたときだけ行います。 問い合わせのPCの名前で日ごとの値を引き、30日分の推移の表と、そのときの verdict を添えます。問い合わせの無いPCのチケットを、この処理から作ることはしません。 交換の候補は一覧で人が見て、チケットは人が起こします。

Graph へは読み取りの権限だけで足ります。 スクリプトの割り当てや端末の操作の権限は、この処理に持たせません。値を読む処理と、端末を操作する処理を同じ資格で動かさないようにします。

人が確認する

人が見るのは、replace_now と上位30台だけです。 3,000台の全部を見る設計にすると、第10章の16.0時間には収まりません。

1. replace_now を先に見る … 確実な兆しの出たPCです。利用者に、その日のうちにデータの退避を頼みます
2. 上位30台の signals を読む … 増え方が続いているか、一度だけの増加かを見ます
3. 判断がつかないPCだけ遠隔でつなぐ … 値の推移だけで決められないものです
4. stale の台数を見る … 届かないPCが増えていれば、スクリプトの誤りか、使われていないPCです
5. 交換したら理由を正しく書く … 「ディスクの故障を確認」「念のため」を分けます。これが次の学ばせる答えになります

5番目を省かないでください。 外したディスクを検査して、本当に壊れていたかをチケットに書くと、見込みが当たっていたかを測れます。 書かないと、モデルは正しくなっていきません。

一覧は毎朝出ますが、見るのは週に2回で足ります。 replace_now だけは出た日に担当者へ知らせ、その日のうちに見ます。

目標は、120件をならして1件8分です。 遠隔でつなぐのは一部という想定で、それより多い月は、signals の並べ方が判断に足りていません。

例外に対処する

上から2行目が、最初の数か月でいちばん起きます。 機種やドライバーによって、返す値の項目が違います。機種ごとに、どの値が入っているかを最初に一覧にしてください。 値の入らない機種は、イベントの累計と規則だけで見ることになります。

記録を残す

• PCごと・ディスクごと・日ごとの値（届いた値と、埋めた値の印）
• 実行ごとの取得件数と、detectionState ごとの台数
• モデルの版（学ばせた期間、特徴の列、確かめる期間での成績）
• 毎日の出力のJSON（verdict、fail_prob_30d、priority_score）
• 担当者の判断（交換した・様子見・遠隔で確かめた）と、その理由
• 交換したディスクの検査の結果

成績は、上位30台のうち、30日以内に本当に故障したのが何台かで測ります。故障が全体のごく一部なので、全体の正解率では何も分かりません。一覧の上から見ていく使い方に合わせて、上位の当たり方を見ます。