会社情報
採用情報
お問い合わせ
Article

キャンペーンサイト開発事例：SNS連携企画でブランド認知度を拡大

高田晃太郎
キャンペーンサイト開発事例：SNS連携企画でブランド認知度を拡大

2024年のグローバル統計では、世界のSNSユーザーは約50億人、普及率は約63%に達しています¹。ブランド発見の起点としてもSNSは存在感を増し、調査では世界の消費者の約64%が新しいブランドや商品をSNSで発見すると回答しています²³。国内の企業調査でも、SNS活用の主目的として「ブランド認知度の向上」が最多と報告されています⁴。検索と比較サイトだけでは取り切れない「偶発的な発見」の場に、意図的な導線を設計できるかどうかが、認知の臨界点を超える鍵になります。本稿では、CTOの視点から、SNS連携を核にしたキャンペーンサイトの設計・実装と、クリエイティブとデータ計測を同時に回すオペレーションを、実装可能な粒度で解説します。適切に設計すれば、一般に報告される傾向として、ブランド想起の改善や共有を起点とした到達の拡張、獲得コスト（CPA）の効率化につながる可能性があります。以下では、企画からアーキテクチャ、運用とセキュリティ、再現性のある学びまで、手順とコードを交えて整理します。

事例の全体像：認知拡大を生む企画と計測の両輪

例えば日用品カテゴリのように、短期に高頻度接触を作るよりも、共有による二次波及で到達母数を広げる戦略が適するケースがあります。キャンペーンは、SNSログイン（SSO）での簡易参加、参加者ごとの自動生成OG画像（OGはOpen Graphの略。SNSでのリンク共有時に表示される見出し画像）、抽選結果の即時返却、そして参加後に自然な共有を促すユースケース設計で構成します。重要なのは、共有を単なるボタンにしないことです。参加者の入力内容や抽選結果を反映したパーソナライズドOG画像を生成し、プライバシー配慮を前提に「自分ごと化」された視覚的表現をシェアできるようにします。共有リンクはHMAC署名（共通鍵で生成する改ざん検知用ハッシュ）付きで改ざん耐性を持たせ、同時にアトリビューションに必要なパラメータを安全に保持します。

評価の焦点は3点に集約できます。まずブランドリフト調査で想起・認知の有意な上昇が見られるか。次にエントリーフローの最適化とSSO導線によるCVR（コンバージョン率）の改善が確認できるか。最後に、共有率の向上に伴って一次流入に対する二次流入がどの程度生まれているかです。計測はGA4（Google Analytics 4）のイベント設計、UTM規約、そしてBigQueryでのセッション連結を基盤に置き、プラットフォーム側の計測差分はサンプリングやベイズ的な補正などの統計的手法で扱います。詳細はサーバーサイド計測ガイドに近い構成で、クライアントとエッジのハイブリッドが現実的です。

企画設計の要点：UGCが生まれる文脈の埋め込み

UGC（ユーザー生成コンテンツ）は「作ってください」とお願いしても生まれません。参加体験のなかに自然な共有理由を埋め込み、共有先のフィードで意味が崩れないよう、メタデータとプレビューを丁寧に設計する必要があります。参加者の回答から短いコピーを自動生成し、キャンペーンのステートメントとともにOG画像に焼き込みます。コピーはテンプレートとルールベースの変形で管理し、倫理ガイドラインに抵触しないようNG辞書を併用します。画像生成はサーバーサイドのCanvasレンダリングで行い、パフォーマンス劣化を防ぐためフォントと背景素材はエッジ（地理的に近い配信層）にプリロードします。こうして生まれた共有は、受け手のフィードにおいても意味が通り、広告的な匂いを抑えながらもブランド名とキャンペーンハッシュタグが視認される状態を確保できます。

KPIと計測の設計：「見える化」よりも「結びつけ」

KPIは単発の数字で追うと誤誘導が起きます。主目標が認知であれば、相関の高い行動指標として、完全視認可能なOGプレビューの露出回数、シェア後のクリック率（CTR）、シェア経由の初回セッション滞在時間などを中間KPIとして置くと整合的です。A/Bテストでは、一般にエントリー前に共有を促す導線よりも、エントリー完了画面で結果をプレビューしてから共有させる導線の方が、共有率やシェア後のCTRで良好な傾向が見られます。計測はサーバーログとGA4イベントの二重化で担保し、リファラ欠損やITP（ブラウザのトラッキング制限）影響を最小化するため、共有リンク側では短命の署名付きクエリとサーバーサイドのセッション再結合を使います。イベント命名規約は、後述のコード例の通りMeasurement Protocolで欠損補填も可能です。

