Azure Cosmos DB Blogで2026年6月22日に公開された「How to Use Deep Agents with Azure Cosmos DB – Plan, act, and verify against operational data」は、Azure Cosmos DBの破壊的変更や強制移行を知らせるものではなく、Deep Agentsを使って運用データを「計画し、実行し、検証する」エージェント設計例を示したNoticeです。管理者がまず確認すべきなのは、新機能を有効化するかどうかではありません。AIエージェントにAzure Cosmos DB上の本番データを読ませる、更新させる、更新後に検証させる場合の権限設計、RU消費、監査ログ、承認フロー、利用者への周知です。
今回の発表では、サポートチケットのキューをAzure Cosmos DBに保存し、エージェントがチケットを読み取り、必要に応じて更新し、最後に読み戻して結果を確認する流れが紹介されています。つまり、Azure管理者にとっての論点は「Cosmos DBにAIをつなぐ方法」だけでなく、「AIが操作できる範囲をどこまで許すか」です。(Microsoft for Developers)
管理者が最初に押さえるべきポイント
今回の公式発表は、Azure Cosmos DBそのものの仕様変更というより、Azure Cosmos DBを運用データ基盤として使うAIエージェント構成の実装例です。発表内では、Deep Agentsが複数ステップの作業を進めるためのエージェント基盤として紹介され、Azure Cosmos DB上のサポートチケットを読み取り、必要な場合は更新し、その後に再読取で検証するサンプルが示されています。(Microsoft for Developers)
管理者は、次のように整理すると判断しやすくなります。
| 確認項目 | 管理者の判断 |
|---|---|
| 既存のAzure Cosmos DBにすぐ影響するか | 公式発表の内容だけで既存環境が自動変更されるものではない |
| 対応が必要な組織 | AIエージェントやLangChain、LangGraph、独自CopilotからCosmos DBを操作する予定がある組織 |
| 最優先で確認すること | エージェント用IDの権限、書き込み範囲、監査ログ、RU消費、承認プロセス |
| 移行作業の有無 | Cosmos DBのスキーマ移行やアカウント移行が必須という内容ではない |
| リスクが高い使い方 | 本番データへの広範な読み取り、複数レコードの一括更新、監査なしの自動更新 |
特に注意したいのは、AIエージェントを「便利な検索窓」としてだけ扱うと、実際にはデータ更新権限を持つ自動処理主体になってしまう点です。読み取り専用の分析用途と、チケットのステータス変更や担当者割り当てまで行う用途では、管理上のリスクが大きく異なります。
今回の発表で示されたDeep AgentsとAzure Cosmos DBの関係
公式発表のサンプルでは、サポートチケットをAzure Cosmos DBのアイテムとして保存し、エージェントがAzure Cosmos DB SDK経由で同じデータストアを読み書きします。サイドインデックスを別に作るのではなく、運用チームが使っているデータに直接アクセスする構成です。(Microsoft for Developers)
エージェントが行う操作は、大きく分けると次の4種類です。
| エージェントの処理 | Cosmos DB側の主な操作 | 管理者が見るべきポイント |
|---|---|---|
| チケットの優先度確認 | クロスパーティション検索、フィルター、並べ替え | RU消費、検索条件、取得項目の絞り込み |
| 特定チケットの確認 | パーティションキー付きのポイント読み取り | 低コストな読み取り経路を使えているか |
| チケット更新 | パッチ更新、履歴追加、更新日時の変更 | 書き込み権限、変更履歴、再試行時の影響 |
| 更新後の検証 | 更新済みアイテムの再読取 | 実行結果を確認してから利用者へ返す設計になっているか |
この構成の良い点は、エージェントが単発のLLM回答ではなく、必要なデータ操作を段階的に選びながら作業できることです。一方で、管理者から見ると「どのツールを呼べるか」「どのクエリを許すか」「どの項目を書き換えられるか」を明確に制限しなければなりません。
影響範囲：既存環境で確認すべきAzureリソース
今回のNoticeを受けて、すべてのAzure Cosmos DB利用者がすぐに設定変更する必要はありません。ただし、次のいずれかに当てはまる場合は、管理者レビューを行うべきです。
| 対象環境 | 確認の優先度 | 理由 |
|---|---|---|
| 本番のAzure Cosmos DBにAIエージェントを接続する予定がある | 高 | 読み取り・書き込み権限と監査設計が必要 |
| サポート、インシデント、注文、デバイスなどの運用データをCosmos DBに保存している | 高 | エージェントが業務状態を変更する可能性がある |
| LangChain、LangGraph、Deep Agents、独自AIアプリを検証中 | 中 | PoC段階でも本番キー流用を避ける必要がある |
| Cosmos DBを読み取り専用のRAG用途で使っている | 中 | 書き込み権限が付与されていないか確認すべき |
| Cosmos DBを通常のアプリDBとしてのみ使い、AI連携予定がない | 低 | 直接の対応は急がないが、将来の接続ルールを決めておくとよい |
管理者向けには、まず「AIアプリがどのCosmos DBアカウントに接続できるか」を棚卸しするのが現実的です。PoC環境で作成した接続文字列やキーが、そのまま本番アプリに残っているケースは珍しくありません。AIエージェントの検証を始める前に、接続方式と権限スコープを確認してください。
権限確認：エージェントにフルアクセスを渡さない
もっとも重要なのは、エージェント用のIDに必要以上の権限を与えないことです。Azure Cosmos DB for NoSQLでは、Microsoft Entra IDとネイティブのデータプレーンRBACを使って、データ操作に必要なロールを割り当てられます。Microsoft Learnでは、データプレーンRBACのロール定義やロール割り当てを作成し、スコープをアカウント全体、データベース、コンテナー単位で指定できることが説明されています。(Microsoft Learn)
読み取り専用エージェントと更新可能エージェントを分ける
管理者は、少なくとも次の2種類のIDを分けて設計するべきです。
| 用途 | 権限の考え方 | 例 |
|---|---|---|
| 分析・要約・検索用エージェント | 読み取り専用にする | チケット件数、滞留状況、障害傾向の確認 |
| 更新可能エージェント | 更新対象のコンテナーとフィールドを限定する | ステータス変更、担当者割り当て、タグ追加 |
避けたいのは、検証用に発行した接続文字列やアカウントキーを使い回し、エージェントが全コンテナーへ自由にアクセスできる状態です。AIエージェントは人間の代わりに複数ステップの操作を行えるため、権限が広すぎると、意図しない大量更新や機密データの過剰取得につながります。
確認すべき権限チェックリスト
Azure管理者は、次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| 接続方式 | アカウントキーや接続文字列ではなく、可能な範囲でMicrosoft Entra IDベースの認証を使う |
| ID分離 | アプリ本体、読み取り専用エージェント、更新可能エージェントのIDを分ける |
| スコープ | / のようなアカウント全体スコープを安易に使わず、データベースまたはコンテナー単位に絞る |
| 権限内容 | 読み取りのみでよい処理に書き込み権限を付けない |
| 本番・検証分離 | PoC用エージェントが本番Cosmos DBへ接続できないようにする |
| キー管理 | キーや接続文字列がGitHub、CI/CD変数、ローカル設定ファイルに残っていないか確認する |
特に更新可能エージェントでは、「Cosmos DBに書き込めるか」だけでなく、「どのフィールドを書き換えてよいか」までアプリケーション側で制御する必要があります。RBACだけで業務ロジック上の制限をすべて表現できるとは限らないため、ツール関数側で許可フィールドを固定する設計が有効です。
監査確認：エージェントの読み取り・更新を追跡できるようにする
AIエージェントを本番データに接続する場合、監査ログは後付けではなく導入前に設計してください。Azure Cosmos DBでは、診断設定によりリソースログを収集できます。データプレーンログには、読み取り、作成、更新、削除などのデータ操作が含まれると説明されています。(Microsoft Learn)
また、Azure MonitorのCDBDataPlaneRequestsテーブルは、Cosmos DBアカウントに対するデータプレーン操作を取得するログテーブルとして説明されています。(Microsoft Learn)
監査で見るべき具体的な観点
| 観点 | 確認例 |
|---|---|
| 誰が操作したか | エージェント用マネージドID、サービスプリンシパル、アプリIDを識別できるか |
| 何を読んだか | 対象アカウント、データベース、コンテナー、操作種別を確認できるか |
| 何を更新したか | 更新対象のチケットID、顧客ID、ステータス、担当者、タグなどをアプリ側履歴に残しているか |
| いつ操作したか | インシデント対応時に時系列で追えるか |
| なぜ操作したか | プロンプト、承認者、操作理由、エージェントの判断根拠を保存しているか |
| 異常を検知できるか | 短時間の大量読み取り、大量更新、RU急増を検知できるか |
Cosmos DBの診断ログだけでは、エージェントが「なぜその更新を行ったか」までは十分に説明できない場合があります。そのため、アプリケーション側にも監査用の履歴を持たせるのが安全です。公式発表のサンプルでも、チケット更新時に履歴配列へノートを追加し、更新後に読み戻して確認する流れが紹介されています。(Microsoft for Developers)
RU消費とパフォーマンス：AIエージェントはクエリ回数が増えやすい
Deep Agentsのような複数ステップ型のエージェントは、1回の質問に対して複数のCosmos DB操作を行う可能性があります。公式発表でも、キュー全体を調べる処理はクロスパーティションの作業量に応じてRUを消費するため、必要なフィールドだけを射影する設計が示されています。(Microsoft for Developers)
管理者は、通常アプリとは別に「AIエージェント利用時のRU消費」を測定してください。人間が自然文で「今朝見るべきチケットを教えて」と聞いただけでも、裏側では複数の検索、集計、読み取りが実行される場合があります。
RU消費を抑える設計ポイント
| 対策 | 効果 |
|---|---|
| パーティションキーを意識した読み取りを優先する | 既知の顧客IDやチケットIDがある場合、低コストなポイント読み取りに寄せられる |
| 取得フィールドを絞る | 説明文や履歴など大きいフィールドを毎回取得しない |
| クロスパーティション検索を制限する | キュー全体の調査は必要な場面に限定する |
| クエリテンプレートを用意する | エージェントが自由なSQLを生成し続けるリスクを下げる |
| 集計処理の回数を制限する | 1回の自然文依頼で何度も全体集計しないようにする |
| 検証環境で負荷試験する | 本番導入前にRU、遅延、スロットリングの傾向を確認する |
特に「全顧客を横断して障害傾向を探す」「似た問い合わせを複数条件で探す」といった依頼は便利ですが、クロスパーティション検索が増えがちです。管理者は、AI導入の前後でRU消費のベースラインを比較し、想定外のコスト増がないか確認してください。
書き込み制御：更新前の承認と更新後の検証を分けて考える
今回の発表で管理者が注目すべき設計思想は、エージェントが「実行して終わり」ではなく、更新後に読み戻して検証する点です。サンプルでは、チケットのステータスや担当者、タグ、履歴を更新した後、再度チケットを読み取り、反映されたことを確認してから結果を報告します。(Microsoft for Developers)
ただし、検証があるからといって、すべての書き込みを自動化してよいわけではありません。管理者は、更新の種類ごとに承認要否を分ける必要があります。
| 操作内容 | 推奨される扱い |
|---|---|
| 1件のチケットにタグを追加する | 条件付きで自動化可能 |
| 担当者を割り当てる | 業務ルールに合えば自動化可能 |
| ステータスを「対応中」に変える | 更新履歴と理由を残す前提で検討 |
| 複数チケットへ同じタグを付ける | 人間の承認を挟む |
| 顧客影響を伴うステータス変更 | 人間の承認を挟む |
| 削除、クローズ、返金、契約変更など不可逆に近い操作 | 原則として自動実行させない |
公式発表内でも、複数の関連チケットへタグ付けするような場面では、エージェントがすぐ更新せず、ユーザー確認を挟む流れが示されています。管理者はこの考え方を本番ルールに落とし込み、「何件以上の更新なら承認が必要か」「どのフィールドは自動更新禁止か」を明文化してください。(Microsoft for Developers)
ツール設計：エージェントに生のDB接続を渡さない
公式発表では、エージェントが生のデータベース接続を直接扱うのではなく、クエリ、ポイント読み取り、集計、更新といった限定されたツール経由でCosmos DBを操作する構成が紹介されています。読み取り用ツールはSELECTのみ許可し、書き込みは別の更新ツールに分ける設計です。(Microsoft for Developers)
これは管理上とても重要です。AIエージェントに「何でも実行できるDB接続」を渡すのではなく、「業務上許可された操作だけを行える道具」を渡す発想に切り替える必要があります。
管理者がレビューすべきツール設計
| レビュー項目 | 望ましい状態 |
|---|---|
| 読み取りツール | SELECTのみ許可し、取得件数、対象コンテナー、取得フィールドを制限する |
| 更新ツール | 更新可能なフィールドをホワイトリスト化する |
| 削除操作 | 原則としてエージェントツールに含めない |
| 一括更新 | 件数上限と承認フローを設ける |
| クエリ生成 | 完全自由入力ではなく、テンプレート化やバリデーションを行う |
| エラー処理 | 書き込み失敗、競合、スロットリング時に再試行条件を制御する |
| 検証処理 | 更新後に再読取し、期待値と一致するか確認する |
実務では、エージェントのプロンプトに「削除しないでください」と書くだけでは不十分です。プロンプト上の制約は破られる可能性があるため、削除ツールをそもそも提供しない、更新可能フィールドをコードで限定する、複数件更新には承認を要求する、といった技術的なガードレールが必要です。
移行・導入時の確認事項
今回のNoticeは、既存のAzure Cosmos DB環境に対する必須移行を求める内容ではありません。ただし、AIエージェント連携を導入する場合は、運用設計の移行が必要になります。特に、これまで人間やアプリケーションだけが更新していたデータに、エージェントという新しい操作主体が加わる点を見落とさないでください。
導入前チェックリスト
| フェーズ | 確認事項 |
|---|---|
| 企画 | エージェントに任せる業務範囲を定義する |
| 設計 | 読み取り専用、更新可能、承認必須の操作を分類する |
| 権限 | エージェント専用IDを作成し、最小権限で割り当てる |
| データ | 本番データではなく、匿名化または検証用データでPoCを始める |
| 監査 | Cosmos DB診断ログとアプリ側の操作履歴を設計する |
| コスト | RU消費、クロスパーティション検索、集計処理の負荷を測定する |
| 運用 | 誤更新時の戻し方、停止手順、問い合わせ先を決める |
| 周知 | 利用者に、AIができること・できないこと・承認が必要な操作を説明する |
PoCでは、サンプルデータだけを使って「正しく動いた」と判断しがちです。しかし、本番データではチケットの表記ゆれ、古いスキーマ、空欄、想定外の値、巨大な履歴フィールドなどが存在します。エージェント導入前に、実データに近い検証データでクエリ精度と更新制御を確認してください。
利用者へ周知すべきこと
Azure管理者やシステム管理者だけでなく、実際にエージェントを使うサポート担当者、運用担当者、開発者にも周知が必要です。特に、自然文で依頼できるUIでは、利用者が「お願いしただけ」のつもりでも、裏側ではデータ更新が行われることがあります。
周知内容は、次のように具体化すると伝わりやすくなります。
| 周知項目 | 伝える内容 |
|---|---|
| できること | チケットの優先度確認、滞留状況の要約、関連チケットの探索など |
| 自動で行うこと | 条件を満たす場合のタグ追加、担当者設定、ステータス更新など |
| 承認が必要なこと | 複数件更新、重大ステータス変更、顧客影響がある操作 |
| できないこと | 削除、契約変更、返金、権限変更など自動化対象外の操作 |
| 記録されること | 実行者、依頼内容、更新対象、更新理由、検証結果 |
| 異常時の対応 | 誤更新を見つけた場合の連絡先と停止手順 |
利用者向けには、「AIが勝手に判断する」のではなく、「許可された範囲で、記録を残しながら操作する」という説明が重要です。逆に、管理者側で許可範囲を曖昧にしたまま公開すると、現場はどこまでAIに依頼してよいか判断できません。
失敗しやすいポイント
PoC用の接続情報を本番でも使ってしまう
AIエージェントの検証では、動作確認を急ぐあまり、管理者権限に近い接続文字列を使ってしまうことがあります。PoCの成功後にそのまま本番化すると、権限過多のエージェントが残ります。検証段階から本番と同じ権限設計の考え方を使ってください。
読み取り専用のつもりで書き込み権限を残す
最初は要約や検索だけの用途でも、サンプルコードや拡張機能に更新ツールが含まれている場合があります。エージェントに渡しているツール一覧と、IDに割り当てたCosmos DB権限を両方確認してください。
クロスパーティション検索のコストを見落とす
「障害の兆候を探す」「似た問い合わせを全体から探す」といったAI向きの依頼は、横断検索を発生させやすい処理です。取得フィールドを絞らずに履歴や説明文を大量取得すると、RU消費や応答遅延が増える可能性があります。
更新後の検証を省略する
書き込みAPIが成功しても、業務上期待した状態になっているとは限りません。競合、入力値の誤り、部分更新、再試行などを考えると、更新後に対象アイテムを読み戻して、期待するステータス・担当者・タグ・履歴が反映されているか確認する設計が必要です。
監査ログだけで説明責任を満たせると思い込む
Cosmos DBのログで操作種別やリソースは追跡できても、エージェントがどのユーザー依頼を受け、どの判断で更新したかは、アプリ側に記録しなければ分からない場合があります。AIエージェントでは、技術ログと業務ログを組み合わせて監査できる状態を目指してください。
管理者向けの実践チェックリスト
最後に、今回のNoticeを受けてAzure管理者が確認すべき項目を整理します。
| 優先度 | 確認事項 | 対応の目安 |
|---|---|---|
| 高 | Azure Cosmos DBに接続するAIアプリやエージェントを棚卸しする | 本番・検証・個人検証を分けて確認 |
| 高 | エージェント用IDの権限を確認する | 読み取り専用と更新可能IDを分離 |
| 高 | 書き込み可能なツールを確認する | 更新フィールド、件数上限、削除不可を明確化 |
| 高 | 診断ログとアプリ操作履歴を確認する | 誰が、何を、なぜ、いつ更新したか追える状態にする |
| 中 | RU消費とクロスパーティション検索を測定する | 代表的な自然文依頼で負荷を確認 |
| 中 | 更新後の検証処理を確認する | 書き込み後に再読取して結果を確認 |
| 中 | 承認フローを定義する | 複数件更新や重大操作は人間承認を必須にする |
| 中 | 利用者向けルールを周知する | AIに依頼してよい操作と禁止操作を明文化 |
| 低 | 将来のAI連携方針を文書化する | 新規AIアプリのCosmos DB接続ルールを標準化 |
今回の「How to Use Deep Agents with Azure Cosmos DB」は、Azure Cosmos DBの利用者にただちに移行を求める発表ではありません。しかし、AIエージェントが運用データを直接扱う構成は、今後のAzure運用で現実的な選択肢になります。
管理者が次に行うべきことは、サンプルを試す前に、まず自社のAzure Cosmos DB環境で「AIが読めるデータ」「AIが更新できるデータ」「人間の承認が必要な操作」を分けることです。そのうえで、最小権限、監査ログ、RU監視、更新後検証をセットで設計すれば、Deep AgentsとAzure Cosmos DBを安全に業務活用しやすくなります。
コメント