Glide無料プランの機能比較と移行チェックリスト

想定読者とこの記事の使い方

対象はプロダクトマネージャー（PM）、アプリ開発者、運用担当（SRE/IT）です。
PoCの評価基準を素早く決めたいPM、負荷／連携の実務検証を行う開発者、SLAや監査要件で判定する運用担当が主な想定読者です。各役割に向けて必要な章と深さを案内します。

• PM向けに読む箇所：要点サマリ、移行判断のKPI、コスト試算テンプレート。
• 開発者向けに読む箇所：公式数値参照表、負荷試験手順、外部連携（API/Webhook）欄。
• 運用担当向けに読む箇所：監査・ログ、DPA/法務チェック、バックアップ・ロールバック手順。

重要ポイントの要約

Freeプランは短期PoCや社内小規模運用に適していますが、レコード増加・ピーク同時接続・外部連携頻度・認証要件（SSO）・監査ログなどで限界が出ます。Proはブランド／公開向け、BusinessはSSOや監査ログ等の企業要件を満たすための主な差分です。まずは実データに近いPoCで応答時間（p95）、エラー率、API呼び出し頻度を測定してください。

Glide公式数値の参照と管理ルール

主要上限（行数、同時接続、ストレージ、API/Webhookレート等）は頻繁に更新されます。導入判断で使う場合は必ず公式の料金／仕様ページを参照し、参照日と確認者を記録してください。下表は公式情報を整理するためのテンプレートと、運用意思決定に使える「参考閾値」を併記したものです。

公式参照一覧（確認手順付き）

下表の「公式値」欄は必ず公式ページで確認して入力してください。公式確認は料金ページとドキュメント（機能一覧・FAQ）を両方参照し、確認者名と参照日を記録してください。

参照手順（簡易）：

1. 上の参照URLを開き、該当項目の表記（プラン別）を確認する。
2. 画面のスクリーンショットは取らず、参照日と確認者名を表に記録する。
3. 変更が見つかった場合は「更新フラグ」を立て、影響範囲を評価する（後述の更新ルールを参照）。

Glide Freeプランの機能と実務制約

ここではFreeプランで実務的に確認すべき事項を整理します。機能の有無や上限は必ず公式参照表で確認してください。

利用可能な主要機能

Freeプランで一般に使える機能の概要です。詳細は公式で確認してください。

• アプリ作成とビルダーによるUI構築（テンプレート利用含む）。
• 標準コンポーネント（リスト、カード、フォーム、チャート等）。
• データソース接続（Google Sheets 等、Glide Tables の利用可否は公式参照）。
• 公開リンク共有、基本的なログイン（Google／メール等）機能（高度なSSOは制限されることが多い）。
• 基本的な計算列やフィルタ、条件表示などの編集機能。

Freeプランで特に確認すべき具体項目

以下は導入時に必ず数値で確認すべき項目です。各項目は公式ページの該当欄を参照し、表に記録してください。

• アプリあたりのレコード（行）上限：増加予測と照合すること。
• 同時接続・同時書き込みの目安：ピーク時にエラーが出ないか負荷検証すること。
• 画像・添付ファイルのストレージ上限：高解像度画像を多用する場合は外部ストレージを検討。
• API／Webhookの有無とレート上限：リアルタイム連携が重要な業務はここでボトルネックになる可能性あり。
• カスタムドメイン・白ラベル可否：顧客公開時のブランド要件を満たすか確認。
• SSO/SAML/SCIMおよび監査ログの提供有無：企業のID管理・監査要件を満たすかを確認。

Freeプランでの実務的な回避策（短期）

Freeプランで運用する場合の現場で使える暫定的な対応例です。

• データ分割：テーブルを分割して主要クエリの負荷を下げる。
• 外部ストレージ活用：画像や大きなファイルはGoogle Drive/S3に置き、URLのみ保存する。
• 外部DB併用：成長が見込まれるデータは外部DBに置き、Glideは表示用メタデータに限定する。
• 連携のバッファ化：Zapier/Make/Queueを使いWebhook負荷を平準化する。
• 定期エクスポート：CSV/JSONで定期バックアップを取得し、古いデータはアーカイブする。

