RealityKitと空間的メンタルモデル

ジャンル： frontier-essay。本記事では、RealityKitが要求する空間的メンタルモデルを明らかにします。visionOS上のSwiftUIでは3D空間に浮かぶウィンドウが手に入りますが、RealityKitでは部屋全体が手に入るのです。両者の違いはメンタルモデルにあり、そのメンタルモデルこそがアーキテクチャそのものとなります。

SwiftUI開発者が初めてvisionOSに触れると、iOSで作るのと同じ形——内部にビューを持つWindowGroup——を組み立てがちです。その結果、空間に浮かぶ平面パネルができあがります。多くのアプリにとって、このパネルは十分な選択肢です。しかし、パネルの周囲に広がる「部屋」こそがvisionOSの真価であり、そこはRealityKitの領域となります。

RealityKitは3D版のSwiftUIではありません。アーキテクチャは次元が違うだけでなく、形そのものが異なります。SwiftUIは値型のビューツリーであり、observationシステムの上にresult-builder DSLを乗せた構造です。フレームワークの仕事は、現在の状態から次のレンダリングを計算することにあります。一方、RealityKitはエンティティ・コンポーネント・システム（ECS）であり、仮想エンティティを現実世界の参照点に結びつけるアンカーを起点とするシーングラフを持ちます。フレームワークの仕事は、ユーザーと世界が動き回る中で3Dシーンを維持することです。同じSwiftプロジェクトが両者を同時に使うこともあり、その境界線こそが空間デザインの失敗が最も多く生まれる場所となります。

本記事では、空間的メンタルモデルを順を追って解説します。SwiftUIウィンドウとモデルが異なる5つの具体的な観点と、それぞれのフレームワークが正解となる場面を切り分けるルーティングの問いを取り上げます。

TL;DR

• RealityKitはエンティティ・コンポーネント・システム（ECS）です。エンティティはノード、コンポーネントはノードに付加された型付きデータ、システムは特定のコンポーネントの組み合わせを持つエンティティに対してロジックを実行する仕組みとなります。
• アンカーは仮想エンティティを現実世界の参照点に結びつけます。RealityKitはAnchoringComponent.Target（.world、.head、.hand(_:location:)、.plane(...)、.image(...)、.referenceObject(...)）を通じてアンカーターゲットを公開します。visionOSでは、ARKitがアンカー更新ストリーム経由で報告する裏側のアンカー構造体（WorldAnchor、HandAnchor、ImageAnchor、ObjectAnchor、PlaneAnchor）を提供します。
• 3Dシーンはビューツリーではありません。レンダーループは連続的に動作し、シーングラフは時間とともに変化します。レンダリング層は差分ベースではなく、GPU駆動（裏側ではMetal）となります。
• RealityViewはSwiftUIのブリッジです。SwiftUIビューツリーの中にRealityKitシーンを配置するもので、境界は一方向となります（SwiftUIがRealityKitをホストし、その逆ではありません）。
• ルーティングのルール：ユーザーがウィンドウを求めるならSwiftUIで、ユーザーが部屋を求めるならRealityKitで出荷しましょう。両方が必要なアプリは、SwiftUIウィンドウの中にRealityViewを配置し、両者の連携を明示的に書くことを受け入れることになります。

SwiftUIウィンドウとの5つの違い

パネルの外に何かを置いた瞬間、形が変わります。重要な違いは5つあります。

1. View-Body-Stateではなく、Entity-Component-System

SwiftUIのビューは値型で、body計算プロパティとプロパティラッパーで支えられたstateを持ちます。¹ フレームワークはstateが変わるたびにbodyを再実行し、その差分がレンダラーに渡されます。

RealityKitのエンティティは、シーングラフ上に存在する参照型のオブジェクトです。コンポーネントはエンティティに付加される型付きの構造体で（ModelComponent、Transform、CollisionComponent、PhysicsBodyComponent、自前で定義するカスタムComponent型など）、² システムはSystemプロトコルに準拠する型となります。フレームワークは登録された各システムをフレームごとに1回実行し、System.update(context:)（通常は構造体上でmutating）が、クエリにマッチするエンティティのコンポーネントをシステムが読み書きする場所となります。

