アカウントとアクセス

アカウントには、プロジェクト、チームメイト、1つのアクセスモデルが含まれます。

アカウントには、プロジェクトと、そのプロジェクトで働く人々が含まれます。サインアップすると、Beeuniが個人アカウントを作成します。チームメイトを招待すると、チームアカウントになります。個人アカウントとチームアカウントで、ロール、請求、上限は共通です。

1つのアクセスモデル

Beeuniには、アクセス付与のレコードが1種類あります。割り当てです。すべての割り当ては、1つのプリンシパルを、1つのスコープで1つのロールに結び付けます。

別のアクセス付与ストアはありません。グループのアクセス、リソース単位の付与、カスタムロールの割り当ては、すべて割り当てです。違いはプリンシパル、オブジェクト、ロールだけです。

アカウントロール

アカウント内の各ユーザーは、アカウントロールを1つ持ちます。

• オーナー — メンバー管理や請求を含む、すべての操作を行えます。
• 管理者 — プロジェクト、メンバー、グループ、ロール、トークンを管理します。
• メンバー — プロジェクト割り当てを持つプロジェクトでのみ作業できます。

オーナーと管理者は、アカウント内のすべてのプロジェクトで、マネージャーと同等のアクセス権を持ちます。プロジェクト割り当てでこれを制限することはできません。特定のプロジェクトでオーナーや管理者のアクセスを制限するには、まずアカウントロールをメンバーに変更してください。

マネージャーと同等のアクセス権には、メンバーのプライベートセッションは含まれません。アカウントオーナーは、Settings → Security の Admins can open every session をオンにすると、オーナーと管理者にそのアクセスを許可できます。変更できるのはオーナーのみで、使用のたびに監査記録が残ります。セッションアクセスを参照してください。

アカウントのメンバーページからメールでチームメイトを招待します。招待はpendingプリンシパルへの割り当てです。招待を承諾すると、user割り当てになります。

プロジェクトロール

プロジェクト内では、プリンシパルは次の2つのロールのいずれかを持ちます。

• メンバー — プロジェクトを読み取り、セッションを開始・停止し、トリガーを実行できます。編集や設定はできません。
• マネージャー — プロジェクトのすべての権限を持ちます。プロジェクトの編集、トリガー、コネクター、スキル、シークレット、アクセスの管理、ゲートウェイキーの保持、プロジェクトの削除ができます。

プロジェクトロールはこの2種類のみです。

マネージャーは、プロジェクトのすべての権限を持ちます。カスタムロールでできるのは権限の追加のみなので、マネージャーから権限を取り上げるロールは作れません。オブジェクト割り当ては、権限が「どのオブジェクト」に及ぶかを絞り込む別の仕組みです。

プロジェクトのアクセス設定から、またはbeeuni accessでプロジェクトアクセスを設定します。CLIを参照してください。

グループ

グループはユーザーと同じく、プリンシパルです。スコープでグループにロールを割り当てると、そのグループの全メンバーがそのロールを持ちます。グループはアクセスを追加するもので、個人がすでに持っているアクセスを取り消すことはありません。SCIMでプロビジョニングされたグループも、手動で作成したグループと同じ種類のプリンシパルです。

オブジェクト割り当て

割り当てでは、プロジェクト内の1つのオブジェクトを指定できます。対象はagent、skill、secret、app、またはtriggerです。Beeuniは現在、エージェントとスキルに対するオブジェクト割り当てを適用します。

• エージェントはデフォルトでアクセスが閉じられています。 メンバーがエージェントにアクセスできるのは、そのメンバー、自身が属するグループ、またはプロジェクト内の全員を指定した割り当てがある場合のみです。
• それ以外のオブジェクトはすべて、デフォルトでアクセスが開かれています。 オブジェクトに割り当てがなければ、メンバーはアクセスできます。割り当てがある共有コネクターアカウントは、指定されたユーザーだけが利用できます。共有アカウントを使えるユーザーを選ぶを参照してください。
• プロジェクト内の全員もプリンシパルです。 Grant access ダイアログで、プロジェクト名に続く Everyone in を選ぶと、すべてのメンバーに一度にエージェントを付与できます（principal_type: "project"、principal_id = プロジェクトID）。このプリンシパルが持つのはオブジェクト割り当てのみで、ロールは持ちません。そのため、各ユーザーは自分のプロジェクトロールを維持します。
• オブジェクト割り当ては、プロジェクトマネージャーも制限します。 これにより「このエージェントの対象を経理グループに限定する」という設定が意味を持ちます。マネージャーロールで得られるのは、オブジェクト割り当てがない場合のデフォルトアクセスであり、制限の免除ではありません。
• アカウントのオーナーと管理者は、オブジェクト割り当てによる制限を受けません。独自の割り当てに基づいて動作するサービスアカウントも同様です。

