Valdiとは何か？Snapchat発のクロスプラットフォームUIフレームワークの特徴とできることを徹底解説

Valdiとは何か？Snapchat発のクロスプラットフォームUIフレームワークの特徴とできることを徹底解説

Valdi（バルディ）は、Snap社（Snapchatの開発元）が内製し長年運用してきたクロスプラットフォーム対応のUIフレームワークです。2025年にオープンソースとして公開された比較的新しいプロジェクトですが、その実力は8年間の社内運用実績が裏付けています。一度のコーディングでiOS・Android・macOSのネイティブUIを同時に構築できる点が最大の特徴で、Web技術に頼らない純粋なネイティブアプリ開発をTypeScriptで実現します。

開発者はTypeScriptでUIコンポーネントを宣言的に記述し、それを各プラットフォームのネイティブUI要素に直接コンパイルできます。例えば一つのTSXコードからiOSならUIKit、AndroidならViewやCompose、macOSならAppKit向けのビューが生成されます。HTML的なWebViewは使わず、React NativeのようなJavaScriptブリッジも介さないため、表示パフォーマンスは各OSのネイティブアプリと同等になります。Snapchatアプリそのものが長期間Valdiで構築・改善されてきたことからも、モバイルならではの高度なUI/UX（スムーズなアニメーションや高度なARエフェクト等）を十分に実現できるフレームワークと言えます。

対応プラットフォームは現在モバイル（iOS/Android）とデスクトップ(macOS)です。Webには対応していないものの、スマートフォンアプリからパソコン向けクライアントまで共通のコードで展開できるメリットは大きいでしょう。Snap社は元々複数プラットフォームでサービスを提供しており、その開発効率とネイティブ品質を両立するためにValdiを開発しました。オープンソース化により外部開発者もこのメリットを享受できるようになったことで、「次世代のクロスプラットフォーム開発」として注目を集めています。

総じてValdiは、「開発速度（Developer Velocity）と実行時のネイティブ性能」のトレードオフを解消することを理念に設計されています。TypeScriptという馴染みやすい言語で高速に開発しつつ、出来上がるアプリはOSごとのネイティブコンポーネントで動作するため高速です。後述するようにホットリロードなど開発体験も洗練されており、単なる新しいおもちゃではなくSnap社のノウハウが詰まった実用志向のフレームワークとなっています。

ValdiはSnapchatが開発し2025年にオープンソース化されたクロスプラットフォームUIフレームワーク

Snap社は長年社内で利用していたクロスプラットフォーム開発基盤を、ついに2025年に「Valdi」としてオープンソース公開しました。Snapchatアプリのように大量のユーザーを抱えるサービスで8年間も磨かれたフレームワークという点で信頼性は折り紙付きです。FacebookのReact Native（2015年公開）やGoogleのFlutter（2018年公開）に続く形で、第三の選択肢としてSnap社が送り出したのがValdiになります。社内専用ツールをあえて外部に公開した背景には、社外開発者コミュニティの力を借りてさらに進化させたい狙いや、業界標準の一翼を担う存在に育てたいという意図があると考えられます。

Snap社はAR（拡張現実）機能や高度なビデオ処理など技術志向の強いプロダクトを展開しており、その開発過程で培われたノウハウをコミュニティに還元する動きとしてValdiは位置付けられます。オープンソース化によってバグ報告や機能改善の提案が集まり、フレームワークの完成度がさらに高まることが期待されています。また、社内の特殊なツールではなく「誰でも使えるOSS」とすることで、優秀な開発者に注目してもらい、ひいてはSnap社自身の技術ブランディング向上にもつながるでしょう。こうした背景から、Valdi公開は単なるソフトウェア提供以上に、Snap社の戦略的な一手として業界の注目を浴びています。

TypeScriptでUIを宣言的に記述しネイティブUIコンポーネントに直接コンパイルされる仕組みが特徴

Valdi最大の特徴は、ユーザーインターフェースをTypeScript (TS)で記述し、それが各プラットフォームのネイティブUIに直接コンパイルされるという点です。開発者はJSXに似たTSX構文でビュー階層を宣言的に記述しますが、その結果物は仮想DOMではなく、ビルド時にネイティブコードへと変換されます。例えば、TSで書かれた<view>や<label>タグは、iOSならUIViewやUILabel、AndroidならViewやTextViewといったネイティブUIコンポーネントに対応します。これにより、動作時には追加のJavaScriptエンジンやWebレンダリングを介さずにUIが表示されます。

この仕組みはReact NativeともFlutterとも異なるユニークなアプローチです。React NativeはJavaScriptでUIを記述しますが、それを実行時にブリッジ経由でネイティブUIに反映します。一方FlutterはDart言語でUIを宣言し、自前の描画エンジンでUIをレンダリングします。Valdiは開発時の記述言語こそReact Nativeに近いTypeScriptですが、変換後の実行形態は「プラットフォーム純正UI」という点でFlutterに近いとも言えます（ただしFlutterはネイティブのUIコンポーネントは使わずSkiaエンジンで描画）。Valdiはこのように「TSで書いてネイティブで描く」という仕組みを取ることで、Web技術の知見を活かしつつネイティブ性能を引き出すことに成功しています。

iOS・Android・macOSと幅広いプラットフォームに対応したマルチプラットフォーム開発が可能

ValdiはiOS（iPhone/iPad）、Android、そしてmacOSという3つのプラットフォームに対応しています。スマートフォンとデスクトップの両方をカバーするクロスプラットフォームUIフレームワークは珍しく、モバイルアプリとPCクライアントを統一技術で作りたいケースに適しています。たとえばチャットアプリやSNSアプリで、スマホ版とMac版を同時開発するといった場面でValdiは威力を発揮するでしょう。

現時点でWeb（ブラウザ）やWindowsには対応していない点には注意が必要です。つまりValdiはWebアプリ開発フレームワークではなく、あくまでインストール型のネイティブアプリ開発向けです。しかし裏を返せばサポートOSを限定することで、各プラットフォームのネイティブ機能に特化し高いパフォーマンスと安定性を得ています。モバイルとデスクトップ（Apple系）に注力した設計はSnap社のプロダクト戦略とも合致しており、将来的にはSnap社製のARグラス（Spectacles）など他デバイスへの拡大も期待されています。

マルチプラットフォーム開発と言えばReact NativeやFlutterもAndroid/iOSをカバーしていますが、ValdiはさらにMac対応が公式に含まれる点で一歩リードしています。特にFlutterはDesktop対応も進めていますがまだ新しく、React Nativeは公式にはモバイルのみ（コミュニティによるWindows/Macサポートはあり）です。その意味でValdiは「Snapchat版Flutter」とも呼べる存在で、Snap社自身がMac向けのクリエイター向けツール（Lens Studioなど）を提供している背景からもMacサポートが重視されています。

WebViewやJavaScriptブリッジに依存せずネイティブ並みの高速パフォーマンスを実現する技術

ValdiはWebViewベースのハイブリッドアプリではなく、また実行時にJS処理を介してネイティブを操作する仕組みでもないため、動作速度や滑らかさはネイティブアプリと遜色ありません。内部的に大量の最適化が施されており、例えば画面要素の再利用（View Recycling）やレイアウト計算の効率化などによって、UI描画のオーバーヘッドを極限まで削減しています。React Nativeの場合、画面上の変更はJavaScript側の仮想DOM差分計算＋ネイティブブリッジ通信を経て適用されますが、Valdiでは最初からネイティブUIを直接構築するためそのような中間コストがありません。

また、Valdiはアプリ起動時や画面遷移時のパフォーマンスにも配慮されています。WebViewを用いるCordova系や一部ハイブリッドアプリでは、初回ロードに時間がかかったりスクロール時にカクついたりする問題がありましたが、Valdiではそうした心配はほぼ無用です。ネイティブコードとしてコンパイルされる分、コード実行も高速で、JSエンジンのガベージコレクションに起因する一時停止なども発生しません。Snapchatほどリッチなアプリの基盤として8年間耐え抜いた性能が保証されているため、パフォーマンス重視のプロジェクトでこそValdiの強みが発揮されるでしょう。

Snapchatアプリで8年間運用され培われた実績が裏付ける高い信頼性と成熟した豊富な機能群が強みとなっている

Valdiはただ理論上速いだけの新参フレームワークではなく、Snapchatという大規模サービスで長年実運用されてきた実績があります。そのおかげで一般的なユースケースはもちろん、苛酷な負荷環境下での安定動作も確認済みです。Snap社内で積み上げられたノウハウが凝縮されており、エッジケースへの対処や細かな使い勝手にも成熟度の高さが感じられます。事実、Valdiには高機能なアニメーションやジェスチャー認識、プロトコルバッファ対応など現代的なアプリ開発に必要な便利機能が標準で含まれています。

さらに、Valdiはまだ「Beta」（ベータ版）という位置づけではありますが、これはフレームワーク自体の不安定さを意味するものではありません。Snap社はドキュメントや周辺ツール類が外部向けに十分こなれていないため慎重を期してBetaと表現していますが、裏を返せばフレームワークそのものは既にプロダクション品質だと言えます。「Betaだから様子見」というより、今すぐ試してフィードバックを提供することで、この強力なツールを一緒に育てていけるフェーズだと捉えると良いでしょう。豊富な機能群と実績に支えられたValdiは、クロスプラットフォーム開発の新たな有力候補として大きな期待が寄せられています。

Valdiが注目される背景：Snapchat内製フレームワークのオープンソース化とその狙い

ここでは、Snap社がValdiをオープンソース化した背景と、その狙いについて掘り下げます。社内専用だった開発フレームワークを外部に公開するに至った経緯には、どのようなストーリーがあるのでしょうか。また、競合するクロスプラットフォーム技術が既に存在する中で、Valdiを公開する戦略的意義にも注目します。

Snapchat社内で使われていたフレームワークを外部公開した経緯と狙いに迫る：Valdi誕生の背景

Snapchatはこれまで、多くの機能を社内開発のカスタム技術で実現してきました。Valdiもその一つで、同社が約8年前から独自に育て上げてきたクロスプラットフォーム開発フレームワークです。Snapchatアプリの裏側で長年動いていた技術を「Valdi」と名付け一般公開したのが2025年末の出来事です。背景には、Snapchatアプリが巨大化・複雑化する中で得られたノウハウを閉じたままにせず、オープンソースコミュニティと共有することでさらなる発展を図る狙いがありました。

Snap社にとって、社内フレームワークを外部公開することは技術力アピールの意味合いもあります。FacebookがReact Nativeを公開しエコシステムを築いたり、GoogleがFlutterで新市場を開拓したりしたように、Snap社もValdiで開発コミュニティに貢献し存在感を示そうとしているのでしょう。つまりValdi公開には、単なる「ソースコード公開」以上に、業界トレンドをリードするプレイヤーになろうとするSnap社の戦略が透けて見えます。事実、Valdiは公開直後から海外の技術メディアやSNSで話題となり、「Snapchatが放った新たなクロスプラットフォームフレームワーク」として注目の的となりました。

内部ツールをオープンソースに踏み切った理由とは？コミュニティへの貢献と社内技術の標準化戦略にある狙い

なぜSnap社は内部ツールをあえてオープンソースにしたのでしょうか。その理由の一つはコミュニティへの貢献とフィードバック獲得です。優れたツールを公開すれば世界中の開発者から改善提案が寄せられ、結果として自社プロダクトの品質向上にもつながります。特にクロスプラットフォーム開発は様々な端末・OSで試されることで初めて欠点が見えてくる部分も多いため、外部の知見を取り込む価値は大きいでしょう。

もう一つの理由は社内技術の標準化です。社内でのみ通用する特殊なフレームワークでは、人材採用や育成の際にハードルが生じます。オープンソース化し広く使われる技術となれば、社内外で同じ知識を持ったエンジニアが増え、結果として社内開発もやりやすくなります。例えばReact Nativeが広まったことで、Facebook社内でもReact Native経験者を採用しやすくなったという話がありますが、Snap社もValdiを普及させることで同様のメリットを得ようとしているのかもしれません。

