【2026年】ONLYOFFICE セルフホスト構築ガイド｜Microsoft Office互換の最強

ONLYOFFICE Document Server の概要とセルフホストにおける重要性

現代のビジネス環境および個人の情報管理において、データの所有権（データ・ソブリンティ）は極めて重要な価値となっています。マイクロソフトオフィスやグーグルドキュメントなどのクラウドサービス利用が一般的ですが、これらはサーバー側でデータを処理するため、機密情報の漏洩リスクやサブスクリプション費用の継続的な負担が生じます。そこで注目されるのが、自社サーバー内で完結する文書編集システム「ONLYOFFICE Document Server」です。2026 年現在、バージョン 8.x を基盤としたこのソフトウェアは、マイクロソフト Office のファイル形式への高い互換性を維持しつつ、オープンソースの柔軟性を兼ね備えた最強のオフライン文書管理ソリューションとして確立されています。

この記事では、ONLYOFFICE Document Server のセルフホスト構築を完全ガイドする内容を提供します。特に Docker コンテナ技術を活用したデプロイ手法に焦点を当て、PostgreSQL データベースや RabbitMQ メッセージブローカー、Redis キャッシュサーバーといった必須コンポーネントの連携を詳説します。また、次世代クラウドストレージである Nextcloud 30 や Seafile 12 との統合方法について、具体的なプラグイン設定から JWT トークンによるセキュリティ強化までを解説します。

セルフホスト環境を構築する際に最も懸念されるのが「運用コスト」と「互換性」です。ONLYOFFICE は Word の .docx、Excel の .xlsx、PowerPoint の .pptx 形式をネイティブに近い品質で編集可能なため、従来の LibreOffice や OpenOffice 系ソフトウェアよりもビジネス現場での採用適合度が高いと評価されています。本ガイドでは、単なるインストール手順だけでなく、2026 年時点の最新トレンドである AI 機能や共同編集（コラボレーション）の限界値、そしてエンタープライズ版とのライセンス比較を通じて、読者が最適な構成を選定できるような実用的な知見を提供いたします。

ONLYOFFICE Document Server とは何か？Office 互換性とセルフホストのメリット

ONLYOFFICE Document Server は、エストニアに拠点を置く Ascensio System SIA 社が開発・提供するウェブベースの文書編集サーバーです。2026 年時点で主流となっているバージョン 8.x では、コアエンジンが大幅な刷新が行われ、特に複雑なレイアウトを持つ文書の表示精度と、Excel の数式計算速度において劇的な改善が見られました。このソフトウェアは、クライアントサイドのブラウザだけで動作するのではなく、サーバー上でファイル処理を行う「Document Server」と、そのドキュメントを編集するためのクライアントアプリである「ONLYOFFICE Editors」から構成されるエコシステムです。

セルフホスト環境における最大のメリットは、データが自社ネットワーク内や管理下のクラウドストレージに留まることです。例えば、医療機関や法律事務所、あるいは防衛関連企業などの場合、機密情報を外部のクラウドサーバーにアップロードすることが規程で禁止されているケースが多々あります。ONLYOFFICE を Docker コンテナとして自社の Linux サーバー（Ubuntu 24.04 LTS や Debian 12 など）上に展開することで、社外へのデータ持ち出しを完全に防止しつつ、Microsoft Office と同等の編集体験を提供できます。これにより、毎年のサブスクリプション費用をゼロに抑えながら、機能制限のない文書管理を継続することが可能になります。

もう一つの重要な利点は、カスタマイズ性と拡張性です。Community Edition（コミュニティ版）は無料で利用可能です。2026 年現在でもライセンスの更新が無料であるため、予算制約のある中小企業や個人開発者にとって極めて魅力的な選択肢となっています。さらに、REST API を通じて独自アプリケーションと統合が可能であり、社内システムにドキュメント編集機能を埋め込むことが容易です。また、Collabora Online や CryptPad といった競合サービスと比較して、ファイルの表示崩れが少なく、Word 文書でのフォント埋め込みやレイアウト維持において圧倒的な精度を誇ります。

