スプレッドシートは業務データの置き場として広く使われています。無料で始められ、権限を渡せば共有でき、表計算の操作をそのまま使えます。データベース製品を用意するより立ち上がりが速く、最初の一手としては合理的です。
つまずくのは、置き場として成立した後です。行が増え、触る人が増え、「入力されたら通知したい」「別のシステムへ渡したい」という要求が出てきます。このとき、スプレッドシート単体で届く範囲と届かない範囲が分かれます。
以下では、Googleスプレッドシートの仕様を公式ヘルプで確認しながら、データベースとして設計するときの原則、限界が出る地点、その先の選択肢を整理します。引用した仕様はいずれも2026年8月12日に取得したものです。
スプレッドシートはデータベースとして使えますか？
使えます。ただし「どこまで持つか」を先に決めることが条件になります。
容量の上限は公式に明記されています。"Up to 10 million cells or 18,278 columns (column ZZZ) for spreadsheets that are created in or converted to Google Sheets."（Google ドライブ ヘルプ、2026-08-12取得）
1,000万セルは、20列の表であれば50万行に相当します。多くの業務データはこの範囲に収まるため、行数の上限が理由で行き詰まることは実務上あまり起きません。
先に来るのは別の壁です。誰に何を見せるか、変更をどう検知するか、同時に書き込まれたときどうなるか。データベース製品が標準で担っている部分が、スプレッドシートでは人の運用に委ねられています。
データベースとスプレッドシートの違いは何ですか？
違いは2点に集約できます。型を守る主体が誰かという点と、同時に書き込まれる前提があるかという点です。
データベースは列ごとにデータ型を定義し、規則に反する値を受け付けません。日付の列に「未定」と入れることはできません。スプレッドシートのセルには何でも入ります。表示形式は設定できますが、規則を守るのは入力する人です。
もう1点は書き込みの扱いです。データベースは複数の処理が同じ行を同時に更新する前提で、順序と整合性を制御します。スプレッドシートの共同編集は、人が同じ画面を見ながら編集するための仕組みで、処理の整合性を保証するものではありません。
この違いは、表どうしのつなぎ方にも出ます。データベースはキーで表を関連づけ、関連が壊れる操作を拒否します。スプレッドシートで同じことをするには、VLOOKUP や QUERY のような式を使います。式は列の位置や範囲を指しているため、列を1つ挿入した時点で参照先がずれます。
つまりスプレッドシートでは、構造そのものが「誰かが式を壊さないこと」に依存しています。人数が増え、触る頻度が上がるほど、この前提は保ちにくくなります。
データベースとして設計する4つの原則
置き場として使うと決めたら、最初に構造を決めます。ここを飛ばすと、行が増えてから作り直すことになります。
1行1レコードにする。 1行が1つの事実を表す形にします。1つのセルに複数の値をカンマで詰めない、結合セルを使わない、見出し行は1行だけにする。この形を外すと、後から機械が読めません。
一意キーを持つ。 各行を一意に指す列を1つ置きます。会社名や担当者名は重複し、改称もするためキーになりません。連番でも、他システムが発行したIDでも構いません。キーが無い表では、後から重複を見つけられません。
列の型を1つに固定する。 1つの列に日付と文字列を混ぜない。「2026/08/12」と「8月中」を同じ列に入れると、並べ替えも集計も自動化も止まります。値が確定しない場合は、状態を表す列を別に足します。
マスタとトランザクションを分ける。 変わらないもの（会社、商品、担当者）と、起きたこと（受注、問い合わせ、対応履歴）を別のシートに置き、キーで参照します。1枚に全部を並べると、会社名を1つ直すために全行を直すことになります。
この4つは、後でデータベースやCRMへ移すときの移行コストも決めます。構造が整った表はそのまま取り込めます。整っていない表は、移行の前に人が直すことになります。
限界が出る3つの地点
構造を整えても越えられない範囲があります。仕様として決まっている部分なので、運用の工夫では埋まりません。どこで当たるかを先に知っておくと、移行の判断が早くなります。
権限：保護は編集制御であって、表示制御ではない
シートやセル範囲の保護は、編集を制限する機能です。閲覧を制限する機能ではありません。公式ヘルプは非表示シートについて "Spreadsheet viewers can still access content in hidden sheets, for example by using the browser's Developer tools." と記載しています（Google ドキュメント エディタ ヘルプ、2026-08-12取得）。
同じヘルプは "Protect data with a password" を、できないこととして挙げています。
ファイルを開ける人は、原則としてそのファイルの中身を見られます。 原価や個人情報のように見せる相手を絞る必要があるデータは、シートを分けるのではなく、ファイルを分けて権限を設計します。
通知：標準で指定できる条件は2つだけ
変更を知らせる仕組みは用意されています。ただし条件は限定的です。公式ヘルプが挙げる通知ルールの条件は "Any changes are made" と "A user submits a form" の2つです（Google ドキュメント エディタ ヘルプ、2026-08-12取得）。
同ヘルプは、より細かい条件で通知したい場合について "use Apps Script" と案内しています。
「特定の列が特定の値になったときだけ」「金額が一定を超えたときだけ」という条件は、標準機能の範囲外です。運用で実際に要求されるのは、この細かい条件のほうです。
同時実行：最後に書いた値が残る
共同編集は、人が同時に開いて編集するための仕組みです。同じセルを2人が別の値に変えれば、後から確定したほうが残ります。
行の追加でも同じことが起きます。「最終行を探して、その下に書く」処理を2つ同時に走らせると、同じ行を狙って上書きが起きます。人の手作業では滅多に起きませんが、自動で書き込む処理を足した瞬間に確率が上がります。
置き場が育つと、最初に壊れるのは中身
権限・通知・同時実行は仕組みの限界です。運用の現場でそれより先に表面化するのは、入っているデータそのものの状態です。
同じ会社が「株式会社Mer」「(株)Mer」「Mer」の3通りで入る。担当者が退職して、行だけが残る。同じ問い合わせが、フォーム経由と手入力で2件になる。どれも入力を止める仕組みが無いことの結果で、行が増えるほど確実に増えます。
この状態のまま自動化を足すと、揃わない結果がそのまま出てきます。重複した会社が2件あれば通知も2回飛び、集計は実態より多い数を返します。自動化が悪いのではなく、参照しているデータが揃っていません。
対処は2つの方向に分かれます。入り口を絞る（自由入力をやめてプルダウンにする、入力経路を1本にする）か、入った後に整える仕組みを置くか。自動化を検討する前に、どちらを取るかを決めておく必要があります。
自動化を足すときの分岐
上の3つに当たったとき、選択肢は2つです。Apps Scriptで書くか、外部の自動化ツール（iPaaS）でつなぐか。
Apps Scriptは、Google Workspaceの中で完結させる方法です。公式が通知の拡張手段として案内している経路で、シートの操作と条件判定をそのまま記述できます。コードを書ける人が社内にいて、対象がGoogle Workspaceの中で閉じるなら、これが最短です。
iPaaSは、外部サービスとつなぐ方法です。自動化ツールは「起点」と「接続先の鍵」を分けて管理します。n8nの公式ドキュメントは、本番で動かすワークフローに最低1つのトリガーが必要だと定義し（"All production workflows need at least one trigger to determine when the workflow should run."）、認証情報をノードとは別に保管する設計だと記載しています（n8n 公式ドキュメント、2026-08-12取得）。
判断軸は、接続先が社外に出るかどうかです。スプレッドシートとGmail、カレンダーの範囲で閉じるならApps Script、CRMや基幹システムへ渡すならiPaaS。ここを取り違えると、作った後にもう一度作り直すことになります。
費用の考え方も分かれます。iPaaSの多くは実行量で課金し、n8nはワークフローの実行回数、Makeはクレジット、Zapierはタスクを単位にしています（各社公式、2026-08-12取得）。1行につき1回動かす設計にすると、行数がそのまま費用になります。 課金単位ごとの伸び方はn8nとはで扱っています。
自動化を足す前に決める3つ
どちらを選ぶ場合も、作り始める前に決めておく項目があります。ここを決めずに動かすと、動いている間は問題が見えず、止まってから慌てることになります。
失敗にどう気づくか。 自動化は失敗しても静かに止まります。通知が来ないことと、通知すべき変更が無かったことは、外から見分けがつきません。失敗時に人へ知らせる経路を、処理そのものと一緒に作ります。
誰が直すか。 作った人が異動した後も動き続けます。何のための処理か、止めてよいか、直すには何を触るかを、書き残す先とあわせて決めます。
鍵を誰が持つか。 外部サービスにつなぐと、APIキーやOAuthの認可が発生します。個人アカウントの権限で組むと、その人が退職した時点で止まります。接続に使うアカウントは、最初から共有のものにしておきます。
どこまでスプレッドシートで持つか
判断の目安は次のとおりです。
条件 | スプレッドシートで持つ | 別システムへ移す |
|---|---|---|
見せる相手を絞る必要がある | × | ○ |
条件つきの自動処理が要る | △（Apps Script） | ○ |
複数の処理が同時に書き込む | × | ○ |
履歴を追跡する必要がある | △（変更履歴のみ） | ○ |
部門をまたいで参照する | △ | ○ |
一時的な集計・検討用 | ○ | — |
見方は単純です。閲覧の制限が要るか、条件つきの自動処理が要るか。このどちらかが出た時点で、スプレッドシート単体では足りません。
△を付けた行は「できるが、担い手が要る」という意味です。Apps Scriptで条件つきの処理は書けますが、書いた後に保守する人が必要になります。変更履歴も残りますが、いつ誰がどの値をどう変えたかを業務の記録として使うには向きません。△は、仕組みではなく人で埋めている状態を指します。
足りないと分かったとき、すべてを移す必要はありません。データはスプレッドシートに置いたまま自動化だけ外に出す、参照頻度の高い項目だけ別システムに持つ、という段階を踏めます。
diverは、業務フローの設計からツールの実装、運用の定着までを担う社外RevOpsチームです。どこまでを表計算で持ち、どこから仕組みに移すかを含めて設計したい場合は、diverへ相談するところから始められます。
よくある質問
スプレッドシートをデータベース代わりにするにはどうすればいいですか？
構造を先に決めます。1行1レコード、一意キー、列ごとの型の固定、マスタとトランザクションの分離の4点です。この形を守った表は、集計・自動化・他システムへの移行がそのまま通ります。順序として、シートを作る前に列の定義を決めるほうが手戻りが出ません。
何行を超えたらデータベースに移すべきですか？
行数では決まりません。上限は1,000万セル（20列なら50万行）で、多くの業務データはその手前で運用上の問題に当たります。移行の判断材料になるのは、閲覧を制限する必要が出たか、条件つきの自動処理が要るか、複数の処理が同時に書き込むかの3点です。
スプレッドシートは同時に何人でも編集できますか？
共同編集は前提として設計されていますが、同じセルを別の値に変えた場合は後から確定したほうが残ります。人が交代で触る運用では問題になりにくく、自動で書き込む処理を足すと表面化します。書き込みを行う処理が2つ以上になる時点で、順序を制御する仕組みが必要です。
特定の条件を満たしたときだけ通知できますか？
標準機能では指定できません。通知ルールの条件は "Any changes are made" と "A user submits a form" の2つで、それより細かい条件については公式ヘルプが "use Apps Script" と案内しています（2026-08-12取得）。外部サービスへ通知や登録まで行う場合は、iPaaSを使う構成になります。
シートを非表示にすれば見られませんか？
見られます。公式ヘルプは、非表示シートの内容にも閲覧者がアクセスできると明記しています。保護機能が制御するのは編集であって表示ではありません。見せる相手を絞る必要があるデータは、ファイルそのものを分けて権限を設計してください。
表記ゆれや重複はどうすれば防げますか？
入力の自由度を下げるのが先です。会社名や区分のように選択肢が決まる項目は、データの入力規則でプルダウンにします。入力経路が複数ある場合は、フォームなど1本に寄せて、直接入力を例外扱いにします。すでに溜まった分については、一意キーを決めてから重複を突き合わせる作業になります。
他システムへ移すとき、何を準備すればいいですか？
移行先が要求する形は、多くの場合1行1レコードと一意キーです。設計の4原則を満たした表であれば、列名の対応づけだけで取り込めます。満たしていない場合は、結合セルの解除、1セル内の複数値の分割、日付形式の統一を先に済ませます。この作業量が、構造を最初に決めるかどうかで変わります。
進めるときの順番
最初に決めるのは、そのデータを最終的にどこで持つかです。スプレッドシートを恒久的な置き場にするのか、次の仕組みへ渡すまでの入口にするのか。
入口として使うと決めたなら、4つの原則に沿って構造を整えるだけで、後の移行は短く済みます。恒久的に持つと決めたなら、閲覧制限と自動処理の2点について、どこで妥協するかを先に決めておく必要があります。
判断を先送りにしたときに起きるのは、両方が中途半端に進む状態です。恒久的な置き場のつもりで運用しながら、限界に当たるたびにApps Scriptを1本ずつ足していく。半年後には、誰も全体像を把握していない処理が並びます。移すかどうかより、いつ決めるかのほうが影響が大きいのはこのためです。
フォームからの入力を起点にする場合は、Googleフォームとスプレッドシートの連携もあわせて確認してください。部門をまたぐ自動化を検討する段階であれば、AIワークフロー自動化の考え方が対応します。
参照元
記事情報
著者: diver編集部
レビュー: diverチーム
更新日: 2026年8月12日
部門間データ連携を、実装できる業務フローへ
既存ツールを活かしながら、どの境界から直すべきかを整理します。
