メールセキュリティシステム開発の進め方/やり方/流れや方法/手法/工程/手順

メールセキュリティシステムの開発は、送信経路と既存契約を確認してから、要件整理、設計、テスト、展開の順に進めます。段階的な導入は、業務への定着につながります。

全体は、要件整理から稼働後の定着までの6フェーズです。費用と見積もりの確認点は、その成果物とつながっています。

▼全体ガイドの記事
・メールセキュリティシステム開発の完全ガイド

メールセキュリティシステムの全体像

メールセキュリティシステムを中心に、受信保護、送信保護、認証、保管、配信後対応の5層を示す図。
防御範囲を受信から配信後まで見渡せます。

メールセキュリティシステムは、迷惑メールを振り分けるだけの仕組みではありません。メール基盤やID管理と連携して、受信から配信後の対応までを扱います。

開発の初めに守る対象を整理しておくと、必要な機能を比べやすくなります。

受信・送信・認証・保管・配信後対応の5層での整理

守る対象は、次の5層に分けて整理できます。

  • 受信保護:受信時に、スパムやマルウェア、フィッシングを検知します。危険なURLや添付ファイルも対象です。
  • 送信保護:宛先確認、一次保留、上長承認のほか、個人情報・機密語句の検査や添付のURL化も含みます。
  • 認証:SPF・DKIM・DMARCにより、自社ドメインのなりすましを抑えます。
  • 保管:監査検索、保存期間、改ざんへの耐性、バックアップを定める領域です。
  • 配信後対応:届いたあとの不審メールの報告、侵害アカウントの停止、送信済みメールの一括回収が対象です。

5層すべてを1つの製品で満たす必要はありません。Microsoft 365の既存ライセンスと外部製品の機能が重なると、費用や管理画面が増える可能性があります。

また、誤送信防止や長期アーカイブを後から付け足すと、メール経路や権限設計のやり直しが生じる場合があります。そこで、MUSTとWANTを分け、不足する層だけを補う考え方が現実的です。

ゲートウェイ型・API型・オンプレミス型の使い分け

方式によって、メール経路や運用の負担は異なります。そのため、既存の基盤と管理体制に合わせて選びます。

  • ゲートウェイ型:既存基盤の前段で検査します。複数基盤を制御しやすい一方で、DNSや許可リスト、送信経路の確認が要ります。
  • API型:Microsoft 365やGoogle Workspaceの受信箱やメール情報をもとに、検知や回収を行います。
  • オンプレミス型:データ配置や独自ポリシーを管理しやすい方式です。サーバーや冗長化、パッチ、監視、バックアップ、災害復旧を、自社か委託先が継続して担います。

API型では、MX変更を小さく始められる場合があります。ただし、必要な権限と、テナント全体への影響、配信後に操作できる範囲を事前に確かめておく必要があります。

特別な承認フローや業務アプリ連携があっても、脅威判定エンジンまでゼロから作る必要はありません。そのうえで、実績ある製品やクラウドAPIを使い、周辺業務だけを個別に開発すると、更新性と安全性を保ちやすくなります。

ポイント

守る範囲を受信から配信後までのどこに置くかを決めると、既存の契約と重なる機能や、足りない機能が見えやすくなります。迷ったときは、MUSTとWANTを分け、不足する層だけを補うかで考えます。

メールセキュリティシステムの進め方

開発・導入は、要件整理から稼働後の定着までを一続きの計画として組みます。利用者が把握していない送信経路も調べます。たとえば、複合機や営業配信、請求システム、採用サービス、委託先などです。

6フェーズは順に進めます。各段階で作るものは、次の判断の材料になります。

フェーズ1:要件整理での守る対象と現状経路の確定

要件整理では、環境、送信経路、業務目的の順に洗い出します。そのうえで、洗い出した情報を要件と成果物に結び付けます。

  • 環境:ユーザー数や拠点数、Microsoft 365・Google Workspace・オンプレミスの別、保有ドメインを一覧にします。
  • 送信経路:受信、通常送信、複合機、業務アプリなどからの流れを洗い出します。
  • 認証担当:SPF・DKIMの対象送信元と担当者の結び付け。
  • 業務要件:「標的型攻撃を減らす」「誤送信を止める」「監査のために7年間検索する」といった目的で書き表します。
  • 優先度:法令・監査・重大事故に直結する項目はMUST、将来の自動化や分析はWANTとして分けます。

環境一覧には、月間の送受信量とメール停止の許容時間も含めます。経路の調査では、メールマガジンや採用・請求サービス、委託先も確認します。

