データベース化を判断する基準｜Googleスプレッドシートの件数・共有・権限の限界

Googleスプレッドシートを使い続けるべきか、データベースへ移行すべきか。この判断は、感覚ではなく次の4点で決まります。

 

1つ目は件数です。行数と列数を掛け合わせたセル数が実質的な上限に近づき、開く・集計する・フィルタをかけるといった操作に待ち時間が発生しているかどうかです。列が多い台帳ほど、この上限には早く到達します。

 

2つ目は共有です。目安として5〜10人以上が同じ台帳を頻繁に同時編集し、入力の競合や「どれが最新か分からない」状態が繰り返し起きているかどうかです。部門ごとにファイルを分けて対処しているケースも、ここに含まれます。

 

3つ目は権限です。「営業は自担当の案件だけ編集させたい」「経理は金額の列だけ見せたくない」といった、行や列の単位で権限を分けたいという要望が、実際の業務で出ているかどうかです。

 

4つ目はデータ整合性です。表記ゆれや入力規則の破損、数式・参照のずれが月次で発生し、その修正作業に毎回時間を取られているかどうかです。原因が分からないまま同じ修正を繰り返している状態も含まれます。

 

この4点のうち複数に当てはまる場合、データベース化を検討する段階に来ています。逆に、当てはまる項目が少ないうちにデータベース化を急ぐと、現場が使いこなせないまま定着せず、移行にかけた時間とコストが無駄になりかねません。

 

大切なのは、件数という1つの指標だけで判断しないことです。件数が少なくても、共有や権限の要望が強い業務であれば、データベース化の優先度は上がります。まずは自社がどの項目に当てはまるかを、次の章から順に具体的に確認していきましょう。

Google公式ヘルプでは、Googleスプレッドシートの上限を「1ファイルあたり合計1,000万セル、または18,278列」と案内しています（出典 Google公式ヘルプ「Google ドライブに保管可能なファイル」）。

 

行数そのものに一律の上限があるわけではなく、行数と列数を掛け合わせたセル数で考える必要があります。例えば20列の業務台帳であれば、単純計算で50万行まで保存できます。一方、100列の台帳では10万行で上限に達します。列が多い業務台帳ほど、保存できる行数は少なくなるという計算です。

 

ただし、上限は保存容量だけの問題ではありません。VLOOKUPやQUERY、IMPORTRANGEといった関数を大量に使ったり、ピボットテーブルや条件付き書式を広い範囲に設定したりすると、データ量が同じでも操作は重くなります。

 

IMPORTRANGE（別のスプレッドシートの特定の範囲を、自分のシートに呼び出して表示する関数）を使えば、ファイルを分割して容量超過を避けることもできます。しかし、ファイルが増えるほど構造は複雑になり、参照元の変更や権限の変更によって、別ファイルの集計が正常に動かなくなるリスクが生まれます。容量を超えないための分割が、新たな運用負荷を生んでしまうのです。

 

「まだ上限内なのに重い」と感じる場合、原因はセル数だけではありません。不要な空行・空列が大量に残っている、全列を対象にした配列関数を使っている、複数ファイルをIMPORTRANGEで連鎖させている、といった要因が重なっていることがあります。パソコンやブラウザの性能も、体感速度に影響します。

 

つまり、1,000万セル未満だから問題ないと判断するのではなく、データ量・計算量・参照関係・利用環境をまとめて確認する必要があります。

 

自社の台帳が重くなっている原因を切り分けるには、まず次の3点を確認します。

 

1. セル数が上限のどの程度に達しているか
2. 関数や条件付き書式が広い範囲に設定されていないか
3. IMPORTRANGEで参照しているファイルがいくつあるか

 

この3点を確認するだけで、件数を減らすべきなのか、関数の設定を見直すべきなのか、切り分けられます。

 

ファイル分割による回避策は、短期的には有効です。しかし、部門ごと・年度ごとにファイルが増えていくと、「どのファイルの数字が最新か」を突き合わせる作業自体が新たな業務になってしまいます。分割を選ぶ前に、なぜ重くなっているのかを先に特定しておくことが、後戻りを防ぐ近道です。自社の台帳がどの要因で重くなっているのかを、次の章以降で個別に見ていきましょう。

