AIエージェントを試すとき、回答が合っているかだけを見ていると、前回の状態をどこまで引き継いだか、誰の権限で操作したか、失敗後に何が残ったかを見落とします。MongoDBが2026年9月29日に発表したAtlas Agent Engineを題材に、この3点を分けて確認する方法を整理します。
11月3日確認：公開プレビュー。公式ドキュメントは本番ワークロードを非推奨とし、可用性のSLA・SLOは提供していません。 本稿は公式資料を読んだ設計メモです。製品の導入・実行・性能測定はしていません。
1. 記憶、実行、統制を別々に見る
公式資料では、セッション状態と長期記憶を扱う機能、エージェントを動かす実行環境、IDやポリシーを扱う統制が説明されています。記憶に保存できたことと、次の実行で正しく参照できたことは別です。架空の問い合わせを使い、前回の担当者メモが引き継がれ、別の顧客のメモが混ざらないかを確認します。
2. 誰が何を許可したかを、結果とは別に残す
例えば「問い合わせを読めるが送信できない」テスト用の役割を用意します。入力は架空データに限定し、読み取りが通り、送信操作が拒否されることを、応答文と操作先の記録の両方で見ます。モデルが「送りませんでした」と答えるだけでは、外部操作が起きていない証拠にはなりません。
3. 中断と再開を先に試す
| 模擬ケース | 見るもの | 合格条件の例 |
|---|---|---|
| 同じ受付IDが二度届く | 作成物の件数 | 下書きが1件だけ残る |
| 下書き保存の直後に中断 | 保存状態と送信履歴 | 再開時に保存済みと判定し、勝手に送信しない |
| 閲覧のみの役割で更新を要求 | 拒否記録と更新先 | 拒否が記録され、更新先の状態が変わらない |
これは導入前に使える試験案で、Atlasでの実測や機能保証ではありません。まず表の1行を、自分の業務で使う架空データに置き換えると、何をもって「動いた」とするかが明確になります。
出典
問い合わせ返信の下書きなど、文章業務1種類についてAIの入力と人の確認手順を整理したい場合は、実務プロンプトと運用手順マニュアルの相談も利用できます。製品導入やAPI実装のサービスではありません。