AppSheetのシステム開発は、要件整理から定着まで6フェーズを順に進めます。途中で利用範囲を段階的に広げながら、現場で使い続けられる業務アプリに仕上げていきます。
全体像は、AppSheetのシステム開発の完全ガイドで詳しく確認できます。
▼全体ガイドの記事
・AppSheetのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
AppSheetのシステム開発の全体像
AppSheetは業務アプリを作れるサービスです。データソースには、Google SheetsやExcelを使えます。Google DriveやAppSheet Databaseも選べます。
接続先の候補には、SQL ServerやMySQL、PostgreSQLが入ります。さらに、Oracle、BigQuery、Salesforceも候補で、ODataにも接続できます。
アプリはスマートフォン、タブレット、ブラウザで利用できます。画面は、フォームや一覧、詳細で組み立てられます。ダッシュボードも加えられます。
写真、位置情報、署名などを組み合わせられるほか、バーコードやオフライン同期にも対応します。記録から通知や帳票作成までを、一つの業務フローにできます。
AppSheetで作りやすい業務システム
AppSheetは、決まった項目を入力したあとに承認、通知、帳票出力が続く業務に向いています。まず現場の定型入力から始めると、業務フローを整理しやすくなります。
- 記録：営業訪問記録、現場日報、設備点検
- 在庫・取引：在庫・棚卸、受発注、配送進捗
- 受付・承認：問い合わせ管理、申請・承認
このほか、写真や位置情報を記録する業務、通信が不安定な外出先で入力する業務、入力後に管理者への通知が要る業務とも相性があります。
会計や給与のように法令や専門機能が中心の業務は、AppSheet単体で置き換えない判断が要ります。複雑な取引や、多数の利用者が扱う大量データにも注意が要ります。
画面や性能を作り込む必要がある業務は、単体で無理に実装しない選択肢があります。そのため、役割を分ける設計が現実的です。
たとえば、定型的な現場入力はAppSheetで扱い、正規化データや高負荷の処理はCloud SQLやBigQuery、既存の基幹システムに担わせます。
システム開発でのアプリ以外の設計
画面や式は短期間で作れるため、見える部分の完成度だけで評価しがちです。実務では、周辺の設計が不足すると運用停止につながる場合があります。
- データ管理：マスタの管理者とデータの正を決める
- 権限・所有権：利用者ごとのロールと、アプリの所有者
- 継続運用：変更履歴、バックアップ、問い合わせ窓口の整備
周辺の設計が抜けると、誤入力を戻せない、同期に時間がかかる、閲覧範囲が曖昧といった問題が起こり得ます。
退職者が所有者のままだと、アプリの管理が途切れるおそれがあります。そのため、開発の開始時に利用者とロール、所有権を決めておきます。
Google Sheetsを使う場合も、1枚にすべてを詰め込むと管理が難しくなります。そこで、顧客や担当者、商品の表と、取引、履歴、添付ファイルの表を役割ごとに分けます。
データ量や同時利用者が増える場合は、AppSheet DatabaseやCloud SQLを検討します。将来の移行条件も、要件に含めておきます。
AppSheetの開発は、アプリを作るだけで終わりません。業務とデータを、運用が続く形に整えるプロジェクトです。
AppSheetのシステム開発の進め方｜6フェーズの流れ
開発は、要件整理から定着までを一続きの流れとして捉えます。全社向けの完成版を最初から目指さず、利用範囲を段階的に広げていきます。
- 少人数のPoCによる業務価値の確認
- 限定部署でのパイロット
- 利用実績を見ながらの対象拡大
各フェーズでは、目的と決めることを具体化し、完了の判断基準も明確にします。
フェーズ1：要件整理｜対象業務と成功条件の決定
要件整理では、対象業務を「入力」「判断」「承認」「出力」に分けて捉えます。まずは現場が困っている業務を一つ選び、そのうえで利用者や端末、入力内容を整理します。
業務フローには、入力のあとに誰が何を判断するかも書き込みます。利用場面と成果まで具体化すると、「日報をアプリ化する」より目的がはっきりします。たとえば、現場が作業終了後5分以内に写真付きで報告し、管理者が当日中に未完了を確認する形です。
- 利用・入力：利用者数、入力項目、必須項目
- 業務機能：承認者、差し戻し条件、写真・位置情報・署名
- 運用・評価：オフライン、通知・帳票・連携、情報区分、KPI
導入前に、入力時間と転記ミスを計測します。承認リードタイムや未処理件数も計っておきます。数字があれば、PoC後の判断がぶれにくくなります。
要件はMust、Should、Laterの3段階に分けます。PoCはフォーム、一覧、1つの通知に絞り、例外処理や全社連携は後の段階に回します。
完了条件は画面の完成とは別に、対象業務や利用者、KPIを文書で合意して決めます。対象外の範囲と次の判断日も、文書で合意します。
フェーズ2：選定｜データ基盤と料金プランの判断
業務の規模や連携、料金プランを比べて選びます。データ基盤は、次の条件から確かめます。
- 小規模・少量データ：Google SheetsやAppSheet Database
- 中規模以上・複数連携：Cloud SQLなどのRDB
- 表の設計：列名、キー、参照関係、履歴を先に決める
- アクセス・同期：認証、行レベル制御、オフライン同期
- 連携・運用：API、帳票、監査ログ、データ保存場所
スプレッドシートの不整合は、アプリの式だけで隠さないようにします。
2026年8月に確認した公式料金は、Starterが5米ドル、Coreが10米ドル、Enterprise Plusが20米ドルです。いずれも1ユーザー当たり月額の価格です。料金の根拠は、Google AppSheet Pricing（2026年8月確認）です。
1米ドル=150円で換算した試算では、1人当たり月約750円、約1,500円、約3,000円です。Coreは多くの有料Google Workspaceプランに含まれる場合があります。ただし、対象プラン、契約形態、利用機能は契約前に確かめておきます。
公式ページには、最大10人まで無料で試作できる案内もあります。一方で、無料試作と本番運用の総額は分けて考えます。
公式のAPI資料では、外部サービスからレコードの追加・削除・更新・検索ができます。AutomationからWebhookを呼び出すこともできます。
連携の可否は、APIの利用可能プラン・データ形式・失敗時の再実行・ファイル送信の制限を確認してから決めます。
根拠：AppSheet Help「API integration points in AppSheet」「Invoke the API」（2026年8月確認）。
フェーズ3：設計・開発｜現場で迷わない画面とデータ
データモデルと画面、権限を決めます。式やAutomation、連携、エラー時の動作も定めます。そのうえで、入力の順番は業務の流れに合わせます。
1画面に項目を詰め込みすぎず、必須項目は欠けると困るものに絞ります。また、選択肢や初期値で入力の負荷を下げます。
写真の枚数や位置情報を取得するタイミング、署名者も、仕様に書き込みます。
権限は、行の閲覧や列の編集、承認操作を誰に許すかまで整理します。ロール表には、管理者、現場担当者、承認者、閲覧者などの役割を書き込みます。
部署や担当者によって表示データが変わる条件は、具体例を挙げて示します。security filterに加えて、元データ側の共有権限も確認します。認証、外部共有、端末紛失時の対応も、同時に設計します。
まずダミーデータで画面とフローを確かめ、合意を得てから本番データを移行します。式やBotを追加するたびに、動作も確かめます。
- 入力・データ：未入力、重複、削除
- 業務フロー：差し戻し、通信断、連携先停止
大量の行をすべての端末に同期すると、遅延の原因になります。そこで、対象期間や担当者で絞る方法を検討します。
履歴を分けて持つ方法や、RDBへ移す方法も、設計の段階で検討しておきます。
フェーズ4：テスト｜実データと実機による業務の再現
開発担当者だけで完了とせず、利用者と管理者が実際の業務で検証します。業務の最初から最後までの操作に加え、端末や通信環境、失敗時の動き、不具合の記録まで確かめます。
- 現場担当者、承認者、管理者による、業務の最初から最後までの操作
- 利用端末と通信環境での、入力時間・画面・通知・帳票・検索の確認
- スマートフォン、タブレット、ブラウザでの動作と、オフライン入力・再同期の検証
- 未入力、二重送信、担当者変更、差し戻し、写真添付の失敗、APIエラー、同時更新の再現
- 不具合ごとの再現手順、影響範囲、暫定回避策、修正担当者、再テスト日の記録
本番公開の前には、AppSheetのDeployment Checkを実行します。アプリ定義・基盤データ・セキュリティ・料金プランとの互換性を確かめます。
問題があれば修正してから、デプロイ状態へ移します。ただし、合格しても、業務手順や個人情報の扱いまでは保証されません。業務責任者による受入確認は、別に行います。根拠は、AppSheet Help「Perform a deployment check」（2026年8月確認）です。
フェーズ5：稼働｜小さな公開と、戻れる状態の維持
小さく公開して引き継げるよう、稼働前に次の準備を整えます。
- 全社公開前に1部署や数名でパイロットを行い、旧帳票やExcelの併用期間を決める
- 二重入力の終了時期と、障害時に戻す方法の決定
- 利用者リスト、ロール、アプリURL、操作マニュアルの配布
- 問い合わせ窓口と障害時の連絡先の案内
Manage画面では、デプロイとバージョンを管理できます。モニタリングや所有者移管も、同じ画面で扱えます。そのうえで、会社が管理する所有者と共同編集者を設定します。
退職や異動のあとも引き継げるよう、納品物にはアプリ定義・式・Bot・Apps Scriptを含めます。API仕様とデータモデルも納品物に含めます。運用手順とバックアップ方法も、納品物として整理します。
根拠はAppSheet Help「Manage your apps: The Essentials」（2026年8月確認）です。
フェーズ6：定着｜利用率と改善の継続的な確認
公開後も、利用者がつまずいている箇所を確かめます。特に初月は、毎週、利用状況とエラーを見ます。
- 業務指標：入力時間、未入力件数、差し戻し件数、承認時間
- システム状況：通知エラー、同期エラー
利用率が低い場合でも、原因が現場の意欲だけとは限りません。まず、入力項目や通信、権限を調べ、画面と業務ルールがずれていないかも確かめます。旧運用が残っている可能性もあるため、原因を切り分けます。
監査や障害調査が要る業務では、ログの保持期間も設計します。Audit Historyは、Enterprise Plusで53日、それ以外のタイプで7日保持されます。表示には最大5分程度の遅延が生じる場合があります。
保持期間には限りがあります。そのため、長期保管が必要なら、BigQueryやデータソース側の履歴機能へのエクスポートを検討します。保存期間と閲覧権限も決めます。根拠は、AppSheet Help「Monitor app activity using Audit History」（2026年8月確認）です。
定着後は、月1回または四半期ごとに改善会を設けます。変更は、申請・影響確認・テスト・承認・リリース・周知の手順で固定します。
現場が本番の式を直接変えない、というルールにします。公式のセキュリティ情報も、組織でアプリやデータソース、作成者を統制する考え方を示しています。
市民開発は続けたうえで、命名や所有者、公開審査の手順を標準化します。バックアップと引継ぎも標準化します。
AppSheetのシステム開発にかかる費用相場と内訳
費用は、ライセンス料金と開発・運用委託費に分けて考えます。要件整理・データ整備・連携・テスト・教育・保守も必要になると、総額は大きくなります。
ここで示すのは、一般的な業務システムの相場と、AppSheetで工数を抑えやすい点をもとにした推定です。定価ではなく、要件によって上下する目安として見てください。
規模別の開発委託費の目安
規模ごとの費用と期間は、含める機能や支援範囲で変わります。次の目安は、AppSheet公式の定価ではありません。
- 小規模PoC：20万〜100万円程度、期間は1〜4週間程度
- 部門向け：50万〜300万円程度、期間は1〜3か月程度
- 連携を含む案件：300万〜1,000万円程度、期間は3〜6か月程度
- エンタープライズ・ハイブリッド：1,000万〜3,000万円以上、期間は6〜12か月程度
小規模PoCの対象は、フォーム、一覧、写真、簡単な通知です。社内担当者が作り、外部会社が要件整理やレビューだけを担うと、費用は下限に近づきます。
データの整理や承認者の調整に時間がかかると、PoCの期間も延びます。
部門向けの費用には、顧客管理や日報、点検、在庫などの権限設計が入ることがあります。さらに、帳票、通知、操作研修、受入テストも含む場合があります。
複数部門や複数のデータソースに加えて、承認やAPI、データ移行、監査を含む案件は、上記の連携案件と同程度の規模になる可能性があります。
エンタープライズやハイブリッド構成の推定には、Cloud SQLやBigQueryを含む場合があります。API基盤やID管理、データ移行も含まれる場合があります。
運用設計や複数拠点の教育も、対象になり得ます。見積書には、一般的な業務システム相場と想定工数による推定であることを明記します。
ライセンス以外にかかるランニングコスト
月々の費用は、ライセンスや周辺サービス、保守運用の範囲によって変わります。見積では、次の項目ごとに分けて確かめます。
- サービス費：AppSheet、Google Workspace、データベース、API・帳票・ストレージ
- 利用者数：社員、社外協力会社、派遣社員、閲覧者、複数端末の数え方
- 保守範囲：問い合わせ、権限・式・Botの変更、Google側仕様変更、脆弱性・制度対応
- 運用支援：月次レポート、データ修復、対応時間・期限・障害重大度
契約プランによって使えるAPIや監査、ガバナンス機能も変わります。そのため、単価だけで比べないようにします。
保守運用費は、初期費用の年15〜25％程度を目安に置くことがあります。これは一般的な目安で、AppSheet公式の固定料金ではありません。
見積では、月に何時間まで対応するかを確かめます。さらに、何営業日以内に対応するかや、障害の重大度ごとの対応も分けて記載してもらいます。
AppSheetの見積を取るときのチェックポイント
見積は、合計金額の安さより、業務と運用をどれだけ理解しているかで比べます。「アプリ開発一式」とだけ書かれた見積では、要件を追加したときの費用範囲が分かりません。
作業と成果物を分けたうえで、前提条件、対象外、検収条件、変更時の扱いまで確かめます。
作業範囲と成果物の分解
作業項目は、工程ごとに分けて記載してもらいます。含まれる範囲がはっきりすると、追加作業の判断がしやすくなります。
- 設計・開発：要件定義、業務フロー、データ・画面設計、式・権限、Automation
- 移行・公開：外部連携、データ移行、テスト、リリース、操作研修
- 運用：運用設計、保守
成果物には、要件一覧やロール表、データモデルを含めます。画面一覧、テスト仕様書、操作マニュアルも、成果物として確認します。
アプリ定義・式とBotの一覧・API仕様・障害時の手順・引継ぎ資料も、成果物として確かめます。
既存データの名寄せや重複削除、形式変換、過去履歴の移行範囲を確かめます。写真や添付ファイルは、どこにどう保管するかも確認します。
API認証情報の管理者も決めておきます。顧客から提供されるデータなら、形式や品質基準、作業回数に加えて、エラー修正をどこまで誰が受け持つかを定めます。
移行条件が曖昧なままだと、アプリが完成しても、本番データを使えない状態になり得ます。
依頼先の技術力と伴走範囲
依頼先を比べるときは、技術面と伴走範囲を次の観点で確かめます。
- 技術・業務：AppSheet、要件整理、Google連携、RDB・API、個人情報
- 体制・支援：教育、保守、要件定義の担当、所有権と引渡し
- 継続支援：障害復旧、保守範囲、契約終了時の返却・移管
近い業務の事例を聞くときは、利用者数やデータ量、連携先、開発期間、導入後の支援範囲を尋ねます。
最短納期や認定資格は、参考情報として受け止めます。それだけで、自社の成功が保証されるわけではありません。
式やBotを自社で変えるための研修や、実機・オフライン・権限のテストが用意されているかも確かめます。障害時の復旧方法や目標時間、保守の月額範囲は、見積の段階で示してもらいます。
実機デモで、エラー時の挙動まで説明できるかを見ると、提案書だけでは分からない実力を判断しやすくなります。
セキュリティ・法令・契約の見積項目
セキュリティ、法令、契約の確認項目は、見積と要件の両方に含めておきます。
- アクセス管理：認証、最小権限、行・列制御、端末紛失、外部共有
- 運用管理：保存場所、委託先、退職者アカウント、自社の設定・契約
- 法令・記録：アクセス制御、委託先監督、電子取引データ、証憑管理
- 契約・権利：所有権、利用許諾、改修権、契約終了後の引渡し
主な保存先は、利用者が選ぶGoogle SheetsやCloud SQLなどです。根拠は、Google AppSheet「Security and governance」（2026年8月確認）です。
性能や監査ログのために、データを一時的に保持する場合もあります。
AppSheetが、個人情報保護法や電子帳簿保存法、インボイス制度への適合を自動で保証するわけではありません。そのため、保存期間や検索要件、改ざん防止は機能要件に落とし込みます。監査証跡と制度変更時の改修の責任は、保守契約に書き込みます。
受託開発では、アプリ定義・式・Apps Script・API仕様・データモデルの所有権と利用許諾を、契約書ではっきりさせます。翻案と改修の権利、契約終了後の引渡しも定めます。
AppSheetのシステム開発でよくある質問（FAQ）
よくある質問は、料金、開発期間、内製化、セキュリティの4つに分かれます。答えは、利用者数やデータ量、連携の有無、個人情報の扱い、運用体制を前提に判断します。
AppSheetのシステムは何日で作れますか？
フォーム、一覧、写真、簡単な通知に絞ったPoCは、1〜4週間程度が目安です。
権限や帳票、データ移行、教育を含む部門向けは、1〜3か月程度です。複数システムの連携や全社展開は、3〜12か月程度になる場合があります。
要件の合意やデータの整理、受入テスト、社内決裁も、全体の納期を左右します。画面を作る速さだけで、納期が決まるわけではありません。
AppSheetは自社だけで開発できますか？
小規模で定型的な業務なら、社内担当者が試作し、現場の意見を取り入れて開発できます。
本番運用では、データモデルや権限、監査、API、所有権の設計が要ります。加えて、バックアップと変更管理の設計も要ります。
社内で画面を作り、外部会社には要件レビューやセキュリティ確認、連携、教育を頼むという分担も有効です。
Google Sheetsに顧客情報を置いても安全ですか？
安全性は、AppSheetを使うかどうかだけで決まるものではありません。認証やデータ共有権限、行・列の制御、端末管理が関係します。さらに、ログや委託先、運用ルールも影響します。
シートを直接共有するか、AppSheet経由で必要なデータだけを見せるかを整理します。また、外部共有や退職者のアクセスは定期的に確認します。
機密性やデータ量が高い場合は、Cloud SQLなどのデータ基盤も比べます。そのうえで、セキュリティ担当者のレビューも受けます。
AppSheetのシステム開発費を抑える方法はありますか？
対象業務を一つに絞り、20万〜100万円程度のPoCで入力時間や転記ミスなどのKPIを検証する方法があります。
使われなかった機能は本番仕様から外し、価値を確認できた機能だけを広げます。そうすると、要件の膨らみを抑えられます。
認証や権限、バックアップ、引継ぎなど、本番に必要な統制項目は、削らないようにします。
まとめ｜AppSheetのシステム開発の段階導入と運用設計
開発は、要件整理から定着までの6フェーズで進めます。まず、紙やExcelで負担の大きい業務を選び、PoCでKPIを検証します。
データの正や権限、オフライン、連携を設計し、性能や監査、所有者、引継ぎも決めておきます。そのうえで、作って終わりにならない運用を整えます。
費用は、公式ライセンスと開発委託費に分けて見積もります。データ移行、連携、教育、保守も、それぞれ見積もります。
小規模PoCは20万〜100万円程度、部門向けは50万〜300万円程度、連携案件は300万〜1,000万円程度が推定レンジです。
金額は、要件と成果物に応じて調整します。判断の基準は、現場で使えること、安全に変更できること、担当者が変わっても引き継げることです。
AppSheet単体か、RDBやAPI、既存システムとの連携かは、業務の標準性・データ量・性能・法令・将来の拡張性で判断します。
段階導入と運用ルールの整備を同時に進めると、現場の速さと企業の統制を両立しやすくなります。
▼全体ガイドの記事
・AppSheetのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。