LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Jitsiセルフホストとは何か

Jitsiセルフホストとは、オープンソースのWeb会議基盤であるJitsi Meetを、自社が管理するサーバー上に構築し運用する形態を指します^*1。公式ハンドブックでは、既存のホスティングサービス（meet.jit.si）を使わずに「自身のJitsi-Meetサーバーをホストする」ための情報として、このセルフホスト方式が案内されています^*1。

Jitsi Meetは、WebRTC（ブラウザ間でリアルタイムに音声・映像をやり取りする通信規格）に対応したJavaScriptアプリケーションであり、Jitsi Videobridge（映像ストリームを配信するサーバー）を用いて高品質でスケーラブルなビデオ会議を実現します^*2。ソースコードはすべてGitHub上に公開されており、誰でも監査・改変し、自前のインスタンスとして展開できる点が特徴です^*3。

SaaS会議ツールとの違い

Zoom・Microsoft Teams・Google Meetといった主要なSaaS型Web会議サービスは、提供事業者側のクラウド基盤上でセッションが処理され、利用企業はアカウント契約とライセンスに応じてサービスを利用する形態です。会議データやログの保管場所、アクセス権限の設計は基本的に提供事業者の仕様に依存します。

Jitsiセルフホストでは、サーバーの設置場所・ネットワーク構成・アクセス制御をすべて自社の裁量で設計できます。会議室はミーティングごとに生成され、最初の参加者が入室した時点で作られ、最後の参加者が退出すると破棄される一時的な存在です^*3。録音・録画やチャット履歴の保存も、自社の運用方針で有効・無効を選べる点がSaaS型との構造的な違いといえます。

WebRTCとJitsi Videobridgeの仕組み

Jitsi Meetは、ブラウザ同士でリアルタイムに音声・映像を伝送する標準技術であるWebRTCを基盤としています^*2。WebRTCベースのシステムでは、マルチメディアを正常に機能させるために暗号化通信（HTTPS）が必要になるとハンドブックに明記されています^*1。

会議の中核を担うのがJitsi Videobridge（JVB）です。JVBは「会議参加者間でビデオストリームをルーティングするために設計されたWebRTC対応サーバー」と定義される、SFU（Selective Forwarding Unit、選択的転送ユニット）です^*2。SFUは映像ストリームを合成せず、参加者ごとの帯域や表示レイアウトに応じて必要なストリームだけを選択的に転送する仕組みで、MCU（Multipoint Control Unit、映像を1本に合成する方式）よりも軽量にスケールできます^*4。

会議ごとのセッション管理と参加者・Videobridge間の負荷分散は、Jicofo（Jitsi Conference Focus）が担います^*2。シグナリング（接続の確立や制御情報のやり取り）にはXMPP（拡張可能なメッセージ・プレゼンスプロトコル）サーバーであるProsodyが使われます^*2。

自前運用が意味を持つ場面

セルフホストの利点が明確になるのは、会議データの管轄権を自社側に置く必要がある場面です。自前運用ではメタデータ・ログ・バックアップがすべて自社の管理下に置かれ、データ主権を確保しやすくなります。音声・映像はDTLS-SRTP（データグラム版TLSとSRTPを組み合わせた暗号化方式）でネットワーク上を暗号化されており^*5、Videobridgeを通過する際に外層の暗号は一時的に解除されますが、パケットは永続ストレージに保存されず、他参加者への転送中のみメモリ上に存在します^*5。

機密性の高い会議、たとえば人事・法務・経営層の協議や、取引先との契約交渉など、会議内容そのものを外部のクラウド事業者に預けたくない場面では、自前基盤を社内ネットワークや閉域網内に構築する選択が検討されます。Jitsi Meetの会議室は一時的な存在であり、参加者が全員退出すると破棄されるため^*3、恒常的な会議室情報の蓄積を避ける運用も可能です。

アカウント不要のゲスト会議を重視する場面も自前運用の意義につながります。会議を作成した本人以外の参加者はアカウント登録が不要で、氏名やメールアドレスの入力は任意であり、入力した情報は他の参加者にのみ共有されます^*3。社外の取引先やクライアントを都度アカウント登録なしで招待できる点は、SaaS型サービスのライセンス制約を回避したい企業にとって実務的な利点です。

構築に必要なコンポーネント

Jitsi Meetの自前基盤は単一のアプリケーションではなく、複数のコンポーネントの組み合わせで構成されます。中核となるのは前述のJitsi Meet（フロントエンド）、Jicofo（セッション管理）、Jitsi Videobridge（映像ルーティング）、Prosody（シグナリング）の4つです^*2。

用途に応じて追加コンポーネントを組み合わせます。Jigasi（Jitsi Gateway to SIP）は、通常のSIP電話クライアントからJitsi Meet会議への参加を可能にするゲートウェイです^*2。Jibri（Jitsi Broadcasting Infrastructure）は、Chromiumインスタンスとffmpegを用いて会議の録画・配信を行う仕組みですが、1台のJibriインスタンスは1つの会議しか処理できず、録画機能自体には水平スケーラビリティがありません^*6。録画・配信の需要が多い運用では、この制約を踏まえた台数計画が要点になります。

Debian・Ubuntu環境での構築では、公式パッケージ`jitsi-meet`のインストールに加え、nginx（Webサーバー）、Prosodyリポジトリ（ロビー機能等に必要）、OpenJDK 17の準備が要件として案内されています^*7。TLS証明書はLet’s Encryptの利用が推奨され、自己署名証明書はスマートフォンクライアントで受け入れられないことが多く、セキュリティ上も非推奨とされています^*1*7。

サーバー要件と帯域の目安

