AppSheetのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

AppSheetのシステム開発は、紙やExcelの業務をそのままアプリ化するのではなく、入力・判断・承認・出力を整理し、現場で続く最小単位から段階的に作る進め方が成功の近道です。

「ノーコードだからすぐに安く作れる」と考えて始めると、データの重複、権限の抜け、例外処理、運用担当者の不在によって、公開後に作り直しになる場合があります。この記事では、AppSheetのシステム開発を要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズに分け、各段階で何を決めるべきか、どの程度の費用を見込むべきか、見積書のどこを確認すべきかを実務目線で解説します。

▼全体ガイドの記事
・AppSheetのシステム開発の完全ガイド

AppSheetのシステム開発とは？全体像を先に確認します

AppSheetは、Google SheetsやExcel、Google Drive、AppSheet Databaseのほか、SQL Server、MySQL、PostgreSQL、Oracle、BigQuery、Salesforce、ODataなどをデータソースとして、スマートフォン、タブレット、ブラウザで使える業務アプリを構成できるサービスです。フォーム、一覧、詳細、ダッシュボード、写真、位置情報、バーコード、署名、オフライン同期を組み合わせ、現場の記録から通知や帳票作成までを一つの業務フローにできます。

作りやすいのは、現場担当者が決められた項目を入力し、その後に承認や通知、帳票出力が続く業務です。たとえば営業訪問記録、現場日報、設備点検、在庫・棚卸、受発注、問い合わせ管理、配送進捗、申請・承認などが候補になります。写真や位置情報を記録したい、外出先で通信が不安定でも入力したい、入力後に管理者へ通知したいという課題とは相性がよいです。

一方、会計や給与のように法令・専門機能が中心の業務、複雑なトランザクション、大量データを多数の利用者が同時に処理する業務、画面や性能を完全に作り込む必要がある業務は、AppSheet単体で無理に置き換えない判断も必要です。定型的な現場入力はAppSheet、正規化されたデータや高負荷処理はCloud SQL・BigQuery・既存基幹システムというように、役割を分ける設計が現実的です。

AppSheetでは画面や式を短期間で作れるため、最初に見えるアプリの完成度だけを評価しがちです。しかし、実務で止まりやすいのは、マスタの管理者が決まっていない、退職者がアプリの所有者になっている、誤入力を戻せない、同期に時間がかかる、誰がどのデータを見られるか決まっていないといった周辺設計です。開発開始時点で、データの正、利用者とロール、アプリの所有権、変更履歴、バックアップ、問い合わせ窓口を決めておく必要があります。

また、Google Sheetsを使う場合でも、1枚のシートにすべてを詰め込むのではなく、顧客、担当者、商品、取引、履歴、添付ファイルなどを役割ごとに分けます。データ量や同時利用者が増える場合は、最初からAppSheet DatabaseやCloud SQLを検討し、将来の移行条件を要件に含めます。AppSheetのシステムは「アプリを作る作業」ではなく、「業務とデータを運用可能な形に整えるプロジェクト」と捉えることが大切です。

AppSheetのシステム開発の進め方｜6フェーズで解説します

開発は、要件整理から定着までを一続きの流れとして考えます。おすすめは、最初から全社向けの完成版を目指さず、少人数のPoCで業務価値を確認し、限定部署でパイロットを行い、利用実績を見ながら広げる進め方です。以下では各フェーズの目的、決めること、完了の判断基準を具体化します。

最初に、対象業務を「入力」「判断」「承認」「出力」に分解します。現場が困っている業務を一つに絞り、誰が、いつ、どの端末で、何を入力し、入力後に誰が何を判断するのかを業務フローにします。「日報をアプリ化する」ではなく、「現場が作業終了後5分以内に写真付きで報告し、管理者が当日中に未完了を確認する」のように、利用場面と成果を具体化します。

