CASE STUDIES 導入事例

宮崎氏

JALグループは航空事業を中心に展開しており、グループ路線数は197路線です。国内線が131路線、国際線が66路線で、1日平均約1,000便を運航しています。年間の搭乗者数は約4,300万人、乗り入れ国数は68ヶ国、コードシェア便も含めると395都市に就航しています。連結従業員数は57社で約38,000人という規模です。（2026年2月に取材を行い、2025年3月時点の情報として掲載しています。）

JALグループではデジタル推進の体制を強化するため、2025年4月にJALデジタル株式会社を発足いたしました。従来のシステム会社であったJALインフォテックと日本航空のデジタルテクノロジー本部を一体化し、システムに強い人財と業務知識を持つ人財を融合させることで、JALグループ全体のDXをさらに推進していく体制を整えています。

宮崎氏

私は日本航空のデジタルテクノロジー本部 システムマネジメント部において、社内グループウェアであるGoogle Workspaceのシステムオーナーなどを務めており、Gmailの運用・管理責任を持つ立場から、今回のDMARC対応プロジェクトをプロジェクトオーナーとして牽引することになりました。

田嶋氏

JALデジタルのシステムマネジメント本部で、グループ全体のネットワーク運営を担当しています。通常業務としてDNS管理を受け持っていることから、本プロジェクトにはプロジェクトマネジャーとして参画し、実務全般の指揮を執りました。

石塚氏

田嶋と同じくJALデジタルにおいて、DNS管理やオンプレミスネットワーク、クラウド基盤の運用を担当しています。プロジェクトにはベアメール導入後のタイミングから参画し、主にメインドメインを「reject（拒否）」ポリシーへ引き上げるための具体的な実務・検証作業を担当しました。

宮崎氏

我々にとってメールは、お客さまの旅のプロセスを支える非常に重要なインフラです。
具体的には、航空券の予約確認から、ご搭乗時の運航案内、欠航や遅延のお知らせまで多岐にわたります。搭乗されるお客さまの数に比例して膨大な配信量となりますが、その一通一通を確実に、かつリアルタイムに届けなければなりません。
こうしたお客さま向けメールに加えて、社内においても日常業務のやり取りはもちろん、各種システムからの自動通知メールなどが広範囲かつ大量に配信されています。社内外を問わず、あらゆる業務にメールが深く組み込まれていますね。

田嶋氏

配信数としては、Googleの送信者ガイドラインで基準となっている「1日5,000通」を優に超えています。最近ではワンタイムパスワードなどの認証メールも増えており、万が一これらが届かなくなれば、お客さまのサービス利用や我々の業務そのものに甚大な影響が出てしまいます。

宮崎氏

DMARCの検討自体は2023年から行っていました。当時、クレジットカード業界を中心にDMARC対応の機運が高まっており、JALグループでも決済サービスを担うJALカードのドメインで、先行してポリシーを「reject」まで引き上げたのが発端です。
そして2024年には、GoogleとYahoo!の送信者ガイドラインの改定があり、1日5,000通以上を配信する送信者に対してDMARCによる認証が義務化されたことで、いよいよ全社的に対応しなければならない状況になりました。

宮崎氏

単にガイドラインの最低基準をクリアして終わりにするのではなく、「JALグループとしてサイバーリスクにどう向き合うか」という、より本質的な課題を重視したためです。
DMARCを導入してもポリシーが「none（監視のみ）」の状態では、なりすましを防ぐことはできません。我々はこの状態を、サイバーリスクに対する根本的な解決には至っていない「実質的な未対応状態」であると判断しました。

近年、巧妙なフィッシング詐欺によって弊社のドメインが悪用されるリスクは現実のものとなっています。万が一、お客さまが偽のメールによって被害に遭われれば、我々が長年築いてきたブランドの信頼は根底から崩れてしまいます。
「このサイバーリスクをいかに低減し、安全性を高めていくか」は、情報システム部門の作業レベルの話ではなく、JALグループのブランドを守るための経営課題です。 だからこそ、悪意あるメールを排除できる「reject」への強化こそが、お客さまへの信頼提供を担保するために不可欠なプロセスであると考えました。

