焼肉きんぐ1078万件流出。あなたのパスワード、まだ使い回してない？

焼肉きんぐのアプリから、メールアドレスと電話番号が1078万件以上流出した。そのメールアドレスは、あなたが他のサービスにログインするときのIDでもある。パスワードを使い回しているなら、他人事ではない。私自身、パスワード管理ツールを入れるまでは、完全に使い回していた側だ。

そして、AIでアプリを作り始めた人には、もう一歩踏み込んで読んでほしい。最近の大きな漏えいは、正面のドアを壊された話ではなかった。では自分で作る側はどうか。私がAIと作ったレジアプリには、ドアそのものが付いていなかった。

一晩で5社、そして国が一つ

10月5日の夜、AIニュースを毎日発信しているチャエンさんが「今日だけで企業の情報漏洩事件が多すぎる」と投稿していた。焼肉きんぐ、ホワイトエッセンス、大和証券、大起水産、日経。最大の焼肉きんぐは、公式アプリの会員情報が1078万件を超えて流出した。翌日には、デンマークで国民の個人番号を含む約880万人分にアクセスされた、という続報まで流れてきた。

（10月5日の漏えい公表をまとめた記事）

危ない時代が来るかもしれない、ではない。もう来ている。

合鍵を持っている人の家から入られる

目立った2件を読むと、同じ形をしていた。

デンマークでは、国の登録システムそのものが破られたわけではなかった。正規の照会権限を持つ民間企業が経由され、その権限で大量の自動検索がかけられた。大和証券も、問い合わせ管理に使っていた外部サービスのサーバーが不正アクセスを受け、約11万人分が漏れた可能性があるという。

正面のドアは破られていない。合鍵を持っている人の家から入られている。データに入れる鍵を誰かに渡した時点で、その誰かの戸締まりが自分の戸締まりになる。

なお、焼肉きんぐがどこから入られたかは、まだ公表されていない。だからこの記事では、焼肉きんぐを「合鍵型」とは呼ばない。

では、自分でアプリを作る側はどうか。合鍵どころの話ではなかった。私の場合、ドアがそもそも付いていなかった。

AIが書いた要件定義書に、ログインがなかった

私はいま、社会人向けのテック講座で、スーパーのレジ（POS）アプリを作っている。コードはほとんどAIに書かせている。いわゆるバイブコーディングだ。

最初に要件定義書を作った。正確には、AIに初版を書かせた。講座の公式の要求資料を、私はまだ手に入れていなかった。題材と前提だけを渡して起案させた。出てきたものは、よくできていた。項目は整理され、文章はもっともらしく、そのまま提出できそうに見えた。

あとで公式の要求資料を見つけ、AIに読ませて突き合わせた。初版からは、ログイン機能がまるごと抜けていた。会員の仕組みもなかった。レジ担当者が自分のIDでログインする、という一番最初に書かれていた要求が、影も形もなかった。

AIの名誉のために書いておくと、AIは初版に「公式の仕様は読めていないので仮置き」と書いていた。悪いのはAIではない。要求の実物を持たないまま、出典も渡さずに起案させた私のほうだ。その「仮置き」の一行を、私は読み流していた。

それでも、怖さは残る。ないものは、ないまま整って見える。抜けのある文書も、AIが書くと滑らかに読めてしまう。もし初版のままコードを書かせていたら、ログインのないレジアプリが、ちゃんと動いて出来上がっていたはずだ。動くから、作った本人は満足する。「よく分からないけどアプリ作っちゃいました」の正体は、たぶんこれだ。

星4つでも、見えないところ

焼肉きんぐの件では、SNSで一本の記事が掘り起こされた。2年ほど前、同社のアプリのテストを請け負った会社の導入事例だ。開発のコストと期間を優先した結果、アプリに仕様書が存在しなかったこと、仕様書がないままテストを設計して回したことが、成功談として書かれていた。テストでアプリストアの評価は1点台から4点台まで上がった、と。

先に断っておくと、今回の漏えいの原因は公表されていない。記事のアプリと現行のアプリが同じかも、テスト体制と漏えいに因果があるかも分からない。犯人探しに使うつもりはない。

ただ、私のログイン抜けと同じ構図が見える。仕様書がないということは、「正しい動き」の基準がないということだ。基準がなければ、テストは画面で触って確かめられる範囲に寄っていく。ボタンが押せるか、注文が通るか、画面が崩れないか。利用者の目に見える不具合はかなり減らせるし、評価も上がる。

ところが、ログインの仕組みや、誰がどのデータを見てよいか、そもそも何のデータを持つのか、は画面には出てこない。誰かが要件として書き、別に確かめない限り、星4つになっても守られている保証はない。

要求は自分で持つ。1行にテストを1本

それ以来、私はいきなりアプリを作らせない。先に要求と要件を自分で整理し、それと対になるテストまで決めてから、コードを書かせる。開発の世界でV字モデルと呼ばれる考え方だ。左側で「何を作るか」を書き、右側で「それができているか」を確かめる。

POSアプリの要件定義書には、セキュリティの要件を6行書いた。

大事なのは、その先だ。テスト仕様書で、この6行の1行ずつにテストをつないだ。要件とテストの対応表、つまりトレーサビリティ表である。

たとえば1行目の「認証しないと使えない」には、画面を経由せずにレジの会計処理を直接呼び出したらどうなるか、というテストを付けた。ログインしていなければ断られる、が正解だ。画面にログインボタンがあっても、裏口から呼べてしまえば意味がない。最後の「実在の個人情報は扱わない」にも、登録データが架空のものだけかを確かめるテストがある。

