Qwen Godot コード JSONL 根拠 マッチング テスト チェックリスト
作成日: 2026年 6月 28日
目的
Qwen で Godot 3 コードチャンク 50 個を生成し、昨日実施した JSONL 根拠 マッチングテストと同様の方法で 例/いいえ 判定が正しく分かれるか確認する。
今回のテストは、モデルが Godot の知識を持っているかを確認するものではない。SOURCE_CODE と JSONL を同時に入力したとき、JSONL 内に実際のコードチャンクと直接一致する文字列/API/パターン 根拠があるかどうかを判定するテストである。
すなわち、関連する JSONL は 例 として出力され、関連しない JSONL は いいえ として除外されるべきである。
テスト方式
各コードチャンクにつき最低二種類の JSONL を組み合わせてテストする。ただし Godot 3 と Godot 4 で文法が同じ共通文法が存在する可能性があるため、すべての機能を Godot 3 専用文法として扱うわけではない。
| JSONL 種類 | 期待応答 | 意味 |
|---|---|---|
| 正しい JSONL | 例 |
JSONL の source_api、source_pattern、match_terms、required_when_seen_in_code、before_code のいずれかがコードチャンクと直接一致する |
| 誤った JSONL | いいえ |
JSONL が別の API、別のノード、別のシステム、広い語彙だけを共有する根拠である |
各テストは次の入力セットとして扱う。
JSONL
Qwen direct-evidence validator prompt
SOURCE_CODE chunk実際の検証要求は JSONL + プロンプト + チャンク を同時に投げたときに Qwen が はい または いいえ だけを返すかを確認する方式です。
共通文法の場合は同じコードチャンク一つを基準にテストします。このとき正解 JSONL は該当コード/関数に関する説明やパターンを含む JSONL であり、誤答 JSONL は全く別の関数やシステムに関する説明を含む JSONL です。期待応答が はい のケースと いいえ のケースはコードが異なるために分かれるのではなく、JSONL 内に直接根拠があるかないかで分かれるべきです。
繰り返し生成ループ
全体目標は 50 個の機能全体テストです。ただし本日は 5 個まで手作業で確認し、以降は蓄積結果から はい/いいえ の応答パターンを先に分析する形で削減します。
今日の目標: 5個
全体目標: 50/505つを埋めた後は、新しい項目数を無理に増やさず、共通文法/バージョン差異/テーブル別の false positive と false negative の傾向をまず確認する。
テストは以下のフローを繰り返しながらデータを作成する。
1. QwenにテストするGodot機能を一つ与える。
2. その機能が Godot 3/4 共通文法か、Godot 3 固有文法か、Godot 4 固有文法かをまず表示する。
3. 共通文法であれば同じコードチャンクを一つ作る。
4. 共通文法であればそのコード/関数に対する正解 JSONL を一つと、全く別の関数に対する不正解 JSONL を一つ作る。
5. 共通文法でない場合は Godot 4 専用 JSONL と Godot 3 専用 JSONL を別々に作成してテストする。
6. すべての JSONL は対象テーブルのカラムに合わせて作成する。
7. 検証プロンプトに JSONL + SOURCE_CODE チャンクを入れ、`はい`/`いいえ` を確認する。
8. 期待応答と実際の応答が一致するか記録する。核心はコード生成の品質ではなく、JSONL の根拠マッチング判定が安定しているかを見ることです。したがって正解 JSONL は 예 が出力され、誤答 JSONL は 아니오 が出力されなければなりません。
共通文法 注意事項
Godot 3 と Godot 4 で同じ形で維持される文法はバージョン分類テストとして扱ってはいけません。例えば _ready(), _process(delta), 基本変数代入, print() のように両方で使用されるコードがあるかもしれません。
このような場合は次のように見ます。
| コードの性質 | テスト方式 | 期待 |
|---|---|---|
| Godot 3/4 共通文法 | 同じコードチャンク 1 つでその関数 JSONL と全く異なる関数 JSONL をテスト | JSONL の直接根拠のみで 예/아니오 が分かれるべき |
| Godot 3 特有文法 | Godot 3 チャンクを基準に Godot 3 専用 JSONL と Godot 4 専用 JSONL を比較テスト | 実際の Godot 3 文字列/パターンが JSONL にあれば 예 |
| Godot 4 特有文法 | Godot 4 チャンクを基準に Godot 4 専用 JSONL と Godot 3 専用 JSONL を比較テスト | 実際の Godot 4 文字列/パターンが JSONL にあれば 예 |
| バージョン差に関係ない機能説明 | コードがどのバージョンでも JSONL content/code_blocks に直接根拠がある必要がある | 広い意味での類似性だけであれば 아니오 |
したがって記録表には共通文法かどうかを必ず残します。後で結果を見るときに、共通文法なのに migration の根拠として無理に判定したのか、バージョン差がある文法なのに共通文法として扱ったのかを区別するためです。
基準再定義 メモ
4 番と 5 番をテストしながら、確定判定を下すのが難しいことが分かりました。特に Godot 3 基準で JSONL を作成したか、Godot 4 基準で JSONL を作成したかによって、同じコードチャンクの応答が変わり、その差自体がパターン分析の対象となりました。
したがって現在は良し悪しを確定せず、次のように生の応答を先に記録します。
| 区分 | JSONL 作成基準 | 検査コード | 現在の期待フロー |
|---|---|---|---|
| 共通文法 | Godot 3 基準 | 共通コードまたは同じ意味の Godot 3/4 コード | 例, いいえ, 例, いいえ, 例, いいえ |
| 共通文法 | Godot 4 基準 | 共通コードまたは同じ意味の Godot 3/4 コード | 例, いいえ, 例, いいえ, 例, いいえ |
| バージョン差異 | Godot 3 基準 | Godot 3 コード | 例, いいえ, 例, いいえ, 例, いいえ |
| バージョン差異 | Godot 3 基準 | Godot 4 コード | 大部分が いいえ。ただし、api_mapping や prototype が明示的に Godot 3 → 4 変換の根拠を含む場合は一部 例 が出ることがあるため、元の応答を別途確認する |
| バージョン差異 | Godot 4 基準 | Godot 3 コード | 大部分が いいえ。ただし、JSONL が source/target 両方の文字列を同時に含む場合は一部 例 が出ることがあるため、元の応答を別途確認する |
| バージョン差異 | Godot 4 基準 | Godot 4 コード | 例, いいえ, 例, いいえ, 例, いいえ |
応答の順序は基本的に docs_chunks 関連, docs_chunks 無関係, api_mapping 関連, api_mapping 無関係, label_prototypes 関連, label_prototypes 無関係 とみなす。
4 番目も従来は整理された項目として記録したが、Godot 3 の検査で いいえ, いいえ, 例, いいえ, 例, いいえ のような流れがあったため、確定判定から除外する。この文書は今後「いくつが正しかったか」よりも「どの基準でどの応答が揺れ動くか」を見る観察記録とする。
生成リクエスト例
以下は最初の機能である _ready() 関数の初期化およびビューポートサイズ設定をテストする際のリクエスト例です。
JSONL 形式と各 JSONL の用途は別文書に分けました。
_ready() 関数の初期化およびビューポートサイズ設定に合わせた godot3 用のチャンクを1つ、godot4 用のチャンクを1つ提供してください。
ただし、この機能が godot3 と godot4 で共通の文法かどうかをまず示してください。共通の文法であれば、同じコード1つを基準にテストしてもよいと示してください。
そして、docs_chunks JSONL 形式に合った正解 JSONL と、正解でない JSONL を提供してください。この例は docs_chunks を基準としています。api_mapping、label_prototypes も同様の方法で各 JSONL 形式と用途に合わせた正解 JSONL と不正解 JSONL を作成し、同じ検証プロンプトで はい/いいえ を確認します。
検証入力は以下のようになります。
JSONL:
<正解または不正解のJSONL一行>
PROMPT:
<direct-evidence validator prompt>
SOURCE_CODE:
<Godot 3 コードチャンク、Godot 4 コードチャンク、または共通文法コードチャンク>プロンプトは以下のように SOURCE_CODE と JSONL の間の直接的な説明根拠または変換根拠を判定する感じで送ります。
あなたは JSONL 根拠マッチング判定機です。
以下の SOURCE_CODE に対して、以下の JSONL が直接的な説明根拠または変換根拠を含むか判定しなさい。
判定基準:
- JSONL スキーマのいずれかが SOURCE_CODE 内の実際の文字列または API 呼び出しと直接一致している場合のみ「はい」です。
- 単に Godot、Godot3、Godot4、migration、2D、physics などの広い単語が同じであっても関連なしです。
- JSONL が別の API、別のノード、別のシステムに関する内容であれば「いいえ」です。
- あなたが知っている Godot の知識は使用せず、JSONL に記載された文字列根拠だけを使用してください。
- 回答は必ず「はい」または「いいえ」のいずれか一つだけ出力してください。判定マトリックス
| 期待応答 | 実際応答 | 臨時解釈 | 記録内容 |
|---|---|---|---|
예 |
예 |
期待と一致 | 正しい JSONL を直接根拠として認める |
아니오 |
아니오 |
期待と一致 | 誤った JSONL を破棄する |
예 |
아니오 |
再検討必要 | 直接根拠があるのに見落とし。false negative 候補 |
아니오 |
예 |
再検討必要 | 直接根拠がないのに認める。false positive 候補 |
예 または 아니오 |
他の回答 | 再検討必要 | 応答形式違反。説明、JSON、空応答、曖昧な回答を含む |
観察チェックリスト
テーブルごとに 50 件のサンプルテストが終わった後、次の項目を確認する。
| チェック | 基準 | 結果 |
|---|---|---|
| 応答形式 | すべての応答が 예 または 아니오 のみで出力される |
|
| 関連 JSONL 応答 | 関連 JSONL テストで 예 応答が十分に安定して出る |
|
| 無関係 JSONL 応答 | 無関係 JSONL テストで 아니오 応答が十分に安定して出る |
|
| false positive 記録 | 아니오 が正しいのに 예 が出たケースをすべて別途記録 |
|
| false negative 記録 | 예 が正しいのに 아니오 が出たケースをすべて別途記録 |
|
| 広範な単語フィルタ | Godot、migration、2D、physics などの広範な単語だけで 예 が出ない |
|
| 直接文字列根拠 | 예 判定には実際のコード文字列/API/パターンと合致する JSONL フィールドがある |
|
| 共通文法区別 | Godot 3/4 の共通文法サンプルは同じコードチャンク基準で期待 예／期待 아니오 JSONL をテストした |
|
| テーブル別差異 | docs_chunks、api_mapping、label_prototypes で不一致の様相がどう異なるか記録 |
|
| 再現可能性 | 同じ入力を再度入れたとき判定が大きく揺れない | |
| 次の判断 | このプロンプトと判定方式で次の PoC に回してよいか決定する |
テスト記録様式
以下の表をコピーしてテスト結果を埋める。
| ID | 機能 | 共通文法か | テーブル | JSONL 種類 | 期待応答 | 実際応答 | 判定 | 直接一致したフィールド | メモ |
|---|---|---|---|---|---|---|---|---|---|
| G03-001-A | _ready() 関数初期化およびビューポートサイズ設定 |
正しい JSONL | 예 |
||||||
| G03-001-B | _ready() 関数初期化およびビューポートサイズ設定 |
誤った JSONL | 아니오 |
テーブル別記録
docs_chunks
公式ドキュメントの説明型根拠がコードチャンクと直接合っているか確認する。
| 番号 | 機能 | 共通文法かどうか | 関連 JSONL 結果 | 無関係 JSONL 結果 | メモ |
|---|---|---|---|---|---|
| 1 | _ready() 関数の初期化およびビューポートサイズ設定 |
共通文法 | 関連 JSONL はい 観察 |
無関係 JSONL いいえ 観察 |
Node._ready, get_viewport().get_visible_rect().size, DisplayServer.window_set_size がある docs_chunks 説明根拠は はい; _process(delta) 説明 JSONL は いいえ と判定される |
| 2 | _process(delta) フレームごとの更新ループ |
共通文法 | 関連 JSONL はい 観察 |
無関係 JSONL いいえ 観察 |
_process(delta), position.x +=, speed * delta がある docs_chunks 説明根拠は はい; Vector2.lerp 説明 JSONL は いいえ と判定される |
| 3 | プレイヤー移動入力処理（WASD または矢印キー） | 共通文法 | 関連 JSONL はい 観察 |
無関係 JSONL いいえ 観察 |
Input.is_action_pressed, Vector2.ZERO, direction.normalized(), velocity, move_and_slide() がある docs_chunks 説明根拠は はい; TileMapLayer.set_cell() 説明 JSONL は いいえ と判定される |
| 4 | プレイヤー移動速度および加速度適用 | バージョン差異 | 既存双方向 はい 記録は確定判定から除外 |
Godot 3 検査で docs 側が いいえ/いいえ となった流れがあり再検討 |
いいえ, いいえ, はい, いいえ, はい, いいえ の生データ応答のため基準再定義が必要 |
| 5 | プレイヤーの最大速度制限 | バージョン差異 | Godot 3 基準で一次観察。Godot 4 基準の逆方向生データ応答: Godot 4 コード はい/はい, Godot 3 コード はい/はい |
Godot 4 基準の逆方向で docs 候補がすべて はい と判定された |
CharacterBody2D, max_speed, velocity = input_vector * max_speed, move_and_slide(), Input.is_action_pressed が文字列として直接重複。機能範囲を絞るかパターン分析が必要 |
| 6 | マウスクリック時に弾丸生成・発射 | バージョン差異 | Godot 3/4 説明根拠がそれぞれコード基準と合致し 24/24 全体合格フローに含まれる |
他のコード説明 JSONL も期待通り破棄 | PackedScene.instance() と instantiate(), マウス入力処理の差異がコード基準で分離され docs 候補が分かれる |
| 7 | 弾丸の移動および寿命（time‑to‑live）管理 | バージョン差異 | docs_chunks 側の説明根拠が弾丸移動/TTL コードと合致しているか確認 | docs_chunks 無関係説明候補は期待通り破棄 | 全体 22/24 中の不一致は api_mapping/label_prototypes の Godot 3 変換根拠が Godot 4 コードでも はい と付いた側で発生 |
| 8 | 敵（Enemy）のプレイヤー追跡（AI）ロジック | バージョン差異 | Godot 4 docs 説明候補が Godot 3 コードでも はい と付く false positive が観察 |
他のコード説明候補も Godot 3/4 で はい と付くケースがあり再検討が必要 |
全体 21/24; docs_chunks が同じ追跡/移動テーマや類似 API 手がかりを直接説明根拠として広く取った事例 |
| 9 | 敵の移動速度および回転ロジック | バージョン差異 | 移動速度と回転処理の docs 根拠がコード別に期待通りマッチ | 無関係 docs 候補も期待通り破棄 | 24/24 合格。移動/回転目的と最終動作が比較的明確で docs 候補が安定して分離 |
| 10 | プレイヤーが画面外に出たら消える | 共通文法 | 画面外逸脱、global_position, get_viewport_rect().size, hide() 説明根拠が はい と整理 |
他のコード説明候補は いいえ と整理 |
共通文法 6/6 合格。docs 説明根拠と migration 系列候補がうまく分離 |
| 11 | 衝突検知（Area2D または PhysicsBody） | バージョン差異 | 衝突イベント、検知対象、衝突コールバック/物理ボディ関係を説明する docs 候補をコードチャンクと対照 | ダメージ計算や体力処理のように衝突後ロジックを説明する候補と区別 | sample-11 で衝突を「検知」する根拠と衝突後「処理」する根拠が混在しないか確認する項目 |
| 12 | 衝突時のダメージ計算および適用 | 共通文法 | 衝突結果としてダメージ値を計算し対象の体力に適用する説明根拠をコードチャンクと対照 | 単なる衝突検知、得点更新、ゲームオーバー説明候補と区別 | sample-12 は衝突自体よりダメージ式/適用フローが docs 説明根拠の核心か確認 |
| 13 | プレイヤー体力減少ロジック | 共通文法 | プレイヤー体力変数減少、被弾処理、下限値処理の説明根拠をコードチャンクと対照 | 敵体力減少や得点増加候補と区別 | sample-13 は同じ health 文字列があっても対象がプレイヤーか敵かを区別する項目 |
| 14 | プレイヤー体力が 0 になるとゲームオーバー処理 | 共通文法 | health <= 0, ゲームオーバー状態遷移、シーン切替/停止フローの説明根拠をコードチャンクと対照 |
単なる体力減少や敵除去候補と区別 | sample-14 は体力減少ではなく 0 到達後の結果状態が docs 根拠と合致するか確認 |
| 15 | 敵体力減少ロジック | 共通文法 | 敵体力変数減少と被弾処理の説明根拠をコードチャンクと対照 | プレイヤー体力減少や得点増加候補と区別 | sample-15 は対象オブジェクトが enemy か player かが直接説明根拠判定の核心 |
| 16 | 敵が体力 0 になると除去および得点追加 | 共通文法 | 敵除去、queue_free()/非活性化、得点増加フローの説明根拠をコードチャンクと対照 |
単なる体力減少や得点表示候補と区別 | sample-16 は除去と得点追加が同時にある最終動作を説明しているか確認 |
| 17 | 得点（Score）変数更新 | 共通文法 | 得点変数の増減、累積値更新の説明根拠をコードチャンクと対照 | ラベル表示更新や UI レンダリング説明候補と区別 | sample-17 はデータ値更新と画面表示更新を分離して見る項目 |
| 18 | 得点テキスト（Label）更新関数 | 共通文法 | Label.text/文字列フォーマットで得点を画面に反映する説明根拠をコードチャンクと対照 |
得点変数だけを更新する候補と区別 | sample-18 は score 値自体より UI テキスト反映が直接根拠か確認 |
| 19 | 背景音楽（BGM）再生およびボリューム調整 | 共通文法 | BGM 再生ノード、バスボリューム、ループ/ボリューム調整の説明根拠をコードチャンクと対照 | 効果音単発再生候補と区別 | sample-19 は継続再生 BGM と短い SFX 呼び出しを分離して検証する項目 |
| 20 | 効果音（SFX）再生関数 | 共通文法 | 効果音プレイヤー生成/呼び出し、単発再生の説明根拠をコードチャンクと対照 | 背景音楽ループ/ボリューム調整候補と区別 | sample-20 は Audio 関連の共通語だけで BGM 根拠が付かないか確認 |
| 21 | 画面揺れ（Screen Shake）効果実装 | バージョン差異 | カメラオフセット、揺れの強さ/時間、Tween またはランダムオフセットの説明根拠をコードチャンクと対照 | 敵の移動、カメラ追従、UI アニメーション候補と区別 | sample-21 は “カメラ” という語が同じでも画面揺れの結果を直接説明しているか確認 |
| 22 | パーティクルシステム生成および位置合わせ | バージョン差異 | パーティクルノード生成、位置同期、放出開始の説明根拠をコードチャンクと対照 | 通常ノード生成、発射体生成、アニメーション候補と区別 | sample-22 は生成対象が particle か、位置合わせと emission の流れが含まれているか確認 |
| 23 | シーン切替（Scene Change）関数 | バージョン差異 | シーン切替要求、SceneTree 呼び出し、対象シーンパスを説明する docs 候補をコードチャンクと対照 | メニュー表示、一時停止、リソースロードのようにシーン切替自体でない候補と区別 | sample-23 は実際に画面/シーンを変える呼び出しか、単なるロードや UI 表示の説明かを分けて見る |
| 24 | メインメニューシーンのロードおよび表示 | バージョン差異 | メインメニューシーンをロードして画面に表示する説明根拠をコードチャンクと対照 | 単純なシーン切替、一時停止、リソースプリロード候補と区別 | sample-24 はメニューシーンを実際に表示する流れか、別シーンの処理説明かを分けて見る |
| 25 | ゲーム一時停止（Pause）機能トグル | 共通文法 | pause 状態トグル、get_tree().paused、入力に応じた停止/再開の説明根拠をコードチャンクと対照 | メニューを開く、シーン切替、ゲームオーバー候補と区別 | sample-25 は一時停止状態自体を変更するか、単なる UI 表示かを確認 |
| 26 | キーボード入力状態確認（Input.is_key_pressed） | バージョン差異 | Input.is_key_pressed とキー定数/キーコード確認の説明根拠をコードチャンクと対照 | アクションマップ入力、マウス入力、移動処理候補と区別 | sample-26 はキーボード状態取得自体と移動ロジック全体を分けて見る |
| 27 | マウス位置（カーソル）座標取得 | 共通文法 | viewport/global mouse position 取得の説明根拠をコードチャンクと対照 | マウスクリック発射、タッチ入力、カーソル表示候補と区別 | sample-27 はクリックイベントではなく座標を読むコードか確認 |
| 28 | ランダム数生成関数 | バージョン差異 | RNG 初期化、乱数生成、範囲指定の説明根拠をコードチャンクと対照 | ランダム位置分布、敵スポーンタイマー候補と区別 | sample-28 は数値生成関数自体とその数値を使用するゲームプレイロジックを分けて見る |
| 29 | 特定時間ごとの敵スポーン（Spawn） | バージョン差異 | Timer/timeout/累積時間ベースで敵を定期的に生成する説明根拠をコードチャンクと対照 | ランダム位置計算や敵移動 AI 候補と区別 | sample-29 は時間間隔と spawn 呼び出しが直接根拠か確認 |
| 30 | スポーンした敵の位置ランダム分布 | 共通文法 | ランダム座標範囲、spawn エリア、位置分布の説明根拠をコードチャンクと対照 | 特定時間ごとにスポーンするタイマー候補と区別 | sample-30 はいつ生成するかではなく、どこに配置するかを説明しているか確認 |
| 31 | プレイヤーアニメーション状態遷移（Idle, Run, Jump） | バージョン差異 | 入力/速度/状態に応じてアニメーション名を変更する説明根拠をコードチャンクと対照 | アニメーション再生速度や時間制御候補と区別 | sample-31 は状態遷移と再生時間制御を分けて見る |
| 32 | アニメーション再生時間制御 | 共通文法 | animation speed、seek、advance、playback position 制御の説明根拠をコードチャンクと対照 | Idle/Run/Jump 状態遷移候補と区別 | sample-32 はどのアニメーションを選ぶかではなく、再生時間/速度を調整しているか確認 |
| 33 | 衝突領域サイズ調整 | バージョン差異 | CollisionShape2D/Shape2D のサイズ属性、RectangleShape2D の size/extents 系列の説明根拠をコードチャンクと対照 | 衝突検知、ダメージ処理、Area2D signal 候補と区別 | sample-33 は衝突が発生したかどうかではなく、衝突領域の形状/サイズを調整するコードか確認 |
| 34 | 物理重力（Gravity）適用 | バージョン差異 | velocity に gravity と delta を蓄積し move 関数で適用する説明根拠をコードチャンクと対照 | ジャンプ力、着地検知、Area 重力設定候補と区別 | sample-34 は重力蓄積の流れとジャンプ/着地判定を分けて検証する項目 |
| 35 | ジャンプ（Jump）力適用および着地検知 | バージョン差異 | is_on_floor()、ジャンプ速度、入力条件、着地状態の説明根拠をコードチャンクと対照 | 重力だけ適用する候補やアニメーション状態遷移候補と区別 | sample-35 はジャンプ入力と床判定が同じ移動フロー内で説明されているか確認 |
| 36 | 壁衝突時の滑り（Slide）処理 | | | | |
| 37 | プレイヤー方向転換（Facing Left/Right） | | | | |
| 38 | 弾薬（Ammo）カウント減少 | | | | |
| 39 | 弾薬がなくなったときのリロード（Reload）状態遷移 | | | | |
| 40 | UI ボタンクリックイベント接続 | | | | |
| 41 | 設定（Settings）メニュー開閉トグル | | | | |
| 42 | 言語（Language）変更時のテキスト更新 | | | | |
| 43 | 保存データ（Save Game）JSON シリアライズ | | | | |
| 44 | 読み込みデータ（Load Game）JSON デシリアライズ | | | | |
| 45 | ファイル読み書きエラー処理 | | | | |
| 46 | ネットワーク接続状態チェック | | | | |
| 47 | リモート関数（RPC）呼び出しによる同期 | | | | |
| 48 | シーンリソース動的ロード | | | | |
| 49 | メモリ解放およびリソースアンロード | | | | |
| 50 | デバッグログ出力（print または print_debug） | | | | |
api_mapping
Godot 3からGodot 4へ名前、クラス、関数、シンボルがどのように変わるかの根拠がコードチャンクと直接合っているか確認する。
| 番号 | 機能 | 共通文法か | 関連 JSONL 結果 | 無関係 JSONL 結果 | メモ |
|---|---|---|---|---|---|
| 1 | _ready() 関数の初期化およびビューポートサイズ設定 |
共通文法 | 関連 JSONL 例 観察 |
無関係 JSONL いいえ 観察 |
DisplayServer.window_set_size、Vector2i があるマッピングは 例；AudioServer.get_bus_volume_db のマッピングは いいえ と判定 |
| 2 | _process(delta) フレームごとの更新ループ |
共通文法 | 関連 JSONL 例 観察 |
無関係 JSONL いいえ 観察 |
position.x、delta、_process がある stable マッピングは 例；get_node("Sprite2D") のマッピングは いいえ と判定 |
| 3 | プレイヤー移動入力処理（WASD または矢印キー） | 共通文法 | 関連 JSONL 例 観察 |
無関係 JSONL いいえ 観察 |
CharacterBody2D.move_and_slide、velocity、Vector2 があるマッピングは 例；Node.connect/signal connect のマッピングは いいえ と判定 |
| 4 | プレイヤー移動速度および加速度の適用 | バージョン差異 | 既存の双方向 例 記録は確定判定から除外 |
Godot 3 の検査で api_mapping 側は 例/いいえ に分岐 |
move_and_slide、CharacterBody3D、move_toward、velocity.x、velocity.z、target_velocity のマッピングがコードバージョンに応じてどう反応するか再検討が必要 |
| 5 | プレイヤーの最大速度制限 | バージョン差異 | Godot 3 基準で一次観察。Godot 4 基準の逆方向生データ応答：Godot 4 コード 例/例、Godot 3 コード いいえ/いいえ |
Godot 4 コードではマッピング候補 2 件とも 例、Godot 3 コードではすべて いいえ |
move_and_slide、velocity、limit_speed、衝突法線の返却差異を基準に。Godot 4 文法と Godot 3 文法を期待値としてどう分けるかパターン分析が必要 |
| 6 | マウスクリック時に弾丸を生成・発射 | バージョン差異 | Godot 3/4 の弾丸生成 API の違いと入力処理のマッピングが期待通りにマッチ | 無関係マッピング候補も廃止 | PackedScene.instance() と instantiate() のように source/target 形態が分離され、24/24 通過フローに含まれる |
| 7 | 弾丸の移動および寿命（time‑to‑live）管理 | バージョン差異 | Godot 3 基準で変換マッピングが Godot 3 コードでは 例 と判定 |
同じマッピングが Godot 4 コードでも 例 と付いて不一致が観察 |
全体 22/24；すでに Godot 4 コードであれば変換適用対象ではないので、検証プロンプトで source‑side かどうかをより明確に見る必要あり |
| 8 | 敵（Enemy）のプレイヤー追跡（AI）ロジック | バージョン差異 | api_mapping 側は 8 番の不一致の直接原因ではなかった | 無関係マッピング候補は期待通りに廃止されるフロー | 全体の不一致は docs_chunks で発生。マッピングは追跡 AI コードのバージョン別 API 変更有無を確認する補助軸として記録 |
| 9 | 敵の移動速度および回転ロジック | バージョン差異 | 回転/移動関連マッピングがコード基準と合致してマッチ | 無関係マッピング候補も期待通りに廃止 | 24/24 通過。移動速度と回転 API の差異が比較的うまく分離されている |
| 10 | プレイヤーが画面外に出たら消える | 共通文法 | 共通コードなので api_mapping 関連 JSONL は変換不要と判断 | 無関係変換候補も いいえ フロー |
6/6 通過。共通文法では migration テーブルが付かないフローが確認される |
| 11 | 衝突検知（Area2D または PhysicsBody） | バージョン差異 | Area2D/PhysicsBody の衝突検知 API や signal 接続の変化が現在のコードに必要なマッピングか確認 | ダメージ適用や体力処理のマッピングとは区別 | sample-11 は検知 API 自体とその後の処理ロジックを分離するマッピング判定項目 |
| 12 | 衝突時のダメージ計算および適用 | 共通文法 | ダメージ適用方法でバージョン別 API 変更が実際のコードにあるか確認 | 衝突検知 signal のみを説明するマッピングとは区別 | sample-12 はマッピングが必要な変更か、単なるゲームロジック説明かを分ける項目 |
| 13 | プレイヤー体力減少ロジック | 共通文法 | プレイヤー体力減少コードにバージョン別 API 変更根拠が実際に必要か確認 | 敵体力/スコア/ゲームオーバーのマッピング候補とは区別 | sample-13 はほとんどゲームロジック性が強く、migration 根拠が過剰に付かないか観察 |
| 14 | プレイヤー体力が 0 になるとゲームオーバー処理 | 共通文法 | ゲームオーバー処理でシーン遷移、pause、tree API の変化がコードに直接あるか確認 | 単なる体力減少マッピング候補とは区別 | sample-14 は結果状態遷移 API がマッピング根拠かどうかを確認 |
| 15 | 敵体力減少ロジック | 共通文法 | 敵体力減少ロジックに実際の Godot 3→4 API 変更根拠が必要か確認 | プレイヤー体力処理やスコア処理のマッピングとは区別 | sample-15 は対象オブジェクトが異なるため、マッピング候補が検索されても いいえ と落ちるべき項目 |
| 16 | 敵が体力 0 になると削除およびスコア加算 | 共通文法 | 削除 API、スコア更新 API、シーンツリー操作の差異が現在のコードにあるか確認 | 単なるダメージマッピングや Label 更新マッピングとは区別 | sample-16 は削除とスコア加算のどの部分がマッピング根拠かを分離して見る |
| 17 | スコア（Score）変数更新 | 共通文法 | スコア変数更新に実際の API 変更根拠が必要か確認 | UI テキスト更新や保存/ロードのマッピングとは区別 | sample-17 は単なる変数演算を migration 根拠として過大評価しないかを見る項目 |
| 18 | スコアテキスト（Label）更新関数 | 共通文法 | Label テキストへのアクセス方法やノード参照方式の変化が現在のコードに必要か確認 | スコア値計算のマッピングとは区別 | sample-18 は Label.text 系の表現が共通か、バージョン別変更があるかを確認 |
| 19 | 背景音楽（BGM）再生およびボリューム調整 | 共通文法 | AudioServer、AudioStreamPlayer、バスボリューム関連の変更根拠がコードに直接必要か確認 | SFX の単発再生マッピングとは区別 | sample-19 はオーディオ関連の広い語だけでマッピングが付かないように見る項目 |
| 20 | 効果音（SFX）再生関数 | 共通文法 | 効果音再生 API やノード生成方式の変化がコードに直接あるか確認 | BGM ループ/ボリューム調整のマッピングとは区別 | sample-20 は SFX と BGM が同じ Audio 系でも変換根拠を分離して見る |
| 21 | 画面揺れ（Screen Shake）効果実装 | バージョン差異 | Tween、Camera2D、offset/random shake 実装でバージョン別 API 変化があるか確認 | カメラ追跡や一般移動のマッピングとは区別 | sample-21 はカメラ関連候補が画面揺れ変換根拠かどうかを検証 |
| 22 | パーティクルシステムの生成と位置合わせ | バージョン差異 | Particles2D/GPUParticles2D、emitting、position/global_position に関する変更根拠がコードに直接あるか確認 | 発射体生成や一般ノード生成のマッピングと区別 | sample-22 はパーティクルシステム専用 API の変化と一般生成ロジックを分けて見る |
| 23 | シーン切り替え（Scene Change）関数 | バージョン差異 | change_scene、change_scene_to_file、change_scene_to_packed 系の変更根拠が現在のコードに直接あるか確認 | 単純な load()/preload() やメインメニュー表示のマッピングと区別 | sample-23 は Godot 3 のシーン切り替え呼び出しと Godot 4 の代替呼び出しが実際のコードバージョンに合わせて付いているか確認 |
| 24 | メインメニューシーンのロードと表示 | バージョン差異 | シーンロード、インスタンス化、メニューシーン表示に関する変更根拠が現在のコードに必要か確認 | 一般的なシーン切り替えやリソース preload のマッピングと区別 | sample-24 はメインメニュー表示目的とシーン API の変更根拠が混ざっていないか見る項目 |
| 25 | ゲーム一時停止（Pause）機能トグル | 共通文法 | pause mode / process mode、ツリーポーズに関する変更根拠が現在のコードで実際に必要か確認 | メニュー UI やゲームオーバーのマッピングと区別 | sample-25 は共通 pause トグルコードにマイグレーションマッピングが過剰に付いていないか確認 |
| 26 | キーボード入力状態確認（Input.is_key_pressed） | バージョン差異 | キー定数、scancode/keycode、Input.is_key_pressed に関する変更根拠がコードと直接合っているか確認 | アクションマップの移動処理やマウス入力のマッピングと区別 | sample-26 はキー状態取得 API の変化と入力を使用するゲームプレイロジックを分けて見る |
| 27 | マウス位置（カーソル）座標取得 | 共通文法 | mouse position 取得 API がバージョン別に変更根拠を必要とするか確認 | クリックで発射体生成やタッチ入力のマッピングと区別 | sample-27 は座標読み取りコードに不要な変換根拠が付いていないか確認 |
| 28 | ランダム数生成関数 | バージョン差異 | randomize、RandomNumberGenerator、range 関数の変更根拠がコードに直接あるか確認 | ランダムスポーン位置や spawn timer のマッピングと区別 | sample-28 は乱数 API 自体の変更と乱数使用目的を分離して見る |
| 29 | 特定時間ごとの敵スポーン（Spawn） | バージョン差異 | Timer シグナル、timeout 接続、yield/await 系の変更根拠が現在のコードに直接あるか確認 | 敵位置のランダム分布や敵 AI 移動のマッピングと区別 | sample-29 は周期実行構造と生成対象ロジックを共に確認 |
| 30 | スポーンした敵の位置ランダム分布 | 共通文法 | random range、viewport size、spawn エリア計算に実際の API 変更根拠が必要か確認 | Timer ベースの周期 spawn のマッピングと区別 | sample-30 は位置計算だけのコードに spawn 周期のマッピングが付いていないか確認 |
| 31 | プレイヤーアニメーション状態遷移（Idle、Run、Jump） | バージョン差異 | AnimatedSprite/AnimatedSprite2D、AnimationPlayer の状態遷移に関する変更根拠がコードと直接合っているか確認 | playback speed/seek/time 制御のマッピングと区別 | sample-31 はアニメーションノード名の変更と状態遷移パターンを分離して見る |
| 32 | アニメーション再生時間制御 | 共通文法 | playback speed、seek、current position に関する変更根拠が現在のコードに必要か確認 | Idle/Run/Jump 状態選択のマッピングと区別 | sample-32 は再生時間調整 API と状態遷移 API を区別 |
| 33 | 衝突領域サイズ調整 | バージョン差異 | CollisionShape2D、RectangleShape2D、shape size/extents の変更根拠が現在のコードに直接必要か確認 | collision signal、physics layer、damage のマッピングと区別 | sample-33 は衝突判定 API ではなく shape サイズ調整 API の変化が実際のコードと合っているか見る項目 |
| 34 | 物理重力（Gravity）適用 | バージョン差異 | CharacterBody2D/KinematicBody2D、velocity、move_and_slide 系の変更根拠が現在のコードに直接必要か確認 | jump impulse、floor check、Area2D 重力のマッピングと区別 | sample-34 は物理フレームで重力を蓄積して移動に反映するマッピングか確認 |
| 35 | ジャンプ（Jump）力適用と着地検知 | バージョン差異 | is_on_floor()、jump velocity、Input アクション、move_and_slide に関する変更根拠がコードと直接合っているか確認 | gravity のみの移動、アニメーション状態、壁衝突のマッピングと区別 | sample-35 はジャンプ開始条件と着地判定が共に必要なマッピングか確認 |
| 36 | 壁衝突時の滑り（Slide）処理 | | | | |
| 37 | プレイヤー方向転換（Facing Left/Right） | | | | |
| 38 | 弾薬（Ammo）カウント減少 | | | | |
| 39 | 弾薬がなくなったときのリロード（Reload）状態遷移 | | | | |
| 40 | UI ボタンクリックイベント接続 | | | | |
| 41 | 設定（Settings）メニュー開閉トグル | | | | |
| 42 | 言語（Language）変更時のテキスト更新 | | | | |
| 43 | 保存データ（Save Game）JSON シリアライズ | | | | |
| 44 | 読み込みデータ（Load Game）JSON デシリアライズ | | | | |
| 45 | ファイル読み書きエラー処理 | | | | |
| 46 | ネットワーク接続状態チェック | | | | |
| 47 | リモート関数（RPC）呼び出しによる同期化 | | | | |
| 48 | シーンリソースの動的ロード | | | | |
| 49 | メモリ解放とリソースアンロード | | | | |
| 50 | デバッグログ出力（print または print_debug） | | | | |
label_prototypes
単なる名前の変更ではなく、関数の使用方法、引数の構成、呼び出しパターンが全体的に変わる例がコードチャンクと直接合っているか確認する。
| 番号 | 機能 | 共通文法か | 関連 JSONL 結果 | 無関係 JSONL 結果 | メモ |
|---|---|---|---|---|---|
| 1 | _ready() 関数の初期化およびビューポートサイズ設定 |
共通文法 | 関連 JSONL 例 を観察 |
無関係 JSONL いいえ を観察 |
DisplayServer.window_set_size(Vector2i(1920, 1080)) プロトタイプは 例; AudioStreamPlayer3D プロトタイプは いいえ と判定 |
| 2 | _process(delta) フレームごとの更新ループ |
共通文法 | 関連 JSONL 例 を観察 |
無関係 JSONL いいえ を観察 |
func _process(delta) と position.x += move_speed * delta プロトタイプは 例; _input(event)/event.is_action_pressed プロトタイプは いいえ と判定 |
| 3 | プレイヤー移動入力処理（WASD または矢印キー） | 共通文法 | 関連 JSONL 例 を観察 |
無関係 JSONL いいえ を観察 |
Input.is_action_pressed, velocity = direction * move_speed, move_and_slide() プロトタイプは 例; @onready/ノードパスアクセス プロトタイプは いいえ と判定 |
| 4 | プレイヤーの移動速度および加速度適用 | バージョン差異 | 既存の双方向 例 記録は確定判定から除外 |
Godot 3 の検査で label_prototypes 側は 例/いいえ に分かれる |
軸別 move_toward(velocity.x/velocity.z), move_and_slide(), CharacterBody3D プロトタイプがバージョン専用根拠か共通文字列根拠か再検討が必要 |
| 5 | プレイヤーの最大速度制限 | バージョン差異 | Godot 3 基準で一次観察。Godot 4 基準の逆方向生データ応答: Godot 4 コード 例/いいえ, Godot 3 コード 例/いいえ |
Tween プロトタイプは両方とも いいえ と廃止 |
CharacterBody2D, move_and_slide(), velocity が両コードに存在するため、関連プロトタイプは両方とも 例 と判定。バージョン専用根拠と共通文字列根拠を分離すべき |
| 6 | マウスクリック時に弾丸を生成・発射 | バージョン差異 | 弾丸生成/発射呼び出しパターンのプロトタイプがコード基準と正しくマッチ | 無関係プロトタイプ候補も廃止 | 24/24 通過フローに含まれる。入力処理と projectile 生成パターンがうまく分離されている |
| 7 | 弾丸の移動および寿命（time‑to‑live）管理 | バージョン差異 | Godot 3 基準の変換プロトタイプが Godot 3 コードでは 例 と判定 |
同じプロトタイプが Godot 4 コードにも 例 と付いている不一致を観察 |
全体 22/24; すでに変換済みの Godot 4 コードに “変換必要” プロトタイプが付いてはいけないケース |
| 8 | 敵（Enemy）のプレイヤー追跡（AI）ロジック | バージョン差異 | label_prototypes 側は 8 番の不一致の直接原因ではなかった | 無関係プロトタイプ候補は期待通りに廃止されるフロー | 全体の不一致は docs_chunks で発生。プロトタイプは追跡 AI の使用方法変化有無を見る補助軸として記録 |
| 9 | 敵の移動速度および回転ロジック | バージョン差異 | 移動/回転呼び出しパターンのプロトタイプがコード基準と正しくマッチ | 無関係プロトタイプ候補も期待通りに廃止 | 24/24 通過。移動速度計算と回転適用パターンが比較的明瞭に分離 |
| 10 | プレイヤーが画面外に出たら消える | 共通文法 | 共通コードなので label_prototypes 関連 JSONL は変換不要と判断 | 無関係変換候補も いいえ フロー |
6/6 通過。共通文法ではプロトタイプが付かないフローが確認 |
| 11 | 衝突検知（Area2D または PhysicsBody） | バージョン差異 | 衝突検知シグナル/コールバック使用方法が現在コードの変更前パターンか確認 | 衝突後のダメージ適用プロトタイプと区別 | sample-11 は検知イベントパターンとその後のゲームプレイ処理パターンを分けて見る項目 |
| 12 | 衝突時のダメージ計算および適用 | 共通文法 | 衝突結果としてダメージを適用する呼び出しパターンが現在コードに直接あるか確認 | 単純な衝突検知や体力 0 処理プロトタイプと区別 | sample-12 は引数構成、対象オブジェクト、ダメージ適用順序がプロトタイプ根拠か確認 |
| 13 | プレイヤーの体力減少ロジック | 共通文法 | プレイヤー被弾/体力減少パターンが現在コードに直接あるか確認 | 敵の体力減少プロトタイプと区別 | sample-13 は同じ health 系列でも player/enemy の対象差を検証 |
| 14 | プレイヤーの体力が 0 になったらゲームオーバー処理 | 共通文法 | 体力 0 後のゲームオーバー呼び出しパターンが現在コードに直接あるか確認 | 単純な体力減少や敵除去プロトタイプと区別 | sample-14 は条件式後の状態遷移/シーン処理までプロトタイプが説明しているか確認 |
| 15 | 敵の体力減少ロジック | 共通文法 | enemy のダメージ/体力減少パターンが現在コードに直接あるか確認 | player のダメージプロトタイプと区別 | sample-15 は対象オブジェクトと状態変数名が広く重なると false positive が生じるかを見る項目 |
| 16 | 敵の体力が 0 になったら除去およびスコア加算 | 共通文法 | enemy 除去と score 増加が同時にある呼び出しパターンが現在コードに直接あるか確認 | 単純なスコア更新や単独除去プロトタイプと区別 | sample-16 は複数の動作が束ねられたプロトタイプが SOURCE_CODE の実際の順序と合っているか確認 |
| 17 | スコア（Score）変数の更新 | 共通文法 | score 変数更新パターンが現在コードに直接あるか確認 | Label テキスト反映プロトタイプと区別 | sample-17 は内部データ更新と UI 表示更新を分ける項目 |
| 18 | スコアテキスト（Label）更新関数 | 共通文法 | Label テキスト更新パターンが現在コードに直接あるか確認 | score 変数だけを変えるプロトタイプと区別 | sample-18 は値変更ではなく画面表示に関するプロトタイプか確認 |
| 19 | 背景音楽（BGM）再生およびボリューム調整 | 共通文法 | BGM 再生/ボリューム調整パターンが現在コードに直接あるか確認 | SFX の単発再生プロトタイプと区別 | sample-19 は Audio 系列の共通語より継続再生/ボリューム調整目的を見る項目 |
| 20 | 効果音（SFX）再生関数 | 共通文法 | SFX 呼び出し/再生パターンが現在コードに直接あるか確認 | BGM ループやバスボリュームプロトタイプと区別 | sample-20 は短い効果音再生と背景音楽管理フローを区別 |
| 21 | 画面振動（Screen Shake）効果実装 | バージョン差異 | 画面揺れの強度/時間/オフセット適用パターンが現在コードに直接あるか確認 | カメラ追従や一般 Tween プロトタイプと区別 | sample-21 は Camera2D/Tween があっても最終効果が shake かどうか確認 |
| 22 | パーティクルシステム生成および位置合わせ | バージョン差異 | パーティクル生成、位置合わせ、emitting 開始パターンが現在コードに直接あるか確認 | 弾丸生成や一般ノード生成プロトタイプと区別 | sample-22 は位置同期と放出開始までプロトタイプが説明しているか確認 |
| 23 | シーン切り替え（Scene Change）関数 | バージョン差異 | シーンパスを受け取り SceneTree に切り替える呼び出しパターンが現在のコードに直接あるか確認 | 単純リソースロード、メニュー表示、ポーズプロトタイプと区別 | sample-23 はシーン切り替えの入力パス、呼び出し対象、切り替え結果までプロトタイプが説明しているか確認 |
| 24 | メインメニューシーンのロードと表示 | バージョン差異 | メニューシーンを読み込み表示する呼び出しパターンが現在のコードに直接あるか確認 | 単純リソースロード、シーン切り替え、ポーズメニュープロトタイプと区別 | sample-24 は「メインメニューを表示する」結果までプロトタイプが説明しているか確認 |
| 25 | ゲーム一時停止（Pause）機能トグル | 共通文法 | pause 状態を反転し関連 UI/入力処理をまとめるパターンが現在のコードに直接あるか確認 | 設定メニューを開くやゲームオーバープロトタイプと区別 | sample-25 は pause フラグ変更と画面表示を同じフローで見るべきか確認 |
| 26 | キーボード入力状態確認（Input.is_key_pressed） | バージョン差異 | キー入力状態を直接ポーリングするパターンが現在のコードにあるか確認 | アクション強度、移動ベクトル、マウス入力プロトタイプと区別 | sample-26 は入力取得とその入力で実行する動作を分離して記録 |
| 27 | マウス位置（カーソル）座標取得 | 共通文法 | カーソル座標を読み取り変数や位置計算に使用するパターンが現在のコードに直接あるか確認 | マウスクリックイベントや弾丸生成プロトタイプと区別 | sample-27 は mouse position の取得自体が核心か確認 |
| 28 | ランダム数生成関数 | バージョン差異 | 乱数生成／範囲指定の呼び出しパターンが現在のコードに直接あるか確認 | スポーン位置分布、ドロップテーブル、タイマー spawn プロトタイプと区別 | sample-28 は random API 呼び出しと random 結果の使用先を分離して見る |
| 29 | 特定時間ごとの敵スポーン（Spawn） | バージョン差異 | 定期的に spawn 関数を呼び出すパターンが現在のコードに直接あるか確認 | ランダム位置計算や敵追跡 AI プロトタイプと区別 | sample-29 は時間条件、タイマー、spawn 呼び出し順序が正しいか確認 |
| 30 | スポーンした敵の位置ランダム分布 | 共通文法 | 生成された敵の位置をランダム範囲内に配置するパターンが現在のコードに直接あるか確認 | 定期的に生成する spawn ループプロトタイプと区別 | sample-30 は分布／座標計算と生成周期を分離 |
| 31 | プレイヤーアニメーション状態切替（Idle、Run、Jump） | バージョン差異 | 状態値や速度に応じて animation 名を変更するパターンが現在のコードに直接あるか確認 | 再生速度、シーク、フレーム／時間制御プロトタイプと区別 | sample-31 はどの状態に切り替えるかが核心か確認 |
| 32 | アニメーション再生時間制御 | 共通文法 | 再生速度、シーク、現在の再生位置を制御するパターンが現在のコードに直接あるか確認 | Idle/Run/Jump 状態切替プロトタイプと区別 | sample-32 はアニメーション選択ではなく再生時間制御が核心か確認 |
| 33 | 衝突領域サイズ調整 | バージョン差異 | 衝突シェイプのサイズ値を読み取ったり変更したりするパターンが現在のコードに直接あるか確認 | 衝突イベント処理やダメージ適用プロトタイプと区別 | sample-33 はシェイプサイズ変更が核心か、衝突結果処理かを分離して記録 |
| 34 | 物理重力（Gravity）適用 | バージョン差異 | delta に基づき重力を velocity に蓄積し移動呼び出しで反映するパターンが現在のコードに直接あるか確認 | ジャンプ入力、着地確認、スポーン／タイマープロトタイプと区別 | sample-34 は物理移動ループ内での重力蓄積が核心か確認 |
| 35 | ジャンプ（Jump）力適用と着地検知 | バージョン差異 | 地面にいるときにジャンプ力を適用し、その後の着地有無を確認するパターンが現在のコードに直接あるか確認 | 重力蓄積のみの移動プロトタイプやアニメーション状態切替プロトタイプと区別 | sample-35 はジャンプ条件、垂直速度変更、フロア判定が一つのフローで束ねられるか確認 |
| 36 | 壁衝突時の滑り（Slide）処理 | | | | |
| 37 | プレイヤー方向転換（Facing Left/Right） | | | | |
| 38 | 弾薬（Ammo）カウント減少 | | | | |
| 39 | 弾薬がなくなったときのリロード（Reload）状態切替 | | | | |
| 40 | UI ボタンクリックイベント接続 | | | | |
| 41 | 設定（Settings）メニュー開閉トグル | | | | |
| 42 | 言語（Language）変更時のテキスト更新 | | | | |
| 43 | 保存データ（Save Game）JSON シリアライズ | | | | |
| 44 | 読み込みデータ（Load Game）JSON デシリアライズ | | | | |
| 45 | ファイル読み書きエラー処理 | | | | |
| 46 | ネットワーク接続状態チェック | | | | |
| 47 | リモート関数（RPC）呼び出しによる同期 | | | | |
| 48 | シーンリソース動的ロード | | | | |
| 49 | メモリ解放とリソースアンロード | | | | |
| 50 | デバッグログ出力（print または print_debug） | | | | |
2026年7月6日 追加記録
6番から10番までは2026年7月3日にすでに改善フローまで反映して詳細観察を残した区間です。したがって今回の文書では6〜10番を空欄にせず、既存の観察内容を docs_chunks、api_mapping、label_prototypes 表にもそれぞれ合わせて記入しました。
2026年7月6日には http://localhost:8520/#item=sample-22 を基準に11番から22番まで追加記録しました。この区間は各項目でどの根拠候補が該当する JSONL か、どの候補が別のコード／別の変換／別のパターンに分けられるべきかを項目別に詳述します。
2026年7月8日 追加記録
2026年7月8日には http://localhost:8520/#item=sample-32 を基準に23番以降、32番まで追加記録しました。この区間も確定判定表というより、docs_chunks、api_mapping、label_prototypes が同じコードチャンクをそれぞれどの観点で説明または拒否すべきかを残す観察表とみなします。
2026年7月13日 追加記録
2026年7月13日には http://localhost:8520/#item=sample-35 を基準に33番以降、35番まで記録しました。今回の区間は衝突領域のサイズ、重力、ジャンプ／着地のように物理的移動と衝突形態が互いに影響し合う項目であり、単なる文字列の重複よりもコードの目的と適用位置を併せて見る必要があるようです。
5番 逆方向観察
5番は本日の目標数量には入っていましたが、Godot 4 基準の JSONL で逆方向に検査したときに結果がきれいな はい/いいえ のペアだけにはなりませんでした。したがって確定可否を判断せず、次の段階でパターン分析の対象とします。
応答順序は docs_chunks #1、docs_chunks #2、api_mapping #1、api_mapping #2、label_prototypes #1、label_prototypes #2 です。
| 検査コード | 応答順序 | 観察 |
|---|---|---|
| Godot 4 コード | はい, はい, はい, はい, はい, いいえ |
limit_speed、velocity、move_and_slide()、Input.is_action_pressed のようにコードと直接重なる文字列が多く、docs/api 候補が広く はい と判断される |
| Godot 3 コード | はい, はい, いいえ, いいえ, はい, いいえ |
docs 候補と CharacterBody2D プロトタイプは はい と判断されるが、Godot 4 基準の api_mapping 候補は いいえ に分かれる |
この結果は単にモデルが間違ったと見るより、JSONL 内の match_terms、required_when_seen_in_code、content が広すぎるかどうかを確認すべきシグナルとみなします。特に move_and_slide() や Input.is_action_pressed のように共通して出現する文字列は直接的な根拠になりますが、最大速度制限やバージョン差異の根拠としては広すぎる可能性があります。
不一致ケース記録
False Positive
いいえ が正しいのに はい と出たケースを記入します。
| ID | 機能 | 共通文法か | テーブル | 誤った JSONL 要約 | Qwen 応答 | 再検討理由 |
|---|---|---|---|---|---|---|
False Negative
はい が正しいのに いいえ と出たケースを記入します。
| ID | 機能 | 共通文法か | テーブル | 正しい JSONL 要約 | Qwen 応答 | 再検討理由 |
|---|---|---|---|---|---|---|
応答形式違反
はい または いいえ ではなく説明文、JSON、空応答、複数文で答えたケースを記入します。
| ID | 機能 | 共通文法か | テーブル | 期待応答 | 実際応答 | メモ |
|---|---|---|---|---|---|---|
観察要約
テストを進めながら以下の数字と生の応答を埋めます。ここでは判定を確定せず、応答がどの基準で揺れ動くかを見るだけです。
| 項目 | docs_chunks | api_mapping | label_prototypes | 合計 |
|---|---|---|---|---|
| 本日の観察量 | 23~32 追加記録 | 23~32 追加記録 | 23~32 追加記録 | 2026-07-08 基準 23~32 追加記録 |
| 全体観察量 | 32/50 テスト記録 | 32/50 テスト記録 | 32/50 テスト記録 | 32/50 テスト記録 |
| テストしたコードチャンク数 | 32/50 | 32/50 | 32/50 | 32/50 |
| 共通文法サンプル数 | 累積算定保留 | 累積算定保留 | 累積算定保留 | 32番までラベル記録後別途集計必要 |
| バージョン差異サンプル数 | 累積算定保留 | 累積算定保留 | 累積算定保留 | 32番までラベル記録後別途集計必要 |
| 第1基準 期待応答一致数 | 5 | 5 | 5 | 15 |
| 第1基準 期待応答不一致数 | 0 | 0 | 0 | 0 |
| 5番 Godot 4 基準 逆方向生応答 | Godot 4 はい/はい、Godot 3 はい/はい |
Godot 4 はい/はい、Godot 3 いいえ/いいえ |
Godot 4 はい/いいえ、Godot 3 はい/いいえ |
パターン分析必要 |
| 応答形式違反 | 0 | 0 | 0 | 0 |
| 再検討必要 | 2 | 2 | 2 | 4番/5番 基準で再定義必要 |
| 現在の判断 | 確定判定保留 | 確定判定保留 | 確定判定保留 | 23~32 追加記録まで含めて後続パターン分析必要 |