AppSheetでできないことを機能・デザインなど領域別に解説
「AppSheetで業務アプリを作りたいけど、本当にできるのかな?」 「無料で使えるって聞いたけど、制限が多いんじゃないの?」
このような疑問を抱いていませんか。
AppSheetは、Googleが提供するノーコードツールとして注目を集めています。プログラミング知識がなくても業務アプリを作れる手軽さが魅力です。しかし、実際に導入を検討する際には「できないこと」もしっかり把握しておく必要があります。
本記事では、AppSheetでできないことを機能やデザインなど領域別に詳しく解説していきます。導入前に知っておくべき制約を理解することで、自社の業務に本当に適したツールなのか判断できるでしょう。
なお、AppSheetでは実現が難しい複雑な開発要件がある場合、ノーコード開発に特化したEPICs株式会社にご相談ください。日本最大級の実績を持ち、複数のノーコードツールに対応しているため、開発内容に最適なツールを選定し、費用と開発期間を抑えながら理想のシステムを実現できます。
AppSheetでできないことは何ですか?
主に4つの制約があります。複雑な自動化や高度な計算、大量データ処理などの機能面、完全独自レイアウトや凝ったアニメーションなどのデザイン面、日本語開発環境や複数人同時編集などの開発面、そして複雑なアクセス権限設定などができません。
AppSheetでの開発を避けるべきアプリは?
一般消費者向けアプリ、複雑な業務システム、リアルタイム処理が必要なアプリは不向きです。デザインの自由度が低く、大規模アクセスに対応できないため、社内向けのシンプルな業務アプリに適しています。
AppSheetで開発できない場合の対策は?
他のノーコードツール(Bubble、kintoneなど)で開発するか、フルスクラッチ開発を検討しましょう。要件に応じて最適なツールを選ぶことで、AppSheetでは実現できなかった機能やデザインを実装できます。
AppSheetとは簡潔な身内向けアプリを作れるノーコードツール

AppSheetは、Googleが提供するノーコード型のアプリケーション開発プラットフォーム。プログラミングの知識がない方でも、直感的な操作だけで業務アプリを作成できる点が最大の特徴です。
もともとは独立したサービスでしたが、2020年にGoogleが買収したことで、Google Workspaceの一部として提供されるようになりました。このため、GoogleスプレッドシートやGoogleドライブといった既存のGoogleサービスとスムーズに連携できます。
AppSheetの主な用途は、社内向けの業務アプリ開発。在庫管理や勤怠管理、タスク管理など、日々の業務を効率化するためのシンプルなアプリを素早く構築できるのです。
特に注目すべきは、アプリを公開していない開発段階であれば、10人まで無料で利用できる点でしょう。小規模なチームでまずは試作品を作り、実際の業務で使い勝手を確認してから本格導入を判断できます。
また、用意されているテンプレートを活用すれば、ゼロから設計する必要もありません。業務に合わせてカスタマイズするだけで、短期間でアプリを完成させることが可能です。
ただし、AppSheetはあくまで「簡潔な身内向けアプリ」を作るためのツール。一般消費者向けの洗練されたデザインや、複雑な機能を持つシステムの開発には向いていません。
次のセクションからは、AppSheetでできないことを詳しく見ていきましょう。
AppSheetでできないこと一覧

- 複雑で高度なフローの自動化
- 複雑な計算
- 非常に大きなデータの処理
- 数万ユーザーの同時使用
- オフライン環境での全機能保持
- 複雑なアクセス権限の設定
- 完全独自のレイアウト
- 凝ったアニメーション
- 日本語での開発
- 本格的なバージョン管理
- 複数人での同時開発
AppSheetは手軽に業務アプリを作れる便利なツールですが、ノーコードツールであるがゆえに、いくつかの制約があります。導入前にこれらの「できないこと」を把握しておくことで、後々のトラブルを避けることができるでしょう。
AppSheetでできないことは、大きく分けて4つの領域に分類できます。
まず1つ目は、画面構成やデザインのカスタマイズに関する制約。
用意されたテンプレートの範囲内でしか画面を構成できず、ボタンの配置やレイアウトを自由に変更することはできません。フォントサイズや色の設定も画面ごとに個別調整できないため、デザイン性の高いアプリには不向きです。
2つ目は、自動的な処理の実行に関する制限。
一定時間が経過した後に自動で画面を切り替えたり、画面を自動更新して最新データを表示したりする機能は搭載されていません。ユーザーが手動で操作する必要があります。
3つ目は、データベースの複雑な処理への対応の難しさ。
データ量が増えると同期に時間がかかったり、多対多の関係性を持つような複雑なデータベース設計には向いていなかったりします。また、スプレッドシート上で削除したデータの行自体は残ってしまうという仕様もあります。
そして4つ目が、開発環境や協働作業に関する制約。
開発画面が英語のみで提供されているため、日本語での作業はできません。さらに、複数人が同時に編集作業を行うこともできないため、チームでの同時開発には適していないのです。
これらの制約は、AppSheetが「シンプルで使いやすい業務アプリを素早く作る」というコンセプトに特化しているために生じるもの。
次のセクションからは、各領域の制約について具体例を交えながら詳しく解説していきます。
「受託開発サービス概要」が同梱されたお役立ち資料セット

