NextcloudメールアプリをOAuth2認証で設定する方法

OAuth2は、多くのホスト型メールアカウントをNextcloud Mailに接続するための推奨される方法です。なぜなら、メールプロバイダがトークンを発行するため、Nextcloudがユーザーの通常のメールボックスパスワードを使い続ける必要がないからです。しかし実際には、OAuthの同意ウィンドウが正常に閉じるかどうかで、適切な設定かどうかを判断できるわけではありません。重要なのは、Nextcloud MailがIMAP経由でフォルダを読み込み、SMTP経由でメールを送信し、ユーザーに繰り返し認証を求めることなく認証を更新し、最初のアクセストークンの有効期限が切れた後もこれらの動作を継続できることです。

このガイドでは、Nextcloud Mail が直接文書化している 2 つの OAuth 統合、つまり Google アカウントとホスト型 Microsoft Outlook/Microsoft 365 アカウントについて説明します。2026 年 10 月 6 日現在、Nextcloud App Store では Mail 5.12.3 が Nextcloud 32 ～ 35 の安定版リリースとして掲載されていますが、現在の管理マニュアルには Google OAuth と Microsoft XOAUTH2 の設定が記載されています。古い Mail リリースを使用している場合は、既に変更されている可能性のある動作のトラブルシューティングを行う前に、Nextcloud サーバーがサポートする互換性範囲内でアップデートしてください。

ここで参照されている公式資料には、 Nextcloud Mail 管理マニュアル、Nextcloud Mail App Store ページ、Google のIMAP、POP、SMTP OAuth ドキュメント、および Microsoft のIMAP と SMTP の OAuth ドキュメントが含まれます。

Nextcloud MailのOAuth2設定が成功すれば達成できること

プロバイダ設定を変更する前に、期待する結果を定義してください。正常に動作する構成は、以下のすべてのチェックに合格する必要があります。

• プロバイダは、OAuthクライアント用に設定されたNextcloudのリダイレクトURIにユーザーをリダイレクトします。
• Nextcloud Mailは、通常のメールボックスパスワードを再度要求することなく、メールボックスを開き、フォルダの一覧を表示します。
• 新しいメッセージはIMAP経由で受信され、手動で更新した受信トレイは認証エラーなしで更新されます。
• Nextcloud Mailから送信されたテストメッセージはSMTP経由で受信され、送信済みフォルダに表示されます。
• 有効期限の短いアクセストークンが期限切れになるまで十分な時間が経過すると、アカウントは毎回新規ログインを強制するのではなく、リフレッシュトークンを使用して引き続き動作します。

設定が同意画面のステップのみを通過し、IMAPおよびSMTPテストに合格しない場合は、設定が不完全であるとみなしてください。OAuth認証とメールプロトコルアクセスは関連していますが、別々の段階です。

ステップ1：プロバイダーがサポートされているOAuthパスと一致していることを確認します。

Nextcloud Mailは現在、GoogleアカウントとMicrosoftアカウント向けのOAuth処理機能を内蔵しています。Googleのメールサーバーは、IMAPとSMTPでSASL XOAUTH2によるOAuth 2.0をサポートしています。Microsoftは、Microsoft 365とOutlook.comにおけるIMAP、POP、SMTPのOAuth2サポートについてドキュメントを公開しています。Nextcloudは、メールプロトコルへの認証時に、プロバイダが発行したトークンを使用します。

OpenID ConnectまたはOAuth2に対応したメールサーバーであればどれでも、同じインターフェースに組み込めるとは限りません。汎用的なサードパーティ製OAuth/OpenIDプロバイダーに関するNextcloud Mailの機能強化リクエストは、2026年に提出されましたが、一般的な設定手順として文書化されることなく、機能強化として扱われました。プロバイダーがGoogleまたはMicrosoft以外の場合は、OAuth2を使用した本番環境への展開を行う前に、そのプロバイダーのサポート状況を確認してください。このプロジェクトに関する議論は、Nextcloud Mailの汎用OAuth2機能強化に関する課題で確認できます。

OAuth2を使用してGmailを設定する

ステップ2：NextcloudからGmailのリダイレクトURIをコピーする

Nextcloud管理者としてサインインし、管理設定を開き、「グループウェア」に移動して、「Gmail連携」を探します。Nextcloud管理マニュアルには、このセクションにGoogleクライアントIDとクライアントシークレットを入力するように記載されています。Googleを設定する際は、ご自身のインスタンスに表示されるリダイレクトURIを使用してください。リバースプロキシ、ウェブルートの変更、デプロイメントレイアウトによって外部から見えるURLが影響を受ける可能性があるため、例からパスを再構築しないでください。

品質チェック：リダイレクトURIには、本番環境のHTTPSホスト名を使用し、ユーザーのブラウザからアクセスできる必要があります。ユーザーがパブリックホスト名にアクセスしているにもかかわらず、Nextcloudに内部ホスト名が表示される場合は、まずNextcloud/proxy URLの設定を修正してください。OAuthは、パブリックURLの不一致を補正しません。

