Windows ERROR_DISK_FULL (112) 対策：ディスク満杯エラーの解消と再構築編

【注意書き】本記事は、Windows の ERROR_DISK_FULL (112)（ディスク満杯）に関する一般的な情報提供を目的としています。実際の最適解は、ストレージ構成（ローカル/RAID/SAN/NAS/仮想化）、運用（ログ設計・監視・バックアップ）、権限/クォータ、業務停止許容度、復旧要件などの条件で大きく変わります。誤った削除や拡張操作は、復旧不能なデータ損失・停止時間の増大につながります。個別案件の設計判断や障害対応はリスクが高いため、必要に応じて株式会社情報工学研究所のような専門家へご相談ください。

　

空き容量はあるのに落ちる――ERROR_DISK_FULL(112)は「障害」ではなく「設計のツケ」

「またディスク満杯か……」と通知が鳴った瞬間、現場の頭に浮かぶのは“掃除”より先に止まった連鎖だと思います。ログが書けない→アプリが例外を投げる→再起動しても落ちる→調査ログも残らない。しかも上からは「とりあえず容量増やして」で済まされがち。でも、112 はディスクが小さいというより、運用と設計の境界が破綻したサインとして出ることが多いです。

Windows の ERROR_DISK_FULL (112) は Win32 エラーのひとつで、ファイル書き込み、ログ出力、データベースの拡張、更新処理などで「これ以上書けない」と判断されたときに返ります。ここで重要なのは、“見えている空き容量”と“実際に書ける余地”が一致しないケースが普通にあることです。

---

「空き容量があるのに満杯」になりやすい代表パターン

たとえば、エクスプローラー上では空きが数 GB あるのに、特定のサービスだけが 112 を返すことがあります。理由は「容量」だけでなく、書き込み先の制約や予約領域、クォータ、スナップショットなどが絡むからです。

分類	見え方	典型例	落とし穴
クォータ/権限	容量は空いて見える	ユーザー/フォルダ単位の上限、共有フォルダ制限	OS全体は空いていても、その主体は書けない
VSS/スナップショット	突然空きが減る	シャドウコピーが膨張、バックアップ連動	「削除したはず」が反映されず、増分が残る
ログ/Temp肥大	ジワジワ埋まる	IIS/アプリログ、ETW、ダンプ、更新残骸	“障害時ほど増える”ため、事故が事故を呼ぶ
ストレージ側の実容量	OS上は余裕に見える	薄いプロビジョニング、SANプール枯渇	“仮想的な空き”が嘘になる瞬間がある

つまり、112 を「片付けの問題」に矮小化すると、同じ事故が繰り返されます。ここから先は、112 を“再現できる現象”として捉え、どこで満杯判定が起きているのかを切り分けていきます。

　

112が出る瞬間を再現する――失敗するAPIとアプリ側の挙動を先に押さえる

プログラマー視点で一番つらいのは、「満杯です」と言われてもどの書き込みが失敗したのかが曖昧なことです。だからこそ、ここではロジックからではなく現場感で言います。“どのパスに、誰が、どんなサイズを書こうとして落ちたか”が分かれば、だいたい勝てます。

112はどこから返るのか（アプリに見える“失敗点”）

Windows アプリやサービスは、最終的にファイル書き込みや領域確保を OS に依存します。112 は、書き込み処理（例：ログ追記、DBファイル拡張、添付保存、テンポラリ生成）で OS が「もう無理」と判断したときに返るため、アプリ側では例外やエラーコードとして観測されます。重要なのは、“ディスク全体が満杯”とは限らないこと。書き込み先が別ボリュームだったり、Temp が別ドライブだったり、サービスアカウントのクォータだったりします。

---

切り分けの第一歩：失敗した「書き込み先」を確定する

ログ・例外メッセージ・イベントログに、次のどれかが残っていることが多いです。

• ファイルパス（例：C:\inetpub\logs、D:\AppData\work、%TEMP%）
• 対象ボリューム（C: / D: / 共有パス）
• サイズ感（ダンプ出力、Zip生成、DB拡張など“重い処理”の直前）
• 主体（サービス名、実行ユーザー、アプリプールID、タスク実行アカウント）