移行判断のKPIと検証手順（PoC→本番）

移行判断に使うKPI、測定方法、合格基準を具体的に示します。合格基準は業務重要度に応じて調整してください。

KPI一覧（測定方法と例示閾値）

下は代表的なKPIと実務での測定方法、例示閾値です。閾値は一律適用せず業務要件で調整してください。

• 応答時間（p95）
• 測定方法：典型的なユーザーフローを負荷試験で実行し、p95応答時間を記録。ブラウザのRUMも併用。

• 例示閾値：p95 < 2.0 秒（一般業務）、p95 < 1.0 秒（顧客向けクリティカル）。

• エラー率（HTTP 4xx/5xx またはアプリエラー）

• 測定方法：負荷試験・本番ログの割合を算出。

• 例示閾値：エラー率 < 1.0%（許容）、< 0.1%（高信頼運用）。

• ピーク同時接続（同時書き込み含む）

• 測定方法：負荷試験でピークを再現し、エラー発生点と比較。

• 例示閾値：運用条件により設定。小規模内製サービスは50同時、業務系は100〜200同時を想定して評価。

• レコード増加率（月次）

• 測定方法：PoCでの月次増加を記録し6か月予測。

• 例示閾値：予測値が公式上限の70%を超える場合は移行検討。

• API/Webhookスループットと遅延

• 測定方法：外部連携の呼び出しログを集計して秒レートとエラーを確認。
• 例示閾値：レートが公式上限の70%を超える前にPro/Businessを検討。

負荷試験の実務手順（再現可能なステップ）

概要：典型ワークフローを定義 → シナリオ化 → ツールで実行 → メトリクス収集 → 判定。

1. シナリオ設計：画面表示（読み取り）、フォーム送信（書き込み）、画像アップロード等をワークフローとして定義する。
2. テストデータ準備：実運用に近いデータ分布とサイズで準備する。
3. ツール選定と設定：k6 / Locust / Artillery / Apache JMeter を推奨。負荷プロファイルは「Ramp-up（増加）→ Sustain（維持）→ Ramp-down」。
4. 実行例（k6 の簡易スクリプト）：

javascript
import http from 'k6/http';
import { check, sleep } from 'k6';
export let options = {
stages: [
{ duration: '3m', target: 50 },
{ duration: '10m', target: 50 },
{ duration: '2m', target: 0 },
],
};
export default function () {
let res = http.get('https://your-app.glideapps.app/');
check(res, { 'status 200': (r) => r.status === 200 });
sleep(1);
}

上記は基本的な例です。POST/PUTを使った書き込みシナリオや認証トークンの付与が必要な場合はスクリプトを拡張してください。

1. 収集指標：p50/p95/p99、エラー率、スループット（requests/sec）、成功/失敗の割合、平均送信サイズ。
2. 判定：事前に定めた閾値を超えていないか確認。超える場合はPro/Businessでのトライアルかアーキテクチャ変更を検討。

ログ収集とエクスポートの実務例

• 取得方法：Glideの監査ログ（Businessで提供されることが多い）をCSV/JSONでダウンロード。未提供の場合はWebhookで自前ログ受信エンドポイントを用意。
• 形式：JSON Lines（jsonl）を推奨。解析用にCSVエクスポートも用意。主要フィールド：timestamp, user_id, action, record_id, status, latency_ms, error_code。
• 集約／可視化：Datadog / Sentry / Elastic Stack 等でインジェストし、アラート基準（エラー率やp95超過）を設定する。
• データ整合性チェック：エクスポートしたCSVの行数、主要キーの重複チェック、各フィールドのハッシュ（例：SHA256）で整合性を検証。

法務・利用規約上の必須確認事項（商用展開前）

商用展開前に最低限確認すべき契約・法務項目を列挙します。確認の有無は必ず記録し、必要であれば法務/調達と契約交渉してください。