さらに考えられるのは、Snap社が自社のビジネスに直接関係しない部分はオープンにして、よりコアな部分（例えば独自のARアルゴリズムなど）に社内リソースを集中させる狙いです。フレームワーク自体はオープンソースコミュニティに発展を委ね、Snap社はその恩恵を受けつつ、自社サービスの差別化要因にフォーカスするという戦略とも捉えられます。

React NativeやFlutter台頭の中での差別化：Snapが独自フレームワークを育てた背景

Snap社がValdiを独自開発した背景には、既存のクロスプラットフォーム技術に対する課題意識もありました。2010年代後半、FacebookのReact NativeやGoogleのFlutterが台頭し、多くの企業がそれらを採用してモバイル開発を効率化しました。しかしSnapchatほどパフォーマンス要求が高く複雑なアプリでは、React Nativeでは処理が追いつかない部分や、Flutterではカスタムレンダリングゆえに実現が難しいネイティブ体験などがあったと推測されます。Snap社は自社プロダクトに最適化された解を求め、Valdiという独自路線を歩むことにしたのでしょう。

また、Snapchatはサービス開始当初からiOS/Android両対応でしたが、当初はそれぞれネイティブで別々に開発されていました。並行開発による人的コストや機能差異の発生に課題を感じ、早くからマルチプラットフォーム開発手法を模索していた歴史があります。その結果として社内で生まれたのがValdiであり、React NativeやFlutterが登場する以前から社内で育まれていた可能性もあります。実際、Valdiの原型が8年以上前から存在していたことを考えると、Snap社がいかに先進的にクロスプラットフォーム開発へ取り組んでいたかが分かります。

Snap社にとって、Valdiは単なるフレームワーク以上の戦略的プロジェクトだったと考えられます。他社製技術では得られない要求水準を満たすため、自ら技術投資してでも独自解を追求した結果がValdiです。React NativeやFlutterが一般化した今、Snap社は自前の解決策をコミュニティに提示し、「高速さと開発効率の両立」という難題への一つの答えを示した形です。これは他社との差別化でありつつ、同時にクロスプラットフォーム開発全体の底上げにも寄与する動きといえます。

8年にわたる社内利用で培われたノウハウを全開放するインパクト：開発コミュニティへの刺激と波及効果に期待

Valdiのオープンソース化は、開発コミュニティに大きな刺激を与えました。長年クローズドな環境で熟成された技術が一気に公開されたことで、多くのエンジニアがその中身に興味を持ち、議論や解析が活発に行われています。Hacker NewsやRedditでは「Snapchatのエンジニアはこんな物を作っていたのか」と驚きの声が上がり、ソースコードリポジトリには早速スター（お気に入り）が多数付けられました。

このように注目を集めたことで、Valdiの開発には社外からのコントリビューション（貢献）も期待できます。例えばバグ修正のプルリクエストや、ドキュメントの翻訳、他プラットフォーム対応の提案など、コミュニティ主導で進む部分も出てくるでしょう。それによりフレームワークの成熟が加速すれば、結果的にValdiを採用する企業やプロジェクトも増える好循環が生まれます。

また、大手企業が独自技術を公開する流れ自体にも波及効果があります。Snap社の例にならい、他社も内部ツールを公開する動きが促進されるかもしれません。最近ではByteDance（TikTokの開発元）も社内のクロスプラットフォームUIフレームワーク「Lynx」をオープンソース化しており、企業間で技術を共有し競い合う時代が訪れています。Valdi公開はそのトレンドを象徴する出来事であり、エンジニアコミュニティ全体への良い刺激となっています。

オープンソース化で期待されるValdiのエコシステム形成と開発者にもたらすメリットおよび今後の可能性

Valdiがオープンソースになったことで、今後は周辺ツールやライブラリなどエコシステムの形成も期待されます。例えば、Valdi用のUIコンポーネント集や、ネイティブ機能をラップしたプラグイン、または学習リソース（チュートリアル動画や書籍）などがコミュニティから生まれてくるでしょう。React NativeやFlutterが辿ってきた道と同じく、Valdiも使う人が増えれば自然とエコシステムが拡充していくはずです。

開発者にとって、Valdiという新しい選択肢が増えたメリットは大きいです。これまでReact NativeやFlutterで満足できなかったケース（例えば「ネイティブUIの質感をそのまま活かしたい」「Web前提の技術に頼りたくない」等）に対し、Valdiは有力な代替案を提示します。またTypeScriptを使えることで、Webエンジニアがモバイル領域に参入しやすくなる効果もあります。逆にネイティブエンジニアにとっても、Valdiは従来の知識（iOS/AndroidのUI原則）を踏まえた設計になっているため、違和感なく導入できる可能性があります。

今後の可能性としては、Valdiがクロスプラットフォーム開発のデファクトスタンダードの一つになるシナリオも考えられます。React NativeやFlutterに続く「第三の勢力」として、採用事例が増えていけば業界への影響力も増すでしょう。その一方で、Snap社がどこまで積極的にValdiを推進し続けるかも注視が必要です。現時点ではBeta扱いですが、今後安定版リリースやさらなる機能追加、他OS対応などのロードマップ次第では、Valdiが開発者コミュニティで不動の地位を築く可能性も十分にあります。

クロスプラットフォームUIフレームワークとしてのValdiの仕組み：高性能を支えるアーキテクチャと動作原理

Valdiの高いパフォーマンスと柔軟性を支える内部の仕組みやアーキテクチャについて詳しく見ていきましょう。単にTypeScriptをコンパイルしているだけではない、独自のレンダリングモデルや最適化技術が数多く盛り込まれています。ここでは、Valdiのレンダリング手法、ビュー再利用戦略、レイアウト計算、ネイティブ連携など、主要な技術要素を順に解説します。

宣言的UIレンダリング：JSXライクな構文とonRender関数による効率的な描画モデル

ValdiではUIコンポーネントの描画を宣言的に行うために、JSXに似た構文と独自のレンダリングモデルを採用しています。各コンポーネントクラスにはonRenderというメソッドが定義でき、これがそのコンポーネントのUI構造を記述する役割を担います。例えば以下のようなコードです。

class MyComponent extends Component { onRender() { <view>  ; } } 

ご覧のように、onRenderメソッド内ではまるでHTMLを書くかのように<view>や<label>といったタグを記述できます。これはJSX記法に近いですが、Reactのように要素（virtual DOM）をreturnするのではなく関数内で直接UIを定義して完了させる点が特徴的です。すなわち、ValdiではonRenderが呼ばれた時点でUIツリーがネイティブ側に構築され、以後そのUIを保持します。

このレンダリングモデルにより、Reactのような仮想DOM diffは存在しません。UI更新が必要な場合は適宜コンポーネントのonRenderが再実行され、その差分だけネイティブUIに反映されます。Valdiはこのメカニズムを通じて、宣言的な記述の分かりやすさと、余計なオーバーヘッドを省いた効率的な描画を両立しています。React的なコンポーネント志向に慣れた開発者でも直感的に理解できる一方、内部では無駄な処理を省いた軽量な実装となっているのです。

コンパイルによるネイティブUI生成：TypeScriptコードをiOS/Android/macOS向けに変換するアプローチ

Valdiのビルドプロセスでは、TypeScriptで記述されたUI定義が各プラットフォームのネイティブコードに変換されます。これはコンパイラやコードジェネレータの働きによるもので、具体的にはTypeScriptのインターフェースやコンポーネント定義からKotlinやSwift、Objective-C++のコードを自動生成します。そのため、ビルド後の成果物には各OSのUI部品を構築するコードが含まれており、ランタイムに追加の解釈や中間言語なしで直接実行されます。

このアプローチは、いわばAOT（Ahead-of-Time）コンパイル戦略と言えます。React Nativeが実行時にJSバンドルを読み込んで処理するのに対し、Valdiは事前に必要なネイティブ実装を用意して組み込んでおくイメージです。FlutterもDartコードをAOTコンパイルしてネイティブバイナリに組み込むため、そこは似た発想ですが、Valdiは各OSのUIコンポーネントを直接利用する分、Flutterのようなランタイムエンジンは含みません。そのため生成物のサイズも比較的抑えられ、ネイティブアプリとしてシンプルな構造になります。

もちろん、完全にコード生成任せではなく、Valdi独自のランタイム部分も存在します。例えば共通機能を提供するC++のコアライブラリや、生成コードとOSを繋ぐブリッジ部分（※ここでのブリッジはJSではなくネイティブ間の意味）などです。しかしそれらはSnapchatで鍛え抜かれた高効率な実装になっており、パフォーマンスへの影響は最小限です。結果として、Valdiは「コードを事前にネイティブ化しておく」というアプローチで、実行時のオーバーヘッドを減らし高速動作を実現しているのです。

View Recyclingによるビュー再利用：グローバルプーリングで描画効率とメモリ最適化を実現

Valdiのパフォーマンス技術の一つに「View Recycling（ビュー再利用）」があります。これは画面から消えたUI要素を破棄せずプールし、次に新しく似たようなUIが必要になった際に再利用する仕組みです。例えば、ある画面Aから別の画面Bに遷移したとき、画面Aのビューはすぐには破棄されず、一時的にメモリ上に保持されます。そしてさらに次の画面Cを表示する際に、Aで使っていた一部のビューオブジェクトを再活用できるなら、新規生成を省略して使い回すのです。

このグローバルなビュー・プールによって、画面遷移やリスト表示の際のビュー生成コストが大幅に削減されます。Android開発経験のある方ならListView/RecyclerViewでの「ビューホルダーの再利用」を思い浮かべるかもしれませんが、Valdiはそれをフレームワーク全体で包括的に行っているイメージです。全画面で共通のビューオブジェクトプールを持つことで、例えば複数の画面に共通するUIコンポーネント（ボタンやヘッダー等）は一度生成すれば何度も使い回せますし、リストスクロールで大量のアイテムビューを高速にレンダリングすることも容易です。

この仕組みによりメモリ効率とパフォーマンスの両立が図られています。新規オブジェクト生成やガベージコレクションの頻度が下がるため、アプリの動作がよりスムーズになり、不要なメモリアロケーションも減ります。Snapchatのように複雑なUIが次々と切り替わるアプリでは、このView Recyclingが大きな効果を発揮していると考えられます。Valdiは標準でこの再利用ロジックを組み込んでおり、開発者が意識せずとも自動的に恩恵を受けられる点が優れています。

メインスレッドC++製レイアウトエンジン：Yogaを活用した高速なレイアウト計算処理

UIのレイアウト計算は意外に負荷が高い処理ですが、Valdiではこれにも工夫があります。Facebook製のレイアウトエンジン「Yoga」（C++実装のFlexboxエンジン）を採用し、各コンポーネントのレイアウト計算を効率良く行っています。YogaはReact Nativeも使用している実績あるエンジンで、CSSのFlexboxレイアウトを高速に解決できるのが特徴です。ValdiでもUI要素の配置は基本的にFlexboxモデルで指定するため、WebやReact Native経験者には馴染みやすくなっています。

Valdiがユニークなのは、このYogaによるレイアウト計算をメインスレッド上のC++で実行している点です。一般的にはUIスレッド（メインスレッド）で重い処理をすると描画が止まるため敬遠されますが、Valdiの場合はJavaScriptを介さないネイティブコードであること、さらにレイアウト計算自体を最適化していることから、メインスレッドで即座に計算しても問題がないよう調整されています。むしろ別スレッドで非同期にやり取りするオーバーヘッドを避け、一貫してメインスレッドで処理することで無駄を省いていると言えます。

この結果、レイアウトは非常に高速で、複雑なUIでもスムーズに再配置・再計算が可能です。たとえば画面サイズの変化（回転やリサイズ）や、コンテンツの動的追加・削除が起きても、ValdiはネイティブUIと同等の手応えでレイアウトを更新できます。またYogaのおかげで自動でRTL（右から左の言語）対応もされるなど、多言語展開にも強い設計となっています。