アーキテクチャ：Next.js×エッジ×マルチOAuth

構成はNext.js 14のApp RouterにCloudflare Workers/Pagesでのエッジ配信を組み合わせ、動的APIはリージョナルなNodeクラスタに寄せます。静的アセットはR2互換のオブジェクトストレージ（S3互換系）、画像処理はエッジでのレスポンス変換、データ集計はBigQueryに集約、ダッシュボードはLooker Studioを利用します。認証はNextAuthを採用し、X（Twitter）とMeta、LINEのログインをマルチプロバイダ（OAuth）で接続します。以下がベースの設定です。

// src/app/api/auth/[...nextauth]/route.ts
import NextAuth from "next-auth";
import TwitterProvider from "next-auth/providers/twitter";
import GoogleProvider from "next-auth/providers/google"; // Instagram Graphは別途連携
import LineProvider from "next-auth/providers/line";
import { PrismaAdapter } from "@next-auth/prisma-adapter";
import { prisma } from "@/lib/prisma";

const handler = NextAuth({
  adapter: PrismaAdapter(prisma),
  providers: [
    TwitterProvider({
      clientId: process.env.TW_CLIENT_ID!,
      clientSecret: process.env.TW_CLIENT_SECRET!,
      version: "2.0",
    }),
    GoogleProvider({
      clientId: process.env.GOOGLE_CLIENT_ID!,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET!,
    }),
    LineProvider({
      clientId: process.env.LINE_CHANNEL_ID!,
      clientSecret: process.env.LINE_CHANNEL_SECRET!,
    }),
  ],
  session: { strategy: "jwt" },
  callbacks: {
    async jwt({ token, account }) {
      if (account) token.provider = account.provider;
      return token;
    },
    async session({ session, token }) {
      session.provider = token.provider as string;
      return session;
    },
  },
});

export { handler as GET, handler as POST };

Instagram Graph APIやXのWebhookは、認可更新やイベント受信時の検証が肝になります。サブスクリプション検証のミドルウェアは次の通りです。

// src/app/api/webhooks/meta/route.ts
import crypto from "node:crypto";
import { NextRequest, NextResponse } from "next/server";

function verifySignature(rawBody: string, signature?: string) {
  if (!signature) return false;
  const hmac = crypto
    .createHmac("sha256", process.env.META_APP_SECRET!)
    .update(rawBody)
    .digest("hex");
  return crypto.timingSafeEqual(Buffer.from(hmac), Buffer.from(signature.replace("sha256=", "")));
}

export async function POST(req: NextRequest) {
  const raw = await req.text();
  const sig = req.headers.get("x-hub-signature-256") || undefined;
  if (!verifySignature(raw, sig)) return new NextResponse("invalid", { status: 401 });
  // TODO: イベント種別ごとの処理
  return NextResponse.json({ ok: true });
}

export async function GET(req: NextRequest) {
  const url = new URL(req.url);
  if (url.searchParams.get("hub.verify_token") !== process.env.META_VERIFY_TOKEN)
    return new NextResponse("forbidden", { status: 403 });
  return new NextResponse(url.searchParams.get("hub.challenge") || "", { status: 200 });
}

共有リンクの改ざん耐性とアトリビューションのため、クエリに短命の署名を付加し、サーバーで再検証します。

// src/lib/share.ts
import crypto from "node:crypto";

export function signShare(params: Record<string, string>, ttlSec = 900) {
  const exp = Math.floor(Date.now() / 1000) + ttlSec;
  const base = new URLSearchParams({ ...params, exp: String(exp) }).toString();
  const sig = crypto.createHmac("sha256", process.env.SHARE_SIGNING_KEY!).update(base).digest("base64url");
  return `${base}&sig=${sig}`;
}

