--- title: AIで開発が低コストに。不正対策ベンダーは、今なお何のために必要なのか？ source_page: https://www.sardine.ai/jp/media/the-saturday-fraud-strategist/episodes/building-vs-buying-fraud-vendors canonical: https://www.sardine.ai/jp/media/the-saturday-fraud-strategist/episodes/building-vs-buying-fraud-vendors format: text/markdown date: 2026-10-31T01:01:00.000Z description: 不正対策の内製か外部ベンダーの活用かは、もはや二者択一ではありません。何を内製し、何を外部から導入し、どの領域で今なおベンダーが強みを発揮するのかを整理します… --- **Quick links:** [Human page](https://www.sardine.ai/jp/media/the-saturday-fraud-strategist/episodes/building-vs-buying-fraud-vendors) · [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) --- # AIで開発が低コストに。不正対策ベンダーは、今なお何のために必要なのか？ **Published:** 2026-10-31T01:01:00.000Z 不正対策の内製か外部ベンダーの活用かは、もはや二者択一ではありません。何を内製し、何を外部から導入し、どの領域で今なおベンダーが強みを発揮するのかを整理します… ベンダー業界では常に開発競争が繰り広げられてきましたが、今年はAIがその中心です。一方、私が話を聞く現場の実務者たちは、以前よりもはるかに多くのものを自分たちで開発しています。数週間前、あるリスク管理責任者から、彼女のチームが社内で開発したものについて話を聞き、その内容に感銘を受けました。それをきっかけに、ベンダーを取り巻く環境が根本から変わりつつあるのではないか、そして1、2年後にも私たちはベンダーを必要としているのだろうかと考えるようになりました。 この問いを一緒に考えるため、Netanel Kabalaを招きました。Netanelと私がPayPalで出会ったのは17年前です。テルアビブのFraud SciencesチームがPayPalに買収された後、彼が不正対策アナリストとして働き始めた頃でした。その後、彼は暗号資産の購入を可能にするオンランプサービスの先駆けとなったSimplexを共同創業し、同社の買収後はNuveiでAIとアナリティクスを統括しました。最近では、決済事業者やフィンテック企業が意思決定システムを自社で管理・運用できるよう支援するDulyを共同創業しています。今回は、不正対策システムを内製するか、ベンダーから導入するかというテーマを、ベンダー疲れ、チームが最初に内製するもの、基盤モデルや意思決定モデルがもたらす変化など、さまざまな角度から考えます。結論は単純なイエスかノーにはなりませんが、それが誠実な答えだと思います。その代わりに、どの領域を内製し、どの領域で外部製品を導入し、どの領域で共同開発するのが合理的か、その見取り図を描きます。 このエピソードで取り上げる内容： ベンダー疲れがチームを自社開発へと向かわせる理由と、それがベンダーとの関係に及ぼす影響 これまでに最も成功している内製開発が、プラットフォーム全体を置き換えるものではなく、専門家一人の作業時間を短縮する小さなツールである理由 ベンダーがエンドツーエンドのソリューション提供からデータ提供へと軸足を移しつつある状況と、大規模なチームがネットワークデータやデバイスインテリジェンスを特に重視する理由 AIコーディングで手動レビュー用ビューアを簡単に構築できる理由と、ルールエンジンの開発がまったく異なる種類のプロジェクトである理由 一夜にして作られる数十ものモデルから、誰も想定していなかったレイテンシーやドリフト監視の問題まで、AIが生み出す低品質な成果物がリスク管理チームにどのような形で現れるのか 基盤モデルと意思決定モデルによって、特徴量や異常検知はどう変わり、リアルタイムの不正検知モデルを誰がデプロイできるようになるのか セグメンテーションが最適な出発点である理由と、KYC（本人確認）や制裁リスト照合のような汎用機能の構築が落とし穴となる理由 エンジニアリング面の支援、リスク管理の専門人材の確保、経営陣の賛同などの観点から、自社が内製化に取り組む準備ができているかを判断する方法 プロダクトマネージャー、DevOpsエンジニア、バックエンドエンジニアを兼務するアナリストが、保守の罠に陥る理由 次のような方におすすめのエピソードです： 不正対策やリスク管理チームを率いており、何を内製し、何を引き続き外部から調達するかを検討している方 ベンダーとの付き合いに疲れを感じ、どの取引関係を維持する価値があるのか、より明確な基準で考えたい方 AIを活用して社内で何かを開発し、それが規模の拡大に対応できるか知りたい 短期間の概念実証にとどまらず、開発ロードマップに何が必要かを経営陣に説明する必要がある 基盤モデルや意思決定モデルが、特徴量レイヤーやベンダーデータをどのように変える可能性があるのかを知りたい ### エピソードの概要と重要なポイント ベンダー疲れがチームの内製化を後押し Netanelは、業界のさまざまなチームから同じ話を聞いています。誰もが自社開発へのプレッシャーを感じており、それはAIモデルが実務をこなせるようになるずっと前から始まっていました。今ではAIモデルにその能力が備わり、ベンダー疲れと実現可能性が結びついています。彼が見てきた中で最も成功している自社開発の事例は、有能なチームメンバーが作業時間を短縮するツールを作るといった、小規模なものです。長年、ベンダーは判断や保証、スコアを完成されたパッケージとして提供してきました。チームには、それ以外のものを使いこなす専門知識や余力がなかったからです。今ではチーム側が、もっと細かな単位でも扱えると考え、カスタマイズ可能な部品を求めています。私の見方では、ベンダーは今後ますますデータ提供者として捉えられるようになる一方、負荷の大きいリアルタイム処理のエンジニアリングは、引き続きベンダーが担うことになるでしょう。両者の関係は変化しており、その姿は業界ごとに異なるものになるはずです。 ビューアーの構築は容易だが、ルールエンジンはそうではない Netanelは、情報を表示するビューアーと、実際のアクションにつながる製品を区別しています。手動レビュー用の操作画面を作るのは簡単な部分です。AIによるコーディングで容易にカスタマイズできるうえ、チームはベンダーが変更対応の優先順位を上げてくれるのを待つことにうんざりしているからです。一方、ルールエンジンの構築は別の仕事です。リアルタイム性能、高可用性、効率的なデータアクセス、そしてテストとシミュレーションが求められるバックエンドエンジニアリングです。Simplexでは、当初からPythonでルールエンジンを構築していたため、チームは戦略を自動的に切り替えることができました。多くのチームは、決済を審査するために複数のソースからデータを集めるなど、手作業の分析から着手します。ベンダーのアルゴリズムを丸ごと置き換えたいと考えるチームはほとんどありません。彼はまた、私にも心当たりのあるリスクとして、AIが粗製乱造する低品質な成果物、いわゆる「AIスロップ」を挙げました。新たな不正の問題に直面したチームは、一晩で20個のモデルをリリースできてしまいます。その結果、レイテンシやドリフトの監視が、誰も想定していなかった課題になるのです。 基盤モデルが変えるのは特徴量のレイヤーであり、業務全体ではない 私はNetanelに、基盤モデルはベンダーにとって脅威になるのかと尋ねた。ベンダーが競争優位を築いてきた、手作業で設計する特徴量のレイヤーを置き換えてしまうからだ。彼は、標準的なLLMがすでにその作業の多くを担うようになったと考えている。データセットからどのような特徴量を抽出すべきかLLMに尋ねれば、専門家チームが生み出すものの約80％は得られるというのが彼の見立てだ。彼は、基盤モデルの真の価値は高度な異常検知にあると見ている。私は、これまでに見た中で最も優れた成果は、過去の履歴がある既知の対象に関するものだったと付け加えた。より大きな変化をもたらすのは、必ず何らかの決定を下す必要があり、その判断にLLMを用いる半決定論的な意思決定モデルかもしれない。こうしたモデルは、外部データ、ネットワークデータ、特徴量ストアの価値を高める。彼が使った料理人のたとえが、私の心に残った。食材がそろっていることと、料理が予想より早く煮立ったときや、シミュレーションに含まれていなかった攻撃が起きたときにどう対処すべきかを知っていることは、別なのだ。 ターゲット層のニーズが満たされていない領域で開発する Netanelの最初のアドバイスは、セグメンテーションについて考えることです。新規ユーザーとリピーター、地域、商品、決済方法によって、その傾向は大きく異なります。成果が出ていない領域や採算性の低い領域を探し、別のベンダー、AI、独自のソリューション、新たな人材の採用など、何かを試してみましょう。私からも付け加えるなら、こうした領域こそ内製化が最も効果を発揮するところです。規模の大きな企業には、どのベンダーにも対応できない、その企業特有のセグメントがあるはずです。盗難カードへの対策はそれに当たりません。制裁対象者のスクリーニングやKYC（本人確認）も同様です。そこに時間を費やすのは、陥りがちな落とし穴です。2つ目のアドバイスは、自社の事業にとってリスク管理がどれほど中核的なものかを問うことです。そのうえで、過去6〜12か月のロードマップを振り返り、リスク管理の仕組みが障壁となって遅れた施策がいくつあったかを数えてみてください。内製するなら、意思決定を最小単位の要素に分解し、それぞれを自社で開発するか、外部から調達するかを判断しましょう。 準備態勢とメンテナンスの落とし穴 Netanelは、リスク管理部門の責任者の多くが自分のチームを厚く信頼しているものの、それが盲点になり得ると述べました。彼が勧めるのは、組織の体制を見極めることです。必要なエンジニアリング能力はあるか。投資を回収するまでに先行コストがかかるプロジェクトを経営幹部は支援してくれるか。リスク管理の人材を継続的に確保できるか。私はそこに、チームが最も見落としがちな点を付け加えました。作るのは簡単で、行き詰まるのは保守の段階です。アナリストが、自分のツールのプロダクトマネージャー、DevOpsエンジニア、バックエンドエンジニア、UXエンジニアをすべて兼ねる羽目になることもあります。それでもアナリストとしての仕事がなくなるわけではありません。結果として、プロジェクトの保守が止まってしまうのです。経営陣の理解と支持を得るには、2日で概念実証を作るのとは別のスキルが必要です。リスク管理チームも、内製化の落とし穴とは無縁ではありません。 ### 最後のまとめ 不正対策を内製するか、ベンダーのソリューションを購入するかは、単純にイエスかノーで答えられる問題ではありません。意思決定基盤のどの部分を自社で保有すべきか、どの部分は外部から購入したほうがよいかという問題です。これをうまく進めるチームは、まず自社のセグメントを見極め、内製したものの保守コストを見積もり、コードを一行書く前に経営陣との認識をそろえます。今回の対話は、確信よりも問いを多く残して終わりました。これほど速く変化し続けているテーマには、それがふさわしいと思います。 参考資料とリンク 私の、そして願わくば皆さんの大好きなテーマについて、もっと語り合いたいですか？ニュースレター「サタデー・フラウド・ストラテジスト」にぜひご登録ください。 つながりましょう：Netanel Kabala | LinkedIn Duly共同創業者 つながりましょう：Chen Zamir | LinkedIn 「The Saturday Fraud Strategist」ホスト フィンテック企業による、よりスマートな不正対策の構築を支援 『不正対策担当者のためのAI実践ガイド』共著者