Google公式ヘルプでは、「最大100人のユーザーに対し、ファイルの閲覧、編集、コメント追加を同時に行えるよう権限を付与できます」と案内されています。100人を超えるアクセスがあった場合、ファイルを編集できるのはオーナーと一部の編集権限者のみに制限されます（出典 Google公式ヘルプ「スプレッドシートを特定のユーザーと共有する」）。

 

ただし、100人という数字は、快適に業務運用できる人数ではありません。営業、物流、経理など複数部門の担当者が同じ台帳を同時に更新する場合、誰がどの項目をいつ変更したのかを、利用者が増えるほど把握しにくくなります。

 

部門ごとにファイルを分ければ、同時編集の集中は避けられます。しかし、部門別ファイルが増えると、IMPORTRANGEや手動コピーによるデータ連携が必要になり、結果として「正本」が複数存在することになります。

 

当社がSlopebaseの導入の際に実施しているPoC（本格導入を決める前に、実際の業務データを使って作れるかどうかを試す取り組み）のヒアリングでは、従業員約220名の学習塾運営企業からある声が上がりました。「各拠点から生徒の情報などExcelが届き、本部で再度Excelに二重入力する手間がめんどう」という声です。同社は拠点ごとのファイルをマクロで集計していますが、年度替わりに様式が変わったり、ファイルが破損したりする恐れがあると回答しています。

 

従業員約150名のソフトウェア開発企業（金融系）からは「支店ごとにExcelブックが分かれている。ファイルが壊れるリスク」という声も確認しました。対象はExcelでの運用ですが、複数のファイルに分かれて正本が定まらなくなるという構造は、Googleスプレッドシートでも同様に起こり得ます。

 

Googleスプレッドシートには、共同編集者全員の画面に影響する通常のフィルタと、自分の画面だけに反映される「フィルタ表示」の2種類があります。この使い分けが定着していないと、誰かがフィルタを変更した際に、他の担当者の画面まで意図せず変わってしまいます。

 

共有リンクを使った運用では、退職者のアカウントに編集権限が残っている、外部ドメインのユーザーに共有してしまう、閲覧者がコピーやダウンロードでデータを持ち出す、といったリスクもあります。部門や担当者ごとに異なるデータだけを扱わせたい場合、ファイル単位の共有管理では設計が複雑になりやすくなります。

 

部門ごとに散らばった正本を一本化し、共有や権限の悩みを解消したいと感じたら、まずは判断材料を集めてみませんか。Slopebaseで何ができるかは、資料請求ページからご確認いただけます。

Googleスプレッドシートを業務台帳として使う場合、入力の自由度の高さが、そのままデータ崩れの原因になることがあります。代表的な事象を、具体的な操作の場面で確認します。

 

1つ目は、関数が入っているセルが分かりにくいことです。通常表示では計算結果の値しか見えないため、数式が入っているセルだと気づかず、手入力で上書きしてしまいます。上書きされた行は、次に集計を回すまで誰も異常に気づけません。

 

2つ目は、表記ゆれです。入力規則を設定していても、外部からの貼り付けや自由入力によって「株式会社」と「（株）」が混在してしまいます。表記ゆれがあると、同じ取引先のデータが別の行として集計され、件数や金額が正しく合計されません。

 

3つ目は、コピー&ペーストによる書式崩れです。結合セル、列幅、条件付き書式、罫線が、他のセルの貼り付けによって意図せず上書きされます。

 

4つ目は、プルダウンや入力規則の破損です。値の貼り付けや行の追加・削除、範囲指定の変更によって、入力規則が外れたり、参照範囲からデータが外れたりします。

 

5つ目は、行の挿入・削除による数式・参照のずれです。VLOOKUPやSUMIFの参照範囲、ARRAYFORMULAが行操作によって狂い、集計結果が誤ったまま放置されるケースがあります。行を1行追加しただけで在庫数の集計範囲がずれ、誤った数量のまま担当者が発注してしまうという事故も起こり得ます。

 