import RealityKit

let cube = Entity()
cube.components.set(ModelComponent(
    mesh: .generateBox(size: 0.1),
    materials: [SimpleMaterial(color: .blue, isMetallic: false)]
))
cube.components.set(InputTargetComponent())
cube.components.set(CollisionComponent(shapes: [.generateBox(size: [0.1, 0.1, 0.1])]))

このcubeにはbodyがありません。cubeにはコンポーネントのセットがあるのです。InputTargetComponentとCollisionComponentを加えることで、cubeはジェスチャーに反応するようになります。それらを取り除けば、ジェスチャーは奥のエンティティへ素通りします。PhysicsBodyComponentを加えれば、cubeは重力で落下します。それを取り除けば、cubeは宙に浮いたままです。コンポーネントの組み合わせがエンティティの振る舞いを決定するのです。

メンタルシフト：SwiftUIでは、stateの関数として画面に何が表示されるべきかを記述します。RealityKitでは、エンティティが何であるか（コンポーネント）を記述し、何が起こるかはシステムに委ねるのです。

2. 座標ではなく、アンカー

SwiftUIビューの座標系はウィンドウです。0,0は左上の角、位置はポイント単位、ビューのフレームがその空間となります。ウィンドウが宇宙そのものなのです。

RealityKitシーンの座標系は、そのアンカーに依存します。アンカリング層には2つの顔があります。RealityKitのAnchorEntity（AnchoringComponent.Targetによって駆動される）はエンティティを配置する対象であり、ARKitのアンカー構造体は、ターゲットを現実世界と同期させ続けるためにシステムが使う裏側のデータとなります。³

AnchorEntityやAnchoringComponentの内側で利用できるRealityKitのアンカーターゲットは次のとおりです：

• .world(transform:)：transformで定義された現実空間の点
• .head：ユーザーの頭部姿勢にロックされ、エンティティはユーザーの視線に追従します
• .hand(_:location:)：特定の手の関節（手のひら、指先、手首など）にロックされます
• .plane(...)：検出された水平面または垂直面（テーブル、壁、床）にロックされます
• .image(...) / .referenceImage(...)：環境内で認識された2D画像にロックされます
• .referenceObject(...)：認識された現実世界の3Dオブジェクトにロックされます

visionOSでは、ARKitがWorldAnchor、HandAnchor、ImageAnchor、ObjectAnchor、PlaneAnchor構造体を通じて裏側のアンカーデータを供給し、これらはARKitSessionのアンカー更新プロバイダ経由で配信されます。（ボディトラッキングは、Appleのボディトラッキング表面ではiOS/iPadOS限定です。visionOSはRealityKitアンカーターゲットとして.bodyを公開していません。）

シーンを「リアル」にするのは、まさにアンカーです。ユーザーのテーブル上の.planeターゲットに配置された仮想チェス盤は、ユーザーが周囲を歩いてもテーブル上に留まります。一方、.headターゲットに対する固定座標に配置されたチェス盤は、ユーザーの頭に追従し、まるで幻覚のように感じられるでしょう。

メンタルシフト：位置は数字ではありません。位置とは、アンカーは何で、エンティティはアンカーに対してどこにあるかということです。妥当なアンカーを持たない仮想オブジェクトは幻覚にすぎず、アンカーこそがそのオブジェクトが部屋の一部であるとユーザーに伝えるものなのです。

3. 差分ベースではなく、連続レンダーループ

SwiftUIはstateが変わったときにレンダリングします。再レンダリングが必要かどうかをフレームワークが判断し、最小限のツリー変更を計算します。レンダリングの間、画面は静止しています。

RealityKitはフレームベースのシミュレーションとレンダリングループを駆動します。シーングラフは時間とともに変化し、物理エンジンやアニメーションシステム、入力ハンドラがエンティティのトランスフォームやコンポーネント値を更新します。レンダラー（Metalベース）はフレームごとにアクティブなシーンを描画します。フレームごとのロジックはSystem.update(context:)の中に書きます。このフックは、フレームワークが「毎ティック、シーンを変更してよい」と招待してくれている場所なのです。⁴

