マルチプラットフォームとは？クロスプラットフォームとの違いと、1つのコードでも「同じにならない」もの【2026年版】

「提案書に『マルチプラットフォーム開発』と書いてあるが、これは結局どういう意味なのか」——アプリの発注を検討している方から、こうした問いをよく受けます。辞書サイトを引くと「複数のOSで動くこと」と一行だけ書いてある。開発会社に聞くと「1つのコードでiOSとAndroidの両方に出せます」と返ってくる。クロスプラットフォームという似た言葉も出てきて、どちらが正しいのかも分からない。カタカナ語が増えるほど、判断の材料は減っていくものです。

結論から言うと、マルチプラットフォームとは「1つのソフトウェアが複数のプラットフォーム(OS・実行環境)で動くこと」を指し、開発の文脈では「1つのソースコードから複数のOS向けの成果物を作る手法」という意味で使われます。クロスプラットフォームとはほぼ同義で、業界で統一された定義はありません。そして発注者にとって本当に重要なのは、語の定義ではありません。「1つのコードで両OSに出せる」ことと「両OSで同じアプリになる」ことは別だ、という一点です。

共通化できるのは実装の一部です。OS固有の画面の作法、権限を求めるダイアログ、プッシュ通知の仕組み、課金、ストアの審査対応は、どの手法を選んでも2つ分残ります。ここを見積もりに入れていない提案を承認してしまうと、開発の終盤で「この機能はこの方式では難しい」という話が出てきます。逆に、残る部分を最初から数えておけば、マルチプラットフォームは十分に合理的な選択になります。

本記事では、マルチプラットフォームの2つの用法とクロスプラットフォームとの使い分け、ネイティブ開発との違い(画面を誰が描くかで3つの型に分かれます)、代表的な手法5つの仕組みと対応プラットフォーム、1つのコードでも同じにならないもの、性能と保守のリスク、発注者としての決め方、よくある質問の順に解説します。手法の仕組み・対応プラットフォーム・サポート状況は、競合記事やまとめサイトではなく公式ドキュメントを直接確認し、確認日を明記しました。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。「マルチプラットフォームなら費用が半分になると言われた」という相談は今でも多く届きますが、半減の根拠を一次情報で示せた会社には、まだ出会っていません。この記事を読み終えるころには、提案書に書かれた方式が自社の案件に合っているか、どこを追加で確認すべきかが判断できるはずです。

マルチプラットフォームとは——1つのソフトウェアが複数のOSで動くこと。開発の文脈では「1つのソースコードから複数のOS向けに作る手法」

マルチプラットフォームという語は、実は2つの意味で使われています。1つは「そのソフトウェアが複数のプラットフォームに対応している」という状態を指す使い方。もう1つは「1つのソースコードから複数のOS向けの成果物を作る」という開発手法を指す使い方です。提案書でこの語を見たときに混乱が起きるのは、書き手がどちらの意味で使っているかを明示しないまま話が進むからです。まずはこの2つを分けて押さえてください。

2つの用法——「対応している状態」と「そう作る手法」

「プラットフォーム」とは、ソフトウェアが動く土台のことです。WindowsやmacOS、LinuxといったパソコンのOS、iOSやAndroidといったスマートフォンのOS、さらにWebブラウザやゲーム機も含みます。この土台が複数あるものに対応していれば「マルチプラットフォーム対応」と呼ばれます。

状態を指す用法では、作り方は問いません。iOS版をSwiftで、Android版をKotlinで別々に作ったアプリも、両方のOSで使えるのですから「マルチプラットフォーム対応」です。一方、手法を指す用法では、作り方こそが本質です。「1つのソースコードを書けば、iOS向けとAndroid向けの両方の成果物ができる」という開発のやり方を指します。

発注の場面で問題になるのは、ほぼ後者です。開発会社が「マルチプラットフォームで作ります」と言うとき、それは「コードを1つにまとめることで、工数を減らします」という提案だからです。見積書を読むときは、この提案がどこまでの範囲を1つにまとめるつもりなのかを確認してください。後述するとおり、1つにまとめられる範囲は手法によって違います。