商用利用と利用規約

• 利用規約（Terms of Service）で商用利用の制限・禁止事項を確認すること。特に再販やサブライセンスの可否を確認。
• 課金形態（課金サイクル、キャンセルポリシー、返金条件）を確認。

データ保護・DPA・データ移転

• DPA（Data Processing Agreement）の提供有無と契約条項を確認し、必要ならDPA締結を要求する。
• データの保存地域（リージョン）と国外移転に関する制限を確認。GDPR等に基づくデータ主体の権利行使が可能かを確認する。
• サブプロセッサ一覧（外部委託先）とそのセキュリティ準拠状況（SOC2/ISO27001 等）を確認する。

セキュリティ・インシデント対応・責任範囲

• 暗号化（転送中および保存時）の有無。
• 脆弱性開示・インシデント発生時の通知期間（例：72時間以内）を確認。
• 責任賠償上限、保証除外事項、保険（サイバー保険等）の有無をレビュー。

商用チェックリスト（合格基準の例）

• DPAが交付され、主要条項（処理範囲、目的、データ削除、監査権）が含まれること。
• データエクスポート（完全なCSV/JSONダンプ）が可能で、リストア手順が文書化されていること。
• 監査ログが取得でき、保存期間・出力形式が要件を満たすこと。
• SSO要件がある場合はSAML/SCIMの対応可否とテストフローが合意されていること。

Pro／Businessでの主要差分と選定ポイント

Pro/Business/Enterpriseの差分は契約や時期で変わります。以下は運用決定に使う観点と、確認すべき項目の明確化例です。

機能差分（運用決定向けの概観）

H3の導入文：下表は機能の有無を判定するための観点を整理したものです。公式の機能比較表で必ず値を確認してください。

注：上表は「運用決定観点」を整理したもので、各セルは必ず公式ページ・営業窓口で確認してください。曖昧な箇所は「要確認」として契約時に文書化することを推奨します。

コスト試算テンプレートと運用ルール

ここでは簡易コスト試算テンプレートと、公式数値の更新・確認フローを示します。実コストは為替や契約条項で変化します。

コスト試算（簡易例：参考値）

注：上の数値は例示です。ライセンス費用は公式料金ページの記載を必ず参照してください。

公式数値の更新・確認フロー（推奨）

1. 定期確認：本番運用中は月次、PoC段階は四半期ごとに公式料金/仕様ページを確認する。
2. 記録：参照日と確認者を「公式参照一覧」表に記入する。
3. 変化時の対応：数値が変わった場合はPMが影響分析を実施し、技術・法務・コストの観点で改定案を提示する。
4. 緊急時：公式が重要上限を下方改定する等、重大影響がある場合は72時間以内に関係者を招集し暫定対応（スロット制限、機能停止等）を実施する。
5. バージョン管理：表の更新履歴（参照日、確認者、変更要点）を内部ドキュメントで管理する。

実運用事例からの学び（短いまとめ）

• 成功例：PoC段階で実データを入れ、Proへ移行して公開。事前の負荷測定とドメイン移行でスムーズに公開できた。
• 失敗例：公開設定のチェック漏れでデータが外部公開された。公開前に複数者で権限・公開設定の確認を必須化すべき。
• 失敗例：データ増加を過小見積もりし、パフォーマンス劣化で業務に支障。早期に成長シナリオを想定し、外部DB併用を検討すること。

まとめと推奨アクション

まずはFreeプランでPoCを作成し、実データに近い負荷でp95応答時間、エラー率、API/Webhook頻度、レコード増加を測定してください。公式の料金・仕様ページで各上限（行数・同時接続・ストレージ・APIレートなど）を必ず参照し、参照日と確認者を表に記録する運用ルールを導入してください。業務要件（SSO／監査／ブランド公開）がある場合は早期にPro/Businessのトライアルを行い、特に法務面（DPA等）の確認を契約前に完了させることを推奨します。