記事の最後まで読まれないなら、本文を広告サンドにするな――PCの「何もない横」を売るAdsterra設計

1. 「広告はある。でも最後まで読まれないと会えない」という悲しい配置

記事サイトに広告を置いた。

ちゃんと表示される。よし。

ところが、よく見ると広告が記事のかなり下にいる。

読者はタイトルを読む。冒頭を読む。途中で満足する。検索へ戻る。別の記事へ行く。

広告はその下で待っている。

「本日も誰とも会えませんでした」

これでは広告が存在していても、上の方だけ読んで帰る訪問を十分に収益機会へ変えられない。

ここで最初に浮かびやすいのが、「じゃあページを開いた瞬間にデカい広告を出せばいいじゃん」である。

理屈だけなら速い。

しかし、読者が記事を読みに来たのに、最初に広告との面接を強制されるサイトは普通に嫌われる。

Coalition for Better Adsの研究では、デスクトップのポップアップ、カウントダウン付きのprestitial、大型sticky広告などは、受容性の低い広告体験に分類されている。2026年の更新では、デスクトップ本文領域で広告密度が50％を超える体験も基準以下に追加された。^[1][2]

つまり問題は、

「広告をもっと見せたい」

ではない。

「本文を邪魔せず、読者が自然に通る場所へ広告在庫を移したい」

である。

2. そしてPC画面を見る。「横、めちゃくちゃ空いてない？」

スマホは狭い。

本文だけでも幅が足りない。そこへ広告を何枚も差し込めば、記事はすぐ広告入りミルフィーユになる。

一方、PCは違う。

読みやすさのために本文幅を絞ると、左右に大きな余白が残る。目次をサイドバーに置いても、その上と下が空いていることがある。

そこで気づく。

本文の中に広告を増やさなくても、横に土地が余っている。

広告設計というより、不動産である。

中央の一等地は本文に渡す。読者が歩く道は塞がない。

その横の空き地を貸す。

Adsterraは現在、160×300、160×600、300×250、320×50、468×60、728×90などのBannerサイズを案内している。公式ガイドでも160×600は左右のサイド配置、300×250は本文ブロックやサイドバーに馴染みやすいサイズとして紹介されている。^[3]

だからPCでは、

広告
↓
目次
↓
広告

という縦配置がかなり自然に成立する。

読者は本文を読める。広告も見える。

誰も道路の真ん中に看板を置かなくていい。

3. PCでは「目次の上下」がかなりおいしい

たとえば右サイドバーに目次があるサイトなら、考え方は単純だ。

目次の上

300×250などの中型Banner。

ページを開いて比較的早い段階で画面へ入る可能性が高い。

目次

記事ナビゲーション。

必要なら目次だけstickyにする。

目次の下

160×600、160×300、またはレイアウト幅に合う別Placement。

長い記事を読む人ほど、スクロール中にこの枠へ近づく。

重要なのは、広告までずっとstickyにしなくていいことだ。

大型sticky広告は、読者がスクロールしても画面を占有し続ける。Coalition for Better Adsでは、画面の30％超を占める大型sticky広告はデスクトップで基準以下の広告体験として扱われる。^[2]

だから「空いている横を使う」と「読者を横から追尾する」は別である。

余白は売る。

読者は追い回さない。

これだけでかなり品が良くなる。

4. 上部広告も欲しい。ただしH1を広告の地下へ埋めない

記事末尾だけでなく、ページを開いて早い段階にも広告枠は欲しい。

ここも、いきなりページ最上部へ巨大Bannerを置く必要はない。

自然なのは、

記事タイトル
→ 概要・メタ情報
→ 広告
→ 目次・本文

くらいだ。

読者はまず「何の記事か」を確認できる。

そのあとに広告が一つある。

そして本文へ進む。

Adsterraには通常BannerのほかNative Bannerもあり、Nativeはサイト側でブロックサイズや色、フォントサイズを合わせやすい形式として案内されている。^[4]

ただし、「上に置けば必ず1PV＝広告収益」ではない。

Adsterraの広告はCPMだけでなくCPCやCPAなど複数の価格モデルがあり、実際の収益は広告需要、国、端末、広告形式、トラフィック品質などで変わる。^[3]

