はじめに 見出しへのリンク
大量のデータをオンラインで保存し管理したい場合、現代においては Google Drive や iCloud 、 OneDrive など GAFAM のサービスへデータをアップロードするケースが多いと思います。個人なら2TBで付帯サービスもついて月々1500円程度といった相場感で、契約されている方も多いのではないでしょうか。
一方で、企業・団体、個人のポリシーや制約により、こうした米国資本・ビッグテックへデータを預けたくない、預けられない方もいらっしゃると思います。ゼロかイチとまで行かなくとも、一部の重要な機密データだけはどうしても自前のインフラに保持しておきたい等の使い分けもあるでしょう。 かくいう私も、個人用に Nextcloud をホストしています1。 また、各サービスの AI 機能に対するプライバシー面での警戒感も少しずつ上がってきているように感じます。10月には、 OneDrive が「顔認識機能のオフは年に3回まで」という制約を設けようとしたことが波紋を広げました2。相手が GAFAM となると、こうした改悪に対しても堂々と文句を言える立場はそう多くありません。デジタル主権とはかくも難しいものです。
オンプレオンラインストレージの代表格こと Nextcloud 見出しへのリンク
こういった事情もあって、内製オンラインストレージを立ち上げる場合は規約や企業に縛られにくい OSS のソフトウェア、代表的なものとして Nextcloud がかなり有名です。 Nextcloud3 は 2016 年に生まれた4 PHP 製のソフトウェアで、OSS (AGPL) のため誰でも自由に利用することができます。ざっと調べてみただけでも国内企業や大学での採用事例がヒットするとともに、個人で立ち上げている例も大勢見つかりました5。 Nextcloud 向けの拡張機能も豊富で、ファイル管理のほかにもオンライン通話・チャット、写真・動画・音楽といったマルチメディアギャラリー、Office っぽい文書作業環境など様々な機能が揃っています。つまり、うまく構築すれば Google Workspace や Microsoft 365 のようなオンラインオフィスのプラットフォームを内製できるようになっています(やや語弊がありますが)。 最近は AI 機能にも力を入れ始めており、ローカルで動作するモデルを含む多種多様な AI との連携機能もメリットとして謳っていたりします。自分たちがどのモデルをどういった手法で利用するかすらも選択できるようにするというわけです。
Nextcloud の課題 : 重い 見出しへのリンク
そんな素敵な Nextcloud ですが、課題があります。重いのです。 Nextcloud は WordPress と同様に古き良き PHP アプリケーションのため、 PHP が動作するウェブサーバとセットで動作させる必要があります。高速化のためには PHP の opcache などチューニングが必要で、 nginx などリバースプロキシの設定も詰めていく必要があります。 また、ファイルをデータベースで管理しているため、 MySQL / PostgreSQL といったデータベースサーバも必須です。かつファイルロックの高速化を行うには redis も必要になってきます。 現在は Nextcloud All-in-One という Docker ベースのパッケージが展開されており、これを使うと簡単に公式の推奨する設定での環境が構築できそうですが、細かい設定のチューニング自体は引き続き必要になってくるでしょう。
私も個人で使っている中で、特に細かいファイルを大量にアップロードしたい場合のパフォーマンス・エラー率が気になるケースがありました。初期の頃と比べると大分高速化された気がしますが、それでも完璧とは言えません。特にブラウザ用のインターフェースはイケておらず、多くのファイルをアップロードした際、エラーで失敗したファイルが欠落(アップロード失敗)することもしばしばでした。
その他の豊富な機能にしても、絶妙に中途半端という印象でした。多種多様な機能が利用できるということは、不要な機能が増えるという裏返しでもあります。 複数のアプリを入れていると、 Nextcloud やアプリのバージョンアップのタイミングで不具合が出て 500 エラーになる確率が上がります。アプリ同士のコードが衝突してエラーになったり、Nextcloud のメジャーアップデートリリース直後にアプリを管理する中央サーバが不安定になり、メジャーバージョンアップ時にアプリ更新が行えずエラーとなったこともありました。以前にオンライン通話のアプリを複数人で使ってみた際は、重すぎてサーバが応答不能になったりもしました。
これらのアプリや機能が現在改善されているかは定かではありませんが、私がここで述べたいのは、オンライン通話をはじめとした専門性の高い機能らについては「結局専用サービスの方が軽いし安定するじゃないですか」ということです。オンライン通話なら Zoom といった鉄板がありますし、 FOSS を選ぶにせよ Jitsi Meet といった実績のある専用アプリケーションがすでにあります。 さらに言えば、多くの顧客が求めているのはオンプレ版 Google Workspace でもなければ Microsoft 365 でもないでしょう。いわば NAS 的な、あくまでファイルをオンラインで管理するためのサービスとしての Nextcloud を求める方が大多数ではないでしょうか。その他の機能はオマケみたいなもので、ファイルアップロードのパフォーマンス、安定かつ軽量なインターフェースこそ本丸、最重要機能なはずなのです。
そういった観点で考えたとき、リリースの度に様々な機能拡張が華々しく宣伝されているのを見ると、いちユーザとしてやや複雑な気持ちになります。平たく言えば「最近、肥大化してきてない?」とどうしても思ってしまうわけですね6。
期待の新星 ownCloud Infinite Scale (oCIS) と OpenCloud 見出しへのリンク
oCIS とは 見出しへのリンク
そんな形で良くも悪くも大きくなっていく Nextcloud ですが、最近、 Nextcloud に対するアンチテーゼとして「軽量さ」を売りにしたオンラインストレージの OSS が出てきました。その名を ownCloud Infinite Scale と言います。
……あれ、どこかで見た名前だな、と思われた方もいらっしゃるかもしれません。それもそのはず、何を隠そう Nextcloud は ownCloud7 をフォークして生まれた存在なので、親というか始祖にあたる存在こそ ownCloud な訳です。 ownCloud 自体は Nextcloud が生まれてからゴタゴタがあったようで、ここ数年はめっきり存在感も薄かったのですが、軽量になった oCIS を引っさげて再び競争環境に戻ってきたというところでしょうか。
さて、この oCIS ですが、一体どうやって軽量化したのでしょうか? 答えを端的に言えば「PHP をやめて Golang で書き直した上で DB 依存をなくした」となります。 ownCloud にせよ Nextcloud にせよ、 PHP というスクリプト言語を使う以上、どう頑張っても事前コンパイルされたバイナリの速度には敵いません。それを脱却すべく、 Golang でバイナリ化できるようにしたということでしょう。言うは易しですが、なかなかアグレッシブな対応です。 そしてさらに挑戦的なのが、 DB 依存からの脱却です。 Nextcloud ではファイルを DB を用いて管理していました。したがって一貫性を保ちやすかった一方で、大量のファイルを処理する際にこれがボトルネックになりがちで、例えばファイルロックの高速化のために redis を持ち出したりしなければならなかったりと厄介な点であったことは否めません。また、ストレージのデータと DB の両方を正しくバックアップする必要がある(データだけだと権限などファイルの管理情報がリストアできない)という点も面倒なところでした。 oCIS ではこれを廃止し、実データのほかにメタデータもファイルとして扱うようにしました8。こうすることでバックアップはストレージだけで完結し、障害点や複雑性が少なくなっているというわけです。
どうやら ownCloud の顧客に大量ファイルを処理するニーズがあったらしく、その要件を適切かつ安定して満たすためにはこうせざるを得なかったのでしょう。その甲斐もあって、かなりパフォーマンスは向上しているようです。Nextcloud との比較結果は後述します。
oCIS のゴタゴタ、OpenCloud の誕生 見出しへのリンク
そんな素敵な oCIS ですが、ようやく軌道に乗ってきたはずの 2024 年に、開発メンバーと会社との間で意見の相違があったらしく、最終的に分裂騒動に発展してしまいます。そのため Nextcloud の時と同じ流れで OpenCloud9 がフォークとして誕生しました。さらに、oCIS の開発メンバーが複数名 OpenCloud 側に流れたと言われています10。これも Nextcloud の分裂時と酷似しており、外野からは如何ともしがたい状況です。 オンラインストレージの世界はいまいち分からないのですが、それくらい競争が激しい業界とみるか、偶然似たような対立が起こったのか……。
いずれにせよ、ゴタゴタを経て OpenCloud 側も少しずつ認知度が上がってきているようです。少し前までは出たばかりということもあり、ドキュメントも未整備で環境構築も難しい印象があったのですが、今は docker-compose 用の設定ファイルを含め以前より整ってきているように見えました。 DB やキャッシュサーバが不要なので、構成もシンプルになるはずです。
PosixFS 見出しへのリンク
ところで、さきほど oCIS では DB 依存をなくしたと書きました。その上で DB に依存せずファイルを管理するための方式について、後発の OpenCloud では大きく分けて二つの方式が用意されています:
- メタデータと実ファイルを分離する方式(Decomposed FS11。現状の oCIS のデフォルト)
- メタデータは POSIX のファイルシステムで管理し、実データは任意の場所に保存する
- これにより DB 依存を排しつつ、 S3 など非 POSIX のストレージに対してもデータを保存・管理できる
- ただし、ディレクトリ・ファイルのレイアウトがユーザの意図したものと異なるため、データの参照には「メタデータを解釈してアクセスするための実装」が必要になる(人間がそのまま判別できない)
- メタデータと実ファイルをセットで保存する方式(PosixFS12)
- メタデータを各実データのファイルの拡張属性として保存する
- これにより DB 依存を排し、かつユーザの意図通り(= ウェブインターフェースで見た通りのレイアウト)でデータを保存・管理できる
- さらに inotify で監視することで、ウェブ・アプリ外(シェル等)から直接操作されたファイルについても即時反映可能
- ただし、 S3 など非 POSIX ストレージには適用できない
1.の方式は S3 など外部ストレージ種別をある程度選ばない柔軟性を持つ一方で、レイアウトが人間が認識できる形式ではないため、データへのアクセスは実装に依存(≒ベンダーロックインリスク・複雑性が増加)となってしまいます。 その上で、 oCIS では安定性を加味して PosixFS が Experimental とされているところ、 OpenCloud では v2.0.0 以降デフォルトで PosixFS を使うように変更されています13。シンプルさをかなり推しているようですが、このあたりからも oCIS との思想の違いを感じますね。
Nextcloud と OpenCloud をざっくり比べてみる 見出しへのリンク
ここまでつらつらと説明を重ねてきましたが、説明文だけなら AI に負けてしまう時代です。 Nextcloud に対して対抗馬がどれくらい有力で軽量なのか、違いはどれくらいあるのか、実際に環境構築をした上で比較検証をしてみましょう。 検証にあたって、対抗として oCIS か OpenCloud のどちらを選ぶかで悩みましたが、今回は一番後発の OpenCloud を選んで Nextcloud と比較することにします。基本的な設計は同じでしょうから、 oCIS を選択してもさほどパフォーマンスに差は出ないだろうという判断です。見切り発車かもしれませんが、今回は時間や紙面の都合で oCIS は割愛とさせてください。
比較環境 見出しへのリンク
比較にあたり、なるべく公平な条件下でテストを行いたかったため、以下の環境を構築しました。Nextcloud と OpenCloud は別々のインスタンスにしています。
- ホスト環境 : Vultr にて Tokyo リージョン の
2 vCPU, 4096 MB RAM, 128 GB NVMe, 3.00 TB Transferインスタンスをレンタル(計2インスタンス) - OS :
Ubuntu Server 24.04- Kernel :
6.8.0-90-generic #91-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 18 14:14:30 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
- Kernel :
- Docker :
Docker version 28.2.2, build 28.2.2-0ubuntu1~24.04.1- Docker-Compose :
Docker Compose version v5.0.1
- Docker-Compose :
- モニタリング用ソフトウェア :
netdata v2.8.4
また、比較に使用した Nextcloud と OpenCloud のバージョンは以下の通りです。
- Nextcloud : Nextcloud (AIO) 32.0.3
- OpenCloud 4.1.0 rolling
Nextcloud は All-in-One14 、 OpenCloud は opencloud-compose15 をベースとして構築します。 どちらも docker-compose ベースで、 AIO ではウェブ画面、 OpenCloud-Compose では .env で初期設定を入力しました。 AIO についてはデフォルト設定ママで、 OpenCloud については以下、
Default: OpenCloud and Collabora with traefik and letsencypt
とあった設定に Radicale を加えた設定としています。これは Nextcloud がデフォルトでかなり多くの機能が有効にされているのと、 OpenCloud が極めてシンプルなため、なるべく OpenCloud を Nextcloud 側に寄せたかったという意図です。 あまりに両者の設計が違うのでこれが本当に公平かは議論の余地があると思いますが、どちらも公式が提供するデフォルト設定からは逸脱していないという前提で進めることにします。
なお、 OpenCloud は設定が難しいという話を目にしてはいたのですが、12月末現在においてはどちらも特に詰まることなく、少なくとも docker-compose を使う限りは構築難易度が高いとは感じませんでした。すでに改善されていたのかもしれません。これは嬉しい誤算です。 両者とも、設定は十数分で終わったと思います。
インターフェース 見出しへのリンク
さて、準備が整いました。パフォーマンスを確認する前に、まずはインターフェース・外観の差から見ていきましょう。
Nextcloud 見出しへのリンク
こちらは広く知られている画面ではありますが、念のため載せておきます。以下は AIO でセットアップした直後の画面です(Sampleフォルダだけ作成しています)。