Viewport-awareレンダリング：可視範囲のビューのみをインフレートして無限スクロールも軽快に実現

リスト表示やフィード画面など、スクロール可能なUIでは画面外の要素をどのように扱うかがパフォーマンスに直結します。Valdiは「Viewport-aware（ビューポート認識）なレンダリング」機構により、画面に見えている範囲のビューだけをインフレート（生成）し、見えていない部分は生成すらしないようになっています。これによって、項目数が非常に多いリスト（いわゆる無限スクロール）でも最小限のビュー数で済み、メモリと描画負荷を劇的に削減できます。

この考え方自体はネイティブ開発では一般的で、iOSのUITableViewやAndroidのRecyclerViewも同様の最適化をしています。Valdiではそれをフレームワークレベルで包括的に取り入れており、開発者が特別な対応をしなくても自動的に適用されます。例えばValdi上で長大なリストを実装した場合、フレームワークが現在の表示領域に合わせて必要な要素だけを生成し、スクロールに応じてそれ以外の要素を逐次生成・破棄していきます。この時にも前述のView Recyclingが効いており、一度生成したビューは再利用されるため、新規生成のコストは極小化されています。

これにより、ユーザーがどれだけスクロールしようが常に一定数のビューだけが存在する状態となり、メモリ効率・描画効率共に最適です。Snapchatのフィードやストーリーリスト、チャット一覧などでもこの仕組みが使われていると考えられ、ネイティブのリスト同様にキビキビ動く体験を損なわない要因となっています。Valdiはデフォルトでこうした高度な最適化を備えているため、大規模なデータセットを扱うアプリでも安心して構築できる強みがあります。

「Polyglot Modules」による他言語コード統合：ネイティブコードとのシームレスな連携手法

ValdiはTypeScriptだけで全てを完結させる必要はなく、必要に応じて他言語で書かれたコード（ネイティブモジュール）と連携できます。これを可能にする仕組みが「Polyglot Modules（ポリグロットモジュール）」です。開発者はC++やSwift、Kotlin、Objective-Cといったネイティブ言語でモジュールを実装し、それをValdiに組み込むことができます。Valdiはそれらモジュールとの間で型安全なバインディングを生成し、TypeScript側から直接それらを呼び出したり、逆にネイティブ側からTS側の関数を呼んだりすることも可能です。

この仕組みのおかげで、例えばグラフィックスのようなパフォーマンスクリティカルな処理や、プラットフォーム特有の機能（カメラ制御、Bluetooth操作など）をC++/Swift/Kotlinで実装し、アプリの他部分はTypeScriptで書く、といった柔軟な開発ができます。Polyglot Modulesを用いれば、既存のネイティブライブラリをプロジェクトに統合することも容易でしょう。Valdiが自動生成するバインディングコードは各言語間のデータ受け渡しを安全に行うため、複雑なシリアライズ処理や不安定なブリッジを意識する必要はありません。

これはReact Nativeのネイティブモジュール機能にも似ていますが、Valdiでは事前のコード生成によってより厳密な型チェックと高速な呼び出しが実現している点が優れています。また、単にネイティブ機能を呼び出すだけでなく、たとえばC++で書かれた高性能なライブラリを組み込んでTSから使う、といった高度な活用も考えられます。Snapchat社内ではこの仕組みでレンズ（ARフィルタ）の処理や画像解析エンジンなどを統合しているかもしれません。Polyglot ModulesによりValdiは単体で完結せず、多言語の長所を組み合わせたソリューションを構築できる拡張性を備えています。

Valdiのメリット・デメリット：React NativeやFlutterなど他フレームワークとの違いを比較

次に、Valdiを他の代表的なクロスプラットフォームフレームワークであるReact NativeやFlutterと比較し、そのメリット・デメリットを整理します。それぞれ得意分野や思想が異なるため、プロジェクトの要件によって向き不向きがあるでしょう。ここでは、性能面・開発体験・エコシステム・対応範囲などの観点からValdiの優位点と課題を見ていきます。

ネイティブパフォーマンスの強み：WebView非依存かつ直接ネイティブ描画による高速動作

Valdi最大のメリットは、前述のとおりネイティブアプリと遜色ないパフォーマンスが得られることです。React NativeはJavaScriptブリッジを介した通信オーバーヘッドがボトルネックになりやすく、Flutterは高性能ながらレンダリングが独自エンジン経由となるためOSごとの最適化が難しい面があります。それに対しValdiはUI描画を各プラットフォームの純正コンポーネントで行うため、スクロールの慣性挙動やシステム標準のアニメーションなども含めてネイティブそのものの動きを示します。カクつきの少ない滑らかなUIや、ユーザーの端末リソースを無駄遣いしない軽快さはValdiの大きな強みです。

また、Valdiはレンダリング以外にもパフォーマンス面の配慮が行き届いています。例えば前述のView再利用や遅延レンダリング、C++による効率化など、React Nativeで課題となりがちな部分をことごとく最適化しています。Flutterは独自レンダリングのおかげで画面遷移アニメーションなど統一的にリッチな表現ができますが、その分アプリサイズ増加やメモリ使用量増大のトレードオフがあります。Valdiはよりネイティブに近いアプローチのため、そうしたフットプリント面でも有利と考えられます。総じて、性能重視のアプリ（ゲームや動画処理、ARなど）にはValdiが最有力候補となるでしょう。

ホットリロードと開発者体験：コンパイル不要の即時反映とVSCodeデバッグ対応による快適さ

Valdiは開発者体験（DX）にも注力しており、特にホットリロード（Hot Reload）機能は大きな魅力です。コードを保存すると数百ミリ秒以内に変更がアプリに反映されるため、ネイティブアプリ開発特有のビルド待ち時間を大幅に短縮できます。React NativeやFlutterもホットリロード機能を持っていますが、Valdiは前述のレンダリングモデルのおかげでより細かな粒度で即時反映が可能になっています。UIの一部を修正した際、その部分だけが素早く更新され、アプリ状態を保ったまま確認できるため、UI調整やデバッグが快適に行えます。

さらにVisual Studio Codeでのフルデバッグサポートも提供されており、ブレークポイントを張って変数の中身を確認したり、パフォーマンスプロファイルを取得したりといった作業がVSCode上で完結します。React NativeでもVSCode拡張はありますが、一部ネイティブ側のデバッグにはXcode/Android Studioが必要でした。Flutterは独自IDEプラグインでデバッグを行いますが、Valdiの場合はWebフロントエンド開発でお馴染みのVSCodeで統一できる点が嬉しいポイントです。

言語面でもTypeScriptであることは開発者にとって敷居の低さにつながります。Dart（Flutterの言語）は習得が比較的容易とはいえ新規言語ですし、React NativeのJavaScriptは馴染みやすいもののTypeScript対応は任意です。Valdiは最初からTypeScript前提で型安全かつ快適なオートコンプリートを享受でき、コーディング時のストレスが少ないです。総じて、Valdiの開発体験は「ネイティブ開発の生産性をいかにWeb開発並みに上げるか」という思想で作られており、ホットリロードやデバッガなどその成果が随所に見られます。

既存エコシステムとの互換性：ネイティブUIへの組み込みや既存アプリへの段階的導入が可能

Valdiは既存プロジェクトへの柔軟な統合も考慮されています。公式ドキュメントによれば、Valdiコンポーネントを既存のネイティブアプリ（例えば既存のiOS SwiftUIプロジェクトやAndroid Kotlinプロジェクト）に部分導入することも可能です。具体的には、ネイティブ側のビュー階層にValdiのビューを埋め込んだり、その逆にValdiの画面内にネイティブのUIビューを<custom-view>タグで挿入したりできます。これにより、「新規開発部分だけValdiを使い、それ以外は既存のネイティブコードを活かす」といった段階的移行もできるわけです。

React Nativeも一部画面だけReact Native化するケースがありますが、Valdiも同様にハイブリッド運用が可能です。また、Polyglot Modules機能により既存のネイティブライブラリを包んでTSから利用できるため、過去資産の再利用も比較的容易です。Flutterは逆に既存ネイティブコードとの統合がやや難しく、全画面をFlutterで構築する前提になりがちですが、Valdiはその点で互換性が高く現場に導入しやすいと言えます。

この互換性は、現在React Nativeやネイティブで構築されているアプリにもValdiを試し導入するハードルを下げます。例えばパフォーマンス改善が求められる一部の画面だけValdi版に差し替えて検証するといったことも現実的に可能でしょう。Valdi側でネイティブUIとデータやイベントをやり取りする仕組みが整備されているため、ユーザーから見れば自然に統合されたアプリに映ります。こうした柔軟な導入モデルはValdiの魅力であり、既存エコシステムへの互換性を保ちつつ新技術を活用できる点で実務上ありがたいメリットです。

学習コストとコミュニティ：TypeScript活用の利点と新規フレームワークゆえの課題

Valdiの学習コストについて見ると、言語がTypeScriptであることは多くの開発者にとってプラスでしょう。Web開発者やReact Native経験者であれば、クラス定義やJSXライクな記法も含めて抵抗なく入っていけます。一方でValdi特有の概念（onRenderの仕組みやPolyglot Modulesの使い方など）は新たに学ぶ必要があります。またReactのような巨大コミュニティがまだ無いため、困った時にネット上で解決策が見つかりにくいという課題も当面はあるでしょう。

コミュニティ規模という点では、React NativeやFlutterは既に成熟期に入り多くの利用者と情報が蓄積されています。それに比べるとValdiは黎明期であり、日本語情報も限られます。ただ裏を返せば、黎明期ゆえにコアな部分まで把握しやすいとも言えます。ソースコードが公開されておりSnap社のエンジニアもDiscordコミュニティ等でサポートしているため、積極的に関われば深い知見を得られるでしょう。また先行者利益的に、今Valdiに習熟しておけば将来的に貴重なスキルとなる可能性もあります。

学習に際しては公式のドキュメントやチュートリアルが整備されつつありますが、React Native/Flutterほど豊富ではありません。TypeScript自体の学習コストは低めとはいえ、UI宣言のパラダイムはReactとも少し異なるため、最初は公式サンプルに沿って作りながら慣れる必要があるでしょう。新規フレームワークゆえの未知数な部分も含め、導入前にはチーム内で試験的に触ってみて習熟度を測るといったステップが推奨されます。

サポート範囲の違い：Valdiの対応プラットフォーム（モバイル中心）とWeb未対応の制約

対応プラットフォームの観点で見ると、Valdiは現状モバイルとmacOSに特化しているため、Webアプリ開発には使えないという制約があります。これに対し、FlutterはWebやWindows/Linuxにも対応を広げつつあり、React NativeもエクスペリメンタルながらWeb版（React Native Web）やWindowsサポートが存在します。もしプロダクトでWebとモバイル両方を一つの技術で開発したいという要件がある場合、Valdi単独では完結しない点に注意が必要です。

もっとも、ValdiはWeb未対応だからこそネイティブ性能にフォーカスできているとも言えます。Snap社としてはWeb版は従来通りWeb技術で構築し、モバイルアプリはValdiで、という住み分けを考えているのでしょう。Flutterのように“一つの言語で全プラットフォーム”を目指す方向性も魅力的ではありますが、Valdiはあえて領域を絞ることで品質を高めている印象です。そのため、モバイルアプリに注力するプロジェクトであればValdiの範囲内で十分完結できますが、Web含めオールマイティを求める場合は他技術との併用になる可能性があります。

サポートOSに関連して、Valdiは今のところWindowsやLinuxのデスクトップはサポート外です。macOS対応があるとはいえ、クロスプラットフォームデスクトップアプリフレームワークとして期待すると物足りないでしょう。そうした意味ではValdiは基本モバイルファーストの設計と言え、Snapchatというモバイル主体のサービスから生まれた経緯を反映しています。将来的にSnap社がWindows対応などに取り組むかは未定ですが、当面はモバイルアプリ開発用途で検討するのが現実的です。

