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

AppSheetのシステム開発を発注・外注するなら、ライセンス費だけで判断せず、要件整理、データ設計、連携、テスト、教育、保守まで含めた業務改善プロジェクトとして委託することが成功の近道です。

AppSheetは、Google SheetsやExcelなどの表データから現場向けアプリを作りやすい一方、業務ルールや権限、既存システムとの接続まで自動で設計してくれるサービスではありません。この記事では、発注形態の選び方、RFPと要件のまとめ方、契約形態、費用相場、委託先の比較方法を、初めて外注する担当者にもわかるように解説します。

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

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

AppSheetの発注では、アプリの画面を作る作業だけでなく、入力前の業務、登録後の承認、通知、帳票、データの保管までを一つの流れとして捉えます。特に紙やExcelの置き換えでは、現在の運用をそのまま画面に移すだけでは、入力項目が多くなり、現場で使われないアプリになりやすいです。

外注と相性がよいのは、営業訪問記録、現場日報、点検・保守、在庫・棚卸、問い合わせ管理、申請・承認、設備台帳、配送進捗など、定型的な入力と確認が中心の業務です。写真、位置情報、バーコード、署名を使う現場では、スマートフォンやタブレットで入力できるメリットが大きく、転記時間や入力漏れの削減を効果として測りやすいです。

一方で、会計・給与のように法令や専門機能が中心の領域、複雑なトランザクション、大量データを短時間で同時処理する基幹業務、厳密な性能保証が必要なサービスは、AppSheet単体で置き換えられるとは限りません。AppSheetを入力フロントとして使い、データベースやAPIを組み合わせるハイブリッド構成、あるいはパッケージやスクラッチ開発を併用する判断も必要です。

AppSheetの料金は、アプリを作る費用ではなく、利用者やプランに応じて継続的に発生するサービス利用料です。公式料金ではStarterが5米ドル、Coreが10米ドル、Enterprise Plusが20米ドルのユーザー月額です（出典: Google AppSheet公式Pricing、2026年8月確認）。Coreは一部の有料Google Workspaceに含まれる場合がありますが、契約プランと対象機能の確認が必要です。

開発委託費には、業務ヒアリング、RFP作成支援、データの整理、画面・式・Automationの実装、外部連携、テスト、操作研修、リリース支援などが含まれます。見積書でこの二つが「開発一式」として混ざっている場合は、初期費用が安く見えても、後からデータ移行や保守費が追加される可能性があります。

AppSheetの発注形態はどれを選べばよいですか？

最適な発注形態は、自社の要件整理力、社内に残したい運用ノウハウ、連携の難しさ、リリース後の改修量で決まります。すべてを丸投げするか内製するかの二択ではなく、要件定義だけ外注し、実装と運用を社内で担うなど、工程ごとに役割を分ける方法も現実的です。

業務部門に専任のIT担当者がいない、複数の現場をまとめて短期間で導入したい、既存システムとのAPI連携や権限設計がある場合は、一括外注が向いています。委託先がヒアリングから設計、実装、テスト、研修、保守まで担当するため、社内の調整窓口を一本化しやすいです。

ただし、一括外注でも業務上の判断まで委託先に任せてはいけません。誰が何を入力し、誰が承認し、どの情報を正とするのかは発注者が決める事項です。アプリ定義、式、Bot、データモデル、API仕様、操作マニュアルを納品物に含め、担当者が退職しても引き継げる状態にすることが重要です。

現場の知識を社内に残したい場合は、初期の要件整理やデータ設計、難しい式のレビューだけを外注し、画面の追加や軽微な変更は社内で行う形が適しています。外部の担当者と社内の業務担当者が一緒に作るため、利用者の声を画面へ反映しやすく、リリース後の小さな改修にも対応しやすいです。

この形では、誰がアプリの所有者になるか、外注先がアクセスできる期間、レビューの方法、質問への回答時間をあらかじめ決めます。社内で作れる範囲を広げるために、操作研修だけでなく、命名規則、変更申請、テスト環境、本番反映の手順まで教えてもらうと、担当者依存を抑えられます。

対象業務がAppSheetに合うか不明な場合は、1業務、1部門、少人数に絞ったPoCを発注します。たとえば現場日報なら、入力項目、写真添付、上長確認、未提出通知までを作り、入力時間、提出率、転記ミス、承認までの時間を測定します。見栄えのよいデモではなく、実際の利用者が一定期間使った結果で本番化を決めることが大切です。

リサーチノートでは、AppSheetの小規模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月確認）。ただし、接続できることと、そのデータ構造が業務システムに適していることは別です。マスタ、明細、履歴、添付ファイル、個人情報をどう分けるかを先に決めます。

