Open Learning Commons

第10章

広告を設定し、公開後も運用する

AdMobとAdSenseの使い分け、テスト広告、同意、権限分離、監視と更新の流れを学びます。

この章で学ぶこと

  • Android・iOSのAdMobとWebのAdSenseを使い分ける
  • 広告ID、同意、ストア申告を安全に設定する
  • 公開後の監視、問い合わせ、更新、権限棚卸しを続ける

AdMobとAdSenseを分ける

配信先 主なサービス 組み込み方法
Android / iOSアプリ AdMob Mobile Ads SDKとアプリID・広告ユニットID
Webサイト AdSense サイト審査、Web用コード、ads.txtなど

Flutter向けGoogle Mobile AdsプラグインはAndroidとiOS向けで、Webを対象にしません。公式クイックスタートを基準に設定します。

広告を入れる前に、利用者体験、対象年齢、プライバシー、通信量、審査、収益の見込みを比較してください。最初の版では広告を入れず、価値と継続利用を確認してから追加する判断もあります。

1. AdMobをAndroid・iOSへ設定する

AdMobでAndroid用とiOS用のアプリを別々に登録し、それぞれのアプリIDと広告ユニットIDを取得します。

flutter pub add google_mobile_ads

Androidではandroid/app/src/main/AndroidManifest.xmlのapplication内にAdMobアプリIDを設定します。

<meta-data
    android:name="com.google.android.gms.ads.APPLICATION_ID"
    android:value="ca-app-pub-xxxxxxxxxxxxxxxx~yyyyyyyyyy" />

iOSではios/Runner/Info.plistに設定します。

<key>GADApplicationIdentifier</key>
<string>ca-app-pub-################~##########</string>

SDKを初期化してから広告を読み込みます。

await MobileAds.instance.initialize();

アプリIDと広告ユニットIDは用途が違います。プラットフォームや広告形式ごとに管理し、コードへ意味のない文字列として散らさず、設定クラスにまとめます。

開発中は必ずテスト広告を使う

開発者が本番広告をクリックしたり、表示を不自然に繰り返したりしてはいけません。Googleが公開するテスト広告ユニットID、またはテスト端末設定を使います。

debug / development → テスト広告ID
release / production → 本番広告ID

productionの広告IDへ切り替わる条件を自動テストまたはビルドログで確認します。

2. WebにAdSenseを設定する

AdSenseではサイトを追加し、所有確認、審査、プライバシー対応を行います。審査が通る前に表示されないことや、承認後も常に広告が配信されるとは限りません。

一般的な流れです。

  1. AdSenseへ公開サイトのURLを追加する。
  2. 指定された方法でサイト所有権を確認する。
  3. プライバシーポリシーと必要な同意管理を公開する。
  4. 審査を依頼する。
  5. 承認後、広告ユニットまたは自動広告を設定する。
  6. ads.txtの内容と公開URLを確認する。

Flutter Webの画面へ広告スクリプトを直接混ぜる場合は、HTMLのライフサイクル、ルーティング、レイアウト、同意前の読み込みを検証する必要があります。まずWebサイト側の固定した広告枠で試し、規約とユーザー体験を確認してください。

3. 同意とストア申告を一致させる

広告SDKを追加すると、広告識別子、端末情報、IPアドレス、利用状況などの扱いが変わることがあります。

  • 対象地域に応じた同意管理を実装する。
  • 同意前に読み込んでよいSDK・データを確認する。
  • Google PlayのData safetyを更新する。
  • App StoreのApp Privacyを更新する。
  • プライバシーポリシーへ広告事業者と目的を書く。
  • 子ども向け、年齢不明、パーソナライズ制限の設定を確認する。

法的判断が必要な場合は、対象地域と事業内容を伝えて専門家へ確認します。生成AIの回答だけを法的根拠にしません。

4. 広告と支払いの権限を分ける

AdMob・AdSenseの画面を管理する権限と、支払いプロファイルを管理する権限は別です。

  • 開発者には対象アプリの設定に必要な範囲だけを付ける。
  • 売上・税務・銀行情報は会計担当へ限定する。
  • 新しい利用者を招待できるAdminを少人数にする。
  • 退会者をAdMob / AdSense本体とPaymentsの両方から確認する。
  • 支払い先変更は複数人で照合する。

5. 公開後の運用サイクル

公開は終点ではありません。

監視 → 問い合わせ確認 → 優先順位付け → 修正
  ↑                                  ↓
公開記録 ← 段階公開 ← テスト ← 新しいビルド

毎日〜毎週

  • クラッシュ、ログイン失敗、保存失敗、費用の急増を見る。
  • ストア審査、ポリシー通知、問い合わせを確認する。
  • 広告の無効トラフィックや配信制限の通知を見る。

毎月〜四半期

  • Flutter、Firebase、広告SDKの更新とセキュリティ情報を確認する。
  • Admin、Owner、支払い利用者、CIの鍵を棚卸しする。
  • プライバシー申告と実装の差を確認する。
  • バックアップと復旧手順を実際に試す。
  • 使われていない機能、データ、広告枠を減らす。

障害時

  1. 影響範囲と開始時刻を記録する。
  2. 本番変更を止め、直前のリリースと監視値を見る。
  3. Hostingの切り戻し、段階公開の停止、機能フラグなど安全な手段を選ぶ。
  4. 利用者へ事実、回避策、次の更新時刻を伝える。
  5. 復旧後、原因と再発防止を記録する。

最終課題

自分のアプリについて、次を1つのリリース記録へまとめてください。

  • 企画の1ページ仕様書と、最初の版に含めない機能
  • GitコミットID、アプリのversion、3プラットフォームのビルド番号
  • Firebaseのdevelopment / production対応表
  • Webプレビュー、Android内部テスト、iOS TestFlightの確認結果
  • 管理者、リリース担当、会計担当、問い合わせ担当
  • 広告の有無、テスト方法、同意とプライバシー申告
  • 公開後に見る指標と、障害時の停止・切り戻し方法

生成AIに記録の抜けをレビューさせた後、実際の管理画面と成果物を人が照合して完成です。