Atlas Agent Engine が MongoDB の社内 AI 戦略を支える仕組み

私は25年以上テクノロジー業界に身を置いてきたため、新しい技術に驚くことはめったにありません。たいていの場合、一般の人々が目にするよりも早く、間近で目にすることができるからです。IT リーダーとして、新しい機能を単独で評価することは決してありません。常に、実際のエンタープライズのユースケースと、それに伴うリスクを踏まえて判断します。最近では、AI 時代の CIO とは、堤防を補強するエンジニアと、それでも洪水門を開かなければならないオペレーターの2つの役割を同時に担うことだと人々に話しています。

今週、MongoDB は Atlas Agent Engine のパブリックプレビューを発表しました。これがお客様にもたらす可能性について、これ以上ないほど期待を寄せています。Atlas Agent Engine は、本番環境で AI エージェントをビルド、デプロイ、ガバナンスするための安全な方法を提供します。組み込みのメモリと検索機能を備えた Atlas Agent Engine は、企業データが存在する場所でインデックスを作成し、リアルタイムで正確なコンテキストを提供することで、精度を向上させながらトークンコストを削減します。また、設計段階からオープンで柔軟性があるため、チームは任意の LLM やフレームワークを使用してビルドできます（近日中に任意の環境でも可能になります）。

お客様からはすでに、Atlas Agent Engine が自社のビジネスにもたらす可能性に大きな期待を寄せていただいています。例えば、Paysafe は MongoDB Atlas を使用して、トランザクションデータに対する自然言語から SQL へのクエリを実行するエージェント型システムを強化しています。これは、Paysafe が今後のユースケース向けのテンプレートとしてビルドを計画している、一連の再利用可能なワークフローパイプラインの第1弾です。

現在、同社の Snowflake MCP セットアップでは、API クライアントは根底にあるデータスキーマについて限定的な理解しか得られません。MongoDB Atlas の柔軟なドキュメントアーキテクチャと信頼性の高い拡張性は、そのセットアップを、API クライアントが自然言語で直接クエリを実行でき、より高機能で再利用可能なパイプラインへと置き換えるように設計されたエージェントをサポートします。

「現在、決済ネットワークにおける異常なアクティビティの調査とは、アナリストが時間のプレッシャーを受けながら、複数のシステムからのデータを手作業でつなぎ合わせることを意味します」と、Paysafe のペイメントエンジニアリング担当 SVP である Jana Janarthanan 氏は述べています。「MongoDB の Atlas Agent Engine 上に構築されたインテリジェントエージェントが、問題の発生からチームが対応するまでの時間を短縮し、アナリストが最も重要な判断により多くの時間を割けるようになる可能性に大いに期待しています。」

MongoDB チームが初めて Atlas Agent Engine を見せてくれたとき、「設計段階から安全性とガバナンスを確保」というフレーズがすぐに注意を引きました。なぜなら、夜も眠れない理由があるとすれば、それは MongoDB（またはお客様）のシステムでエージェントが暴走することだからです。

エージェントのガバナンスは、私だけの懸念事項ではありません。これはニュースでも取り上げられており、業界全体の CIO が取り組んでいる課題です。同業者との会話のたびに同じことを実感します。エンタープライズ全体でエージェントの需要は増え続けていますが、IT リーダーには、単に迅速にではなく、安全かつセキュアにエージェントをデプロイする方法が必要です。

本質的には、これは集中化と分散化の対立をめぐる話です。開発者は最小限の摩擦でエージェントを迅速にリリースできる自律性を求める一方、IT リーダーは、大規模に運用するエージェントの動作に対する一元的な制御、可視性、コスト最適化の手段を求めています。これを適切に実現する組織は、両方を実現するアーキテクチャを構築できます。

ソフトウェアはますますヘッドレス化し、エージェント主導になっており、CIO には今すぐ選択肢が必要です。言い換えれば、未来はすでにここにあり、それを責任を持って形作ることが私たちの役割です。

カスタマーゼロ：社内における AI 戦略の実践

MongoDB では、その実現方法の一つとして、自社製品にとって最初のカスタマーとなることを実践しています。業界ではこの慣行に「ドッグフーディング」や「自社製品を自社で試す」などさまざまな呼び名がありますが、意味は同じです。製品をリリースする前に、実際のユースケースや状況を用いて本番環境でソフトウェアをテストするために、自社が顧客となります。

例えば、当社が2024年に MongoDB 8.0 をリリースした際、8.0がチームのパフォーマンスをどれほど向上させたかについて、同僚の Jim Scharf がブログ記事を執筆しました。

Atlas Agent Engine を活用した当社のドッグフーディングは、Holly という形で結実しました。これは、MongoDB の営業担当者が7つものツールを行き来する代わりに、必要なものすべてを1か所で完結できる統合エージェント型ワークスペースです。Holly の導入前は、1つのアカウントの準備をするために互いにコンテキストを共有していない7つの分断されたツール間を行き来する必要があり、商談サイクルごとにアカウントあたり4～6時間が純粋な「ツールのオーバーヘッド」として浪費されていました。Holly はその状況に終止符を打ちます。7つのツールが1つのエージェント型エクスペリエンスに統合され、営業担当者はそうして取り戻した時間を、真に重要な場所であるお客様との対話にかけることができます。

Holly：数時間の作業を数分に短縮