外部連携では、AppSheet REST APIでレコードの追加・更新・削除・検索やアクション実行を呼び出せます。また、AutomationからWebhookで外部サービスへ通知できます（出典: Google AppSheet Help「API integration points in AppSheet」、2026年8月確認）。連携先の認証方式、エラー時の再送、重複登録の防止、タイムアウト、障害時の手動復旧までRFPに書くと、単なる「API連携あり」という曖昧な見積を避けられます。

テストでは、画面が表示されるかだけでなく、権限ごとの見え方、同じデータを複数人が更新した場合、通信が不安定な場合、オフラインから同期した場合、写真や署名を登録した場合、BotやWebhookが失敗した場合を確認します。利用者が実際に使う端末と通信環境で試し、業務部門が合否を判断する受入テストを設けます。

本番公開は、いきなり全社へ展開せず、限定部署でパイロット運用を行います。AppSheetのDeployment Check、バージョン履歴、Monitor、Audit Historyを運用手順に組み込み、誰がいつ変更し、エラーをどう確認するかを明文化します。リリース後の問い合わせ窓口と、緊急時に旧運用へ戻す方法も決めておくと、現場の不安を減らせます。

AppSheetのRFP・要件整理では何を書けばよいですか？

RFPは、委託先に同じ条件で提案と見積を出してもらうための資料です。長い仕様書を最初から完成させる必要はありませんが、目的、対象範囲、利用者、現行業務、データ、連携、セキュリティ、納期、納品物、保守条件を最低限そろえます。情報が足りない部分は「提案してほしい事項」として分けて書くと比較しやすいです。

冒頭には「誰の、どの作業を、どう改善するか」を書きます。たとえば、営業担当30名が訪問後に紙の日報を提出し、管理者が翌日にExcelへ転記している場合、訪問先、活動内容、写真、次回対応、上長確認を対象にし、当日中の共有と転記廃止を目標にします。対象外として給与計算や会計連携を明記すれば、提案範囲が膨らみにくくなります。

利用者は、一般ユーザー、現場リーダー、承認者、管理者、外部協力会社などの役割に分けます。利用人数だけでなく、同時利用の想定、社外ユーザーの有無、共有端末の有無、サインイン方式も書きます。AppSheetの公式料金では、サインインユーザーはアカウントを基準に数え、サインインしないゲストは端末単位で数えられる場合があるとされています（出典: 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月確認）。データソース側の権限、端末紛失、外部共有、委託先アクセスも要件に含めます。

納品物には、アプリ本体だけでなく、アプリ定義、画面一覧、式とAutomationの一覧、データモデル、APIやWebhookの仕様、テスト結果、操作マニュアル、管理者マニュアル、バックアップ方法、教育資料を含めます。アプリの所有者と管理者アカウントを発注者側に置き、委託先の個人アカウントに依存しないことも重要です。

検収条件は「正常系の画面が動く」だけでは不十分です。役割ごとの権限、必須入力、重複防止、オフライン同期、通知、帳票、APIの成功・失敗、データ移行件数、端末別の操作を確認項目にします。検収後に見つかった不具合の無償修正期間、仕様変更として扱う条件、問い合わせへの初動時間もRFPに書くと、契約後の解釈違いを減らせます。

AppSheetの契約形態は請負と準委任のどちらがよいですか？

契約形態は、成果物と仕様が固まっているか、発注後に現場のフィードバックで変えるかで選びます。請負は合意した成果物の完成を重視し、準委任は一定の専門人材・作業時間による支援を重視します。AppSheetは使いながら改善する案件が多いため、全工程を一つの契約形態にせず、要件定義と初期開発、運用改善で分ける方法もあります。

対象業務、画面、データ項目、権限、通知、帳票、受入条件が決まっている場合は、請負契約で成果物と納期を明確にします。PoC後に本番仕様が固まり、限定部署向けのアプリを予定どおり作る段階では、請負の方が予算と検収を管理しやすいことがあります。

請負でも、AppSheetのライセンス契約やGoogle Workspaceの管理設定まで委託先が負うとは限りません。どこまでが成果物で、どのサービス費が発注者負担かを分けて記載します。アプリ定義や式の著作権・利用権、第三者素材、再委託の可否、ソース相当の設定情報の引渡しも契約条項に入れます。

現場へのヒアリング、業務フローの整理、データクレンジング、社内担当者への伴走、リリース後の改善など、作業しながら内容が具体化する工程は準委任契約が合いやすいです。作業時間や体制、定例会、報告内容、相談への対応時間を決め、成果物を一方的に固定しすぎないようにします。

準委任では、時間を使ったことだけが評価される契約にならないよう、月ごとの到達目標を設定します。たとえば1か月目は業務フローとデータ項目の確定、2か月目は現場日報の試作とテスト、3か月目は限定部署への展開と研修というように、会議体と成果の確認方法を決めます。

