開発者が画像生成APIに求めること

開発者は、画像生成APIに「魔法」を感じる必要はありません。必要なのは、それが「振る舞う」ことです。

最良のAPIは、適切な場所では退屈であるべきです。明確な入力を受け取り、明確な状態を返し、失敗を理解しやすくし、提供側の粗さを補うためにチームが“もう一つのプロダクト”を作り込むことを強いません。

ジョブの状態は明示されるべき

画像生成には時間がかかることがあります。すぐに完了するジョブもあれば、キューに入るジョブもあり、モデルや入力が適切でないために失敗するジョブもあります。

そのため、APIはジョブの状態を明確に公開すべきです：

• accepted
• queued
• running
• completed
• failed

これらの状態があれば、開発者はタイムアウトから推測するのではなく、正直なユーザーインターフェースを作れます。

エラーは問題の近くにあるべき

曖昧なエラーは時間を浪費します。入力が大きすぎるならそう伝えてください。モデルが利用できないならそう伝えてください。生成ワーカーが失敗したなら、単なる「不正なリクエスト」を返すのではなく、それを伝えるべきです。

良いエラーメッセージは、プライベートな内容を公開する必要はありません。失敗している操作を特定できれば十分です。

進捗のストリーミングが役立つ

ポーリングでも動作しますが、進捗ストリームがあると画像生成のワークフローは格段に良く感じられます。ユーザーはジョブが生きていることを確認でき、アプリケーションは出力が届いたときに反応できます。

これは、生成がより大きな流れの一部になっているプロダクトにとって重要です：エディター、ダッシュボード、アセットパイプライン、社内ツールなどです。

APIはデータを尊重すべき

開発者は、プロンプトや元画像がどこへ行くのかも知る必要があります。APIがコンテンツを第三者プロバイダーへ送信するのか、学習のために保存するのか、それは細かな免責事項の中に隠すべきではありません。

統合のプライバシーは、それを支えるAPIのプライバシーと同じ程度にしかなりません。