Skip to main content
Enterprise プラン (Business または Enterprise) では、ワークスペース設定により、オーナーと管理者がワークスペース内のすべてのメンバーに対して、アプリと Superagents の動作を一元的に管理できます。すべてのアプリで SSO を強制したり、ロールまたはグループごとに公開権限を設定したり、AI アシスタントの MCP アクセスを制御したり、組織に適さない場合は Superagents を完全に無効化したりできます。

アプリへの SSO の強制

ワークスペースのオーナーと管理者は、単一のプロバイダーを通じて、ワークスペース内のすべてのアプリに SSO を強制できます。これにより、複数のアプリへのサインインが容易になり、セキュリティ基準がすべての場所で適用されます。 たとえば、会社が Base44 ワークスペース内に 10 個の異なるアプリを持っている場合、アプリアクセス用の SSO を有効にすれば、各アプリで新しいログインを作成する代わりに、全員が中央の会社の認証情報でログインできます。
重要:
  • アプリアクセス用の SSO を管理できるのは、ワークスペースのオーナーと管理者のみです。有効にすると、アプリユーザーは組織の SSO 認証情報を使用してワークスペース内のすべてのアプリにアクセスします。
  • すべてのアプリでワークスペース SSO を強制するには、ID プロバイダー (IdP) の設定に追加のリダイレクト URI を追加する必要があります: https://app.base44.com/api/workspace_apps/{{WORKSPACE_ID}}/auth/sso/callback
ワークスペース内のすべてのアプリで SSO を設定するには:
  1. ワークスペース SSO を設定します。
  2. アカウントの左下にあるワークスペース名をクリックします。
  3. Settings をクリックします。
  4. Governance をクリックします。
  5. Apps SSO トグルをクリックします。このトグルは、ワークスペース SSO の設定後にのみ表示されます。
    • 有効: すべてのアプリがワークスペース SSO 設定を使用し、アプリレベルの設定は無効になります。サインインを必要としなかったパブリックアプリも、アプリと API の両方でサインインが必須になります。
    • 無効: 既存のアプリはワークスペース SSO を維持し、引き続きサインインが必要です。新しいアプリのみが独自の認証設定を使用します。

SSO ユーザーの自動受け入れ

ワークスペースのオーナーと管理者は、SSO 経由でサインインしたときに、対象となるプライベートアプリへのアクセスを自動的に付与するワークスペースのデフォルトを設定できます。これにより、各アプリにユーザーを招待したり、個別のアクセス要求を承認したりする必要がなくなります。 これは、SSO を唯一のサインイン方法として使用しているプライベートアプリにのみ適用されます。別の方法でサインインするユーザーは、引き続き通常の招待またはアクセス要求のフローを使用します。
ワークスペースのデフォルトを設定するには Enterprise プラン (Business または Enterprise) が必要です。2026 年 10 月 1 日より前に作成されたワークスペースは、Elite プランでも設定できます。
プライベートアプリへのアクセスを自動的に付与するには:
  1. アカウントの左下にあるワークスペース名をクリックします。
  2. Settings をクリックします。
  3. Governance をクリックします。
  4. Apps SSO カードを見つけます。
  5. Auto-admit SSO users in private apps トグルをクリックします。
プライベートアプリで SSO ユーザーを自動受け入れするワークスペースのデフォルトを設定する

プライベートアプリで SSO ユーザーを自動受け入れするワークスペースのデフォルトを設定する

このワークスペース設定は、対象となるアプリのデフォルトになり、この方法で受け入れられたユーザーには user ロールが付与されます。個別のアプリごとに、そのアプリの認証設定 でデフォルトを上書きできます。独自の設定を持たないアプリは、ワークスペースのデフォルトに従います。独自の設定を持つアプリは、オンまたはオフのいずれかでその設定を維持し、その後のワークスペースのデフォルトの変更の影響を受けません。
自動受け入れの仕組み:
  • 自動受け入れは、SSO がアプリの唯一のサインイン方法である場合にのみ適用されます。別のサインイン方法を追加したり、SSO をオフにしたりすると、ワークスペースのデフォルトがオンであっても、そのアプリの自動受け入れは停止します。
  • ワークスペースのデフォルトをオフにしても、既にアクセス権を持っているユーザーは削除されません。
  • アプリダッシュボードの Users からユーザーを削除しても、そのアクセス権は取り消されません。次に SSO 経由でサインインしたときに再度受け入れられるため、代わりに ID プロバイダーで削除または停止してください。

