AIを使えば、予約フォームや会員ページ、業務用の小さなWebサービスを作る選択肢が広がります。ただ、「動くものができた」ことと、顧客の情報を預かって運営できることは別の判断です。
2026年10月20日、ふるさと納税サイト「ふるさとチョイス」を運営するトラストバンクは、不正アクセスによる会員情報の外部流出を発表しました。流出が確認された情報には、氏名、住所、メールアドレスなどとともに、ハッシュ化されたパスワードが含まれています。件数や影響範囲は調査により変わる可能性があるとしています。トラストバンクの発表
同社が公表したのは、ハッシュ化されたパスワードの流出です。自社でもサービスを立ち上げるなら、パスワードをどう守るかに加え、そもそも自社で何を預かる必要があるのか。ここを、開発を始める前に決めておきたいところです。
パスワードを、そのまま保存していないか
「平文で保存する」とは、入力されたパスワードを、その文字列のまま記録することです。保存先を読まれると、パスワード自体も読まれてしまいます。
通常のパスワード認証では、元の文字列を保存する代わりに、専用の処理を施した値を保存し、ログイン時の照合に使います。これがハッシュ化です。元に戻して読むことを前提とする暗号化とは用途が異なります。ただし、流出した値に対してパスワードの候補を次々に試す攻撃は可能なので、「ハッシュ化済み」という説明だけでは、十分な対策かどうかは分かりません。
OWASPは、パスワード保存用のArgon2idなどの方式を案内しています。利用者ごとに異なるソルトという値と組み合わせ、推測の試行に計算時間やメモリがかかる設定にするのが基本です。SHA-256を一度かけただけのような高速なハッシュ処理で済ませないことも重要です。OWASPのパスワード保存ガイド
米国NISTも、盗まれた保存データに対する推測攻撃を想定し、ソルトと適切なパスワード用ハッシュ処理を求めています。なお、ふるさとチョイスの上記発表には、具体的な方式や設定値の説明はありません。保存方法の良否や侵入原因は、この情報だけでは判断できません。NISTのパスワード検証に関する要件
経営者が計算方式を選ぶ必要はありません。開発担当者には、次の説明を求めてください。
自社でパスワードを保存しますか。保存するなら、利用する認証基盤・ライブラリと方式、設定を説明してください。元のパスワードが、保存データ、ログ、通知メールに残らないことも確認してください。
「忘れたパスワードを、そのまま本人に送り直せる」という仕様になっていたら、保存と再設定の仕組みを見直す必要があります。AIに安全かどうかを尋ねるだけで済ませず、実際の設定と保存内容を、認証の実装を確認できる人に見てもらいましょう。
会員登録を付ける前に、登録なしで使えないかを考える
これから作るサービスなら、保存方法を工夫する前に、取得そのものを減らせます。「あとで営業に使えるかもしれない」という理由だけで、名前、電話番号、住所、誕生日まで必須にしないことです。
例えば、料金の概算を出すだけなら、会員登録を設けずに結果を画面に表示できないでしょうか。資料をすぐ閲覧できるようにし、個別相談を希望する人にだけ連絡先を入力してもらう方法もあります。
| 作りたい機能 | 先に検討する設計 |
|---|---|
| 料金の概算・簡易診断 | 登録不要にし、氏名や連絡先を求めない。入力値をサーバーに送らず、ブラウザー内で計算できるか検討する。 |
| 単発の予約 | 継続利用や本人確認の必要性を確かめ、会員登録を必須にしない。連絡に必要な項目を選び、住所などは必要な場合だけ取得する。 |
| 商品の注文 | ゲスト購入を用意できるか検討する。配送先は注文時に取得し、カード番号は決済事業者の入力画面で扱う。 |
| 継続利用する業務サービス | 認証を外部の基盤に任せ、自社には利用者IDと業務に必要な情報だけを持たせる設計を検討する。 |
登録をなくすと、利用履歴の引き継ぎや会員向けの案内が難しくなる場合もあります。会員数を増やすこと自体を目的にせず、継続利用や営業上の価値と、情報を預かる運用負担を比べて決めます。
また、「ブラウザー内で処理する」と説明されていても、解析ツールやエラー収集、AIへの送信で入力内容が外に出る設計なら、情報を持たないサービスとはいえません。入力から保存・外部送信までの流れを確認する必要があります。
認証と決済は、自社で抱え込まない方法を選ぶ
ログインが必要でも、自社でパスワードの保存機能から作るとは限りません。外部の認証サービスや、Googleなどのアカウントを利用するログインを選べば、自社でそのログイン元のパスワードを預からない構成にできます。
ただし、外部ログインを選んだうえで、自社にもパスワード登録を残せば、その保存責任は残ります。メールアドレス、利用者ID、ログイン状態を維持する情報などが自社に残ることもあります。「外部認証だから個人情報はゼロ」とは扱わず、実際に残る項目を確認してください。
決済も同じです。例えばStripeは、カード情報を自社サーバーに通さず、直接Stripeへ送る連携方法を案内しています。決済事業者の画面を使う構成にすれば、カード番号を自社で受け取って保存する範囲を減らせます。ただし、事業者側のセキュリティ対応が不要になるわけではありません。Stripeの連携セキュリティガイド
自社には注文内容、決済結果、顧客との対応履歴などが残ります。認証・決済の外部サービスを選ぶときは、月額・利用量・決済件数に応じた費用に加え、管理者の多要素認証、障害時の対応、利用者からの削除依頼、解約や乗り換え時の扱いを、担当者と確認しておきます。
外部に任せる費用は、自社で実装・更新・監視・障害対応を続ける費用と比べて判断します。初期の開発費だけを比べると、その後の運営に必要な人手を見落としがちです。
保存する情報には、目的・見られる人・削除期限を付ける
業務に必要な情報まで一律になくす必要はありません。配送には住所が必要ですし、問い合わせに返答するには連絡先が要ります。必要な情報については、開発担当者と業務責任者で、次の項目を一枚にまとめてください。
- 何のために使うか：取得する項目ごとに、予約連絡、発送、請求などの用途を決める。
- どこに残るか：サービス本体、認証・決済事業者、メール、管理画面、書き出したファイルなどの保存先を挙げる。
- 誰が見られるか：担当業務に必要な人に絞り、全件ダウンロードなど強い権限を持つ人を決める。
- いつ、誰が消すか：削除の起点と期限、実行担当、処理が失敗したときの確認方法を決める。
保存期間を「とりあえず無期限」にしないことです。例えば予約の連絡先は予約終了後の問い合わせ対応期間と結び付け、継続利用のない情報を残す必要があるか検討します。法令上の保存義務や会計・契約上の必要がある記録は、対象を分けて扱います。
個人情報保護委員会のFAQでは、個人情報保護法に一律の保存期間の定めはなく、不要になった個人データは遅滞なく消去するよう努めると説明されています。何年でも残してよいという意味ではありません。自社の用途に応じて期間と削除手順を決めます。個人情報保護委員会「取得した個人情報は、いつ廃棄しなければなりませんか」
ログ、バックアップ、AIへの入力にも複製を増やさない
サービス本体から消しても、通知メール、開発中の画面キャプチャ、問い合わせ管理用の表などにコピーが残ることがあります。本番の顧客情報を、動作確認やAIへの修正依頼にそのまま使わない運用も必要です。テストには、実在の人と結び付かない架空データを用意します。
エラーの原因を調べるために、フォームの入力内容を丸ごとログへ残す設定にも注意してください。OWASPは、パスワードやアクセストークンなどを原則としてログから除外し、情報に応じて削除やマスキングを行うよう案内しています。ログ自体を止めるのではなく、不正なログインや権限変更など、調査に必要な記録を残しながら機密情報を混ぜない設計にします。OWASPのログに含めない情報のガイド
バックアップについても、保持期間、見られる人、期限後に消える仕組みを決めます。復元した際に、削除済みの利用者情報が再び利用されないようにする手順まで、運用担当者に確認してください。
公開の承認は、「ログインできた」だけで出さない
認証は本人かどうかを確かめる仕組みで、認可は、その人に何を見せてよいかを決める仕組みです。外部の認証サービスを使っても、他人の予約や注文を見られないようにする制御は、自社サービスで確認する必要があります。
開発担当者には、テスト用の利用者A・Bを用意し、AでログインしてもBの情報を閲覧・更新・ダウンロードできないことを、画面とサーバー側の処理の両方で確かめてもらいます。画面でボタンを隠すだけでは足りません。管理者の操作についても、権限と記録を確認します。OWASPのアクセス権限に関するガイド
公開を承認する前に、責任者は次の4点を受け取るようにしてください。
- 保存・外部送信する情報の一覧：取得しない項目も含め、業務責任者が必要性を判断したもの。
- 認証と閲覧権限の確認結果：パスワードの扱い、他の利用者の情報へのアクセス防止、管理者の多要素認証。
- 削除と復旧の手順：本体、ログ、バックアップ、外部サービスを含め、担当者が実行できるもの。
- 運営の担当と予算：更新、監視、問い合わせ、事故時の連絡・停止判断を担う人と、外部サービスを含む継続費用。
AIが生成した実装は、別の確認担当者にも見てもらいます。OWASPも、AIによる承認を人によるレビューの代わりにしないよう案内しています。社内に確認できる人がいなければ、公開前のレビューと公開後の保守を見積もりに含めます。それが難しい段階なら、会員機能を外す、既存の予約・販売サービスを使うなど、預かる情報を減らした構成で始める判断が現実的です。OWASPのAIを使った開発のガイド
開発を依頼するときの最初の指示を、「会員登録も付けてください」から「この機能に会員登録は必要ですか。取得せずに済む情報と、自社で保存せずに済む構成を示してください」に変えてみてください。サービスを作りやすくなった今こそ、預かる情報を選び、その後の管理まで引き受けられる範囲で公開することが大切です。