メンタルシフト：時間はシーンの一部です。1回だけ実行されるSwiftUIのビューbodyで十分な場面はあります。しかしRealityKitのエンティティでは、フレームN+1、N+2、N+3で何が起こるかを考慮する必要があります。カスタムSystemのupdate(context:)メソッドはフレームごとのロジックを書く場所であり、update内で変更するComponentの値が、次のパスでレンダラーが読み取るデータとなります。

4. RealityViewはブリッジ、ただし一方向

SwiftUIビューは他のSwiftUIビューを組み立てます。RealityKitのエンティティは他のRealityKitエンティティを組み立てます。両者の境界がRealityViewであり、これはRealityKitシーンをホストするSwiftUIビュー型となります。⁵

import SwiftUI
import RealityKit

struct ContentView: View {
    var body: some View {
        RealityView { content in
            // Build the scene
            let cube = Entity()
            cube.components.set(ModelComponent(
                mesh: .generateBox(size: 0.1),
                materials: [SimpleMaterial(color: .blue, isMetallic: false)]
            ))
            content.add(cube)
        } update: { content in
            // Mutate the scene in response to SwiftUI state changes
        }
    }
}

makeクロージャは、ビューが最初に表示されるときに1回だけ実行されます。updateクロージャは、ビューが依存しているSwiftUIのstateが変化するたびに実行されます。どちらのクロージャでも、contentパラメータを通じてRealityKitシーンにアクセスでき、エンティティを追加したり、トランスフォームを変更したり、システムを登録したりできるのです。

境界は一方向です。SwiftUIがRealityKitをホストします。RealityKitはSwiftUIをホストしません。つまり、SwiftUIビューをエンティティの「内部」に置いて、SwiftUIサブビューが親の中で描画されるかのように3Dシーンの一部としてレンダリングさせることはできません。例外はアタッチメント（RealityViewのattachments:パラメータ内）で、名前付きSwiftUIビューを宣言し、ViewAttachmentEntity値として取得して、他のエンティティと同様に3Dシーン内で配置・スケーリングできます。⁵ アタッチメントはエンティティ内部に埋め込まれたSwiftUIビューではなく、レンダラーが3D空間に配置できるエンティティとしてラップされた2DのSwiftUIサーフェスです。デフォルトでは固定の向きを保ちます。装着者の方を向かせたい場合は、アタッチメントエンティティにBillboardComponentを付加してください。

5. 3Dにおけるジェスチャーは別物

SwiftUIのジェスチャー（.onTapGesture、DragGestureなど）はスクリーン空間で動作します。システムは指がビューに対してどこにあるかを把握しており、フレームワークは2Dのヒットテストに基づいてディスパッチします。

RealityKitのジェスチャーはシーン空間で動作します。⁶ システムはユーザーがどこを見ているか（ゲイズレイ）、ユーザーの手がどこにあるか（ハンドトラッキングの関節）、そしてゲイズ＋タップがどのエンティティと交差するかを把握しています。ディスパッチモデルは「ユーザーがこのエンティティを見てピンチした」という形で、タップに相当するものとなります。

エンティティがジェスチャーを受け取るには、InputTargetComponentと、ヒットテスト用の形状を定義するCollisionComponentが必要です。InputTargetComponentがなければ、エンティティはジェスチャーシステムから見えません。CollisionComponentがなければ、ジェスチャーシステムにはヒットテストする形状がありません。両方が揃っている必要があるのです。

メンタルシフト：ジェスチャーのターゲットはスクリーン領域ではありません。ジェスチャーのターゲットは、明示的に入力をオプトインした3Dエンティティとなります。シーンの残り部分は「ユーザーが透かして見ることができる装飾」にすぎないのです。

SwiftUIで十分な場合

