Godot 4.7 バージョンレビュー：アーキテクチャの革新、開発者エコシステム、およびプロダクション標準

オープンソースのゲームエンジンエコシステムにおいて最も重要かつ革新的な代表格の一つであるGodotは、2026年6月18日にリリースされた安定版（stable release）バージョン4.7により、アーキテクチャの柔軟性、グラフィックスの正確性、そして開発者の人間工学という文脈において、決定的な成熟レベルに到達しました 1。以前のバージョンがエンジンの基本システムの安定化とコアバグの修正に焦点を当てていたのに対し、バージョン4.7は、本番稼働中のプロフェッショナルなスタジオやインディー開発者が日々のワークフローで直面するボトルネックを解決することを目的とした「プロダクションおよびワークフロー指向」の構造を示しています 3。2026年8月18日にリリースされたメンテナンスアップデート4.7.2により、PCSSの影の座標、Windows上での高ポーリングレート（polling rate）マウスのパフォーマンス、およびマルチプレイヤーのレプリケーションシナリオにおける細かな不具合も解消され、本番環境（production-ready）におけるエンジンの安定性がさらに強化されました 5。

Godot 4.7は、ゼロからの新しい物理エンジンや完全に書き直されたレンダーパイプラインを提供するものではなく、既存のForward+およびMobileレンダーインフラストラクチャを拡張し、ユーザーインターフェース（UI）アニメーションにおける慢性的な問題を解決し、モバイル開発プロセスを標準化し、高ダイナミックレンジ（HDR）などの最新のハードウェア要件を満たす、徹底的な改善パッケージです 2。コミュニティや業界の専門家による評価では、特に長年にわたって異なるクローズドソースのエンジン（例えば Unity）を使用してきた開発者が、Godot 4.7のレンダー機能と高速なプロトタイピングの可能性に感銘を受けていることが見受けられます 2。このレポートは、Godot 4.7がもたらす技術的革新、ソフトウェアアーキテクチャに対するこれらの革新の影響、コミュニティからのフィードバック、およびプロジェクトがこの新しいバージョンに移行する際の戦略的評価を、非常に包括的な分析的枠組みの中で検証しています。

レンダーエンジンと3Dグラフィックスインフラストラクチャにおけるイノベーション

グラフィックス処理パイプラインは、Godot 4.7が最も顕著な進歩を遂げた分野の筆頭です。現代のゲーム開発におけるフォトリアリズムとパフォーマンス最適化の間の絶妙なバランスは、レンダーエンジンが提供するツールの多様性とハードウェアアクセラレーション能力にかかっています。新バージョンは、ライティング計算からマテリアル管理に至るまでの多くのレイヤーで、業界標準に追いつく分析的機能を提供しています。

エリアライト（AreaLight3D）とライティング物理学

ライティングモデルは、3Dレンダーエンジンの視覚的説得力を決定する最も基本的な要素です。Godot 4.7以前では、開発者は長方形や広範囲の表面を持つ光源（例えば、ネオンサイン、巨大な工業用窓、テレビ画面、蛍光灯、または柔らかなスタジオ照明）をシミュレートするために、ポイントライト（point lights）を密集させるか、グローバルイルミネーション（Global Illumination）でサポートされた発光（emissive）マテリアルを使用する必要がありました 1。これらの暫定的な間接的解決策は、パフォーマンスの観点からGPUに追加の不必要な負荷を生み出すだけでなく、生成される影のぼかし（半影・ペナンブラ）や物理的正確性の観点からも不十分でした。

Godot 4.7によりコアノジューミュアーキテクチャに追加されたAreaLight3Dノードは、光が無限に小さい単一の点からではなく、境界が定義された2次元の長方形の表面積から放射されることを可能にする分析的なリアルタイムレンダーソリューションを提供します 1。この構造的アーキテクチャは、光源の物理的サイズに応じて自然で徐々に柔らかくなる影の移行を生み出すと同時に、シーン内の滑らかな反射面（specular reflections）上で光源の長方形の形状が正確に反射されることを保証します 1。レイトレーシングを必要としないこのアプローチは、パフォーマンスの予算を超過することなく、シーンの照明品質を劇的に向上させます。建築ビジュアライゼーション、屋内ホラーゲーム（indoor horror）、およびシネマティックな雰囲気のデザインという観点において、この進化はシーンデザイナーにはるかにクリーンなワークフローと優れた視覚品質をもたらします。

高ダイナミックレンジ（HDR）画像出力のサポート

ディスプレイ技術の進歩に伴い、標準的なsRGBの色空間の限界を超えるハードウェアがエンドユーザー市場で標準になりつつあります。Godot 4.7は、エンジンが内部的に浮動小数点（floating point）形式で計算した高ダイナミックレンジのライティングデータを、OSレベルのHDR APIを介して直接サポートされているディスプレイに転送する機能を獲得しました 2。理論的に最大10,000ニトの輝度値をサポートするこの機能により、爆発、ネオンライト、魔法のエフェクト、直射日光などの要素を、画面上で眩しいほどの輝度、深い黒、そしてはるかに広い色域（color gamut）とともに表現することが可能になります 3。

HDR出力のサポートには、ハードウェアドライバおよびOSのウィンドウマネージャ（window manager）との非常に低レベルな統合が必要であるため、プラットフォームとレンダーエンジンの依存関係は固有のものです。この機能の統合に関する構成マトリックスは、以下の表に詳述されています。

