Facebook広告チーム：プロジェクト立ち上げから引き継ぎまで

立ち上げから引き継ぎまで：2026年にFacebook広告チームのワークスペースを整理する方法

Facebook広告プロジェクトが、単一の広告アカウントだけで構成されることはほとんどありません。チームは、Meta Business Portfolio（現在でも一般的にBusiness ManagerまたはBMと呼ばれます）、Facebookページ、Instagram、ブラウザプロファイル、プロキシ、支払い方法、社内メモ、そして従業員ごとのアクセス権限レベルも扱う場合があります。

プロジェクトが2つか3つだけなら、これらの関係を覚えておくのは簡単です。しかしチームが成長するにつれ、記憶は管理システムとして機能しなくなります。ある担当者はどのプロファイルがどのクライアントのものかを覚えており、別の担当者は支払い情報の保存場所を知っていて、さらに別の担当者だけがプロジェクトの現在の構成を理解している、という状態になりがちです。

これは、新しい従業員が参加するときや、プロジェクトを別のメディアバイヤーに引き継ぐ必要があるときに特に顕著になります。作業を始めるために複数のスプレッドシートを開き、過去の会話を検索し、同僚に何度も質問しなければならないなら、問題はツールの数ではありません。問題は、それらのツールがどのように整理されているかです。

だからこそ、スケーリングはシンプルな目標から始めるべきです。どのチームメンバーでも、どのアセットがプロジェクトに属しているのか、作業環境がどこにあるのか、誰がアクセスできるのか、そして誰が最新状態を保つ責任者なのかを理解できるようにすることです。

Facebook広告プロジェクトのライフサイクル：セットアップ → 作業 → チームアクセス → 引き継ぎ

Facebook広告プロジェクトは広告アカウント以上のもの

プロジェクトは、ひとつの作業コンテキストとして考えるほうが有用です。

含まれる可能性があるもの：

• Metaのビジネスアセット；
• ブラウザ環境；
• ネットワーク接続；
• 支払い方法；
• チームメンバーとアクセス権限レベル；
• 現在のプロジェクトステータス；
• 未完了タスク；
• 社内メモ。

すべてのプロジェクトにすべての要素が必要なわけではありません。重要なのは、使用されている要素同士の関係が明確であることです。

従業員が広告アカウントは確認できても、どのページがそれに紐づいているのか、どのブラウザプロファイルを使うのか、誰が支払いを担当しているのか、現在のステータスをどこで確認できるのかが分からない場合、そのプロジェクトは口頭の知識に依存しすぎています。

チームが大きくなるほど、その依存は高くつきます。

プロジェクトパスポートから始める

コンテキストを維持する最もシンプルな方法のひとつは、短いプロジェクトパスポートを作成することです。

それはCRMカード、スプレッドシート、社内ドキュメント、タスク管理の記録などで構いません。形式そのものよりも、チームが現在のプロジェクト情報の情報源として認識する場所がひとつあることが重要です。

記録すべき内容

プロジェクトパスポートを、100項目もあるデータベースにしてはいけません。その目的は、コンテキストを素早く提供することです。

構成をテストする簡単な方法があります。プロジェクトに初めて参加する人が、1分以内に主要な構成要素と作業環境の場所を理解できる必要があります。

それに複数の同僚へメッセージを送る必要があるなら、構成を改善する必要があります。

オーナーを割り当てる

すべてのプロジェクトにはオーナーが必要です。つまり、現在の状態を理解し、セットアップを説明できる人です。

メディアバイヤー、デザイナー、アナリスト、チームリードが同じプロジェクトに関わることはあります。それ自体は普通です。ただし、パスポート、ステータス、アクセス情報を最新に保つ人は必要です。

そうでなければ、プロジェクトは徐々に「全員のもの」になり、実質的には誰のものでもなくなります。

作業環境を構築する

基本構造が定義できたら、チームはプロジェクトの作業スタックを組み立てられます。

ビジネスアセット

まず、既に存在するMetaアセットと、それを誰が管理しているかを文書化します。

プロジェクトでBusiness Portfolio/BM、広告アカウント、Facebookページ、Instagram、その他のアセットを使用する場合、所有権とアクセス権は最初から明確にしておくべきです。

Metaが公式のロールと権限を提供している場合、従業員間でパスワードを繰り返し共有するよりも、通常はそのほうが管理しやすくなります。

これにより、将来のチーム変更にも対応しやすくなります。

ブラウザプロファイル

次のレイヤーはブラウザ環境です。

