AIエージェント時代のバックアップ入門

1. なぜAIエージェント環境にもバックアップが必要なのか

「プロジェクトはGitHubにあるから大丈夫」と思われがちです。GitHubはコードを守るうえで 非常に有効ですが、PC上のすべてを守ってくれるわけではありません。

たとえば、次のような情報は安全上の理由からGitHubへ入れないのが普通です。

• .env や .auth/ にあるAPIキーや認証情報
• SSHの秘密鍵
• 個人環境だけで使うローカル設定
• AIエージェントの端末固有設定
• Gitの管理対象から除外した記憶や履歴

つまり、コードの正本はGitHubにあっても、 仕事を動かすための鍵や設定はPCにしかないことがあります。

AIエージェントは、使い込むほどその人や会社の仕事に合わせて育ちます。 設定や記憶を失うことは、単にアプリを入れ直すこととは違います。 積み上げた仕事の進め方まで失う可能性があります。

2. バックアップは「全部」ではなく役割分担で考える

今回の実例では、PC全体を丸ごと保存していません。守っているのは、 失われたら再取得・再作成が難しいものです。

この分け方には、次の利点があります。

• バックアップ容量を小さくできる
• 毎日短時間で実行できる
• 本当に重要なファイルを点検しやすい
• 復元時に「何をどこから戻すか」が明確になる

ただし、画像、会計データ、顧客データなど、GitHubにも今回の対象にも入らない重要データがある場合は、 別のバックアップ設計が必要です。

3. 実際の構成

実運用では、毎朝7時30分に次の処理を自動実行しています。

1. PC内の重要ファイルを集める
2. 圧縮しながらGPGの公開鍵で暗号化する
3. 暗号化済みのアーカイブをSSHで外部サーバーへ送る
4. PC側と外部サーバー側のSHA-256を比較する
5. 一致した場合だけ成功として記録する
6. PC側と外部サーバー側に直近14世代を残す

運用実績は、2026年8月26日時点で次のとおりです。

バックアップ処理自体のソースコードも、非公開リポジトリで履歴管理しています。 これらは一つの実例であり、ファイル数や容量の適正値は環境ごとに異なります。

公開鍵暗号を使う理由

公開鍵暗号では、暗号化するための「公開鍵」と、開くための「秘密鍵」を分けられます。

毎日のバックアップに使うPCには公開鍵だけを置き、復号用の秘密鍵は置きません。 これにより、毎朝パスワードを入力せず自動実行できます。さらに、PCが盗まれても、 そのPCだけでは暗号化済みバックアップを開けません。

ただし、PC上に残っている元の設定や認証情報は別問題です。盗難時の元ファイル保護には、 BitLockerなどのディスク暗号化、強いWindowsサインイン、画面ロックも必要です。

圧縮前のデータは、tarからGPGへ直接渡します。 暗号化前の一時アーカイブをディスクへ保存しないため、平文の秘密情報を余計に残しません。

転送できたことと、正しく届いたことは違う

ファイル転送が「成功」と表示されても、受信側のファイルが想定どおりかは別の話です。

そこで、送信前と送信後にそれぞれSHA-256という値を計算します。これはファイルの内容から作る 照合用の値です。両者が一致して初めて、同じ内容が届いたと判断します。

4. 何をバックアップしているのか

実例で守っているのは、主に次の3群です。

AIエージェント環境

• 基本設定
• hooksなどの自動処理
• 担当エージェント
• コマンドやスキル
• 複数の場所に保存された記憶
• 外部ツールとの接続設定
• プロジェクトごとの信頼設定

全プロジェクトの認証情報

• .auth/
• .env
• SSH鍵
• GitHubへ入れていない秘密情報

プロジェクト固有のローカル設定

• 各プロジェクトの .claude/ など
• Gitの管理対象外になっている端末固有設定

重要なのは、ファイル名を一つずつ列挙するだけで終わらせないことです。 AIツールの更新やプロジェクト追加によって保存場所は増えます。 可能なものはフォルダ単位で収集し、対象の増減も監視します。

