Jitsiルームの作成を特定の認証済みユーザーのみに制限する方法

2026年10月6日現在、Jitsiのセルフホスティングハンドブックでは、認証済みユーザーのみが会議室を作成でき、ゲストは後から参加できるという目標を引き続きサポートしています。ただし、ハンドブックでは、以前の「セキュアドメイン」手順を新規インストールでは非推奨とし、代わりにトークンベースの認証を推奨しています。適切な設定方法は、Jitsiのインストール方法によって異なります。このガイドでは、Dockerデプロイメント向けの直接的な内部認証パスと、DebianまたはUbuntuへの新規インストール向けの現在の方向性について説明します。

これらの設定は、誰がルームを開始できるかを制御するものです。ただし、すべてのルームが自動的に非公開になるわけではありません。ルームのパスワード、ロビー、招待プロセスはそれぞれ独立した設定です。

認証パスを選択してください

最新のJitsi認証ガイドでは、匿名ゲストによる認証済みルームの作成について説明していますが、以前のセキュアドメインのページでは、この方法は新規インストールでは非推奨であると明記されています。インストール方法に合ったガイドを確認せずに、古いProsodyまたはJicofoの設定を新しい環境にコピーすることは避けてください。

Docker: プロビジョニングされたユーザーのみがルームを開始できるようにする

この手順は、公式のDocker ComposeプロジェクトからJitsi Meetを既に実行しており、その.envファイルを編集できることを前提としています。以下の例では、組み込みのinternal認証モードを使用しています。公開サインアップページは追加されません。管理者が許可されたアカウントを作成および削除します。

1. 環境ファイルで認証を有効にする

Jitsi Composeデプロイメントで使用されるファイルを開きます.env。認証変数を次のように設定します。

ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

行がコメントではなく、有効な設定であることを確認してください#。 のENABLE_GUESTS=1場合、認証済みのユーザーが会議を開始した後、ログインしていないユーザーもゲストとして参加できます。すべての参加者に認証を要求する場合は、 を設定してください。ENABLE_GUESTS=0これは、ルームを作成できるユーザーだけでなく、参加できるユーザーも変更します。

Dockerガイドには、これらの変数と組み込みのアカウントワークフローが記載されています。サポートされている認証タイプとオプションの最新リストについては、Dockerの認証セクションを参照してください。

2. 設定を適用する

Compose ファイルを含むディレクトリから、更新された環境を適用します。Compose は、構成が変更されたサービスを再作成します。

docker compose up -d

アカウントを作成する前に、コンテナが実行されていることを確認してください。カスタマイズされたComposeプロジェクト、別のプロジェクト名、またはオーケストレーションレイヤーを使用している場合は、2つ目のJitsiスタックを起動するのではなく、そのデプロイメントに対して同等の更新を実行してください。

3. 承認されたルームホストごとにアカウントを作成します。

Prosodyコンテナ内でシェルを開きます。

docker compose exec prosody /bin/bash

次に、デフォルトのDocker XMPPドメインにJitsiユーザーを登録します。

prosodyctl --config /run/prosody/config/prosody.cfg.lua register <username> meet.jitsi <strong-password>

両方のプレースホルダーを、そのユーザーのユーザー名と固有のパスワードに置き換えてください。山括弧は含めないでください。2 つ目の認証済みホストの場合は、別のユーザー名でコマンドを再度実行してください。表示されているコマンドはデフォルトの Docker ドメインを使用しています。meet.jitsiドメインを変更した場合はXMPP_DOMAIN、デプロイメントで設定されているドメインに従ってください。現在の Docker ガイドには、Prosody コンテナ コマンドと関連する削除コマンドが記載されています。

ユーザーを取り消すには、Prosodyコンテナに入り、次のコマンドを実行します。

prosodyctl --config /run/prosody/config/prosody.cfg.lua unregister <username> meet.jitsi

アカウントリストは、会議を開始できる権限を持つユーザーのみに限定してください。ルーム名はアクセス制御の仕組みではないため、ホストがアカウントへのアクセス権限を必要としなくなった場合は、その権限を削除する必要があります。

4. ホストパスとゲストパスを個別にテストする

プライベートブラウザーウィンドウまたは別のブラウザープロファイルを使用して、既存の Jitsi ログインセッションによって結果が隠されないようにしてください。公開されている Jitsi URL を開き、認証せずに新しいルームを開始してみてください。インスタンスは、新しい会議を割り当てる前に認証を要求するはずです。作成したアカウントのいずれかでサインインしてルームを開始し、ルームが開くことを確認してください。

