LASSIC Media らしくメディア
Nextcloudで社内ファイル基盤を外注構築
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Nextcloudはオープンソースのファイル共有・コラボレーション基盤で、自社サーバーやプライベートクラウド上にセルフホストできます。
- Google DriveやDropboxなどのクラウドストレージSaaSと異なり、データの保管場所とアクセス権限を自社で管理できる点が特徴です。
- 認証連携・バックアップ・アップグレードなど運用面の設計が要となるため、外注と内製のどちらが適するかを見極める視点を紹介します。
目次
Nextcloudセルフホストの基本と自社運用の意味
Nextcloudとは、ファイルの同期・共有・コラボレーション機能をオープンソースで提供し、自社のサーバーやプライベートクラウド上にセルフホスト（自前運用）できるソフトウェア基盤を指します*1。Linux環境にインストールするほか、Web installerやDockerイメージでの導入にも対応しています*2。
セルフホストという運用形態を選ぶ理由は、データの保管場所とアクセス権限を自社側で決められる点にあります。Nextcloud GmbH（開発元企業）は利用者のデータに一切アクセスできない設計になっており、データ処理者との契約が不要になるとしています*3。公的機関や自治体でもセルフホスト型プライベートクラウドとして採用例が広がっている領域です*3。
構築の流れは要件整理からサーバー構築、認証連携、外部サービスとの連携設定を経て運用開始に至ります。この一連の設計判断が、SaaS型のクラウドストレージを契約する場合と最も異なる部分です。
SaaS型ストレージとセルフホストの違い
Google DriveやDropbox、BoxといったクラウドストレージSaaSは、契約するだけで即座に利用開始できる利点があります。一方でデータの保管先やアクセス制御の詳細はサービス提供者の仕様に依存し、利用容量に応じた課金が積み上がっていく仕組みです。
セルフホストのNextcloudでは、データを自社が管理するサーバーやプライベートクラウド環境に置くため、保管場所を自社の判断で決められます。容量が増えても追加のライセンス費用ではなく、ストレージ機器の増強という形でコストが発生する点も異なります。
| 比較軸 | SaaS型クラウドストレージ | Nextcloudセルフホスト |
|---|---|---|
| データの保管先 | サービス提供者のデータセンター（契約プランに依存） | 自社サーバー・プライベートクラウド（自社で選定） |
| 課金モデル | ユーザー数・容量に応じた月額課金 | サーバー・ストレージ機器の調達費と運用費 |
| 認証連携 | 提供者側の対応範囲に限定される | LDAP/Active Directory・SAML等を自社方針で構成*4 |
| 導入スピード | 契約後すぐに利用開始できる | サーバー構築・設定の工程が必要 |
| 運用の責任範囲 | 可用性・バックアップは提供者側が担う | アップグレード・バックアップ・監視を自社（または外注先）が担う*5 |
ファイル同期・共有・権限管理の仕組み
Nextcloudの中核機能はファイル共有と管理にあり、共有設定や有効期限の管理、複数のNextcloudサーバー間でファイルをやり取りするフェデレーション共有に対応しています*2。デスクトップやモバイルのクライアントを介して、ローカル環境とサーバー間でファイルを同期する仕組みも用意されています*1。
大容量ファイルのアップロード設定やオブジェクトストレージのプライマリストレージ化、外部ストレージとの統合、サーバー側暗号化（マスターキー方式やユーザーキー方式など複数モード）も管理者側で構成可能です*2。ファイルロック機能によって複数人が同時編集した際の不整合も防ぎます*2。
権限設計を誤ると、社外に公開すべきでないファイルが共有リンク経由で漏れるリスクがあります。共有の有効期限設定やパスワード保護、グループ単位でのアクセス制御を、自社のセキュリティ方針に沿って初期段階で設計することが欠かせません。
オフィス文書編集・カレンダーなど外部連携
Nextcloud Officeは、CollaboraやOnlyOfficeをWOPI（Web Application Open Platform Interface。文書編集用の連携プロトコル）クライアントとして連携させ、ブラウザ上での文書編集を可能にする機能です*6。WOPIリクエストを許可するIPアドレスを制限したり、編集可能なグループをアプリ側の設定で絞り込んだりできます*6。新規作成時のファイル形式はOpenDocument Format（ODF）が既定ですが、Office Open XML（OOXML）形式に切り替える設定も用意されています*6。
カレンダー機能はCalDAV（カレンダー同期の標準プロトコル）のバックエンドで動作し、ThunderbirdなどのオフラインクライアントとNextcloud側の変更を差分同期します*7。会議室やリソースの予約機能も備え、同一時間帯の重複予約を防ぐ仕組みが組み込まれています*7。連絡先についても同様にCardDAV（アドレス帳同期の標準プロトコル）で管理し、全利用者が参照できるシステムアドレス帳を有効化できます*8。
認証基盤との連携（LDAP・SSO）
Nextcloudとは、社内で既に運用しているID管理基盤と接続して使う設計を前提にしたシステムでもあります。LDAP/Active Directory連携では、管理画面からサーバーのIPアドレスやポート、User DN（ディレクトリ内のユーザー識別情報）を設定して既存のユーザー情報と同期します*4。
SSO（シングルサインオン）とSAML認証は標準搭載されているものの初期状態では無効になっているアプリで有効化し、SAML 2.0やShibboleth、Active Directory Federation Services（ADFS）など複数のプロバイダー方式に対応しています*4。SSOを有効化すると通常のログイン画面からのアクセスができなくなるため、緊急時に備えて管理者アカウント用のバイパス手順を事前に確認しておく必要があります*4。
認証基盤の接続には、LDAPサーバーの構成情報やSAMLプロバイダーとの鍵交換など、ネットワークとディレクトリサービス双方の知識が求められます。設定を誤ると全社員がログインできなくなる事態にもつながるため、テスト環境での事前検証が重要な工程です。
構築後の運用課題（アップグレード・バックアップ・可用性）
Nextcloudのアップグレードは、サーバーをメンテナンスモードにして利用者をログアウトさせた状態で実施します*9。組み込みのアップデーター（Web版・コマンドライン版）を使う方法と、アーカイブファイルを手動で入れ替える方法が用意されており、いずれの場合もアップグレード前の最新バックアップ取得が前提です*9。
バックアップの対象はconfig・data・theme・カスタムアプリの各フォルダとデータベースの5点です*5。手順としてはメンテナンスモードを有効にしてデータの一貫性を確保し、rsync等でフォルダを外部ロケーションへ複製、使用しているデータベース（MariaDB・MySQL・SQLite・PostgreSQL）に応じたダンプコマンドを実行してから、メンテナンスモードを解除します*5。
利用規模が拡大し複数のアプリケーションサーバーで負荷分散する場合は、HAProxyやnginxなどのリバースプロキシでロードバランサー層を構成し、データベースもGaleraクラスタ等で冗長化する設計が必要になります*10。ファイルロック処理をデータベースクラスタから分離するためにRedisを外部キャッシュとして導入する構成も紹介されています*10。管理画面からの設定変更が単一ノードのconfig.phpにしか反映されない点も、複数サーバー構成では注意が必要な仕様です*10。
外注と内製の判断軸
Nextcloudのセルフホスト構築では、認証基盤との連携設計、バックアップ・アップグレード運用、将来的な可用性確保まで一連の工程を見通した設計が求められます。内製で対応するには、Linuxサーバー運用・データベース管理・ディレクトリサービス連携・Webサーバー設定という複数領域の知識を持つ人員を確保する必要があります。
対応を誤った場合の影響も無視できません。アップグレード時にバックアップを取らずに手順を誤ると、データ復旧に長時間を要する可能性があります*9。認証連携の設定ミスは全社的なログイン不能に直結し、業務停止のリスクに発展します。
外部パートナーに構築・運用を依頼する場合は、既存の認証基盤やファイルサーバーの構成を踏まえた移行計画の設計、および運用フェーズでの監視・アップグレード対応まで一括して任せられる点が内製との違いです。自社で対応する場合は、初期構築だけでなく運用フェーズの体制も含めて工数を見積もっておくことが判断の前提になります。
まとめ：Nextcloud構築で押さえる3つの判断軸
本稿では、Nextcloudをセルフホストでファイル基盤として構築する際の要点を整理しました。要点は3つに集約できます。第一に、SaaS型クラウドストレージとの違いはデータの保管場所と課金モデルにあり、自社でアクセス権限を管理できる点が特徴です。第二に、ファイル共有・権限管理・オフィス文書編集・カレンダー連携といった機能面の設計が利用者の使いやすさを左右します。第三に、認証連携とバックアップ・アップグレード・可用性確保という運用面の設計が、構築後の安定運用を決める分かれ道になります。
よくある質問
Nextcloudの導入形態にはどのような選択肢がありますか。
自社のLinuxサーバーへのインストールに加え、共有Webホスティング向けのWeb installer、事前構築済みのクラウド・仮想マシンイメージ、Dockerでの導入など複数の方法が用意されています*2。自社のインフラ方針に合わせて選べます。
既存のActive Directoryのユーザー情報はそのまま使えますか。
LDAP/AD連携機能を使い、管理画面からサーバーのIPアドレスやポート、User DNなどを設定することで、既存のディレクトリ情報と同期できます*4。新たにユーザーを二重管理する必要はありません。
Officeファイルの編集にはどのような仕組みが必要ですか。
Nextcloud OfficeはCollaboraやOnlyOfficeをWOPIクライアントとして連携させることでブラウザ上での編集を実現します*6。連携先のサーバーを別途用意し、Nextcloud側の管理設定でIPアドレス制限や編集権限を構成します。
バックアップはどの範囲まで取得すればよいですか。
config・data・theme・カスタムアプリの各フォルダとデータベースの5点が対象です*5。メンテナンスモードを有効にしてから複製し、データベースは種類に応じたダンプコマンドで取得します。
利用者数が増えた場合、サーバーを増強すれば対応できますか。
単一サーバーの増強に加え、複数のアプリケーションサーバーをロードバランサーで束ね、データベースをクラスタ構成にする構成が可能です*10。ただし管理画面からの設定変更が単一ノードにしか反映されない仕様もあるため、複数台構成では構成管理の設計を事前に固めておくことが望ましいです*10。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Nextcloud「Nextcloud Files – Open source file sync and share platform」
- *2 出典：Nextcloud「File sharing and management — Nextcloud Administration Manual」
- *3 出典：Nextcloud「Nextcloud compliance」
- *4 出典：Nextcloud「SSO & SAML authentication – Apps – App Store」
- *5 出典：Nextcloud「Backup — Nextcloud Administration Manual」
- *6 出典：Nextcloud「Configuration（Nextcloud Office） — Nextcloud Administration Manual」
- *7 出典：Nextcloud「Calendar / CalDAV — Nextcloud Administration Manual」
- *8 出典：Nextcloud「Contacts / CardDAV — Nextcloud Administration Manual」
- *9 出典：Nextcloud「How to upgrade — Nextcloud Administration Manual」
- *10 出典：Nextcloud「Scaling Across Multiple Machines — Nextcloud Server Administration Manual」
