checking-member-access

メンバーのアクセス権を確認する

アクセス制御ツールを使って、「このユーザーはここで何ができますか？」という質問に答えるためのスキルです。ツールは、適用されているレベルとその根拠を返します。このスキルでは、それらを正しく読み取る方法を説明します。

このスキルを使うタイミング

• 「このメンバーはこのプロジェクトで何ができますか？」／「このメンバーは機能フラグを編集できますか？」
• 「ダッシュボードを編集できるのは誰ですか？」／「実験にアクセスできないのは誰ですか？」
• 「このメンバーがこのダッシュボードを開けないのはなぜですか？」／「このロールはどのテーブルへのアクセスを制限されていますか？」
• 「サポートロールにはどのプロパティが表示されませんか？」
• 「analyst ロールでは何が許可されますか？」／「このプロジェクトのデフォルトのアクセス権は何ですか？」

アクセスルールは、MCP の書き込みツールを使って変更することもできます。まず現在のルールを読み取り、変更内容を説明してから、準備／実行のフローを使います。実行は、ユーザーの確認を得てから呼び出してください。

プランでの利用可否

• Free プランと pay-as-you-go プランではアクセス制御を利用できず、アクセス制御ツールも提供されません。ツールがカタログにない場合は、そのプランにはアクセス制御が含まれていないと伝え、Boost プランへのアップグレードを提案してください。プランの比較はこちらです：https://posthog.com/platform-packages。
• Boost プランと Scale プランには、プロジェクト、ツール、オブジェクト、プロパティに対する、個々のメンバー向けのデフォルトレベルとルールが含まれています。
• ロールはすべてのプランにありますが、ロールルールは Enterprise の機能です。ロールルールは Enterprise でのみ設定でき、適用されます。また、3 つのロールアクセスツールも Enterprise でのみ提供されます。ツールがない場合は、ロールベースのアクセス制御には Enterprise プランが必要であると、同じリンクを添えて伝えてください。それ以外のプランでは、メンバーのロールによって適用レベルが変わることはありません。
• ツールからは、組織がどのプランを利用しているかはわかりません。members-list の結果のどこかに source_subject が role の項目があれば、ロールルールが適用されていることがわかります。そうでない場合は、ワークフローのステップ 4 でロールを確認する前に、その組織が Enterprise を利用しているかユーザーに尋ねてください。

アクセス権の解決方法

• スコープ。 プロジェクト自体、その後に各ツール（dashboard、insight、feature_flag、notebook、experiment、warehouse_objects など）、ツール内の個々のオブジェクト、最後にユーザーとイベントのプロパティが対象です。ツール名は、members-list のエントリにある resources のキーです。
• プロジェクトのレベル。 none はプロジェクトとそのリソースへのアクセスをブロックします。member は、他のルールで許可されているリソースを表示および編集できます。admin はさらに、プロジェクトの設定を編集し、プロジェクトのアクセスルールを管理し、プロジェクトを削除できます。
• ツールとオブジェクトのレベル。 none では表示できません。viewer は表示できますが変更できません。editor は表示および変更できます。manager はさらに、ツールまたはオブジェクトのアクセスルールを管理できます。順序は none < viewer < editor < manager です。
• プロパティのレベル。 none はプロパティを非表示にします。read はプロパティを表示します。read_write は編集も許可します。ルールがない場合、すべてのプロパティは read_write です。
• 上限と下限。 defaults-get にあるツールごとの minimum と maximum は、ルールで設定可能なレベルです。minimum が viewer のツールは、none に設定できません。
• 対象。 ルールは、1 人のメンバー、1 つのロール、またはプロジェクト内の全員（デフォルト）のいずれかに適用されます。
• 組織の管理者とオーナーは、すべてのプロジェクトですべてに完全にアクセスできます。これらのユーザーにはルールは適用されません。organization_level は数値で、1 は member、8 は admin、15 は owner です。
• 作成者は、自分が作成したオブジェクトにのみ完全にアクセスできます。ダッシュボードに対する viewer のメンバーでも、自分が作成したダッシュボードは編集できますが、他のダッシュボードは編集できません。
• 2 つの解決モード。 組織は、ルールを最も具体的なものから順に解決する方式（メンバーのルール、ロールルール、デフォルトの順。オブジェクトのルールはツールのルールより優先）か、レガシー方式（メンバー自身のルールとロールルールのうち、より高いレベルを優先）のいずれかを使います。どちらの方式が適用されるかはツールからはわかりません。サーバーがすでに適用しています。そのため、effective_access_level を信頼し、保存されたルールから自分で再計算しないでください。 ユーザーから理由を尋ねられた場合は、自分で優先順位を判断するのではなく、inherited_access に基づいて説明してください。