このように、ONLYOFFICE は無料利用でも十分な性能を発揮しますが、大規模な組織で導入する場合はエンタープライズ版のサポート体制や高度な管理機能を検討する必要があります。また、Microsoft Office 365 と比較するとサーバー構築の手間は増えますが、長期的な TCO（総所有コスト）を削減できる点において、システム管理者にとっては魅力的な投資対象となります。特に Docker を活用したコンテナ化により、バージョンアップのリスクや環境依存の問題を最小限に抑えながら運用できます。

事前準備とシステム要件の確認（CPU, メモリ，ディスク）

ONLYOFFICE Document Server を安定して稼働させるためには、適切なハードウェアリソースの確保が不可欠です。2026 年時点の文書処理負荷を考慮すると、単に「動作する」レベルではなく、「快適に編集できる」環境を整える必要があります。ドキュメントサーバーは、ファイル変換やレンダリング処理において CPU とメモリを大量消費します。特に Excel の大規模な数式計算や、PowerPoint の高解像度画像を含むスライドのプレビュー生成時には、マルチコアプロセッサと十分な RAM が要求されます。

最低要件としては、CPU は 2 コア（x86_64 または ARM64）、RAM は 4GB を確保する必要があります。ただし、これは 1〜5 名程度の小規模利用を想定した数字です。実運用では、同時接続ユーザー数が 10 名を超えると、メモリ不足によりプロセスがスワップ現象を起こし、編集操作がカクつく原因となります。推奨スペックとしては、CPU を 4 コア以上、RAM を 8GB から 16GB に設定することが推奨されます。特に Redis や RabbitMQ、PostgreSQL のバックグラウンド処理を考慮すると、OS 自体に 2GB を確保し、コンテナ群に各 1〜2GB を割り当てる設計が必要です。

ディスクストレージの性能も重要な要素です。ONLYOFFICE はファイル変換時に大量の一時ファイルを生成します。HDD での稼働は避けるべきであり、少なくとも SSD または NVMe SSD を使用してください。ディスク I/O がボトルネックになると、ドキュメントの保存や検索に数秒の遅延が発生し、ユーザー体験が著しく低下します。また、ログファイルとデータベースのバックアップ領域を考慮して、総容量 50GB 以上の空き容量を確保しておくことを強くお勧めします。2026 年時点ではデータセキュリティのため、ストレージレベルでの暗号化（LUKS や ZFS 暗号化など）が標準的なベストプラクティスとなっています。

ネットワーク帯域についても考慮が必要です。ドキュメントのアップロードやダウンロードに使用されるため、LAN 環境であれば問題ありませんが、インターネット経由でアクセスする場合は、10Mbps あたりの帯域をユーザー数分確保できるとスムーズです。ただし、画像が含まれるファイルサイズが大きくなることを想定し、Nginx や Traefik などのリバースプロキシサーバーを経由して Gzip 圧縮や CDN の利用を検討すると、転送速度の向上に繋がります。

この表を参考にご自身の環境に合わせてリソースを割り当ててください。また、仮想化環境で実行する場合、ハイパーバイザ側の設定も重要です。例えば VMware ESXi や Proxmox VE 上でコンテナホストを構築する場合は、CPU のコアアフィニティ（固定）やメモリオーバーコミットの抑制を有効にすると、パフォーマンスの安定性が向上します。特に Docker コンテナはリソース制限（Cgroups）を柔軟に設定できるため、他の重要なサービス（Web サーバーやメールサーバーなど）と競合しないよう、CPU 制限値（CPU Quota）を適切に設定することが重要です。

Docker Compose を使った導入手順（PostgreSQL, RabbitMQ, Redis含む）

ONLYOFFICE Document Server の標準的なインストール方法は、Docker と Docker Compose を利用する手法が最も推奨されます。2026 年時点でもこのアプローチは変更されておらず、環境間での移植性やバージョン管理の容易さから、デベロッパーやシステム管理者の間で事実上の標準となっています。Snap パッケージによるインストールも可能ですが、Docker の方がコンテナ間のネットワーク接続設定やリソース制限のカスタマイズが容易であるため、本ガイドでは Docker Compose 方式を主体に解説します。

