クライアント向けのアプリを構築したいですが、手間をかけたくありませんか? ホワイトラベルSaaSアプリ により、エージェンシーは1つのコアアプリを作成し、複数のクライアント向けにカスタマイズできます。時間を節約し、コストを削減できます。 Adaloを使用すれば、1つのプラットフォームを使用してiOS、Android、およびWeb用のアプリを構築、ブランディング、および公開できます。エージェンシーが次の理由で Adalo に移行しています。 Adalo:
- 定額料金プランは月額$36から始まり、使用量ベースの料金はありません。
- クロスプラットフォーム公開1つのビルドがiOS、Android、およびWebで動作します。
- 高速セットアップモジュラーテンプレートを使用して、数か月ではなく数日でアプリを立ち上げます。
- スケーラビリティ100万人以上のユーザーと2000万件の1日あたりのデータリクエストに対応します。
AdaloのビルダーであるAdaは、あなたが何を望んでいるかを説明してアプリを生成することができます。Magic Startは説明からアプリの基盤全体を作成し、Magic Addは自然言語を通じて機能を追加します。
Adaloのツール( Magic Start および動的ブランディングにより、技術チームでなくても簡単にカスタマイズできます。 予約アプリ、マーケットプレイス、またはメンバーシッププラットフォームのいずれであっても、より速く、より低価格でポーランドされたアプリを配信できます。仕組みを説明しましょう。
Adaloでホワイトラベルサービスアプリを構築するための5段階のプロセス
ステップ1:コアアプリテンプレートを構築する
モジュラーベースアプリを作成する
成功するホワイトラベルビジネスは、さまざまなクライアント向けに簡単にカスタマイズできるモジュラーベースアプリから始まります。Adaloのビジュアルエディターを使用すると、このFoundationの構築は簡単です。ドラッグアンドドロップインターフェース(ユーザーから「PowerPointと同じくらい簡単」と説明されています)は、アカウント設定とプレビュー用の水平リボン、リアルタイム更新を備えた中央キャンバス、およびデータベースとバックエンド設定用のツールを提供します。
モジュール機能を作成するには、事前に設計されたテンプレートに依存します。例えば、 予約アプリテンプレートを設計する場合、カレンダー、ユーザー認証、および支払い処理を含む再利用可能な予約モジュールを開発できます。ユーザープロファイル、通知、管理ダッシュボードなどの他のモジュールを追加して、アプリを完成させます。このモジュール構成により、各クライアント向けに特定の機能を有効または無効にでき、カスタマイズを迅速かつ効率的に行えます。
再利用性は、設計されたロジックフロー次第です。確認メールの送信や予約後のユーザーロールに基づくデータのフィルタリングなど、プロセスを自動化するカスタムアクションを使用します。これらのアクションは、データベースクエリまたは外部API(すべてコードを記述せずに)にリンクできます。組み込みのユーザー認証ツールにより、テンプレートに安全なサインアップおよびログイン画面を簡単に追加でき、異なるクライアントインスタンス間での一貫したユーザー管理を保証します。
ベーステンプレートの準備ができたら、アプリ設定で「複製可能(画面のみ)」に設定します。これにより、新しいクライアント向けに構造全体(画面、コンポーネント、アクション、データベーススキーマ)を複製でき、データベースレコードは空に保たれます。このアプローチにより、セットアップが高速化され、プロジェクト全体で一貫性が維持されます。
モジュラーベースが配置されたら、AIツールを使用してさらなるカスタマイズを簡素化できます。
より高速なテンプレート作成にAIビルダーを使用する
AdaloのMagic Start機能により、テンプレートの構築プロセスが加速します。「ユーザー認証と支払い処理を備えたサロン向けの予約アプリ」などのニーズを説明するだけで、AIがデータベース構造、画面、およびユーザーフローを自動的に生成します。これにより、初期セットアップに時間を費やすのではなく、アプリの微調整に焦点を当てることができます。
Magic Addはこれをさらに進め、自然言語プロンプトを通じて新機能を統合できます。例えば、「ユーザー認証を備えた予約カレンダーを追加する」と入力すると、ツールが必要なコンポーネント、ロジックフロー、およびデータベース接続を作成するように促します。AIは、表示ルールと外部統合の準備ができている動的コンポーネントを備えたモジュラーなデータベース駆動機能を生成し、複数のクライアント向けに1つのコアテンプレートを適応させるのが簡単になります。
テンプレートを確定する前に、 X-Ray 診断ツールを使用して、パフォーマンスやスケーラビリティの問題を検出します。このAI搭載機能は、非効率なデータベースクエリやヘビーユースの下でアプリを遅くする可能性があるコンポーネントなど、潜在的な問題領域を強調表示するため、開発の早い段階で対処できます。
「Adaloが気に入っている点は、クライアントが持っているアイデアをテストするための非常に迅速なシーケンスを作成でき、彼らが彼らの MVPのために実現できることを合理的に達成できるかどうかを確認できることです。」–Christina Cheng
ステップ2:マルチテナントデータアーキテクチャを設定する
ユーザー固有のデータ可視性を設定する
マルチテナント設定では、各クライアントのデータは分離されたままである必要があります。データベース構造の根として 患者の声は信頼を構築し、 または Organization コレクションを作成することから始めます。その後、ユーザー、プロジェクト、トランザクション、レポートなどの他のすべてのコレクションを、リレーションシッププロパティを使用してこのクライアントコレクションにリンクします。例:クライアント→ユーザー→プロジェクト→タスク。各レコードは親クライアントを参照する必要があり、これによりクライアントIDに基づいてデータを自動的にフィルタリングできます。
この分離を強制するには、Adaloのデータベースビルダーで コレクション権限 を使用します。「シールドとキー」アイコンをクリックし、権限を「一部のログインユーザー」に設定し、ユーザーコレクションにリンクするリレーションシッププロパティを定義します。これにより、アプリのインターフェイスで非表示になっているのではなく、データベースレベルでデータが制限されます。
ダッシュボードを構築する場合、データクエリをフィルタリングして、以下の場所のレコードのみを表示します。 record.client_id = currentUser.client_idAdaloのインフラストラクチャは、2000万件以上の1日あたりのデータリクエストを99%以上の稼働率保証で支持しています。
「可視性ルールは、アプリ内のUIコンポーネントのみを非表示にしますが、アプリがアクセスできるデータは非表示にしません。権限を設定すると、アクセス可能であるべきデータのみがアプリにアクセス可能であることを確認できます。」–Adaloヘルプドキュメント
セキュリティを強化するため、データベース権限と画面レベルの可視性ルールを組み合わせます。リストは関連レコードのみを表示する必要があり、権限はこれらの制限を強化する必要があります。「ログインされた一部のユーザー」権限は現在、2つのレベルまでの深さのリレーションシップをサポートしているため、それに応じてデータベーススキーマを設計してください。
内部データ分離が確実になったら、外部データソースをリンクしてアーキテクチャを拡張できます。
外部データソースに接続する
複数のクライアントのデータを様々なアプリインスタンス全体で管理している場合、Adaloの外部コレクション統合は、 データベースとしてのAirtable, PostgreSQL、, Google Sheets, Firebaseまたは任意のJSON REST APIなどのプラットフォームに接続できます。これは、カスタマイズされたアプリを個別のクライアント向けにデプロイしながら、一元化されたデータベースを維持する場合に特に役立ちます。
外部ソースを使用したデータ分離を維持するには、同じ階層構造に従います。外部データベースに、ルートとしてクライアントまたは組織テーブルがあることを確認します。Adaloの API(Professional プランで月額$36で利用可能)と統合する場合、テナント別にクエリをフィルタリングします。正確なフィルタリング用にAdaloユーザーコレクションの外部データベースから各クライアントの一意のレコードIDを保存します。
マルチテナントアプリをスケーリングする場合、パフォーマンスが重要な要素になります。例えば、Airtableでは、「アクティブクライアントのみ」ビューなどのフィルタビューを作成して、アプリに送信される前にデータを事前フィルタリングできます。このアプローチにより、APIロードが最小化され、Airtableの1秒あたり5リクエストのレート制限内に留まるのに役立ちます。無制限のレコードのためのより堅牢なバックエンドフィルタリングが必要な場合、AdaloのチームとBusinessプランにはXano統合が含まれており、スプレッドシートベースのソリューションの制限を排除します。
外部データをマッピングする場合、各列には少なくとも1つのデータが入力されていることを確認します。Adaloの API 統合は、セットアップ中に空の列を検出しません。また、2026年2月1日現在、Airtableはお持ちのAPIキーの代わりにPersonal Access Tokenが必要です。次の必要なスコープを使用してこれらのトークンを設定します。 data.records:read, data.records:writeおよび schema.bases:read [33,34]。
ステップ3:クライアントブランディング向けにカスタマイズする
データベース駆動型コンポーネントを使用して動的ブランディングを実現する
クライアントブランディングをアプリテンプレートに直接埋め込む代わりに、これらのアセットをあなたの Adaloデータベースに保存します。ロゴと16進数カラーコード用のフィールドを持つ「クライアント設定」または「ブランディング」コレクションを設定します。このセットアップにより、単一のアプリコードベースからすべてのクライアント向けのブランディングを無制限に管理できます。
これを機能させるには、リレーションシッププロパティを使用して各ユーザーをクライアントのブランディングレコードにリンクします。ユーザーがログインすると、アプリは自動的にログイン中のユーザー > クライアント > ロゴというデータパスをたどって、その組織のロゴとカラースキームを取得します。
Adaloは、これらのブランディング要素を動的に適用しやすくしています。例えば、カスタムコンポーネントを構築する際に color ファイル内の manifest.json プロパティを設定できます。これにより、色を変数にバインドしたり、データベースから直接引き出したりできます。このプラットフォームには @primary または @secondaryプロパティも含まれており、背景色に基づいて黒と白の間で自動的に調整することで、テキストが読みやすいままであることを保証します。 @contrast 複数のクライアントを管理する代理店にとって、このアプローチはゲームチェンジャーです。マスターアプリテンプレートへの更新(バグ修正や新機能など)は、個別の更新を必要とせずに、すべてのクライアントに自動的にロールアウトされます。このシステムはブランディングを単純化するだけでなく、追加のカスタム機能のシームレスな統合も実現します。
各クライアント向けにカスタマイズされた機能を追加する
Adaloのフィーチャーテンプレートを使用すると、一から始めることなく機能を簡単に追加できます。これらの事前構築されたモジュールには、設計されたスクリーン、アクション、およびデータベースコレクションが含まれています。例えば、クライアントが予約システムをリクエストした場合、数日手動で構築する代わりに、数分で予約テンプレートを統合できます。
より細かいカスタマイズについては、フィーチャーフラグシステムを実装します。クライアントコレクションにブール値フィールドを追加し(has_advanced_analytics、has_push_notifications、has_payment_processingなど)、条件付き表示ルールを使用して機能のオン/オフを切り替えます。これにより、標準的な機能セットを提供しながら、それを必要とするクライアント向けにプレミアムオプションを有効にできます。すべて同じアプリ内で実現できます。
クライアントが共有コードベースを破壊する可能性のある高度に特定の変更を必要とする場合、Adaloのクローン機能が解決策です。クローンは独自のデータベースを持つ独立したアプリを作成し、広範なカスタマイズをマスターテンプレートおよび他のクライアントから分離して保ちます。これにより、安定性を犠牲にすることなく柔軟性を確保できます。
クラッシュコース |
Adalo 初心者向けチュートリアル2024 Adalo ステップ4:クライアントオンボーディングを合理化する
モジュール式テンプレートと動的ブランディングを設定した後、クライアントオンボーディングプロセスを合理化する時が来ました。これにより、各クライアント向けにカスタマイズされたアプリを迅速に提供できます。
オンボーディングフローを構築する
クライアントから必要なすべてのブランディング詳細を収集するためのオンボーディングフォームを作成することから始めます。以下のようなフィールドを含めます。
ロゴ画像アップロード
- 16進数カラーコードまたはカラーピッカーのテキスト入力
- フォント設定用のドロップダウンメニュー(例:
- 支払い処理やプッシュ通知などのオプション機能用チェックボックス Google Fonts)
- 検証ルールを使用してAdaloのフォームコンポーネントを使用し、完全で正確なデータのみがデータベースに送信されることを確認します。これによりエラーが排除され、すべてがスムーズに動作します。
ガイド付きの段階的なオンボーディング体験を設計することで、さらに一歩進めます。例えば:
ビジュアルアクションを使用してナビゲーションをトリガーします。クライアントがロゴをアップロードしてフォームを送信すると、確認画面に案内します。
- 条件付きロジックを追加して、必須フィールドが完成した後のみ次のステップに分岐するようにします。
- プログレスインジケータ(バーまたはシェイプなど)を含めます。このインジケータはクライアントの進捗に基づいて動的に更新されます。これをデータベース内の表示条件に結びつけることで、クライアントは常に自分の立場を把握できます。
- このようなインタラクティブフローは、技術的な専門知識のないクライアントでもプロセスを直感的にします。すべてのオンボーディングデータがキャプチャされたら、次のフェーズに移る準備ができています。アプリ作成の自動化です。
アプリクローニングとデータインポートを自動化する
ここで、各クライアントのアプリを作成および入力する方法を標準化します。Adaloダッシュボードから「複製」アクションを使用してコアテンプレートアプリをコピーします。クライアント固有のプリフィックス(「ClientName-App」など)を追加して、すべてを整理したままにします。複数のクライアントを管理している場合は、マルチテナントデータベースセットアップを検討してください。これにより、各クライアント向けに個別のアプリインスタンスを必要とせずに、表示フィルタを使用してデータアクセスを管理できます。
クライアントデータをインポートする場合は、CSVアップロードまたは外部統合に依存します。クライアントがオンボーディングフォームを送信すると、自動的にデータベースレコードを作成し、フォームフィールドを正しい場所にマップするアクションを設定します。これにより、ユーザー固有のフィルタを使用してクライアントデータを分離し、プライバシーとセキュリティを確保します。Adaloの有料プランは無制限のデータベースレコードを提供するため、このプロセスをスケーリングしても追加の費用は発生しません。
アプリの準備ができたら、
プレビューリンクを生成してクライアントに電子メールで送信します。クライアントはネイティブiOSおよびAndroidバージョンの Progressive Web App(PWA)またはネイティブアプリ 公開 に進む前に、ブラウザで直接ブランド化されたアプリを探索できます。ループを完成させるために、「承認」と「変更をリクエスト」などのボタンを含む承認画面を含めます。これらのボタンはクライアントのフィードバックをデータベースに直接ログしたり、フィードバックと承認の シームレスなプロセスを作成します。ステップ5:ブランド化されたアプリを公開および管理する
クライアントが了承したら、アプリを公開する時です。Adaloの公開セクションに移動し、iOSまたはAndroidのいずれかを選択し、クライアント固有の詳細(Android Package Name(例:
アプリストアに公開する
)またはiOS Bundle ID)を入力します。クライアントのブランド化されたアセット(アプリアイコン、スプラッシュスクリーン、ストアスクリーンショットなど)をアップロードします。バージョン番号を設定してから、必要なビルド(Android用のAPKまたはAABファイル、またはiOS用のIPAファイル)を生成します。 com.clientfitness.appクライアントは独自の開発者アカウントを使用してビルドを送信する必要があります。Appleの場合は年間99ドル、
は25ドルの1回限りの費用がかかります。このセットアップにより、アプリがクライアントのブランディング下で公開され、ホワイトラベル構造が維持されます。送信する前に、 Google Play Google Playの内部テストトラック Appleの を使用して、アプリストアに提出する前に、内部テスターまたは外部テスターに配布します。 さらに を活用してベータ版を配布し、すべてが正しく動作することを確認します。特に動的ブランディングは、異なるデバイスでスムーズに動作します。 プラットフォーム間でレビュー時間が異なることに注意してください。
Google Playのレビューは1~7日かかる場合がある レビューは通常1~2日かかりますに達し、 支払い方法 ただし、最大1週間の遅延が発生する可能性があります。提出前に徹底的なテストを行うことで、アプリストアレビュアーとの不要なやり取りを避け、承認プロセスを高速化できます。アプリがライブになったら、Adaloのシステムにより、更新の管理とクライアント固有のブランディングの維持が簡単になります。
アプリがライブになると、Adaloのシステムにより、更新の管理とクライアント固有のブランディングの維持が簡単になります。
クライアント全体でアップデートを管理
Adaloの単一コードベースシステムは、すべてのクライアントアプリのアップデートを簡素化します。コアテンプレートを更新する場合(バグ修正、機能追加、パフォーマンス改善など)、これらの変更はすべてのクローンアプリに自動的に適用されます。アップデートを1回だけ行い、ステージング環境でテストしてから、本番環境にプッシュするだけです。 Adaloのフラット料金体系なら、iOS、Android、PWAに無制限のアップデートを公開でき、追加費用について心配する必要がありません。
クライアント固有のカスタマイズを維持するには、データベース駆動型の動的コンポーネントに依存してください。たとえば、クライアントが 予約スケジューリングなどのユニークな機能が必要な場合、クライアントIDに関連付けられた表示フィルターを使用できます。これにより、その機能は彼らのアプリに限定され、コアテンプレートはクリーンで管理しやすい状態に保たれます。アップデートをデプロイする前に、いくつかのクライアントアプリでテストして、ブランディングとカスタム機能が無傷であることを確認してください。
手元のタスクが緊急かつ重要である場合があります。そしてこれらの場合、すぐに立ち往生したときにすぐに助けを求めるのは理にかなっています。しかし、助けが必要なものは即座に答える必要がないことが可能性があります。問題は、すぐに立ち往生した時点で、タスクがどれほど重要であるかに関係なく、一人で助けたいという自然な衝動があることです。 手動公開コントロールでは、ビルダー内の変更がいつ実装されるかを決定します。これにより、十分にテストし、自分のスケジュールでアップデートをロールアウトする柔軟性が得られ、クライアントのためにすべてがスムーズに実行されることが保証されます。
結論
複数のクライアント向けのホワイトラベルSaaSアプリの作成は、もう複数のコードベースを処理したり、法外なコストを負担したり、長い開発タイムラインに直面する必要がありません。Adaloのインフラストラクチャにより、エージェンシーは1回構築して、単一のスケーラブルテンプレートを使用してウェブ、iOS、Androidにデプロイできます。 Magic Start さらに Magic Add などのツールは開発を加速し、月額$36のフラットレート料金により、コストは予測可能なままです。
このアプローチを区別するのは、それが提供する運用効率です。動的な データベース駆動型ブランディング により、コア機能を再実装することなく、各クライアントのアプリをカスタマイズできます。iOS とAndroidのネイティブアプリストア公開により、アプリはポーランド仕上げで市場対応可能です。追加のモバイル開発は不要です。
Adalo 3.0のリリース以来、 パフォーマンスは大きく向上しました。アプリは3~4倍高速に実行され、月間100万以上のアクティブユーザーにスケーリングでき、1日2000万件のリクエストを処理します。
複数のクライアントアプリを管理するエージェンシーにとって、メリットは明らかです。1つのコードベースは、バグ修正であれ機能追加であれ、どのアップデートもすべてのクライアントアプリに即座に適用されることを意味します。それは効率性であり、簡素化されています。
よくある質問
マルチテナントアプリまたはクライアントごとの個別クローンアプリを使用すべきですか?
ホワイトラベルSaaS ソリューションに関しては、 マルチテナントアプリ がより賢い選択肢であることがよくあります。なぜですか?それは、1つのプラットフォーム内で複数のクライアント向けのサービスを管理およびカスタマイズできるようにします。一方、クライアントごとに個別のクローンアプリを作成すると、各クライアントに対する独立したインスタンスが生成されます。それは魅力的に聞こえるかもしれませんが、すぐに複雑さと増加したコストにつながる可能性があります。マルチテナンシーを選択することで、運用を簡素化し、スケーラビリティを保ち、オーバーヘッド費用を削減できます。
マルチテナントAdaloアプリで各クライアントのデータをプライベートに保つにはどうすればよいですか?
マルチテナントAdaloアプリで各クライアントのデータを安全に保つには、 ユーザーインターフェース用と 慎重に設定する必要があります。機密データへのアクセスを制限することで、適切なユーザーだけが特定の情報を表示または変更できるようにすることができます。 ユーザーロールまたは権限 を設定することが重要です。これにより、特定のデータを表示または編集できるユーザーを制御できます。このアプローチはデータプライバシーを保護し、すべてのクライアント全体でセキュリティを確保します。
スクリーンを再構築せずにクライアントごとのブランディングを処理するのに最適な方法は何ですか?
単一のアプリテンプレートを作成し、各クライアント向けにカスタマイズすることは、アプリ開発を効率化するスマートな方法です。ロゴとカラースキームなどの要素を調整することで、同じコードベースから作業しながら、複数のブランド化されたアプリをすばやく製造できます。このアプローチにより、スクリーンをゼロから再構築する必要がなくなり、時間と労力の両方が節約されます。
関連ブログ記事