正確には、

早い位置へ広告を置くと、完読されなくても広告表示・視認の機会を作りやすい。

である。

「ページを開けば必ずコインが1枚落ちる魔法の箱」ではない。

5. 広告が後から降ってきて本文を吹き飛ばすのはやめる

広告枠を増やすと、別の敵が出る。

CLSである。

ページを開く。

本文を読み始める。

数秒後、広告がロードされる。

突然その場所が200px、300pxと膨らむ。

読んでいた段落が下へ飛ぶ。

記事を読んでいたら床が動いた。

これはかなり嫌な体験だ。

web.devは、広告・iframe・動的に挿入される要素をCLSの代表的な原因として挙げている。対策は、広告がロードされる前からmin-heightやaspect-ratioなどで必要なスペースを予約することだ。^[5]

Core Web Vitalsでは、少なくとも75％のページ訪問でCLS 0.1以下が良好の目安とされている。^[5]

つまり広告枠は、

読み込まれてから場所を要求する客

ではなく、

最初から席を予約している客

にする。

PCサイドなら300×250の箱を先に確保する。160×600ならその縦スペースを先に取る。

広告が遅れて来ても、本文は動かない。

この差は地味だが大きい。

6. ここでAdsterra特有の罠。「同じ広告コード、横にも貼ればよくない？」

広告枠が一つある。

サイドバーにも欲しい。

なら同じコードをコピーして2回貼れば一瞬で完成する。

残念ながら、ここはAdsterra自身が止めている。

公式ガイドでは、同じBannerコードを同一ページで2回使うと統計やCPMへ悪影響が出る可能性があり、同じサイズを2個使う場合でも別コードを用意するよう案内している。^[6]

同じ広告が同時に出て、読者にも広告主にも妙な画面になりやすい。

だから、

• article-top
• desktop-sidebar-top
• desktop-sidebar-bottom

のように、役割ごとに独立したPlacementを作る方がいい。

これにはもう一つ利点がある。

どこが本当に稼いでいるか分かる。

上部はimpressionが多いがCPMが弱いのか。

サイド下部は表示回数が少ないのに単価が高いのか。

PCだけ強いのか。

Placementが別なら比較できる。

同じコードをコピペして全部一つの数字へ混ぜると、改善しようとしても何を改善しているのか分からなくなる。

広告配置は「出たからヨシ」ではなく、計測できて初めて運用になる。

7. そして自動化しようとすると、APIが急に「見るだけです」と言い出す

ここが妙に面白い。

サイト側の実装はかなり自動化できる。

AIコーディングエージェントに、

• 共通記事レイアウトを調べる
• 広告コンポーネントを追加する
• PCだけサイド広告を出す
• スマホでは隠す
• CLS用スペースを予約する
• buildする
• デプロイする
• 本番HTMLを確認する

まで任せられる。

ではAdsterra側もAPIでPlacementを作れば完全自動化できるのでは？

ここでPublisher APIを見る。

AdsterraはPublisher APIで、登録サイト、Placement一覧、impressions、clicks、CTR、CPM、revenueなどを取得できる。^[7]

便利である。

しかし2026年9月25日時点、Publisher側が使えるHTTPメソッドはGETのみである。^[7]

つまり、

見ることはできる。
作ることはできない。

Publisher APIは監視カメラとしては優秀だが、ドアノブではない。

新しい広告ユニットを作るには、Publisher Dashboardでサイトを選び、ADD UNITからサイズを選び、発行されたコードを取得するGUI工程が残る。^[8]

ここで自動化の99％が終わっているのに、最後の1％だけ人類が召喚される。

「では最後に、このボタンを押してください」

文明はここまで来た。

最後に残った仕事が広告枠作成ボタンである。

ブラウザ操作が可能なAIエージェントなら、そのGUIも操作対象にできる。ただしPublisher APIだけでは新規Placement作成を代替できない、という境界は理解しておく必要がある。

8. Bannerはレスポンシブだと思って雑に置くと、スマホで事故る

もう一つ重要なのが端末別表示だ。

Adsterraの公式Bannerガイドは、Adsterra Bannerはレスポンシブではなく、端末によって自動的にサイズが変わるわけではないと説明している。そのためCSSでPC用・モバイル用の表示を切り替える方法が案内されている。^[6]