まず、サーバーに Docker Engine と Docker Compose プラグインが最新バージョン（2026 年現在 v27.x〜v28.x を想定）でインストールされていることを確認してください。次に、コンテナ構成定義ファイルである docker-compose.yml の作成が必要です。このファイルには、ONLYOFFICE アプリケーション本体だけでなく、依存するバックエンドサービス群も記述されます。具体的には、PostgreSQL データベース（ドキュメントメタデータの保存）、RabbitMQ（非同期ジョブのキューイング）、Redis（セッション管理とキャッシュ）が必須です。これらを一つのネットワーク上で連携させることで、高可用性な文書処理環境を構築できます。

以下の手順は、Ubuntu 24.04 LTS サーバーを前提とした典型的な設定例です。まず、ドキュメントサーバーのコンテナイメージをプルします。docker pull onlyoffice/documentserver コマンドを実行し、最新バージョンを取得しましょう。次に、PostgreSQL のデータベースを作成するスクリプトや初期化コマンドを実行します。ここで注意すべきは、RabbitMQ と Redis が起動していない状態で ONLYOFFICE コンテナが開始されると、接続エラーが発生してコンテナが再起動ループ（Crash Loop）に陥ることです。そのため、依存サービスの起動順序を Docker Compose の depends_on ディレクティブで制御することが必須となります。

version: '3.8'
services:
  app:
    image: onlyoffice/documentserver:latest
    container_name: onlyoffice-docs
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./data:/var/www/onlyoffice/Data
      - ./logs:/var/log/onlyoffice
    depends_on:
      - db
      - redis
      - rabbitmq
    environment:
      - DB_TYPE=postgresql
      - DB_HOST=db
      - REDIS_HOST=redis

  db:
    image: postgres:16
    container_name: onlyoffice-db
    restart: always
    volumes:
      - ./postgres_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=StrongPasswordChangeMe
      - POSTGRES_USER=onlyoffice

  redis:
    image: redis:7-alpine
    container_name: onlyoffice-redis
    restart: always
    volumes:
      - ./redis_data:/data

  rabbitmq:
    image: rabbitmq:3.12-management
    container_name: onlyoffice-rabbitmq
    restart: always
    ports:
      - "5672:5672"
      - "15672:15672"
    volumes:
      - ./rabbitmq_data:/var/lib/rabbitmq

  nginx-proxy:
    image: nginx:alpine
    container_name: onlyoffice-nginx
    restart: always
    ports:
      - "8080:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf

上記の docker-compose.yml は基本的な構成を示しています。実際の運用では、データベースパスワードを環境変数ファイル（.env）から読み込むようにし、コンテナ起動時に自動的に暗号化された情報を管理することを推奨します。また、db サービスの POSTGRES_PASSWORD には必ず複雑なパスワードを設定してください。初期設定後は、ONLYOFFICE の管理画面にログインしてデータベース接続テストを行う必要があります。ここで成功すれば、後続の Nextcloud 連携や外部アクセスが可能になります。

Nextcloud 30 と Seafile 12 との連携方法（Connector プラグイン）

セルフホスト文書サーバーの真価は、ファイルストレージシステムとの統合にあります。ONLYOFFICE Document Server は単独でも編集可能ですし、ブラウザから直接アクセスしてドキュメントを作成・保存もできますが、多くのユーザーはすでに Nextcloud や Seafile などのクラウドストレージを利用しています。2026 年現在、Nextcloud 30 と Seafile 12 は最も人気のあるオープンソースファイル共有ソフトウェアであり、これらと ONLYOFFICE を連携させることで、Web ブラウザ上で「ドキュメントを開く」操作をシームレスに行えるようになります。

まず Nextcloud 30 との連携について解説します。Nextcloud の管理画面から「アプリ（Apps）」メニューにアクセスし、「ONLYOFFICE Docs」というプラグインを検索してインストールします。このプラグインは、Nextcloud がアップロードされたドキュメントファイルをクリックした際に、バックグラウンドで ONLYOFFICE Document Server へリクエストを飛ばし、ブラウザ上で編集可能なウィンドウを表示させる役割を果たします。設定画面では、「ドキュメントサーバーの URL」に http://localhost または Docker のホスト名（例：http://onlyoffice-docs）を指定する必要があります。ただし、外部からアクセスする場合は HTTPS 対応が必須となるため、リバースプロキシ経由での URL 登録となります。

