AppSheetのシステム開発の発注/外注/依頼/委託方法について

AppSheetのシステム発注は、対象業務と成功指標を決めることから始まり、委託先の選定と契約を経て、設計から保守へと順に進みます。

発注形態は社内の体制で、契約形態は仕様の確定度や現場での変更の有無で選び、費用はライセンス費と開発委託費を分けて見積もります。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

AppSheetのシステム発注・外注を始める前の全体像

AppSheetの発注では、画面を作るだけでなく、入力から承認までと、通知や帳票、データ保管を一連の流れとして考えます。なお、紙やExcelの様式をそのまま画面にすると、入力項目が増えて現場で使われにくくなります。

AppSheetで外注しやすい業務と、先に見極めたい業務

入力と確認が定型的に決まっている業務は、AppSheetで外注しやすい対象です。

• 現場記録：営業訪問記録、現場日報、点検・保守、配送進捗の記録。
• 管理業務：在庫・棚卸、問い合わせ管理、申請・承認、設備台帳の管理。
• 現場入力：写真、位置情報、バーコード、署名を使う業務。

スマートフォンやタブレットで入力できます。このため、転記時間や入力漏れの削減を効果として測りやすくなります。

会計や給与のように法令や専門機能が中心の領域は、AppSheet単体で置き換えられるとは限りません。また、複雑な処理や大量データの同時処理、厳密な性能保証が必要な場合も、単体での対応は慎重に判断します。

入力画面にはAppSheetを使い、データベースやAPIを組み合わせる構成もあります。さらに、パッケージやスクラッチ開発と併用する形も検討します。

ライセンス費と開発委託費の分け方

見積では、継続するサービス利用料と開発委託費を分けて確認します。

• ライセンス料：利用者やプランに応じて決まる月額で、アプリ作成費とは別です。
• 公式料金：プラン別のユーザー月額。
• Workspaceとの契約：Coreは一部の有料Google Workspaceに含まれる場合があるため、契約プランと対象機能を照らし合わせます。
• 開発委託費：ヒアリング、RFP支援、データ整理が対象です。画面・式・Automationの実装、連携、テスト、研修、リリース支援も含みます。

公式料金は、Starterが5米ドル、Coreが10米ドル、Enterprise Plusが20米ドルのユーザー月額です（出典: Google AppSheet公式Pricing、2026年8月確認）。

「開発一式」として二つの費用が混ざると、後から移行費や保守費が加わる可能性があります。

AppSheetの発注形態の選び方

発注形態は、要件を整理する力や残したい運用ノウハウ、連携の難しさ、リリース後の改修量で選びます。全外注か内製かの二択にせず、要件定義だけを外注して実装と運用を社内で担う方法もあります。

要件定義から保守までの一括外注

次の条件や役割に照らすと、一括外注が自社に合うかを判断できます。

• 導入体制：専任のIT担当者がいない場合や、複数の現場へ短期間で導入する場合。
• 連携・権限：既存システムとのAPI連携や権限設計がある場合。
• 委託範囲：ヒアリングから保守までを委託先が担い、窓口を一本化しやすくなります。
• 発注者の役割：入力者、承認者、正とする情報を決め、アプリ定義、式、Bot、データモデル、API仕様、操作マニュアルを納品物に含めます。

伴走型・部分外注による内製化

内製化を目指す部分外注では、社内と外注先のどちらが何を担うか、引継ぎ内容を先に決めます。

• 外注する範囲：要件整理、データ設計、難しい式のレビューを依頼します。
• 社内で担う範囲：画面の追加や軽微な変更を行い、利用者の声を画面に反映します。
• 事前に決めること：アプリの所有者、外注先のアクセス期間、レビュー方法、質問への回答時間。
• 研修・手順：操作に加えて、命名規則、変更申請、テスト環境、本番反映の手順も学びます。

この形であれば、リリース後の改修にも対応しやすく、担当者への依存を抑えられます。

PoCだけの外注と本番展開の判断

PoCでは対象を絞り、実際の利用結果と費用条件を本番化の判断材料にします。

• 対象範囲：適合性がわからない場合は、1業務、1部門、少人数で試します。
• 現場日報の検証：入力、写真、上長確認、未提出通知を作り、時間、提出率、ミス、承認時間を測ります。
• 本番化の判断：実際の利用者が一定期間使った結果を、本番化の根拠にします。
• 推定レンジ：小規模PoC・1業務は、20万〜100万円、1〜4週間程度の推定です。

金額と期間は、要件の複雑さ、データ整備、委託範囲で変わります。この金額と期間は推定の目安で、公式の定価ではありません。