つまりPCで160×600が気持ちよく収まったからといって、そのままスマホへ持っていくと、

広告が本文より態度でかい

ということが起きる。

設計は端末で分ける。

スマホ

• 記事上部に小さめの広告
• 必要なら記事末尾
• サイド広告は出さない
• 本文幅を広告に奪わせない

PC

• 記事上部広告
• 目次上のサイド広告
• 目次下のサイド広告
• 既存の末尾広告
• 十分な幅がある場合だけ追加サイド領域を検討

ただし、PCだから無限に置いていいわけではない。

2026年に追加されたBetter Ads Standardsでは、デスクトップ本文領域で広告密度が50％を超える体験は基準以下とされ、サイドレール広告も密度計算へ含まれる。^[1]

余白は売っていい。

壁という壁にポスターを貼って、本文が地方自治体の掲示板みたいになるところまでは行かない。

9. 結論：売るべきなのは「読者の注意」より先に「余っている空間」

広告収益を増やしたいとき、最も雑な解決は本文の中へ広告を追加することだ。

しかしPCの記事ページには、もっと先に使えるものがある。

余白。

本文は読みやすい幅のまま保つ。

タイトルは最初に読ませる。

早い位置に広告を一つ置く。

PCでは目次の上下に別Placementを置く。

大きなsticky広告で追い回さない。

広告枠のスペースは先に確保してCLSを防ぐ。

同じBannerコードをコピーせず、枠ごとに分けて計測する。

そして新しいPlacement作成だけは、Publisher APIがGET専用なのでDashboard GUIを通る。

設計としては非常に単純だ。

本文を広告で埋めるのではなく、本文の外にある未利用不動産を貸す。

読者は読める。

広告は見える。

サイト側は数字を比較できる。

広告主も同じクリエイティブを同時に二枚並べられずに済む。

全員が少しずつマシになる。

そして最後に一つだけ残る。

AIがコードを書き、CSSを直し、ビルドし、デプロイし、本番を確認したあと、広告会社の管理画面で「広告ユニット追加」を押す。

ウェブ自動化の最終ボスが、だいたいボタン一個なのはちょっと面白い。

---

出典

1. Coalition for Better Ads, „CBA Updates Desktop Web and Mobile Web Standards“, angekündigt am 14. Januar 2026. Der aktualisierte Desktop-Standard umfasst eine Werbedichte über 50%, Sidebar-Anzeigen zählen mit. und https://www.betterads.org/desktop-ad-density-over-50-percent betterads.org
2. Coalition for Better Ads, „The Research“ und „Large Sticky Ads [Desktop]“. und https://www.betterads.org/desktop-large-sticky-ad/ betterads.org
3. Adsterra, „Standard Banner Ad Sizes 2026: Complete Guide with Dimensions“, 9. Juli 2026 adsterra.com
4. Adsterra, Produktinformationen für Publisher zu Native Banners (anpassbare Blockgröße, Farben und Schriftgröße) adsterra.com
5. web.dev, „Optimize Cumulative Layout Shift“, zuletzt aktualisiert am 7. Februar 2025. Anzeigen und nachträglich eingefügte Inhalte sind häufige Ursachen; Platz mit min-height/aspect-ratio reservieren web.dev
6. Adsterra, „Banner Ads Still Drive High CPM and Revenues for Publishers“. Rät davon ab, denselben Banner-Code zweimal auf einer Seite zu nutzen, und erklärt, dass Adsterra-Banner sich nicht automatisch an Geräte anpassen adsterra.com
7. Adsterra, „Ad network API“ und „Adsterra Publisher API: Easily Pull Data to Power Your Monetization Strategy“, Stand 25. September 2026. Die Publisher API liefert Websites, Placements und Berichte und unterstützt nur GET. und https://adsterra.com/blog/how-to-use-adsterra-publishers-api/ adsterra.com
8. Adsterra, „Buy Banner Ads | Adsterra Banner Advertising“. Ablauf für Publisher: Website wählen, ADD UNIT, Bannergröße wählen und den erzeugten Code kopieren adsterra.com