Seafile 12 との連携も同様のプロセスを踏みます。Seafile の管理コンソールには「ONLYOFFICE Docs」設定項目が存在し、Server Address（サーバーアドレス）と Secret Key（秘密鍵）の入力を求められます。この Secret Key は、ONLYOFFICE Document Server の管理画面（/login などではなく、ドキュメント編集サーバーの内部設定画面）から取得する必要があります。このキーを設定することで、Seafile ユーザーがドキュメントを編集する際に、正当なユーザーのみが ONLYOFFICE サーバーにアクセスできる認証フローが確立されます。

JWT トークンによる連携はセキュリティ強化のために強く推奨されます。Nextcloud や Seafile が ONLYOFFICE に対してリクエストを送信する際、API キーだけでなく JWT（JSON Web Token）方式で認証情報を渡す設定を行うことで、リクエストの改ざんやなりすしを防ぎます。具体的には、Nextcloud の設定画面で「JWT 署名鍵」を設定し、ONLYOFFICE サーバー側でも同じ秘密鍵を受け渡す構成にします。これにより、ドキュメント編集セッションの安全性が大幅に向上し、第三者による不正な編集アクセスを防止できます。また、2026 年時点では SSO（シングルサインオン）機能との連携も強化されており、Nextcloud のログイン状態で ONLYOFFICE への再認証が必要ない設定が可能です。

この連携により、ユーザーは Nextcloud や Seafile の Web ファイルブラウザから直接ドキュメントを開くだけで、専用ソフトを起動せずとも編集を開始できます。特にモバイル端末からのアクセスにおいても、Nextcloud App と ONLYOFFICE の連携が確立されているため、スマートフォンやタブレットでの文書確認・軽編集が可能となり、業務の柔軟性が格段に向上します。

Office ファイルの編集と互換性検証（Word, Excel, PowerPoint 形式）

ONLYOFFICE が他社製品と比較して優れている点は、マイクロソフト Office のファイル形式に対する高いネイティブ対応率です。2026 年時点においても、.docx、.xlsx、.pptx は Office Open XML (OOXML) 標準に基づいており、ONLYOFFICE のレンダリングエンジンはこの標準をほぼ完全に実装しています。これにより、Word で作成された文書が、ONLYOFFICE を使用した際にレイアウト崩れやフォント欠落を起こすことが極めて少ないです。特に、表組みの複雑な配置や、スタイルシート（CSS 相当）による見出しの整形において、Microsoft Office との互換性は 95% 以上と評価されています。

Excel の数式計算機能については、バージョン 8.x でさらに強化されました。2026 年現在、VBA（Visual Basic for Applications）のスクリプト実行は完全にはサポートされていませんが、主要な数式関数やピボットテーブルの表示・編集、グラフの描画は問題なく動作します。特に大規模なデータセットにおける計算速度については、Redis をキャッシュサーバーとして利用することで、メモリアクセスを最適化し、従来バージョンよりも 30% 程度高速化されています。ただし、マクロ機能を含むファイルを開く際や、外部リンクを持つワークシートがある場合は、一部機能が制限される可能性があります。

PowerPoint の編集においては、スライドのアニメーションやモーショングラフィックスのプレビューがブラウザ上でも可能となりました。ただし、高度な 3D アニメーションや特定のフォントを使用した演出については、ネイティブ PowerPoint と完全に一致しない場合があります。そのため、プレゼンテーション資料を最終的に PowerPoint として配布する場合は、完成後に「Office 互換モード」でエクスポートしてファイル形式を確認することが推奨されます。また、フォント埋め込み機能も標準搭載されており、クライアント側で対応していないフォントを表示しても、画像化や代替表示ではなく、元のフォントに近い描画を試みるため、デザイン崩れを最小限に抑えています。