MongoDB の GTM チームは、お客様の現在の状態、目標、そしてそれを達成するために何が必要かを理解するために、標準化されたステップ別の手法に従っています。担当者はこれを「スポーク」と呼んでいますが、手早く済むものではありません。MongoDB の戦略アカウントエグゼクティブである Jack Bunkenburg によると、スポークには毎週1～2日が費やされています。

問題はプロセスではなく、ツールにありました。担当者が必要としていたのは、参照するデータの全体像を理解し、これまで互いに連携したことのなかったシステム間でコンテキストを引き継ぐことができる1つのツールであり、

それがないと、7つの異なるツールにまたがってアカウントに対応することは、1つの症状に対して 7 人の専門医に診てもらい、他の医師の所見を誰も把握できていないようなものになります。受診のたびに一からやり直しとなり、症状や病歴、前の医師がすでに把握した内容を再度説明することになります。それぞれの専門医は優秀かもしれませんがコンテキストが引き継がれないため、システムは期待どおりに機能しません。手間だけがかかります。

構築を開始する前に、チームは実際の業務がどのように行われているかを観察しました。そして現場の実態は、Bunkenburg の言葉を借りれば、書面上のプロセスよりも「かなり煩雑」なものでした。アカウント調査だけでも、お互いや MongoDB のシステムとコンテキストを共有せず、画一的でありきたりな回答しか返さない複数の AI ツール（ChatGPT、Claude、Gemini）を使い分ける必要がありました。プルーフポイントを見つける作業も、結果を本当に重要なものだけに絞り込む作業も同様に手作業でした。

Holly こそが解決策であり、ほかのツールにはなかった共有コンテキストを提供します。営業担当者が調査、準備、実行に必要なすべてを集約する、1つのインターフェース。ツールの切り替えは不要です。その基盤となる Atlas Agent Engine が、ランタイム、セキュリティ、ID、オーケストレーション、状態管理、オブザーバビリティ、ライフサイクル管理といった負荷の大きい処理を担うため、Holly のエージェントは単なるデモではなく本番環境で実行されます。

図 1. Holly のエージェントアーキテクチャー。

実際には、Holly は会議のトランスクリプトをキュレーションして要約し、概要を下書きし、営業担当者がまだ回答していない質問を浮き彫りにし、アウトリーチの作成を支援します。その結果、Holly を使用する営業担当者は、アウトバウンドの見込み顧客リストの調査と作成にかかる時間を約95％削減し、以前は数時間かかっていた準備を数分で完了できるようになりました。これにより、営業担当者のスピードが単に改善されるだけでなく、より万全の準備を整えてすべての会話に臨めるようになります。

「Holly の導入前は、リサーチやアウトリーチのために十数種類ものツールを使い分けていましたが、すべてが単一のインターフェースに集約されたことは、非常に大きな価値をもたらしています」と Bunkenburg は述べています。「多くのツールは MongoDB のビジネスモデルや、私たちがそれらのツールを使って具体的に何を達成しようとしているのかを理解していませんが、Holly はそれを正確に理解しています。」

AI 時代のインテリジェントデータプラットフォーム

今後は、Holly が MongoDB、お客様、個別のアカウントを深く理解する完全に統合されたインテリジェンスレイヤーとなり、GTM 組織全体がエンドツーエンドのワークフローをより効果的に実行できるよう支援することを目指しています。

最も期待が高まるのは、Holly そのものの背後にある仕組みです。Holly は現在約30個のエージェントで稼働しており、すべて同じ Atlas Agent Engine アーキテクチャ上に構築されています。このアーキテクチャはエージェントを追加しても不安定になることはなく、30個を実行している場合でも3,000個を実行している場合でも安定性を維持できるように設計されています。私たちは単に自社の GTM チーム向けのツールを構築しただけではありません。組織が新しいエージェントを追加するたびにリスクが蓄積していくのではなく、安全にスケールできるブループリントの実効性を証明しました。

これこそが Atlas Agent Engine がもたらす変革です。単一のクラウド、モデル、フレームワークに縛られることなく、単発のエージェント構築から統制された再利用可能なプラットフォームへの移行を実現します。それは、実行するエージェントの数にかかわらず、エージェントが期待通りに動くことを祈るのか、確実に動作すると確信を持てるのかという決定的な違いです。

Atlas Agent Engine の提供開始は、MongoDB 9.0 や Atlas Infinite と並び、今週 MongoDB が行った3つの主要な発表の1つです。これらの製品は互いを基盤としています。MongoDB 9.0 はすべての MongoDB のお客様がすでに稼働させている基盤を強化し、Atlas Infinite はその基盤をスケーリングする際の上限を取り除き、Atlas Agent Engine はリアルタイムデータに基づきガバナンスされた AI エージェントをその両方の上で動作させます。

開発者が常に MongoDB を選んできた理由は、そのドキュメントモデルがアプリケーションデータの自然な構造や、AI システムによる情報の表現および交換の方法に適合しているためです。これにより、アプリケーションをより迅速に構築し、より容易に適応させることができます。企業が MongoDB を選択するケースが増加している理由は、そのネイティブな適合性と、リアルタイムの運用データ、柔軟なスケーラビリティ、どこでも実行可能な自由、そして今日のエージェント時代のために専用設計されたプラットフォームが融合されているためです。

単一のプラットフォーム。任意の数のエージェント。MongoDB のインテリジェントデータプラットフォームにより、データがすでに存在する場所でビルド、デプロイ、実行できます。