export function verifyShare(query: URLSearchParams) {
  const sig = query.get("sig");
  const exp = Number(query.get("exp"));
  if (!sig || !exp || Date.now() / 1000 > exp) return false;
  const copy = new URLSearchParams(query);
  copy.delete("sig");
  const expect = crypto.createHmac("sha256", process.env.SHARE_SIGNING_KEY!).update(copy.toString()).digest("base64url");
  return crypto.timingSafeEqual(Buffer.from(sig), Buffer.from(expect));
}

急増するトラフィックに備え、アプリ側でのレート制御とボット抑制も実装します。ここではRedis互換のトークンバケットを使った例を示します。

// src/middleware/rate-limit.ts
import { NextRequest, NextResponse } from "next/server";
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";

const redis = new Redis({ url: process.env.UPSTASH_REDIS_REST_URL!, token: process.env.UPSTASH_REDIS_REST_TOKEN! });
const limiter = new Ratelimit({ redis, limiter: Ratelimit.slidingWindow(120, "1 m") });

export async function middleware(req: NextRequest) {
  const ip = req.ip ?? "0.0.0.0";
  const { success, reset, remaining } = await limiter.limit(ip);
  if (!success) return new NextResponse("Too Many Requests", { status: 429, headers: { "Retry-After": String(Math.ceil((reset - Date.now()) / 1000)) } });
  const res = NextResponse.next();
  res.headers.set("X-RateLimit-Remaining", String(remaining));
  return res;
}

計測の欠損補填にはGA4 Measurement Protocolを活用し、サーバーでイベントを冪等（同じ入力に対して結果が変わらない）に送出します。ネットワーク障害に備えた再試行と重複排除の実装は次の通りです。

// src/lib/ga4.ts
import fetch from "node-fetch";
import crypto from "node:crypto";

const GA_ENDPOINT = "https://www.google-analytics.com/mp/collect";

export async function sendGA4(eventName: string, params: Record<string, unknown>) {
  const payload = {
    client_id: params.client_id ?? `srv.${crypto.randomUUID()}`,
    events: [
      {
        name: eventName,
        params: { ...params, engagement_time_msec: 1 },
      },
    ],
  };

  const body = JSON.stringify(payload);
  const url = `${GA_ENDPOINT}?measurement_id=${process.env.GA4_MEASUREMENT_ID}&api_secret=${process.env.GA4_API_SECRET}`;

  for (let i = 0; i < 3; i++) {
    const controller = new AbortController();
    const timeout = setTimeout(() => controller.abort(), 2000 + Math.random() * 500);
    try {
      const res = await fetch(url, { method: "POST", body, headers: { "Content-Type": "application/json" }, signal: controller.signal });
      if (res.ok) return true;
      if (res.status >= 400 && res.status < 500) return false; // 再試行無効
    } catch (e) {
      // ネットワーク系は再試行
    } finally {
      clearTimeout(timeout);
    }
    await new Promise((r) => setTimeout(r, 300 * 2 ** i + Math.random() * 100));
  }
  return false;
}

最後に、OG画像のオンデマンド生成は、レスポンス時間に直結します。エッジでのCanvasレンダリングとキャッシュを併用する例を示します。

// src/app/og/route.tsx
import { ImageResponse } from "next/og";
export const runtime = "edge";

export async function GET(req: Request) {
  const { searchParams } = new URL(req.url);
  const title = searchParams.get("t") || "Campaign";
  return new ImageResponse(
    (
      <div
        style={{
          display: "flex",
          width: "1200px",
          height: "630px",
          background: "#0f172a",
          color: "white",
          alignItems: "center",
          justifyContent: "center",
          fontSize: 72,
        }}
      >
        {title}
      </div>
    ),
    { headers: { "Cache-Control": "public, max-age=60, s-maxage=86400" } }
  );
}

スケーラビリティと性能：数値で語る

中〜大規模のキャンペーンでは、ピークトラフィックの目安として毎秒数百〜千リクエスト規模を想定し、p99のTTFB（Time to First Byte、最初のバイトまでの時間）で200ms前後、モバイルのp75 LCP（Largest Contentful Paint、主コンテンツの描画完了）で2秒未満を設計目標に置くと安定します。OG画像のコールドスタートを避けるには、人気文言の事前レンダリングとエッジキャッシュを併用し、キャッシュヒット率の高止まりを狙います。アプリサーバー側はNodeのクラスタを複数リージョンで冗長化し、リージョン間の整合はイベントソーシングなどで最終整合（最終的に整合が取れるモデル）を選ぶと、スパイクに強い構成になります。負荷試験にはk6を用い、共有直後のアクセスバーストを模擬するのが有効です。スクリプトは下記の通りです。

