2025年11月12日·1 分
クライアント承認付きキャンペーンWebアプリの作り方
マーケティングエージェンシー向けに、キャンペーン、アセット、クライアント承認を管理するWebアプリを、ロール、ワークフロー、監査対応の履歴を含めて計画・構築する方法を解説します。
マーケティングエージェンシー向けに、キャンペーン、アセット、クライアント承認を管理するWebアプリを、ロール、ワークフロー、監査対応の履歴を含めて計画・構築する方法を解説します。
画面を描いたり技術スタックを選ぶ前に、コアの問題を明確にしましょう：マーケティングキャンペーンと承認がメール、チャット、共有ドライブに散在していること。キャンペーンWebアプリはブリーフ、アセット、フィードバック、サインオフを一箇所にまとめ、次に何をすべきか全員が見えるようにするべきです—スレッドを追いかける手間をなくします。
多くのエージェンシーの承認ワークフローには、ニーズの異なる次の4つのグループが関わります：
メールベースの承認は予測可能な問題を生みます：最新の依頼が誰にも見えておらず締切が守れない、"make it pop"のような曖昧なフィードバック、複数バージョンが飛び交うことによる混乱、遅いまたは矛盾する入力による手戻り。
プロダクトが機能しているかを判断するために測定可能な成果を定義します：
v1では、キャンペーンと承認を一緒に保つための最小セットに集中します：
後回しにしてよいもの：高度なレポーティング、深い連携、オートメーションルール、カスタム承認パス。
画面や技術を考える前に、実際の業務フローを書き出してください。明確なワークフローは「これはどこまで進んでいる？」を予測可能なステップに変え、アプリが強制／自動化／報告できるようになります。
多くのキャンペーン承認アプリは少数のビルディングブロックで表現できます：
関係性をドキュメント化しましょう：キャンペーンはプロジェクトを含み、プロジェクトはタスクを含み、タスクはアセットを生み、アセットは承認を経ます。
エージェンシー向けにシンプルなフローの例：
Draft → Internal review → Client review → Approved
各状態に運用上の意味を持たせます。例えば「Internal review」はクリエイティブリードとアカウントマネージャーの署名が必要で、クライアントに見せる前のチェックを保証する、など。
製品内でフィードバックがどのように見えるかを決めてください：
重要なのはフィードバックをアセットバージョンに紐づけることです。どのファイルがレビューされたのかで議論しなくて済みます。
一般的な遅延の原因：レビュアー待ち、次の手順が不明、繰り返しのセットアップ。役立つ自動化は：
実際の承認は常に綺麗ではありません。計画しておくべき例：
これらのルールを平易な言葉で説明できれば、画面やデータモデルに落とし込む準備はできています。
キャンペーンアプリの優れたUXは、エージェンシーの考え方を写した単純な情報階層から始まります：クライアント → キャンペーン → デリバラブル（アセット）。ユーザーが常に「私は今どこにいるか？」「次は何をするか？」に答えられれば、承認は速くなり、抜け漏れが減ります。
トップレベルをクライアントにし、その下にキャンペーン、さらにデリバラブル（広告、メール、ランディング、ソーシャル投稿）を表示します。ナビゲーション、パンくず、検索で同じ構造を保つと、ユーザーは毎画面で学び直す必要がありません。
実用的なルール：各デリバラブルは常にクライアント、キャンペーン、期日、ステータス、担当者を一目で示すべきです。
ダッシュボード： エージェンシーのホームベース。今日注目すべきこと（期日が近い項目、内部レビュー待ち、クライアント承認待ち）に集中させます。
キャンペーンタイムライン： カレンダー形式やフェーズベースのビューで依存関係を明示（例：「コピー承認」→「デザイン最終」）。読みやすさを優先し、数秒で進捗が理解できること。
アセットレビュー画面： 時間を稼げる場所。プレビューを大きく、コメントを見つけやすく、次のアクションを明確に。
インボックス： 「自分が対応する必要があるもの」を一箇所に集約（新しいフィードバック、承認依頼、メンション）。これによりメールやチャットの往復が減ります。
よくある問いに答えるクイックフィルタを用意します：
主要なコールトゥアクションは明白に：承認／変更を依頼。レビュー画面では（スティッキーフッターやヘッダーで）常に見える場所に固定し、クライアントがコメントをスクロールした後も探さなくて済むようにします。
クライアントは会議の合間にレビューすることが多いです。モバイルの可読性を優先：クリーンプレビュー、大きなボタン、短いフィードバックフォーム。一度のタップでアセットを開き、もう一度で承認できれば承認ターンアラウンドは早くなります。
キャンペーン承認アプリは信頼で成り立ちます：クライアントは見て良いものだけを見ていると安心し、チームは誤って上書きされたり誤った人物が承認することがないよう境界が必要です。
ほとんどのエージェンシーは次の5つで十分です：
グローバルな権限だけでなく、オブジェクトタイプ（キャンペーン、デリバラブル、アセット、コメント）ごとにアクションを定義します。典型的なアクションは表示、コメント、アップロード、承認、編集、削除です。
実用的なデフォルトは「最小権限」：コントリビューターは自分のアセットをアップロード・編集できますが、キャンペーン設定の削除や変更はアカウントマネージャー／管理者に限定します。
クライアントは自分のキャンペーン、アセット、議論のみを見られるべきです。他のアカウントが見えてしまう共有フォルダは避けてください。これを容易にするには、各キャンペーンをクライアントアカウントに紐づけ、ページ、ダウンロード、通知をまたいで一貫してアクセスチェックを行います。
デリバラブルごとに2つの承認モードをサポートします：
利便性のための共有リンクを提供できますが、デフォルトで非公開にします：有効期限付きトークン、任意のパスワード、取り消し機能など。共有はクライアント境界をバイパスしてはいけません——そのユーザーが通常見られる項目だけにアクセスを与えるべきです。
クライアント承認機能は明確さが命です。チームやクライアントが「誰が何を待っているか」を把握できなければ承認は停滞し、「承認済み」が議論の的になります。
全員が認識しやすい少数のステータスから始めます：
エッジケースごとにステータスを増やしすぎないでください。より細かいニュアンスが必要ならタグ（例：「legal review」）で対応します。
各アップロードを不変のバージョンとして扱います。ファイルをその場で置き換えず、v1、v2、v3… として同じアセットに紐づけます。
これにより会話が明確になり（"v3を更新してください"）、誤って上書きしてしまう事故を防げます。UIでは現在のバージョンを明示し、過去バージョンを比較できるようにします。
自由記述コメントだけでは整理がつきません。次のような構造を加えます：
動画のタイムコードやPDF／画像のページ／領域ピンをサポートすると、フィードバックが圧倒的に実行可能になります。
誰かが承認を行ったら、次を記録します：
承認後のルール：通常は承認済みバージョンを編集不可にしますが、マイナーな修正を新しいバージョンとして作成できる（これによりステータスがIn Reviewに戻る）ようにして、承認の正当性を保ちつつ実務上の柔軟性を担保します。
クリエイティブ承認は適切なファイルに素早くアクセスできるかにかかっています。アセット管理は多くのキャンペーンアプリが地味に破綻する箇所です—遅いダウンロード、わかりにくいファイル名、最終版がどれかわからないループ。
分かりやすいパターンは：実ファイルはオブジェクトストレージ（高速・スケールしやすく廉価）、メタデータはデータベース（検索可能で構造化）にすること。
データベースにはアセット名、タイプ、キャンペーン、現在のバージョン、アップロード者、タイムスタンプ、承認ステータス、プレビューURLなどを持たせ、ストレージレイヤーはバイナリとサムネイル等の派生物を保管します。
多くのワークフローをカバーする小さなセットを目指します：
UIで何がアップロード可能か、何がリンクのみかを明示すると失敗やサポートコールが減ります。
プレビューはレビューを速くし、クライアントフレンドリーにします。生成すべきもの：
これによりステークホルダーはフル解像度を落とさずに一覧で目を通せます。
ファイル制限は早めに決めます（最大サイズ、キャンペーンあたりの最大数、対応拡張子）。拡張子だけで判断せず、ファイルタイプと内容を検証します。エンタープライズクライアントや大容量ファイルを扱う場合はウイルス／マルウェアスキャンの導入を検討してください。
承認は追跡可能性が求められます。「削除」が何を意味するかを決めます：
キャンペーン終了後12～24ヶ月保持などのポリシーを組み合わせて、保管コストが無制限に増えないようにします。
クライアント承認付きキャンペーンアプリは特別なインフラを必要としません。必要なのは役割分担の明確さ：人間向けの使いやすいUI、ルールを強制するAPI、ファイルとデータの保管、そしてリマインダーなどの時間ベース処理を行うワーカーです。
チームが自信を持って構築・運用できるものから始めます。既にReact＋Node、Rails、Djangoに慣れているならそれがv1に最適です。ホスティングはデプロイの簡便さやログ、スケーリング、シークレット管理のしやすさで選びます。
一から重めに組む代わりにプロトタイプを早く回したいなら、vibe-codingプラットフォームのようなツール（例：Koder）を使ってワークフロー（キャンペーン、アセット、承認、ロール）をチャット駆動でプロトタイプし、準備ができたらソースをエクスポートする方法もあります。
フロントエンド（Webアプリ）： ダッシュボード、キャンペーンタイムライン、レビュー画面。APIと通信し、リアルタイムのUX（ロード、アップロード進捗、コメントスレッド）を扱います。
バックエンドAPI： ビジネスルールの真実のソース—誰が承認できるか、いつアセットがロックされるか、どの状態遷移が許可されるかを管理します。煩雑にせず予測可能に保ちます。
データベース： キャンペーン、タスク、承認、コメント、監査イベントを格納。
ファイルストレージ＋プレビュー生成： アップロードはオブジェクトストレージに保管し、サムネイルやプレビューを生成してクライアントが大きなファイルをダウンロードせずにレビューできるようにします。
バックグラウンドジョブ： ユーザーの操作をブロックしない作業（メール送信、プレビュー生成、定期リマインダー）を処理します。
多くの場合、モジュラーなモノリスが最適です：1つのバックエンドコードベースの中でモジュール（アセット、承認、通知）を明確に分けます。真に有用な箇所（専用ワーカープロセスなど）だけをサービス化すれば良く、最初から多数のデプロイに分ける必要はありません。
通知は一等機能として扱います：アプリ内＋メールで、オプトアウトとスレッド表示を提供。ジョブキュー（BullMQ、Sidekiq、Celeryなど）によりリマインダーを確実に送信し、失敗のリトライを行い、アップロードや承認処理を遅延させないようにします。
初めから3つの環境を計画します：
データ側に深く踏み込みたい場合は /blog/data-model-and-database-design を参照してください。
整ったデータモデルは、キャンペーンアプリを成長させてもシンプルに感じさせる鍵です。目的は共通画面（キャンペーン一覧、アセットキュー、承認ページ）を高速かつ予測可能に保ちながら、後で必要になる履歴を記録することです。
業務に即した小さなテーブルセットから始めます：
IDはUUIDでも数値でも一貫性を持たせます。重要なのは子レコード（clients、campaigns、assets）がorganization_idを持ち、データ隔離を強制できることです。
ステータスだけでは何が起きたかわかりません。次のようなテーブルを追加します：
これにより監査トレイルと説明責任が取りやすくなりますが、コアテーブルを膨らませずに済みます。
多くの画面はclient、status、due_dateでフィルタします。次のようなインデックスを追加します：
さらに「今レビューが必要なもの」向けに複合インデックス（organization_id, status, updated_at）も検討します。
スキーマ変更はすべてマイグレーションで管理し、テンプレート（デフォルトステージ、サンプルステータス、標準承認ステップ）を数件シードしておくと、新しいエージェンシーが素早く始められ、テスト環境も現実的なデータになります。
クライアント承認アプリは信頼が命です：クライアントはシンプルなログインを望み、チームは正しい人だけが正しい作業にアクセスしていると確信したい。まずはエージェンシー向けに十分な最小限の認証機能を実装し、必要に応じて拡張します。
クライアントが時折ログインするユーザーが多いなら、メール＋パスワードが最もスムーズです。大規模組織やエンタープライズ向けには**SSO（Google／Microsoft）**を検討し、後から両方をサポートしても構いません。SSOを必須にするのは特に要望がある場合に限定します。
招待は迅速でロール指定ができ、寛容に扱います：
マジックリンクでパスワード設定を促すパターンは、新規ユーザーが覚える負担を減らします。
安全なセッション管理（短命なアクセストークン、ローテーションするリフレッシュトークン、可能ならhttpOnlyクッキー）を使い、期限付き単回使用のトークンでのパスワードリセットフローを実装します。
認証は「あなたは誰か？」に答えます。認可は「何ができるか？」に答えます。キャンペーンアセット、コメント、承認に対するあらゆるエンドポイントで権限チェックを行い、UI上で要素を隠すだけに頼らないでください。
監査に役立つログ（ログイン試行、招待受諾、ロール変更、疑わしい活動）は保持しますが、秘密情報は記録しないでください。識別子、タイムスタンプ、IP／デバイスのヒント、結果をログに残し、生ファイル内容やパスワードは絶対に記録しないでください。
通知はキャンペーンアプリを有用にするか煩わしくするかの分かれ目になります。目標はシンプル：作業を停滞させず、すべてのコメントを受信箱の火事にしないこと。
まずは小さく高信号なトリガーセットから始め、一貫性を保ちます（メール・アプリ内共通）：
各通知には「何が起きたか」と次に取るべきアクションへの直接リンク（アセットレビュー画面やクライアントインボックス）を含めます。
役割によって欲しい通知の量は異なります。ユーザー単位で制御させます：
スマートなデフォルトを設定：クライアントは内部チームより少ないメールを好み、通常は自分の判断待ちの項目だけ気にします。
類似の更新はまとめて送信します（例：「Homepage Bannerに3件の新コメント」）。ガードレール：
専用のApproval Inboxページはクライアントが対応すべきものだけを示します："あなたの対応待ち"、期日、ワンクリックで該当レビュー画面に入れる導線。これをシンプルかつアクセスしやすくし、すべてのレビュー通知メールからリンクします（例：/approvals）。
メールは必ず届くとは限りません。配信状況（送信済み、バウンス、失敗）を保存し、賢くリトライします。メールが失敗したら管理者に可視化し、アプリ内通知でフォールバックしてワークフローが黙って停滞しないようにします。
クライアントがクリエイティブを承認するということは、単にボタンを押す以上の行為です。あなたのアプリはその決定の履歴を見つけやすく、理解しやすく、後から争いにくくするべきです。
アクティビティフィードを2レベルで実装します：
エントリは非技術者にも読みやすく一貫したフォーマットにします：誰が、何を、いつ、どこで。例：「Jordan (Agency) が Homepage Hero v3 をアップロード — 12月12日 14:14」や「Sam (Client) が Homepage Hero v3 を承認 — 12月13日 09:03」。
説明責任のために次を保存します：
実務ルール：イベントがデリバラブル、タイミング、クライアントのサインオフに影響する場合は監査トレイルに残します。
監査イベントは原則不変にします。修正が必要なら新しいイベント（例：「Agencyが承認を再オープン」）を記録して履歴を書き換えないでください。表示上の誤字修正などは編集を許す場合でも、その編集が行われたことはログに残します。
最終承認バージョン、承認タイムスタンプ、主要フィードバック、アセットへのリンクをまとめた簡単なサマリー（PDFまたはCSV）をエクスポートできるようにすると、プロジェクト完了時やクライアント側のチーム変更時に便利です。
これがうまく機能すれば、混乱を減らし双方を保護し、キャンペーン管理ソフトを複雑ではなく信頼できるものにします。
レポーティングと連携はスコープを膨らませやすい機能です。コツは、チームが日々の運用に使う最小セットを先に出し、利用実績に基づいて拡張することです。
まずはシンプルなビュー（ウィジェット）で週間のステータスチェックと日次のトリアージをサポートします：
その後、キャンペーンヘルスの軽量指標を追加します：
完璧な予測は不要です。明確なシグナルと一貫したルールがあれば十分です。
連携は手作業を減らすためのもので、失敗の新しい原因を作るべきではありません。ユーザーの日常習慣に基づいて優先順位を付けます：
公開APIをすぐ出さなくても、拡張戦略を定義しておきます：
Phase 1: コアダッシュボード＋保留／期限切れリスト。
Phase 2: ヘルス指標＋サイクルタイム傾向。
Phase 3: 1～2の高インパクト連携（通常はメール＋Slack）。
Phase 4: Webhookとパートナー向けAPI。
課金ティアでレポーティングや連携を分けるなら、シンプルで透明に保ってください（参照：/pricing）。より早いMVPパスを求めるなら、プロトタイピングツールのKoderを使い、承認ワークフローを“planning mode”で反復し、ホストビルドを使ってフィードバックを得て、スナップショットでロールバックしながら要件を洗練することも可能です。
より深いワークフローパターンについては /blog を参照できます。
まずコアの問題を定義しましょう：承認やフィードバックがメール／チャット／共有ドライブに散在していることです。v1ではブリーフ、アセット、フィードバック、承認を一箇所に集約し、関係者がすぐに以下のことに答えられるようにします：
承認のターンアラウンド時間やリビジョン回数など、測定可能な成果指標を使ってスコープを絞り込みましょう。
以下の4つの代表的なグループに向けて設計します：
内部ユーザーだけを最適化すると、クライアントの利用や承認速度が落ちることが多いです。
ワークフロー上の摩擦に直結する少数の指標を選びます：
v1ローンチ後にこれらを計測して改善を検証しましょう。
実用的なv1に含めるべきは：
高度なレポーティング、深い連携、オートメーションルール、カスタム承認パスは利用状況を見てから後回しにしましょう。
ワークフローを少数のコアオブジェクトでモデル化します：
そして承認ライフサイクル（例：Draft → Internal review → Client review → Approved）を定義し、各状態が誰に何を要求するかを明確にします。
フィードバックは必ずアセットの特定バージョンに結び付けて、どのファイルがレビューされたかの議論を避けます。具体的には：
構造化することでフィードバックが実行可能になり、手戻りが減ります。
ナビゲーションは一貫した階層にします：クライアント → キャンペーン → デリバラブル（アセット）。主要な“デイリードライバー”画面は：
検索やフィルタは「クライアント」「期日」「ステータス」「担当者」といった実際の問いに即したものにします。
まずシンプルなロールで始めます：
権限はオブジェクト単位（キャンペーン、アセット、コメント、承認）で定義し、「最小権限」をデフォルトにします。UIで隠すだけでなくバックエンドでチェックを必ず行ってください。
各アップロードを不変のバージョン（v1、v2…）として扱い、ファイルを上書きしないでください。承認時には以下のメタデータを記録します：
承認されたバージョンは通常ロックしますが、正当な理由があれば新しいマイナーバージョンを作成してステータスを再び「In Review」に戻せるようにすると、承認の防御性を保ちながら調整が可能です。
v1に必要十分なアーキテクチャは次のとおりです：
多くの場合、モジュラーなモノリス＋ジョブワーカーの構成が運用しやすく、v1としては過剰分割よりも推奨されます。