2026 年 6 月 30 日 | idea_world

ワールドカップシーズンでワールドカップを見ていたため、睡眠が十分取れず作業はあまりできなかった
localhost:8501 の Markdown -> JSONL 変換は現在約 655 件まで進んでいることを確認
今日は大規模な収集/学習よりも、検証テストデバッグツールを簡単に作成し、磨くことに集中した
検証テストデバッグツールの戦略を立て、別のウェブツールである Qwen Validation Debugger を実装した
- 実行パスは tools/qwen-validation-debugger
- ローカル実行コマンドは npm run validation-debug:debug
- 基本アドレスは http://127.0.0.1:8520/
6 月 28 日には Qwen チャットボットで Godot コードチャンクと JSONL を直接作成し、はい/いいえ の検証を手作業で行った
- この方法は可能性は確認できたが、項目が増えるにつれてコピー/貼り付けと結果比較が非常に多くなった
- 特に docs_chunks, api_mapping, label_prototypes の 3 テーブルすべてをテストする必要があり、共通文法なら 6 スロット、バージョン別なら 12 スロットが必要となり、手動管理が急激に複雑化した
ツールでは 50 件の Godot テスト項目をサンプルとしてロードし、項目ごとに Qwen が共通文法か Godot 3/4 の分離かを先にラベリングさせる
- 共通文法なら共通コード 1 件を生成
- バージョン差があれば Godot 3 コードと Godot 4 コードをそれぞれ生成
- その後テーブル別の JSONL スロットを自動で構成
docs_chunks, api_mapping, label_prototypes を同じ はい/いいえ でまとめてはいけないことを再確認
- docs_chunks はコード説明の根拠なのでコードと直接合えば はい
- api_mapping と label_prototypes はマイグレーションソースの根拠なので、すでに Godot 4 に適用されたコードや共通文法では いいえ が正しい場合が多い
- そこでスロット名を 説明根拠, 無関係説明, 変換必要, 既に適用, 共通/不要, 無関係変換 に分けた
ツールを作りながら最も大きく変わった部分は JSONL 生成基準コード と 検証対象コード を分離したこと
- 最初は Godot 3 コードで作った JSONL は Godot 3 コードだけで検証し、Godot 4 コードで作った JSONL は Godot 4 コードだけで検証する構造だった
- しかし実際には Godot 3 基準の JSONL を Godot 4 コードに貼り付けたときにも いいえ が出るか確認する必要がある
- そこで各スロットごとに Godot 3 コード検証, Godot 4 コード検証 ボタンを別々に配置し、結果もそれぞれ保存するよう改善した
ツールを作った後、開発生産性がかなり変わった
- 以前は Qwen に毎回コードと JSONL を要求し、再びプロンプトに貼り付けて検証し、期待応答を頭の中で比較しなければならなかった
- 現在は項目選択、ラベリング、コード生成、JSONL 生成、Godot 3/4 クロス検証、raw prompt/response 確認が一画面で連続して行える
- 単に速く大量に作るより、どの基準で生成しどのコードで検証したかが混乱しないようになったことが最大の変化
- 50 件のテスト項目を繰り返すときに人が覚えておくべき状態が減り、失敗パターンをより早く見つけられるようになった
このツールを通じて、どのプロンプトでリクエストを送るか、JSONL 一括生成/検証をどの順序で呼び出すか、検証プロンプトとリクエストプロンプト自体がどのように構成されているかを画面上で直接確認できるようになった
- 期待応答はラベリングとスロットの性質に応じて固定し、はい/いいえ 基準が混乱しないようにした
- 応答結果もスロット別にすぐ表示されるため、どのコードとどの JSONL の組み合わせで失敗したかをはるか早く確認できる
- プロンプトが原因で失敗したケースがあっても、使用されたプロンプトが画面に残っているので、後でプロンプトを修正しやすくなる
ツールをある程度作ったので、今後はテンポを少し落とし、無理に量を増やすより検証基準をゆっくりと練り直す方向で進める予定
記録文書: Qwen Validation Debugger 戦略と実装記録
振り返り: docs/retrospectives/2026-06-30.md