オペレーティングシステム / プラットフォームHDRサポートステータス必要なレンダーエンジンアーキテクチャと統合に関する注記Windows完全サポートForward+またはMobileOSレベルでWindows HD Colorの設定がオンになっており、互換性のあるモニターを使用する必要があります。macOS完全サポートForward+またはMobileAppleのネイティブHDR管理APIおよびMetalインターフェースと直接統合されています。iOS & visionOS完全サポートForward+またはMobileモバイルAppleデバイスの高輝度機能およびXDRディスプレイの構成と互換性があります。Linux (Wayland)完全サポートForward+またはMobile最新のWaylandコンポジターでのみ動作します。包括的なウィンドウ管理プロトコルが必要です。Linux (X11)サポートされていません適用不可古いX11アーキテクチャの色深度制限のため無効になっています。開発者はWaylandに移行する必要があります。Androidサポートされていません適用不可広範なAndroidハードウェアの断片化（fragmentation）のため、現在は利用できません。Web (HTML5)サポートされていません適用不可WebGLおよびWebGPUのブラウザグラフィックスAPIの制限により、まだHDR出力を標準化していません。

表からもわかるように、HDRの使用は全体的な必須条件（requirement）というよりも、サポートされているプラットフォームで有効になるオプションの視覚的エンハンスメントレイヤーとして扱うべきです 4。開発者は、HDRをすべての美術監督（art direction）の基礎にするのではなく、標準ダイナミックレンジ（SDR）上で良好に見えるプロジェクトをさらに豊かにするための仕上げとして評価すべきです 4。

Vulkanハードウェアレイトレーシングインフラストラクチャ

ゲーム業界における最大の技術的転換点の一つであるハードウェアレイトレーシング技術は、Godot 4.7とともに、エンジンのVulkanアーキテクチャに対する低レベル（low-level）な配管（plumbing）インフラストラクチャとして統合されました 2。このバージョンには、プレイヤーや開発者がワンクリックで有効にできる「レイトレース反射」（Ray-traced reflections）や「パストレーシング」（Path tracing）といった直接的なエンドユーザー向け機能は含まれていません 10。その代わりに、レイトレーシングの基本要件であるアクセラレーション構造（acceleration structures）の構築や、Vulkanレンダーパイプライン内からの直接的なレイディスパッチ（ray dispatch）機能がエンジンに組み込まれています 2。

この戦略的なエンジニアリングの動きは、大規模スタジオが独自のレイトレーシングソリューション（例えばカスタムライティングシェーダーやミラーシステム）を記述するための標準化された基盤を提供します。過去数年間、ハードウェアレイトレーシングを使用したいと考えていたチームは、NVIDIAまたは独立系開発者がメンテナンスを行っている専用のGodot RTXフォーク（fork）に依存していました 2。4.7で導入されたこのコア統合は、Godot 4.8や4.9などの将来のバージョンにおいて、組み込み（built-in）のレイトレーシング機能がメインエンジン（mainline）上で直接動作することの確実な証拠です 2。

DrawableTexture2Dとランタイムテクスチャ処理

ゲームメカニクスにおいて頻繁に必要とされる「実行時のテクスチャへの描画」（runtime texture drawing）処理は、過去のバージョンでは、別個のViewportを作成してそのビューポート内にシーンを描画するか、複雑なRenderingDevice APIを介して低レベルのGPUコマンドを送信するといった、間接的でコストの高い操作によって実行されていました。Godot 4.7は、これらの複雑さを抽象化し、非常にアクセスしやすくパフォーマンスの高いAPIであるDrawableTexture2Dクラスを導入しました 2。

DrawableTexture2Dにより、開発者は標準的なブリット（blit）呼び出しを使用して、テクスチャ（texture）上にピクセルデータやブラシストロークを直接書き込むことができます 2。この機能により、レンダリングAPIに深く精通していない開発者であっても、複雑なエフェクトを簡単に作成できるようになります。例えば、ストラテジーゲームにおける探索可能な戦場の霧（fog of war）のマスク、レースゲームにおける動的タイヤ痕、キャラクターが表面に塗料を投げつけるメカニクス（paint tools）、プレイヤーが自由に描画できるツール、スクラッチ/露光（reveal mask）ゲーム、あるいはダメージを受けるにつれて変形するアーマーテクスチャ（scratch effects）などが、このAPIを使用してメインシステムに追加の負荷をかけることなく開発できます 1。

Pixel Art and 3D Visuals: Nearest-Neighbor Scaling 伝統的な3Dレンダーエンジンは、低解像度のテクスチャ、マテリアル、または画面出力を画面に投影する際に、デフォルトでバイリニア（bilinear）フィルタリングを使用します。この平滑化アルゴリズムはフォトリアリスティックなグラフィックスでは完璧な結果をもたらしますが、特に90年代のレトロなスタイル（PS1の美学）を模倣したゲームや、低解像度の3Dピクセルアートゲームにおいて、望ましくないぼやき（blurring）を引き起こします 2。コミュニティ内の多くの開発者は、この不具合を排除するためだけにカスタムシェーダーを書く必要がありました。Godot 4.7は、3Dビューポート用に「ニアレストネイバー（Nearest-Neighbor）」のスケーリングオプションを標準的なエンジン機能として統合し、解像度が低下した場合でもピクセルの鮮明さとシャープなエッジを維持する優れた美的制御ツールを提供します 1。この機能は、最新の3D機能とノスタルジックなピクセルアートのアプローチを組み合わせたインディー作品にとって、不可欠なインフラストラクチャを構築しています。

