小編精選 - 技術文章翻譯 · 09月27日

整理新しい Copilot（Home・Code・Autopilot）與收費方案，並思考在大型企業廣泛導入時的課題

前言

2026 年 9 月 25 日，Microsoft 發表了「新的 Copilot」。這是一項會大幅改變 Copilot App 本身形態的重大發表，同時也將收費架構整理成「以使用者為單位的授權」與「依使用量計費」兩條線。

這次發表的內容，對我個人來說也非常令人興奮。另一方面，站在平時協助客戶推動 Copilot 與 Power Platform 的立場來看，若從「能否在全公司廣泛部署」的角度思考，老實說，我認為有不少事情是值得先想清楚的。

本文會先以官方資訊為 आधार，整理這次發表內容與費用體系，接著寫出我個人對於在組織中（特別是大型企業）推展時會在意的地方。最後，也會談談我對生成式 AI 要在企業中被廣泛使用，所需要的前提條件的看法。

※本文內容以 2026/09/26 當時的公開資訊，以及我個人的驗證與見解為基礎。由於許多功能是透過 Frontier Program 或預覽版提供，未來可能會變動，敬請注意。

參考的主要資訊如下：

吉田先生的文章，對於不熟悉技術的人也能清楚整理發表內容，非常有參考價值。若想掌握整體輪廓，我也建議一併閱讀。

本次發表的整體樣貌

一句話說明

以我個人的感受來看，這很像是 Claude 的桌面應用程式或 ChatGPT App 那樣，把「Chat（聊天）」「Work（交辦）」「Code（建立）」整合到同一個 App 裡，再疊上 Microsoft 365 的安全性與管理機制。

本次發表的主要功能如下。

名稱｜概要｜提供時期（發表時點）
---｜---｜---
Home｜整合 Chat 與 Cowork 的 Copilot 新入口｜未來數週內從 Frontier 開始
Office in Copilot｜可直接在 Copilot 內建立與編輯 Word、Excel、PowerPoint｜作為 Home 的一部分
Code｜用日常語言建立小型應用程式與工具｜本月底先於 Frontier 提供，之後數週內一般提供
Copilot Managed Runtime｜在自家 Microsoft 365 環境中執行所建立應用程式的基礎｜預覽版
Autopilot（舊名 Scout）｜不需等待指示即可持續執行的專用代理程式｜本月底擴大私人預覽
FinOps for AI｜讓 AI 成本可視化並進行管理的機制｜本次發表（部分自 10 月起）

Home 與 Office in Copilot

Home 是開啟 Copilot 時最先顯示的畫面，Chat 與 Cowork 也整合在這裡。Chat 是即時回應的對話式互動；Cowork 則是從頭到尾把工作交給它，最後把成果交回來，兩者各自扮演不同角色。未來的方向是，使用者不必自己決定要用 Chat、Cowork 還是 Code，由 Copilot 自動分派。

此外，透過 Office in Copilot，只要從 Home 發出需求，就能產出真正的 Word 文件、Excel 活頁簿與 PowerPoint 簡報，並可供團隊同時編輯。

Code 與 Copilot Managed Runtime

Code 是一項功能：當你用日常語言描述想做的東西時，它能幫你建立小型 App、儀表板、Widget 等。它以 GitHub Copilot 的技術為基礎，並在隔離環境（Sandbox）中執行。

建立好的 App 可以在 Copilot Managed Runtime 上，於自家 Microsoft 365 環境（租用戶）內執行。官方說明這個基礎架構是用來支援 Cowork、Code，以及以 Copilot Studio 建立的應用程式。

Autopilot

Autopilot 是先前稱為 Scout 的功能新名稱。官方表示，只要給它名稱、角色與目標，它就會依照目的持續檢查頻道狀況，並進行後續追蹤、定期作業等持續性工作。

Cowork 著重的是交辦具體工作並接收成果，而 Autopilot 則是給它一個角色，讓它持續執行活動。不過，Cowork 也有排程執行或以事件觸發的功能，因此並不是單純以「會不會自動執行」來區分（Cowork FAQ）。

