プライベート画像生成の開発者ガイド

プライベート画像生成は、1つの機能ではありません。判断の連鎖です。

まずリクエストから始めます。プロンプト、ソース画像、マスク、参照画像、生成された出力、そしてキーをユーザーコンテンツとして扱ってください。つまり、通常のテレメトリよりも狭い経路で扱うべきです。ログ、分析、ダッシュボード、カスタマーサポート画面に、気軽に表示されるべきではありません。

次に、認可とコンテンツを分離します。システムは、そのアカウントがタスクを実行できるか、そして支払いができるかを把握する必要があります。だからといって、課金レイヤーがプロンプトを必要とするわけではありません。コンテンツ非依存の課金は退屈なほど適切です。使用が発生したことは記録しますが、何が生成されたかは記録しません。

次に、処理を短寿命にします。Generation Session は、タスクを処理して結果を返すために存在し、永続的な作業場になるべきではありません。ジョブ実行中に一時ファイルが必要になる場合があります。それらは、ジョブ終了後にプロダクト状態として残らないようにします。

観測性（observability）もコンテンツ非依存に保ちます。必要なのはメトリクスです。キュー時間、モデル性能、失敗タイプ、キャパシティ、コスト、そしてヘルスです。ほとんどの運用イベントでは、生のユーザーコンテンツは不要です。必要だと思うなら、それがシステムのデバッグのためなのか、それとも顧客コンテキストを抱え込むためなのかを問い直してください。後者のほうが簡単だからです。

リトライには注意してください。失敗したジョブがプロンプトをログに漏らしたり、ソース画像を残したりしてはいけません。リトライシステムは有用ですが、成功したジョブと同じコンテンツ境界を尊重する必要があります。

履歴を提供するかどうかを決めます。ギャラリーを提供するなら、その旨を明確にしてください。提供しないなら、それを機能として扱います。ギャラリーなしのアーキテクチャは、出力を返して保持しないため、ゼロ保持の約束に合わせやすくなります。

非専門家向けにドキュメントを書きます。「密封されたリクエスト（sealed request）」は、それが何を守り、何を守らないのかをユーザーが理解できる場合にのみ有用です。コンテンツがどこへ行くのか、何が残るのか、オペレーターが何を見られるのかを説明してください。

開発者ガイドが本当に言いたいことはこれです。プライベート画像コンテンツが存在しうる場所の数を減らし、残った経路を説明しやすくすることです。

さらに読む： Getting started、How Unexposed works、Unexposed data storage。