Google AppSheetで業務アプリを内製する方法｜Workspaceで始めるノーコード開発ガイド

本記事を読めば、Google AppSheetで部署別の申請・点検・台帳アプリを2〜4週間で試作し、月額SaaSや外注に頼る業務改善費を抑える設計判断ができます。

AppSheetはGoogle Workspaceと相性がよく、情シス・DX担当が現場主導の内製化を始めやすいノーコード基盤です。ただし、データソース、権限、公開範囲を決めずに作ると全社展開で運用が止まります。

AIzen株式会社の業務アプリ開発支援の知見をもとに、継続運用できる設計を解説します。

Google AppSheetで業務アプリを内製化する前提

Google AppSheetで業務アプリを内製化する前に、まず確認すべきことは「作れるか」ではなく「社内で安全に使い続けられるか」です。AppSheetは現場部門が改善に参加しやすい一方、管理ルールが曖昧なまま広がると、情シス側の統制が難しくなります。

特にWorkspace環境で始める場合は、ライセンス、管理者権限、対象業務の選定を最初に整理します。小さく作る段階と、全社で使う段階では見るべき論点が変わります。

AppSheet CoreとEnterpriseで使える機能の違い

Google公式ヘルプでは、AppSheet Coreは多くのGoogle Workspaceエディションに含まれ、Workspace組織内のユーザーがCore機能でアプリを作成・利用できると説明されています。一方、Enterprise Plusは高度な統合、チーム管理、監視、ガバナンスを重視する組織向けです。

判断の目安は、次のように整理できます。

観点	AppSheet Coreで始めやすいケース	Enterprise検討が必要なケース
利用範囲	Workspace内の社員が中心	外部ユーザーや複数組織を含む
業務規模	部署内の申請、点検、台帳管理	全社基幹データや複数部門横断
管理要件	基本的なセキュリティ設定で足りる	詳細なガバナンスや監視が必要
連携先	Sheets、Drive、標準的なデータソース	高度なコネクタや外部DB連携を重視

Workspaceとの連携で前提となる管理権限

AppSheetはWorkspace管理コンソールから組織単位やグループ単位で利用可否を管理できます。情シス・DX担当は、アプリ作成者、公開承認者、データソース管理者を分けます。

Drive上のスプレッドシートや共有ドライブの設定が乱れると意図しない閲覧が起こるため、AppSheetの設定だけでなく、Workspace全体の共有ポリシーと合わせて確認することが重要です。

内製化に向く業務と外注が向く業務

AppSheetの内製化に向くのは、入力項目が明確で、現場の改善サイクルが早い業務です。備品申請、作業日報、店舗巡回チェック、営業訪問記録、案件台帳などが該当します。

複雑な承認分岐、基幹システム連携、大量データ処理、厳格な監査証跡が必要な業務は、外注や専門家支援を組み合わせるべきです。

Google AppSheetのデータソース設計のポイント

AppSheetの成否は、画面よりもデータソース設計で決まります。Google公式ヘルプでは、Google Sheets、Microsoft Excel、AppSheet database、Cloud SQL、BigQuery、MySQL、PostgreSQL、SQL Server、Salesforceなど複数のデータソースが示されています。

最初はスプレッドシートで始めやすいものの、全社利用ではデータ量、更新頻度、権限、他システム連携を踏まえます。試作はSheets、本番は必要に応じてDBへ移すという段階設計が重要です。

スプレッドシートをデータソースにする際の制約

スプレッドシートは初期構築に向いています。現場が列名や入力項目を理解しやすく、既存のExcel管理から移行しやすいためです。ただし、列の追加や名称変更はアプリ側に影響します。

AppSheetはローカルコピーとクラウド上のデータソースを同期する仕組みのため、データ量が増える業務では同期時間や表示対象の整理も必要です。

Cloud SQLや他データベースに切り替える判断

Cloud SQLや他のデータベースに切り替える判断は、件数だけで決めません。承認履歴を残す、部門ごとに閲覧範囲を分ける、基幹システムと連携する、複数アプリで同じマスタを使う場合は、DB化を検討します。担当者名が自由入力、部門名が表記ゆれ、顧客IDが未設定のまま全社展開すると、データ統合に手戻りが出ます。

弊社エンジニアからのコメント：

AppSheet内製化では、最初からCloud SQLにする必要はありません。ただし、複数部署で同じ顧客・案件・社員マスタを参照し始めたら、スプレッドシートを分けて増やすより、主キーと権限を設計したDBに移すほうが運用が安定します。画面より先にマスタの持ち方を決めることが重要です。

データ構造を後から変えにくくならない設計

AppSheetでは後から画面を直しやすい一方、データ構造の変更はアプリ、レポート、集計、権限設定に影響します。顧客ID、社員ID、部門ID、案件IDのようなキー項目は早めに決めます。

備品管理なら、備品マスタ、貸出履歴、利用者マスタを分けておくと、部署別アプリを統合する際にもデータの意味が揃います。

Google AppSheetの権限設計と公開範囲

AppSheetで業務アプリを内製する際、権限設計は後回しにできません。現場では「自分の部署だけで使う」前提で作り始めても、便利になるほど他部署、管理部門、役員へ共有したくなります。

このときに必要なのは、誰が見られるか、誰が編集できるか、誰が設定を変えられるかを分けることです。AppSheetのアプリ設定、データソース側の共有、Workspaceのグループ管理を同時に見る必要があります。