利用可能なツール

ツール	戻り値
posthog:access-control-members-list	各メンバーの、プロジェクトおよび各ツールに対する強制アクセス権。member_id を指定すると、対象をメンバーに絞り込みます。
posthog:access-control-roles-list	ロールごとの同じ情報。role_id を指定すると、対象をロールに絞り込みます。
posthog:access-control-defaults-get	プロジェクトの基本設定と、個別オブジェクトにルールを設定できるツール。
posthog:access-control-default-rule-set-prepare / posthog:access-control-default-rule-set-execute	スコープのデフォルトルールを設定または解除します。
posthog:access-control-member-rule-set-prepare / posthog:access-control-member-rule-set-execute	スコープに対する、特定メンバーのルールを設定または解除します。
posthog:access-control-role-rule-set-prepare / posthog:access-control-role-rule-set-execute	スコープに対する、特定ロールのルールを設定または解除します。
posthog:access-control-member-objects-list	メンバーに設定されたオブジェクトルール。一覧には、そのメンバーにルールが設定されたすべてのオブジェクトが含まれます。
posthog:access-control-member-properties-list	メンバーに設定されたプロパティルール。
posthog:access-control-role-objects-list	ロールに設定されたオブジェクトルール。
posthog:access-control-role-properties-list	ロールに設定されたプロパティルール。
posthog:access-control-default-objects-list	プロジェクト内の全員に適用されるオブジェクトルール。
posthog:access-control-default-properties-list	プロジェクト内の全員に適用されるプロパティルール。
posthog:org-members-list	メンバーシップ ID、名前、組織内のレベル。プロジェクトへのアクセス詳細は含まれません。
posthog:roles-list、posthog:role-members-list	ID ごとのロール名と、各ロールに所属するメンバー。

すべてのアクセス制御ツールでは、プロジェクト ID を任意で指定できます。指定しない場合は、アクティブなプロジェクトが使用されます。

ワークフロー

1. 対象の ID を確認します。 member_id は組織メンバーシップ ID です。org-members-list の id、または members-list の organization_membership_id を使います。ユーザー ID でもユーザー UUID でもありません。role_id は roles-list の id です。
2. ツールレベルの質問には、1 回の呼び出しで回答できます。「このメンバーはダッシュボードを表示できますか？」や「このメンバーはフィーチャーフラグにどのようなアクセス権がありますか？」という質問には、member_id を指定して members-list を使います。このツールの effective_access_level が完全な回答です。メンバーのロール、プロジェクトのデフォルト、バイパスがすでに含まれています。
3. inherited_access からレベルを説明します。 下の表を参照してください。保存された access_level と適用されるレベルが異なる場合に限り、access_level に言及します。
4. オブジェクトについての質問には、オブジェクトとそのルールの確認が必要です。「このメンバーはダッシュボード 42 を開けますか？」という質問には、ツールレベルだけでは回答できません。次の順に確認し、最初に該当した時点で終了します。
   1. メンバーのエントリーで organization_level が 8 または 15 の場合：フルアクセスで、ルールは適用されません。
   2. メンバーがオブジェクトを作成した場合：フルアクセスで、ルールは適用されません。ルールツールではオブジェクトの作成者がわからないため、dashboard-get や insight-get など、そのオブジェクト用の get ツールで取得し、created_by.uuid とメンバーのエントリーにある user.uuid を比較します。
   3. オブジェクトに設定されたルール：メンバーツールが返すのは、そのメンバーに設定されたルールのみです。そのため、member-objects-list、メンバーの role_ids にある各 ID の role-objects-list、および default-objects-list を取得し、このオブジェクトに該当する行を選びます。調べるロールの数をユーザーに伝え、多数のロールを持つメンバーについて調べる場合は、事前に確認を求めます。
   4. オブジェクトにルールがない場合：手順 2 のツールレベルの回答が適用されます。
