モバイルプロダクト開発：ディスカバリーからスケールまでのロードマップ（オンデバイスAIとクラウドAI対応）

このガイドは、新しいモバイルアプリを計画している、または停滞したアプリを再構築しようとしているファウンダー、プロダクトオーナー、CTOを対象としています。ディスカバリーからスケールまでのロードマップ、ネイティブ対クロスプラットフォームの選択、モバイル向けバックエンドとAPI設計、AIフィーチャーをどこで実行すべきか、セキュリティ、アプリストアのリリースオペレーション、タイムラインとチームの一般的な構成について解説します。最後に、トレードオフ、よくあるミス、ローンチチェックリストでまとめます。

このガイドの内容

• ロードマップの概要
• ディスカバリー：デザイン開始前に決定すべきこと
• ネイティブかクロスプラットフォームか：判断の基準
• モバイル向けに設計されたバックエンドとAPI
• AIフィーチャー：デバイス上かクラウドか
• 最初のスプリントからのセキュリティ
• リリースオペレーションとアプリストア
• タイムライン、チーム、デリバリーリズム
• コマースからの実績とその示唆
• トレードオフとよくあるミス
• モバイルローンチチェックリスト
• このクラスターで計画中のガイド
• このガイドの限界
• よくある質問
• このガイドの作成方法
• 次のステップ

ロードマップの概要

モバイルプロダクトが失敗する原因は、最初の画面の実装が難しかったことではありません。間違ったジョブを選んだこと、バックエンドが追いつかなかったこと、あるいはリリースが毎回緊急対応になったことが原因です。ステージ型のロードマップは、各ステップに判断ポイントと終了テストを設けます。

各ステージは、未完成の作業を残さずに停止できます。これが重要なのは、モバイルプロダクトがステージ2または3で、ジョブ、対象ユーザー、または価格を変更する必要があると気づくことが多いためです。

ディスカバリー：デザイン開始前に決定すべきこと

ディスカバリーは、モバイルプロダクトのコストの大部分が決まる段階です。デザインを開始する前に、以下の問いに答えてください。

• ユーザーとジョブ。誰がどのような状況でアプリを使い、Webサイトを含む代替手段よりも優れていなければならない唯一のジョブは何か。
• アプリかモバイルWebか。ジョブにデバイス機能、オフライン使用、ホーム画面へのインストールが不要であれば、レスポンシブWebの方が十分で、運用コストも安く済む場合があります。
• プラットフォーム。ローンチ時にiOS、Android、またはその両方か、スマートフォンのみかタブレットも含むか、対応する最小OSバージョンはどれか。
• オフラインと低速ネットワーク。接続なしで何が動作しなければならないか、オフラインで行った操作はどう処理されるか。
• デバイス機能。カメラ、位置情報、生体認証、プッシュ通知、決済、Bluetooth、ヘルスデータはそれぞれデザイン、権限設定、レビュー作業を追加します。
• インテグレーション。アカウント、注文、決済、CRM、ERP、コンテンツシステムなど、アプリが読み書きするシステム。
• ストアとビジネスルール。アプリがどのように収益を上げるか。アプリ内課金やサブスクリプションに関するストアルールがプロダクト設計に影響します。
• AIフィーチャー。検索、カメラ認識、アシスタント、パーソナライズドコンテンツなど、AIが高速化するジョブ、各フィーチャーが必要とするデータ、オフラインで動作する必要があるかどうか。
• データとプライバシー。収集する個人データ、その目的、保存場所、同意の記録方法。
• 成功指標。アクティベーション、リテンション、コンバージョン率、またはタスク完了率。最初の1行のコードを書く前に、アナリティクスイベントとして定義します。

ディスカバリーの成果物は、数週間で構築できるほど小さな初回リリースと、意図的に除外するものの一覧です。

ネイティブかクロスプラットフォームか：判断の基準

モバイルプロダクトを構築する方法は大きく3つあり、それぞれが特定のプロダクトにとって正解となります。

6つの問いがほとんどの判断を決定します。

