2026-06-12 振り返り

再び振り返りを書くことにした

久しぶりに振り返りを残す。これまで記録をしなかった理由は、忙しいからというより、完璧な文章だけを残したいという思いが大きかったからだと思う。結果が確実に整理された後でしか記録したくなく、失敗したり途中で方針が変わった過程はむやみに残すのは微妙だと感じていた。

しかし振り返ってみると、むしろその過程が最も意味があった。過去10日間で完成した成果物は多くなかったが、Godot 特化のコーディングモデルを作るために何を調査し、どこで詰まり、どんな判断を変えたかはかなり蓄積された。そこで今日はその流れを一度整理しようと思う。

ローカルモデル実験

最初は RunPod の使用料がもったいないので、ローカル PC に Qwen 系列モデルを載せようとした。RTX 3060 を使用中なので、9B 程度のモデルなら何とか WSL で動かせるのではないかと考えた。

しかし実際には期待通りにはいかなかった。ネットワーク接続速度と応答遅延の問題が深刻で、回答ひとつを受け取る前に思考段階だけで 5 分以上かかってしまった。この状態では実験速度も遅すぎるし、開発ツールに組み込んで使うのも難しいと判断し、ローカルモデルの起動はすぐに中止した。

この実験で得られたことは明確だった。自分の環境で無理に大きなモデルをローカルで走らせるより、今はデータセット構造と学習パイプラインを先に設計する方が重要だということ。

Godot データセット調査

モデルを学習させるにはまずデータが必要だった。そこで Godot 4 のコード学習に使えるデータセットを探したところ、Hugging Face の wallstoneai/godot-gdscript-dataset を見つけた。

• https://huggingface.co/datasets/wallstoneai/godot-gdscript-dataset

最初は単に .gd ファイルを多数集めたデータセットだと思っていたが、Gemini で分析してみると構造がより重要だった。ポイントは GitHub リポジトリからファイルを一つずつ抜き出すのではなく、リポジトリ全体を展開してプロジェクトの文脈を保持する方式だった。

このデータセットはリポジトリの README.md、.gd ファイル、ディレクトリ構造を一つのテキストに統合し、その中にプロジェクト名、Godot バージョン、ファイルツリー、ファイルごとの内容を Markdown 形式で整理する方式のように見える。こうすればモデルは単一のコード片だけでなく、プロジェクト構造とファイル間の関係も把握できる。

特に重要だったのは Godot 3/4 のバージョン判別方法だった。Godot は一般的なウェブプロジェクトのように package.json や requirements.txt がある構造ではない。代わりに project.godot ファイル内の config_version、config/features といった値を読むか、GDScript の文法差異を利用する必要がある。

例えば Godot 3 では onready var、KinematicBody といった表記が使われ、Godot 4 では @onready、CharacterBody3D といった表記が使われる。このような文法差を正規表現やパーサで捕まえれば、JSON ベースのバージョンファイルがなくてもある程度バージョンフィルタリングが可能だというインサイトを得た。

データセットだけでは不十分だった

その後 YouTube で OPL という古典的プログラミング言語を対象にファインチューニングする動画を見た。

• https://www.youtube.com/watch?v=5wGD92ktQL4

しかし動画を見ても感覚が完全に掴めなかった。データセットを収集する工程とファインチューニングする工程がつながっていなければ、「データセットだけあれば何をどう学習させるのか？」という疑問が残った。

そこで SSAFY のコーチに、特定バージョンのマイナー言語データを収集したいが最も効果的な方法は何かと質問した。ここで重要な回答を得た。

第一に、現在参照しているデータセットは assistant 学習用データセットというより raw コードデータセットに近いという点だった。私が作りたい成果物がチャットボット形式なら、raw コードをそのまま入れるだけでは不十分だ。

第二に、raw データセットを基に LLM に質問/回答ペアを作らせる必要があるという点だった。この回答を聞いて初めて、私がすべきことが少し明確になった。Godot 4 のコードだけを集めることで終わるのではなく、質問データと正解データを生成して instruction データセットとして作る必要がある。

この工程を踏まなければ「マップを設計してくれ」などのリクエストに対し、モデルが Godot ではなく Python で答える可能性が高い。既存モデルは Python データをはるかに多く学習しているはずだからだ。正解データが曖昧だと旧バージョンの Godot コードや全く別の言語が混入するリスクも大きいと判断した。

instruction データセットとプロンプト設計の検討

instruction データセット候補として Magicoder-Evol-Instruct-110K も調べた。

• https://huggingface.co/datasets/ise-uiuc/Magicoder-Evol-Instruct-110K

しかしほとんどが Python 中心で書かれていた。そのまま使うと Godot 4 専用モデルを作るには適さないように思えた。

このとき「Godot を敢えて明示すべきか？」という疑問が生まれた。Godot データを多く入れれば、ユーザーが敢えて Godot と言わなくても Godot コードで答えるようにできないかと考えた。

この点は大学の先輩に相談しながら方向性が少し整理された。最近は無条件に RAG よりもプロンプトや文書ベースの検索構造を上手く設計する方が良い場合もあり、ベクトルベースで Markdown 文書を作成し、モデルが必要なデータを探せるようにマップを作る手法が現実的だという助言を受けた。

結局現在の段階では「マップを作ってくれ」より「Godot でマップを作ってくれ」のように明確な文脈を与える方が、正確な回答を得られる可能性が高いと整理した。既存モデルの Python 重みが大きいため、Godot という条件をプロンプトの前段で強く提示する必要があると考えた。

アーキテクチャ再設計

最初はアーキテクチャをシンプルに考えた。

