Cannes Lions でDigitas北米CEOのAmy Lanziがしゃべった話、The Vergeのpodcastで聴いた。「AIが広告を救う、みたいな話はoverpromiseだ」というやつ。広告業界の話なのになぜかめちゃくちゃ刺さった。
PublicisがCannes前にAIについての「false promises」を列挙した広告を出したらしい。その内容に自分もうなずく部分があった。Metaとかの大手プラットフォームが「AIでどんどん広告を生成します」と言ってるのと、LLMのAPIを使ってコードを量産する自分の状況が、なんとなく重なったからだ。
量産できるから価値がある、と信じてた時期
自分がLLMのAPI周りを本格的に触り始めたのは半年くらい前。とりあえずOpenAIのAPIを叩いてslack botを作って、「えぐい、なんでも生成できるじゃん」と感動した。その後はチームの小さな自動化タスクにもLLMを突っ込んでみた。
その頃の自分のコードはこんな感じで、system promptもほぼ丸投げだった。
curl https://api.openai.com/v1/chat/completions \\
-H 'Authorization: Bearer $OPENAI_API_KEY' \\
-d '{\"model\":\"gpt-4o\",\"messages\":[{\"role\":\"system\",\"content\":\"何でもやる\"}]}'とりあえず動かしてみた段階なので、これでよかった。でも数週間後にトークンのコストが予想の3倍くらい来てハマった。
LLMを使う目的を自分で言語化できてたか
Amyのインタビューで印象的だったのは「CMOという役職はもう終わった」という発言だ。自分の仕事はdata and analyticsを使ってビジネスのresultを出すことだ、と言い切ってた。ポジションの名前じゃなく、何をアウトプットするかで自分を定義してる。
これ、自分がLLMを使うときの設計判断にも言える話だと思った。「LLMを使ってます」じゃなくて、「このタスクのどのステップにLLMを挟んだら精度が上がるか」を先に考えてたか。正直、半年前の自分はできてなかった。
たとえばPR reviewの自動コメント生成をLLMでやろうとしたとき、最初はdiffをまるごと渡してた。当然コストが爆発する。ちょっと考えれば、変更行だけフィルタしてからLLMに渡せばいい。
# github actions の一部
steps:
- name: filter changed lines
run: git diff HEAD~1 --unified=0 | grep '^[+-]' | grep -v '^---\\|^+++' > diff_filtered.txt
- name: call llm api
run: python review.py diff_filtered.txtこういう当たり前の前処理をさぼると、token消費が3〜5倍になる。Amyが言う「AI万能論はoverpromise」というのは、自分のコストが爆発したあの瞬間と同じ構造だと思う。
「creatorが自分をad agencyと呼ぶ」現象から思ったこと
インタビューでもう一個おもしろかったのは、Cannesに集まったクリエイターたちが自分をmarketerと名乗り始めてるという話だ。大きなクリエイターはほぼ全員自分のプロダクトをlaunchしてる。Amyはそういうクリエイターにはoperationalなscaleが必要になると言ってた。
これ個人開発視点でもリアルな話だ。個人でツールを作って公開し始めたら、今度は課金管理・サポート対応・ドキュメント整備が発生する。コードを書く時間より、それ以外が増える。
今自分が作ってるslack向けのちょっとしたOSSも、starが30を超えた辺りからissueが飛んでくるようになった。LLMでissueへの初期回答を自動化しようか検討中だ。ただAmyの話を聴いたあと、「LLMに任せたらissue対応の質が上がるのか、それとも量をさばけるだけか」を先に考えようと思い直した。
よく使うlibrary選定でも同じだ。最近langchainからlitellmに乗り換えたのは、abstraction layerが薄い方がコスト計算しやすかったから。神ツールかどうかより、自分のユースケースに合ってるかを確認する順番を守った方がいい。
Amyが言う「AIに過大な期待をするのは危険だ」というのは、エンジニア的に訳すと「目的関数を定義してからツールを選べ」ということだ。広告業界もLLM活用も、構造は変わらないと気づいた。