// loadtest/share-burst.js
import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  scenarios: {
    burst: {
      executor: 'ramping-arrival-rate',
      startRate: 50,
      timeUnit: '1s',
      preAllocatedVUs: 200,
      stages: [
        { target: 800, duration: '60s' },
        { target: 800, duration: '120s' },
        { target: 0, duration: '30s' },
      ],
    },
  },
};

export default function () {
  const res = http.get(`${__ENV.TARGET}/campaign?${__ENV.SIGNED_QUERY}`);
  if (res.status !== 200) console.error(res.status);
  sleep(0.2);
}

セキュリティと不正対策：懸賞の穴を塞ぐ

インセンティブ設計がある以上、ボット応募や多重申込への備えは必須です。実務では3層のガードが有効です。まずインビジブルreCAPTCHA v3で低スコアを遮断し、次にサーバー側での行動指標（滞在、スクロール、遷移）スコアリングでヒューリスティック判定を加え、最後に当選処理やポイント付与などの副作用系APIには冪等性キー（同一操作の重複実行を防ぐキー）を必須化します。冪等性キーはユーザーID×受付時刻のハッシュを用い、重複リクエストは最初の結果を返すことで、リロードやタイムアウト再試行でも整合を保てます。また、Webhookの署名検証はすべてタイミング攻撃に強い比較を採用し、署名鍵はKMS（鍵管理サービス）でローテーションします。下記はシンプルな冪等実装例です。

// src/app/api/award/route.ts
import { NextRequest, NextResponse } from "next/server";
import { prisma } from "@/lib/prisma";
import crypto from "node:crypto";

export async function POST(req: NextRequest) {
  const body = await req.json();
  const userId = body.userId as string;
  const nonce = body.nonce as string; // クライアント生成
  const key = crypto.createHash("sha256").update(`${userId}:${nonce}`).digest("hex");

  const exists = await prisma.idempotency.findUnique({ where: { key } });
  if (exists) return NextResponse.json(JSON.parse(exists.response));

  const result = await prisma.$transaction(async (tx) => {
    // 当選ロジックや在庫引き当て
    const awarded = Math.random() < 0.1;
    const response = { awarded };
    await tx.idempotency.create({ data: { key, response: JSON.stringify(response) } });
    return response;
  });

  return NextResponse.json(result);
}

プライバシーは設計の出発点です。SSOで取得できるデータはスコープを最小化し、キャンペーンで不要な属性は取得しません。オプトインは目的別に分割し、広告類推や類似オーディエンスに用いる場合は別チェックボックスで明示します。データ保持期間はキャンペーン規約で明文化し、削除要求はセルフサービスで可能にします。これらは技術実装だけでなくプロセスと規約の連動が肝で。

運用とビジネスインパクト：ROIで読み解く

実装は8週間前後のスプリントを一つの目安に、最初の2週間でKPI・イベント設計とワイヤー、3〜6週で実装・負荷試験、7〜8週でABテストと素材チューニングを行う進め方が現実的です。クリエイティブは複数系統×複数バリエーションを動的配信し、共有後のクリック率と滞在時間で逐次的に最良を採用します。媒体費は検索・SNS・ディスプレイのミックスで、共有起点の二次流入を含めた実効CPMの低減を狙うと、到達単価（CPAではなく到達ベースの指標）も圧縮しやすくなります。

ダッシュボードは日次で、媒体別一次流入、共有率、二次流入、シェア後のクリック率、滞在、応募完了、そしてブランドリフトの中間集計を並べると意思決定に効きます。特に有用なのは、共有直後のOGプレビューの視認秒数と、そこからのクリック率の相関です。プレビューが正しく生成されず既定画像にフォールバックしたケースでは、クリック率が大きく低下する傾向があります。これに備え、素材CDNの障害を検知したらサーバー側で軽量テンプレートに自動フェールバックする経路をあらかじめ用意すると安定します。技術的な修正がビジネス指標に直結する典型例です。