【機能面】AppSheetでできないこと

AppSheetは業務アプリの作成に便利なツールですが、機能面ではいくつかの制約があります。特に高度な処理や大規模なシステムが必要な場合には、その限界を感じることがあるでしょう。
機能面でAppSheetができないことは以下の通りです。
- 複雑で高度なフローの自動化
- 複雑な計算
- 非常に大きなデータの処理
- 数万ユーザーの同時使用
- オフライン環境での全機能保持
- 複雑なアクセス権限の設定
それぞれ詳しく見ていきましょう。
複雑で高度なフローの自動化
AppSheetには「Automation機能」という自動化の仕組みが用意されています。特定の条件を満たしたときにメールを送信したり、ファイルを自動作成したりすることは可能です。
しかし、高度な自動化には対応していません。たとえば、一定時間操作がない場合に自動でトップページに戻る「自動画面遷移」や、定期的にデータを更新して最新情報を表示する「自動画面更新」といった機能は実装できないのです。
常に最新のダッシュボードを表示し続けたい場合や、タイムアウト処理が必要な場合には、ユーザー自身が手動で操作する必要があります。

通知やアラートでユーザーに行動を促すことはできますが、完全自動化は難しいでしょう。
複雑な計算
AppSheetでは基本的な四則演算や関数を使った計算は問題なく実行できます。しかし、秒単位で変動するような複雑かつリアルタイムな計算には向いていません。
たとえば、為替レートを秒単位で反映した価格計算を行いたい場合、AppSheetだけでは対応が困難です。外部APIから最新のレートを取得して即座に反映させるような高度な処理は、標準機能では実現できないからです。
また、複雑な統計計算や機械学習を用いた予測分析なども、AppSheetの守備範囲外。こうした高度な計算が必要な場合は、外部システムと連携させるか、別のツールを検討する必要があります。
非常に大きなデータの処理
AppSheetは、データソースとしてGoogleスプレッドシートを使用することが多いツール。しかし、スプレッドシートが大きくなると、データの同期に時間がかかってしまいます。
具体的には、数十万行を超えるような大量のデータを扱う場合、動作が遅くなったり、同期エラーが発生したりする可能性があるのです。たとえば、過去10年分の全取引履歴を1つのアプリで管理しようとすると、パフォーマンスの問題に直面するでしょう。
回避策として、AppSheet専用のデータベースである「AppSheet Database」を利用する方法があります。これはスプレッドシートよりも高速な処理が可能ですが、それでも大規模データの処理には限界があることを理解しておく必要があります。
数万ユーザーの同時使用
AppSheetは、主に社内の限られたメンバーで使用することを想定したツールです。そのため、数万人のユーザーが同時にアクセスするような大規模なシステムには適していません。
料金プランによって利用できるユーザー数やデータベースの規模に制限があり、エンタープライズプランでも数百人規模までの利用を前提としています。数千人、数万人が同時にアクセスするような一般消費者向けのサービスを作る場合には、別のプラットフォームを検討すべきでしょう。
また、大量のアクセスが集中すると、レスポンスが遅くなったり、一時的にサービスが利用できなくなったりするリスクもあります。
オフライン環境での全機能保持
AppSheetにはオフラインモードが用意されており、インターネット接続がない環境でもアプリを使用することは可能です。しかし、オフライン時には大きな制約があります。
オフラインモードでは、あらかじめキャッシュ(一時保存)されたデータしか閲覧・編集できません。オフライン中に追加されたデータや、他のユーザーが更新した情報はリアルタイムで反映されないのです。
また、外部サービスとの連携機能や、画像のアップロードなど、インターネット接続を必要とする機能は使えなくなります。