1. プロダクトはデバイス機能をどの程度深く使うか。深いほど、ネイティブを選ぶ理由が強くなります。
2. iOSとAndroidを同時にローンチしなければならないか。そうなら、クロスプラットフォームの方が通常早くパリティを達成できます。
3. インターフェースはどれだけ高度か。複雑なアニメーション、リアルタイムグラフィックス、カメラ処理はネイティブに有利です。
4. どのスキルセットでメンテナンスするか。プロダクトは何年もメンテナンスされます。チームまたはパートナーがサポートできるものを選んでください。
5. 他のチャネルとどれだけ共有できるか。WebチームはロジックやデザインシステムやAPIを再利用できる場合があります。
6. 次のステージに何が必要か。ステージ2だけでなく、ステージ5で期待するプロダクトに対して判断してください。

混合アプローチは一般的で健全です。必要な少数の機能にネイティブモジュールを組み合わせたクロスプラットフォームアプリがその典型例です。

モバイル向けに設計されたバックエンドとAPI

バックエンドは、モバイルプロダクトがWebサイトと最も異なる部分です。Webサイトは全ユーザーに対して一度にアップデートできますが、モバイルアプリはユーザーが選んだタイミングでしかアップデートされません。

• 古いバージョンが残り続ける。APIにバージョン管理を導入し、サポートされているアプリバージョンが使用されている限り後方互換性を維持してください。最小サポートバージョンを設定し、ユーザーにアップデートを求めるまたは強制する手段を用意します。
• 低速ネットワークを考慮した設計。ラウンドトリップ数を少なく抑え、リストをページネーションし、デバイスに合わせたサイズの画像を送信し、タイムアウト後のリトライが2件目の注文を生まないようにリクエストを冪等にします。
• オフライン使用には同期モデルが必要。必要なデータをローカルに保存し、オフラインでの変更をキューに入れ、デバイスが再接続したときのコンフリクト解決方法を決めます。
• デバイス向けの認証。リフレッシュトークン付きの短命アクセストークンを使い、プラットフォームのセキュアストレージでトークンを保護し、有効な場面では生体認証サインインを提供します。
• 同意を得た通知。プッシュメッセージはプラットフォームの通知サービスを経由します。ユーザーが意味を理解できるタイミングで権限を求め、カテゴリ別に制御できるようにします。
• リモート設定とフィーチャーフラグ。ストアリリースを待たずに、機能のオン・オフ切り替えやコンテンツの変更が可能です。
• 初日からのオブザーバビリティ。クラッシュレポーティング、パフォーマンストレース、ディスカバリーで定義したアナリティクスイベントは、ローンチ後ではなく初回リリースに含めます。

同じバックエンドがWebサイト、モバイルアプリ、パートナーに対応する場合は、APIをドキュメント・バージョン管理ルール・モニタリングを備えた独立したプロダクトとして扱います。

AIフィーチャー：デバイス上かクラウドか

ユーザーは今や、カメラが見ているものを認識し、自然言語で質問に答え、適切なコンテンツを優先表示するアプリを期待しています。各AIフィーチャーをどこで実行するかは、プライバシー、コスト、速度、リリースサイクルに影響するアーキテクチャの判断であり、フィーチャーごとに決定します。

目安として、オンデバイスはカメラからのテキスト認識、画像分類、シンプルなランキング、オフラインで動作が必要な機能に適しています。クラウドは大規模カタログをまたぐ意図理解型検索、ドキュメント解析、ビジネスデータを読み取る処理、そしてアシスタントに適しています。多くのプロダクトは両方を組み合わせています。デバイス上で素早く一次処理を行い、難しいケースはクラウドに送ります。

モバイルアプリにおけるクラウドAIの設計ルール：

• AIはバックエンド経由で呼び出す。アプリパッケージにAIプロバイダーのキーを含めてはいけません。バックエンドがキーを保持し、ユーザーごとの制限を適用し、アプリアップデートなしでモデルやプロバイダーの切り替えを可能にします。
• フォールバックを計画する。AIサービスが遅い、または利用できない場合でも、コアジョブは機能し続けます。
• 結果に対する責任を人間に持たせる。アシスタントは注文変更やサポート返信の下書きを作成できますが、ユーザーまたはスタッフがそれを確認します。
• 開示する。ストアのプライバシー開示とアプリ内通知に、AIが何を処理し、どこで処理するかを明記します。

最初のスプリントからのセキュリティ

