自治体Glideアプリのデータ漏洩を防ぐ権限設計とRow Owners実装解説

地方自治体や地域団体、企業がノーコードツール「Glide」と「Google Workspace」を連携させてPWA（Progressive Web Apps）を導入する際、最も重視される審査基準となるのが「住民や顧客の個人情報が漏洩しないか」というセキュリティの担保です。

ノーコード開発は、従来のスクラッチ開発に比べて圧倒的に早く、かつ低コストで地域DXを実現できます。しかし、初期のアクセス権限設計を誤ると「他人の申請内容や個人情報がブラウザから丸見えになる」という、重大なセキュリティ事故を引き起こしかねません。

本記事では、Civic Tech Akitaが提供する『おたよりアプリ』や『町内会デジボ』などの地域DXソリューションで標準採用している、「自治体水準のデータ機密性を担保するRow Owners（行オーナー）実装」および「GAS（Google Apps Script）連携におけるAPIキー保護の実務コード」を徹底解説します。

※なお、弊社の独自サーバー非保持・多層防御の基本思想については【情報セキュリティ基本方針】を、Webサーバー停止時でもアプリが100%稼働し続けるインフラ耐障害性の検証については[【実証】サーバー障害時でも止まらない！自治体・地域アプリに「Glide×Google Workspace」基盤が選ばれる理由]をご覧ください。

なぜ「Filter（絞り込み）」だけでは自治体データを守れないのか？

結論から言うと、Glideの「Filter（絞り込み）」機能はUI（画面）上の表示を整理するためのものであり、セキュリティ目的のアクセス制御（閲覧制限）としては機能しません。

多くの開発初心者が「Filterでログインユーザーの行だけを表示させれば安全」と誤認しがちですが、これを行政や地域アプリで運用することは極めて危険です。

ブラウザ開発者ツール（F12）で見えてしまうFilter機能の落とし穴

Filter機能を用いた場合、サーバーはスプレッドシートに登録されている「全ユーザーの全行データ」を一度クライアント（利用者のスマートフォンやPCブラウザ）に送信します。その上で、ブラウザ側のJavaScriptやCSSで「該当しない行を非表示にする」処理を行っています。

つまり、ブラウザの開発者ツール（F12）の「Network」タブやメモリ上の通信パケットを覗くだけで、画面上では非表示になっている他の全住民の氏名・電話番号・住所・相談履歴などのJSONデータが平文で閲覧できてしまいます。これは、明らかな情報漏洩事故に繋がります。

通信パケットレベルでデータを遮断する「Row Owners（行オーナー）」の仕組み

これに対し、「Row Owners（行オーナー）」機能は、データ送信の判断をブラウザではなく、Glideのクラウドサーバー側で実行します。

利用者が認証ログインした際、Glideサーバーはユーザープロファイルと合致する行データのみを抽出し、そのデータのみをブラウザへ暗号化送信します。他人のデータ行はそもそも端末側の通信パケットに一切流れてこないため、どれほど端末やブラウザを解析されても、データ漏洩を物理的に遮断できます。

【比較表】Filter機能 vs Row Owners機能のセキュリティ通信比較

評価項目	Filter（画面上の絞り込み）	Row Owners（行オーナー機能）
データ選別の場所	クライアント側（利用者のブラウザ）	サーバー側（Glide Cloud Server）
端末への送信データ	全住民・全ユーザーの行データをすべて送信	認証された本人の行データのみ送信
開発者ツール（F12）での閲覧	容易に他人のデータが閲覧可能（危険）	他人のデータは物理的に取得不可（安全）
用途・適用領域	カテゴリ分け・日付並び替え・検索UI	氏名・住所・相談履歴・保護者連絡などの機密保護
自治体・公共セキュリティ基準	不合格（導入不可）	行政基準クリア（多層防御の達成）

自治体水準をクリアするGlide×Google Workspaceの3大セキュリティ実装

