AI駆動開発における「GitHubがあるから大丈夫」という落とし穴
〜バックアップ戦略の重要性〜
AI協働開発で実際に発生した38記事のデータ破損事例。GitHubがあっても防げなかった理由と、ローカルバックアップが救世主となった経験から学ぶ、AI時代の新しいバックアップ戦略。
目次
はじめに:ある朝の悪夢
2025年6月17日の朝、私たちは驚愕の事実に直面しました。51個のニュース記事のうち、38個の記事内容が完全に間違っていたのです。
- 「睡眠観測アプリ」の記事が「東京のお客様の社内勉強会」に
- 「振動フィードバック技術」の記事が「コンテンツ制作サービス」に
- 多数の異なる記事が同一の内容で上書きされていた
さらに不可解なことに、この問題は前日に修正済みだったはずでした。しかし、その修正履歴も含めて消失していたのです。
GitHubがあるのに、なぜ?
多くの開発者は「GitHubがあるから大丈夫」と考えがちです。私たちもそうでした。しかし、この事例はGitHubだけでは不十分であることを痛感させられました。
GitHubの限界
1. コミットされていないデータは保護されない
# 作業中のファイルに問題が発生
$ node scripts/migrate-data.js # バグのあるスクリプト
# → 大量のファイルが破損
# → まだコミットしていない = GitHubには正しいデータがない
2. 誤った変更がコミットされると「正しい履歴」になる
$ git add -A
$ git commit -m "feat: データ移行完了" # 実は破損したデータ
$ git push
# → GitHubに破損したデータが「正しい状態」として記録される
3. AI特有の問題:セッション間での記憶喪失
AI(Claude、ChatGPTなど)は新しいセッションで以前の作業内容を忘れます。そのため:
- 同じ問題を繰り返す可能性がある
- 修正履歴が文書化されていないと、修正方法も失われる
救世主:ローカルバックアップ
今回、私たちを救ったのは偶然残っていたnews.json.backupファイルでした。
// scripts/fix-wordpress-news.js
const backupData = JSON.parse(
await fs.readFile('../public/data/news.json.backup', 'utf8')
);
// バックアップから正しいデータを復元
for (const article of wpNewsArticles) {
// 正しい内容で記事を再生成
const correctData = backupData[article.id];
await fs.writeFile(filePath, JSON.stringify(correctData, null, 2));
}
実践的なバックアップ戦略
1. データ構造変更時の必須バックアップ
#!/bin/bash
# scripts/pre-migration-backup.sh
# タイムスタンプ付きでバックアップ
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
cp -r public/data "backups/data_${TIMESTAMP}"
echo "✅ Backup created: backups/data_${TIMESTAMP}"
echo "📝 Reason: データ構造の大規模変更前" >> backups/backup.log
2. 復元可能性の確保
// バックアップと同時に復元スクリプトも準備
const createBackupWithRestoreScript = async (dataPath) => {
const timestamp = new Date().toISOString();
const backupPath = `${dataPath}.backup-${timestamp}`;
// バックアップ作成
await fs.copyFile(dataPath, backupPath);
// 復元スクリプトも生成
const restoreScript = `
#!/bin/bash
# Restore script for ${dataPath}
# Created: ${timestamp}
cp "${backupPath}" "${dataPath}"
echo "✅ Restored from ${backupPath}"
`;
await fs.writeFile(`restore-${timestamp}.sh`, restoreScript);
};
3. AI協働開発での必須ドキュメント化
## データ破損時の対応手順
### ニュース記事が破損した場合
1. バックアップから復元
```bash
node scripts/fix-wordpress-news.js
- インデックス再構築
bash
node scripts/rebuild-news-index.js
使用するファイル
- バックアップ:
/public/data/news.json.backup - 翻訳データ:
/i18n/locales/ja/news.json
## 学んだ教訓:多層防御の重要性
### 1. バックアップの3-2-1ルール
- <strong>3つ</strong>のコピーを保持(オリジナル + バックアップ2つ)
- <strong>2つ</strong>の異なる媒体に保存(ローカル + クラウド)
- <strong>1つ</strong>はオフサイトに保存(GitHub or クラウドストレージ)
### 2. AI協働開発特有の対策
#### ドキュメント管理ルールの強化
```markdown
### 重要な修正履歴の保護
- データ破損の修正履歴は必ずCHANGELOG.mdに記録
- 修正に使用したコマンドを明記
- バックアップファイルの場所を記録
削除時の注意事項
### 重複ファイル削除時の確認事項
1. 内容を比較し、重要な記録が含まれていないか確認
2. 修正履歴(fix、修正、復元)のキーワードをgrep
3. 異なる内容がある場合は統合してから削除
3. 実装すべきツール
// scripts/backup-guard.js
// データ変更前に自動的にバックアップを作成
const guardedOperation = async (operation, dataPath) => {
// 1. 自動バックアップ
const backupPath = await createBackup(dataPath);
try {
// 2. 操作実行
await operation();
// 3. 整合性チェック
const isValid = await validateData(dataPath);
if (!isValid) {
throw new Error('Data validation failed');
}
} catch (error) {
// 4. 問題があれば自動復元
console.error('Operation failed, restoring backup...');
await restoreBackup(backupPath, dataPath);
throw error;
}
};
まとめ:「転ばぬ先の杖」
今回の事例は、現代の開発者が陥りやすい「GitHubがあるから大丈夫」という過信への警鐘となりました。
特にAI駆動開発では:
- AIのセッション間での記憶喪失
- 大量の自動変更による影響範囲の拡大
- 人間のレビューが追いつかない速度での変更
これらのリスクに対して、ローカルバックアップは最後の砦となります。
アクションアイテム
-
今すぐ実施
- 重要なデータのバックアップスクリプトを作成
.gitignoreにバックアップディレクトリを追加- チームでバックアップポリシーを共有
-
継続的な改善
- データ変更操作の前後でのバックアップを習慣化
- 復元手順のドキュメント化とテスト
- AI向けの明確な指示書の整備
「GitHubがあるから大丈夫」ではなく、「GitHubもバックアップもあるから大丈夫」という意識への転換が、AI時代の開発には不可欠です。
関連記事
参考リンク
画像を読み込み中...
📢 この発見を仲間にも教えませんか?
同じ課題を持つ人に届けることで、AI協働の輪が広がります
関連記事
AI協働開発における ドキュメント管理の重要性
実プロジェクトの事例から学ぶ、AI協働開発で膨大なドキュメントが必要になる理由と効果的な管理手法
Claude Codeの安全な運用:権限分離による事故防止策 〜記事追加がシステム破壊を招いた日〜
「記事を書いて」という指示でなぜdata-loader.tsが破壊されたのか。AI開発における権限分離の重要性と、CLAUDE.mdを使った実践的な事故防止策を解説。
AIが「親切心」で勝手に改善してしまう現象 〜より良いという判断基準の共有が課題〜
AIが「親切心」で指示されていない改善を加える現象とその対策。CLAUDE.mdにルールを書いても無視される現実と、効果的なコミュニケーション方法を解説。