「でもログが書けないんだよ…」となるのが 112 の厄介さです。その場合、イベントログの“書き込み先とは別の場所”に手がかりが残ることがあります。具体的には、アプリケーションログ／システムログ／サービス固有ログ（IIS や SQL Server など）です。ログが残らない前提で、“OS側が残す情報”に寄せていくのが実務的です。

---

再現のしかた：わざと“容量の崖”を踏みに行く

本番でいきなり削除や拡張をする前に、可能なら検証環境や影響の小さい時間帯で、同等の処理を走らせて「落ちる瞬間」を捕まえます。たとえば、次のような観点です。

• 同じ処理（バックアップ、エクスポート、アップロード、月次バッチ）を実行する
• 書き込み先を変えずに実行する（Temp の場所も含む）
• 失敗直前のディスク残量、対象フォルダ増分、スナップショット増分を同時に見る

ここでの伏線は次章につながります。112 の一次対応は「空ける」ですが、空け方を間違えると“復旧不能”や“再発の加速”が起きる。だから、次は「止めない」「壊さない」一次対応の型を先に持ちます。

　

まず止めない一次対応――“今すぐ埋まる”状況でやっていいこと／ダメなこと

112 が出たとき、現場の心の声はだいたいこうです。
「分かった、消せばいいんだろうけど……何を消したら壊れるの？」
この疑いは健全です。というのも、ディスク満杯の現場では、削除＝復旧不能の引き金になり得るからです（誤削除、必要ファイルの欠落、更新ロールバック不能、ログ証跡の破壊）。

結論：一次対応の目的は「恒久解決」ではなく「安全な余地を作る」

一次対応のゴールは、いきなり根本対策をすることではありません。まずは、次の3点を満たす“安全な余地”を作ります。

1. サービスが最低限動ける（ログが出せる、DBが伸びる、Tempが作れる）
2. 原因調査のログが残る（調査のための出力先を確保）
3. 削除・拡張の判断材料が揃う（何が増えているかを見える化）

---

やっていいこと（安全性が高い順）

• “退避”を優先：削除ではなく、別ボリューム/別サーバへコピーしてから整理する（証跡と復旧性を残す）
• 明確に一時物と分かる出力：アプリの一時生成物、明示的なキャッシュ（設計上再生成できるもの）
• サイズの大きい単発ファイルの退避：ダンプ、Zip、エクスポート成果物など（何かを壊しにくい）
• ログのローテーション確認：肥大化ログは“消す”より先に、ローテ設定や出力先変更で増分を止める

やってはいけないこと（事故が増えやすい）

• よく分からないシステム領域の一括削除（更新残骸やロールバック情報を壊す、復旧が難しくなる）
• 本番DB/VMのディスクを勢いで縮小・移動（停止や破損のリスクが高い）
• “空くまで削る”（原因が増分型の場合、数時間後に再発するだけ）

---

判断を間違えないための「リスク表」

対象	一次対応	リスク	推奨
アプリ生成物	退避→必要分のみ残す	低（再生成可能なら）	まずここから
ログ	増分停止（ローテ/出力先）→退避	中（証跡喪失）	“消す”の前に設計を直す
システム領域	慎重に、根拠がある範囲だけ	高（更新失敗/起動不能）	知見がないなら触らない

ここまでが“止めない一次対応”の型です。次章では、実際に「どこが太っているのか」を数分〜十数分で掴むための、増分可視化（PowerShell/標準機能/ツール）の進め方に入ります。

　

「どこが太った？」を数分で特定――PowerShellとツールで増分を可視化する

一次対応で“少しだけ空けた”としても、原因が分からなければ同じ夜がまた来ます。ここでやるべきは、精神論ではなく計測です。現場の独り言で言うと、
「結局どのフォルダが増えてるの？前日比で何GB？」
これに答えられる状態にすると、112対応は一気に落ち着きます。

最初に押さえる観点：ボリューム／フォルダ／“見えない領域”

可視化は、次の順で進めるのが安全です。最初から深追いしないことがポイントです。

1. ボリューム単位：C: / D: / 共有先など、どこが詰まっているか
2. トップ階層：直下の大きいフォルダを洗い出す
3. 増分の正体：ログ、Temp、ダンプ、更新残骸、バックアップ生成物など
4. 見えない領域：VSS、システム予約、クォータ、ストレージ側制約

---

PowerShellで“まず当てる”（トップ階層のサイズ感）