ライブラリやツールの充実度：成熟したFlutter/RNと比べ黎明期のValdiエコシステム

フレームワーク選定では利用できるライブラリの豊富さも重要な要素です。この点で現状、Valdiのエコシステムは立ち上がったばかりで、React NativeのExpoや無数のnpmパッケージ、Flutterのpub.devに並ぶ資産はまだ揃っていません。例えば地図表示やSNSログイン、広告SDK統合など定番の機能について、React Native/Flutterなら公式・非公式パッケージが見つかりますが、Valdiでは自作やネイティブ連携で対応する必要があるでしょう。

ただしValdiはPolyglot Modulesを通じて既存ネイティブSDKを呼び出せるため、「ライブラリが無い＝実現不可能」というわけではありません。手間はかかりますが、iOS/Android向けのネイティブSDKが提供されていればValdiから利用可能です。また今後ユーザーが増えれば、有志がValdi対応のラッパーライブラリを次々と開発していくことも十分考えられます。React NativeやFlutterも最初はライブラリが少なかったものの、人気とともに爆発的に充実した経緯があります。

ツール面では、Valdi専用のCLIやVSCode拡張は既に提供されているため基本的な開発は問題ありません。しかし例えばFlutterのDevToolsのような高度なUIデバッグツールや、React NativeのFlipperのようなネイティブ統合デバッグツールなどは、まだValdi独自にはありません。そのあたりは今後コミュニティやSnap社が整備していく部分でしょう。現段階でValdiを採用する場合、ライブラリやツールの未整備による追加工数を見込んでおく必要がありますが、それを補って余りある性能や設計上のメリットを享受できるかどうかが判断の分かれ目となるでしょう。

開発環境の準備とインストール手順：Valdiを始めるためのセットアップガイド

ここではValdiで開発を始めるために必要な環境構築とインストール手順を説明します。モバイルアプリ開発環境として一般的なツールに加え、Valdi特有のCLI（コマンドラインツール）や推奨設定があります。一つずつ順を追ってセットアップしていきましょう。

必要なツールと前提条件：Node.jsやXcode/Android Studioなど開発環境の事前準備

Valdi自体はTypeScriptベースのフレームワークなので、まずNode.js/NPMのインストールが必要です。Node.jsがインストールされていればnpm経由でValdiのCLIを導入できます。またiOS向けにはXcode（およびコマンドラインツール）、Android向けにはAndroid Studio（およびAndroid SDK）といった各プラットフォームの開発ツールも事前に用意しておきましょう。macOS上で開発する場合、Xcodeが必要なのはもちろん、Android開発用にはJavaやAndroid SDKのパス設定も確認しておくと安心です。

現状Valdiの開発環境はMacでの利用を前提としています（iOSビルドにXcodeが必要なため）。WindowsやLinuxでもAndroid向けには開発可能と思われますが、公式ドキュメントではMacでのセットアップ手順が中心となっています。そのため、MacユーザーであればiOS/Android両対応アプリを作れますが、Windowsユーザーの場合はAndroid専用アプリのみValdiで開発できる形になるでしょう。将来的にクラウドビルドなどの選択肢が増える可能性はありますが、まずはMac環境での構築が無難です。

Valdi CLIの導入：npm経由でコマンドラインツールをグローバルインストール

環境の前提が整ったら、Valdi用のコマンドラインツール（CLI）をインストールします。Node.jsが入っていれば、ターミナルで次のコマンドを実行するだけです。

$ npm install -g @snap/valdi

@snap/valdiというパッケージ名でnpm経由インストールすることで、valdiというコマンドが使用可能になります。グローバルインストールすることで、どのプロジェクトからでもvaldiコマンドを呼び出せるようにします。インストールが成功したら、valdi --versionでバージョン確認をしてみましょう。現時点（2025年末）での最新版が正しく表示されればCLI導入は完了です。

Valdi CLIはプロジェクトのセットアップやビルドを担う心臓部です。Snap社が提供するこのツールで、後述の開発環境自動セットアップやプロジェクト作成、各種ビルドを行います。npmを使うため、将来的なアップデートもnpm update -g @snap/valdiで容易に行えるでしょう。なお、CLI自体はMac/Linux環境で問題なく動作しますが、Windowsでは一部機能が制限される可能性があるため注意が必要です。

開発環境の自動セットアップ：valdi dev_setupコマンドによる依存関係の一括構築

Valdi CLIが使えるようになったら、次は必要な依存関係を一括インストールする自動セットアップを行います。Terminal上で以下のコマンドを実行してください。

$ valdi dev_setup

このコマンドにより、Valdiに必要なさまざまなツールやライブラリが自動的にインストールされます。例えばAndroidビルドに必要なGradleや特定バージョンのAndroid SDK、iOSビルドに必要なCocoaPods依存なども、このコマンド一発でセットアップされます。Homebrewが入っていればそれを経由してツール導入を試みるなど、Snap社が環境構築で躓きがちなポイントをスクリプトで解決してくれます。

実行には多少時間がかかる場合がありますが、一度完了すれば手動での煩雑な設定はほとんど不要です。途中でApple IDの入力（Xcodeのコード署名用）や、Android SDKのライセンス同意といったプロンプトが表示されることもあるため、指示に従ってください。完了後、valdi doctorのようなコマンドがあれば実行し、環境に問題がないか確認すると良いでしょう。

この自動セットアップは非常にありがたい機能で、React Nativeでいうpod installやAndroid設定、Flutter Doctorに相当する処理を一括でやってくれるイメージです。初心者でも迷わず環境構築できるよう工夫されているので、エラーが出た場合もログをよく確認し、不足しているものがあれば適宜インストールして再度valdi dev_setupを実行しましょう。

新規プロジェクトの作成：valdi bootstrapでiOS/Android/macOS対応の雛形プロジェクトを生成

次に、Valdiアプリの新規プロジェクトを作成します。任意の作業ディレクトリ（空のフォルダ）に移動して、以下のコマンドを実行しましょう。

$ valdi bootstrap

コマンドを実行すると対話的なプロンプトが表示され、プロジェクト名などの入力を求められます。案内に従って適切に入力すると、iOS・Android・macOSそれぞれのサブプロジェクトを含んだValdi用の雛形プロジェクトが生成されます。例えばiosフォルダ内にはXcodeプロジェクトが、androidフォルダ内にはGradleベースのAndroidプロジェクトが作られ、共通のsrcディレクトリにはTypeScriptのソースコード類が配置されます。

この雛形には簡単なデモ用UIが含まれており、生成直後にビルドすれば画面にHello World的な内容が表示されるようになっています。Valdi独自のプロジェクト構成として、ネイティブプラットフォームごとの設定ファイル（Info.plistやAndroidManifest.xmlなど）は各フォルダに存在し、アプリの画面ロジックはsrc以下にTSで書く、という形になっています。React Nativeを使ったことがある人には似た構成に感じられるでしょう。

このプロジェクト作成コマンドによって、基本的なビルド設定や依存関係も自動で組み込まれるため、手動でプロジェクトをセットアップする手間がありません。特にiOSの設定（Bundle IDやコード署名設定）や、macOSのCatalyst有効化設定など、煩雑な部分はテンプレートが適切に処理してくれます。数分もあれば新規Valdiアプリの骨組みが完成する手軽さは、開発初動のスピードアップに寄与するでしょう。

プラットフォームごとのビルド準備：valdi install ios（またはandroid）でネイティブ依存をインストール

プロジェクトを生成したら、各プラットフォームの依存関係をインストールします。生成直後にこのステップを促される場合もありますが、手動で行うには以下のようにします。

• iOSの場合：$ valdi install ios
• Androidの場合：$ valdi install android
• macOSの場合：iOSと同様iosで兼用（Catalyst経由）

このコマンドにより、iOS/macOS向けにはCocoaPods経由のライブラリインストール（pod install）が実行され、Android向けにはGradle依存の同期が行われます。React Nativeでnpx pod-installするのと同じような工程ですが、ValdiではCLIに統合されています。実行後、ios/ディレクトリに.xcworkspace（Xcode用ワークスペース）が生成され、AndroidもGradleの設定キャッシュが更新されます。