PoCで作ったものと本番の見積条件を分けて考えると、検証が失敗しても投資を限られた範囲に抑えられます。

AppSheetの発注・外注の進め方

発注は、業務選定と要件整理、委託先選定と契約の順に進みます。そのあとは、設計・開発から受入テスト、教育・リリース、保守へと続きます。なお、順番を飛ばすと、権限やデータ構造の変更が生じ、追加費用や納期遅延につながりやすくなります。

対象業務と成功指標の決め方

まず、現場の課題を「入力」「判断」「承認」「出力」に分けて、改善したい業務を定めます。

• 転記の課題：入力時間と転記ミスを指標にします。
• 承認の遅れ：申請から承認までの時間。
• 状況把握：未処理件数や更新率。

「アプリを作る」ことより先に、何を何パーセント改善したいかを決めると、要件の優先順位づけに役立ちます。

責任者や入力者、承認者、データ管理者を集めます。たとえば、管理者だけでは現場の使いやすさが抜け、現場だけでは権限や監査が抜けやすくなります。

発注者は、帳票やExcel、マスタのサンプルを用意し、通知メールや例外処理の扱いも含めて委託先と認識を合わせます。

データ・権限・連携の設計と実装

AppSheetは、Google SheetsやExcel、Google Drive、AppSheet Databaseをデータソースとして扱えます。

データソースとしては、SQL ServerやMySQL、PostgreSQLなどに対応します。さらに、Oracle、BigQuery、Salesforceなどにも対応します（出典: Google AppSheet Help「Manage data sources」、2026年8月確認）。

接続できることと、そのデータ構造が業務システムに適していることは別です。そこで、データ構造と連携時の動きを具体化します。

• データ構造：マスタ、明細、履歴、添付、個人情報の分け方を決めます。
• REST API：レコードの追加・更新・削除・検索、アクション実行を呼び出せます。
• Webhook：外部サービスへの通知条件。
• RFPの連携条件：認証、再送、重複防止、タイムアウト、障害時の手動復旧を、RFPに明記します。

AutomationからWebhookで外部サービスへ通知できます（出典: Google AppSheet Help「API integration points in AppSheet」、2026年8月確認）。

連携の条件まで具体化しておけば、「API連携あり」とだけ書かれた曖昧な見積を避けられます。

実データに近いテストと段階的なリリース

テストでは、画面が表示されるかだけでなく、権限、複数人の同時更新、通信が不安定なときの挙動も確かめます。

• 同期：オフライン中の入力を同期したときの競合を確かめます。
• 登録：写真や署名を実際に登録する操作。
• 自動処理：BotやWebhookが失敗した場合の動き。

利用者の端末と通信環境で試し、そのうえで業務部門が合否を決める受入テストを設けます。本番前は限定部署で試験運用し、全社一斉の展開は避けます。

また、Deployment Checkとバージョン履歴を手順に組み込み、変更者とエラーの確認方法を明文化します。MonitorとAudit Historyも、同じ手順に含めます。

問い合わせ窓口と、緊急時に旧運用へ戻す方法も決めておくと、現場の不安を減らせます。

AppSheetのRFPと要件整理の記載項目

RFPは、同じ条件で提案と見積を得るための資料です。長い仕様書を最初から完成させる必要はなく、目的、範囲、利用者から先にそろえます。

現行業務や納期、保守条件も、RFPに含めます。残りの条件は、項目ごとに整理します。

不足している情報は「提案してほしい事項」として分けておくと、各社の提案を比べやすくなります。

目的・対象範囲・利用者の示し方

RFPでは、改善の目的、対象外の範囲、利用者の役割と利用条件を示します。

• 目的：「誰の、どの作業を、どう改善するか」を示します。
• 対象範囲：営業担当30名の日報なら、訪問先、活動、写真、次回対応、上長確認を含めます。
• 目標と対象外：当日共有と転記廃止を目標にして、給与計算や会計連携は対象外にできます。
• 利用者：一般ユーザー、現場リーダー、承認者、管理者、外部協力会社などに分けます。
• 利用条件：人数、同時利用、社外ユーザー、共有端末、サインイン方式。

たとえば、紙の日報を管理者が翌日にExcelへ転記しているような業務では、その転記をどこまで置き換えるかを示すと、提案の範囲を具体化できます。

公式料金では、サインインユーザーはアカウント単位で数えます。サインインしないゲストは、端末単位で数える場合があります（出典: Google AppSheet公式Pricing、2026年8月確認）。

データ項目・権限・セキュリティ要件の具体化

