Godot 4.6でMaskノード系プラグインをビルドできない原因は？MSVCとSConsエラーの正体と解決策を徹底解説
Godot 4.6環境で、BlendTree向けのMaskノード風プラグインを作ろうとしているのに、SConsビルドでMSVCが大量の警告と構文エラーを吐いて止まる。この手のトラブルは、ソースコードそのものではなく「コンパイラの呼び出し方」「Visual Studio環境の読み込み不足」「MSVCではなく別系統のclが参照されている」など、開発環境側の不整合が原因になっているケースが非常に多いです。
本記事では、Godot C++拡張開発で起きやすいMSVC/SConsビルド失敗の症状を整理しながら、なぜ /std:c++17 が無視され、defs.hpp で意味不明な構文エラーが連鎖するのか、その背景と直し方を実践的に解説します。Maskノード的な機能を作りたい人にとっても、ここを突破できるかどうかが最初の大きな壁になります。
- Godot 4.6でMaskノード系プラグインをビルドできない原因は？MSVCとSConsエラーの正体と解決策を徹底解説
- 発生している問題の整理
- まず結論：怪しいのはプラグインのロジックではなくビルド環境
- /std:c++17 が無視される時点で普通のMSVC挙動ではない
- defs.hpp の構文エラーは“被害”であることが多い
- もっとも可能性が高い原因
- 原因1：Visual Studio Developer Command Promptを使っていない
- 原因2：PATH上で別の cl.exe を拾っている
- 原因3：SConsとgodot-cppの組み合わせ、または取得手順にズレがある
- 原因4：MSVCのC++ワークロード不足
- すぐ試したい実践的な解決手順
- 1. 開発者向けコマンドプロンプトを使う
- 2. ビルド成果物を削除してやり直す
- 3. godot-cpp のバージョン整合性を見直す
- 4. PythonとSConsの実行元を整理する
- 5. 最小サンプルで先に通す
- Maskノード風プラグインの設計自体は十分あり得る
- なぜ環境問題だと断言しやすいのか
- ハマりやすい落とし穴
- 解決までの最短ルート
- まとめ：今回の本当の敵はMaskノード実装ではなくMSVC環境の不整合
発生している問題の整理
今回の症状は、Godot 4.6でWindows向けにGDExtension系のビルドを進めようとした際、SCons実行中に以下のような流れで止まるものです。
-
scons platform=windows generate_bindings=yes target=template_debug -j8を実行 -
SCons自体は読み込みに成功
-
godot-cpp系の生成やmemory.cppのコンパイル段階で失敗 -
MSVCが
/std:c++17や/utf-8などを「unknown option」として無視 -
include/godot_cpp/core/defs.hpp内でmissing ';' before 'const'などの構文エラーが連発 -
最終的に
Error 2でビルド中断
一見すると「Godotのヘッダにバグがあるのでは」と思いがちですが、実際にはその可能性は低く、環境側の問題で正しいC++として解釈されていない状態に陥っていると考えるのが自然です。
まず結論：怪しいのはプラグインのロジックではなくビルド環境
今回作ろうとしているのは、Blend2ノードに近い挙動を持ちながら、2入力のブレンド量ではなくブール値で切り替えるようなMaskノード風の仕組みです。発想としては十分現実的で、Godot拡張として成立しうる内容です。
しかし、今回のエラーはその実装内容に到達する前の段階で起きています。つまり、ノード設計の正しさ以前に、C++ビルド環境がまともに機能していないのが本質です。
ここを誤解すると、ノード処理やクラス定義を何度書き直しても永遠に解決しません。まず見るべきは次の3点です。
-
本当に正しいMSVCが呼ばれているか
-
Visual Studioの開発者環境を通してビルドしているか
-
godot-cppと使用しているビルドツール群の組み合わせが整合しているか
/std:c++17 が無視される時点で普通のMSVC挙動ではない
今回もっとも重要なのはここです。
cl : Command line warning D9002 : ignoring unknown option '/std:c++17'
本来、現代のMSVCで /std:c++17 は普通に通るオプションです。しかも、表示されているコンパイラバージョンは 19.44.35225 と比較的新しいため、C++17を理解できないはずがありません。
それにもかかわらず unknown option 扱いになる場合、よくあるのは次のパターンです。
実は本物のMSVC cl.exeではない
Windows環境では、cl.exe という名前の実行ファイルが複数の文脈で存在しうるため、意図したVisual C++コンパイラではないものを拾ってしまうことがあります。
PATHの順序が崩れていると、SConsが想定外の cl を呼び出し、結果としてC++標準オプションが通らないという不可解な状況になります。
開発者コマンドプロンプトを通していない
Visual Studioをインストールしていても、通常のPowerShellやコマンドプロンプトからそのまま scons を叩くと、必要な環境変数やツールチェイン設定が不足することがあります。
その結果、MSVC自体は見つかっても、正しく初期化されていない状態で動いてしまい、不完全な解釈や異常な警告を出すケースがあります。
互換モードや古いツールセットが混在している
Visual Studio本体は新しくても、Build ToolsやWindows SDK、環境変数の向き先が古いものを指していると、見かけのバージョン情報と実際のコンパイル挙動が一致しないことがあります。
defs.hpp の構文エラーは“被害”であることが多い
次に注目したいのが、include/godot_cpp/core/defs.hpp でのエラー連鎖です。
-
missing ';' before 'const' -
missing type specifier -
auto should be preceded by ';' -
expected a trailing return type
この種のエラーは、Godotのヘッダ自体に問題があるというより、前提となるC++標準やマクロ定義が正しく読み込まれていないときに一気に発生しやすい典型例です。
つまり、defs.hpp が悪いのではなく、その前段階でコンパイラが近代的C++としてファイルを読めていない可能性が高いのです。
たとえばC++17前提の構文や constexpr、テンプレート周辺、マクロ展開の結果を古い解釈で読むと、後続の行が全部崩れて見えます。そのため、エラー行番号だけ追っても解決しないことが多いです。
もっとも可能性が高い原因
ここからは、今回のログから推測しやすい主要原因を絞っていきます。
原因1：Visual Studio Developer Command Promptを使っていない
GodotのC++拡張や godot-cpp のビルドでは、Windows環境だとVisual Studioの開発者向けコマンドプロンプトから実行するのが基本です。
通常のターミナルではなく、以下のような環境からビルドする必要があります。
-
x64 Native Tools Command Prompt for VS
-
Developer Command Prompt for Visual Studio
この環境で cl や where cl を確認し、Visual Studio配下の正しい cl.exe が参照されているかを見るのが第一歩です。
普段使いのPowerShellから実行している場合、たとえ cl が見えても、それが完全なMSVC開発環境とは限りません。
原因2：PATH上で別の cl.exe を拾っている
これはかなり危険です。cl という名前は短すぎるため、別ツールや古い開発環境の残骸がPATH上に残っていると誤爆しやすいです。
確認ポイントは単純で、コマンドラインから where cl を実行して複数候補が出ないかを見ることです。理想は、Visual StudioのMSVCパスが最優先で出る状態です。
もし変な場所の cl.exe が先に出てきているなら、それが今回の D9002 祭りの真犯人である可能性は非常に高いです。
原因3：SConsとgodot-cppの組み合わせ、または取得手順にズレがある
Godot 4系のGDExtension開発では、godot-cpp を正しい手順で取得し、サブモジュールや対応ブランチを合わせることが重要です。
もしGodot 4.6本体を使っているのに、古いバージョン向けの godot-cpp や互換性の薄いビルド設定を混ぜていると、ヘッダ生成やバインディング生成に問題が出やすくなります。
とくにありがちなのが以下です。
-
Godot本体のバージョンと
godot-cppの世代がずれている -
generate_bindings=yesを使っているが、生成元やフォルダ構成が中途半端 -
一度失敗した生成物が残り、それを再利用している
-
古いビルド成果物が混ざっている
この場合は、生成物を一度削除してクリーンビルドするのが有効です。
原因4：MSVCのC++ワークロード不足
Visual Studioを入れていても、C++デスクトップ開発関連のコンポーネントが不十分だと、コンパイラ本体だけ見えていても実用上のビルド環境が完成していないことがあります。
必要になりやすいのは次のあたりです。
-
Desktop development with C++
-
最新のMSVC v143 build tools
-
Windows 10/11 SDK
-
C++ CMake tools for Windows（環境によって有用）
Godotの拡張ビルドでは、表面上「コンパイラがある」だけでは足りません。標準ライブラリやSDK群が揃ってはじめて安定します。
すぐ試したい実践的な解決手順
ここからは、再現率の高い順に対処法をまとめます。
1. 開発者向けコマンドプロンプトを使う
まず、Visual Studio付属の開発者向けコマンドプロンプトを起動し、その中で以下を順に確認します。
-
cl -
where cl -
scons --version
ここで cl を実行したとき、Visual C++の正規のバナーが出るかを確認します。
さらに where cl でVisual StudioのMSVCパス以外が先頭に来ていないかを見ます。
これだけで解決するケースは珍しくありません。
2. ビルド成果物を削除してやり直す
中途半端な生成物が残っていると、原因の切り分けを難しくします。bin、gen、.sconsign 的なビルドキャッシュや生成済みオブジェクトを消し、クリーンな状態から再ビルドしてください。
Godot拡張系では、一度おかしく生成されたファイルがその後もエラーを引きずることがあります。
初回失敗後に設定だけ変えて再実行しても、古い生成物を読んでいる限り改善しないことがあります。
3. godot-cpp のバージョン整合性を見直す
Godot 4.6を使っているなら、それに見合った godot-cpp の状態になっているか確認が必要です。
とくに、過去のチュートリアルやサンプルを見ながら手元に構成を作った場合、実は4.1～4.3前提のやり方が混ざっていることがあります。
表面的には同じように見えても、ヘッダや生成コード、ビルドスクリプトの前提が微妙に変わっているとエラーが出ます。
4. PythonとSConsの実行元を整理する
SConsはPython上で動くため、Python環境が複数あると予期せぬSConsを叩いている可能性もあります。
仮想環境、システムPython、別ユーザー環境などが混ざると、ビルドスクリプトの挙動や参照先が不安定になります。
理想は、どのPythonでSConsが起動しているのかを明確にしたうえで、必要な依存を1つの環境に寄せることです。
5. 最小サンプルで先に通す
いきなりMaskノード風の独自ロジックを入れず、最小構成のGDExtensionサンプルをビルドしてみるのが重要です。
最小サンプルが通らないなら、独自ノードの設計以前に環境が壊れています。
逆に最小サンプルが通るなら、実装レイヤーの問題に切り分けできます。
この順番を守るだけで、問題の所在が圧倒的に見えやすくなります。
Maskノード風プラグインの設計自体は十分あり得る
今回作ろうとしているものは、Blend2ノードの「2つを混ぜる」思想ではなく、ブール値でオン・オフを切り替える1入力1出力寄りのマスク的ノードです。
さらに、Blend2ノードが持つボーンフィルタの考え方を応用し、falseなら入力をそのまま、trueなら新しい情報を反映するような設計を目指しているようです。
これは実用性があります。
アニメーション制御では、「連続的に混ぜたい」のではなく「条件成立時だけ部分的に差し替えたい」という場面が多く、特に上半身だけ別モーションを当てたいケースでは、ブール駆動のほうが設計が明快になることがあります。
そのため、アイデア自体を疑う必要はありません。今つまずいているのはプラグインの価値ではなく、ビルド基盤です。
なぜ環境問題だと断言しやすいのか
今回のログが環境問題を強く示している理由は明快です。
警告の種類が“コードのバグ”ではない
/std:c++17 や /utf-8 を知らないと言われるのは、通常のGodot拡張コードのミスとは無関係です。
エラー発生箇所がライブラリ内部
自作ノードのクラス実装ではなく、godot_cpp/core/defs.hpp で死んでいます。
これは自作ロジック以前に前提が崩れているサインです。
近代C++構文を理解していないような崩れ方
auto や戻り値型まわりで連鎖崩壊しているため、C++標準設定や前処理が疑わしいです。
つまり、Node設計の是非を検討するフェーズにまだ入れていないのです。
ハマりやすい落とし穴
Godot拡張開発初心者だけでなく、C++経験者でもハマるポイントを挙げておきます。
Visual Studioを入れた＝使える状態ではない
実際にはワークロード不足やSDK不足で未完成ということが多いです。
PowerShellで動いたから正しいとは限らない
見かけ上 cl が反応しても、正しく初期化されていない場合があります。
エラー箇所のヘッダを直そうとしてしまう
これは遠回りになりやすいです。
まずコンパイラが正しくC++17を解釈しているかを確認するほうが先です。
独自コードを削っても直らない
今回のようなケースでは当然です。根が環境にあるからです。
解決までの最短ルート
最短で前進したいなら、次の順番が効率的です。
まず、Visual Studioの開発者向けコマンドプロンプトから where cl を確認する。
次に、不要な生成物を削除して godot-cpp をクリーンビルドする。
それでもダメなら、Visual Studio InstallerでC++デスクトップ開発一式とSDKを再確認する。
さらに、最小のGDExtensionサンプルが通るか検証する。
そこで通れば、初めてMaskノード風の実装に戻る。
この順番なら、闇雲にコードを書き換えるよりはるかに早く原因へたどり着けます。
まとめ：今回の本当の敵はMaskノード実装ではなくMSVC環境の不整合
Godot 4.6でBlendTree向けのMaskノード風プラグインを作ること自体は十分現実的です。
しかし、今回のビルド失敗ログを見る限り、問題の中心はノード設計ではありません。
-
/std:c++17が無視されている -
godot_cppのヘッダで構文エラーが連鎖している -
自作コード以前の段階で止まっている
この3点から、最優先で疑うべきはMSVCの呼び出し先、Visual Studioの開発者環境、そして godot-cpp を含むビルド基盤の整合性です。
逆に言えば、ここさえ整えば、作りたいプラグインの実装検証に進める可能性は高いです。
Godot拡張開発では、コードそのものより先に「正しいツールチェインが動いているか」を確保することが成功の分かれ道になります。まずはコンパイラが本当に想定通りのMSVCとして動いているか、その一点から見直すのが突破口です。