GUIツールを入れられない環境でも、PowerShellだけで「当たり」をつけられます。例えば、対象ドライブ直下のフォルダサイズを概算で把握し、突出している箇所から深掘りします。実運用では、処理時間・権限・除外の調整が必要になるため、無理に全域を走査せず、まずトップ階層→問題箇所の流れで絞ります。

• ポイント：“昨日まで無かった増分”を探す（更新・バッチ・障害と相関が出る）
• ポイント：アクセス不可が出ても焦らない（権限の壁＝“別管理”の領域の可能性）

---

定番ツールで“深掘りを速くする”

フォルダ肥大の特定には、ツリー表示で大容量ファイルを一瞬で炙り出せるツールが有効です。代表例として WinDirStat や TreeSize Free などがあります（導入可否は組織ポリシー次第）。重要なのはツール名ではなく、「最大ファイル」「最大フォルダ」「拡張子別」の切り口で、増分の性質を把握することです。

たとえば、.log が急増しているならログ設計の問題、.dmp が増えているなら障害時のダンプ出力、.cab/.msu が多いなら更新残骸、というように次章以降の“伏線回収”につながります。

---

“可視化してから動く”が事故を減らす

ディスク満杯の現場では、削除や移動を急ぎがちです。でも、可視化してから動けば、「削除してはいけないもの」を避けられるし、対策が「掃除」から「再発防止」へ進みます。次章では、最頻出の原因であるログ肥大化を、IIS・アプリ・ETW・イベントログの観点で整理します。

　

伏線① ログ肥大化――IIS／アプリ／ETW／イベントログが静かに容量を食う

ディスクが埋まる原因で、最も“納得されやすい”のはログです。なぜなら、ログは正義であり、障害時ほど増えるからです。現場の心の会話で言うと、
「ログ切ったら、次の障害で詰むじゃん……」
そう感じるのは自然です。だからここでは、ログを否定せず、ログを“設計対象”として扱う方向で整理します。

IISログ：出力先とローテーションを把握する

IIS を使っている環境では、アクセスログが想像以上に太ります。特に、攻撃トラフィック（スキャン、ブルートフォース、脆弱性探索）が増えると、アプリが落ちていなくてもログだけが増え続けます。確認すべき観点は次の通りです。

• 出力先：既定のログディレクトリがシステムドライブにあるか
• ログ粒度：フィールドを増やしすぎていないか（詳細化＝容量増）
• 保持期間：削除ではなく、世代管理・退避（圧縮）・別ストレージ化ができているか

---

アプリログ：無限追記・例外ループ・再試行が“爆発”を生む

アプリ側ログは、設計が甘いと“静かに”増えます。典型は次の3つです。

1. 無限追記：ローテーションがなく、単一ファイルが肥大
2. 例外ループ：外部依存（DB/ネットワーク）障害で同じエラーを秒間多数回出力
3. 再試行の多重化：キュー処理やワーカーが同時に失敗し、同じログを量産

ここでのポイントは「ログを減らす」より、ログ出力が暴走する条件（例外ループ）を止めることです。ログを削っても、再試行が続けばすぐ埋まります。

---

ETW／トレース／ダンプ：障害時ほど“増える設計”

Windows では ETW（Event Tracing for Windows）や各種トレースが有効な一方、設定や障害条件次第で出力量が跳ねます。また、プロセスが落ちるたびにダンプを吐く設定（WERやアプリ側設定）があると、.dmp が一気に増えます。ここは証跡として重要なので、一次対応では消す前に退避が原則です。

---

ログの“落としどころ”：現場を守る設計にする

結論として、ログは「多いほど良い」でも「少ないほど良い」でもなく、運用可能な量に設計するものです。よく効く打ち手は次の通りです。

• ログの出力先をデータドライブへ分離（OSと同居させない）
• ローテーション＋圧縮＋退避（保管先を確保してから削除）
• 例外ループを防ぐレート制限（同一エラーの連続出力を抑える）
• 監視で“増分”を検知（容量が0になる前に止める）

次章では、ログと並んで多い原因であるTemp／キャッシュ／更新残骸を扱います。ここは「掃除」のように見えて、実は“壊しやすい地雷”が混ざります。

　

伏線② Temp・キャッシュ・更新残骸――掃除のつもりが壊す“落とし穴”まで

