AI901-Foundry#38-1
注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。
前提
ある企業の社内開発者が、Azure AI Foundry の GPT-4o を呼び出す Python の軽量チャット クライアント (社内 Slack ボット代替) を構築します。本番デプロイは Azure App Service で、認証 / 秘匿性 / 運用性のベスト プラクティスを守る必要があります。
解決策
AzureOpenAI クライアントを Microsoft Entra ID の DefaultAzureCredential で初期化し、Azure App Service の managed identity 経由で認証、
chat.completions.create メソッドで messages 配列 (system + user) を送信、応答テキストは Slack 互換の JSON で返すシンプルな Web API を構築します。この解決策は目的を満たしますか?
解説
【判定: はい】の理由
本構成は Microsoft 公式の Foundry SDK ベスト プラクティスに完全に沿った設計です。DefaultAzureCredential + Azure App Service の managed identity の組み合わせはキーレス認証の標準で、コードにキーを含まず、ローテーション不要で、Privacy and security 原則の中核実装になります。chat.completions.create + messages 配列形式は OpenAI 互換 API の標準で、Foundry SDK の最も基本かつ堅実な使い方です。Slack 互換 JSON 出力は外部システム統合のシンプルなパターンで、保守性 / 拡張性も担保できます。Microsoft Learn の Foundry SDK チュートリアルに沿った設計で、認証 / 秘匿性 / 運用性の全要件を満たします。
【「いいえ」が違う理由】
本ソリューションは Foundry SDK の標準的な軽量チャット クライアント構成で、Azure App Service の標準デプロイにも適合します。「目的を満たさない」と判断する根拠はありません。
本構成は Microsoft 公式の Foundry SDK ベスト プラクティスに完全に沿った設計です。DefaultAzureCredential + Azure App Service の managed identity の組み合わせはキーレス認証の標準で、コードにキーを含まず、ローテーション不要で、Privacy and security 原則の中核実装になります。chat.completions.create + messages 配列形式は OpenAI 互換 API の標準で、Foundry SDK の最も基本かつ堅実な使い方です。Slack 互換 JSON 出力は外部システム統合のシンプルなパターンで、保守性 / 拡張性も担保できます。Microsoft Learn の Foundry SDK チュートリアルに沿った設計で、認証 / 秘匿性 / 運用性の全要件を満たします。
【「いいえ」が違う理由】
本ソリューションは Foundry SDK の標準的な軽量チャット クライアント構成で、Azure App Service の標準デプロイにも適合します。「目的を満たさない」と判断する根拠はありません。
コメント