公開権限の設定

公開権限を使用すると、アプリを公開する際に何ができるかを制御できます。公開できるかどうか、選択できる可視性レベル、およびデフォルトで設定される可視性レベルを制御します。これらのルールはロール (Owner、Admin、Editor、Guest) ごとに設定し、チームがロールと異なる権限を必要とする場合は、特定のワークスペースグループにルールを追加できます。ユーザーの公開権限が公開アクションをブロックする場合、代わりに 公開承認要求 を送信できるため、ポリシーを緩めることなく作業を進められます。
公開権限について知っておくべきこと:
  • Owner ロールは常に公開権限を持ち、任意の可視性レベルを使用できるため、その設定は変更できません。
  • 公開できないロールのメンバーでも、アプリのビルドと編集は可能です。

ロールごとの権限の設定

ワークスペースの設定から、各ロールの公開権限と可視性レベルを構成します。 ロールごとに公開権限を設定するには:
  1. アカウントの左下にあるワークスペース名をクリックします。
  2. Settings をクリックします。
  3. Governance をクリックします。
  4. Role based publishing permissions テーブルで、構成したいロールを見つけます。
  5. Can publish トグルを使用して、そのロールの公開を許可またはブロックします。
  6. Allowed visibility で、そのロールが使用できる可視性レベルを選択します。少なくとも 1 つのレベルを選択したままにしてください:
    • すべて: ロールは任意の可視性レベルを使用できます。
    • プライベート: 明示的に招待した人のみがアクセスできます。
    • ワークスペース: すべてのワークスペースメンバーがアクセスできます。
    • 公開(ログイン必須): ワークスペース外のユーザーを含む、Base44 アカウントを持つすべての人がアクセスできます。
    • 公開(ログイン不要): インターネット上の誰でもアクセスできます。アカウントは不要です。
  7. Default visibility で、そのロールを持つユーザーが公開したときに自動的に選択される可視性レベルを選択します。前の手順で許可したレベルからのみ選択できます。
ロールごとの公開権限

ロールごとに公開権限を設定する

すべてのロールを元の設定に戻すには、Reset to defaults をクリックします。これはロールの行のみをリセットし、グループルールには影響しません。

グループの権限の設定

同じロールを持つ他の全員とは異なる公開権限を、特定のチームだけに設定したい場合があります。たとえば、すべての Editor に公開アプリの公開を開放することなくマーケティングチームに許可したい場合や、他の Editor をブロックせずに外部委託者の公開を止めたい場合です。グループルールを使えばこれが可能です。ルールを持つグループのメンバーは、ロールのルールではなくグループのルールに従います。
グループルールの仕組み:
  • グループルールは既存の ワークスペースグループ を使用します。グループは、ワークスペース設定の Members and groups で管理されます。
  • 各グループには 1 つのルールを設定できます。変更するには、ルールの行を編集するか、ルールを削除して新しいルールを追加します。
  • ルールを持つ複数のグループに所属しているユーザーは、それらのルールの最も許容度の高い組み合わせに従います。
  • グループルールは Owner には影響しません。Owner は常に公開できます。
  • ワークスペースで ID プロバイダー (IdP) グループがオフになっている場合、IdP グループのルールには Inactive バッジが表示され、適用されません。