ディスクが逼迫すると、誰かが必ず言います。
「Temp消せば空くでしょ？」
……はい、空くことは多いです。ただし、ここには“危ない消し方”があります。現場エンジニアの健全な疑いとして、「いま消していいTemp」と「消すと壊れる領域」を分ける必要があります。

Tempは1か所ではない：システム／ユーザー／アプリごとに分裂する

Windows の Temp は単一ではありません。システム側、ユーザー側、サービスアカウント側、アプリ固有の作業ディレクトリに分かれます。112 を引き起こすのは、必ずしも C: 全体ではなく、特定のTemp先が詰まったケースもあります。だから、削除の前に「どの主体がどこをTempとして使っているか」を押さえます。

---

キャッシュ：“再生成できる”前提が崩れると事故になる

キャッシュは基本的に削除可能ですが、システムやミドルウェアによっては、キャッシュの破損が起動失敗や再同期地獄を招くことがあります。例えば、アプリがキャッシュ再生成の設計になっていない、または権限が足りず再生成できない、という事故です。削除＝再生成を試すので、影響時間と手順が必要です。

---

更新残骸：削除したい気持ちは分かるが、順序が重要

Windows Update やコンポーネントストア（WinSxS）は容量を取りますが、無闇に手作業で削るのは危険です。一般には、OSが用意しているクリーンアップ手段（ディスククリーンアップ、DISMのコンポーネントクリーンアップなど）を使い、ロールバックや更新整合性を壊さない形で整理します。ここは環境差が大きい領域で、運用ポリシーや停止許容度によって手順が変わります。

---

“掃除”を再発防止につなげる視点

Temp・キャッシュ・更新残骸の問題は、結局のところ「置き場が設計されていない」ことから起きます。例えば、

• バッチが成果物を永遠に同じ場所へ吐き続ける
• 更新のたびに一時ファイルが残り、削除されない
• 監視が“残量”しか見ておらず、“増分”を見ていない

ここまで来ると、個別のフォルダ掃除では限界が見えてきます。次は「見えない領域」として厄介なVSS／シャドウコピーに入ります（ここは誤操作すると影響が大きいので、判断基準を丁寧に書きます）。

　

伏線③ VSS／シャドウコピー――見えない領域が満杯を作る仕組みを理解する

ディスク満杯の調査で、いちばん精神を削るパターンがあります。
「大きいファイルも無い。ログも削った。なのに空きが戻らない……」
この“消えない容量”の代表格が VSS（Volume Shadow Copy Service） と、そこにぶら下がるシャドウコピー／スナップショット領域です。

VSSが増える理由：バックアップと復元のための「差分領域」

VSS は、バックアップやシステム復元、アプリケーション整合性スナップショットなどに使われます。仕組みとしては、ボリューム上の変更点（差分）を保持するための領域（シャドウコピーの保存領域）を使い続けます。ここで重要なのは、VSS の領域は普通のフォルダサイズ集計に出てこないことです。結果として「見える範囲は小さいのに、実際は満杯」に見えます。

---

まず確認すべきこと：VSSが原因かを“確定”する

原因を断定する前に、VSS の利用状況を確認します。Windows では、管理者権限で以下のような情報確認が可能です（運用ポリシーに従い、実行可否は判断してください）。

• シャドウコピー一覧：存在するスナップショットが多すぎないか
• シャドウコピー保存領域：割当（最大）と使用量がどれくらいか
• バックアップ製品との関係：バックアップがVSSを使っているか、保持設計が妥当か

ここでの現場の独り言はこうです。
「消したら空くのは分かる。でも、消していいのか？」
その疑いは正しいです。シャドウコピーを削除すると、復元ポイントや過去時点への復旧ができなくなり得ます。特に、ランサムウェア・誤削除・更新失敗など“復元が命綱”の状況では、勢いで削除するのは危険です。

---

対処の選択肢：削除／上限設定／保存先分離

VSS が容量を食い尽くしている場合、対処は大きく3種類です。選ぶ基準は「復元が必要な時間幅」「バックアップの実態」「停止許容度」です。

対処	効果	リスク	向く状況
シャドウコピー削除	即効で空く	過去復元が失われる	復元要件が低い／別バックアップが確実
上限（最大使用量）見直し	暴走を止める	保持世代が減る	復元は必要だが“無制限”は不要
保存先を別ボリュームへ	OS領域を守れる	設計変更が必要	C: が逼迫しがち／長期運用

