メールを配送する前に脅威を判定する仕組みでは、詳しく調べるほど処理時間や計算資源が必要になります。AIエージェントに分析を任せる場合も、「どこまで調べるか」と「どこでコードを動かすか」は一緒に考えたいところです。

2026年9月14日に公開されたAbnormal AIの導入事例は、その設計を考える手がかりになります。同社はメール検知を支えるエージェントに、Amazon Bedrock AgentCore Code Interpreterを計算用の一時環境として組み込んでいます。

なぜ大規模な検知基盤に、この小さな作業場所が役立つのでしょうか。処理対象の絞り方から、コードに与える権限、長時間処理の区切り方まで追うと、本番で任せられる範囲が見えてきます。

難しいメールだけをエージェントへ送る三段階の検知

Abnormal AIの構成は、前の段階で判断に十分な確信が持てなかったメールを、次の段階へ渡します。公表された各段階の処理規模は次のとおりです。

段階	主な処理	1日あたりの規模
Tier 1	ヒューリスティック、軽量なモデルや分類器	数十億件
Tier 2	深層学習・機械学習による行動シグナルの分析	数百万件
Tier 3	Code Interpreterを使うインラインエージェント	数万件

エージェントが担当するのは、最も判断の難しいケースです。脅威インテリジェンスを受け取り、動的にスクリプトを書いて分析し、行動モデルと照らし合わせて判定します。これらは顧客事例として示された規模であり、Code Interpreter単体の性能保証ではありません。Abnormal AIの導入事例

この振り分けから、計算資源を見積もるときはメール総数に加えて、後段へ進む件数を見る必要があると分かります。自社で同様の構成を検討するなら、エージェントへ渡す割合と、そこで追加される待ち時間を測るのが出発点ですね。

Code Interpreterで言語による判断に実際の計算を加える

Code Interpreterは、エージェントが生成したコードを実行し、結果を受け取るためのマネージド環境です。Python、JavaScript、TypeScriptを利用でき、データの集計や変換などをプログラムとして処理できます。Code Interpreterの公式ガイド

たとえば、分析対象のデータから件数を集計する場面では、自然言語の回答を作るだけでは集計処理を実行したことにはなりません。コードを実行すれば、計算結果やエラーを次の判断へ渡せます。ただし、入力データや集計条件が正しいかどうかは、別に検証する必要があります。

ここで使う実行単位がセッションです。各セッションにはCPU、メモリ、ファイルシステムを隔離した専用のmicroVMが割り当てられます。同じセッションの中で状態を使いながら計算を進められるため、エージェントの作業場所として扱えます。セッションの分離仕様

「計算できること」と「計算結果を採用できること」は、設計上それぞれ判断したい点です。実行環境ができたら、次はそこへ何を渡し、どこへアクセスさせるかを決めます。

Sandboxの選択とS3権限を一緒に設計する

Abnormal AIは、インターネットへのデータ流出を防ぐことと、実行中の外部要因を減らすことを狙い、外向き通信を許さない構成を選んでいます。入力するデータや、許可する書き込み操作も制御しています。この説明は同社の構成を指します。

一方、現在のネットワーク設定の公式仕様では、Sandboxモードでもデータ操作のためのAmazon S3アクセスが可能です。Publicモードは公開インターネットへ、VPCモードは設定したVPC内のリソースへ接続する用途を持ちます。

したがって、Sandboxという名前だけで通信先が一切ないと判断するのは避けたいところです。導入時はネットワークモードに加え、実行ロールがアクセスできるS3の範囲や、書き込みを許す保存先まで具体化します。通信経路と権限を組み合わせて、データが出入りできる範囲を決めるわけです。

また、外部との通信を制限しても、プロンプトインジェクションによる誤った分析まで自動的に防げるとは限りません。隔離はコードの行動範囲を狭める仕組みであり、判定内容の検証も引き続き必要です。

長時間の分析はセッションの期限で区切る

リアルタイムの判定とは別に、Abnormal AIは誤分類などのシグナルを分析し、前段の検知改善につなげるバッチ型のエージェントも運用しています。長時間のモデル学習は外部で行い、その前後でCode Interpreterを使う構成が紹介されています。

ここで区別したいのが、業務全体の所要時間と、1回のセッションの寿命です。sessionTimeoutSecondsは既定で900秒、最大28,800秒です。処理が続いていても指定時間で終了するため、操作するたびに期限が延びるアイドルタイムアウトとしては扱えません。StartCodeInterpreterSession API仕様

そのため、長い処理では、再開に必要な状態をセッション外へ取り出す設計が必要になります。セッション内のローカルファイルへ書くだけで、終了後の新しいセッションから使えるとは考えないようにします。保存先と復元手順を決めたうえで、外部処理の結果を次の計算へ渡す流れです。

稼働中の一時環境が終了することと、関連データの保持期間も別の論点です。公式のセッション管理ガイドにはセッションデータの30日間のTTLも記載されています。終了と同時に関連データがすべて消えるという前提で、機密データの保持方針を組み立てることはできません。

本番採用は判定品質と実行コストを並べて判断する

実行基盤の状態を見るには、セッション数、リクエストの遅延、スロットリング、エラーなどのCloudWatchメトリクスを利用できます。実行時の標準出力・標準エラーについては、CloudWatchの実行コンソールログを探すのではなく、各呼び出しの出力を扱う必要があります。Code Interpreterの監視仕様

費用もセッションの使い方に関係します。現行の料金説明では、CPUの実消費と、その秒までのピークメモリ使用量を基に秒単位で課金されます。CPUを消費しない待機時間でもメモリの課金を別に考える必要があるため、使い終わったセッションを停止する設計が効いてきます。

自社で評価するなら、基盤側の遅延やエラーに加えて、エージェントへ回した件数、誤分類、判定までの総時間を同じ評価期間で追うと判断しやすくなります。これは導入検証の提案です。今回の事例からは、検知精度の改善幅や遅延分布、1件あたりの費用までは確認できません。

最初の問いへの答えは、難しいケースに計算を使える余地を作り、その実行範囲を運用側で定めることにあります。三段階の振り分けで対象を絞り、通信と権限でデータの境界を決め、セッションの期限で処理を区切る。そのうえで判定品質と費用を測ることが、エージェントの計算能力を本番の設計へ落とし込む道筋になります。

出典

• Title: Abnormal AI: Amazon Bedrock AgentCore for agentic email security at scale
• URL: https://aws.amazon.com/blogs/machine-learning/abnormal-ai-amazon-bedrock-agentcore-for-agentic-email-security-at-scale/