アプリへの SSO の強制
ワークスペースのオーナーと管理者は、単一のプロバイダーを通じて、ワークスペース内のすべてのアプリに SSO を強制できます。これにより、複数のアプリへのサインインが容易になり、セキュリティ基準がすべての場所で適用されます。 たとえば、会社が Base44 ワークスペース内に 10 個の異なるアプリを持っている場合、アプリアクセス用の SSO を有効にすれば、各アプリで新しいログインを作成する代わりに、全員が中央の会社の認証情報でログインできます。 ワークスペース内のすべてのアプリで SSO を設定するには:- ワークスペース SSO を設定します。
- アカウントの左下にあるワークスペース名をクリックします。
- Settings をクリックします。
- Governance をクリックします。
- Apps SSO トグルをクリックします。このトグルは、ワークスペース SSO の設定後にのみ表示されます。
- 有効: すべてのアプリがワークスペース SSO 設定を使用し、アプリレベルの設定は無効になります。サインインを必要としなかったパブリックアプリも、アプリと API の両方でサインインが必須になります。
- 無効: 既存のアプリはワークスペース SSO を維持し、引き続きサインインが必要です。新しいアプリのみが独自の認証設定を使用します。
SSO ユーザーの自動受け入れ
ワークスペースのオーナーと管理者は、SSO 経由でサインインしたときに、対象となるプライベートアプリへのアクセスを自動的に付与するワークスペースのデフォルトを設定できます。これにより、各アプリにユーザーを招待したり、個別のアクセス要求を承認したりする必要がなくなります。 これは、SSO を唯一のサインイン方法として使用しているプライベートアプリにのみ適用されます。別の方法でサインインするユーザーは、引き続き通常の招待またはアクセス要求のフローを使用します。ワークスペースのデフォルトを設定するには Enterprise プラン (Business または Enterprise) が必要です。2026 年 10 月 1 日より前に作成されたワークスペースは、Elite プランでも設定できます。
- アカウントの左下にあるワークスペース名をクリックします。
- Settings をクリックします。
- Governance をクリックします。
- Apps SSO カードを見つけます。
- Auto-admit SSO users in private apps トグルをクリックします。

プライベートアプリで SSO ユーザーを自動受け入れするワークスペースのデフォルトを設定する
自動受け入れの仕組み:
- 自動受け入れは、SSO がアプリの唯一のサインイン方法である場合にのみ適用されます。別のサインイン方法を追加したり、SSO をオフにしたりすると、ワークスペースのデフォルトがオンであっても、そのアプリの自動受け入れは停止します。
- ワークスペースのデフォルトをオフにしても、既にアクセス権を持っているユーザーは削除されません。
- アプリダッシュボードの Users からユーザーを削除しても、そのアクセス権は取り消されません。次に SSO 経由でサインインしたときに再度受け入れられるため、代わりに ID プロバイダーで削除または停止してください。
公開権限の設定
公開権限を使用すると、アプリを公開する際に何ができるかを制御できます。公開できるかどうか、選択できる可視性レベル、およびデフォルトで設定される可視性レベルを制御します。これらのルールはロール (Owner、Admin、Editor、Guest) ごとに設定し、チームがロールと異なる権限を必要とする場合は、特定のワークスペースグループにルールを追加できます。ユーザーの公開権限が公開アクションをブロックする場合、代わりに 公開承認要求 を送信できるため、ポリシーを緩めることなく作業を進められます。ロールごとの権限の設定
ワークスペースの設定から、各ロールの公開権限と可視性レベルを構成します。 ロールごとに公開権限を設定するには:- アカウントの左下にあるワークスペース名をクリックします。
- Settings をクリックします。
- Governance をクリックします。
- Role based publishing permissions テーブルで、構成したいロールを見つけます。
- Can publish トグルを使用して、そのロールの公開を許可またはブロックします。
- Allowed visibility で、そのロールが使用できる可視性レベルを選択します。少なくとも 1 つのレベルを選択したままにしてください:
- すべて: ロールは任意の可視性レベルを使用できます。
- プライベート: 明示的に招待した人のみがアクセスできます。
- ワークスペース: すべてのワークスペースメンバーがアクセスできます。
- 公開(ログイン必須): ワークスペース外のユーザーを含む、Base44 アカウントを持つすべての人がアクセスできます。
- 公開(ログイン不要): インターネット上の誰でもアクセスできます。アカウントは不要です。
- Default visibility で、そのロールを持つユーザーが公開したときに自動的に選択される可視性レベルを選択します。前の手順で許可したレベルからのみ選択できます。

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

グループの公開権限を設定する
ガバナンス追跡のため、公開権限の変更は、すべてのアプリの公開、非公開、公開承認要求のイベントとともに、ガバナンスルールの変更としてワークスペースの監査ログに記録されます。これらのイベントは Audit Logs API で取得できます。
公開リクエストの処理
ワークスペースのメンバーが公開しようとしたが、ロールまたはグループルールのいずれかによって権限が許可されていない場合、ブロックされる代わりに公開要求を送信できます。あなたと他のワークスペースオーナーおよび管理者は、メールと、ワークスペース上部の Bell アイコン の下にある Base44 通知で通知されます。通知をクリックするとエディターでアプリが開き、いずれかがメンバーに代わってレビューして公開できます。 メンバー側では、アプリエディターの Publish パネルに Request to publish ボタンが表示されます。このボタンをクリックすると短い要求フォームが開き、アプリに希望する可視性を選択し、必要に応じてレビュアーへのメッセージを追加し、Send request をクリックします。
アプリの公開承認を要求する
MCP アクセスの管理
MCP を使用すると、Claude や ChatGPT などの AI アシスタントがアプリに接続して操作できます。ワークスペースのオーナーまたは管理者として、ワークスペース内のアプリがこの接続を提供できるかどうか、および AI アシスタントが先にサインインする必要があるかどうかを選択します。個別のアプリで MCP を設定するには、AI アシスタントをアプリに接続する を参照してください。 MCP アクセスを管理するには:- アカウントの左下にあるワークスペース名をクリックします。
- Settings をクリックします。
- Governance をクリックします。
- MCP access for AI assistants の下でポリシーを選択します:
- 許可: アプリはサインインの有無にかかわらず MCP 接続を提供できます。
- サインイン必須: アプリは MCP 接続を提供できますが、AI アシスタントはサインインする必要があります。
- 不許可: ワークスペース内のアプリは MCP 接続を提供できません。