シェーダー（Shaders）、エフェクト、およびマテリアルの改善

ゲームの視覚言語を定義するポストプロセス（post-processing）エフェクトやパーティクルシステムも、詳細な最適化を経ています。コードベースのテキストシェーダー（text shaders）で作業する開発者にとって最大のイノベーションは、エディター内のインライン（inline）シェーダープレビューです。シェーダーコードで数学的な変更を行った際（例えば波の関数の周波数を変更した際など）、エンジンの再コンパイルや異なるワークスペースへの切り替えを行うことなく、変更をリアルタイムでコードエディターの背景上で直接プレビューできるようになりました 2。これは反復速度を圧倒的な次元まで向上させる進化です。

物理ベースレンダリング（PBR）マテリアル側では、車の塗装や濡れた地面などの表面をシミュレートするために使用されるクリアコート（clearcoat）レンダーアルゴリズムが改善され、光のこれらの透明な層上の屈折がより正確になりました 1。レンダーパス（render passes）は、独自の個別の環境（environment）ユニフォームバッファ（uniform buffers）を保持できるようになり、複雑なポストプロセッシングチェーンにおける柔軟性が向上しました 1。一方、3Dパーティクルシステムでは、パーティクルのスケール（scale）および回転（rotation）に対する拡張された制御が開発者に提供され、パーティクルの角速度（angular velocity）に向けた数学的修正が適用されることで、シミュレーションがより有機的に見えるようになりました 1。

ユーザーインターフェース（UI）エンジニアリングとアニメーション

システム

ゲーム開発のプロセスにおいて、ユーザーインターフェースのデザインは、多くの場合、ゲームのコアメカニクスのコーディングよりもはるかに多くの時間を必要とし、イテレーション（反復）が行われやすく、非常に壊れやすい性質を持つ分野です 9 。UI要素がゲーム画面上の変化する解像度に適応できるよう、Godotは最初から堅牢なノードベースのレイアウトシステムを提供しています。しかし、バージョン4.7では、UI要素とアニメーションのインタラクションにおける根本的な構造上の問題が解決され、業界で最も優れたUIツールセットの一つが実現されました 9 。

コントロールノードのオフセット変換（Offset Transforms）

GodotのUIレイアウトシステムは、階層的なコンテナ（Container）ノード上に構築されています。HBoxContainer（水平ボックス）やVBoxContainer（垂直ボックス）内に配置されたコントロールノード（ボタン、パネル、スクロールバーなど）は、コンテナの自動並べ替えおよび配置アルゴリズムによって厳密に管理されます 1 。過去のバージョンでは、デザイナーがボタンにカーソルが乗ったとき（ホバー状態）に視覚的なフィードバックを生み出す目的で、Tweenアニメーションを使用してボタンのスケール（scale）、回転角度（rotation）、または位置（position）を拡大すると、この変更は親コンテナによって「レイアウトの崩れ」として認識されていました。コンテナは即座に再計算を行い、自身のアルゴリズム的ロジックに従ってUI要素を元の位置に戻そうと試みました。これが原因で、ボタンが意図しない形でスナップバック（跳ね返り）したり、メニューがちらついたり、開発者がコンテナシステムと文字通り「戦う（fighting layout）」ことになっていました 1 。

Godot 4.7がUIエンジニアリングにもたらした最も重要な解決策は、視覚的な変換と論理的なボックスモデルを分離するコントロールのオフセット変換（offset transforms）システムです。新しく追加された offset_transform_*（位置、回転、スケール）プロパティは、UI要素が視覚的にどのように描画されるかを決定する一方で、その論理的な座標と占有領域は元の状態に維持します 1 。つまり、オフセット変換を使用してボタンが視覚的に20%拡大されたり、画面上で移動されたりした場合でも、親コンテナはこの変更をレイアウトの更新として認識せず、配置計算を維持します 4 。この分離により、UIプログラマーやテクニカルアーティストは、コンテナ構造やアンカー（anchoring）のロジックを破壊することなく、スムーズでダイナミックかつ柔軟なUIアニメーションを完全に設計できるようになります 4 。コミュニティからのフィードバックにより、この機能がメニューデザインにおける何百もの行に及ぶワークアラウンド（回避策）コードを排除し、「救世主」となっていることが確認されています 9 。

リッチテキストラベル（RichTextLabel）と円錐グラデーション

ユーザーインターフェースのデータ表示能力は、現代のゲームの動的なフォントサイズ調整の要件に対応するように改善されています。RichTextLabel内に [img] タグを使用して埋め込まれた画像（例えば、テキスト内に表示されるXboxコントローラーの「A」ボタンや特殊な絵文字アイコン）は、インラインのテキストサイズに敏感に追従して配置できるようになりました 1 。開発者は [img height=1em] のような相対的なCSS風の定義を使用することで、ゲームの解像度、言語翻訳、またはアクセシビリティ設定が変更されたとき、テキストフォントとともに画像も自動的に比例してスケーリングされるようにすることができます 3 。