クロスプラットフォームとの使い分け——ほぼ同義。ただし「状態」と「仕組み」で区別する説明もある

「マルチプラットフォーム」と「クロスプラットフォーム」の関係は、この分野で最もよく聞かれる質問です。結論を先に言うと、日本語のIT記事や開発会社の資料では、この2語はほぼ同義として扱われています。実際、検索上位の記事の多くがタイトルで「クロスプラットフォーム(マルチプラットフォーム)とは」のように併記しており、内容も区別していません。

一方で、次のように区別する説明もあります。

ただし、この区別が業界標準として確立しているわけではありません。国際規格や公的機関が定義した用語ではなく、説明の便宜上の整理です。そのため「厳密にはこちらが正しい」という議論に時間を使う価値はほとんどありません。

実務上の要点は1つだけです。提案書や見積書にこれらの語が出てきたら、「対応OSはどれとどれか」「1つのコードで共有する範囲はどこまでか」の2点を、言葉ではなく具体の内容で確認する。これで用語の揺れは無害になります。用語の定義を巡って社内で議論が長引くのは、判断を先送りするだけで失敗のもとです。

ゲーム業界での別用法——同じタイトルを複数のハードで出すこと

もう1つ、覚えておくと混乱を避けられる用法があります。ゲーム業界で「マルチプラットフォーム展開」と言うとき、それは「同じタイトルを、家庭用ゲーム機・パソコン・スマートフォンなど複数のハードで遊べるようにリリースすること」を指します。こちらは開発手法ではなく、販売戦略の話です。

検索結果にゲーム関連の記事が混ざるのはこのためです。ゲーム開発でも1つのコードから複数のハード向けに書き出す仕組みは使われますが、業務アプリや自社サービスのアプリを作る文脈とは、論点がかなり違います。本記事は後者、つまりiOSとAndroid(必要に応じてWebやデスクトップ)に自社のアプリを出す場合を扱います。

では、その「1つのソースコードから複数のOS向けに作る」は、具体的に何をしているのでしょうか。ネイティブ開発との違いを、画面の作り方から見ていきます。

ネイティブ開発との違い——「画面を誰が描くか」で3つの型に分かれる

マルチプラットフォームの手法は数多くありますが、仕組みの違いは「画面を誰が描くか」という一点に集約できます。OSが用意した画面部品をそのまま使うのか、フレームワークが自分で描くのか、それともブラウザに描かせるのか。ここが違うと、見た目の一致のしかた、性能の傾向、OSの更新への追従のしかたがすべて変わります。フレームワークの名前を覚える前に、この3つの型を押さえてください。

ネイティブ開発とは——OSの標準の道具で、そのOS専用に作る

ネイティブ開発とは、そのOSの提供元が用意した言語と開発環境で、そのOS専用のアプリを作ることです。iOSならSwift(あるいはObjective-C)とXcode、AndroidならKotlin(あるいはJava)とAndroid Studioを使います。画面はOSが持つ標準の部品を組み合わせて作ります。

この方式の強みは、OSが提供するものをそのまま使える点にあります。新しいOSの機能が発表されれば最初に使えるのはネイティブですし、画面の見た目や操作感はそのOSの標準そのものになります。弱点は明快で、iOSとAndroidの両方に出すなら、言語も環境もコードも2つ分必要になることです。

マルチプラットフォームの手法はすべて、この「2つ分」をどこまで1つにまとめられるかという挑戦だと考えると、違いが整理しやすくなります。

3つの型の比較表——自前描画型 / ネイティブUI変換型 / Web技術型

Flutterの公式ドキュメント(2026-09-19確認)は、この「自前で描く」方針を明確に書いています。Flutterは各UIコントロールを独自に実装しており、iOSのトグルスイッチにもAndroidのスイッチにも、Dart言語による自前の実装を持っています。公式はその利点として、OSが用意した拡張点に縛られないこと、Flutterのコードとプラットフォームのコードを行き来せずに画面全体を一度に合成できるため性能上のボトルネックを避けられること、アプリの挙動をOSへの依存から切り離せることを挙げています。