ステップ3：Google OAuthクライアントを作成する

Google Cloud で、プロジェクトの Google 認証プラットフォーム/同意設定を構成し、Web アプリケーション用の OAuth クライアントを作成します。Nextcloud からコピーしたリダイレクト URI を承認済みリダイレクト URI として追加します。Google では、認証リクエストのリダイレクト URI が承認済み値と完全に一致する必要があります。スキーム、大文字/小文字、パス、末尾のスラッシュも考慮されます。Google はこの動作について、「Web サーバー アプリケーションでの OAuth 2.0 の使用」で説明しています。

Gmailメールへのアクセスは、コンプライアンスの観点から重要です。Googleは、https://mail.google.com/IMAP、SMTP、POP3の使用を含む広範な範囲を制限付きスコープとして分類しています。アプリが社内用、テスト用、またはより広範な本番環境での使用を想定しているかによって、Googleの検証要件が適用される場合があります。多数のユーザーをオンボーディングする前に、 Googleの制限付きスコープに関するドキュメントとOAuthアプリ検証ガイダンスを確認してください。

ステップ4：GoogleクライアントIDとシークレットをNextcloudに保存する

管理設定 > グループウェア > Gmail 連携に戻り、Google クライアント ID とクライアント シークレットを貼り付けて保存します。スクリーンショット、チケット、シェル履歴、共有メモなどにシークレットを公開しないようにしてください。後で OAuth クライアント シークレットを変更する場合は、Nextcloud を速やかに更新し、既存のアカウントの検証をスケジュールしてください。

ステップ5：Gmailアカウントを追加し、同意を完了する

ユーザーとして Nextcloud Mail を開き、Gmail アカウントを追加します。現在の Mail コードは、標準の Gmail IMAP/SMTP ホストによって Gmail を認識し、管理者が Google OAuth を設定している場合は認証方法を XOAUTH2 に切り替えます。サポートされている SMTP ポートでのimap.gmail.com:993SSL 経由の IMAP およびsmtp.gmail.comTLS に関する Google ドキュメントを参照してください。

Googleへのサインインに進み、同意画面を確認してください。OAuthアプリが使用されているスコープと対象ユーザーに対して設定または検証されていない場合、プロバイダーは警告を表示したり、アクセスを制限したりする場合があります。

「アカウント接続完了」で止まってはいけません。受信トレイを開き、少なくとも1通のメッセージを開き、自分が管理する別のメールボックスにメッセージを送信し、それに返信して、通信の往復を確認してください。このテストは、OAuthリダイレクトだけの場合よりもはるかに多くのことを証明します。

Microsoft 365またはOutlookをOAuth2で構成する

ステップ6：Microsoft Entraにアプリケーションを登録する

Microsoft Entra 管理センターを開き、アプリ登録を作成します。Nextcloud ガイドでは、一般的な例として、組織アカウントと個人アカウントの両方を許可するアカウントタイプを選択し、 Nextcloud からコピーしたWebリダイレクト URI を設定するように管理者に指示しています。組織が意図的にシングルテナントを使用している場合は、マルチテナントの例をそのままコピーせず、サポートするアカウントタイプとテナント設定を ID ポリシーに合わせてください。

Microsoft では、リダイレクト URI をアプリケーションに登録する必要があります。不一致があると、などのエラーが発生する可能性がありますAADSTS50011。Microsoft の現在のガイダンスは、「リダイレクト URI のベスト プラクティスと制限」に記載されています。

ステップ7：クライアントIDを記録し、クライアントシークレットを作成する

アプリケーション（クライアント）IDをコピーします。次に、「証明書とシークレット」を開き、新しいクライアントシークレットを作成して、そのシークレット値をすぐにコピーします。Microsoftによると、ページを離れると値は再度表示されません。また、クライアントシークレットの有効期間は24か月以下に制限されており、現在のアプリ登録に関するドキュメントでは、より短い有効期限を推奨しています。

その有効期限は運用上の依存関係であり、一度限りのインストール時の詳細ではありません。組織の認証情報ローテーションプロセスにシークレットの有効期限を設定してください。そうしないと、一見安定しているように見えるNextcloud Mailのデプロイメントが、トークンの更新が完了できなくなり、後々失敗する可能性があります。

ステップ8：NextcloudにMicrosoftの認証情報を入力します

Nextcloud の管理設定で、グループウェアと Microsoft 統合エリアを開きます。クライアント ID とクライアント シークレットを入力します。公式の Nextcloud ガイドでは、common広範なホスト型 Outlook 構成にテナント値を使用しており、サポートされているアカウントの種類も変更していない限り、カスタム テナント ID はその基本ガイドの範囲外であることを明示的に警告しています。