この段階の成果物には、現状構成図、送信元台帳、リスク一覧があります。MUST/WANT表とRTO・RPOも、この段階で整えます。保存期間と責任分界表も文書にします。

要件が曖昧なまま製品を選ぶと、あとから追加費用が生じやすくなります。

フェーズ2:選定での方式・既存ライセンス・運用負荷の比較

検知率の宣伝だけで比べず、方式ごとの作業や責任を確認します。また、既存ライセンスとの機能の重なりも調べます。

  • ゲートウェイ型:配送経路の変更と、停止時の迂回方法を確かめます。
  • API型:必要な権限と、配信後に回収できる範囲です。
  • オンプレミス型:保守と災害復旧を担う担当者を決めます。
  • Microsoft 365:Defender for Office 365のプラン1・2と、既存契約との重複。

Microsoft Defender for Office 365のプラン1には、Safe LinksとSafe Attachmentsが含まれ、リアルタイム脅威検出も備えています。さらに、プラン2では、高度な脅威ハンティングや自動調査・対応などが追加されます。

参照元は、Microsoft Learnの「Microsoft Defender for Office 365 サービス説明書」(2025年10月更新)です。

比較表には、受信保護と送信DLP、アーカイブを入れます。残りは、認証と回収、連携、サポート、ログと契約終了の4つの観点で比べます。

  • 認証と回収:SPF・DKIM・DMARCと、配信後の一括回収。
  • 連携:SSO・MFA、SIEM連携、API。
  • サポート:時間帯を確かめます。
  • ログと契約終了:ログ出力と、契約終了時のデータ返却。

機能の有無だけでなく、誤検知メールの解除時間や、月次運用の工数も確かめます。比較は3年TCOで行い、最低ID数やオプション、初期設定、保守、容量課金も、その計算に含めます。

フェーズ3:設計・開発でのポリシーと連携の具体化

設計では、メールの流れと制御条件を具体化します。

  • 基本設計:入口から検査、隔離、配信、保管、管理者操作までの流れを図にまとめます。
  • 詳細設計:送信ルール、保留、承認、検疫解除権限を定めます。
  • 例外設計:全社一律の制御で業務が止まらないよう、例外の扱いを決めます。
  • 送信認証:全送信サービスを洗い出し、DMARCを監視、隔離、拒否の順に強化します。
  • データ管理:個人データの取り扱いを、設計書と契約の両方で揃えます。

詳細条件は、部署や役職ごとに分けて決めます。外部宛ての保留時間などは、業務の流れに合わせて設定します。例外申請の期限や添付の容量、URLの有効期限も、同じ設計で決めておきます。

想定する利用者は、役員秘書や営業、経理です。複合機や外部配信なども含みます。

個人データを本文・添付・ログに保存する場合は、保存場所、再委託、越境移転、削除方法を設計書と契約に記載します。

SPF・DKIM・DMARCは、DNSの設定を終えた後も見直しが続きます。委託先やSaaSを追加したときも、送信ドメインの設定を確認します。2025年には、日本メールセキュリティ協会のメール送信認証ガイドラインが施行されました。

フェーズ4:テストでの誤検知・遅延・切り戻しの検証

テストでは、脅威の遮断と正規メールの配送を、どちらも確かめます。パイロットの対象と確認条件は、業務に合わせて選びます。

  • 参加者:IT部門に加えて、営業、経理、役員秘書、複合機、外部配信の担当を含みます。
  • 試験条件:添付、パスワード付きファイル、URL、転送、返信、メーリングリストの各場面。
  • 利用環境:スマートフォンや社内メール、海外拠点との通信を、実業務に近い条件で確かめます。
  • 合否基準:遅延、誤検知、検疫解除、検索、保管、権限、迂回の各項目。
  • 切り戻し:MX変更時のTTLと手順を決めておき、DNS反映待ちの時間も確保します。

テスト結果には、事象、原因、対応を記録します。さらに、再発防止と承認者も残します。未解決の例外を本番へ持ち越さないことが重要です。

フェーズ5:稼働での段階展開と初動対応の管理

本番稼働は段階展開し、初期対象で機能と連絡体制を確認してから範囲を広げます。

  1. 部門やドメインごとに分けて展開し、配送や検疫、送信保留、添付URL化、ログ連携を確かめます。
  2. 問題がなければ対象を広げます。切替当日には、各担当の連絡先と判断者を一覧にします。
  3. 停止、遅延、誤検知、外部配信停止の優先順位を共有し、稼働直後は指標を毎日見ます。

