個人開発者のバックアップ戦略 (3年分のコードを守る)
個人開発のコードと環境を失う日は突然来る、その備えを最初から作る
個人開発を1年以上続けると、コード以外に「ローカル設定 / .env / ドキュメント / メモリ / ノウハウ」が積み上がり、PCクラッシュ時の復旧コストは数週間-数ヶ月分の作業時間に相当します。私は OneDrive 同期から Google Drive 一本化の自動バックアップに切り替え、毎日03:00に node_modules/dist/playwright-profile を除外した約600MBアーカイブを Google Drive にアップロード、30日 FIFO で世代管理する運用に落ち着きました。月コスト¥0 (無料15GB枠内) で、別マシンで24時間以内に復旧できる体制です
結論を先に書きます。個人開発を1年以上続けると、コード以外に「ローカル設定 / .env / ドキュメント / メモリ / ノウハウ」が積み上がり、PCクラッシュ時の復旧コストは数週間-数ヶ月分の作業時間に相当します。私は OneDrive 同期から Google Drive 一本化の自動バックアップに切り替え、毎日03:00に node_modules/dist/playwright-profile を除外した約600MBアーカイブを Google Drive にアップロード、30日 FIFO で世代管理する運用に落ち着きました。月コスト¥0 (無料15GB枠内) で、別マシンで24時間以内に復旧できる体制です。本記事ではその実装と、3年運用して見えた業界統計との比較、3-2-1戦略の現実的な実装を共有します。
業界の前提として、Backblaze の Drive Stats レポート (四半期更新、25万台以上のHDD観測) によると、家庭/個人用ストレージのHDD年間故障率 (AFR) は約1.5-2.5%の範囲で推移しており、3年間使い続けると累積故障確率は5-8%程度まで上がります。SSDは故障率は低いが書き込み寿命の制約があり、突然死のリスクはゼロではありません。個人開発者にとってPC破損は「いつかは起こる」ことが前提で、復旧コストを最小化する設計が事業継続性の核になります。
あなたが個人開発で複数のプロジェクトを抱えているなら、PCクラッシュ時の備えは最重要事項です。コードは GitHub に push しているから安心、と思っているかもしれませんが、ローカル設定、.env ファイル、node_modules の一部の状態、ドキュメント類は GitHub に上がっていません。私はある時点でGoogle Drive一本化の自動バックアップ運用に切り替え、3年分のコードと環境を守れる体制を作りました。実装と運用ノウハウを共有します。
OneDrive 併用時代の問題
初期の私のバックアップは OneDrive 自動同期に任せていました。OneDrive をデスクトップに紐付け、デスクトップにプロジェクトフォルダを置けば自動で同期される、という仕組みです。シンプルで便利でしたが、いくつか問題が発生しました。
第一に、node_modules が毎回同期対象に含まれ、容量が無駄に膨らみました。1プロジェクトあたり 500MB以上の node_modules がクラウドにアップされ続けるのは非効率です。第二に、同期競合が頻発しました。ローカルでファイルを書いている最中に同期が走ると「競合ファイル」が複数生成され、どれが最新か分からなくなる現象です。第三に、有料プランの容量を圧迫しました。
Google Drive 一本化への切替
2026年5月、バックアップ運用を Google Drive 一本化に切り替えました。OneDrive 自動同期を停止し、自前のバックアップスクリプトで毎日03:00に Google Drive にアップロードする形に変更しました。これにより、同期競合がゼロになり、容量も管理しやすくなりました。
新しい構成は以下の通りです。第一に、毎日03:00に Windowsタスクが backup-all.mjs を実行。第二に、対象フォルダを zip 形式で圧縮 (PowerShell の Compress-Archive を使用)、node_modules/dist/playwright-profile/local-cache は事前のステージングコピー段階で除外。第三に、生成したアーカイブを Google Drive (Claude-PC-Backups フォルダ) にアップ。第四に、アップ成功後、ローカルのアーカイブを削除。第五に、Google Drive 側で FIFO 30件を維持 (古いものは自動削除)。
除外設定の落とし穴 — local-cache を含めない
バックアップ対象の除外設定で、最初に踏み抜いた罠が「local-cache」フォルダの再帰圧縮でした。バックアップシステム自身が生成する圧縮ファイルが C:/AI_WORK/backup-system/local-cache/ に一時保存される構造だったのですが、バックアップ対象 C:/AI_WORK 全体を圧縮しに行くと、自分自身が生成した圧縮ファイルも含めて再圧縮しようとして、アーカイブが無限に膨らむバグになっていました。
修正は単純で、除外リストに local-cache を明示的に加えるだけです。具体的にはステージング用の一時フォルダに対象ファイルを robocopy /XD local-cache node_modules dist playwright-profile で除外コピーした後、powershell Compress-Archive -Path "<temp>\*" -DestinationPath "<output>.zip" -Force で圧縮。これでアーカイブサイズが約 8GB から約 600MB まで圧縮され、Google Drive アップロード時間も大幅短縮されました。
復元手順を定期的にテストする
バックアップで最も危険なのは「バックアップを取っていたが、復元できないことが本番障害時に判明する」パターンです。私は3ヶ月に1度、テスト用の仮想マシンで「バックアップから完全に環境復元できるか」をテストしています。手順は概ね以下です。
# 1. Google Drive から最新アーカイブをダウンロード
gdrive download --id [FILE_ID]
# 2. 解凍 (PowerShell)
Expand-Archive -Path .\backup-20260518-030002.zip -DestinationPath C:/AI_WORK_RESTORE
# 3. 各プロジェクトで npm install
cd C:/AI_WORK_RESTORE/ai-pick && npm install
# 4. .env を別途復元 (.env はバックアップ対象外、別途暗号化保管)
cp /path/to/encrypted/.env.gpg C:/AI_WORK_RESTORE/ai-pick/.env
gpg --decrypt .env.gpg > .env
# 5. 動作確認
npm run dev3ヶ月に1回のテストで、何度か「あれ、復元が想定より複雑」というケースを発見しました。.env の暗号化保管を別ルートにしたり、npm install の競合パッケージを記録したり、復元手順をドキュメント化し続けることが大事です。
個人開発の継続性はバックアップで決まる
個人開発で1年以上同じプロジェクトを続けると、コードだけでなく「環境設定」「ドキュメント」「ノウハウ」が積み上がります。これらが失われると、復旧に数週間-数ヶ月かかります。Google Drive 一本化の自動バックアップは、月コストゼロ (Google Drive 無料15GB枠で十分) で、復元の安心感を大きく高めます。
個人開発者として、バックアップは「面倒だがやるべきこと」ではなく「事業継続性の保証」と捉えるべきです。私の3年分のコードは、PC が突然壊れても24時間以内に別マシンで動かせる状態になっています。
運用基盤の作り方は技術ログ、リスク管理の判断はビジネスカテゴリに追記しています。
業界で標準とされる 3-2-1 バックアップ戦略
個人/事業者向けバックアップ戦略の業界標準は CISA (米国サイバーセキュリティ・インフラセキュリティ庁) のガイドライン でも推奨されている「3-2-1 ルール」です。データの**3つのコピー**、**2種類の異なる媒体**、**1つは遠隔地**に保管する設計原則です。
個人開発のスケールに落とし込むと、私の運用は以下のようにマッピングできます。
- コピー 1: ローカル作業用 (C:\AI_WORK のオリジナル)
- コピー 2: GitHub プライベートリポジトリ (バージョン管理 + 履歴付き)
- コピー 3: Google Drive (毎日03:00自動アーカイブ、30日FIFO)
- 媒体の分散: ローカルSSD と クラウドオブジェクトストレージ で異なる物理層
- 遠隔地: Google Drive のデータセンター (国内/海外複数リージョン分散)
厳密には GitHub と Google Drive の両方がクラウドなので「2種類の媒体」が完全には成立しませんが、個人開発のリスク許容度では現実的な落とし所です。完全な物理分離 (例: 外付けHDDを定期的に金庫に保管) は運用負荷が高く、私の規模では費用対効果が低いと判断しました。
Google Drive 無料15GB枠の運用設計
Google Drive の無料枠は15GB、Google ワンドライブ (有料) は ¥250/月で100GB。私は無料枠内で運用するために、アーカイブサイズと保管世代数を意図的に絞り込んでいます。
| 項目 | 設定値 | 理由 |
|---|---|---|
| アーカイブ対象 | C:/AI_WORK + Claude memory | 事業継続性の核、約2-5GB |
| 除外フォルダ | node_modules / dist / playwright-profile / local-cache | npm install で再生成可、巨大化 |
| 圧縮 | zip (PowerShell Compress-Archive) | Windows標準、追加ライブラリ不要、Expand-Archive で展開容易 |
| 1アーカイブサイズ | 約500-700MB | 除外後の実サイズ |
| 保管世代 | 30日 FIFO | 15GB / 0.6GB ≒ 25世代、安全マージン込み |
| 合計使用量 | 約15-21GB (現状の15GB枠ギリギリ) | 枯渇したら有料プラン or 保管世代減 |
30日 FIFO は googleapis Node.js クライアントで実装しています。アップロード成功後、ファイル一覧を取得して created_time 順にソート、31番目以降を削除する手順です。これは Google Drive 公式API で正式にサポートされている操作なので、規約上の問題はありません。
除外設定の落とし穴 — 私が踏んだ3つの罠
バックアップ対象の除外設定は、運用初期に必ず躓きます。私が実際に踏んだ罠を共有します。
罠 1: 自己再帰圧縮
本文中で触れた通り、バックアップシステム自体が生成する圧縮ファイルが local-cache に一時保存される構造で、これを除外しないとアーカイブが指数関数的に膨らみます。1日目 600MB、2日目 1.2GB、3日目 2.4GB ... と倍々で増えるバグです。
罠 2: 隠しファイル/シンボリックリンク
.git/ 配下のオブジェクトファイル、.next/cache/、.vscode/ のヒストリーファイルは項目数が膨大で、圧縮時間が長くなります。.git を残すべきか除外すべきかは判断が分かれますが、私は「GitHub に push 済みなので除外、ローカル.git は復元時に git clone で取り直す」運用にしました。.next や .vscode/history も同様に除外しています。
罠 3: .env と secrets の扱い
API key や本番DB パスワードが含まれる .env ファイルは、そのまま Google Drive にアップすると不安が残ります。私は .env を gpg で対称暗号化したものを別フォルダに保管し、復元時にパスフレーズで復号する運用にしました。gpg --symmetric --cipher-algo AES256 .env で暗号化、復元時は gpg --decrypt .env.gpg > .env。パスフレーズは Bitwarden 等のパスワードマネージャに保管。
復元テストを3ヶ月に1回回す理由
バックアップ運用で最も重要なのは「**取れていること**」ではなく「**復元できること**」です。Backblaze の バックアップ戦略レポート でも、「バックアップを取っているが復元したことがない」状態が最大のリスク要因として挙げられています。
私の運用では3ヶ月に1度、テスト用の仮想マシン (Hyper-V or VirtualBox) で完全復元テストを回します。手順を整理すると以下です。
- Google Drive から最新アーカイブをダウンロード (gdrive CLI or Web UI)
- PowerShell の
Expand-Archiveで C:/AI_WORK_RESTORE 配下に展開 - 各プロジェクトで npm install (除外していた node_modules を再生成)
- .env を別途復元 (gpg 復号)
- 各プロジェクトの動作確認 (npm run dev / pm2 起動)
- 所要時間と詰まったポイントを記録
これを3年運用してきて、「あれ、想定より復元が複雑」というケースを何度か発見しました。Node.js のバージョン依存、グローバルツール (pm2 / playwright / electron-builder) のインストール、Windows タスクスケジューラの設定、Discord webhook URL の再設定 ... 復元手順は単純な「展開して動かす」だけではないので、ドキュメント化して更新し続けることが復元時間を短縮します。
個人開発者が押さえるべきバックアップの判断軸
個人開発でバックアップ運用を組むときの判断軸を、コストと復旧時間で整理します。
| 戦略 | 月コスト | 復旧時間 (PC破損→別マシンで稼働) | 誰向け |
|---|---|---|---|
| GitHub のみ | ¥0 | 1-3日 (環境再構築から) | 初学者、副業始めたて |
| GitHub + Google Drive (無料枠) | ¥0 | 4-12時間 | 個人開発1年目-2年目 (私の現運用) |
| GitHub + Google Drive 有料 + 外付けHDD | ¥250-500 | 2-6時間 | 個人開発3年目以降、収益化済 |
| NAS + クラウド + オフサイト | ¥1,000-3,000 | 1-3時間 | 法人化視野、複数人開発 |
個人開発の収益規模に対して過剰なバックアップ投資は本末転倒です。月コストはMRR (月次経常収益) の数%以内に抑える、というのが私の判断基準です。MRR 1万円の段階で月¥500のバックアップ投資は適正範囲、MRR 1,000円の段階で月¥1,000のNAS投資は過剰、というイメージです。
個人開発の継続性は「コードを書く時間」だけでなく「事業継続性の保証」によって決まります。バックアップ運用は地味で目立たない作業ですが、PC破損や災害が起こったときに「24時間以内に別マシンで開発再開できる」という安心感は、長期的なメンタル維持にも効きます。
運用基盤の作り方は 技術ログ、リスク管理の判断は ビジネスカテゴリ に随時追記しています。
筆者: GRAMSHIFT — 個人開発SaaS を3年継続中、Google Drive 一本化バックアップ運用で復元テスト3ヶ月毎実施。
私の構成図: 3-2-1 戦略の個人開発スケール実装
業界標準の 3-2-1 バックアップ戦略 (3コピー / 2媒体 / 1遠隔地) を、個人開発スケールに最適化して実装した構成を図にすると以下のようになります。本体データ + ローカル zip + Google Drive の 3 層構成で、PC 物理故障・ランサムウェア感染・うっかり削除の 3 シナリオを全部カバーしています。
この設計の核は「ローカル zip を Google Drive に成功裏にアップした時点で本来のソース以外を 1 つに集約する」点です。Google Drive を Single Source of Truth として扱い、ローカル一時 zip は容量節約のため自動削除します。これで PC のディスク使用量を肥大化させず、リモートに常に最新のフルバックアップが残る状態を維持できます。
実際の Discord 通知 (毎日 03:00 のバックアップ完了)
設計図だけでなく、実際に Discord に届く通知も残しておきます。毎日 03:00 に Windows タスクスケジューラ経由で backup-all.mjs が起動し、完了時に webhook で #gramshift-alerts チャネルに以下の通知が届きます。
通知の内容で実用上効くのは「ローカル zip のサイズ」と「Drive アップロード成功の絵文字」「履歴ローテ削除件数」の 3 つです。サイズが前日と比べて極端に増減していれば異常 (大量データ追加 or 削除ミス)、Drive アップロード失敗なら即対応、ローテ削除件数で 30 日 FIFO が動いているか確認できます。1 通の通知でバックアップ運用の健全性を 5 秒で判定できる設計です。
関連記事
以下の記事も同じ文脈で書いています。
個人開発者のバックアップ自動化 5 ステップ
個人 PC のバックアップを自動化する具体手順 (Google Drive 一本化、30 日 FIFO)
- バックアップ対象を決める: C:\AI_WORK と Claude memory (~/.claude/projects) を最重要対象に設定。node_modules / dist / playwright-profile / logs を除外
- 圧縮スクリプトを作る: PowerShell Compress-Archive で zip 化、ファイル名に YYYYMMDD タイムスタンプを付ける
- Google Drive 連携: Google Drive API の OAuth 認証を一度通して、refresh_token を保存。バックアップ毎にトークンで自動アップロード
- Windows タスクスケジューラ登録: 毎日 03:00 に backup-all.mjs を起動するタスクを登録。失敗時のリトライ・通知も設定
- Discord 通知の組み込み: webhook で完了/失敗通知を Discord に送る。スマホで即気付けるようにし、Drive アップ失敗時はローカル zip を保持
よくある質問
OneDrive と Google Drive どちらを選ぶべきか?
本記事の運用では Google Drive 一本化を選択。OneDrive は同期競合トラブルが頻発した経験あり、Drive は単純な「アップロード/ダウンロード」の API がシンプルで個人スクリプトに組み込みやすい。
30 日 FIFO で本当に足りるか?
個人開発スケールでは過去 30 日分あれば「うっかり削除」「マルウェア感染」「PC 物理故障」の主要 3 シナリオはカバー可能。それ以上の保持期間が必要な場面は実体験では未経験。
OAuth トークンが期限切れになったらどうなるか?
refresh_token は通常 6 ヶ月有効。期限切れ時は drive-upload.mjs --auth で再認証 (ブラウザフロー)。失敗時もローカル zip は保持されるためデータ消失リスクはなし。