さらに、2DエフェクトやUIデザインの分野でカラーパレットを作成するために使用される GradientTexture2D クラスに FILL_CONIC（円錐塗りつぶし）モードが追加されました。標準的な線形または円形のグラデーションとは異なり、この円錐グラデーション機能は、CSSスタイルに似た方法で中心の周りに色をスイープ（sweep）させて分散させます。この数学的な追加により、2Dシェーダーの記述において、円形のプログレスバー、弾薬インジケーター、レーダーのスキャンエフェクト、あるいは疑似3D円柱シェーディング（fake 3D shading）のイリュージョンを作成するための非常に実用的な基盤が提供されます 3 。

エディターエコシステムと開発者ワークフローの改善

ゲームエンジンは、単に実行ファイルを生成するコンパイラーエンジンであるだけでなく、デザイナー、アーティスト、プログラマーが何千もの時間を過ごす生産性および開発ソフトウェア（IDE）でもあります。この文脈において、エディター自体のUIの滑らかさは、開発時間に直接影響します。Godot 4.7には、エディター体験を最適化し、クリック数を減らし、大規模プロジェクトにおける認知負荷（cognitive load）を軽減する多数のQuality of Life（QoL - 生活の質向上）アップデートが含まれています。

アセットストアの誕生（旧アセットライブラリ）

長年にわたりGodot開発者にコミュニティ作成のツールをダウンロードするサービスを提供してきたアセットライブラリ（Asset Library）は、ゼロから最新のAPI標準で書き直されたアセットストア（Asset Store）のコンセプトへと移行しました 2 。これは単なる見た目の名前の変更ではなく、インフラストラクチャレベルのアーキテクチャの刷新です。旧システムでは、巨大なアセットパックがサーバーからダウンロードされる際や検索クエリが処理される際にメインエディターのスレッド（main thread）がロックされ、フリーズの原因となっていました。新しいストアのAPIは、バックグラウンドスレッド（background threading）を積極的に活用します 1 。これにより、コンテンツのダウンロード中であっても、エディターのUIは完全に応答性（responsive）を保ちます 3 。さらに、アセットをより詳しく確認するためのプレビュー画像のズーム機能、コミュニティによる最新の評価（rating）表示、およびよりクリーンなカテゴリーツリー（ショーケース）が統合されています 3 。

インスペクター（Inspector）の改善とアニメーションのトラック折りたたみ

大規模な3Dプロジェクトにおいて、開発者が最も時間を浪費するポイントの一つは、複雑なデータ構造をノード間で転送することです。Godot 4.7のインスペクターパネルに追加された新しいパネルツールのおかげで、類似したノード間で変数（例えば、X、Y、Zの回転やマテリアルのカラーコードなど）を1つずつコピーして転送する代わりに、プロパティのセクション全体をまとめてコピーし、別のノードの同じフィールドにワンクリックで貼り付けることが可能になりました 1 。このメカニズムは、特にマテリアルパラメータや階層的な物理設定をまとめて転送する際に、手動でのヒューマンエラーの可能性をゼロにし、絶大な時間節約をもたらします 2 。

複雑なシーンのアニメーションを管理するために使用される AnimationPlayer とアニメーションのトラック（Animation Tracks）パネルも、人間工学に基づいて見直されました。40〜50個の異なるトラックが存在する複雑なキャラクターのスケルトン（skeleton）をアニメーション化する際、画面がトラックで埋め尽くされスクロールが複雑になるのを防ぐために、「使用されていないノードトラックの折りたたみ（track collapsing）」機能が導入されました 1 。折りたたまれたトラック上に配置されたキーフレーム（keyframes）は、1行の「集約表現（aggregate representation）」として提示されます。これにより、アニメーターは、折りたたまれたトラック内の詳細な内容を確認しなくても、全体のアニメーションのタイミング（timing）に関する視覚的なガイドを持ち続けることができます 3 。

3Dシーンのスナップと定規の改善

レベルデザインやワールド構築（world building）を行う3Dアーティストやレベルデザイナーのために、シーン操作ツールが大幅に強化されました。Godot 4.7以前では、アセットの結合や地面への配置は、主に目視または数値を入力することによって行われていました。新しいバージョンでは、業界標準に追いつく3つの主要なツールセットが提供されます。

