powered by TechFeed
表示モード
Deep Dive

1日数十億件のメールをAIエージェントで捌く — Abnormal AIがCode Interpreterをセキュリティ基盤に組み込んだ理由

9月15日、AWSが「Abnormal AI: Amazon Bedrock AgentCore for agentic email security at scale」と題した記事を公開した。この記事では、Abnormal AIがAmazon Bedrock AgentCore Code Interpreterを活用し、1日数十億件規模のメールを処理するセキュリティエージェントを本番環境で稼働させた実装事例について詳しく紹介されている。

9月15日、AWSが「Abnormal AI: Amazon Bedrock AgentCore for agentic email security at scale」と題した記事を公開した。この記事では、Abnormal AIがAmazon Bedrock AgentCore Code Interpreterを活用し、1日数十億件規模のメールを処理するセキュリティエージェントを本番環境で稼働させた実装事例について詳しく紹介されている。


LLMだけでは足りない——エージェントに「計算の作業台」が必要な理由

AIエージェントが実務で使われ始めると、ある共通の課題が浮上してきた。LLM(大規模言語モデル)は推論や文章生成には長けているが、次のような処理には本質的に弱い。

  • 数値計算・カウント:「過去1時間で検知したフィッシングメールは何件か?」
  • データ加工・可視化:生データをグラフやPDFに変換する
  • コードの検証:自分が生成したコードが正しく動くかユニットテストで確認する

こうした「言語生成ではなく計算が必要な処理」を担うのが、Amazon Bedrock AgentCore の一機能である Code Interpreter だ。AgentCoreはAWSが提供するエージェント基盤サービスであり、Code InterpreterはそのAgentCoreが提供するコード実行コンポーネントとして位置づけられている。エージェントがAPIを呼び出すと、エフェメラル(使い捨て)なMicroVMサンドボックスが起動し、コードを動的に実行して結果を返す。セッションは最短15分から最長8時間まで設定可能で、PythonとNode.jsのランタイムが事前に用意されている。


Abnormal AIの実装:3層構造で1日数十億件をさばく

Abnormal AIはFortune 500の25%超を顧客に持つメールセキュリティ企業で、このCode Interpreterをリアルタイムのメール脅威検知パイプラインに組み込んでいる。

処理は3層に分かれている。以下の各Tierの処理件数は元記事に記載されている数値だ。

Tier 1 — 軽量分類(1日数十億件規模)
ヒューリスティックルールとロジスティック回帰などの軽量モデルで大量のメールを捌く。コストと速度の観点から、大きなモデルは使わない。

Tier 2 — 機械学習モデル(1日数百万件規模)
Tier 1が判定できなかったメールを深層学習モデルで行動シグナル分析にかける。

Tier 3 — インラインエージェント(1日数万件規模)
最も難しいケース——従来なら人間のアナリストが判定していた案件——をAIエージェントが処理する。エージェントは脅威インテリジェンスデータをサンドボックスに渡し、動的にスクリプトを書いて分析を実行。最終的に脅威の有無を判定する。Code Interpreterが使われるのはここだ。

この構造の要点は、エージェント計算を「最も難しいケースにだけ使う」設計にある。全件にエージェントを使えばコストが爆発するが、Tier 1・2でほとんどを振り分けることで現実的なスケールを実現している。


バッチ処理でモデル自体を自動改善する「アナリストエージェント」

リアルタイム検知とは別に、Abnormal AIは週約100件のバッチジョブを処理する「アナリストエージェント」も運用している。

このエージェントは誤分類のデータを取り込み、パターンを分析して、Tier 1向けの新しいヒューリスティックルールの草案を自律的に書く。バッチジョブは30分以上かかることもあり、長時間のモデルトレーニングを挟む場合は次のパターンを使う。

  1. Code Interpreterで前処理を実行
  2. 中間状態をファイルシステムに保存(チェックポイント)
  3. 外部でモデルトレーニング(数時間規模)
  4. 再度Code Interpreterを呼び出して結果を処理

セッションをまたぐ長時間処理を、ファイルシステムを「回復ポイント」として活用することで実現している。


ゼロトラスト設計:サンドボックスをあえてネットワーク遮断

Abnormal AIはCode Interpreterの設定で外部ネットワークへのアクセスを遮断するサンドボックスモードを選んだ。理由は2つだ。

  1. 再現性:外部ネットワークが遮断されていれば、Abnormal AIの管理外の要素がエージェントの挙動に影響を与えられない。環境が決定論的になる。
  2. データ漏洩防止:脅威インテリジェンスデータをサンドボックスに渡して分析するため、プロンプトインジェクションや確率的な挙動でエージェントが不正な動作をしても、データがインターネットに流出しない設計になっている。

本番運用から得た教訓

記事では、実運用から得た実践的な知見として以下をまとめている。

  • エージェントに裁量を与える:細かいステップを指示するより、高レベルの原則だけ渡してエージェントに判断させた方がパフォーマンスが上がる。
  • 全エージェントに「作業台」が必要:コードを書くエージェントだけでなく、セキュリティ分析エージェントもデータ集計や検証のために計算サンドボックスが必要になる。
  • プログラムによる検証をガードレールとして使う:ユニットテストやlintingをサンドボックス内でエージェント自身が実行できるようにすると、アウトプットの品質が上がる。

Abnormal AIのVP of AI Strategy、Shrivu Shankar氏は次のように述べている。

「コードを書くかどうかに関わらず、ほぼすべてのエージェントは、データを実際に計算して答えを出せるコードインタープリターのサンドボックスを必要としている」

なお、元記事によれば、Abnormal AI社内では現在、コード変更の80%が何らかのエージェントを介して構築されており、40%はバックグラウンドエージェントによるエンドツーエンドの自律生成(AIによる補助ではなく、AIによる構築)だという。これらは同社が公開した社内指標として紹介されている数値だ。


詳細はAbnormal AI: Amazon Bedrock AgentCore for agentic email security at scaleを参照していただきたい。