保守契約では、問い合わせ対応、権限変更、式やBotの軽微な修正、データ復旧、Google側の仕様変更への確認、脆弱性や制度対応、月次レポートを分けて定義します。AppSheet公式のAudit Historyは、Enterprise Plusでは53日、その他のプランでは7日保持と案内されています（出典: Google AppSheet Help「Monitor app activity using Audit History」、2026年8月確認）。長期保管が必要な監査ログは、別途エクスポートやデータソース側の仕組みを検討します。

保守費は、リサーチノートでは初期費用の年15〜25％を目安としていますが、公式の一律相場ではありません。対象アプリ数、利用者数、連携先、受付時間、障害時の復旧目標、改修の月間上限で大きく変わります。月額に含む作業と、別見積になる機能追加を明確にし、使わない月も支払う固定費か、作業量に応じた従量費かを比較します。

AppSheetの発注・外注費用相場はいくらですか？

AppSheetの外注費は、アプリの画面数だけで決まらず、データの状態、権限、連携、移行、テスト、教育、保守の範囲で変わります。以下はリサーチノートと一般的な業務システムの工程をもとにした発注時の推定レンジです。AppSheet公式が日本の受託開発費を定めているわけではないため、予算計画の起点として使い、同じRFPで複数社から見積を取ります。

小規模なPoCや1業務のアプリは、フォーム、一覧、写真、簡単な通知に絞る場合で20万〜100万円程度、期間は1〜4週間程度が推定の目安です。社内担当者が主体となり、外部には要件整理やレビューだけを依頼する場合は下限寄りになりやすいです。

顧客管理、日報、点検、在庫などの部門向け実用アプリは、権限、帳票、データ整備、テスト、研修を含めて50万〜300万円程度、期間は1〜3か月程度が推定レンジです。複数部門、複数データソース、承認、API、SQL連携、データ移行、監査を含む案件は300万〜1,000万円程度、3〜6か月程度を見込みます。

Enterprise Plus、Cloud SQL、BigQuery、API基盤、ID管理、全社データ移行、厳格な運用設計を組み合わせるエンタープライズ案件では、1,000万〜3,000万円以上となる可能性もあります。この金額帯はAppSheetのアプリ作成費だけではなく、周辺のクラウド、データ、セキュリティ、移行、教育を含む場合の推定です。案件の前提を分解せず、特定の金額だけを断定することは避けます。

公式料金のStarter 5米ドル、Core 10米ドル、Enterprise Plus 20米ドルを、記事作成時の概算として1米ドル=150円で換算すると、約750円、約1,500円、約3,000円のユーザー月額です。ただし、実際の請求は為替、税、契約形態、Google Workspaceへの含まれ方で変動します。見積書には、どのプランを何人分、誰を利用者として数えたかを記載してもらいます。

サインインユーザーだけでなく、社外ユーザー、共有端末、サインインを求めない公開アプリの扱いも確認します。Publisher Proは50米ドル／アプリ／月で公開アプリを作れると公式に案内されていますが、サインインやSecurity Filterを使えず、機密情報を扱う社内システムの代替にはなりません（出典: Google AppSheet公式Pricing、2026年8月確認）。安いプランを選ぶより、必要な認証・権限・監査機能から逆算します。

見積書は、要件定義、業務フロー整理、データ設計、画面・式、Automation、API・Webhook、データ移行、テスト、研修、リリース、ドキュメント、保守の項目に分けてもらいます。各項目について、担当人数、期間、前提、含まない作業、追加になる条件を確認します。「画面10枚で一式」のような表現だけでは、権限や例外処理がどこまで含まれるか判断できません。

特に追加費用になりやすいのは、元データの重複整理、過去データの移行、既存基幹システムのAPI調査、帳票の細かなレイアウト、オフライン時の挙動、端末ごとの検証、利用者研修、リリース後の問い合わせです。提案段階で「別途」と書かれた項目を一覧にし、実施しない場合の影響も説明してもらうと、価格だけでなく総額で比較できます。

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

委託先は「AppSheetを触れる会社」ではなく、業務を整理し、データと権限を設計し、使われる状態まで伴走できる会社を選びます。Google Workspaceの導入支援会社、AppSheet専門会社、一般的なSIerでは得意領域が異なるため、自社の課題に合う実績と支援範囲を見極めます。

実績確認では、単に「AppSheetの開発実績が多数」と書かれているかではなく、自社に近い業務の事例を聞きます。現場入力、写真、位置情報、承認、在庫、帳票、オフライン、社外ユーザーなど、必要な要件ごとに経験を確認します。既存のGoogle Workspaceだけでなく、SQLやAPI、ID管理、個人情報を扱った経験があるかも重要です。

事例の成果は、導入期間だけで判断しません。利用者数、対象部署、アプリ数、入力時間、転記ミス、承認時間、定着率など、公開できる範囲の具体的な変化を確認します。担当者の交代後も運用できたか、内製化研修があったか、障害や仕様変更にどう対応したかを聞くと、開発後の実力が見えやすいです。

