はじめに セキュリティ推進室の山田です。 MNTSQはエンタープライズ企業を主な顧客としています。 契約という、顧客企業の事業戦略に直結するような情報を取り扱う性質上、さまざまな観点からセキュリティをしっかりと担保する必要があり、DMARCへの対応もそうした取り組みのひとつです。 DMARCはなりすましメール対策の仕組みであり、実質的な効果を持たせるにはポリシーをp=quarantineまたはp=rejectに設定する必要があります。 しかしMNTSQでは、DMARCレコード自体は存在していたものの、ポリシーはp=noneの状態が続いていました。本記事ではDMARCポリシーをp=rejectまで厳格化した取り組みについて紹介します。 DMARCとは DMARCはSPF・DKIMの認証結果を照合し、ポリシーに従ってメールを処理する仕組みです。認証に失敗した場合、設定されたポリシーの値に応じて処理されます。 DMARCポリシーの設定値は3つあります。 Step0: 現状の整理と取り組みの方針の決定 現状を整理した結果、次のようなステップで取り組む必要が出てきました。 自社ドメインからのメール送信元の確認 → Step1: DMARCレポートの分析 SPF・DKIMなどDNSレコード設定の適切性の確認 → Step2: DNSレコードの棚卸し メール送信元の管理方式の策定 → Step3: 未対応サービスの洗い出しと対応 DMARCレコードの管理者の策定 → Step4: DMARCポリシーの厳格化 Step1: DMARCレポートの分析 DMARCレポートとは、メールを受信したサーバーが送信ドメインの管理者に送る集計レポートです。どのIPアドレスから自社ドメインを名乗ったメールが送られているかを把握できます。 MNTSQではすでにValimailがレポートの送信先として設定されていたため、まずはValimailを使って送信元の洗い出しを試みました。Google Workspaceなど日頃から利用しているSaaSがレポートとして上がっていた一方で、Valimailだけでは不十分だとわかりました。数日ほど集計レポートを眺めていると、利用しているにもかかわらずレポートに現れないサービスがあることに気づきました。レポートがサマライズされており全容が把握しきれていなかったことが原因でした。またSendGridのようにCNAMEで委譲された独自サブドメイン（例：sg-123.example.com）からの送信がValimailで拾えていなかったことも、この時点では把握しきれていませんでした。 そこでDMARCレポートを分析するツールを自作しました。GASのコードはClaudeを活用して作成しており、ツール自体は1日ほどで動くものができました。その後、表示内容や確認したい情報が適切に出力されているかを1〜2日かけて調整し、実用的な状態に仕上げました。生成AIを活用することで実装より設計に集中できるため、ツールを自作するという意思決定のハードルが下がった実例でもあります。 GASは機能ごとに分割し、機能の橋渡しとなるようデータの構造を設計している 作成したツールの仕組みは以下の通りです。 各受信サーバーからメール添付で届くDMARCレポート（XML）をGASで収集し、Google Driveに格納 XMLをクレンジングし、表示に必要な情報だけをスプレッドシートに中間データとして展開 DMARCレポートは1日あたり数個から十数個になる BIツール側でXMLを直接読み込むと処理速度に影響するので中間データを生成する 中間データをもとにGASでBIツールを構築 中間データを挟むことで低レイテンシーでの表示を実現している これによりValimailでは把握できていなかった送信元を含めたDMARCレポートの全容が把握できるようになり、次のステップであるDNSレコードの棚卸しに必要なサービス一覧が作成できました。 スクショはサマリーだけですが、トグルを開くと詳細レポートもみれます Step2: DNSレコードの棚卸し Step1のDMARCレポート分析で得たサービス一覧をもとに、SPFおよびDKIMのレコードが正しく設定されているかを確認していきました。ヒアリングから入ると曖昧な情報に引っ張られるリスクがあるため、まずDMARCレポートというファクトをベースに実態を整理してから従業員に確認する、という順序を意識しました。 MNTSQではDNSレコードはTerraformで管理されており、変更はPRを作成してSREチームにレビュー・デプロイを依頼する運用になっています。Terraformで管理されているとDNSレコードをコードとして確認しながら棚卸しを進められる点は、作業を進める上で都合が良かったです。Terraformの構成ファイルを読み進めていくとStep1の時点で把握できていなかったCNAMEサブドメインの実態がようやく明らかになったのもこのときでした。 Terraformのファイルを読み進めながら、各サービスのDKIMレコードが正しく定義されているかを一件ずつ確認していきました。以下はDKIMレコードの一例です。DKIMの公開鍵は長く、Route 53のTXTレコードは1件あたり255文字の制限があるため、format()を使って文字列を分割して定義しています。この分割が正しく行われていないとレコードが有効にならず、DKIM認証が通らない状態になります。このコードは修正後のものですが、それまでは正しく分割されておらず、レコードが無効な状態になっていました。 resource "aws_route53_record" "txt__gws_dkim" { zone_id = local.zone_id name = "google._domainkey" type = "TXT" ttl = local.ttl records = [ format ( "%s\" \"%s" , "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmBKdjgohxRFnbL8pb0BTNajVMYNAFRHwUT7WgiKmxxsvr/H5dSIcq+1xTaKTYRA5f29yUG6K2D5UJ7MHaUr2q1F3YOX6XCbX6J1MBB0JTyfDINBXxwspf8xxx6W5I/J0nAaf4SS3LEHSSTymFRiPN27sTTI13vplwgjQ07n0JRrCg62KQTxNmV" , "ekhPuLwTZM4fqKYzZVcoP1ezQOqIlRdd80pnRvSsX1bmGmofJXBxaNlRnHA9x4z8yPN09v18jT8yJRFgXw44uyMcE9+4a9l4AOHik2Z3z/yHpxjEZY47G+tXXefRlKWb0V6dDfywB/bMtkMY4O0ICH2+a0TvBbTQIDAQAB" , ) ] } こうして机上で把握できる範囲の実態を整理しきった段階で次のステップとして全社へのヒアリングに移りました。 Step3: 未対応サービスの洗い出しと対応 DMARCレポートとDNSレコードの棚卸しによってメール送信サービスの実態はある程度整理できましたが、机上の調査には限界があります。例えばDMARCレポートの収集期間外にメールを送信していたサービスは、この時点では拾えていないケースとして残り得ます。そこで全社員を対象にヒアリングを実施しました。 ヒアリングの結果、リストに載っていないサービスがいくつか出てきました。内容を確認すると、メール送信サービス経由で送信しているため実態としては問題ないケース、FromにはSaaS側のメールアドレスが使われReply-Toに会社ドメインが設定されているだけで自社ドメインからの送信ではないケースなど、対応不要と判断できるものが多くありました。一方で、社員自身では判断がつかないとして連絡をもらったものもあり、そういった情報も含めて整理を進めることができました。 全社へのヒアリングは手間がかかるように思えましたが、机上の調査だけでは拾いきれない情報を補完できた点で有効でした。 Step4: ポリシーの厳格化 DMARCレポートの分析、DNSレコードの棚卸し、全社へのヒアリングと多角的に対応を進めた結果、自社ドメインからメールを送信しているサービスの全体像が把握できました。送信元のサービスごとにSPFおよびDKIMの設定が適切に行われていることを確認し、DMARCポリシーを引き上げる準備が整いました。 ポリシーの設定にあたっては、p=quarantineを経由せずp=rejectに直接移行することにしました。ここまでの調査と対応を通じてメールの送信状態はひと通り整理できており、段階を踏むよりも一気に厳格化した方が運用上もシンプルだという判断からです。 ポリシーをp=rejectに移行した後は、継続的な運用体制の整備に着手しました。今回の取り組みを通じて対応状況や設定内容はNotionにドキュメントとして整備しました。DMARCはメールを送信するサービスが追加・変更されるたびに設定の見直しが必要になりますが、運用の標準化という観点では担当者が複数つけられる規模になっていないと難しい面もあり、現時点では筆者が責任を持って管理する体制としています。 まとめ 今回の取り組みを通じて得られた知見を整理します。 DMARCポリシーの厳格化は、設定よりも実態の把握が本質的な難しさ DMARCレコード自体は存在していても、送信元サービスの全体像が把握できていなければポリシーの引き上げはできません。レコードを書き換えること自体は簡単ですが、そこに至るまでの調査と整備に大半の時間がかかりました。 自作の分析ツールが調査の精度を上げた Valimailでは拾えていなかったCNAMEサブドメイン経由の送信元を含め、DMARCレポートの全容を把握できるようになりました。ツールを自作して可視化したことで、調査の抜け漏れを防ぐことができました。 全社ヒアリングで調査の精度を上げた 机上の調査だけでは拾いきれないケースを補完するために全社ヒアリングを実施しました。社員が自発的に判断のつかない情報を連絡してくれたことで、調査の精度が上がりました。エンジニアだけで抱え込まず、早めに全社へ展開することが有効だと感じました。 送信状態が整理できたらp=rejectまで一気に引き上げる p=quarantineは段階的な移行のための中間設定として有効ですが、今回はStep1～Step3を通じて送信元の全体像を把握した上でポリシーを引き上げたため、p=quarantineを経由せずp=rejectに直接移行しました。送信状態の整理が完了していれば、段階を踏まずに一気に厳格化することで運用上シンプルにすることができました。 おわりに DMARCポリシーの厳格化は一度対応すれば終わりではなく、新しいサービスの導入や設定変更のたびに送信元の管理が必要になります。今回の取り組みで整備した分析基盤を活用しながら、継続的に運用していく予定です。 また、TerraformのDNSレコード変更にあたり、PRのレビューとデプロイを何度もSREチームに依頼しましたが、快く対応いただきました。この場を借りて感謝を伝えたいと思います。同様の課題を抱える組織の参考になれば幸いです。

こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中 里絵 です。 私は日本全国・業種・業態を問わず様々なお客様を支援する広域事業統括本部の中の、首都圏以外のお客様を支援するチームに所属しています。私たちは 2026 年 4 月〜5 月にかけて、大阪・名古屋・広島・博多・札幌の 5 都市・計 8 回にわたり、「 AWS Local Executive Roadshow 」と題した生成 AI 活用をテーマとしたイベントを開催しました。AI を自社の業務に活かしたい企業の経営層・情報システム部門の皆様と、AI で顧客を支援する IT 企業の皆様、それぞれにお集まりいただき、各地域の登壇企業の実体験を起点に、参加者同士で生成 AI 活用の次の一歩を考える場として企画したシリーズです。本ブログシリーズでは、各拠点の開催レポートを、順にお届けしていきます。 初回となる本ブログでは、2026 年 4 月 13 日に大阪支社にて開催したイベント「 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 」の様子をレポートします。AI を自社の業務に活かしたい企業のエグゼクティブ・情報システム部門の皆様をお迎えし、生成 AI をいかに自社のビジネス価値へと転換するかをテーマに、登壇企業のストーリーを中心にお送りします。 全国各地でイベントを開催することにした背景 「東京のイベントには物理的に参加しづらい」「AI エージェントという言葉は聞くものの、自社で何から始めればよいかわからない」「社内にデータは眠っているはずだが、どう活用すればよいかイメージが湧かない」…こうしたご意見は、昨年度私たちが全国のお客様と対話する中で、繰り返しいただいてきました。AWS としても、リモートでのお打ち合わせを重ねるたびに、各地域のお客様に十分な情報をお届けしきれていないと感じていたのが正直なところです。 このギャップを埋めるため、私たち自身が実際に各地へ足を運び、AWS からの情報提供に加えて、その地域で生成 AI を実際のビジネスに活かしているお客様の生の声を共有する場を作ろう、というのが本シリーズの出発点です。 イベントの流れ 当日はまず、私 田中から「AWS で一歩先へ！生成 AI 時代のビジネス変革の打ち手」と題して、生成 AI を取り巻く世界と日本の環境、AWS の生成 AI ポートフォリオ、そして AI を自社の業務に活かしたいお客様がどのように生成 AI で業務とビジネスを変えていけるかについて、 Amazon Quick  のデモを交えながらご紹介しました。 写真: 筆者（田中）によるオープニングセッション 続いて、AWS ファイナンス部門の Finance Manager 坂本 秀隆 が「AWS のファイナンスが語る！生成 AI で実現する業務効率化の実践とデモ」と題して登壇し、わずか 2 名のファイナンス担当が多くの問い合わせや報告業務にどう対応していったのか、具体的な実例をデモを交えて紹介しました。印象的だったのは、AWS 社内でも AI の浸透は一夜で起きたわけではなく、 小さく始めて使い心地を体感するところから少しずつ広がっていった 、というポイントです。 写真: AWS ファイナンス部門 坂本によるセッション AWS 側のセッションを通じて生成 AI 活用の全体像とイメージをつかんでいただいたあと、お客様事例のご紹介セッションへ進みました。ここからは、大阪・関西を拠点に、社内に眠る知的資産を生成 AI で価値に変える取り組みを進めてこられた 2 社の事例をご紹介します。 事例紹介：株式会社サクラクレパス様 〜AWS × Dify で、安全・低コストに始める全社生成 AI〜 事例紹介の 1 社目は 株式会社サクラクレパス 様です。1921 年創業、大阪市に本社を構え、グループ従業員数は約 1,600 名。文具・画材・事務用品の製造販売を主軸に、工業用・医療用・エレクトロニクス分野にも色材技術を応用されています。当日は統轄本部 情報システム部長の高橋 幹成 様に、全社生成 AI 活用の取り組みについてお話しいただきました。 サクラクレパス様社内では、2025 年 7 月までは社内での生成 AI 利用は原則禁止のルールがありました。これは、情報漏洩・著作権・品質・コンプライアンス・セキュリティ管理上のリスクが整理できていなかったためですが、テクノロジーの進化とともに、社内外で「AI を活用したい」という声が急速に広がったことで、利用制限から活用推進へと方針を転換 されました。2025 年 8 月より、安全な SaaS 型チャットの導入と社内ガイドラインの策定を進め、RAG による社内のナレッジ活用、業務フローの一部を生成 AI/AI エージェントに代行させるところまで、段階的に AI のビジネス活用を進められました。 これらのお取り組みのなかで特に試行錯誤された点として挙げられていたのが、生成 AI の「3 ヶ月ごとに常識が変わる」というスピード感に対応していくことです。「どのモデルが最適か判断できない」「技術的ハードルが高く専門エンジニアが必要」「高額な初期投資が必要で、数ヶ月後には状況が変わっている」──この 3 つの壁にどう向き合うかが論点でした。サクラクレパス様は、今後様々なモデルや用途が登場することも見据えてマルチ LLM を前提としたプラットフォームを構築すること、可能な限り自前で開発せずエージェント機能を活用すること、ノーコード・ローコード開発手法（ Dify ）で開発を民主化すること、という 3 つの方針を立てて、それらの課題に対応されました。 もともとセキュリティリスクへの懸念から生成AI活用を制限していた背景があったため、AI 基盤の選定には セキュリティの確保を最優先事項 として位置づけました。このことをふまえて、AI 基盤としてグローバル水準のコンプライアンス・データ管理を実現できる Amazon Bedrock を採用しました。また、専門的な知識がなくても AI アプリケーションが作成ができガバナンスにも強みがある Dify を選定し、Amazon Bedrock と組み合わせて社内のAI共通基盤とされました。Amazon Bedrock では、ユースケースに応じて複数のモデルプロバイダーが提供するモデルを切り替えて使用することができ、進化が早い領域においても様々な試行錯誤を低リスクで行える環境を実現されました。さらに、AWS の生成 AI 実用化推進プログラムを活用して、初期投資を抑えながら検証を行う「小さく始める」アプローチが実現できたとも語っています。 運用面では、 情シス主導 × ユーザー作成の役割分担 という考え方をもとに社内展開を進められました。お取り組みの工夫として、ツールを配るだけでなく経営層も現場も共通認識を持てるよう、生成 AI 勉強会を実施されたこと、少数精鋭の検証チームを作成し様々なユースケースに対して試行錯誤の検証を日々行っていること、ただ業務を AI に当てるだけでなく、既存の業務の見直しを並行して行い、①やめる業務、②プロセスを改善する業務、③デジタル化する業務、④自動化する業務 といった仕訳けをされるという工夫についてもお話いただきました。これによって、より注力すべき領域が明確になり、AIを取り入れた場合の業務のゴールも明確になる効果があります。また、このような仕訳のなかで、AIが得意な領域、工夫が必要な領域を見定めることにも繋がりました。 社内ルールの面でもいくつかの工夫をされました。ノーコードアプリは、誰でも AI アプリを作れる便利さ故に、管理されない「野良アプリ」の増殖が課題となりがちです。サクラクレパス様はこれに対し、ユーザーはテスト環境で自由に検証し、情シスが承認したアプリだけを本番環境に昇格させる運用ルールを確立し、自律と統制のバランスを実現されています。 サクラクレパス様のお取り組みはこれからも続いていきます。全社展開を見据えた Dify 基盤の Amazon S3 + Amazon Bedrock Knowledge Bases への移行、業務棚卸に基づく AI 適用業務の明確化、部門別パイロット導入から全社的な横展開、AI エージェントによる業務自動化など、やるべきことはまだまだあり、今後は「生成 AI を『特別なツール』から『日常の業務インフラ』として位置づけて活用を進めていきたい」というメッセージで締めくくられました。 「全社基盤の整備」というマクロな切り口で語ってくださったサクラクレパス様に続き、もう 1 社は「研究・開発現場に眠る専門知識」という切り口から生成 AI に向き合われた事例です。 事例紹介：メック株式会社様 〜ベテランの専門知識を AI エージェントに渡す、自前 Agentic RAG の挑戦〜 事例紹介の 2 社目は メック株式会社 様です。1969 年設立、兵庫県尼崎市に本社を構える東証プライム上場企業で、従業員数は単体 277 名・連結 480 名。プリント配線板（PCB）製造用の薬品、特に半導体パッケージ基板向け銅表面処理剤「MECetchBOND CZ シリーズ」を主力とされ、世界中のパッケージ基板メーカーに製品を提供されています。当日は情報システム部門 岸本 宗真 様に「AI Agent による検索システム」の開発ストーリーをお話しいただきました。 設立から 57 年近くが経つメック様には、これまでの数多くの受託案件対応の過程で蓄積された大量のデータが存在します。これらを活用して、「経験や力量の差によらず全員が高い水準で業務に取り組める状態にしたい」「複雑な専門領域でも直感的に情報にアクセスできるようにしたい」「報告書・特許・議事録・論文といった知的資産を戦略的な強みに変えたい」という観点から、AI の活用に取り組まれました。 岸本様がまず取り組まれたのは、チャットベースで過去の案件ナレッジを得られる Agentic RAG （RAG に AI エージェントの自律的判断を組み合わせ、必要に応じて複数のデータソースを動的に検索できる仕組み）アプリケーションの構築でした。しかし、実際に取り組んでみると、AI は研究データの取得のために複雑な手順が必要となってしまうケースがあり、取得がうまくいかないケースがありました。また、業界特有の言葉・社内の専門用語・プロジェクトの詳細といった、検索の前提となるような知識を AI が持っていないために、もっともらしい嘘（ハルシネーション）を返してしまうという状況も発生しました。 これを解決するために、 専門ナレッジを事前に AI に付与する アプローチを採用しました。文書検索の前処理として、プロジェクト単位で概要・進捗・時系列・関連ファイルをまとめた「スキル」と呼ばれる専門ナレッジを情報検索エージェントに渡し、「ベテラン社員の視点」で社内データを探せる状態を作りました。また、この仕組みに継続性を持たせるために、新しいデータが追加されるたびにナレッジが自動更新される情報更新エージェントも同時に作成しました。 図: メック株式会社 社内ナレッジを使いこなす Agentic RAG 構成 アーキテクチャは、 AWS Amplify と Amazon Bedrock AgentCore を使用し、AI アプリケーションをサーバーレスに稼働させることで費用や開発量を抑えたスモールスタートを実現しました。ベクトルデータベースには Amazon S3 Vectors を採用し、データベースレイヤーのコストも抑えることができました。データベースレイヤーのコストはこれまで検証の壁になりがちでしたが、Amazon S3 Vectors の活用が取り組みにおけるコストの障害を解消することに寄与したと語っていただきました。さらにAWS 製の AI エージェントライブラリ Strands Agents との相性の良さもポイントに挙げられました。 実際の導入にあたっての技術的な工夫として、AI Agentによる検索性を意識してメタデータを持たせる工夫をされました。これが、AI が効率的に文書検索を行うことに寄与しています。また、社内の専門用語やプロジェクトの詳細など、社内でも専門とするコンテキストが異なる場合があるため、まずはグループ単位で最適化し、少しずつスコープを拡大していくというスモールスタートのアプローチを取るなど運用面でも工夫をされました。 このような工夫を重ねられ、現在は特定の部門で本番導入をした直後でありながら、導入部門から非常に前向きなフィードバックが得られており、他グループへの展開、研修など社内の別ユースケースへの活用など様々な展開が見えている状態とのことです。数字に表れる成果はこれからですが、数字よりも大事な『次の取り組みにつながる変化』が既に社内で起きていると岸本様は語られました。一方、様々な社内特有の暗黙知をどうAIに渡していく（渡し続ける）こと、データフォーマットに関わる課題、多様化するユースケースに対応するため開発速度を上げていくことなど、現在進行中の課題感もあるとのことです。そのなかでも、開発速度に関しては AWS 主催のハッカソンイベントへの参加、コストに対しては Amazon S3 Vectors など新しい機能の積極的な活用、のように、ひとつひとつ課題に向き合って解決されていることをお話いただきました。 岸本様は最後に、「製造業でも自前でできる」「小さく早く始めて、大きく育てる」という 2 つのメッセージを伝えてくださいました。地方にいる製造業では、ドメイン知識が多くあるため、これらを積極的に活用できる基盤を整えることでAIを大きく活用できる可能性がある、生成 AI というテクノロジーは革命だが、取り組みは泥臭く地道に、一歩一歩進めていく部分も重要、とお話いただきました。 写真: メック株式会社 岸本様によるセッション パートナーセッション：クラスメソッド株式会社様 〜生成 AI 活用、次の一歩の具体像〜 お客様事例のあとには、AWS プレミアティアサービスパートナーである クラスメソッド株式会社 様のセッションです。「生成 AI 活用、次の一歩の具体像」と題して、技術ブログ「 DevelopersIO 」で多数の生成 AI 関連記事を執筆され、Amazon Bedrock AgentCore を特に得意とされているクラウド事業本部 コンサルティング部 AI ソリューションアーキテクトの神野 雄大 様より、これまでの支援実績に基づいたお話をいただきました。 自律型コーディング AI エージェントの登場によって、曖昧な指示でも高品質なアウトプットが出せるようになり、変化は急速に進んでいる一方で、PoC の先に進めない、作ったけれど運用が回らない、使われない・広がらない、という 3 つの局面で多くのお客様が悩まれている、といった現状についてお話しいただきました。これらの課題に対して、効果のある進め方の例として4つの実際のご支援プロジェクトの事例を紹介いただきました。 「スモールスタートして、成功事例を他部門へ展開する」「ガバナンスのための基盤を整える」「投資対効果を数値化する」「改善サイクルを積み重ねる」といった、生成 AI 活用のポイントとなる事例を、実際にクラスメソッド様がどう支援され、どう結果が得られたかについて詳しく紹介いただきました。 写真: クラスメソッド株式会社 神野様によるセッション まとめ 大阪でご登壇いただいた 2 社のお客様とパートナー様は、それぞれ異なるお取り組みでありながら、共通していたのは、小さく始め、地道で時には泥臭い改善のサイクルを積み上げていく という姿勢だと考えます。AI 活用は決してツール導入だけでは終わりません。スモールスタートでの導入、成功体験からはじめ、そこで得られたデータの課題、運用の課題、リテラシーの課題は、現場の意見も取り入れながら改善サイクルを回しておられたと思います。 セッション後の懇親会では、セキュリティの考え方、データ整備の進め方、社内への AI 浸透の仕方など、参加者同士・登壇者・AWS チームとの間で活発な議論が交わされていました。サービスや技術そのものだけでなく、こうした実際の取り組みの事例や知見を全国各地様々なお客様に対して発信していくことは、AWS の大切なミッションの一つだと考えています。 このブログシリーズでは、本イベントの開催レポートを各拠点の開催順にお届けしていきます。今回お届けした大阪・初回に続き、次回は翌日開催の大阪・AI で顧客を支援する IT 企業編を予定していますので、どうぞお楽しみに。 そして読者の皆様へ──もし本ブログを読んで「うちの会社の取り組みもぜひ発信したい」「AWS と一緒に自社の眠るデータを価値に変えたい」「AI で日本をもっと元気にしていきたい」と感じていただけたなら、ぜひ担当営業、あるいはお近くの AWS メンバーまでお気軽にお声がけください。 関連ブログ メック株式会社の事例：Amazon Bedrock AgentCore で研究業務を効率化 – AI エージェントによる情報検索と更新の自動化 執筆者 Amazon Web Services Japan 合同会社 ソリューションアーキテクト　田中 里絵

はじめに 昨今、ランサムウェアをはじめとするサイバー攻撃による被害が深刻化しています。 ログ分析や不正検知は昔から取り組まれてきたテーマですが、不正は複数のイベントの関連の中で現れることが多く、単発のイベントだけでは検知が難しくなっています。 特にクラウドやSaaSでは、管理操作やデータアクセスがAPIや複数サービスに分散して監査ログに記録されるため、個々の操作は自然に見えても、主体・対象の関係を横断して見ると不自然さが現れることがあります。 そこで本記事では、クラウド監査ログ向けに設計した不正検知の一つのアプローチと、その検証結果について解説します。 クラウドログで見抜くべき