官方說明，Autopilot 在租用戶內擁有專用的身分、記憶、電腦與工作區，並在雲端運作。其特色是在使用者不在場時仍可持續工作，並且在權限、稽核與治理機制下進行管理（官方發表）。

我個人很期待的用途之一，是製作實作訓練教材。比如，只要提供情境與操作步驟，它就能實際操作目標服務、截圖，並整理成附有步驟的投影片教材。這目前尚未確認可真正做到，但若未來能交辦這類工作，應該會有很大的效益。

不過，如果要製作數百頁的資料，完成所需成本，以及人工作確認與修正還剩下多少，評估就會不同。假如大約花 1～2 萬個 Credit，就能做出符合期待品質的內容，並大幅減少製作與審稿時間，那我認為會是很有力的選項。反之，如果要耗費數十萬個 Credit，還需要大量確認與修改，那麼在現階段選擇由人來製作，也不是不合理的決定。當然，這些 Credit 數字並非實測或官方估算，而是為了思考成本效益所做的假設。

實際上能操作哪些網站或 App、又是以誰的權限執行、成本會到什麼程度，這些都希望之後能進一步確認。企業使用時的存取範圍與管理論點，我會在後面整理。

其他

此外，Microsoft IQ（整合 Work IQ、Fabric IQ、Foundry IQ、Web IQ 的機制）也擴大了可參照的範圍，例如宣布 Fabric IQ 在 Chat 與 Cowork 的一般提供，以及 Dynamics 365 與 Power Platform（Dataverse）資料參照的公開預覽。還有可集中管理外掛的 Plug-in Registry，以及後續即將提供的 Today（10 月私人預覽）與 @Copilot in Teams（本月底前私人預覽）。詳細內容請參考開頭列出的參考文章。

費用體系整理

USL 與 UBB 的雙軌制

這次將 AI 工作分成「日常 AI（Everyday AI）」與「進階 AI（Advanced AI）」兩類，並分別整理對應的付費方式（Microsoft Learn：USL 與 UBB 說明）。

使用者單位授權（USL）｜依使用量計費（UBB）｜對象
---｜---｜---
日常 AI 活用（提問、草稿、摘要、分析等）｜長時間自律進行的工作、包含最先進模型｜Chat、Word/Excel/PowerPoint/Outlook/Teams 的 Copilot、模型選擇
｜Cowork、Code、Autopilot、SharePoint 的新代理功能、Astra・Fable 等模型｜付款方式
使用者每月固定費｜消耗 Copilot Credits

USL 的核心是名為 Auto 的機制，它會根據每次需求，在正確性、速度與成本之間取捨，選出最佳模型與推理深度。使用者也可以自行選擇模型；官方表示 GPT 5.6 與 Sonnet 在合理使用範圍內包含在內，Opus 則以有上限的方式包含（同頁面）。

UBB 是以「加購」的方式附加在 USL 之上，使用 UBB 功能也以 USL 為前提。並且，若管理員沒有設定計費政策，就無法使用 UBB 功能（同頁面）。

※USL 用量達到上限時的提示機制（可選擇回到 Auto 或改以 Credit 繼續）則標示為「即將提供」（同頁面）。

Copilot Credits 的單價與購買方式

Copilot Credits 是 Cowork、Copilot Studio、Work IQ API 等共通使用的計費單位。購買方式包含：按用量付費（Pay-as-you-go）、每月購買固定量的容量套組（Capacity Pack）、以及一次買足一整年的預購方案。

按用量付費（Pay-as-you-go）：1 Credit = 0.01 美元，依使用量付款（按用量付費計量）。
容量套組（Capacity Pack）：每套購買每月 25,000 Credits（容量套組）。
預購方案：預先購買一年內要使用的 Credits（預購方案）。

這裡最需要理解的是：買來的 Credits 不一定只會用在特定功能上。官方文件說明，Cowork、Copilot Studio、Work IQ API 的使用量會以共通的 Copilot Credits 計費，而容量套組的 Credits 也可用於多個服務（管理中心與 Azure 帳單的顯示差異）。

