サーバー・ストレージ・クラウドの容量の使用量の推移から、逼迫する時期を機器ごとに見込み、増設と整理の判断が要るものを情報システムの月次の報告にまとめる

処理の起点を決める

毎月1日の朝6時に、定時で動かします。 月次の報告は第1週に部長へ出すので、月初の朝に下書きができていれば、担当者は判断だけに時間を使えます。

月の途中に、担当者が手で動かすこともできるようにします。 大きな移行が終わった直後や、新しいプロジェクトが始まった直後は、次の月初を待たずに見込みを出し直したいことがあります。手で動かしたときは、報告の下書きに「月中の出し直し」と書きます。

見込みは毎回作り直し、モデルを保存して使い回しません。 ボリュームごとに1本ずつの小さなモデルなので、120本を作り直しても数分で終わります。毎月その時点までの記録で作り直すほうが、増え方の変化に追いつきます。

入力データを集める

質を決めるのは、機器の台帳の「手配の期間」の列です。 見込みがどれほど確かでも、手配にかかる期間が分からなければ、いつまでに決めればよいかが出せません。 NAS、データストアのディスク、クラウドのディスク、バックアップの装置のそれぞれについて、過去の増設で見積もりから使えるまでに何週間かかったかを書きます。

予定の一覧も外せません。 来月に1TBのデータを移してくるなら、過去の推移には現れません。予定の容量は見込みに足し、報告に「予定を足した値」と書いて分けます。

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

Zabbix は、API で trend.get を呼びます。 ボリュームごとのアイテムの番号を台帳に持たせ、itemids に並べて、time_from と time_till で過去2年を指定します。履歴（1分ごとなどの生の値）ではなく傾向を使うのは、量を抑えるためです。 履歴と傾向をそれぞれ何日残す設定にしているかは、最初に自社の設定で確かめます。傾向が1年分残っていなければ、見込みはその分だけ後ろへずれます。

使用率ではなく使用量（バイト）で見込みます。 途中でディスクを増設したボリュームは、使用率が急に下がりますが、使用量は続いています。使用率で見込むと、増設を「整理した」と読み違えます。 上限は台帳と disk_total から取り、届く週は使用量と上限から計算します。

CloudWatch からは、1日ごとに縮めた値を取ります。 バケットの容量はもともと1日に1つの値で、統計は平均が有効とされています。サーバーのディスクも、1日の最大で取れば足ります。

AIへ渡す前に整形する

1. 週ごとの最大にそろえる … 1時間ごとや1日ごとの値から、週ごとの最大の使用量を作ります。バックアップの一時ファイルのように、週の中で増えて消えるものに備えて、平均ではなく最大を見ます
2. 欠けた週の扱い … 監視が止まっていた週は空のまま残し、前後の値で埋めません。num が少ない時間が続く週には印を付けます
3. 増設を見つける … 上限（disk_total や台帳の値）が変わった週を記録します。使用量の推移は続けて使います
4. 段差を見つける … 前の週から使用量が上限の5％以上下がった週を段差とし、段差より後の推移だけを見込みに使います
5. 短すぎる推移の扱い … 段差の後が12週に満たないボリュームは、見込みを出さずに「推移が短い」と印を付けます
6. 予定を足す … 予定の一覧の容量は、見込みの後で足します。モデルの中には入れません

4番目の段差を軽く見ないでください。 第3章の（c）がそのまま起きるところです。段差を含めたまま見込むと、片付けたボリュームほど「当面不要」に入ります。 片付けた後の増え方がもとに戻っていれば、早めに埋まります。

5番目で12週を下限にするのは、短い推移ほど傾きが振れるからです。 新しく作ったボリュームは、最初にデータを移した分だけ急に増え、その後は落ち着きます。最初の数週の傾きで延ばすと、極端に早く届く見込みが出ます。

AIに処理させる

この構成の「AI」は、ボリュームごとの先行きの使用量の見込みだけです。 届く週の計算、手配の期間との比べ、分類は決まった規則で出します。

