「社内文書に対してAIに質問したい。でも、その文書を外部のクラウドAIに丸ごと渡すのは避けたい」——この矛盾を、セルフホストで解こうとするのが Nextcloud AI です。ファイル同期サーバーとして知られる Nextcloud は、いまや Context Chat（自前ドキュメントへのRAG）、ローカルLLM連携、Nextcloud Assistant といったAI機能群を、本体に載せる別アプリとして提供しています。うまく組めば、質問文も対象ドキュメントも自社サーバーの外に一切出さないAIアシスタント基盤を作れます。
この記事は、Nextcloud を「Google Drive の代替」として説明するのではなく、プライバシー重視のセルフホストAI基盤という角度から整理します。中心に据えるのは Context Chat とローカルLLMです。素のファイル同期の一般論は最小限にして、「自分のデータに答えるAIを、外に出さずに動かせるのか」「その実力とコストはどれくらいか」に紙幅を割きます。数値・仕様はすべて公式リポジトリと公式ドキュメントで確認した実測ベースです（2026年7月時点）。
- ・課題→解決：社内文書をクラウドAIに渡したくない → Context Chat＋ローカルLLMで、文書もクエリも自社サーバー内に閉じたRAGアシスタントを組める。
- ・正体：Nextcloud本体（nextcloud/server・⭐約3.6万・AGPL-3.0）に、Assistant・Context Chat・llm2 などのAIアプリを追加する構成。AIは既定では無効で、管理者が有効化して初めて動く。
- ・何ができる：自前ドキュメントへのRAG質問、要約・翻訳・文字起こし・画像生成などのAIタスク、フォルダ単位での対象絞り込み。
- ・何を代替できる：クラウド型の「ドキュメントに聞くAI」（NotebookLM・Copilot・Gemini等）を、データ主権を保ったまま置き換える候補。
- ・正直な注意：AIアプリ群は本体（⭐3.6万）に比べ星数が数十〜数百と若く、ローカルLLMはVRAM 8GB以上が目安。GPUなしでは実用速度・品質が制約される。
RAGそのものの仕組み・ベクトルDB選定・構築手順の全体像は、当サイトのピラー記事 RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップ にまとめています。本記事はそのRAGを「Nextcloud という土台の上で、データを外に出さずに動かす」具体ケースとして読んでください。
Nextcloud AIとは — 本体に「AIアプリ」を載せる構成
まず全体像です。Nextcloud AI は単体の製品ではなく、Nextcloud本体（nextcloud/server）に、機能ごとのAIアプリを追加インストールして組み上げる方式を取ります。ここが最初のつまずきポイントで、「Nextcloud を入れればAIが使える」わけではありません。既定ではAI機能は何も動いておらず、管理者が必要なアプリを有効化して初めて動きます。
nextcloud/server 本体は GitHub スター 約3.6万（36,228・2026年7月21日時点）、ライセンスは AGPL-3.0、主開発言語は PHP で、Nextcloud GmbH が開発をリードしています。日々コミットが続く、セルフホスト系コラボレーション基盤としては最大級のOSSです。その上に載るAIアプリは、おおむね次のように分かれています。
・Nextcloud Assistant（assistant）：AIタスクの統一GUI。要約・見出し生成・自由質問・文字起こし・画像生成などをまとめて呼び出す入口
・Context Chat（context_chat）＋Context Chat Backend（context_chat_backend）：自前ドキュメントへのRAG。app側がUI、backend側（Python）が埋め込み・検索の実処理を担う
・Context Agent（context_agent）：Assistant上でツールを使う、よりエージェント的な対話を狙う新しめのアプリ
・ローカルLLM 2（llm2）：テキスト生成をローカルで動かすためのモデル提供アプリ。ライセンスは本体と異なり MIT
・各種ローカルタスクアプリ：翻訳（translate2）、音声認識（stt_whisper2）、画像生成（text2image_stablediffusion2）、音声合成（text2speech_kokoro）、画像認識（recognize）
・Integration系（integration_openai ほか）：Ollama・vLLM・HuggingFace TGI・LocalAI・OpenAI などの外部/自ホストモデルを接続する橋渡し。「AI as a Service」として OpenAI や IBM watsonx.ai とも繋げる
① 何ができる：自前ドキュメントへのRAG質問と、要約・翻訳・文字起こし等のAIタスクを、1つのGUI（Assistant）から。
② 何を解決する：「社内データを外部AIに渡せない」制約。ローカルモデルを選べば処理が自社サーバー内で閉じる。
③ 何を代替できる：クラウド型の文書質問AI（NotebookLM等）を、データ主権を保った自ホスト版に置き換える。
重要なのは、AI機能の「賢さ」は Nextcloud 側ではなく、裏でつなぐモデル側が決めるという点です。Nextcloud AI はモデルそのものを開発しているわけではなく、Assistant というGUIと、Context Chat というRAGの配管、そしてモデルへの接続層を提供する「基盤」です。だからこそ、どのモデルをどこで動かすか（ローカルか、外部APIか）を選べる自由が、そのままデータ主権の選択になります。
Assistant GUI"] --> Q{"質問の種類"} Q -- "自前文書に聞く" --> CC["Context Chat
（RAG）"] Q -- "要約・翻訳など" --> TASK["各タスクアプリ
translate2 / whisper 等"] CC --> LLM["接続されたLLM
llm2 / Ollama / OpenAI"] TASK --> LLM LLM --> A["回答をAssistantに返す"]
Context Chatの仕組み — 自前ドキュメントをRAGで検索する
この記事の主役が Nextcloud Context Chat（以下 Context Chat）です。やっていることは典型的な RAG（Retrieval-Augmented Generation＝検索拡張生成）で、LLMの回答を「Nextcloud上に保存された、あなた自身のファイル」で裏打ちします。ユーザーは Assistant の Context Chat インターフェースから、インデックス済みのファイル群について自然文で質問できます。「先月の議事録で決まった予算はいくらだった？」のような問いに、実際のファイルを根拠にして答えを返す——それが狙いです。
流れを分解すると、① Context Chat Backend が対象ファイルを読み込み、テキストを分割して埋め込み（ベクトル化）してローカルに索引する → ② 質問が来ると、意味の近い断片を検索して取り出す → ③ 取り出した文脈をプロンプトに添えて接続先のLLMに渡し、根拠つきの回答を生成する、という3段です。ここで効いてくるのが、埋め込みを外部サービスに投げないという設計です。Microsoft Copilot や Google Gemini のような「クラウド側でベクトル化する」構成と違い、Context Chat Backend（Python製）が自ホスト環境で索引を作ります。
・対象の絞り込み：全インデックスに聞くだけでなく、「選択コンテキスト」で特定のファイル・フォルダだけを知識源に指定できる。プロジェクト単位・部門単位で答えを分けたいときに効く
・権限の尊重：Nextcloud のアクセス権に沿って、ユーザーが本来見られるファイルだけが回答の根拠に使われるのが建前。共有と権限がそのままAIの見える範囲になる
・バックエンド分離：context_chat（app）はNextcloud内、context_chat_backend（Python）は外部プロセス/Dockerコンテナとして分離配置できる。公式はGPU搭載マシンでの実行が最良のパフォーマンスとしている
RAGの心臓部である「どう分割し、どう埋め込み、どう検索するか」を自分で全部組むのは骨が折れます。その配管を Nextcloud のファイル権限と統合した形で用意してくれるのが Context Chat の価値です。逆に言えば、RAG基盤を単体で厚く作りたいなら、RAGFlow の使い方 や LightRAGで知識グラフRAGを組む のような専用OSSの方が、チャンク戦略や検索方式の作り込みでは自由度が高い。Nextcloud の強みは「作り込み」より「既存のファイル資産とアクセス権の上に、最短でRAGを載せられる」ことにあります。
ローカルLLMで完結させる — llm2・Ollama連携とデータの流れ
Context Chat が用意した「根拠つきプロンプト」を、最終的に文章にするのが LLM です。ここをどこで動かすかが、Nextcloud AI がセルフホストAI基盤になれるかどうかの分岐点になります。選択肢は大きく3つです。
・llm2（ローカルLLMアプリ）：Nextcloud純正のローカル生成アプリ。追加サービスなしで生成をローカル化できる最短経路。ライセンスは MIT
・Integration経由で自ホストモデルを接続：Ollama・vLLM・HuggingFace TGI・LocalAI などを「LocalAI or OpenAI Integration」アプリでつなぐ。手元のGPUサーバーで動かす大きめのモデルを使いたいときに
・外部API（クラウド）：integration_openai から OpenAI や IBM watsonx.ai へ。手軽で賢いが、データは外部に出る。データ主権を捨てる代わりに品質と運用の軽さを取る選択
ローカル完結のカギは、Context Chat の埋め込みもローカル、生成も llm2 か自ホストOllama にすることです。この組み合わせなら、質問文・対象文書・ベクトル・生成結果のどれも、自社サーバーの外に出ません。冒頭のデータフロー図が示すのは、まさにこの「境界の内側で閉じる」構成です。
公式ドキュメントでは、ローカルLLMアプリ llm2 の目安として VRAM 8GB以上・システムメモリ12GB以上が挙げられているとされます。GPUなし・小型モデルでも動きはしますが、応答速度と回答品質は大きく制約されます。「賢いローカルAIをゼロコストで」は期待しすぎで、ローカル完結はプライバシーとハードウェア投資のトレードオフだと捉えるのが現実的です。
なお、ローカルで動かすモデル自体の選び方・量子化・VRAM要件といった一段深い話は、本記事の範囲を超えます。モデル側の検討をするなら、専用の解説にあたるのが早いでしょう。Context Chat の分割・チャンク設計に関心が向いたら、LangChainで日本語RAGを組む のようなフレームワーク側の記事が、内部で何が起きているかの理解を助けます。
必要スペックとセットアップ手順 — 実行コマンドで確認する
ここでは、実際に手を動かすときの入口となるコマンドを示します。細部はバージョンや環境で変わるため、必ず公式ドキュメントの当該バージョン手順と突き合わせてください。以下は「自分の環境で何を有効化し、どこに何が入っているか」を確認するための最小の足がかりです。
まず、Nextcloud 本体を Docker で起動する最短形（評価用）。本番はデータベース・リバースプロキシを分離した公式の推奨構成に従います。
# 評価用に単体コンテナで起動（本番用途はAIO/compose推奨）
docker run -d --name nextcloud -p 8080:80 nextcloud:latest
# 起動後、管理者ユーザーを作成してブラウザ http://localhost:8080 でログイン
docker logs -f nextcloud # 初期化ログを確認
次に、AIアプリを有効化します。Nextcloud のCLIツール occ で、Context Chat と関連アプリを入れて状態を確認します（www-data はWebサーバーのUID。環境により異なる）。
# occ はNextcloudのCLI。Dockerなら exec 経由で叩く
docker exec -u www-data nextcloud php occ app:enable context_chat
docker exec -u www-data nextcloud php occ app:enable assistant
docker exec -u www-data nextcloud php occ app:enable llm2 # ローカルLLMを使う場合
# 有効化されたAI関連アプリの一覧を確認
docker exec -u www-data nextcloud php occ app:list | grep -Ei "context|assistant|llm|integration"
Context Chat Backend（埋め込み・検索の実処理を担うPythonプロセス）は、GPUマシン上で別途起動し、Nextcloud から接続します。索引付けはバックグラウンドジョブとして走るため、ジョブが回っているかを確認するのが実運用の勘所です。
# バックグラウンドジョブ（cron）が回っているか確認：索引付けはここで進む
docker exec -u www-data nextcloud php occ background-job:list | head
docker exec -u www-data nextcloud php occ background-job:worker -v 'OC\TaskProcessing\SynchronousBackgroundJob'
上のコマンド群は「何を有効化し、索引ジョブが動いているか」を確認するための入口です。Context Chat の初回インデックスは対象ファイル量とハードウェアに強く依存し、GPUなしでは体感が重くなります。セットアップの実質的な難所は、Nextcloud本体ではなく Context Chat Backend のリソース確保とジョブ運用にある、と考えておくと計画が立てやすいはずです。
運用に入ってからの勘所は「索引の鮮度」です。RAGは索引に載っている情報しか答えられないため、ファイルを更新・追加したのに索引が追いついていないと、AIが古い内容を根拠に返してしまいます。Nextcloud ではこの再索引をバックグラウンドジョブが定期的に処理しますが、ジョブが滞っていないか、大量更新の直後に索引が回りきっているかを、上記の background-job:list で確認する癖をつけておくと事故が減ります。加えて、より対話的にツールを使う Context Agent（context_agent） という新しめのアプリも登場していますが、こうしたエージェント寄りの機能ほど発展途上で、まず堅いのは Context Chat による素直な文書RAGだと押さえておくのが安全です。
① 何ができる：`occ app:enable` でAIアプリを足し、`background-job` で索引ジョブの稼働を確認できる。
② 何を解決する：「どこに何が入っているか分からない」不安。CLIで有効アプリとジョブ状態を可視化する。
③ 何を代替できる：手動のRAGパイプライン構築を、Nextcloudのアプリ有効化とジョブ運用に置き換える。
Ethical AI Rating — 「データ主権」を保てるモデルの見分け方
Nextcloud AI に固有の面白い仕組みが Ethical AI Rating です。これは、各AIアプリ/モデルが「どれだけ自分の手の内に置けるか」を4段階の信号色で示すラベルで、モデル選びをデータ主権の観点から一目で判断できるようにしたものです。
判定は3つの基準で行われます。① ソフトウェア（コード）が推論・学習ともにオープンソースか、② 学習済みモデルが自己ホスト用に自由に入手できるか、③ 学習データが公開され自由に使えるか。この3条件をいくつ満たすかで色が決まります。
| 評価 | 満たす条件数 | 意味 | Nextcloudでの含意 |
|---|---|---|---|
| 🟢 Green | 3つすべて | 完全なコントロール | コード・モデル・データすべて手元。データ主権を最大化できる |
| 🟡 Yellow | 2つ | 中程度のコントロール | 一部を外部に依存。多くの自己ホスト構成が該当しやすい |
| 🟠 Orange | 1つ | 限定的なコントロール | 依存度が高い。用途を選んで使う |
| 🔴 Red | 0（該当なし） | コントロールなし・高い依存 | 外部プロバイダー依存。データは外に出る前提 |
・読み方：緑に近いほど「文書もモデルも自分のサーバー内で完結できる」度合いが高い。赤はクラウドAPI依存で、利便性と引き換えにデータ主権を手放す
・使いどころ：機密文書のRAGは緑〜黄のローカル構成、雑多な下書き生成は赤（外部API）でも許容、といったデータの機微度に応じた色の使い分けが現実的
・補足：データセットやモデル表現に大きな偏り（バイアス）が見つかった場合の注記も、評価とは別に添えられるとされる
この格付けは、他のクラウドAIサービスにはあまり見られない Nextcloud らしい設計思想です。「AIを使うかどうか」ではなく「どの色のAIを、どのデータに使うか」を組織で決める材料になります。
クラウド型AIとの比較 — プライバシー軸の使いどころ
では、素直にクラウドのAIを使う場合と比べて、Nextcloud AI はどこで選ばれるのでしょうか。プライバシー・データ主権を軸に整理します。断っておくと、すべての面で優れているわけではありません。賢さや手軽さでは、クラウド大手のマネージドAIに軍配が上がる場面が多いのが正直なところです。
| 観点 | Nextcloud AI（ローカル構成） | クラウド型AI（NotebookLM/Copilot/Gemini等） |
|---|---|---|
| データの置き場所 | 自社サーバー内で完結（外に出さない） | 文書・プロンプトを外部プロバイダーに送信 |
| 自前文書へのRAG | Context Chatで対応（フォルダ単位で絞込可） | サービスにより対応（アップロード前提が多い） |
| モデルの賢さ | 動かせる範囲のローカルモデルに依存 | 最新の大規模モデルを利用しやすい |
| セットアップ | 複数アプリ＋バックエンド＋GPUで手間 | アカウント登録ですぐ使える |
| 運用コスト | ハードウェア・保守は自分持ち | 従量課金・サブスク（データ主権は放棄） |
| ライセンス | AGPL-3.0（llm2はMIT）・自己ホスト自由 | 各社の利用規約に従う |
| 向く用途 | 機密文書・規制業界・データを渡せない組織 | 手軽さ最優先・機微度の低いタスク |
Nextcloud AI が刺さるのは、「AIは使いたいが、この文書だけは外に出せない」という制約が明確な組織です。医療・法務・行政・研究のように、データの持ち出しが規制やポリシーで縛られる現場では、多少の手間とスペック投資を払ってでも自社サーバー内で完結させる価値があります。逆に、機微度の低い雑務や下書き生成でスピードを最優先するなら、クラウド型の方が合理的です。両者は排他ではなく、Ethical AI Rating の色でデータごとに使い分けるのが、いちばん現実的な着地でしょう。
① 何ができる：クラウドに渡せない文書へのRAG質問を、自社サーバー内で。
② 何を解決する：「便利さ」と「データ主権」のどちらかを全捨てする二択を、色で使い分ける形に変える。
③ 何を代替できる：規制・機密の壁でクラウドAIを諦めていた領域のAI活用。
まとめ — Nextcloud AIは「使えるか」正直な現在地
Nextcloud AI は、「自分のデータに答えるAIを、外に出さずに動かす」という要求に、既存のファイル基盤の上で応えようとする構成です。Context Chat が自前ドキュメントをRAGの知識源に変え、llm2 や自ホスト Ollama を組み合わせれば、質問も文書も自社サーバー内で完結します。Ethical AI Rating という「データ主権の物差し」まで用意している点は、他のAIサービスにない独自色です。
一方で、過大評価はしないでおきます。AIアプリ群（context_chat ⭐27、context_chat_backend ⭐22、llm2 ⭐31 など）は、本体（⭐約3.6万）に比べればまだ若く、実戦投入の蓄積も本体ほどではありません。ローカルLLMは VRAM 8GB以上が目安とされ、GPUなしでは実用速度・品質が制約されます。セットアップも複数アプリとバックエンドをまたぐ多段構成で、手軽さではクラウド型に及びません。
参照ソース
・nextcloud/server（公式リポジトリ・README） — スター数・ライセンス（AGPL-3.0）・活動状況の一次情報
・Nextcloud Administration Manual — AI（公式ドキュメント） — 提供AIアプリ一覧・Assistant・Context Chat・llm2 の位置づけ
・Nextcloud Blog — Ethical AI Rating（公式ブログ） — 4段階格付けと3基準の定義
・nextcloud/context_chat_backend（公式リポジトリ） — RAGバックエンド（Python）の実装・配置方法
