ユースケース：DMARCeyeとAIチャットの連携でできること

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が改善したか教えて。」

ユースケース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が初めての方は、フル機能の無料トライアルから始められます。