Collabora CODEコンテナがARM64アーキテクチャで起動しない問題を修正する

Collabora Online Development Edition (CODE) コンテナが ARM64 マシンで即座に終了する場合は、ネットワーク、証明書、または WOPI 設定を変更する前に、まずアーキテクチャの互換性を確認してください。2026 年 10 月 7 日現在、公式リポジトリには、現在のタグとバージョン 26.04.4.2.1 を含む、現在のリリース用のcollabora/codeネイティブバリアントがリストされています。つまり、最新の ARM64 ホストでは、CODE を実行するためだけに x86 エミュレーションが必要になることは通常ありません。初心者にとって最も役立つワークフローは、ホストのアーキテクチャを確認し、正確なイメージ タグを調べ、強制的に適用された AMD64 設定をすべて削除し、ARM64 対応のイメージをプルしてから、アプリケーション レベルの構成のトラブルシューティングを行うことです。linux/arm64latest

このガイドは、起動失敗そのものに焦点を当てています。すべてのARM64の問題が同じ原因によるものだとは想定していません。コンテナが正常に起動しても、Nextcloud、ownCloud、または他のWOPIホストが接続できない場合は、別のトラブルシューティングが必要になります。

変更を加える前に知っておくべきこと

ARM64は 64 ビット ARM CPU アーキテクチャです。Linux では一般的に と表記されますaarch64が、Docker では通常同じターゲットを と表記しますlinux/arm64。AMD64 ( x86-64 とも呼ばれる) は別の CPU アーキテクチャです。コンテナ イメージには、1 つ以上のアーキテクチャ用にビルドされたバイナリが含まれています。Docker は、イメージ タグに互換性のあるマニフェストが提供されている場合にのみ、適切なバリアントを自動的に選択できます。

マルチプラットフォームイメージとは、レジストリマニフェストがAMD64やARM64などのアーキテクチャ向けに個別のイメージビルドを指す、単一のイメージタグです。Dockerのドキュメントによると、マルチプラットフォームイメージをプルすると、ホストに一致するバリアントが自動的に選択されます。詳細な動作については、Dockerのマルチプラットフォームイメージに関するドキュメントを参照してください。

Collabora CODE に関しては、古いチュートリアルに頼るのではなく、Docker Hub の公式 collabora/code タグ リストを確認してください。この記事は 2026 年 10 月 7 日に確認され、latestが26.04.4.2.1含まれておりlinux/arm64、専用のlatest-arm64タグもリストされていました。古い固定リリースでは異なる場合があるため、「Collabora は ARM をサポートしています」という一般的な主張よりも、実際にデプロイするタグの方が重要です。

安全なトラブルシューティングセッションを準備する

• 現在実行中のコマンドまたは展開コマンドのコピーを保管してくださいdocker-compose.yml。
• 使用しているCollaboraの画像タグを正確に記録してください。
• アーキテクチャの不一致を診断するためだけに、アプリケーションデータやリバースプロキシの設定を削除しないでください。
• これが本番環境へのデプロイである場合は、まずメンテナンスウィンドウ内またはステージングホストで代替タグのテストを行ってください。

目標とする結果は単純です。DockerはARM64イメージをプルし、コンテナはすぐに終了するのではなく実行状態を維持し、ログはアーキテクチャエラーで失敗するのではなく、通常のCollaboraの起動へと進むべきです。

ステップ1：ホストとDockerアーキテクチャを確認する

Collaboraコンテナを実際に実行しているマシンで、以下のチェックを実行してください。

uname -m
docker info --format '{{.Architecture}}'
docker version

ネイティブの64ビットARM Linuxホストでは、uname -m通常 が返されますaarch64が、Dockerは を報告するはずですarm64。これらの名前は、このコンテキストでは同じアーキテクチャファミリーを指します。

物理マシンがARM64であるにもかかわらず、DockerがAMD64と報告する場合は、リモートDockerコンテキスト、仮想マシン、または異なるバックエンドを持つDocker Desktopのいずれを使用しているかを確認してください。続行する前に、この曖昧さを解消してください。そうしないと、あるシステムを検査しながら別のシステムにデプロイしてしまう可能性があります。

アーキテクチャの不一致を示すエラーはどれですか？

典型的なシグナルとしてはexec format error、レジストリに が存在することを示すメッセージno matching manifest for linux/arm64や、 で明示的に構成された Compose サービスなどがありますplatform: linux/amd64。これらのメッセージは、一般的な「コンテナが終了しました」という出力よりも、プラットフォームの不一致を示す強力な証拠となります。

ステップ2：Collaboraイメージタグを取得する前に、そのタグを正確に検査する

すべての過去のタグが今日のタグと同じプラットフォームをサポートしているとは限りませんlatest。デプロイメント内のタグのレジストリメタデータを確認してください。

docker buildx imagetools inspect collabora/code:latest

Docker のbuildx imagetools inspect のドキュメントには、このコマンドがレジストリ イメージに含まれるプラットフォームを表示する方法が説明されています。また、 Docker はマニフェスト検査リファレンスdocker manifest inspectでこのコマンドを文書化しています。

が表示された場合はlinux/arm64、マルチプラットフォームタグを使用して、Docker に適切なイメージを選択させることができます。明示的なトラブルシューティング テストについては、公式リポジトリにも が記載されていますlatest-arm64。長期間運用される本番環境では、新しいリリースが公開されるたびに が移動するlatestため、テスト済みの正確なバージョン付きタグの方が よりも再現しやすい場合がほとんどですlatest。

ピン留めしたタグにARM64が含まれていない場合、次の3つの選択肢があります。

ステップ3：誤って適用されたAMD64オーバーライドを削除し、クリーンにプルします。