公式ハンドブックの要件ガイドでは、Jitsi Meetはリアルタイム性を要するシステムであり、通常のWebサーバーとは異なる要件を持つと説明されています^*8。CPUについては、Prosodyコンポーネントが1コアしか使えない制約があり、基本的なサーバー構成では4コア程度で足りるとされています^*8。メモリは通常8GB程度が推奨されますが、小規模な会議であれば4GB、テスト用途であれば2GBでも動作するとされ、大規模会議には複数サーバー構成が推奨されます^*8。ストレージはSSDが必須ではなく、20GB程度の標準的なハードディスクで運用できるとされています^*8。

帯域幅は解像度に応じて変わります。180pでは200kbps、360pでは500kbps、720p（HD）では2,500kbps、4Kでは10Mbpsが推奨帯域として示されています^*8。小規模組織であれば1Gbit/sの回線で足りることが多いものの、本格的な運用サーバーでは10Gbit/s程度の帯域が望ましいとされています^*8。参加者数と解像度の組み合わせによって必要帯域が大きく変動するため、想定する会議規模を先に固めてから回線・サーバーを選定する順序が実務上重要です。

ポート開放も要件の一つです。構築時は80/443番（TCP）に加え、10000番（UDP、メディア伝送用）、5349番（TCP）などのポートを開放する必要があります^*7。社内ネットワークにファイアウォールやNAT機器が挟まる構成では、これらのポート制御の設計が接続不良の主な原因になりやすく、事前の通信要件確認が欠かせません。

認証・運用設計の要点

自前運用では、誰が会議室を作成できるか、誰がモデレーター権限を持つかという認証設計を自社の方針で決められます。公開インスタンスであるmeet.jit.siでは2023年8月24日以降、会議室を作成する本人にはアカウントが必要になりましたが、その他の参加者には不要という運用がとられています^*3。自前基盤ではこの認証範囲を、社内アカウント連携やJWT（JSON Web Token、署名付きの認証情報を運ぶトークン形式）による発行制御など、自社のID管理方針に合わせて設計する必要があります。

暗号化面では、E2EE（エンドツーエンド暗号化）が音声・映像・画面共有に対応していますが、チャットや投票機能は対象外である点に注意が必要です^*5。E2EEはChromium系ブラウザの一定バージョン以降で利用可能で、セキュリティオプションから有効化する仕組みです^*5。機密会議での利用を想定する場合は、対象範囲の限定を理解した上で運用ルールを設計することが欠かせません。

運用開始後は、OS・Jitsiパッケージ・TLS証明書の更新、ログ監視、障害時の切り戻し手順の整備が継続的に発生します。バージョンアップに伴うコンポーネント間の互換性検証や、参加者数増加に応じたVideobridgeの追加・負荷分散の見直しも運用フェーズの主要タスクです。これらを兼務の情報システム担当者だけで回すには、WebRTCとサーバーインフラの両方の知識、および継続的な監視体制が必要になります。

外注と内製の判断軸

内製で自前基盤を構築する場合、必要になるのはLinuxサーバー運用、WebRTC・SFUの仕組みの理解、TLS証明書・DNS設定、ファイアウォール・帯域設計、そして継続的な監視・パッチ適用の知識です。構築時点の知識だけでなく、リリース後も継続して人員を確保できるかが内製判断の分岐点になります。

構築を誤った場合の影響も具体的です。TLS証明書の設定を誤ると会議への接続そのものができなくなり、ポート開放の設計を誤ると社内ネットワークの参加者だけ音声・映像が届かない事態が起こり得ます。認証設計が甘いと、社外の第三者が会議室URLを推測して参加してしまうリスクも生じます。こうした失敗は会議当日に判明することが多く、事業運営への影響が直接的です。

外部パートナーに構築を委託する場合との違いは、要件定義からサーバー設計・認証設計・運用体制構築までを一貫して任せられる点にあります。内製では要件を固める段階から専門知識を要する一方、委託先が自社の閉域網構成や既存ID管理システムとの連携を含めて設計を担うことで、社内担当者は運用ルールの策定や利用部門との調整に集中できます。自社の会議規模・機密性の要求水準・社内に確保できる専門人員の3点を洗い出した上で、内製か外注かを判断することが現実的な進め方です。

まとめ：Jitsiセルフホスト構築の3つの判断軸

本稿では、Jitsi Meetをセルフホストで構築する仕組みと意義を整理しました。要点を3つに集約すると、第一にWebRTCとJitsi Videobridge・Jicofo・Prosodyといったコンポーネント構成の理解が構築の前提になること、第二にデータ主権・機密会議・閉域網対応・アカウント不要のゲスト参加といった自前運用ならではの利点があること、第三にサーバー要件・帯域・認証設計・継続運用の負荷を踏まえ、内製と外注のどちらが自社に適するかを事前に見極める必要があることです。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Jitsi「Self-Hosting Guide – Overview」（jitsi.github.io/handbook）
2. *2　出典：Jitsi「Architecture」（jitsi.github.io/handbook）
3. *3　出典：Jitsi「Jitsi Meet Security & Privacy」（jitsi.org/security）
4. *4　出典：Jitsi「Jitsi Videobridge」（github.com/jitsi/jitsi-videobridge）
5. *5　出典：Jitsi「Jitsi Meet Security & Privacy」（jitsi.org/security）
6. *6　出典：Jitsi Handbook「Jibri」記載（jitsi.github.io/handbook）
7. *7　出典：Jitsi「Self-Hosting Guide – Debian/Ubuntu server」（jitsi.github.io/handbook）
8. *8　出典：Jitsi「Requirements」（jitsi.github.io/handbook）

Tweet