OWASP Mobile Application Security Verification Standard（MASVS）は、モバイルセキュリティ要件をストレージ、暗号化、認証と認可、ネットワーク通信、プラットフォームインタラクション、コード品質、改ざん・リバースエンジニアリングへの耐性、プライバシーの8つのコントロールグループに整理しています。バイヤーはこれらのグループを使って最初のバックログに要件を記述し、パートナーに各コントロールのテスト方法を問い合わせることができます。最後にセキュリティレビューを依頼するのではなく、最初から組み込みます。

実践的な出発点として：AIプロバイダーキーを含むシークレットをアプリパッケージから除外する、機密データはプラットフォームの保護されたストレージにのみ保存する、すべての接続にTLSを使用する、アプリを信頼するのではなくサーバー側で認可を確認する、ジョブに必要な個人データのみを収集する、すべてのビルドで依存関係をスキャンする。

Netbase JSCの公開済みセキュリティプラクティスには、セキュアコードレビューとバージョン管理、転送時のTLSと保存時のAES暗号化、ロールベースアクセス制御、管理ダッシュボードへのMFA、脆弱性スキャンとペネトレーションテスト、ディザスタリカバリが含まれます。NDA、DPA、SLAはリクエストに応じて提供可能で、コントリビューターはNDAのもとで作業します。これらはプラクティスであり、特定のアプリに関する保証ではありません。

リリースオペレーションとアプリストア

モバイルプロダクトをローンチするということは、ルールが継続的に変化する2つのストアオーナーによるレビューを通過し、ユーザーを混乱させることなく何度もリリースを続けることを意味します。

• Apple。App Store Review Guidelinesは、安全性、パフォーマンス、ビジネス、デザイン、法律の5つのセクションで構成されています。ビジネスセクションはアプリ内課金やサブスクリプションを含む決済を扱い、法律セクションはプライバシーとデータ取り扱いを扱います。提出の1週間前ではなく、ディスカバリーの段階で確認してください。
• Google Play。Googleは新しいアプリとアップデートに最新のAndroid APIレベルをターゲットにすることを要求しており、最小ターゲットレベルを下回る既存アプリは新しいデバイスの新規ユーザーに表示されなくなります。プロダクトが安定していても、これらの要件に対応するために年1回のアップデートを計画してください。

適切なリリースオペレーションは次のようになります。

• 各公開リリース前に内部・パイロットユーザー向けのベータチャンネル；
• 少数のユーザーから始まり、クラッシュ率の上昇時に一時停止する段階的ロールアウト；
• リリースノート、ストアスクリーンショット、プライバシー開示を最新に保つ；
• 修正がレビューされている間、壊れた機能を無効化するサーバーサイドスイッチを備えたホットフィックスパス；
• OSの変更、依存関係の更新、セキュリティ修正のための定期的なアップデートリズム；
• AIモデルまたはプロンプトの変更にはサーバーサイドフラグを使用し、全体展開前に少数のユーザーで確認する。

タイムライン、チーム、デリバリーリズム

Netbase JSCはモバイルアプリに特化したレンジを別途公開していません。SaaS製品の一般的なレンジは、MVPで8〜12週間、中規模プロダクトで3〜6カ月、エンタープライズプロダクトで6〜12カ月以上です。これらはスコープに依存する一般的なレンジであり、見積もりではありません。独自のバックエンド、インテグレーション、両プラットフォームを持つモバイルプロダクトは、既存のAPIを使うシングルプラットフォームアプリよりもレンジの上位に位置します。

モバイルのタイムラインを左右する要因：

• ローンチ時にサポートするプラットフォームとデバイスの数；
• ネイティブ作業や追加のストアレビューが必要なデバイス機能；
• 既存システムとのインテグレーション、およびそれらのAPIの状態；
• オフライン要件と同期の複雑さ；
• プロダクトの判断とコンテンツの準備がどれだけ素早くできるか。