頂点スナップ（Vertex Snapping）：エディターでキーボードに割り当てられたショートカットキー（デフォルトでは「B」）を押しながら、開発者は3Dメッシュの特定の頂点を直接選択し、他のオブジェクトの頂点にミリ単位の精度でスナップさせることができます 1 。これにより、モジュラー式のダンジョンデザインや建築ブロックを作成する際に隙間ができるのを防ぎます。
Path3Dとコリジョンスナップ（Collider Snapping）：シーン内に軌跡を描くために使用されるPath3Dのノードポイントは、ビューポートのカメラ平面（camera plane）だけでなく、シーン内の物理コライダー（colliders）の表面に直接スナップできるようになりました 1 。この機能は、山岳地帯や傾斜した地形の上を移動するAIのパトロール経路（patrol paths）や、レーストラックの軌跡を描く際に非常に便利なサポートを提供します 3 。
高度な定規（Ruler）：Shift修飾キーで使用される3D計測ツールは、2点間の絶対的な距離（例えば15メートル）だけでなく、三次元空間内の各座標軸（X、Y、Z）に沿った相対的な長さのベクトル（例えばX軸に10m、Yに5m、Zに10m）も個別に表示するようになりました 1 。ブロックアウトと呼ばれる初期段階のレベルデザインにおいて、この幾何学的なフィードバックは非常に重要です。さらに、3Dカメラのコントロールがエンジン内部の埋め込み型ゲームビュー（embedded game view）と統合（unified）され、開発者が両方の環境でキーボードショートカットやナビゲーションレイアウトを同じに保てるようになりました 3 。長いリストから目的のオブジェクトを見つけやすくするために、PopupMenuウィンドウに検索バーが追加され、新しいノード（Node）やリソース（Resource）の作成画面（Create Dialog）には「カスタムのみを表示」（Show Custom）などのフィルタリングメカニズムが統合されました 1 。コードエディターで作業している開発者がスクリプトウィンドウの上部にあるファイル名をダブルクリックすると、そのファイルが左側のファイルシステム上のどこにあるかが自動的にハイライト（highlighted）され、巨大なデータツリーの中で迷子になるのを防ぎます 3 。リモートシーンインスペクター（Remote Scene Inspector）画面では、列挙型（Enum）の値が単なる意味のない整数（0、1、2）としてではなく、コード内で表される文字列の名前（string names）で表示されるようになりました 3 。

モバイル開発、XR（仮想現実）、およびパフォーマンス最適化

ゲーム業界においてモバイルデバイスやXRヘッドセット（プラットフォーム）のシェアがますます拡大する中、Godot 4.7では、これらのデバイスのハードウェアの制約に対応する専用のソフトウェアフックが標準のコア機能として組み込まれています。

組み込みのVirtualJoystick（バーチャルジョイスティック）統合

モバイルプラットフォーム向けにアクションやロールプレイングゲームを開発するチームは、これまで長い間、画面上の仮想タッチ操作のためにサードパーティ製プラグインや、ゼロから記述され保守が困難な入力（input）コードに依存していました。コミュニティ製プラグインには、エンジンがアップデートされるたびに動作しなくなるリスクがありました4。Godot 4.7は、エンジンのコアに直接統合されたVirtualJoystickノードを提供することで、この断片化を根本から解決します1。

この統合は、モバイルゲームデザインの古典的な操作スキームに完全に対応する3つの異なるインタラクションモデルをサポートしています。

ジョイスティックモードメカニズムとユーザーの動作理想的な使用シナリオ固定（Fixed）ジョイスティックの画面上の位置が固定されています。プレイヤーは親指を画面のこの特定のエリアにドラッグする必要があります。中心には古典的な「デッドゾーン」（dead zone）設定があります。レトロアーケードの移植、コンソール風の固定コントローラー1。動的（Dynamic）プレイヤーが画面の指定されたエリアにタッチした瞬間、その場所にジョイスティックが表示されます。指が離されると瞬時に消え、位置をリセットします。素早い反応が求められるシューターゲーム1。追従（Following）動的モードと同じロジックで始まりますが、プレイヤーの親指が移動の限界を超えると、ジョイスティックの中心軸も指を追従して移動し、プレイヤーが常時接触し続けられるようにします。キャラクターが休むことなく移動するRPGやエンドレスランナー1。

また、コントローラーからの加速度センサー（accelerometer）およびジャイロスコープ（gyroscope）のデータをAPI経由で読み取ることが可能になり、モバイルやコンソールのゲームコントローラーが提供する傾きおよびモーション（motion）コントロールの統合が安定化されました3。

GABE（Godot Android Build Environment）とオンデバイス開発

GodotはAndroid向けのゲーム開発にとどまらず、哲学的スタンスとして「AndroidOS搭載タブレットやモバイルデバイス上で直接ゲーム開発を行う」（Godot Editor for Android）というビジョンをバージョン4.7で大きく前進させました。GABE（Godot Android Build Environment）と呼ばれる専用のコンパニオンアプリのおかげで、Androidデバイス（Samsung Galaxy Tabなど）上で動作するGodotエディタは、APKやAABをビルドするために必要なGradleのエクスポートサポートをデバイス内に直接持つことになりました3。これにより、開発者はパソコンを必要とせず、デバイス上で記述したコードをその場でコンパイルしてフルバージョンのパッケージ（APK）を作成できるようになりました4。

Android上で動作するエディタの人間工学的制約も克服されました。実行時の埋め込みゲームウィンドウ（embedded game window）は固定ではなくなり、サイズ変更やドラッグが可能になったため、横向き、縦向き、タブレットフォーマットなどの異なる画面アスペクト比（aspect ratios）を1台のデバイスでテストできるようになりました1。スクリプト記述画面は、デバイスの横向き・縦向きセンサーに反応して回転可能（landscape coding）になり、キーボードを接続した際の人間工学性が向上しました4。また、ピクチャー・in・ピクチャー（Picture-in-Picture）機能によりテストプロセスがよりモジュール化され、バックグラウンドで実行中であってもゲームを監視できるようになりました1。エクスポートオプションが拡張され、Androidプロジェクトのスプラッシュ画面をカスタマイズ可能に設定できるようになりました1。

