ノーコードを使うべきか、フォームと表計算で足りるかを見分ける判断表

困りごと別の判断表

下の表は、編集部が整理した判断の目安です。公式の仕様ではなく、規模や運用で結論が変わります。

• 回答を集めて自分だけが見る、フォーム+表計算のまま：◎ このままでよい、アプリ化を検討：不要
• 回答が増えて探しにくい、フォーム+表計算のまま：○ フィルタや並べ替え、集計用シートで対応、アプリ化を検討：不要
• 申請者が自分の申請状況だけ確認したい、フォーム+表計算のまま：△ シートを共有すると他人の行も見えやすい、アプリ化を検討：◎ 利用者ごとに見える行を制限できる仕組みが必要
• 担当者が「未対応→完了」を更新する(少人数)、フォーム+表計算のまま：○ 担当列とフィルタで回せる、アプリ化を検討：△ 誤編集や上書きが続くなら検討
• 閲覧だけの人と編集できる人を分けたい、フォーム+表計算のまま：△ 共有権限はシート単位で、行や列の細かい制御は難しい、アプリ化を検討：◎ 役割ごとの権限設計が必要
• 選んだ顧客名から住所などを自動で表示したい、フォーム+表計算のまま：△ 数式で作れるが、入力画面は組みにくい、アプリ化を検討：○ 入力画面で参照できる
• 外部の人から回答だけ受け取る、フォーム+表計算のまま：◎ フォームが向く、アプリ化を検討：不要
• 会員登録、ログイン、決済のある独自サービス、フォーム+表計算のまま：× 向かない、アプリ化を検討：◎ ただし難度は別物

読み方のルールは単純です。右列に◎が付く困りごとが1つもないなら、変えません。 ◎があっても、利用が週に数回程度で、利用者が数人なら、まず表の運用ルールで済まないかを先に試してください。

いちばん見誤りやすい「見せる相手を分けたい」

アプリ化の理由として最も強いのは、これです。ただし「画面で隠す」と「そもそも届けない」は別物です。

Bubbleの公式マニュアルは、プライバシールールを「条件を満たす場合にだけ、サーバーがブラウザへデータを送る(または書き込む)仕組み」と説明しています。さらに、要素を非表示にするだけでは、利用者の端末に届いたデータは安全とは言えないという趣旨も書かれています(Bubble Manual: Protecting data with privacy rules)。

Glideも、データを制限したい場合のために「Row Owners(行の持ち主)」という機能を用意しています。公式ヘルプによると、Google スプレッドシート以外のデータ元では複数ロールが使えず、その代わりに Row Owners で各ユーザーが見られるデータを絞ることを勧めています(Glide Help: Does Glide support multiple roles?)。

つまり、「他人の行を見せたくない」という要件があるなら、アプリ化するだけでなく、行単位の制限をツール側で設定できるかが選定の条件になります。見た目だけ非表示にする作り方では、要件を満たしたことになりません。

選ぶツールで変わる前提

同じ「ノーコード」でも、前提は違います。確認できた範囲は次のとおりです。

• AppSheet:Google スプレッドシートやExcelなどのデータから、アプリを作れます。表の1行目に列見出しを置いた整った表が前提です(AppSheet: How to create an app)。今のシートをそのまま土台にしたい場合の候補です。
• Glide:データ元とプランが結びついています。公式の料金案内（2025年11月1日時点）では、Google スプレッドシート対応はMakerプラン以上で、Explorerは Glide Tables のみと記載されています(Glide Help: Pricing Plans)。この案内は2025年11月1日時点の内容なので、現行のプランは契約前に公式ページで確認してください。なお、2024年12月18日以降、旧無料プランでは外部データ元との同期が終了しています(Glide Help: Free plans and external data sources)。
• Bubble:データベースとプライバシールールを自分で設計する前提のツールです。自由度が高い分、初心者が最初の1本に選ぶと、設計の負担が大きくなります。

AIに判断を手伝わせる依頼文

アプリを作る前に、AIには「どの壁に当たっているか」の整理を任せられます。次の依頼文を、そのまま貼り付けられます。

あなたは業務改善の相談役です。
次の運用について、「Googleフォーム+スプレッドシートのまま」か
「ノーコードでアプリ化」かを判断する材料を整理してください。

【運用の概要】(説明用の例を、自分の内容に置き換える)
- 目的:
- 入力する人(人数・外部の人か):
- 見る・更新する人(人数):
- 1か月の入力件数:
- 今いちばん困っていること:

【確認してほしい観点】
1. 「人ごとに見せるデータを変える」必要があるか
2. 「役割ごとに操作を制限する」必要があるか
3. 「入力時に既存データを参照・更新する」必要があるか
4. 表の運用ルールや列の追加だけで解決できないか

【出力形式】
- 観点ごとに「当てはまる/当てはまらない/情報不足」と理由
- 情報不足の場合、私が答えるべき質問
- 最終的な推奨(フォームのまま/アプリ化/まず試作)と、その理由を3行で

氏名や取引先名、実際の申請内容は入れず、「担当者A」「顧客X」のように置き換えてください。

説明用の例

以下は架空の運用で、実際に検証した結果ではありません。

目的:部の備品の貸出管理。入力する人:部員12人。見る人:管理担当2人と、申請した本人。1か月の入力件数:約30件。困りごと:「自分の貸出状況だけ確認したい」という声が出ている。

この例では、観点1(人ごとに見せる範囲)が当てはまります。管理担当が毎回返信すれば表で足ります。本人確認の手間が続くなら、行単位の制限が付くツールで試作する価値があります。一方、貸出件数が月数件なら、アプリ化の維持コストのほうが上回りやすいでしょう。

AIの答えを受けて、人が確認すること

AIの推奨は、判断材料のひとつです。最終判断は、次の点を確認してからにしてください。

1. AIが「アプリ化」と言ったら、使うツールの公式ページで、データ元・権限機能・料金プランを確認します。
2. 権限制限が目的なら、試作後に、管理者とは別のアカウントでログインします。他人の行が見えないことを、実際の画面で確かめてください。
3. 試作は1つの困りごとに絞ります。「貸出状況の確認」だけを作り、うまくいってから広げます。
4. 元の表は残します。アプリを止めても、元のシートとフォームに戻れる状態にしておきます。

最初の判断に迷うなら、この順番が安全です。①右列に◎が付くか、②付くならそれは運用ルールで避けられないか、③避けられないなら1機能だけ試作する。この順で進めれば、作りすぎを防げます。