これで各プラットフォームのビルド準備が整いました。試しにXcodeでios/*.xcworkspaceを開いてビルドしてみたり、Android Studioでandroid/フォルダを読み込んで実行してみて、初期状態のアプリが動くか確認しましょう。エミュレータ（シミュレータ）上でデフォルトの画面が表示されれば成功です。なお、Valdi CLIにはvaldi run iosやvaldi run androidといったコマンドは今のところ無いようなので、ビルド・実行は各プラットフォーム標準のツール（Xcode/Android Studioもしくはコマンドラインツール）で行います。

VSCode拡張機能の導入：Valdi専用エクステンションでシンタックスハイライトやデバッグを強化

快適に開発を進めるため、Visual Studio Codeの拡張機能もインストールしておきましょう。Valdi公式からVSCode用の拡張（またはCursorエクステンション）が提供されており、エディタでValdiのTSX構文をシンタックスハイライトしてくれたり、デバッグ支援を行ってくれます。VSCodeの拡張機能マーケットプレイスで「Valdi」を検索し、Snap社提供のものをインストールしてください。

この拡張を導入すると、<view>や<label>などValdi固有のタグが正しく色分け表示されたり、コード補完の精度が上がる効果があります。さらに、先述のVSCodeデバッグ機能もこの拡張を通じて実現されます。ブレークポイントを設定してアプリを実行すると、TSコード上で変数の中身を確認できたり、コールスタックを追えたりします。Valdi開発にVSCodeはほぼ必須と言ってよく、特にChromeのデベロッパーツールなどに頼らなくてもVSCode単独でデバッグが完結する点は大きなメリットです。

なお、エディタはVSCode以外にもJetBrains系（WebStormなど）でも開発自体は可能ですが、公式のデバッグ連携はVSCode向けに用意されています。Valdiプロジェクトを開くと自動でデバッグ設定（launch.jsonなど）が追加されるため、そのままF5キーでデバッグ実行できるでしょう。セットアップガイドとしては以上で、これでValdiアプリの開発を開始する準備が整いました。

はじめてのValdiアプリを作る手順：Hello Worldチュートリアルで基本を徹底解説

それでは、実際にValdiで簡単なアプリを作りながら基本的な開発の流れを掴んでみましょう。ここでは典型的な「Hello World」アプリ相当のシンプルなUIを作成し、画面に文字を表示するまでの手順をチュートリアル形式で解説します。前節でセットアップした雛形プロジェクトをベースに進めます。

プロジェクトの初期状態を確認：デフォルトで生成されるAppコンポーネント構成

まずは生成直後のプロジェクト構成を簡単に確認しましょう。プロジェクトのsrc/ディレクトリには既にApp.ts（またはApp.tsx）というファイルがあり、ここにメインの画面ロジックが記述されています。おそらく以下のような内容になっているはずです。

import { AppRegistry } from 'valdi_core'; import { HomeScreen } from './HomeScreen';
AppRegistry.registerComponent(HomeScreen); 

このように、最初からHomeScreen（仮の画面コンポーネント）が用意されており、それがアプリ起動時に表示される設定になっています。AppRegistry.registerComponent()はReact NativeでいうAppRegistryに似た役割で、メインエントリーポイントを登録しています。HomeScreen.tsxの中身を見ると、Valdiのコンポーネントクラスがどのように書かれているかが分かるでしょう。初期状態ではシンプルなビューとラベルを表示するよう実装されているはずなので、まずはそれを読み解き、出力結果を実行ファイルで確認します。

プロジェクトをビルド＆実行してみましょう。XcodeでビルドしてiOSシミュレータを起動するか、Android Studioでエミュレータ実行します。デフォルトの画面に「Hello Valdi!」等のテキストが表示されれば成功です。初期テンプレートは既に簡単なUIを含んでいるので、これをベースに改造していきます。

簡単なUIコンポーネントの作成：HelloWorldクラスを定義してラベルを表示

では、新たに自分でコンポーネントを作成してみます。src/ディレクトリにHelloWorld.tsxというファイルを作成し、以下のように編集します。

import { Component } from 'valdi_core/src/Component';
export class HelloWorld extends Component { onRender() {   ; } } 

このコードでは、HelloWorldというコンポーネントクラスを定義し、そのonRender内で黄色い背景（#FFFC00）を持つ<view>と、その中に黒いテキストラベル<label>を配置しています。backgroundColorやpaddingといった属性でビューの見た目を指定でき、非常に直感的です。labelには表示したい文字列をvalueプロパティで渡します。

この新規コンポーネントをアプリに表示するには、先ほどのApp.tsでHomeScreenの代わりにHelloWorldを登録します。

import { AppRegistry } from 'valdi_core'; import { HelloWorld } from './HelloWorld';
AppRegistry.registerComponent(HelloWorld); 

これでアプリ起動時にHelloWorldコンポーネントが表示されるようになります。保存してアプリを再実行（またはホットリロード）すると、明るい黄色の背景に「Hello, Valdi!」というテキストが表示されているでしょう。これが最も単純なValdiアプリの画面構築手順です。

onRenderメソッド内でのJSX的記法：<view>や<label>タグでUIを宣言

上記コードから分かるように、ValdiではonRender内で<view>や<label>といったタグ表記を直接記述します。一見するとJSX/TSXでXMLライクなUI定義を書いているようですが、実体はComponentクラスのonRender関数内で特殊な構文を使用している形です。この構文はTypeScriptのJSXサポートを利用したもので、Valdi独自のUI要素をタグとして書けるようになっています。

Reactとの違いは、Reactの場合return <view>...;のようにJSX要素を戻り値としますが、ValdiではonRender関数がvoid（何も返さない）点です。つまり、関数内のタグが一種のテンプレートとして解釈され、Valdiフレームワーク内部でUI構築コードに変換されます。開発者はあたかもJSXをreturnしているかのように記述できますが、実際にはValdiがその場でUIを生成しています。この仕組みにより、JSX的記法のわかりやすさと、レンダリングの効率を両立しています。

<view>タグは基本的なコンテナ（箱）を表し、<label>は文字列表示コンポーネントです。これら以外にもValdiには様々な組み込みUIタグが用意されていますが、名前や属性はできるだけWeb/CSSや従来のネイティブUIに近いものになっているため、推測しやすいでしょう。実際、上記のコードもCSSの知識があれば直感的に背景色や余白を指定でき、React Native経験者ならViewコンポーネントやTextコンポーネントに相当すると理解できるはずです。

アプリのビルドと実行：iOSシミュレータやAndroidエミュレータ上で動作確認

コードを書いたら、実際にアプリをビルド・実行して動作を確認します。Xcodeを使用している場合はビルドしてiOSシミュレータにアプリをインストールします。Androidの場合は./gradlew installDebugなどでエミュレータに転送するか、Android Studio上で実行ボタンを押してください。前述のHelloWorldコンポーネントが画面に表示され、「Hello, Valdi!」のテキストが見えれば成功です。

Valdiはビルド自体は通常のネイティブアプリと同様に行います。初回ビルドには多少時間がかかりますが、2回目以降は差分ビルドになるため高速化されます。また、一度ビルドして実行した後は、基本的にホットリロードで開発を進めることができます。アプリを起動した状態でコードを編集し保存すると、自動で再ビルド・再展開が走り、エミュレータ上の画面が更新されます。従来ネイティブ開発に慣れた方は、このビルド＆実行サイクルが非常に速いことに驚くかもしれません。

開発中にアプリのログを確認したい場合は、Xcode/Android Studioのコンソールや、VSCodeのデバッグコンソールを利用します。Valdiではコンソールログ出力も可能で、console.logを呼べばVSCode上に表示されます。これはReact Nativeのデバッグと同じ感覚で扱えるため、web系開発者にも馴染み深いでしょう。

変更の反映とホットリロード：コード修正が即座にアプリに反映される開発体験

Valdi開発のハイライトとも言えるのが即時フィードバックです。例えば先ほどのHelloWorldコンポーネントのテキストを「Hello, Valdi!」から「こんにちは Valdi！」に変更してみましょう。コード上で書き換えて保存すると、わずか数百ms程度でエミュレータ上の表示が「こんにちは Valdi！」に変わるはずです。ビルドの進捗バーを見る間もなく画面が更新される様子は、まるでWebブラウザのライブリロードや、React NativeのFast Refreshをさらに高速化したような感覚です。

このホットリロードの仕組みはValdi独自のものですが、React Nativeで培われたアイデアを踏襲しつつ、TypeScriptコンパイルの差分反映などでさらに高速化しているようです。編集している箇所にブレークポイントを仕掛けた状態でホットリロードしても、ステップ実行がそのまま継続するとのことで、デバッグしながらのUI修正もシームレスに行えます。ネイティブアプリ開発でありがちだった「微調整してビルド・起動して確認」のサイクルが劇的に短縮されるため、生産性が大幅に向上します。

注意点として、すべての変更がホットリロード可能というわけではありません。プロジェクト設定やネイティブモジュール部分の変更など、一部は完全なリビルドが必要です。しかしUIレイアウトやロジックの大部分はホットリロードが利くため、通常の画面開発ではほぼ再起動なしで開発を進められます。もしホットリロードで不整合が起きた場合は、手動でアプリを再起動すれば正しく反映されるでしょう。いずれにせよ、この即応性の高さはValdiの開発体験を非常に快適なものにしています。

スタイルやレイアウトの調整：paddingやcolorプロパティでUIをカスタマイズ

ValdiでのUIスタイリングは、基本的に各タグの属性として指定します。例えば先ほどの<view>にはpadding={30}と指定しましたが、他にもwidth・height・margin・borderRadiusなど、一般的なスタイルプロパティが用意されています。React Nativeのスタイルシートや、CSSのプロパティに近い感覚で使えるでしょう。

<label>に関しても、color="black"やfontSize={16}などテキスト表示用のスタイル指定ができます。さらにalignItemsやjustifyContentといったFlexbox特有のプロパティもサポートされています。Valdiは内部でYogaエンジンを使っているため、Flexboxベースのレイアウトが基本です。親<view>にflexDirection="row"を指定すれば子要素を横並びにする等、Web/CSS経験者には馴染みやすいでしょう。

スタイル調整もホットリロードが利くため、パラメータを変えては即座に見た目を確認する、といった試行錯誤が容易です。特にアプリUIの微調整は実機で確認しながら進めるのが効率的で、Valdiならではの開発フローと言えます。ちなみに、色指定は「black」のようなキーワードの他、#RRGGBB形式やrgba()関数もサポートされています。単位指定の必要な値（例えばpaddingの値はdp/ポイントとして解釈）は数値で指定します。基本的にReact Nativeのスタイル仕様と近いため、React Nativeから移行する人も習得しやすいでしょう。

最後に、Valdiにはスタイル指定方法として「StyleSheetオブジェクトを使う」という概念はありません。すべてタグ属性ベースで完結します。スタイルの共通化をしたい場合はコンポーネント化して再利用するか、またはJavaScript/TypeScriptの変数でスタイルオブジェクトを作り展開するやり方になります。CSSやRNに慣れた人は最初少し戸惑うかもしれませんが、いくつか画面を実装してみればすぐに慣れるでしょう。

TypeScriptで記述するネイティブUIの基本構文：宣言的TSX記法とコンポーネント実装の例

このセクションでは、Valdiの基本的なコーディングパターンや構文について整理します。TypeScriptでネイティブUIを記述するにあたり、どのようなクラス構造・文法でコンポーネントを定義するのか、イベント処理や状態管理はどう行うのか、といった点を一つずつ見ていきます。前節のチュートリアルで触れた内容を踏まえ、より一般化した形で理解を深めましょう。

Valdiのコンポーネントクラス構造：Componentクラスを継承して画面部品を定義

ValdiでUI部品（画面）を作る際は、基本的にComponentクラスを継承したサブクラスを定義します。ReactにおけるComponentクラスや、FlutterにおけるWidgetクラスに相当する概念です。例えば前述のHelloWorldクラスもComponentのサブクラスでした。ValdiのComponentクラスはフレームワークの核心で、画面上に描画可能な要素は全てこのコンポーネントとして表現されます。

Valdiのコンポーネントクラスには、主に以下のようなライフサイクルメソッドやプロパティが用意されています。

• onRender(): コンポーネントが描画される際に呼ばれるメソッド。ここでJSXライク構文を記述してUIを定義。
• onMount(): コンポーネントが画面にマウントされた後に呼ばれる（※存在すれば）。初期化処理などに利用。
• onUnmount(): コンポーネントが画面から取り除かれる直前に呼ばれる（※存在すれば）。後処理に利用。
• state: コンポーネントの状態を保持するオブジェクト（独自実装か、Reactのようなフックではない）※詳細後述。
• props: 親コンポーネントから渡されるデータ。ValdiのComponentもpropsの概念を持つ。

Valdiでは基本的に画面単位・大きなUI塊ごとにコンポーネントを作成し、それらをネストしていくことでアプリ全体のUIツリーを構築します。Componentを継承するクラスにはexportを付けてモジュール化し、他からインポートして使い回せます。Reactの関数コンポーネントのような軽量な定義方法は用意されておらず、全てクラスとして定義するスタイルとなっています。

onRenderとJSXライクな記法：XMLライクなタグ構文でUI階層を組み立てる宣言的アプローチ

ValdiのUI定義は、何度も述べているようにJSXに似たタグ構文を用いた宣言的アプローチです。onRenderメソッド内で<view>...のように書くと、コンポーネントの子要素としてそのビューが配置されます。onRenderはコンポーネントごとに定義され、そのコンポーネント直下のUI構造を宣言する役割を持ちます。

例えば親コンポーネントAのonRender内で<ChildComponent>（カスタムコンポーネント）をタグとして書けば、ChildComponentのonRenderが実行されて子UIが組み立てられる、といった仕組みです。これはReactにおいてJSX内で別コンポーネントを使うのと同じ感覚ですが、Valdiでは前述の通り戻り値ではなくその場でUI構築が行われます。開発者は違いを意識せずともReactのようにUIを宣言できる点がメリットです。

ValdiのJSX構文では、self-closingタグ（<label ... />のような閉じタグ省略）や{...}での式埋め込みも可能です。例えば、変数messageを表示したい場合、<label value={message} />のように書けます。ただしReactのように{children}をタグの間に書く（例：<view>Helloとテキストを直接書く）ことはできず、テキストを表示するには<label value="Hello">を使う必要があります。

この宣言的UIアプローチにより、コードは見通し良く構造化され、人間にとって理解しやすくなります。またValdi内部で最適な形にコンパイルされるため、パフォーマンス上も無駄がありません。UIツリーが大きくなっても宣言的に分割して書けるため、可読性と保守性に優れたUIコードが実現できます。

プロパティとスタイル指定：TypeScriptの型安全性でUI属性を定義しレイアウトを調整

Valdiコンポーネントの各タグには、先述のように様々なプロパティ（属性）を設定できます。これらはTypeScriptの型情報として定義されているため、存在しないプロパティ名や誤った値の型を指定するとコンパイルエラーとなります。例えば<label>に誤ってbackgroundColour（タイポ）を指定しようとすればエラーで気付けますし、padding="large"のように型不整合な値を入れた場合も検知できます。TypeScriptの恩恵で、UIスタイル設定も安全に行える点は安心感があります。

プロパティ例として、レイアウト系ではwidth, height, padding, margin, flex, alignItems, justifyContentなど、表示系ではbackgroundColor, color, fontSize, src（画像ソース用）などが用意されています。これらはValdiのAPIリファレンスに掲載されていますが、React Native経験者ならかなりの部分が想像で使えるほど似通っています。

スタイル指定には数値・文字列・論理値などが使われ、TypeScriptで型定義されているので、例えばalignItemsには"center"など特定の文字列しか受け付けない、といった制約も効いてきます。エディタの補完で有効な値がサジェストされるため、ドキュメントを逐一調べなくても開発を進めやすいでしょう。

Valdiではレイアウト調整も基本的にはこのプロパティ指定で行います。React Native同様、Flexboxベースでレイアウトを組むことになるので、画面全体の配置を決める際は<view style={{...}}>のようなスタイルオブジェクトを使ず、ダイレクトにflexDirection等をタグ属性で記述します。スタイルの定義方法は異なりますが、「何を指定すれば何が起こるか」というルール自体はネイティブUIやCSSと一致する部分が多いため、レイアウト経験がそのまま活かせます。

イベント処理とコールバック：ユーザー操作をTypeScript側でハンドリングするための仕組み

アプリ開発ではユーザーのタップやスワイプなどイベント処理が不可欠です。Valdiでも、ボタン押下やリスト項目選択などに応答してコードを実行する仕組みが用意されています。基本的な考え方は、イベントリスナー（ハンドラ関数）をプロパティとして渡す方式です。

例えば、React Nativeで<Button onPress={...} />のように書くのと同様に、Valdiでも<button onPress={this.handlePress} value="Click me" />といった記述ができます（Valdiにもbuttonコンポーネントがあります）。ここでhandlePressはthis.handlePress = () => { ... }のように定義した関数を指します。onPressイベントが発火すると、その関数が呼び出されるわけです。

他にもonChangeText（テキスト入力変化）、onScroll（スクロール時）、onSwipeやonPinch（ジェスチャー関連）など、多彩なイベントがサポートされています。Valdiではこれらイベントも型定義されており、渡される引数（例えばonPressには(event: PressEvent) => voidのような型）が明確なので、コールバック関数内でevent.と書けばプロパティやメソッドが補完されます。

Valdiにおけるイベント処理は、React Nativeとほぼ同じ発想で問題ありません。違いがあるとすれば、ReactのようなSyntheticEvent（合成イベント）ではなく、よりネイティブに近いイベントオブジェクトが渡される点くらいです。しかし抽象度は高く、例えばonPressのコールバックではイベントオブジェクトを受け取らず単に関数が呼ばれるだけ、といった簡略化も行われています。詳細な情報が必要な場合はジェスチャーやタッチ系のイベントを使うことで取得可能です。

用意されたネイティブUI要素：<view>・<label>・<button>など組み込みコンポーネント

Valdiには多くの組み込みUIコンポーネント（タグ）が用意されています。その主要なものを挙げると：

• <view>：汎用コンテナビュー。スタイルレイアウトの基本。
• <label>：テキスト表示用ラベル。valueプロパティで文字列指定。
• <button>：ボタン。valueプロパティでボタン上のテキスト、onPressで押下ハンドラ。
• <image>：画像表示。srcプロパティで画像パスやURLを指定。
• ：単一行のテキスト入力フィールド。placeholderやonChangeText等。
• <scrollView>：スクロール可能領域。中に大量の子Viewを入れてもスクロール表示。
• <listView>：リスト表示。効率的なアイテムレンダリングと再利用が可能。
• <switch>：オンオフのスイッチトグル。
• <slider>：数値範囲のスライダーUI。
• <modal>：モーダル表示のコンテナ（ダイアログ的な使用）。

これらはほんの一部ですが、要するにモバイルアプリで一般的なUIパーツは一通り揃っています。React NativeでいうView/Text/Button/Image等に相当します。それらの属性もReact NativeやWebに近い形で統一されており、例えば<image>でresizeModeを指定できたり、<textField>でsecureTextEntry（パスワード入力）を指定できるなど、直感的に使えるでしょう。

Valdiは内部的にiOS/Android/macOS各プラットフォームのネイティブUIコンポーネントを使っているため、これら組み込みタグはそれぞれ対応するネイティブ要素にマッピングされています。例えば<label>はiOSならUILabel、AndroidならTextViewに対応するようになっています。ですから見た目の挙動も各OSの標準そのままで、不自然さがありません。これもValdiのウリの一つで、ネイティブUIを使うからこその高品質な見た目と操作感が得られます。

コンポーネントのネストと再利用：ビューを入れ子にしてモジュール化し部品を効率的に再利用

ValdiでUIを構築する際は、コンポーネントを適切にネスト・分割して再利用性を高めることが重要です。Reactでのコンポーネント分割と同じ発想で、Valdiでも複雑な画面は小さなコンポーネントに分けていくと管理しやすくなります。

例えば、共通のヘッダーやフッターを表示したい場合、HeaderComponentやFooterComponentを作って各画面のonRender内でそれらをタグとして使い回せます。同様に、カスタムのボタンデザインが必要ならCustomButtonコンポーネントを作り内部で<button>と<label>を組み合わせて装飾する、といったこともできます。そのCustomButtonを他のコンポーネントに組み込めば統一したスタイルのボタンをアプリ全体に適用できます。

Valdiではこのコンポーネント再利用が効率的に行えるよう、前述のView Recyclingなども働いています。例えば同じカスタムコンポーネントが複数画面で使われる場合も、一度生成された内部ビューを共有できるケースもあるでしょう。また、親子コンポーネント間でデータを受け渡すprops機構も備わっているため、親から子へ属性値を渡して汎用コンポーネントを作ることも可能です（<CustomButton text="OK" onPress={...} />のように）。

こうしたモジュール化により、大規模なUIでも効率的に構築・保守できます。ValdiはReactライクなコンポーネントモデルを採用しているため、チーム開発でコンポーネント単位に担当を分けたり、デザインシステムに沿ったUI部品集を作ったりするのにも向いています。再利用を前提にコンポーネントを切り出す設計を心がけることで、Valdiのメリットを最大限に活かした開発ができるでしょう。

パフォーマンスとアーキテクチャ設計のポイント：高速化の仕組みと最適な実装手法

このセクションでは、Valdiを用いた開発で意識すべきパフォーマンス上のポイントやアーキテクチャ設計上の指針について解説します。Valdi自体が高性能を目指して設計されていますが、それを活かすも殺すも開発者次第の部分があります。内部の最適化を理解した上でアプリ実装を工夫すれば、よりスムーズで洗練されたアプリを作れるでしょう。

グローバルViewプール戦略：画面間でビューを使い回して生成コストとメモリ使用を削減

ValdiのView Recycling（ビュー再利用）については既に説明しましたが、開発者側でもこれを念頭に置いた設計をすると効果的です。具体的には、画面遷移時にあえてビューを完全破棄せず次に活かす前提で構築するようなケースです。例えば、タブ切り替え型のアプリにおいて各タブ画面をValdiコンポーネントとして実装する場合、Valdiの仕組みにより裏画面のビューはプールされます。そこで、タブに戻った際になるべく状態を維持できるよう、コンポーネントのonMount/onUnmountで必要なデータの永続化やUI更新を工夫すると良いでしょう。

また、長大なリスト表示を実装する場合も、Valdiの無限スクロール最適化を信頼して必要以上の先読みやプリフェッチを行わない設計が望ましいです。Valdiは表示中の要素だけビューを持つため、例えば「全項目をまとめて描画してから隠す」ような実装は逆効果になります。React NativeではFlatListなどにwindowSizeやinitialNumToRenderを調整するケースがありますが、Valdiではデフォルト挙動が最適化されているため、基本的には任せておけばOKです。

UI部品の再利用方針としては、Valdiが自動再利用する部分以外にも、たとえばカスタムコンポーネントをシングルトン的に使い回すような設計も考えられます。ただし、あまりに状態を共有しすぎると別画面間で予期せぬ副作用が出る恐れがあるため、原則はValdiの仕組みに沿ってコンポーネントごとに状態を完結させ、再表示時に必要に応じて復元する程度が良いでしょう。

親子間の独立レンダリング：子コンポーネントのみ再描画する差分更新で無駄を排除

Valdiはコンポーネントのレンダリングにおいて、親子間の再描画を独立させられるようになっています。つまり、ある子コンポーネントの状態が変わって再レンダリングが必要になっても、親コンポーネントには波及せず、その子だけを更新することが可能です。Reactでは親が再レンダリングすると子も再レンダリングしがちですが、Valdiでは親子を分離した差分更新を効率よく行える設計です。

これを活かすため、状態を持つコンポーネントはできるだけ小さく分割し、親には不必要な再描画をさせないようにしましょう。例えばリスト項目コンポーネントが独自に内部状態（「いいね」済みかどうか等）を持つ場合、各項目を独立コンポーネントにしておけば、ある項目が変わっても他の項目やリスト全体には影響を与えません。Valdiは内部的にコンポーネント単位で変更検知と更新を行っているようなので、開発者がそれに沿う形で設計すると無駄な処理が発生せず済みます。

また、状態リフレッシュのタイミングも必要最小限に抑えることが重要です。ValdiにはReactのようなsetStateはありませんが、コンポーネントのプロパティやフィールドを直接書き換えてthis.invalidate()のようなメソッドで再描画要求を出す仕組みがあると想定されます（※正確なAPIはドキュメント要確認）。その際も、本当に変化したときだけ再描画をトリガーするようロジックを工夫し、頻繁な無意味な再描画を避けましょう。Valdiのアーキテクチャは効率的ですが、乱用するとパフォーマンス低下に繋がるのは他フレームワークと同じです。

マルチスレッド活用：Worker Threadsで重い処理をオフロードしてUIスレッドを保護

ValdiはUIスレッド（メインスレッド）をブロックしないよう、ワーカースレッドでの処理実行もサポートしています。例えば大きなデータのパースやネットワークIO、AI推論など時間のかかる処理は、Valdiのワーカー機能を使ってバックグラウンドで実行し、終わったらUIに結果を反映するという流れが推奨されます。

JavaScript環境でいうWeb Workerのような仕組みが用意されているとのことで、開発者は専用のワーカースレッド用コードをTSで書けるようです。React NativeでもInteractionManagerや別途JSスレッドを起こす方法がありますが、Valdiではこれがフレームワークレベルで用意され、しかもTypeScriptでマルチスレッド処理を書けるとのこと。重い計算を行う際はぜひこの仕組みを使ってUI応答を妨げない設計にしましょう。

例えばチャットアプリで大量メッセージの全文検索をする場合、ワーカースレッドで検索しつつ、UI側では「検索中…」とインジケータを表示しておくといったことが容易に実現できます。処理完了をワーカーからUIスレッドに通知する方法も、Valdiの型安全なメッセージング機構が使えるはずです。C++モジュール側で別スレッドを起こすこともできますが、TypeScriptだけで並列処理を扱える点はアプリ設計上大きな自由度となります。

プロトコルバッファ対応：高速なデータシリアライズでデータ通信や状態管理を効率化

Valdiは内部でprotobuf（Protocol Buffers）に対応しており、TypeScriptとネイティブ間のデータシリアライズに利用できます。大きなデータ構造を頻繁にやり取りする場合、protobufを用いることで高速かつ堅牢な通信が可能です。React NativeではJSONシリアライズを介してJSとネイティブがデータ交換しますが、Valdiではコンパイル時に型定義を基にprotobufコードを生成することで、効率的なシリアライズ/デシリアライズ処理を自動化できます。

実際のアプリ設計でも、例えばローカルデータベースとのやり取りや、ネイティブモジュールから大量のセンサーデータを取得するような場面では、protobufを活用すると良いでしょう。ValdiのPolyglot ModulesでC++やSwift側と連携する際も、protobuf形式でデータをやり取りすれば変換の無駄がありません。TypeScript側でもprotobufメッセージの型が定義されるため、IDEの補完も効いて開発しやすいです。

プロトコルバッファはGoogle製の汎用バイナリフォーマットで、言語間でのデータ共有に強みを持ちます。Valdiが公式にこれをサポートしているのは、Snapchat内部で効率的にデータ交換する必要があったからでしょう。リアルタイム性が要求される機能（例えばSnapchatのフィルター処理やゲーム機能）でもデータ遅延が少なくなるよう工夫されています。開発者としては、Valdi提供のこの仕組みを使うことで高度なパフォーマンスチューニングをあまり意識せずに恩恵を受けられるため、必要なときに活用してみてください。

ネイティブ機能の直接利用：カメラやセンサーなどプラットフォームAPIにTypeScriptからアクセス

Valdiアプリでネイティブの機能（カメラやGPS、センサー類、ファイルストレージ等）を使いたい場合、Polyglot Modulesを介さずとも、Valdiが提供するネイティブAPIアクセス機能を利用できます。具体的には、TypeScript側からSwift/KotlinのAPIを直接呼び出すためのバインディングが自動生成される仕組みです。Valdiプロジェクト内で「このネイティブクラスを使いたい」という宣言をすると、TSからそのまま呼べるようになります。

例えば、iOSのUIImagePickerController（画像ピッカー）を使って写真を選ばせたい場合、ValdiのネイティブAPIアクセスを設定すれば、UIImagePickerControllerのメソッドをTSから操作できます。結果の写真データも型安全にTSへ渡ってきます。Androidでも同様に、CameraXやSensorManagerといったクラスを利用可能にできます。このように、Valdiはネイティブコードに対しても高い親和性を持ち、必要ならば従来のネイティブ知識を直接活かせる作りになっています。

もっとも、これらを1から手動でセットアップするのはやや高度な作業になるため、一般的なニーズ（カメラ、位置情報など）は将来的に公式かコミュニティのサポートライブラリが提供される可能性があります。現時点では自身でブリッジコードを生成する必要がある場面もありますが、そのためのドキュメントやツールもValdiには用意されています。React Nativeでネイティブモジュールを作るのと原理は似ているので、ネイティブ開発経験者なら難しくはないでしょう。重要なのは、Valdiでは「何でもTypeScriptだけで閉じないで、必要ならネイティブの力を借りる」という選択肢が常にあることです。

Valdiアプリの軽量化：ネイティブコード生成によるフットプリント削減とパフォーマンス向上

最後に、アプリ全体のアーキテクチャ設計として留意すべき点として、Valdiアプリのフットプリント（サイズ・消費リソース）について触れます。ValdiはFlutterのように重厚なランタイムエンジンを含まず、React NativeのようなJS VMも持たないため、比較的アプリサイズは小さく済みます。とはいえ、使い方によってはバイナリが大きくなったり、メモリ消費が増える可能性もあります。

例えば、TypeScriptコードが増えればそれだけネイティブコード生成量も増え、アプリサイズが膨らむでしょう。特に多言語対応や大きな定数データを抱える場合は、そのデータをどう管理するかも検討が必要です。ValdiはBazel統合もサポートしており、再現性の高いビルドや不要コードの除去にも配慮されています。大規模プロジェクトではBazelによるモジュール分割や依存の明確化を図ることで、アプリの肥大化を防ぎつつ効率的な開発が可能になります。

また、パフォーマンス向上のためには不要な処理を避けるコーディングが大事です。Valdiの自動最適化に頼りつつも、例えばタイマーで頻繁にUI更新しない、画像は適切なサイズのものを使う、ネットワーク通信は圧縮する等、基本的なベストプラクティスは従来と同じです。Valdi独自の注意点としては、TS→ネイティブの境界を跨ぐ処理（Polyglot Modules呼び出しなど）は乱発しない方が良いでしょう。ただしValdiはその辺りもかなり効率化しているので、よほどの高頻度でなければ問題にならないと考えられます。

全体として、Valdiアプリは構造上かなり軽量に動作するよう設計されていますが、それを最大限活かすにはアプリ側の設計・実装も練られている必要があります。適材適所でValdiの機能（ビュー再利用、ワーカー、ネイティブ連携など）を活かし、ボトルネックを作らない構成を心がけましょう。そうすれば、Snapchatにも匹敵するリッチでありながら高速なアプリケーションを構築できるはずです。

既存のReact NativeやFlutterからの移行を検討する際の比較観点と注意点

ここでは、現在React NativeやFlutterで開発を行っている場合に、Valdiへ移行すべきかどうかを検討する際のポイントをまとめます。両者にはアーキテクチャやエコシステムに違いがあるため、安易に乗り換えると想定外の苦労があるかもしれません。逆にValdiの方が適しているケースもあるでしょう。その判断材料として、UIの仕組みや言語、パフォーマンス、ライブラリ、開発組織への影響などを比較してみます。

UIレンダリング方式の違い：React NativeのJSブリッジ/FlutterのSkiaエンジン vs Valdiのネイティブビュー方式

まずUIレンダリング方式の違いです。React NativeはJavaScriptが仮想DOMを計算しネイティブUIを橋渡しする方式、FlutterはSkiaレンダリングエンジンで独自にUIを描画する方式でした。Valdiはそれらとは異なり「ネイティブビューを直接利用する方式」です。これは性能面ではネイティブそのものの強みが出る一方、カスタマイズ性やプラットフォーム間での一貫性は各OSの仕様に依存します。

例えば、FlutterではiOS/Androidで全く同じUIを再現できますが、Valdiは各OSのUIコンポーネントを使うため微妙なプラットフォーム差異（フォントレンダリングやスクロール挙動など）が生じる可能性があります。ただ、それこそが「ネイティブらしさ」でもあるため、ユーザー体験的には自然です。React NativeはネイティブUIを使う点でValdiと近いですが、間にJSブリッジがあるか無いかが大きな違いです。Valdiならではのダイレクトなレンダリングは、RNでは解消しにくかったラグを取り除く効果が期待できます。

移行時には、このレンダリング方式の違いによるUXの変化を考慮しましょう。RNからValdiに変えるとスクロールの感じやアニメーションの滑らかさが改善するかもしれませんが、一方でカスタム描画していた部分（例えばCanvasやOpenGLを使った特殊UI）はValdi用に作り直す必要があるかもしれません。Flutterから移行する場合も、Skiaで凝ったUIを作っていたなら同等の表現を実現するためにネイティブのDrawing APIやサードパーティライブラリを模索する必要が出てくるでしょう。

開発フローと言語の相違：JavaScript+JSX（またはDart）からTypeScript+TSXへの移行ハードル

React Native開発者にとってValdi移行の言語的ハードルは低いです。普段からTypeScriptでRNを書いている人なら、ほぼ同じ感覚でValdiを書けます。JSX記法も類似しており、クラスベースではありますがReactのClass Componentに近いノリで学習できます。Dart/Flutterからの移行だと言語が変わりますが、DartもJava/C#に近いシンタックスのためTSへの移行はそこまで難しくないでしょう。ただ、Flutter独特のWidgetツリー構築パターン（ビルダーとかInheritedWidget等）に慣れていると、ValdiのシンプルなComponentモデルはかえって分かりやすいかもしれません。

開発フローとしては、RN/FlutterからValdiに移るとビルド＆デプロイの待ち時間が減ります。React NativeもMetroバンドラーでのホットリロードがありますが、Valdiの方がよりネイティブ寄りでありながら高速反映される点で快適に感じるでしょう。Flutterもホットリロードが高速ですが、状態保持が難しかったりエミュレータが重くなったりといったことがあります。Valdiは各プラットフォームのネイティブデバッグツールも使えるため、デバッグしやすさでも利点があります。

一方で、Valdiのドキュメントや学習リソースがまだ少ないため、移行初期はチーム内で試行錯誤が必要です。RN/FlutterではStackOverflowやQiita記事で大抵の疑問が解決しましたが、Valdiでは英語公式フォーラムやDiscordで直接質問する場面も出てくるでしょう。移行の際はある程度リソースを割いて、PoC（概念実証）やトレーニングを行うことをおすすめします。

パフォーマンスと挙動の差異：スクロールやアニメーションの滑らかさなどネイティブUIならではの強み

パフォーマンス面の差異は先述した通り、Valdiの方が基本的に有利です。特にスクロールの滑らかさや、ページ遷移時の標準アニメーションなど、システムUIが関わる部分はValdiが自然かつ高速です。React Nativeでもだいぶ改善されてきましたが、複雑なネストや大量要素ではどうしてもフレーム落ちするケースがありました。Valdiではそうしたケースを潰す工夫が多く入っているため、同じ画面を実装して比較すれば差が出るかもしれません。

一方、カスタムアニメーションについては注意が必要です。Flutterは60fpsの滑らかな独自アニメーションが得意ですが、ValdiではネイティブUIのアニメーション（iOSのUIView.animateやAndroidのPropertyAnimator等）に頼ることになります。単純なフェードや移動アニメーションは問題ないですが、複雑な独自描画アニメーションはFlutterほど簡単には実装できない可能性があります。Snapchatのような高度なUIをValdiでどう実現しているか興味深いところですが、その辺りはC++モジュール等でカバーしているのかもしれません。

ジェスチャーやタッチ挙動も、Valdiはネイティブそのままなので違和感ありません。Flutterは独自実装ゆえに一部プラットフォームらしさが損なわれることがありましたが、ValdiならiOSはiOSらしく、AndroidはAndroidらしいフィーリングです。React Nativeも同様にネイティブ挙動ですが、Valdiではさらに微細なラグが少ないと期待できます。UX観点で、現在のアプリにパフォーマンス不満があるならValdi移行は魅力的ですが、逆にFlutterの表現力に依存したUIで売っているアプリの場合、同等再現にコストがかかる点に留意が必要です。

ネイティブモジュールの取り扱い：既存プラグイン資産の活用可否とValdiでの代替手段

React NativeやFlutterで構築したアプリには、多くの場合サードパーティのプラグイン/ライブラリを利用しています。例えば地図表示、プッシュ通知、決済連携などさまざまです。移行を検討する際には、既存のプラグイン資産をValdiで活かせるかが重要なポイントになります。

現状Valdi専用に用意されたプラグインは少ないため、多くは自分で実装し直すか、ネイティブのSDKをPolyglot Module経由で使うことになります。例えばReact Nativeでreact-native-mapsを使っていたなら、ValdiではiOSのMapKitとAndroidのGoogle Maps SDKを直接使うことになるでしょう。Flutterでfirebaseプラグインを使っていたなら、Valdiでは各OSのFirebase SDKを導入しTSから呼ぶ必要があります。

このようにプラグイン資産の再利用は基本的に効きません。ただし、Valdiの強みはネイティブAPIへ直接アクセスできることなので、RNやFlutterでプラグインを介していた部分をダイレクトに実装できるという見方もできます。既存プラグインの内部実装を参考にしつつ、自分たちでValdi用モジュールを整備するフェーズが最初に必要でしょう。それだけの手間をかけてもValdiの利点（性能や統合度）が欲しいかどうかが判断基準となります。

企業やプロジェクト規模によっては、この作業コストが許容できるか否かで移行の成否が分かれます。もし依存プラグインが多岐に渡るなら、移行のメリットと比較して冷静に検討しましょう。一方で、Snap社自身もSnapchatに数多くのSDK連携を抱えていたはずで、それをValdi上で解決してきた実績があります。コミュニティ発展とともに主要なプラグインは揃っていく可能性もありますから、早期に移行すれば逆にその開拓者になれるという見方もあります。

コード移行の難易度：既存プロジェクトの再利用範囲と段階的移行のアプローチ

実際に移行すると決めた場合、既存コードのどの程度を再利用できるかも気になるところです。React NativeのTypeScriptコードについては、UI定義部分はValdi用に書き換える必要があります。しかしビジネスロジック部分（API通信や計算処理など）は多くが再利用可能でしょう。ValdiでもNode.js標準APIやサードパーティの純粋TSライブラリは使用できるため、RNで利用していたロジック系ライブラリやユーティリティ関数群はそのまま生かせる場合があります。

Flutterからの移行では、Dart言語コードの直接再利用はできません。ただアルゴリズムやアプリの構造そのものは踏襲できるため、翻訳作業に近いものになります。UI構築もFlutterのWidgetツリーをValdiコンポーネントツリーに置き換える形で書き直す必要があります。UIに関しては、レイアウトの考え方がFlexbox中心という違いがあるので、Figma等のデザインを元に再度実装するくらいの気持ちの方が良いでしょう。

段階的移行という手段も考えられます。Valdiは既存ネイティブへの組み込みが可能なので、例えば現在のアプリの一部画面だけValdiで作り直し、ネイティブコンテナに差し込むこともできます。React Native製アプリの場合、ネイティブ部分が薄いのでそのまま共存は難しいですが、一度ネイティブに戻してValdiを組み込む手もあります。Flutterからは共存が難しいため、段階的というより別アプリとして一からリプレイスする形になりやすいです。

総じて、移行難易度はReact Native→Valdiの方が低く、Flutter→Valdiの方が高いでしょう。特にコード資産の活用という点で、TS資産を持っているかどうかがカギです。また、どちらからの移行でもUI周りは作り直しが必要なケースが多いと覚悟しましょう。移行に踏み切る前に、小規模でValdi版UIを試作し、チームで比較検証することを強く推奨します。

開発体制とコミュニティ：人材のスキルセットや利用できる情報・ライブラリの成熟度の違い

最後に、移行がチームや組織に与える影響です。React NativeやFlutterは既に広く普及しており、開発者も多く存在します。Valdiは新興のため、人材プールが限られます。現在RN/Flutterエンジニアがいるチームなら多少のトレーニングでValdiに順応できると思われますが、採用市場から即戦力を得るのは難しいかもしれません。よって、既存メンバーのスキルアップ前提で計画する必要があります。

コミュニティから得られる情報量も現時点ではRN/Flutterに軍配が上がります。困ったときに検索して解決策が見つかる可能性はRN/Flutterの方が高いでしょう。Valdiでは公式DiscordやGitHub Issueが主な情報源になるため、英語で自ら質問・調査する積極性が求められる場面もありそうです。企業としてサポート契約があるわけでもないので、困ったときのリスクヘッジは考えておきましょう。

一方、Snap社自体がValdiを推進しているため、公式からの情報発信やサンプル公開も期待できます。React Nativeも初期はFacebook直々に情報提供がありましたし、Flutterも公式ドキュメントが充実していきました。Valdiも今後数年でコミュニティが育ち、情報量の問題は緩和する可能性があります。移行時期を急がず、もう少しエコシステムが整うのを待つという選択も十分ありえます。

組織的には、「尖った技術を採用している」というアピールができるメリットもあります。Snapchatと同じ技術基盤で開発しているというのは技術者受けするかもしれません。ただ、それを活かせるのは開発力に余裕がありチャレンジングな案件の場合でしょう。保守性重視や確実性重視のプロジェクトでは、コミュニティ成熟度が高い技術を使う安心感も捨てがたいものです。総合的に判断して、Valdi移行が自社プロジェクトにとってプラスになるかを見極めることが大切です。

今後のロードマップとValdiの活用シーン：採用事例やユースケースから見る可能性

最後に、Valdiの今後の展望や想定される活用シーンについて述べます。まだ公開されたばかりのValdiですが、Snap社の発表やコミュニティの動向から、将来的にどう発展していくか、そしてどのような分野で活用が期待できるかを考察します。

公式ロードマップ：Valdi開発チームが示す今後の予定と機能拡充の展望

Snap社はValdiを「Beta」として公開した際に、今後の計画についてもいくつか示唆しています。主なトピックとしては、開発者体験のさらなる改善（ドキュメント充実、ツールの安定化）と、対応プラットフォームや機能の拡充があります。具体的なロードマップは記事公開時点で限定的ですが、コミュニティで頻出する要望に応える形でアップデートが続くでしょう。

例えば、Windowsプラットフォーム対応やWeb対応の検討が今後行われる可能性があります。Snap社自身は現状必要としていないかもしれませんが、コミュニティの声が大きければオープンソースプロジェクトとして広げていく可能性は否定できません。また、UIコンポーネントの充実（たとえば地図コンポーネントや動画プレーヤーの公式提供）、パフォーマンスチューニング機能（FPSメーターやメモリトラッキングツールの提供）なども開発者が望む所でしょう。

Snap社のカンファレンスやブログなどでValdi関連のアップデート情報が発信されるはずなので、利用者はそれを追いながら計画を立てる必要があります。Betaを脱し正式版1.0となるタイミングがいつ頃かも注目です。おそらく2026年中には安定版リリースを目指しているのではないかと予想されます。ロードマップ上のマイルストーンとしては、「ドキュメント整備完了」「主要OSSライブラリとの統合」「Snapchat以外での事例紹介」などが挙げられるでしょう。Snap社の動向次第でValdiの将来像も変わってきます。

オープンソースコミュニティの展開：外部開発者の参加促進とプラットフォーム拡大の可能性

Valdiの成否はオープンソースコミュニティの盛り上がりにかかっています。Snap社はすでに公式Discordやフォーラムを開設し、外部開発者との交流を始めています。今後はGitHub上でのコントリビューションも増えていくでしょう。例えばバグ修正のPull Requestがマージされたり、新機能提案が受け入れられたりといった、コミュニティ駆動の改善が期待されます。

そうした動きが活発になれば、Valdiの発展スピードも加速します。例えばReact Nativeも初期は社内主導でしたが、今やMicrosoftやExpoなど多くの企業が貢献して支えています。Valdiもモバイル開発に関心の高い企業（例えばTwitterやPinterestなどUIの高速化を追求する企業）が興味を示せば、コントリビューションしてくるかもしれません。あるいは個人開発者が便利ツールやプラグインを作って公開する動きも出てくるでしょう。

Snap社自体がそこまでオープンソースコミュニティ運営の経験が豊富ではない印象もありますが、React NativeやFlutterの例を参考に進めていくでしょう。開発者にとっては、公式Issueでの意見交換や、ベータテスター的に新機能を試す機会なども増えます。コミュニティが成熟すれば、Valdiを採用することへの心理的障壁も下がり、導入事例がさらに増える好循環が生まれるでしょう。

想定ユースケース：高パフォーマンスが求められるAR/VR・ゲーム・動画配信アプリへの応用

Valdiの特徴を活かせるユースケースとして、まず思い浮かぶのはSnapchatの本丸であるAR/VR分野です。ARフィルターやリアルタイム映像処理など、重たい処理を伴うアプリではValdiのパフォーマンスが頼りになります。例えばスマホ向けのARナビゲーションアプリや、VRゴーグルのコンパニオンアプリなどでもValdiは有用かもしれません。

次にゲーム分野も考えられます。高度な3D描画は専門エンジンに譲るとしても、例えばカードゲームやパズルゲーム程度であればValdiでUIを構築してネイティブ機能でサウンドや振動を制御する、といったアプリは作れるでしょう。2Dゲームであれば60fpsのアニメーションもネイティブUI＋Valdiで実現可能です。ただ、UnityやUnrealなど既存ゲームエンジンとの住み分けは必要で、Valdiはゲームライブラリではないのでゲーム全般に万能というわけではありません。

動画配信・ライブ配信アプリもValdiの高性能を活かせる領域です。複雑なコメント表示やエフェクト、マルチウィンドウ表示などを行ってもネイティブUIなら耐えられる可能性があります。ライブ配信中のリアルタイム更新やアニメーションなどはRNでは厳しい部分もありますが、Valdiならよりスムーズに処理できるでしょう。Snapchatがまさにそれに近いので実証済みと言えます。

その他、社内業務向けのアプリでもValdi採用は考えられます。特に現場で使う軽快な専用ツール（例えば倉庫管理スキャナアプリなど）では、動作速度と開発効率の両立が求められます。ValdiはUIリッチなConsumer向けだけでなく、そうしたIndustrialなユースケースにもマッチするでしょう。要は「ネイティブ品質を保ちたいが開発効率も欲しい」という案件全般がValdiの活躍シーンになると考えられます。

企業での採用事例：Snapchat以外のプロダクトでの導入は進むか？初期の利用例を検証

2025年末時点では、まだ目立ったValdi採用事例は報告されていません。Snapchat本体が最大の実例ですが、それ以外の企業やプロジェクトで試験採用され始めているとの噂もあります。例えば、あるスタートアップがReact NativeからValdiに乗り換えてパフォーマンス改善を狙っているとか、個人開発者が趣味アプリでValdiを試している等の話がSNSで散見されます。

今後6ヶ月〜1年の間に、いくつか具体的な事例が出てくるでしょう。特にモバイルSNSや動画系アプリで競争力を高めたい企業は、Snapchatが使っている技術ということでValdiに興味を示すかもしれません。また、React Nativeアプリを運用しているがパフォーマンス課題に直面している企業なども、ValdiをPoC導入する可能性があります。

採用事例が増えてくれば、それ自体がValdiの信頼性向上につながります。Flutterも初期はGoogle製アプリ以外少なかったものの、BMWやAlibabaなど大手が採用を公表してから注目度が上がりました。Valdiも今後誰もが知るサービスで使われ始めれば、市場での評価が一変するでしょう。ただし現状は未知数な部分も多く、大企業ほど様子見するかもしれません。まずはスタートアップや個人開発の範囲で実績が出て、それを元に大規模案件へ広がっていく流れが予想されます。

他フレームワークとの共存戦略：用途に応じた使い分けとValdiがもたらす選択肢の拡大

Valdiが登場したことで、クロスプラットフォーム開発の選択肢が増えました。今後はReact Native/Flutter/Valdiをプロジェクトの性質に応じて使い分けるといった戦略も考えられます。例えば、UIリッチでパフォーマンス最優先のプロダクトにはValdi、Webとモバイル統一技術で開発したい場合はReact Native（あるいはExpo）、新規性の高いUI表現やマルチプラットフォーム統一UIを求めるならFlutter、といった具合です。

実際、企業によっては既にReact NativeとFlutterを案件によって使い分けたりしています。そこにValdiも加わることで、「こういう要求ならValdiがベストだ」と判断できる場面が出てくるでしょう。特にネイティブ性能がカギを握るアプリ（Snapchatのような）では、Valdiが第一候補になるかもしれません。逆にWebとの統合が重視される場合（PWAも提供したいなど）はValdiは選択肢から外れるでしょう。

重要なのは、Valdiが既存技術を完全に置き換えるものではなく、特定のニーズにフィットする新たな選択肢だということです。React NativeやFlutterにも依然として強みはあり、それぞれ進化を続けています。開発者としては各フレームワークの動向をウォッチし、適切な道具を選ぶ目を養う必要があります。Valdiがこの競争に加わったことで、モバイル開発者にとっては面白い時代になってきたと言えるでしょう。

クロスプラットフォーム開発への影響：Valdiが今後のモバイル開発にもたらすインパクト

最後に、Valdiが業界全体に与えるインパクトについてまとめます。Snapchatという巨大アプリの裏で動いていた技術がオープン化された意義は大きく、クロスプラットフォーム開発の常識をアップデートする可能性があります。これまで「開発効率ならクロスプラットフォーム、性能ならネイティブ」という妥協が語られてきましたが、Valdiはその妥協を不要にするアプローチを示しました。このコンセプトが広まれば、各社がクロスプラットフォーム戦略を見直すきっかけになるかもしれません。

また、Valdiの登場でReact NativeやFlutter側も刺激を受けるでしょう。競合が増えることで、互いに不足を補う形で進化が促されます。例えばReact Nativeは性能改善にさらに力を入れるかもしれませんし、FlutterはWeb以外の領域にフォーカスするかもしれません。最終的に開発者にとっては、どの選択肢を選んでも以前より良い結果が得られるという、嬉しい状況が訪れる可能性があります。

Snap社はValdiを戦略的プロジェクトとして投じてきましたが、今後も継続的に改良を重ねていくでしょう。仮にValdiが大成功しなくても、その思想や技術が他に影響を与え、クロスプラットフォーム開発全体が底上げされることになるでしょう。要注目のValdi、まずは触ってみて、その可能性を肌で感じてみるのも良いかもしれません。エンジニアとして新たなツールを試すことは、常に刺激と成長につながるものです。Valdiが描く未来に期待しつつ、自身のプロジェクトにどう活かすかをぜひ検討してみてください。