一方、React Nativeの公式ドキュメント(2026-09-19確認)は、新アーキテクチャのFabricレンダラーが実際のプラットフォームのネイティブコンポーネント(ViewやTextなど)を描画すると説明しています。.NET MAUIも同様に、Android・iOS・macOS・WindowsのAPIを1つのAPIに統一し、そのうえで各プラットフォームのネイティブAPIを直接利用する構成です。

つまり、Flutterで作ったアプリとReact Nativeで作ったアプリでは、同じ「マルチプラットフォーム」でも画面の成り立ちが根本的に違います。提案を比較するときは、この型の違いを確認してください。

「ロジックだけ共有する」という第4の選び方

3つの型のほかに、もう1つの考え方があります。画面は各OSのネイティブで作り、その裏側の処理だけを共有する方式です。

Kotlin MultiplatformはJetBrainsによるオープンソース技術で、公式ドキュメント(2026-09-19確認)は「Android、iOS、デスクトップ、Web、サーバーの間でコードを共有しながら、ネイティブ開発の利点を保てる」と説明しています。共有する範囲は選べます。通信やデータ保存といった特定のモジュールだけを共有することも、ビジネスロジック全体を共有してUIはネイティブのままにすることも、Compose Multiplatformを使ってUIまで共有することもできます。

この方式は、画面の操作感をOS標準に保ちたい一方で、業務ルールや計算処理の二重実装は避けたい、という要求に合います。ただし画面は2つ分作ることになるため、工数の削減幅は他の手法より小さくなります。

では、それぞれの手法は具体的にどこまで対応していて、今どういう状態にあるのか。公式ドキュメントで確認した内容を次にまとめます。

代表的な手法5つ——仕組みと対応プラットフォーム(公式ドキュメントで確認)

ここからは、提案書に名前が出てくる代表的な5つの手法を取り上げます。仕組み・対応プラットフォーム・サポート状況は、まとめサイトや比較記事ではなく、それぞれの公式ドキュメントを直接確認しました(確認日はすべて2026-09-19)。この領域は変化が速く、2〜3年前の記事の記述がそのままでは当てはまらないことが珍しくないためです。

手法の比較表——開発言語 / 画面の作り方 / 対応プラットフォーム / 出典・確認日

表を見ると、「マルチプラットフォーム」と一括りにされている手法が、対応範囲も共有の考え方も相当違うことが分かります。iOSとAndroidだけでよいのか、将来Webやデスクトップにも出すのかで、選ぶべき手法は変わります。

Flutter——独自の描画エンジンを同梱し、OSのUI部品を使わない

Flutterの特徴は、アーキテクチャ概要のページ(2026-09-19確認)が明言しているとおり、OSのUIウィジェットライブラリを迂回して自前のウィジェット群を使う点にあります。画面を描くDartのコードはネイティブコードにコンパイルされ、描画にはImpellerが使われます。公式は「Impellerはアプリと一緒に配布されるため、端末のOSが新しいバージョンに更新されていなくても、開発者はアプリを更新して最新の性能改善を取り込める」と説明しています。

この構造の利点は、OSのバージョン差による見た目の揺れが起きにくいことです。逆に、OS標準の操作感をそのまま再現したい場合は、Flutter側で作り込む必要があります。OSの機能を使うときは、公式が「プラットフォームチャネル」と呼ぶ仕組みでDartのコードとOS固有のコードをやり取りします。C言語系のAPIについては、シリアライズを伴わないFFIという手段も用意されています。

つまりFlutterは「OSからできるだけ独立する」という設計思想です。独立している分、OSの新機能を使うにはFlutter側の対応か、自前でプラットフォームチャネルを書く作業が必要になります。

React Native——JavaScriptでOSのUI部品を動かす。0.76でNew Architectureが既定に

React NativeはJavaScript(またはTypeScript)で書いたコードから、OSのネイティブコンポーネントを描画します。ここがFlutterとの決定的な違いです。

