ガイド

ユースケース:DMARCeyeをAIチャットに接続することで実現できること

全く新しい方法でDMARCデータを管理します。チャットするだけで、アカウントサマリーの取得、送信者/IPの調査、関係者へのメール送信などが可能です。


MCP(Model Context Protocol)は、単なる「連携機能」ではありません。DMARCeyeのデータを、ふだんの言葉で扱えるようにする、まったく新しいインターフェースです。

最初のMCP発表記事では、「DMARCデータをLLMに持ち込み、質問するだけで次のアクションに変える」という大きなコンセプトを中心に紹介しました。本記事ではさらに踏み込み、MCPを有効にしたあとに、実際に何ができるのかを具体的なユースケースで解説します。

最初に確認: “get-” や “list-” って何?

DMARCeyeアプリには、get-account-reportget-domain-source-report のような名前の「対応ツール(tools)」が一覧で表示されます。これは、AIアシスタントがDMARCeyeからデータを取得するために使う “道具” です。

DMARCeye MCP Supported Tools

イメージとしては、これらは安全に定義された、あらかじめ用意されたデータ操作です。

  • “get-” ツール:特定のレポートやデータセットを取得します(例:指定期間のドメインレポート)。
  • “list-” ツール:一覧や概要を返します(例:アクセス可能なドメイン一覧、アラート設定一覧など)。

重要ポイント:これらのツールは裏側で動くものです。 あなたは自然言語で質問するだけで、AIアシスタントが必要なツールを選んで呼び出し、答えを組み立てます。

これが、MCPがDMARCで強力な理由です。「データはあるけど、次に何をすべきか分からない」というギャップを埋めてくれます。レポート画面を行ったり来たりする代わりに、「知りたい結論」を伝えるだけで、アシスタントがDMARCeyeの文脈を引き出して、判断に必要な材料をそろえてくれます。

ユースケース1:アカウント全体の即時サマリー

深掘り調査が必要なときばかりではありません。週次チェック、経営層向けの報告、あるいは「改善している?」「何か変わった?」のような軽い確認には、アカウント全体のスナップショットが最適です。

代表的な使い方は次のとおりです。

  • 全ドメインの状態サマリー(pass/failの傾向、主要送信元、重要な変化)。
  • 優先順位付け:どのドメイン/送信元を先に対応すべきか。
  • 変化検知:先週から何が変わり、それがなぜ重要か。

裏側では、get-account-reportlist-domains-overviewget-report-preview のようなツールで、必要な情報を引き出します。

プロンプト例:

  • 「全ドメインの週次サマリーを作って。先週と比べて何が変わった?」
  • 「今、DMARC失敗ボリュームが最も多いドメインはどれ?」
  • 「ステータス更新用に、現在の状況を6つの箇条書きでまとめて。」

DMARCeye MCP Instant Account Overview

ユースケース2:詳細分析(ドメイン/送信元/IPのドリルダウン)

見慣れない送信元が出てきた、失敗が急増した、なりすましが疑われる。そんなときは、できるだけ早く、でも生データに溺れずに深掘りしたいはずです。MCPが便利なのは、会話しながら調査を誘導できる点にあります。追加質問を重ねていけば、状況がクリアになるまで整理し続けられます。

詳細分析でよくある流れ:

  • ドメインの深掘り:特定期間のpass/fail傾向を、単一ドメインで把握する。
  • 送信元(source)の分析:特定の送信元(ESP、CRM、マーケツール、社内システムなど)を切り出し、何が失敗していて、なぜ起きているかを見る。
  • IPレベルのドリルダウン:失敗の原因となっているIPを特定し、正規/不審の見立てをつける。

こうした調査は通常、get-domain-reportget-domain-source-reportget-domain-ip-report のようなツールで支えられます。

プロンプト例:

  • 「example.comの直近14日間で、失敗している送信元トップをボリュームとリスクで優先順位付けして。」
  • 「この送信元がDKIMのalignmentに失敗している。最も可能性の高い原因と、最初に確認すべきことは?」
  • 「失敗を起こしているIPにドリルダウンして、未承認送信っぽいものを指摘して。」

メリットは速さだけではなく、分かりやすさです。DMARCのシグナルを自分で翻訳して手順に落とすのではなく、「診断」と「次の打ち手」を、DMARCeyeが観測している実データに基づいて引き出せます。

Detailed Analysis

ユースケース3:クイックレポート(複雑なフィルタなしで即答)

いつでもフル調査が必要なわけではありません。「先月はどうだった?」「会議まで5分。きれいな要約がほしい」といった、読み取り専用のスナップショットが欲しい場面も多いはずです。

クイックレポートの典型:

  • エグゼクティブサマリー(技術ノイズを避け、傾向とリスクに絞る)。
  • IT/セキュリティ向けの運用チェック(現状把握を短時間で)。
  • 変更前後の比較(施策によってalignmentが改善したかを検証)。

これは主に get-report-preview で動きます(必要に応じて、アカウント/ドメイン系ツールと組み合わせて文脈を追加できます)。

プロンプト例:

  • 「直近30日間の要約を作って。上位3つのリスクも強調して。」
  • 「チーム用にSlackへ貼れる短いレポートを作成して。」
  • 「今週と先週を比較して、alignmentが改善したか教えて。」