データセット収集 -> 質問/回答データセット作成 -> モデル学習

しかしすぐにこの構造が危険すぎると感じた。Godot 3から4へ何が変わったのかを十分に知らない状態でデータを収集すると、誤ったコードが正解データとして入ってしまう可能性がある。質問/正解データセットを作成したとしても、PythonコードやGodot 3コードが混在することがある。

そこで公式ドキュメントをまず基準点とする構造を思いついた。Godot 3から4へのマイグレーション文書とGodot 4公式ドキュメントをクロールしてRAGチャットボットを作り、このチャットボットをフロントに配置して、収集したコードがGodot 3か4か、旧バージョンAPIを使用しているか、Godot 4コードに適合しているかを判別させる方式である。

添付したダイアグラムはこのとき整理したパイプライン草案である。

大まかな流れは次のとおりだ。

• Godot公式ドキュメントとマイグレーション文書をクロールしてRAGナレッジベースを作る。
• GitHubのGodotプロジェクトをリポジトリ単位で収集する。
• README、ファイル構造、GDScriptコードをひとつのコンテキストに統合する。
• project.godot 設定ファイルとGDScript文法の違いで一次フィルタリングを行う。
• RAGチャットボットでGodot 3/4 の有無と旧バージョンAPI使用の有無を追加判別する。
• Godot 4 に精製されたデータだけを instruction/response データセットとして作成する。
• SFT と DPO/Preference データで Godot 4 コーディングモデルを学習する。

SFT と DPO の方向

その後 ChatGPT にさらに質問しながら、予想外の方向性も得られた。単に「Godot 4 コードを生成するモデル」だけを考えていたが、学習タスクをより具体的に分割できた。

SFT では次のようなタスクを作れる。

• Godot 3/4 コード分類
• Godot 3 コードを Godot 4 コードに変換
• Godot 4 コード生成
• Godot 4 エラー修正
• Godot 3 API の拒否または訂正

DPO/Preference では、悪い回答と良い回答を明確に作り分けられる。例えば Godot 3 文法が混在した回答を悪い回答とし、Godot 4 純粋コードで書かれた回答を良い回答とする方式である。

この視点が生まれたことで「データをたくさん集めよう」ではなく「何を良い回答とみなすか」を先に決める必要があると考えるようになった。

Godot 公式ドキュメントのクロール

この方向を実際に試すためにクロールツールを探し、crawl4ai を使用した。

• https://github.com/unclecode/crawl4ai
• https://docs.godotengine.org/en/stable/tutorials/migrating/upgrading_to_godot_4.html

Godot 4 公式ドキュメント、Godot 3 → 4 マイグレーション文書、Godot 4 クラスリファレンス、Godot 4 チュートリアル文書を含め、約1,500ページ近くをクロールして文書化した。

最初はあまりにも多くクロールしすぎたのではと感じたが、全体モデルコンテキストサイズと比較すれば約3% 程度の規模だと判断した。すべてをモデルに投入するのではなく、RAG や文書検索構造で利用すれば十分に扱える量だと考えた。

データパイプラインと I/O の検討

アーキテクチャを再設計すると、ディスク I/O と学習タイミングも問題になる。データ収集、前処理、後処理、保存、再インデックス、学習がすべて連続するとボトルネックが生じるからだ。

この点については先輩に相談した。得られた回答は、リアルタイムでファインチューニングを回すより、データ確保と加工を迅速に行い、学習はバッチで実行した方が良いというものだった。

例えばデータセットが一定量以上たまったときだけ強化学習やファインチューニングを実行する方式だ。レプリケーションスロットのように基準を超えたときに処理すれば I/O ボトルネックを減らせ、リアルタイム性が重要な部分は学習ではなくデータ確保と加工であるという観点だった。

再インデックスのコストは構造的に完全に排除できない。したがってこのコストをなくすより、いつ再インデックスし、いつ学習するかの基準を設ける方が現実的だと整理した。

今日のまとめ

過去10日間の流れをまとめると、最初は漠然と「Godot コーディングモデルを作りたい」から始まった。しかし今はもう少し具体的な構造ができた。

raw コードデータセットだけでは不十分だ。Godot 4 を基準に精製されたコードデータ、公式ドキュメントベースの判別構造、instruction/response データ、SFT タスク、DPO/Preference 基準がすべて必要になる。

また、現時点の自分の技術レベルでは Qwen のような大規模モデルなしに最初からコーディングモデルを作るのは現実的に難しい。ローカルモデルと ChatGPT のコーディング実力を比較しながら、モデルサイズと事前学習量の差を無視できないことも実感した。

それでも方向性は以前よりはるかに明確になった。Godot 4 公式ドキュメントを基準にナレッジベースを作り、収集データをフィルタリングし、良い回答と悪い回答の基準を設定して学習データにする流れを試すことができる。

回顧

今回の回顧を書きながら最も大きく感じたのは、記録のハードルを下げるべきだという点だ。完璧な成果物だけを記録しようとすると、実際に重要なプロセスが失われる。失敗した実験、曖昧だった判断、途中で変わったアーキテクチャは次の決定を作る材料なのに、それを残さなければ後で「なぜこの選択をしたのか」分からなくなる。

今後は完成した結果だけを上げようとするより、プロセス自体をもっと頻繁に残すようにしたい。失敗したという思いが先行して回顧を先延ばしにするのではなく、失敗と悩みを含めて記録することがより良い方向だと考える。

今日を機に再び継続的に回顧を残したい。完璧な文章でなくても構わないし、途中経過でも構わない。重要なのは自分が何を試み、何を学び、次にどの基準で動くかを残すことだ。