5. バックアップ自身を見張る

この構成で最も重要な教訓は、失敗通知をバックアップ処理の中だけに置いてはいけない ということです。

過去に、スクリプトの構文エラーでバックアップが22日間止まりました。 処理が最初の1行も動かなければ、その中に書いた通知も動きません。 以前の「SUCCESS」という記録だけが残り、正常に見えてしまいました。

現在は、バックアップ本体とは別の見張り役が、毎日12時に「最後の成功が2日以内か」を確認します。 可能なら、この見張り役は別のプロセスや別の機器・サービスで動かすと、 PC自体が停止した場合も検知しやすくなります。

さらに、次の変化も通知対象にしています。

• 対象ファイル数が急に減った
• AI環境の保存場所に見慣れないフォルダが増えた
• 最低限あるはずのファイル数を下回った
• 転送後のSHA-256が一致しなかった

「エラーが出たら知らせる」だけでなく、黙って対象から漏れたときにも知らせる ことが大切です。

6. 復元の鍵は、バックアップとは別に守る

暗号化されたバックアップを復元するには、少なくとも次の2つが必要です。

• バックアップを復号する秘密鍵
• 外部サーバーへ接続するSSH秘密鍵

この2つをバックアップの中にしか入れていないと、復旧時に 「取り出すための鍵が、取り出したい箱の中にある」という循環依存が起きます。

実運用では、2つの鍵を一組にして、USBと信頼できるパスワード管理サービスへ別々に退避します。 GPG秘密鍵にパスフレーズを設定した場合は、そのパスフレーズも紛失しない管理が必要です。

鍵の保管先は、災害・盗難・アカウント停止が同時に起きにくい組み合わせにします。 そして、保管したつもりで終わらず、実際に取り出せるか確認します。

7. 復元テストをして初めて完成する

バックアップファイルが毎日増えていても、復元できるとは限りません。

実例では、別フォルダへ実際に復号・展開し、AI環境、認証情報、プロジェクト固有設定が 戻ることを確認しました。全復旧経路は2026年7月30日に実地検証しています。

この構成の目標は、最後に成功した朝7時30分の状態へ戻すことです。そのため、 事故の時刻によっては最大約1日分の変更を失います。これは一般にRPO、つまり 「どこまで前の状態へ戻ることを許容するか」という考え方です。

一方、「何時間で仕事を再開できるか」という復旧時間は、PCの準備、アプリの再インストール、 回線速度などにも左右されます。バックアップ成功だけでは確定しないため、復旧訓練で実測します。

8. 初心者が最初に決めること

難しいツールから考える必要はありません。まず、次の質問に答えます。

1. PCが今日壊れたら、二度と戻せないものは何か
2. GitHubやクラウドから再取得できるものは何か
3. 何日前の状態まで戻れれば仕事を続けられるか
4. バックアップが止まったことを、誰がどうやって知るか
5. 復号鍵と接続鍵をPCの外のどこへ置くか
6. 最後に復元を試したのはいつか

AIエージェントへ構築を依頼する場合も、実際のパスワード、秘密鍵、APIキーを 会話欄へ貼り付ける必要はありません。保存場所、必要な権限、処理の条件だけを伝え、 秘密情報そのものは安全な保管場所から実行時に読み込ませます。

9. この構成が守らないもの

今回の仕組みは万能ではありません。

• PC全体の完全なディスクイメージではない
• アプリ本体は再インストールが必要
• サービスによっては再ログインや再認証が必要
• GitHubへ未送信のコードは、別途対象にしなければ戻らない
• 外部サーバー自身のデータをPCへ退避する仕組みとは別物
• 復号鍵を失えば、暗号化されたバックアップは開けない

「何を守るか」と同じくらい、何は守られないかを明記することが重要です。

10. まとめ

よいバックアップには、次の5点がそろっています。

1. 失うと戻せないものを選んでいる
2. 自動で暗号化し、PCとは別の場所へ置いている
3. 転送後の破損と、対象漏れを検知している
4. バックアップ本体とは別の見張り役がいる
5. 復号鍵をPCの外に保管し、復元を実地で試している