田嶋氏

実務面でいうと、将来の要件厳格化への備えという側面が大きいです。現在は各メールサービスのガイドラインにおいてDMARCポリシーについては「none」で許容されていますが、将来的には「quarantine（隔離）」以上が求められるようになる可能性が高いと見ています。その時に慌てるのではなく、今のうちから段階的に引き上げ、高水準なセキュリティを維持しておくべきだと判断しました。

田嶋氏

JALカードについては、JALグループのメインドメインとは切り離された環境であり、利用している送信システムも限定的で全容把握が容易でした。そのため、スムーズに「reject」までポリシーを強化することができたんです。
しかし、グループ全体のドメインとなると、そう簡単にはいきませんでした。管理対象となるドメインが多岐にわたるだけでなく、それぞれのドメインに紐づくシステムも膨大であるため、送信環境を把握できていない状態だったんです。もし、このままDMARCポリシーを引き上げてしまったら、各部署のさまざまなシステムに影響が及び、重要なメールが止まってしまうリスクがありました。

宮崎氏

システムの複雑化に伴い、どのシステムがどのドメインを用いて、どこからメールを送っているのか、その全体像を情報システム部門で把握するのが難しい状況にありました。まずは送信環境の全容を「見える化」しないことには、次の一手が打てない。それが当時の最大の課題だったと言えます。

宮崎氏

最初は、自分たちでDMARCレポートを確認しようと試みました。ところが、届くのは読みづらいXML形式のデータですし、その数は何百という数にのぼります。これらを一つ一つ確認するのは、物理的に人力では不可能だと痛感しました。そこで、DMARCレポートの解析ツールの導入が不可欠であるという判断に至ったわけです。

田嶋氏

GoogleやYahoo!のガイドライン改定が話題になったタイミングで、複数のベンダーさんからご提案をいただきました。中には、非常に多機能な総合製品もありましたが、我々のニーズを照らし合わせると、大きく分けて2つの懸念点が見えてきました。

一つはコスト感です。我々にとって「DMARCレポートの解析」は実態を把握するための手段であり、年間数百万円の予算を投じることは、投資対効果の面から、コストはなるべく抑えたいと考えていました。もう一つ懸念していたのは、「特定の製品への過度な依存」です。多機能なサービスに頼り切った運用を構築してしまうと、自社のシステムがその製品なしでは立ち行かなくなる「ベンダーロックイン」の状態に陥ってしまいます。インフラを預かる身としては、自分たちで主導権を持って運用をコントロールできる状態を維持しておきたかったんです。

そこで、DMARC解析に特化した手軽なツールはないかと探して、見つけたのがベアメールの迷惑メールスコアリングでした。

田嶋氏

まず、SPF・DKIMのアライメント（※）の状況について「どの程度クリアできているか」が可視化され、一目で把握できたのが嬉しかったです。DMARCレポートを直接解読することには限界を感じていたので、現状をデータとして一覧できるようになったことで、ようやく具体的な対策に手が付けられるという実感が持てましたね。

※アライメント：メールの送信者として表示されるドメイン（ヘッダFrom）と、SPFやDKIMで認証されたドメインが「一致」していること。DMARC認証をパスするためには、各認証の成功に加えてアライメントが必須となる。

田嶋氏

当時、我々が求めていたのは統合的なセキュリティソリューションではなく、DMARCレポートの解析に特化したツールでした。
特定の製品の機能に「おんぶにだっこ」になるのではなく、ツールが集計・可視化したデータをベースに自分たちが納得感を持って運用を回すことで、社内にナレッジを蓄積していく。そのためにはベアメールの迷惑メールスコアリングが最適だと考えました。

