ロールと権限

Pathruleは個人向けのツールとして使い始め、そのままチームのプロダクトとして使えるようになります。同僚を招待すると、誰が何を閲覧・変更できるのかが問題になります。このページでは、割り当てるロール、組織からワークスペースへとアクセスを絞り込む仕組み、そしてチェックが実際にどこで行われるかを説明します。

要点をまとめると、ロールは組織レベルで割り当て、アクセスはワークスペースごとに絞り込めます。そしてPathrule Cloudのワークスペースに対するすべての読み書きは、サインイン中のユーザーに基づいてデータベースがチェックします。このチェックは、リクエストがapp.pathrule.ioのWebコンソール、Pathrule CLI、VS Code拡張機能、AIクライアントが通信するMCPサーバーのどこから来ても同じように適用されます。

--localで作成したローカルワークスペースはアカウントを持たず、1台のマシン上にのみ存在します。そのため、Cloudに移行するまではロールは適用されません。

4つのロール

ロールは組織レベルで、メンバーごとに割り当てます。OwnerまたはAdminが同僚をメールで招待してロールを選び（デフォルトはEditor）、同僚が招待を承諾すると参加できます。招待はWebコンソールのMembersから、またはターミナルから行えます。

pathrule invite colleague@example.com --role viewer

ここから、いくつかの保護ルールが導かれます。

• 所有権の変更にはOwnerの権限が必要で、組織には常にOwnerがいなければなりません。
• 所有権とメンバーの変更はサーバー側でチェックされ、Owner維持の要件もこれに含まれます。

メンバーの変更には、有効な認可済みセッションが必要です。ワークスペースのアーカイブや削除といった影響の大きい操作では、さらに再認証が求められます。

シートとプラン

組織のメンバーは、ロールに関係なく全員が1席ずつ使用します。

• SoloとProは1人用です。招待機能はなく、他の人と共同作業するにはTeamに移行します。
• Teamはオーナーを含めて最低2席からのシート単位の課金です。購入済みのシート数を超えて招待するには追加のシートが必要です。シート数がメンバー数を下回る場合、既存のメンバーは全員アクセスを維持し、新しい招待は保留になります。
• Enterpriseのシートは営業との契約で決まります。

シートと請求書はWebコンソールのBillingで確認でき、ターミナルからはpathrule billingで開けます。詳しくはPathrule Webを参照してください。

ワークスペースのアクセス：組織全体または非公開

ロールは、その人が何をできるかを決めます。ワークスペースのアクセスモードは、そもそも誰がそのワークスペースに到達できるかを決めます。各ワークスペースは次の2つのモードのどちらかです。

• 組織全体。 組織の全メンバーが、組織でのロールに応じてアクセスできます。
• 非公開。 ワークスペースに明示的に追加された人だけがアクセスできます。組織のメンバーであるだけでは不十分です。

OwnerとAdminは、Webコンソールの設定のWorkspace、Accessでモードを切り替えます。ワークスペースを非公開にすると、明示的に追加されたワークスペースメンバーだけがアクセスできるようになります。必要な人を確認して追加してください。組織のメンバーであることだけでは、もうアクセス権は付与されません。非公開ワークスペースでは、その人がそこで何をできるかはワークスペースでのロールで決まります。そのため、他の場所とは異なるレベルのアクセスを与えることができます。

アクセスを失ってもデータは失われない

権限を変更しても作業内容が消えることはなく、見えなくなることもほとんどありません。

• 書き込み権限を失った場合（たとえばEditorからViewerに変更された場合）、何も消えません。それまで閲覧できたものはすべて引き続き閲覧できますが、本人による書き込みや、本人として動作するアシスタントによる書き込みは拒否されます。
• ワークスペースへのアクセスを失った場合（非公開ワークスペースや組織から外された場合）に限り、そのワークスペースのコンテンツが本人から見えなくなります。コンテンツ自体はチームに残ります。

同じ境界はアシスタントにも適用されます。メンバーが書き込めない場所にAIクライアントが書き込もうとすると、MCPのツール呼び出しは明確な権限拒否の結果を返します。これにより、黙って失敗したり成功したように見えたりすることなく、アシスタントがその旨をわかりやすい言葉で伝えられます。アシスタントが受け取るコンテキストや、Pathruleがアシスタント向けに書き出す指示ファイルは、必ずそのメンバーが閲覧できるワークスペースからのみ作られます。

チェックが行われる場所

これらの制御は、どれも利用中のアプリケーション側で行われているわけではありません。Cloudワークスペースに対するすべての読み書きは、サインイン中のユーザー、組織のメンバーシップ、ワークスペースのアクセスモードに基づいて判定されるデータベースのアクセスチェックを通ります。アクセスチェックはサーバーのデータベース操作の一部であり、画面上でボタンを隠しているだけの仕組みではありません。

• すべての画面で共通のチェック。 Webコンソール、Pathrule CLI、VS Code拡張機能、ローカルMCPサーバー、Remote MCPはすべて、同じデータベースレベルのアクセス制御を通ります。ターミナルからの変更も、AIクライアントからの書き込みも、同じルールで制御されます。
• 共有の管理キーはありません。 各画面が持つのはユーザーごとの短期間だけ有効なトークンで、他チームのデータを開けてしまうような共有サービスキーは決して使いません。クライアントが漏洩しても、到達できるのはそのユーザーがもともとアクセスできる範囲だけです。
• サーバー側での判定。 メンバーシップとワークスペースのロールはサーバー側で判定され、クライアントからの情報をそのまま信用することはありません。そのため、リクエストを改ざんしても、与えられていないアクセス権を得ることはできません。

Cloudのアクセス制御の全体像については、セキュリティの概要を参照してください。

セルフホストの場合

Enterpriseのセルフホスト版では、同じロールと権限のモデルがお客様自身のCloudflareアカウント上で動作します。ロールとワークスペースのアクセスモードの挙動は同じで、違いはデータとデータベースがお客様のアカウント内にある点です。お客様自身のIDプロバイダーを使ったシングルサインオンはEnterprise契約のもとで設定し、ここで説明した組織のロールにそのまま対応付けられます。このデプロイの仕組みについては、Enterpriseセルフホストを参照してください。