AdMob メディエーションの優先度調整を Claude in Chrome に任せた 3 週間

5/3 の朝、複数アプリの eCPM が一斉に 2 割落ちました。広告ネットワーク A の単価が日中だけ落ち、夜にかけて戻る。優先度を動かせば拾える下げ幅です。ただコンソールに入って 1 アプリずつ並べ替えていくと、それだけで午前が終わります。結局その日は手をつけないまま暮れました。

拾えたはずの数字を、作業量を理由に見送った。この感触が残ったのが、Claude in Chrome に任せてみようと思った直接のきっかけです。個人開発で運用している以上、月初の数日を丸ごとコンソールに差し出す余裕はありません。

以下は 5/8 〜 5/28 の 21 日間の記録です。うまくいった部分より、任せられなかった線引きのほうに紙幅を割いています。

並べ替えの何が重い作業なのか

先に整理しておくと、メディエーションの優先度調整には性質の違う 2 つの作業が混ざっています。

10 分強のうち、8 割は反映側です。しかも反映側だけがアプリ本数に比例して伸びる。この非対称が、月初に集中して効いてきます。

Claude in Chrome が担当できるのは、まさにこの反映側 — ブラウザの画面を開いて、読んで、操作する — です。判断を任せる話ではなく、判断と反映を切り離す話だと捉え直したところで、設計が一気に素直になりました。

役割分担をどこで切ったか

3 週間運用した枠組みは以下のとおりです。

人間（私）が決めること

• どの eCPM 差分から並べ替えに踏み切るかの閾値（私の運用では前週同曜日比 ±10% を超えた場合のみ）
• 月初の初期優先度（運用方針が大きく変わる場合は、たたき台を手で作る）
• 並べ替え結果のレビューと最終保存ボタンの押下

Claude in Chrome に任せること

• AdMob レポート画面を開き、対象アプリの過去 7 日 × 広告ネットワーク別の eCPM 表を抽出する
• 設定された閾値を超えた組み合わせをリストアップする
• 該当アプリのメディエーション設定画面まで遷移し、新しい優先度の候補をドラフト状態で並べ替えてスクリーンショットを撮る
• 「保存」を押す手前で停止し、私のレビュー待ちのリンクを Slack に投げる

最終保存だけは必ず人間が押す形にしてあります。AdMob の優先度は収益に直接効くため、誤った並びで保存されると数時間単位で取り返しがつかない損失が出ます。不可逆な操作の手前で止める。自動化を進めるうえで、ここは譲れない線でした。

なお、この枠組みはウォーターフォール（従来型のメディエーション）を前提にしています。ビディングに寄せているネットワークは優先度という概念そのものが違うため、対象から外しました。両方が混在しているアプリでは、ウォーターフォール部分だけを抽出対象にする指示を明示的に書いています。書かないと、Claude in Chrome はビディング側の行も素直に拾ってきます。悪気なく拾ってくるぶん、気づくのが遅れました。

プロンプトで効いた 3 つの指定

任せ始めた最初の週は、ドラフトの精度がまるで安定しませんでした。効いた修正は、振り返ると 3 つに絞られます。

1. 遷移経路を毎回ゼロから確認させる

最初は「メディエーション設定画面を開いて」とだけ書いていました。これだと過去の画面構造を前提に動こうとして、少しでも UI が変わると迷子になります。「メディエーション → 広告ユニット → 編集 の順に、各段階で画面上のラベルを実際に読んでから次に進むこと。想定と違うラベルが出たら停止して報告すること」と書き直したあと、迷子は起きなくなりました。

2. 抽出した数字を表として書き出させてから判断させる

並べ替え候補だけを出させると、根拠が追えません。「まず eCPM 表を出力し、そのうえで閾値超過の行を指摘し、最後に並べ替え案を出す」と段階を明示すると、私のレビューが目視 10 秒で済むようになりました。順番が逆だと結論が先に立ち、理由が後付けに見えて、結局すべて確認する羽目になります。

3. 停止条件を「押すな」ではなく「ここで止まれ」と書く

「保存を押さないで」だと、押さないまでも周辺を触ります。「保存ボタンが画面に見えた時点で操作を止め、スクリーンショットを撮って報告する」に変えたところ、挙動が明確になりました。禁止で縛るより、停止地点を肯定形で書くほうが安定する。同じ感触は Claude Code と Claude in Chrome の使い分け — 運用で見えた境界線 を書いたときにもありました。

3 週間で出た数値

5/8 〜 5/28 の 21 日間で、Claude in Chrome がドラフトを上げてきたのは 14 回、そのうち私が承認して保存に進んだのが 11 回でした。3 件は判断保留にして翌日まで様子を見て、結果として 1 件は破棄、2 件は翌日に再評価して承認しています。

承認 11 件の内訳は以下のとおりです。