パスワードの保存方式でも一つ学んだ。チュートリアルでよく見るライブラリを、更新が止まっていると分かって、あえて使わなかった。AIの提案も、ネットの手順も、そのまま信じないで一度調べる。

役割分担をはっきりさせておく。

• 人がやること：要求の出典を持つ（なければ自分で書く）、持たないデータを決める、テストの結果を自分の目で確かめる

• AIに任せてよいこと：初版の起案、要求との突き合わせ、対応表づくり、コードを書くこと

公式資料がない個人のアプリなら、要求は自分で書くしかない。誰が使うか、何を預かるか、何をされたら困るか。この3つを数行で書いてからAIに渡すだけで、初版の抜けは自分で拾える。

システム開発に30年携わってきた方が、こう書いていた。「作るのは一度ですが、面倒を見るのはずっと続きます」。

持たなければ、漏れない

要件の最後の1行「実在の個人情報は扱わない」は、学習用だから書けた行でもある。でも、この発想は本番のアプリにもそのまま使える。一番強いセキュリティは、守ることではなく、持たないことだ。持っていないデータは、どんな攻撃を受けても漏れようがない。

漏えいは、データとデータがつながった瞬間に重くなる。メールアドレスだけなら迷惑メールで済むかもしれない。そこに名前と電話番号と住所がそろうと、特定の一人に届く情報になる。デンマークの件が深刻なのは、氏名と住所と個人番号がセットで出たからだ。

AIに「会員登録機能を付けて」と頼むと、名前もメールも電話番号も住所も、頼んでいない入力欄まで気を利かせて作ってくることがある。その親切を一度疑って、欄を一つ削ってほしい。

ログインや決済のように、自分で作らずに既存のサービスに任せる手もある。合鍵の話と矛盾するようだが、任せること自体は正しい。専門の会社のほうが、自分よりずっと戸締まりがうまい。管理すべきなのは、渡した鍵の権限と置き場所だ。

そして個人開発でよく起きるのが、その鍵の置き忘れだ。データベースにつなぐための鍵を、画面側のコードに書いたまま公開してしまう。データベース側の「誰が読めるか」の制限を、オフのまま公開してしまう。この瞬間、あなたのアプリは、見知らぬ誰かに合鍵を配っている。

そして足元に戻る。私のパスワード

ここまで偉そうに書いてきたが、冒頭で白状したとおり、私は Bitwarden を入れるまでパスワードを完全に使い回していた。どのサイトも、ほぼ同じ文字列だった。

これも合鍵の話だ。どこか一つのサービスからメールアドレスとパスワードが漏れると、攻撃する側はその組み合わせを他のサービスに片っ端から試す。パスワードリスト攻撃と呼ばれる手口で、使い回しているなら、一つの漏えいで全部のドアが開く。自分で合鍵を配り歩いていたのと同じだ。

今はパスワード管理ツールの Bitwarden を使っている。無料で使えるツールだ。

1年以上前、お金の勉強をするコミュニティで、1Password というパスワード管理ツールのセミナーを受けた。講師はとても熱心に1Passwordを勧めていた。最後に私は手を挙げて聞いた。「Bitwardenじゃダメなんですか」。

返ってきたのは逆質問だった。無料のところに、パスワードを全部預けておくのってどうですか。何かあったとき、どこが保証してくれるんですか。

確かに不安だな、と思ったのを覚えている。それでも1Passwordは有料なので、ためらって、結局移らなかった。今回の漏えい続きで、本当に移ろうかと少し揺れている。

技術の目で見ると、この問いは少しずれている気もする。Bitwardenも1Passwordも、パスワードを自分の端末の中で暗号化してから預ける仕組みで、運営会社でも中身は読めない設計だとしている。Bitwardenはソースコードを公開し、外部の監査も受けている。無料だから中身を読まれる、という作りではない。

一方で、講師の問いにも一理ある。有料なら、会社が続く理由がはっきりしていて、困ったときの窓口もある。ただ、漏えいしたときに何を補償してくれるかは規約次第で、有料だから安心とも言い切れない。何を「保証」と呼ぶかで答えが変わる問いなのだと思う。

どちらを選ぶかより先に、確実に言えることがある。暗号化された保管庫がもし盗まれても、親玉のパスワード（マスターパスワード）が強ければ中身は開けられない。だからマスターパスワードだけは長く、他で使っていないものにする。そして二段階認証は、まずメールアカウントと、パスワード管理ツール本体にかける。メールは、他のサービスのパスワード再設定が届く場所、つまり全部の合鍵の親玉だからだ。

まとめ：明日やること

漏えいのニュースは、もう止められない。でも、自分のドアを付けること、配った合鍵を回収することはできる。AIでアプリを作っている人に、明日やってほしいことを3つ置いておく。

• ログアウトした状態で、アプリの中の画面のURLを直接開いてみる。ログイン画面に戻されなければ、ドアが付いていない

• GitHub に上げたコードの中に、鍵や「.env」という名前のファイルが入っていないか見る

• 会員登録の入力欄を一つ削る。その項目は、本当に要るか

最後に聞いてみたい。あなたがAIに作らせたアプリには、頼んでいない入力欄がありませんでしたか。そしてもう一つ、パスワード管理は無料のBitwardenで十分か、有料の1Passwordに払う価値があるか。使っているツールと理由も、コメントで教えてもらえるとうれしいです。

（作る前の設計に時間の8割を使った話は、こちらに書いた）