Googleが「The Small Brief」というイニシアチブを発表した。
Jayanta JenkinsやSusan Credleといった広告業界のレジェンドたちが、GoogleのAIクリエイティブスタジオ「Flow」を使って中小企業の広告を作るプロジェクトだ。
Storywood FarmやSouth Ferryといったローカルビジネスのために、スタジオクオリティのキャンペーンを仕上げるらしい。
「広告の話か、自分には関係ないな」と最初は思った。
でも読み進めると、自分が最近触っているLLM周りの設計と重なる部分が多くて、少し立ち止まってしまった。
記事の中で気になったのは、クリエイターたちにFlowへの「unlimited access」が与えられたという部分だ。
これってAPIコスト設計の観点から見ると、かなり興味深い判断だと思う。
プロのユーザーに制限なく触らせて、どんなプロンプト設計やワークフローが生まれるかを観察する。
そこから得られるデータは、モデル改善にも機能設計にも使えるはずで、Googleにとっても単なる広告PR以上の意味がある。
自分が個人開発でGeminiやOpenAIのAPIを触るとき、真っ先に気にするのがトークンコストだ。
どうしても「なるべく短いプロンプトで」「出力を絞って」という方向に最適化してしまう。
でもFlowのこの設計思想は逆で、「まずリッチに使わせて、どう使うかを見る」という発想に近い気がする。
The Small Briefのプロジェクトは6月に最終キャンペーンを公開する予定になっている。
そのプロセス公開も含まれるらしいので、実際にどんなプロンプト構造や生成フローを使ったかが見えてくるかもしれない。
そこは素直に楽しみにしている。
自分が最近考えているのは、LLMをプロダクトに組み込むときの「ユーザーへの自由度の設計」だ。
制限を厳しくすればコストは下がるけど、ユーザーが本来やりたかったことを潰してしまうことがある。
Flowが広告のプロに無制限アクセスを渡したように、「まず制限を外して使ってもらう」フェーズを意図的に作るのは、プロダクト設計として理にかなっている。
自分のコードで言うと、LLMへのリクエスト部分にレート制限をガチガチにかけるより、まずログをちゃんと取って実際の使われ方を把握する方が先だと思い始めている。
こういう「観察ファースト」の姿勢、Googleがレジェンドクリエイターにやらせていることと本質的には同じだと感じている。
Flowのプロセス公開が6月に来たら、プロンプト構造と生成フローの部分をちゃんと読み込んでみるつもりだ。
自分のLLM周りの設計に引きつけて使えるものがあるか、確認してみたい。
Jayanta JenkinsやSusan Credleといった広告業界のレジェンドたちが、GoogleのAIクリエイティブスタジオ「Flow」を使って中小企業の広告を作るプロジェクトだ。
Storywood FarmやSouth Ferryといったローカルビジネスのために、スタジオクオリティのキャンペーンを仕上げるらしい。
「広告の話か、自分には関係ないな」と最初は思った。
でも読み進めると、自分が最近触っているLLM周りの設計と重なる部分が多くて、少し立ち止まってしまった。
Flowが「無制限アクセス」で渡された意味
記事の中で気になったのは、クリエイターたちにFlowへの「unlimited access」が与えられたという部分だ。
これってAPIコスト設計の観点から見ると、かなり興味深い判断だと思う。
プロのユーザーに制限なく触らせて、どんなプロンプト設計やワークフローが生まれるかを観察する。
そこから得られるデータは、モデル改善にも機能設計にも使えるはずで、Googleにとっても単なる広告PR以上の意味がある。
自分が個人開発でGeminiやOpenAIのAPIを触るとき、真っ先に気にするのがトークンコストだ。
どうしても「なるべく短いプロンプトで」「出力を絞って」という方向に最適化してしまう。
でもFlowのこの設計思想は逆で、「まずリッチに使わせて、どう使うかを見る」という発想に近い気がする。
LLMを「ツール」として設計するときの視点
The Small Briefのプロジェクトは6月に最終キャンペーンを公開する予定になっている。
そのプロセス公開も含まれるらしいので、実際にどんなプロンプト構造や生成フローを使ったかが見えてくるかもしれない。
そこは素直に楽しみにしている。
自分が最近考えているのは、LLMをプロダクトに組み込むときの「ユーザーへの自由度の設計」だ。
制限を厳しくすればコストは下がるけど、ユーザーが本来やりたかったことを潰してしまうことがある。
Flowが広告のプロに無制限アクセスを渡したように、「まず制限を外して使ってもらう」フェーズを意図的に作るのは、プロダクト設計として理にかなっている。
自分のコードで言うと、LLMへのリクエスト部分にレート制限をガチガチにかけるより、まずログをちゃんと取って実際の使われ方を把握する方が先だと思い始めている。
// 雑に制限かけるより、まずログから実態を把握する
const result = await callLLM(prompt);
logUsage({ tokens: result.usage, userId, feature: 'ad-copy-gen' });こういう「観察ファースト」の姿勢、Googleがレジェンドクリエイターにやらせていることと本質的には同じだと感じている。
Flowのプロセス公開が6月に来たら、プロンプト構造と生成フローの部分をちゃんと読み込んでみるつもりだ。
自分のLLM周りの設計に引きつけて使えるものがあるか、確認してみたい。