行政機関や地域団体が運用に耐えうるセキュリティを確保するためには、フロントエンド（Glide）、データベース（Googleスプレッドシート）、自動化プログラム（GAS）の各階層で、厳格なアクセス権の分離を施す必要があります。

1. Row Ownersの正しい割り当て手順（メールアドレス・ユーザーロール）

Row Ownersを安全に機能させるには、Glideのデータエディタにおける「User Profiles」テーブルの設計が起点となります。

1. Email列のRow Owner化：
   ユーザーテーブルおよび各申請・投稿テーブルに「Email」型のカラムを作成し、カラム設定で「Row Owner」のトグルをONにします。これにより、ログインしたGoogleアカウントのメールアドレスと一致する行のみが端末にダウンロードされます。
2. Roles（役職・権限グループ）による多段制御：
   自治体職員や町内会長などの管理者には、全件の閲覧権限が必要です。単一のメールアドレスだけでなく、ユーザーテーブルに「Role」カラム（例：Admin, Staff, User）を定義し、Row OwnerをRoleに割り当てることで、一般住民には自身のデータのみ、管理者グループには管轄データ全体を表示させる安全な認可境界線を構築します。

2. Googleスプレッドシート連携時の「共有権限の境界線設計」

GlideのバックエンドとしてGoogleスプレッドシートを接続する際、最も多い設定ミスが、アクセス権を「リンクを知っている全員が閲覧可能」にしてしまう事故です。

• 「一般アクセス」の完全制限：
  スプレッドシートの共有設定は「制限付き」を死守し、組織外へのURL共有を遮断します。
• サービスアカウントおよび最小権限の原則：
  Glideがスプレッドシートへアクセスするための認可は、Google Workspace管理者の認可トークン経由で行われます。スプレッドシートを直接編集・閲覧できるGoogleアカウントは、自治体内の専任管理者（最小人数）に限定し、一般の職員や住民はスプレッドシートに直接アクセスさせず、GlideのUI（画面）越しにのみ操作を許可する「データのカプセル化」を徹底します。

3. GAS（Google Apps Script）連携時のAPIキー保護コード実装

Glideと外部API、またはLINE公式アカウントや自動メール配信をGASで連携させる際、スクリプトコード内にAPIキーやトークンを生書き（ハードコード）することは、重大な脆弱性となります。

コードを共有した際やGitHub等への流出を防ぐため、Google Workspaceの「スクリプトプロパティ（PropertiesService）」に機密情報を隔離し、プログラム実行時に動的取得する設計を必須化します。

/**
 * ====================================================================
 * Utility Module for GAS / Civic Tech Akita
 * Copyright (c) Civic Tech Akita (https://akita-csmedia.com/)
 * 
 * 本モジュールの著作権は Civic Tech Akita に帰属します（自社資産）。
 * ライセンス・実装に関するお問い合わせ: https://akita-csmedia.com/?page_id=1476
 * ====================================================================
 */

// スクリプトプロパティから安全にAPIキーを取得する（コード内ハードコードの完全排除）
function getSecureGlideApiKey() {
  const scriptProperties = PropertiesService.getScriptProperties();
  const apiKey = scriptProperties.getProperty('GLIDE_API_KEY');
  
  if (!apiKey) {
    throw new Error('GLIDE_API_KEY が未設定です。スクリプトプロパティを確認してください。');
  }
  return apiKey;
}

// セキュアに外部連携を実行するサンプル関数
function syncGlideUserData() {
  const apiKey = getSecureGlideApiKey();
  
  // 認証ヘッダーを動的に構築
  const options = {
    method: 'GET',
    headers: {
      'Authorization': 'Bearer ' + apiKey,
      'Content-Type': 'application/json'
    },
    muteHttpExceptions: true
  };
  
  // 安全な通信処理をここに記述
  // ...
}

自治体・法人のセキュリティ審査を通すGoogle Workspace環境設定

