Windows 11の「ファイル履歴」機能をはじめて使ってバックアップを設定し、外付けSSD（Dドライブ）に保存しようとしたところ、「なぜかバックアップ先のDataフォルダに一切ファイルが書き込まれない…」というトラブルに遭遇しました。
コントロールパネル上は動いているように見えても、実際のパスを確認すると中身は空のまま。
D:\FileHistory\<ユーザー名>\<PC名>\Dataイベントログの解析やパス長チェック、設定の初期化など、AIにも相談しながらあらゆる対処法を試したものの解決せず……。
かといってサードパーティ製のバックアップソフトを使うのはセキュリティ面で不安があります。そこで最終的に「Pythonの標準ライブラリだけ」を使った自作バックアップツールに切り替えることにしました！
この記事では、今回行った泥臭いトラブル調査の全容と、Pythonで自作するに至った理由をご紹介します。
バックアップで使ったUSBメモリはソースネクストで購入したこちら↓です。
このバックアップツールでできること・できないこと
パソコンのバックアップには、大きく2種類あります。
| 種類 | 概要 | 例 |
|---|---|---|
| イメージ（システム）バックアップ | OSやインストール済みアプリも含めてまるごと保存。復元するとパソコンを丸ごと元の状態に戻せる | Windowsの「回復ドライブ」「システムイメージ」など |
| データバックアップ | 写真・文書・音楽などの「ファイル」だけを保存する | ファイル履歴、今回のPythonスクリプトなど |
「ファイル履歴」も今回のPythonスクリプトも「データバックアップ」です。
Windowsが起動しなくなった・アプリが壊れた、という場面の復元には対応していません。OSやアプリを復元したい場合は、「回復ドライブ」や「システムイメージ」を別途作成しておく必要があります。
トラブル解消のために試してみたこと（調査の記録）
「ただオンにするだけ」では一向にデータが保存されなかったため、以下のような手順で原因究明と対処を行いました。
① 「ライブラリ」の設定・見直し
Windows 11のファイル履歴は「ライブラリ」に登録されたフォルダやユーザーフォルダ（C:\Users\<ユーザー名>）が対象になります。
まずはエクスプローラーの表示設定を変更して「ライブラリ」を表示させ、バックアップしたいフォルダをインクルードしたり、新規ライブラリを作成して構成し直しました。
② パス長（260文字制限）オーバーの調査と除外設定
作業途中に「発生した操作はファイルの有効なデータ長を超えています。」というエラーが発生したため、Windowsのパス長制限（MAX_PATH）を疑いました。
PowerShellで以下のコマンドを実行し、240文字を超える長すぎるパスを探索。
Get-ChildItem -Path "C:\Users\<ユーザー名>" -Recurse -ErrorAction SilentlyContinue | Where-Object { $_.FullName.Length -gt 240 } | Select-Object FullName結果、anaconda3 や開発環境（Dockerボリューム等）の深い階層に極端に長いパスが大量に存在することが判明。これらを「フォルダの除外」に指定して再試行しました。
③ イベントビューアーでログの確認・分析
コントロールパネルの表示だけでは原因がわからないため、イベントビューアー（eventvwr.msc）を開き、FileHistory-Core や FileHistory-Engine のログをチェックしました。
ProtectedUpToTimeの項目が空（一度もバックアップが完了していない状態）であることを確認- エラーコード
15003や内部ステータスhc_stateid: 255などのログを検知
④ サービス停止＆設定ファイル・SSD側フォルダの完全初期化
設定ファイル（Configuration）の破損を疑い、以下の手順で構成のリセットも行いました。
- サービス画面（
services.msc）で 「File History Service」(fhsvc) を停止 C:\Users\<ユーザー名>\AppData\Local\Microsoft\Windows\FileHistory\Configurationフォルダを削除・リネーム- 外付けSSD側の
D:\FileHistoryフォルダも丸ごと削除して一からやり直す
それでも解決せず…サードパーティ製を使わなかった理由
ここまで徹底的に調査・リセットを行いましたが、結局 Data フォルダにまともにデータが書き込まれることはありませんでした。
通常であればここで市販ソフトや無料のサードパーティ製バックアップツールに頼るところですが、私は使いませんでした。理由はセキュリティ上の不安です。
- 大切なファイルや個人データへのフルアクセス権限をサードパーティ製アプリに渡すリスク
- バックグラウンドでの通信や動作が見えない不安
- フリーソフトなどの不要な広告・不要機能の同梱リスク
バックアップはデータを守るためのものなのに、それでセキュリティリスクを抱えては意味がありません。
「Python × 標準ライブラリ」で自作する選択
そこで辿り着いたのが、「Pythonで自分の必要な機能だけを持ったバックアップスクリプトを作る」という解決策です。
しかも、外部から追加パッケージをインストールする pip install も使わず、「Pythonの標準ライブラリのみ」で実装することにこだわりました。
標準ライブラリ自作のメリット
- 完全な安全性：外部通信も未知のコードも一切含まれないため、安全
- トラブルが起きない：
shutilやosモジュールを使った単純なファイルコピーなら、Windowsの複雑な「ファイル履歴」のバグに振り回されない - メンテナンスが容易：自分の好きなフォルダだけを、好きなタイミングで正確にバックアップできる
必要なツール（どちらも無料）
実際に動かすには以下の2つが必要です。
- Python（プログラム本体の実行環境）
- Visual Studio Code（VS Code／コードの編集・確認用エディタ）
Windows「ファイル履歴」と今回作った「Pythonツール」の違い
実際に作成したツール（usb_backup）と、Windows 11標準の「ファイル履歴」を比較すると、以下のような決定的な違いがあります。
| 比較項目 | Windows 11 「ファイル履歴」 | 今回作成した Python バックアップツール |
|---|---|---|
| 動作方式 | バックグラウンドサービス（fhsvc）が常駐・自動監視 | 必要な時だけ実行するCLIツール（手動またはタスクスケジューラ） |
| 保存形式 | FileHistory\...\Data 内にタイムスタンプ付き独自階層で保存 | バックアップ元のフォルダ構造のまま保存（エクスプローラーでそのまま閲覧・復元可能） |
| 透明性・ログ | 裏でエラーが起きても気づきにくく、サイレントに空のまま停止する | 実行ログ（logs/*.log）が明確に出力され、コピー/スキップ/エラーを一目瞭然で把握 |
| 除外設定 | GUIでの設定が複雑で、ライブラリ単位のざっくりした指定になりがち | config.json で対象パス・除外フォルダ（.git, .venv等）・除外パターンを明快に一括管理 |
| 堅牢性 | 長いパス名（260文字制限）や壊れたリンク・特殊権限で処理全体が止まる | エラーハンドリングと os.walk により、アクセス不能なファイルがあっても安全にスキップして完走 |
作成したPythonコードと詳しい使い方（Zenn記事のご案内）
具体的なPythonバックアップツールのソースコード全文や、設定ファイル（config.json）の書き方・詳しい使用方法については、別途 Zenn 記事 にて分かりやすく解説・公開しています！
実際のコードでは、外部ライブラリを一切使わずPython標準の os や shutil だけを利用し、差分コピー（更新日時・ファイルサイズ判定）・詳細ログ出力・柔軟な除外設定を実現しています。
AIを活用したコード作成の経緯
今回のスクリプトはすべて手書きしたわけではなく、AIコーディングツールの力を借りて作りました。
最初に投げたプロンプト
まず Cursor（AIコーディングエディタ）の無料枠（composer / Claude Sonnet Fastというモデル）に、以下のプロンプトを入力しました。
外付けUSBメモリにバックアップするプログラムを作りたい。
普段は、USBメモリはパソコンにつけない。毎日ではなく、私が必要だと思ったとき実行したい。
セキュリティ的にPythonの標準ライブラリだけ使う。
UIはこだわらなくていい。
バックアップするフォルダを指定したい。そのフォルダ内でも除外するフォルダを指定可能にしてバックアップ先の容量を節約したい。
logを出力したい。
Cursorでの生成 → 無料枠の制限に到達
Cursorは30分ほど考え続け（生成中のまま待機状態が長く続きました）、最終的にコードを出力してくれました。しかしその後、細かい修正を重ねるうちに無料枠のリクエスト制限に到達してしまいました。
Antigravity 2.0（無料枠）で仕上げ
Cursorの制限に達した後は、Antigravity 2.0（Googleが提供するAIコーディングアシスタント）の無料枠に切り替えて修正・仕上げを行いました。レスポンスが速く、細かい修正や質問への回答もスムーズで、最終的なコードの完成まで問題なく進めることができました。
メディアそのものが壊れていた話 ― ログをいくら読んでも解決しない障害があった
以下のUSBメモリ型SSDはうまくいったんですが
3年前に購入した未開封の別のUSBメモリでやったらエラーを吐くようになった。
[ERROR] コピー失敗: ...\test2.txt -> D:\backup\...\test2.txt
([WinError 1392] ファイルまたはディレクトリが壊れているため、読み取ることができません。)
最初はスクリプトのバグを疑った。ファイルシステムをFAT32からNTFSに変更してみたが、今度は別のエラーに変わっただけだった。
[Errno 22] Invalid argument: 'D:\\backup\\...\\DSCN6135.JPG'
エラーメッセージを頼りにログの出力を詳細化し、OSError から Windows 固有の winerror を拾うようにコードを直した。原因を切り分けるにはまず情報量を増やす必要がある、という判断自体は間違っていなかったと思う。
しかし、結論から言うと原因はコードのどこにもなかった。使っていたUSBメモリそのものが物理的に壊れていた。
メディアが壊れている場合、ログ解析やコードのデバッグは無意味
これが今回の一番の教訓だ。
書き込み先のメディアが物理的に不良を抱えている場合、どれだけログを詳細にしても、どれだけコードを読み直しても、根本原因には辿り着けない。エラーメッセージは「OSがどう失敗を報告してきたか」を教えてくれるだけで、「なぜ失敗したか」まで教えてくれるとは限らない。Invalid argument にせよ [WinError 1392] にせよ、これらは症状であって原因ではなかった。
同じような境界（数GB書き込んだあたり）で毎回症状が出る、コピー処理の内容を変えても再現する、といった「アプリケーション層の外側で何かが起きている」兆候が見えたら、ログ解析よりも先にメディア自体の健全性を疑うべきだった。今回は数時間分の調査時間を、原因の切り分けに使ってしまった。
メディアの健全性はどう検証するか
Windows標準の chkdsk は、ファイルシステムの論理構造（管理情報）の整合性チェックであり、ドライブが自己申告する不良セクタしか検出できない。今回のように「読み込みは成功するが中身が違う」という静かなデータ破損や、実容量以上の書き込みで起きる不整合は検出できない。
こうした物理メディアそのものの信頼性を検証するには、実際にデータを書き込んで読み返し、内容が一致するかをバイト単位で比較する専用ツールが必要になる。今回は H2testw というフリーソフトを使い、実際にディスク全域を書き込み検証した結果、表示容量の一部（1.3GB相当）で書き込んだデータと読み出したデータが一致しないことが判明した。
注意）H2testwはUSBメモリに対して非常に高い負荷（書き込み負荷）をかけるため、頻繁に行うべきではありません。購入直後や挙動がおかしい時の「一回限りの検証用ツール」として使うのが正しい用途です。定期的な「健康診断」として毎月・毎週行うのは絶対にNGです。
ツールの入手先には注意が必要
ここで一つ強調しておきたいのは、こうしたツールをWeb検索だけで探すのは危険だということだ。
「H2testw ダウンロード」で検索すると、非公式の配布サイトが検索結果の上位に出てくることがある。中には公式サイトのデザインを模した「ファンサイト」もあり、本家が明確に「うちの公式サイトではない」と否定しているケースまで確認した。フリーソフト経由でマルウェアを掴まされるリスクは、この手のジャンルでは常につきまとう。
対策として今回は、検索エンジンで直接探すのではなく、生成AI（Claudeなど）に「公式配布元はどこか」を尋ねる形をとった。AIであれば、公式ドメインと非公式ドメインを区別して案内してくれる可能性が高く、検索結果の見た目だけでは判別しにくい偽サイトを避けやすい。
ただし、これは万能な対策ではない。AIも学習データや検索結果の誤りをそのまま引き継いで、間違った情報を返す可能性はゼロではない。過信は禁物で、AIが案内した先が本当に公式ドメインかは自分の目でも確認する、複数の情報源を照らし合わせる、といった慎重さは変わらず必要だ。それでも「検索結果の上位表示だけを信じる」よりは安全な一手にはなる、という程度の位置づけで捉えるのがいいと思う。
具体的な入手URLや操作手順はここでは割愛する。ダウンロードページの構成やUIはバージョンアップで変わることもあるため、実際に試す際はその時点でAIに確認するのがよい。
ダウンロード後の実行前チェックについて
余談だが、ダウンロードしたexeを実行する前に、セキュリティソフトでスキャンしておくのが一般的な推奨だ。ただしこの点も一言補足しておきたい。
「ファイルを個別に指定してスキャンする」という操作は、セキュリティソフトのUIやバージョンによって手順が変わりやすく、必ずしもすべての環境で同じ手順が使えるとは限らない。仮に個別スキャンの導線が見当たらなくても、多くのセキュリティソフトはリアルタイム保護機能を持っており、ファイルを実行した瞬間に自動でスキャンが走る仕組みになっている。神経質に個別スキャンの手順を探すよりも、リアルタイム保護が有効になっているかを確認しておく方が実用的かもしれない。
得られた教訓
今回の一件から、バックアップ運用について次のことを意識するようになった。
- エラーが特定の書き込み量付近で再現するなら、まずメディアを疑う。 コードのバグを疑うのはその後でいい。
- 新品・未使用のフラッシュメモリでも、長期間の未通電保管は劣化要因になる。 今回使ったUSBメモリは3年前に購入して未開封のまま保管していたものだった。NANDフラッシュは電荷を使ってデータを保持する性質上、保管期間中にも自然に劣化が進む。
- バックアップ用メディアは、本番投入前に一度書き込み検証してから使う。 特に無名メーカーの安価な製品や、長期間保管していたものは要注意。
- ツールの入手元は検索結果の見た目だけで判断しない。 信頼できる情報源（AIへの確認を含む）と組み合わせて、公式配布元かどうかを慎重に見極める。
バックアップスクリプト自体の品質を上げることと、それを書き込む先のメディアの信頼性を確保することは、別軸の話だった。今回はその当たり前のことを、時間をかけて再認識する結果になった。
まとめ：Windowsのバグに悩まされるなら「標準機能＋Python自作」が一番安全！
Windows 11のファイル履歴は非常に便利な機能に見えますが、ひとたび裏でエラーが起きると原因特定が難しく、時間が無駄になってしまいます。
サードパーティ製ツールを入れるのが不安な方は、ぜひ「Python標準ライブラリでの自作」を試してみてください。シンプルですが、一番安全で確実なバックアップ環境が作れますよ！
この記事を書いたイチゲを応援する（質問でもokです）
Vプリカでのお支払いがおすすめです。