解析に特化したシンプルなツールを選定したことで、導入もスピード感を持って進めることができました。また、コスト面での工夫により、社内調整に時間を費やすことなく、現場判断で迅速に着手することが可能になりました。

田嶋氏

はい。膨大なZIPファイルを一つひとつ解凍して読み込むという、かつて断念した作業が自動化され、ベアメールのDMARC分析ツールで一元管理できるようになったことで、業務時間は劇的に短縮されたと感じています。DMARC分析機能を活用し、JALグループのメインドメインを無事に「reject」の状態まで持っていくことができました。

田嶋氏

大規模な組織ゆえに、ツールによるエラー送信元のあぶり出しと、現場への地道なヒアリングをセットで回していく必要がありました。運用主体や配信基盤が多岐にわたる中で、ツールで見つけたエラーの正体を突き止めるには、現場への確認が不可欠だったからです。

手順としては、まずベアメールの解析結果から認証失敗している配信元をリストアップし、プラットフォームやIPに関してアタリをつけます。次に、その情報を手に社内へ「このドメインでメールを送っている心当たりはないか」とヒアリングをかけ、利用シーンや具体的なアドレスを特定していきました。

調査で最も根気がいったのは、このツール上のエラーと現場の実態を紐付けるフェーズでした。各担当者に実際のメールヘッダーを出してもらい、解析結果と照らし合わせることで何が設定不足なのかを客観的な事実として確認しました。その上で、担当者やその背後にいるシステムベンダーさんと「こういう設定を追加してください」と具体的な調整を進めていったんです。

このデータによる特定と現場との対話を一つ一つ地道に繰り返したことで、半年ほどで実質的にすべての問題を解消し、DMARC成功率を99%台に引き上げました。

田嶋氏

ポリシーを引き上げるにあたっては、現場と役員の双方が抱える「業務メールが止まってしまうのでは？」という不安に対し、それぞれ異なるアプローチで合意形成を図りました。
まず実務を担う現場に対しては、不測の事態に備えた段階的なステップを示すことで安心感を持ってもらいました。いきなり「reject」にするのではなく、まずは「quarantine」のポリシーで、対象を50%に絞って段階的に引き上げるという2段階のアプローチを提案しました。「隔離ポリシーなら、もし認証に失敗しても迷惑メールフォルダに入るだけで、最初から完全に届かなくなるわけではないですよ」と丁寧に伝えたことで、現場から合意を得られました。

一方で、経営判断をする役員に対しては、不達リスクが実質ゼロであることの証明に注力しました。役員の立場からすると、セキュリティを強化できても、業務に必要なメールまで届かなくなる事態は非常に困る問題です。
ベアメールで出したDMARC成功率を元にグラフを作成し、認証成功率が99%台まで改善できている事実を報告しました。その上で、「100%に達しない残りの送信元は、悪質ななりすましメールであるため、止めるべきメールである」という明確な判断材料を示したんです。それにより役員からもスムーズに承認を得ることができました。

ポリシーの引き上げ後は、「もし必要なメールが隔離されてしまったら、お問い合わせベースで個別に対処する」というセーフティネットを敷いて様子を見ました。しかし蓋を開けてみると、エラー送信元をあぶり出し環境を整備できていたおかげで、現場からの不達の申告はありませんでした。調査と整備を地道に行い、ポリシー引き上げを段階的に行ったことで、大きなトラブルを招くことなく、最終的な目標であった「reject」設定を安定して運用できる状態まで持っていくことができました。

石塚氏

プロジェクトメンバーとの定例会議で、ベアメールの画面を見ながら各ドメインのDMARCの認証状況をチェックしています。グループ全体のポリシーを上げていくにあたって、各社のドメインの状況が直感的にわかるので、「このドメインを優先的に進めよう」といった優先順位の判断がその場ですぐにできる。会議のスピード感が以前とは違いますね。
また、より踏み込んだ分析が必要なときは、CSVデータをダウンロードして活用しています。ベアメールから出力されるデータは扱いやすい形できれいに整理されているので、GASやGeminiなどで加工して使いやすい点も個人的に非常に重宝しています。