次に、認証されていない別のブラウザセッションで会議室リンクを開きます。ゲストアクセスが有効になっている場合、認証済みのホストが会議を開始した後、ゲストは会議に参加できるようになります。JitsiのDockerガイドによると、ゲストアクセスが有効になっている場合、認証されていないユーザーはユーザーが認証されるまで待つ必要があるとのことです。

DebianまたはUbuntuを新規インストールする場合は、最新のトークン認証ガイドを参照してください。

Jitsi の最新のセルフホスティング ハンドブックでは、トークン認証を使用した新しい認証パスが提供されています。ドキュメントに記載されている例では、Jitsi を Keycloak に接続し、Prosody ホストでトークンを要求するように設定し、ゲストを許可する場合に匿名ゲスト ドメインを追加します。Jitsi の設定では、ドキュメントに記載されているセットアップではメイン ホストにauthentication = "token"とを使用しallow_empty_token = false、ゲスト ドメインを としてマッピングしますjitsi-anonymous。Keycloak レルム、クライアント リダイレクト URL、リバース プロキシ ルーティング、Prosody、および Jitsi Web クライアント設定については、完全な認証ガイドを参照してください。すべての例のホスト名を独自のホスト名に置き換え、ID プロバイダー エンドポイントは HTTPS で保護してください。

トークン認証は、アカウントをIDプロバイダーで管理する場合や、アプリケーションがルーム固有のアクセストークンを発行する場合に役立ちます。トークン認証には、正しく構成された発行者とトークン検証が必要です。ブラウザの設定でトークン認証を有効にするだけでは、ルームの作成を安全に制限することはできません。DockerでLDAPベースのアカウントが必要な場合は、DockerガイドにLDAPモードに関する説明がありますが、LDAP接続、証明書、およびフィルタの設定は、ご使用のディレクトリと一致している必要があります。

部屋の作成と部屋のプライバシーは別物です

認証は「誰が会議を開始できるか」という問いに答えるものですが、「誰がこの部屋に入れるか」という問いには答えません。ゲストの参加が許可されている場合、部屋のURLを取得した人は誰でも参加を試みる可能性があります。招待された参加者のみが入室できる会議のために、部屋のパスワードを追加するか、ロビーを設定してください。Jitsiのセルフホスティングガイドでは、サーバーレベルでの会議開始機能と、個々の部屋で管理されるアクセス制御を区別しています。

チェックすべき一般的な問題

• ルームの作成は引き続き匿名で行えます。ENABLE_AUTH=1実行中の Compose プロジェクトで使用される環境ファイルで有効になっていることを確認してから、設定を再適用してください。
• 参加者全員にログインプロンプトが表示されます。この設定が無効になっているかどうかを確認してくださいENABLE_GUESTS。この設定では参加者の認証が必須となりますが、認証済みのホストとゲスト参加者のみを対象とした場合は不要です。
• 新しいアカウントではサインインできません。デプロイメント用に構成されたドメインに登録されていることを確認してください。Docker のデフォルトコマンドは を使用しますmeet.jitsi。カスタム XMPP ドメインには対応する値が必要です。
• ゲストはホストより先に入室できません。これはゲストアクセスに関する仕様です。認証済みのホストが先にルームを開始し、その後ゲストにルームリンクを使用するよう促してください。
• 別のインストールタイプのチュートリアルに従う場合： Debianパッケージパス、Dockerで生成された設定、および古いsecure-domainスニペットを混在させないでください。インストールに関するハンドブックのセクションを参照し、非推奨に関する注記を確認してください。

検証チェックリスト

1. 認証されていないブラウザでは、新しいルームを作成できません。
2. プロビジョニング済みのユーザーはサインインしてルームを開始できます。
3. 削除されたアカウントは認証できなくなります。
4. ゲストの参加は、お使いの環境において意図したとおりに動作しますENABLE_GUESTS。
5. プライベートな会議では、必要に応じて部屋のパスワードやロビー利用に関する規則が用いられることもあります。

重要な決定事項は、Jitsiインスタンスで個別にプロビジョニングされた内部アカウントを使用するか、IDプロバイダー経由で発行されたトークンを使用するかです。既存のDocker Composeデプロイメントの場合、内部認証は、登録した少数のユーザーのみにルーム作成を制限する直接的な方法です。新規インストールの場合は、最新のトークン認証ガイドを参照し、ルームレベルのアクセス制御は別途設定してください。

公式資料

• Jitsi Meet：認証（最新ガイド；最終更新日：2026年10月5日）
• Jitsi Meet：セルフホスティングガイド — Docker
• Jitsi Meet: セキュアドメイン設定（新規インストールでは非推奨）
• Jitsi Meet: セルフホスティングガイド — Debian/Ubuntu