この段階のチェック項目は、(1)対象利用者と人数、(2)入力項目と必須項目、(3)承認者と差し戻し条件、(4)写真・位置情報・署名の要否、(5)オフライン入力の要否、(6)通知・帳票・外部連携、(7)個人情報や機密情報の有無、(8)導入効果を測るKPIです。入力時間、転記ミス、承認リードタイム、未処理件数など、導入前の数字を1つでも計測しておくと、PoC後の判断がぶれにくくなります。

要件が膨らみ始めたら、Must、Should、Laterの3段階に分けます。最初のPoCはフォーム、一覧、1つの通知など最小構成にし、例外処理や全社連携を後段へ送ります。要件整理の完了条件は、画面ができたことではなく、対象業務、利用者、KPI、対象外の範囲、次の判断日が文書で合意されていることです。

次に、どのデータソースと料金プランで始めるかを決めます。小規模でデータ量が少ない業務ならGoogle SheetsやAppSheet Database、中規模以上や複数システムとの連携がある場合はCloud SQLなどのRDBを候補にします。スプレッドシートを使う場合も、列名、キー、参照関係、履歴の持ち方を先に決め、アプリの式だけでデータの不整合を隠さないようにします。

2026年8月に確認したAppSheet公式料金では、Starterが5米ドル、Coreが10米ドル、Enterprise Plusが20米ドルのユーザー／月です。記事上の試算として1米ドル=150円で換算すると、1人あたり月約750円、約1,500円、約3,000円です。Coreは多くの有料Google Workspaceプランに含まれる場合がありますが、対象プラン、契約形態、利用機能は契約前に確認が必要です。公式ページでは最大10人まで無料で試作できる案内もありますが、無料で試せることと本番運用の総額は分けて考えます。料金の根拠はGoogle AppSheet Pricing（2026年8月確認）です。

選定時は、認証方式、部署・担当者ごとの行レベル制御、オフライン時の同期、API、帳票、監査ログ、データ保存場所を確認します。AppSheet公式のAPI資料では、外部サービスからレコードの追加・削除・更新・検索・アクション実行ができ、反対方向にはAutomationからWebhookを呼び出せると説明されています。ただし、APIの利用可能プランやデータ形式、失敗時の再実行、ファイル送信の制限まで確認してから連携可否を判断します。根拠はAppSheet Help「API integration points in AppSheet」「Invoke the API」（2026年8月確認）です。

設計では、データモデル、画面、権限、式、Automation、連携、エラー時の動作を決めます。現場の入力画面は、1画面に項目を詰め込みすぎず、入力順を業務の順番に合わせます。必須項目は本当に欠けると困るものに絞り、選択肢や初期値を使って入力負荷を下げます。写真を何枚まで、位置情報をどのタイミングで、署名を誰が行うかも仕様に書きます。

権限は、アプリを開けるかどうかだけでなく、どの行を見られるか、どの列を編集できるか、承認操作を誰に許すかまで整理します。管理者、現場担当者、承認者、閲覧者などのロール表を作り、部署や担当者によって表示データが変わる条件を例示します。security filterだけに頼らず、元データ側の共有権限、認証、外部共有、端末紛失時の対応を一緒に設計します。

開発は、まずダミーデータで画面とフローを確認し、合意後に本番データを移行する流れが安全です。式やBotを追加するたびに、正常系だけでなく、未入力、重複、差し戻し、削除、通信断、連携先停止の動作を確認します。大量の行を全員の端末へ同期する設計は遅延の原因になるため、対象期間や担当者で絞り込む、履歴を分ける、RDBへ移すなどの対策を設計段階で検討します。

テストは、開発担当者だけで完了させないことが重要です。現場担当者、承認者、管理者が実際の業務を最初から最後まで操作し、入力時間、画面の分かりやすさ、通知のタイミング、帳票の内容、検索結果を確認します。スマートフォン、タブレット、ブラウザ、利用予定の通信環境で試し、オフライン入力と再同期も実機で検証します。

