はじめに
2026年9月25日、Microsoft から「新しい Copilot」が発表されました。Copilot アプリそのものの形が変わる大きな発表で、あわせて料金体系も「ユーザー単位のライセンス」と「利用量に応じた課金」の2本立てに整理されています。
発表の内容自体は、個人的にも非常にワクワクするものでした。一方で、日頃からお客様の Copilot や Power Platform の推進を支援している立場からすると、「これを全社に広く展開できるか」という観点では、正直なところ考えておいた方がよいことも多いと感じています。
本記事では、まず今回の発表内容と料金体系を公式情報ベースで整理し、そのうえで、組織 (特に大企業) で展開する際に個人的に気になっている点を書きます。最後に、生成 AI が企業で広く使われるための前提条件について、私なりの考えを書いてみたいと思います。
※本記事の内容は 2026/09/26 時点の公開情報と、私個人の検証・見解に基づくものです。多くの機能は Frontier プログラムやプレビューからの提供となるため、今後変わる可能性がある点はご注意ください。
参考にした主な情報は以下の通りです。
- Introducing the new Copilot with Home, Code and Autopilot(The Official Microsoft Blog、2026年9月25日)
- Understanding the user subscription license (USL) and usage-based billing (UBB)(Microsoft Learn、2026年9月25日更新)
- Evolution of the Copilot pricing model(Microsoft Tech Community、2026年9月)
- 新しくなったCopilot を発表 – Home、Code、Autopilot が登場(吉田の備忘録、2026年9月26日)
吉田さんの記事は、発表内容を技術に詳しくない方にも分かりやすく整理されていて、とても参考になりました。全体像をつかみたい方は、あわせて読んでいただくと良いかと思います。
今回の発表の全体像
ひとことで言うと
個人的な感覚では、Claude のデスクトップアプリや ChatGPT のアプリのように「Chat(話す)」「Work(任せる)」「Code(作る)」が一つのアプリにまとまり、そこに Microsoft 365 のセキュリティと管理の仕組みが乗った、という印象です。
発表された主な機能は以下の通りです。
| 名前 | 概要 | 提供時期(発表時点) |
|---|---|---|
| Home | Chat と Cowork がまとまった Copilot の新しい入り口 | 今後数週間のうちに Frontier から |
| Office in Copilot | Word・Excel・PowerPoint を Copilot の中でそのまま作成・編集 | 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 は、作りたいものを普段の言葉で説明すると、ちょっとしたアプリやダッシュボード、ウィジェットなどを作ってくれる機能です。GitHub Copilot と同じ技術をベースに、隔離された環境(サンドボックス)で動きます。
作ったアプリは Copilot Managed Runtime 上で、自社の Microsoft 365 環境(テナント)の中で動かせます。この基盤は Cowork、Code、Copilot Studio で作られたアプリを支えるものと説明されています。
Autopilot
Autopilot は、これまで Scout と呼ばれていた機能の新しい名前です。名前、役割、ゴールを与えると、その目的に沿ってチャネルの状況を確認し、関係者へのフォローアップや定期的な作業などを継続して行うものとして発表されています。
Cowork が具体的な仕事を依頼して成果物を受け取る使い方を中心としているのに対し、Autopilot は、役割を与えて継続的な活動を任せるイメージです。ただし、Cowork にも定期実行やイベントをきっかけに動く機能があるため、「自動で動くかどうか」だけで分かれるわけではありません(Cowork の FAQ)。
Autopilot は、テナント内に専用の ID、記憶、コンピューター、作業スペースを持ち、クラウド上で動作すると説明されています。利用者が不在の間も作業を続けられ、権限・監査・ガバナンスの仕組みの下で管理される点が特徴です(公式発表)。
個人的に期待する用途の一つが、ハンズオントレーニングの資料作成です。例えば、シナリオや操作手順を伝えると、対象のサービスを実際に操作し、スクリーンショットを撮影して、手順付きのスライド資料にまとめてくれる、といった使い方です。これは現時点で実現を確認したものではありませんが、任せられるようになれば、大きな効果がありそうです。
ただし、数百ページの資料を作る場合、完成までにかかる費用と、人による確認・修正がどれだけ残るかで評価は変わります。仮に1〜2万クレジット程度で期待する品質に仕上がり、作成やレビューの時間を大幅に減らせるなら、有力な選択肢になると思います。一方、数十万クレジットを消費したうえに、多くの確認や修正が必要であれば、現時点では人が作成するという判断もあり得ます。なお、これらのクレジット数は実測や公式の見積もりではなく、費用対効果を考えるための仮定です。
実際にどのサイトやアプリを操作できるのか、誰の権限で動き、どの程度の費用がかかるのかは、今後確認したいところです。企業で利用する際のアクセス範囲や管理上の論点については、後段で整理します。
その他
ほかにも、Microsoft IQ(Work IQ、Fabric IQ、Foundry IQ、Web IQ をまとめた仕組み)による参照範囲の拡大として、Fabric IQ の Chat・Cowork での一般提供や、Dynamics 365 と Power Platform(Dataverse)のデータ参照のパブリックプレビューが発表されています。プラグインを一元管理するプラグインレジストリ、今後提供予定の Today(10月にプライベートプレビュー)や @Copilot in Teams(今月末までにプライベートプレビュー)もあります。詳細は冒頭の参考記事をご覧ください。
料金体系の整理
USL と UBB の2本立て
今回、AI の仕事を「日常的な AI(Everyday AI)」と「高度な AI(Advanced AI)」の2つに分け、それぞれに対応する支払い方法が整理されました(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 に戻すか、クレジットで継続するかを選べる仕組み)は「近日提供」とされています(同ページ)。
Copilot Credits の単価と買い方
Copilot Credits は、Cowork、Copilot Studio、Work IQ API などで共通して使われる課金単位です。購入方法には、使用した分を支払う従量課金(Pay-as-you-go)、毎月一定量を購入するキャパシティパック、1年分をまとめて購入する事前購入プランがあります。
- 従量課金(Pay-as-you-go):1クレジット=0.01ドルで、使用量に応じて支払います(従量課金メーター)。
- キャパシティパック:1パックあたり月25,000クレジットを購入します(キャパシティパック)。
- 事前購入プラン:1年間で使用するクレジットを事前に購入します(事前購入プラン)。
ここで押さえておきたいのは、購入したクレジットが、特定の機能だけで使われるとは限らない点です。公式ドキュメントでは、Cowork、Copilot Studio、Work IQ API の使用量は共通の Copilot Credits として請求され、キャパシティパックのクレジットも複数のサービスで利用できると説明されています(管理センターと Azure 請求書の見え方の違い)。
そのため、課金やクレジットの割り当て方によっては、Copilot Studio のエージェントと Cowork などが共通のクレジットを消費することになります。市民開発でエージェントが増えている企業ほど、どのサービスに、どの部門の予算を使うのかを、事前に整理しておく必要があると考えます。
Microsoft 365 管理センターでは、支出ポリシーを使い、対象のユーザーやグループ、利用できるサービス、消費できるクレジットの上限を設定できます。対象サービスについては、この仕組みで利用範囲と支出上限を管理します(利用量に応じた課金の管理)。
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 アプリの部分はこれまで通り展開できる
まず、Chat や Word・Excel・PowerPoint などの Copilot は USL の範囲なので、これまで通り全社に展開できる部分だと考えます。Office in Copilot で資料作成の体験が良くなるのは、純粋に喜ばしい変化です。
最上位モデルと Cowork を広く開放するのは簡単ではない
一方で、最上位モデルや Cowork については、今回の価格体系を踏まえると、全従業員に広く開放するのは、正直そんなに簡単ではない認識です。
例えば、以前 Copilot の Cowork で GPT の Sol 系モデルを使い、構成や意図をそれなりに言語化したうえでサンプルの資料作成を依頼し、少し修正をお願いしただけで約6,000クレジットを消費しました。単価で計算すると約60ドル、1本の資料と軽い修正で1万円弱です。日々変わっていくものと思いますし、現在は、同じモデル使っても価格は下がっているものと考えられますが、正直、最近は怖くて同じことを試せていないです。
また、上記はサンプル資料の作成でしたが、社外向けの資料など、本当にビジネスで使うものを想定すると、どれだけ丁寧に指示を出しても手直しは複数回発生すると思っています。手直し自体を AI に行わせず、自分でやるという手段もありますが、正直、ある程度のところまでは何回か指摘をしながら修正までして、人による修正は最小限にしたいという人も多いと思います。
出来るだけ原案は Copilot Chat で作成して、資料作成時に Cowork 等に依頼すれば修正回数は減らせると思いますが、正直、資料は PowerPoint として形になって初めて見えてくる部分が多いと思います。これは人に頼んだ場合も同じです。そのため、修正を5回から10回回すとなると、1本あたりのクレジットはさらに膨らむことになります。
あくまで私の使い方での体感ですが、資料作成等について、Claude Code(私の使い方で月1万5千円程度のプランで十分)で行っていることを Cowork でやろうとすると、月当たりのコストは10倍以上かかってしまうかもしれないと感じています。
もちろん、Claude Code は個人の定額プランであり、大企業のセキュリティや管理の仕組みまで含めた比較ではありません。個人的に、Copilot の上乗せ費用が正当化しやすいのは、Work IQ で社内のメールや会議、ファイルの文脈を引いてこないと作れないような仕事だと考えます。自分が話した内容と Web 検索で組み立てる資料であれば、Cowork での資料作成の費用対効果はそれほど高くないかもしれません。
※個人的に、そもそも資料作成だけなら、Cowork 使うより PowerPoint の Copilot でいいケースも多いと思っています。そのため、Copilot の場合その使い分けを出来るかどうかも費用対効果が高いかどうかに関わってくると思います。
そのため、Cowork は Copilot Chat やその他の生成 AI ツールと比較して費用対効果が高いため、全従業員に広く開放して積極的に何でもお任せするという展開方針より、本当に費用対効果が高いシナリオを見極めて、その上でそのような使い方ができる人を選別する、申請を受け付け、どのようなシナリオで利用するかヒアリングして承認するなど、段階的に利用を広げていくという展開方針の方が多い印象です。
Code は魅力的だが、業務で使うには考慮することが多い
生成 AI でアプリを作れるのは非常に魅力的です。ただ、社内向けにしても社外向けにしても、大企業で実際に業務に使うとなると、セキュリティ面も含めてハードルはそれなりに高いと感じています。
個人的な感覚では、Code で作るアプリは Power Apps のコードアプリ(Code Apps)、Vibe Power Apps 等に近いものと捉えています。そうなると、市民開発で長年向き合ってきた論点がそのまま出てきます。
Power Apps のキャンバスアプリでは、ローコードとはいえ、学習や試行錯誤を重ね、アプリの仕組みをある程度理解しながら作成してきた人が多いと思います。
それでも、業務での利用を広げる際には、作成者の異動や退職後も使い続けられるかが課題になってきました。特に、引き継いだ人が不具合を修正したり、要件の追加・変更に合わせて改修したりできるかという保守の観点から、どの業務まで利用を認めるか、その判断や運用に苦労してきた企業も多いのではないかと思います。現時点で悩まれながら進めている企業もある認識ですし、推進、教育を長年に渡って続けることで引継ぎなどのハードルがようやく下がってきた、担当者が変わってもなんとか業務継続できているというケースも出てきた印象です。
市民開発の延長または代替でこちらの機能を広く利用する場合、中身を理解するという観点では更にハードルが上がると思います。引き継がれた場合はもちろん、作成者ですら (AI に頼みながらしか) 保守できないアプリを、業務でどこまで使わせるのか検討する必要があります。AI で簡単に作れるようになった分、この論点はむしろ重要度が増していると思っています。
一方で、統制の仕組み自体はかなり作り込まれています。Copilot Managed Runtime のアプリは、作成時点から Entra ID による認証、条件付きアクセス、データ損失防止(DLP)ポリシー、共有範囲の制限が自動で適用され、すべてのアプリが Microsoft 365 管理センターの一覧に並びます。既定で使えるコネクタも、Entra ID で認証する Microsoft 製の18種類に絞られています(Copilot Managed Runtime の概要(管理者向け)、既定のガバナンス設定)。「作られたアプリが誰にも把握されない」状態になりにくいのは、マイクロソフトならではの強みと思います。
ただし、ライセンスと環境管理の面では考えておくべきことがあります。2026/09 時点の公式ドキュメントを整理すると、以下のような流れになるという認識です。
1. 作るときも使うときも費用がかかる
Code は UBB の対象で、アプリを作る分は作成者の Copilot Credits を消費します(USL と UBB の解説)。
作ったアプリを使う側は、Power Apps Premium を持っているか、Copilot Credits で支払う(起動ごとと、API 呼び出し1回あたり0.1クレジット)かのどちらかが必要です。
一方で、アプリを使うだけなら Microsoft 365 Copilot のライセンスは不要とされています(Copilot Managed Runtime SDK の概要:ライセンス、よくある質問)。
Power Apps Premium を持つ利用者でも、Work IQ API など別に課金されるサービスを使う場合や、1日あたりのリクエスト上限(1ユーザー24時間あたり40,000件)を超えた場合はクレジットを消費します(Copilot Managed Runtime の概要:ライセンスと課金、リクエストの上限と割り当て)。
2. 作成者ごとにマネージド環境が自動で作られる
アプリは作成者ごとの個人用開発環境に作られます。
この環境は、環境ルーティング(作成者を自分専用の環境に自動で振り分ける仕組み)で自動作成され、既定でマネージド環境(管理機能を強化した Power Platform 環境)になります。なお、私の場合、既に個人用開発環境があったため、そちらの環境が使われました。
Copilot Managed Runtime 向けの環境ルーティングは、オフにできません(Copilot Managed Runtime の環境ルーティング)。
3. 同じ環境で通常のアプリやフローを作るとプレミアムライセンスが必要になる
Code のアプリを作るだけであれば、作成者にプレミアムライセンスは不要です。
ただし、その個人用開発環境で通常の Power Apps のアプリや Power Automate のフローを作ると、プレミアムライセンスが必要になる場合があるとされています(Copilot Managed Runtime の環境ルーティング)。
マネージド環境では、アプリやフローを実行する利用者全員にプレミアムライセンスが必要になるためです(マネージド環境のライセンス)。
※同ページによると、マネージド環境で必要なライセンスを持たない利用者は、2027年2月以降アプリを開けなくなると案内されています。現在は通知の段階ですが、ライセンスの割り当ては早めに確認しておくのが良いかと思います。
マネージド環境を広く使わせる場合に増える管理ポイント
Code を全社で使わせるということは、マネージド環境を広く使わせることでもあります。そうなると、ガバナンスの観点で気にしておくべきポイントが増えてくると考えます。
まずライセンスです。マネージド環境では、プレミアム機能を使っていない通常のキャンバスアプリであっても、そのアプリを使う利用者全員にプレミアムライセンスが必要になる認識です。公式ドキュメントでも、対象はアプリの種類ではなく環境内での利用であり、標準的なアプリを使う利用者も含まれると明記されています(マネージド環境のライセンス)。
ここで気になるのが、環境へのセキュリティロールの割り当てです。環境作成者以上のロールが割り当たっていると、その環境で自由にアプリを作れます。環境ルーティングで作られる個人用開発環境では、作成者本人に管理者ロールが割り当てられ、既定では個人5人までアプリを共有できる設定になっています(環境ルーティングのよくある質問)。作ったアプリを同僚が使い始めると、その同僚にも本来は Power Apps Premium などが必要な状態になっていきます。誰にどのロールを渡すのか、共有をどこまで許すのかを、これまで以上に意識して管理する必要があると考えます(共有の制限)。
また、そもそも個人用開発環境で作ったアプリを、そのまま他の人に使ってもらう前提でよいのか、という点は個人的に疑問に感じています。これまでの Power Platform では、開発用の環境で作ったものを本番用の環境に移して公開する、という考え方が一般的でした。Code のアプリにも共有の機能自体は用意されていますが(アプリの共有)、個人用開発環境のまま使ってよいという判断なのか、本番用の環境に移す考え方になるのかについては、2026/09/26 時点で調べた範囲では言及が見当たりませんでした。今後の情報に注目したいと思います。
もう一つがコネクタの制御です。Copilot Managed Runtime の環境グループでは、新しい DLP ポリシーである「高度なコネクタポリシー(ACP)」でコネクタを制御する認識です。ACP は、許可したコネクタ以外を既定ですべてブロックする方式で、従来のデータポリシー(コネクタを「ビジネス」「非ビジネス」「ブロック」に分類する方式)とは考え方が異なります。従来のデータポリシーと併用している間は両方が評価され、より厳しい設定が適用されます。また、ACP は現時点では認定コネクタのみが対象で、カスタムコネクタや HTTP コネクタは引き続き従来のデータポリシーで管理する必要があります(高度なコネクタポリシー)。
これまで従来型のデータポリシーで運用してきた企業からすると、ロールと共有範囲の管理に加えて、2つのコネクタ制御の仕組みを並行して見ていくことになります。少なからず追加の管理コストが発生する点は、展開を検討する段階で考慮に入れておく必要があると考えます。
上述の通り、私の場合、既に個人用開発環境があったため、そちらの環境が使われました。その結果、該当環境について、高度なデータ損失防止 (DLP) ポリシーが有効になり、沢山のコネクタ、アクションが既定でブロックされているため、既存の Power Automate のフローが大量に DLP ポリシー違反になってしまいました。
このように、既に個人用開発環境を使っている場合は注意が必要です。個人的に、Power Apps Premium のライセンスを潤沢に持っていない場合、環境ルーティング、マネージド環境、高度なデータ損失防止 (DLP) ポリシーは利用していないと考えられるため、Code の機能を利用する場合、Power Platform 側の既存の環境、アプリやフローに影響ないかやそれらを利用するにあたってのライセンスをどうするかを事前に検討、設計、設定しておくことが必要と考えます。
また、すでに Power Platform で環境ルーティングを設定している企業では、その対象範囲も確認が必要です。例えば、特定の開発者グループだけを対象にしている場合、そのグループに含まれない従業員は、Copilot Managed Runtime 上で動く Code のアプリを作成できません。利用させるには、既存のルールで対象となっているグループにその従業員を追加するか、「全員」を対象にしたルールを追加する必要があります。
ただし、「全員」を対象にしたルールは削除できないとされています。対象者を広げる際は、誰にアプリを作らせ、どの環境グループの管理ルールを適用するかを、Power Platform の管理者と確認しておく必要があると考えます(Copilot Managed Runtime の環境ルーティング)。
結果として、統制の仕組みは用意されているものの、作成にも利用にも Copilot Credits や Power Apps Premium が必要になり、既存の Power Platform の環境設計や管理の手間にも関わってくるため、全社展開のハードルはまだ高い印象です。
Autopilot は自由度が高いからこそ制御が求められる
Autopilot は、役割や目標を与え、継続的に仕事を任せるエージェントとして発表されています。Cowork にも定期実行やイベントをきっかけに動く機能はありますが、Autopilot は独自の ID、記憶、コンピューター、作業スペースを持ち、クラウド上で活動を続ける点が特徴として示されています(公式発表、Cowork の FAQ)。
このように、継続的な役割を任せられるようになるほど、「どの情報にアクセスさせるか」「どの操作まで自動で実行させるか」「どの段階で人の確認を求めるか」といった管理が重要になると考えます。
ただし、専用のコンピューターを持つからといって、利用者の PC からアクセスできるサイトやアプリを、そのまますべて操作できるとは限りません。例えば、社内ネットワークに接続しないと使えない Web アプリやファイルサーバー、PC にインストールされた業務アプリに対応できるのかは、気になるところです。2026/09/26 時点で確認した公開情報では、新しい Autopilot の具体的な接続方式や、アクセス先・操作内容を制限する設定までは確認できませんでした。
なお、旧 Scout のドキュメントには、利用者の PC 上でファイルやブラウザーを操作する説明があります。一方、今回の Autopilot はクラウド上で動作すると発表されているため、旧 Scout の仕様をそのまま当てはめてよいかは確認が必要です(旧 Scout の FAQ)。
管理基盤としては、エージェントの ID や権限を管理する Microsoft Entra Agent 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 等もそもそも選ばなくてよくなることが望ましいかもしれないと思っています。
更に、仮に自動の振り分けが十分に機能するようになったとしても、それで解決するのは「選ぶ手間」までではないかと考えています。裏で何が選ばれ、それにどれくらいの費用がかかるのかが見えないままでは、依頼する側は任せてよいかを判断できません。選ぶ手間をなくすことと、費用を示して合意を取ることは、別の話だと思っています。
選び方で費用が大きく変わり、しかもやってみないと分からない
選び方を覚えておかないと、費用に大きく跳ね返ります。しかも、実際にやってみるまで、どれくらいかかるかは分かりません。
前述の通り、私自身、試しに作った資料で数千クレジット、日本円にして1万円近くかかったことがあります。これを何万人もの従業員がいる企業で、多くの人がそれぞれ試したとすると、思った以上の費用になると思います。しかも、試しに作ったものが業務で使われなければ、何の価値も生み出さず、費用だけがかかったということも起こりうると考えます。
人に仕事を頼むときと同じ流れで任せられるか
人に仕事を頼むとき、派遣でも業務委託でも、普通は見積もりが発生します。
- 依頼を受けた相手が、要件や作業範囲、前提条件、期待する成果、スケジュールなどを確認し、進め方と見積もりを提示する。複数のアプローチが考えられる場合は、それぞれのメリット・デメリットや費用の違いも示す。
- 依頼する側が、目的と費用に照らしてアプローチを選び、作業範囲や予算、期待する成果について合意する。
- 途中で予算を超えそうになったり、前提条件が変わったりした場合は、早めに相談してもらう。
この流れがあるからこそ、依頼する側は、専門外の分野でも「お金をかけてまでやるか」「どこまで進めてもらうか」を判断できます。専門外の仕事について、どのような進め方が適切で、どれくらいの費用がかかるのかを、依頼する側だけで見極めるのは難しいからです。
生成 AI にも同じように、依頼した段階で進め方と暫定の見積もりを示してもらえれば、費用対効果を踏まえて任せるかどうかを判断し、必要な予算の確保や追加申請も検討できます。たとえば、資料作成を頼んだときに、次のように返ってくるイメージです。
ご依頼の目的に照らすと、進め方として次の3つが考えられます。
- まずは会話しながら構成案を一緒に詰める(ライセンスの範囲内で、追加の費用はかかりません)
- 構成案をもとに、資料一式を作成する(暫定の見積もり:〇〇〜〇〇クレジット)
- 社内の関連資料や会議の内容も調べたうえで、資料一式を作成する(暫定の見積もり:〇〇〜〇〇クレジット)
どの方法で進めましょうか。進める場合は、〇〇クレジットを超えそうになった時点で一度ご相談します。また、途中で前提が変わり、見積もりが大きく変わりそうな場合も、その都度お知らせします。
このように返ってくれば、依頼する側は Chat、Cowork、Work IQ といった機能の名前を知らなくても、目的と費用を見比べて「どの方法で任せるか」を選べます。
そして、この判断こそ、マネジメント力や専門性を持っている人が得意とするところです。見積もりと費用対効果を見て、任せるかどうか、つまり発注するかどうかを判断する、ということです。そうした人が使う前提であれば、裏でどの機能が使われているかは、場合によっては知らなくても良いのが本来の姿ではないかと思っています。
これは、使える人を限定するという話ではありません。見積もりを見て発注するかどうかを決めることは、外注や経費の承認をしている管理職の方であれば、日頃から行っている判断です。見積もりが示されるようになれば、求められる力が「AI の機能の知識」から「発注の判断」に置き換わり、すでにその力を持っている多くの人が使えるようになるのではないかと考えています。
現在も、使った後にクレジット消費量を確認したり、管理者が上限を設定したりすることはできます。今回の FinOps for AI でも、利用者が自分の使用量や残り、利用履歴を Copilot の中で確認できるようにすること、利用者からの追加利用の申請を既存の承認フローにつなぐこと、部署やグループごとに使える AI モデルを決めて Auto が選ぶ範囲にも反映することが発表されています(公式ブログ、USL と UBB の解説)。また SharePoint の Copilot では、クレジットを消費する高度な作業に入る前に、利用者に確認を求める仕組みがあります(SharePoint の Copilot:ライセンスと Copilot Credits)。これらはとてもありがたい方向だと思います。ただ、事後に分かる、上限で止まる、という仕組みだけだと、依頼する側は「よく分からないから使わない」か「使い分けを覚える」かのどちらかになりやすいのではないかと感じています。
AI エージェントは作業中にどれだけの情報を読み込むかを自分で判断するため、正確な見積もりは難しいと思います。ただ、人間の見積もりにも幅があるものです。レンジと確認のタイミングさえ示してもらえれば、十分に判断材料になるはずです。
個人的には、利用者にモデルや機能を選ばせるのではなく、目的に照らして進め方と暫定の見積もりを示し、上限や前提の変化を都度知らせてくれることこそが、生成 AI がもう少し広く企業で使われるための前提条件ではないかと考えています。
まとめ
今回は、2026年9月25日に発表された新しい Copilot と料金体系を整理し、大企業で広く展開する際の課題について考えてみました。
- Chat と Office アプリの Copilot は USL の範囲で、これまで通り全社展開しやすい
- Cowork、Code、Autopilot、最上位モデルは UBB で、価格・ライセンス・統制の面から、全従業員への開放は現時点では難しいと考える
- AI の課金を事業部門の予算で考える方向性は Microsoft の考え方とも近いが、使いこなせる人の数と予算化には課題がある
- モデルや機能を「選ぶ」こと自体が、まだ人が AI に合わせている状態で、選び方次第で費用が大きく変わり、やってみるまで分からない
- 人への依頼と同じように「進め方と見積もりの提示、合意、超過前の相談」ができることが、広く使われるための前提条件ではないか
発表内容自体は本当に素晴らしく、今後の進化にも大いに期待しています。だからこそ、「誰に、どの環境で、どの予算で、どこまで許すか」を先に決めておくことが、機能を活かすうえで重要になると考えます。
私の見方が偏っている部分もあるかもしれないので、「うちではこう運用している」「こういう工夫でコストを抑えられた」といった情報が集まることも期待しています。本記事が、新しい Copilot の展開を検討されている方のお役に立てば幸いです。




