自己ホスト型Dockerサーバー上でのONLYOFFICE共同編集の遅延を修正する

ONLYOFFICEの共同編集が、自己ホスト型のDockerサーバー上で遅く感じられる場合、まずはドキュメント化されていないエディタパラメータを変更することから始めないでください。まず、問題を3つの測定可能な領域に分けましょう。サーバーリソースの負荷、リバースプロキシ/WebSocketの動作、ストレージまたはコンテナレベルのエラーです。共同編集は長時間にわたるリアルタイム通信に依存するため、ドキュメントを正常に開くサーバーでも、複数のユーザーが同時に入力すると動作が遅く感じられることがあります。

このガイドでは、架空の例を用いて説明します。小規模なチームがNGINXの背後でDockerコンテナ内でONLYOFFICE Docsを運用しているとします。1人か2人のユーザーは通常通り編集できますが、6人が同じドキュメントを開くと、カーソルの更新が遅れ、他のユーザーの変更も目立った遅延の後に反映されます。この例はあくまで教育的なシナリオであり、ベンチマークや実際の導入事例の報告ではありません。

2026年10月現在、ONLYOFFICE Docs 9.4が公式変更履歴に記載されている最新リリースです。バージョン9.4では、RabbitMQとデータベースへの依存関係を削除することでCommunity Editionのアーキテクチャも変更されたため、以前のリリース向けに書かれたアドバイスは、現在のCommunity Editionコンテナには適合しない可能性があります。古いフォーラム投稿からチューニングに関するアドバイスをコピーする前に、必ずインストールされているエディションとバージョンを確認してください。

1. 変更を加える前に遅延を測定する

仮にそのような状況になった場合、まず最初に試すべき間違いは、無作為にサービスを再起動してラグが解消されることを期待することでしょう。そうではなく、再現可能なテストを作成してください。複数のブラウザセッションまたはテストアカウントから同じドキュメントを開き、短い編集を行い、ローカル画面でのキー入力、リモートカーソルの移動、他のユーザーのテキストの表示、保存ステータス、またはドキュメントの初期読み込みなど、何が遅延しているかを記録します。

これらの症状は、それぞれ異なるボトルネックを示しています。ローカルブラウザ上でエディタ自体がフリーズする場合は、クライアント側のCPUまたは非常に複雑なドキュメントが原因である可能性があります。ローカルでの入力は即座に反映されるものの、リモートでの編集が遅れる場合は、ネットワークパスとWebSocketセッションを確認してください。ドキュメントを開く数が増えるにつれてすべての動作が遅くなる場合は、サーバーのCPU、メモリ、スワップ、ディスクI/Oを調べてください。

ONLYOFFICEは、公式のDockerインストールガイドで、Dockerの導入方法と基本要件について説明しています。Docker Composeについては、公式のDocker Composeの手順を参照してください。

2. ユーザーが編集作業を行っている間のCPUとメモリの負荷を確認する。

Dockerホスト上で、以下を実行します。

docker stats

テストグループが編集作業を行っている間、ドキュメントサーバーコンテナを監視してください。また、次のようなツールを使用してホストリソースを検査してください。

free -h
uptime
vmstat 1
df -h

ONLYOFFICEの公式Docker要件では、ドキュメントに記載されている構成には最低4GBのRAMと最低40GBの空きディスク容量が必要とされており、スワップ領域も必要となります。エンタープライズ向けガイダンスでは、容量は同時アクティブユーザー数、およびドキュメントの数、種類、サイズによって異なることも明記されています。これらの数値はあくまで基準値であり、4GBあればあらゆるワークロードでスムーズなコラボレーションが実現できるという保証ではありません。

この例では、docker stats6人が同時に入力するたびに、ドキュメントサーバーコンテナが利用可能なCPUのほとんどを繰り返し消費しているとします。これは重要な証拠です。プロキシのタイムアウトを追加しても、CPU使用率は向上しません。次のステップは、過度に制限的なDockerのCPU制限を解除するか、コンテナをより高速なホストに移行するか、同時実行ワークロードを削減することです。一方、CPU使用率が控えめなままであれば、ハードウェアを購入する前に調査を続けるべきです。

容量に関する公式なガイダンスの参照資料は、ONLYOFFICE DocsのDockerシステム要件です。

3. ディスク容量、マウントポイント、ファイルキャッシュを確認する

ONLYOFFICEのDockerドキュメントには、/var/log/onlyofficeログや/var/lib/onlyofficeファイルキャッシュなどの永続的な保存場所が記載されています。ホストのルートファイルシステムだけでなく、これらのパスを支えるファイルシステムも確認してください。

df -h
docker inspect documentserver --format '{json .Mounts}'

