モンゴDB The Six Five Summit：AI Unleashed 2026

お招きいただきありがとうございます。エンタープライズのデータアーキテクチャが、AIの急速な進歩に伴ってどう変わる必要があるのか、お話しできるのを楽しみにしています。どのモデルを使うかという話から、モデルを本番環境で使うために必要な、信頼できるコンテキストへと、議論の焦点が移ってきました。

いい質問ですね、Jason。振り返ってみると、MongoDBは、アプリケーションを素早く直感的に構築できることから、開発者に愛されるデータベースとして始まりました。市場で本当に変わったのは、ソフトウェアそのものが変化していることです。静的で決定論的なコードから、状況を認識し、その場で推論して行動する自律型AIエージェントへと移行しています。生成AIが最初に急速に広がったとき、多くのチームは単体のベクトルデータベースを従来の技術スタックに組み込もうとしました。ほどなくして、データ同期の問題やレイテンシが発生し、運用上の悪夢となりました。組織は、本番環境でAIを稼働させるには、ベクトルデータは一か所、業務データは別の場所、セキュリティルールはさらに別の場所という状態ではいけないと気づきました。統合されたプラットフォームが必要です。重要なのはAIを稼働させることだけではなく、ソフトウェアの構築方法がどう変わっているかです。

Emergent Labsは、ここで柔軟性が重要な理由を示す好例です。同社は当社のお客様の一社です。同社はまずPostgresを試しましたが、エージェントがアプリケーションを構築する際にはデータモデルが絶えず変化するため、MongoDB Atlasを選びました。Atlasでは、何かが変わるたびに移行を実行するよう強いられるのではなく、アプリケーションと並行してスキーマを進化させられます。そのため、同社はMongoDB上で約200万件のエージェント型アプリケーションを稼働させることができています。

そうですね。基盤モデルは、非常に優れた推論エンジンで、エンジニアリングの世界のアインシュタインのような存在だと考えています。しかしコンテキストがなければ、自社の実際のビジネスについては何一つ知りません。良いコンテキストの定義は、とてもシンプルです。リアルタイムの業務シグナル、過去の記録、明示的なビジネスルールをまとめ、AIが信頼できる形で一体として利用できるようにすることです。こうしたモデルに業務上のコンテキストを与えず、生のテキストだけを入力すると、単に根拠に基づいて推測しているにすぎません。しかし、実際のコンテキストを与えれば、賢明な判断を下せるようになります。当社のもう一社のお客様であるAT&Tは、その好例です。同社はリアルタイムのネットワークシグナルと過去の障害データをまとめています。それらを統合することで、AIが修理要員を実際にどこへ派遣すべきか、より適切に判断できるようにしています。それは物理的な影響を伴います。実際のビジネスインパクトです。

同社の場合、不要な派遣を310万件回避し、ダウンタイムを1,200万ドル分削減しました。―すごいですね。

エージェントが現場要員を派遣したり、請求システムにアクセスしたりする場合、誤ったコンテキストは単なる不便や軽微なハルシネーションでは済みません。甚大な金銭的影響をもたらします。

そうですね。エージェント型アプリケーションは誰もが構築している、と私はよく言っています。しかし、エージェントの賢さは、アクセスできるコンテキストの範囲で決まります。

つまり、メモリのないエージェントは、結局のところ高価なチャットボットにすぎません。

一般知識などについて話しているのですね。それでは会話の流れを保てず、学習もできません。エージェントには今、複雑な複数段階のプロセスに対応することが求められています。メモリがなければ、それはできません。状態やメモリについて話すとき、エージェントが継続性を保つ能力について話しています。3ステップ前に何が起きたかを覚えておき、ユーザーが何を達成しようとしていたかを把握し、そのユーザーの好みを時間とともに記憶しておくことです。3日かかり、5種類の承認が必要なプロセスをエージェントに処理させるなら、途中で取りこぼすことなく、その状態を保持しなければなりません。しかし、それを大規模に実現するのは、非常に大きなデータの課題です。これはまさに中核となるデータの課題です。