--- title: データ責任者が不正対策チームに加わるとき ― シャハル・メイアーとともに source_page: https://www.sardine.ai/jp/media/the-saturday-fraud-strategist/episodes/llm-analytics canonical: https://www.sardine.ai/jp/media/the-saturday-fraud-strategist/episodes/llm-analytics format: text/markdown date: 2026-08-03T04:01:00.000Z description: LLM 分析は、不正対策チームがより迅速に動くことを可能にしますが、そのためには、強固なデータガバナンス、クリーンな基盤、そして AI を導入する前により良い問いを立てることが不可欠です… --- **Quick links:** [Human page](https://www.sardine.ai/jp/media/the-saturday-fraud-strategist/episodes/llm-analytics) · [Home](https://www.sardine.ai) · [Customers](https://www.sardine.ai/jp/customers) · [Blog](https://www.sardine.ai/jp/blog) · [Demo](https://www.sardine.ai/jp/demo) --- # データ責任者が不正対策チームに加わるとき ― シャハル・メイアーとともに **Published:** 2026-08-03T04:01:00.000Z LLM 分析は、不正対策チームがより迅速に動くことを可能にしますが、そのためには、強固なデータガバナンス、クリーンな基盤、そして AI を導入する前により良い問いを立てることが不可欠です… このエピソードは、データ担当の役員が不正対策チームのところへやって来る場面から始まります。 とてもニッチなジョークの前振りみたいに聞こえるかもしれません。実際、そうかもしれません。でも正直なところ、これは多くの不正対策チームが身に覚えのありすぎる現実の問題でもあります。私たちはほとんどあらゆることにデータを頼っていますが、不正対策チームとデータチームの関係は、多くの人が認めたがらないほど複雑でやっかいなものになりがちです。 今回のエピソードでは、データアドバイザーであり、元Meta社データ部門ディレクターのシャハル・メイア氏を迎え、LLMアナリティクスやセルフサービス型アナリティクス、データ基盤、そしてなぜ不正対策チームは散らかったデータの上にただAIを載せるだけでは戦略にはならないのかについて話します。 そう、LLM を活用したセルフサービス型アナリティクスは本当に魅力的に聞こえます。平易な英語で質問すれば答えが返ってきて、意思決定が速くなり、900もの優先事項を抱えたデータチームに3週間も順番待ちする必要がなくなる。最高ですよね。私もそんな世界を望んでいます。 でもそこで自分に問いかける必要があります。答えはどこから来たのか？どのテーブル同士を結合したのか？どんな定義を使ったのか？ビジネスの文脈を理解していたのか？幻覚のようにでっち上げていないか？そもそもあなたは正しい質問を投げかけていたのか？ 小さなことではありません。 この対話の本質は、AIアナリティクスが約束する理想と、不正検知アナリティクスの現場での現実とのギャップについてです。不正対策やリスク管理のチームは、常に敵対的な環境で仕事をしています。問題の姿は絶えず変化し、シグナルとノイズの比率は悪く、判断を誤ったときのコストは、不正を通してしまう場合であれ、正当なユーザーをブロックしてしまう場合であれ、非常に大きくなり得ます。ですから、LLMアナリティクスを本当に役立てたいのであれば、きらびやかなインターフェースだけでは不十分です。必要なのは、データの基盤、ガバナンス、意味の一貫性、そして小さく始めるという謙虚さです。 このエピソードでお届けする内容： なぜ不正対策およびリスク管理チームは、特に複雑なデータの顧客となるのか 不正対策チームが、次々とポイントソリューションを要求するのではなく、データチームとより良く協働する方法 なぜセルフサービス型アナリティクスは、LLMが登場する以前にはこれほど頻繁に失敗していたのか LLM 分析がインターフェースになったときに、何が変わり、何が変わらないのか なぜ、素早い答えを得ることよりも「正しいデータの問い」を立てることが重要なのか データガバナンス、セマンティックレイヤー、そしてデータ品質がAI分析の結果をどのように左右するか なぜ不正対策チームは、厳選された1つのテーブル、1つのユースケース、そして1つの測定可能な成果からAI導入を始めるべきなのか データプロジェクトにおける1時間版、1日版、1週間版、1か月版の考え方 このエピソードは次のような方におすすめです： 不正対策業務に携わっており、リスクや不正に関する分析プロジェクトを推進するためにデータチームに依存している 不正対策基盤でのデータ分析に、LLM を用いたアナリティクスや AI エージェントの導入を検討している あまりにも簡単そうに聞こえるAIによるデータクエリを約束されているなら、おそらく本当にそんなに甘くはありません データエンジニアリング、アナリティクス、またはリスクデータインフラのチームと、よりうまく連携できる方法が必要です 実際のユーザーに影響を与えるツールを導入する前に、AIデータガバナンスについて現実的かつ実践的な考え方を身につけたい ### エピソードの概要と主なポイント 不正対策チームは、一般的なデータ利用者とは異なります このエピソードでシャハルが伝えている主なポイントの一つは、詐欺対策チームはほとんどのビジネス上のステークホルダーとは違うということです。愛情を込めて言っていますよ。たぶんね。 マーケティング、営業、財務のチームには、良質なデータが絶対に必要です。しかし、不正対策やリスク管理では、複雑さの質がまったく異なります。何年分もの履歴データに対して巨大なバッチ処理を実行することもありますが、その結果は最終的に、ミリ秒単位での意思決定を支えなければなりません。このアカウントは正当なものか？この取引はリスクが高いか？この行動は通常どおりなのか、それとも攻撃の始まりなのか？ それは非常に奇妙な運用環境です。 通常、信号対雑音比は悪いものです。不正のパターンは常に変化します。正当なユーザーであっても、一見すると奇妙な行動をとることがありますし、不正行為者が一見普通に見える行動をとることもあります。そして、盗まれたアカウントと、国境を越えて移動している本物のユーザーとの違いが、まったく判別できないこともあるのです。 だからこそ、不正対策チームとデータチームの連携は、一般的な「依頼して結果を受け取る」関係よりも、はるかに密接でなければなりません。不正対策チームは、ただタスクを丸投げして、データチームが本番環境で回してくれることを期待するだけではいけません。データチームには文脈が必要です。ミッションを理解する必要があります。なぜその判断が重要なのか、そしてシステムが誤った判断をしたときに何が起こるのかを知る必要があります。 そうでなければ、形式上は全員が自分の仕事をきちんとこなしているのに、なぜかシステムはうまく機能しない。理想的とは言えません。 ポイントソリューションは長期的なデータ問題を引き起こします シャハルは、不正対策やリスク管理のチームでよく見られる代表的な誤りの一つについて語っています。それは、基盤となるインフラではなく、個別のポイントソリューションばかりを求めてしまうことです。 不正対策チームは、ある問題に気づきます。再び現れる悪質な出品者。繰り返し現れる迷惑な購入者。特定の詐欺パターン。新しいリスクフロー。そこで彼らは、その一つの問題を解決するための対策をデータチームに求めます。その場ではもっともに思えます。しかし、すべての依頼が単発のプロジェクトになってしまうと、システム全体は保守が難しくなり、スケールしづらくなり、再利用もしにくくなってしまいます。 より良い問いは、「これらの多くの解決策をもっと簡単にするには、どのようなインフラが必要か？」ということです。 多くの不正検知・不正分析の課題は、共通する基盤を必要とします。過去の行動履歴からバックエンドのシグナルを算出し、それらをアクセスしやすい場所に保存し、リアルタイムまたはそれに近い形で利用できるようにする必要があります。そのパイプラインを一度きちんと構築しておけば、新しい不正パターンが現れるたびにゼロからやり直す必要はありません。 だからといって、すべての問題に同じ解決策があるわけではありません。当然そうではありません。それが本当なら、不正対策はずっと簡単になるでしょう。しかし、だからこそ不正対策チームは、個別の依頼ベースではなく、再利用可能なインフラを軸にデータチームと足並みをそろえるべきなのです。 そうすることで、次のプロジェクトをより安く、より速く、そしてより負担の少ないものにできます。 不正検知モデルの最後の一歩は、チームが認めている以上に重要だ 会話の中でよくある場面として、シャチャルは、チームが高度なモデルを構築しながら、その後でほとんどランダムに近い形で固定のしきい値を使ってしまう状況を説明しています。 モデルスコアが800を超えたら、その取引を拒否してください。 なぜ800なのですか？ 多くの場合、その答えはあまり良くありません。 これは、不正対策の担当者を思わず黙って遠くを見つめさせてしまうような事柄の一つです。チームは数か月をかけて、高性能なモデルを構築し、パフォーマンスを測定し、特徴量を調整し、統計的な出力を評価します。ところが、実際のビジネス上の意思決定レイヤーには、それほど注意が払われません。 しかし、最後の一歩こそがモデルがユーザーと接する部分です。そこで、どれだけ不正を止めるか、どれだけ誤検知を生むか、そして実際にビジネスとしてどのようなトレードオフを選択しているのかが決まります。 AUC（曲線下面積）は有用な指標になり得ます。しかし、それだけではモデルが適切に使われているかどうかは分かりません。また、閾値が地域やセグメント、プロダクト、ユーザータイプごとに妥当かどうかも分かりません。さらに、ビジネス上の成果が本当に改善しているかどうかも教えてくれません。 だからこそ、戦略レイヤーが重要なのです。運用環境でモデルがどのように使われているかを定期的に検証しなければ、モデルに費やした多くの労力が無駄になってしまう可能性があります。 AIが登場する前にセルフサービス分析がうまくいかなかったのには理由がある セルフサービス型アナリティクスは新しいものではありません。LLM アナリティクスが登場するずっと前から存在していました。フィルター付きのダッシュボード、BI ツール、目的別に作られた社内ツール、あらゆるところにあるドロップダウンメニュー。夢はシンプルでした。ビジネスユーザーが SQL や Python、あるいはアナリストの助けを借りることなく、自分たちのデータに関する疑問に自分で答えられるようにすることです。 それでも、多くの場合うまくいきませんでした。 なぜでしょうか？それは、セルフサービス型のアナリティクスが、現実にはほとんど当てはまらない前提に依存しているからです。 ユーザーは自分が何を求めているか分かっている、とあなたは仮定します。はっきりと説明できる、とも仮定します。社内で使われる言葉には一意で決まった意味がある、とも仮定します。「売上」や「減少」や「アクティブユーザー」といった言葉が、どのチームにとっても同じ意味だと仮定しているのです。悪くない発想ですが、たいてい間違っています。 また、ユーザーがデータの複雑さを理解していると仮定してしまいますが、たいていはそうではありません。これはユーザーを侮辱しているわけではありません。データには、あちこちに部族的な暗黙知が埋もれています。たとえば、あるアナリストは、特定のレポートでは特定の国からのトラフィックを除外しないと結果がノイズだらけになることを知っています。ビジネスユーザーは、その判断が行われたことを知らないかもしれませんが、その誰かの判断があって初めてレポートは意味を持つのです。 セルフサービスは、人々が自分で数字を取りに行き、その結果に責任を負いたいと考えていることも前提にしています。しかし、必ずしもそうとは限りません。もしCEOの前で数字が間違っていたら、多くの人は自分ではなくアナリストが責任を問われる立場であってほしいと思うでしょう。これが人間の行動です。洗練されてはいませんが、現実です。 だから、LLM 分析がセルフサービス分析の問題を解決してくれると言うときには、立ち止まって考えるべきです。インターフェースは変わりましたが、根本的な問題は消えていません。 LLM 分析は、質の悪い質問をより危険なものにしかねない LLM 分析で怖いのは、平易な英語で質問に答えられること自体ではありません。その点はむしろ驚くべきことです。 怖いのは、間違った質問に対しても自信満々に答えてしまうかもしれないことです。 従来型のダッシュボードでは、指標の定義はたいていハードコードされています。ダッシュボードが気に入らないこともあるかもしれませんが、少なくとも既知のデータソースから取得し、既知のロジックを適用していることは分かっています。AIによるデータクエリでは、どのテーブルを使うか、どう結合するか、リクエストをどう解釈するか、そして答えをどう提示するかを、システム側が判断することになります。 ユーザーがSQLやデータ構造、指標の定義、ビジネス上の文脈を理解していない場合、どのようにしてその回答を検証できるのでしょうか？ そのとおりです。 ここで、分析におけるAIの幻覚が実際のオペレーションリスクになります。回答は洗練されて見えるかもしれません。クエリももっともらしく見えるかもしれません。結果も、感覚的には「正しそう」と思えるところまで近いかもしれません。しかし、もし問いの立て方が不適切だったり、データの文脈が欠けていたりすれば、出力は依然として誤っている可能性があります。 そして不正対策の現場では、誤った回答は単なる理論上の問題ではありません。誤ったルールや誤った審査、誤ったモデル判断や誤ったポリシー変更につながり、ユーザーへの実害や損失という形で現実の影響を及ぼす可能性があります。 だからこそシャハルの指摘はとても重要なのです。アナリストの仕事は、単に質問に答えることではなく、正しい問いを立てる手助けをすることなのです。 正直なところ、その部分こそ最初ではなく最後に自動化すべきです。 AI分析ツールにおいてデータガバナンスは必須であり、任意ではありません この議論で最も有益な点の一つは、AI分析ツールに対する2つのアプローチの違いを明確にしていることです。 1つのアプローチは、AIエージェントにデータウェアハウスへのアクセス権を与え、人々が自由に質問できるようにすることです。 それが、誰もが不安になるような、少なくともそうなるべきバージョンです。 もう一つのアプローチは、まず堅牢なデータ基盤を構築することです。指標を定義し、セマンティックレイヤーを作成し、メタデータを追加し、各フィールドの意味を明確にします。テーブルを整理・管理し、品質を監視します。そのうえで、統制されたデータ環境の上で LLM 分析を活用します。 その2つ目のアプローチは、デモではあまり派手ではありません。しかし、実際にうまくいく可能性はずっと高いのです。 AI 分析ツールには、人間以上に基本が求められます。人間のアナリストであれば、データの様子がおかしいと気づいたり、組織内で共有されている暗黙知を思い出したり、追加の質問を投げかけたりすることができます。一方で LLM は、もっともらしい答えをそのまま出してしまうことがあります。そして、もとになる前提や文脈が乱れていれば、その答えも同じように乱れたものになりかねません。 そのため、不正対策チームがLLMを活用したセルフサービス型アナリティクスを導入したい場合、最初のプロジェクトは「データウェアハウス全体に接続する」ことではあるべきではありません。まずは信頼できる1つのユースケースと、厳選された1つのデータセットまたはテーブル群、明確な定義、質の高いメタデータ、そしてそのツールが本当に役立っているかを検証する方法を用意すべきです。 とても退屈だが、とても必要なことだ。 すべてのデータではなく、まずは一つのユースケースから始めよう 不正対策チームがAIを導入するにあたってのシャハルのアドバイスは、驚くほど実践的です。「最初から何もかも一度にやろうとしないこと」です。 まずは 1 つのユースケースから始めましょう。1 つの繰り返し出てくる問い。1 つの信頼できるデータセット。チームが本当に理解している定義を備えた 1 つのテーブル、もしくは少数の厳選されたテーブルのセットから始めるのです。 検証レイヤーを構築しましょう。コンテキストレイヤーを構築しましょう。メタデータを追加しましょう。「取引の拒否」とは何を意味するのかを定義してください。それは不正検知システムによって拒否されたのでしょうか？カード発行会社によって拒否されたのでしょうか？残高不足によって拒否されたのでしょうか？これらの違いは重要です。 次に、そのLLM分析ツールが本当に役に立つかを検証しましょう。正しい問いに答えているでしょうか？適切なデータを使っているでしょうか？インサイトを得るまでの時間を短縮できているでしょうか？より安全な意思決定を支援できているでしょうか？不正対策チームを本当に強化しているでしょうか、それとも単に間違った判断をより速く下せるようにしているだけでしょうか？ その最後の問いが重要です。 最初のユースケースがうまくいったら、少しずつ範囲を広げていきましょう。ディメンションを追加し、メトリクスを追加し、さらに多くの問いを増やしていきます。ただし、AIが会社中の散らかったデータベースや環境、テーブル、定義をすべてうまくつなぎ合わせてくれるという幻想から始めてはいけません。 それは戦略ではありません。ただの、非常に高くつく「さあね」という態度にすぎません。 AIは文脈の把握やブレインストーミング、より鋭い思考に役立ちます このエピソードは反AIではありません。そんなのは怠慢ですし、しかも間違っています。 シャハルは有用な区別を示しています。AI は、外部コンテキストの提供やブレインストーミング、アイデア出し、そしてあなたの考え方に異議を唱えることに非常に長けている場合があります。ビジネス指標のおおよその範囲を知りたいときには、AI は方向性となるコンテキストを得る助けになるかもしれません。自分が見落としている点について考えを深めたいときにも、AI は役立ちます。計画をストレステストしたいときにも、AI は助けになります。 重要なのは、任せきりにするのではなく、自分を補強するために使うことです。 つまり、AIはあなたの思考を磨く手助けはしてくれますが、あなたの思考そのものを置き換えるべきではありません。AIは問いを提案してくれますが、どの問いが重要かを判断するのは依然としてあなたです。AIは選択肢の枠組みづくりを助けてくれますが、最終的な判断を理解する必要があるのもあなたです。AIはクエリの下書きを作成してくれますが、その結果が実際のユーザーに影響するのであれば、論理を検証する責任はあなたにあります。 特に不正対策やリスク管理の分野では、下した判断が取引の拒否や再審査、摩擦の増大、ユーザーへの被害、金銭的損失、あるいはコンプライアンス上のリスクにつながる可能性があるため、このことはいっそう重要になります。 だからこそ、AI は使うべきです。ただし、本番環境の主導権をすべて渡して放置するのはやめたほうがいいでしょう。妥当な話ですよね。 1時間で作ったバージョンのほうが、1か月かけて作ったバージョンより良いことはよくある。 会話の終わり頃に、シャチャールはシンプルだが役に立つフレームワークを共有します。それは「どんなプロジェクトにも、1時間バージョン、1日バージョン、1週間バージョン、そして1か月バージョンがある」という考え方です。 これは盗む価値があります。敬意を込めて。 多くの技術チーム、特に不正対策やリスク管理のチームは、問題を見つけるとすぐに「1か月かかる完璧なバージョン」を思い描いてしまいます。あらゆるイレギュラーケース、あらゆる外部連携、理想的なデータソースのすべて、あらゆる複雑さを盛り込もうとするのです。そうしているうちに、プロジェクトはどんどん巨大になり、停滞し、優先度を下げられ、あるいはロードマップのドキュメントの中でひっそりと消えていきます。 その代わりに、1時間バージョンがどのようなものかを考えてみてください。すぐに方向性のある価値を生み出せますか？その指標をおおよそ見積もれますか？最終形だと装わずに前進できますか？ それから改善していきましょう。1日で作るバージョンは、より洗練されています。1週間で作るバージョンは自動化されています。1か月で作るバージョンは、さらに完成度が高くなります。 これは新しいことではありません。MVP的な考え方であり、アジャイルです。しかしどうやら、私たちは数年おきに名前だけ変えて、同じような単純なことを学び直す必要があるようです。まあ、いいでしょう。 データチームと連携している不正対策チームにとって、この考え方は特に有用です。というのも、データリソースには限りがあるからです。素早く価値を示し、進むべき方向性を検証し、そのうえで段階的に構築していければ、誰も全体像を理解していない2年がかりのプロジェクトを提案するよりも、はるかに支援を得やすくなります。 ### 最終的なまとめ LLM 分析は不正対策チームに大いに役立ちます。ただし、そのためには基盤がきちんと整っていることが前提です。 データ定義があいまいで、セマンティックレイヤーが存在せず、指標の意味がチームごとにバラバラで、ユーザーも正しい質問の仕方を理解していないのであれば、AIがそれを魔法のように解決してくれることはありません。むしろ混乱を加速させてしまうだけかもしれません。 今回のエピソードから得られる、少し厄介だけれど有益なポイントはこうです。詐欺対策チームは完璧なデータを待つべきではありませんが、同時に、AIがデータガバナンスやデータ品質、そしてデータチームとの賢い連携の必要性をなくしてくれると考えるべきでもありません。 小さく始めましょう。まずは信頼できるひとつのユースケースを作り上げてください。基盤となるインフラを整え、足並みをそろえましょう。より良い問いを立ててください。AIは状況理解や思考を支えるために使い、責任から逃れるための抜け道として使ってはいけません。 ともあれ、LLM アナリティクスの戦略が「とりあえず全部つないで、何が起きるか見てみる」なのであれば、技術的にはそれも一応“戦略”と言えるでしょう。 ただ、壊れたあとで説明したいとは思えないやり方ですね。 リソースとリンク 私の、そしてできればあなたの一番好きなテーマについての話を、まだ終わらせたくありませんか？ 登録してください：The Saturday Fraud Strategist ニュースレター。 つながるシャハル・メイアー | LinkedIn データアドバイザー 元Metaデータ部門ディレクター つながるなら Chen Zamir | LinkedIn The Saturday Fraud Strategist のホスト フィンテック企業の、よりスマートな不正防止対策づくりを支援 『The Fraud Fighter’s AI Playbook』共著者