1人の担当者が複数のプロジェクトを扱う場合、個別のブラウザプロファイルを用意すると、セッション、Cookie、設定、ブックマーク、その他のデータを各ワークフローに紐づけて保持しやすくなります。

Undetectableはローカルプロファイルとクラウドプロファイルの両方に対応しています。

ローカルプロファイルは特定のデバイスに保存されます。クラウドプロファイルは、作業環境を複数のデバイスから利用したり、他のチームメンバーと共有したりする必要がある場合に便利です。

多数のクラウドプロファイルはグループに整理でき、そのグループへのアクセスを特定のユーザーに割り当てることができます。たとえば、環境をクライアント、GEO、またはワークストリームごとに分けられます。

これにより、ブラウザプロファイルは単なる別のブラウザウィンドウではなく、プロジェクトの明確に定義された構成要素になります。

プロキシと接続

ワークフローでプロキシを使用する場合、たとえば分散チーム、テスト、その他許可されたシナリオのために使用する場合は、その接続もプロジェクト構造の一部にするべきです。

コンテキストなしに単独の行として保存されたプロキシは、すぐに「このクライアントに使っていたはずのIP」になってしまいます。

プロジェクトパスポートには関連する接続タイプまたは識別子だけを記録し、プロキシ自体は適切なブラウザプロファイルに紐づけることができます。

これにより、従業員が毎回その関係を手作業で再構築する必要がなくなります。

支払い

支払い方法にも明確な所有者が必要です。

チームは、それがどのプロジェクトと広告アカウントに関連するのか、どの通貨が使われるのか、誰が費用を監視するのか、請求に関する質問の責任者は誰なのかを理解しておくべきです。

ここでもアクセスはロールベースにするべきです。従業員には、業務を遂行するために本当に必要な情報だけを付与する必要があります。

プロジェクトスタックを完成させる

中核となる関係が文書化されると、プロジェクトに既にあるリソースと、まだ準備が必要な構成要素を把握しやすくなります。

たとえば、クライアントがBusiness Portfolio、広告アカウント、ページを提供し、チームがブラウザ環境やその他の作業ツールを独自に整理する場合があります。

ブラウザプロファイルとチームアクセスはUndetectableで整理できます。選択したワークフローにFacebookアカウント、Business Manager/BM、ファンページ、モバイルプロキシ、広告向けの支払いソリューションも必要な場合、これらのカテゴリは**CrazyFB.shop**のような専門ストアで入手できます。

特定の構成要素の入手元が、全体の整理原則を変えるべきではありません。プロジェクトに追加されたものはすべて、ただちにそのパスポート、目的、責任を持つチームメンバーに紐づけられるべきです。

サードパーティサービスを利用する場合、チームは製品規約、アセットの権利、支払い要件、Metaのポリシー、適用法も独自に確認する必要があります。

1つのプロジェクト、1つの明確なコンテキスト

セットアップが完了したら、プロジェクトは従業員にとって、切り離された情報の集まりではなく、すぐに作業できる環境として見えるべきです。

一貫した命名ルールが役立ちます。

次のような名前ではなく：

プロファイル1 新規プロファイル テスト DE

次のような名前を使います：

ClientA_DE_Main

または：

Brand_GEO_Project_Owner

唯一の正しい命名形式があるわけではありません。重要なのは、チーム全体が同じロジックに従うことです。

同じ原則は、プロファイルグループ、社内メモ、フォルダ、プロジェクトカードにも適用できます。

ルールはシンプルです。名前を見れば、チャットで追加質問をしなくても、そのオブジェクトが何かを理解できるようにすることです。

クライアントA → プロファイルグループ → ブラウザプロファイル → ビジネスアセット → オーナー

メディアバイヤーが作業開始前に確認すべきこと

広告マネージャを開く前に、担当者は既に次のことを把握しているべきです。

• どのプロジェクトに取り組んでいるのか；
• どのビジネスアセットがそのプロジェクトに属しているのか；
• どのブラウザプロファイルを使うのか；
• 必要な場合、どの接続がその環境に属しているのか；
• 自分にどの権限があるのか；
• 誰が支払いを担当しているのか；
• 現在どのタスクが進行中なのか；
• アクセス変更が必要なときに誰へ連絡すべきか。

小規模チームにとっては、これは余計な管理作業に見えるかもしれません。実際には、複数の従業員とプロジェクトが同時に動き始めた時点で、こうした基本ルールは時間を節約します。

「どのプロファイルがうちのもの？」や「正しいBMを送って」と聞く代わりに、担当者はプロジェクトパスポートを開き、必要なコンテキストをすぐに得られます。

2人目の従業員が参加すると何が変わるか

