月次運用報告に何を書くか｜そのまま使える項目テンプレート
月末。報告書のファイルを開く。カーソルが点滅する。
……今月、何かあっただろうか。障害は起きなかった。大きな改修もなかった。書こうとすると「特に問題ありませんでした」の一行しか出てこない。何も起きなかった月ほど、書くことがないように見えるのは、なかなかつらいものです。
でも実際には、問い合わせに答えて、パッチを当てて、バックアップの結果を毎朝見て、証明書の期限を気にしていたはずです。書けないのは、仕事がなかったからではありません。書く枠が決まっていないだけです。
結論：月次運用報告は、①稼働状況 → ②対応した件 → ③予防・保守作業 → ④気づいたこと・相談したいこと → ⑤来月の予定の5ブロックで固定します。毎月同じ枠を埋めるだけにすると、書く時間は30分ほどに収まります。そしていちばん効くのは④です。ここに書いた一行が、半年後の予算や工数の相談につながります。
一度テンプレートを作ってしまえば、翌月からは埋めるだけです。今日は枠を作るところまでで十分です。
何が起きているか：月次運用報告が書きにくい4つの理由
毎月これに時間がかかるのは、書き方が下手だからではありません。理由はだいたいこの4つです。
- 「異常なし」は、書くことがないように見える。保守運用の成果は、起きなかったことです。ところが起きなかったことは、そのままでは文章になりません。「今月は何もありませんでした」と書くと、読み手には「何もしていない月」と映ってしまう。この非対称が、報告をいちばん書きにくくしています。
- 記録が散らばっている。障害の経緯はチャットに、問い合わせはメールに、改修はチケットに、パッチ適用は自分の記憶に。月末に全部を集め直す作業から始まるので、書き始めるまでが重い。
- 誰に何のために出すのかが決まっていない。上長向けなのか、利用部門向けなのか、客先向けなのか。決まっていないと、毎月の粒度がぶれます。ぶれると、前月との比較ができず、書く側も読む側も手応えが持てません。
- 技術用語のまま書くと届かず、噛み砕くと薄く見える。「worker が枯渇して 502 が発生」と書けば正確ですが、読み手には伝わらない。「一時的につながりにくくなりました」と書けば伝わりますが、今度は自分の仕事が軽く見える気がしてくる。この板挟みは、かなり多くの人が感じているところです。
そして、実務的な背景もひとつあります。経済産業省の「システム管理基準」でも、運用は手順を定めて実施し、その記録を残して点検することが土台に置かれています。社内の監査や取引先からのセキュリティ確認で「運用状況はどう報告していますか」と聞かれる場面は、ある日突然やってきます。月次の1枚が積み上がっていれば、それがそのまま答えになります。
逆に言えば、この4つは枠を先に決めるだけで、ほとんど解けます。次から順に見ていきます。
月次運用報告に入れる5つのブロック
上から順に、思い出す順番でもあります。全部を厚く書く必要はありません。②と③は1行ずつ、④だけ少し丁寧に、くらいのバランスがちょうどいいです。
① 稼働状況：「何も起きなかった」を数字で残す
最初のブロックは、起きなかったことを目に見える形にするためのものです。ここがあるだけで、報告全体の印象が変わります。
入れる項目は3つで足ります。
- サービス停止：件数と合計時間。なければ「0件」と書く。この0件が、いちばん価値のある行です。
- 稼働率：停止時間から計算します。30日の月なら月間43,200分。停止が合計25分なら、(43,200 − 25) ÷ 43,200 = 約99.94%です。
- 監視アラートの発報件数：発報数と、そのうち本当に対応が必要だった数。
稼働率を出すときに、先に一度だけ決めておきたいことがあります。計画停止（メンテナンス）を停止時間に含めるかどうかです。含めない扱いにするのが一般的ですが、どちらでもよいので、決めて注記に書いておきます。これを決めずに毎月出すと、数字が比較できなくなります。
参考までに、稼働率の水準はこのくらいの感覚です（30日の月の場合）。
| 稼働率 | 月間で許される停止時間の目安 |
|---|---|
| 99.9% | 約43分 |
| 99.5% | 約3時間36分 |
| 99.0% | 約7時間12分 |
Googleの「Site Reliability Engineering」でも、まず目標値（SLO）を決めてから測ることが勧められています。契約でSLAが定められているなら、その水準に対して今月どうだったかを書きます。決まっていないなら、まず測るだけでかまいません。数ヶ月分たまると、それ自体が目標を決めるときの材料になります。
アラートの「発報したが対応不要だった数」も、地味ですが書く価値があります。誤報が毎月大量に出ている状態は、そのうち本物を見逃す前触れです。数字が残っていると、閾値を見直す相談がしやすくなります（→監視アラートの閾値の決め方）。
② 対応した件：障害・問い合わせ・改修を件数で
2つ目は、実際に手を動かした分です。ここは件数＋一行の内訳で十分です。一件ずつ詳しく書き始めると終わらなくなります。
- 障害：件数と、発生日・現象・対応状況を1行ずつ。恒久対策がまだなら「暫定対応済・恒久対策は◯月予定」と書きます。
- 問い合わせ：件数と、前月との比較。可能なら「操作方法／データ修正依頼／不具合」くらいの粗い内訳を付けます。
- 改修：件数と、何を直したか。
問い合わせの内訳は、あとから効いてきます。「操作方法」の問い合わせが毎月同じ画面に集中しているなら、それはマニュアルか画面のほうを直したほうが早い、という話につながるからです。日々の対応をどう記録に残すかは問い合わせ対応を「調査ログ」として残して資産にする方法にまとめています。
障害を書くときは、報告書の中で長く書きすぎないのがコツです。詳細は別紙にして、月次報告には1行だけ置く。振り返りをきちんと残す形はポストモーテムの書き方が、対応履歴そのものの残し方は障害対応を属人化させない「対応履歴」の残し方が使えます。
③ 予防・保守作業：見えない仕事を1行ずつ
3つ目が、いちばん書かれないのに、いちばん自分を助けるブロックです。誰にも気づかれない作業を、ここで1行ずつ表に出します。
書くのはこのあたりです。
- セキュリティパッチの適用：件数と実施日（→セキュリティパッチ適用の進め方）
- バックアップ：成功状況と、復元テストの実施有無・所要時間（→復元テストの手順）
- 証明書・ドメイン・契約の期限：直近で期限が来るものと、更新予定（→SSL/TLS証明書の期限切れを防ぐ更新と監視）
- 定期点検の実施状況：「日次 21/22日 実施」のように、実施できた日数で書く
「バックアップが毎日成功していた」は、書かなければ誰も知らないままです。そしてその状態を保つのに、あなたの確認が毎朝入っている。ここに一行あるかないかで、報告書の意味はかなり変わります。
定期点検を日数で書くと、抜けた日も見えます。隠さなくて大丈夫です。「7/13は障害対応のため未実施」と書けるほうが、記録として誠実で、あとから状況を思い出す手がかりにもなります。この記録の作り方は定期作業を手順化するで扱っています。
④ 気づいたこと・相談したいこと：ここがいちばん効く
4つ目が、この記事でいちばんお伝えしたいところです。報告書の価値は、ほとんどこのブロックに集まっています。
書くのは、まだ問題になっていないけれど、放っておくと問題になりそうなことです。書き方は3行で固定します。
- いま何が見えているか（数字で）
- このままだといつ困りそうか（時期で）
- いつまでに何を決めたいか（判断の期限で）
たとえば、こう書きます。
・ディスクの増加ペースが上がっています。
6月末 68% → 7月末 79%（月あたり約11ポイント）
このペースだと10月ごろに逼迫する見込みです。
ログ保存期間の見直しか、容量追加かの判断を、9月末までにいただけると助かります。「危ないです」ではなく、数字と時期と判断の期限を置く。これだけで、読み手は動きやすくなります。責めるためではなく、一緒に決めるための書き方です。
このブロックは、技術的負債を少しずつ表に出す場所でもあります。いきなり大きな提案書を書くのは大変ですが、月次報告に3行ずつ積んでいけば、半年後には経緯が残ります。「前から書いていた」という記録は、いざ判断が必要になったときに効きます（→技術的負債を「見える化」して優先順位をつける方法）。
サポート期限の話も、ここに置くのが向いています。たとえばPHPは公式サイトにバージョンごとのサポート期限一覧が公開されていて、PHP 8.1は2025年12月末でセキュリティサポートが終了しています。期限は公式の一覧で都度確認するのが確実です。棚卸しのやり方はEOL（サポート終了）の棚卸し手順に、更新そのものの進め方は古いPHPバージョンの上げ方とリスクにまとめています。
ひとつだけ気をつけたいのは、ここに書きすぎないことです。毎月5件も6件も並ぶと、読み手はどれも重く受け取れなくなります。多くて2〜3件に絞り、残りは自分の手元のリストに置いておくくらいがちょうどいいです。
⑤ 来月の予定：先に言っておく
最後は、来月やることです。ここは短くて構いません。
- リリース予定（日付と内容）
- 作業でサービスに影響が出る予定（再起動・メンテナンス）
- 月次で必ずやること（証明書確認・アカウント棚卸し・復元テストなど）
先に書いておくと、当日に「聞いていない」が起きにくくなります。作業予定の共有は、月次報告とは別に直前にも出すのが確実ですが、月初の段階で一度目に入れておいてもらうだけで、調整はかなり楽になります。
連休をまたぐ月は、ここに連休前後の予定も書いておくと安心です（→連休前にやる運用チェック）。
そのまま使える月次運用報告テンプレート
コピーして、自分の環境の名前に置き換えて使ってください。埋まらない項目は「なし」「該当なし」と書いて残すのがコツです。項目ごと消すと、翌月に思い出せなくなります。
■ 2026年7月 月次運用報告
対象システム: 社内業務システム / 公開サイト
作成: 2026-08-03 保守担当: 山田
※停止時間に計画メンテナンスは含みません
1. 稼働状況
サービス停止 : 1件 / 合計25分（7/13 03:10-03:35）
稼働率 : 99.94%（月間43,200分中 25分停止）
監視アラート : 発報18件（要対応3件 / 対応不要15件）
2. 対応した件
障害 : 1件
7/13 ディスク逼迫により一時的に応答が遅延。
不要ログの削除で復旧。恒久対策は9月に検討予定。
問い合わせ: 14件（前月11件）
操作方法8 / データ修正依頼4 / 不具合2
改修 : 3件
受注CSVの項目追加 / 帳票の日付表示修正 / ログイン画面の文言修正
3. 予防・保守作業
パッチ適用 : OS 2件（7/8）、ミドルウェア1件（7/22）
バックアップ: 毎日成功。復元テストを7/28に実施し、38分で復元完了。
期限管理 : www証明書は10/14期限（9月に更新予定）。契約更新は該当なし。
定期点検 : 日次21/22日実施（7/13は障害対応のため未実施）
4. 気づいたこと・相談したいこと
・ディスク使用率が 6月末68% → 7月末79%。このペースだと10月ごろ逼迫。
ログ保存期間の見直しか容量追加かの判断を、9月末までにお願いしたいです。
・PHPのバージョンがセキュリティサポート終了済みです。
更新の想定工数は5人日。11月ごろに時間をいただけると進めやすいです。
5. 来月の予定
・8/20（木）帳票改修のリリース
・8/26（水）パッチ適用のためサーバー再起動（深夜帯・影響時間10分程度）
・月次作業: 証明書確認 / アカウント棚卸し / 復元テストA4で1枚に収まる分量が目安です。読み手が1分で読み切れることを優先して、詳細は別紙に逃がします。
月末に集計しないための、日々の1行
報告書づくりがつらいのは、書く作業そのものより、月末に1ヶ月分を思い出す作業のほうです。ここを軽くすると、全体が一気に楽になります。
やることは、日々の記録に1行ずつ残しておくだけです。すでに何かしらの記録を付けているなら、その形式のまま使えます。
2026-07-13 障害 ディスク逼迫で応答遅延 03:10-03:35（25分）不要ログ削除で復旧
2026-07-14 問合 受注CSVの出力方法（操作方法）
2026-07-14 問合 6月分データの誤登録修正依頼（データ修正）
2026-07-22 保守 ミドルウェアのパッチ適用（影響なし）
2026-07-28 保守 復元テスト実施 38分で完了日付・種別・内容の3つだけ。種別を障害／問合／改修／保守／変更の5つくらいに固定しておくと、月末に数えるのが一瞬で終わります。
置き場所は、すでに毎日開いている場所にします。チャットの自分専用チャンネル、テキストファイル1枚、チケットのメモ欄。どこでも構いませんが、新しい場所を作らないのが続けるコツです。変更作業については変更管理台帳の付け方の台帳がそのまま集計元になります。
そして月末は、この1行たちを数えて、テンプレートに移すだけ。ここまで来ると、報告書は30分で書けます。思い出す作業がなくなるからです。
数字を書くときの注意がひとつ。件数は毎月同じ数え方で数えるようにします。「問い合わせ1通＝1件」なのか「1案件＝1件」なのか。先に決めて、テンプレートの末尾に注記しておくと、来月の自分が迷いません。
具体例：一人で社内システムと公開サイトを見ている場合
社内の業務システムと会社の公開サイトを一人で保守している、という状況で考えてみます。月次報告は上長へ提出。これまでは「今月も特に問題ありませんでした」の数行で済ませていました。
最初の月は、テンプレートを作るところからです。5ブロックの枠だけ用意して、思い出せる範囲で埋めました。①の稼働状況は「停止0件」しか書けず、②の問い合わせ件数は正確には分からないので「10件程度」と幅で書きました。それでも、A4の半分は埋まりました。何もない月だと思っていたのに、パッチを2回当てて、証明書を1枚更新していたことに、書きながら気づいたそうです。
2ヶ月目からは、日々の1行を始めました。チャットの自分だけのチャンネルに、対応するたび1行投げる。1件あたり10秒ほどです。月末の集計は、そのチャンネルを上から見て数えるだけで15分。前月比が出せるようになり、報告書に「問い合わせ 14件（前月11件）」と書けるようになりました。
4ヶ月目、④のブロックにディスクの増加ペースを3行で書きました。このときは何の反応もありませんでした。
6ヶ月目、同じ内容を数字を更新して書き続けたところ、上長から「これ、いつまでに決めればいいんだっけ」と声がかかりました。過去4ヶ月分の報告書に同じ数字の推移が並んでいたことが、判断の材料になったそうです。容量追加の予算が付き、逼迫する前に対応が終わりました。
印象的だったのは、上長のひとことだったといいます。「毎月これが来るようになって、何が動いているのか分かるようになった」。止まっていないから何も起きていない、と思われていた期間が、報告書によってようやく見えるようになった、ということでした。
影響：月次運用報告が続くと何が変わるか
- 相談ができるようになる。「危ないです」ではなく「このペースだと10月に逼迫します」と数字で言えると、予算や工数の話が具体的になります。判断するのは読み手の仕事なので、判断できる材料を渡すところまでが報告の役目です。
- 「前から書いていた」が残る。何かが起きたとき、月次報告に経緯が残っていれば、責任の話ではなく再発防止の話に進めます。
- 自分の仕事が自分で見える。これは実務的な効果と同じくらい大きいところです。何もない月だと思っていた1ヶ月に、確かに手を動かした記録が並ぶ。月の終わりに、それを自分で確認できるのは、静かに効いてきます。
- 引き継ぎ資料の芯になる。1年分の月次報告があれば、そのシステムで年間に何が起きるかがほぼ分かります。ゼロから引き継ぎ資料を書くより、はるかに早い（→退職・異動時の引き継ぎチェックリスト）。
- 聞かれたときに示せる。監査や取引先のセキュリティ確認で運用状況を尋ねられたとき、月次の積み重ねがそのまま答えになります。
- 見積もりの根拠になる。問い合わせと改修の件数が数ヶ月分たまると、保守にかかっている実際の工数が見えます。契約更新や改修見積もりを「保守目線」で出すときの観点にも、実測は強い材料です。
明日やること：集計ではなく、枠を作るところから
いきなり過去の集計をしなくて大丈夫です。明日できる、いちばん小さな一歩はこれです。
- テキストファイルを1枚作り、上のテンプレートの5ブロックの見出しだけをコピーする。
- 今月分について、思い出せることだけを埋める。埋まらない項目は「不明」でも「該当なし」でも構いません。
- ④のブロックに、いま気になっていることを1つだけ書く。数字と時期が分からなければ、文章だけでも大丈夫です。
- 記録用のメモを1枚決める（チャットの自分専用チャンネルでも、テキストファイルでも）。
- 明日から、対応するたびに「日付・種別・内容」を1行だけ残す。
1と3までなら、明日10分で終わります。完璧な1枚目を作る必要はありません。1枚目は、来月の自分が埋めるための枠を用意する作業です。そして2枚目からは、埋めるだけの作業になります。
「月次運用報告」チェックリスト
コピーして、自分の報告書に当ててみてください。全部そろえる必要はありません。
まず外せない最低ラインはこの3つです。時間がなくても、ここだけは押さえます。
- 【最低ライン】停止件数（0件でも）を書いたか
- 【最低ライン】予防・保守作業（パッチ・バックアップ・期限）を1行ずつ書いたか
- 【最低ライン】④に「気づいたこと・相談したいこと」を1件以上書いたか
次の項目は、余裕があるとき・より確実にしたいときに追加で確認します。当てはまらなければ飛ばして大丈夫です。
- 誰に向けた報告か（上長／利用部門／客先）を決めているか
- 稼働率の計算に計画停止を含めるかを決めて、注記に書いたか
- 件数の数え方（1通=1件か、1案件=1件か）を決めて注記したか
- 問い合わせ件数に前月比を入れたか
- 障害の詳細は別紙にして、本文は1行に収めたか
- 定期点検の実施状況を「実施日数／対象日数」で書いたか
- 未実施・抜けた分も隠さず書いたか
- ④に書いた項目に「数字」「困りそうな時期」「判断の期限」の3つが入っているか
- ④の項目を2〜3件に絞ったか（多すぎると読み手が動けない）
- 来月のリリース・再起動予定を書いたか
- A4で1枚に収まっているか
- 埋まらなかった項目を「該当なし」と残したか（項目ごと消していないか）
- 日々の記録（日付・種別・内容の1行）を残す場所を決めたか
- 過去分をすぐ見返せる場所に置いたか（→運用ドキュメントに最低限書くべき項目テンプレート）
全部に○が付かなくても大丈夫です。最低ラインの3つ、とくに「予防・保守作業を書いた」さえ言えれば、見えなかった仕事はもう紙の上に出ています。
よければ、こちらも
月次報告は、日々の記録とつながると一気に楽になります。
- 定期作業を手順化する｜日次・週次・月次を1枚のチェックリストに：③の予防・保守作業の中身は、この1枚がそのまま集計元になります。
- 問い合わせ対応を「調査ログ」として残して資産にする方法：②の問い合わせ件数と内訳を、月末に数え直さずに済ませる形です。
- 変更管理台帳の付け方｜いつ・誰が・何を変えたか残す：改修・変更の件数は、この台帳から拾えます。
- 技術的負債を「見える化」して優先順位をつける方法：④に何を書くか迷ったときの、材料の探し方です。
- 障害対応を属人化させない「対応履歴」の残し方：障害の1行を、あとから経緯までたどれる形にしておく方法です。
月次運用報告は、自分の成果を売り込むための書類ではありません。外から見えない仕事を、見える場所に置き直す作業です。
止まらなかった1ヶ月は、勝手に止まらなかったわけではありません。毎朝画面を見て、パッチを当てて、期限を気にしていた人がいたからです。それを書き残せるのは、実際にやってきた人だけです。
今日は、テンプレートの見出しを5行コピーするところまでで十分です。埋めるのは、来月の自分に任せてしまいましょう。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。