注意すべきは、アーキテクチャが刷新されている点です。公式ドキュメント(2026-09-19確認)は、New ArchitectureがJavaScriptとネイティブの間にあった非同期のブリッジを廃止し、JSI(JavaScript Interface)に置き換えたと説明しています。JSIはJavaScriptがC++オブジェクトへの参照を保持できる仕組みで、公式は「メモリ参照があれば、シリアライズのコストなしにメソッドを直接呼び出せる」としています。そしてバージョン0.76以降、New Architectureがすべてのプロジェクトで既定になっています。

数年前の記事にある「React Nativeはブリッジがボトルネックになる」という説明は、この変更を踏まえていない可能性があります。技術選定の資料を読むときは、記述がどの時点のものかを確認してください。古い前提で判断するのは失敗のもとです。

Kotlin Multiplatformと.NET MAUI——ロジック共有型と、ネイティブUI変換型

Kotlin Multiplatformは前章で触れたとおり、共有する範囲を選べる点が特徴です。公式ドキュメント(2026-09-19確認)の安定度の表では、Android・iOS・デスクトップ(JVM)・サーバー(JVM)・Kotlin/JSによるWebがStable、Kotlin/WasmによるWeb・watchOS・tvOSがBetaとされています。既にAndroidアプリをKotlinで作っている組織が、iOS版を追加するときにロジックだけを持ち込む、といった使い方に向きます。

.NET MAUIはMicrosoftによるフレームワークで、Xamarin.Formsの後継にあたります。公式ドキュメント(2026-09-19確認)は、Android・iOS・macOS・Windowsのそれぞれに対応し、「1つの共有コードベースからアプリを開発できる」と説明しています。コンパイルのされ方はOSごとに異なり、AndroidはC#から中間言語を経てアプリ起動時にJITコンパイル、iOSはC#からARMのネイティブコードへ完全にAOTコンパイル、macOSはMac Catalyst、WindowsはWinUI 3を使います。なお公式は、iOSとmacOS向けのビルドにはMacが必要だと明記しています。社内にMacがない組織では、この一文がそのまま調達の要件になります。

C#とXAMLの資産を持つ組織、すなわち業務系で.NETを使ってきた会社にとっては、.NET MAUIが現実的な選択肢になります。

PWAとWebView型——ブラウザの仕組みで動かす。ストアに出すかどうかで話が変わる

最後がWeb技術型です。MDN(2026-09-19確認)はPWAを「Webプラットフォームの技術で作られているが、プラットフォーム固有のアプリのような体験を提供するアプリ」と定義し、「Webサイトと同じく単一のコードベースから複数のプラットフォームとデバイスで動作し、プラットフォーム固有のアプリと同じく端末にインストールでき、オフラインやバックグラウンドで動作し、端末や他のインストール済みアプリと統合できる」と説明しています。技術的にはWebアプリマニフェストとService Workerが中核です。

これと近いのがWebView型(ハイブリッド)です。アプリの外枠だけをネイティブで作り、中身はアプリ内のブラウザ表示領域でWebページを表示します。既存のWebサイトを流用できるため短期間で作れますが、後述するとおりストア審査で問題になる場合があります。

なお、Webの画面をどう描画するか(SPAかMPAか、サーバー側で描画するか)という設計は、本記事の範囲ではありません。そちらは「SPA開発」の記事で扱っています。また、アプリという概念そのものの分類(ネイティブ・Web・ハイブリッド・PWA)を整理したい場合は「アプリとは」の記事をご覧ください。

ここまでで、手法ごとの仕組みの違いは見えたはずです。次に、どの手法を選んでも残る問題を扱います。

1つのコードで両OSに出せても「同じにならない」もの——UI作法、権限、通知、課金、審査

この章が本記事で最も重要です。「1つのソースコードで両OSに出せる」という説明は正しいのですが、そこから「両OSで同じアプリになる」「作業が1つ分で済む」を導くと、見積もりが足りなくなります。フレームワークが吸収できるのは、あくまで実装の一部です。AppleとGoogleがそれぞれ定めるルールは、フレームワークの外側にあります。

共通化できるもの・できないものの一覧表

