OWASPの「LLMアプリケーションのTop 10」2025年版は、生成AIアプリケーションのリスクを10項目に分類しています。AIが書いたコードが動いても、データの行き先やメールの宛先まで安全だとは限りません。

判断：実在のユーザーや同僚のメールアドレス、認証コード、個人情報をデモのテストに使わないでください。 合成テストデータと隔離した受信経路を使い、ログを必要最小限にします。公開前には、実在の宛先へ誤送信されないことを設定と実動作の両方で確かめます。

この記事は、AIコーディングツールで登録・認証・通知機能を作り、デモを控えている個人開発者向けです。
小さな社内ツールを作る非技術チームや、デモ環境とメールフローを確認するQA・プロダクト担当者にも役立ちます。

最終更新日：2026年10月20日。 生成AIのリスクはOWASPの資料、ログの扱いはOWASPのログ記録ガイド、AI開発の動向はSonarの2026年開発者調査を確認しています。調査は動向の背景情報であり、個人情報の漏えい率や個別のコードの安全性を示すものではありません。

データを用意する前に、環境ごとの境界を決める

まず、デモ、ステージング、本番がそれぞれ何に接続しているかを書き出します。データベースだけでなく、メール送信先、送信サービスの認証情報、ログやエラー追跡先も対象です。AIが生成した設定値やサンプルコードをそのまま流用すると、デモから本番のメール設定を呼び出す経路が残ることがあります。

「実在のユーザー情報を使わない」「同僚の個人アドレスを借りない」「本物の認証コードを資料や画面例に載せない」といったチームのルールを先に決めます。デモデータが本番環境へ同期されないことも、設定や処理経路で確認してください。合成データに置き換えるだけで、すべてのプライバシー要件や法的な義務を満たせるわけではありません。

前半の判断には、次の比較が使えます。評価は、本稿で示す「実在情報の露出」「誤送信の影響」「あとから管理しやすいか」という運用上の観点に基づいています。

データ・受信方法 実在情報の露出 誤送信時の影響 運用上の評価
実在ユーザーや同僚のメールアドレス 高い 本人への送信や情報露出につながる デモには不適
架空の名前とテスト専用アドレス 低くしやすい 受信先を管理できる 第一候補
実在アドレスを使った加算アドレス 実在の受信箱と紐づく 本人の受信箱に届く可能性がある デモ用途では慎重に判断
受信しない固定値だけのテスト 低い メール本文や到達を確認できない 送信処理の単体確認向け

合成テストメールを使うときは、実在しそうな他人のアドレスを適当に作らないでください。合成データは、架空の名前・プロフィールと、チームがテスト用として管理する受信先を組み合わせます。実際に受信が必要な場合は、テスト専用の受信経路を用意し、どの環境から届くメールか判別できるようにします。

初回実行前に、合成データとメール設定をそろえる

AI生成のデモを実在のメールアドレスで試してよいか

原則として使わないでください。実在アドレスで試すと、認証メールや通知が本人に届くだけでなく、アドレスがログ、スクリーンショット、AIツールに渡したプロンプトへ残る可能性があります。AI生成コードの説明文に「テスト用」と書かれていても、実際の環境変数や送信設定が隔離されている証拠にはなりません。

実在の受信箱を使う必要がある場合は、デモで本番データや実在の利用者に触れないことを確認し、組織の手順に従って許可とアクセス範囲を管理します。テストのために本番の利用者へメールを送る設計は採用しません。

初回実行の前に、次の項目をそろえます。

  • 名前、プロフィール、アカウント内容を架空の値に置き換える。
  • 実際に受信確認が必要なら、テスト専用アドレスを使う。
  • サンプル、プロンプト、リポジトリ、画面キャプチャに実在のメール本文を貼らない。
  • デモ用の送信設定が本番の認証情報や宛先を参照しないことを確認する。
  • テストデータが本番へ同期される経路がないか確認する。

個人情報保護の観点では、「架空の値にしたから安全」と決めつけないことが重要です。たとえば、実在ユーザーの文章を少し書き換えただけのデータは、本人を推測できる情報を含む場合があります。テストデータの作り方やリスク評価は、組織のルールと対象地域に合わせて別途確認してください。NISTの差分プライバシーガイドも、プライバシー保護の評価を検討する際の参考資料です。

