ノーコードアプリ開発：少人数チーム向け4選

ノーコードでのアプリ開発では、チームの業務フローにはAppSheet、Web・モバイル向けのプロダクトにはBubble、既存データと連携するアプリにはSoftr、コードのエクスポートを重視するならWeWebを検討してみてください。どれを選ぶかは、誰がアクセスする必要があるか、アプリの運用にいくらかかるか、乗り換え時に何を移行できるかによって変わります。

ノーコードアプリ開発の基本

アプリの動作を支えるコードを書かなくても、視覚的に操作できるツールでアプリを作れます。Microsoft（新しいタブで開きます）は、ノーコードアプリビルダーを、コードの書き方を知らなくてもアプリを作成できる開発ソフトウェアと定義しています。作業の中心は、アプリをどう動かすかを決めることに移ります。

まずは業務上のニーズから考えましょう。従業員の業務フローと顧客向けプロダクトでは、アクセス、サポート、公開に求められるものが異なります。ここでのおすすめは調査に基づくもので、実際に使って検証した結果ではありません。

選んだツールは業務上のニーズに沿って、チームの業務、顧客向けプロダクト、既存データを活用するアプリ、コードの所有権の順に紹介します。この順序が大切なのは、ある用途にはよく合うツールでも、別の用途では維持費が高くなることがあるためです。あらゆる用途で最適なツールはありません。

上記のAppSheet（新しいタブで開きます）の区分は料金ページに基づいており、そこでは無料のテストとPublisher Proが区別され、Publisher Proのアクセス制限も示されています。Bubble（新しいタブで開きます）の料金ページには、従量課金制と、Web、iOS、Androidアプリへの対応が記載されています。SoftrとWeWebは、最新の利用条件が要件に合うと確認できるまでは、条件付きの候補です。

アプリ開発プラットフォームを選ぶ前に、そこで扱う情報を明確に把握しておく必要があります。データとは、アプリが読み取ったり変更したりする記録やファイルのことです。こうした記録を自社で管理するアカウントに保管しておくと、所有権を管理しやすくなりますが、それだけではアプリ内で誰が閲覧できるかは決まりません。

• データの計画では、記録の保存先、保存元アカウントの所有者、バックアップの仕組みを明確にします。
• 業務フローの計画では、何をきっかけに処理が始まるか、何が変更されるか、失敗した場合にどうなるかを定めます。
• アクセスの計画では、それぞれの人がどの記録を閲覧・変更できるかを定めます。
• 乗り換えの計画では、何をエクスポートできるか、何を作り直す必要があるかを明確にします。

アクセスには特に注意が必要です。ボタンを非表示にしても画面の見え方が変わるだけで、その背後にある情報が保護されている証明にはなりません。非公開のレコードには、データを取得・変更する段階で権限を適用する必要があります。サインインは本人を確認するもので、権限はその人に何ができるかを決めるものです。

画面が動くようになっても、運用上の課題は残ります。操作が失敗したときの対応、アカウントの復旧、連携先サービスの変更には、誰かが責任を持つ必要があります。小規模なチームでは、最初の画面をどれだけ早く形にできるかよりも、その責任のほうが重要かもしれません。

プラットフォームが業務の流れに合い、継続的な費用を負担できるなら、ノーコードアプリ開発は妥当な出発点です。その代わり、そのプラットフォームのルールやサービスに依存することになります。候補を絞る際は、見た目の完成度よりも先に、必須機能、アクセス制御、他への移行手段を判断基準にしましょう。

チームの業務フローに使うAppSheet

スタッフ向けのツールなら、AppSheetを試験導入する価値があります。本格導入を決める前に、少人数でテストできるからです。AppSheetの料金ページによると、プラットフォームの機能を試したり、最大10人のユーザーでアプリをテストしたりすることが無料でできます。業務の流れを確認するには役立ちますが、本番公開時の費用がこれでわかるわけではありません。

