AI901-Foundry#47-2
注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。
前提
ある旅行サイト企業が、顧客に対し「リアルタイムにフライト料金検索 + 宿泊予約 + 天気予報統合」を行う AI 旅行アシスタントを Foundry SDK で構築します。ユーザー体感応答時間が短く、外部 API (フライト / ホテル / 天気) と統合する必要があります。
解決策
外部 API 統合機能を諦め、ユーザーが手入力で「フライト料金 / ホテル空き / 天気」を毎回入力し、それを LLM が単純に要約する設計に変更します。function calling や streaming は使用しません。
この解決策は目的を満たしますか?
解説
【判定: いいえ】の理由
本提案は要件全項目に違反します。第一に、ユーザーが手入力で外部情報を入れる方式は「リアルタイム検索 + 予約統合」要件と完全に矛盾し、AI 旅行アシスタントの価値そのものが消失します。第二に、function calling の不使用は LLM がアプリ統合の中核として機能する Foundry SDK の設計意図と反し、本来 AI が自律的に行うべき検索 / 予約処理をユーザーに押し付ける UX 劣化を生みます。第三に、streaming 非使用により長い応答での体感レイテンシ短縮の機会を逃し、ユーザー体験がさらに劣化します。要件 (リアルタイム性 / 外部 API 統合 / UX) のすべてを犠牲にする退化的な設計で、Microsoft 公式の Foundry SDK 高度機能のベスト プラクティスとも完全に相反します。
【「はい」が違う理由】
外部 API 統合の放棄は要件の根本的破壊で、機能 / UX のすべてに違反するため、「目的を満たす」と判定する根拠は皆無です。
本提案は要件全項目に違反します。第一に、ユーザーが手入力で外部情報を入れる方式は「リアルタイム検索 + 予約統合」要件と完全に矛盾し、AI 旅行アシスタントの価値そのものが消失します。第二に、function calling の不使用は LLM がアプリ統合の中核として機能する Foundry SDK の設計意図と反し、本来 AI が自律的に行うべき検索 / 予約処理をユーザーに押し付ける UX 劣化を生みます。第三に、streaming 非使用により長い応答での体感レイテンシ短縮の機会を逃し、ユーザー体験がさらに劣化します。要件 (リアルタイム性 / 外部 API 統合 / UX) のすべてを犠牲にする退化的な設計で、Microsoft 公式の Foundry SDK 高度機能のベスト プラクティスとも完全に相反します。
【「はい」が違う理由】
外部 API 統合の放棄は要件の根本的破壊で、機能 / UX のすべてに違反するため、「目的を満たす」と判定する根拠は皆無です。
コメント