WEB問題集
解説
【正解: C】の理由
Microsoft Foundry のハブ(Hub)は、複数のプロジェクトを束ねる親リソースであり、接続(Connections)、コンピューティング、ストレージ、Key Vault、セキュリティやネットワークの設定を組織として一元的に管理する起点になります。ハブを最初に作成し、その配下に各開発チーム用のプロジェクト ワークスペースを作成すると、チームごとに独立した作業空間や成果物の分離を保ちながら、ハブで定義した接続情報・コンピューティング クォータ・ネットワーク構成・アクセス制御を継承・共有できます。これにより、組織横断のガバナンスとセキュリティ統制を効かせつつ、チームには自律的な開発環境を与えられます。各チームに Azure OpenAI や ML ワークスペースを個別に作る方法や、ハブなしでプロジェクトだけを作る方法では、この一元的な共有・統制が実現できません。まずハブを作成するのが適切です。
【他選択肢が違う理由】
- A: Azure OpenAI リソースを個別に作るとモデルへのアクセスは得られますが、プロジェクトワークスペースの共有やハブ単位のガバナンスは実現できません。
- B: Azure Machine Learning ワークスペース単独では、Foundry のハブ/プロジェクト構造による接続共有やエージェント開発の統制を提供できません。
- D: ハブを作らずプロジェクトのみを作る構成では、接続やセキュリティ設定をチーム横断で共有・統制する仕組みがなく、要件の一元管理を満たせません。
【参考】
| ステートメント | はい | いいえ |
|---|---|---|
|
ハブは、接続・計算クォータ・セキュリティ設定を一元管理し、配下の複数プロジェクトで共有する親リソースとして機能します。 |
||
|
プロジェクトは、ハブから接続を継承しつつ、チーム固有の成果物（エージェント、評価、デプロイ）を分離して管理します。 |
||
|
プロジェクトを作成するたびに、Azure OpenAI 接続を毎回個別に再構成しなければなりません。 |
解説
【正解一覧】
| ステートメント | 正解 |
|---|---|
| ハブは、接続・計算クォータ・セキュリティ設定を一元管理し、配下の複数プロジェクトで共有する親リソースとして機能します。 | はい |
| プロジェクトは、ハブから接続を継承しつつ、チーム固有の成果物（エージェント、評価、デプロイ）を分離して管理します。 | はい |
| プロジェクトを作成するたびに、Azure OpenAI 接続を毎回個別に再構成しなければなりません。 | いいえ |
【ポイント】
ハブは接続・計算クォータ・セキュリティ設定を一元管理し、配下の複数プロジェクトでそれらを共有する親リソースとして機能するため、第一の記述は正しいです。プロジェクトはハブから接続を継承しつつ、エージェント・評価・デプロイといったチーム固有の成果物を分離して管理できるため、第二の記述も正しいです。プロジェクトはハブの接続を継承するため、作成するたびに Azure OpenAI 接続を毎回個別に再構成する必要はなく、そうしなければならないとする第三の記述は誤りで、「いいえ」となります。ハブとプロジェクトの階層構造を理解することで、共有と分離のバランスをとった効率的な運用が可能になります。
【参考】
- エージェントまたはプロンプトフローを接続インデックスにグラウンディングする
- Azure AI Search サービスを作成する
- データをインジェストして検索インデックスを構築する
- プロジェクトに Azure AI Search 接続を追加する
解説
【正しい順序】
- ステップ 1: Azure AI Search サービスを作成する
- ステップ 2: プロジェクトに Azure AI Search 接続を追加する
- ステップ 3: データをインジェストして検索インデックスを構築する
- ステップ 4: エージェントまたはプロンプトフローを接続インデックスにグラウンディングする
【ポイント】
- ステップ 1 Azure AI Search サービスを作成する: 検索とベクトル検索を提供する Azure AI Search サービスが、データソースの基盤として最初に必要です。
- ステップ 2 プロジェクトに Azure AI Search 接続を追加する: プロジェクトから検索サービスを参照できるよう、接続を登録して資格情報または Managed Identity を構成します。
- ステップ 3 データをインジェストして検索インデックスを構築する: 接続済みの検索サービスにドキュメントを取り込み、ベクトルやセマンティック構成を含むインデックスを作成します。
- ステップ 4 エージェントまたはプロンプトフローを接続インデックスにグラウンディングする: インデックスが利用可能になった後に、エージェントやフローへインデックスを紐付けて取得拡張生成を有効にします。
【誤った順序の問題点】
- 接続追加より前にグラウンディングを行う: プロジェクトに検索接続が登録されていないと、インデックスを取得元として選択できません。
- インデックス構築より前にグラウンディングを構成する: インデックスがまだ存在しない状態ではグラウンディングする対象がなく、検索結果を返せません。
【参考】
あるチームは Microsoft Foundry でエージェントを構築し、Azure AI Agent Service を使用してスレッドと実行（run）を管理します。エージェントには関数呼び出しツールとナレッジツールを割り当てる予定です。次の各ステートメントが正しいか（はい／いいえ）を判定してください。
| ステートメント | はい | いいえ |
|---|---|---|
|
Azure AI Agent Service では、会話の状態をスレッドとして保持し、各応答生成を実行（run）として処理できます。 |
||
|
エージェントにツールを割り当てる場合、関数呼び出しとナレッジ取得を同一のエージェントに共存させることはできません。 |
||
|
スレッドは一度作成すると新しいメッセージを追加できず、実行のたびに毎回作り直す必要があります。 |
解説
【正解一覧】
| ステートメント | 正解 |
|---|---|
| Azure AI Agent Service では、会話の状態をスレッドとして保持し、各応答生成を実行（run）として処理できます。 | はい |
| エージェントにツールを割り当てる場合、関数呼び出しとナレッジ取得を同一のエージェントに共存させることはできません。 | いいえ |
| スレッドは一度作成すると新しいメッセージを追加できず、実行のたびに毎回作り直す必要があります。 | いいえ |
【ポイント】
Azure AI Agent Service は会話の状態をスレッドとして保持し、ユーザー メッセージに対する各応答生成を実行（run）として処理するため、第一の記述は正しく「はい」です。エージェントには関数呼び出しツールとナレッジ取得ツールを同時に割り当てて共存させることができ、両者を排他とする第二の記述は誤りで「いいえ」です。スレッドは永続的で、作成後も新しいメッセージを追加でき、実行のたびに作り直す必要はないため、第三の記述も誤りで「いいえ」です。スレッドとツールの仕組みを正しく理解することが重要です。
【参考】
ある企業は、RAG を用いたエージェントの応答品質が時間とともに低下していないかを継続的に確認したいと考えています。入力データの分布の変化 (ドリフト) や、根拠に基づかない応答 (ファブリケーション) の増加を検知する監視を設計します。この目的に適した設計はどれですか。該当するものを2つ選択してください。
解説
【正解: D / A】の理由
応答品質の経時的な低下やドリフトを検知するには、定期的に評価データセットに対して自動評価を実行し、根拠性や関連性スコアの推移を時系列で追跡します。さらに、本番トラフィックのサンプルを継続的に評価し、入力分布や品質メトリックの変化を検知してアラートを設定することで、ドリフトやファブリケーションの増加を早期に把握できます。継続的な評価と監視の組み合わせが要点です。初回デプロイ時の一度だけの評価や、推論を止めて合成データのみで運用する方法では、実運用の変化を継続的に捉えられず、品質低下を見逃します。
【他選択肢が違う理由】
- B: 本番推論を停止して合成データのみで運用するのは本番監視の目的を損ない、実際のドリフト検知になりません。
- C: 初回デプロイ時の一度だけの評価では、時間とともに進行するドリフトや品質低下を検知できません。
- E: モデル提供元に完全依存し自社で指標を持たないと、自社のデータ分布に固有のドリフトやファブリケーションを検知できません。