データの送信先を定める

二つのデータフローを分ける

Vibe codingは、架空のレコードで業務フローを試す際に役立ちます。会社の実際の情報をツールに入れると、リスクが変わります。アプリにまだ利用者がいない段階でも起こり得ます。

調べるフローは二つあります。開発時のフローには、プロンプト、リポジトリのコンテキスト、添付ファイル、ツールの出力、診断ログが含まれます。アプリ利用時のフローには、利用者のリクエスト、データベース、連携、テレメトリー、バックアップが含まれます。受信者と管理策は、フローごとに異なる可能性があります。

架空の経費精算アプリを考えます。データベースは承認済みのクラウドアカウントで稼働しています。開発者がパーサーを修正するため、実際の申請を支援ツールへ貼り付けました。申請には従業員名、領収書、銀行口座の情報が含まれます。データベースの場所が承認されていても、この別の情報提供が許可されているとは限りません。

経路全体を調べる

機密データを加える前に経路を描きます。各段階で、実際のサービスとアカウントを示します。「enterprise」という製品の表示は、データフロー図の代わりにはなりません。

適用される契約と設定を記録します。必要に応じて、再委託先、削除時の動作、モデル学習に関する条件、国際的なデータ移転を確認します。プライバシーとセキュリティの責任者に、不明点の解決を依頼してください。

GDPRの要件は、処理の状況によって異なります。関連する規定には、データの最小化、処理者との取り決め、セキュリティ、影響評価があります。会社の機密情報には、ソースコードや事業計画など、個人データでない情報も含まれます。規則を確認してください。

有用な架空のテストデータから始める

安全な例にも、実際に近い構造が必要です。氏名、識別子、口座番号を置き換えます。フィールドの欠落、通常と異なる日付、長い説明など、不具合の原因となった条件は保ってください。

本番レコードをコピーして名前を一つ変えただけで、「合成データ」と呼んではいけません。残るフィールドから人を特定できたり、取引の内容が分かったりする可能性があります。スキーマと不具合の条件から、新しいレコードを作成します。

認証情報は、プロンプトやテストデータに含めません。シークレットが必要なタスクでは、アクセスを制限した承認済みの仕組みを使います。「秘密にしてください」という指示では、技術的な境界を強制できません。

検証してから用途を広げる

許可する用途を簡潔に記録します。データの分類、承認したサービス設定、許可する操作、責任者を含めます。有効期限または見直しの条件も示してください。新しいコネクター、モデルへの経路、ログの設定によって、判断が変わる場合があります。

未承認の受信者に情報が届いた場合は、それ以上の提供を止め、インシデント対応手順に従います。何をどこへ共有したか記録します。機密情報を別のチケットやチャットへさらにコピーしないでください。

実務上の目標は、制御された利用です。架空のデータがあれば、素早くアイデアを試せます。処理の範囲を検証すれば、次に会社の業務フローへ進めます。見栄えのよいデモやクラウドのリージョンだけでは、必要な疑問のすべてに答えられません。