Brazeを利用してアプリやWebサイト内のバナーによるお知らせを差し替えたい場合、これまでは「コンテンツカード（Content Cards）」機能をカスタマイズして利用するのが唯一の選択肢でした。
しかし、新しいチャネルとして「Banners（バナー）」が登場したことにより、実装方法や運用の選択肢が広がりました。
本記事では、既存のコンテンツカードと何が違うのか、Bannersならではのメリット（D&Dエディタやレスポンシブ対応など）や、導入前に知っておくべき制限事項を整理して解説します。
WebサイトへのBanners組み込み例（上部「New Collection」の箇所）
アプリへのBanners組み込み例
右：カルーセルバナーのコンテンツ差し替え
左：アプリ内ページへのコンテンツ差し込み
1. コンテンツカード（フルカスタマイズ）との違い
Bannersは、「Webサイトやアプリの特定枠への表示」をよりシンプルに実現できるようになった機能です。
コンテンツの形式（HTML vs データ）や編集方法、描画パフォーマンスに違いがあります。
(1) コンテンツの形式と自由度
最大の違いは、「WebView（HTML）」として表示するか、「データ（JSON）」として受け取ってネイティブで描画するかという点です。
| 項目 | Banners | コンテンツカード（フルカスタマイズ） |
|---|---|---|
| 形式 |
HTML形式 アプリ内ではWebViewとして描画されます。 |
データ（JSON/テキスト）形式 画像のURLやテキスト情報だけを受け取り、ネイティブ側でレイアウトを組みます。 |
| 作成方法 |
D&Dエディタによる編集 管理画面上のドラッグ＆ドロップ操作で、モバイルとPCの両方のレイアウトに対応できるレスポンシブ対応のデザインをノーコードで作成可能です。 |
実装依存 「画像はここに、テキストはここに」といったレイアウトをアプリ/Webのフロントエンドのコード側で実装する必要があります。 |
| 自由度 |
やや低い D&Dエディタで画像や文字、ボタンを含むHTML形式で作成できるが、HTML自体を直書きできるわけではない。 |
高い 画像とテキストを用途に合わせて利用でき、アプリのUIに完全に溶け込ませることが可能。 |
| ロギング |
自動 インプレッションやクリック計測は自動で行われます。 |
手動 フルカスタマイズの場合、クリック等のイベント計測用のメソッドも実装する必要があります。 |
D&Dエディタによる編集
Bannersは、メール作成などでお馴染みのドラッグ＆ドロップ（D&D）エディタを使って作成できます。
エディタ上でモバイル（スマホ）とPCのそれぞれの表示設定ができるため、画面サイズに合わせてレイアウトが自動で切り替わる「レスポンシブ対応」のバナーも作成できます。
Banners編集画面 - モバイル表示
Banners編集画面 - PC表示
この点はコンテンツカードにはなかった機能です。
(2) 描画パフォーマンスの向上
- Banners: 読み込みが高速化されており、表示の遅延（チラつき）が軽減されています。
- コンテンツカード: ユーザーごとにサーバー側で情報を生成する処理が入るため、初回の読み込み時にわずかなタイムラグが発生しやすく、実装によっては画面描画後にバナーが遅れて表示されることがありました。
(3) 表示場所は「配置 (Placement)」で管理
Bannersでは、「どこに表示するか」を 配置 (Placement) で設定します。
- 配置ID (Placement ID) の活用:
Braze管理画面とアプリ/Web側で共通の「配置ID」を定義します。- 例：「トップページのヘッダーバナー」用に
header_banner_1というIDを作成。 - エンジニアは「この配置IDで取得できたコンテンツを、この場所に埋め込む」という実装をするだけでOKです。
- 例：「トップページのヘッダーバナー」用に
これまでのコンテンツカードでは、Key-Valueペア（メタデータ）を使って「これはトップページ用」などのフィルタリングロジックを組む必要がありましたが、Bannersでは「配置」という概念が標準化されたため、ダッシュボード上での設定もより直感的でわかりやすくなりました。
2. セッション中のバナー更新が可能に
Bannersのリリース当初は、更新タイミングは「セッション開始時」のみでしたが、アップデートによりアプリ利用中（セッション中）でもrequestBannersRefresh というメソッドを呼び出すことにより最新情報を取得・更新できるようになりました。
ユーザーがアプリやWebサイトを回遊している最中に、その行動に合わせてバナーを切り替えるといった、よりリアルタイムなパーソナライズが可能になります。
更新リクエストのレートリミット：トークンバケット方式
過度な更新リクエストを抑止するため、最新SDK（Android 38.0.0+ / Swift 13.1.0+ / Web 6.1.0+）では「トークンバケット方式」でリクエスト頻度が制御されています。基本的には180秒に1回以下になるように制御していればレートリミットに引っかかることはありませんが、詳細な仕様としては以下の通りとなります。
- 初期トークン: セッション開始時に 5トークン 付与。
- 補充: 180秒ごとに1トークン が自動的に再補充されます。
- 消費: バナーの再取得（リフレッシュ）リクエスト1回につき1トークン消費。トークンがない状態ではリフレッシュできません。
※ Banners対応後のSDKの旧バージョン（Android 33.1.0+ / Swift 12.0.3+ / Web 5.6.1+ など）を使用している場合は、これまで通り「1セッションにつき1回のみ」のリフレッシュとなります。
3. 制限事項
現時点でのBannersには以下のような制限事項があります。
- キャンペーンでのスケジュール配信のみ:
現時点では「キャンペーン」機能でのみ配信可能です。「キャンバス（Canvas）」のステップとしては利用できません。また、APIトリガーキャンペーンにも未対応です。 - 設定できる個数の制限:
一度のリクエストで取得できるのは 最大10個の配置ID（Placement ID） 分までです。また、1つの配置IDに対して同時にアクティブにできるキャンペーン数にも制限があります。 - パーソナライズの制約:
- Connected Content (コネクテッドコンテンツ): 外部APIからデータを取得して表示する機能は未対応です。
- プロモーションコード: Brazeのプロモーションコードを使ったクーポンの表示などは利用できません。
まとめ
Bannersの登場により、BrazeによるWebサイトやアプリ画面へのコンテンツ差し込みの選択肢が広がりました。
-
Bannersがおすすめなケース:
- 実装工数を抑えつつ、Brazeによるバナーへの差し込みを実現したい。
- 特定の「配置（枠）」に対する管理をシンプルに行いたい。
- 運用担当者がD&Dエディタで手軽にデザインしたい。
-
コンテンツカードがおすすめなケース:
- アプリのネイティブUI内に画像をパーツして埋め込み一体化したデザインにしたい。
- Connected Contentなど高度な動的データを使いたい。
- キャンバスを使った複雑なシナリオ配信を行いたい。
実装方法の詳細については、Brazeの開発者ガイド - Bannersをご参照ください。
また私の方でサンプルコードを以下のGithubレポジトリに載せておりますので、こちらもご参照ください。
- gtm-banners: Braze Web SDK(GTM)にてBannersのデータを取得し、ページのトップにあるdivタグ内にバナーを埋め込む場合のサンプルです。
- braze-banners-swift: iOSのSwift SDKにてBannersを取得し、表示する際のサンプルです。