ただしこの点において、開発エコシステムからのパフォーマンスに関する警告に注意を払う必要があります。Godotの3Dエンジンは高度な機能を備えていますが、特にモバイルデバイスでCompatibility（GLES3/OpenGL）エンジンを使用する場合、Mali G68などのミドルレンジGPUを搭載したデバイスではレンダリングの制約が発生する可能性があります。業界の分析（Redditのテストレポートなど）によると、バックグラウンドオブジェクトが非常に少なく、わずか3,000ポリゴンしか含まないシンプルなシーンでは、解像度スケールを下げない限りフレームレートが最大38 FPSまで低下することが示されています16。そのため、開発者はAndroidプラットフォーム向けの3D製品を開発する際、ビューポート解像度スケール（viewport resolution scale）、マテリアルのシンプルさ、およびテストデバイスの多様性に最大限の注意を払う必要があります16。

拡張現実（XR）：コンポジションレイヤーとフォービテッドレンダリング

仮想現実（VR）および拡張現実（AR）市場で業界標準となったOpenXRアーキテクチャは、Godot 4.7によってより実用的なものになりました2。Steam FrameおよびAndroid XRプラットフォームへのプロダクションレディ（production-ready）なサポートが提供される一方、OpenXRのアクションマップ（action maps）は最も基本的な4つのプロファイルに絞り込まれ、コントローラー統合の複雑さが軽減されました1。

VR開発プロセスにおいて、UIの読みやすさは最も重要な人間工学的課題です。ヘッドアップディスプレイ（HUD）やテキストを通常の3Dジオメトリのようにシーンに配置する（eye-buffer rendering）と、レンズの焦点距離とピクセル密度のため、ちらつき、ぼやけ、読みにくいテキストが発生します。OpenXRコンポジションレイヤー（composition layer）システムは、UIを通常のゲームワールドバッファの外に移動させ、バイザーのプロジェクションレイヤー（プロジェクター上）に直接描画します3。

Godot 4.7は、これらのコンポジションレイヤーに対する制御を深化させました。開発者は次のことが可能です：

コンポジションレイヤーをシーン内のXRCamera3Dノードに直接アタッチして（lock）固定し、プレイヤーがどれほど素早く頭を振っても、視界内でミリ秒単位の遅延すら発生せずに固定され続ける超シャープ（crisp）なHUD画面を設計できます3。
コンポジションレイヤーのオブジェクトをワールドジオメトリ（world geometry）とペアリング（pairing）させることで、テキストレイヤーを空間内の特定の座標に固定（world-locked）したままにできます3。

グラフィックスパフォーマンスの観点から、VRヘッドセット（Meta Questなど）は解像度が非常に高いデバイスであり、1ミリ秒の節約が快適性（comfort）の面で極めて重要です4。Godot 4.7のMobile Renderエンジンには、Vulkanの「サブサンプル画像」（Subsampled images）技術が統合されました1。この技術は、フォービテッドレンダリング（中央の注視エリアをシャープに、周辺視野エリアを低解像度でレンダリングする）のプロセスで処理されたピクセルをより低い密度で保存することにより、GPUのメモリ帯域幅（memory bandwidth）を劇的に削減します3。これにより、パフォーマンスおよびモバイルデバイスのバッテリー消費において大きなメリットが得られます1。XRプロジェクトには、デフォルトでMobileレンダーエンジンを使用することが推奨されます1。

物理演算の哲学と高度な2Dツールセット

物理システムと衝突アルゴリズムは、ゲームエンジンの動作における心臓部を形成します。Godotはバージョン4.6において、デフォルトの3D物理エンジンとして高性能なJolt Physicsプラグインをコアエコシステムに組み込んでいました。業界における一部の噂に反して、バージョン4.7ではJolt Physicsを変更または廃止していません。Joltエンジンは、新しい3Dプロジェクトおよび4.7アーキテクチャのデフォルト（default）物理エンジンとして、プロダクション環境での安定性を維持しています1。しかし、バージョン4.7における真の物理の変革は、2D衝突アーキテクチャにおける根深い制約を克服することによって成し遂げられました。

一方向コリジョンの方向の自由度（One-way Collision）

2Dプラットフォーマーゲーム（例えば、MarioやHollow Knightのように、キャラクターが下からジャンプして通り抜けることで上に乗ることができる雲や吊り橋のプラットフォームなど）では、一方向コリジョンは頻繁に使用されるメカニクスです。Godot 4.7以前は、物理エンジンは一方向衝突ベクトルが、対応するCollisionShape2Dノード自体のローカルな「上」（Up）の方向（(0, -1)ベクトル）に向かっていると厳格かつ変更不可能なものとして仮定していました3。ゲームデザイナーが衝突の方向を変更したい場合（例えば、キャラクターが右からは通り抜けられるが左からは衝突する壁など）、コライダー（collider）の物理構造や回転を、視覚的なグラフィックノードから完全に独立して回転させ、これら2つの構造を同期させるという面倒な（painful）ハックに頼る必要がありました3。