テストケースには、正常な登録だけでなく、必須項目を空にする、同じ伝票を二重送信する、担当者を変更する、承認を差し戻す、写真を添付できない、外部APIがエラーになる、同時に複数人が更新する、といった事象を含めます。テスト結果は「合格」だけでなく、再現手順、影響範囲、暫定回避策、修正担当者、再テスト日まで記録します。

本番公開前には、AppSheetのDeployment Checkを実行します。公式ヘルプによると、アプリ定義と基盤データの検証、セキュリティレビュー、料金プランとの互換性確認などが行われ、問題があれば修正してからデプロイ状態へ移します。ただし、Deployment Checkに合格しても、自社の業務手順や個人情報の扱いまで自動的に保証されるわけではないため、業務責任者による受入確認を別に置きます。根拠はAppSheet Help「Perform a deployment check」（2026年8月確認）です。

稼働時は、いきなり全社公開せず、まず1部署や数名の現場でパイロットを行います。旧帳票やExcelをいつまで併用するか、二重入力をいつ終了するか、障害時にどの方法へ戻すかを決めておくと、現場が安心して使えます。公開前には、利用者リスト、ロール、アプリURL、操作マニュアル、問い合わせ窓口、障害時の連絡先を配布します。

AppSheetの公式情報では、Manage画面からデプロイ、バージョン、モニタリング、所有者移管を管理できます。したがって、開発者個人のアカウントで公開するのではなく、会社が管理する所有者と共同編集者を設定し、担当者が退職・異動しても引き継げる状態にします。アプリ定義、式、Bot、Apps Script、API仕様、データモデル、運用手順、バックアップ方法を納品物として整理します。根拠はAppSheet Help「Manage your apps: The Essentials」（2026年8月確認）です。

アプリは公開しただけでは定着しません。初月は利用者のつまずきを毎週確認し、入力時間、未入力件数、差し戻し件数、承認時間、通知エラー、同期エラーを確認します。利用率が低い場合も、現場の意欲だけを原因にせず、入力項目が多い、通信が悪い、権限が足りない、業務ルールと画面が合っていない、旧運用が残っているなどの原因を切り分けます。

監査や障害調査が必要な業務では、ログの保持期間も運用設計に含めます。AppSheet公式ヘルプでは、Audit Historyの保持期間はEnterprise Plusで53日、それ以外のタイプで7日とされています。さらに、監査履歴の表示には最大5分程度の遅延が生じる場合があるため、長期保管が必要な場合はBigQueryやデータソース側の履歴機能へのエクスポート、保存期間、閲覧権限を別途設計します。根拠はAppSheet Help「Monitor app activity using Audit History」（2026年8月確認）です。

定着後は、月1回または四半期ごとに改善会を設けます。変更申請、影響確認、テスト、承認、リリース、周知の手順を固定し、現場が直接本番式を変更しないルールにします。AppSheet公式のセキュリティ情報でも、アプリの作成・デプロイ、データソース、作成者を組織で統制する考え方が示されています。市民開発を禁止するのではなく、命名、所有者、公開審査、バックアップ、引継ぎを標準化することが大切です。

AppSheetのシステム開発にかかる費用相場と内訳

AppSheetの費用は、ライセンス料金と開発・運用委託費を分けて考えます。公式のユーザー料金が低くても、要件整理、データ整備、既存システム連携、テスト、教育、保守が必要なら、プロジェクト全体の費用は大きくなります。以下は、リサーチノートにある一般的な業務システムの相場とAppSheetで工数を抑えやすい点をもとにした推定レンジです。定価ではなく、要件によって上下する目安として利用します。

小規模なPoCや1業務の試作は、20万〜100万円程度が一つの目安です。フォーム、一覧、写真、簡単な通知を対象にし、社内担当者が作成して外部会社が要件整理やレビューだけを行う場合は下限に近づきやすいです。期間は1〜4週間程度ですが、データの整理や承認者の調整に時間がかかる場合は延びます。