一般公開アプリの料金には注意が必要です。AppSheetでは、Publisher Proはアプリ1つあたり月額50米ドルで、ユーザー数は無制限と案内されています。同じページには、これらのアプリにCoreの機能は含まれるものの、ユーザーのサインインとセキュリティフィルターは含まれないと記載されています。

セキュリティフィルターは、アプリがユーザーに提供するレコードを制御するものです。サインインとこのフィルターがないため、Publisher Proは、特定の顧客や従業員だけが閲覧できるようにする必要があるレコードには適していません。ユーザー数が無制限でも、このアクセスの問題は解決しません。

サインインが必要なアプリについて、AppSheetはGoogleやMicrosoftなどのプロバイダーを通じた認証に対応すると記載しています。認証とは、ユーザーが本人であることを確認することです。そのユーザーがどのレコードにアクセスできるかを確定するには、別途、権限の確認が必要です。

実用上の違いは、誰がアプリを使えるかという点にあります。一般公開の情報やサービスなら、身元を把握する必要がない人にも提供できます。非公開の顧客向けポータルには、サインインした人と、その人がアクセスを許可されているレコードとの確実なひも付けが必要です。ユーザーごとの料金を避けるために一般公開を選んでも、この要件は満たされないままです。

最初に取り組むべきなのはテストです。AppSheetが示すテスト利用の範囲内で、担当業務や必要なアクセス権が異なる人にも試験導入に参加してもらえます。有用な成果となるのは、各役割の人が、閲覧を制限された情報を見ることなく、自分の業務を完了できるという証拠です。

• 権限のあるユーザーが、業務に必要なレコードを閲覧・更新できます。
• アクセスを制限されたユーザーは、検索や直接リンクから非公開のレコードを取得できません。
• 削除されたユーザーは、意図したとおりにアクセスできなくなります。
• 更新が失敗した場合も状態が明確に残り、スタッフが再試行すべきかどうかを判断できます。

運用コストは別途確認が必要です。ログインが必要なアプリ向けのプラン、ライセンスのルール、連携サービスの料金によって、継続的に支払う金額が決まります。日付入りの見積書には、通貨と請求条件を明記してもらいましょう。事業でカナダドルを使って支払う場合は、特に重要です。掲載されているPublisher Proの金額だけでは、非公開アプリの費用はわかりません。

スタッフがそのツールを頼りにするようになる前に、利用をやめる際の確認もしておくことが大切です。データのエクスポートとは、記録を使える形式で取り出すことです。画面やワークフローのルールも一緒に移せるとは限りません。データ元のアカウントは会社で管理し、アプリがどのように動作するかを記録しておきましょう。

• データの所有者が、特定の従業員の個人アカウントに頼らずに、記録や添付ファイルを取り出せます。
• エクスポートしても、関連する記録同士のつながりが保たれます。
• 将来の作り直しに備えて、チームが権限設定と自動化のルールを文書化しています。
• 業務情報を失わずに、連携サービスのアカウントを移管したり、別のアカウントに置き換えたりできます。

スタッフの業務フローがAppSheetのツールに合い、ログインが必要なアプリの導入・運用コストもチームにとって妥当なら、AppSheetは有力な候補になります。Publisher Proは別の判断で検討するプランで、誰でもアクセスできる状態を許容できる場合に適しています。

Web・モバイル向けプロダクトのためのBubble

顧客向けプロダクトでは、公開計画にWebアプリやモバイルアプリが含まれるなら、Bubbleは検討する価値があります。Bubbleの料金ページには、Web、iOS、Android向けの開発に対応していると記載されています。適しているかどうかは、必要な公開先をカバーするプランを選び、アプリが消費するリソースを測定したうえで判断します。

使用量のメーターに目を向けましょう。Bubbleは従量制の料金体系を採用していると説明しているため、アプリが消費するリソースが請求額に影響します。ユーザー数だけでは、費用の全体像はわかりません。