よくある失敗は、Collabora イメージ自体ではなく、間違ったプラットフォームを強制するデプロイメント ファイルです。Docker Compose は、platformイメージ バリアントを選択するために使用されるターゲット オペレーティング システムとアーキテクチャを定義します。Docker のCompose サービス リファレンスには、などの値が表示されますlinux/arm64/v8。

ARM64ホストでは、この設定は疑わしい。

services:
  collabora:
    image: collabora/code:latest
    platform: linux/amd64

エミュレーションが不要な場合は、その行を削除して、Dockerにホストネイティブのバリアントを選択させてください。あるいは、platform: linux/arm64アーキテクチャを明示的に指定したい場合は、その旨を指定してください。

次に、障害が発生したコンテナのみを削除し、イメージを再プルしてください。特別な理由がない限り、永続データは削除しないでください。

docker compose down
docker image rm collabora/code:latest 2>/dev/null || true
docker pull --platform linux/arm64 collabora/code:latest
docker compose up -d

診断実行に専用のアーキテクチャ タグを使用する場合は、 を に置き換えてくださいcollabora/code:latest-arm64。デプロイメントが正常に動作することを確認したら、本番システムを変動するタグのままにしておくのではなく、テスト済みの 26.04.x タグなどの正確なリリースを固定することを検討してください。

ステップ4：統合のトラブルシューティングを行う前に、CODEが起動することを確認します。

コンテナを再作成した後、状態とログを確認してください。

docker compose ps
docker compose logs --tail=100 collabora

単一コンテナのデプロイメントの場合、同等のコマンドは とdocker ps -aですdocker logs --tail=100 <container-name>。

最初の成功基準は、コンテナが起動状態を維持し、マニフェストまたは実行可能ファイル形式のエラーで失敗しなくなることです。その後で初めて、ポート9980への到達可能性、リバースプロキシ設定、TLS、許可されたWOPIホスト、またはアプリケーション統合に進むべきです。現在のデプロイメントパラメータを確認するには、Collaboraの公式CODE Dockerドキュメントを参照してください。

初心者がよく犯す間違いを避ける

公式イメージを確認する前にQEMUをインストールする

エミュレーションは、ソフトウェアが別のCPUアーキテクチャ向けにしか存在しない場合に役立ちますが、現在のCollabora CODEイメージにはARM64版が含まれています。最初にエミュレーションを追加すると、本当の問題が隠蔽され、別の要素が加わることになります。必要なCODEバージョンでネイティブARM64が提供されている場合は、そちらを優先してください。

「最新」と古い固定タグが同等であると仮定する

プラットフォームの可用性は、特定のイメージタグとマニフェストに紐づいています。最新のタグはARM64をサポートしていますが、古いリリースではサポートしていません。Composeファイル内の正確な参照箇所を確認してください。

古いガイドで使われていたため、プラットフォームをlinux/amd64に強制します。

これにより、ネイティブのARM64イメージが存在する場合でも、ARM64ホストがx86-64版をプルしてしまう可能性があります。エミュレーションを行う意図的でテスト済みの理由がない限り、オーバーライドを削除してください。

プロセスを実行する前に、WOPI、SSL、またはプロキシの設定を変更してください。

exec format errorCollaboraがアプリケーションレベルの設定を効果的に処理できるようになる前に、問題が発生します。まずはアーキテクチャの選択を修正してください。ネットワークとWOPIのトラブルシューティングは後回しで構いません。

診断中にボリュームを削除する

アーキテクチャの不一致は通常、永続データを削除する必要はありません。ロールバックを容易にするため、修正範囲は狭く抑えてください。

ARM64イメージがまだ存在する場合はどうすればよいでしょうか？

マニフェストにそのバリアントが明確に含まれておりlinux/arm64、Docker がそのバリ​​アントをプルする場合、アーキテクチャはもはや主要な説明要因ではありません。その時点で、以下をキャプチャします。

• docker compose psまたはdocker ps -a
• 最後の100～200行のログ
• 正確なCODEタグ
• Docker EngineとComposeのバージョン
• Composeサービス定義の非機密部分

次に、実際のログメッセージに基づいて、権限、マウントされたパス、セキュリティプロファイル、メモリ負荷、ポートの競合、証明書、またはWOPI構成を調査します。実行中のイメージがARM64であることを確認したら、アーキテクチャを繰り返し切り替えることは避けてください。

実践的な意思決定の道筋

1. ホストがARM64でない場合は、ARM64専用の修正プログラムの使用を中止し、実際のプラットフォームを診断してください。
2. ホストがARM64であるにもかかわらず、選択したCODEタグにARM64マニフェストがない場合は、サポートされているネイティブタグに移行するか、意図的に別のホスティング戦略を選択してください。
3. タグがARM64をサポートしているにもかかわらず、ComposeがAMD64を強制している場合は、そのplatform設定を削除または修正してください。
4. 正しいARM64イメージがまだ存在する場合は、CPUアーキテクチャのせいにし続けるのではなく、通常のCollabora起動時の問題として扱い、ログを追跡してください。

結論

最新のARM64システムでは、通常、エミュレーションは推奨される解決策ではありません。2026年10月7日に確認したところ、現在の公式Collabora CODEタグにはネイティブARM64イメージが含まれています。ホスト上でaarch64/を確認しarm64、正確なイメージマニフェストを調べ、古いまたは強制されたAMD64参照を削除し、ARM64互換イメージを再プルして、コンテナが引き続き実行されていることを確認します。この手順により、トラブルシューティングが初心者にも分かりやすくなり、無関係なSSL、プロキシ、またはWOPIの変更によって基本的なプラットフォームの不一致が隠蔽されるのを防ぎます。