バックアップは「安心のためのファイル」ではなく、事故後に仕事を再開するための仕組みです。 付属の一般化仕様書を自分の環境に合わせ、まずは対象一覧と復元テストから始めてください。

付録：そのまま貼れる依頼文（一般化仕様書）

ここから下は、この記事の仕組みを自分のパソコンに作るための依頼文です。 文章をコピーして、Claude Codeなど自分のAIエージェントへ順番に送ってください。 OSの違い（Windows／Mac）や道具の選定は、AIエージェント側に判断させて構いません。

ステップ1：まず「守るもの」を棚卸しさせる

いきなり作らせず、調査だけをさせます。対象一覧がこの仕組みの土台になります。

このパソコンの中で「失われたら再取得・再作成が難しいもの」を調査してください。
まだバックアップの仕組みは作らないでください。調査だけです。

次の観点で棚卸しし、一覧にしてください。

1. AIエージェントの設定・エージェント定義・コマンド・スキル・記憶・接続設定
2. 各プロジェクトの認証情報（.env や .auth などのファイル、SSH鍵）
3. Gitの管理対象から外れているローカル設定
4. GitHubやクラウドから再取得できるもの（これはバックアップ対象から除く候補）

条件は次のとおりです。

- パスワードやAPIキーなどの中身の値は、会話欄に一切表示しない（ファイルの場所と種類だけ書く）
- ファイルは読むだけで、変更・移動・削除をしない
- 「対象一覧」「対象から外すもの」「判断に迷うもの」の3つに分けて、専門用語を使わず日本語で報告する

ステップ2：バックアップと見張り役を構築させる

棚卸しの結果を確認したら、次の文章を送ります。外部の保存先（VPS・クラウドストレージなど）を すでに持っている場合は、その旨を書き添えてください。

先ほど棚卸しした「失うと戻せないもの」を対象に、毎日自動で動くバックアップを構築してください。

仕様は次のとおりです。

- 対象ファイルを集め、圧縮しながら公開鍵暗号（GPGなど）で暗号化する。復号用の秘密鍵はこのパソコンに置かない
- 暗号化前の一時ファイルをディスクに保存しない（圧縮から暗号化へ直接渡す）
- 暗号化済みのアーカイブを、パソコンの外（外部サーバーまたは私が指定する保存先）へ送る
- 送信前と送信後のSHA-256を比較し、一致した場合だけ成功として日時を記録する
- 保存先とパソコン側の両方で、直近14世代だけを残す
- OSの機能（タスクスケジューラ等）で毎日1回、自動実行する
- バックアップ本体とは別の見張り役を作り、毎日「最後の成功が2日以内か」を確認して、止まっていたら知らせる
- 対象ファイル数が急に減ったときも知らせる

条件は次のとおりです。

- パスワード・秘密鍵・APIキーの値を、会話欄にもスクリプトの中にも書かない
- 外部の保存先が決まっていない場合は、先に候補と費用感を挙げて私に相談する
- 復号用の秘密鍵と保存先への接続鍵は、バックアップの中だけに置かず、パソコンの外（USBやパスワード管理サービス）へ退避するよう私に案内する
- 完了後は「何を守っているか」「何は守られないか」「復元に何が必要か」を、非エンジニア向けに報告する

ステップ3：復元テストで完成させる

作って終わりにしないための、いちばん大事なステップです。

構築したバックアップから、実際に復元できるかをテストしてください。

- 最新のバックアップを別のフォルダへ復号・展開する（元のファイルには一切触れない）
- 棚卸しで挙げた対象が実際に入っているか、件数と中身を突き合わせる
- 復号用の秘密鍵と保存先への接続鍵が、パソコンの外の保管場所から実際に取り出せるかを私に確認させる
- 「何日前の状態まで戻れるか」と「復元に何の作業と時間が必要か」をまとめる

未確認の項目があれば、確認済みのように書かず、未確認と明記してください。