因此，依課金與 Credit 分配方式不同，Copilot Studio 的代理程式與 Cowork 等功能就可能共用同一批 Credits。對於市民開發日益增加的企業來說，事先整理好哪個服務要用哪個部門的預算，我認為是必要的。

Microsoft 365 管理中心可以使用支出政策，設定對象使用者或群組、可使用的服務，以及可消耗的 Credit 上限。針對對象服務，就用這套機制管理使用範圍與支出上限（依使用量計費的管理）。

Microsoft 的思路

Microsoft 的說法是，如果把日常 AI 也做成按量計費，企業就會抑制使用，導致只有少數人能用 AI，所以想讓所有人都用得到的部分，就採固定費率（Evolution of the Copilot pricing model）。此外，Microsoft Learn 也提到，USL 一般適合由 IT 部門購買後提供給整個組織；UBB 則可能更適合由能判斷成本效益平衡的事業部門預算來負擔（USL 與 UBB 說明）。

我認為這個思路本身是合理的，也與我後面要談的個人看法有相近之處。

在大型企業廣泛展開時會在意的地方

接下來是我個人的看法。先把我對各功能的評估整理成表格。

功能｜課金｜全公司展開的看法（2026/09 時點）
---｜---｜---
Chat、Word/Excel/PowerPoint 等 Copilot｜USL｜目前來說仍容易推展
Cowork、最上位模型｜UBB（以 Microsoft 365 Copilot 授權為前提）｜要說服成本效益不容易，可能會縮小對象
Code｜建立時為 UBB，使用時為 Power Apps Premium 或 Copilot Credits｜雖有控管機制，但維運、成本與環境設計的論點較大
Autopilot｜UBB（若要把 Entra 的安全功能延伸到代理程式，需 Agent 365）｜在尚未看清楚存取範圍的控制方式前，會採較保守態度

Chat 與 Office App 部分仍可照舊推展

首先，Chat 與 Word/Excel/PowerPoint 等 Copilot 都屬於 USL 範圍，所以我認為這仍是可照舊在全公司展開的部分。Office in Copilot 讓製作文件的體驗更好，這是非常令人開心的變化。

要廣泛開放最上位模型與 Cowork，並不容易

相較之下，考量這次的價格體系，要把最上位模型與 Cowork 廣泛開放給所有員工，老實說並不容易。

例如，我以前在 Copilot 的 Cowork 裡使用 GPT 的 Sol 系列模型，在大致說明架構與意圖後，請它製作範例簡報，只是要求一些小修正，就消耗了約 6,000 Credits。換算單價大約是 60 美元，單一份簡報加上輕微修改，接近 1 萬日圓。老實說，最近我都不太敢再試同樣的事情了。

而且，上述還只是範例資料。如果是社外簡報等真正要在商務上使用的內容，我認為即使下得再仔細，修改也一定會發生好幾輪。當然，也可以選擇不讓 AI 進行修改、改由自己動手，但坦白說，很多人還是會希望先讓它修到一定程度，再由人做最後少量修正。

如果盡量先用 Copilot Chat 做出草稿，在製作資料時再交給 Cowork 等工具，理論上可以減少修改次數；但老實說，簡報很多內容都是在變成 PowerPoint 之後才會真正看得出來。這點在人工作業時也是一樣的。因此，若要修改 5 到 10 輪，單份資料消耗的 Credits 會再膨脹。

就我自己的使用感受來說，若把我目前用 Claude Code 在做的事情（以我自己的使用方式，每月大約 1.5 萬日圓的方案就足夠）改用 Cowork 來做，月成本可能會高出 10 倍以上。

當然，Claude Code 是個人定額方案，並沒有把大型企業的安全與管理機制也一併納入比較。以我個人來說，Copilot 額外費用較容易被正當化的情境，是那些需要從 Work IQ 把公司內的郵件、會議、檔案脈絡一起帶出來才能完成的工作。如果是靠自己說明的內容加上 Web 搜尋就能組成的簡報，那麼 Cowork 做簡報的成本效益，可能就沒有那麼高。