Bubbleの料金ページでは、ワークロードユニット（WU）とAIクレジットを区別しています。ワークロードユニットは、アプリのホスティングと実行に必要な通常のサーバー処理量を測る指標です。一方、AIクレジットは、AIを使った機能の使用量を測る指標です。これらは別々の指標なので、AIの利用枠を見ても、通常のアプリ処理がどれだけ含まれているかはわかりません。

通知が届く基準も重要です。Bubbleの料金ページによると、アプリの使用量が利用枠の100%に達し、超過分の利用が始まるとメールが届きます。このメールは予算に関する警告であり、支出が止まったことを示すものではありません。

使用量のアラートを誰が受け取り、誰が対応できるのかを、チームで把握しておく必要があります。誰も確認しない受信トレイに請求関連の通知が届いても、ほとんど歯止めになりません。利用できる支出管理機能と、それがアプリの利用可否に与える影響は、公開前に確認しておきましょう。

料金を公平に比較するには、公開に関する条件もそろえる必要があります。Web専用のプランと、モバイルアプリの公開も含むプランでは、満たすニーズが異なります。月払いと年間契約では、どちらも月額で表示されていても、支払いの義務が異なります。

これらの項目がそろうまでは、目立つところに表示された価格が安くても、運用コストが低いとはいえません。信頼できる見積もりは、該当するプランと、実測したアプリの稼働状況に基づいて算出します。アプリ作成ツールとは別に請求されるサービスの費用も見込んでおきます。

役に立つ試験運用では、顧客が実際に行う作業を測定します。サーバー処理とは、情報の取得や更新など、画面の裏側で実行される作業のことです。見た目がシンプルな画面でも、大量の処理が発生することがあります。そのため、機能のチェックリストよりも、実際に使うワークフローで試すほうが、コストを適切に検証できます。

1. 個人情報を含まないサンプルデータを使い、顧客が行う一連の作業を最初から最後まで実行できるワークフローを1つ作ります。
2. 操作が成功した場合と失敗した場合の両方で、処理量を測定します。
3. 公開時に想定されるレコード数で、もう一度テストします。
4. 測定した処理量と現在のプラン条件を使って、通常の月と利用が多い月の費用を見積もります。

移行のしやすさは、別途評価する必要があります。データのエクスポートで対象となるのは、レコードとファイルです。アプリのロジックの移行で対象となるのは、権限や操作、計算を制御するルールです。一方を移行できるという証拠があっても、もう一方も移行できるとは限りません。

• エクスポートの対象に、必要な業務レコード、ファイル、それらの関連付けが含まれています。
• プラットフォームの現在の利用条件に、利用をやめた場合にアプリのロジックがどうなるかが説明されています。
• 自社でドメインと連携サービスのアカウントを管理しています。
• 移行先への切り替え計画で、どの画面、権限、ワークフローを作り直す必要があるかを明確にしています。

Bubbleは、公開方法の選択肢がプロダクトに合い、測定した利用量で予算内に収まるなら、有力な候補です。運用費を固定する必要がある場合や、アプリ全体を移行できることが必須の場合は、採用を決める前にその要件を満たせるか確認する必要があります。

既存データを使うアプリ向けのSoftr

すでに管理しているレコードを中心にポータルを構築するなら、Softrは候補に入れる価値があります。Zapier（新しいタブで開きます）によると、Google SheetsやAirtableを含む50以上のサービスとの連携に対応しています。そのため、条件次第で適した選択肢となりますが、判断の決め手はアクセス制御とユーザーにサービスを提供するためのコストです。

まずは既存のレコードから確認しましょう。連携すれば情報を別のシステムに移す手間を省けますが、現在のデータが抱える問題もアプリに持ち込むことになります。重複したデータやアカウント名の表記の不一致があると、画面が完成して見えても、ポータルの信頼性が損なわれることがあります。

データの確認を始めるには、Google Sheetsが役立ちます。各レコードには、位置が変わってもそのレコードに紐づいたまま変わらない値、つまり固定の識別子が必要です。行が移動したり削除されたりすると、行番号だけではその役割を果たせません。各レコードに誰がアクセスできるかを確実に特定する方法も必要です。