オンラインに復帰した際にデータが同期される仕組みではありますが、完全なオフライン環境での業務には向いていないと言えるでしょう。
複雑なアクセス権限の設定
AppSheetでは、ユーザーごとにアクセス権限を設定する機能が用意されています。たとえば、部署ごとに閲覧できるデータを制限したり、管理者だけが編集できるようにしたりすることは可能です。
しかし、非常に細かく条件を設定した複雑なアクセス制御は困難。たとえば「特定の曜日の特定の時間帯にだけ、特定の担当者が、特定の条件を満たすデータにのみアクセスできる」といった多層的な権限設定を実装するのは難しいでしょう。
また、データの一部のフィールドだけを特定のユーザーに見せたり、特定の行動をしたユーザーにだけ権限を付与したりするような、動的で柔軟なアクセス制御も実現しにくい仕様となっています。
【デザイン面】AppSheetでできないこと

AppSheetは機能面だけでなく、デザイン面でも制約があります。特に見た目の美しさやユーザー体験にこだわりたい場合、その限界を感じることになるでしょう。
デザイン面でAppSheetができないことは以下の通りです。
- 完全独自のレイアウト
- 凝ったアニメーション
順番に解説していきます。
完全独自のレイアウト
AppSheetでは、画面構成やデザインの自由度が非常に低いという特徴があります。用意されているテンプレートやパターンの範囲内でしか画面を作れないため、完全にオリジナルのレイアウトを実現することはできません。
たとえば、ボタンを画面の好きな位置に配置したり、メニューを独自の形状にデザインしたりすることは不可能です。AppSheetが提供する基本的なレイアウトパターンから選択し、その中で調整する形になります。
また、文字の大きさやフォントの種類を変更することは可能ですが、画面ごとに個別の設定を適用することができません。アプリ全体で統一された設定となるため、「この画面だけ大きな文字にしたい」「トップページだけ特別なフォントを使いたい」といった細かい調整は難しいのです。
このような制約があるため、AppSheetは一般消費者向けの洗練されたデザインのアプリには不向き。むしろ、見た目よりも機能性を重視した社内向けの業務アプリに適していると言えるでしょう。
もちろん、不要な部品を削除したり、色合いを調整したりすることで、ある程度は理想のデザインに近づけることは可能です。しかし、ブランドイメージを重視するような対外向けアプリの開発には向いていません。
凝ったアニメーション
現代のアプリでは、ボタンを押したときの動きや画面遷移時のエフェクトなど、さまざまなアニメーションが使われています。これらは見た目を華やかにするだけでなく、ユーザーに「操作が受け付けられた」という安心感を与える役割も果たしているのです。
しかし、AppSheetではこうした凝ったアニメーション効果を実装できません。画面が切り替わる際のスライドアニメーションや、データが更新されるときのフェードイン効果、ボタンを押したときの拡大縮小といった視覚的な演出は、標準機能には含まれていないのです。
また、ローディング画面のカスタマイズも限定的。データを読み込んでいる間に独自のアニメーションを表示させたり、プログレスバーのデザインを変更したりすることは困難です。
このため、AppSheetで作られたアプリは、どうしてもシンプルで素朴な印象になります。「使いやすさ」や「分かりやすさ」を最優先するのであれば問題ありませんが、視覚的なインパクトやブランディングを重視する場合には、物足りなさを感じるかもしれません。
業務効率化を目的とした社内アプリであれば、派手なアニメーションは必要ないことが多いでしょう。しかし、顧客向けのサービスや、マーケティング目的のアプリを作る場合には、他のツールを検討した方が良いかもしれません。
【開発面】AppSheetでできないこと

