「保護されたセルを編集しようとしたら、エラーが出て何もできない……」「ゴミ箱アイコンがグレーアウトしていて、保護を消すことすらできない……」そんな経験、ありませんか？Googleスプレッドシートの保護機能は、チームの共同編集において非常に頼もしい存在です。しかし、いざ自分が編集したいときに壁となって立ちはだかると、途端にストレスの原因に変わります。
特に厄介なのが、Google Workspaceの組織管理者によって制限がかけられているケースです。個人アカウントで使っているときには起きなかった問題が、会社や学校のアカウントに切り替えた途端に発生する。この「組織制限」という見えない壁に、多くの方が戸惑っています。
この記事では、GoogleSheetsの保護範囲が解除できない原因を徹底的に掘り下げ、組織制限が絡む場面での具体的な解決策から、Google Apps Scriptを活用した上級テクニックまで、初心者にもわかりやすく解説します。読み終わるころには、保護に関するモヤモヤがスッキリ晴れているはずです。
- GoogleSheetsの保護範囲を解除できない5つの原因と、組織制限が関係するパターンの見分け方
- 管理者権限がなくても実践できる7つの具体的な対処法とワークアラウンド
- GASによる保護の自動管理や、2026年最新のWorkspaceセキュリティ設定を踏まえた運用ベストプラクティス
- そもそもGoogleSheetsの保護機能とは何か？
- 保護範囲が解除できない5つの原因を徹底解明
- 組織制限で保護が解除できないときの7つの突破法
- 2026年最新のWorkspaceセキュリティを踏まえた保護運用術
- 保護トラブルを未然に防ぐための運用ベストプラクティス
- GASを使った高度な保護の自動化テクニック
- 情シス歴10年以上のプロが教える「現場で本当に起きる」保護トラブルと泥臭い解決法
- 現場で重宝する実戦GASコード集
- Workspace管理者向けAdmin Consoleでの保護関連トラブル対応フロー
- 意外と知らない「保護の仕様の落とし穴」
- 大規模組織での保護戦略設計情シスが本当に考えるべきこと
- ぶっちゃけこうした方がいい！
- GoogleSheetsの保護範囲と組織制限に関する疑問解決
- 今すぐパソコンやスマホの悩みを解決したい！どうしたらいい？
- まとめ
そもそもGoogleSheetsの保護機能とは何か？
Googleスプレッドシートのイメージ
まず基本から整理しましょう。Googleスプレッドシートの保護機能は、指定したシートやセル範囲の編集を制限するための仕組みです。よく誤解されますが、これはセキュリティ対策そのものではありません。保護されたスプレッドシートであっても、閲覧権限があればコピーやエクスポートは可能です。あくまで「うっかり上書きを防ぐ」ための機能だと考えてください。
保護の設定には大きく分けて2つのタイプがあります。ひとつはシート全体の保護で、タブ単位でまるごと編集をロックする方法です。シートタブの横に南京錠のアイコンが表示されるので、見た目でもすぐにわかります。もうひとつが特定範囲のセル保護で、シート内の一部のセルだけを選んでロックする方法です。たとえば売上管理表で、計算式が入ったセルだけを保護し、データ入力セルは自由に編集できるようにする、といった柔軟な使い方ができます。
保護の権限レベルを理解しよう
保護を設定する際には、権限レベルを選ぶ必要があります。ここを正しく理解しておかないと、「なぜ解除できないのか」の原因も見えてきません。
| 権限レベル | 内容 | 解除可能なユーザー |
|---|---|---|
| 自分のみ | オーナーと設定者だけが編集可能 | オーナーまたは設定者本人 |
| カスタム | 指定したユーザーやグループのみ編集可能 | オーナーまたは編集権限を持つ指定ユーザー |
| ドメインのみ | 同じ組織ドメイン内のユーザー全員が編集可能 | ドメイン内の編集権限者 |
| 警告を表示 | 編集は可能だが確認メッセージが出る | 誰でも（確認後に編集可） |
ここで注目してほしいのが「ドメインのみ」という選択肢です。これはGoogle Workspaceの組織アカウントでのみ表示されるオプションで、個人のGoogleアカウントでは出てきません。この「ドメインのみ」設定が絡むと、組織外のユーザーはどうやっても保護範囲を編集できなくなります。
保護範囲が解除できない5つの原因を徹底解明
「保護を解除したいのにできない」という状況には、実はいくつかの異なるパターンがあります。原因を正しく特定しないと、いくら操作を繰り返しても解決しません。ここでは代表的な5つの原因を、頻度の高い順に紹介します。
原因1編集権限そのものが不足している
最も多いパターンがこれです。スプレッドシートに対して「閲覧者」や「コメント可」の権限しか持っていない場合、保護の設定や解除はいっさい行えません。そもそもメニューの
データ
→
シートと範囲を保護
を開いても、ゴミ箱アイコンが表示されなかったり、グレーアウトしている状態になります。この場合はスプレッドシートのオーナーに編集権限の付与を依頼するのが唯一の方法です。
原因2保護を設定したユーザーが別にいる
自分がスプレッドシートの編集者であっても、保護を設定した本人またはオーナーでなければ、その保護を解除することはできません。これはGoogleSheetsの仕様です。たとえばAさんが範囲保護を設定した場合、同じ編集者であるBさんはその保護を削除できません。Bさんが保護を解除したいなら、Aさんかオーナーに依頼する必要があります。
原因3組織のWorkspace管理者による共有制限
ここが本記事の核心部分です。Google Workspaceを利用している企業や学校では、管理者がAdmin Consoleから共有やアクセスに関するポリシーを設定しています。たとえば「組織外のユーザーとのファイル共有を禁止する」「ホワイトリストに登録されたドメインとのみ共有を許可する」といったルールが敷かれていると、保護の権限操作にも影響が及ぶことがあります。
具体的には、組織のドメインポリシーで外部共有がオフになっている場合、外部ユーザーを保護範囲の編集者として追加できません。また、管理者がDLP（データ損失防止）ルールを設定していると、特定のスプレッドシートに対するアクセスや操作がさらに制限される場合があります。2026年3月時点では、Google WorkspaceのDLPルールはGoogle Drive、Gmail、Google Chatなど複数のサービスに横断的に適用でき、組織単位やグループ単位での細かな制御が可能になっています。
原因4ファイルがExcel形式のまま開かれている
意外と見落とされがちなのが、ファイル形式の問題です。
.xlsx
や
.xls
形式のファイルをGoogleスプレッドシートで直接開いている場合、「シートと範囲を保護」のメニュー自体が表示されないことがあります。この場合は、
ファイル
→
Googleスプレッドシートとして保存
を選んで、スプレッドシート形式に変換してから操作してください。
原因5ブラウザやキャッシュの問題
保護設定が正しいはずなのに挙動がおかしい場合、ブラウザ側の問題である可能性があります。特に長時間スプレッドシートを開いたまま放置していたり、複数のGoogleアカウントを同時にログインしている環境では、キャッシュの不整合が起きやすくなります。ブラウザのキャッシュをクリアする、シークレットモードで開き直す、別のブラウザで試す、といった対処が有効です。
組織制限で保護が解除できないときの7つの突破法
原因がわかったところで、実際にどう対処すればよいのかを具体的に見ていきましょう。特に組織制限が絡むケースを中心に、すぐに試せる方法から管理者レベルの対応まで幅広くカバーします。
突破法1オーナーまたは保護設定者に直接依頼する
最もシンプルで確実な方法です。保護範囲を解除できるのは、原則としてスプレッドシートのオーナーか、保護を設定したユーザーだけです。相手に依頼する際は、「Q4レポートのタブにあるF5:F25の保護を解除してほしい」というように、シート名とセル範囲を具体的に伝えると、相手も対応しやすくなります。Googleスプレッドシート上で
@メンション
を使ってコメントを残すか、SlackやメールなどでURLとセル番地を共有するのがスムーズです。
突破法2ファイルのコピーを作成して自分がオーナーになる
オーナーが退職済みで連絡が取れない、あるいは急ぎで作業が必要で依頼を待てない場合に使えるワークアラウンドです。
ファイル
→
コピーを作成
を選ぶと、コピーされた新しいスプレッドシートではあなた自身がオーナーになります。そして元のファイルに設定されていた保護はすべて自動的に解除されます。ただし、コピーはあくまで別ファイルなので、元のファイルに対する変更は反映されない点にご注意ください。
突破法3Workspace管理者にポリシー変更を相談する
組織のドメインポリシーが原因で操作が制限されている場合、一般ユーザーには対処のしようがありません。この場合は、IT部門やWorkspace管理者に連絡して、以下のような確認をお願いしましょう。
まず、Admin Consoleの
アプリ
→
Google Workspace
→
ドライブとドキュメント
にある共有設定が、どのレベルに設定されているかを確認してもらいます。「外部共有オフ」になっている場合、外部ドメインのユーザーに対して保護範囲の編集権限を付与することができません。また、組織単位（OU）ごとに異なる共有ポリシーが設定されていることもあるため、自分が所属するOUの設定を個別に確認してもらうことが重要です。
さらに、DLPルールが適用されている場合は、特定のファイルに対するアクセスや編集操作がブロックされることがあります。管理者にAuditログを確認してもらうと、どのルールによってブロックされたかが判明する場合があります。
突破法4Googleグループを活用した権限管理に切り替える
組織で多くのメンバーがスプレッドシートを共同編集する場合、個別のメールアドレスではなくGoogleグループを使って権限を管理する方法がおすすめです。たとえば「sales-team@company.com」というグループを作成し、そのグループに保護範囲の編集権限を付与すれば、メンバーの入れ替わりがあってもグループへの追加・削除だけで対応できます。保護のたびに個別ユーザーを指定する手間が省け、管理コストが大幅に下がります。
突破法5Google Apps Scriptで保護を一括管理する
保護の設定や解除を頻繁に行う業務フローでは、手動操作は非効率です。Google Apps Script（GAS）を使えば、スクリプトから保護を自動的に操作できます。以下は、アクティブなシート上のすべての保護を一括で解除するスクリプトの例です。
function removeAllProtections() {
var sheet = SpreadsheetApp.getActiveSheet();
var protections = sheet.getProtections(SpreadsheetApp.ProtectionType.RANGE);
for (var i = 0; i < protections.length; i++) {
if (protections.canEdit()) {
protections.remove();
}
}
}
このスクリプトは、
拡張機能
→
Apps Script
からエディタを開き、コードを貼り付けて実行するだけで動作します。ただし非常に重要な点として、このスクリプトは自分に編集権限がある保護しか解除できません。他のユーザーが設定した保護や、組織ポリシーによる制限を回避することはできない仕組みです。セキュリティを突破するものではなく、あくまで自分が持っている権限の範囲内で作業を効率化するツールだと理解してください。
突破法6保護の「警告表示」モードを活用する
保護には「編集を完全にブロックする」モードのほかに、「編集時に警告を表示する」という緩やかなモードがあります。テンプレートのように「触ってほしくないけど、どうしても必要なら編集していい」という場面では、この警告モードが適しています。警告モードの場合、編集しようとすると確認ダイアログが表示されますが、「OK」を押せばそのまま編集が可能です。このモードであれば、ブロックされて困るという事態は発生しません。
突破法7モバイルの制限を理解してPC環境で操作する
Googleスプレッドシートのモバイルアプリ（iOS・Android）では、保護の新規設定や解除ができません。保護されたセルを編集しようとすると「この範囲は保護されています」というメッセージが表示されるだけです。保護に関する操作は必ずPC版のブラウザから行ってください。どうしてもスマートフォンで対応が必要な場合は、Chromeブラウザの「PCサイト表示」モードで操作する方法もありますが、画面が小さいため操作ミスのリスクが高く、あまりおすすめはできません。
2026年最新のWorkspaceセキュリティを踏まえた保護運用術
2026年に入り、Google Workspaceのセキュリティ機能はさらに進化しています。保護機能を適切に運用するためには、最新の仕組みを理解しておくことが欠かせません。
コンテキストアウェアアクセスと保護の関係
Google Workspaceの管理者は、コンテキストアウェアアクセスを使って、ユーザーのIDやデバイスのセキュリティ状態、接続元の場所に基づいてアクセス条件を設定できます。たとえば「社外ネットワークからのアクセス時はGoogleドライブを読み取り専用にする」といったルールが設定されている場合、スプレッドシートの保護解除操作もブロックされる可能性があります。自宅やカフェからの作業で突然保護が解除できなくなった場合、このポリシーが原因かもしれません。
DLPルールによるファイル操作の制限
2026年3月の最新状況として、Google WorkspaceのDLP（データ損失防止）機能は、Google Drive、Gmail、Google Chatに加え、Googleカレンダーやchromeにも対応が拡大しています。管理者はDLPルールを使って、機密性の高いデータを含むスプレッドシートに対する共有、ダウンロード、コピーなどの操作を自動的にブロックできます。保護の解除そのものがDLPで直接ブロックされるわけではありませんが、ファイル全体のアクセスが制限されている場合は間接的に影響を受けます。
クライアントサイド暗号化（CSE）環境での注意点
Google Workspaceの上位エディションでは、クライアントサイド暗号化（CSE）を利用して、Googleのサーバー側でもデータの内容にアクセスできない状態にすることが可能です。CSEが適用されたスプレッドシートでは、Gemini（AI機能）がデータにアクセスできないなど、通常とは異なる制約があります。保護機能そのものへの直接的な影響は限定的ですが、CSE環境では権限管理がより厳格になっているため、保護の解除にも通常以上に注意が必要です。
保護トラブルを未然に防ぐための運用ベストプラクティス
保護が解除できなくて困る事態を避けるためには、そもそもの運用ルールを整えておくことが大切です。ここでは、実務で効果の高い運用のコツを紹介します。
保護設定時の「説明」欄を必ず記入する
保護を設定するとき、多くの人が「説明を入力」の欄を空欄のまま完了してしまいます。しかし、この欄に「マスターデータ保護変更はyamada@company.comに連絡」のように保護の理由と連絡先を書いておくだけで、後からのトラブル対応が格段にスムーズになります。特に複数の保護設定が混在するスプレッドシートでは、どの保護が何のためのものなのかを一覧で把握できるようにしておくことが不可欠です。
必要最小限の範囲だけを保護する
列全体（A:Aなど）をまるごと保護してしまうと、新しい行の追加や空白セルの利用までブロックされてしまいます。保護はあくまで本当に守りたいセルだけに限定し、たとえば「A1:A100の計算式セルのみ保護」というように、範囲を絞り込むことを心がけましょう。
バージョン履歴と保護機能を組み合わせる
保護機能だけに頼らず、バージョン履歴と組み合わせて運用すると、より安全です。Googleスプレッドシートは自動的に変更履歴を保存しているため、万が一データが書き換えられてしまっても、
ファイル
→
変更履歴
→
変更履歴を表示
から過去の状態に復元できます。保護を解除する前に変更履歴のスナップショットを確認しておけば、何か問題が起きてもすぐにリカバリーが可能です。
定期的なアクセス権限の棚卸しを行う
人事異動や退職によって、本来アクセス権限を持つべきでないユーザーが編集者のまま残っているケースは珍しくありません。四半期に一度程度の頻度で、スプレッドシートの共有設定と保護設定を見直し、不要な権限を削除するようにしましょう。退職者のアカウントがオーナーになっているスプレッドシートは、Workspace管理者にオーナー権限の移譲を依頼する必要があります。
GASを使った高度な保護の自動化テクニック
ここからは上級者向けの内容です。Google Apps Scriptを活用すれば、保護の設定・解除を自動化し、業務フローに組み込むことができます。
承認済みデータの自動保護
たとえば、ステータス列が「承認済」になった行を自動的に保護するスクリプトを組むことで、承認後のデータ改ざんを防げます。以下のようなコードを時間駆動トリガーで定期実行すれば、手動で保護を設定する手間がなくなります。
function protectApprovedRows() {
var sheet = SpreadsheetApp.getActiveSheet();
var data = sheet.getRange("A2:E100").getValues();
for (var i = 0; i < data.length; i++) {
if (data === "承認済") {
var row = sheet.getRange(i + 2, 1, 1, 5);
var protection = row.protect();
protection.setDescription("承認済データ - 自動保護");
protection.removeEditors(protection.getEditors());
if (protection.canDomainEdit()) {
protection.setDomainEdit(false);
}
}
}
}
このスクリプトでは、E列が「承認済」の行に対して保護を設定し、さらに
setDomainEdit(false)
でドメイン内の全員編集を無効にしています。これにより、承認者以外はデータを変更できなくなります。
月末に当月データを自動ロックする仕組み
月次の売上データや経費データを管理している場合、月が変わったタイミングで前月分のデータを自動的に保護するトリガーを設定できます。Apps Scriptの時間ベーストリガーを使い、毎月1日の深夜に前月分のデータ範囲を自動保護するスクリプトを組めば、人為的なミスを完全に排除できます。
情シス歴10年以上のプロが教える「現場で本当に起きる」保護トラブルと泥臭い解決法
Googleスプレッドシートのイメージ
ここからは、ネット上の記事ではまず出てこない「情シス（情報システム部門）の現場で実際に何度も遭遇してきた」リアルなトラブルと、その具体的な対処を共有します。正直なところ、保護機能のトラブルは公式ドキュメント通りにいかないケースが山ほどあります。教科書的な回答ではなく、「実際にどうしたか」を軸に話していきます。
退職者がオーナーのスプレッドシートが大量に残っている問題
これは本当に頻発します。退職者のGoogleアカウントが削除された後に、そのユーザーがオーナーだったスプレッドシートの保護が一切解除できなくなるパターンです。しかもやっかいなのが、アカウント削除後は「オーナー権限の移譲」という選択肢自体が消えることです。
この場合、Workspace管理者であればAdmin Consoleのデータ移行機能を使って解決できます。具体的な手順はこうです。Admin Consoleにログインし、
アカウント
→
データの移行
に進みます。移行元に退職者のアカウント（まだ削除していない場合）、移行先に後任者や管理用アカウントを指定します。これでドライブ内の全ファイルのオーナー権限が一括で移譲されます。
ただし、ここに大きな落とし穴があります。アカウントを完全に削除してしまった後では、データ移行機能は使えません。だからこそ、退職処理のフローにおいて「アカウント削除の前にドライブデータの移行を完了させる」というステップを必ず組み込んでおくべきです。10年やってきて断言しますが、これを忘れて後悔する企業は後を絶ちません。退職が決まった段階で、その人がオーナーになっているファイルをリストアップする仕組みを事前に作っておくことが最善策です。
もしすでにアカウントを削除してしまった場合は、残念ながらファイルのコピーを作成して保護を外すしか手段がありません。ただ、Workspace管理者がセキュリティ調査ツール（Security Investigation Tool）を使えば、過去180日以内にアクセスのあったファイルについてはオーナー移譲が可能な場合もあります。このツールはEnterprise以上のエディションでしか使えませんが、知っておくと救われる場面があります。
「共有ドライブに移動したら保護設定が全部飛んだ」事件
個人のマイドライブにあったスプレッドシートを共有ドライブに移動したとき、それまで設定していた保護が意図せず変わってしまうことがあります。共有ドライブではファイルのオーナーが「共有ドライブ」自体になるため、元の個人オーナーベースの保護ロジックが崩れるのです。
具体的には、「自分のみ編集可能」に設定していた保護が、共有ドライブの「オーガナイザー」全員に編集権限が付与された状態に変わることがあります。これは仕様であってバグではないのですが、知らないと「なぜ保護が効いていないのか」と混乱します。
対策としては、共有ドライブへの移動後に必ず
データ
→
シートと範囲を保護
を開いて、保護設定を一つずつ確認・再設定することをルーティンにしてください。この確認作業を怠ると、本来保護されるべきデータが丸見え・丸編集可能な状態で放置される危険があります。
複数アカウントログインの罠保護操作が別アカウントに紐付く問題
Chromeブラウザで個人アカウントと会社アカウントを同時にログインしている状態で保護を設定すると、意図しないアカウントで保護が作成されることがあります。たとえば会社のスプレッドシートなのに、個人アカウントで保護を設定してしまい、会社アカウントからは解除できない、という事態です。
URLの末尾にある
/u/0/
や
/u/1/
といった数字がアカウントの切り替えを表しています。
/u/0/
がデフォルトアカウント、
/u/1/
が2番目のアカウントです。保護の設定・解除を行う際は、ブラウザのアドレスバーでこの数字を確認するか、いっそのことシークレットウィンドウで対象のアカウントだけにログインして操作するのが最も確実です。情シスの現場では「保護操作はシークレットモードで」と指導しているケースもあります。
現場で重宝する実戦GASコード集
情シスの現場では、保護の管理を手作業で行い続けることに限界があります。ここでは、上の記事で紹介した基本的なGASに加えて、「これがないと仕事にならない」レベルで現場で使い倒しているスクリプトを複数紹介します。すべてコピペで動くように書いていますが、必ずテスト用のスプレッドシートで先に動作確認をしてから本番環境に適用してください。
全シートの保護状況を一覧レポートとして書き出すスクリプト
「このスプレッドシート、どこに何の保護がかかっているのか全体像がわからない」という問題は、保護が10個20個と積み重なったファイルで頻繁に発生します。以下のスクリプトを実行すると、新しいシートに全保護設定の一覧表を自動生成します。
function auditProtections() {
var ss = SpreadsheetApp.getActiveSpreadsheet();
var reportSheet = ss.getSheetByName("保護レポート");
if (!reportSheet) {
reportSheet = ss.insertSheet("保護レポート");
} else {
reportSheet.clear();
}
reportSheet.appendRow);
var sheets = ss.getSheets();
for (var s = 0; s < sheets.length; s++) {
var sheetName = sheets.getName();
if (sheetName === "保護レポート") continue;
var rangeProtections = sheets.getProtections(SpreadsheetApp.ProtectionType.RANGE);
for (var i = 0; i < rangeProtections.length; i++) {
var p = rangeProtections;
var editors = "";
try { editors = p.getEditors().map(function(u){return u.getEmail();}).join(", "); } catch(e) { editors = "権限なし"; }
reportSheet.appendRow);
}
var sheetProtections = sheets.getProtections(SpreadsheetApp.ProtectionType.SHEET);
for (var j = 0; j < sheetProtections.length; j++) {
var sp = sheetProtections;
var sEditors = "";
try { sEditors = sp.getEditors().map(function(u){return u.getEmail();}).join(", "); } catch(e) { sEditors = "権限なし"; }
reportSheet.appendRow);
}
}
}
このスクリプトのポイントは、
getEditors()
をtry-catchで囲んでいることです。自分に編集権限がない保護に対して
getEditors()
を呼ぶと例外がスローされるため、catchで「権限なし」と表示するようにしています。これにより、自分が解除できない保護も含めて全体像を把握できるのが強みです。四半期ごとの棚卸しや、引き継ぎ時のドキュメント作成に重宝します。
特定シートを保護しつつ入力セルだけ穴を開けるスクリプト
テンプレート型のシートを作るとき、「全体を保護してから、入力欄だけ除外する」パターンは非常に多いです。手動だと除外範囲の指定が面倒ですが、GASなら一発です。
function protectSheetWithHoles() {
var sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName("入力フォーム");
var protection = sheet.protect().setDescription("テンプレート保護入力セル以外はロック");
var inputRanges = [
sheet.getRange("B3:B10"),
sheet.getRange("D3:D10"),
sheet.getRange("B15:F20")
];
protection.setUnprotectedRanges(inputRanges);
var me = Session.getEffectiveUser();
protection.addEditor(me);
protection.removeEditors(protection.getEditors());
if (protection.canDomainEdit()) {
protection.setDomainEdit(false);
}
}
配列
inputRanges
に入力を許可したいセル範囲を列挙するだけで、それ以外の全セルが自動的に保護されます。テンプレートの構造変更があったときも、この配列を修正するだけなのでメンテナンスが楽です。
チェックボックスをONにしたら該当行を自動保護するスクリプト
承認フローで「承認者がチェックを入れたら、その行をロックする」という運用はとても実用的です。以下のスクリプトをonEditトリガーに設定すると、F列のチェックボックスがTRUEになった瞬間にその行全体が保護されます。
function onEdit(e) {
var sheet = e.source.getActiveSheet();
var range = e.range;
if (sheet.getName() !== "承認管理" || range.getColumn() !== 6) return;
if (range.getValue() === true) {
var row = range.getRow();
var lockRange = sheet.getRange(row, 1, 1, sheet.getLastColumn());
var protection = lockRange.protect();
protection.setDescription("承認済ロック - 行" + row);
protection.removeEditors(protection.getEditors());
if (protection.canDomainEdit()) {
protection.setDomainEdit(false);
}
}
}
注意点として、シンプルトリガーの
onEdit
では
removeEditors()
が権限不足で失敗する場合があります。その場合は、Apps Scriptのエディタから
トリガー
→
トリガーを追加
で「インストール可能なトリガー」として
onEdit
を設定し直してください。インストール可能なトリガーはスクリプト実行者の権限で動くため、保護の細かな操作が可能になります。この「シンプルトリガーとインストール可能なトリガーの違い」は、GASで保護を扱う際に最もハマりやすいポイントなので、ぜひ覚えておいてください。
保護範囲のバックアップと復元スクリプト
「保護設定を全部解除して一括編集したいけど、後で元に戻せるか不安」という声をよく聞きます。以下のスクリプトは、現在の保護設定をJSON形式でPropertiesServiceに保存し、後から復元できるようにします。
function backupProtections() {
var ss = SpreadsheetApp.getActiveSpreadsheet();
var allProtections = ;
var sheets = ss.getSheets();
for (var s = 0; s < sheets.length; s++) {
var protections = sheets.getProtections(SpreadsheetApp.ProtectionType.RANGE);
for (var i = 0; i < protections.length; i++) {
if (protections.canEdit()) {
allProtections.push({
sheet: sheets.getName(),
range: protections.getRange().getA1Notation(),
description: protections.getDescription(),
warning: protections.isWarningOnly()
});
}
}
}
PropertiesService.getScriptProperties().setProperty("protectionBackup", JSON.stringify(allProtections));
Logger.log("バックアップ完了: " + allProtections.length + "件の保護を保存しました");
}
function restoreProtections() {
var ss = SpreadsheetApp.getActiveSpreadsheet();
var backup = PropertiesService.getScriptProperties().getProperty("protectionBackup");
if (!backup) { Logger.log("バックアップが見つかりません"); return; }
var data = JSON.parse(backup);
for (var i = 0; i < data.length; i++) {
var sheet = ss.getSheetByName(data.sheet);
if (!sheet) continue;
var range = sheet.getRange(data.range);
var protection = range.protect().setDescription(data.description);
if (data.warning) {
protection.setWarningOnly(true);
}
}
Logger.log("復元完了: " + data.length + "件の保護を復元しました");
}
このスクリプトの制約として、保護の「編集可能ユーザー」情報はバックアップに含まれません。なぜなら
getEditors()
で取得したユーザーオブジェクトをJSONにシリアライズするのが困難だからです。復元後は手動でユーザー権限を再設定するか、あるいはバックアップスクリプト側でメールアドレスを文字列として保存するようにカスタマイズしてください。それでも「保護範囲と説明の復元だけでも自動化できる」のは実務では大きな時短です。
Workspace管理者向けAdmin Consoleでの保護関連トラブル対応フロー
ここからは、情シス部門の管理者や、管理者に相談する立場の人が知っておくべき具体的な対応手順です。「ユーザーからの問い合わせにどう回答するか」という視点で解説します。
「保護が解除できない」と問い合わせがきたときのチェックリスト
ユーザーから「保護を外したいのに外せない」と連絡が来た場合、管理者として確認すべきことは以下の順番です。まず、対象ファイルのURLをユーザーに聞きます。次にAdmin Consoleの
レポート
→
監査と調査
→
ドライブのログイベント
で、そのファイルに対する最近のアクティビティを確認します。ここで「誰が保護を設定したか」「ファイルのオーナーは誰か」が判明します。
オーナーがすでに退職済みの場合は、セキュリティ調査ツールを使ったオーナー移譲を検討します。Enterprise、Education Plus、またはCloud Identity Premiumのエディションであれば、ドライブのログイベントからファイルを特定し、アクション欄から「オーナーを変更」を実行できます。ファイルのURLを元にドキュメントIDを割り出し、検索条件に入力すればピンポイントで対象を見つけられます。
組織単位（OU）ごとの共有ポリシーが保護に与える影響
見落とされがちですが、Google Workspaceの共有設定は組織単位（OU）ごとに異なるポリシーを設定できます。たとえば「営業部のOUは外部共有OK、経理部のOUは内部のみ」のような設定が可能です。この場合、経理部のユーザーがスプレッドシートの保護で外部ユーザーを編集者に追加しようとしても、そもそもファイルを外部と共有できないため、保護の権限設定にも外部ユーザーを指定できません。
ユーザーが「カスタム権限でメールアドレスを入力しても追加できない」と報告してきた場合は、まずそのユーザーが所属するOUの共有ポリシーを確認してください。Admin Consoleの
アプリ
→
Google Workspace
→
ドライブとドキュメント
→
共有設定
で、OU別の設定を確認できます。
退職処理フローに組み込むべきドライブ関連の3ステップ
保護トラブルの根本原因を断つために、退職処理のフローに以下の工程を必ず入れてください。
- 退職者がオーナーのファイルをAdmin Consoleの
データの移行で後任者に一括移譲する。移譲はアカウント削除の最低1週間前に完了させることが望ましいです。なぜなら大量のファイルがある場合、移譲処理に数日かかるケースがあるからです。
- 退職者が共有ドライブのオーガナイザーになっている場合は、別のメンバーにオーガナイザー権限を付与し、退職者を外す。共有ドライブのオーガナイザーが不在になると、ドライブの設定変更やメンバー管理ができなくなります。
- 退職者がGASの保護スクリプトを組んでいた場合、そのスクリプトのトリガー設定を確認し、必要に応じて新しいユーザーで再設定する。GASのトリガーはスクリプト作成者の権限で動くため、アカウント削除後にトリガーが停止し、保護の自動設定が動かなくなることがあります。
意外と知らない「保護の仕様の落とし穴」
保護機能には、ドキュメントに明記されていない（あるいは明記が不十分な）挙動がいくつかあります。実際に遭遇して初めてわかるものばかりなので、ここで先に共有しておきます。
オーナーの編集は保護で止められない
これは仕様として明記されていますが、スプレッドシートのオーナーは、自分自身を保護の対象外にすることができません。つまり、自分がオーナーのファイルで「自分も含めて全員の編集を禁止する」ということは不可能です。自分の誤操作を防ぎたい場合は、「編集時に警告を表示する」モードを使うか、信頼できる別のメンバーにオーナー権限を移譲したうえで保護を設定してもらう方法しかありません。
IMPORTRANGE経由のデータは保護の影響を受けない
IMPORTRANGE
関数で別のスプレッドシートからデータを参照している場合、参照元の保護設定は参照先に影響しません。つまり、保護されたスプレッドシートのデータを
IMPORTRANGE
で別シートに引っ張ると、その別シートでは制限なくデータを閲覧・コピーできます。機密データを扱う場合、IMPORTRANGEの許可設定（参照元でアクセスを許可するかどうかのダイアログ）を慎重に管理する必要があります。
フィルタビュー使用中に保護の挙動が変わる場合がある
複数ユーザーがフィルタビューを使用している状態で保護を設定すると、保護範囲の表示がフィルタビューの状態に引っ張られて正しく反映されないことがあります。保護の設定・解除を行う際は、フィルタビューを一度解除してから操作することを習慣にしてください。これはGoogleの公式ドキュメントにはほぼ記載されていないのですが、実務では何度も遭遇するパターンです。
コピー先のファイルで保護が外れても書式設定は残る
ファイル
→
コピーを作成
で保護を回避したとき、保護設定自体は外れますが、セルの背景色やフォント設定など書式はそのまま引き継がれます。保護されていたセルに薄い縞模様の背景が表示されていた場合、それはGoogleSheetsが保護の視覚的インジケーターとして表示していたものであり、コピー後にも一部残存することがあります。見た目上は保護されているように見えて実は編集可能、という状況になるため、コピー後のファイルでは
表示
→
保護された範囲を表示
で保護状態を明示的に確認してください。
大規模組織での保護戦略設計情シスが本当に考えるべきこと
従業員数が100人を超えてくると、スプレッドシートの保護管理は個別対応では回らなくなります。ここでは、組織規模で保護を設計する際の考え方を共有します。
保護設計の「三層モデル」
私が長年の経験で行き着いた運用モデルが、「三層での保護設計」です。まず第一層としてファイルレベルの共有権限で大きくアクセスを制御します。閲覧だけでいいユーザーは「閲覧者」、データ入力が必要なユーザーは「編集者」にします。第二層としてシート保護で、マスターデータや計算式のシートを丸ごとロックします。そして第三層としてセル範囲保護で、入力用シート内の計算式セルやヘッダー行だけをピンポイントで守ります。
この三層を組み合わせることで、保護設定の数を最小限に抑えつつ、十分な安全性を確保できます。よくある失敗は、すべてをセル範囲保護でやろうとして設定が数十個に膨れ上がり、管理不能になるパターンです。レイヤーを分けて考えるだけで、保護管理の複雑さは劇的に下がります。
「保護設計書」をスプレッドシートに同梱する
重要なスプレッドシートには、「保護設計」という専用シートを一枚追加しておくことを強くおすすめします。そこに、どの範囲を誰がなぜ保護しているか、保護を解除する際の承認フロー、緊急時の連絡先を記載しておきます。これがあるだけで、引き継ぎや退職時のトラブルが大幅に減ります。先ほど紹介した
auditProtections
のGASスクリプトを定期実行して、このシートに自動反映させると、ドキュメントが常に最新状態になります。
ぶっちゃけこうした方がいい！
ここまで読んでくれた方に、10年以上情シスをやってきた人間としてぶっちゃけた本音を言います。
正直なところ、保護機能だけでデータを守ろうとするのは、そもそもの設計として無理があるんです。Googleスプレッドシートの保護は「編集のブロック」はできますが、コピー、エクスポート、画面キャプチャは止められません。公式ドキュメントにも「セキュリティ対策そのものではない」と明記されています。なのに、多くの企業が保護機能をセキュリティの要のように扱ってしまい、そこからトラブルが生まれています。
じゃあどうするのが一番いいか。ぶっちゃけ言うと、保護は「うっかり防止」程度の役割だと割り切って、本当に大事なデータは共有ドライブに入れて、ファイルレベルの権限で守るのが圧倒的に楽だし効率的です。共有ドライブならファイルのオーナーが個人に紐づかないから退職トラブルも起きないし、管理者がメンバーを一元管理できます。保護で細かくセルを守るよりも、そもそもアクセスできる人を絞る方がセキュリティとしてはよほど強固です。
そのうえで、入力テンプレートのように「編集はさせたいけど壊されたくない」シートだけにGASで保護を自動化する。これが最小工数で最大効果を出す組み合わせです。セル単位の保護を手動でチマチマ設定して、それが解除できなくなって困って、管理者に泣きつく――このサイクルを10年見てきて断言しますが、保護の設定数が10個を超えたスプレッドシートは、運用設計を根本から見直すべきサインです。
そしてもう一つ。退職処理の話を上でしましたが、これを「起きてから考える」企業があまりにも多い。退職者のドライブデータの移行は、内定辞退や突然の退職もあるわけで、今日この瞬間から「アカウント削除前のデータ移行チェックリスト」を作って運用を始めるべきです。保護の解除ができなくて困る問題の半分以上は、実は「退職処理のフローが甘かった」ことに起因しています。保護の解除方法を調べているあなたが今一番やるべきことは、目の前の保護を外すことじゃなくて、二度と同じ問題が起きない仕組みを作ることなのかもしれません。
技術的な対処法はこの記事に全部書きました。でも一番伝えたいのは、保護機能との付き合い方はシンプルに「守る範囲を絞る、権限設計はファイルレベルで考える、自動化できる部分はGASに任せる」。この3つを徹底するだけで、保護にまつわる問題の9割は消えます。難しいことは何もなくて、ただ正しい順番で考えるだけの話です。
このサイトをチップで応援
GoogleSheetsの保護範囲と組織制限に関する疑問解決
自分がオーナーなのに保護を解除できないのはなぜ？
スプレッドシートのオーナーであっても、別の編集者が設定した保護に対しては、その編集者の許可なしに解除できる仕様になっています。ただし、ごくまれにブラウザのキャッシュや複数アカウントのログイン状態が原因で、操作が正常に反映されないケースがあります。キャッシュをクリアしてから再度試すか、シークレットモードでログインし直してみてください。それでも解決しない場合は、一時的なサーバー側の問題の可能性もあるため、時間をおいて再試行することをおすすめします。
組織のWorkspace管理者に何を依頼すればスムーズに解決する？
管理者に連絡する際は、以下の情報を整理して伝えると対応がスムーズです。対象スプレッドシートのURL、問題が発生しているシート名とセル範囲、表示されているエラーメッセージの内容、そして自分のGoogleアカウントのメールアドレスです。管理者はAdmin Consoleの監査ログを確認することで、どのポリシーやルールが原因でブロックされているかを特定できます。「共有設定を確認してほしい」「DLPルールの影響を調べてほしい」と具体的に伝えれば、管理者側の調査もスピードアップします。
Excelのようにパスワードで保護することはできる？
Googleスプレッドシートには、パスワードによるシート保護の機能はありません。これはExcelとの大きな違いです。代わりに、ユーザーアカウントベースの権限管理で保護を行います。どうしてもパスワード的な仕組みを実現したい場合は、Google Apps Scriptでウェブアプリを作成し、パスワードを入力しないとスプレッドシートのURLにアクセスできない仕組みを構築する方法があります。ただし、一度パスワードでアクセスした後はURLが見えてしまうため、毎回パスワードを求めるような厳格なセキュリティには向いていません。
スマートフォンから保護の設定や解除はできる？
2026年3月時点でも、Googleスプレッドシートのモバイルアプリ（iOS・Android）では保護の新規設定や解除には対応していません。保護されたセルは編集が制限されますが、保護の管理操作はPC版ブラウザからのみ行えます。緊急時にはスマートフォンのChromeブラウザで「PC版サイトを表示」を使う方法もありますが、画面の制約から重要な操作はPCでの実施をおすすめします。
共有ドライブ上のスプレッドシートでは保護の挙動が違う？
共有ドライブ（旧チームドライブ）上のファイルでは、ファイルのオーナーが個人ではなく共有ドライブそのものになります。このため、「オーガナイザー」権限を持つユーザーが通常のオーナーに相当する操作を行えます。コンテンツの制限やダウンロード制限など、個人ドライブとは異なる追加の制限が適用される場合があるため、共有ドライブ上での保護設定はより慎重に行う必要があります。
今すぐパソコンやスマホの悩みを解決したい！どうしたらいい？
いま、あなたを悩ませているITの問題を解決します！
「エラーメッセージ、フリーズ、接続不良…もうイライラしない！」
あなたはこんな経験はありませんか？
✅ ExcelやWordの使い方がわからない💦
✅ 仕事の締め切り直前にパソコンがフリーズ💦
✅ 家族との大切な写真が突然見られなくなった💦
✅ オンライン会議に参加できずに焦った💦
✅ スマホの重くて重要な連絡ができなかった💦
平均的な人は、こうしたパソコンやスマホ関連の問題で年間73時間（約9日分の働く時間！）を無駄にしています。あなたの大切な時間が今この悩んでいる瞬間も失われています。
LINEでメッセージを送れば即時解決！
すでに多くの方が私の公式LINEからお悩みを解決しています。
最新のAIを使った自動応答機能を活用していますので、24時間いつでも即返信いたします。
誰でも無料で使えますので、安心して使えます。
問題は先のばしにするほど深刻化します。
小さなエラーがデータ消失や重大なシステム障害につながることも。解決できずに大切な機会を逃すリスクは、あなたが思う以上に高いのです。
あなたが今困っていて、すぐにでも解決したいのであれば下のボタンをクリックして、LINEからあなたのお困りごとを送って下さい。
ぜひ、あなたの悩みを私に解決させてください。
まとめ
GoogleSheetsの保護範囲が解除できない原因は、権限不足、別ユーザーによる設定、組織のWorkspaceポリシーによる制限、ファイル形式の問題、ブラウザの不具合など多岐にわたります。特に組織制限が絡むケースでは、一般ユーザーの操作だけでは解決できないことが多く、Workspace管理者との連携が不可欠です。
まずは自分の権限レベルを確認し、保護設定者やオーナーに依頼できるかを試してみてください。急ぎの場合は「ファイルのコピーを作成」するワークアラウンドが有効です。そして長期的には、保護の説明欄をきちんと記入する習慣をつけること、Googleグループを活用した権限管理に移行すること、GASによる保護の自動化を検討することが、チーム全体の生産性向上につながります。
保護機能は「面倒なもの」ではなく、正しく理解して使いこなせば共同作業の安心感を支える強力な味方です。この記事で紹介した知識とテクニックを活用して、スプレッドシートをもっと安全かつ効率的に運用していきましょう。
コメント