JSONL 収集状況に基づくテストリポジトリ選定観察日誌
作成日: 2026年 6月 27日
目的
現在までに生成された JSONL を基準に、どのような性格の Godot リポジトリを先にクローンしてテストするのが良いか判断する。
ここでの目標は「有名なリポジトリを何でも一つ選ぶこと」ではない。現在 DB に蓄積されている根拠がどの領域に強く、どの領域がまだ弱いかをまず見極め、Retriever が実際に根拠を見つけられるリポジトリの性格を選ぶことである。
分析基準は次の二つのファイルである。
/Users/joyeongjin/make_md/work/web_jsonl/docs_chunks/docs_chunks.jsonl
/Users/joyeongjin/make_md/work/web_jsonl/api_mapping/api_mapping.jsonlstate.jsonには変換状態、分類プロンプト、元の応答デバッグが含まれていますが、ランタイム設定値も混在する可能性があるため、公開文書には原文を移しません。この観察日誌には JSONL 統計と判断のみを残します。
スナップショット状態
観察時点での変換はまだ進行中です。
docs_chunks.jsonl: 153 records
api_mapping.jsonl: 117 records
label_prototypes.jsonl: まだ生成ファイルがありませんウェブ変換の状態は大まかに次の流れでした。
done: 132 files
pending: 1425 files
deferred: 11 files
converting: 2 files
classified: 144 filesしたがって、この文書は最終結論ではなく、「現在までに収集されたJSONLを基準とした第1次レポート選定基準」である。
docs_chunks の観察
docs_chunksは153件のレコードが生成されていた。
構成は以下に近い。
class_reference: 127
about: 2695個の Markdown 原本ファイルからチャンクが作成され、129 件のレコードに API シンボルが含まれていました。コードブロックを持つレコードは 36 件でした。
現在まで docs_chunks で強く見える領域は次のとおりです。
Animation 系
Audio 系
Camera 系
Canvas/CanvasItem 系
Array/Callable/GlobalScope のような基礎 API
AnimatedSprite2D の一部
AStar/AStarGrid2D の一部逆に、まだ弱く見える領域は次のとおりです。
KinematicBody / CharacterBody の移行
move_and_slide の呼び出し方式
yield -> await への変換
Color8 -> Color.from_rgba8 への変換
TileMap の移行
RigidBody / physics body の移行
HTTPRequest / ネットワーキングつまり、現在の時点で docs_chunks は「Godot 4 公式ドキュメントの説明根拠」としてある程度使用できるが、まだ典型的な Godot 3 → Godot 4 2D アクションゲームの移行根拠が十分に蓄積されたとは言い難い。
api_mapping 観察
api_mappingは 117件のレコードが作成されていました。
変更タイプは次のように分かれます。
rename_or_replacement: 82
behavior_change: 24
deprecated: 11すべてのレコードの confidence は verified_from_docs に入っていました。
現在までに強く見えるマッピング領域は以下です。
Array メソッドと動作の違い
AnimationPlayer / AnimationMixer / AnimationTree / AnimationNode 系列
AudioStream / AudioEffect / AudioEffectSpectrumAnalyzer 系列
Camera / Camera3D / CameraAttributes 系列
CanvasItem draw/modulate 系列
GlobalScope の一部関数と非推奨定数
AStarGrid2D の一部例として、現在の JSONL には次のような性格の根拠が含まれています。
Camera -> Camera3D
WorldEnvironment の露出設定 -> CameraAttributes 系列
AnimationPlayer の一部機能 -> AnimationMixer に分離
AnimationNode._process -> AnimationNodeExtension._process_animation_node
AudioEffectLimiter -> AudioEffectHardLimiter
Array.sort の動作変化
Array.has の C# 名称の違い
CanvasItem.modulate の動作変化
CanvasItem.draw_string / draw_rect の動作変化この発言は、今すぐ migration テストを行う場合、2D プラットフォーマーの KinematicBody2D や move_and_slide よりも Camera、Animation、Audio、CanvasItem、Array 側のコードがより多く引っ掛かる可能性が高いという意味です。
label_prototypes の観察
現在のスナップショットには label_prototypes.jsonl ファイルがありません。
したがって、現段階で「関数使用方式全体が変わる例」を Retriever でテストするには根拠が不足しています。もちろん api_mapping にも behavior_change が含まれていますが、これはまだ「全体使用パターンの例」よりも、文書から抽出した API 変更の根拠に近いです。
そのため、現在リポジトリを選ぶ際は label_prototypes を積極的にテストするリポジトリよりも、docs_chunks と api_mapping がすでに持っている領域を先に検証するリポジトリの方が適しています。
今すぐクローンしやすいリポジトリの性格
現在 JSONL 基準で最も先にクローンしやすいリポジトリは「小規模で、Godot バージョンの手がかりが明確で、現在蓄積された mapping と重なる API を実際のコードで使用しているリポジトリ」です。
優先順位は以下の通りです。
1 順位: Godot 3 ベースの小さな Camera/WorldEnvironment/Animation サンプル
最も適した最初のテスト候補は、Godot 3 プロジェクトの中で Camera、WorldEnvironment、AnimationPlayer、AnimationTree、CanvasItem の描画、AudioEffect などの機能を実際に使用している小規模なサンプルリポジトリです。
理由は、現在 api_mapping に次の根拠がすでに含まれているためです。
Camera -> Camera3D
Camera.get_transform -> Camera3D.get_camera_transform
WorldEnvironment exposure 設定 -> CameraAttributes
AnimationPlayer -> AnimationMixer に関する変更
AnimationNode / AnimationTree 系列の変更
CanvasItem draw/modulate 動作の変更
AudioEffect / AudioStream 系列の変更このリポジトリをクローンすると、AST の断片に Camera、WorldEnvironment、AnimationPlayer、CanvasItem、AudioEffect のような手がかりが現れ、Retriever が現在の JSONL で根拠を見つける可能性が高くなります。
テスト目的も明らかです。
Godot 3 コードスニペット
-> AST スニペット
-> api_mapping 検索
-> docs_chunks 補助検索
-> LLM 判断 プロンプト プレビューつまり「このコードが Godot 3 API を使用しているか、Godot 4 ではどのような根拠で変更すべきか」を現在のデータで即座に確認できる。
第2優先: Godot 4 ベースの小さな Animation/Audio/Camera の例
2番目の候補は Godot 4 で作成された小さな例のリポジトリです。
このリポジトリは、migration の検証というよりも「正常な Godot 4 コードの説明」と「Retriever が間違った Godot 3 の migration を持ち込んでいないか」を確認するのに適しています。
現在 docs_chunks には Animation、Audio、Camera、CanvasItem、Array の公式ドキュメントの説明がかなり入っています。そのため、Godot 4 のコードスニペットを入れたときに docs_chunks を中心に説明の根拠が取れるかどうかが分かりやすいです。
このリポジトリは次のような性格だと良いです。
project.godotがある完成された小さなプロジェクト
.gd ファイルが5〜30個程度
.tscn ファイルが一緒にある
AnimationPlayer または AnimationTree を使用
AudioStreamPlayer または AudioEffect を使用
Camera2D/Camera3D を使用
Array/Callable のような基礎 API を使用
大容量アセットは多くない3順位: Godot 3とGodot 4バージョンに分かれた同一テーマの例
可能であれば同じテーマをGodot 3バージョンとGodot 4バージョンに分けて提供する例が最も良いです。
例えば同じカメラ/アニメーション/オーディオの例がGodot 3ブランチとGodot 4ブランチで別々に用意されていれば、RetrieverとLLMの判断を比較しやすくなります。
このようなリポジトリは以下を確認すると良いです。
Godot 3 の断片で api_mapping が正しく機能しているか
Godot 4 の断片で docs_chunks の説明根拠が正しく機能しているか
同じ機能のバージョン別コード差異を LLM プロンプトでどのように示すことができるか
プロジェクト単位で godot3/godot4/mixed の判定をどのように蓄積するか今すぐクローンするか微妙なリポジトリの性格
現在 JSONL だけを見ると、次の性格のリポジトリはまだ最初のテストとしては微妙です。
典型的な Godot 3 2D プラットフォーマー
KinematicBody2D、move_and_slide、yield、TileMap、Color8 のような手がかりが多い Godot 3 2D プラットフォーマーは、後々必ず必要になります。
しかし現在のスナップショットでは、これらの手がかりが JSONL にほとんどありません。今すぐこのようなリポジトリを入れると、Retriever が根拠を見つけられなかったり、関係のない Animation/Audio/Camera の根拠を引っ張ってくる可能性があります。
したがってこの性格のリポジトリは「良い最終テスト候補」ですが「現在の JSONL で直接検証しやすい第一候補」ではありません。
大規模ゲーム全体リポジトリ
アセットが多く .gd ファイルが数百個ある大規模ゲームリポジトリはまだ早いです。
今必要なのは、モデルに大きなプロジェクトを投げ込むことではなく、コード片がどの JSONL 根拠を検索するかを最後まで追跡することです。大規模リポジトリはデバッグ対象が広すぎて、どの根拠がなぜ検索されたかを見るのが難しくなります。
最初のテストは小さく機能が明確な例が良いです。
C# 中心リポジトリ
現在の JSONL には C# の言及と一部 C# 名称の違いがありますが、全体の流れは GDScript AST と .gd 片を基準に設計されています。
したがって C# 中心の Godot リポジトリは現段階の最初のテスト対象としては適切ではありません。
GDExtension / ネイティブプラグイン中心リポジトリ
GDExtension、C++、Rust バインディング、ネイティブプラグイン中心のリポジトリもまだ早いです。
現在の目標は Godot プロジェクトの .gd、.tscn、project.godot を片に分割し、Retriever が公式ドキュメントの根拠を見つける流れを見ることです。ネイティブエクステンション中心のリポジトリは分析軸が変わります。
リポジトリ選定基準
現在の基準でクローン候補は次の条件を満たすことが望ましいです。
Godot バージョンは README や project.godot で確認できる必要があります
project.godot ファイルが存在する必要があります
.gd ファイルが存在する必要があります
.tscn ファイルがあると望ましいです
大容量アセットは少ない方が良いです
機能範囲は小さく、明確である必要があります
現在 JSONL にある API と重複するコードが必要です現在、JSONLに適したキーワードは以下の通りです。
Camera
Camera3D
WorldEnvironment
CameraAttributes
AnimationPlayer
AnimationTree
AnimationNode
AnimationMixer
AudioStream
AudioEffect
CanvasItem
draw_string
draw_rect
modulate
Array.sort
Array.has
AnimatedSprite2D
AStar2D
AStarGrid2D逆に、現在の最初のテストで重要な基準とするには時期尚早なキーワードは次のとおりです。
KinematicBody2D
CharacterBody2D
move_and_slide
yield
await
Color8
TileMap
RigidBody2D
HTTPRequest
multiplayer
GDExtension判断
現在までに収集された JSONL を基準にすると、最初のクローン対象は「小さな Godot 3 移行候補レポジトリ」が良いです。ただし、一般的な 2D プラットフォーマーではなく、Camera/WorldEnvironment/Animation/Audio/CanvasItem 系列を実際に使用しているプロジェクトの方が適しています。
理由は単純です。
現在の api_mapping は Camera、Animation、Audio、CanvasItem、Array 側の根拠をすでに持っています。一方、Godot 3 の 2D フィジックス移行の代表的手がかりである KinematicBody2D、move_and_slide、yield、TileMap はまだ現在の JSONL にほとんどありません。
したがって、最初のテストは次の流れが最も現実的です。
小さな Godot 3 カメラ/アニメーション/オーディオ の例クローン
-> .gd と .tscn の断片化
-> 現在 JSONL で Retriever を検索
-> api_mapping のヒットが実際のコードと関連しているか確認
-> LLM に入るプロンプトのプレビューを確認次に、Godot 4で作成された小さなAnimation/Audio/Cameraの例をクローンし、docs_chunksベースの説明生成フローを確認するのが良いでしょう。
最終的に label_prototypes が生成され、KinematicBody2D、move_and_slide、yield、Color8、TileMap 系列の根拠が蓄積されたら、その時点で典型的な Godot 3 の 2D プラットフォーマーやアクションゲームのリポジトリをクローンして、マイグレーションの判断をテストするのが適切です。
結論
今すぐクローンすべきリポジトリの性格は以下のとおりに決定します。
第一候補：
小さくバージョンが明確な Godot 3 の例
Camera / WorldEnvironment / AnimationPlayer / AnimationTree / Audio / CanvasItem の一部を実際に使用
.gd、.tscn、project.godot を含む
アセットが過度に大きくない
第2候補:
同じ領域を使用する Godot 4 の例
migration よりコード説明と docs_chunks の検索品質検証に使用
保留:
KinematicBody2D / move_and_slide / yield / TileMap中心の Godot 3 2D プラットフォーマー
label_prototypes と関連する migration の根拠がさらに蓄積された後テストこの順序が現在収集された JSONL を最も無駄なく検証する方法のように見えます。