一般的なvisionOSアプリにはRealityKitが必要ない場合があります。SwiftUI単体で正解となる3つのパターンを挙げましょう。

空間的コンテンツを持たないウィンドウ型アプリ。 瞑想タイマー、ノートブック、設定画面、チャットインターフェース。これらは2Dのアフォーダンスを通じて読んだり操作したりする情報です。WindowGroupに入れてフラットなまま保つのが正解となります。visionOSはSwiftUIウィンドウをシステムchromeを伴う浮遊するガラスパネルとして扱うため、RealityKitを1行も書かずに、ユーザーは快適な閲覧体験を得られます。

フラットパネルを空間に組み合わせるマルチウィンドウアプリ。 エディタ、ターミナル、ドキュメントを別々のウィンドウとして持つコードエディタ。ユーザーはウィンドウを3D空間に配置（左、右、後ろ）したいと思いますが、各ウィンドウ自体はSwiftUIビューです。3D配置はOSの仕事であり、パネルはフラットなままです。

ドキュメントビューア、フォトギャラリー、ビデオプレーヤー。 ユーザーがパネルを通じて消費するコンテンツです。パネルはレンダリング面であり、3次元目はパネルが部屋の中で占める空間的な位置にすぎません。

ルール：コンテンツが2D（テキスト、画像、動画、コントロール）なら、正解のフレームワークはSwiftUIです。3次元目はパネルが配置される場所のことであり、内部にレンダリングされるものではないのです。

RealityKitが必須となる場合

SwiftUIでは不十分なケースは次のとおりです：

ユーザーが歩き回れる3Dコンテンツ。 ユーザーのテーブル上の仮想オブジェクト（モデルカー、彫刻、建物）。オブジェクトには体積があり、ユーザーは周囲を移動でき、オブジェクトは部屋と正しくオクルージョンする必要があります。正解のフレームワークは、.planeターゲットにアンカリングされたRealityKitとなります。

部屋に応答する空間UI。 現実のキーボードの上に浮かぶボタン、現実のオブジェクトに付随する注釈、現実の壁に沿って配置された仮想メジャー。UIの位置はワールドジオメトリによって決まるのであり、ウィンドウの座標空間によって決まるのではありません。RealityKitアンカーがバインディングを行い、RealityView内のSwiftUIアタッチメントが2Dのアフォーダンスを提供します。

連続的な空間シミュレーション。 鳥の群れ、床を転がるボール、流体シミュレーションなど、シーンの状態が時間とともに進化するもの全般。連続レンダーループが正しいツールです。SwiftUIの差分ベースのレンダラーでは、フレームを取りこぼすか、バッテリーを消耗させてしまうでしょう。

ハンドトラッキング操作。 ピンチでつかむ、両手でスケーリングする、空中で描画する。入力モデルとして、ARKitのHandTrackingProvider（HandAnchorの更新付き）と.hand(_:location:)アンカーターゲットが必要となります。SwiftUIはこの表面を公開していません。

ボディトラッキング型AR。 ユーザーのポーズを仮想キャラクターに反映させる、フィットネスアプリでユーザーの身体を追跡する、現実世界のオブジェクトを認識する。キャプチャと推論はARKit（RealityKitの低レベルの相棒）で行われ、RealityKitが結果をレンダリングします。

ルール：コンテンツが3Dで部屋の中に存在する（体積を持つ、アンカリングされている、シミュレーションされている、または手で駆動される）なら、正解のフレームワークはRealityKitです。SwiftUIはその周囲のchromeとなるのです。

コンポジションパターン

非自明なvisionOSアプリのほとんどは、両方を使うことになります。よく出荷されるパターンは次のとおりです：

1. アプリのchrome（設定、ナビゲーション、リスト、フォーム、インスペクタパネル）はSwiftUIウィンドウに置きます。
2. 空間シーン（ユーザーが操作する体積のあるコンテンツ）は、独自のウィンドウまたはボリューム内のRealityViewに置きます。
3. 両者はSwiftUIのstateを通じて通信します。SwiftUIパネルのボタンが@Stateのbooleanをトグルし、RealityViewのupdate:クロージャがそのbooleanを読み取ってシーン内のエンティティを変更します。
4. SwiftUIに表面化させる必要があるRealityKit側のstate変更は、RealityViewのmake:クロージャが登録するコールバック（シーンのイベントパブリッシャに対するsubscribe(to:)）を通じて行います。⁷

