「ビディングのソースを増やしたい。でも SDK はこれ以上増やしたくない」。この一見矛盾した要求から、先日 AdMob のサーバーサイド入札パートナーを片っ端から申請する作業を始めました。結果から言うと、申請そのものより「申請して有効化されても、それだけでは1インプレッションも増えない」という線引きを理解することのほうがずっと重要でした。
私は 2014 年から個人でスマートフォンアプリを作り続けていて、壁紙・癒し・引き寄せ系を中心に累計 5,000 万ダウンロードほど、AdMob の月間収益はピーク時で 150 万円を超えていました。その運用の中で何度も痛い目に遭ってきたのが「広告 SDK の数」です。Android 版でメディエーションアダプタを増やすたびに AAB が膨らみ、あるバージョンでは Glide 5.0.5 と AGP 9 系の組み合わせで Android 6.0.1 ユーザー全員がクラッシュする事故を起こしました（coreLibraryDesugaringEnabled true の1行で消えましたが、原因特定に半日溶かしました）。SDK は需要をもたらすと同時に、確実に保守コストとクラッシュ面を増やします。
だからこそ「SDK を増やさずに入札に参加する需要源だけ増やせるなら、それが理想」という発想になります。AdMob のビディングソースには、まさにそのための「SDK 不要のサーバーサイド入札パートナー」という枠が用意されています。今回はそこに 11 社を申請してみて、想定通りに進んだこと・つまずいたこと・最終的に何を採用したかを、判断基準ごと残しておきます。
なぜ「ウォーターフォール追加」ではなく「ビディングパートナー申請」なのか
前提として、私の Android アプリ（綺麗な壁紙 net.dolice.beautifulwallpapers / 浮世絵壁紙 net.dolice.ukiyoe）では、長く使っていた Unity Ads のウォーターフォール・メディエーションが構造的に死にました。Google AdMob 公式が「Unity Ads のウォーターフォール・メディエーションのサポートは 2026 年 1 月 31 日で終了」とアナウンスしており、実際レポートを見ると 7 日間で約 97,000 リクエストに対してインプレッション 0、収益 0 ドルという状態が三週連続で安定再現していました。ウォーターフォールはもう増やしても意味がありません。
新規の需要を入れるなら、選択肢は2つです。
ひとつは Bidding 対応の AdNetwork を SDK ごと統合する道。これは需要が太い反面、アダプタ Pod / Gradle 依存・app-ads.txt・テスト端末での挙動確認まで一式が増えます。もうひとつが、今回の本題である SDK を一切アプリに入れずに、AdMob のサーバー間でだけ入札に参加してもらうサーバーサイド入札パートナー です。後者はアプリ側のバイナリに触れないので、保守面・クラッシュ面のリスクがゼロに近い。SDK 削減方針を取っている私にとっては、まず後者を最大限に増やしてから、本当に必要なものだけ SDK 統合に昇格させる、という順番が理にかなっていました。
申請フローには2つの型がある — doc 型と form 型
AdMob コンソールの「メディエーション → ビディング → 広告ソースを設定」から各社を有効化していくと、申請フローが大きく2パターンに分かれることに気づきます。ここを把握しておくと、1社あたりの所要時間が読めるようになります。
doc 型 は、AdMob 上で「パートナー契約への署名手順」を押すと Google のヘルプドキュメントが開き、ステップ1が自動的に完了済みになるタイプです。あとは AdMob に戻ってステップ2の「確認して同意する」を押すだけで有効化されます。実際のパートナー関係はオフラインで確立される設計で、私が試した中では Improve Digital（Azerion）と Mobfox がこの型でした。数分で終わります。
form 型 は、「パートナー契約に署名する」→「表示して署名する」と進むと各社の外部サイトに飛び、そこでフォーム入力・規約同意・送信まで行うタイプです。送信後に AdMob へ戻り、ステップ2の「確認して同意する」を押します。Chocolate Platform、Nativo、Verve Group、Sharethrough、Yieldmo がこの型でした。pub-0667784050147760 のような publisher ID は Google 側から自動で引き継がれるので、フォームに手入力する必要はありません。
form 型でひとつ実用上の落とし穴があります。reCAPTCHA の種類によって自動化できるかどうかが変わる という点です。Verve のように reCAPTCHA v3（invisible 型）を使っているサイトは、フォーム送信時にスコアリングだけで通過するので一気に完了できます。一方 Sharethrough のように reCAPTCHA v2（チェックボックス型）が出るサイトは、人間がチェックを入れる操作が物理的に必須で、ここだけは自動化に頼らず手で押す必要があります。私はこの運用作業の大半を AI アシスタントに任せていますが、v2 チェックボックスだけは毎回自分の手で通しています。
11社申請した結果 — 有効化・送信・不適格の三層
実際に 11 社を回した結果は、きれいに三層に分かれました。
完全に有効化まで到達したのは Verve Group です。reCAPTCHA v3 を自動通過し、住所入力まで含めてフォーム送信が成功、AdMob 側のステップ2も同意済みになりました。
オフラインでパートナー関係が確立する doc 型で有効化できたのが Improve Digital と Mobfox の2社。AdMob のステップ2まで同意済みです。
フォーム送信は完了したものの先方の処理待ちなのが Chocolate Platform （24 時間以内に連絡が来る旨の明記あり）、Nativo （2 営業日、既存の Outbrain 契約が要件になる可能性あり）、Sharethrough 、Yieldmo の4社。questionnaire 型のものは、先方の審査が通ってから AdMob 側のステップ2が開放される設計でした。
そして、申請にすら進めなかった「不適格」が4社。Nexxen は「Email already exists」で既存アカウントの確認が必要、Rise は法人格（Ltd. / Inc.）が必須で個人事業の私は対象外、MobileFuse と Sonobi は US / カナダ限定でそもそも地域が合いませんでした。MobileFuse は加えて「日次 100 万リクエスト必須」という規模要件もありました。
ここから学べる個人開発者向けの教訓は明確です。サーバーサイド入札パートナーは「誰でも申請できる」わけではない 。法人格・地域・最低トラフィック量という三つのゲートがあり、個人事業かつ地域がアジア圏だと、申請可能なパートナー自体が想像よりかなり絞られます。申請を始める前に、各社の eligibility をざっと確認しておくと無駄足が減ります。
最大の落とし穴 — 「パートナーシップ有効」は「配信可能」を意味しない
ここからが、今回いちばん書き残したかった部分です。
私は当初、AdMob で「パートナーシップ有効」と表示されるパートナーの中に、BidMachine と LY Ads Network 、そしておそらく DT Exchange を「SDK 不要のサーバーサイド入札」だと分類していました。ところがこれは誤りでした。これらは実際には 各社のアダプタ SDK をアプリに統合することが必須 で、AdMob 上の「パートナーシップ有効」という表示は、あくまでアカウント契約が完了したことを意味するだけで、配信可能になったことを意味しません。Moloco と同じ「SDK 必須グループ」です。
つまり、入札パートナーには大きく2種類あります。
第一に、今回 11 社で申請したような 純粋なサーバーサイド入札 。AdMob のサーバーと各社のサーバーが直接やり取りするので、アプリ側のバイナリには一切触れません。有効化＝（app-ads.txt の整備後に）配信可能です。
第二に、「有効化はサーバー側で完結するように見えるが、実配信にはアダプタ SDK が要る」パートナー 。BidMachine / LY Ads / DT Exchange がこちら。AdMob のコンソール上は前者と同じように「有効化」できてしまうので、ここで「もう配信されているはず」と勘違いすると、いつまでもインプレッションが増えない理由が分からず時間を溶かします。
見分け方はシンプルで、そのパートナーの AdMob 統合ガイドに「アダプタ」「Gradle 依存」「Pod」「SDK バージョン」の記述があるかどうか を最初に確認することです。記述があれば、それは SDK 必須です。「有効化できたから配信されるはず」ではなく「統合ガイドにアダプタ座標が書いてあるか」を判断基準にすると、この勘違いは防げます。
SDK を増やさない方針の下で、何を採用し何を見送ったか
ここで冒頭の矛盾した要求に戻ります。「需要は増やしたいが SDK は増やしたくない」。この方針を貫くと、判断は自ずと決まりました。
純粋なサーバーサイド入札の 11 社は、SDK を増やさないので全件採用方針。承認が下り次第、app-ads.txt に各社の seller 行を追記していきます。
一方、アダプタ SDK が必須な3社については、原則見送りです。ただし例外をひとつ設けました。LY Ads Network だけは日本国内の需要を狙って Android 限定のパイロット採用を決めました 。理由は、私のアプリのユーザー基盤が日本に厚く、LY（旧 LINE ヤフー）系の需要は他のグローバル AdNetwork では拾いきれない可能性が高いからです。BidMachine と DT Exchange は、現時点で SDK を1つ増やすコストに見合う固有の需要が見えないため見送りました。
「需要が太いから全部入れる」ではなく「SDK を1つ増やすコストを、その需要が固有に上回るか 」で判断する。これが、12 年の個人開発で何度も SDK 肥大化に苦しんだ末にたどり着いた基準です。AppLovin・Unity・Mintegral を停止してきた流れと同じく、SDK は「足し算」ではなく「常に正当化を求める対象」として扱っています。
LY Ads パイロットの実装手順（Android・BW / UKI）
採用を決めた LY Ads は、近々の Android アップデートに同梱する予定です。アダプタ SDK 必須パートナーを1社だけ入れるときの手順を、再現できる形で残しておきます。
まず AdMob の LY Ads 統合ガイドで、アダプタの Gradle 座標・SDK の同梱要否・認証情報を確認します。次にアプリの app/build.gradle にアダプタ依存を追加します。
// app/build.gradle — LY Ads アダプタの追加（座標は AdMob 統合ガイドの最新版で要確認） dependencies { // 既存の AdMob 本体 implementation 'com.google.android.gms:play-services-ads:23.+'
// LY Ads ビディングアダプタ（メディエーション用） implementation 'com.google.ads.mediation:lyads:1.0.+' } アダプタを足したら、ProGuard / R8 と AAB の検証は新規に書き起こさず、InMobi 統合時に使った検証スクリプト（verify-inmobi-build.sh）を流用します。アダプタ追加で増えがちなのは「リリースビルドだけで起きる R8 の難読化由来 NoClassDefFoundError」なので、./gradlew bundleRelease まで通して実機で広告表示まで確認するのが安全です。Debug ビルドだけで OK と判断すると、本番で初めて壊れます。
そのうえで、AdMob の対象メディエーショングループ（INT、必要なら BNR）に LY Ads のビディングソースを追加します。最後に app-ads.txt の行の要否を確認し、リリース後はクラッシュ率と imp / eCPM を 1〜2 週間監視します。問題なければ他アプリへ展開、駄目なら撤去、という撤退ラインを先に決めておくのがパイロットのコツです。
app-ads.txt は「承認後」に、seller ID を捏造しない
純粋なサーバーサイド入札パートナーで一点だけ厳守すべきことがあります。各社とも承認後に「自社の seller ID（authorized seller 行）」を提供してくる設計 なので、承認前に勝手に行を書いてはいけません。
# 承認後に、各社が指定してきた行を dolice.net/app-ads.txt に追記する # 例（ドメインは確定しているが、ID は各社の指定値を待つ — 下は形式の例示） verve.com, <各社指定のID>, RESELLER, 0c8f5958fc2d6270 improvedigital.com, <各社指定のID>, RESELLER sharethrough.com, <各社指定のID>, RESELLER ありがちな失敗が、ドメインだけ分かっているからと seller ID を推測で埋めてしまうこと。app-ads.txt は「このドメインで自分の在庫を売る権限を持つのは誰か」を宣言するファイルなので、捏造した ID を書くと、最悪その行のデマンドが認証されず無効になります。私は承認メールを受け取ってから、各社指定の DIRECT / RESELLER 行をそのまま転記する運用に統一しました。Cloudflare のキャッシュに乗るので、追記後はパージも忘れずに。
個人開発者がサーバーサイド入札パートナーを増やすときの判断基準
最後に、今回の作業を一枚にまとめておきます。これからビディング需要を増やそうとしている個人開発者の方は、この順番で点検すると無駄が少ないはずです。
まず、増やそうとしている需要源が 純粋なサーバーサイド入札か、アダプタ SDK 必須か を統合ガイドで確認する。次に、自分が 法人格・地域・最低トラフィックの eligibility を満たすか を申請前に確認する。SDK 必須パートナーは「SDK を1つ増やすコストを、その需要が固有に上回るか」だけで採否を決める。そして app-ads.txt は 承認後に、各社指定の行をそのまま 書く。
私自身は今回、純粋なサーバーサイド入札を全方位に広げつつ、SDK 必須枠は LY Ads 1社の日本需要パイロットだけに絞りました。需要を増やすことと、保守可能な状態を保つことは、しばしばトレードオフになります。そのトレードオフを毎回意識的に選ぶこと自体が、個人開発で広告事業を長く続けるための運用設計だと考えています。
まずは自分のメディエーショングループに、純粋なサーバーサイド入札パートナーを1社、申請してみてください。アプリのバイナリに触れずに需要を1つ増やす感覚をつかめば、SDK 統合に踏み切るべきラインも自然と見えてきます。