ノーコード基盤がどれほど安全であっても、データ母体となるGoogle環境のアカウント管理が甘ければセキュリティは破綻します。

個人Gmail運用がNGな理由と組織アカウント（Workspace）の必須機能

地域DXや受託開発において、無料の個人用Googleアカウント（@gmail.com）でシステムを構築することは、コンプライアンス上許容されません。自治体・企業のセキュリティ監査をクリアするには、有償の「Google Workspace」組織アカウントの導入が必須です。

機能項目	無料版Gmailアカウント	組織向け Google Workspace
2要素認証（2FA/MFA）	個人判断（強制不可）	管理者権限で組織全員に強制適用
データ所有権	個人に帰属（退職時の持ち出しリスク）	組織（自治体・企業）に完全帰属
アクセス監査ログ	簡易履歴のみ	誰が・いつ・どのファイルを操作したか完全記録
外部共有制御	制限不可	ドメイン外へのファイル共有を一括遮断可能

行政・企業DXを支えるGoogle Workspaceの導入・初期設定サポート

Civic Tech Akitaでは、PWAアプリの受託開発と同時に、安全なデータ基盤となるGoogle Workspaceの組織アカウント設計・導入支援を行っています。

セキュアな業務基盤の構築やアカウント開設をご検討中の組織様は、以下より公式導入支援をご活用いただけます。

👉 Google Workspace 組織アカウントに関する詳細はこちら

自作・内製運用の壁とCivic Tech Akitaのセキュア開発体制

Glide×Google Workspaceは手軽に導入できる一方、運用フェーズにおいて内製化チームが直面する「技術的な壁」が存在します。

Glideの仕様変更・行数上限・APIクォータ超過リスク

• データ同期遅延と行数制限：
  利用者が増えるにつれてスプレッドシートの行数が上限に近づき、同期速度の低下やプラン上限超過によるアプリ停止リスクが発生します。
• プラットフォームの仕様改定：
  ノーコード基盤は頻繁にアップデートが行われるため、アクション設定や権限仕様の変更に追従できず、「ある日突然通知が届かなくなる」といったトラブルが起こり得ます。
• GASの実行時間制限（6分壁）：
  データ集計やPDF自動生成処理など、扱うデータ量が増大すると、GASの最大実行時間（6分）を超過してエラー停止する問題に直面します。

確かな実績と行政水準のセキュア開発

Civic Tech Akitaでは、金融機関出身・地域DXプロデューサーの視点に基づき、最初から運用リスクを排除した堅牢なアーキテクチャで受託開発・OEM供給を行っています。

すでに秋田をはじめ各地で稼働している『スマート市民ナビ』『町内会デジボ』『おたよりアプリ』などのソリューション群は、すべて行政機関や公共団体の厳しいセキュリティ要件をクリアして設計されています。

詳細な導入事例や機能一覧は、【地域DXアプリ・製品情報一覧】をご覧ください。

よくある質問（FAQ）

まとめ：ノーコードのスピード感と行政水準のデータ保護は両立できる

ノーコード（Glide）とクラウド（Google Workspace）を組み合わせた開発は、正しくアーキテクチャを設計することで、高額なスクラッチ開発と同等以上の機密性と耐障害性を発揮します。

1. 画面の絞り込み（Filter）を過信せず、必ず「Row Owners」で通信レベルのデータ遮断を行う
2. スプレッドシートの共有設定を「制限付き」にし、データのカプセル化（直接アクセスさせない設計）を徹底する
3. GASスクリプト内の機密情報は「PropertiesService」を用いて環境変数化する
4. 組織運用の基盤として「Google Workspace」のセキュリティ機能を有効化する

「自組織でアプリを作ってみたがセキュリティに不安がある」「行政基準を満たすセキュアな地域アプリを最短で導入したい」とお考えの担当者様は、ぜひCivic Tech Akitaへご相談ください。