グループの公開権限を設定するには:
  1. アカウントの左下にあるワークスペース名をクリックします。
  2. Settings をクリックします。
  3. Governance をクリックします。
  4. Group based publishing permissions の下にある Add rule をクリックします。
  5. Search for a group ボックスで対象のグループを見つけ、そのチェックボックスを選択します。
  6. Add をクリックします。
  7. ルールの行で、グループの権限を設定します:
    • Can publish トグルを使用して、公開を許可またはブロックします。
    • Allowed visibility で、グループが使用できる可視性レベルを選択します: Public、Private、Workspace。
    • Default visibility で、グループメンバーが公開したときに自動的に選択される可視性レベルを選択します。
Group based publishing permissions カードが囲まれた Governance ページのスクリーンショット

グループの公開権限を設定する

グループのルールを削除するには、その行の削除アイコンをクリックします。そのグループのメンバーは、再びロールの権限に従います。
ガバナンス追跡のため、公開権限の変更は、すべてのアプリの公開、非公開、公開承認要求のイベントとともに、ガバナンスルールの変更としてワークスペースの監査ログに記録されます。これらのイベントは Audit Logs API で取得できます。

公開リクエストの処理

ワークスペースのメンバーが公開しようとしたが、ロールまたはグループルールのいずれかによって権限が許可されていない場合、ブロックされる代わりに公開要求を送信できます。あなたと他のワークスペースオーナーおよび管理者は、メールと、ワークスペース上部の Bell アイコン の下にある Base44 通知で通知されます。通知をクリックするとエディターでアプリが開き、いずれかがメンバーに代わってレビューして公開できます。 メンバー側では、アプリエディターの Publish パネルに Request to publish ボタンが表示されます。このボタンをクリックすると短い要求フォームが開き、アプリに希望する可視性を選択し、必要に応じてレビュアーへのメッセージを追加し、Send request をクリックします。
アプリの公開承認を要求する

アプリの公開承認を要求する

各要求には、メンバーのメールアドレス、要求された可視性、およびメッセージが表示されます。

MCP アクセスの管理

MCP を使用すると、Claude や ChatGPT などの AI アシスタントがアプリに接続して操作できます。ワークスペースのオーナーまたは管理者として、ワークスペース内のアプリがこの接続を提供できるかどうか、および AI アシスタントが先にサインインする必要があるかどうかを選択します。個別のアプリで MCP を設定するには、AI アシスタントをアプリに接続する を参照してください。 MCP アクセスを管理するには:
  1. アカウントの左下にあるワークスペース名をクリックします。
  2. Settings をクリックします。
  3. Governance をクリックします。
  4. MCP access for AI assistants の下でポリシーを選択します:
    • 許可: アプリはサインインの有無にかかわらず MCP 接続を提供できます。
    • サインイン必須: アプリは MCP 接続を提供できますが、AI アシスタントはサインインする必要があります。
    • 不許可: ワークスペース内のアプリは MCP 接続を提供できません。
AI アシスタントの MCP アクセス

ワークスペースの MCP アクセスポリシーを選択する

ポリシーの変更は即座に適用されます。アプリを再公開する必要はありません。不許可 を選択すると、すでに接続されている AI アシスタントは、次にアプリを呼び出したときにアクセスを失います。

アプリのチャネルの制御

アプリは、WhatsApp、Slack、Telegram、LINE、iMessage、メールなどのチャネルを通じて、ワークスペース外の人にメッセージを送信したり、受信したりできます。データ入出力ポリシーを使用すると、アプリがどのチャネルを使用できるかを決められます。このポリシーは、後で構築されるアプリを含め、ワークスペース内のすべてのアプリに適用され、ポリシーがオンの間はビルダーが上書きすることはできません。
データ入出力ポリシーを設定するには Enterprise プランが必要です。Business プランには含まれません。Enterprise プランが有効でなくなった場合、設定は保存されますが、再度アップグレードするまでポリシーの強制は停止します。

チャネルポリシーの設定

