RORK LABEN
MAX — Rork MaxはiPhone・iPad・Apple Watch・Apple TV・Vision Pro向けにネイティブSwiftを生成し、2クリックでApp Store公開でき、Xcodeを必要としませんSTACK — 通常のRorkはReact Native(Expo)でクロスプラットフォームのモバイルアプリを作る位置づけ。用途に応じた使い分けが鍵ですFOCUS — BoltやLovableのようなWeb中心ツールと違い、RorkはiOS/Androidのネイティブアプリ生成に特化していますBUGS — 実利用レビューでは遭遇したバグの約70%を手動介入なしで解決、残り3割はエクスポート済みコードでの手修正が必要と報告されていますFUNDING — Rorkはa16z(Andreessen Horowitz)から$2.8Mを調達しましたPRICING — 無料で開始でき、有料プランは$25/月からです。まず触ってから判断できますMAX — Rork MaxはiPhone・iPad・Apple Watch・Apple TV・Vision Pro向けにネイティブSwiftを生成し、2クリックでApp Store公開でき、Xcodeを必要としませんSTACK — 通常のRorkはReact Native(Expo)でクロスプラットフォームのモバイルアプリを作る位置づけ。用途に応じた使い分けが鍵ですFOCUS — BoltやLovableのようなWeb中心ツールと違い、RorkはiOS/Androidのネイティブアプリ生成に特化していますBUGS — 実利用レビューでは遭遇したバグの約70%を手動介入なしで解決、残り3割はエクスポート済みコードでの手修正が必要と報告されていますFUNDING — Rorkはa16z(Andreessen Horowitz)から$2.8Mを調達しましたPRICING — 無料で開始でき、有料プランは$25/月からです。まず触ってから判断できます
記事一覧/AIモデル
AIモデル/2026-06-15上級

Rork Max の RoomPlan で部屋を測るアプリを作る — スキャン精度のばらつきを設計で吸収する

Rork Max が Swift ネイティブを生成できるようになり、LiDAR を使った RoomPlan の部屋スキャンが現実的な選択肢になりました。スキャン結果は端末や持ち方で揺れます。その揺れをアプリ側の設計でどう吸収し、安定した寸法データとして書き出すかを実装視点でまとめます。

Rork Max166RoomPlanLiDAR2Swift25アーキテクチャ11

プレミアム記事

最初に RoomPlan を触ったとき、同じ六畳の部屋を三回スキャンして、三回とも壁の長さが違う数字で返ってきました。3.62m、3.57m、3.64m。誤差にして数センチですが、間取り図に書き出すアプリを作るなら、この揺れをそのまま見せるわけにはいきません。利用者は「測るたびに数字が変わる道具」を信用しないからです。

Rork Max が Swift ネイティブを生成できるようになって、LiDAR を前提にした計測アプリが個人開発でも一気に近づきました。ただ、生成されたコードをそのまま公開すると、この「揺れ」が利用者の手元でむき出しになります。今回は、私自身が小さな採寸アプリを通して整理した、スキャン精度のばらつきを設計で吸収する考え方を共有します。

なぜ RoomPlan の数字は揺れるのか

RoomPlan は ARKit の上に載っていて、LiDAR で取った点群と、カメラ画像から推定した平面を組み合わせて部屋の構造を再構成します。つまり最終的な寸法は「測定」ではなく「推定」です。推定である以上、入力条件で結果が動きます。

揺れの主な原因は三つあります。採光です。逆光や暗所では特徴点が拾えず、平面推定が甘くなります。次に移動速度です。速く振ると点群が疎になり、壁の端の確定が遅れます。そして端末です。iPhone と iPad Pro では LiDAR の解像度もカメラの画角も違い、同じ部屋でも再構成が微妙にずれます。

ここで大事なのは、これらを「バグ」として潰そうとしないことです。推定の揺れは仕様であり、アプリ側が受け止める前提で設計するほうが、結果として安定します。

揺れを受け止める三層の設計

私は計測データを三つの層に分けて扱うことにしています。生データ層、確定層、表示層です。

生データ層は RoomPlan が返す CapturedRoom をそのまま保持します。ここでは一切丸めません。確定層では、生データに丸めとスナップをかけて「アプリが責任を持つ寸法」に変換します。表示層は確定層の値だけを利用者に見せます。