• 単一ネットワークの順位を 1 段下げただけの小さな調整 — 6 件
• 上位 2 ネットワークの入れ替え — 3 件
• 国別の優先度を新しく分割（日本・米国・その他）— 2 件

体感の eCPM 改善は控えめで、21 日平均で前月比 +4.8% でした。劇的な改善ではありませんが、動かなかったぶんの機会損失を回収したと考えると、運用としては合っています。私の規模では月額の差は 1 万円台です。それ以上に、月初の数日が創作の時間に戻ってきたことのほうが大きい変化でした。

数字の見方として 1 つ補足しておきます。+4.8% のうちどこまでが並べ替えの効果かは、厳密には切り分けられません。同じ期間に AdMob のフロアプライス調整を Claude in Chrome で 3 週間続けた所感 で書いた床値の見直しも走らせていたためです。単独の効果を測りたいなら片方ずつ動かすべきですが、収益を止めてまで測る性質の数字ではないと判断しました。運用の記録としては、この粒度で十分だと考えています。

想定していなかった壁

便利になったぶん、壁もありました。最大のものは AdMob 側の UI 変更への追従です。3 週間のうちに小さなレイアウト変更が 2 回あり、そのたびに Claude in Chrome が並べ替え画面に辿り着けなくなりました。前述の遷移再確認で安定しましたが、AdMob 側のリリースが続く時期は、しばらく手作業に戻したほうが安全だと感じています。動かないときの切り分け手順は Claude in Chrome が思い通りに動かないときのトラブルシューティング にまとめてあります。

もう 1 つは、レポート画面の集計遅延です。当日分のデータは数時間遅れて反映されるため、午前 9 時のタスク実行時には前日分までの数字しか見えません。閾値判定を「前週同曜日比」にしたのは、この遅延を吸収するためです。当日比でやるとノイズが多すぎて、ドラフトの偽陽性が増えました。曜日で需要が動く広告在庫では、前日比よりも前週同曜日比のほうが素直です。同じ理由で、AdMob のフィルレート低下を朝に察知する運用に切り替えて 2 週間 でもフィルレートの判定を曜日基準に寄せています。

3 つ目は、私自身の判断疲れです。ドラフトが Slack に上がってきても、すぐに開いて承認できる時間帯ばかりではありません。1 度、夜に承認を後回しにしたまま翌朝になり、市場が動いて判断材料が古くなってしまったケースがありました。今は、ドラフトを上げる時刻を朝 9 時と夕方 17 時の 2 枠に絞り、その時間帯に承認まで終える運用に変えています。ドラフトは多いほど良い、という発想を早めに捨てられたのは幸運でした。承認できない量のドラフトは、ノイズと変わりません。

同じ枠組みを試すなら

これから同じことを試す方に向けて、私が最初の週にやり直した順番をそのまま書いておきます。

1. まず 1 アプリだけで 1 週間回す。 いきなり全アプリに広げると、UI 変更で全部が同時に壊れます。1 本で遷移が安定してから増やしたほうが、結局は速いです
2. 閾値は緩めから始めて締める。 私は ±5% から始めてドラフトが多すぎ、±10% に落ち着きました。逆順（厳しく始めて緩める）だと、そもそもドラフトが出ないので調整の手がかりが得られません
3. 承認できる時間帯を先に決めてから、実行時刻を決める。 逆にすると必ず溜まります
4. ドラフトと承認結果をあとで見返せるようにしておく。 私は Slack のスレッドをそのまま履歴にしています。自分の判断のブレが見えるので、閾値を動かすときの根拠になります

任せない範囲と、これから取り組むこと

優先度の入れ替え自体は任せられても、メディエーションの根本的な再設計（新規ネットワークの追加、入札方式の切り替え、価格床の見直し）は、しばらく手で続けるつもりです。これらは年に数回のことで、自動化の費用対効果に合いません。さらに、直近の eCPM だけで判断してはいけない場面が混ざりやすく、長期的な事業判断が必要だからです。ネットワークを増やすときの実務については AdMob メディエーション 3 社追加を Claude と進めた実録 に別途書いています。

これから取り組むのは、ドラフト承認時の判断材料を、Claude in Chrome 側から少しずつ厚くしていくことです。たとえば、過去 30 日のフィルレート推移や、競合ネットワークの直近の単価傾向を短い要約として添えてもらえると、私の判断時間がさらに短くなりそうです。半年運用したあと、もう一度同じ枠組みで振り返りを残しておくつもりです。

3 週間で分かったことを一言でまとめるなら、任せられたのは判断ではなく、判断と作業のあいだにあった距離でした。もし今日から 1 つだけ試すなら、全アプリではなく 1 アプリで、閾値 ±10%、朝 9 時の 1 枠から。そこで遷移が安定するかどうかが、広げてよいかの答えになります。

同じように個人で AdMob メディエーションを運用している方の参考になれば嬉しいです。お読みいただきありがとうございました。