2026年版GDScript向け最良LLM（ホスト型・ローカル型ランキング）

「GDScriptに最適なLLM」で検索すると、たいてい役に立たない2種類の答えが返ってきます。「ChatGPTを使えばいい」という汎用的な答えか、Godotに一切触れていないベンチマークチャートです。どちらも本当に知りたいこと、つまりどのモデルがGodot 4のGDScriptを動く形で書けるか、そしてコードを外部に出さずにローカルで動かせるモデルはどれかを教えてくれません。

この記事では両方に答えます。まずホスト型モデルについて手短に触れ、次にOllamaで実行できる最良のローカルモデルを正直なハードウェア要件とともに紹介し、最後にモデル選択以上に結果を変える要因を説明します。Summer Engineもこのリストに含まれており、どこで役立ち、どこでは素のモデルの方が良い選択かについても正直に述べます。

この記事はGDScript向け最良AIツールのラウンドアップの、モデル選定に特化したコンパニオン記事です。あちらはツール（チャット、MCP、プラグイン、エンジン）をランキングしています。こちらはホスト型とローカル型のモデルをランキングし、自分で実行する方法を深掘りします。

{/* IMAGE: Split graphic, left a terminal running ollama run qwen2.5-coder outputting GDScript, right the same code corrected inside a Godot editor with a runtime error panel. 1200x630, illustration. */}

GDScriptですべてのLLMが陥る落とし穴

ランキングの前に、この比較全体を形作る唯一の失敗パターンを理解してください。LLMから良いGDScriptを引き出す最難関は、モデルを賢くすることではありません。Godot 3を書かせないことです。

Godot 4は言語とノードAPIの大部分を刷新しましたが、インターネット上にはまだGodot 3のチュートリアルやリポジトリが溢れています。モデルはそのデータで学習し、自信を持って古い構文を出力します。よくある例を挙げます。

• awaitの代わりにyield(...)
• CharacterBody3DとCharacterBody2Dの代わりにKinematicBodyとKinematicBody2D
• @export var speedの代わりにexport var speed
• create_tween()の代わりに古いTweenノード
• Godot 4のcallable形式の代わりにconnect("pressed", self, "_on_pressed")
• Timeに移動したOS.get_ticks_msec()の呼び出し

非推奨の呼び出しが1つあるだけで、スクリプト全体が動かなくなることがあります。モデルが強いほどこのズレは少なくなりますが、ゼロのモデルはありません。そしてローカルモデルは規模が小さく、同じ古いコードで学習しているため、最もズレが多くなります。これが、以下のランキングを見る際に常に2つの軸を頭の中に持っておく必要がある理由です。モデルがどれだけクリーンか、そしてそれを動かす環境がどれだけうまくズレを検出するか。

パート1: GDScript向け最良のホスト型LLM

これらはAPIまたはチャットウィンドウ経由で利用するフロンティアモデルです。比較全体の品質上限を設定しており、順位付けは簡潔です。

• Claude Opusは2026年中盤においてGodot 4のGDScriptで最も信頼できるLLMです。クリーンでイディオマティックなコードを生成し、awaitとGodot 4のシグナル構文を正しく使い、ここで紹介するどのモデルよりもGodot 3のパターンへの後退が少なく、ビジョン対応なので適切なツールと組み合わせればゲームのスクリーンショットを読めます。複雑なスクリプトに最適で、修正回数が最も少なくなります。トレードオフはトークンごとのコストです。
• GPTは僅差で続き、初回レスポンスが速いことも多いです。GDScript品質は日常的なタスク（移動、UI、タイマー、シンプルなステートマシン）ではOpusと同等で、小さなコンテキストミスが複数ファイルをまたいで蓄積する長いエージェントチェーンでは一歩遅れます。こちらもビジョン対応です。自己完結したスクリプトには安定したデフォルト選択です。
• DeepSeekは最良のコストパフォーマンスのホスト型オプションで、複数のツールがこれを無料または標準ティアとして採用している理由でもあります。はるかに低コストで使えるGDScriptを書きますが、マルチファイルの作業では修正回数が増え、標準のホスト型バリアントはテキストのみのため、ビジュアルバグのデバッグにゲームを見ることができません。

ホスト型の順位はOpus、GPT、DeepSeekの順です。現実ではありますが、見た目ほど決定的ではありません。これらはいずれ必ずGodot 3の呼び出しを出力してきます。ホスト型モデルの詳細はGDScript向け最良AIのラウンドアップで深掘りしています。この記事で検索する多くの人にとって最も興味深い部分は次のパートです。オフラインで動くものは何か。

パート2: Godot向け最良のローカルLLM（Ollama）

ほとんどのラウンドアップが飛ばす部分です。コードを自分のマシンに留めたい、トークンごとの課金をなくしたい、またはインターネットなしで作業したい場合は、ローカルでモデルを実行します。Ollamaが最も簡単な方法です。インストールしてollama pullでモデルをダウンロードすれば、任意のAIツールが指定できるローカルエンドポイントが手に入ります。GDScriptに使える価値のあるモデルを、良い順に紹介します。

