メインコンテンツへスキップ
AMPL
公開した瞬間、世界中から見える
レッスン 1 / 15|11分で読めます

公開した瞬間、世界中から見える

URLを渡した相手にだけ見えている、は錯覚。ブラウザの開発者ツールで「誰でも見えるもの」の正体を自分の目で確かめる。

はじめて作ったツールを院内のグループに送ったとき、私はこう思っていました。

URLを知っている人にしか、見えないだろう、と。

これが、最初に捨てるべき思い込みです。

インターネットに公開したものは、原則として世界中の誰からでも、そして誰かが書いたプログラムからでも見える状態になります。URLを教えた相手「だけ」に見えているわけではありません。

しかも相手は、人間だけではありません。

  • なぜ、作ったばかりの無名のツールが狙われるのか？
  • なぜ、医療者の小さな計算ツールに価値があるのか？
  • なぜ、公開して数時間で見つかるのか？

この3つの「なぜ」に答えられるようになるのが、今回のゴールです。

ㅤ

狙われるのは「あなた」ではなく「全部」

まず、いちばん大事な事実からいきます。

攻撃の多くは、人間があなたのサイトを選んで行うものではありません。プログラムが、インターネット全体を機械的に巡回して、鍵のかかっていない場所を探しています。

例えるなら、泥棒が家を下見して選ぶのではなく、全部の家のドアノブを自動で回して回る機械が四六時中動いているようなものです。あなたの家が豪邸かどうかは関係ありません。鍵がかかっていないドアが見つかれば、そこが入口になります。

実際、公開されたばかりのサイトのURLは、証明書の発行記録（Certificate Transparencyログという公開台帳）などから機械的に収集できます。「無名だから見つからない」は、成り立ちません。

2026年1月の調査では、公開されたアプリのURL2万件超をスキャンしたところ、11%がデータベースの接続情報をブラウザ側に露出していました（SupaExplorer, 2026）。探す側から見れば、11%の家のドアが開いているのです。

ㅤ

ブラウザの「開発者ツール」で、見える側に立ってみる

守り方を学ぶ前に、まず攻撃者から何が見えているのかを自分の目で確かめます。

使うのは、特別なハッキングツールではありません。ChromeやSafariに最初から入っている開発者ツール（devtools）です。自分のアプリを開いて、次の操作をしてみてください。

Macなら Command + Option + I、Windowsなら F12。これだけで開きます。

見るべき場所は3つです。

  • Elements（要素）: ページのHTML。画面に表示していない「隠し要素」も全部ここに見えます
  • Network（ネットワーク）: アプリとサーバーの通信内容。どこに何を送り、何が返ってきたかが全件記録されます
  • Sources（ソース）: アプリのJavaScriptコード。あなたがAIに書いてもらったフロントエンドのコードは、ほぼ原文のままここで読めます

ここから導かれる、この講座でいちばん大事な一文がこれです。

ブラウザに届いたものは、すべて利用者に見えている。

「画面に表示していないから大丈夫」は通用しません。HTMLの中に隠したパスワードも、JavaScriptに書き込んだAPIキーも、通信に含まれる他人のデータも、開発者ツールを開けば数クリックで読めます。

注意

「隠す」と「守る」は別物

CSSで非表示にする、ボタンを押せなくする、URLを複雑にする。これらはすべて「隠す」であって「守る」ではありません。守るとは、サーバー側で「この人にはこのデータを返さない」と判断することです。この区別が、講座全体を貫く背骨になります。

ㅤ

98%という数字

「とはいえ、AIが書いたコードなら大丈夫では」と思うかもしれません。

2026年に公表された調査では、実際に公開されているVibe Coding製アプリ1,072本をスキャンした結果、98%に少なくとも1件の脆弱性があり、16%は重大な欠陥を抱えていました。172本はログインなしでデータを削除でき、39本は誰でもデータベースの全テーブルを読み取れる状態でした（Symbiotic Security, 2026）。

AIはコードを書くのは得意ですが、「公開して人に使わせる」ための守りの設定は、頼まなければやってくれないことが多い。そして頼む側が何を頼めばいいか知らなければ、頼めません。

だからこの講座があります。

医療者にとって、これは他人事ではありません。作るツールの性質上、利用者は同僚の医療者で、扱う情報は職業上の信頼に直結します。患者情報を扱わない設計にしていても（それが大前提です）、利用者のメールアドレスや利用記録が漏れれば、信頼は大きく傷つきます。

視点

「患者情報を扱わない設計」は、規制の観点でも効いている

医療情報システムには、厚労省と経産省・総務省による安全管理ガイドライン群（いわゆる3省2ガイドライン）があります。その適用範囲は「患者情報（個人識別情報）を含む」システムです。つまり、最初から患者情報を扱わない設計にしておくことは、この重い規制の線をそもそも踏まないという意味も持ちます。この連載が一貫して「カルテ非依存・患者データなし」を前提にしているのは、安全のためであると同時に、この線引きのためでもあります。法規の全体像は医療データと法規の講座で。

ㅤ

「見える」の全体地図

今日の内容を1枚にまとめると、こうなります。

場所見える範囲守りの考え方
ブラウザ（HTML/JS/通信）利用者全員に全部見える秘密を置かない
サーバー（API・環境変数）外からは見えない秘密はここに置く
データベース設定次第で全世界に公開にも、堅牢にもなる次回以降の主役

この地図の「データベース」の行が、実は事故の最大の発生源です。それは第2回と第3回でじっくり扱います。

ㅤ

今日のまとめ

3行で振り返ります。

  • 公開されたアプリは、URLを教えた相手だけでなく、世界中の自動スキャンから見えている
  • ブラウザに届いたものはすべて利用者に見える。隠すと守るは別物
  • Vibe Coding製アプリの98%に脆弱性。ただし原因の大半は「知っていれば防げる」設定の抜け

ㅤ

次のレッスン

次回は、実際に起きた事故を3つ解剖します。150万件のAPIキーが漏れた事件も、原因をたどれば「3つの過ち」のどれかに行き着きます。自分のアプリに当てはまるかを確かめながら読んでください。

ㅤ

参考・出典