送信テストでは、宛先・本文・失敗経路を確認する

テストメールの認証コードや個人情報はどう扱うか

認証コードやパスワード再設定用リンクは、使い捨てのテストデータとして扱い、実在ユーザーのものを再利用しません。テスト用のメール本文にも、実在の氏名、連絡先、注文内容などを含めないでください。検証が終わったら、共有資料やログに残したコードやリンクを削除するか、チームの手順に従って閲覧を制限します。

送信テストでは、正常に届くケースだけを見て終わりにしません。認証失敗、期限切れ、再送、送信失敗も試し、各経路で本番宛ての設定が使われないかを確認します。本文に本番データが混ざらないこと、リンクがデモ環境のドメインを指すこと、送信処理の再試行が実在ユーザーへの重複送信を起こさないこともチェック対象です。

メールアドレスの形式確認や認証フローを実装するなら、OWASPのメール検証ガイドも参照してください。形式が正しいかを確認する処理と、本人がメールを受け取れることを確かめる処理は別です。テストでは、どちらを検証しているかを切り分けます。

デバッグ中は、ログと共有画面から情報を減らす

メールアドレス、認証コード、再設定リンクは、エラー調査のログや画面共有にも残ることがあります。障害の切り分けに必要な情報だけを保存し、メールアドレスを必要に応じてマスクし、トークンや本文を記録しない設定を確認します。OWASPのログ記録ガイドは、記録対象やアクセス管理を設計する際の参照先になります。

共有画面、デモ動画、スクリーンショットも見直してください。メールアドレスだけでなく、ブラウザーの通知、ターミナル出力、エラー追跡画面に認証コードや個人を識別できる情報が表示されていないか確認します。調査に不要になった記録は、チームの手順に沿って削除し、閲覧できる人を絞ります。

公開前に、送信経路を条件分岐で判定する

公開演示前のメール誤送信チェックは、コードレビューだけでは足りません。設定値と実際の受信先を照らし合わせ、デモ操作が自家製品のテスト範囲内で完結することを確かめます。AIが生成した説明やコメントだけを根拠に、安全と判断しないでください。

次の条件分岐で、演示方法を決めます。

  • 送信先がテスト専用で、デモから本番の認証情報や利用者データに到達できないなら、合成データを使って実メールの送受信をテストします。
  • 受信は不要で、テンプレートや処理分岐だけ確かめたいなら、実際に送信しないテスト経路を選びます。
  • 宛先や環境変数が不明、または本番設定と分離できないなら、送信テストを止め、固定値やモックによる確認へ戻します。
  • 実在ユーザーへの誤送信を排除できないなら、公開デモでメール機能を有効にしません。

公開前には、生成コードの初期宛先、環境変数、送信の有効・無効を切り替える設定、リンク先のドメイン、例外時や再試行時の動作を人が確認します。最後に、実在ユーザーへ送らない条件で、自家製品の登録・認証・通知フローを一通り実行します。自家製品のメールフローを確認する際は、テスト対象と受信先を分離し、送信が本番設定に到達しない手順を用意してください。

演示後に、テスト記録と一時データを片づける

演示が終わったら、テスト用アカウント、受信記録、認証コード、ログ、共有用の画像を一覧にして、削除またはアクセス制限の対象を決めます。法律や組織の要件を確認せず、保存期間を一律に設定しないでください。

管理を曖昧にしないため、チームでは次を記録します。

  • 担当者： テストデータとログを清掃する人。
  • 実施条件： 演示終了、検証完了、環境の再利用など、清掃を始めるタイミング。
  • 対象： アカウント、受信記録、ログ、スクリーンショット。
  • 確認記録： 削除やアクセス制限を実施したことを確認できる記録。
  • 再確認： 共有環境にコードや個人を特定できる情報が残っていないかの確認。

テスト環境の受信経路やログ設定に不安が残る場合は、メール送信の問題を開発者向けに切り分ける診断ガイドを使って確認項目を整理できます。