これらは、担当者の注意不足ではありません。複数人が同時に自由な形式で書き込めるという、Googleスプレッドシートの構造そのものに起因する問題です。

 

独立行政法人情報処理推進機構（IPA）は「AIのためのデータ環境整備」で、質の高いデータを、正確かつ最新で、抜け漏れやバイアスのない状態と説明しています（出典：独立行政法人情報処理推進機構（IPA）「AIのためのデータ環境整備」2023年12月20日公表）。

 

表記ゆれや入力規則の破損が積み重なった台帳は、この状態から少しずつ離れていきます。Googleスプレッドシートには、変更履歴やセルごとの編集履歴機能が備わっているため、操作の記録自体は一定程度残ります。しかし、数万行に及ぶシートで「いつ」「誰が」「どのレコードの」「どの項目を」変更したのかを個別に調査するのは、実務上かなりの手間です。レコード単位で監査ログを残せるデータベースと比べると、日常的な変更追跡の負荷は大きくなります。

 

事象の種類	月次発生件数
関数が入っているセルの手入力による上書き
自由入力やコピペによる表記ゆれ
コピー＆ペーストによる書式崩れ
プルダウンや入力規則の破損
行の挿入・削除による数式・参照のずれ

※グラフ作成用のデータプレースホルダーです。

Googleスプレッドシートの権限は、ファイルまたはシートの単位で設定します。行単位・列単位・レコード単位での制御は、標準機能ではできません。「営業は自担当の案件のみ編集可」「経理は金額列のみ閲覧可」といった業務要件には対応できないのです。

 

必須項目・重複禁止・選択肢固定といったデータ入力ルールも、スプレッドシートだけで徹底することは簡単ではありません。保護範囲の設定や入力規則、警告ルールはありますが、台帳の規模が大きくなるほど、設計と保守が特定の担当者に依存しやすくなります。

 

当社が実施した自社アンケート（情報システム部門の管理職221人が回答）では、データ活用が進まない理由として「データ品質が低い」が44.3%、「データが分散・サイロ化している」が28.5%を占めました（出典 「レガシーシステムが存在する企業は91.9%！～情シス部門の管理職221人に"現場が直面するDX推進の障壁と課題"についてアンケート調査を実施～」）。

 

■全社的なデータ活用を阻害している最も大きな要因は何だと思いますか？

 

理由の項目	回答比率
データ品質が低い	44.30%
データが分散・サイロ化している	28.50%

 

この調査はDX推進全般への回答ですが、権限や入力ルールが徹底できないまま台帳が広がると、同じ構図が個別の業務でも起きやすくなると考えられます。

 

こうした権限の粗さを放置すると、本来は経理担当者しか見るべきでない取引金額を、営業担当者や外部の委託先が閲覧できる状態のまま台帳を共有してしまう場面が生まれます。データが部門をまたいで分散し、どこに何があるか分からなくなる状態については、「サイロ化とは？組織で起こる原因と弊害・解消するデータ統合アプローチ」で仕組みごと詳しく解説しています。

 

スプレッドシートとデータベースは、そもそも向いている用途が異なります。スプレッドシートが得意とするのは、表計算や簡単な集計、グラフ作成、自由な分析です。一方、複数ユーザーによる同時アクセス、権限モデルの適用、入力検証、データの一元管理に向いているのはデータベースです。

 

どちらが優れているかという二択で考えるのではなく、役割を分けることが実務では有効です。正本となる業務データはデータベースで管理し、分析や一時的な加工にはスプレッドシートを使うという分担です。

 

当社が提供するSlopebaseは、ノーコード（プログラムのコードを書かずに、画面上の設定だけで業務アプリケーションを作れる仕組み）のクラウドサービスです。社内に分散する業務データや業務フローを、クラウド上で統合・可視化する目的で使われています。対象となるのは予算、販売、購買、経費、顧客、在庫などの業務データです。既存システムを入れ替えずに、段階的な導入を進められます。

次の項目に複数当てはまる場合は、Googleスプレッドシートからデータベースへの移行を検討するタイミングです。件数・共有・権限・データ整合性の4点を軸にしつつ、他システムとの連携要否も判断材料に加えています。

 