限られた人だけがアクセスできるかどうかの検証が、判断の決め手になります。サインインは利用者が誰なのかを確認するもので、権限はその人が何を閲覧・変更できるかを決めるものです。ボタンが非表示になっているだけでは、その先にあるレコードが保護されている証拠にはなりません。

有料プランを選ぶ前に、現在の公式の利用条件で次の点を確認する必要があります。

• プランにアプリで必要なデータ連携が含まれており、その上限が想定するレコード数に対応しています。
• 利用可能なユーザー数の条件に、スタッフと外部の顧客をどのように数えるかが説明されています。
• アクセス制御によって、レコードにアクセスできる人や組織を適切に限定できます。
• 公開に関する条件が、本番アプリとドメインに関する要件を満たしています。

プラン名だけでは判断できません。購入の判断には、Softrの現在の公式料金表と購入手続き画面に表示される価格と利用枠を使い、確認日、通貨、請求期間も記録しておきましょう。これらの詳細を確認するまでは、月額予算を確定するのは時期尚早です。

連携には、それ自体のコストもかかります。データソースの有料アカウントを維持する費用を予算に含める必要があるかもしれませんし、自動化を追加すると別のサブスクリプションが必要になる場合もあります。誰が責任を持つかも重要です。連携によるレコードの更新が止まったときに、誰かが気づけるようにする必要があります。

既存のデータソースにレコードを保持しておくと、移行作業の一部を簡単にできます。ただし、画面や権限ルールも一緒に移せるとは限りません。データの所有権とアプリの移行可能性は、別々に確認する必要があります。

移行に備えた確認では、次の点を押さえておきましょう。

• 自社でデータソースのアカウントを管理し、そのレコードと添付ファイルをエクスポートできること。
• 関連するレコードを再び結び付けるために必要な識別子が、エクスポート時に保持されること。
• インターフェースとワークフローのルールについて、何を持ち出せるかがプラットフォームの規約に説明されていること。
• 乗り換え計画で、権限と連携している自動化処理が考慮されていること。

既存のデータ構造がすでに業務に合っているなら、手の込んだ開発に進む前にSoftrを検討するとよいでしょう。権限の設定に無理のある回避策が必要だったり、大規模なデータ整理が必要だったりする場合は、すぐに使える接続機能の便利さも、それほど大きな利点ではなくなります。

コードのエクスポートならWeWeb

コードの所有権を要件として重視するチームなら、WeWeb（新しいタブで開きます）は検討する価値があります。コードのエクスポートとセルフホスティングに対応していると案内しているためです。セルフホスティングとは、自分たちで管理するインフラ上でアプリを動かすことです。選択肢が増える一方で、責任も増えます。

WeWebの比較記事では、Essentialは年払いで月額20と記載されており、コードのエクスポート、セルフホスティング、GitHubとの同期、WeWeb cloudでの無制限のセッションが追加されると説明されています。この金額を予算に使う前に、通貨と現在の購入条件を確認する必要があります。公開にかかる費用の総額ではなく、確認の出発点となる情報として扱いましょう。

請求の頻度は重要です。年間プランの月額換算額が示されていても、その金額を毎月支払えるとは限りません。見積もりには、定期料金の換算額と購入時に実際に支払う金額の両方を明記する必要があります。

エクスポートは始まりにすぎません。アプリは、レコードや、ユーザーのサインインなどの処理を担うサービスにも依存しています。インターフェースを移しても、こうした依存先が自動的に移るわけではありません。

コードの保存と変更履歴の追跡ができるサービスであるGitHubは、エクスポートしたコードの履歴を残すのに役立ちます。リポジトリがあるだけでは、別の開発者がそのアプリを動かせる証拠にはなりません。引き継ぎには、手順書と、アプリが使うサービスに接続するための設定も必要です。

有意義なエクスポートテストでは、元のエディターの外にデプロイして、実際に動作する状態にします。フォルダーをダウンロードすれば、ファイルが存在することは確認できます。実行すれば、運用に必要なものがそろっているかどうかが分かります。