データと権限は、具体的な項目と、役割ごとのアクセス範囲まで落とし込みます。

• データ項目：項目名、形式、必須可否、入力例を示します。マスタ関係、保存期間、添付の扱いも含めます。
• 移行データ：正規化するデータ、参照専用の過去分、新規登録分に分けて扱います。
• 役割別権限：営業は自分の顧客、支店長は支店の記録、管理者は全件を見られるようにします。
• 変更制御：承認後は現場が変更できないなど、操作の範囲。

既存のExcelをそのまま渡すと、顧客名の重複や表記ゆれも一緒に引き継がれる可能性があります。

AppSheetには、認証やロール、Security Filterなどがあります。

完全なセキュリティにするには、Security Filterに加えてデータソース側の保護も必要です（出典: Google AppSheet Help「Set access mode as app creator or app user」、2026年8月確認）。

データソース側の権限と端末紛失への備えは要件に含めます。外部共有や委託先からのアクセスも、あわせて整理します。

納品物・検収条件・運用体制の決め方

納品物、検収項目、運用条件をRFPで具体化すると、契約後の解釈違いを減らせます。

• 納品物：アプリ、定義、画面一覧、式・Automation一覧、データモデル、API・Webhook仕様。
• 運用資料：テスト結果、操作・管理者マニュアル、バックアップ方法、教育資料。
• アカウント：所有者と管理者アカウントを発注者側に置きます。
• 検収項目：権限、必須入力、重複防止、オフライン同期の動作を確かめます。通知、帳票、APIの成功・失敗、移行件数、端末操作も対象です。

検収後の無償修正期間、仕様変更の条件、問い合わせへの初動時間も、RFPに書いておきます。

AppSheetの契約形態と、請負・準委任の使い分け

契約形態は、仕様がどこまで固まっているか、現場で変更が続くかで選びます。請負は成果物の完成を、準委任は人材や作業時間による支援を重視します。なお、改善が続くAppSheetでは、要件定義、初期開発、運用改善で契約を分ける方法もあります。

要件が固まった部分の請負契約

仕様や成果物が決まっている工程では、請負の対象と契約条件をはっきりさせます。

• 適用する工程：対象業務、画面、データ項目が決まった部分に適用します。権限、通知、帳票、受入条件も、決まっていれば含まれます。
• 管理しやすさ：PoC後に仕様が固まった、限定部署向けの開発では、予算と検収を管理しやすい場合があります。
• 費用の区分：委託先が作る成果物と、発注者が負担するAppSheetやWorkspaceの利用料を分けて示します。
• 契約条項：定義・式の著作権や利用権、第三者素材、再委託の可否、設定情報の引渡しを定めます。

AppSheetのライセンスやGoogle Workspaceの管理設定は、委託先が負うとは限りません。

要件探索と内製化支援の準委任契約

作業しながら内容が具体化していく工程では、準委任で支援の内容と到達点を決めます。

• 対象工程：ヒアリング、業務フロー整理、データクレンジング、社内担当への伴走、リリース後の改善。
• 運営条件：作業時間、体制、定例会、報告内容、相談対応の時間。
• 月ごとの目標：時間だけでなく、各月の到達点を設定します。
• 進行例：1か月目は業務フローとデータ項目、2か月目は日報試作とテスト。
• 展開例：3か月目は限定部署へ展開して研修し、会議体と成果の確認方法を決めます。

保守契約の対応範囲と時間の分け方

保守契約は、対応範囲、ログ保管、費用条件を分けて決めます。

• 対応範囲：問い合わせ、権限変更、式・Botの軽微な修正、データ復旧。
• 運用支援：Google側の仕様変更、脆弱性・制度対応、月次レポート。
• ログ保持：プランごとの保持期間。
• 保守費：初期費用の年15〜25％が目安という推定で、公式の一律の相場ではありません。
• 料金条件：アプリ・利用者数、連携先、受付時間、復旧目標、月間改修上限で変わります。

Audit HistoryはEnterprise Plusで53日保持されます。一方で、その他のプランは7日です（出典: Google AppSheet Help「Monitor app activity using Audit History」、2026年8月確認）。

長期保管が必要な監査ログは、別途エクスポートするか、データソース側の仕組みで残す方法を検討します。

月額に含まれる作業と、別見積になる機能追加をはっきりさせ、固定費か従量費かを比べます。

AppSheetの発注・外注費用の相場

外注費は、画面数だけでなく、データの状態や権限、連携の範囲で変わります。移行やテストの範囲、教育や保守の範囲も費用を左右します。