※我個人甚至認為，若只是做簡報，很多情況其實用 PowerPoint 內建的 Copilot 就夠了，不一定非得用 Cowork。因此，對 Copilot 來說，能否做出適當的功能分工，也會影響成本效益是否划算。

因此，與其把 Cowork 當成因為比 Copilot Chat 或其他生成式 AI 工具更具成本效益，所以要全面開放、積極交辦各種工作，我反而更常看到的是：先找出真的有高成本效益的情境，再篩選出適合這樣使用的人；或接受申請、詢問使用情境後再核准，透過階段式方式逐步擴大使用。

Code 很有魅力，但用在業務上要考慮的事情很多

生成式 AI 可以用來做 App，這非常有吸引力。不過，不論是內部用途還是對外用途，在大型企業中真要拿來做業務，包含安全面在內，我認為門檻還是相當高。

以我的感覺，Code 所做出的 App，接近 Power Apps 的程式化 App（Code Apps）、Vibe Power Apps 之類的東西。如此一來，市民開發多年來一直面對的問題，就會原封不動地浮現出來。

在 Power Apps 的 Canvas App 中，雖然是低程式碼，但多數人其實也是經過學習與反覆試作，在理解 App 的機制後才完成的。

即便如此，當業務要擴大使用時，仍然會遇到：建立者調職或離職之後，App 是否還能持續使用的問題。尤其是從維運角度來看，接手者能否修正錯誤、能否配合需求新增或變更進行修改，這些都會成為是否允許某些業務使用的判斷難題。我想很多企業至今仍一邊推進一邊苦惱，也有些企業因為長年推動教育與制度，總算降低了交接門檻，讓人員更替後仍能勉強維持業務運作。

如果把這個功能當成市民開發的延伸或替代而廣泛使用，那麼從「理解內容」的角度來看，門檻只會更高。無論是接手者，甚至連建立者本身都只能靠 AI 才能維護的 App，究竟要讓它在業務上使用到什麼程度，都需要慎重檢討。因為現在已經可以更容易地做出來，這個論點反而變得更重要。

另一方面，控管機制本身其實做得相當完整。Copilot Managed Runtime 的 App 在建立時，就會自動套用 Entra ID 驗證、條件式存取、防止資料外洩（DLP）原則，以及分享範圍限制，而且所有 App 都會列在 Microsoft 365 管理中心清單中。預設可用的連接器也只限於 18 種可用 Entra ID 驗證的 Microsoft 產品連接器（Copilot Managed Runtime 概要（系統管理員）、預設治理設定）。「做出來的 App 不容易變成沒人知道」這點，我認為是 Microsoft 很大的優勢。

不過，從授權與環境管理的角度來看，還是有些事情要先考慮。整理 2026/09 時點的官方文件後，我的理解如下。

1. 不論建立或使用，都會產生成本

Code 屬於 UBB 對象，建立 App 這件事會消耗建立者的 Copilot Credits（USL 與 UBB 說明）。

使用已建立 App 的一方，則需要持有 Power Apps Premium，或以 Copilot Credits 付款（每次啟動，以及每次 API 呼叫 0.1 Credit）。

另一方面，若只是使用 App，則不需要 Microsoft 365 Copilot 授權（Copilot Managed Runtime SDK 概要：授權、FAQ）。

即使是持有 Power Apps Premium 的使用者，若使用像 Work IQ API 這類另外計費的服務，或超過每日請求上限（每位使用者 24 小時 40,000 筆），也會消耗 Credits（Copilot Managed Runtime 概要：授權與計費、請求上限與配額）。

2. 會為每位建立者自動建立受管理環境

App 會建立在各自建立者的個人開發環境中。

這個環境是透過環境路由（將建立者自動導向其專屬環境的機制）自動建立，且預設會成為受管理環境（加強管理功能的 Power Platform 環境）。

Copilot Managed Runtime 的環境路由不能關閉（Copilot Managed Runtime 的環境路由）。

3. 如果在同一環境建立一般 App 或 Flow，可能需要進階授權

