別アプリに散らばっていた、ある国家資格試験の過去問データを Turso DB に丸ごと移した。年度フォルダの奥に exam_XX_batch_NN_NN.json という名前で50ファイルほど眠っていたものを、1つのクラウドDBに集約する。やってみたら、JSONを読んで流し込むだけの単純作業だと思っていた手前で何度も足を止めた。トップレベルの構造がファイルごとに揺れていたり、進捗ログが画面に出てこなくてスクリプトが生きているのか分からなくなったり、そもそも会話の履歴が膨らみすぎてツール呼び出しが途中で壊れたり。事実に忠実に、つまずいた順に書き残しておく。
やりたかったこと
別アプリ（ある国家資格試験の学習アプリ）が持っている過去問データを、独立した Turso DB（libSQL/SQLite互換のクラウドDB）に全部コピーして、データベースとして管理したかった。将来的には Cloudflare 上のDBとして使っていきたい、という展望もある。学習アプリのフォルダにJSONが散らばったままでは、横断的に問題を引くこともできないし、解説や法令参照を後から検索することもできない。まずは「全部1か所に集める」のが今日のゴールだった。
まずデータの所在を特定させた
最初にやったのは、学習アプリのコードベースを調べさせて、過去問データが実際にどこにあるかを突き止めることだった。フォルダを開けると、年度ごとのディレクトリの中に現役データとバックアップが混在していた。
現役データは各年度フォルダの直下にある exam_XX_batch_NN_NN.json。archive/ 配下にも似た名前のファイルが並んでいたが、こちらは古いバックアップで、移行対象から外す必要があった。間違ってバックアップを混ぜると、同じ問題が二重に入る。最初にこの線引きをはっきりさせたのが効いた。
データ構造を把握する
バッチファイルを開かせて中身を読むと、3階層になっていた。
exam_info— 試験回などのメタ情報question_groups— 問題のグループ（問題番号やカテゴリといったメタ）questions— 各設問の選択肢、解説、法令参照
これとは別に、試験回・分野・カテゴリの定義を持つマスターデータもあった。問題本体とマスターを分けて入れれば、後から「この分野の問題だけ」といった引き方ができる。
スキーマの方針はシンプルに決めた。スカラー値（試験回番号、問題番号、選択肢のテキストなど平たい値）はそのまま列にする。解説や法令参照のようにネストした構造は、無理に正規化せず JSON 列にまるごと入れて完全に保持する。 正規化を頑張りすぎると、移行スクリプトが複雑になって今日のうちに終わらない。「まず全データを失わずに入れる」を最優先にした。
Turso スキルを読み込ませて、過去問用の独立DBを新規に作らせた。蔵書用など既存のDBとは混ぜず、過去問だけの専用DBにする。
つまずき①：トップレベルが配列のファイルが混じっていてexit 1
スキーマを切って、JSONを読んで流し込む移行スクリプトを書かせ、初回実行した。すぐに exit 1 で落ちた。
ログを読むと、あるファイルで「dict を期待したのに list が来た」という趣旨で止まっていた。同じ exam_XX_batch_NN_NN.json という名前なのに、トップレベルが dict のファイルと、配列のファイルが混ざっている。
そこで全ファイルのトップレベル構造を診断させた。結果、50ファイル中36ファイルがトップレベル dict、残り14ファイルが「dict を1つだけ包んだ配列」だった。つまり一部のファイルだけ、中身は同じなのに [ { ... } ] と余計な配列で包まれていた。書き出した時期によって形式が揺れていたのだろう。
対策は単純で、トップレベルが配列なら最初の要素を取り出し、dict ならそのまま使う、という分岐を1つ入れさせた。
# トップレベルが配列でも dict でも、中身の dict を取り出す
data = raw[0] if isinstance(raw, list) else raw
これで14ファイルも問題なく処理できるようになった。外から渡されたデータは、見た目が同じでも構造が揃っているとは限らない。最初に全件の形を診断しておけば、ここはもっと早く抜けられた。
つまずき②：進捗ログが出てこなくて生きているか不安になった
構造の分岐を直して再実行したら、今度はスクリプトが何も言わなくなった。標準出力に進捗を print していたはずなのに、画面が沈黙したまま動かない。固まったのか、処理を続けているのか、判断がつかない。
これは Python の出力バッファリングだった。端末（TTY）に直接つながっていないと、標準出力がブロックバッファリングになり、ある程度たまるまで画面に出てこない。プロセスは生きているのに、ログだけが詰まって見えなかった。
-u（アンバッファ）を付けて実行し直したら、1ファイル処理するごとに進捗がそのまま流れてきた。何件目を処理中か見えるようになって、ようやく安心して待てた。
python -u migrate_to_turso.py
結果
最終的に、過去問データを全件 Turso に格納できた。
- 試験10回分
- 問題 499 件
- 選択肢 1992 件
- 解説・法令参照などのネスト構造は JSON 列で完全保持
ローカルのレプリカファイルを介さず、HTTP接続でクラウドのDBまで到達できることも確認した。実際にクラウド側へ届いているかを確かめないと、ローカルにだけ書いて満足するという事故が起きうる。あわせて、移行で増えた新しいレプリカファイルが .gitignore の除外対象に入っているかも確認した。DBの実体をうっかりリポジトリにコミットしたくない。
最後に、今日やった作業と今後の計画を memo/2026-05-27/ 配下にチェックボックス形式でドキュメント化した。Cloudflare 上での運用に向けて、次に何をやるかを残しておく。
この日いちばんのハマり：会話履歴の肥大でパースエラーが頻発した
実は移行作業そのものより、この日いちばん時間を持っていかれたのは別のところだった。
冒頭でコードベースを調査させたとき、venv のパスや大量のファイルパスが会話の履歴にどんどん流れ込んでいた。その状態で次の作業を頼むと、ツール呼び出しを生成している途中で出力が崩れ、「The model's tool call could not be parsed」というエラーが何度も出た。一度出ると、同じ調子で連発する。
最初はツール側の不調を疑ったが、よく見ると共通点があった。履歴が膨らんでいるときほど壊れる。真因は会話履歴の肥大だった。一度に大きな調査をさせて出力をため込むと、その後のツール呼び出しが不安定になる。
対策は地味だが効いた。1回ずつ小さく刻んで進める。 大きな調査を一度に投げず、ファイルを絞って読ませ、結果を受け取ってから次へ。出力を膨らませない進め方に切り替えたら、パースエラーはぴたりと止まった。
学びメモ
- 会話履歴を肥大させない。小刻みに刻んで進める。 venv や大量パスを一度に流し込むと、その後のツール呼び出しが「could not be parsed」で壊れ始める。大きな調査ほどファイルを絞って分割する
- 外部由来データは、トップレベル構造のばらつきを最初に診断する。 同じ命名規則のファイルでも dict と「dict を包んだ配列」が混在していた。流し込む前に全件の形を見ておけば、exit 1 で止まらずに済んだ
- 非TTYでは標準出力がブロックバッファリングされる。 進捗が見えないときはプロセスが死んだとは限らない。Python なら
-uを付けるだけでログがそのまま流れる - 正規化を頑張りすぎない。 スカラーは列、ネストはJSON列、という割り切りで「まず全データを失わずに入れる」を先に達成した。設計の磨き込みはDBに入ってからでも遅くない
- クラウドへ実際に届いたかを確認する。 ローカルのレプリカに書けただけで安心せず、HTTP接続でクラウド側まで到達したことを確かめる