AIによるAmazon広告運用システム

ここのところ、CassetteOSの開発からちょっと離れて(Twitterもしないで)、Amazonショップ(要するに「しまぱん.COM」)のシステム改善を行っています。

今まで何年もやって来てやっとDXに手を出したという、紺屋の白袴を絵に描いたような展開なのですが、絶大なる成果が出てしまい、何で今までやって来なかったのかと怒りを覚えるくらいの出来です。

と言っても大したことじゃなくて、ログデータをローカルに取得してAIエージェントにかけるシステムを作ったというだけなんですが。

背景

去年のブラックフライデーの前頃にちょっとした事件がありました。某首相の某発言による中国からのデュアルユース品に対する輸出規制です。

いくら拡大解釈しても「しょせんパンティ」ですから、軍事物資でもなければデュアルユース品でもないはずなので無関係そうに見えますが、税関等は同じ施設を通ります。何が起きるかと言えば、検査の厳格化による処理の停滞です。お陰で納期が普段よりちょっと延びてしまいました。と言うか、「なんで今回だけ遅いの？？」「何か事故があった？」と随分悩んでいたのですが、他の話とかから総合して「検査の厳格化による処理の停滞」だという結論に至りました。

弊社は資金があまりないですから、在庫はいつもギリギリです。平均在庫日数はAmazonショップの目安となる90日どころか30日ない商品もあります。

とは言えブラックフライデー前後は商品の回転が良くなりますから、それに合わせて入庫します。かと言って過剰在庫にする余裕もありませんから、必要在庫を複数回に分けてギリギリかつ品切れしないようにというオペレーションにします。そこで売行きから品切れ日を予想して、それに合わせて入庫するような発注にします。カッコ良く言えば「ジャスト・イン・タイム」ですｗ

通常ならこれで良いのですが、例の件で普段よりも納品が遅くなりました。その結果、弊社からFBAへ入庫する前に品切れになってしまい、結果的に品切れの期間ができてしまいました。

まぁここまでは「運が悪かった」と思うしかありません。オマケに予想外に売れてしまったとゆー、本来ならラッキーなイベントもあったわけです。

ところが、売れ筋商品が品切れを起こすと、Amazonではペナルティとなります。何が起きるかと言えば、「Amazonのお勧め」から外れてしまうわけです。しかもその隙に他の業者が同じような商品を激安で出してしまい、「お勧め」がそちらに取られてしまいました。

そんなこんなで、去年はウハウハだった12月の販売実績がガタガタになってしまいました。何とかしなければならない状態になってしまいました。

広告データの可視化

そこでAmazon上にある諸データを取得して、手元で分析可視化はできないものかというアプローチを考えました。この辺のことは、

AIモードは便利

の方でも書いています。あの話の元はこれだったんですねー。

そこである程度のデータを取得するツールを作り、程々可視化ができるようにはなったのですが、社長(mayumi)が「可視化だけではあまり意味がない」ということを言い出しました。

と言うのも、可視化がローカルでできることそれ自体は悪いことじゃないのですが、出来る出来ないというレベルであればAmazon Sellerのダッシュボードでもある程度は出来てします。ローカルで色々できることは便利ではありますが(レスポンスも良いし細かいことができる)、急いで作るという程の緊急性はないというのです。また、それ以前に我々は販売の素人ですから、いくら可視化ができたところで「なんとなく」とか「雰囲気で」ということからの進歩はあまり期待できません。結局従来のやり方から大きな進歩は期待できません。

gemini-cliに食わしてみる

そのうちmayumiがAmazon Sellerのダッシュボードからデータを取って、それをChatGPTにコピペして相談するということを始めました。じっくり見たわけではないですが、どうも有用な指導を受けたらしく、以前よりも確信に満ちた感じで設定をしていました。つまり、AIを使うということに手を出し、それで成果が出始めたというわけです。

そこで例によってAIモードに「gemini-cliを使って広告分析ができないか」という相談をしてみました。

データベース上に、Amazonの売上や広告のログデータがあります。これから、広告を出す戦略を立てるエージェントを作りたい。エンジンとしてgemini-cliを使ってやろうと思うのだけど、どうだろう?

と言うとデータのハンドリングについて難色を示されたので、

データはPostgreSQLに抽出してある。Amazon Ads APIで取得できるデータはここにある。足りなければ、あらためて取得する設定を書けば取得できる。こちらはあまりコードを書きたいとは思ってないけど、書けないわけじゃない。必要ならMCPとか作ることはできる

と言ったところ、いきなり対応が積極的になり始めます。ちなみにMCPはgemini-cliで常用しているものがあって、それは以前Mayumiが自作したものです。

PostgreSQLに抽出されたデータとAmazon Ads APIで取得できるデータに基づいて、分析と戦略立案を行う方法を提案します。 MCP (Model Context Protocol)を活用することで、コードを最小限に抑えつつ、PostgreSQL内のデータをAIに分析させることができます [1]。 PostgreSQLに抽出されたデータとAmazon Ads APIで取得できるデータに基づいて、分析と戦略立案を行う方法を提案します。 MCP (Model Context Protocol)を活用することで、コードを最小限に抑えつつ、PostgreSQL内のデータをAIに分析させることができます [1]。