單純建立 Code 的 App，建立者不需要進階授權。

但如果在那個個人開發環境裡建立一般的 Power Apps App 或 Power Automate Flow，則可能需要進階授權（Copilot Managed Runtime 的環境路由）。

原因是，在受管理環境中，所有執行 App 或 Flow 的使用者都需要進階授權（受管理環境的授權）。

※同一頁也指出，沒有受管理環境所需授權的使用者，將自 2027 年 2 月起無法開啟 App。現在仍屬通知階段，但我認為最好提早確認授權配置。

如果要廣泛使用受管理環境，管理點會增加

若要讓 Code 在全公司使用，就等於要讓受管理環境被廣泛使用。如此一來，從治理角度來看，必須留意的點就會增加。

首先是授權。我的理解是，在受管理環境中，即使是沒有使用進階功能的一般 Canvas App，只要是該 App 的使用者，全都需要進階授權。官方文件也明確指出，判斷依據不是 App 類型，而是環境中的使用情況；連使用標準 App 的使用者也包含在內（受管理環境的授權）。

接著讓人在意的是環境中的安全性角色分配。只要被分配到環境建立者以上的角色，就能在該環境自由建立 App。在透過環境路由建立的個人開發環境中，建立者本人會被指派系統管理員角色，且預設可分享給最多 5 位個人（環境路由 FAQ）。當建立的 App 開始被同事使用時，那些同事本來也會進入需要 Power Apps Premium 等授權的狀態。誰該拿到什麼角色、分享範圍要開到哪裡，都需要比以往更有意識地管理（分享限制）。

此外，我個人也對「在個人開發環境中建立的 App 是否就直接給別人用」這件事抱有疑問。過去 Power Platform 的一般做法是：在開發環境做出來的東西，再搬到正式環境公開。Code App 也確實有分享功能（分享 App），但截至 2026/09/26，我查到的資料中，並沒有明確提到這是否代表可直接留在個人開發環境中使用，或是應該搬到正式環境中。這部分我會持續關注後續資訊。

另一個重點是連接器的控管。對 Copilot Managed Runtime 的環境群組來說，我的理解是會透過新 DLP 原則「進階連接器原則（ACP）」來管控連接器。ACP 預設會阻擋所有未允許的連接器，和傳統的資料原則（將連接器分類為「商務」「非商務」「封鎖」）概念不同。若與傳統資料原則並用，兩者都會被評估，並套用較嚴格的設定。此外，ACP 目前僅適用於已認證連接器，客製化連接器與 HTTP 連接器仍需用傳統資料原則管理（進階連接器原則）。

對一直以傳統資料原則運作的企業來說，除了角色與分享範圍管理外，還得同時看兩套連接器控管機制。這會帶來不少額外管理成本，因此在評估推展時就應先納入考量。

此外，若企業已經在 Power Platform 中設定了環境路由，也需要確認其適用範圍。例如，若只針對特定開發者群組，那麼不在那個群組中的員工，就無法在 Copilot Managed Runtime 上建立 Code App。若要讓他們能使用，就必須把他們加入既有規則的對象群組，或新增一條以「所有人」為對象的規則。

不過，據說以「所有人」為對象的規則是不能刪除的。擴大對象時，應先與 Power Platform 管理員確認：要讓誰建立 App、套用哪個環境群組的管理規則（Copilot Managed Runtime 的環境路由）。

總結來說，雖然已經具備控管機制，但建立與使用都需要 Copilot Credits 或 Power Apps Premium，也會牽涉到既有 Power Platform 的環境設計與管理負擔，所以我仍覺得全公司推展的門檻很高。

Autopilot 自由度越高，越需要控制

Autopilot 被發表為可被賦予角色與目標、並持續交辦工作的代理程式。雖然 Cowork 也有定期執行或事件觸發的功能，但 Autopilot 的特徵是擁有自己的 ID、記憶、電腦與工作區，並在雲端持續活動（官方發表、Cowork FAQ）。