表のとおり、共通化の効果が大きいのは上の3行、つまりロジックと通信と(手法によっては)レイアウトです。下の6行は、どの手法を選んでも2つ分に近い作業が残ります。見積書にこの6行の工数が計上されていない場合は、どこで吸収するつもりなのかを質問してください。

通知と課金——iOSのWeb Pushはホーム画面に追加したWebアプリのみ。デジタルコンテンツはアプリ内課金が必須

通知と課金は、発注前の検討で最も見落とされる2つです。

プッシュ通知については、Web技術型を選んだ場合に制約が大きくなります。WebKitの公式ブログ(2026-09-19確認)は、iOSとiPadOS 16.4でホーム画面に追加したWebアプリへのWeb Push対応を追加したと発表しています。裏を返せば、iOSでWebアプリがプッシュ通知を受け取るには、利用者が自分でホーム画面に追加する操作を行う必要があります。ブラウザのタブで開いているだけでは通知は届きません。通知が事業の中心にあるサービスで、利用者に追加操作を期待する設計は、失敗のもとです。

課金は、ストアに出す以上は避けて通れません。App Reviewガイドライン(2026-09-19確認)の3.1.1は、「アプリ内の機能やコンテンツを解放したい場合(たとえばサブスクリプション、ゲーム内通貨、ゲームのレベル、プレミアムコンテンツへのアクセス、フル機能版の解放など)は、アプリ内課金を使わなければならない」と定め、さらに「アプリはライセンスキー、拡張現実のマーカー、QRコード、暗号資産やそのウォレットといった独自の仕組みでコンテンツや機能を解放してはならない」としています。マルチプラットフォームのフレームワークを使っても、この要件は各ストアの課金の仕組みに沿って実装する必要があり、iOSとAndroidで別々の作業になります。

当社が手がけた決済アプリの案件でも、Stripeによる決済、二要素認証、ウォレット、PDF出力といった機能群のうち、ロジックは共通化できても、ストアの規約に関わる部分は個別に設計する必要がありました。デジタルコンテンツの販売を含むアプリでは、企画の段階で課金方式を決めておかないと、後戻りが大きくなります。

審査——「Webサイトを包んだだけ」はApp Storeで通らない

「既存のWebサイトをアプリの中に表示すれば、安くアプリが作れるのではないか」。これもよく受ける相談です。技術的には可能ですが、ストア審査という壁があります。

App Reviewガイドライン(2026-09-19確認)の4.2「Minimum Functionality」は、「あなたのアプリは、Webサイトをそのまま包み直したもの(repackaged website)を超える機能・コンテンツ・UIを備えているべきである」「アプリが特に有用でも独自でもなく、アプリらしくもないなら、App Storeにふさわしくない」と述べています。さらに4.2.2では、「カタログを除き、アプリは主としてマーケティング資料、広告、Webの切り抜き、コンテンツのまとめ、リンク集であってはならない」としています。

一方でガイドライン4.7は、HTML5やJavaScriptによるミニアプリ・ミニゲーム、ストリーミングゲーム、チャットボット、プラグインなど、バイナリに組み込まれていないソフトウェアを提供できる場合があるとも定めています。ただし同項は「アプリ内で提供されるそうしたソフトウェアについては、本ガイドラインおよび適用されるすべての法令への適合を含め、あなたが責任を負う」としています。

つまり、Web技術を使うこと自体は否定されていません。否定されているのは「Webサイトを包んだだけで、アプリとしての価値がないもの」です。この線引きは審査の裁量に左右される部分があり、事前に確実な判定を得る方法はありません。Web技術型を検討するなら、アプリならではの機能(オフラインでの利用、通知、端末機能の活用)をどう入れるかを企画段階で決めておくのが安全です。

ここまでが「同じにならないもの」です。次は、リリースした後に続く話——性能と保守を見ていきます。

性能と保守——重くなる場面と、OSの年次更新に追従し続けるコスト

マルチプラットフォームの話題では性能が真っ先に論じられがちですが、実務で効いてくるのは保守のほうです。性能が問題になるのは用途が限られる一方、OSの更新への追従は、すべてのアプリに毎年やってきます。この章では両方を扱います。