このように、一般的なビジネス文書作成には ONLYOFFICE が十分に対応可能です。ただし、Microsoft Office のマクロ機能に依存した業務システムを運用している場合は、そのマクロが ONLYOFFICE で動作しない可能性を理解しておく必要があります。代替案として、VBA を避けた数式設計や、JavaScript による Web API コードへの移行を検討することが長期的な互換性向上の鍵となります。また、自社のカスタムフォントを使用する際にも、ONLYOFFICE サーバー内にフォットをインストールし、編集環境から参照可能に設定することで、一貫したデザイン維持を実現できます。

セキュリティ強化設定（Let's Encrypt, JWT トークン，リバースプロキシ）

セルフホストシステムにおいてセキュリティは最も重要な要素の一つです。ONLYOFFICE Document Server はデフォルトで HTTP 接続を使用しますが、これを HTTPS で保護するために SSL/TLS 証明書の取得と設定が必要です。2026 年現在は Let's Encrypt が無料かつ自動更新に対応しており、この証明書を利用してリバープロキシサーバーを構成するのが標準的なベストプラクティスです。Nginx または Traefik をリバースプロキシとして導入し、外部からの HTTPS リクエストを ONLYOFFICE のコンテナポート（80/443）に転送する設定を行います。

Let's Encrypt による証明書取得には Certbot ツールを使用します。例えば Nginx を使用する場合、certbot --nginx コマンドを実行することで、自動で Nginx の設定ファイルが書き換えられ、HTTPS リダイレクトも設定されます。ただし、ONLYOFFICE コンテナ自体に SSL 証明書ファイルを配置するよりも、リバースプロキシ側で終端させる方が管理が容易です。これにより、コンテナの再起動や更新時に証明書の再取得が不要となり、運用負荷を軽減できます。また、TLS 1.2 または TLS 1.3 のみを有効にし、古いプロトコル（SSLv3, TLS 1.0）の接続をブロックすることで、セキュリティホールを防ぎます。

JWT トークンによる認証強化も必須です。前述の Nextcloud や Seafile と連携する際だけでなく、直接 ONLYOFFICE にアクセスする場合にも、ユーザーの権限を管理する必要があります。JWT（JSON Web Token）は、リクエストヘッダーに署名されたトークンを添付することで、サーバー側でその正当性を検証します。ONLYOFFICE の設定ファイル（docservice.json 等）または環境変数を通じて、JWT 署名キーを設定します。これにより、不正なリンクが共有されても、認証されていないユーザーはドキュメント編集にアクセスできなくなります。また、トークンの有効期限を設定することで、セッションの安全性をさらに高めることが可能です。

リバースプロキシの設定においては、WAF（Web アプリケーションファイアウォール）機能の利用も検討してください。Nginx には ModSecurity モジュールや、Traefik には自動 WAF フィルタリング機能があります。これらを活用することで、SQL インジェクションやクロスサイトスクリプティング（XSS）攻撃から ONLYOFFICE サーバーを保護できます。特に文書編集サーバーは、ファイルアップロード機能を利用するため、マルウェアの拡散リスクが存在します。そのため、アップロードされるファイルの拡張子制限やサイズ制限、ウイルススキャンの実施も併せて行うことが推奨されます。

これらの設定を組み合わせることで、ONLYOFFICE Document Server は外部ネットワークへの公開にも耐えうる堅牢なシステムとなります。ただし、セキュリティ対策は一度きりではなく、定期的なパッチ適用やログの監視が不可欠です。Docker コンテナのバージョン更新時には、依存ライブラリの脆弱性情報を確認し、必要に応じてコンテナイメージを再構築してください。また、バックアップ計画も重要で、データベースと設定ファイルを定期的にスナップショットとして保存することで、システム障害発生時の復旧時間を最小化できます。

運用におけるトラブルシューティングと最適化（キャッシュ，フォント，バックアップ）

ONLYOFFICE Document Server を運用する際、頻繁に遭遇するのが「編集が重い」「ファイルが開けない」といったパフォーマンスに関する問題です。これらの多くはキャッシュ機能やリソース配分の不備に起因します。Redis は ONLYOFFICE において重要な役割を果たしており、セッション管理だけでなく、ドキュメントのプレビュー生成時のキャッシュとしても利用されます。Redis に十分なメモリを割り当てていない場合、頻繁なファイル開閉時にディスク I/O が発生し、応答速度が低下します。したがって、docker-compose.yml 内で Redis コンテナに maxmemory-policy allkeys-lru などのポリシーを設定し、キャッシュ効率的な運用を行うことが重要です。