切り替え時の担当には、ベンダーやメール管理者、DNS管理者が入ります。ネットワーク担当とヘルプデスクも加わります。

稼働直後は、検疫された正規メールとDMARCレポートを確認します。バウンス、送信量、問い合わせ件数も見ておきます。

想定外の送信元を見つけた場合は、まず所有者と利用目的を調べます。認証状況と停止時の影響も確かめてから、許可リストへの追加を判断します。

重大なフィッシングが起きた場合は、ユーザーからの報告を受けて、アカウント停止、パスワードリセット、送信済みメールの回収、関係部署への連絡を行います。手順書どおりに動けるかも、稼働の合否に含めます。

フェーズ6:定着でのルール・教育・KPIの更新

定着には、月次の数値確認、教育、定期点検が欠かせません。KPIごとに、担当と対応を決めておきます。

  • 月次確認:脅威の種類、誤検知・解除件数、未承認送信元、検疫時間、報告、送信保留の状況を見ます。
  • KPI対応:数値が悪化したときの対応と、KPIごとの責任者。
  • 教育:不審メールの見分け方、報告ボタン、誤送信時の連絡先、共有方法、例外申請期限を利用者に伝えます。
  • 年次点検:異動・退職時の停止、契約更新、製品変更、契約終了時のデータ出力。

KPIの数値が悪化した場合の対応には、ルールを弱める、教育を追加する、送信元を修正するなどがあります。

PPAPを廃止する際は、添付のURL化に加えて、宛先確認やアクセス権、ダウンロードログ、URL無効化、保存期限を業務ルールとして決めます。

ポイント

次のフェーズへ進むかどうかは、今の段階で作ったものが次の判断に使えるかで決めます。要件が曖昧なままなら、製品選びへ進む前に整理し直すほうが手戻りを減らせます。

メールセキュリティシステムの費用相場とコストの内訳

小規模、中規模、大規模の3区分について、本文にある初期導入費の推定レンジを横棒で比較した図。
規模が上がるほど、想定する初期費用の幅も変わります。

費用は、保護範囲やメール経路、保存容量によって大きく変わります。連携数、移行作業、運用支援も、ユーザー数と合わせて費用を左右します。

国内で一律の相場を示す公開情報は少ないため、公開価格と、要件定義から導入までを含む個別導入の推定レンジを分けて見ます。以下は予算を仮置きするための目安で、契約金額を保証するものではありません。

公開価格から見るライセンス費用の目安

HENNGE Oneの公式価格では、3つのプランの月額が200円から800円の幅にあります(出典:HENNGE株式会社「価格とプラン」、2026年8月確認)。

  • Cybersecurity Edition:月額200円からです。
  • DLP Edition:月額350円からです。
  • Ultra Suite:月額800円からです。

100ユーザーで単純計算すると、HENNGE Oneのライセンス部分は年間約24万円から約120万円が目安です。

最低契約ID数やプラン、オプションは、この金額とは別になる可能性があります。初期設定やサポート、税、保存容量も、別に見込む必要があります。そのため、単純計算を見積金額とみなさず、契約条件を確かめることが大切です。

また、NECは2025年5月に、Mission Critical Mail Filter V1.8を500 IDで130万円からと発表しました。

出典は日本電気株式会社の「Mission Critical Mail V1.8販売開始」で、同社の発表資料は2025年5月付です。

これは製品の販売価格で、総額とは限りません。サーバーや冗長化、バックアップ、監視は、販売価格に含まれないことがあります。既存メール基盤との連携や、保守、導入支援も、別に見込む必要があります。

Microsoft 365利用企業は、既存契約に含まれる機能と追加ライセンスを確認してから、外部製品の費用と比べます。

導入・開発費の規模と連携範囲による推定

導入費は、利用者の規模と連携範囲によって異なります。下の推定レンジを、予算を考える起点にします。

  • 小規模:既存クラウドメールに標準設定を追加する場合、50〜200ユーザーで初期50万〜200万円、期間は1〜3か月程度です。
  • 中規模:200〜1,000ユーザーで初期300万〜1,000万円、期間は3〜6か月程度です。
  • 大規模:初期は1,000万〜3,000万円超、期間は6〜12か月程度の場合があります。

小規模導入の想定には、要件整理やDNS変更、検証を含みます。管理者教育と切り替え支援も含めます。アーカイブ移行や複数ドメインがあると、費用は上振れします。

中規模では、送信DLPやアーカイブ、複数ドメインを設計します。SSOやSIEM、例外ルールの設計も含みます。さらに、大規模ではオンプレミスや独自承認、業務アプリ・SOAR連携が費用を押し上げます。

各レンジは、メールセキュリティ固有の公開統計ではなく、ノートの調査に基づく推定です。また、メールエンジンは既製品やクラウドAPIを使い、独自業務だけを開発すると、費用とリスクを抑えられます。

ランニング費用と3年TCOの切り分け

継続費用は、ライセンスに保管、保守、監視などを加えて考えます。100ユーザーの概算は予算の仮置きに使い、その前提は見積書で確かめます。

  • ライセンス:月額200〜1,000円/ユーザーが起点です。
  • 追加運用:アーカイブ、バックアップ、24時間365日監視、SOCを加えます。訓練、保守、問い合わせ対応も含みます。
  • 100ユーザーの概算:ライセンスは年24万〜120万円、運用支援を込みにすると年60万〜300万円です。

運用支援込みの幅は、類似するセキュリティ運用からの推定です。契約ID数と保存容量で変わるため、根拠は見積書に記しておきます。

3年TCOには、初期費用、3年分のライセンス、保守を含めます。さらに、ログやアーカイブの容量、DNSやメール経路の変更、移行を見込みます。教育、定期訓練、監視、障害対応、契約終了時のデータ出力も含めます。

複数製品を組み合わせる場合は、管理者の作業時間や障害時の問い合わせ先、連携の改修費用も加えます。

業務停止や誤送信からの復旧の負担まで見ておくと、選んだ理由を社内で説明しやすくなります。

ポイント

費用は、ライセンスだけでなく、運用支援や3年TCOまで含めて比べると判断しやすくなります。100ユーザーの概算は、見積書の前提を確かめるまでの仮置きとして使います。

メールセキュリティシステムの見積もりを取る際のポイント

RFPの前提、見積項目、追加費用の3点をチェックカードで示す図。
この3点を共通の土台にすると、提案内容を並べて見やすくなります。

見積もりの精度は、依頼側が前提をどれだけ揃えられるかで変わります。対象ユーザーやドメイン、送信経路、保護対象、保存期間を提示します。さらに、既存ライセンスや希望稼働日、運用体制も伝えます。

提案を比べやすくするため、同じRFPを複数社へ渡します。各社には、含む作業と含まない作業を分けて回答してもらいます。

要件と成果物の見積書項目への対応

RFPと見積書を突き合わせると、追加費用や契約条件まで確かめられます。

  • RFPの前提:構成図、ユーザー・ドメイン、送信元、メール量、課題、認証、DLP、保存期間、連携対象、SLA、試験・切り戻し条件を記します。
  • 見積項目:要件定義、基本・詳細設計、設定・開発、DNS・メール経路、移行、テスト、教育、稼働支援、運用設計を分けます。
  • 追加費用:人数・ドメイン増、容量、API、ログ長期保管、休日切替、現地作業、移行、PoC延長、個別画面を確認します。

準委任と請負の範囲や、成果物の受け入れ条件は、契約書で確かめます。仕様変更と検収後の保証期間も、契約書に書かれているかを見ます。

複数社比較での製品・SI・運用の責任分界

比較では、担当者や対応時間、追加料金を揃えて確かめます。PoCには、代表的な送信元を含めます。

  • 責任分界:ベンダーとSIerの担当を分け、DNS、配送障害、誤検知ルールの変更、問い合わせの担当を決めます。
  • インシデント対応:一括回収、ログ調査、監査資料ごとの担当、時間、追加料金。
  • 受付時間:24時間365日か、平日日中かは、業務の重要度で決まります。
  • PoC評価:正規メール、遅延、添付・URL、検疫解除、権限、連携の試験。

PoCでは、管理者権限の分離やレポートの読みやすさを確かめます。API・SIEM連携と、契約終了時のエクスポートも見ておきます。

現場ユーザーにも、誤送信防止を試してもらいます。操作が業務を妨げないかを確かめておくと、導入後の反発や例外ルールの乱立を抑えられます。

見積もりの抜け漏れを防ぐチェックリスト

最終確認では、対象範囲と運用作業、契約終了時の扱いを一通り見ます。

  • 対象範囲:全ユーザー、共有アドレス、複数ドメイン、外部送信サービスを含むか。
  • 重複と設定:既存ライセンス、初期設定、DNS変更、移行、保存容量の確認。
  • 運用と終了:テスト、教育、報告、障害対応、見直し、データ返却の扱い。

初期設定とDNS変更、アーカイブ移行は、見積書で内容を確かめます。保存容量と月次レポートの扱いも、見積書に載っているかを確認します。さらに、現地作業や契約終了時の削除証明も、見積もりに含めてもらいます。

安い提案ほど、対象範囲と運用作業を細かく見ます。ライセンスだけ安くても、誤検知の解除やDMARCレポートの分析、インシデント対応を自社で担うと、人件費が増えます。

一方で、すべてを高機能製品で揃える必要はありません。MUSTを満たし、運用できる複雑さに収まる提案が、長期的な費用対効果につながります。

ポイント

RFPの前提と見積項目を対応させ、契約終了時の扱いまで含めて比べます。安い提案ほど、対象範囲や運用作業の抜けを細かく見ることが目安です。

よくある質問

導入を検討する企業から寄せられやすい質問に、順に答えます。判断は、既存基盤やユーザー体制、費用、運用条件によって変わります。

Microsoft 365やGoogle Workspaceがあれば専用システムは不要ですか?

標準機能で受信保護や認証を満たせる企業もあるため、専用システムが必ずしも必要とは限りません。

送信時の承認や長期アーカイブ、複数基盤の統合が必要な場合は、追加製品や開発を検討します。業務連携、配信後の回収、運用代行を求める場合も、追加製品や開発が候補になります。

まずは既存契約のプランと有効化の状況を確認し、不足する機能だけを補います。

メールセキュリティシステムの導入には何か月かかりますか?

標準設定中心で50〜200ユーザーなら、要件整理から稼働まで1〜3か月程度が推定の起点になります。複数ドメインや既存サーバーがあると、期間は長くなります。

アーカイブ移行や送信DLP、SSO・SIEM連携、独自承認フローが増えると、3〜6か月程度を見込む場合があります。大規模構成では、6〜12か月程度を見込むこともあります。

DNSの洗い出しやパイロットを後回しにすると、期間が延びやすくなります。

SPF・DKIM・DMARCは導入時に何を確認すればよいですか?

自社ドメインから送信する全経路を確認し、正規の送信元台帳に記録します。対象は、営業配信や請求、複合機、業務アプリ、委託先です。

DMARCは監視から始め、レポートで正規の経路を確かめてから、隔離・拒否へ強化します。送信元や委託先が変わったときは、台帳とDNSを更新する担当も決めておきます。

担当を決めておけば、誤配信や正規メールの拒否を防げます。

PPAP廃止とメールセキュリティシステムはどのように関係しますか?

PPAP廃止では、添付ファイルをURLで共有する方式などへ移ります。ただし、URL化しただけで安全になるとは限りません。

宛先確認、アクセス権、ワンタイムURL、ダウンロードログを設計します。そのうえで、期限、誤送信時のURL無効化、アーカイブも設計に入れます。

たとえば、西部ガス情報システムの2025年の導入事例では、送信時の一次保留、添付URL化、誤送信時のワンタイムURL無効化を組み合わせています(出典:同社「メールセキュリティ導入事例」、2025年4月)。

まとめ

導入前の6フェーズの成果物の確認

導入前には、現状構成図、送信元台帳、MUST/WANT表、方式比較が揃っているか確かめます。そのうえで、設計書、テスト計画、切り替え手順、運用手順書も見ておきます。

正規メールが届かない場合の切り戻しと、侵害アカウントから送られたメールの回収手順は、テスト段階で承認を得ておきます。

最初の一歩は送信経路と既存契約の洗い出し

導入を始めるときは、現状を洗い出して不足する機能を見極め、試験導入で構成を確かめます。

  1. ユーザー、ドメイン、送信サービス、既存ライセンス、保存要件、社内の運用担当を一覧にします。
  2. 標準機能で足りる範囲と追加機能を分け、代表部門を含むパイロットへ進みます。
  3. 構成図、送信元台帳、MUST/WANT表、方式比較、設計書、試験・運用手順を揃えます。
  4. 切り戻しと侵害メール回収をテストで承認し、6フェーズで導入・定着させます。

メールセキュリティシステムの開発・導入は、メールを使う業務全体のリスクと運用を組み直すプロジェクトです。受信フィルターを追加する作業とは、規模も中身も大きく異なります。

費用は、公開ライセンス、初期設定・連携、移行、運用支援に分けて、3年TCOで比べます。検知率のほか、誤検知解除や障害復旧も確かめます。さらに、アーカイブ検索、DMARC管理、契約終了時のデータ返却も確認します。

▼全体ガイドの記事
・メールセキュリティシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。