オブジェクト割り当て自体は権限を持ちません。「どの操作ができるか」ではなく、「どのオブジェクトが対象か」を指定します。

有効期限

割り当てにexpires_atを設定すると、その時点でアクセス付与が停止します。エンジンは期限切れの割り当てを無視しますが、監査証跡のためレコードは残ります。

1つの用語体系、2つのバインディング

ユーザー、グループ、エージェントは、ここで説明した割り当て、つまりロールを通じてBeeuniからアクセスを得ます。エージェントには、もう1つ独立したバインディングがあります。agents.<name>.beeuni_permissionsのbeeuni.yamlでマニフェストが宣言するBeeuni権限です。セッションで実行できるのは、両方が許可する操作だけです。どちらかがもう一方の範囲を広げることはありません。マニフェストにproject.secret.readが記載されたエージェントでも、ロール判定で拒否されれば何も読み取れません。オーナーが起動したエージェントでも、マニフェストにその操作が記載されていなければ何も読み取れません。ロールはアカウントの状態であり、Beeuni権限はマニフェスト内のリポジトリの状態です。マニフェストリファレンスを参照してください。

エージェントのセッションに適用されるロールは、エージェント自身のサービスアカウントに割り当てられたロール、つまりその上限です。割り当てがない場合は、デフォルトのエージェント上限が適用されます。セッションを開始したユーザーのロールは適用されません。project.credentials.issueという権限は人間専用で、エージェントには決して付与されません。エージェントが付与できるのは、自身が持つ権限だけです。管理者はアクセスハブの Agents で、エージェントをプロジェクトロールのプリンシパルに選びます。エージェントの権限を参照してください。

カスタムロール

カスタムロールは、アカウントが所有する、選択した権限を持つロールです。割り当てると、単一の割り当てが作成され、その下に組み込みの基本ロールのレコードが作成されることはありません。組み込みプロジェクトロールがなくても、カスタムロールでプロジェクトアクセスを付与できます。部署向けのロールは、この方法で機能します。

カスタムロールでできるのは権限の追加のみです。Beeuniに拒否ルールはありません。

カスタムロールには、エンタープライズrbacの利用権が必要です。利用権がない場合、割り当て時に402へcode: "entitlement_required"が返されます。

スーパー管理者

スーパー管理者はロールではなく、1つのアカウントメンバーシップに設定するフラグです。すべての権限チェックを迂回し、迂回するたびに監査ログに記録されます。通常のアクセスにはロールを使い、スーパー管理者は監査対象の緊急用アクセス手段として使います。

アカウント作成者は、オーナー兼スーパー管理者として開始します。オーナーを降格すると、オーナーロールとスーパー管理者フラグも一緒に解除され、その変更はiam.member.super_admin.revokeとして記録されます。オーナーでないユーザーに付与されたスーパー管理者フラグは、オーナーが取り消すまで有効です。

シングルサインオンのドメイン

SAML IDプロバイダーは、各ユーザーのメールアドレスを提示します。Beeuniは、アカウントで検証済みのドメインに限り、アカウント外でもそのアドレスを信頼します。検証されるまでは、次のようになります。

• IDプロバイダー経由でサインインしたユーザーは、引き続きアカウントに参加し、所属グループが適用されます。
• そのユーザーのSSO IDは、別のアカウントからの招待には一致せず、別のアカウントの「メールでメンバーを追加」でも見つかりません。
• SSOでサインインしても、既存のIDがSSO IDに統合されることはありません。
• Enforce SSO は効果がなく、そのドメインではパスワードでのサインインも引き続き利用できます。

ドメインを検証するには、アカウント設定で Identity を開きます。SSOカードに、DNS TXTレコードの名前_beeuni-verification.<your-domain>と値beeuni-verification=<token>が表示されます。DNSプロバイダーで公開してから、Verify domain（POST /v1/accounts/:accountId/iam/sso/provider/verify-domain）を選択します。1つのドメインを登録できるのは1つのアカウントのみです。別のアカウントで検証済みのドメインを、再度検証することはできません。プライマリドメインを変更すると、検証前の新しい申請が始まります。

検証済みのドメインで Enforce SSO をオンにすると、Webのサインインフォーム、/v1/access/check-email、ヘッドレスの/v1/auth/sign-in/password、/v1/auth/sign-in/magic-link、/v1/auth/verify-otpルートでは、そのドメインに対するパスワードとメールコードでの認証がすべて拒否されます（403 sso_required）。

検証済みのドメインでも、SSOでのサインインによってオーナーやスーパー管理者がSSO IDに統合されることはありません。既存のIDはそのまま維持され、SSO IDは別のメンバーとして参加します。

機能ごとのアクセス設定

一部の機能には、ロールモデルに加えて独自の可視性設定があります。