---

ここでの結論：VSSは「削除技」ではなく「設計・運用の調整対象」

VSS が原因だった場合、単に空けるだけでは再発します。バックアップや復元の要件を踏まえ、上限・保持期間・保存先を設計し直す必要があります。ここから先は、さらに根が深い「構造問題」――パーティション設計やストレージの前提が崩れているケースに進みます。

　

構造問題の正体――パーティション設計・拡張・薄いプロビジョニングの罠

112 が繰り返される現場では、だいたい“掃除”ではなく構造が限界に来ています。ここでの心の会話はこうです。
「毎回深夜に削除してる。これ、いつまで続くの？」
その直感は当たっていて、根本は容量の置き方（どこに何が増える設計か）の問題であることが多いです。

まず前提：OS領域（C:）に“増えるもの”を置くほど事故る

Windows では、OS 自体がログ、更新、ダンプ、テンポラリ、サービスの既定出力先など、さまざまな“増えるもの”を抱えます。そこにアプリのログや成果物、DB、アップロードファイルまで同居させると、C: 逼迫が業務停止に直結します。C: は「壊れると全停止」になりやすいので、運用上は“守るべき領域”として扱うのが基本です。

---

設計の典型的な失敗パターン

• 単一ボリューム運用：OS・ログ・データ・バックアップ生成物が全部C:にある
• 出力先が未設計：ログやバッチ成果物の格納先が「とりあえず既定」
• 拡張不能な前提：物理/仮想/クラウドで拡張の手段と手順が決まっていない
• ストレージの実容量を意識していない：薄いプロビジョニングで“見かけの余裕”を信用している

---

拡張の考え方：増やす前に“増え方”を直す

ディスク拡張は有効な解決策ですが、ここで失敗しがちなのが「とにかく増やす」だけで終わることです。増え方（ログ設計、退避、ローテ、監視）を直さないと、結局同じ速度で埋まります。

また、拡張の方法は環境で変わります。物理RAID、仮想ディスク、SAN、NAS、クラスタ、どれも手順・リスクが異なります。例えば、仮想化環境では「仮想ディスクは拡張できても、OS側のパーティション拡張が別手順」「スナップショットやチェックポイントが残っていて拡張後の運用が重くなる」など、現場固有の地雷があります。

---

薄いプロビジョニングの罠：OSの空き≠ストレージの空き

ストレージ側（SANや仮想化基盤）で薄いプロビジョニングを使うと、OS からは大きなディスクに見えます。しかし実際のストレージプールが枯渇すると、突然書き込みが失敗し、結果として 112 や I/O エラーにつながることがあります。ここは“OSだけ見て安心”が通用しない領域です。

---

構造の改善案：分離・マウントポイント・退避先の用意

構造問題に対して、現実的な改善案は大きく次の方向です。

• ログ／Temp／成果物の出力先をデータボリュームへ分離（C:を守る）
• バックアップ生成物の置き場を別ストレージへ（同一筐体内で完結させない）
• 退避先を先に用意（緊急時に“移せない”が一番つらい）
• 増分が大きい処理の設計見直し（圧縮、分割、世代管理、上限設定）

ここまで来ると、112 は「掃除が足りない」のではなく、「運用の前提が崩れている」サインとして扱うべきだと見えてきます。次章では、再発防止を“運用とコード”に落とす――監視、容量計画、ログ設計、ジョブ設計の実務に進みます。

　

再発防止をコードと運用に落とす――容量SLO／閾値／自動退避の設計

ディスク満杯は、対処そのものよりも“説明コスト”が重い障害です。
「また容量？運用が悪いんじゃないの？」
と言われがちで、現場はやってるのに伝わらない。だから再発防止は、精神論ではなく合意できる指標と仕組みに落とすのがいちばん効きます。

容量SLO：残量ではなく「枯渇しない」状態を定義する

まず、容量に対して SLO（サービスレベル目標）を置きます。例としては「システムドライブは常にXGB以上の空きを維持」「増分が一定以上なら自動でアラート」「枯渇予測がN日以内なら計画対応」などです。重要なのは、残量の絶対値だけでなく“増え方（増分）”を見ることです。残量が20GBあっても、1日10GB増えるなら2日で死にます。

---

監視の観点：残量・増分・上位消費者・失敗兆候