フォントの問題も運用で頻出するトラブルです。自社のロゴや社名が入った文書では、標準のフォント（Arial, Times New Roman など）だけでなく、独自フォントを使用する必要があります。ONLYOFFICE サーバー上にこれらのフォットをインストールし、システムが認識させることで、編集時に表示崩れを防げます。具体的には、U[bun](/glossary/bun-runtime)tu 環境であれば /var/www/onlyoffice/Data/fonts ディレクトリにフォットファイルを配置し、fc-cache -fv コマンドを実行してキャッシュを更新します。また、Nextcloud と連携する際にも、同じフォント設定を行う必要がありますが、ONLYOFFICE サーバー側の設定を優先させることで、一貫した表示を実現できます。

バックアップ戦略はデータを守るために不可欠です。ONLYOFFICE のデータ構造は、PostgreSQL データベース（メタデータ）と Redis/RabbitMQ（キャッシュ/キュー）、そしてファイルストレージ（ドキュメント本体）の 3 つに分かれています。これらを別々にバックアップする必要がありますが、特に重要なのは PostgreSQL のダンプです。pg_dump コマンドを使用して定期的なスナップショットを取得し、外部ストレージ（S3 バケットや NAS など）に保存します。また、コンテナ設定ファイル自体も git リポジトリなどでバージョン管理しておくと、システム再構築時のミスを防げます。

トラブルシューティングにおいては、ログの確認が第一歩です。docker logs onlyoffice-docs コマンドでメインのログを確認し、エラーメッセージを特定します。また、PostgreSQL の接続エラーが発生している場合は、db コンテナの POSTGRES_PASSWORD が一致しているか確認してください。RabbitMQ 関連のエラーが出た場合でも、キューが溢れて処理待ちの状態になっている可能性があり、その場合は RabbitMQ の管理画面（ポート 15672）からメッセージをクリアするなどの処置が必要です。

Collabora Online との比較検討（機能表，同時接続，コスト）

セルフホスト文書サーバーには、ONLYOFFICE の他に「Collabora Online」が代表的な選択肢です。LibreOffice ベースのコラボレーションソフトウェアであり、GNU GPL ライセンスの下で開発されています。2026 年時点で ONLYOFFICE と Collabora を比較する際、考慮すべき点は互換性、機能性、そしてコストのバランスです。Collabora はオープンソースとしての歴史が長く、コミュニティサポートが厚いですが、ファイル表示の精度においては ONLYOFFICE の方が Office 形式に対して優位です。

ONLYOFFICE の最大の強みは、マイクロソフト Office とのファイル形式互換性です。Collabora は LibreOffice をベースにしているため、Office の複雑なスタイルやマクロ機能を完全に再現する必要がある場合、ONLYOFFICE に劣る場合があります。特に企業で Microsoft Office ファイルを頻繁に扱う環境では、レイアウト崩れが業務効率を阻害するため、ONLYOFFICE が選定されるケースが多いです。しかし、GNU GPL ライセンスの遵守が必要なプロジェクトや、完全なオープンソースエコシステムを望む場合は Collabora の方が適しています。

同時接続におけるコスト面については、両者とも Community Edition は無料ですが、大規模運用ではライセンス購入が必要です。ONLYOFFICE のエンタープライズ版は、サポート体制と高度な管理機能（ホワイトラベルなど）を提供します。Collabora Enterprise も同様の機能を有しますが、価格帯やサポート範囲が異なります。また、Google Docs や Microsoft Office Online と比較すると、これらはクラウド依存であり、データ主権の問題を解決できないため、オンプレミス環境では ONLYOFFICE や Collabora が唯一の選択肢となります。

よくある質問（FAQ）

