詳細を読む
フィンテック企業のBrexは、カンファレンス「VB Transform 2026」で、AIエージェントを本番環境へ安全に組み込む独自手法を明らかにしました。CEOのペドロ・フランチェスキ氏によると、同社はコンテナ内で動くコードを制御する従来型の防御を諦め、コンテナと外部を流れる通信を監視する方式へ切り替えたといいます。エージェントの価値の源泉であるコード実行能力を殺さずに統制を効かせるためです。
発端は、コーディングモデルの成熟を受けて1月に公開されたオープンソースのAIエージェント「OpenClaw」でした。エージェントが固定的なツールに頼らず自らコードを書いて自己更新できるようになったことから、フランチェスキ氏は社内業務の自動化への投入を提案します。しかし社内のセキュリティ担当は「コード実行能力を持つものを信頼できるはずがなく、制御する方法もない」と、これを真っ向から拒みました。
そこで生まれたのが、Brexが自ら開発してオープンソースとして公開したHTTPプロキシCrabTrapです。この仕組みは、エージェントが何でもでき、すでに侵害されているかもしれないと想定したうえで、コンテナとインターネットの間の全通信を受け止め、その内容が承認済みポリシーに沿うかをLLMに判定させます。フランチェスキ氏は、ツール利用を絞って守るNvidiaのNemoClawのような方式は、エージェントの強みであるコーディング能力を打ち消してしまうと指摘しました。
課題は速度でした。全リクエストをLLMに通せば数千ミリ秒の遅延が乗るため、Brexは処理を二層に分けています。LinkedInのプロフィール閲覧のような低リスクな行為は事前承認の静的ルールで即座に通し、メール送信などの高リスクな行為だけをLLM審査へ回すことで、遅延を被る複雑なリクエストは全体の約2%にとどまるといいます。
実証の場となったのが、OpenClaw上に構築した仮想リクルーター「Jim」です。候補者の探索から応募者の採点、メール送信までこなすJimがポリシー外の動きをすると、CrabTrapはSlackで人間の管理者に通知し、エージェントの意図の説明とルール変更案を添えて可否を尋ねます。壁にぶつかった従業員が上司にエスカレーションする、という会社では解決済みの作法をそのまま持ち込んだ形です。
興味深いのは、LLMが審判役として想定以上に機能した点です。フランチェスキ氏はその理由を、モデルが事前学習で膨大なWebページとHTTPリクエストに触れ、通信の意味を自然に理解しているからだと説明します。「作った時点で、半年後に捨てる確率は70%だと思っていた」と内製の割り切りを認めつつ、答えを全部持っていなくても何もしないという選択肢はない、というのが経営層への示唆です。