青と白を基調としたデザインですっきりとしていますが、ホワイトボード、Collabora Office連携が有効になっており、上部のメニューバーからは様々な機能がデフォルトで有効であることが分かります。

また、 Nextcloud は ownCloud フォークかつ10年近くの歴史を持つため、エコシステムも盤石です。拡張アプリのインストール画面を開くと、画面いっぱいにアプリたちが並びます。痒いところに手が届く便利な機能がアプリという形で多数提供されているので、運用側としてはかなり助かりそうですね。

OpenCloud 見出しへのリンク
Nextcloud と異なり OpenCloud は .env で初期設定を投入後、コンテナを立ち上げるとすぐにログイン可能になりました。この時点でかなりシンプルなのですが、ログイン後の画面はさらにシンプルです。

濃い青緑にピンク色のロゴという絶妙な色合いはさておき、着目すべきはこのシンプルさです。Nextcloud もさしてゴチャついていたわけではありませんが、 OpenCloud のシンプルさはミニマリストのそれといったところです。なお、上記画像の Sample フォルダは私が実験のために作ったものですから、初回ログイン直後は全面真っ白だったということになります。
Nextcloud と違い、機能も至ってシンプルです。 左上のメニューアイコンらしきものを押すと、機能一覧が出てきます。

これだけです。不必要なものは絶対に入れないのだという意思を感じます。個人的には好感しますが、無骨さに面食らう方もいらっしゃるかもしれません。 ただ、メニューの中に App Store というのが見えますね。Nextcloud 同様、いろいろ拡張アプリがあるのかなと開いてみます。

