「サービスを停止してください」「いや、普段から停止しています」
PHP脆弱性騒動から考える、Webサービスと個人情報のあたらしい関係
2026年10月、Webシステムで広く使われているPHPの脆弱性が公表され、多くのサービス運営者が緊急対応に追われました。
私たちが10年以上運営している写真配信サービス「SPIXD」も、基盤にPHPを利用しています。そんな折、ある取引先から連絡をいただきました。
「安全が確認できるまで、サービスを停止してはどうでしょうか」
もっともなご提案です。ただ、私は少し返答に詰まってしまいました。
「いや、うちのサービス、普段から停止しているんですけど……」
冗談のようですが、本当の話です。このやり取りをきっかけに、私はWebサービスとセキュリティ、そして個人情報のあり方について深く考えることになりました。
食べログに載らない小料理屋
SPIXDは、イベント会場で撮影した写真を、その場で発行したQRコード経由で参加者のスマートフォンに届けるサービスです。
一般的なWebサービスは「24時間365日オープン」が当たり前です。検索エンジンにインデックスされ、世界中からいつでもアクセスできる状態こそが価値だと信じられてきました。
しかし、SPIXDは真逆です。
イベント当日に写真のアップロード窓口を開き、イベントが終われば入口を閉じます。参加者が写真をダウンロードできる閲覧期間は約2週間。その期間が過ぎれば、閲覧ページ自体を非公開にします。検索エンジンのクローラーもブロックしています。
1年365日のうち、開いている時間よりも、閉じている時間の方が圧倒的に長いサービスです。
例えるなら、食べログにも載らず、営業時間も看板も出さず、ランチもやらない「完全予約制の小料理屋」です。客は決まった日の宴席にだけ集まり、料理を楽しみ、終われば暖簾を下ろす。
それでも、ビジネスとして成り立っています。顧客が対価を払っているのは「24時間サーバーが稼働していること」ではなく、「必要な人に、必要な写真が、確実に届くこと」だからです。
暖簾を下ろせば安全なのか？
では、店を閉じていれば安全なのでしょうか。
公開期間を絞ることには、攻撃を受ける機会（アタックサーフェス）を減らし、インターネット上に古いデータを放置しないという意味で、確かな合理性があります。
ただし、過信は禁物です。
画面上が「404 Not Found」になっていても、裏側のWebサーバーやPHPプロセスが動いていれば、攻撃者は直接IPアドレスを叩いて脆弱性を突くことができます。小料理屋だって、暖簾を下ろしたからといって、勝手口の施錠や厨房の火の元確認を怠っていい理由にはなりません。修正パッチの適用や適切なインフラ管理は不可欠です。
それでもなお、「必要なときだけ開き、役目が終われば閉じる」という設計思想は、運用リスクを物理的に下げる強力な防壁になります。
そもそも、客の名前を知らない
SPIXDには、もうひとつ特徴があります。
写真を受け取る人の氏名も、住所も、メールアドレスも取得しないことです。
撮影された写真には固有のIDが割り振られ、参加者はQRコードを読み取るだけで自分の写真を受け取れます。私たちが「誰が誰なのか」を知る必要はありません。
人物が写った写真そのものは個人情報になり得ますし、アクセス制御には細心の注意が必要です。しかし、顔写真と「氏名・住所・決済情報」が紐づいた顧客データベースを持たずに済むことは、リスク管理上、決定的な意味を持ちます。
「万一、侵入されたらどうするか？」
セキュリティを強固にすることは大前提ですが、究極の防御策は別にあります。
「最初から、持たなくていいものは持たない」
これに尽きます。
AI時代、小さな会社が個人情報を持つリスク
最近はAIツールの進化によって、個人や小規模チームでも驚くほど高機能なWebサービスを短期間で作れるようになりました。
顧客管理、予約フォーム、会員制ECサイト。かつて数千万円かかったシステムが、一人で数日で組めてしまう。これは素晴らしい民主化です。
しかし、サービスを簡単に作れるようになったからといって、個人情報を安全に守り続ける能力まで簡単に手に入るわけではありません。
氏名、住所、電話番号、パスワード。とりあえず必要そうだからとDBに保存し、サービス終了後も放置される。開発者が増えるペースに対して、セキュリティや法務の専門家が同じペースで増えるわけではありません。
新しいサービスを立ち上げるとき、私たちはまず自分に問いかけるべきです。
「その個人情報、本当に自社のDBに保存する必要がありますか？」
SNSログインの「その先」へ
「それなら、LINEログインやGoogleログインを使えばいいのでは？」と思うかもしれません。
確かにSNS認証を使えば、パスワード管理の責任からは解放されます。しかし、SNS認証の本質は「本人確認（認証）」です。サービス側が氏名や配送先住所を取得して自社のDBに保存してしまえば、保管責任は結局自社に残ります。
私が考えているのは、「個人情報の保管」と「サービスの提供」を完全に切り離す仕組みです。
例えば、小さなECサイトを想像してください。
顧客は、信頼できる「個人情報預かりサービス」に氏名や住所をあらかじめ登録しておく。
小さなECサイトで買い物をする際、店主側のDBに保存されるのは「注文内容・金額」と「顧客トークン（ランダムなID）」だけ。顧客の住所や本名は保存されない。
商品を発送する際、店主のシステムはAPI経由で配送会社に発送伝票の発行を依頼し、預かりサービスが配送会社へ直接宛先データを連携する。
店主は、顧客の住所や氏名を自社サーバーに1バイトも保存することなく、商品を届けることができます。
「情報を保管していないこと」と「必要な業務を遂行すること」は、両立できるはずなのです。
「個人情報を売らない」管理ビジネスの可能性
このインフラを担うのは、高度なセキュリティ投資とガバナンス能力を持つ企業であるべきです。
例えば、リクルートやビズリーチのような大手人材系企業、あるいは金融機関のように、膨大な会員基盤と厳格なコンプライアンス体制をすでに確立している企業が、APIプラットフォームとして提供する形が考えられます。
ビジネスモデルも明快です。 利用する事業者から、APIコール数や認証件数に応じた利用料を受け取る「BtoBのセキュリティ・インフラ事業」です。
重要なのは、「預かった個人情報を広告やトラッキングに二次利用して儲ける（従来のビッグデータビジネス）」のではないという点です。
「私たちはあなたの情報を売りません。あなたの情報を安全に保護し、必要な相手に必要な分だけ開示する代行手数料として、事業者から対価をいただきます」
このスタンスを貫ける専門プレイヤーこそが、これからのWebに必要な信頼を獲得できるのではないでしょうか。
Webサービスは「何を持たないか」で進化する
もちろん、データを1箇所に集約することには「標的としてのリスクが高まる」という課題もあります。利用ごとのトークン分離、ゼロ知識証明などの暗号技術、ユーザー自身によるアクセス権限の即時破棄機能など、極めて高度な設計が前提になるでしょう。
今回のPHPの脆弱性騒動は、長年動かしてきたシステムのメンテナンスを見直す厳しい契機でした。
しかし同時に、Webの本質を再定義する機会でもありました。
世界中から24時間アクセスできることだけが、正解ではない。 あらゆる顧客データを自前で抱え込むことだけが、おもてなしではない。
必要な人に、必要な時間だけ、そっと暖簾を掲げる。 必要な役割を果たしたら、余計な情報は残さずに手放す。
SPIXDが「普段から停止している」のは、高度なセキュリティ戦略から始まったわけではありません。「目の前のイベントで、確実に写真を届ける」という目的を純粋に突き詰めた結果、削ぎ落とされた姿でした。
AIが作るサービスで溢れかえるこれからの時代、Webの進化は「どれだけ多くの機能やデータを持つか」ではなく、「どれだけ持たずに価値を届けるか」にかかっているのかもしれません。
コメント