今回の「Least privilege AI agents」は、Azure SDKのライブラリ仕様が突然変わる更新ではありません。結論から言うと、MicrosoftとCurityが、AIエージェントを最小権限・短命トークン・監査ログ前提でAzureへ展開するための新しいazdテンプレートを公開した、という内容です。
AIエージェントのデモでは「自然言語を解釈してAPIを呼び出せる」ことに注目しがちです。しかし本番利用では、「そのユーザーが見てよいデータだけを返せるか」「プロンプトインジェクションで余計なAPIを呼ばれても被害を抑えられるか」が重要になります。今回のテンプレートは、その課題に対して、OAuth 2.0のアクセストークン、Microsoft Entra ID、Curity Identity Server、MCPサーバー、APIゲートウェイ、Azureのインフラ構成を組み合わせた実装例を示しています。Microsoft公式Azure SDK Blogでは2026年5月7日付の投稿として公開されています。(Microsoft for Developers)
Azure SDKのAIエージェント更新で何が変わるのか
今回のポイントは、Azure SDKやAzure Developer CLIを使ったAIエージェント開発で、認証だけでなく認可を設計の中心に置くテンプレートが提供されたことです。
従来のAIエージェントのサンプルでは、ユーザー認証やAPI呼び出しの動作確認までは比較的分かりやすく実装できます。一方で、本番環境に近づくほど次のような問題が出てきます。
- エージェントが別ユーザーのデータを取得しないか
- APIキーのような恒久的な認証情報をエージェントに持たせていないか
- ユーザーの権限、顧客ID、地域、スコープをAPI側で確実に判定できるか
- プロンプトインジェクションで想定外の操作を要求された場合に止められるか
- エージェント経由のAPI呼び出しを監査できるか
新しいテンプレートは、これらを単なる注意喚起ではなく、実際にAzureへ展開できる構成として示している点が重要です。Microsoftの説明では、このテンプレートにより、Microsoft Foundry上のC#製バックエンドAIエージェント、MCPサーバー、Curity Identity Server、Microsoft Entra ID、外部・内部APIゲートウェイ、BicepによるAzureインフラが含まれます。(Microsoft for Developers)
今回の更新は「Azure SDKの破壊的変更」ではない
まず押さえておきたいのは、今回の情報はAzure SDKパッケージのAPI変更や非推奨化の告知ではない、という点です。
対象は、Azure Developer CLI、Microsoft AI関連SDK、MCP/A2A、OAuth 2.0、Azureのインフラ構成を組み合わせたazdテンプレートです。したがって、既存のAzure SDK利用アプリに対して、ただちにコード修正やライブラリアップデートが必要になる種類の更新ではありません。
ただし、AIエージェントを業務アプリに組み込んでいる、または今後組み込む予定があるチームにとっては、設計方針を見直すきっかけになります。特に「ログイン済みユーザーの代わりにAIがAPIを呼ぶ」構成では、認証済みであることだけでは不十分です。
| 観点 | 今回の更新で見るべきポイント | 既存システムへの影響 |
|---|---|---|
| SDKの互換性 | Azure SDKの直接的な破壊的変更ではない | 既存コードの即時修正は基本的に不要 |
| AIエージェント設計 | エージェントに過剰権限を与えない構成を提示 | 既存のAI連携設計を見直す材料になる |
| 認証・認可 | Entra IDとCurity Identity Serverを組み合わせる | IAM、API管理、開発チームの連携が必要 |
| デプロイ | BicepとazdでAzureリソースを段階的に展開 | 検証環境でのコスト・リージョン確認が必要 |
| セキュリティ | 短命トークン、スコープ、監査ログを重視 | APIキー依存の構成は再検討したい |
Least privilege AI agentsとは何か
Least privilege AI agentsとは、AIエージェントに必要最小限の権限だけを与え、必要なタイミングで、短い有効期限のトークンを使ってAPIへアクセスさせる考え方です。
たとえば、顧客サポート用のAIエージェントが「過去3か月の株式取引とポートフォリオの価値をMarkdownでまとめて」と依頼されたとします。このとき、エージェントは自然言語を解釈してAPIを呼び出します。しかし、API側が「このユーザーはどの顧客IDのデータを読めるのか」を確認できなければ、別の顧客の資産情報を返してしまうリスクがあります。
今回のテンプレートでは、アクセストークンにscope、customer_id、region、client_type、agent_idなどの属性を含め、MCPサーバー側がそれらを使って返すデータを絞り込む設計が示されています。Microsoftの例では、scopeは読み取り専用のstocks/read、customer_idは特定顧客、regionは特定地域を表す値として扱われています。(Microsoft for Developers)
重要なのは、AIエージェントの判断を完全に信頼するのではなく、API側がトークンの中身に基づいて必ず制御することです。エージェントが間違ったツールを呼ぼうとしても、APIが権限外のデータを返さなければ、被害を抑えられます。
新しいazdテンプレートに含まれる主な構成
公式情報によると、このテンプレートはフルスタックのAIエージェントアプリをAzureへ展開できる構成です。単なるサンプルコードではなく、ID基盤、APIゲートウェイ、ネットワーク、監査ログ、Azureリソースのプロビジョニングまで含む点が特徴です。
| 構成要素 | 役割 |
|---|---|
| Microsoft Foundry上のバックエンドAIエージェント | 自然言語リクエストを処理し、必要なツールやAPI呼び出しを判断する |
| C#アプリケーションコード | Microsoft A2A SDK、MCP SDKを使ったサンプル実装を提供する |
| MCPサーバー | サンプルのポートフォリオAPIを公開し、トークン属性に基づいてデータアクセスを制御する |
| Curity Identity Server | 認可サーバーとして、短命かつ最小権限のアクセストークンを発行する |
| Microsoft Entra ID | ユーザー認証とユーザー情報の管理を担う |
| 外部APIゲートウェイ | 外部クライアントからのアクセスを受け、トークン交換を処理する |
| 内部APIゲートウェイ | エージェントとMCPサーバー間で監査ログや粗い制御を担う |
| Bicep | Container Apps、仮想ネットワーク、Azure Container Registry、Azure AI Foundryリソース、Key Vault、Azure SQL Databaseなどを構成する |
GitHubリポジトリのREADMEでも、このテンプレートはOAuth 2.0のトークンインテリジェンスを使ったエンタープライズAIセキュリティアーキテクチャの例として説明されています。C#コード、OpenID Connect、OAuth 2.0によるトークン検証・交換、IDシステムとAPIゲートウェイの構成が含まれます。(GitHub)
管理者が確認すべき設定
管理者がまず確認すべきなのは、「AIエージェントにどの権限を与えるか」ではなく、「ユーザー、エージェント、API、ゲートウェイの境界をどこで区切るか」です。
Entra IDの役割を誤解しない
今回の構成では、Microsoft Entra IDはユーザーのサインインとID管理を担います。一方、エージェントやAPI向けの短命トークンを設計・発行する役割として、Curity Identity Serverが組み合わされています。Microsoftの説明でも、Entra IDを置き換えるのではなく、隣にトークン発行者を追加する構成だとされています。(Microsoft for Developers)
そのため、管理者は次の点を確認しておく必要があります。
- Entra ID上のどの属性をトークンに含めるのか
- 顧客ID、部署、地域、ロールなどの属性が最新か
- テストユーザーと本番ユーザーの属性設計が混ざっていないか
- 認証と認可の責任分界点が文書化されているか
- Curity Identity Serverをコンテナで使うのか、Marketplace経由で導入するのか
特に顧客IDや地域のような属性は、AIエージェントの出力結果に直結します。属性が間違っていれば、AIの回答も正しく制限できません。
トークンに入れる値を先に設計する
最小権限のAIエージェントを作るうえで、最も重要なのはトークン設計です。
開発チームだけで「APIを呼べるようにする」段階まで進めると、後から権限制御を追加するのが難しくなります。先に、どのAPIがどのスコープを必要とするか、どの属性でデータを絞り込むかを決めておくべきです。
| トークン属性 | 確認すべきこと | 失敗しやすい例 |
|---|---|---|
scope | 読み取り、書き込み、承認操作を分けているか | read/writeをまとめて付与してしまう |
customer_id | ユーザーがアクセス可能な顧客範囲を表せるか | アプリ側の画面制御だけに依存する |
region | 国・地域・拠点単位の制限が必要か | グローバル検索APIで全データを返す |
client_type | AIエージェント経由の呼び出しを区別できるか | 人間の操作とAIの操作を同じ扱いにする |
agent_id | どのエージェントが呼び出したか追跡できるか | 監査ログで原因を特定できない |
AIエージェントは、通常のクライアントアプリよりも呼び出しパターンが予測しにくくなります。だからこそ、API側で「このトークンなら何を返してよいか」を明確にする必要があります。
内部エンドポイントも認可対象にする
Curityの解説では、インターネットに公開されたエンドポイントだけでなく、内部エンドポイントでも認証と認可を行うべきだと説明されています。短命で最小権限のOAuth 2.0アクセストークンを使い、エージェントにAPIキーのような恒久的なアクセス権を与えないことが重要です。(Curity)
これは実務上、かなり重要なポイントです。社内ネットワークやプライベートネットワーク内にあるAPIでも、AIエージェントが間違ったリクエストを作る可能性はあります。内部だから安全、と考えるのではなく、内部APIにもスコープ、audience、発行者、期限、属性チェックを実装する必要があります。
開発者が確認すべき実装ポイント
開発者にとって今回のテンプレートは、AIエージェントのサンプルというより、APIを安全に呼ばせるための実装パターン集として見ると分かりやすいです。
APIコードに権限ロジックを散らばらせない
Microsoftが評価しているポイントの一つは、MCPサーバーがトークン属性を取り出してクエリに使うことで、APIコードを比較的シンプルに保てる点です。権限の考え方をすべてアプリケーションコードに埋め込むのではなく、上流でトークンを設計し、APIはそのトークンに基づいてデータを絞り込みます。(Microsoft for Developers)
実装時は、次のような方針を取ると事故を減らせます。
- APIは必ずアクセストークンを検証する
audが自分のAPI向けか確認するexpとnbfで有効期間を確認するscopeで操作種別を制御するcustomer_idやregionで検索条件を必ず絞る- トークン内の
client_typeやagent_idをログに残す - エージェントから渡された自然言語やパラメータを信用しすぎない
たとえば、ポートフォリオ取得APIでcustomer_idをリクエストボディから受け取るだけでは不十分です。ユーザーが「顧客178のデータを見せて」と入力した場合でも、APIはトークンに含まれるcustomer_idを正とし、リクエスト側の値をそのまま信用しない設計が必要です。
ローカル実行でトークンの流れを確認する
テンプレートのREADMEでは、最初にローカル環境でエンドツーエンドの動作を確認する手順が示されています。az login後、./tools/local/backend.shでローカルバックエンドを起動し、コンソールクライアントを実行する流れです。(GitHub)
本番導入を検討する前に、開発者は次の観点でローカル確認を行うとよいでしょう。
| 確認項目 | 見るべきポイント |
|---|---|
| トークン交換 | 初期トークンがどのようにスコープダウンされるか |
| JWTの中身 | scope、customer_id、region、agent_idが期待どおりか |
| MCPサーバーの応答 | トークン属性に合うデータだけが返るか |
| 権限外リクエスト | 不正な顧客IDやスコープで拒否されるか |
| ログ | 内部ゲートウェイに監査に必要な情報が出ているか |
AIエージェントの出力が正しいかだけでなく、「間違った要求をしたときに正しく拒否されるか」を必ず検証してください。
A2AとMCPの役割を分けて理解する
Curityの解説では、外部アプリケーションがA2AプロトコルとMicrosoft A2A SDKを使ってバックエンドエージェントへ自然言語コマンドを送り、バックエンドエージェントがMCPプロトコルとMicrosoft MCP SDKを使ってMCPサーバーと通信する構成が説明されています。(Curity)
実務では、A2AとMCPを「AI関連の新しい仕組み」とまとめて捉えるより、次のように分けると設計しやすくなります。
| 領域 | 主な役割 | セキュリティ上の注目点 |
|---|---|---|
| A2A | クライアントとバックエンドエージェントのやり取り | ユーザーの意図、初期トークン、セッション管理 |
| エージェント | 自然言語を解釈し、必要な処理を選ぶ | 誤判断、ツール選択、プロンプトインジェクション |
| MCP | エージェントとツール・APIの接続 | トークン検証、スコープ、データ境界 |
| API | 実データへのアクセス | 顧客ID、地域、操作種別による絞り込み |
この分離を意識すると、「AIにどこまで任せるか」と「API側で必ず守るべき境界」を整理しやすくなります。
展開時に注意すべきAzureリソースとリージョン
このテンプレートは、Azure上に複数のリソースを作成します。試すだけでもコストやリージョン制約を確認してから進めるべきです。
GitHub READMEでは、Azure開発アカウント、Azure CLI、Azure Developer CLI、.NET SDK 10以上、Docker/Docker Compose、openssl、envsubst、jqなどのローカルツールが必要とされています。また、AzureデプロイではEntra IDテナントとテスト用ユーザーアカウントも必要です。(GitHub)
リージョンはgpt-4.1-mini対応を確認する
テンプレートではgpt-4.1-miniを使うため、すべてのAzureリージョンで同じように動くとは限りません。Microsoft公式ブログでは、East US 2、Sweden Central、UK Southが選択肢として挙げられていますが、開始前にリージョン可用性を確認するよう案内されています。(Microsoft for Developers)
日本国内の環境で検証する場合も、「いつものリージョンで作る」だけではなく、対象モデルが利用可能かを先に確認してください。利用できないリージョンを選ぶと、AI Foundry関連のリソースやモデルデプロイで詰まる可能性があります。
azdの環境名はdevで始める
Microsoft公式ブログでは、azd init時の環境名としてdevを使うことが推奨されています。README内のデプロイスクリプトや監査ログ確認コマンドがdev前提になっているためです。(Microsoft for Developers)
小さな点に見えますが、検証初期では重要です。環境名を独自に変えると、リソースグループ名やContainer Apps名、ログ確認コマンドを読み替える必要があります。まずはdevで動作確認し、構成を理解してから命名規則を自社向けに変えるのが安全です。
デプロイは層ごとに進める
このテンプレートは、ベースインフラ、ID基盤、アプリケーションの層に分けてデプロイする構成です。Microsoft公式ブログでは、ネットワークやContainer Registryなどのベース層、Curity Identity ServerとAPIゲートウェイを含むID層、エージェントとMCPサーバーを含むアプリケーション層の構成が説明されています。(Microsoft for Developers)
GitHub READMEでも、azd provision base、azd provision identity、azd deployの順に進める手順が示されています。(GitHub)
| 手順 | コマンド例 | 目的 |
|---|---|---|
| プロジェクト作成 | azd init --template curityio/azd-ai-autonomous-agent | テンプレートからプロジェクトを作る |
| リージョン設定 | azd env set AZURE_LOCATION='uksouth' | 利用するAzureリージョンを指定する |
| ベース層作成 | azd provision base | ネットワークや共有基盤を作成する |
| ID層作成 | azd provision identity | Curity、ゲートウェイ、認可関連を構成する |
| アプリ展開 | azd deploy | C#アプリ、エージェント、MCPサーバーを展開する |
いきなり全体を本番サブスクリプションへ展開するのではなく、検証用サブスクリプションでリソース作成内容と費用感を確認してください。
移行・既存環境への適用で考えるべきこと
今回のテンプレートは、既存のAzure SDKアプリをそのまま置き換えるものではありません。むしろ、既存のAPIやAI連携を見直すための参照アーキテクチャとして使うのが現実的です。
APIキーをエージェントに持たせている場合は見直す
AIエージェントに固定APIキーや長期有効なシークレットを持たせている場合、今回のテンプレートが示す考え方とは相性がよくありません。エージェントが侵害されたり、プロンプトインジェクションで想定外の操作を実行したりした場合、APIキーの権限範囲全体がリスクになります。
移行を考えるなら、まず次の順で棚卸しします。
| 棚卸し項目 | 確認内容 |
|---|---|
| エージェントが呼ぶAPI | どのAPIを、どの操作で呼ぶか |
| 認証情報 | APIキー、クライアントシークレット、Managed Identity、アクセストークンのどれか |
| 権限範囲 | 読み取り専用か、書き込みや削除まで可能か |
| ユーザー境界 | ユーザーごと、顧客ごと、部署ごとに制限できているか |
| 監査ログ | 誰の代わりに、どのエージェントが、何を呼んだか追えるか |
最初から全APIを作り直す必要はありません。まずは、個人情報、顧客データ、金融情報、契約情報など、漏えい時の影響が大きいAPIから優先的に見直すと現実的です。
認可ロジックを画面側だけに置かない
従来の業務アプリでは、画面側でボタンを非表示にしたり、メニューを出し分けたりすることで権限を表現しているケースがあります。しかしAIエージェントは、画面のボタンをクリックするだけの存在ではありません。自然言語からAPI呼び出しを組み立てるため、画面側の制御だけでは不十分です。
AIエージェント時代の認可では、次の考え方が必要です。
- 画面で隠していても、API側で拒否できるようにする
- ユーザー入力に含まれるIDを信用しない
- トークンに含まれる属性を基準にデータを絞る
- 読み取りと書き込みの権限を明確に分ける
- 高権限操作は人間の承認を挟む
Microsoft公式ブログでも、将来的な応用例として、人間の承認を挟んだうえで高権限のstocks/writeスコープを持つトークンを発行するシナリオが紹介されています。(Microsoft for Developers)
監査ログを「あとで見るもの」にしない
内部ゲートウェイの監査ログは、トラブル発生後の調査だけでなく、導入初期の設計検証にも役立ちます。Microsoft公式ブログでは、Container Appsのログを追跡し、scope、customer_id、region、agent_idを確認する例が示されています。(Microsoft for Developers)
実務では、次のような観点でログを設計してください。
| ログ項目 | 目的 |
|---|---|
| ユーザーIDまたはサブジェクト | 誰の代わりに呼び出されたかを確認する |
| エージェントID | どのAIエージェントが呼び出したかを追う |
| スコープ | 読み取り、書き込み、承認操作を判別する |
| 顧客ID・地域 | データ境界が守られているか確認する |
| 拒否理由 | 権限不足、期限切れ、audience不一致などを切り分ける |
| リクエストID | アプリ、ゲートウェイ、API間のログを関連付ける |
「ログは出ているが、調査に使えない」という状態を避けるには、AIエージェント経由の呼び出しを通常のAPIアクセスと区別できるようにしておくことが大切です。
本番利用前に確認したいチェックリスト
このテンプレートをそのまま本番投入するのではなく、自社のID管理、API設計、監査要件、運用体制に合わせて調整する必要があります。GitHub READMEでも、このテンプレートはビジネスデータを保護するアーキテクチャを示すものの、本番システムでは追加のセキュリティ強化が必要だと明記されています。(GitHub)
| チェック項目 | 確認内容 |
|---|---|
| 本番用テナントと検証用テナントを分けているか | テスト属性や検証ユーザーが本番に混ざらないようにする |
| トークンの有効期限は短く設定されているか | 長期トークンや固定APIキーへの依存を避ける |
| スコープは操作単位で分かれているか | 読み取り、書き込み、承認、管理操作を分離する |
| API側で必ずトークン属性を検証しているか | エージェントの判断や入力値だけに依存しない |
| 内部APIも認可しているか | プライベートネットワーク内でもゼロトラストを意識する |
| ログでエージェント経由の操作を追えるか | agent_idやclient_typeを監査に使えるようにする |
| リージョンとモデル可用性を確認したか | gpt-4.1-miniの利用可否を事前に確認する |
| コスト見積もりを行ったか | Container Apps、AIサービス、VNet、SQLなどの費用を確認する |
| Curityのライセンスや導入経路を確認したか | コンテナ利用、Marketplace利用、調達ルールを整理する |
| 高権限操作に人間の承認を挟むか | 自動実行してよい操作と承認が必要な操作を分ける |
どのチームがこの更新を見るべきか
今回の情報は、Azure SDKの利用者だけでなく、AIエージェントを業務システムへ組み込む複数のチームが確認すべき内容です。
| 対象者 | 確認すべきポイント |
|---|---|
| Azure管理者 | 作成されるリソース、ネットワーク、リージョン、コスト、Key Vault、Container Apps |
| ID管理担当者 | Entra ID属性、Curity Identity Server、トークン設計、スコープ設計 |
| API開発者 | MCPサーバー、トークン検証、データ絞り込み、拒否時の挙動 |
| AIアプリ開発者 | A2A/MCP連携、エージェントのツール呼び出し、プロンプトインジェクション対策 |
| セキュリティ担当者 | 監査ログ、最小権限、内部APIの認可、運用時の検知 |
| DevOps担当者 | Bicep、azd、GitHub Actions、Managed Identity、環境変数・シークレット管理 |
特に、AIエージェント開発をアプリ開発チームだけで進めている場合は注意が必要です。今回のテンプレートが示しているのは、AIの精度向上ではなく、ユーザー、エージェント、API、ID基盤、監査をつなぐ全体設計です。早い段階でID管理担当者とセキュリティ担当者を巻き込むべきです。
まず何から始めるべきか
この更新を受けて最初にやるべきことは、既存アプリへの大規模な移行ではありません。まずは検証環境でテンプレートを動かし、トークンがどのように交換され、API側でどのようにデータ境界が守られるかを確認することです。
実務では、次の順番で進めると無理がありません。
- GitHubリポジトリのREADMEで前提ツールと構成を確認する
- 検証用AzureサブスクリプションとEntra IDユーザーを用意する
- ローカル環境でエンドツーエンドの流れを試す
- JWTの
scope、customer_id、region、agent_idを確認する - 権限外の顧客IDやスコープでAPIが拒否するか試す
- Azureへ層ごとにデプロイする
- 監査ログでAIエージェント経由の呼び出しを追跡する
- 自社APIに置き換えた場合のトークン設計を作る
今回の「Least privilege AI agents」は、AIエージェントを便利に動かすためのテンプレートというより、AIエージェントを安全に業務データへ接続するための設計サンプルです。Azure SDKやMicrosoft Foundryを使ったAIアプリを検討しているなら、まずはこのテンプレートを検証し、自社のAPIキー運用、トークン設計、監査ログ、内部APIの認可を見直してください。
コメント