全8つ。うち一つは明らかにテンプレートですから、実質意味を持つのは7つだけということになります。黎明期を体現している印象です。
これらの見ると、前評判通り OpenCloud は確かに軽量かつ肥大化していなさそうに見えます。その代わり、少なくとも2025年12月現在においては、公式が提供する機能以外の拡張アプリはほぼほぼ望めないものとみて間違いないでしょう。これは Nextcloud と異なり、 PHP から Golang へ書き換えたことによる代償です。 Golang による拡張機能は PHP よりも多少ハードルが高そうですから、エコシステムが育つまでどれくらいかかるかは見守る必要がありそうですね。
なお、 docx ファイルの編集などオフィスファイル系の作業は Collabora Office との連携機能がビルトインされていることもあり、問題なく行えました。純粋なファイル管理主体のユースケースは現状でも満たせそうです。
パフォーマンス 見出しへのリンク
では、いよいよ肝心のパフォーマンスを見ていきましょう。 測定にあたって、サンプルデータは以下の要件が必要そうです:
- ある程度の合計サイズがあること
- 大きいサイズのデータ処理能力を確認したいため
- ファイル数が十分に多いこと
- ファイル数が少ないのであれば差が出にくいため
- ファイルの種別がある程度多いこと
- 特定ファイル種別に依らないことを確認したいため
これを踏まえて悩んだ結果、今回は OSS で公開されている RedRunner16 というUnity製ゲームのプロジェクト一式をフォルダごとアップロードし、これが完了するまでの時間を計測することにしました。 Unityのプロジェクトですから細かいファイルも多いですし、ゲームの性質上マルチメディアを含んでおり、合計サイズは 120MB ほどとそこそこ。また、ファイル・ディレクトリの合計数も 1600 近くあるので、テストとしてちょうど良さそうです。
なお、計測環境は有線接続の Windows 機で実施しました。回線はベストエフォート 1Gbps の光回線で、時間帯も混雑するタイミングを外しているので安定性には懸念ありません。 計測はウォームアップとして RedRunner のリポジトリをまとめた zip ファイルをアップロードし、その完了を見届けた上で、 Nextcloud と OpenCloud へリポジトリのフォルダをアップロードするのをそれぞれ2回ずつ行います。また、計測区間はアップロード開始からブラウザの完了表示までとし、秒数は手元のストップウォッチで計ることにしました。 ……もっと良い方法があるだろとツッコミが来そうですが、早くて確実なのはいつだって堅実なローテクなのです(という言い訳を置いておきます)。
それだけだと流石に負荷面が全くウォッチできないため、CPU負荷のモニタリング用に netdata17 を入れて計測することにしました。なお、メモリの使用率については存外両者間で差が出なかったので、今回は比較結果から除外しています。
Nextcloud 見出しへのリンク
さて、まずは Nextcloud の結果から。
- (1回目) 完了までの所要時間 : 3分04秒16
- (2回目) 完了までの所要時間 : 2分51秒54
大体3分前後で完了していることが分かります。netdata で記録したその区間のCPU使用率グラフが以下です。