DMARCeye MCP quick reports

ユースケース4:監視とアラート(問題の先回り)

MCPは分析だけのものではありません。アラートやブラックリスト監視に依存している運用では、「何が有効になっているか」「何を追跡しているか」「今の状態はどうか」を会話で確認できるのは大きな助けになります。

監視系のワークフロー例:

  • アラート設定の見直し(重要シグナルがカバーされているか確認)。
  • ブラックリスト状況のチェック(ドメインの評判と配信性を守る)。
  • インシデント初動:何が変わったかを要約し、次に何をすべきか整理する。

裏側では、list-alert-settingslist-report-settingslist-blacklist-overview のようなツールが使われます。

プロンプト例:

  • 「いま有効になっているアラートを一覧にして。重要なものが抜けていない?」
  • 「ブラックリスト状況をチェックして、注意すべき問題を要約して。」
  • 「短いインシデント更新を書いて:何が起きて、何を意味して、次に何をする?」

DMARCeye MCP important alerts

ユースケース5:チーム管理とステークホルダー向けの運用

DMARCは、いつまでも一人で管理し続けるものではありません。ドメインはチーム間で移動し、代理店は複数クライアントを支援し、社内の関係者には「DMARC用語」ではない説明が求められます。

チームとアクセスのワークフロー:

  • アクセスできるチームの把握(どのチームに何があるかを確認)。
  • チームメンバーの一覧(誰が何に対応できるかを明確に)。
  • 非専門家にも伝わる更新文の生成(DMARCの結果を、関係者向けの言葉に変換する)。

これらは主に list-user-teamslist-team-users に対応します。さらに send-user-email というツールもあります。これは、認証されたユーザーのメールアドレスに対して内容を送信できるものです。実運用では「チャットで要約を作る → 自分宛にメールで送って記録/転送する」という、かなり実用的な流れになります。

プロンプト例:

  • 「アクセスできるチーム一覧を出して、各チームのドメインを要約して。」
  • 「このチームのメンバーを表示して、共有用の短い更新文を下書きして。」
  • 「重要指標・リスク・推奨手順を含む週次DMARCステータスメールを作って、私に送って。」

DMARCeye MCP team management

ユースケース6:レポートを生成して(自分宛に)メールで送る

MCPの中でも特に実用的なのが、「DMARCレポートを共有できる更新に変える」ワークフローです。データを書き出して、手で要約を書いて…という作業をせずに、DMARCeyeのレポートをもとに、関係者向けのメール文面を作らせることができます。

たとえば、次のように依頼できます。

  • 「ドメイン dmarceye.com の週次レポートを jack@topol.io に送って。」

DMARCeye MCPは、関連するレポートデータを引き出し、何が変わったのか、何がリスクか(新しい送信元や失敗スパイクなど)をまとめ、推奨する次の手順を明確にしたうえで文章化できます。DMARCダッシュボードを読ませずに、IT・セキュリティ・マーケティングの足並みをそろえたいときに便利です。

なお、DMARCeyeでは安全性のため、メール送信機能は意図的に範囲を絞っています。アシスタントが送れるのは認証されたユーザー自身のメールアドレスのみです。つまり、自分宛に送って記録として残したり、必要に応じて転送したりする用途に向いています。

ベースができたら、あとは改善していけます。たとえば:

  • チームが重視する指標に合わせた、週次の定型サマリーを作る。
  • グラフや週次比較を含むHTML版にアップグレードする。
  • リスクと実施(enforcement)への進捗に絞った、月次の「役員向け」版を作る。

最大のメリットは継続性です。DMARCレポーティングが「面倒な作業」ではなく、シンプルな習慣になります。質問すれば、アシスタントがDMARCeyeのデータを取得し、共有できる要約と次のステップを返してくれます。

DMARCeye MCP send emails

なぜDMARCeyeとMCP Serverなのか?

MCPは、土台となるDMARCデータが「きれいで」「継続的に収集され」「意思決定に使える形で整理されている」ことが前提になります。DMARCeyeが目指しているのはまさにそこです。生の集計レポート(aggregate reports)を、信頼できる可視化に変え、そこから迷いなく行動できるようにします。

DMARCeye MCP Serverは、そのワークフローをAIアシスタントの中に拡張します。ダッシュボードやエクスポートを行き来する代わりに、欲しい結果を伝えれば、アシスタントがDMARCeyeの適切な文脈を引き出して答えを支えます。

  • ドメイン固有の文脈:実際の送信元や認証パターンに基づいた回答。
  • 変化への高速な初動:新規送信元、失敗スパイク、不審トラフィックなどを素早く整理。
  • より安全な実施(enforcement)計画:実データのpass/fail挙動に根ざしたガイダンス。
  • 伝わるコミュニケーション:技術的な所見を、関係者が動ける更新に変換。

次のステップは? DMARCeyeアカウントでMCP Serverを有効化(Account Settings → MCP Server)し、本記事のプロンプト例をいくつか試してみてください。DMARCeyeが初めての方は、フル機能の無料トライアルから始められます。

Similar posts

新しいマーケティングインサイトに関する通知を受け取る

DMARC ポリシー戦略を構築または改善するための新しい情報をいち早く入手しましょう。