Glideアプリの公開範囲を決める:リンク共有とログイン制限の確認手順
AIを使いこなすClaudeで執筆し、GPTで自動校閲・修正しています。

結論から言うと、公開範囲は設定画面を見て決めるだけでは足りません。自分がログインしていない状態で、実際にリンクを開いて確かめるところまでやって、はじめて「公開前の確認」になります。編集画面のプレビューだけでは、公開用リンクでのサインインやアクセス制限まで確認できないからです。この記事の設定説明は、公式ドキュメントで「Glide Classic」向けとされているアプリを対象にしています(App Settings)。 この記事では、①アプリを3つの公開パターンのどれにするか決め、②自分のアカウント外で試し、③チェック表に結果を記録する、という流れを紹介します。サンプルの名前やメールアドレスは、すべて説明用の例です。
先に決める:公開パターンは3つ
Glideの公式ヘルプの用語集では、非公開アプリは「閲覧や操作の前にサインインが必要なアプリ」、公開アプリは「サインインなしで誰でも開けるアプリ」と説明されています(The Glide Glossary)。さらに公式のセキュリティ紹介ページでは、新しく作ったアプリは初期状態で非公開であり、設定から公開にしたり、ユーザーテーブルに載っている人だけ、または特定のメールドメインだけに絞ったりできると書かれています(Glide Security Center)。
公式のUsersには、公開アプリでもサインインを必須にできることが説明されています。これを、確認作業のために次の3パターンに整理します。この分け方は編集上の整理で、Glideの正式な分類名ではありません。表の期待結果は、この記事で設定の合否を判断する基準であり、実機で確認した結果ではありません。
- A. 誰でも開ける、向く用途の例:店舗の案内、イベント資料、外部の人が開いたときの期待結果:リンクを知っていればサインインなしで中身が見える
- B. サインイン必須(誰でも登録可)、向く用途の例:参加者の出欠入力、外部の人が開いたときの期待結果:サインインするまで中身は見えない。誰でも入れる
- C. 指定ユーザーのみ、向く用途の例:社内の作業メモ、少人数の共有、外部の人が開いたときの期待結果:登録された人だけ入れる。それ以外は入れない
どれにするかは「画面に出る情報を、リンクを拾った知らない人が見てもよいか」で決めます。見られて困る情報(個人の連絡先、顧客名など)が1つでもあるならAは避け、Cを基本にします。
設定画面で見る場所
公式のApp Settingsでは、SettingsのAccessでPrivate/Publicを選び、Usersでサインインできる人の範囲を設定すると説明されています。CではPrivateにし、Usersを「Users in the users table」にして、許可するメールアドレスをユーザーテーブルに登録します。「Anyone」や許可ドメインによる設定とは区別してください。サインイン方法はAuthenticationで確認し、以下ではメールでPINを受け取る方法を使います。ただし画面の項目名や配置は更新で変わることがあります。設定と「外から見た結果」の両方を確認してください。
プランにも注意が必要です。今回確認したGlide PricingはGlideOS向けの料金を掲載しているため、この記事で扱うGlide Classicの利用条件の根拠にはしません。公開機能や利用できるユーザーの条件は、ご自身の契約内容と管理画面で確認してください。
公開前の確認手順(自分のアカウント外で試す)
1. 試験用の「役」を3つ用意する
- 許可する人:Cの場合に、ユーザーとして登録しておくメールアドレス(自分の別アドレスなど)
- 許可しない人:どこにも登録していないメールアドレス
- 未ログインの人:何もサインインしていないブラウザ
メールアドレスは実在して受信できるものを使います。本番の顧客のアドレスは使わず、自分で管理しているものに限ります。
2. 公開用リンクを、編集画面とは別のブラウザで開く
本番の個人情報や社外秘を入れる前に、説明用データで試します。公開用リンクでの試験に公開操作が必要な場合は、リンクを配布する前に行ってください。作成者としてログインしているブラウザではなく、新しいシークレットウィンドウや未ログインの別ブラウザ、できればスマートフォンで開きます。試験用アカウントを切り替えるたびにサインアウトするか、シークレットウィンドウをすべて閉じて開き直します。ここで未ログインの人としてどう見えるかを記録します。
- Aなら:サインインなしで中身が見える。見えてはいけない画面や項目が混ざっていないか、全画面をたどります。
- BまたはCなら:中身が見える前にサインインを求められる。
3. 「許可しない人」でサインインを試す
登録していないメールアドレスでサインインを試します。Cなら、入れないことが期待結果です。入れてしまった場合は公開しないでください。エラー時にどんな文言が出るかは画面で確認し、メモしておきます。
4. 「許可する人」でサインインを試す
Bでは試験用のメールアドレス、Cでは登録したメールアドレスでPINを受け取り、サインインします。入れたあと、その人に見せるつもりのない画面や行が見えていないかも確認します。Glideにはサインインした人のメールや役割に応じて行の閲覧を絞る「Row Owner」という仕組みがあり、列をRow Ownerに設定すると、メールまたは役割が一致する人だけがその行を見られると用語集に説明されています。入口を絞っても、中のデータの見せ方が緩いと意味が薄れます。画面で見えないことだけではデータ保護の確認になりません。表示条件はセキュリティ機能ではないため、非公開データにはRow Ownerなどの保護設定も確認します(公式ヘルプ)。
5. 許可を外して、入れなくなることを確かめる
Cでは、アクセス許可に使っているユーザーテーブルから試験用ユーザーを外し、新しい未ログインのブラウザで、そのメールアドレスによるサインインを試します。さらに、すでにサインインしていたブラウザでも再読み込みや操作を試し、アクセスできるかを記録します。削除後の反映時間や既存のログイン状態への影響は、今回確認した公式資料では確認できていません。「入れない」はこの記事で求める合格条件で、即時に遮断されるという製品仕様の保証ではありません。アクセスできる場合は共有を止め、設定と対処方法をGlideのサポートに確認してください。
6. リンクの扱いを決めて共有する
公式ヘルプによると、Glideは検索エンジンにアプリがインデックスされないようにしています(Navigating SEO and Indexing)。ただし、検索エンジンによるインデックスの防止は閲覧者を制限する仕組みではなく、Aのアプリはリンクを知った人なら誰でも開けます。リンクを転送されることを前提に、Aの内容を決めてください。
設定チェック表
下の表をコピーして、確認日と結果を埋めてください。結果欄の例は説明用で、実際の確認結果ではありません。
- 1、確認項目:採用パターン(A/B/C)を決めた、期待する結果:例:C、結果(○/×/メモ):
- 2、確認項目:未ログインのブラウザでリンクを開く、期待する結果:A:見える/B・C:サインイン要求、結果(○/×/メモ):
- 3、確認項目:未登録アドレスでサインインを試す、期待する結果:B:入れる/C:入れない、結果(○/×/メモ):
- 4、確認項目:B・Cで許可する人がPINサインインする、期待する結果:入れる(Aは対象外)、結果(○/×/メモ):
- 5、確認項目:登録済みの人に見せない画面・行がない、期待する結果:見えない、結果(○/×/メモ):
- 6、確認項目:Cで許可を外し、新規サインインとログイン済みの状態を試す、期待する結果:どちらもアクセスできないことを合格条件とし、結果と確認時刻を記録、結果(○/×/メモ):
- 7、確認項目:スマートフォンでも2〜4を再確認、期待する結果:同じ結果、結果(○/×/メモ):
- 8、確認項目:画面に個人情報・社外秘が出ていない(Aは必須)、期待する結果:出ていない、結果(○/×/メモ):
- 9、確認項目:共有するリンクと共有先を記録した、期待する結果:記録済み、結果(○/×/メモ):
1つでも期待と違えば公開を止め、設定を直してからやり直します。
AIに任せる部分と、人が確認する部分
AIに頼めるのは、チェック表のたたき台作りと、結果の整理です。サインインを実際に試して画面を見るのは人の仕事です。次の依頼文は、そのまま使える形にしてあります(未実行の例です)。
Glideで作った小さなアプリの公開前チェック表を作ってください。
- アプリの用途:イベントの当日担当表(説明用の例)
- 公開パターン:指定ユーザーのみ
- 画面:担当表、連絡先一覧、自分の担当シフト
- 見せたくない情報:スタッフの電話番号
- 試験用の役:許可する人、許可しない人、未ログインの人
未ログイン、未登録アドレス、登録済みアドレス、ユーザーを外した後
の4場面で、確認すべき画面と期待結果を表にしてください。
わからない設定名は推測せず「要確認」と書いてください。実在のメールアドレス、電話番号、顧客名は入力せず、staff-a@example.com のような架空の値に置き換えてください。AIの回答にある設定名は、必ずご自身の画面で照らし合わせます。
つまずきやすい点
- PINメールが届かない:Office 365などでスパム扱いになることが公式ヘルプに書かれています。迷惑メールフォルダの確認、送信元(no-reply@auth.appnotify.io)の許可、「Include magic link to sign in without PIN」のチェックを外す、といった対処が案内されています。許可する人のテストが失敗しても、まず権限ではなく届いていないだけでないかを確認します。
- 自分では見えるのに他人は見えない/逆:プレビューで選んだユーザーや、サインイン状態、アクセス設定の違いが考えられます。必ず別ブラウザの検証結果で判断します。
- あとから公開範囲を変える:AからCに変えるときは、すでにリンクが広まっている前提で、再度手順2〜5をやり直します。