監視は「C:の残量」だけだと弱いです。最低限、次の4点をセットにすると実務が回ります。

• 残量（絶対値）：閾値（例：%やGB）で警告
• 増分（傾き）：1時間/1日でどれだけ増えたか
• 上位消費者：ログ、Temp、特定ディレクトリの肥大を特定できる形
• 失敗兆候：ログ書き込み失敗、DB拡張失敗、更新失敗など“112の前兆”

ここでの“心の会話”はこうです。
「監視増やすと運用が増えるだけじゃない？」
その懸念も自然です。だからこそ、監視は“増やす”より事故を減らす項目だけに絞り、アラートは“行動が決まる形”にします。

---

行動が決まる形：ランブック（手順書）と自動退避

アラートが鳴ったときに、判断が毎回ゼロからだと疲弊します。そこでランブックを作ります。最低限、次を揃えると運用が回り始めます。

1. 確認順（どのコマンド／どの画面で何を見るか）
2. 退避手順（どこへ、どの種類のファイルを、どの優先度で移すか）
3. 削除の可否（消してよいもの／ダメなものの一覧）
4. エスカレーション（何分で誰に相談するか、停止判断の基準）

さらに成熟させるなら、ログや成果物の“退避”を自動化します。ここは、単にバッチで削除するのではなく、圧縮→別領域へ移動→保管期限→削除の流れにすると、証跡と安全性を両立できます。

---

技術と組織の接点：個別要件で最適解が変わる

ここまでの話は一般論として有効ですが、実務では要件が割れます。例えば、監査要件でログを長期保管しなければならない、復元ポイントを一定期間残す必要がある、停止できないので拡張手順が制限される、などです。つまり、最終的には「容量」「保管」「復旧」「停止許容」「コスト」のトレードオフになります。

次章では、ここまでの伏線を回収して、112 を「その場しのぎ」で終わらせず、再構築へ踏み切る判断基準と、一般論の限界を整理して締めます。

　

帰結――ディスクは「無限ではない依存関係」：112を起点に再構築へ踏み切る判断

ここまで読んで、「結局、掃除・監視・設計見直し……やること多いな」と感じたかもしれません。そう感じるのは自然です。なにせ ERROR_DISK_FULL(112) は、単なるストレージ不足ではなく、アプリ・OS・運用・バックアップ・監査要件といった“依存関係の綻び”が、最後に表へ出てくる形だからです。

だから結論はシンプルです。ディスクは無限ではない依存関係であり、112 は「今の仕組みのままでは、いつか必ず止まる」という合図です。ここで重要なのは、目の前の空き容量を作ることだけではありません。次に止めない仕組みへ、段階的に移行する意思決定です。

---

「その場しのぎ」で終わらせない判断基準

実務では、すべてを一気に作り直す必要はありません。ですが、どの段階で“再構築（設計変更）”に踏み切るべきか、判断軸は持っておくべきです。次の表は、112対応でよく使われる判断基準です。

状況	意味すること	推奨アクション
同じサーバで112が再発する	掃除では追いつかない増分がある	増分の源（ログ/Temp/VSS/成果物）を設計対象にする
C:逼迫が業務停止に直結する	OSと増えるものが同居している	出力先分離（ログ/Temp/成果物）と退避先を先に用意
バックアップ/復元要件が重い	VSSや保持設計が容量と衝突している	保持期間・上限・保存先の再設計（削除は最後の手段）
仮想化/SANで“見かけの空き”がある	ストレージ側プール枯渇の可能性	OSだけでなく基盤側の実容量・増分も監視対象にする
ログが証跡・監査に必須	“消せない”ので増える設計が致命傷になりやすい	ローテ・圧縮・退避・保管先（別ストレージ）を仕組み化

---

再構築の現実的ロードマップ（段階的に進める）

再構築というと大ごとに聞こえますが、現場で効くのは“段階的な分離”です。例えば次の順で進めると、停止リスクを抑えながら効果を出せます。

1. まず“増分を止める”：例外ループ、無限ログ、成果物の無期限保存などを止める
2. 次に“置き場を分ける”：ログ/Temp/成果物をC:から分離し、C:を守る
3. そして“退避と保管”：圧縮→別ストレージ→保持期限→削除の流れを作る
4. 最後に“監視と合意”：残量だけでなく増分、前兆を見て、行動が決まる運用へ