これは多くの場合、運用システムに対する最初の本格的なテストです。

プロジェクトのコンテキストがすべて最初のメディアバイヤーのコンピュータと個人メモの中だけにある場合、別の人を追加することは手作業の移行になります。

設定を移し、構成を説明し、現在の情報を探し、過去の判断を再構築する必要があります。

チームワークフローでは、一部の環境をUndetectableのクラウドプロファイルで整理できます。

プロファイルはプロジェクトまたはワークストリームごとにグループ化でき、特定のグループへのアクセスは実際に必要なユーザーに付与できます。

その結果、作業環境は単一のコンピュータと単一の人物への依存が少なくなります。

最小限必要なアクセスの原則は、スタック全体で有効です。ひとつのプロジェクトに割り当てられた人は、通常、チームが所有するすべての環境を閲覧する必要はありません。

混乱なくプロジェクトを引き継ぐ方法

引き継ぎは、どの社内システムにとっても有用なストレステストです。

プロジェクトが適切に整理されていれば、引き継ぐ担当者は次の一言から始める必要はありません。

「全部どこにありますか？」

引き継ぎは、シンプルな手順に沿って行えます。

1. プロジェクトパスポートを更新する。
2. ビジネスアセットと現在のアクセス権を確認する。
3. 必要なブラウザプロファイル、またはそのグループへのアクセスを移管する。
4. 接続と作業設定を確認する。
5. 現在のタスクとプロジェクトステータスを記録する。
6. 新しいオーナーまたはバックアップオーナーを割り当てる。
7. 移管完了後、以前の権限を確認する。

引き継ぎの目的は、認証情報だけでなくコンテキストを移すことです。

引き継ぐ担当者がアクセス権を受け取っても、プロジェクトの構造をまだ理解していないなら、引き継ぎは完了していません。

引き継ぎ：現在のオーナー → プロジェクトパスポート + ワークスペース → 新しいオーナー

引き継ぎ後に確認すべきこと

問題の中には、引き継ぎ後になって初めて現れるものがあります。

元従業員が「念のため」アクセスを保持している、プロジェクトパスポートが更新されない、重要な情報がプライベートな会話の中に残っている、といったケースです。

移管後は、次の点を確認します。

• 新しいオーナーがパスポートに記録されている；
• 以前の権限が見直されている；
• 適切な従業員が作業環境にアクセスできる；
• ステータスとメモが最新である；
• 未完了タスクが移管されている；
• 重要な情報が前任者のデバイス上だけに保存されていない；
• チームが、今誰がプロジェクトの責任者なのかを把握している。

これにより、プロジェクトを不確かな中間状態のままにせず、引き継ぎに明確な終点を持たせることができます。

すぐに作業できるワークスペースのチェックリスト

プロジェクトが完全に準備できたと判断する前に、次の点を確認してください。

• プロジェクトに明確な名前とオーナーがある；
• 主要なビジネスアセットが1か所に文書化されている；
• ロールと権限が従業員の責任に合っている；
• ブラウザプロファイルを簡単に識別できる；
• プロキシまたはその他の接続を使用している場合、それが正しい環境に紐づいている；
• 支払い構造が責任を持つチームメンバーにとって明確である；
• 現在のステータスと未完了タスクが文書化されている；
• 重要な情報がプライベートチャットの中だけに存在していない；
• プロジェクトを別の担当者に引き継ぐための明確なプロセスがある。

チームが過去の会話を探し回らずにこのチェックリストを完了できるなら、そのワークスペースは成長に向けてはるかによく準備されています。

ツールの集まりから機能するシステムへ

Facebook広告チームは何十ものサービスを利用できますが、ツールの数はプロセスの品質をほとんど示しません。

重要なのは、すべての構成要素に明確な場所があることです。ビジネスアセットはプロジェクトに紐づき、ブラウザ環境は特定のワークフローに紐づき、アクセス権はチームメンバーに紐づき、重要な変更はチャット履歴の中だけに存在しない状態です。

この構成において、Undetectableはローカルおよびクラウドプロファイル、プロファイルグループ、チームアクセス管理を通じて、ブラウザ環境のレイヤーを担うことができます。

ただし、チーム自身がそれらの要素をひとつの運用システムに接続する必要があります。

プロジェクトを開き、理解し、新しい従業員と共有し、別の担当者に引き継ぎ、過去のメッセージからコンテキストを再構築することなく継続できるなら、そのプロセスは意図どおりに機能しています。

それこそが、チームがFacebook広告キャンペーンだけでなく、その周辺業務もスケールできるようにするものです。