モバイルゲーム向け2大メディエーションプラットフォーム
2026 年にモバイルゲームを運営しているなら、メディエーションの選択肢はおそらく Unity LevelPlay（旧 ironSource。Unity と ironSource の統合後に改称）と AppLovin MAX（AppLovin が MoPub の市場的地位を引き継いで構築したメディエーション層）の 2 つに絞られます。両者で世界中のモバイルゲーム広告収益の大半が仲介されています。
どちらを選ぶべきかは簡単ではありません。いずれも成熟したフル機能のプラットフォームで、強力な入札対応と幅広いネットワーク連携を備えています。最適解は、あなたのゲームポートフォリオ、チームの体制、地域分布、既存のネットワーク関係によって変わります。本比較では重要な観点を余すところなく解説します。
入札対応とオークションの仕組み
Unity LevelPlay
Unity LevelPlay は、アプリ内入札（bidding）と従来のウォーターフォールを組み合わせたハイブリッド型のオークションを採用しています。入札対応ネットワークがリアルタイムで競り合い、勝者の入札額がウォーターフォールのラインアイテムと比較され、最終的な勝者が決まります。LevelPlay は Meta Audience Network、Google AdMob bidding、Pangle、Mintegral、そしてもちろん Unity 独自の需要を含む主要需要ソースの入札に対応。ironSource 時代から入札基盤は大きく成熟し、現在では大半のインプレッションがウォーターフォールより入札で処理されています。
AppLovin MAX
MAX は、オール入札モデルへの移行を積極的に推進してきた代表的なメディエーションです。LevelPlay と同様、リアルタイムで入札者が競り合うハイブリッドオークションを実行し、勝者の入札額をウォーターフォールのインスタンスと比較します。MAX も同等レベルに幅広いネットワークの入札をサポート。AppLovin 独自の需要（AppLovin Exchange 経由）は深く統合され、プラットフォーム内の勝ち入札の相当部分を占めることが少なくありません。
結論
2026 年時点で両プラットフォームの入札機能は概ね同等です。意味のある違いはオークションの仕組みではなく、それぞれが持つ独自需要にあります。Unity LevelPlay は Unity Ads の需要への最適化されたアクセス、MAX は AppLovin 需要への最適化されたアクセスを提供します。いずれも巨大な需要ソースであるため、あなたのアプリと地域ミックスにおいて、どちらの独自需要がより高いパフォーマンスを示すかが焦点です。
ネットワークアダプターと需要カバレッジ
Unity LevelPlay
LevelPlay は Meta、AdMob、AppLovin（はい、LevelPlay 上で AppLovin を需要ソースとして利用可能）、Pangle、Mintegral、Vungle/Liftoff、Chartboost、InMobi、Digital Turbine、Fyber など 15 以上の広告ネットワークに対応するアダプターを備えています。Unity Ads ネットワークはネイティブ統合され、設定不要です。
AppLovin MAX
MAX も同等のネットワークアダプターをサポートしています：Meta、AdMob、Unity Ads（MAX 上で需要ソースとして利用可能）、Pangle、Mintegral、Vungle/Liftoff、Chartboost、InMobi、Verve、Yandex など。AppLovin Exchange の需要はネイティブに統合されています。
結論
ネットワークのカバー範囲は実質的に同等です。両プラットフォームとも主要ネットワークをすべてサポートし、アダプターの品質も同等水準です。重要なポイントは、自社プラットフォームの独自需要は、競合のアダプター経由よりもネイティブ環境でわずかに良い成績を出しやすいという点です。つまり Unity の需要は LevelPlay 上で、AppLovin の需要は MAX 上で数ポイント良くなる傾向があります。
SDK サイズと導入の複雑さ
Unity LevelPlay
LevelPlay のコア SDK はアプリのバイナリに約 2〜3 MB を追加します（プラットフォームにより異なる）。ネットワークアダプターを一通り入れると、統合するネットワーク数に応じて合計オーバーヘッドは 8〜15 MB に達することがあります。Unity エンジンのゲームでは LevelPlay 用プラグインにより導入はスムーズ。ネイティブの Android/iOS アプリでは手作業がやや増えますが、ドキュメントは整備されています。
AppLovin MAX
MAX のコア SDK も同程度のサイズ（2〜3 MB）です。アダプターを含めた総フットプリントは LevelPlay と同等。MAX は Unity エンジンとネイティブ開発の両方に対して、メンテナンスの行き届いたプラグインとドキュメントで強力な導入支援を提供します。AppLovin ダッシュボードの MAX 導入ウィザードは、選択したネットワークに合わせた設定コードを自動生成する便利な機能です。
結論
SDK のサイズと導入の複雑さは決定的な差ではありません。どちらも十分に成熟しており、経験のあるモバイル開発者なら 1～2 日で統合できます。Unity エンジンで開発している場合は、共通エコシステムの恩恵で LevelPlay の方が導入がわずかにスムーズです。ネイティブ開発では両者ほぼ同等です。
レポーティングとアナリティクス
Unity LevelPlay
LevelPlay は Unity ダッシュボード上で、広告ユニット、ネットワーク、国、フォーマット、期間ごとの詳細なレポートを提供します。ユーザーレベルの分析や LTV モデリングに使えるインプレッション単位の収益データ（ILRD）も提供します。レポーティング API は堅牢でドキュメントも充実しており、自社の分析基盤に取り込みやすい設計です。
AppLovin MAX
MAX のレポートも同等の粒度で、ネットワーク、国、フォーマット、広告ユニットの切り口を提供。ILRD にも対応。MAX ダッシュボードには Compare というユニークな機能があり、ネットワークや期間をまたいだ eCPM を視覚的に比較できます。レポーティング API は明快で積極的にメンテナンスされています。
結論
レポーティング機能は拮抗しています。視覚的なクイック分析には MAX の Compare が便利。Unity の広範なアナリティクスエコシステムと連携する LevelPlay は、すでに Unity の他サービスを使っている場合に価値を発揮します。決定的な優位はありません。
A/B テスト
Unity LevelPlay
LevelPlay には A/B テストのフレームワークが組み込まれており、異なるウォーターフォール構成、フロアプライス、ネットワーク設定を統計的有意性の追跡付きで相互比較できます。トラフィック配分をテスト群間で割り当て、結果をリアルタイムで監視可能。外部ツールの必要性を下げる実用的な機能です。
AppLovin MAX
MAX もウォーターフォール構成向けに同等の A/B テスト機能を提供。トラフィック分割やリアルタイム結果など機能性は同等です。両プラットフォームとも、入札とウォーターフォールの比較、異なるフロア設定、ネットワーク組み合わせの検証が可能です。
結論
いずれも十分な A/B テスト機能を備えています。専用の実験プラットフォームほど高機能ではありませんが、標準的な収益化最適化には十分です。
ウォーターフォール vs 入札：移行をどう扱うか
業界は 100% 入札へと向かっていますが、移行はまだ完了していません。一部ネットワークは全プラットフォームで入札を未対応で、最大限の需要カバレッジにはウォーターフォールのラインが依然として必要です。
LevelPlay と MAX はハイブリッドモデルを適切に扱います。実務上の差は、手作業のウォーターフォール管理がどの程度必要か。四半期ごとに入札対応ネットワークが増えるにつれ、両者ともウォーターフォール管理の手間は減っています。それでも特定ネットワークとの関係上、ウォーターフォール設定が必要な場合には、両プラットフォームとも対応可能です.
注意： 入札主体の世界になってもウォーターフォール管理は消えません。フロア価格の最適化、非入札インスタンスのネットワーク優先度、広告ユニットの設定などは引き続き能動的な管理が必要であり、マネージドサービスと組む価値が大きい領域です。
ゲーム特化 vs 一般アプリ対応
Unity LevelPlay
LevelPlay の出自は明確にゲーム領域です。ironSource によりゲームパブリッシャー向けに構築され、Unity（ゲームエンジンの会社）に買収され、現在も主にゲーム用途に最適化が続けられています。広告フォーマット、ネットワーク提携、最適化アルゴリズムは、ゲーム収益化のパターンに合わせて調整されています。ゲームパブリッシャーにとっては明確な強みです。
AppLovin MAX
MAX も AppLovin のゲームスタジオ群と MoPub の買収を通じて強いゲームのルーツを持ちます。ただし AppLovin は非ゲーム領域への拡張により積極的です。MAX はユーティリティ、コンテンツ系など非ゲームカテゴリでも利用が広がっています。ゲームと非ゲームの両方を含むポートフォリオなら、MAX は一つのプラットフォームで柔軟に対応できる選択肢になり得ます。
Google Ad Manager と併用する場合
Google Ad Manager を主要アドサーバーとして利用するパブリッシャーにとって、両メディエーションは GAM のウォーターフォール内で需要ソースとして機能でき、置き換える必要はありません。
- GAM × LevelPlay： GAM 設定内で LevelPlay をメディエーショングループとして統合し、GAM が LevelPlay 仲介の需要と他の GAM ライン間を裁定できるようにします。
- GAM × MAX： 同様に、MAX の需要は SDK 入札またはウォーターフォールのラインとして GAM に統合できます。
RevenueFlex があなたの GAM ウォーターフォールを運用する場合、両メディエーションの需要を主要ネットワークのダイレクト需要と並行して統合します。これにより、どちらか一方を選ぶことなく、Unity と AppLovin の需要のメリットを享受できます。
どちらを選ぶべきか
- Unity LevelPlay を選ぶなら：Unity エンジンで開発しており、開発ツールと収益化ツールの最も密接な統合を求める場合。主要地域で Unity Ads の需要が好調なときも有力です。
- AppLovin MAX を選ぶなら：ゲームと非ゲームの混在ポートフォリオを持つ場合、または AppLovin Exchange の需要があなたの業種・地域ミックスで特に強い場合。
- 両方を併用するなら：Google Ad Manager を介して、両エコシステムの需要がすべてのインプレッションで競争できるようにする。二者択一をなくし、需要カバレッジを最大化します。
メディエーションの選択は重要ですが、3 年前ほどの重要性はありません。入札が普及し需要の可搬性が高まるにつれて、プラットフォーム間の性能差は縮小しています。どのプラットフォームがオークションを司るかにかかわらず、あなたの在庫で競い合う総需要を最大化することに注力してください。