ここで示すのは、リサーチノートと一般的な業務システムの工程による推定レンジです。AppSheet公式の受託費相場ではないため、予算の起点として使い、同じRFPで複数社から見積を取ります。

規模別の開発委託費の幅

委託費の推定レンジは、開発規模と、含める工程によって異なります。

• 小規模PoC・1業務：フォーム、一覧、写真、簡単な通知で20万〜100万円程度。
• 部門向けアプリ：顧客管理、日報、点検、在庫などで50万〜300万円程度。
• 複数部門の案件：複数データソース、承認、API・SQL連携、移行、監査を含め300万〜1,000万円程度。

小規模案件は1〜4週間程度が目安です。ただし、社内担当が主体で要件整理やレビューだけを外注する場合は、下限寄りになります。

部門向けは1〜3か月程度で、権限や帳票、データ整備を含む推定レンジです。テストと研修も、この推定に含めています。

複数部門の案件は3〜6か月程度を見込みます。Enterprise PlusやCloud SQL、BigQueryを使うこともあります。さらに、API基盤やID管理を組み合わせる場合もあります。

全社データ移行や厳格な運用設計を含むエンタープライズ案件では、1,000万〜3,000万円以上となる可能性もあります。

この金額帯は、アプリ作成だけでなく、周辺クラウドやデータ、セキュリティを含む場合の推定です。移行や教育を含むときも、同じ前提で見ます。

前提を分けずに、特定の金額だけを断定することは避けます。

ユーザー数・プラン・為替で変わるライセンス費

ライセンス費は、料金換算と契約条件、利用者の数え方を合わせて見ます。必要な機能も、同時に考えます。

• Starter：5米ドルは、1米ドル=150円換算で約750円のユーザー月額です。
• Core・Enterprise Plus：各10米ドル・20米ドルで、約1,500円・約3,000円のユーザー月額です。
• 請求額：為替、税、契約形態、Workspaceへの含まれ方で変わります。
• 利用者数：プラン、人数、数え方を見積書に記すとともに、社外ユーザーや共有端末も確かめます。
• 公開アプリ：Publisher Proが適用される範囲。

Publisher Proは50米ドル／アプリ／月で公開アプリを作れます（出典: Google AppSheet公式Pricing、2026年8月確認）。

サインインやSecurity Filterは使えないため、機密情報を扱う社内システムの代替にはなりません。

ここに示した換算額は概算です。必要な認証、権限、監査の機能から、プランを判断します。

見積書の工程別の内訳と追加費用

見積は、工程ごとの範囲と、追加費用になり得る作業を分けて見ます。

• 工程別項目：要件定義、業務フロー、データ設計、画面・式、Automation、API・Webhook。
• 付帯作業：データ移行、テスト、研修、リリース、文書、保守を別に示します。
• 見積条件：担当人数、期間、前提、対象外、追加条件。
• 追加費用の例：重複整理、過去データ移行、基幹API調査、帳票調整が代表例です。オフライン検証、端末別検証、研修、リリース後の問い合わせも含まれます。

「画面10枚で一式」という見積では、権限や例外処理をどこまで含むかが分かりません。

「別途」の項目と、実施しない場合の影響を一覧にすると、価格だけでなく総額で比べられます。

AppSheetの委託先選定と見積比較の確認ポイント

委託先は、AppSheetを扱えるだけでなく、業務やデータ、権限を整理して、利用の定着まで支援できる会社を選びます。

Google Workspace導入支援会社、AppSheet専門会社、SIerは、それぞれ得意な領域が異なります。そのうえで、自社の課題に合う実績と範囲を確かめます。

アプリ数より業務・連携・定着まで見る実績

自社に近い業務の事例を聞き、必要な要件ごとに経験があるかを確かめます。

• 現場要件：入力、写真、位置情報、承認、在庫、帳票。
• 利用環境：オフラインや社外ユーザーへの対応。
• 連携・管理：SQL、API、ID管理、個人情報の経験。

導入期間だけでなく、利用者数や対象部署、アプリ数を聞きます。入力時間や転記ミス、定着率の変化も確かめます。承認時間の変化も、あわせて見ます。

担当交代後の運用や内製化研修、障害や仕様変更への対応も聞くと、開発後の支援力が見えます。

Google Workspace公式のLIXIL事例では、社内有志約250名の開発・テスト体制が紹介されています。

利用拡大前に500以上のアプリが作られ、国内全社展開後の約3か月で1万点、うち公式アプリが3,000点を超えました（出典: Google Workspace公式顧客事例「LIXIL」、2025年3月）。

本番アプリでは申請と審査が行われ、年1回の棚卸しも実施されています。バックエンドのデータモデルも統一されています。