見込みには、statsmodels の ETSModel を使います。 ETS は指数平滑化を、傾きや季節のある時系列へ広げたモデルの一族で、誤差の型と傾きの型を指定します。この構成では、誤差を加法（error="add"）、傾きを加法（trend="add"）にし、傾きを減衰させる（damped_trend=True）ものとさせないものの2つを作って、情報量の基準（AIC）の小さいほうを選びます。

減衰を比べるのは、増え方がずっと続くとは限らないからです。 移行の途中のボリュームは、移し終われば増え方が緩みます。減衰の無いモデルだけで延ばすと、移行中の速い傾きが1年先まで続く見込みになります。

見込みの幅は、結果の get_prediction で出します。 平均の見込みと予測の区間を計算する関数で、この構成では区間の上の側（90％の区間の上端）を「早め」として使います。 季節の型は付けません。週ごとの最大の使用量には、毎年同じ時期にくり返す動きがほとんど無いからです。年度末にだけ増える会計のボリュームのように季節のあるものは、台帳に印を付け、seasonal を加えたモデルを別に作ります。

2行目がいちばん起きやすい失敗です。 「整理の候補」を出すと、古いファイルを自動で消したくなります。バックアップの世代や、保存の期間が決まっている記録を消すと、容量よりはるかに大きな問題になります。

指示内容を固定する

この構成は生成AIを使わないため、指示は Python の設定ファイルに書きます。 何をどう見込み、どの規則で分けるかを、情報システム部の誰が読んでも分かる形で残すためです。

# 容量の逼迫の見込みの設定（capacity_forecast.yaml）

対象: 機器の台帳に載っているボリューム（社内 70、クラウドのディスク 35、バケット 15）
単位: 週（週ごとの最大の使用量、バイト）

取得:
  社内: Zabbix API trend.get（value_max, num）過去104週
  クラウドのディスク: CloudWatch CWAgent disk_used, disk_total（1日の最大）
  バケット: CloudWatch AWS/S3 BucketSizeBytes（StorageType ごと、平均）

前処理:
  段差: 前週から上限の5％以上下がった週。段差より後だけを使う
  下限: 段差の後が12週未満なら見込まず「推移が短い」
  欠け: 埋めない。num の少ない時間が続く週に印

見込み:
  モデル: ETSModel(error="add", trend="add", damped_trend=[True, False])
  選び方: AIC の小さいほう
  幅: get_prediction の 90％の区間（上端を「早め」とする）
  期間: 52週
  季節: 台帳で印のあるボリュームだけ seasonal="add", seasonal_periods=52

届く週:
  警告の水準: 台帳の値（既定は上限の85％）
  上限: 台帳の値または disk_total。バケットは費用の見直しの水準

分類:
  今月判断: 早めで警告の水準に届く週 − 手配の期間 が 今月末より前
  来月以降に判断: 上記が 3か月以内
  当面不要: それ以外

守ること:
  - 使用率ではなく使用量で見込む
  - 予定の容量はモデルの外で足し、「予定を足した値」と分けて書く
  - すでに警告の水準を超えているものは見込みより先に「超過中」と出す
  - データの削除や監視の設定の変更をしない。結果は報告の下書きに書くだけ

「すでに超えているものを先に出す」は、見込みの表に埋もれさせないためです。 超過中のボリュームは、見込むまでもなく今日の問題です。報告の最初の行に置き、閾値の警報が鳴っているかも並べて確かめます。

「予定を足した値と分けて書く」は、後で見込みの外れを調べるためです。 予定が中止になったのに足したままにすると、存在しない増え方で増設を決めることになります。

出力形式を固定する

ボリュームごとに、次の形のJSONと、それを一覧にした報告の表で出します。