部門向けの実用アプリは、50万〜300万円程度、期間は1〜3か月程度が目安です。顧客管理、日報、点検、在庫などに権限、帳票、通知、操作研修、受入テストを含める場合のレンジです。複数部門、複数データソース、承認、API、データ移行、監査を含める案件は、300万〜1,000万円程度、3〜6か月程度の規模になる可能性があります。

エンタープライズやハイブリッド構成では、1,000万〜3,000万円以上、6〜12か月程度を見込む場合があります。これはAppSheetの画面作成だけでなく、Cloud SQL、BigQuery、API基盤、ID管理、データ移行、運用設計、複数拠点の教育を含む場合の推定です。上記の開発費レンジは、AppSheet公式の定価ではなく、リサーチノートの一般的な業務システム相場と想定工数を組み合わせた推定であることを見積書に明記します。

ランニングコストには、AppSheetのライセンス、Google Workspaceやクラウドデータベース、API・帳票・ストレージなどの周辺サービス、保守運用費が含まれます。ライセンスを試算するときは、社員だけでなく、社外協力会社、派遣社員、閲覧者、複数端末を使う利用者がどのようにカウントされるかを確認します。契約プランによって使えるAPI、監査、ガバナンス機能が変わるため、単価だけで比較しません。

保守運用費は、初期費用の年15〜25％程度を目安に置くことがありますが、これは一般的な目安であり、AppSheet公式の固定料金ではありません。問い合わせ対応だけか、権限変更、式やBotの改修、Google側仕様変更への対応、脆弱性・制度対応、月次レポート、データ修復まで含むかで変わります。見積書では、月何時間まで、何営業日以内に、どの重大度の障害へ対応するかを分けて記載してもらいます。

AppSheetの見積を取るときのチェックポイント

見積を比較するときは、合計金額の安さよりも、どこまで業務と運用を理解しているかを確認します。「アプリ開発一式」とだけ書かれた見積では、要件追加が発生したときに追加費用の範囲が分かりません。作業と成果物を分解し、前提条件、対象外、検収条件、変更時の扱いまで確認します。

最低限、要件定義、業務フロー整理、データ設計、画面設計、式・権限設定、Automation、外部連携、データ移行、テスト、リリース、操作研修、運用設計、保守を分けて記載してもらいます。成果物は、要件一覧、ロール表、データモデル、画面一覧、テスト仕様書、操作マニュアル、アプリ定義、式・Botの一覧、API仕様、障害時の手順、引継ぎ資料です。

特に確認したいのは、既存データの名寄せ・重複削除・形式変換が含まれるか、過去履歴をどこまで移すか、写真や添付ファイルをどう保管するか、APIの認証情報を誰が管理するかです。データ移行を「顧客提供」とする場合は、提供フォーマット、品質基準、作業回数、エラー修正の責任分界を決めます。ここが曖昧だと、アプリが完成しても本番データを使えない状態になります。

依頼先は、AppSheetの操作経験だけでなく、業務要件の整理、Google WorkspaceやGoogle Cloudとの連携、RDB・API、個人情報、教育、保守まで確認します。候補会社には、同じ業務に近い事例で、利用者数、データ量、連携先、開発期間、導入後の支援範囲を聞きます。最短納期や認定資格は参考になりますが、それだけで自社の成功を保証するものではありません。

比較時の質問は、(1)要件定義を誰が担当するか、(2)アプリの所有権と引渡し方法は何か、(3)式やBotを自社で変更できるよう研修するか、(4)テストで実機・オフライン・権限を確認するか、(5)障害時の復旧方法と目標時間は何か、(6)保守の月額範囲は何か、(7)契約終了時に何を返却・移管するか、です。実機デモでエラー時の挙動まで説明できるかを見ると、提案書だけでは分からない実力を判断しやすくなります。