性能が問題になる場面——高頻度の描画、カメラ・映像のリアルタイム処理、OSの最新機能

まず、性能について「マルチプラットフォームは遅い」という一般論は、現在はそのままでは成り立ちません。前章までに見たとおり、Flutterは描画エンジンをアプリに同梱してOSのUI部品を経由せずに画面を合成し、React NativeはJSIによってシリアライズのコストなしにネイティブのメソッドを直接呼べるようになっています。React Nativeの公式ドキュメント(2026-09-19確認)は、この仕組みが可能にする高帯域の処理の例として、リアルタイムのカメラフレーム処理(毎秒およそ2GB)を挙げています。

そのうえで、慎重に検討すべき用途は残ります。

大半の業務アプリやサービス系アプリは最後の行に当てはまります。性能を理由にネイティブを選ぶべき案件は、実際にはそれほど多くないというのが実情です。

OSのバージョンアップ追従——Google Playは2026年8月31日までにAndroid 16(API 36)以上

保守の話に移ります。アプリはリリースして終わりではありません。OSは毎年更新され、ストアは対応を求めてきます。

Google Playのターゲット API レベル要件(2026-09-19確認)では、2025年8月31日までに新規アプリと更新がAndroid 15(API 35)以上を対象とすることが求められ、2026年8月31日までにはAndroid 16(API 36)以上が必要とされています。対応に時間を要する場合は2026年11月1日までの延長を申請できるとされていますが、期限までに対応しなければ、新しいAndroidを使う利用者への配信が制限されます。

これはマルチプラットフォームでも同じです。むしろ、フレームワークが新しいAPIレベルに対応するのを待ってから自社アプリを更新する、という一段階が挟まります。Flutterのサポート対象プラットフォームのページ(2026-09-19確認)を見ると、3.47.2時点でAndroidはAPI 24〜37、iOSは15〜27がサポート対象とされており、フレームワーク側のサポート範囲もOSの更新に合わせて動いていることが分かります。

保守契約を結ぶときは、「OSのメジャーアップデートへの対応が契約に含まれるか」「フレームワークのバージョンアップ作業は誰がやるか」を明示してください。ここが曖昧なまま数年が過ぎ、いざ更新しようとしたら依存関係が大きくずれていて、多額の改修費が必要になる——という相談は毎年届きます。保守の考え方については「システム改修・開発保守の外注」の記事もあわせてご覧ください。

ライブラリの保守リスク——依存が「OS」「フレームワーク」「サードパーティ」の3階建てになる

ネイティブ開発では、依存関係は基本的に「OS」と「使っているライブラリ」の2階建てです。マルチプラットフォームでは、その間にフレームワークが入り、3階建てになります。

とくに注意が要るのは3段目です。マルチプラットフォームのフレームワークでOSの機能を使うとき、公式が用意していない領域は有志が公開したライブラリに頼ることになります。そのライブラリの更新が止まると、OSの新しい仕様に追従できなくなり、自前で書き直すか、別のライブラリへ乗り換えるかの判断を迫られます。

対策は地味ですが有効です。採用するライブラリの更新頻度と、公式が提供しているものかどうかを、選定時に確認しておく。そして、どのライブラリに依存しているかの一覧を維持しておく。当社ではGitのプルリクエストによるコードレビューを標準化しており、新しい依存を追加する際はレビューの対象にしています。地味な運用ですが、数年後の改修費を左右します。

では発注者として、結局どう決めればよいのでしょうか。

発注者としての決め方——ネイティブを選ぶべきケース、費用は半分になるのか、外部チームでの体制

ここまでの内容を、発注者の判断に落とします。決め方の順序は単純です。まず「ネイティブでなければならない条件」に当てはまるかを確認し、当てはまらなければマルチプラットフォームを検討する。この順序にすると、技術の比較検討に時間を使わずに済みます。

判断表——ネイティブ / マルチプラットフォーム / Webのどれを選ぶか

