信頼を殺す1枚のスクリーンショット

信頼は、スクリーンショットによってよく死にます。

これは侵害報告でもありません。規制当局からの手紙でもありません。「learnings」という言葉で緊急のブランド対応をしている、見事に整えられたポストモーテムでもありません。単に、管理画面にプライベートなプロンプトが映っているスクリーンショット、サポートスレッドに顧客の画像が載っているスクリーンショット、共有ギャラリーに生成された出力が表示されているスクリーンショット、あるいは削除したはずのファイルがURL経由でまだ到達できてしまっているスクリーンショット——それだけです。

スクリーンショットが強力なのは、プライバシーに関する約束を「見える矛盾」1つに凝縮してしまうからです。あなたは「内容はプライベートだ」と言いました。ここにあります。あなたは「削除した」と言いました。ここにあります。あなたは「サポートは見られない」と言いました。ここにあります。まるで家賃を払っているかのように、ダッシュボードに座っています。

AI画像プロダクトは特にスクリーンショットにされやすいです。内容が視覚的だからです。証拠も視覚的です。ユーザーはパケットキャプチャやデータベースのフォレンジックを理解する必要がありません。画面を指して「なぜ私の画像がそこにあるの？」と言えば済むのです。これは、とても短い一文ですが、影響範囲は非常に大きい。

危険な表面（リスクのある場所）は、たいてい普通のものです。管理用ダッシュボード。顧客サポートツール。エラートラッカー。分析イベント。バグレポートに添付されたブラウザのスクリーンショット。Slackのプレビュー。CDNのURL。オブジェクトストレージのコンソール。QAフォルダ。社内ギャラリー。プロダクトチームはそれを「AI画像システム」とは考えていないかもしれませんが、ユーザーは組織図に安心しません。

信頼のための設計とは、決定的なスクリーンショットが存在しうる場所の数を減らすことです。サポートに画像プレビューが不要なら、作らないでください。エラーログに生のプロンプトが不要なら、取り除いてください。生成された出力が納品後に保存される必要がないなら、「将来のプロダクトアイデア」のために残さないでください。将来のプロダクトアイデアこそが、プライバシーの約束を“取り憑かれた家具”に変えてしまう場所です。

コンテンツの可視化が必要な場合は、意図的かつ監査可能にしてください。ユーザーが制御する履歴が本当に必要なこともあります。コンプライアンスのために、エンタープライズの購入者が保持を求めることもあります。安全性のレビューが法的な義務を生むこともあります。いいでしょう。そう言ってください。プロダクトのモデルに組み込んでください。デバッグの都合で偶然同じものを作っておきながら、「スクリーンショットが不公平だ」と振る舞うのはやめましょう。

最も強い信頼姿勢は、アーキテクチャです。たとえ誰かがスクリーンショットを欲しがっても、プロダクトがそれを生成できないようにする——コンテンツが消えている、あるいはそのシステムにそもそも存在していないからです。これは、「スタッフは見てはいけない」というポリシーよりも優れています。ポリシーは重要ですが、「そのボタンが存在しない」というのには、鈍いほどの美しさがあります。

Unexposedでは、コンテンツに依存しない運用記録の言語を使うことで、この罠を避けることを意図しています。サービスは、作業が行われたことを把握する必要があります。しかし、顧客のプロンプト、ソース画像、出力、あるいはキーを、ダッシュボードが気軽に露出できる形で保持する必要はありません。

自分たちのAI画像機能をテストしたいなら、モデルから始めないでください。次の問いから始めましょう——「どんなスクリーンショットがあれば、私たちは嘘つきに見えるだろうか？」

そして、その画面を取り除く。

さらに読む： Unexposed data storage、プロンプト保持なしのプライベート画像生成、プライベートなAI画像ツールを評価する方法。