1. 購入予定のプランでテスト版をエクスポートします。
2. 文書化された手順に従って、別の環境にデプロイします。
3. テストデータを接続し、サインインとレコードの権限を確認します。
4. 画面を変更して再デプロイし、どの作業に引き続きビルダーが必要なのかを記録します。

その運用作業には、責任を持つ担当者が必要です。自分たちでホスティングする場合は、更新の手配やバックアップの確認、アプリの配置・公開に失敗したときの対応が必要になることもあります。技術サポートのない小さなチームでは、こうした業務の負担が、すぐにホスティング先を移すメリットを上回るかもしれません。

利用量についての説明にも、同じ注意が必要です。WeWebによると、同社が提示するEssentialプランには、WeWebクラウド上での無制限のセッション利用が含まれています。この記述だけでは、アプリに接続するサービスの上限や料金はわからないため、運用予算にはそれらのサービスを別々に記載する必要があります。

この選択肢を最後に紹介したのは、別の環境へ移せることが特定の購入要件であり、その価値はチームのニーズによって変わるからです。ノーコードアプリ開発では、書き出したものを活用できる人がいてこそ、エクスポートの価値が最も高まります。運用をすべて任せたいチームにとって、当面のメリットは、将来ほかへ移る選択肢を残しておけることかもしれません。

無料プランの先を見据えた予算

公開時の予算には、きちんと動作し、サポートを受けられるアプリと、そのアプリが依存するサービスの費用を含める必要があります。無料で試せる範囲からわかるのは、支払う前に何を試せるかだけです。本番公開や、顧客だけがアクセスできるようにするための費用まではわかりません。

まずは対象範囲を決めます。公平に比較するには、どのプラットフォームでも同じ利用対象者と公開要件を使います。スタッフ向けツールと顧客ポータルでは、画面が似ていても、アクセスやサポートに求められるものが大きく異なる場合があります。

どの見積もりにも、日付、通貨、請求期間を併記する必要があります。米ドル建ての請求書で支払うカナダの企業では、銀行口座から出ていく金額が、為替レートや決済手数料によっても変わります。年間契約は、資金計画に独立した項目を設ける必要があります。

下のワークシートでは、通常の月額費用と、公開前に支払う金額を分けています。空欄は、見積もりで提示された金額や実測に基づく推計額で埋めていきます。不明な費用は、不明と明記したままにしてください。

月額の合計は、無理なく負担できるかを判断するのに役立ちます。支払額を見れば、公開に必要な資金を用意できるかがわかります。年間の利用契約は、月額費用として見る場合、年間料金を対象月数で割って計上します。一方、資金の出入りとして見る場合は、支払期日に全額を計上します。

二重計上を避けましょう。アプリ作成ツールの利用料金に含まれるホスティングを、別のホスティング料金としても計上してはいけません。連携先のデータサービスの利用料金をすでに会社で支払っている場合も、その旨を記載しておきましょう。アプリで使うことで、その契約を解約しにくくなる可能性があるためです。

増加の見積もりは、各サービスの課金方式に合わせる必要があります。登録ユーザーが増えると利用人数に応じたプランに影響する可能性があり、レコードの更新を繰り返すと従量料金や自動化の料金に影響する可能性があります。一律の増加率を当てはめると、料金区分の変更を見落とすことがあります。

見積もりに役立つ情報は、試験導入と運用計画から得られます。

• アクセスが必要な人数と、サービス提供元による人数の数え方。
• ワークフローが完了するまでに発生する処理量。失敗した試行も含めます。
• レコードに必要なストレージ容量と添付ファイルの量。
• チームで対応できるサポート業務と、有料で依頼する必要がある業務。

誰もコードを書かない場合でも、保守の予算は必要です。権限の変更や接続の有効期限切れは、独自開発のソフトウェアと同じように、視覚的な操作で作ったアプリも中断させることがあります。サポート契約では、障害を調査する担当者と、追加料金がかかる変更を明確にする必要があります。

