Grokで業務用の管理表や顧客リストを作り、リンクで同僚に渡したことがある会社は、公開範囲を確認したい事案です。URLを社内だけで伝えていても、アプリ側で利用者を制限していなければ、第三者に情報を見られる可能性があります。
2026年11月10日、セキュリティ企業Clarocは、Grok Buildで作られたアプリの調査を公表しました。多数のアプリがログインなしで開け、一部には社内情報や個人情報が含まれていたとしています。
何が調べられ、どんな情報が見つかったのか
Clarocは未ログインで各アプリの最初のページを一度開き、結果を調べました。公表した件数は次のとおりです。
| 調査の段階 | 件数 |
|---|---|
| 発見したgrok.meのホスト名 | 43,601 |
| 接続を試したアドレス | 43,551 |
| 稼働していたアプリ | 37,571 |
| ログインなしで開けたアプリ | 35,578 |
94.7%の分母は37,571件です。 ゲームなど、公開することに問題のない用途も含まれます。この割合は、機微情報の含有率やGrok全利用者の被害率を示しません。一方、Clarocは従業員名簿、患者の医療情報、コード内の平文パスワードなどを含む事例も報告しています。Clarocの調査原文
対象は、GrokのWeb版やモバイルアプリで会話からアプリを作り、公開する機能です。公式紹介でも、公開アプリごとにgrok.meのアドレスが割り当てられ、開ける人を選ぶ仕組みが説明されています。ターミナルで使うGrok Build CLIとは区別して読む必要があります。Grok Buildの公式紹介
ランダムなURLでも、住所の部分は見つかることがある
Webサイトを開くとき、端末はDNSという仕組みにホスト名の接続先を問い合わせます。その観測記録を集める「パッシブDNS」のデータから、アプリのアドレスが見つかることがあります。Clarocはこの経路を使って公開アプリを発見したと説明しています。Clarocの調査原文
図の上部は、URLのうちDNSに問い合わせる部分を示しています。アドレスが分かった後に中身を返すかどうかは、アプリのアクセス制御で決まります。DNSの記録に顧客名簿や医療情報そのものが保存される、という話ではありません。
自社で点検するときも、URLの文字列が長いか、推測しにくいかだけで判断せず、許可されていない人のアクセスを実際に拒否できるかを確かめます。URLを変更しただけで対処を終えるのは避けましょう。
「公開前は非公開」と「公開時の初期選択」を分ける
Clarocが使った有料アカウントでは、公開時のアクセス設定で「Anyone with the link」が初期選択されていました。「Invited users」「Only you」も選べたとしています。作成しただけで自動公開された、という報告ではありません。Clarocの調査原文
一方、Ars Technicaの取材に対し、提供元側は、作成者が共有を選ぶまではアプリは非公開だと説明しています。同記事は、SpaceXSI・X関係者が作成した24件のアプリが、報道時点で「app not found」になったことも伝えています。Ars Technicaの報道
ここは確認する時点が違います。未公開の状態と、公開操作を進めた先のアクセス設定を、別々に確かめる必要があります。
2026年11月11日の本稿確認時点では、一般利用者向けの初期選択が「Only you」に変更されたことや、影響する全アプリの対処完了を確認できる公式案内は見つかっていません。本稿では利用者のアカウントにログインして設定を再現していないため、現在の画面と保存後の動作を各アプリで確認してください。
社内で使っているアプリは、この順で点検する
以下は今回の事案を受けた、業務用アプリの点検案です。確認は自社が所有・管理するもの、または明示的に許可されたものに限ります。
1. 作った人と、公開しているものを把握する
担当者に、Grokなどで作った業務ツールがないかを確認します。会社が正式導入したサービスだけでなく、個人が作った試作品も対象にします。
最低限、次の5点を一緒に残すと、対応を振り分けやすくなります。
- アプリ名と管理者
- 公開URL
- 入れている情報の種類
- 利用を許可する人
- 現在の公開範囲と最終確認日
たとえば、商品説明だけの公開ページと、取引先名・価格を入れた営業管理表では必要な制限が異なります。後者は優先して確認します。
2. 社内情報があるアプリの公開範囲を絞る
Grokでは、画面に表示される設定を確認し、本人だけなら「Only you」、特定の相手と使うなら「Invited users」など、意図する範囲を選びます。「Anyone with the link」は、誰に見られても差し支えない情報に限ります。
画面の表記や選択肢は変わる可能性があります。必要な制限がない場合や、誰が管理しているか分からない場合は、公開をいったん止めてから確認します。設定を保存したら、既存の公開URLでも変更が反映されたかを確かめてください。
3. ログインしていない人と、招待されていない人の両方で確認する
まず、自分のログイン状態を引き継がないブラウザーで、自社のURLを開きます。内部情報が表示されたら、公開範囲を見直します。
次に、担当者が用意した、招待されていない検証用アカウントで確認します。「Googleでログイン」などのボタンがあっても、それだけで社内限定とは限りません。本人を確認する「認証」に加え、その人に利用を許す「認可」が必要です。
開発担当者には、画面を開く場面だけでなく、データ取得、添付ファイルのダウンロード、編集・削除の各操作でも権限を確認するよう依頼します。書き込みの試験は、実際の顧客データではなく、許可された検証環境と架空データで行います。OWASPの認可に関する指針
4. 配信するコードと、接続先も調べる
開発担当者には、ブラウザーに送るHTMLやJavaScriptに、パスワード、APIキー、社内名簿などが含まれていないかを確認してもらいます。画面で隠していても、配信するファイルに入っていれば保護にはなりません。
公式紹介にはAPIキーをコード外に保存する「Secrets」がありますが、保管機能があることと、そのアプリが正しく使っていることは別に確認が必要です。接続先サービスの権限も、業務に必要な範囲に絞ります。Grok Buildの公式紹介
社内情報が見えていた場合は、非公開化の後も確認を続ける
意図しない公開が見つかったら、公開停止やアクセス制限で露出を止め、管理担当者へ連絡します。同時に、対象URL、確認時刻、見えていた情報の種類、変更した設定を記録し、利用できるアクセスログを保全します。調査に必要な証拠まで消さないよう、対応を担当者とそろえてください。
パスワードやAPIキーが配信されていた場合は、画面やコードから消すだけで終わらせず、失効・交換と接続先への反映、不審な利用の確認を進めます。OWASPの秘密情報管理・事故対応の指針
外部に開けたことだけで、悪意ある第三者による持ち出しまで断定はできません。一方、ログがないことだけを理由に「誰も見ていない」とも判断できません。個人情報や顧客の機密情報が含まれる場合は、社内の事故対応窓口や専門家と、通知・報告の要否を確認します。
AIで作るアプリは、機能を足すたびに扱う情報も変わります。公開時だけでなく、顧客情報の追加、共有先の変更、ログイン機能の変更後にも、同じ点検を繰り返す運用にしておきましょう。
本稿は2026年11月11日に確認した公開資料に基づきます。露出したアプリ自体へのアクセスや、第三者のデータの取得・変更は行っていません。