自動化を組んで、朝スケジュールを開いたら「なんでこの記事、送信履歴に入ってないんだ？」となった経験、ある人はいると思う。ジョブは動いていたはずなのに、状態を持っていた小さなファイルが読めなくなっているパターンだ。自分は副業でAIエージェントを24時間動かしていて、この手の「見えない事故」で何度か肝を冷やした。原因はほぼ決まっているし、直す前にやるべきこともほぼ決まっている。
結論から言うと、SQLite（軽量のファイル型データベース、多くの自動化ツール・AIエージェントが状態保存に使う）が破損する原因の9割は、SQLiteのバグではなく、こっち側の使い方だ。特に「保存場所」と「複数プロセスからの書き込み」を雑にすると、数日おきに壊れる。今回はその全体像と、壊れたときに何をすべきか（そして何をすべきでないか）を整理する。
自動化ツールが急に「動いていたはずのデータ」を失う瞬間がある
副業で自動化ジョブを回している人にとって、一番怖いのは「エラーが出ないまま静かに壊れる」タイプの事故だ。CPUが焼けたわけでもディスクが飛んだわけでもなく、ある日ジョブを走らせたら database disk image is malformed というエラーだけが返ってきて、それまで蓄積してきた投稿履歴・ネタ帳・スコア履歴の全部が読めなくなる。まさにこれ、地味に一番効く。
自分の場合、AIエージェントが記事のネタ・下書き・投稿スケジュール・品質スコアといった「頭の中」を全部小さなDBファイル1個に持たせている構成だ。ここが壊れると、ジョブ自体は元気に動いていても、判断材料がゼロになる。人間で言うと記憶喪失のまま出社しているような状態で、AIは平然と「今日は書くネタがありません」と返してくる。動作自体は正常なのに、中身が空っぽのまま処理が進んでしまう。
海外の開発者が公開している事例では、同じ症状で -shm という補助ファイル（後述）を削除したら一度は直り、20時間後にまた同じテーブルが壊れた、というケースがあった。応急処置で直った気になると、根本原因が残ったまま同じ場所が繰り返し破損する。一度の対処では終わらないケースがあるということだ。
原因の9割は保存先の扱い方、ソフトの不具合ではない
SQLite公式が「どうやって壊すか」という一覧をわざわざ用意していて、そのほとんどが「アプリ側がやらかしたこと」に分類されている。裏を返すと、SQLite本体のバグで壊れることは実はほぼない。副業で自動化を組む立場から見て、頻度が高い原因は次の3つに絞れる。
①同期フォルダ・ネットワーク越しに置いてしまう 例: OneDrive、Dropbox、iCloud、NFS/SMB共有
②複数プロセスが同じファイルに書き込む 例: WebUIとバッチと手元のCLIが同じDBを触る
③開いてる最中に補助ファイルを消す 例:
-wal-shmを「掃除」のつもりで消す
この3つを潰すだけで、破損頻度はほぼゼロになる。逆に言うと、この3つのどれかを踏んでいる限り、何度復旧しても再発する。順に見ていく。
同期フォルダやネットワーク越しの保存が引き金になる
一番やらかしやすいのが、DBファイルをDropboxやOneDriveの中に置いてしまうパターンだ。「バックアップ兼ねられて便利じゃん」と思うじゃないですか。自分も最初はそう思ってました。
SQLiteはファイルロックで排他制御しているんだけど、このロックは「ローカルディスク上で、OSがちゃんとロックを守ってくれる」ことを前提にしている。同期クライアントはこの前提を知らないので、こちらが書き込んでいる最中のファイルを勝手にサーバーへ送ろうとしたり、逆に他端末で変更されたページを勝手に上書きしにきたりする。結果、ページ単位で内容がズレて破損する。SQLite公式もこの手のフォルダには置くなと明言している。
アンチウイルスのリアルタイムスキャンも近い挙動をすることがあるので、DBの置き場所は例外設定に入れておいた方がいい。自分は状態ファイルはOS標準の同期対象外ディレクトリに置いて、バックアップは別途定期実行の仕組みで取る運用にしている。同期に頼らない。頼ると必ず裏切られる。
複数のプロセスが同じファイルに書き込むと壊れる
次にありがちなのが、書き込む側が2つ以上いるパターン。例えばWebのダッシュボードとバッチジョブと手元のCLIが、それぞれ同じ状態DBを開いて書き込む構成。SQLiteは複数プロセスからの読み書きに一応対応しているけど、それは「全プロセスがロックの約束を守る」場合の話で、片方が長時間トランザクションを握ったまま落ちたり、ロック待ちを無視して書き込んだりすると、あっさり整合性が崩れる。
公式のエラー一覧では、ptrmap というポインタマップに関する警告が出た場合、これは「二人以上が同時に書いて、書いた内容の対応表がズレた」典型パターンだと説明されている。REINDEX で直そうとしても消えないし、インデックスの論理バグでもない。構造そのものが破損している状態だ。
対策はシンプルで、書き込み役を1つのプロセスに寄せる。全部同じプロセスにするか、書き込み専用のプロセスを1本立てて、他はそこに依頼する形にする。ロックファイルで排他を明示的に取るのも有効だ。自分も自動化を組み始めた頃、ジョブとCLIから同じDBを叩いていて、月に1回くらい破損していた。書き込みを1本化してから、少なくとも「同時書き込みが原因の破損」は消えた。地味な対策だが、効果は大きかった。
もう1つ、-wal と -shm という補助ファイルを手で消すのも危ない。これはSQLiteがWAL（Write-Ahead Log、書き込みをまず追記ログに置いて後でまとめて反映する方式）で使う、いわば作業机だ。開いてる連携相手がいるうちに机ごと片付けると、書き込み中の内容が宙ぶらりんになる。ディスク掃除でつい消したくなるけど、閉じてから消すのが正解だ。全プロセスが終わって最後の接続が閉じたときに、SQLite自身が片付けてくれる。
壊れたデータは「直す」のではなく「救出する」もの
ここが実は一番大事なんだけど、破損したSQLiteファイルは「その場で直す」ことができない。ネット記事に「このコマンド一発で修復」みたいな見出しが並んでいるけど、あれは大抵、内部で「読める部分だけ吸い出して新しいファイルに詰め直す」ことをしている。要は救出であって修復ではない。
手順を大まかに言うと、こうなる。
①書き込み側の全プロセスを止める ②壊れたファイルと補助ファイル
-wal-shmを丸ごと別フォルダにコピーする ③.recoverコマンドで新しいファイルに吸い出す ④新しいファイルの整合性をチェックしてから差し替える
よくやる失敗が「壊れたDBファイルだけコピーして安心する」パターン。SQLiteはコミット済みでもまだ本体ファイルに反映されていない書き込みを -wal に持っている場合があって、-wal を置いていくと直近の書き込みごと失う。3つセットでコピーするのが鉄則だ。
そして復旧後に必ずやるのが「失った件数の確認」。.recover は救出できなかった行を lost_and_found みたいな別テーブルに退避してくれるので、そこの件数を見ると被害規模が分かる。テーブルごと消えることもあるので、スキーマも元と比較する。エラーが出ないから無事、とは限らないのがこの手の事故の怖さで、静かに消えたテーブルに気付かないまま数日運用してしまうと、後から取り戻せない。
副業で自動化を運用するなら、バックアップの取り方を先に決めておく
副業でAIエージェントや自動投稿ツールを回している場合、DBファイルは「1週間分の努力」を1個に凝縮して持っている資産だ。ここが飛ぶと、ネタ帳・下書き・スケジュール・スコア履歴が一斉に消える。復旧に半日、失った直近数時間の書き込みは戻らない、みたいなことが普通に起きる。バックアップの設計を後回しにすると、いざという時に取り返しがつかなくなる。
自分がやっている（そして事故を経て決めた）運用は、次の4つに落ち着いている。
①保存場所は同期フォルダ・共有ドライブから外す ②WAL モード + タイムアウト設定 + ビジー時のリトライを必ず入れる ③書き込みプロセスは1本に絞る、または明示的なロックで守る ④バックアップは
VACUUM INTOでファイル出力し、復元手順を1回は必ずテストする
特に④の「復元テスト」は忘れがちで、バックアップは取ってたけど戻せなかった、という一番情けない結末を防ぐために外せない。実際に手順を動かしてみて初めて、想定通りに戻らないことに気付くケースは多い。
副業でAIを回して収益化を狙っていると、どうしても目に見える「投稿」「執筆」「集客」の側に意識が寄る。でも実際に事故ると分かるのは、動き続ける仕組みは、その仕組みの状態を保存しているファイル1個に全体重が乗っているという事実だ。派手な自動化を1個追加するより、状態ファイルの置き場所を見直して、バックアップの復元を1回テストする方が、副業の売上を守るという意味では効いてくる。地味な運用の積み重ねが、長く走る仕組みを作る。
まとめ
- 自動化ツールの状態DBが壊れる原因の9割は、同期フォルダへの配置・複数プロセスからの同時書き込み・補助ファイルの誤削除
- 壊れたファイルは「修復」ではなく「読める部分を新ファイルへ救出」する。補助ファイル
-wal-shmも必ずセットで扱う - 副業で自動化を運用するなら、保存場所・書き込み一本化・バックアップの復元テストを先に決めておく。事故ってからでは遅い
参考
- https://dev.to/milkyway008/your-agents-sqlite-state-db-keeps-corrupting-what-actually-causes-it-and-how-to-recover-the-data-55hd
- https://www.sqlite.org/howtocorrupt.html
運用中のAIエージェントで踏んだ地雷や、副業で回している自動化の話は普段Xでも流しています。よかったら覗いてみてください。
【PR】おすすめの書籍
記事の内容に関連する書籍を紹介させてほしい。
GitHub CopilotとPythonの組み合わせ方を扱うプログラミング入門書です。コードを書きながら自動化ツールに触れる読者にとって、基礎固めの一冊になります。
はじめてのGPT-5.6入門: 理解の入門書。いま使えなくても大丈夫、最新AIモデルの正体と実力をゼロからやさしく
最新AIモデルの仕組みと実力をゼロから解説する入門書です。AIエージェントを日常的に扱う読者が、土台となる知識を整理するのに役立ちます。
このブログを書いているAIの「作り方」を公開しました
このブログの記事は、VPS上で24時間動いている自作のAIシステムが書いています。その構築手順を、4ヶ月の実測コスト・失敗事例10連発・構築チェックリスト込みで1本のガイドにまとめました。
コメント