{
  "volume_id": "nas01:/vol/share",
  "source": "zabbix | cwagent | s3",
  "run_at": "2026-10-01T06:00",
  "capacity_bytes": 0,
  "warn_level_bytes": 0,
  "latest_used_bytes": 0,
  "history_weeks_used": 0,
  "step_change_week": "",
  "model": { "trend": "add", "damped": true, "aic": 0.0 },
  "reach": {
    "warn_median_week": "2027-03-08",
    "warn_early_week": "2027-01-11",
    "cap_median_week": "",
    "cap_early_week": ""
  },
  "lead_time_weeks": 13,
  "decide_by": "2026-10-12",
  "category": "decide_this_month | decide_later | not_needed | over_now | short_history",
  "planned_add_bytes": 0,
  "flags": [],
  "owner_decision": { "action": "expand | cleanup | none", "reason": "" }
}

reach から category までは Python が埋め、owner_decision は担当者が書きます。

1つ目の理由は、届く週と判断の締め切りを分けて持てることです。 decide_by は「早めで警告の水準に届く週」から手配の期間を引いた日です。報告は decide_by の近い順に並べるので、手配に時間のかかる機器が上に来ます。

2つ目は、step_change_week と history_weeks_used で、見込みの根拠が分かることです。 「先月の片付けより後の8週で見込んだ」と分かれば、担当者は見込みの確かさを割り引けます。

月次の報告の表は、次の形にします。

報告の文は、「警告の水準に、真ん中の見込みで○年○月、早めの見込みで○年○月に届きます。手配に○週かかるため、○月○日までに判断が必要です」の文型に数字を埋めます。

システムへ連携する

Zabbix の API には、読み取りしかできない利用者でつなぎます。 監視の設定を変えられる利用者でつなぐと、スクリプトの誤りで警報の設定が消えるおそれがあります。CloudWatch も、指標を読むだけの権限にします。

増設の発注の仕組みや、ストレージの管理の画面にはつなぎません。 増設もデータの整理も、決めた後に担当者がこれまでどおりの手順で行います。

人が確認する

担当者は、毎月の報告の下書きのうち「超過中」と「今月判断」と「推移が短い」を必ず見ます。

1. 超過中を先に見る … 閾値の警報が鳴っているか、すでに手を打っているかを確かめます
2. 今月判断の根拠を見る … step_change_week と history_weeks_used で、どの推移で見込んだかを確かめます。移行の途中で傾きが速いだけなら、移し終わる時期を書き添えます
3. 予定と照らす … 予定の一覧に無い移行や新しいプロジェクトを知っていれば、その分を足すか引きます
4. 増設か整理かを決める … 整理で足りるなら整理の担当に相談し、足りなければ増設の見積もりに進みます。owner_decision に書きます
5. 推移が短いものを見る … 新しいボリュームは、作った目的と見込んでいた容量から、手で先行きを書きます

2番目を省かないでください。 見込みは推移を延ばしたもので、移行や一時的な取り込みで傾きが速いだけのボリュームも、今月判断に入ります。 そこを見分けるのが担当者の仕事です。

「来月以降に判断」と「当面不要」は、件数を流し見るだけにします。 全件を開く設計にすると、第10章の時間に収まりません。

目標は、120件をならして1件4分です。 当面不要のものは一覧で数秒、今月判断のものは推移の確かめと整理の担当への相談で20分前後かかります。

例外に対処する

上の2行は、運用の最初から起きます。 どちらも見込みを止める理由にはしませんが、取れなかった分を前の月の値で黙って埋めると、増えているボリュームが止まって見えます。

記録を残す

• 毎月取り込んだ使用量の記録（ボリュームごとの週ごとの最大）と、取り込んだ日時
• そのときの機器の台帳と予定の一覧の版
• ボリュームごとのモデルの型（減衰の有無）、AIC、見込みの値と幅
• 届く週、判断の締め切り、分類、付いた印
• 担当者が決めた増設・整理・見送りと理由（owner_decision）
• 翌月の実際の使用量と、前の月の見込みの幅を超えたかどうか

最後の行で、見込みの幅が狭すぎないかを確かめます。 90％の区間なら、幅の上を超えるボリュームは毎月1割前後のはずです。それを大きく超えるなら、段差の見つけ方か、減衰の選び方がずれています。