ポリシーをオンにしてから、ワークスペース内のアプリが使用できるチャネルを選択します。 ワークスペースポリシーを設定するには:
  1. アカウントの左下にあるワークスペース名をクリックします。
  2. Settings をクリックします。
  3. Governance をクリックします。
  4. Data in & out タブをクリックします。
  5. Workspace policy カードで Turn on をクリックします。
  6. Communication channels テーブルで、Access トグルを使用して各チャネルを許可またはブロックします。
ポリシーを初めてオンにしたとき、ワークスペースで使用できるすべてのチャネルは許可された状態で始まります。そのため、アプリがすでに利用しているものは停止しません。不要なチャネルはそこからオフにしてください。 各チャネルには、Base44 のどの部分がそれを使用できるかが表示されます:
コミュニケーションチャネルのテーブルが表示された、Data in and out タブのワークスペースポリシーのスクリーンショット

アプリが使用できるチャネルを選択する

ワークスペースポリシーについて知っておくべきこと:
  • チャネルをブロックすると双方向のメッセージが停止するため、アプリはそのチャネルへの送信も受信もできなくなります。
  • テーブルに表示されるチャネルは異なる場合があり、上記より少ないことがあります。テーブルには、ワークスペースが実際に使用できるチャネルのみが表示されます。
  • コネクターはこのポリシーの対象外です。コネクターは、ワークスペース設定の Connectors ページから個別に管理します。
  • ポリシーをオフにすると、すべてのアプリが再びすべてのチャネルを使用できます。

ポリシーの例外の追加

1 つのアプリがすべてのチャネルを使い続ける必要がある場合は、例外として追加します。例外は制限なしで動作するため、アプリがポリシー外での動作を本当に必要とする場合にのみ追加してください。 ポリシー例外を追加するには:
  1. アカウントの左下にあるワークスペース名をクリックします。
  2. Settings をクリックします。
  3. Governance をクリックします。
  4. Data in & out タブをクリックします。
  5. Policy exceptions カードで Add exception をクリックします。
  6. Search apps ボックスで対象のアプリを見つけ、そのチェックボックスを選択します。
  7. (オプション) Reason フィールドに、アプリがポリシーをスキップする必要がある理由を記入します。
  8. Add exception をクリックします。
アプリリストとオプションの Reason フィールドが表示された Add an exception ダイアログのスクリーンショット

アプリのポリシー例外を追加する

例外を追加できるのは、ワークスペースポリシーがオンの間のみです。アプリによるポリシーのバイパスを停止するには、Policy exceptions カードでアプリ名の横にある削除アイコンをクリックします。

アプリの埋め込みの制御

他のウェブサイトは、公開済みのアプリを iframe 内に表示できます。たとえば、会社のサイトにアプリを配置する場合です。
ポリシーを設定する前に:
  • ワークスペースの埋め込みポリシーを設定するには Enterprise プラン (Business または Enterprise) が必要です。変更できるのは、ワークスペースのオーナーと管理者のみです。
  • アプリを構築する人は誰でも、アプリ独自の埋め込み設定で制限を追加できますが、ポリシーを緩めることはできません。

埋め込みポリシーについて

ワークスペースの埋め込みポリシーは、後で構築されるアプリを含め、ワークスペース内のすべてのアプリを埋め込めるウェブサイトを決定します。仕組みは次のとおりです:
  • 各ウェブサイトは先頭に https:// または http:// を付けて追加します。サイトのすべてのサブドメインを許可するには、https://*.example.com のように先頭にワイルドカードを付けます。
  • 埋め込みはページ単位ではなくウェブサイト単位で許可され、最大 50 個のウェブサイトを追加できます。
  • 変更によって埋め込みが厳しくなる場合、Base44 は先に確認を求めます。すでにアプリを埋め込んでいるウェブサイトはすぐに動作しなくなるためです。
  • ワークスペースは Anyone から始まり、各アプリが自分で決定します。ポリシーを選択するまで何も制限されません。
  • Only these sites または No one を選択すると、各アプリの埋め込み設定に Managed by your workspace と表示されます。Only these sites では、すべてのアプリがリストを使用します。アプリを No one に設定することはできますが、独自のウェブサイトを追加することはできません。