この表は「どちらが優れているか」ではなく「何を守りたいか」で並べています。守りたいものが描画性能やOSの最新機能なら、ネイティブが妥当です。守りたいものが仕様変更への追従の速さや、限られた人数での開発なら、マルチプラットフォームが合います。

「費用が半分になる」は本当か——減る工数と減らない工数を分けて見る

「マルチプラットフォームなら費用が半分になる」。この説明を受けた、という相談を今でも多く受けます。

先に結論を書きます。当社では、削減幅を数値で示すことはしていません。理由は単純で、根拠として示せる一次情報がないからです。削減率は、アプリの性質、画面数、OS固有機能の多さ、対象端末の幅によって大きく変わります。公開されている調査で「マルチプラットフォーム開発により開発費が◯%削減される」と一般化できるものを、私は確認できていません。半減を前提に予算を組み、足りなくなるのが最も避けたい事態です。

代わりに、減る工数と減らない工数を分けて見積もることをお勧めします。

見積書を受け取ったら、この8行に沿って内訳を確認してください。実装工程だけが圧縮されていて、テストと審査対応が同じように圧縮されている見積書は要注意です。アプリ開発の費用の考え方そのものは「アプリ開発 費用相場」の記事で詳しく扱っています。また、会社の選定軸については「アプリ開発会社の選び方」の記事をご覧ください。

外部チームでマルチプラットフォーム開発をするときの体制——当社の場合

最後に、外部のチームでマルチプラットフォーム開発を進める場合の体制について述べます。

当社はFlutterとReact Nativeでの開発に対応しています。ベトナム・ホーチミンを拠点に、2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインする形で、協力会社を経由する仲介マージンは発生しません。体制はパターンA(日本人PM/BrSE+エンジニア)とパターンB(エンジニアのみ)の2種類で、マルチプラットフォームの案件ではパターンAをお勧めしています。理由は、この記事で述べてきた「同じにならないもの」——OS固有のUI作法、権限、通知、課金、審査——の判断が日本側に集中するためです。ここを日本語で詰められる人がチームの中にいるかどうかで、手戻りの量が変わります。

規模は1名から組めます。最短2週間で開始でき、増員は約1週間、縮小と交代は1か月単位です。公開している単価は実務3年目安で1,500USD(約22.5万円 / 1USD=150円換算目安)、5年で2,000USD、10年・ブリッジSEで3,000USD。日本人PMをフロントに置く最小構成は2〜3人月で月額約80万円からになります。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。品質面では、日本人PMによる設計レビュー、Gitプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点を標準にしています。オフショアでの品質確保の考え方は「オフショア開発の品質」の記事で詳しく書いています。

そのうえで、率直に申し上げます。3D表現や映像のリアルタイム加工が中核の案件、OSの最新機能を発表直後から使う方針の案件には、当社はネイティブをお勧めしています。マルチプラットフォームで受けたほうが当社の得意領域に近いのですが、事業の中心にある機能で制約に当たると、作り直しの費用のほうが大きくなるためです。また、ベトナムとの時差は2時間、祝日は2026年で年12日(労働法112条の法定は11日で、2026年からベトナム文化の日が加わります)、2026年のテト(旧正月)は2月14日から22日です。ストア申請の時期をこの期間に重ねないよう、スケジュールの相談は早めにいただければと思います。

自社のアプリは、この記事のどの行に当てはまったでしょうか。

【FAQ】マルチプラットフォームに関するよくある質問

最後に、相談の場で繰り返し受ける質問を5つ取り上げます。いずれも本文で述べた内容の要点ですので、社内で説明する際の言い回しとしてお使いください。

Q1. マルチプラットフォームとクロスプラットフォームは、結局どちらが正しい言い方ですか

どちらも使われており、業界で統一された定義はありません。日本語のIT記事や開発会社の資料では、ほぼ同義として扱われています。「マルチプラットフォーム=複数のプラットフォームに対応している状態」「クロスプラットフォーム=またいで動くように作る仕組み」と区別する説明もありますが、公的な規格に基づくものではありません。実務では語の選択にこだわらず、「対応OSはどれか」「1つのコードで共有する範囲はどこまでか」を具体的に確認してください。