Netbase JSCのチームはビジネスアナリスト、プロジェクトマネージャー、ソリューションアーキテクト、開発者、QA、UI/UXデザイナーを組み合わせた3〜30名で構成され、ディスカバリー後通常1〜2週間以内に作業が開始されます。デリバリーはディスカバリーとアーキテクチャ計画から始まり、成果ベースのマイルストーンを持つアジャイル実行を経てロールアウトと継続サポートまでの6ステップのライフサイクルに従います。スプリントはテストビルドへの週次レビューで終了し、チームはハノイからリモートファーストで英語で作業し、バックエンドはAPIファーストで設計されているため、アプリ、Webサイト、パートナーシステム、AIサービスが同じインターフェースを共有します。

これらのステージを通じてモバイルプロダクトを計画・構築する専任チームについては、Netbase JSCのモバイルアプリ開発サービスをご覧ください。再利用可能な出発点がプロダクトに適している場合は、モバイルプロダクトアクセラレーターでNetbase JSCが初回リリースまでの短縮パスにどうアプローチするかをご確認ください。

コマースからの実績とその示唆

RB MarketplaceとDey Page。Netbase JSCは、このガイドのパターンに従った2つのアプリを構築しました：1つのバックエンドとAPIがWebプラットフォームとモバイルアプリの両方に対応しています。RB Marketplaceのカスタマーショッピングアプリは、注文と取引のFirebaseプッシュ通知を備えたマーケットプレイスのAPIで動作します（RB Marketplaceケーススタディ）。iOSとAndroid向けのDey Page React Nativeアプリは、ナイジェリアのWebディレクトリとリスティング、ユーザー、決済を共有しています（Dey Pageレコード）。どちらのレコードも利用数データを公開していません。

USticker。USticker向けに、Netbase JSCはECサイト決済改善のエンゲージメントを実施しました。公開済みの結果は、デザインツール利用ユーザーのコンバージョン率が40%向上、6カ月以内に完了デザインが32%増加、リテンションが25%向上、オンライン注文売上が15%増加、ページ読み込み時間が21%短縮です。これらの数値はそのクライアントについて報告されたエンゲージメント全体の結果であり、40%はデザインツールのユーザーにのみ適用されます。これはコマースのケースであり、ネイティブアプリのケーススタディではありません。コンバージョン率、完了率、リテンション、速度という指標はモバイルコマースプロダクトが初回リリースから追跡すべきものであるため、ここに含めています。USticker事例を読む。

受賞・認定。Netbase JSCの受賞バッジのひとつに、Top Mobile App Developers 2020、Clutchがあります。

コマースは、モバイルプロダクトが決済、カタログ、注文、顧客アカウントという最も複雑な組み合わせと向き合う領域です。Netbase JSCがストアフロント、マーケットプレイス、注文オペレーションにどうアプローチするかは小売・ECサイトでご確認ください。

トレードオフとよくあるミス

• モバイルWebで十分なのにアプリを構築する。アプリにはストアレビュー、アップデート、2つのプラットフォームが伴います。ジョブに必要な場合にのみ構築してください。
• プロダクトより先にフレームワークを選ぶ。まずデバイス機能、プラットフォーム、チームを決定し、フレームワークはその後に決めます。
• APIを後付けで考える。Webサイト向けに設計されたバックエンドは、古いアプリバージョン、低速ネットワーク、オフライン使用に対応できません。
• すべてを一度にローンチする。大規模な初回リリースは、ユーザーが価値を感じる機能を隠し、レビューリスクを倍増させます。
• ローンチ時にアナリティクスもクラッシュレポーティングもない。それらなしでは、グロースステージは意見だけで進むことになります。
• アプリ内にAIキーを入れる。パッケージに含まれるものはすべて抽出可能です。AI呼び出しはバックエンド経由でルーティングしてください。
• 毎年のプラットフォームアップデートを忘れる。プロダクトが変わらなくても、ストアとOSの要件は変わります。

モバイルローンチチェックリスト