也正因為它能被委任持續性的角色，才更需要管理「允許存取哪些資訊」「允許自動執行到什麼程度」「在哪個階段需要人類確認」這些事情。

不過，有專用電腦並不代表它就能原封不動地操作使用者 PC 上可存取的所有網站與 App。像是必須連上內部網路才能使用的 Web App、檔案伺服器，或安裝在 PC 上的業務應用程式，它是否能處理，這點我也很在意。以 2026/09/26 時點查到的公開資訊來看，尚未確認新 Autopilot 的具體連線方式，以及限制存取目標與操作內容的設定。

另外，舊 Scout 的文件中有描述它可在使用者 PC 上操作檔案與瀏覽器；但這次的 Autopilot 是發表為在雲端運作，因此是否能直接套用舊 Scout 的規格，還需要確認（舊 Scout FAQ）。

在管理基礎方面，現在有 Microsoft Entra Agent ID 可用來管理代理程式的 ID 與權限；若要把 Entra 的安全功能延伸到代理程式，例如條件式存取，則需要 Agent 365。Agent 365 包含在 Microsoft 365 E7 中，因此是否會有額外費用，仍需依既有合約與想使用的管理功能來確認（Microsoft Entra 授權）。

我認為這些管理基礎的存在是很大的優勢。但另一方面，真正想交辦的業務，到底是以誰的權限、存取哪些地方、能自動操作到什麼程度，仍然必須先確認。包含按量計費在內，都應該依這些具體規格來決定使用對象與交辦範圍。

AI 的課金應視為「管理的延伸」

以事業部門預算來思考的方向

我從 Cowork 推出以來，就一直對客戶說：代理式 AI 的課金，不是 IT 部門拿預算來扛，而應該更像是由事業部門或現場部門，以管理的延伸來看待，像是請外包或派遣一樣，把它納入選項。換句話說，AI 已經進步到可以真的交辦工作了。

這次 Microsoft 也明確提出「UBB 應由事業部門預算來看待」，我覺得跟我的想法很接近。

只是，問題也在於：實際上有多少人能把它用到那個程度？又有多少組織真的能用這個思路確實編列預算？這還是個課題。

能讓外包或派遣順利運作的部門，通常是那種有人能把工作切分出來、清楚說出期待成果，並在交付後進行審查與修正的部門。把工作交給 AI 也是一樣，需要完全相同的能力；我認為瓶頸與其說是 AI 操作技巧，不如說是「交辦能力」，也就是管理能力本身。

企業要廣泛使用的前提條件，或許是「估價」

這是本文我最想傳達的部分。

「選擇」這件事本身，仍是人類在配合 AI

我覺得現在的生成式 AI，使用者需要做選擇的地方還非常多。要選哪個模型、要用 Chat、Cowork、Code、Autopilot 哪一種來交辦，都是需要判斷的地方。而如前所述，選擇的模型與功能不同，費用體系也不同，因此現階段「會選」變得非常重要，而且這個能力是壓在使用者身上的。

例如，為了控制成本，可以先用 Chat（USL 範圍）把架構與大綱想清楚，再讓 Cowork 專注在生成，最後的細部修正交給 PowerPoint 的 Copilot。這種分工是可行的。但我也在想，這些分工方式本身，原本是不是不應該要求使用者自己記住。

就這點來說，我認為目前仍是人類在配合生成式 AI。生成式 AI 的目標，應該是像交代人類一樣，把工作直接託付出去。如此一來，若沒有特殊知識就無法順利使用，某種程度上就還沒達到目標。

模型選擇正是最典型的例子。所以才會出現 Auto 這套機制。不過老實說，Auto 是否已經夠好、是否已經讓人覺得「只用 Auto 就沒問題」了，我自己也還是有疑問。另外，從我個人來看，Chat、Cowork、Code、Autopilot 等功能，也許最終都應該朝著「連選都不用選」的方向前進。

即使未來自動分派真的足夠成熟，我認為它解決的也最多只是「選擇的麻煩」而已。若看不見背後到底選了什麼、要花多少錢，委託的一方還是無法判斷能不能放心交給它。換句話說，減少選擇的麻煩，與顯示費用並取得同意，是兩回事。