この順序には理由があります。112 は「止まったら困る」現場で起きやすく、いきなり大改修をすると逆に障害が増えがちです。だから、事故が増えない順番で進めるのが現実的です。

---

一般論の限界：ここから先は“条件”で答えが変わる

ここまでの対策は汎用性がありますが、最後に必ず壁が来ます。たとえば次のような条件が絡むと、同じ112でも最適解が変わります。

• ストレージ構成（ローカル/RAID/SAN/NAS、薄いプロビジョニング有無、冗長化）
• 停止許容（24/365か、メンテ枠があるか）
• バックアップと復元要件（復元ポイント、世代、監査証跡の保持期間）
• アプリ特性（DB拡張、Temp多用、ログ設計、バッチ生成物の大きさ）
• 運用体制（夜間対応の可否、エスカレーション、監視の受け皿）

つまり、最後は個別案件の要件定義と設計が必要です。ここを「とりあえず容量を足す」「とりあえず消す」で進めると、短期的には落ち着いても、長期的には停止リスクが積み上がります。

---

締めくくり：悩んだら“設計と復旧を同時に見られる相手”に寄せる

ERROR_DISK_FULL(112) の厄介さは、障害対応と設計変更が連続している点です。「今止めない」ための一次対応と、「次に止めない」ための再構築を、同じ地図で考える必要があります。

読者の方が、具体的な案件（どのデータを守るか、どこまで止められるか、どんな保管/復元が必要か、コストとリスクの線引き）で悩んだとき、一般論だけでは判断しきれない場面が必ず出ます。そのときは、株式会社情報工学研究所のように、データ復旧（最悪時の回収可能性）とシステム設計保守（再発しない構成）をセットで検討できる専門家へ相談することが、結果的に停止時間とリスクを減らす近道になります。

「まずは現状の増分の正体を整理したい」「C:逼迫を根治する分離案を作りたい」「VSSやバックアップ設計も含めて、止めない運用にしたい」――このあたりからでも十分です。現場の事情を踏まえた現実解を、一緒に組み立てるところから始められます。

---

【付録】現在のプログラム言語各種：ディスク満杯（ENOSPC/112）で壊れやすい点と注意点

最後に、プログラマー目線で「ディスクが満杯になったとき、アプリがどう壊れるか」を言語別に整理します。共通して言えるのは、“書けなかった”こと自体より、書けなかった結果として状態が中途半端になることが事故の本質だという点です。

---

共通の落とし穴（言語に依らない）

• 部分書き込み：書き込み途中で失敗し、ファイルが壊れる／末尾が欠ける
• バッファリング：flush/close までエラーが表に出ず、“成功したつもり”になる
• 一時ファイル方式の破綻：tempに書いてからrenameする設計でも、temp先が満杯だと失敗する
• ログの暴走：エラー処理がログ出力を増やし、さらに満杯を加速する
• リトライ地獄：再試行が多重化し、I/Oとログが増えて回復不能になる

---

C / C++

C/C++は、OSの低レベルエラーが比較的そのまま出ますが、逆に言うと扱いを間違えると壊れます。POSIX系では ENOSPC、Windowsでは GetLastError が 112 相当になる場面があります。

• 注意：write() が“要求サイズより小さい”部分成功を返すことがある（ループで書き切る設計が必要）
• 注意：stdio（fwrite等）はバッファに溜めるため、エラーが close() まで遅延することがある
• 実務ポイント：重要ファイルは「一時ファイルへ完全書き込み→fsync→rename」の原則を守る

---

C# / .NET

.NETは例外（IOException等）として表に出ますが、非同期処理・バッファリング・ログフレームワークが絡むと見落としが起きます。

• 注意：StreamWriter/BufferedStreamのエラーが Dispose/Close まで表に出ないことがある
• 注意：ログ（Serilog/NLog等）のシンクが失敗すると、別ログや例外ループで悪化しやすい
• 実務ポイント：例外時に“ログを書こうとして更に失敗”しないよう、ログ出力を抑制（レート制限）する

---

Java / JVM言語（Kotlin等を含む）

JavaはIOExceptionで検知できますが、エンタープライズ環境ではログ量と一時ファイルが問題化しやすいです（ローテ設定次第で巨大化します）。