• ユーザー、ジョブ、成功指標が書面化され合意されている。
• アプリ、モバイルWeb、または両方の判断が行われ、根拠が示されている。
• プラットフォーム、デバイス、最小OSバージョンが選択されている。
• ネイティブ、クロスプラットフォーム、または混合は、デバイス機能、パリティの必要性、チームスキルに基づいて決定されている。
• APIはバージョン管理され、冪等で、ドキュメント化されており、最小アプリバージョンポリシーが存在する。
• 必要な場所でオフライン動作と同期コンフリクトが仕様化されている。
• セキュリティ要件がOWASP MASVSのコントロールグループにマッピングされている。
• ストアガイドライン、決済ルール、プライバシー開示がレビューされている。
• クラッシュレポーティング、パフォーマンストレース、アナリティクスイベントが初回リリースに含まれている。
• ベータチャンネル、段階的ロールアウト、ホットフィックスパスが整備されている。
• 年1回のプラットフォームアップデートがロードマップに計画されている。
• 各AIフィーチャーはデバイスまたはクラウドに割り当てられており、プロバイダーキーはサーバー上にあり、AIが利用できない場合のフォールバックが用意されている。

このクラスターで計画中のガイド

このピラーはより詳細なガイドの基盤となります。最初のガイドであるネイティブ対クロスプラットフォームモバイル開発では構築ルートを詳しく比較し、モバイルアプリのバックエンド、APIとオフライン同期ではバックエンドをさらに深く掘り下げます。メンテナンス、セキュリティ、リリースオペレーションに関するガイドは計画中です。公開されるまで、上記のセクションが要点をカバーしています。

このガイドの限界

これはNetbase JSCのデリバリー経験に基づく実践的なガイダンスであり、独自の調査ではありません。AppleとGoogleのストアルール、およびOWASP MASVSは、アクセス日時点で確認されており、オンデバイスAI機能と同様に変化します。リリースを計画する前に最新バージョンを確認してください。Netbase JSCのタイムラインレンジはSaaS製品向けに公開されており、一般的なものでスコープに依存します。モバイル向けの別個のレンジは公開されていません。USticker の結果はそのエンゲージメント全体について報告されており、クライアントのベースラインと市場に依存します。アプリストアのダウンロード数や評価指数は主張していません。

よくある質問

ネイティブとクロスプラットフォーム、どちらを選ぶべきか。クロスプラットフォームは、両プラットフォームを素早く必要とするビジネス・コマースアプリの大半に適しています。ネイティブは、デバイス機能、重いグラフィックス、プラットフォーム固有の体験を中心に構築されたプロダクトに適しています。

そもそもアプリは必要か。必ずしも必要ではありません。ジョブにデバイス機能、オフライン使用、ホーム画面へのインストールが不要であれば、レスポンシブWebの方が良い最初のステップになる場合があります。

モバイルの初回リリースにはどれくらい時間がかかるか。プラットフォーム、デバイス機能、インテグレーションによって異なります。参考として、Netbase JSCのSaaS MVPの一般的なレンジは8〜12週間です。

なぜAPIがモバイルにとってこれほど重要なのか。古いアプリバージョンがインストールされたまま残るためです。APIはサポートされているすべてのバージョンと互換性を保ち、低速ネットワークとリトライに対応する必要があります。

AIフィーチャーはデバイス上で実行すべきか、クラウドで実行すべきか。フィーチャーごとに判断します。オンデバイスはカメラのテキスト認識などのオフライン・プライベート・即時性が必要な機能に適しており、クラウドAIは自社データを使ったアシスタントや検索に適しています。プロバイダーキーをデバイスから遠ざけるため、バックエンド経由で呼び出します。

ローンチ後はどうなるか。計測に基づくアップデート、段階的ロールアウト、クラッシュモニタリング、ストアとOSの要件に対応するための少なくとも年1回のアップデートが続きます。

このガイドの作成方法

Netbase JSCの編集チームが、Netbase JSCの公開済みデリバリー、タイムライン、セキュリティのページ、USticker事例、OWASPやApple、Googleの公開ガイダンスをもとにこのガイドを執筆しました。David（CEO）がすべてのNetbase JSCに関する事実を確認しました。外部ソースはアクセス日付きで引用しています。執筆にはAIアシスタンス（Claude）を使用しました。このガイドの目的は、プロダクトオーナーがローンチ後も機能し続けるモバイルプロダクトを計画できるよう支援することです。

次のステップ

モバイルプロダクトが果たすべきジョブ、必要なプラットフォーム、接続が必要なシステムをお知らせください。初回リリースとその後のロードマップを形成するためのソリューションレビューをご予約します。また、関連サービスをご覧になるか、Netbase JSCのインサイトをご覧ください。

関連サービスとソリューション