struct GalleryView: View {
    @State private var selectedSculpture: SculptureID?

    var body: some View {
        HStack {
            // SwiftUI side: list of sculptures
            List(allSculptures) { sculpture in
                Button(sculpture.name) {
                    selectedSculpture = sculpture.id
                }
            }
            .frame(width: 300)

            // RealityKit side: 3D rendering of the selected sculpture
            RealityView { content in
                // Build initial scene
            } update: { content in
                guard let id = selectedSculpture else {
                    content.entities.removeAll()
                    return
                }
                // Mutate scene to show the selected sculpture
                presentSculpture(id, in: content)
            }
        }
    }
}

この分割は、どちらのフレームワークがどの仕事を担うかについて正直となります。SwiftUIはリスト、ボタン、レイアウト、stateを所有します。RealityKitは3Dレンダリング、エンティティ、連続シミュレーションを所有します。stateは1つの@State値として境界を越えますが、どちらのフレームワークも相手の領域に手を伸ばすことはありません。

自分のスタックなら何を変えて作るか

空間シーンを出荷した経験があれば認識しやすくなる、3つのパターンがあります：

アンカーが先、エンティティが後。 機能を設計するときは、ジオメトリより先にアンカーを決めましょう。ユーザーの手にアンカリングされた仮想楽器は、テーブル上の.planeターゲットにアンカリングされた同じ楽器とは別の製品となります。アンカーがオブジェクトに対するユーザーの関係性を決定し、ジオメトリは実装の詳細にすぎないのです。

サブクラスではなく、コンポーネント。 Entityをサブクラス化してChessPiece: Entityのようなドメイン型を作りたくなりますが、コンポジションパターンは継承を毎回上回ります。チェスの駒は、ChessPieceComponent（カスタムデータ：色、種類、位置）、ModelComponent（3Dメッシュ）、InputTargetComponent、CollisionComponentを持つEntityとなります。新しい振る舞いは新しいコンポーネントであり、新しいサブクラスではありません。

横断的ロジックにはシステムを。 10個のエンティティが同じ振る舞い（重力、衝突応答、音声減衰、ジェスチャー状態）を必要とするとき、関連コンポーネント上で動作するSystemを書きましょう。システムはフレームごとに、マッチするすべてのエンティティに対して1回実行されます。代替案（各エンティティにロジックを置く）はn×nフレームのバグを生み出し、ECSパターンが発明されたのはまさにこれを避けるためなのです。

RealityViewが誤った答えとなる場合

RealityViewに手を伸ばすのが間違いとなるケースをいくつか挙げます：

インタラクションのない単一の3D画像。 静的な3Dロゴや製品レンダリング。代わりにSwiftUIのModel3Dビューを使いましょう。⁸ Model3Dは「USDZを読み込んで表示する」ための安価な経路であり、RealityViewは構築・変更するシーン用となります。

シンプルなARオーバーレイを持つiOSアプリ。 ARKitのARView（古い表面）またはRealityKitのiOS側のARView統合は、AR体験が大規模iOSアプリの内部機能となる場合に正解となることが多いです。RealityViewはSwift・SwiftUIネイティブで、SwiftUI内部によく馴染みますが、アプリの残りがUIKitの場合、古いARViewワークフローのほうがシンプルなこともあるのです。

パネル上の2D描画。 ホワイトボード、写真注釈ツール、フラットな図形エディタ。正しいツールはCanvas（SwiftUIのMetalベースの描画サーフェス）またはMetalViewとなります。3D空間で構築していないなら、RealityViewはやり過ぎです。

visionOS 2+で出荷するアプリにとってこのパターンが意味すること

3つの要点を挙げましょう。