AppSheetは手軽にアプリを作れる反面、開発プロセスにおいても制約があります。特にチームで開発を進めたい場合や、本格的なシステム開発の経験がある方にとっては、物足りなさを感じる部分があるでしょう。
開発面でAppSheetができないことは以下の通りです。
- 日本語での開発
- 本格的なバージョン管理
- 複数人での同時開発
それぞれ詳しく見ていきましょう。
日本語での開発
AppSheetの開発環境は、すべて英語で提供されています。アプリの設定画面やメニュー、エラーメッセージに至るまで、開発者が目にするインターフェースは基本的に英語のみ。日本語での開発作業はできないのです。
もちろん、完成したアプリ自体は日本語化することが可能です。ボタンのラベルやメッセージ、データの項目名などを日本語で設定できるため、エンドユーザーが日本語で使えるアプリを作ること自体は問題ありません。
しかし、アプリを作る過程では英語の画面を見ながら作業する必要があります。「Database」「Expression」「Automation」といった専門用語が並ぶため、英語に不慣れな方にとっては学習コストが高くなるでしょう。
幸い、2024年3月からAppSheetの公式サポートサイトが日本語に対応しました。困ったときに日本語で情報を調べられるようになったことは大きな進歩と言えます。また、AppSheetの操作自体は直感的に設計されているため、使い続けるうちに英語の開発環境にも慣れてくるはずです。

それでも、日本語環境で開発したい方や、英語に抵抗がある方にとっては、この点がAppSheet導入のハードルとなるかもしれません。
本格的なバージョン管理
一般的なソフトウェア開発では、Gitなどのバージョン管理システムを使って、コードの変更履歴を細かく記録します。いつ、誰が、どこを変更したのかを追跡でき、問題が発生したときに以前のバージョンに戻すことも簡単です。
しかし、AppSheetにはこうした本格的なバージョン管理機能がありません。アプリの変更履歴を詳細に記録したり、特定の時点の状態に戻したりする機能は限定的なのです。
AppSheetでも、過去のバージョンを保存しておく機能は存在します。しかし、変更内容の詳細な比較や、複数のバージョンを並べて確認するような高度な管理はできません。
たとえば、「先週の金曜日の時点に戻したい」「この部分だけ前のバージョンに戻したい」といった細かい操作が難しいのです。また、どの変更がどのような影響を与えたのかを追跡することも困難でしょう。
大規模なシステム開発や、長期間にわたって継続的に改善していくアプリの場合、この点は大きな課題となります。変更履歴をしっかり管理したい場合には、別途、手動でメモを残すなどの工夫が必要です。
複数人での同時開発
AppSheetは、複数人が同時に同じアプリを編集する「リアルタイム共同編集」に対応していません。GoogleドキュメントやGoogleスプレッドシートのように、複数人が同時に作業しながらお互いの変更をリアルタイムで確認することはできないのです。
もし複数のメンバーが同時に同じアプリを編集しようとすると、競合が発生して一方の変更が保存できなくなってしまいます。後から編集した人の作業が無駄になってしまうリスクがあるため、注意が必要です。
このため、チームで開発を進める場合には、担当を明確に分けたり、順番に作業したりする必要があります。「Aさんがデータベースを設定している間に、Bさんが画面デザインを調整する」といった並行作業は基本的にできません。
また、開発の進捗状況を共有することも難しくなります。誰がどこまで作業を進めているのか、どの部分がまだ未完成なのかを把握しにくいため、コミュニケーションコストが高くなる可能性があるでしょう。
小規模なアプリを1人か2人で作る分には問題ありませんが、大人数のチームで大規模なアプリを開発する場合には、この制約が開発効率を下げる要因となります。
AppSheetでは開発を避けるべきアプリ例
ここまでAppSheetでできないことを領域別に見てきました。では、実際にどのようなアプリがAppSheetには向いていないのでしょうか。
導入を検討する際には、これから作りたいアプリの特性をしっかり見極めることが重要です。AppSheetの制約を理解せずに開発を始めてしまうと、途中で行き詰まったり、完成後に期待通りの成果が得られなかったりする可能性があります。
AppSheetでの開発を避けるべきアプリの例は以下の通りです。
- 一般消費者向けに公開するアプリ
- 一定以上複雑な業務システム
- リアルタイムで高度な処理が必要なアプリ
それぞれ具体的に解説していきます。
一般消費者向けに公開するアプリ
AppSheetは、一般消費者向けのアプリ開発には適していません。最も大きな理由は、デザインやユーザーインターフェース(UI)の自由度が低いためです。
一般消費者向けのアプリでは、第一印象が非常に重要。見た目が洗練されていなかったり、操作感が独特だったりすると、ユーザーはすぐに離れてしまいます。ブランドイメージを表現するデザインや、直感的で分かりやすい画面構成が求められるのです。
しかし、AppSheetでは完全にオリジナルのレイアウトを作ることができません。テンプレートベースのシンプルなデザインになってしまうため、他社のアプリとの差別化が難しくなります。また、ボタンの配置を細かく調整したり、画面遷移時のアニメーションを追加したりすることもできないため、ユーザー体験の質を高めることが困難です。
さらに、数万人規模のユーザーが同時にアクセスするようなアプリにも対応していません。AppSheetは社内の限られたメンバーで使うことを想定しているため、大量のアクセスには耐えられない可能性があるのです。
たとえば、ECサイトやSNS、ゲームアプリといった一般消費者向けサービスは、AppSheetでは開発すべきではないでしょう。こうしたアプリを作る場合には、デザインの自由度が高く、大規模なアクセスにも対応できる別のプラットフォームを選ぶべきです。
一定以上複雑な業務システム
AppSheetは社内向けの業務アプリに向いているツールですが、すべての業務システムに対応できるわけではありません。特に、複雑な業務フローや高度なデータ処理が必要なシステムには不向きです。
たとえば、多対多の関係性を持つような複雑なデータベース設計が必要な場合、AppSheetでは対応が難しくなります。顧客と商品、社員とプロジェクトなど、複数のテーブル間で複雑な関連を持たせるような設計は、AppSheetの得意分野ではないのです。
また、数十万行を超えるような大量のデータを扱う必要がある場合も注意が必要。過去10年分の取引履歴を一元管理したり、全国の店舗の在庫データをリアルタイムで集約したりするようなシステムでは、パフォーマンスの問題に直面する可能性があります。
さらに、複雑な権限設定が必要な業務システムにも向いていません。部署や役職、プロジェクトごとに細かくアクセス権限を制御したい場合、AppSheetの標準機能だけでは実現が困難でしょう。
基幹系システムや大規模な販売管理システム、複雑なワークフローを持つ承認システムなどは、AppSheetよりも専門的な開発ツールやスクラッチ開発を検討した方が良いかもしれません。