• 注意：BufferedWriter/OutputStreamWriter等でエラーが close 時まで遅延することがある
• 注意：ログフレームワーク（Logback/Log4j等）の設定不備で無限肥大が起きやすい
• 実務ポイント：テンポラリディレクトリ（java.io.tmpdir）の置き場を設計し、監視対象にする

---

Python

Pythonは例外で扱いやすい反面、スクリプト運用だと“ちょっとした出力”が積み上がって事故になります。特にバッチ成果物やログ、CSV生成などが積み重なるケースです。

• 注意：例外処理でログを大量に出し、かえって増分を加速する
• 注意：tempfile利用でも、置き場（TEMP）が満杯だと当然失敗する
• 実務ポイント：生成物は世代管理・圧縮・退避を前提にし、成功後に“残す/消す”の方針を決める

---

Go

Goはエラーが戻り値で明示されるため堅牢に作れますが、ログやワーカー並列で失敗が同時多発すると急激に悪化します。

• 注意：並列処理が同時に失敗し、同時にログ出力・リトライして雪崩を起こす
• 注意：bufio.Writerは Flush までエラーが出ないことがある
• 実務ポイント：リトライは指数バックオフ＋上限＋同時実行制御（セマフォ等）で“雪崩”を止める

---

Node.js（JavaScript/TypeScript）

Node.jsは非同期I/Oが強みですが、満杯時はイベントループ上でエラー処理の設計差が品質差になります。

• 注意：streamのerrorイベント未処理がプロセス異常終了につながる場合がある
• 注意：ログ出力（ファイル、ローテ）を雑にすると、障害時に急増して悪化する
• 実務ポイント：エラーハンドリングを「書けない時は落ち着いて縮退」させる（例：ログ最小化、キュー停止）

---

PHP

PHPはWeb運用でIIS/Apache/Nginxのログと一体で増分が起きやすく、アプリ側のログやアップロードファイルが同居するとC:を圧迫しがちです。

• 注意：アップロード一時領域やセッション保存先が満杯で、アプリが不安定になる
• 注意：エラーログの肥大化が“攻撃トラフィック”で加速する
• 実務ポイント：セッション・アップロード・ログの置き場を分離し、保持設計と監視をセットで持つ

---

Ruby

Rubyも例外で扱えますが、ジョブ基盤やログ運用の設計次第でディスク圧迫が起きやすいです（特にバッチ成果物やログ）。

• 注意：例外時にログを大量出力して悪化しやすい
• 注意：一時ファイルを多用する処理（変換、圧縮）がTemp枯渇で失敗する
• 実務ポイント：成果物の保存ポリシー（世代、圧縮、退避）をコードと運用で固定する

---

Rust

Rustはエラー型で堅牢に組めますが、「安全＝壊れない」ではありません。ディスク満杯は外部要因であり、失敗したときに状態を中途半端にしない設計が必要です。

• 注意：write_allでも、flushや同期を意識しないと“確実に書けた”保証にはならない
• 注意：ログや成果物の肥大化は言語では防げない（設計と運用の領域）
• 実務ポイント：重要ファイルはatomic write（temp→sync→rename）を徹底し、失敗時はロールバックする

---

PowerShell / Bash などスクリプト

運用現場で最も“効く”のはスクリプトですが、同時に最も“増やしやすい”のもスクリプトです。ログ出力、成果物、コピーの退避などが、気づかないうちに蓄積します。

• 注意：リダイレクトやログ追記が無限に増える（ローテが無いと危険）
• 注意：エラー時の再試行が無制限だと増分を加速する
• 実務ポイント：実行結果の保存先、保持期間、成功後の削除/退避を“最初から仕様化”する

---

結局のところ、言語ごとの違いは「エラーの出方」や「ハンドリングの癖」であり、ディスク満杯を事故にしない本質は、状態の一貫性（中途半端を残さない）と、ログ/Temp/成果物の置き場と保持設計です。そして、その設計は個別案件の要件（停止許容、監査、バックアップ、構成）で最適解が変わります。

もしあなたがいま、具体的な案件・契約・システム構成の条件の中で「どこまで分離すべきか」「バックアップとVSSをどう両立するか」「停止せずに移行する道筋はあるか」と悩んでいるなら、一般論だけで抱え込むより、株式会社情報工学研究所のような専門家に相談して“条件に合った現実解”へ落とし込むほうが、結果的に早く安全です。