5. 1 つのオブジェクトに複数のルールがある場合。 メンバー、ロール、デフォルトのそれぞれが同じオブジェクトにレベルを設定している場合、サーバーは組織の解決モードに基づいて 1 つを選択します。別のメンバーについて、その選択結果を返すツールはありません。見つかったルールをすべて対象とともに報告し、適用されるルールはモードによって決まると伝え、推測はしないでください。プロパティについての質問も手順 4 と同様ですが、プロパティには作成者がいないため、作成者の確認は不要です。
6. 「誰が……できますか？」という質問には、member_id を指定せずに members-list を使い、resources.<tool>.effective_access_level でフィルタリングします。レスポンスには、すべてのメンバーとすべてのツールの組み合わせが含まれ、ページネーションはありません。大規模な組織の場合は、まずユーザーが知りたい人を尋ねるか、メンバーごとに回答してください。

1 件のエントリーを読む

フィールド	意味
access_level	このスコープに対して、対象者自身が保存しているルールです。null は、対象者自身のルールがないことを意味します。
effective_access_level	実際に適用される内容です。null は、このスコープについて何も解決されないことを意味します。「アクセスなし」という意味ではありません。
inherited_access	対象者自身のルールがない場合に適用されるレベルと、その取得元です。適用元がない場合は null です。
inherited_access.source	ツールのルールでは resource または parent_resource、オブジェクトのルールでは object または parent_object、PostHog のデフォルトでは system_default です。org_admin と creator は前述のバイパスです。org_membership は、オブジェクト自体が組織の場合にのみ表示されます。
inherited_access.source_subject	ルールを提供した対象を示します。member、role、default のいずれかです。バイパスまたは PostHog のデフォルトが適用された場合は null です。

回答の表現方法：

• source が org_admin の場合：「このメンバーは組織の管理者であり、すべてに完全にアクセスできます。」保存済みのルールは適用されません。
• access_level が設定されており、effective_access_level と同じ場合：「このメンバーには明示的なルールが設定されています：editor。」
• access_level が null で、source_subject が role の場合：「このメンバーはロールに基づいて editor アクセス権を持っています。」ロール名はエントリーに含まれていません。必要であれば roles-list で確認できます。
• access_level が null で、source_subject が default の場合：「このメンバーはプロジェクトのデフォルトに基づいて viewer アクセス権を持っています。」
• source が system_default の場合：「どこにもルールが設定されていないため、PostHog のデフォルトが適用されます。」
• effective_access_level が null の場合：「このツールでは、ここで何も解決されません。」アクセスなしと解釈しないでください。

注意点

• 空のオブジェクトまたはプロパティリストは、その種類のルールがないことを意味するもので、アクセスがないことを意味するものではありません。ツールレベルのエントリーは引き続き適用されます。
• プロジェクトのデフォルトが none でも、メンバーまたはロールに明示的に付与された権限は削除されません。メンバーリストとロールリストを確認して、付与された権限を見つけてください。組織の管理者とオーナーには、常にプロジェクトのルールが適用されません。
• members-list にメンバーが表示されないからといって、アクセス権がないとは限りません。呼び出し元が組織の管理者ではなく、組織でメンバー同士の閲覧が禁止されている場合、呼び出し元に表示されるのはプロジェクトスコープのアクセス権を持つメンバーのみです。
• メンバーリストとロールリストの can_edit は対象者ではなく、呼び出し元について説明しています。つまり、ツールを実行するユーザーがルールを変更できるかどうかを示します。
• available_project_levels と available_resource_levels は、低い順に並んだアクセスレベルの一覧です。順序を推測せず、これらを使ってレベルを比較してください。
• defaults-get の object_rule_resources には、単一オブジェクトに対するルールを受け付けるツールが一覧表示されます。この一覧にないツールについては、オブジェクトのルールを探す必要はありません。