社内メール基盤をPostfix（メール配送を担うMTAソフトウェア）とDovecot（メール保管・取得を担うIMAP/POPサーバー）で自前運用していて、コンプライアンス対応の壁にぶつかっている方に向けた内容です。金融・医療・法務など規制業種では、メールにDLP（機密情報の外部流出を検知・防止する仕組み）やeDiscovery（訴訟・監査時に該当メールを横断検索する機能）が求められる場面があります。ところがこれらは通常、Microsoft PurviewやGoogle Vaultのようなクラウド商用スイートのライセンス機能として提供され、自前運用のメールサーバーには標準で付いてきません。
この隙間を埋める選択肢として、AGPL-3.0（改変後もソースコード公開義務が生じるオープンソースライセンス）で公開されたwebmailMaquitaというプロジェクトが登場しています。React（フロントエンドのUIライブラリ）とFastAPI（Pythonの高速なAPIフレームワーク）で構築されたウェブメールクライアントで、Postfix/Dovecot環境に対してDLP・eDiscovery・法的ホールド（訴訟に関連する証跡の削除を禁止する保全措置）を後付けする狙いを持っています。導入するかどうかを判断する材料を整理します。
どんな場面で判断が必要になるか
Roundcube（Postfix/Dovecot環境で広く使われるオープンソースのウェブメールクライアント）を使っていて、監査ログや全文検索の機能不足を感じている運用チームは少なくありません。
監査対応や情報漏えい対策として、メール本文からマイナンバーやクレジットカード番号を検知する仕組みが必要になったが、商用DLP製品の1ユーザーあたりライセンス費用が予算に見合わない、というケースもあります。
こうした状況で、追加コンポーネントを導入するか、商用クラウドスイートへの全面移行を検討するか、判断が必要になります。
判断軸
実績スケールと自組織の規模の一致度
webmailMaquitaは約300メールボックス、10万通超のメールという実運用環境でテスト済みと公開されています。
一方で、数千人規模の同時利用環境ではまだ検証されていないと明記されています。自組織のメールボックス数がこの規模に収まるか、まず確認してください。
機能の完成度と未完成部分の許容度
保持ポリシーはインターフェース上で定義できるものの、自動的なパージ・アーカイブ処理はまだ開発中とされています。
また検疫（スパムやマルウェアメールの隔離）は現状、管理者による手動対応が前提です。自動化を前提にした運用フローを組みたい場合は、この未完成部分が業務要件と噛み合うか見極める必要があります。
既存インフラとの統合コスト
Postfix・Dovecot・Rspamd（スパム判定エンジン）という組み合わせをすでに運用しているなら、追加コンポーネントとして載せやすい設計です。
SPF・DKIM・DMARCといった送信ドメイン認証の仕組みや、milter（メール処理にフックする外部プログラム連携の仕組み）を通じたOutlookやモバイルクライアント連携も用意されています。逆にMicrosoft Exchangeなど別方式のメール基盤を使っている場合、統合の前提が崩れるため評価対象から外れます。
ライセンス条件と自社の配布形態
AGPL-3.0は、ネットワーク越しにサービスとして提供する場合でもソースコード開示義務が及ぶ、通常のGPLより強い制約を持つライセンスです。
自社利用に閉じるなら実務上の支障は小さいですが、SaaSとして再配布・提供する計画がある場合は法務確認が必須になります。
選択肢の比較
| 選択肢 | コスト | DLP/eDiscovery成熟度 | 運用負荷 |
|---|---|---|---|
| Roundcube+自作スクリプト | 低（既存資産流用） | 低（都度実装が必要） | 高（保守が属人化しやすい） |
| webmailMaquita | 中（自前ホスティング工数） | 中（一部機能は開発途上） | 中（新規コンポーネント運用が発生） |
| 商用クラウドスイート | 高（ユーザー数課金） | 高（成熟した機能群） | 低（ベンダー管理） |
ケース別の推奨
自組織のメールボックス数が数百規模で、Postfix/Dovecot構成をすでに自前運用しているなら、検証環境への試験導入は検討価値があります。GPG署名とRFC 3161タイムスタンプ（電子データが特定時刻に存在したことを証明する仕組み）によるエクスポート機能は、監査証跡としての体裁を整えやすい点も評価できます。
数千人規模の同時アクセスが見込まれる、またはミッションクリティカルな基幹メール基盤である場合は、実績不足を理由に本番採用を見送り、まずは限定的な部署・拠点でのパイロット運用に留めるのが妥当です。
自動アーカイブ・自動検疫といった無人運用を前提にした設計をすでに求めている組織は、現時点の機能では要件を満たせません。導入時期を数四半期後にずらし、GitHubリポジトリ（wilsongabriel30/webmailMaquita）のIssueやリリースノートで進捗を確認する運用が現実的です。
あえて見送るべき条件
- Exchange Online など Postfix/Dovecot 以外のメール基盤を使っている
- AGPL-3.0のソース開示義務がビジネスモデル上受け入れられない
- 自動保持ポリシーの実行が監査要件として必須で、代替の運用手当てができない
- 社内にDebianサーバーの運用・パッチ適用を継続できる体制がない
- すでに商用DLP/eDiscoveryを導入済みで、切り替えコストが導入メリットを上回る
導入判断のためにすること
メールボックス数・同時アクセス数を棚卸しし、300メールボックス規模のテスト実績と自組織の規模を比較してください。
次に、GitHubリポジトリのREADMEとIssueで、保持ポリシーの自動化や検疫機能の開発状況を最新化して確認します。
最後に、AGPL-3.0のライセンス条件を法務・セキュリティ部門と共有し、自社の利用形態（社内利用のみか外部提供を伴うか）に照らして問題がないか確認したうえで、まずは検証環境での試験導入から始めるのが無理のない進め方です。