閲覧・編集・管理の権限を分ける設計

権限は最低でも閲覧、編集、管理に分けます。営業案件管理なら、担当者は自分の案件を登録・更新し、マネージャーは部門全体を閲覧し、情シスはアプリ設定を管理します。権限はGoogleグループや組織部門と紐づけると運用しやすくなります。

外部共有が起こりやすい設定の確認

AppSheetは社内外にアプリを共有できるため、外部共有の確認が欠かせません。Workspace組織外のユーザーが関わる場合は、ライセンス、認証、データ閲覧範囲を個別に確認します。元のスプレッドシートやDriveフォルダが広く共有されていれば意図しないアクセスが発生するため、データソース側の権限も同時に見ます。

Workspace全体の権限と整合させる設計

AppSheetの権限設計は、Workspace全体の管理方針と合わせます。退職者、異動者、兼務者のアクセス権が残らないよう、Googleグループや組織部門を使って管理します。

全社展開前に、アプリ一覧、所有者、データソース、利用部署、外部共有有無を棚卸しします。Workspace上の統制と更新手順が揃っていることが内製化継続の条件です。

Google AppSheetとkintone・他社ノーコードの使い分け

業務アプリを内製する際、AppSheetだけで考える必要はありません。kintone、Microsoft Power Apps、Airtable、専用SaaSなど、選択肢は複数あります。既存環境、現場の習熟度、連携先、費用、統制のしやすさで選び分けます。

AppSheetはGoogle Workspaceとの親和性が高く、Sheets、Drive、Forms、Calendarなどを使っている企業では始めやすい選択肢です。一方で、業務プロセス全体をkintone上に集約している企業では、kintoneのアプリ管理やAPI連携を活かすほうが自然な場合もあります。

AppSheetが向く業務とkintoneが向く業務

AppSheetが向くのは、Workspace内のデータを起点に、スマホやブラウザから入力・確認する業務です。現場点検、訪問記録、社内申請、在庫確認、写真付き報告などは相性がよい領域です。

kintoneは、業務プロセスをアプリ単位で整理し、コメント、一覧、承認、プラグイン、JavaScript API、REST APIを組み合わせて拡張したいケースに向きます。

既存システムとの接続性で選び分ける考え方

選定では、今あるデータがどこにあるかを見ます。Google SheetsやDriveに業務データが多いならAppSheet、すでにkintoneで顧客管理や案件管理を運用しているならkintone拡張のほうがデータ分断を避けやすくなります。基幹システムや会計システムと連携する場合は、接続先、同期頻度、マスタの正本を先に決めます。

利用人数とライセンスコストの見方

利用人数が少ない段階では、既存Workspaceに含まれるAppSheet Coreを活用できる可能性があるため、固定費を抑えて試作しやすいです。費用比較では、月額料金だけでなく、運用担当者の工数、外注改修費、データ整理、セキュリティ確認まで含めます。

Google AppSheetを部署単位から全社展開する運用

AppSheet内製化で最も重要なのは、部署単位の成功を全社運用へ広げる手順です。最初のアプリが便利でも、別部署がコピーして独自改修を始めると、データ構造、権限、項目名がばらつきます。

全社展開では、アプリを増やす前に、共通マスタ、命名ルール、管理者、レビュー周期を決めます。内製化を広げるほど、軽量な開発ルールが必要です。

部署単位で作ったアプリを統合する手順

部署単位で作ったアプリを統合するには、まず現状棚卸しを行います。アプリ名、利用部署、所有者、利用人数、データソース、外部共有、更新頻度を一覧化し、残すアプリ、統合するアプリ、廃止するアプリを分けます。統合時には、顧客名、社員名、部門名などの表記ゆれを直し、IDを付与します。

データ構造とアクセス権限の整合性

部署別アプリを全社展開する際に起こりやすい問題は、データ構造とアクセス権限が別々に設計されていることです。スプレッドシートを部署ごとに分けたままでは、全社集計や権限変更のたびに手作業が残ります。共通マスタを持ち、部署、役職、担当者、ステータスに応じて表示範囲を制御します。

内製化を継続するためのレビューサイクル

AppSheetの内製化は、最初の構築よりも運用レビューが重要です。レビューでは、使われていないアプリ、所有者不明のアプリ、共有範囲が広すぎるアプリ、データソースが個人Driveに残っているアプリを確認します。試作段階では週次、本番運用後は月次または四半期ごとに確認します。

まとめ

Google AppSheetは、Google Workspaceを使う企業が業務アプリを内製化するうえで始めやすい選択肢です。AppSheet Coreが多くのWorkspaceエディションに含まれるため、申請、点検、台帳、報告業務を短期間で試作し、SaaSや外注に依存しない改善サイクルを作れます。

要点は3つです。第一に、CoreとEnterpriseの違いを理解し、Workspace管理権限と公開範囲を先に決めることです。第二に、スプレッドシートで試作しつつ、全社利用や複数マスタ連携が見えたらCloud SQLなどのDB化を検討することです。第三に、部署単位で作ったアプリを棚卸しし、データ構造とアクセス権限を揃えてから全社展開することです。

AIzen株式会社では、Google Workspace環境でのAppSheet導入、業務アプリのデータ設計、権限設計、kintoneや既存システムとの使い分け整理まで支援しています。内製化を始めたいが、データソースや公開範囲の設計に不安がある場合は、無料相談で現状業務の整理からご相談いただけます。