AppSheetは、あくまで小規模から中規模の比較的シンプルな業務アプリに適したツールです。
リアルタイムで高度な処理が必要なアプリ
リアルタイム性が求められるアプリや、高度な計算処理を必要とするアプリも、AppSheetには不向き。このようなアプリでは、瞬時にデータを処理して結果を表示する必要がありますが、AppSheetはそこまでの処理速度を持ち合わせていません。
たとえば、株価や為替レートを秒単位で取得して自動計算するようなアプリは、AppSheetでは実現が困難です。外部APIから最新データを取得し、それを即座に画面に反映させるような高速処理は、標準機能では対応できないのです。
また、複雑な統計分析や機械学習を用いた予測システムも、AppSheetの守備範囲外。大量のデータを瞬時に分析して結果を出すような処理は、より高性能なシステムが必要となります。
さらに、一定時間ごとに自動で画面を更新したり、データの変更をリアルタイムで反映したりする機能も限定的です。たとえば、ダッシュボードを常に最新の状態に保ちたい場合でも、ユーザーが手動で更新ボタンを押す必要があります。
リアルタイムチャットシステムや、IoT機器からのデータを瞬時に可視化するモニタリングシステム、金融取引システムといったアプリは、AppSheetでは開発を避けるべきでしょう。こうしたアプリには、より高度な開発環境とインフラが必要になります。
「受託開発サービス概要」が同梱されたお役立ち資料セット

AppSheetでは開発できない時の対策