基盤となるプロトコルのアクセス許可については、Microsoft はhttps://outlook.office.com/IMAP.AccessAsUser.AllIMAP やhttps://outlook.office.com/SMTP.SendSMTP などの委任スコープ、およびoffline_accessリフレッシュトークンが必要な場合についてドキュメントで説明しています。Nextcloud はプロバイダーフローを構築しますが、テナントポリシーと条件付きアクセスルールで要求された委任アクセスが許可されていることを確認する必要があります。

ステップ9：Microsoftアカウントに接続し、メールボックスを確認します。

Nextcloud MailにOutlookまたはMicrosoft 365のアドレスを追加し、Microsoftのサインイン/同意フローを進めてください。Nextcloudの管理マニュアルによると、OAuthが設定されると、アカウント設定時に入力されたパスワードは破棄され、Microsoftの同意が求められるようになります。

繰り返しますが、表示される同意結果はあくまで中間的なシグナルです。フォルダ一覧が読み込まれること、テストメッセージが読めること、メッセージが送信できること、そして送信済みフォルダに期待どおりのコピーが含まれていることを確認してください。

OAuth2が実際に正常かどうかを判断する方法

アプローチを変えるべき時

リダイレクトURI、サポート対象アカウント、テナント設定、または同意設定がデプロイメントと一致しない場合は、OAuthアプリケーション設定を変更してください。構造的な不一致は、繰り返し試行しても修正されません。

Nextcloudが内部、HTTP、またはその他の誤ったパブリックコールバックアドレスを生成した場合は、デプロイメントURL/プロキシ設定を変更してください。まず正規の外部URLを修正し、次にプロバイダのリダイレクトURIを再作成または更新してください。

条件付きアクセス、管理者同意ポリシー、Googleアプリの検証、または制限されたスコープによってユーザーが認証を完了できない場合は、一般的なOAuthの想定ではなく、プロバイダー固有の管理設定を使用してください。これらの制御は、IDプロバイダーによって意図的に適用されています。

別の認証方法を検討するのは、プロバイダーとセキュリティポリシーで明示的に許可されている場合に限ります。たとえば、Nextcloud Mailのインターフェースには、Google OAuthが設定されておらず、Googleアカウントで二段階認証が使用されている場合、Googleアプリパスワードを代替手段として使用できると記載されています。これはOAuth2と同等ではなく、設定が簡単であるという理由だけで、組織全体で推奨される代替手段として扱うべきではありません。

既知の制限事項および2026年のトラブルシューティングに関する注意点

Nextcloud Mail プロジェクトの履歴には、重要な診断上の注意点があります。2026 年 7 月、メンテナーは、プロバイダ側の OAuth エラーが発生しても、「アカウントが接続されました」というリダイレクト ページが認証成功として表示されるバグ報告を確認しました。この報告は Microsoft を直接対象としており、Google でも同様のコントローラー パターンが特定されました。また、2026 年の別の報告では、リフレッシュ トークンが使用できなくなった後にアカウントを再接続するのが困難であるという問題が報告されています。これらの報告は Mail 5.10.7 時代のコードに対して提出されたものです。すべてのバージョンが永久に影響を受けるとは考えないでください。また、リダイレクト ページを成功の唯一の証拠として使用しないでください。

プロジェクトのOAuthリダイレクトエラー処理の問題とOAuth再接続の問題を確認できます。最新リリースでトラブルシューティングを行う場合は、古いブランチ向けに作成された回避策を適用する前に、まずインストールされているMailのバージョンと最新のリリースノートを確認してください。

最終検証チェックリスト

• インストールされているメールアプリのバージョンが、お使いのNextcloudサーバーのバージョンでサポートされていることを確認してください。
• 実際のNextcloudインスタンスに表示されるリダイレクトURIを使用し、それをプロバイダに正確に登録してください。
• Googleの場合、OAuthのオーディエンス、同意設定、制限付きスコープの要件、および本番環境／テスト環境のステータスを確認してください。
• Microsoftの場合、サポートされているアカウントの種類、テナントの選択、クライアントID、クライアントシークレットの有効性、および条件付きアクセスまたは管理者同意ポリシーを確認してください。
• 設定を本格的に展開する前に、まず1つのパイロットアカウントを接続してください。
• 受信トレイの読み込み、メッセージの閲覧、送信、送信済みフォルダへの保存、およびその後のトークン更新をテストします。
• クライアントシークレットの有効期限と所有権を記録しておくことで、認証情報のローテーションが予期せぬシステム停止につながるのを防ぐことができます。

OAuth2はNextcloud Mailの認証モデルを改善しますが、プロバイダーポリシー、リダイレクトURI、アプリケーション認証情報、およびメールプロトコルアクセスを管理する必要性をなくすものではありません。プロバイダー認証、トークン更新、IMAP取得、SMTP送信といった一連のプロセス全体が、ユーザーに適用されるポリシーの下で予測通りに動作する場合、構成は本番環境への導入準備が整ったと言えます。