Q: ONLYOFFICE の無料版と有料版の違いは何ですか？ A: 最大の違いはサポート体制と高度な管理機能です。Community Edition はすべての基本機能が無料で利用可能ですが、技術的なトラブル解決時の公式サポートはありません。Enterprise Edition では電話やメールでのサポートが提供され、ホワイトラベル機能（ロゴ変更）や高度な監査ログ、LDAP/AD 連携の強化機能が利用可能です。小規模利用なら無料版で十分です。

Q: スマートフォンからの編集は可能でしょうか？ A: はい、可能です。ONLYOFFICE は Web ベースアプリケーションであるため、iOS や Android のブラウザからアクセスできます。ただし、モバイル端末の処理能力や画面サイズの影響を受けるため、大規模な Excel ファイルの編集には適さない場合があります。専用アプリの利用も推奨されます。

Q: Docker 以外でのインストールは可能ですか？ A: はい、Snap パッケージや、ソースコードからのビルドによるインストールも可能です。Snap は環境構築が簡単ですが、コンテナ間連携の設定がやや複雑になる場合があります。Docker Compose が最も標準的で推奨されています。

Q: VBA マクロを含む Excel ファイルは編集できますか？ A: 基本的に編集できません。ONLYOFFICE は VBA の実行環境を提供しておらず、マクロが含まれるファイルを開くとマクロ部分が無視されるか、エラーが表示されます。Excel の数式計算機能自体は正常に動作します。

Q: Nextcloud との連携で JWT トークンは必須ですか？ A: 必須ではありませんが、セキュリティ強化のために強く推奨されます。API キーのみでの接続も可能ですが、JWT を使用することでリクエストの改ざん防止やセッション管理の安全性が高まります。

Q: サーバーを再起動するとデータは消えますか？ A: Docker コンテナの設定次第です。ボリューム（volumes）としてデータをマウントしていれば、コンテナ削除後もデータは残ります。ただし、定期的なバックアップ取得が必須であり、再起動時に自動的に復元される仕組みではありません。

Q: 日本語フォントの表示がおかしいですがどうすればよいですか？ A: サーバー OS に日本語フォット（IPA ゴシックなど）をインストールし、ONLYOFFICE の fonts ディレクトリに配置してください。その後、キャッシュを更新するコマンドを実行してシステムが認識させる必要があります。

Q: 外部公開する際、ポート番号を変更できますか？ A: はい、リバースプロキシの設定や Docker Compose のポートマッピングを変更することで可能です。ただし、セキュリティを考慮し、HTTP ではなく HTTPS（443 番）を使用することが強く推奨されます。

Q: バックアップはどのように行うべきですか？ A: PostgreSQL データベースのダンプと、ドキュメントファイルの保存ディレクトリを別々にバックアップする必要があります。定期的なスクリプト実行や、外部ストレージへの自動転送設定が望ましいです。

まとめ

本記事では、ONLYOFFICE Document Server のセルフホスト構築について、2026 年時点の最新情報を元に詳細に解説いたしました。以下の要点をまとめます。

• データ主権とコスト削減: ONLYOFFICE をセルフホストすることで、外部クラウドへの依存を減らし、サブスクリプション費用を削減できます。
• Docker Compose の活用: Docker コンテナによるデプロイが標準であり、[PostgreSQL, Redis, RabbitMQ の連携構成により高可用性を実現します。
• Nextcloud/Seafile 連携: Cloud Storage との統合により、Web ブラウザ上でシームレスな編集体験を提供できます。JWT トークンによる認証強化も重要です。
• Office 互換性: Word, Excel, PowerPoint のファイル形式に対して高い互換性を示し、レイアウト崩れを最小限に抑えます。
• セキュリティ対策: Let's Encrypt を用いた HTTPS 化と WAF 機能の導入により、公開環境でも安全な運用が可能です。
• Collabora との比較: 文書表示精度では ONLYOFFICE が優位ですが、完全オープンソース重視なら Collabora も選択肢となります。

SELFHOSE の文書管理システムは、初期設定の手間こそありますが、一度構築されれば長期的に安定して機能します。システム管理者の皆様には、本ガイドを参考に、ご自身の環境に最適な ONLYOFFICE 構成をご検討ください。