運用上の落とし穴もあります。モデレーションの遅延で承認待ちUGCの公開がボトルネックになりがちです。これは自動フィルタの閾値調整と、ピーク時間帯（昼休みや終業後）に人手を集中的に当てるシフト設計で解消しやすくなります。また、夜間にアクセストークン更新が集中し、一時的な401が多発するケースは珍しくありません。更新の分散化と指数バックオフ、そしてサーキットブレーカで依存APIを守るパターンが有効です。以下はフェッチの堅牢化ユーティリティです。

// src/lib/fetchx.ts
export async function fetchx(url: string, init: RequestInit = {}) {
  const max = 3;
  let delay = 200;
  for (let i = 0; i < max; i++) {
    try {
      const controller = new AbortController();
      const timeout = setTimeout(() => controller.abort(), 2500 + Math.random() * 500);
      const res = await fetch(url, { ...init, signal: controller.signal });
      clearTimeout(timeout);
      if (res.ok) return res;
      if (res.status === 401 && i < max - 1) {
        // トークン更新フック
        await refreshToken();
      } else if (res.status >= 400 && res.status < 500) {
        return res; // 4xxは即時終了
      }
    } catch (e) {
      // ネットワーク/タイムアウト時はリトライ
    }
    await new Promise((r) => setTimeout(r, delay + Math.random() * 100));
    delay *= 2;
  }
  throw new Error("fetchx: failed after retries");
}

async function refreshToken() {
  // 実装は省略：共有リフレッシュロジック
}

このケース設計は、SNS連携の技術とクリエイティブの協調が、直接的な到達と想起の増幅に寄与し得ることを示します。同時に、アトリビューションの整備、ボット対策、フェイルセーフの設計が成果の安定性を支えます。設計原理は他業種にも転用可能で、とくにサインイン体験の摩擦低減、プレビューの完全性、署名付き共有リンク、そしてサーバーサイド計測の四点は、どのキャンペーンでも再現性の高い基盤になると考えます。

再現性のある学び：チェックリストを文章で

まず、KPIを短期の行動指標に翻訳して、毎日意思決定ができる単位に落とし込むことが重要です。次に、共有の導線は「押させる」のではなく「出したくなる」を目指して、OG画像とコピーの自動生成で文脈を先回りしておくべきです。さらに、計測欠損を前提に、サーバーサイドの補完手段と重複排除を整えて媒体横断の比較可能性を高めると、施策の選択がぶれません。そして、流入が偏る時間帯の障害に耐えるよう、レート制御とフェイルオーバーを簡潔に持たせておくと、ピークに強い運用が実現します。最後に、法務・個人情報保護・SNSプラットフォームのポリシー更新を追従する体制を、技術・企画・運用の3者で固定化しておくと、予期せぬブロッキングを避けられます。

まとめ：技術で共有の必然をつくる

認知を広げるために、広告費を積み増すだけでは限界があります。共有される必然をプロダクトの内側に埋め込み、そのための技術と計測を用意できれば、同じ予算でも到達は伸び、想起は深まります。本稿で示した設計要素——SSOによる摩擦の除去、パーソナライズドOG画像、署名付き共有リンク、そして堅牢なサーバーサイド計測——は、認知を増幅させる装置として機能し得ます。あなたのブランドや案件に置き換えるなら、まず現在の導線で「共有する理由」が十分かを点検し、プレビューの完全性と計測の結びつきを強化してみてください。実装から運用までの道のりは短くありませんが、適切な技術的な一手はビジネス成果を大きく押し上げます。次のキャンペーンで、どの部分から改善を始めますか。ここで示した設計とコードは、その第一歩として実用に耐えるはずです。

参考文献

  1. We Are Social / Meltwater. Digital 2024: ソーシャルメディア利用者は約50億人、普及率63%（2024年1月）. https://wearesocial.com/jp/blog/2024/01/digital-2024-5-billion-social-media-users/
  2. WARC. 64% of consumers say they discover new brands on social media. https://www.warc.com/content/article/64-of-consumers-say-they-discover-new-brands-on-social-media/en-gb/146080
  3. GWI Blog. The biggest channels for brand discovery. https://blog.gwi.com/marketing/brand-discovery/
  4. PR TIMES. 企業のSNS活用目的に関する調査：最も多い目的は「ブランド認知度の向上」. https://prtimes.jp/main/html/rd/p/000000060.000064362.html