各設定は、1つのリソースへのアクセスを絞り込みます。どの設定も、ロール判定で拒否された権限を付与するものではありません。

アクセスAPI

カタログは固定リストではなくデータです。各権限には、action、scope_type、resource_type、delegableフラグ、description、area、level、impliesが含まれます。アクション文字列をハードコードせず、カタログを読み取ってください。

書き込みルートでは、付与しようとしている内容に基づいて必要な権限が選択されます。プロジェクトロールまたはオブジェクト割り当てにはproject.members.manage、connection割り当てにはproject.connector.connections.manage、アカウントロールにはmember.update、カスタムロールにはpolicy.createが必要です。別のルートを選んで上限を回避することはできません。

ブランディング

Enterpriseアカウントでは、すべてのメンバー向けに、横長ロゴ、正方形アイコン、ファビコンをそれぞれ独自ブランドに設定できます。各画像にはダークモード用の画像も設定でき、ブラウザーのタブタイトルで「Beeuni」に代わる製品名も指定できます。Account → Branding（/accounts/{accountId}?tab=branding）を開きます。PNG、JPEG、WebP、SVG、ICO形式の画像を最大1 MBまでアップロードできます。ロゴがない場合はアイコンが代わりに使われ、ファビコンがない場合はアイコンが使われます。ダークモード用の画像がない場合は、ライトモード用の画像が使われます。アプリ内のロゴはアプリのテーマに従い、ファビコンはオペレーティングシステムの配色設定に従います。

ブランディングはブラウザーではなくアカウントに紐付きます。プロジェクト内では、そのプロジェクトを所有するアカウントのブランドがメンバーに表示されます。サインインするまではブランディング対象となるアカウントがないため、サインインページ、メール、公開共有ページには引き続きBeeuniのブランドが表示されます。Enterpriseの利用権が失効すると、メンバーには再びBeeuniが表示されます。データは削除されず、アカウントはいつでもアップロードした画像を削除できます。

GET /v1/accountsは各アカウントの有効なbrandingを返します。利用権がある場合はレコード、ない場合はnullです。クライアントは、すでに行っている1回のリクエストでブランドを表示できます。SDKではbeeuni.accounts.branding.{get, update, uploadAsset, removeAsset, reset}を使用します。

アカウントの切り替え

複数のアカウントに所属している場合は、アカウント切り替えメニューからアカウントを切り替えます。各アカウントは、それぞれ独自のプロジェクト、メンバー、設定を保持します。

サインイン済みデバイス

Settings → Security → Devices には、ブラウザー、デスクトップアプリ、モバイルアプリなど、サインインしているすべての場所が表示されます。

• 1台のデバイスで Sign out を選ぶと、そのデバイスのサインインがただちに終了します。トークンを更新できなくなり、アカウント関連ルートで使用できなくなります。スマートフォンではプッシュ通知も届かなくなります。
• Sign out other devices を選ぶと、他のすべてのデバイスのサインインが終了します。それらのデバイスではトークンを更新できなくなり、スマートフォンではプッシュ通知もただちに届かなくなります。

スマートフォンで再度サインインすると、プッシュ通知も再び届くようになります。

トークン

Beeuniでは、個人アクセストークン（beeuni_pat_...）を使ってサインインします。このトークンは作成者本人として動作し、そのユーザー自身の割り当てだけを持ちます。サービスアカウント（beeuni_sa_...）は個人の認証情報とは別のプリンシパルで、割り当てによってアクセスが付与されるまで、プロジェクトへのアクセス権を持ちません。

2種類のトークンは所有者が異なるため、別々の場所で管理します。自分のAPIキーは自分だけに表示され、メンバーシップが終了すると使えなくなります。設定の Settings → API keys（/settings/tokens）で確認できます。サービスアカウントトークンはアカウント設定の Account → Tokens で、トークンの有効期限を管理するキーのルールとともに設定します。

トークンモデルの詳細は、SDK認証を参照してください。

監査ログ

監査ログには、呼び出し元が識別できたかどうかにかかわらず、APIに到達したすべてのリクエストが記録されます。サーバーは、HTTPリクエスト、WebSocketアップグレード、プレビューリクエスト、Git転送、SCIM呼び出しごとに1行を記録します。記録範囲はルートに依存しません。

各行には、リクエストで確認された呼び出し元が記録されます。

各行には、APIが認証した認証情報もcredential_kindとcredential_idに記録されます。IDで示すのは認証情報であり、シークレットではありません。Webアプリでは Via として表示され、トークン名やアプリ名がある場合は併せて表示されます。

