2026-06-14 振り返り
ソウルへ向かうバスの中で思ったこと
今日はソウルへ向かうバスの中で、前回設計した Godot 4 データセット / RAG パイプラインを改めて考え直した。6月12日には公式ドキュメントをクローリングし、GitHub から Godot プロジェクトを収集したうえで、RAG チャットボットをフロントに置き、Godot 3/4 の判別と instruction データを作る構造を考えた。
しかし今日改めて考えてみると、この構造が実際にうまく動作するためにはまだ解決すべき疑問がかなり多いことに気付いた。特に「ドキュメントを集めた」ことと「モデルがそのドキュメントをうまく利用できる」ことの間には、思った以上に大きなギャップがある点がずっと引っかかっていた。
第一の疑問：RAG チャットボットは全体コンテキストを処理できるか
従来は Godot 公式ドキュメントをクローリングして RAG チャットボットを作れば、収集した GitHub プロジェクトを分類したり検証したりできると考えていた。しかし GitHub プロジェクトをスクレイピングして md、jsonl 形式に変換し、その内容を一度にチャットボットに投げ込むシナリオを思い描くと疑問が生じた。
モデルはその入力コンテキストをすべて受け取れるだろうか？
たった一つの Godot プロジェクトでも README、ディレクトリ構造、複数の .gd ファイル、シーンファイル、リソースパスが含まれる。そこに RAG で検索された公式ドキュメントの断片まで加われば、入力はすぐに膨らむ。単にクローリングしたドキュメントが存在するだけで、モデルが毎回プロジェクト全体と関連ドキュメントを安定して読めるわけではない。
結局 RAG チャットボットを作るということは、ドキュメントを丸ごと入れることではなく、どの質問でどのドキュメント断片を取得するかを決める検索／選別構造を作ることに近い。この部分が甘いと、モデルは重要なファイルを見逃したり、不要なドキュメントを読みすぎて本来必要なプロジェクトの文脈を失う可能性がある。
第二の疑問：質問一つに回答コード一つで十分か
二つ目に浮かんだ疑問は instruction データセットの形態だった。例えば「マップを作って」という質問を考えると、その回答は単なるコードの塊だけではないかもしれない。
LLM が実際に答えを生成するには複数のステップが必要になる。プロジェクト構造を見て、どのシーンやスクリプトがあるか把握し、利用できるアセットを確認し、既存のコードスタイルを読み取り、Godot 4 の文法に合っているか検証し、最後に修正すべきファイルとコードを決定しなければならない。
つまり「マップを作って」という質問は表面的には一つのリクエストだが、内部的には複数の推論レイヤーを経る作業である。ところが学習データに最終的な回答コードだけを残すと、モデルがその中間判断プロセスを学べるか疑問が生じた。
正解データには単に完成コードだけでなく、どのファイルを読んだか、どの情報を根拠に判断したか、なぜ特定の API を選んだかといったプロセスがある程度含まれている必要があるかもしれない。特にコーディングエージェントとして機能させたいなら「質問 → 回答」よりも「質問 → 探索 → 判断 → 修正 → 検証」という流れをデータとして残す方が適切かもしれない。
第三の疑問：チャンク単位処理で Python の重みが再び出てこないか
三つ目の疑問は言語重みの問題だった。「Godot 4 でマップを作って」とプロンプトを与えても、モデルが既存プロジェクトやドキュメントをチャンク単位で読み進める過程で、Python コードや Python 風の問題解決パターンの重みが強く働いてしまわないかという考えが浮かんだ。
従来の汎用コーディングモデルは Python をはるかに多く学習している可能性が高い。したがって Godot という語を前に付けるだけでは不十分かもしれない。特に検索されたチャンク内に Godot 4 の文脈が十分に強くない場合や、中間推論過程で一般的なコーディングパターンが想起されると、Python 風の回答に流れる可能性が残る。
そこで単に「Godot 4 で書いて」と言うだけでなく、プロンプトやデータ前処理段階で Godot 4 の文脈をはるかに強く固定する必要があると考えた。例えば入力データに Godot 4 専用タグを付与したり、Godot 3/他言語コードが混在したデータをより強くフィルタリングしたり、回答生成前段階で「この作業は Godot 4 GDScript 基準です」という制約を繰り返し注入する方式が必要になるかもしれない。
今日のまとめ
今日考えた核心は、RAG やクローリング自体が解決策ではないという点だ。ドキュメントを大量に集めることよりも重要なのは、モデルが実際のリクエストでどの文脈を読み取り、どのように判断すべきかを設計することだ。
現在までの構造は次の段階へさらに細分化すべきだと思う。
- プロジェクト全体を一度に入れる方式ではなく、ファイル／役割／依存性ベースで検索可能な構造を作る。
- instruction データは最終コードだけでなく、探索と判断プロセスまで含める必要があるか検討する。
- Godot 4 の文脈が推論途中で希薄にならないよう、プロンプト、タグ、フィルタリング、好みデータ基準をより強く設計する。
結局「Godot 4 コーディングモデル」を作るには Godot 4 のコードだけを集めるだけでは不十分だ。モデルがどの順序でプロジェクトを読み、どの基準で Godot 4 と判断し、どの回答を良い回答として選択すべきかまでデータに反映させる必要がある。
振り返り
今日は実際にコードを書いた日ではないが、以前の設計の抜け穴を再び見つめ直した日だった。バスの中でぼんやり考えているうちに、むしろデスク前で見落としていた問題が浮かんできた。RAG チャットボットを作るというのは簡単に聞こえるが、実際には検索単位、コンテキストサイズ、質問／回答データ構造、言語重みの制御がすべてつながっていた。
まだ答えは出ていない。しかし疑問が生まれたことは良いシグナルだと思う。今の段階で疑問を記録しておけば、後でパイプラインを実装する際に何を検証すべきかの基準になる。
次はこの疑問を基に、プロジェクトコンテキストをどの単位で分割するか、instruction データに推論プロセスをどこまで含めるか、Godot 4 の文脈を強く保つ前処理規則をどう作るかを具体化していきたい。