この分離をしておくと、後で丸めの基準を変えたくなったときに、生データを捨てずにやり直せます。スキャンは利用者にとって手間のかかる操作なので、撮り直しを減らせる設計は体験に直結します。

確定層でかける丸めとスナップ

確定層の中心は二つの処理です。一つは 5cm 単位への丸め。もう一つは直角・平行へのスナップです。実際の部屋の壁はほぼ直角と平行で構成されているので、推定が 88 度や 92 度を返してきたら 90 度に寄せたほうが図面として自然になります。

import RoomPlan
import simd
 
struct ConfirmedDimension {
    let widthMeters: Double
    let lengthMeters: Double
    let cornerAngles: [Double]   // 各コーナーの角度(度)
}
 
enum DimensionResolver {
    // 5cm 単位に丸める。利用者が信頼できる粒度に揃える
    static func snapLength(_ raw: Double) -> Double {
        let grid = 0.05
        return (raw / grid).rounded() * grid
    }
 
    // 直角・平行に寄せる。±4度以内なら 90度倍数へスナップ
    static func snapAngle(_ rawDeg: Double) -> Double {
        let nearest = (rawDeg / 90.0).rounded() * 90.0
        return abs(rawDeg - nearest) <= 4.0 ? nearest : rawDeg
    }
 
    static func resolve(from room: CapturedRoom) -> ConfirmedDimension {
        let walls = room.walls
        // 床平面の最長辺・直交辺をおおまかに width / length とみなす簡略版
        let lengths = walls.map { Double($0.dimensions.x) }.sorted(by: >)
        let width = snapLength(lengths.first ?? 0)
        let length = snapLength(lengths.dropFirst().first ?? 0)
 
        let angles = walls.map { wall -> Double in
            let yaw = atan2(wall.transform.columns.0.z, wall.transform.columns.0.x)
            return snapAngle(yaw * 180 / .pi)
        }
        return ConfirmedDimension(widthMeters: width, lengthMeters: length, cornerAngles: angles)
    }
}

ここで ±4度以内 というしきい値は、私の手元の端末で何度かスキャンして決めた経験値です。広い角度まで寄せると、本当に斜めの壁がある部屋で図面が崩れます。狭すぎると揺れを吸収しきれません。読者のアプリが扱う部屋の種類に合わせて、ここは調整する前提で持ってください。

信頼度を一緒に持たせる

丸めた数字だけを渡すと、表示層は「どれくらい信じてよいか」を判断できません。私は確定値に信頼度スコアを添えるようにしています。点群の密度とスキャン時間から雑に算出するだけでも、表示の出し分けに使えます。

struct DimensionWithConfidence {
    let dimension: ConfirmedDimension
    let confidence: Double   // 0.0〜1.0
 
    var needsRescanHint: Bool { confidence < 0.6 }
}

needsRescanHint が立っていたら、表示層で「もう一度ゆっくり撮ると精度が上がります」と添えます。数字を隠すのではなく、確からしさを正直に伝えるほうが、利用者は道具を信頼してくれます。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
RoomPlan のスキャン結果が端末・採光・持ち方で 5〜10cm 揺れる前提で、寸法を確定させる丸め・スナップ処理の設計が持ち帰れます
Rork Max が生成する Swift コードに、寸法を JSON へ書き出す共有契約レイヤーを最小実装として追加する手順がわかります
スキャン失敗・LiDAR 非搭載端末への分岐を、App Store 審査で弾かれないフォールバックとして用意する判断基準がわかります
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Rork Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

AI モデル2026-03-10
Claude Opus 4.6が支えるRork Maxの開発能力 — 実装パターン
Claude Opus 4.6とRork MaxがどのようにネイティブiOSアプリを数分で生成するのか解説します。
開発ツール2026-06-16
Rork Max のネイティブアプリで CloudKit 同期を設計する — 競合と削除をどう扱うか
iPhone と iPad で同じデータを同期させたい——Rork Max が生成した Swift アプリに CloudKit を入れる際、本当に難しいのは保存ではなく『競合』と『削除』の扱いでした。実装で固めた設計判断を整理します。
開発ツール2026-06-15
Rork Max の Swift 生成と Expo 版の責務分界 — どこまでをノーコードに任せ、どこから手で書くか
Rork Max が Swift ネイティブ生成に対応し、通常の Rork は引き続き Expo(React Native)を生成します。2つの生成エンジンを1つのアプリ事業の中でどう使い分けるか、責務の線引きを実アプリの運用視点で設計します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →