ユースケース:DMARCeyeをAIチャットに接続することで実現できること
全く新しい方法でDMARCデータを管理します。チャットするだけで、アカウントサマリーの取得、送信者/IPの調査、関係者へのメール送信などが可能です。
MCP(Model Context Protocol)は、単なる「連携機能」ではありません。DMARCeyeのデータを、ふだんの言葉で扱えるようにする、まったく新しいインターフェースです。
最初のMCP発表記事では、「DMARCデータをLLMに持ち込み、質問するだけで次のアクションに変える」という大きなコンセプトを中心に紹介しました。本記事ではさらに踏み込み、MCPを有効にしたあとに、実際に何ができるのかを具体的なユースケースで解説します。
最初に確認: “get-” や “list-” って何?
DMARCeyeアプリには、get-account-report や get-domain-source-report のような名前の「対応ツール(tools)」が一覧で表示されます。これは、AIアシスタントがDMARCeyeからデータを取得するために使う “道具” です。

イメージとしては、これらは安全に定義された、あらかじめ用意されたデータ操作です。
- “get-” ツール:特定のレポートやデータセットを取得します(例:指定期間のドメインレポート)。
- “list-” ツール:一覧や概要を返します(例:アクセス可能なドメイン一覧、アラート設定一覧など)。
重要ポイント:これらのツールは裏側で動くものです。 あなたは自然言語で質問するだけで、AIアシスタントが必要なツールを選んで呼び出し、答えを組み立てます。
これが、MCPがDMARCで強力な理由です。「データはあるけど、次に何をすべきか分からない」というギャップを埋めてくれます。レポート画面を行ったり来たりする代わりに、「知りたい結論」を伝えるだけで、アシスタントがDMARCeyeの文脈を引き出して、判断に必要な材料をそろえてくれます。
ユースケース1:アカウント全体の即時サマリー
深掘り調査が必要なときばかりではありません。週次チェック、経営層向けの報告、あるいは「改善している?」「何か変わった?」のような軽い確認には、アカウント全体のスナップショットが最適です。
代表的な使い方は次のとおりです。
- 全ドメインの状態サマリー(pass/failの傾向、主要送信元、重要な変化)。
- 優先順位付け:どのドメイン/送信元を先に対応すべきか。
- 変化検知:先週から何が変わり、それがなぜ重要か。
裏側では、get-account-report、list-domains-overview、get-report-preview のようなツールで、必要な情報を引き出します。
プロンプト例:
- 「全ドメインの週次サマリーを作って。先週と比べて何が変わった?」
- 「今、DMARC失敗ボリュームが最も多いドメインはどれ?」
- 「ステータス更新用に、現在の状況を6つの箇条書きでまとめて。」

ユースケース2:詳細分析(ドメイン/送信元/IPのドリルダウン)
見慣れない送信元が出てきた、失敗が急増した、なりすましが疑われる。そんなときは、できるだけ早く、でも生データに溺れずに深掘りしたいはずです。MCPが便利なのは、会話しながら調査を誘導できる点にあります。追加質問を重ねていけば、状況がクリアになるまで整理し続けられます。
詳細分析でよくある流れ:
- ドメインの深掘り:特定期間のpass/fail傾向を、単一ドメインで把握する。
- 送信元(source)の分析:特定の送信元(ESP、CRM、マーケツール、社内システムなど)を切り出し、何が失敗していて、なぜ起きているかを見る。
- IPレベルのドリルダウン:失敗の原因となっているIPを特定し、正規/不審の見立てをつける。
こうした調査は通常、get-domain-report、get-domain-source-report、get-domain-ip-report のようなツールで支えられます。
プロンプト例:
- 「example.comの直近14日間で、失敗している送信元トップをボリュームとリスクで優先順位付けして。」
- 「この送信元がDKIMのalignmentに失敗している。最も可能性の高い原因と、最初に確認すべきことは?」
- 「失敗を起こしているIPにドリルダウンして、未承認送信っぽいものを指摘して。」
メリットは速さだけではなく、分かりやすさです。DMARCのシグナルを自分で翻訳して手順に落とすのではなく、「診断」と「次の打ち手」を、DMARCeyeが観測している実データに基づいて引き出せます。

