試作品へ現実に近いデータを入れると、使い勝手を想像しやすくなります。そのため、手元にある情報をそのまま貼りたくなる場面があります。
けれども、AIとの会話、ソースコード、画面キャプチャ、テストログは、利用するサービス、プラン、組織契約、アカウント設定に応じて保存や共有の扱いが異なります。一度混ざった値を、すべての履歴や連携先から追い出すのは簡単ではありません。
試作の現実味は、実在する情報ではなく、よく設計したダミーデータで作れます。 さらに、APIキーやパスワードなどの秘密情報は、ダミーデータともコードとも別に管理します。
このレッスンの目的
このレッスンを終えると、次の三つを区別できます。
- 画面や機能を試すためのダミーデータ
- 実行環境ごとに変わる設定値
- 公開してはいけない秘密情報
また、架空のデータ一式を作り、AIへ渡してよい部分だけで登録、保存、ログイン画面の練習ができます。
安全な実習は、入力前の分類から始まります。 貼り付けたあとで消すのではなく、最初から持ち込みません。
所要時間の目安は、読了10分 + 実習14分です。
実習14分では、ダミーデータ、認可ケース、期待する拒否結果を設計します。直接URLやAPIを使った実行検証は、後続の認証・権限駅とサーバー・API駅で行います。
概念：データ、設定、秘密を三つに分ける
ダミーデータは、画面やデータベースの振る舞いを試すための架空情報です。名前、メール、題名、日時などの形は本番に似せても、実在する対象と結びつかない値にします。
環境変数は、開発、確認用、本番などの実行環境ごとに変わる設定を、ソースコードの外から渡す仕組みです。すべての環境変数が秘密とは限りませんが、公開可否を意識して扱います。
秘密情報は、漏れると不正利用につながる値です。APIキー、パスワード、署名用の値などが該当します。秘密情報はテスト入力ではなく、権限を持つ実行環境だけが読む設定です。
階層
試作で扱う情報を三層に分離する
画面で使う架空データ、環境ごとの設定、公開しない秘密情報を別の層として管理します。
- LEVEL 1ダミーデータ画面と機能を試す架空情報
- LEVEL 2環境ごとの設定コード外から渡す設定名
- LEVEL 3秘密情報権限のある実行環境だけが読む値
三つの層を分ける理由は、漏れたときの影響と使う場所が違うからです。ダミーデータは画面やテストへ積極的に入れ、正常系と境界条件を何度も再現するために使います。環境ごとの設定は、開発用と公開用で接続先や動作を切り替えるため、コードの外から名前付きで渡します。秘密情報は、その設定の一部であっても、値を表示、記録、共有する対象にはしません。AIへ構造を相談するときは、設定名と用途だけを示せば十分です。実行時には権限を持つ環境が値を読み、画面やログへ返さないことを確認します。この分離ができていれば、ダミーデータを自由に共有しながら、設定変更と秘密の管理を別の手順で扱えます。
試す中身と、動かす設定と、守る値を同じ場所へ置かないことが基本です。
ダミーデータの四条件
実在性がないこと。 実在する氏名、連絡先、識別子を一部だけ変えた値は使いません。
見てすぐダミーと分かること。 sample-reader-01@example.invalid のように、用途と架空性が読み取れる値にします。
境界を試せること。 空欄、長い文字、同じ値、権限の違いなど、正常系だけでなく失敗条件も準備します。
繰り返し作れること。 誰かの記憶に頼らず、同じ初期状態を再現できる一覧や生成手順を残します。
関係
安全なダミーデータの四条件
現実味の中心を実在情報ではなく、架空性、明示性、境界、再現性で支えます。
安全に試せる現実味
- NODE 1実在性がない元の対象を推測できない
- NODE 2ダミーと明白用途と架空性が読める
- NODE 3境界を試せる空欄、長文、権限差
- NODE 4再現できる同じ初期状態を作れる
認証、認可、データ取得を分ける
認証は「誰として操作しているか」を確認します。認可は、認証された人がそのデータや操作を許されているかを判定します。データベースからの取得は、その認可結果を受け、所有者条件を付けて必要な行だけを返します。
認証→認可判定→所有者条件付き取得の順序を、画面表示だけでなくAPI側でも保ちます。ログインできることと、他のアカウントのデータを見られないことは別の確認です。
データフロー
認証、認可判定、所有者条件付き取得を分ける
架空アカウントの本人確認後に権限を判定し、許可された所有者のダミーメモだけを返す流れです。
- 入力元架空アカウントAまたはB
- 処理認証誰として操作するか
- 処理認可判定その操作を許可するか
- 保存先ダミーデータベース所有者付きの架空メモ
- 出力先本人用一覧対応する架空メモだけ
関係
- 架空アカウント → 認証：架空のログイン
- 認証 → 認可判定：本人情報を渡す
- 認可判定 → ダミーデータベース：所有者条件付き取得
- ダミーデータベース → 本人用一覧：許可したメモだけ返す
一覧画面に他人のメモが出ないだけでは不十分です。アカウントAでBのメモの直接URLを開く場合や、BのメモIDを指定してAPIへ取得、更新、削除を要求する場合も、サーバー側の認可判定で他人のデータを拒否します。
実習：安全なダミーデータセットを作る
今回も架空の「まちの読書メモ」を使います。次の内容を dummy-data.md などの作業メモへ書く想定で進めます。実在する情報へ置き換えないでください。
架空アカウントA
表示名: サンプル読者A
メール: sample-reader-a@example.invalid
役割: member
架空アカウントB
表示名: サンプル読者B
メール: sample-reader-b@example.invalid
役割: member
架空メモ1
題名: 星空図鑑A
本文: ダミーの短いメモ
所有者: 架空アカウントA
架空メモ2
題名: 海辺の物語B
本文: 境界確認用の長いダミー文を繰り返す
所有者: 架空アカウントB
データセットは、画面に一件表示するためだけではなく、失敗の境界を安全に再現する計画を作るために用意します。架空アカウントAには正常な短いメモを割り当て、基本の保存と読み出しで期待する結果を書きます。Bには長い本文や同じ題名を割り当て、上限と重複の規則を確認するケースを定義します。AでBのメモIDを指定した場合と、BでAの直接URLを開いた場合は、拒否されることを期待結果にします。題名を空にした場合は、保存せず、入力値を保ったまま修正方法を示す条件を置きます。各ケースの初期値、操作、期待結果を同じ一覧へ残せば、後続駅で実装したあとも同じ条件で検証できます。現実の情報を一切使わなくても、保存、認証、認可、バリデーションの検証計画は具体化できます。
ダミーデータの質は、正常な見本より、再現できる確認条件で決まります。
次に、正常系と境界条件を分けます。
マトリクス
二つの架空アカウントで正常と境界を試す
アカウントAとBの双方で、正常登録と権限分離を同じ観点から確認します。
認可ケースと期待する拒否結果
正常系: Aがメモ1を登録し、自分の一覧で見られる
分離: Aの一覧にBのメモ2が出ない
直接URL: AがBのメモURLを指定しても拒否される
API: BがAのメモIDを指定しても取得、更新、削除を拒否される
空欄: 題名なしでは保存されず、修正方法が表示される
長文: 本文の上限を超えると、値を失わずにエラーを示す
重複: 同じ題名を許可するか、事前に決めた規則どおりになる
秘密情報の代わりに、設定名だけを書きます。
DATABASE_URL=設定先で管理する。値は教材、会話、コードへ書かない
AUTH_SECRET=設定先で管理する。値は画面やログへ表示しない
ローカルの設定ファイルを使う場合も、値を共有文書へ貼りません。.env.example には必要な名前と説明だけを書き、実値は入れません。
実習の成果は秘密の値を用意することではなく、値なしでも構造と確認手順を説明できることです。
正常な結果
次の7項目を自己採点します。
- すべての入力が見てすぐ架空と分かる
- RFC 2606の例示用ドメインなど、実在先へ届かない値を使った
- 正常、空欄、長文、重複の条件を再現できる
- 認証と認可判定を別の確認として記録した
- 一覧と直接URLの認可ケース、操作、期待する拒否結果を定義した
- APIによる他人データの取得、更新、削除を拒否する期待結果を定義した
- 秘密の値がコード、AI会話、画面、ログに現れない
7項目すべてを同じダミーデータで再検証できれば正常です。
よくある失敗
失敗1：実在する情報を少し変えて使う
一文字だけ変えた氏名や、実在する連絡先の一部を伏せた値は、元の対象を推測できることがあります。最初から無関係な架空値を作ります。
失敗2：秘密情報をコードへ直接書く
手元だけのつもりでも、Gitの履歴、コピーした差分、画面共有へ残ります。あとで削除しても、過去の履歴や外部サービスに残る可能性があります。
失敗3：環境変数なら全部安全だと思う
環境変数は受け渡し方法です。ログへ出す、クライアント側へ渡す、公開用の接頭辞を付けるなど、使い方によっては見えることがあります。
失敗4：一つの架空アカウントだけで認証を確認する
ログイン成功は確認できても、アカウント間の分離は確認できません。AとBを用意します。
復旧：混入を疑ったら広げない
秘密情報や実在情報を入力した可能性に気づいたら、まずコピー、共有、公開、追加実行を止めます。値そのものを新しいメモへ転記してはいけません。
次に、どの種類の情報が、どの場所へ入った可能性があるかを記録します。「秘密情報らしき値がAI会話へ入った可能性」のように、値を再掲せず範囲だけを残します。
秘密情報なら、利用中のサービスが定める手順で無効化と再発行を行います。権限がなければ管理者へ連絡します。単に画面から消すだけで終わらせません。
実在情報なら、組織の規程と責任者へ従います。自己判断で隠し続けず、拡散を止めて正しい連絡経路へ渡すことが復旧です。
その後、ダミーデータへ置き換え、履歴、ログ、共有物の影響範囲を確認します。
手順
混入を疑ったときの復旧順序
値を再掲せず、拡散停止から連絡、無効化、置換、影響確認へ進む順序です。
- NODE 1拡散を止めるコピー、共有、追加実行を停止
- NODE 2範囲を記録値ではなく種類と場所
- NODE 3正しく連絡管理者や定められた経路
- NODE 4無効化と置換承認手順で対応
- NODE 5影響を確認履歴、ログ、共有物
安全メモ
秘密情報の値を、教材、テスト、スクリーンショット、課題提出物へ書かないでください。例示には REPLACE_IN_SECURE_SETTINGS のような明らかな説明用文字列を使います。
.env という名前だけで安全になるわけではありません。バージョン管理の対象外であること、権限が適切であること、クライアントへ露出しないことを確認します。
実在情報を使う必要が生じた時点で、この実習の範囲を超えます。 組織のルール、利用サービスの規約、承認された環境を確認してから別の手順として扱います。
成果物
このレッスンの成果物は、次の二つです。
- 二つの架空アカウント、正常データ、境界データを含むダミーデータ一式
- 設定名、公開可否、保管場所、ログへの非表示を記した秘密情報の保管確認表
設定名: AUTH_SECRET
値を書く場所: 承認された実行環境の設定
コードへ書く: いいえ
AI会話へ貼る: いいえ
画面やログへ出す: いいえ
問題時: 追加利用を止め、管理者の手順で無効化と再発行
成果物には秘密の値を含めない。 この一文を確認表の先頭へ書いてください。
用語集
保存できたこと、本人だと分かったこと、操作を許してよいことは、それぞれ別の証拠で確認します。
参考・一次資料
- RFC 2606: Reserved Top Level DNS Names：文書やテストに使う予約済みの例示用ドメインを確認する
- OWASP Secrets Management Cheat Sheet：秘密情報の保管、アクセス制御、ローテーション、監査を設計する
- GitHub Docs: Removing sensitive data from a repository：履歴からの削除だけでは複製やキャッシュへの対応が終わらないことを確認する
- OpenAI: How your data is used to improve model performance：個人向け、Business、Enterprise、API、設定による扱いの違いを、利用前に公式情報で確認する
AIサービスに入力した内容の保存、学習利用、保持、共有は、サービス、プラン、組織契約、アカウント設定によって異なります。「AIだから保存される」「設定を切れば即時に全履歴から消える」と一律に断定せず、利用中のサービスの公式data policyと現在の設定を確認します。
次の駅
企画上の次駅
架空企画では、データ線の「認証・権限駅」へ進む条件が見えました。ただし需要検証を終えていないため、実装着手はまだ保留です。
需要検証と要件定義を通過した後、認証と認可は「認証・権限駅」、直接URLとAPIの拒否は「サーバー・API駅」で実装して検証します。
教材上の次レッスン
次は「止まる基準」です。ダミーデータと秘密情報を分離しても、異常が出たときに変更を続ければ影響は広がります。
操作前に停止条件を決め、止めたあとに確認、連絡、復旧へ進むストップカードを作ります。
今日のまとめ
3行で振り返ります。
- 試作には実在性がなく、見てすぐ架空と分かり、境界を試せるダミーデータを使う
- 秘密情報はコード、会話、画面、ログから分離し、承認された実行環境だけで扱う
- 混入を疑ったら共有と追加実行を止め、値を再掲せず影響範囲と連絡先を確認する