選法會讓費用大幅改變，而且不試不知道

如果不先學會怎麼選，費用就會大幅反映在帳單上。而且，往往要真的試過才知道會花多少。

如前所述，我自己試作一份簡報就曾花掉數千個 Credit，折合日圓接近 1 萬。若是一家擁有數萬名員工的企業，很多人各自都去試一次，費用恐怕會比想像中高出許多。而且，如果試做出來的內容最後沒有用在業務上，那就會變成只花了錢，卻沒有產生價值。

能否像請人做事那樣交辦

當我們請人做事，不論是派遣還是外包，通常都會產生估價。

接案方會確認需求、作業範圍、前提條件、期待成果與時程，並提出做法與估價；如果有多種做法，也會列出各自的優缺點與費用差異。
委託方會依照目的與費用選擇做法，並就作業範圍、預算與期待成果達成共識。
如果中途快超出預算，或前提條件改變，就會及早提出討論。

正因為有這個流程，委託方即使在非專業領域，也能判斷「值不值得花這筆錢」以及「要做到什麼程度」。畢竟，對於自己不熟悉的工作，要單憑自己去判斷什麼樣的做法合適、需要多少成本，並不容易。

如果生成式 AI 也能在被交辦的當下，直接告訴你做法與暫定估價，那麼使用者就能依成本效益判斷要不要交辦，並思考是否需要另外申請預算。比如請它做簡報時，希望它能像這樣回應：

根據您的目的，進行方式可考慮以下三種：

先邊對話邊一起釐清架構草案（在授權範圍內，不會產生額外費用）

根據架構草案製作整份資料（暫定估價：〇〇～〇〇 Credits）

連同公司內部相關資料與會議內容也一起查閱後，製作整份資料（暫定估價：〇〇～〇〇 Credits）

請問要採用哪一種方式？若繼續進行，當消耗接近〇〇 Credits 時，我會先通知您一次。另外，如果途中前提改變，導致估價可能大幅變動，我也會隨時告知。

若能這樣回覆，即使使用者不懂 Chat、Cowork、Work IQ 等功能名稱，也能根據目的與成本比較，決定要用哪種方式交辦。

而這樣的判斷，正是有管理能力與專業知識的人最擅長的事。依據估價與成本效益，判斷要不要交辦，也就是要不要發包。若是以這類使用者為前提，那麼背後到底用了哪種功能，某些情況下其實不一定非知道不可，這才是原本應有的樣子。

這不是在說要限制哪些人能用。看著估價來決定要不要發包，對於平常就負責外包或費用審批的管理職來說，本來就是日常判斷。若能提供估價，使用所需的能力就會從「懂 AI 功能」轉變為「做發包判斷」，而原本就具備這種能力的許多人，理論上都能使用。

目前也已經可以在使用後確認 Credit 消耗量，或由管理員設定上限。這次的 FinOps for AI 也宣布，讓使用者可在 Copilot 中查看自己的用量、剩餘量與使用紀錄，讓使用者提出追加使用申請並串接到既有核准流程，以及依部門或群組決定可使用的 AI 模型，並反映到 Auto 的選擇範圍中（官方部落格、USL 與 UBB 說明）。另外，SharePoint 的 Copilot 也有在進入會消耗 Credits 的進階作業前，先請使用者確認的機制（SharePoint Copilot：授權與 Copilot Credits）。我認為這些都是很值得感謝的方向。不過，如果只靠事後才知道、或到上限才停止，委託方就很容易變成「因為看不懂所以不用」或「只能硬記各種分工方式」兩種情況之一。

AI 代理程式在作業中會自行判斷要讀取多少資訊，因此要做精準估價應該很難。不過，人類的估價本來也就有範圍。只要能提供範圍與確認時點，就應該已經足夠成為判斷依據。

以我個人的看法，與其讓使用者自己去選模型或功能，不如依目的提供做法與暫定估價，並在超過上限或前提改變時即時通知；這才是生成式 AI 要能更廣泛在企業中使用的前提條件。