つまり、PostgreSQLのMCPを入れろということです。

ものは試しと@modelcontextprotocol/server-postgresを入れてみて動かしてみたら、いきなりそれっぽいことを言って来ます。

# Amazon広告戦略エージェント設定
## 1. 役割 (Role)
Amazon広告（Amazon Ads）のデータサイエンティスト兼、運用戦略エージェントです。
PostgreSQL内のログデータを分析し、過去7日間のキャンペーン別パフォーマンスを効率の悪い広告キャンペーンを教えてください。

というプロンプトを入れたところ、

過去7日間のキャンペーン別パフォーマンスを効率の悪い順に並べた結果を以下に示します。

**ACOS算出不能（売上ゼロ）のキャンペーン**
これらのキャンペーンは広告費が発生しているにもかかわらず売上がゼロのため、最も効率が悪いと判断されます。
...

いきなり分析を始めてしまいました。いや、そもそもテーブルの意味とか教えてないし。

意味教えてないのに処理するのは、どうもテーブル名やフィールド名から推論してやっているからのようです。そこでDBのカタログ情報とか別途わかりやすい形にして与えると、もっとマシなことまでやってくれるようになりました。これは「いける」という感じです。

効果

gemni-cliとPostgreSQL MCPを使うと、なかなかいい感じ運用できそうだということがわかりました。そこで取得するデータを増やしつつ、gemini-cliを使うためのプロンプトの強化を行い始めました。

その結果、データ取得の処理を走らせてgemini-cliを走らせて、結果を見て実際のアクションを起こすというフローができました。従来ですと、データを適当に見て、あーでもない、こーでもないとやっていたことを思うと大きな進歩です。

何が良かったかまではわかりませんが、

ECショップ運用のルーチン化
明確な指針を持った運用
科学的運用実績の蓄積

が今さらながら可能になり、確実に効果が出始めました。

IT屋がECサイトやっていて今までこれらがやれてなかったのは、本当に残念なことですねｗとは言え、我々にも言い訳はあるもので、

科学的分析をするにはデータが少ない(ビッグデータと言う程のデータはない)
(適当な運用でも)年率4割以上伸びている
本業じゃないし、他に頑張るべきことがある(うちは専業パンツ屋じゃない)

とかの理由でやってなかったということです。

システムエンジニアとして一歩ズームアウトして見れば、「企業のDXの壁あるある」そのものですね。本当に草しか生えません。

それでも今回は冒頭に書いたような「事件」があったので、「しばらく全振りして頑張ろう」ということにして、DX化をやってみたわけです。その結果、

DX + AIは効果絶大

ということを身を持って知ることができました。また「ビッグデータ」でなければないなりに効果があるということもわかりました。また自社とは言え、DX + AIの事例が一つできました。

エージェントを自作する

他方、gemini-cliを使い続けることには疑問がありました。 gemini-cliを使った人はわかると思いますが、どんなに短いプロンプトを食わせた時でも、処理に結構時間がかかります。具体的には起動の処理が非常に重いわけです。バージョン確認するのが億劫になる程度には起動が遅いです。

どうやらGoogle AIの認証の時間がかかっているようです。通常のGemini APIを使う分にはそこまで遅くはありません

将来的にはより高度な分析やフローの自動化を進めたいと思っているので、ここが律速なのはちょっとなぁという感じです。とは言え、gemini-cliは結構優秀に見えるので、下手に作るよりはそれを利用したいし… と思っていました。

そこでgemini-cliの呼び出しについてもっと軽量化できないかとか常駐化(サーバ化)はできないかとAIモードに色々聞いていたら、

gemini-cliはモデル呼び出しの最適化とかコスト低減の処理はしてない
gemini-cliの優れた能力はモデルとツールとプロンプトの勝利
今回のような使い方をする範囲なら自分で書いても知れている

とか言い出しました。モデル呼び出しの最適化はしているように見えていたのですが、それは処理によって呼び出すモデルが違うというだけであって、動的にどうこうしているわけではないようです。

まぁ今回はgemini-cliの動作そのもはどうでもいいですし、その解釈が多少間違っていても「我々が使う範囲」に限ればこの理解で問題はありません。より詳細が知りたければ、識者に聞くなりコードを読むなりしてください。ここで大事なのは、三番目の「この範囲であれば自分で書ける」ということです。

そこでそんなものかなぁと思い、Vercel AI SDKを使って、簡単なプログラムを書いてみました。仕様という程ではないですが、

プロンプトを注入する
MCPを1つ登録する
LLMを呼び出す

というだけです。

そうすると、確かにgemini-cliを使った時とほぼ同じクオリティの返答が返って来ました。

処理としては起動してAPIを呼ぶだけで余分なことは何もしていませんから、いきなり処理が始まり処理をして終了です。当然ながらgemini-cliを使った時よりはずっと短い時間で結果を得ることができました。単体で実行して喜んでる範囲であればgemini-cliで良いですが、フローに組み込むには直接API呼ぶ方が使いやすいです。

またこの作業のついでにディスコン状態だった@modelcontextprotocol/server-postgresを捨てて、Postgres MCP Proを使うことにしました。私が使った範囲であれば、特に違いはないようです。