他のノーコードツールで開発する
AppSheetでは実現が難しい機能があっても、他のノーコードツールなら対応できる可能性があります。ノーコードツールにはそれぞれ得意分野があり、AppSheetとは異なる強みを持つツールが数多く存在するのです。
たとえば、デザインの自由度を重視するなら、Bubble(バブル)というノーコードツールが選択肢となります。Bubbleは一般消費者向けのWebアプリケーション開発に強く、レイアウトやデザインを細かくカスタマイズできる点が特徴です。
また、業務アプリの開発に特化したツールとしては、kintone(キントーン)やPower Apps(パワーアップス)などが挙げられます。これらはAppSheetと同じく社内向けの業務効率化アプリを作るためのツールですが、それぞれ異なる機能や料金体系を持っています。
大量のデータを扱う必要がある場合には、データベース機能が充実したツールを選ぶべきでしょう。複雑なデータ構造に対応できるツールや、高速な処理が可能なツールを検討することで、AppSheetでは難しかった要件を満たせるかもしれません。
ノーコードツールを選ぶ際のポイントは、自社の要件を明確にすることです。「デザインにこだわりたいのか」「データ量が多いのか」「複雑な権限設定が必要なのか」といった優先順位を整理したうえで、それに適したツールを選択しましょう。

複数のノーコードツールを比較検討することで、AppSheetでは実現できなかった理想のアプリを作れる可能性が広がります。
フルスクラッチで開発する
ノーコードツールでは対応できない高度な要件がある場合、フルスクラッチ開発を検討する必要があります。フルスクラッチ開発とは、既存のツールやプラットフォームに頼らず、プログラミングによってゼロからシステムを構築する開発手法のこと。
フルスクラッチ開発の最大のメリットは、完全な自由度です。デザインも機能も、すべて要件に合わせて自由に設計できます。AppSheetでは不可能だった複雑なデータベース設計や、リアルタイム処理、高度なセキュリティ設定なども、技術的には実現可能です。
また、将来的な拡張性も高くなります。ビジネスの成長に合わせて機能を追加したり、ユーザー数が増加しても対応できるようスケールアップしたりすることが容易になるのです。
ただし、フルスクラッチ開発にはデメリットもあります。まず、開発コストが高額になる点。専門的なエンジニアを雇用したり、外部の開発会社に依頼したりする必要があるため、ノーコードツールと比べて数倍から数十倍の費用がかかることも珍しくありません。
また、開発期間も長くなります。AppSheetなら数週間で完成するアプリも、フルスクラッチで開発すると数ヶ月から1年以上かかることがあります。市場の変化が速いビジネスでは、このスピード感の違いが大きな問題となるでしょう。
さらに、完成後の保守・運用にも継続的なコストがかかります。システムの不具合修正やセキュリティアップデート、新機能の追加など、技術的な知識を持った人材が必要になるのです。
フルスクラッチ開発を選択する際には、本当にそこまでの投資が必要なのか、慎重に検討する必要があります。予算や開発期間、求める機能のバランスを考えたうえで、最適な開発手法を選びましょう。
なお、「AppSheetでは難しいが、他のノーコードツールなら実現できるかもしれない」という中間的な選択肢も忘れてはいけません。いきなりフルスクラッチに飛びつくのではなく、段階的に検討することをおすすめします。
AppSheetでアプリを開発するならEPICs株式会社
AppSheetでの開発を検討されている方、あるいはAppSheetでは実現が難しい機能があってお困りの方は、ぜひEPICs株式会社にご相談ください。
EPICs株式会社は、AppSheetをはじめとする複数のノーコードツールに特化したプロフェッショナル集団として、日本最大級の開発実績を誇るノーコード開発会社です。これまで150件を超えるアプリ・システムの開発実績があり、お客様の多様なニーズに応えてきました。
AppSheetは便利なツールですが、本記事で解説したように機能やデザイン面でいくつかの制約があります。弊社では、お客様の要件をしっかりとヒアリングしたうえで、AppSheetが最適なのか、それとも他のノーコードツールの方が適しているのかを的確に判断。Bubble、kintone、Adaloなど、複数のノーコードツールに対応しているため、開発したい内容に対して最適なツールを選定し、費用と開発期間を抑えながら理想のシステムを実現いたします。
また、企画から設計、開発、そして導入後のサポートまで一貫して対応しております。「AppSheetで始めたいけど、本当に要件を満たせるか不安」「途中で別のツールに切り替える必要が出たらどうしよう」といった懸念がある方も、安心してお任せください。
定期的なアップデートやトラブル時の迅速対応など、導入後のサポート体制も万全です。最安30万円、最短2週間から開発可能ですので、まずはお気軽にご相談ください。お客様の予算と希望に合わせた最適なプランをご提案いたします。
1からの開発も、途中からの開発も、お気軽にEPICsにご相談ください!