API は X-Beeuni-Client を読み取りません。CLI、MCP サーバー、Web アプリはすべて同じ API を呼び出し、どのクライアントも任意のヘッダー値を送信できるため、ログには API が証明できる内容が記録されます。2026-09-30 より前に書き込まれた行には、自己申告の client_reported_source が含まれている場合があります。新しい行では空のままです。?credential_kind=oauth_app を GET /v1/accounts/:accountId/audit に指定して認証情報でフィルタリングするか、beeuni audit ls --credential-kind oauth_app を使用します。

2026-10 より前に書き込まれた行には、session_sequence、integrity_previous_hash、integrity_hash が含まれます。これはセッションごとのカウンターとハッシュチェーンです。新しい行では3つすべてが空のままで、これらのフィールドは非推奨です。チェーンを検証するものはなく、チェーンの維持によってセッションの書き込みがすべて直列化されていました。セッションのログは作成時刻順に並びます。session_sequence を持つ行がその順序で先に並び、その後に API が作成した順序で新しい行が続きます。

拒否されたリクエストは outcome: denied を持つ行です。metadata.auth には呼び出し元の認証方法が記録されます。トークン ID であり、秘密情報ではありません。Git クローンはアクション git.clone です。プッシュは git.push で、metadata.refs には作成、更新、削除された各 ref が一覧表示されます。

保持期間

週は月曜日 00 UTC から翌月曜日 00 UTC までです。週の最後の時点が90日前になると、その週はアーカイブに移されます。そのため、イベントは発生から90～97日の間にエクスポート専用になります。アーカイブは週の終了から365日後までイベントを保持するため、イベントの合計保持期間は365～372日です。また、保持ロックにより、それまでは Beeuni のスタッフを含め、誰もイベントを短縮または削除できません。プライバシーポリシーにも同じ上限が記載されており、アプリケーションログは最長365日保持されます。

エクスポートは、アーカイブと PostgreSQL のデータを1つのリストとして、古い順に返します。フィルター、フィールド、X-Audit-Next-Cursor ページングは同じです。どちらの読み取り経路にも auditAccess エンタイトルメントが必要です。アーカイブ済みイベントにはライブイベントと同じフィールドが含まれます。2026-10 以降に書き込まれたイベントでは、session_sequence と整合性ハッシュは空です（上記参照）。

アクション

すべての行には action があり、domain.resource.verb という名前と、Web アプリおよび beeuni audit ls が表示するタイトルが付いています。

各 API ルートにはアクションが1つだけあります。リクエストの行には metadata.http にルートテンプレートが保持され、トークンを含む可能性がある生のパスは保持されません。ハンドラーがリクエスト自身のイベントを、変更前と変更後の状態とともに記録する場合、そのイベントがリクエストの唯一の行になります。どのルートにも一致しなかったリクエストは api.route.unmatched です。

アクションのプレフィックスでフィルタリングします。GET /v1/accounts/:accountId/audit では ?action=iam.、beeuni audit ls --action iam.、または監査 Webhook の --action-prefix を使用します。監査ログのアクション には、すべてのアクションとそのタイトルが一覧表示されます。2026-09-24 より前に書き込まれた行では、アクションとして METHOD /template が使用され、同じタイトルが表示されます。

Beeuni のバックグラウンドジョブはリクエストなしで動作します。付与とトンネル権限の期限切れ、期限切れのセッションブランチの削除、App デプロイの有効化、プロジェクトのサンドボックスプロバイダー間の移動を行います。これらの行には source: worker があり、metadata.auth.worker にジョブ名が記録されます。例: tunnel-cleanup または app-deployments。App デプロイの行には、デプロイを開始したメンバーもイニシエーターとして記録されます。

あなたのプロジェクトのいずれかを指定する匿名リクエストは、あなたのログに書き込まれます。これらの行は actor_type=anonymous で選択します。匿名行には API プロセスごとのレート制限があるため、大量発生しても帰属先のある行が押し出されることはありません。ヘルスプローブ、CORS プリフライト、デプロイ済み App への匿名トラフィックは記録されません。

請求

無料プランには1つのプロジェクトと、受取後30日間有効な初回 $20 分のクレジットが含まれます。次の期間から毎月 $2 分を付与し、繰り越しはありません。クレジットはコンピューターの稼働と公式モデルに使えます。

初回クレジットは個人アカウントごとに一度だけ付与されます。以前の初回 $2 を受け取った方には差額の $18 を、未受取の方には $20 を付与します。別のチームやプロジェクトを作成しても再付与されません。購入したクレジットは別に保管され、無料クレジットの期限切れや月次更新では削除されません。

請求はアカウントレベルで適用され、そのアカウント内のすべてのプロジェクトが対象です。Beeuni では、無料ティア、プロティア、シート単位のチームティアを提供しており、それぞれ独自のモデルアクセスとクレジットがあります。自分のモデルキーを使用しても利用料金が無料になるわけではありません。無料ティアを除き、Beeuni はその料金に加えてプラットフォーム料金を請求します。