バインドマウントが低速なネットワークファイルシステムや過負荷状態のディスクを指している場合、ドキュメントのオープン、変換、キャッシュ処理によって遅延が発生する可能性があります。ディスクの容量がほぼ満杯の場合は、アプリケーションのチューニングを行う前にディスクの空き容量を確保してください。ONLYOFFICEのLinuxトラブルシューティングドキュメントでは、ディスク容量不足が変換問題の原因となる可能性が具体的に指摘されています。

このプロジェクトでは、永続的なログ、キャッシュストレージ、または外部データベース/Redis/RabbitMQサービスが必要な場合は、関連データをコンテナ外に保存することを推奨しています。詳細については、公式のDockerボリュームに関するガイダンスを参照してください。

4. リバースプロキシがリアルタイム接続を維持していることを確認する

多くのセルフホスト型デプロイメントでは、ONLYOFFICE は NGINX、Apache、HAProxy、または Traefik の背後に配置されます。ONLYOFFICE の公式プロキシドキュメントでは、 や などの転送ヘッダーが明示的に要求されていますX-Forwarded-Proto。ONLYOFFICEX-Forwarded-Hostに同梱されている設定では、HTTP/1.1 および WebSocket のアップグレード処理も使用されます。

NGINXの場合、他の製品から汎用的なWebSocketのスニペットを貼り付けるのではなく、ONLYOFFICEの公式サンプルと設定を比較してください。代表的なパターンは以下のとおりです。

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $proxy_connection;
proxy_set_header X-Forwarded-Host $the_host;
proxy_set_header X-Forwarded-Proto $the_scheme;

周囲のmap指示やプロキシの場所は重要です。トポロジーに合わせて、ベンダーが提供する完全なサンプルを使用してください。サポートされている構成については、「プロキシの背後で ONLYOFFICE ドキュメントを使用する」に記載されています。

仮に、想定されるチーム環境で、Dockerホストに十分なCPUとRAMが搭載されているにもかかわらず、ブラウザが社内NGINXレイヤーを介してコラボレーションチャネルに繰り返し再接続しているとします。これは、ドキュメントサーバーの処理能力の問題ではなく、プロキシ経路の問題を示しています。

5. ブラウザでWebSocketセッションを確認します。

ブラウザの開発者ツールを開き、「ネットワーク」パネルを選択してWebSocketトラフィックをフィルタリングし、エディタを再読み込みしてください。WebSocketハンドシェイクが成功すると、通常はHTTPが表示され101 Switching Protocols、接続が開いたままになります。長時間「保留中」のWebSocketであっても、それ自体を失敗とみなさないでください。アクティブなWebSocketは開いたままになることが期待されます。

重要なのは、切断と再接続が繰り返される動作、ハンドシェイクの失敗、プロキシエラー、またはコラボレーションの遅延と相関する長い間隔です。WebSocketが再接続されるのと同時にリモート編集が遅延する場合は、解決すべき具体的なネットワーク問題が発生していることになります。

TLS終端、プロキシのアイドルタイムアウト、ロードバランサーのルール、WAFポリシー、およびWebSocketトラフィックを保持しない可能性のある中間層を確認してください。プロキシ層が複数ある場合は、公開されているNGINXインスタンスだけが関与していると想定するのではなく、各ホップをテストしてください。

6. 想定されるコンテナとエディション固有のアーキテクチャを確認する

走る：

docker compose ps
# or
docker ps

最新の ONLYOFFICE デプロイメントでは、必ずしも同じ Redis、PostgreSQL、または RabbitMQ コンテナのコレクションが必要になるとは限りません。バージョンが重要になります。ONLYOFFICE は、Docs 9.4 以降、オープンソースの Community Edition がシングルプロセスアーキテクチャに簡素化され、RabbitMQ とデータベースへの依存関係が削除されたと述べています。Enterprise、Developer、以前の Community デプロイメント、およびカスタム Compose スタックは異なる場合があります。

つまり、「RabbitMQがボトルネックになっているに違いない」と書かれた2023年のトラブルシューティング記事は、現在のCommunity Editionインスタンスには当てはまらない可能性があるということです。実際に実行しているイメージとバージョンを特定してください。

docker inspect documentserver --format '{.Config.Image}'
docker image ls onlyoffice/documentserver

ONLYOFFICE Docsの公式変更履歴には、バージョン9.4.0が2026年5月20日にリリース予定と記載されています。ベンダーのDocs 9.4リリース発表では、コミュニティエディションのアーキテクチャ変更について説明されています。

7. デバッグログを一時的に有効にして、遅延との相関関係を調べる

ONLYOFFICEは、デバッグログ用のDocker環境変数を文書化して提供しています。短時間のトラブルシューティングには、以下を追加してください。

DS_LOG_LEVEL=DEBUG

