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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

記録すべき内容

プロジェクトパスポートは、100項目ものフィールドを持つデータベースにする必要はありません。その目的は、コンテキストを素早く提供することです。

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

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

オーナーを割り当てる

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

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

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

作業環境を構築する

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

ビジネスアセット

まず、どのMetaアセットがすでに存在し、誰が管理しているのかを記録します。

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

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

これにより、将来チーム構成が変わったときにも対応しやすくなります。

ブラウザプロファイル

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

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

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

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

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

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

プロキシと接続

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

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

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

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

支払い

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

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

ここでもアクセスはロールベースにすべきです。従業員には、自分のタスクを遂行するために本当に必要な情報だけを提供するべきです。

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

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

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

Facebook広告向け追加リソースの入手先

広告プロジェクトの立ち上げやスケールには、アンチディテクトブラウザだけでは十分でない場合があります。そのような場合は、 CrazyFB.shop を確認することをおすすめします。Facebook広告での作業に役立つ追加リソースを見つけられる専門ストアです：

• Facebookアカウント；
• Business Manager / BM；
• ファンページ；
• モバイルプロキシ；
• 広告向け支払いソリューション。

Undetectable browser と組み合わせて使用すると、より完全な作業インフラを構築しやすくなります。ブラウザはプロファイル、環境の分離、チームアクセスを処理し、CrazyFB.shop はプロジェクトに必要なリソースを補完するのに役立ちます。

チームの作業環境を構築または拡張する必要がある場合は、 CrazyFB.shop にアクセスし、プロジェクトのニーズに合うソリューションを選ぶことをおすすめします。

作業環境に追加されるすべての構成要素は、理想的には特定のプロジェクト、目的、担当チームメンバーに紐づけられているべきです。

サードパーティサービスを使用する場合は、その利用規約、Metaの要件、適用される法律についても独自に確認することが重要です。

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

セットアップが完了すると、プロジェクトは従業員にとって、つながりのない情報の寄せ集めではなく、すぐに使える作業環境として見えるべきです。

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

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

Profile 1 New Profile Test DE

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

ClientA_DE_Main

または：

Brand_GEO_Project_Owner

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

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

ルールはシンプルです。名前だけで、そのオブジェクトが何なのかを、チャットで追加質問せずに理解できるようにすることです。

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

作業開始前にメディアバイヤーが把握しておくべきこと

Ads Managerを開く前に、担当者はすでに次のことを把握しているべきです：

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

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

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

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

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

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

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

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

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

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

必要最小限のアクセスという原則は、スタック全体で有用です。1つのプロジェクトを担当する人が、通常チーム所有のすべての環境を閲覧できる必要はありません。

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

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

プロジェクトが適切に整理されていれば、引き継ぐ担当者が最初に次のように尋ねる必要はありません：

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

引き継ぎは、シンプルな手順に沿って進められます：

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

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

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

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

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

一部の問題は、引き継ぎ後にしか現れません。

元従業員が「念のため」にアクセスを保持している、プロジェクトパスポートが更新されていない、重要な情報が個人チャットの中に残っている、といったことがあります。

移行後は、次の点を確認します：

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

これにより、プロジェクトを不確かな中間状態に残すのではなく、引き継ぎに明確な終点を設けられます。

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

プロジェクトが完全に準備できたと判断する前に、次を確認します：

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

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

ツールの寄せ集めから機能するシステムへ

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

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

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

チーム自身は、それらの要素を1つの運用システムへと結びつける必要があります。

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

それこそが、チームがFacebook広告キャンペーンだけでなく、その周辺の作業全体をスケールできる理由です。