埋め込みポリシーの設定

Governance 設定から、ワークスペース内のアプリを埋め込める人を選択します。 アプリを埋め込める場所を設定するには:
  1. アカウントの左下にあるワークスペース名をクリックします。
  2. Settings をクリックします。
  3. Governance をクリックします。
  4. App embedded in iframe で、アプリを埋め込める人を選択します:
    • Anyone: どのウェブサイトでもこのワークスペースのアプリを埋め込めます。
    • Only these sites: 追加したウェブサイトのみがこのワークスペースのアプリを埋め込めます。Allowed websites に各ウェブサイトを入力して Enter キーを押します。
    • No one: どのウェブサイトもこのワークスペースのアプリを埋め込めません。
  5. Base44 から変更の確認を求められたら、Apply をクリックします。
Anyone、Only these sites、No one のオプションが囲まれた App embedded in iframe カードのスクリーンショット

ワークスペースの Governance 設定にある App embedded in iframe カード


Superagents の管理

ワークスペースメンバーが Superagents を作成、アクセス、または操作できないようにすることができます。この設定を有効にすると、Superagents はワークスペース全体のすべてのメンバーから非表示になります。 これは、組織が AI エージェントの使用を承認していない場合や、Superagents を特定のチームに段階的に展開したい場合に便利です。
ワークスペースの Superagents を有効または無効にできるのは、ワークスペースのオーナーと管理者のみです。
ワークスペースで Superagents を無効化するには:
  1. アカウントの左下にあるワークスペース名をクリックします。
  2. Settings をクリックします。
  3. Overview をクリックします。
  4. Disable Superagents トグルを有効にします。
Disable Superagents トグルが強調表示されているワークスペースの Overview ページのスクリーンショット

ワークスペースで Superagents を無効化する


FAQ

ワークスペースでのアプリの管理について詳しく知るには、以下の質問を選択してください。
強制が有効になっている場合、既存のアプリは自動的にワークスペース SSO 設定を使用します。アプリレベルの SSO 設定はロックされ、ワークスペースのオーナーと管理者のみが管理できます。
いいえ。ワークスペース SSO の強制が有効になっている場合、すべてのワークスペースアプリは会社の SSO プロバイダーを使用します。アプリビルダーは、管理者が強制を無効にした場合にのみ、SSO 設定を選択できます。
はい。ワークスペースのポリシーで制限されていない限り、いつでもアプリの設定でアプリの可視性を変更できます。
社内アプリと顧客向けアプリの両方を持つ組織では、ワークスペースを次のように構成します:ワークスペースレベル:
  • ワークスペース SSO: ON (従業員は会社の認証情報を使用)
  • Apps SSO トグル: OFF (グローバルに強制しない)
アプリレベル:
  • 社内アプリ: 個別にワークスペース SSO を有効化
  • 顧客向けアプリ: 独自の認証 (メール/パスワード、Google) と適切な可視性制御を使用
これにより、社内ツールを保護しながら、顧客アプリのアクセス性を維持する柔軟性が得られます。
アプリレベルの認証設定は新しいワークスペースに引き継がれますが、以下の点に留意してください:
  1. ワークスペースの Apps SSO トグルがオンになっている場合、ワークスペース SSO はアプリレベルの認証設定を即座に上書きします。
  2. 既存のアプリユーザーは保持されますが、アプリが以前、新しいワークスペースで構成されていないログイン方法 (異なるリダイレクト URI を持つカスタム SSO など) を使用していた場合、認証が再構成されるまでアプリユーザーはログインの問題に直面する可能性があります。
  3. アプリにコネクター (Google、Slack などへの OAuth 接続) が設定されており、それらがアプリ自体ではなく設定した個人に紐付いている場合、それらの接続は新しいワークスペースコンテキストで再認可する必要がある場合があります。
このページは AI によって翻訳されました。最も正確で最新の情報については、英語版 を参照してください。