1. RealityKitとSwiftUIは組み合わさるが、融合はしない。 ウィンドウ型のchromeと2DアフォーダンスにはSwiftUIを、部屋型の3DコンテンツにはRealityKitを使いましょう。境界はRealityViewであり、その境界は一方向となります。

2. メンタルモデルはECSプラスアンカー。 エンティティとは、それを構成するもののことです。アンカーは、エンティティがユーザーの現実空間とどう関係するかを決定します。（コンポーネント、アンカー）のペアが設計の単位となるのです。

3. レンダーループは連続的。 時間はシーンの一部です。フレームごとのロジックはSystem.update(context:)に、stateの変化に応じたロジックはRealityView.update:に置きましょう。2つの層を混ぜる（SwiftUIのbodyにフレームごとのロジックを書く、System.updateにstate駆動のロジックを書く）のは、最も一般的なアーキテクチャの間違いとなります。

Apple Ecosystemクラスター全体：Apple Intelligence向けの型付きApp Intents、クロスLLMエージェント向けのMCPサーバー、両者間のルーティングの問い、オンデバイスLLMとToolプロトコル向けのFoundation Models、iOSロックスクリーンステートマシン向けのLive Activities、Apple Watch上のwatchOSランタイム契約、フレームワーク基盤としてのSwiftUI内部、ビジュアル層向けのLiquid Glassパターン、クロスデバイス展開向けのマルチプラットフォーム出荷。ハブはApple Ecosystem Seriesにあります。AIエージェントを伴うiOSのより広い文脈については、iOS Agent Development guideをご覧ください。

FAQ

RealityKitはvisionOS上のSwiftUIの代替ですか？

いいえ。RealityKitとSwiftUIは組み合わさるものとなります。SwiftUIは2Dウィンドウ、コントロール、chromeを担当し、RealityKitは現実世界の参照点にアンカリングされた3Dシーンを担当します。非自明なvisionOSアプリのほとんどは両方を使い、SwiftUIビューツリーの中にRealityKitシーンを配置するブリッジとしてRealityViewを採用するのです。

RealityViewとModel3Dはどう使い分ければよいですか？

単一の静的な3Dアセット（USDZファイル、単一の製品レンダリング）を表示するにはModel3Dを使いましょう。3Dシーンを時間とともに構築・変更する場合（複数のエンティティ、物理、ジェスチャー、ハンドトラッキング、アンカリングされたコンテンツ）にはRealityViewを使います。Model3Dは安価な経路、RealityViewはECSの全表面となるのです。

RealityKitにおけるEntityとComponentの違いは何ですか？

エンティティはシーングラフ上のノードです。コンポーネントはノードに付加された型付きデータとなります。ModelComponentはエンティティにメッシュを与え、InputTargetComponentはジェスチャー対象にし、CollisionComponentはヒットテスト用の形状を定義し、PhysicsBodyComponentは重力に応答させます。自前で定義するカスタムComponent型はドメインデータを保持します。振る舞いは継承よりコンポジション——エンティティの振る舞いは、そのコンポーネントの総和となるのです。

アンカーとは何で、なぜ重要なのですか？

アンカーは仮想コンテンツを現実世界の参照点——ユーザーの頭、手、検出された面、認識された画像、認識されたオブジェクト、または永続的なワールドポイント——に結びつけます。アンカーがエンティティに対するユーザーの関係性を決定するのです。テーブルの.planeターゲット上の仮想オブジェクトは、ユーザーが歩き回ってもその場に留まります。.headターゲット上の仮想オブジェクトは、ユーザーの頭に追従します。正しいアンカーを選ぶことが、空間機能における最初の設計判断となるのです。

RealityKitはvisionOSだけでなくiOSでも動きますか？

はい。RealityKitはiOS、iPadOS、macOS、visionOSで出荷されています。ARKit駆動のAR体験はRealityKitのiOS表面を使います。visionOS表面では、iOSが公開していない空間特有のアンカータイプ（head、hand、world）が追加されます。コアとなるECSパターンは共有されているのです。

参考文献