Qwen2.5-Coder 32B

2026年におけるGDScript向け最良のローカルLLMです。32Bサイズでは、一般的なタスクにおいてコストパフォーマンスのホスト型モデルに本当に近いGDScriptを書き、Godot 4の構文をそれなりに扱い、他のローカル選択肢よりも複数ステップの指示に従う能力が高くなります。ollama pull qwen2.5-coder:32bでpullできます。14Bと7Bのバリアントはより小さなカードで動き、シンプルなスクリプトなら合格点のGDScriptを書けますが、サイズを縮めるほどミスが増えます。

ハードウェア: 32Bの4ビットクォンタイズはおよそ20GB以上のVRAMを必要とします。24GBのGPUが現実的な最低ラインで、48GBカードやUnified Memoryが豊富なApple Siliconマシンならより快適です。

最適な用途: 1台のハイエンドマシンで完全オフラインで得られる最強のGDScript。

DeepSeek-Coder-V2

強力な2番手です。日常的なタスクに対して安定したGDScriptを書き、Mixture-of-Expertsの設計が能力に対して推論を効率的に保ちます。私たちの経験では、Qwen2.5-CoderよりもわずかにしばしばGodot 3の構文に戻り、長いスクリプトではより多くの修正が必要になりますが、ollama pull deepseek-coder-v2で試す価値のある本物の代替です。

最適な用途: Qwen2.5-Coderがハードウェアや好みに合わない場合の、効率的なローカルコーダー。

Codestral

軽量で高速なコードモデルです。32Bオプションよりレスポンスが速く、シンプルで自己完結したタスクには合格点のGDScriptを書きます。複雑なマルチファイル作業とバージョンドリフトでは3つの中で最も弱いため、速さと小さなフットプリントが品質の上限より重要な場合の選択肢として位置付けてください。

最適な用途: 中程度のハードウェアでの高速なローカルオートコンプリート的なサポートとシンプルなスクリプト。

ローカルモデルについての正直な真実

ローカルLLMを過大評価するコンテンツが多いため、ここは目を開けて見てください。1台のコンシューマー向けGPUで動く最良のローカルモデルは、Claude OpusやGPTよりも明らかに弱いGDScriptを書きます。Godot 3の構文への後退が多く、マルチファイルの作業では修正回数が増え、通常テキストのみのため、スクリーンショットを見てビジュアルバグを直すことができません。あなたは3つの本物のメリットのためにコード品質をトレードしています。コードが外部に出ない、トークンごとの課金がない、インターネットなしで動く。

そのトレードが価値ある人とそうでない人がいます。プライバシー、ランニングコストゼロ、またはオフライン使用が絶対条件なら、Qwen2.5-Coder 32Bを実行して、より多くの修正を受け入れてください。最良のGDScriptが欲しくてコードが外部に出ることが問題ないなら、ホスト型モデルの方が良いツールです。「無料に感じるから」という理由でローカルモデルを動かさないでください。コストはトークンごとの課金からGPUとより弱い出力を修正する自分の時間に移っただけです。

モデルの比較

モデル	種別	GDScript品質	Godot 3ドリフト	ビジョン	コストモデル
Claude Opus	ホスト型	最高	最低	あり	トークンごと、プレミアム
GPT	ホスト型	高	低	あり	トークンごと
DeepSeek	ホスト型	良好	中	なし（標準）	トークンごと、低コスト
Qwen2.5-Coder 32B	ローカル	ローカルとして良好	中	なし	GPUのみ、トークン課金なし
DeepSeek-Coder-V2	ローカル	まずまず	中〜高	なし	GPUのみ、トークン課金なし
Codestral	ローカル	シンプルなタスク	高め	なし	GPUのみ、トークン課金なし

ホスト型ブロックとローカルブロックの間のギャップを正直に読んでください。ローカルモデルは使えるレベルに達しており、急速に改善されていますが、1台のコンシューマー向けGPUではGDScriptにおいてフロンティアのホスト型モデルより一段下です。次のセクションでは、そのギャップが見た目ほど重要ではない理由を説明します。

パート3: モデル選択を超える要因

ここがランキング全体を捉え直す部分です。LLMはテキストを書きます。そのテキストがあなたのプロジェクトで動くGDScriptになるかどうかは、モデルがシーンツリーを見てゲームを実行できるかどうかにかかっており、それはモデル自体の性質ではなく、モデルを取り巻くツールの性質です。

素のチャットウィンドウは何も見えません。ノード名を推測し、get_node("Player")が存在しないノードを指していることを教えられず、手動でゲームを動かすまでyieldをまた書いたことを知りません。これはモデルがOpusであっても7Bのローカルモデルであっても同じです。最も強力なLLMでも、何も見えない状態で使えば、自分で統合してデバッグしなければならないGDScriptを渡してきます。