次に、デプロイ方法に応じて該当するコンテナを再作成または再起動し、ログを確認してください。

docker logs -f documentserver
# Docker Compose:
docker compose logs -f documentserver

公式ドキュメントによると、Dockerログは/var/log/onlyoffice/documentserverコンテナ内部、およびホストにマウントした場合は対応するホストマウントログディレクトリにも保存されます。コンバータログは、ファイルのオープンや変換が遅い場合に役立ちます。一方、共同編集に関する問題は、ドキュメントサーバーのログやブラウザ/ネットワークの監視結果と関連付けて確認する必要があります。

必要な情報を収集したら、デバッグをオフに戻してください。詳細ログは診断用であり、永続的なパフォーマンス設定ではありません。ONLYOFFICE Docs の「デバッグログの有効化」に記載されているベンダーの手順に従ってください。

8. 古いイメージを使用している場合は、慎重にアップデートしてください。

デプロイメントがサポート対象のリリースラインから大幅に遅れている場合、アップデートにはバグ修正やアーキテクチャの改善が含まれる可能性があります。しかし、「最新版をダウンロードして再起動する」という方法は、本番環境のコラボレーションサーバーにおいて安全なパフォーマンス対策とは言えません。

まず、現在のイメージタグ、構成ファイル、JWT設定、マウントされたボリューム、リバースプロキシ構成、および統合構成を記録してください。変更プロセスの再現性が必要な場合は、固定バージョンを使用してください。ONLYOFFICEのDockerインストールガイドには、特定のバージョンを指定する方法が記載されており、公式の変更履歴には変更内容が記載されています。

稼働中のドキュメントサーバーを意図的に停止する前に、ONLYOFFICEのエディションと展開環境に応じたシャットダウン手順に従って、アクティブな編集セッションが安全に処理されるようにしてください。保存されていないユーザー作業を含むベンチマークドキュメントをアップグレードテストに使用しないでください。

仮説的なケースが実際の解決策を絞り込む方法

6人の共同編集者がいる例のチームに戻ってください。トラブルシューティングの結果は、観察される内容によって異なります。

Dockerデプロイメントのための実践的な基準

小規模なセルフホスト型インストールの場合、公開されている ONLYOFFICE の最小要件から始めますが、登録ユーザー総数ではなく、実際の同時アクティビティに基づいてサイズを決定してください。永続的なログとキャッシュは、レイテンシが予測可能なストレージに保存してください。ワークロードを測定していない限り、CPU やメモリの制限を厳しくすることは避けてください。通常の編集負荷時に、Docker ホスト自体がスワップしないように注意してください。

ONLYOFFICEを、ベンダーがサポートするサンプルに基づいたリバースプロキシ構成の背後に配置し、WebSocketのアップグレードと転送されるホスト/プロトコルヘッダーを保持してください。サーバーは、アイドル時だけでなく、実際の共同編集中に監視してください。より詳細な証拠が必要な場合は、一時的にDEBUGログを有効にし、ログのタイムスタンプをブラウザのWebSocket動作およびホストのメトリクスと関連付けてください。

やってはいけないこと

• local.jsonフォーラムの投稿で「パフォーマンス調整」と呼ばれているからといって、文書化されていない値を変更しないでください。
• 「保留中」と表示されている永続的なWebSocketが壊れていると決めつけないでください。長期間存続するWebSocketは想定されています。
• 古いデプロイメント図で使われていたからといって、Redis、RabbitMQ、PostgreSQLを追加しないでください。まずは、お使いのエディションとバージョンのアーキテクチャを確認してください。
• レイテンシを下げるための安易な方法として、TLS検証、JWTセキュリティ、またはプロキシ保護を無効にしないでください。
• アイドル状態のサーバー指標と、ユーザーが実際にラグを報告した期間を比較しないでください。
• ボリューム、構成、およびロールバックパスを保持せずに、本番環境のインスタンスをアップグレードしないでください。

結論

ONLYOFFICEの共同編集時の遅延は、測定可能なシステム上の問題として捉えることで最も簡単に解決できます。遅延を再現し、Dockerとホストのリソース負荷を監視し、ストレージを確認し、ブラウザがすべてのプロキシ経由で正常なWebSocket接続を維持していることを確認し、遅延が発生する時間帯のみのログを調べます。ボトルネックがコンピューティングリソース、メモリ、ディスク、ネットワーク/プロキシの動作、または特定のバージョン/構成変更のいずれであるかが分かれば、推測に頼るのではなく、的を絞った修正が可能になります。

現在のデプロイメントの詳細については、ONLYOFFICEのDockerインストールドキュメント、公式のリバースプロキシの例、デバッグログガイド、および公式のドキュメントの変更履歴を参照してください。