大規模展開の事例では、ガバナンスも委託先選びの重要な評価対象になります。Google Workspace公式のLIXIL事例では、約250名の社内有志による開発・テスト体制を設け、利用拡大前には500以上のアプリが作られ、国内全社展開後の約3か月でアプリ数が1万点、うち公式アプリが3,000点を超えたと紹介されています（出典: Google Workspace公式顧客事例「LIXIL」、2025年3月）。本番アプリの申請・審査、年1回の棚卸し、バックエンドのデータモデル統一まで設計している点は、外注後の運用にも参考になります。

提案時には、営業担当だけでなく、要件定義を行う人、AppSheetを実装する人、データやAPIを担当する人、テストと研修を担当する人に会います。再委託がある場合は、会社名、担当範囲、情報アクセス、責任分界を確認します。少人数の会社でも問題ありませんが、担当者が一人しかいない場合は、休暇や退職時のバックアップ体制を確認します。

引渡しでは、アプリの所有権、管理者権限、データソース、Automation、API認証情報、バックアップ、バージョン履歴、設計書、操作マニュアルを発注者側に移します。Google AppSheetは設定情報やデータアクセスが複数のサービスにまたがるため、委託先のアカウントにしか存在しない情報を残さないようにします。契約終了後に自社で別会社へ保守を移せるかも、選定時に確認します。

3社程度に同じRFPを渡し、見積項目を同じ順番で出してもらいます。比較するのは総額だけでなく、要件定義の時間、実装範囲、データ移行件数、連携方式、テストケース、研修回数、保証期間、保守の応答時間、別途費用の条件です。極端に安い見積は、要件定義やテスト、ドキュメント、保守が含まれていない可能性があります。

提案の質は、発注者が説明していないリスクをどのように指摘するかにも表れます。たとえば、Sheetsの全量取得で同期が遅くなる可能性、個人情報を扱う場合のアクセス制御、オフライン時の競合、API失敗時の再処理、法改正やGoogle側仕様変更への対応です。都合のよい機能一覧だけでなく、できないことと代替策を説明する会社を選びます。

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

AppSheetを外注するときは、料金、納期、技術的な限界、契約後の運用がよく質問になります。発注前に確認しておけば、安く作ったものの現場で使えない、担当者が変わって改修できない、といった事態を避けやすくなります。

単純なフォームや一覧だけなら自作の初期費用を抑えやすいですが、外注の方が必ず安いとは限りません。データ設計、権限、連携、テスト、研修、保守まで含めて比較する必要があります。社内の工数や手戻りも費用として考え、PoCだけ外注する方法も選択肢になります。

小規模なPoCは1〜4週間、部門向けの実用アプリは1〜3か月、複数部門やAPI・データ移行を含む案件は3〜6か月程度が推定の目安です。要件の確定、現行データの整理、利用者のレビュー、承認手続きが遅れると、実装期間より全体のリードタイムが長くなります。納期だけでなく、発注者側がレビューに使える日数も計画します。

AppSheetには認証、暗号化、Security Filter、監査、管理機能がありますが、導入するだけで自社の安全要件を満たすわけではありません。Google AppSheet公式も、アプリのSecurity Filterだけでは完全なセキュリティ対策にならず、データソース側の保護が必要と案内しています。個人情報の範囲、アクセス権、保存期間、委託先の閲覧権限、端末紛失時の対応を自社の規程と照合します。

アプリの所有者と管理者権限、設計書、式、Automation、データ構造、テスト手順が引き渡され、社内担当者が研修を受ければ、軽微な改修を内製化できます。全社共通の変更や権限・連携に関わる変更は、レビューと本番反映のルールを残すことが大切です。契約前に、研修回数、質問できる期間、保守終了後の引継ぎ範囲を確認します。

まとめ

AppSheetのシステム開発を発注・外注するときは、まず対象業務と成功指標を決め、要件定義、データ・権限設計、連携、テスト、教育、保守までを発注範囲として整理します。発注形態は、一括外注、伴走型の部分外注、PoC外注から、自社の体制と内製化方針に合わせて選びます。

費用はライセンス費と委託費を分け、20万〜100万円程度のPoC、50万〜300万円程度の部門向けアプリ、300万〜1,000万円程度の連携案件という推定レンジを起点にします。金額の根拠と含まれない作業を確認し、3社程度へ同じRFPを渡して、価格だけでなく実績、体制、セキュリティ、引継ぎ、保守を比較します。

最初から全社の業務を一つのアプリへ詰め込むのではなく、現場の入力負荷が大きく、効果を測りやすい業務から始めます。実データに近いPoCとパイロットで利用者の声を集め、権限、性能、同期、通知、監査を確認してから本番展開します。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を創業。