4.7のアップデートにより、CollisionShape2Dクラスにone_way_collision_direction（一方向衝突方向）という新しい変数が追加されました3。この機能のおかげで、一方向インタラクションの方向ベクトルは、衝突形状の全体的なジオメトリ（ボックスまたはカプセル構造）を一切損なうことなく、360度のローカル空間で自由に割り当てることができるようになりました3。これにより、強風の流れ、キャラクターを押し出すコンベアベルト、角度のついた重力ゾーン、またはプラットフォームからのすり抜けメカニクスを、不要な回転計算なしで、よりエレガントかつ数学的に正確にコーディングできるようになりました。

動的CSGスムージング（Autosmooth）

CSG（Constructive Solid Geometry：コンストラクティブ・ソリッド・ジオメトリ）は、ゲームデザイナーがBlenderやMayaなどの外部3Dモデリングソフトを必要とせず、エンジン内で交差する単純な幾何学形状（立方体、球体、円柱）を使用して（追加、減算、交差演算により）、3Dレベルのプロトタイピングを即座に行うことを可能にするツールです3。しかし、生成されたCSGの地面は常にシャープで、ローポリゴンで、粗い見た目になっていました。

Godot 4.7のCSGルートノードに追加された新しいAutosmooth（自動スムージング）機能は、これらのシャープな多面体構造をハードウェアレベルでプロシージャルに滑らかにします3。「スムージング角度」（Smoothing Angle）パラメータはデフォルトで50度に設定されており、この閾値以下の表面の接合部は自動的に滑らかな面（smooth faces）として処理される一方、より角度の急な交差部分は角のライン（sharp faces）を維持し続けます3。値を大きくするほどよりアグレッシブなスムージングプロファイルが適用され、この機能により、プロトタイプを作成するチームだけでなく、ローポリ（low-poly）制作を行うスタジオも、CSG構造を最終製品（final asset）品質のままゲームに直接インポートできるようになります3。

APIの変更、スクリプト（Scripting）、および

移行（マイグレーション）戦略すべてのメジャーな.xのバージョンアップデート（マイナーリリース）は、新機能を追加する一方で、バックグラウンドでのエンジンパフォーマンスを向上させるためにいくつかのAPI（アプリケーションプログラミングインターフェース）シグネチャを変更し、コードレベルでの破壊的変更（breaking changes）を含んでいます3。Godot 4.7の基本哲学は下位互換性の維持ですが、開発者が既存の4.6（またはそれ以前の）プロジェクトをアップデートする際に考慮しなければならない厳格な移行階層が存在します。

移行プロセスにおいて最も不可欠な方法論は、現在アクティブに作業しているプロジェクトの既存ディレクトリを、エンジンの新しい4.7バージョンで直接絶対に開かないことであり、代わりにプロジェクトのバージョン管理システム（VCS - 例：Git）上で新しいテストブランチ（branch）を作成するか、フォルダ全体を完全にコピーすることです1。エディタがプロジェクトを4.7フォーマットで初めて開くとき、すべてのテクスチャ、テキスト、およびモデルのインポートプロセス（import pipeline）をゼロから再書き込みするため、この操作は元に戻すことができず、隔離によって致命的なデータ損失や後方互換性の破損を防ぐことができます13。

プログラミングとスクリプト記述の新機能

Godot独自の動的スクリプト言語であるGDScriptは、4.7バージョンでフロー制御とシステム統合の面で強化されました：

Javaインターフェース（Interfaces）の実装：以前は、Androidデバイスの専用ハードウェア（カメラAPI、専用センサー、決済システムなど）にアクセスするために、C++やJavaでブリッジプラグインを記述する必要がありました。4.7により、GDScriptはエンジン内から直接Javaインターフェースを統合する能力を獲得し、外部プラグインの必要性が大幅に軽減されました1。
Tweenの一時停止（tween_await）：コードベースのアニメーションを作成するために使用されるTweenシステムは、tween_await()関数を呼び出すことにより、システム内の別のオブジェクトから送信されるシグナル（signal）がトリガーされるまで、自身のランタイムを一時停止（pause）できるようになりました。この機能は、非同期（asynchronous）なアニメーションチェーンを作成するための計り知れないほど便利な機能です1。

C#（.NET）ユーザー向けには、構造化されたシステムが維持されています。Godot 4.7は、「Standard」（GDScriptおよびGDExtension経由でC++をサポート）と「.NET」（C#をサポートし.NET SDKが必要）という、2つの別々の実行可能バイナリ（binary）配布を引き続き提供しています1。過去のC#ベースのプロジェクトを新しいStandardエンジンで開いた場合、スクリプトはコンパイルされず不具合につながるため、正しいバージョンをダウンロードすることが不可欠です1。

主要な破壊的変更（Breaking Changes）一覧

以下の表は、Godot 4.6からGodot 4.7への移行において、既存のコード構造、データ型、API呼び出しに影響を与え、リファクタリング（コードの修正）が必要となる主な変更点をまとめたものです：

