Euro-Officeを試してみた

きっかけ

最近「Euro-Office」というプロジェクトの名前を見かけるようになりました。

EUの公共機関がMicrosoft Officeへの依存から抜け出すことを目的として2026年3月に始まったプロジェクトです。Euro-Officeはセルフホスト型のオフィススイートで、Word / Excel / PowerPoint相当のファイルをWEBブラウザで開いて編集できるドキュメントサーバです。

実態は、Ascensio System SIA社が開発・提供する「ONLYOFFICE Document Server」のフォークで、DOCX / XLSX /PPTX変換やREST APIまわりの構造をほぼ引き継いでいる様子です。

「ONLYOFFICEのフォークで、APIもほぼ互換」と聞くと、以前よりFileBlogではONLYOFFICE連携ができているのであるから、当然「Euro-Office」も同様に連携できるのではと考えました。

そこで、とりあえず試してみました。

環境を用意する

FileBlogはWindows環境で動作する一方、Euro-OfficeはLinux前提のようでネイティブのWindows向けパッケージは見当たりません。Windowsマシンに直接インストールすることはできないため、今回はDockerコンテナを使うことにしました。

まずJWTシークレットを自前で生成するところから始め、WindowsのPowerShellで32バイトのランダム値を16進文字列にして作ります。

$bytes = New-Object byte[] 32
[System.Security.Cryptography.RandomNumberGenerator]::Create().GetBytes($bytes)
$secret = ($bytes | ForEach-Object { $_.ToString("x2") }) -join ""
$secret

出力された値は、あとでFileBlog設定にも使用するためメモしておきます。

続けてコンテナを起動するコマンドを実行します。上記のJWTシークレットがそのまま反映されます。

docker run -d `
  --name euro-office `
  --restart=unless-stopped `
  -p 8099:80 `
  -e JWT_ENABLED=true `
  -e JWT_SECRET=$secret `
  -e EXAMPLE_ENABLED=true `
  ghcr.io/euro-office/documentserver:latest

動作成功とはなりませんでした。FileBlog（Windowsのローカル起動）からEuro-Officeのコンテナへコールバックする際、プライベート/ローカルアドレス宛のリクエストがデフォルトでブロックされてしまったようです。ALLOW_PRIVATE_IP_ADDRESS=trueを追加してコンテナを構築し直しました。

Server-Side Request Forgery（SSRF）対策として内部からのプライベート IP 宛アクセスを制限しているケースで、ONLYOFFICEのドキュメントサーバでもよくある設定です。

docker rm -f euro-office

docker run -d `
  --name euro-office `
  --restart=unless-stopped `
  -p 8099:80 `
  -e JWT_ENABLED=true `
  -e JWT_SECRET=$secret `
  -e EXAMPLE_ENABLED=true `
  -e ALLOW_PRIVATE_IP_ADDRESS=true `
  ghcr.io/euro-office/documentserver:latest

$secretは最初に生成したものをそのまま使用しているので、FileBlog側のDocumentServerSecretも変更不要です。--restart=unless-stoppedでDocker再起動時にも自動起動させ、EXAMPLE_ENABLED=trueはEuro-Office付属のサンプルページを有効化するオプションとして動作確認用に起動するようにしました。

JWTまわりの環境変数名（JWT_ENABLED / JWT_SECRET）まで含めて、見た目はONLYOFFICEとほぼ同じです。公式ドキュメントにも「REST APIなので他のDMS連携にも使える」とあります。

JWTとWebSocket

JWT（JSON Web Token）とは、WEBアプリ（FileBlogなどのDMS）とEuro-Officeのドキュメントサーバの間でやり取りするAPIリクエストが、正規のものであることを確認するための仕組みです。上記のJWT_SECRETをアプリ側とドキュメントサーバ側で同じ値にしておき、リクエストにこのシークレットで署名したトークンを付けることで、正規リクエスである（なりすましではないこと）を互いに検証します。源流であるONLYOFFICEから使用されている仕組みです。

ドキュメントサーバはWebSocketで常時接続を維持しています。Dockerでコンテナを構築する際、HTTPポート（80番）だけでなく、WebSocket用の通信も同じエンドポイント経由で通す構成になっています。そのため、リバースプロキシなどを挟む場合は、WebSocketのアップグレードリクエストを正しく通す設定が必要です。WebSocketは本来、共同編集における各クライアントへのリアルタイム差分配信のための通信です。FileBlog運用ではMicrosoft Officeでのデスクトップ編集も併用できるため、ONLYOFFICE（Euro-Office）の共同編集機能は提供していません。

FileBlogの設定を変えるだけ

既存のONLYOFFICE連携部分の設定概要です。

ドキュメントサーバのエンドポイントURL
JWTシークレット
コールバックURL（保存時にFileBlogへ通知してもらう用）

ここをEuro-OfficeのURLとシークレットの値で設定しました。ONLYOFFICE用に用意している設定部分に一切の修正を加えずそのまま使用しました。

結果：問題なく動いた

FileBlogからファイルを開くと、見慣れたONLYOFFICE風のエディタUIが表示され、編集・保存・コールバックによるFileBlog（ファイルサーバ）への書き戻しまで一通り動作しました。日本語にも対応しています。見た目や操作感では、これまでのONLYOFFICE連携との違いが分かりません。「フォーク・API互換」というのは間違いなさそうです。

ただし、UIは日本語対応しているものの、コンテナに日本語入力用のフォントが入っておらず、日本語文書の閲覧・編集には違和感があったので、オープンソースである文字情報技術促進協議会が公開している「IPAexフォント」をインストールしてみました。Microsoftは、Linux/Docker向けに日本語フォントを配布していません。

今回の確認は基本的な開く・編集する・保存するの一連の流れだけで、細かい機能差分については確認していません。FileBlogとの連携でONLYOFFICE同様に「どうやら使用できそうだ」という認識は持てました。