ユースケース3:クイックレポート(複雑なフィルタなしで即答)
いつでもフル調査が必要なわけではありません。「先月はどうだった?」「会議まで5分。きれいな要約がほしい」といった、読み取り専用のスナップショットが欲しい場面も多いはずです。
クイックレポートの典型:
- エグゼクティブサマリー(技術ノイズを避け、傾向とリスクに絞る)。
- IT/セキュリティ向けの運用チェック(現状把握を短時間で)。
- 変更前後の比較(施策によってalignmentが改善したかを検証)。
これは主に get-report-preview で動きます(必要に応じて、アカウント/ドメイン系ツールと組み合わせて文脈を追加できます)。
プロンプト例:
- 「直近30日間の要約を作って。上位3つのリスクも強調して。」
- 「チーム用にSlackへ貼れる短いレポートを作成して。」
- 「今週と先週を比較して、alignmentが改善したか教えて。」
.png?width=799&height=634&name=Quick%20Reports%20(1).png)
ユースケース4:監視とアラート(問題の先回り)
MCPは分析だけのものではありません。アラートやブラックリスト監視に依存している運用では、「何が有効になっているか」「何を追跡しているか」「今の状態はどうか」を会話で確認できるのは大きな助けになります。
監視系のワークフロー例:
- アラート設定の見直し(重要シグナルがカバーされているか確認)。
- ブラックリスト状況のチェック(ドメインの評判と配信性を守る)。
- インシデント初動:何が変わったかを要約し、次に何をすべきか整理する。
裏側では、list-alert-settings、list-report-settings、list-blacklist-overview のようなツールが使われます。
プロンプト例:
- 「いま有効になっているアラートを一覧にして。重要なものが抜けていない?」
- 「ブラックリスト状況をチェックして、注意すべき問題を要約して。」
- 「短いインシデント更新を書いて:何が起きて、何を意味して、次に何をする?」

ユースケース5:チーム管理とステークホルダー向けの運用
DMARCは、いつまでも一人で管理し続けるものではありません。ドメインはチーム間で移動し、代理店は複数クライアントを支援し、社内の関係者には「DMARC用語」ではない説明が求められます。
チームとアクセスのワークフロー:
- アクセスできるチームの把握(どのチームに何があるかを確認)。
- チームメンバーの一覧(誰が何に対応できるかを明確に)。
- 非専門家にも伝わる更新文の生成(DMARCの結果を、関係者向けの言葉に変換する)。
これらは主に list-user-teams と list-team-users に対応します。さらに send-user-email というツールもあります。これは、認証されたユーザーのメールアドレスに対して内容を送信できるものです。実運用では「チャットで要約を作る → 自分宛にメールで送って記録/転送する」という、かなり実用的な流れになります。
プロンプト例:
- 「アクセスできるチーム一覧を出して、各チームのドメインを要約して。」
- 「このチームのメンバーを表示して、共有用の短い更新文を下書きして。」
- 「重要指標・リスク・推奨手順を含む週次DMARCステータスメールを作って、私に送って。」

ユースケース6:レポートを生成して(自分宛に)メールで送る
MCPの中でも特に実用的なのが、「DMARCレポートを共有できる更新に変える」ワークフローです。データを書き出して、手で要約を書いて…という作業をせずに、DMARCeyeのレポートをもとに、関係者向けのメール文面を作らせることができます。
たとえば、次のように依頼できます。
- 「ドメイン dmarceye.com の週次レポートを jack@topol.io に送って。」
DMARCeye MCPは、関連するレポートデータを引き出し、何が変わったのか、何がリスクか(新しい送信元や失敗スパイクなど)をまとめ、推奨する次の手順を明確にしたうえで文章化できます。DMARCダッシュボードを読ませずに、IT・セキュリティ・マーケティングの足並みをそろえたいときに便利です。
なお、DMARCeyeでは安全性のため、メール送信機能は意図的に範囲を絞っています。アシスタントが送れるのは認証されたユーザー自身のメールアドレスのみです。つまり、自分宛に送って記録として残したり、必要に応じて転送したりする用途に向いています。
ベースができたら、あとは改善していけます。たとえば:
- チームが重視する指標に合わせた、週次の定型サマリーを作る。
- グラフや週次比較を含むHTML版にアップグレードする。
- リスクと実施(enforcement)への進捗に絞った、月次の「役員向け」版を作る。
最大のメリットは継続性です。DMARCレポーティングが「面倒な作業」ではなく、シンプルな習慣になります。質問すれば、アシスタントがDMARCeyeのデータを取得し、共有できる要約と次のステップを返してくれます。

なぜDMARCeyeとMCP Serverなのか?
MCPは、土台となるDMARCデータが「きれいで」「継続的に収集され」「意思決定に使える形で整理されている」ことが前提になります。DMARCeyeが目指しているのはまさにそこです。生の集計レポート(aggregate reports)を、信頼できる可視化に変え、そこから迷いなく行動できるようにします。
DMARCeye MCP Serverは、そのワークフローをAIアシスタントの中に拡張します。ダッシュボードやエクスポートを行き来する代わりに、欲しい結果を伝えれば、アシスタントがDMARCeyeの適切な文脈を引き出して答えを支えます。
- ドメイン固有の文脈:実際の送信元や認証パターンに基づいた回答。
- 変化への高速な初動:新規送信元、失敗スパイク、不審トラフィックなどを素早く整理。
- より安全な実施(enforcement)計画:実データのpass/fail挙動に根ざしたガイダンス。
- 伝わるコミュニケーション:技術的な所見を、関係者が動ける更新に変換。
次のステップは? DMARCeyeアカウントでMCP Serverを有効化(Account Settings → MCP Server)し、本記事のプロンプト例をいくつか試してみてください。DMARCeyeが初めての方は、フル機能の無料トライアルから始められます。