担当者・体制・引継ぎの確認方法

担当者の体制と、発注者へ引き渡す情報を提案段階で確かめます。

• 担当者：要件定義、実装、データ・API、テスト、研修の担当者に会います。
• 再委託・欠員：再委託先の会社名、範囲、情報アクセス、どこまでを誰が受け持つかを聞きます。一人担当なら、休暇や退職時の体制も聞きます。
• 引渡し情報：所有権、管理者権限、データソース、Automation。API認証情報、バックアップ、履歴、設計書、操作マニュアルも含みます。
• 保守移管：委託先のアカウントだけに設定やデータアクセスを残さず、契約終了後に別会社へ移せるかを聞きます。

見積比較の前提条件の合わせ方

同じ条件で出された見積と、委託先が示すリスクへの対応の両面から比べます。

• 見積依頼：3社程度へ同じRFPを渡し、項目順もそろえます。
• 比較項目：総額や要件定義時間、実装範囲を比べます。移行件数、連携方式、テストケース、研修回数も含みます。
• 契約条件：保証期間、保守応答時間、別途費用を確かめます。安い見積では、要件定義やテスト、文書、保守が含まれない可能性があります。
• 技術リスク：Sheets全量取得による同期遅延、個人情報の制御、オフライン競合、API失敗時の再処理。
• 変更対応：法改正やGoogle側の変更への対応、できないことと代替策。

AppSheetのシステム発注・外注でよくある質問

料金や納期のほか、技術的な限界や契約後の運用がよく問われます。発注前に確かめておくと、使われないアプリや改修できない状態を避けやすくなります。

AppSheetのシステム開発は自作より外注の方が安いですか？

単純なフォームや一覧なら、自作の方が初期費用を抑えやすいです。ただし、外注の方が必ず安いとは限りません。

データ設計、権限、連携、テスト、研修、保守まで含めて比べます。さらに、社内工数や手戻りも費用として数えます。

また、PoCだけを外注する方法も選択肢です。

AppSheetの外注開発はどのくらいの期間がかかりますか？

期間は、案件の規模と発注者側の準備状況で変わるため、レビューの日数も含めて見積もります。

• 小規模PoC：1〜4週間が目安です。
• 部門向けアプリ：1〜3か月程度が推定の目安です。
• 複数部門・連携案件：APIやデータ移行を含み、3〜6か月程度です。

いずれも要件や進行条件で変わります。要件の確定やデータ整理、利用者レビューや承認が遅れると、全体のリードタイムは実装期間より長くなります。

発注者側がレビューに使える日数も、あらかじめ計画しておきます。

AppSheetに個人情報や顧客情報を保存しても安全ですか？

AppSheetには、認証や暗号化、Security Filterがあります。監査や管理の機能もあります。ただし、導入しただけで自社の要件を満たすとは限りません。

公式も、Security Filterだけでは完全な対策にならないとし、データソース側の保護が必要だと案内しています。

個人情報の範囲や権限、保存期間を、自社規程と照らし合わせます。委託先の閲覧や、端末紛失時の対応も確かめます。

納品後に自社でAppSheetを改修できますか？

所有者と管理者の権限、設計書が引き渡されれば、軽微な改修は社内で内製化できます。式やAutomation、データ構造、テスト手順も引き渡されると、社内で対応できる範囲が広がります。

社内担当者への研修も必要です。全社共通の変更や、権限・連携の変更には、レビューと本番反映のルールを残しておきます。

契約前に、研修の回数や質問できる期間、保守終了後の引継ぎ範囲を決めておきます。

まとめ

AppSheetの発注では、対象業務と成功指標を決めたうえで、要件やデータ・権限の設計、連携を含めます。さらに、テストや教育、保守も範囲に含めます。

一括外注、伴走型の部分外注、PoC外注から、自社の体制と内製化方針に合う形を選びます。

発注前のRFPと比較条件の整え方

ライセンス費と委託費は、分けて考えます。

PoCは20万〜100万円程度、部門向けアプリは50万〜300万円程度、連携案件は300万〜1,000万円程度を推定レンジの起点にします。

根拠と対象外の作業を確かめ、3社程度へ同じRFPを渡します。比較では、実績や体制、セキュリティを見るほか、引継ぎと保守も確かめます。

小さな検証から段階的な展開へ

入力負荷が大きく効果を測りやすい業務から始め、実データに近いPoCとパイロットで利用者の声を集めます。

本番展開の前に、権限や性能、同期を確かめます。通知や監査も、同じ段階で見ます。なお、RDBやAPI、別システムとの組み合わせも検討します。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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