長期化したAI開発に、ようやく区切り。DMARC Monitor MVPが完成【DMARC Monitor開発②】

AIと取り組むDMARC Monitor開発記録｜第2回

前回の記事では、自社ドメインのなりすましメール対策をきっかけに、ChatGPTとClaude Codeを使った「DMARC Monitor」の開発を始めたことをご紹介しました。

当初は比較的シンプルなツールを想定していましたが、安全性や検証を重視するあまり、開発は思いのほか長期化。

そこで、これまでの開発成果をいったん凍結し、本当に必要な機能に絞ったMVP（Minimum Viable Product）として開発を進め直すことにしました。

あれから約2週間。

2026年11月、ようやくMVPの基本機能が完成し、実際のDMARCレポートを分析できるところまで到達しました。

今回は、方針転換から完成までの取り組みをご紹介します。

開発が長期化した理由を、改めて考える

振り返ると、長期化した原因は、AIがプログラムを書けなかったことではありません。

むしろ、必要な機能を追加したり、テストを増やしたりすること自体は、AIの得意分野でした。

問題は、開発を進めるたびに「さらに確認しておいた方がよいこと」が増えていったことです。

監査ログの整合性、データベースの保護、バックアップ、復旧手順、プログラムの変更検知など、どれも大切な要素です。

しかし、それらを際限なく充実させようとすると、肝心の「DMARCレポートを分かりやすく表示する」という目的が後回しになってしまいます。

そこで、基本的な安全対策は残しながら、追加の監査機能や高度な自動化は後回しにすることにしました。

「何が完成すれば、実際に使い始められるのか？」

この基準を明確にしたことが、開発を前に進める転機になりました。

ChatGPTとClaude Codeの役割を明確にする

開発体制も整理しました。

ChatGPTが全体の進行管理、実装方針の検討、レビューを担当します。

Claude Codeは、承認された範囲内でソースコードの修正とテストをまとめて実行します。

実際のDMARCレポートやデータベースを扱う重要な操作は、人間が実行します。

特に効果があったのは、一つひとつの細かな変更を承認するのではなく、必要な機能をまとめて実装する方式に切り替えたことでした。

もちろん、AIが自由に実データを書き換えられるわけではありません。

開発用データと実データを分け、作業範囲を明確にしたうえで、実装とテストを進めています。

AIに任せる部分と、人間が判断する部分を整理することも、AIを使った開発では重要だと感じています。

完成したDMARC Monitor MVP

今回のMVPでは、次の機能を実装しました。

• XML、GZIP、ZIP形式のDMARCレポートの取り込み
• 重複レポートの検出
• SPF、DKIM、DMARCの認証結果の集計
• ドメイン別・送信元IP別の分析
• 既知の送信元と未知の送信元の分類
• HTMLレポートの一括生成
• 取り込み前のdry-runと、バックアップ・変更検知による保護

動作環境には、当社で常時稼働している小型Linuxコンピューター「Odroid」を使用しています。

データベースはSQLiteです。

大規模なクラウド環境を新たに構築するのではなく、手元にある機器を活用して、小さく運用できる仕組みを目指しました。

実際のDMARCレポートを可視化

今回は、当社が管理する2つのドメインについて、実際に受信したDMARC集計レポートを取り込みました。

初期段階で取り込んだ7件のレポートには、合計10通分のメール認証結果が含まれていました。

そのうちDMARC認証に合格したものは6通、不合格は4通です。

取り込んだデータからHTMLレポートを生成し、別のLinuxパソコンのブラウザーでも確認できました。

集計結果だけでなく、送信元IPアドレスや認証の成否を一覧できるようになり、XMLファイルを一つずつ読む必要がなくなりました。

ただし、DMARC認証に失敗したことだけで、なりすましメールと断定できるわけではありません。

外部サービスの設定やメールの転送などが影響することもあります。

大切なのは、これまで見えにくかった情報を確認できるようになったことです。

正規のメール送信元を登録する

もう一つ、今回のMVPで実装したのが「baseline」と呼ぶ既知送信元の登録機能です。

当社ではConoHa WINGのメールサーバーを利用しています。

そこで、DMARCレポートに記録されている送信元IPアドレスを、公開されているSPF設定と照合しました。

確認した送信元IPを登録することで、今後のレポートでは、登録済みの送信元と未知の送信元を区別できるようになります。

未知の送信元が見つかったとしても、それだけで不正な送信と決めつけることはありません。

あくまでも、さらに確認するための手掛かりとして利用します。

現在、baseline設定の読み込みは実データ環境で確認済みです。新しい分類ルールについては、今後のレポート取り込みを通じて引き続き検証していきます。

544件のテストを経て、MVPが完成

開発の最終段階では、544件のユニットテストと12件の回帰テストがすべて成功しました。

実際のデータを使ったHTML生成や、ブラウザーでの表示も確認できています。

もちろん、テストに成功したことが、すべての問題がなくなったことを意味するわけではありません。

メールの自動取得、より詳細なアラート表示、設定ファイルのバックアップ強化など、改善したい部分はまだ残っています。

それでも、必要な基本機能を備え、実データを扱えるMVPとして、一つの区切りをつけることができました。

AIを使った開発で学んだこと

今回の経験で感じたのは、AIによってプログラムを書く作業が効率化されても、開発全体が自動的に効率化されるわけではない、ということです。

機能を追加することは比較的容易になりました。

しかし、追加すべき機能と、今は追加しなくてよい機能を見極めることは、人間に残された重要な仕事です。

安全性を軽視するわけにはいきませんが、完成させなければ実際に使うこともできません。

今回は、そのバランスを考え直す良い経験になりました。

次は実際の運用へ

DMARC Monitor MVPの基本開発は、ここでひとまず完了です。

今後は、過去に受信した未取り込みのDMARCレポートや、新しく届くレポートを順次登録し、自社ドメインのメール認証状況を継続的に確認していく予定です。

実際に運用することで、開発段階では気づかなかった課題や、新しい発見が出てくるかもしれません。

また、現在は手動で行っているレポートの取り込みについても、将来的には自動化を検討したいと考えています。

運用を通じてお伝えできるような成果がまとまれば、改めてこのTech Blogでご紹介したいと思います。

AIを使って何でも作ることよりも、本当に必要なものを完成させ、使い続けること。

今回のDMARC Monitor開発で得た、一番大きな学びかもしれません。

---

※本記事は、ナミキアソシエイツ株式会社によるAI活用・IT技術検証の記録です。DMARC Monitor MVPは自社運用を目的としたシステムであり、商用サービスとして提供しているものではありません。