2026-06-21 振り返り
Godot 公式ドキュメント JSONL 変換フローを再質問
Qwen に 2026-06-21-initial-rag-classifier-architecture.md のスキーマ内容を貼り付け、Markdown 文書を JSONL に変換する Python コードの方向性を質問した。
最初の質問の核心は単純変換スクリプトだった。
- Markdown を入力すると JSONL に変換する Python コードが必要
- 実行コマンドまで一緒に提供してほしい
- JSONL 内容は Qwen API を呼び出して生成したい
- JSONL として保存する際にスキーマが壊れないように検査ロジックが必要
- 正規表現またはスキーマ検証で JSONL 形式を確認したい
- API 呼び出し時にどのテーブルにマッピングすべきかもモデルが判断してくれると良い
- 必要なら
docs_chunks,api_mapping,label_prototypesの全スキーマを生成しなければならない
CLI スクリプトからウェブベースツールへ考えが拡張
その後、単なる CLI 変換器だけではフローが見えにくいと判断した。そこでウェブで呼び出す構造も検討した。
- ウェブ画面で API キーを入力できると良い
- Markdown ファイルのアップロードまたはフォルダーアップロードに対応できると良い
- 変換前後の diff や変更内容をウェブ上で目で確認できると良い
- 単に結果ファイルだけを生成するのではなく、変換過程と判別結果を人がレビューできる必要がある
この質問を通じて、JSONL 変換器は単なるバッチスクリプトではなく、人がレビューし承認するデータ加工ツールに近づくべきだと感じた。
1 ファイルが複数テーブルに行く可能性を再確認
最も重要な追加質問は、1 つの Markdown ファイルが 1 つのテーブルにだけマッピングされない可能性がある点だった。
例えば migration 文書 1 つで次の 3 種類の JSONL を同時に作成できる。
- 公式説明チャンクは
docs_chunks.jsonl - API 変更規則は
api_mapping.jsonl - 変換/分類例は
label_prototypes.jsonl
したがって変換器はファイル 1 つを入力として単一の JSONL だけを作る構造ではなく、Qwen を呼び出してどのテーブルレコードが必要かを先に判別し、複数の応答が出た場合は 1 ファイルから 2 つ以上の JSONL レコードを生成できなければならない。
今日新たに決めた設計方針
- Markdown から JSONL への変換は
分類 → 生成 → 検証 → 保存のステップに分ける。 - Qwen は本文を読み、必要な対象テーブルを判断する役割を担える。
- ただし Qwen の応答をそのまま信頼せず、ローカルスキーマ検証器が最終的な保存可否を決定する。
- 正規表現は最小限の形式チェックに使用し、実際のフィールド検証は JSON Schema や Pydantic のような構造的検証が適切。
- 1 つの Markdown ファイルから複数の JSONL 出力が出ることを前提とする。
- ウェブ UI は単なる便利機能ではなく、自動生成されたレコードを人が確認・承認する検査層になる。
次の作業メモ
docs_chunks,api_mapping,label_prototypes別々の JSON Schema 草案を作成する。- Markdown ファイル 1 つを入力として Qwen に対象テーブル候補を判別させるプロンプトを設計する。
- Qwen の応答が複数テーブルレコードを含む場合、ファイル別に分割保存するルールを作る。
- JSONL の行単位検証スクリプトをまず CLI で作成する。
- その後ウェブ UI でアップロード、変換、diff、検証結果、承認/却下フローを見られるように拡張する。
残しておきたい質問
- テーブルマッピング判別まで Qwen に任せるが、どのケースで必ず人が承認すべきか？
api_mapping候補は自動生成後すぐ DB に入れるか、candidate状態だけで保存するか？- ウェブ UI の diff は元の Markdown に対する JSONL diff と見るか、前の JSONL バージョンに対する diff と見るか？
- フォルダーアップロード時に失敗したファイルと部分的に成功したファイルをどう再試行するか？