価格面で最も適したアプリ開発プラットフォームは、運用コストの総額が業務に見合うものです。繰り返し発生する手作業をなくせるなら、サブスクリプション料金が高めでも妥当な場合があります。必須のアクセス制御やサポートが見積もりの範囲外なら、導入時の価格が安くても、その利点は小さくなります。

アプリ開発プラットフォームを選びましょう

試験導入で、チームが実際のワークフローを安全に完了できると確認できれば、候補の絞り込みから選定へと進めます。適切なアプリ開発プラットフォームは、運用予算内でその確認をクリアでき、レコードの復元とサービスからの移行にも実行可能な手段があるものです。

小さく始めましょう。試験導入には、サンプルのレコードから機密情報を取り除いたうえで、すでに行っている業務を使えます。見栄えのよい画面が成功の基準にならないよう、構築を始める前に期待する結果を書き出しておきましょう。

それぞれの確認は前の確認を前提とするため、次の順序で進める必要があります。権限を評価する前に、ワークフローが正しい結果を出せる必要があります。また、顧客のレコードを安心して任せるには、先に復元を確認することが重要です。

1. サンプルデータを使って、ワークフローを1つ、最初から最後まで構築します。チームが業務で必要とする承認や通知も含めて、既存の業務を最初の入力から最終結果までたどりましょう。
2. 想定する役割ごとに別のアカウントを使い、権限をテストします。ボタンを隠しても、その先にある情報が保護されている証明にはならないため、表示される画面だけでなく、直接リンクやレコードの検索も確認しましょう。
3. 操作が失敗する場合や、繰り返される場合をテストします。接続が中断したり、送信を繰り返したりしても、気づかないうちに変更が失われたり、作業が重複したりすることなく、結果が明確にわかる必要があります。
4. バックアップからサンプルのレコードを復元します。バックアップ成功のメッセージも役立ちますが、安全なテスト環境にレコードを復元すれば、復元手順が実際に機能するかどうかを確認できます。
5. 試験導入で作ったものをエクスポートし、プラットフォームから何を取り出せるかを調べます。レコードと添付ファイルをアプリのコードとは別に確認し、ほかの環境で再構築が必要になる接続や設定を洗い出しましょう。
6. 日々の運用を担当する人に、構築担当者の助けを借りずにワークフローを実行してもらいます。未解決の問題を記録し、操作の失敗、アカウントの変更、継続的なサポートに誰が対応するかを確認しましょう。

結果は具体的な形で残しましょう。権限テストのスクリーンショット、復元したサンプルのレコード、内容を確認済みのエクスポートデータは、単に「アプリは動く」と書いたメモよりも確かな証拠になります。進められない作業には、リリース前に必ず担当者を決める必要があります。

判断は証拠に基づいて行い、不具合の種類に応じて結論を変える必要があります。

土台がニーズに合っていて、残る不具合の修正方法が明確なら、私たちは修正をおすすめします。必須要件がプラットフォームの機能では満たせない場合は、再構築のほうが理にかなっています。すでにお金をかけたからといって、必要なアクセス制御がない状態を許容できるわけではありません。

当社のAppDesign360 AI App Review & Launchサービスでは、AIで作成したアプリを対象に、有料でプロダクトとコードをレビューし、調査結果と、現状維持・修正・再構築のいずれかの推奨方針を書面にまとめます。実装の範囲は別途定めます。ノーコードアプリの場合は、まず、お使いの開発ツールが対応対象かどうかと、そのアクセス・エクスポート機能で何を確認できるかを確かめる必要があります。

プラットフォームが提供していないソースコードへのアクセスを、レビューで保証することはできません。レビューで役立つ成果は、何が機能していて、何が未確認で、公開前に何を変える必要があるかをまとめた書面です。それをもとに、必要な予算を見込んで判断できます。

https://appdesign360.com/contact からプロジェクトについてご相談いただくと、レビューがお使いのアプリと開発ツールに適しているかを確認できます。

押さえておきたいポイント

よくある質問