ワークスペースの MCP アクセスポリシーを選択する
ポリシーの変更は即座に適用されます。アプリを再公開する必要はありません。不許可 を選択すると、すでに接続されている AI アシスタントは、次にアプリを呼び出したときにアクセスを失います。
アプリのチャネルの制御
アプリは、WhatsApp、Slack、Telegram、LINE、iMessage、メールなどのチャネルを通じて、ワークスペース外の人にメッセージを送信したり、受信したりできます。データ入出力ポリシーを使用すると、アプリがどのチャネルを使用できるかを決められます。このポリシーは、後で構築されるアプリを含め、ワークスペース内のすべてのアプリに適用され、ポリシーがオンの間はビルダーが上書きすることはできません。データ入出力ポリシーを設定するには Enterprise プランが必要です。Business プランには含まれません。Enterprise プランが有効でなくなった場合、設定は保存されますが、再度アップグレードするまでポリシーの強制は停止します。
チャネルポリシーの設定
ポリシーをオンにしてから、ワークスペース内のアプリが使用できるチャネルを選択します。 ワークスペースポリシーを設定するには:- アカウントの左下にあるワークスペース名をクリックします。
- Settings をクリックします。
- Governance をクリックします。
- Data in & out タブをクリックします。
- Workspace policy カードで Turn on をクリックします。
- Communication channels テーブルで、Access トグルを使用して各チャネルを許可またはブロックします。

アプリが使用できるチャネルを選択する
ワークスペースポリシーについて知っておくべきこと:
- チャネルをブロックすると双方向のメッセージが停止するため、アプリはそのチャネルへの送信も受信もできなくなります。
- テーブルに表示されるチャネルは異なる場合があり、上記より少ないことがあります。テーブルには、ワークスペースが実際に使用できるチャネルのみが表示されます。
- コネクターはこのポリシーの対象外です。コネクターは、ワークスペース設定の Connectors ページから個別に管理します。
- ポリシーをオフにすると、すべてのアプリが再びすべてのチャネルを使用できます。
ポリシーの例外の追加
1 つのアプリがすべてのチャネルを使い続ける必要がある場合は、例外として追加します。例外は制限なしで動作するため、アプリがポリシー外での動作を本当に必要とする場合にのみ追加してください。 ポリシー例外を追加するには:- アカウントの左下にあるワークスペース名をクリックします。
- Settings をクリックします。
- Governance をクリックします。
- Data in & out タブをクリックします。
- Policy exceptions カードで Add exception をクリックします。
- Search apps ボックスで対象のアプリを見つけ、そのチェックボックスを選択します。
- (オプション) Reason フィールドに、アプリがポリシーをスキップする必要がある理由を記入します。
- Add exception をクリックします。

アプリのポリシー例外を追加する
アプリの埋め込みの制御
他のウェブサイトは、公開済みのアプリを iframe 内に表示できます。たとえば、会社のサイトにアプリを配置する場合です。埋め込みポリシーについて
ワークスペースの埋め込みポリシーは、後で構築されるアプリを含め、ワークスペース内のすべてのアプリを埋め込めるウェブサイトを決定します。仕組みは次のとおりです:- 各ウェブサイトは先頭に
https://またはhttp://を付けて追加します。サイトのすべてのサブドメインを許可するには、https://*.example.comのように先頭にワイルドカードを付けます。 - 埋め込みはページ単位ではなくウェブサイト単位で許可され、最大 50 個のウェブサイトを追加できます。
- 変更によって埋め込みが厳しくなる場合、Base44 は先に確認を求めます。すでにアプリを埋め込んでいるウェブサイトはすぐに動作しなくなるためです。
- ワークスペースは Anyone から始まり、各アプリが自分で決定します。ポリシーを選択するまで何も制限されません。
- Only these sites または No one を選択すると、各アプリの埋め込み設定に Managed by your workspace と表示されます。Only these sites では、すべてのアプリがリストを使用します。アプリを No one に設定することはできますが、独自のウェブサイトを追加することはできません。
埋め込みポリシーの設定
Governance 設定から、ワークスペース内のアプリを埋め込める人を選択します。 アプリを埋め込める場所を設定するには:- アカウントの左下にあるワークスペース名をクリックします。
- Settings をクリックします。
- Governance をクリックします。
- App embedded in iframe で、アプリを埋め込める人を選択します:
- Anyone: どのウェブサイトでもこのワークスペースのアプリを埋め込めます。
- Only these sites: 追加したウェブサイトのみがこのワークスペースのアプリを埋め込めます。Allowed websites に各ウェブサイトを入力して Enter キーを押します。
- No one: どのウェブサイトもこのワークスペースのアプリを埋め込めません。
- Base44 から変更の確認を求められたら、Apply をクリックします。

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

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