1. 行数・列数を掛け合わせたセル数が数万行相当を超え、開く・集計する・フィルタをかける操作に待ち時間が発生している
2. 目安として5〜10人以上が頻繁に同時編集し、入力の競合や「どれが最新か分からない」状態が定期的に発生している
3. 部門や拠点をまたいでデータを利用しており、正本が定まっていない
4. 表記ゆれ、入力規則の破損、数式・参照のずれが月次で発生している
5. 行・列単位の権限管理が必要になっている
6. 必須入力や重複禁止などの入力ルールを強制したい
7. レコード単位の変更履歴を確認する必要がある
8. ERP（企業の会計・購買・在庫などの基幹業務を一元管理するシステム）や会計、在庫などの他システムとの連携が必要になっている

 

重要なのは、件数だけで判断しないことです。例えば5,000行程度でも、複数部門が毎日更新し、他システムとの連携が必要であれば、データベース化の優先度は高くなります。

逆に、小規模な台帳、単一部門での利用、更新頻度が低い用途であれば、スプレッドシートによる運用を継続することが合理的です。短期間だけ使う管理表や、自由に加工しながら検討する段階のデータでは、スプレッドシートの柔軟性がそのまま強みになります。

大切なのは、Googleスプレッドシートを使っていること自体ではありません。業務の規模と管理要件に、いま使っているツールが合っているかどうかを、定期的に確認することです。

データベース化を進める際は、既存業務を止めない段階的な移行が重要です。次の6ステップで進めます。

 

ステップ1
現状の棚卸しです。社内に点在するスプレッドシートのうち、どれが正本かを明確にします。データ件数、編集者の人数、更新頻度、他ファイルとの参照関係を整理します。

 

ステップ2
データ構造・ルールの設計です。移行する項目、必須入力項目、文字種のルール、権限設定モデルを決め、正本としてのデータ定義を確定させます。

 

ステップ3
データの整理・クレンジング（表記ゆれや重複、入力漏れを一つずつ確認し、正しい状態に整える作業）です。既存シート内の表記ゆれやデータの欠損、二重登録を修正し、CSV形式などでエクスポートします。

 

ステップ4
パイロット運用です。業務への影響度が高い台帳を1つ選び、優先的に移行します。現場の入力担当者が使いやすいよう、表形式の一覧ビュー画面を提供できる基盤を選ぶことがポイントです。

 

ステップ5
権限設定と定着化です。役割に応じたアクセス権限を適用し、修正履歴の確認フローと締め処理ルールの運用を始めます。

 

ステップ6
分析環境との連携運用です。データベースを正本としながら、必要に応じてCSVで出力し、BIツールや分析用スプレッドシートと連携させる運用を整えます。

 

データを一元管理する意義そのものは、「データ一元管理を始めるべき理由｜中小企業経営者が押さえるべきメリットと導入ガイド」でも詳しく解説しています。

 

移行で最も問題になりやすいのは、操作方法が変わることへの現場の抵抗です。対策として、入力画面をこれまでのスプレッドシートに近づける方法があります。Slopebaseの「ビュー機能」のように、表形式の一覧画面を用意できる基盤を選ぶことがポイントです。

 

項目名や並び順をできるだけ踏襲すれば、覚え直す量を減らせるはずです。また、1〜2か月ほど旧スプレッドシートと新しい基盤を並行稼働させ、入力内容を比較する期間を設けると、移行後のトラブルに気づきやすくなります。

 

移行の目的をスプレッドシートの廃止と定義するのではなく、「正しいデータを、必要な人が、必要な範囲で使える状態にすること」と定義すると、現場との合意形成も進めやすくなります。

自社PoC（導入前検証）の実例で、従業員約100名の建設業（リフォーム）企業の事例を紹介します。同社には情報システム部門がなく、業務部門の数名がExcelで売掛管理と工事進捗管理を担っていました。

 

現場の担当者は、関数を多数埋め込んだExcelを使いこなすスキルを持っていました。しかし「Excelがマクロ使いすぎて重くなっており、脱エクセルを検討開始」というのが、同社が最初に直面した状況です。ファイル内での手作業の操作と、ファイルそのものの重さが、日々の業務の中で負担になっていました。

 