そのギャップを縮めるセットアップは、AIがどれだけ検証できるかという順で、素のチャット（何も見えない）からMCPサーバー（ファイルを読む、ゲームは動かさない）、エディタープラグイン（エディターとデバッガーのエラーを読む）、AIネイティブエンジン（ゲームを動かしてライブのランタイムエラーを読む）へと続きます。Godot向け最良AIのラウンドアップでそれらを全て比較しています。

Summer Engineは最後のカテゴリーです。モデルをエンジンに統合し、Godot 4互換なので.godotプロジェクトを開いて、あなたが所有する本物のシーンとGDScriptを生成し、AIが完全なエンジン状態を見られるようにします。シーン、ノード、物理ボディ、シグナル、そして実行中のゲーム。「プレイヤーにダブルジャンプとウォールスライドを付けて」と言えば、適切なCharacterBody2DにGDScriptを書き、入力を接続し、ゲームを動かし、診断とデバッガーエラーをライブで読み、本物の出力から自分のミスを修正します。yieldやKinematicBodyを出力したら、エンジンが例外を投げ、AIは正確なエラーを見て、その行を書き直します。

その書く、動かす、読むのループがまさにバージョンドリフトが消えるところであり、弱いモデルが順位以上のパフォーマンスを発揮できる理由でもあります。ゲームを動かしてエラーを読める中級モデルは、GDScriptがランタイムで失敗し、チャットウィンドウではその瞬間が見えないからこそ、チャットウィンドウを通じて盲目的に書くトップモデルよりも動くGDScriptを多く生み出すことがあります。

正直な限界: AIネイティブエンジンは、プラグインのインストールやOllamaをエディターに向けるよりも大きな変化です。現在のセットアップへの追加ではなく、フルエンジンだからです。まったく同じ素のGodotインストールに留まることが優先事項なら、プラグインやMCPサーバーの方が小さな変化です。Summer Engineは、AIにGDScriptを最初から最後まで書いて検証してほしい場合に適切な選択です。自分のジャンルのテンプレートから始めてプロンプトを重ねてください。

正直な無料と有料の話

何も制限なく無料だと示唆するラウンドアップは正直ではありません。実際のラインを示します。

• 素のチャットのホスト型モデル: ChatGPTとClaudeの無料ティアは存在しており、GDScriptを学んでスニペットを得るには十分です。有料プランは制限を引き上げ、Opusのような強力なモデルを解放します。
• Ollama経由のローカルモデル: ソフトウェアは無料でオープンソースであり、トークンごとのコストはありません。ハードウェア（有能なGPU）と、より弱い出力を修正する追加時間で支払います。継続的なAPI料金は無料ですが、コストがないわけではありません。
• Summer Engine: GDScriptを書くAI会話、シーンの構築、アセットの生成、ゲームのエクスポートを含め、無料でダウンロードして使用できます。有料プランはAI使用量の上限を引き上げ、より強力なモデルを解放します。無料ティアは最初のゲームのGDScriptを書いてリリースするのに十分な広さがあります。現在の数字は料金ページと無料AIゲームメーカーの詳細でご確認ください。

ここにあるすべてに共通するパターン: LLMは最初は無料かもしれませんが、AIのコンピュートはどこかでお金かハードウェアを必要とします。あなたが選んでいるのは、そのコストをどこに置くかです。

一度で選ぶ方法

自分の状況をこれに当てはめて止めてください。

• 最良のGDScriptが欲しく、コードが外部に出ても構わない場合: 好みのツールでClaude OpusかGPTを使ってください。
• コードをローカルに留める必要があるか、オフラインでトークンごとのコストゼロが必要で、24GB以上のGPUがある場合: Qwen2.5-Coder 32BをOllama経由で実行し、より多くの修正を受け入れてください。
• ローカルが欲しいが小さいカードしかない場合: シンプルなスクリプトにはqwen2.5-coder:14bか:7bを実行し、期待値を抑えてください。
• モデルにGDScriptを書かせて動くことを証明してほしく、修正回数を最小にし、手動の統合を避けたい場合: Summer EngineのようなAIネイティブエンジンを使い、テンプレートから始めてください。

避けるべきミスは、モデルのリーダーボードに執着しながら、モデルが自分のコードを実行できる手段を与えないことです。GDScriptに特定して言えば、検証ループがモデルと同じくらい結果に影響します。最悪のバグがランタイムのみだからです。上限のためにモデルを選び、実際にそこに届けるためにゲームを動かして本物のエラーを読めるセットアップを選んでください。

より広い視点のために、AIでゲームを作る方法のガイドで全体的なワークフローをカバーし、Godot AIエージェントガイドでインエディターエージェントができることを深掘りし、CursorとGodot対Summer Engineでモデルを自分で持ち込むセットアップとAIネイティブエンジンを直接比較しています。