自社広告プラットフォームをAIと共に設計・実装した124タスクの全記録
Mark4外部広告だけでは足りない — 自社で広告を管理・配信する基盤づくり
なぜ自社広告プラットフォームが必要だったのか
wagahiアプリの収益モデルは、広告収益とアプリ内課金の二本柱です。Google AdSenseやH5 Games Adsなど外部広告プラットフォームの審査を進める一方で、自社で広告を管理・配信できるプラットフォームの必要性が見えてきました。
外部広告だけでは足りない理由
- 審査期間の不確実性: AdSenseやH5 Games Adsの審査は数週間かかり、審査結果も不確実
- 広告内容のコントロール: 外部広告ではゲームの世界観に合わない広告が表示される可能性がある
- 自社サービスの告知: セミナー告知、新機能アナウンスなど自社コンテンツの配信手段が必要
- 広告枠の有効活用: 外部広告の審査通過前でも、広告枠を空白にせず自社広告で埋められる
7フェーズ124タスクの作業計画
自社広告プラットフォームの設計から実装まで、7フェーズに分割した作業計画を策定しました。
Phase 0: 設計調査（18タスク）
市場調査、競合分析、技術選定を実施。広告配信の仕組み、クリック計測、レポーティングなどの要件を定義しました。
Phase 1: DB設計・マイグレーション（14タスク）
広告マスタ、広告配置、クリックログ、インプレッションログなどのテーブル設計とFlywayマイグレーションの実装。
Phase 2: バックエンドAPI（22タスク）
広告配置管理API、広告配信API、クリック・インプレッション記録API、レポーティングAPIの実装。
Phase 3: 管理画面UI（20タスク）
管理者向けの広告管理ダッシュボード。広告の作成・編集・削除、配置設定、パフォーマンスレポートの表示機能。
Phase 4: ユーザー側フロントエンド（18タスク）
ユーザー向け画面への広告表示コンポーネント統合。バナー広告、インタースティシャル広告、Rewarded広告の表示制御。
Phase 5: 結合試験（20タスク）
広告配信フロー全体の結合試験。配信→表示→クリック→報酬付与の一連のフローをPlaywright MCPで自動テスト。
Phase 6: 結合検証・Bug修正（12タスク）
結合試験で発見されたバグの修正と再テスト。
実装のハイライト
広告配置管理API
管理者がどの画面のどの位置に、どの広告を表示するかを細かく制御できるAPIを実装しました。
- 画面ごとの広告スロット定義
- 広告の優先順位設定
- 表示期間の指定（開始日〜終了日）
- 表示条件の設定（ユーザー属性、時間帯など）
広告個別ON/OFF機能
各広告を個別にON/OFFできる機能は、運用上非常に重要です。問題のある広告を即座に停止できるだけでなく、A/Bテストにも活用できます。
バナー広告共有スロット問題の解消
開発中に発見された問題として、複数の画面で同じバナー広告スロットを共有している場合、一方の画面での表示設定が他方に影響するというバグがありました。各画面のスロットを独立管理するようにアーキテクチャを修正し、この問題を解消しました。
バナークリック報酬
バナー広告をクリックしたユーザーにトークンを付与する仕組みも実装しました。これにより、ユーザーにとって広告が「邪魔なもの」ではなく「トークンを獲得する手段」として機能します。
営業資料3文書の作成
技術実装と並行して、営業資料も3文書作成しました。
- 広告プラットフォーム概要資料: 機能一覧、技術仕様のサマリー
- 広告メニュー・料金表: 広告種類別の料金体系
- 導入ガイド: 広告出稿の手順書
これらの文書もClaude Codeとの協働で作成しました。技術仕様から営業資料への変換は、AIが得意とする作業の一つです。
124タスク完了の振り返り
設計調査から結合検証まで、全124タスクを完了しました。AI駆動開発だからこそ、これだけの規模の機能を短期間で実装できたと実感しています。
特に効果が大きかったのは以下の点です。
- 設計書駆動: 事前に詳細な設計書を作成し、それに基づいてClaude Codeが実装
- フェーズ分割: 124タスクを7フェーズに分割し、段階的に完成度を上げた
- 自動テスト: Playwright MCPによる結合試験の自動化で、手戻りを最小化
本記事は2026年2月時点の開発状況に基づいています。
著者: 株式会社シーテン — インフラ系から宇宙関連システムまで20年以上の開発経験を持つ技術者集団。2025年より生成AI・AIエージェントを活用したAI駆動開発に本格参入し、自社プロダクト「wagahi」の開発を通じて実践知見を蓄積中。
関連記事:
投稿者プロフィール