同社は当初、比較できる他のサービスが見当たらないという課題も抱えていました。レコードに直接入力できる形の業務基盤自体が、市場に少なかったためです。

 

この状況を受けて、同社は当社のPoCに参加しました。現状のExcel処理をそのまま移行できるか、ノーコードでの操作感が現場に合うかを検証する予定です。効果の測定はこれからですが、「重くなったExcelをどう扱うか」という同じ悩みを抱える企業にとって、何を基準に検証しようとしているかという視点そのものが参考になります。

 

同じ悩みは、業種が異なる企業でも共通しています。従業員約150名のソフトウェア開発企業（金融系）では、支店ごとに分かれたExcelブックが壊れるリスクを抱えていました。それでも「営業担当が使ってくれるか？総務部が使い切れるか？」という定着への不安から、移行には踏み切れずにいたのです。ツールを選ぶ前に、現場が実際に使い続けられるかどうかを見極めようとする姿勢が、この2社に共通しています。

 

属人化のリスクは、この2社に限った話ではありません。当社が実施した自社アンケートでは、営業事務経験者221人のうち64.2%が、前任者が残したマクロや関数の解読に苦労したと回答しています（出典 ：「【2026年調査】営業事務のExcel属人化の実態｜221人中64.2%が「前任者の謎マクロ・関数」に苦労」）。

 

関数に詳しい担当者が異動・退職すれば、同じ苦労が別の現場でも再現される可能性があります。
数万行に満たない台帳であっても、関数の複雑さと属人化が進めば、データベース化を検討する優先度は上がります。件数だけでなく、誰が触れるか、誰が直せるかという視点も判断材料に加えてください。

Q.Googleスプレッドシートの行数・件数の上限はいくつですか。

A.1ファイルあたり合計1,000万セル、または18,278列が上限です。列数が多い台帳ほど、保存できる行数は少なくなります。

 

Q.何人まで同時編集できますか。遅くなる目安はありますか。

A.最大100人まで同時に閲覧・編集・コメントできます。ただし速度は人数だけでなく、関数の量や参照するファイルの数にも左右されるため、5〜10人程度から実際の操作感を確認することをおすすめします。

 

Q.行単位・列単位の権限管理はできますか。

A.標準機能ではできません。権限設定は、ファイル単位またはシート単位が基本です。

 

Q.データベース化した後も、Googleスプレッドシートは使えますか。

A.使えます。正本データはデータベース側で管理し、分析や集計の用途としてスプレッドシートを連携させる運用が一般的です。

 

Q.上司や監査から「なぜ今までの運用ではだめなのか」と聞かれたら、何を根拠に説明すればよいですか。

A.件数・共有・権限・データ整合性の4点のうち、自社が当てはまる項目を、月次で発生している表記ゆれの件数のように具体的な事象とともに示すと、感覚的な説明にならずに伝わりやすくなります。

 

Q.データベース化には、どのくらいの期間がかかりますか。

A.対象業務の複雑さや、既存データの整理にかかる時間によって大きく異なります。棚卸しとデータ構造の設計に時間をかけるほど、パイロット運用以降は手戻りが少なく進みやすくなります。

Googleスプレッドシートは、少人数での台帳運用や自由な分析には便利ですが、件数の増加、複数人での共同編集、共有範囲の拡大によって運用上の限界が見えやすくなります。表記ゆれや入力規則の破損、数式のずれといったデータ崩れも、編集者が増えるほど再発しやすくなります。

 

件数・共有・権限・データ整合性の4点のうち複数に当てはまったら、データベース化を検討する段階です。移行では、正本をデータベース側に一本化し、一覧ビューや分析用スプレッドシートを併用する段階的な進め方が現実的です。現場の使い勝手を保ちながら、安定したデータ管理の基盤づくりを進めていきましょう。

 

段階的な移行から検討したい方に向けた内容です。正本の一本化や権限設定、一覧ビューといった仕組みについて、Slopebaseで何ができるかは資料請求ページからご確認いただけます。