For AI agents: a documentation index is available at /docs/llms.txt. Append .md to any page URL for markdown, or send Accept: text/markdown.
RBAC のベストプラクティス
Amplitudeのロールベースアクセス制御（RBAC）システムは、すべてのAmplitude製品と機能にわたって権限を統一します。 これらのベストプラクティスは、組織の成長に伴って一貫性と拡張性、監査性を維持できるように、プロジェクトレベルのアクセスを設計および管理する方法を示しています。 ロール、権限、アクションの背後にある概念や、権限に関する完全なリファレンスについては、「ロールベースのアクセス制御（RBAC）」を参照してください。
Amplitudeのプロジェクト
Amplitudeでは、プロジェクトによってユーザーが表示または変更できるデータ、ユーザーが使用できるAmplitude製品と機能、ユーザーがそのプロジェクト内で実行できるアクションが定義されます。
プロジェクトごとに権限を設定および管理すると、組織内のユーザーはプロジェクト内のAmplitude製品全体に一貫したアクセス権限を取得できます。
システムアーキテクチャ
これらのガイドラインに従って、RBAC を実装することで、組織のアクセス要件とセキュリティ要件を満たすことを確認してください。
グループをデフォルトの管理層として使用
グループは、大規模なアクセス管理の基盤です。 Amplitudeでは、グループが次のことを定義します：
- グループのメンバーがアクセスできるプロジェクトです。
- これらのプロジェクトでユーザーが保持する役割。
- 適用されるすべてのデータアクセス制御。
グループのすべてのメンバーは、同じプロジェクトに対する同じアクセス権セットを継承します。 これにより、オンボーディング、オフボーディング、監査を簡素化できます。
管理方法を混在させないでください
ユーザーがグループに属している場合、そのユーザーの権限が手動で上書きされたものではなく、そのグループから派生していることを確認してください。
直接的な役割割り当ては必要な場合にのみ使用する
グループメンバーシップによる管理が現実的でない場合にのみ、個々のユーザーレベルの権限を使用してください。例えば：
- 契約者または臨時協力者。
- 読み取り専用アクセスを必要とする経営者。
- サービスまたはシステムアカウント。
ユーザーに直接アクセス権を割り当てる場合は、その理由を社内で文書化してください。
一貫性を保つ
可能な限り、各ユーザーをグループまたは個別に管理してください。同じユーザーに対して両方の方法を使用することは避けてください。
組織全体で役割を標準化
プロジェクトや製品全体に適用できる、コアで再利用可能な役割の小規模なセットを定義します。これにより、共有メンタルモデルが作成され、管理上のオーバーヘッドが削減されます。 役割、使用目的、権限の例については、次の表を参照してください。
| 役割 | 対象ユーザー | 権限の概要 |
|---|---|---|
| ビューア | 経営陣、関係者 | 割り当てられたプロジェクト内のすべてのAmplitude製品への読み取り専用アクセス |
| アナリスト | PM、アナリスト | グラフとダッシュボードのみの作成と共有が可能（データモデルや実験の編集は不可） |
| データガバナー | データスチュワード、管理者 | イベントタクソノミー、トラッキングプラン、および製品間の命名規則を管理 |
| エンジニア | 実験オーナー、機能開発者 | 実験期間の機能フラグ、実験設定、および検証を管理 |
| グロースマーケティング担当者 | ライフサイクルとアクティベーションチーム | ガイドとサーベイ、CDPオーディエンス、コホート同期を管理 |
シンプルに保つ
ほとんどの組織は、5～7つのロールを設定することでうまく運用できています。カスタムロールを追加するのは、ガバナンスやコンプライアンスが必要な場合にのみ行います。
デザイングループ
グループは、AmplitudeのRBACシステムにおけるスケーラブルなアクセスの基盤です。 Amplitudeは、以下のことを考慮することにより、機能と範囲を1つの論理構造に統合するグループを推奨しています。
- 組織内のユーザーがAmplitudeをどのように使用しているか。
- これらのユーザーがアクセスする必要があるプロジェクト。
ワークフローとプロジェクト範囲の両方にグループをアンカー
グループを計画する際には、以下のことを把握したグループを設計してください。
- 組織内のチームがAmplitudeをどのように使用しているか。
- 各チームがアクセスできるプロジェクト。
チームの機能やユースケースと、チームが業務を行うために必要なデータやプロダクトのコンテキストの両方を考慮してください。
各グループは、そのグループのメンバーが何をしているか、どこでそれを行っているかを必ず記述してください。
グループをプロジェクトの範囲と目的に沿ったものに保つ
適切に設計されたグループは、明確な機能、一連のプロジェクト、一貫した役割を提供します。
これを実現するには：
- 各グループに必要な特定のプロジェクトを割り当てます。 ワークスペース全体へのアクセス権を付与することは避けてください。
- チームが複数のプロジェクトで作業している場合は、同じグループ内でそれらのプロジェクトを割り当ててください。
- アクセスを明確かつ監査可能な状態に保つため、グループの重複やネストを避けてください。
明確で一貫性のある命名法を適用する
役割とプロジェクトの範囲を反映した予測可能で読みやすい命名形式を使用してください：
Function / Use Case - Role - Projects
次の表に、この形式を使用したグループ名のリストを示します。
| グループ | ユーザー |
|---|---|
| プロダクト分析 - アナリスト（ウェブアプリ + iOSアプリ） | ウェブとモバイルの両方でグラフやダッシュボードを作成するアナリスト。 |
| 実験のオーナー - エンジニア（Androidアプリ） | Android プロジェクトで機能フラグを作成したり実験したりするエンジニア。 |
| マーケティング業務 - グロースマーケティング担当者（ウェブアプリ） | ウェブアプリのガイド、サーベイ、コホート同期を管理するマーケティング担当者。 |
| データガバナンス協議会 - データガバナー（すべてのプロジェクト） | タクソノミーと追跡計画を管理するデータ管理者。 |
名前付けの一貫性があるため、グループに所属するユーザーや、そのユーザーがアクセスできるコンテンツや機能が明確になります。
メンバーシップを管理しやすい状態に保つ
グループをアクセスの青写真とみなしてください。 それぞれに明確な目的、所有権、ライフサイクル管理が必要です。
- グループのメンバー数は10〜50人に制限してください。
- プロジェクトの役割や責任が異なる場合は、グループを分割します。 たとえば、
Experimentation - Engineer - Android AppまたはExperimentation - Engineer - iOS Appです。 All AnalystsやMarketing Teamのような何でも含めてしまう包括的なグループは避けてください。キャッチオールグループは混乱を引き起こし、Amplitude環境の一部を過度に露出させる可能性があります。
これは役に立ちましたか？