Q2. マルチプラットフォームで作ったアプリを、後からネイティブに作り直せますか

技術的には可能ですが、実質的には新規開発に近い費用と期間がかかります。共通化していた画面の実装は、OSごとに書き直すことになるためです。再利用しやすいのはサーバー側のAPIと、データ構造の設計です。「まずマルチプラットフォームで出して、伸びたらネイティブに作り直す」という計画を立てる場合は、作り直しの費用を最初から見込んでおいてください。

Q3. FlutterとReact Nativeでは、どちらを選ぶべきですか

案件と、保守を担う体制によります。画面の見た目を全OSで揃えたい、OSのUI部品の差異に振り回されたくない場合はFlutterが向きます。社内やチームにJavaScript・TypeScriptの経験者が多く、Webとの人材の行き来を考えたい場合はReact Nativeが向きます。どちらも2026年9月時点で活発に開発が続いており、性能面の一般論で優劣を決められる状況ではありません。判断材料は、自社が5年後もその技術を扱える体制にあるかどうかです。

Q4. アプリを作らず、Webサイト(PWA)で済ませることはできますか

用途によっては可能です。URLで配れて、ストアの審査も課金の制約も避けられる利点があります。ただし制約もあります。iOSでWebアプリがプッシュ通知を受け取るには、利用者がホーム画面に追加する操作を行う必要があります(iOS 16.4以降)。通知が事業の中心にある場合は慎重に検討してください。また、Webサイトをそのままアプリの中に表示しただけのものは、App Reviewガイドライン4.2により審査を通らない可能性があります。

Q5. マルチプラットフォームにすると、保守費用は安くなりますか

実装の修正は1か所で済むため、機能追加や不具合修正の工数は下がる傾向にあります。ただし、フレームワーク本体のバージョンアップ作業と、依存しているサードパーティ製ライブラリの更新追従という作業が新たに加わります。Google Playは2026年8月31日までにAndroid 16(API 36)以上を対象とすることを求めており、OSの年次更新への追従はどの手法でも必要です。保守契約を結ぶ際に確認すべきは、OSのメジャーアップデート対応とフレームワークのバージョンアップ作業が含まれるかどうかの2点。

まとめ: 語の定義ではなく「何が共通化できて、何が残るか」で決める

マルチプラットフォームとは、1つのソフトウェアが複数のプラットフォームで動くこと、そして開発の文脈では1つのソースコードから複数のOS向けの成果物を作る手法を指します。クロスプラットフォームとはほぼ同義で、業界で統一された定義はありません。用語の厳密さを巡る議論に時間を使う必要はなく、確認すべきは「対応OSはどれか」「1つのコードで共有する範囲はどこまでか」の2点です。

手法は画面の作り方で3つに分かれます。描画エンジンを同梱して自分で画面を描く自前描画型(Flutter)、OSの画面部品に対応づけるネイティブUI変換型(React Native、.NET MAUI)、ブラウザの仕組みで動かすWeb技術型(PWA、WebView型)。加えて、ロジックだけを共有してUIはネイティブに保つ選び方(Kotlin Multiplatform)もあります。どれを選んでも、OS固有のUI作法、権限ダイアログ、プッシュ通知、課金、ストア審査、端末での動作確認は2つ分に近い作業が残ります。共通化で大きく減るのは実装工数であり、要件定義・テスト・審査対応・保守は減りにくいというのが実情です。そして、3D表現や映像のリアルタイム加工が中核の案件、OSの最新機能を先行して使う案件には、率直にネイティブをお勧めします。

当社はFlutterとReact Nativeでの開発に対応しており、日本人PM/BrSEをフロントに置く体制を標準としています。「同じにならないもの」の判断が日本側に集中するためです。費用の考え方はアプリ開発の費用相場、会社の選定軸はアプリ開発会社の選び方もあわせてご覧ください。現在の体制と要件をお聞かせいただければ、マルチプラットフォームとネイティブのどちらが合うかの判断と、概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。