リファレンスアーキテクチャ

これらは推奨する構成例であり、顧客事例ではありません。自社に最も近いパターンを選び、必要に応じて調整してください。

1. マルチブランドグループ

複数のブランドのウェブサイトを持ち、それぞれに専任のチームがいる持株会社。

Organization: Group
├── Site: brand-a   (Development, Production)   editors: Brand A team
├── Site: brand-b   (Development, Production)   editors: Brand B team
└── Site: brand-c   (Development, Production)   editors: Brand C team
Approvers: group digital team (organization admins) + one reviewer per brand

• 1 つの組織に、ブランドごとに 1 サイト。 コンテンツ、メディア、トークン、メンバーがサイト間で共有されることはありません。
• 各ブランドは、独自のコンポーネントとデザイントークンを持つ自社のウェブサイトのコードとコントラクトを維持します。Atlas が共通のデザインを強制することはありません。
• ブランドの編集者には、そのサイトに限定したロールを付与します。本番リリースは、グループのデジタルチームが承認します。
• 各ウェブサイトに専用の配信トークンと Webhook があるため、あるブランドのデプロイや障害が他のブランドに影響することはありません。

2. 規制のある、または承認の多い企業

金融、医療、エネルギー、政府関連など、すべての公開変更に承認が必要なチーム。

• 編集者とマーケティング担当者が下書きを作成し、レビュー担当者／公開担当者が開発環境で公開し、より少人数のグループが本番リリースを承認します。
• 重要な操作には、スマートフォンでの承認を有効にします。
• すべてのリリースはチェックされ（コントラクトの同期、公開時の問題なし、サイトの正常性、最新のバックアップ）、署名されます。ロールバックは 1 回の操作です。
• コンプライアンス記録のために、監査ログをエクスポートします。
• 公開前にリードの保持ルールを合意してください。なお、保持と CRM への送信は、現時点では開発環境のリードのみが対象です。
• ホスティング先の所在地とデータ保持について、ご契約前に確認してください（セキュリティをご覧ください）。

3. クライアントのウェブサイトを運営する制作会社

複数のクライアント向けにサイトを構築・保守する制作会社。

• クライアントごとに 1 組織とすることをお勧めします。各クライアントが自社のデータ、メンバー、プランを所有できます。制作会社のスタッフはメンバーとして招待します。
• 自社のコンポーネントのライブラリをコードで構築し、クライアントごとのデザイントークンを使って、各クライアントのコントラクトで再利用します。
• コンテンツ移行には、MCP 経由の AI コーディングエージェントを使い、クライアントのレビュー担当者が公開します。
• 引き渡しも安全です。クライアントの編集者が変更できるのは型付きフィールドだけで、コードには決して触れません。

4. 単一の企業サイト

1 つの企業サイト、小規模なマーケティングチーム、外部の開発者。

• 1 つの組織に 1 つのサイト。開発者がウェブサイトを接続し、コントラクトを一度だけ作成します。
• マーケティングチームがページ、ニュース、翻訳を編集し、マーケティングリーダーが本番リリースを承認します。
• 開発者が必要になるのは、新しいコンポーネントやページタイプのときだけです。

すべてのパターンに共通すること

• ウェブサイトのコード、ホスティング、デプロイは、お客様の手元に残ります。
• まず開発環境。本番環境には、承認されたリリースを通じてのみ反映されます。
• Atlas に接続できなくてもサイトが稼働し続けるよう、組み込みのフォールバックを用意します。
• 配信トークンはサーバー上に置き、有効期限が切れる前にローテーションします。