顧客情報、従業員情報、取引情報を扱うなら、認証、最小権限、行・列の制御、端末紛失、外部共有、データ保存場所、委託先管理、退職者のアカウント停止を要件にします。AppSheet公式は、データの主な保存先をGoogle SheetsやCloud SQLなど利用者が選ぶ場所としつつ、性能や監査ログのために一時的にデータを保持する場合があると説明しています。サービスの安全機能だけでなく、自社の設定・契約・運用を含めて確認します。根拠はGoogle AppSheet「Security and governance」（2026年8月確認）です。

個人情報保護法のアクセス制御や委託先監督、電子帳簿保存法の電子取引データ保存、インボイス制度に関係する証憑管理などは、AppSheetが自動的に法令適合を保証するものではありません。保存期間、検索要件、改ざん防止、監査証跡、制度変更時の改修責任を、機能要件と保守契約に落とします。また、受託開発では、アプリ定義、式、Apps Script、API仕様、データモデルの所有権、利用許諾、翻案・改修の権利、契約終了後の引渡しを契約書で明確にします。

AppSheetのシステム開発でよくある質問（FAQ）

AppSheetのシステム開発では、料金、開発期間、内製化、セキュリティに関する質問が多くあります。結論だけで判断すると自社の条件とずれるため、利用者数、データ量、連携、個人情報、運用体制を前提に確認します。

フォーム、一覧、写真、簡単な通知に絞ったPoCなら、1〜4週間程度が一つの目安です。部門向けに権限、帳票、データ移行、教育まで含める場合は1〜3か月程度、複数システム連携や全社展開まで含める場合は3〜12か月程度を見込むことがあります。画面作成の速さだけでなく、要件合意、データ整理、利用者の受入テスト、社内決裁の期間が全体納期を左右します。

小規模で定型的な業務なら、社内担当者が試作し、現場の意見を取り込みながら開発できます。ただし、本番運用では、データモデル、権限、監査、API、所有権、バックアップ、変更管理を設計する必要があります。社内で画面を作り、外部会社には要件レビュー、セキュリティ確認、連携、教育だけを依頼する分担も有効です。

安全性は、AppSheetを使うかどうかだけでなく、認証、データソースの共有権限、行・列の制御、端末管理、ログ、委託先、運用ルールで決まります。Google Sheetsを使う場合は、シートを直接共有するのか、AppSheet経由で必要なデータだけを見せるのかを整理し、外部共有や退職者のアクセスを定期的に確認します。機密性やデータ量が高い場合は、Cloud SQLなど適切なデータ基盤も比較し、セキュリティ担当者のレビューを受けます。

最初に対象業務を一つに絞り、20万〜100万円程度のPoCで入力時間や転記ミスなどのKPIを検証する方法が有効です。PoCで使われなかった機能を本番仕様から外し、利用価値が確認できた機能だけを拡張すると、要件の膨張を抑えられます。ただし、認証、権限、データバックアップ、引継ぎなど、本番運用に必要な統制項目を削って費用を下げることは避けます。

まとめ｜AppSheetのシステム開発は小さく始めて運用まで設計します

AppSheetのシステム開発は、要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズで進めると、作って終わりになりにくくなります。最初は紙やExcelで負担が大きい一つの業務を選び、入力・判断・承認・出力を整理し、PoCでKPIを検証します。そのうえで、データの正、権限、オフライン、連携、性能、監査、所有者、引継ぎを設計します。

費用は、公式ライセンス、開発委託費、データ移行、連携、教育、保守を分けて見積もります。小規模PoCは20万〜100万円程度、部門向けアプリは50万〜300万円程度、連携を含む案件は300万〜1,000万円程度という推定レンジを出発点にし、要件と成果物に応じて調整します。安さだけでなく、現場で使い続けられること、管理者が安全に変更できること、担当者が変わっても引き継げることを発注判断の基準にします。

AppSheetを単体で使うか、RDBやAPI、既存システムと組み合わせるかは、業務の標準性、データ量、性能、法令、将来の拡張性で判断します。現場のスピードと企業の統制を両立させるには、段階導入と運用ルールの整備を同時に進めることが重要です。

▼全体ガイドの記事
・AppSheetのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。