2026年の春から iOS アプリの大型更新に取り組んでいます。Beautiful HD Wallpapers、浮世絵壁紙アプリ、Relaxing Healing、Law of Attraction Everyday の 4 本で、新 iPhone の解像度対応から Firebase SDK の CocoaPods → SPM 移行まで、ほぼ同時並行で進めてきました。
その中で「広告収益の最適化」として後回しにしていた作業が、AppLovin MAX のメディエーションパートナー追加でした。Unity Ads・Liftoff・InMobi の 3 社を一気に組み込む——文字にすると短いのですが、実際には各社のダッシュボード登録・Pod 追加・W-8BEN 支払い受取用の書類の提出・ATT プロンプトの順序調整と、細かい手順がいくつも重なります。この作業を Claude と一緒に進めながら、ドキュメントには書いていない落とし穴をいくつか踏みました。同じ構成で運用している方の参考になれば、と書き残しておきます。
なぜ今、メディエーションパートナーを 3 社追加したのか
私が個人でアプリ開発を始めたのは 2014 年で、累計の DL 数は 5,000 万を超えています。AdMob 単独で運用していた時期が長く、「ウォーターフォールに複数ネットワークを追加すれば eCPM が上がる」と分かっていても、実際の設定コストを考えると後回しになりがちでした。
転機になったのは AppLovin MAX の「最適化トグル」です。従来のウォーターフォールは floor price を手動で並べる必要がありましたが、最適化トグルを ON にすると eCPM ベースで動的に並び替えてくれます。これなら一度設定してしまえばあとは放置できる——そう判断して、4 月の更新ラッシュが落ち着いたタイミングで本腰を入れました。
4 アプリ全てに同じ構成を入れることで、設定の型が固まれば横展開できます。その設定の型を作るところで、Claude が役に立ちました。
W-8BEN の提出でつまずいた話
Unity Ads・Liftoff・InMobi はそれぞれ独立した広告ネットワークなので、支払いを受け取るためには各社に支払い受取用の書類を提出する必要があります。W-8BEN は非米国人向けの収益受取証明フォームで、提出することで各社からの支払いを受け取れるようになります。
手順自体は難しくないのですが、各社のダッシュボードで「どこから書類提出に進むか」のナビゲーションが少しずつ異なります。Unity Ads はダッシュボードの Finance タブ、Liftoff は設定メニューの深い階層、InMobi は登録完了後のメール案内経由——この微妙な違いを探すだけで時間を溶かしかけました。
そこで Claude に「Unity Ads・Liftoff・InMobi それぞれの W-8BEN 提出フローを教えて」と聞いたところ、各社の最新ドキュメントリンクと手順の概要を整理してくれました。ただし、ダッシュボードの UI は変わりやすく Claude の知識が古い場合もあるので、提示されたリンクをそのまま信用するのではなく、「この画面のこのあたりに該当メニューがあるはず」という方向感を得る使い方が現実的です。
実際に InMobi については、Claude が示したナビゲーション手順と実際の UI が一部異なっていました。それでも「Finance → Tax Information → W-8 Form」という方向を把握していたので、迷わずに辿り着けました。
ATT プロンプトの順序 — 公式が強調していない罠
AppLovin MAX の公式ドキュメントには、ATT（App Tracking Transparency）プロンプトの順序についての記載があります。
// ❌ 問題のある順序（MobileAds 初期化が先）
MobileAds.sharedInstance().start(completionHandler: nil)
ATTrackingManager.requestTrackingAuthorization { status in
// ...
}
// ✅ 正しい順序（ATT プロンプトが先）
ATTrackingManager.requestTrackingAuthorization { status in
MobileAds.sharedInstance().start(completionHandler: nil)
}requestTrackingAuthorization を MobileAds の初期化より前に呼ぶ必要があります。これは iOS 14 以降の仕様で、ATT の承認状態が確定した後に広告 SDK を起動しないと、ターゲティング精度が下がります。
問題は、私の古いコードでは初期化の順序が逆になっているアプリが 2 本あったことです。Claude にコードを見せて「ATT プロンプトと MobileAds 初期化の順序は正しいか確認して」と頼んだところ、すぐに問題を指摘してくれました。
ドキュメントには書いてあることですが、長年運用しているアプリを触るとき「以前動いていたコードだから大丈夫」という思い込みが生まれやすい。そこで Claude に第三者視点で確認してもらうのは、単純ですが効きました。両家の祖父が宮大工だったこともあり、「丁寧に点検してから仕上げる」という習慣は今の開発でも意識しています。Claude にレビューを頼む習慣はその延長にあります。
AppLovin MAX のウォーターフォール — 20 グループ追加の実際
AppLovin MAX では、広告グループ（Ad Unit）ごとにメディエーションネットワークを設定します。私の場合は 4 アプリ × 複数の広告フォーマット（バナー・インタースティシャル・リワード）で合計 20 グループ弱になりました。
Claude に「AppLovin MAX で Unity Ads を 20 グループに追加する最効率な手順は？」と聞いたところ、「MAX のダッシュボードにはバルク編集機能がないので、グループをテンプレートとして CSV エクスポートして差分を確認してから各グループを設定するのが現実的」という回答でした。
実際にやってみると、Bidding 型で追加する場合と固定 CPM 型で追加する場合の挙動の違いが、最初は分かりにくかったです。Bidding 型はリアルタイムオークションに参加するため floor price の指定が不要ですが、ネットワーク側のダッシュボードで Bidding 有効化の手続きが別途必要でした。この点は Claude に確認しながら進めました。
最終的に Unity Ads・Liftoff・InMobi の 3 社ともに Bidding 型で追加し、最適化トグルを ON に設定しました。設定後 1 週間の eCPM 変化はまだモニタリング中ですが、変動はあるもののトータルの収益は上向きに見えています。
4 アプリ同時作業で分かったパターン
4 アプリを同じ構成にする作業を Claude と進めながら気づいたことがあります。
「一番複雑なアプリを先にやる」 という原則です。
私の場合は Beautiful HD Wallpapers を最初に選びました。アプリの規模が大きい分、依存 Pod の数が多く、CocoaPods と SPM が混在している期間があったので、AppLovin MAX SDK の追加でコンフリクトが起きないか確認が必要でした。
Claude に Podfile の内容を貼り付けて「AppLovin MAX と Unity Ads Adapter を追加するとコンフリクトする依存関係はあるか」と確認したところ、既存の Firebase SDK のバージョン制約との兼ね合いを指摘してくれました。事前に分かれば pod install 後に慌てずに済みます。
一番複雑なアプリで手順を固めてから残りの 3 本に横展開する——これが 4 アプリ同時作業の型として機能しました。
広告 SDK の更新は地味だが後回しにすると痛い
AdMob のメディエーションパートナー追加は、ユーザーには全く見えない作業です。でも eCPM 最適化の積み重ねが長期的な収益に効いてきます。個人で複数アプリを運用していると、こういった地味だが重要な作業を後回しにしがちです。
Claude に伴走してもらうことで、各社のドキュメントを並行で確認しながら「次の手順は何か」を整理する認知負荷が下がりました。特に W-8BEN 提出のような行政書類系は、何度も同じ質問をしながら確認できるので助かります。
SDK のバージョン管理・ATT の順序・ウォーターフォール設定・支払い受取用の書類と、種類の異なる作業が並走するときに、Claude を「作業の地図を整理してくれるパートナー」として使うのが今の私の基本スタンスです。
同じ構成で iOS アプリを運用されている方が、この記録から何か一つでも参考にできることがあれば嬉しいです。