アップロード完了までにかかった時間と近似しており、アップロード中に CPU がかなり使われていることが分かりました。やはり多数のファイルを処理するのが負担になっているようです。
OpenCloud 見出しへのリンク
次に、いよいよ OpenCloud の結果を見てみましょう。
- (1回目) 完了までの所要時間 : 0分43秒74
- (2回目) 完了までの所要時間 : 0分46秒25
なんと一分切り! しかも45秒前後で安定しているようです。netdata のグラフも見てみましょう。

Nextcloud よりも遙かに早く CPU が落ち着いていることが分かります。こちらも同様にアップロード時間と近似であることから、多数のファイル処理は重労働であるものの、 Nextcloud よりも効率的に捌いたであろうことが見て取れます。時間の振れ幅も小さいため、安定性も高そうです。これが Golang が故の強さなのでしょうか。
まとめ 見出しへのリンク
Nextcloud および oCIS / OpenCloud の説明と、それぞれについて簡単な外観・パフォーマンスの比較を行いました。
比較を行う前は「意外と差が出なかったらどうしよう」と正直不安になっていたのですが、蓋を開けてみたところ、かなりの差があって驚きました。 特にパフォーマンスに関しては(エッジケースなどを細かく検証していないにせよ) OpenCloud が圧巻で、複雑な操作を加えない個人用途であればそのまま運用できてしまいそうです。 一方、機能面では圧倒的に Nextcloud が優位なのは否めません。本体には存在しない様々な便利機能と、それを取り巻くエコシステムが Nextcloud には充実しています。これは10年近くに渡る Nextcloud の積み重ねの成果であり、 OpenCloud や oCIS が一朝一夕でどうこうできるものではないでしょう。同様のクラスの拡張機能が揃うまでは年月を要するでしょうし、そもそも揃うのかすら分かりません。 したがって、Google Workspaceのような多機能・オールインワンを求めるなら Nextcloud 、シンプル・軽量・高速なオンラインストレージが欲しい場合は OpenCloud / oCIS といった棲み分けはできそうです。
今回の比較はユースケースを網羅できておらず、本番環境含め実際のビジネスでの活用を目指す場合は念入りに様々な条件下でのテストが求められるでしょう。本番環境で運用されてきた Nextcloud に対し、 OpenCloud / oCIS は今後どれくらい採用が広がっていくのか、注目していきたいと思います。
ぜひ、みなさんもご自宅の NAS や自宅サーバ等で試してみてください。
ライセンス 見出しへのリンク
本記事の内容は、特記なき限りCreative Commons Attribution 4.0 International Public License18のもとで自由に利用することができます。ただし、別のライセンスが示されている部分についてはそちらに従ってください(画像中に含まれるアセット・デザインは、各プロジェクト・OSSのライセンスに準拠するものとします)。 なお、本記事は Zenn にて同一の内容19を掲載しています。

これはただの趣味ですが。 ↩︎
https://www.theregister.com/2025/10/13/microsoft_face_grouping_ondrive/ ↩︎
後述しますが、 ownCloud と呼ばれるソフトウェアのフォークが Nextcloud です。 ↩︎
自分が大学生だった頃から大学での採用事例はよく目にしていました。 ↩︎
とはいえ、「ビジネス的には正しいのだ」と言われたら言い返す言葉はありません。OSS とはいえ、収益面での継続性は重要です。 ↩︎
とはいえ共有・権限を考えるとそう単純な話でなく、要件を満たすためのファイル・メタデータの管理方式が複数開発されています。これらは Storage Driver と呼ばれているようです。 ↩︎
https://owncloud.dev/architecture/posixfs-storage-driver/ ↩︎
https://github.com/opencloud-eu/opencloud/releases/tag/v2.0.0 ↩︎
https://zenn.dev/flfymoss/articles/2025-12-21-opencloud-or-nextcloud ↩︎