田嶋氏

石塚が言うように、必要なデータが手軽に得られるので、上層部への報告資料をまとめる際も本当に助かりました。「説得するための材料」をパッと作成できるだけでも、導入した価値は十分にあったと感じています。
また、エラーパターン分析は「ここはSPF認証に失敗している」といった観点で送信環境が整理されるので、何を優先的に着手すべきか分かりやすく、迷わず調査を進められた点が良かったですね。

田嶋氏

送信元の逆引きドメインが表示される機能は、助かっていますね。送信元のプラットフォームが瞬時に判別できるため、当たりがつけやすかったです。送信元にタグ付けできるので、役員への報告する際はそれを活用してグループ分けし、具体的にどのプラットフォームからの送信かを明確に示すことができました。
また、ARC（※）への対応やブラックリストの判定基準など、不明点についてもサポートから迅速かつ詳細な回答をいただけたのは心強かったですね。

※ARC（Authenticated Received Chain）：メールの転送時にSPFやDKIMの認証が失敗してしまう問題を解決するための仕組み。転送経路の認証情報を引き継ぐことで、正当なメールがDMARCで拒否されるのを防ぐ。

石塚氏

あと、送信元の国を表示してくれる機能も非常に便利ですね。ブラックリストに載っているIPの特定に近い活用法ですが、JALグループのメインドメインのポリシーを引き上げる際にも、明らかになりすましと思われる送信元を判別するのに役立ちました。
具体的には、怪しい送信元を最初から分析対象から除外し、逆に最後の仕上げの段階で、「このサブドメインから10数件ほど怪しいメールが飛んでいるけれど、そちらのシステムで送っているものではないですよね？」と、担当者にピンポイントで事実確認を行うことができたんです。
一つひとつの送信元をしらみつぶしに調べるような手間が省け、確認すべき点だけに集中できました。自信を持って「これは不要なものだ」と判断できたのは、この機能のおかげですね。

石塚氏

サブドメインや送信環境を多数抱えているような企業には特におすすめです。どの環境で何が起きているか切り分けられるだけでも、対応の手間が劇的に減るので、非常に高い費用対効果を実感しています。

田嶋氏

DMARCポリシーを「none」から「quarantine」へ引き上げるハードルは決して低くありません。だからこそ、低コストで手軽に始められ、自分たちで主導権を持って動けるベアメールのようなツールが活きてきます。
製品選定にあたり、多角的な検討を行いましたが、必要な機能が使いやすくパッケージ化されている本ツールは、我々の要求定義に最も合致していました。スピード感を持って対策を講じる必要がある企業にとって、非常に心強いパートナーになると実感しています。

宮崎氏

メールセキュリティの観点では、BIMI（※）の導入が重要な目標です。
金融機関などのように、メールの受信画面にJALのアイコンが表示されるようになれば、お客さまに一目で安心をお届けできます。ブランドの信頼性を守るためにも、そこを一つの到達点として進めていきたいです。

※BIMI（Brand Indicators for Message Identification）：DMARCポリシーを強化（隔離または拒否）できているドメインに対し、受信側のトレイ上で差出人名の横にブランドロゴを表示できる仕組み。

田嶋氏

今回のプロジェクトで浮き彫りになったドメイン管理の課題を解消し、グループ全体に強固なガバナンスを浸透させることが次のミッションです。新しいサービスを立ち上げる際、最初から「reject」で運用できるような、高水準なセキュリティを当たり前のスタンダードにしていきたいと考えています。

石塚氏

私は実務の観点から、今回のプロジェクトで得たDMARCやDKIM、SPFに関するナレッジをグループ全体で共有していきたいと考えています。今後新しいドメインを導入する際にも、迷うことなくスムーズに対応が進められるような体制をしっかり整えていきたいですね。