影響を受けるクラス / システムプロパティ変更されたメソッド / 変更内容および詳細説明アーキテクチャの互換性ステータス（GDScript / C#）Object（コア - Core）is_class() classパラメータの型が、一般的なString型から、C++レベルで大幅に高速かつ静的なメモリを使用するStringName型に変更されました18。オブジェクトクエリのパフォーマンスが向上します。GDScript：互換性あり。
C#：バイナリおよびソース互換性あり。ZIPPacker（コア）start_file() APIに、セキュリティ用のpermissions（ファイル権限）とタイムスタンプ用のmodified_time（更新日時）という2つの新しいパラメータが追加されました18。GDScript：互換性あり。
C#：バイナリおよびソース互換性あり。OptimizedTranslationgenerate() 言語ローカライゼーション関数の成功状態をレポートできるようにするため、戻り値の型がvoid（なし）からbool（ブール値）に変更されました18。GDScript：互換性あり。
C#：バイナリ互換性なし、ソース互換性あり。GPU/CPUParticles2Dおよび3Drequest_particles_process() 粒子シミュレーションの物理的精度を向上させるため、微調整用のprocess_time_residualパラメータが追加されました18。すべての言語で互換性あり。Control（UI - GUI）accessibility_live スクリーンリーダーなどのアクセシビリティ機能が、グラフィック画面サーバー（DisplayServer）から分離され、独自のAccessibilityServer.AccessibilityLiveMode型に移動されました18。GDScript：互換性あり。
C#：完全な互換性なし（手動でのリファクタリングが必要）。RichTextLabel（UI）定数（Constant）Enum 幅を指定するパラメータであるImageUpdateMask.UPDATE_WIDTH_IN_PERCENT変数の名前が、論理構造により適したImageUpdateMask.UPDATE_WIDTH_UNITに更新されました18。GDScript：互換性なし。
C#：バイナリ互換性なし、ソース互換性なし。RichTextLabel（UI）add_image() / update_image() サイジングの柔軟性を高め、1emのような相対的な小数点（relative）スケールをサポートするため、widthおよびheightパラメータの型が整数（int）から浮動小数点数（float）に変更されました18。すべての言語で互換性あり。

アップデート後の検証およびテスト手順

プロジェクトを4.7環境のバージョン管理システム上で正常に開いた後、コンパイルが成功した場合でも、特定のモジュールの実行時（runtime）回帰テストを実施する必要があります：

UI階層：新しく導入されたoffset_transformの動的挙動により、深くネストされた既存の親子ノードのレイアウト、スクロールビュー、またはポップアップメニューの計算アルゴリズムに影響を与える可能性があるため、メインメニュー、インベントリ、および設定（HUD）画面を最初から最後までテストする必要があります 1 。
マテリアル表現とレンダーパイプライン：標準ダイナミックレンジ（SDR）から、環境に組み込まれたHDR対応レンダーパイプラインへの移行、およびクリアコートアルゴリズムに起因するPBRマテリアルの外観において、色ずれ（カラーシフト）、光漏れ、または影の違いが観察される場合があるため、すべてのライティング構造を検証する必要があります 1 。
Android設定とXRプロファイル：エクスポートプリセットにおけるAndroidのスプラッシュ画面、OBBデータパッケージングの変更、および簡素化された4つの基本プロファイルに削減されたOpenXRアクションマップ（action maps）をゼロから検証する必要があります 1 。
C++ GDExtensionプラグイン：プロジェクトで使用されており、エンジンのC++ソースコードにバインドされているライブラリ（GDExtensions）が、Godot 4.7の新しいAPIシグネチャをサポートするように更新されていない場合、エンジンがクラッシュする可能性があります。アップグレード前に不要なプラグインを無効化し、プロジェクト設定から各プラグインが正常にロードされていることを確認する必要があります 1 。

結論

Godot 4.7バージョンは、単なるゲームエンジンへの「メディア向け機能の追加」というマーケティング哲学から脱却し、プロフェッショナルなゲーム制作サイクルにおける慢性的な痛みを体系的にターゲットにした成熟したエンジニアリングアップデートです 4 。業界やRedditなどの独立系コミュニティハブからの分析が明確に示すように、Unityのような従来のエンジンから移行する開発者の期待に応える安定性と制作の実用性に達しています 8 。

AreaLight3DとHDR画像の統合は、建築ビジュアライゼーションおよび高品質な3Dフォトリアルプロジェクトにおけるエンジンの能力を証明する一方で、ハードウェアレイトレーシング（Ray Tracing）インフラストラクチャのコアへの統合は、将来のビジュアルスタンダードに向けたエンジンの戦略的な準備を象徴しています 2 。一方で、Controlノードのオフセット変換は、UI開発者にとって最大の悪夢の一つであった「レイアウト崩れ」の問題を解消し、VirtualJoystickとGABEの統合により、モバイル市場における外部依存（プラグイン）が終了しました 1 。フォービテッドレンダリング（Foveated rendering）をサポートするVulkanサブサンプル画像システムにより、XRハードウェアにおけるパフォーマンスの限界も最大化されています 1 。

オープンソースの哲学と何百ものコントリューターの尽力によって形作られたGodot Engineは、バージョン4.7により、4.x世代の中で最も安定しており、開発者フレンドリーで、最新のハードウェア性能を最大限に活用するバリアントを提示しました。既存のプロジェクトにおいて、詳細なAPI変更、互換性の制限、およびテスト手順を考慮して行われる分離されたバージョン移行（マイグレーション）戦略は、開発スタジオのプロジェクトにおける制作スピード（イテレーションタイム）、製品のメンテナンスコスト、およびエンドユーザーからのゲームのグラフィック品質を間違いなく次のレベルへと引き上げるでしょう。

*情報：画像はGoogle Geminiによって生成されました。

Godot 4.7の新機能調査