Copilotが刷新。定額の席代とは別に従量課金へ。発注の線を引く3点

社内で使っている AI が「月いくらの定額」だと思っていると、見積書の運用費を読み違える。2026 年 9 月 25 日に発表された Microsoft Copilot の刷新は、定額の席代と、使った分だけの従量課金を明確に分けた内容だった。

発注側にとっての意味は 2 つある。1 つは、社内の非開発者が自分でアプリを作れる範囲が広がったこと。もう 1 つは、AI の稼働そのものが従量課金になったこと。 どちらも「どこまで開発を発注するか」の線を引き直す話である。

投入口だけの密閉箱と、計量メーターの付いた皿

公表されている事実

Microsoft の公式ブログ（2026 年 9 月 25 日）に書かれている内容を整理する。

名称	内容
Home	起点となる画面。Chat と Cowork を統合し、Word・Excel・PowerPoint を Copilot の中に組み込む。アプリを行き来せずに文書・表計算・スライドを作成・更新できる
Code	自然言語で説明すると、Copilot が方式を選んでアプリやダッシュボード、常駐ウィジェットを作る。GitHub Copilot と同じ基盤技術を使い、隔離された環境で動く
Autopilot	名前・役割・目標を与えると継続的に働くエージェント。チャンネルの監視、スレッドの追跡、繰り返しの業務を、指示を待たずに実行する。独自の ID・メモリ・計算環境・作業領域を持つ
Copilot Managed Runtime	作ったコードを自社の Microsoft 365 環境の中で動かすための実行基盤。IT 部門が統制する。プレビュー
管理機能	権限・監査・統制、プラグインの一元管理レジストリ、支出とモデル可用性と承認フローの管理ポリシー、費用管理（FinOps）
課金	Chat と Office はユーザー単位のサブスクリプション（USL）。Cowork・Code・Autopilot といったエージェントの稼働は従量課金（UBB）
提供時期	Home と Code は Frontier プログラムで数週間のうちに順次。Autopilot は月末にプライベートプレビューを拡大

押さえておきたいのは最後の 2 行である。機能の一部はまだプレビューで、課金は定額と従量の二階建てになっている。

論点 1. 「作れる人」が増えると、発注する範囲が変わる

Code は、自然言語で説明したものを Copilot が組み立てる機能である。用途として挙げられているのは、手元で参照するための常駐ウィジェット、データを見るための対話型ダッシュボード、業務の流れの自動化といったものだ。

これは、これまで小規模な開発案件として外に出ていた仕事とかなり重なる。「Excel で集計している数字をダッシュボードにしたい」「申請の状況を一覧で見たい」という依頼は、確実にこの範囲に入ってくる。

一方で、この手の道具が苦手な領域も従来と変わらない。 ノーコードAIツールの実力と限界で整理した境界は、今回の発表でも動いていない。

社内で作りやすい	開発の発注が必要になりやすい
部門内で使う一覧・ダッシュボード	基幹システムと双方向に連携する処理
定型の文書作成・要約	精度の合格ラインを決めて検証が要る処理
個人や少人数の手順の自動化	監査ログ・権限設計が要件になる処理
試しに作って捨てられるもの	止まると業務が止まるもの

したがって発注側の実務としては、見積もりを取る前に「これは社内の道具で足りるか」を一度通すのが合理的になる。足りるものを外に出すと費用が無駄になり、足りないものを社内で抱えると後で作り直しになる。この線引きはAIに任せる業務の選び方の考え方をそのまま使える。

論点 2. 席代と従量課金が分かれた意味

今回いちばん実務に効くのは、課金の切り分けである。Chat と Office の利用はユーザー単位の定額に含まれ、エージェントが働く分は従量課金になる。

定額なら、人数が分かれば月額が決まる。予算の稟議は通しやすい。従量課金は逆で、使い方次第で月額が動く。しかも Autopilot のように「指示を待たずに働き続ける」ものは、人が使っていない時間にも稼働する。ここが従量になるということは、使っている人の実感と請求額がずれやすいということである。

だから Microsoft 側も、支出の管理ポリシーや費用管理の機能を同時に出している。発注側が確認すべきことも同じ順番になる。

その提案は、定額に含まれる範囲だけで動くのか、従量課金の範囲を使うのか
従量分は誰の契約で発生するのか（自社のテナントか、開発会社の環境か）
上限（月あたりの支出上限・承認フロー）を誰がどこに設定するのか

見積書で「運用費月額 15 万円」と書かれていても、そこに従量分が入っていないことは普通にある。API 実費を誰が持つかで契約の型が変わる話はAI運用費は定額保守か従量精算かで 3 つの型に分けた。今回のようにプラットフォーム側が二階建ての課金を標準にしてくると、この論点は AI 開発案件のほぼ全部に付いてくる。

似た形の「含まれる範囲の変更」は、2026 年 9 月にも起きている。Googleが法人契約から開発ツールを分離は値上げではなく、含まれる範囲が更新時に変わった例だった。単価ではなく境界が動くほうが、発注側にとっては読みにくい。

論点 3. 自社テナントの中で動く、という設計

Copilot Managed Runtime は、作ったコードを自社の Microsoft 365 環境の中で動かすための基盤である。IT 部門が統制し、利用者は難しいことを知らずに使える、という位置づけになっている。

セキュリティ要件の審査を通す側から見ると、これは追い風になりやすい。データが自社のテナントの外に出ないなら、AIシステムのセキュリティ設計で挙げた論点のうち、保存先と持ち出しの部分は説明が短くなる。

ただし裏返しもある。自社テナントの中で動くものは、そのプラットフォームから出しにくい。 数年後に別の基盤へ移すとき、自然言語で作った資産が移植できるかどうかは分からない。見積もりの段階では見えないが、契約や引き継ぎの条件を決めるときには考えておく論点である。引き継ぎで確認する項目はAI開発の引き継ぎにまとめた。

発注者・企業への影響

ここからは見立てである。

1 つ目。「内製か外注か」の判断軸が、作れるかどうかから統制できるかどうかへ移ると考えられる。 社内で作れる範囲が広がると、数が増える。増えたものを誰が棚卸しし、権限と支出をどう管理するかが次の問題になる。AI開発、内製と外注はどちらが安いかで書いた損益分岐は、今後は「作る費用」ではなく「管理する費用」で決まりやすくなる。

2 つ目。開発会社への発注は「社内の道具では届かないところ」に寄っていくと考えられる。 具体的には、基幹連携、精度の検証が要る処理、監査対応、複数部門をまたぐ権限設計である。逆に言えば、この 4 つを提案書で語れない会社は選びにくくなる。 会社選びで見るべき点はAI開発会社の選び方で整理している。

3 つ目。プレビュー段階の機能に乗った提案は、時期の約束ができない。 Autopilot はプライベートプレビューの拡大が始まった段階で、Home と Code も先行プログラムからの順次提供である。「その機能を前提にした見積もり」は、提供時期が動けばそのまま納期が動く。 提案書に preview・先行プログラム前提の機能が入っている場合は、それが使えなかったときの代替案を併せて出させたほうがよい。

見積もりで確認する 3 点

提案の中で、定額ライセンスに含まれる範囲と従量課金になる範囲が分けて書かれているか
従量分がどちらの契約で発生し、月額上限を誰が設定するか
プレビュー・先行提供の機能に依存していないか。依存するなら代替案があるか

同じ条件で複数社に投げると、この 3 点の書き方の差がそのまま見積もりの差として出る。条件をそろえた案件票で相見積もりを取る場合は無料の相見積もりから始められる。

まとめ

Copilot の刷新は、機能の統合と同時に課金の構造を定額と従量に分けた発表だった。社内で作れる範囲は広がり、エージェントが働いた分は使用量で課金される。

発注側がやることは 2 つある。発注する前に社内の道具で足りるかを通すこと。そして見積書の運用費に、従量分と上限が書かれているかを確認すること。 どちらも技術の話ではなく、境界の話である。

参考・出典

Introducing the new Copilot with Home, Code and Autopilot（The Official Microsoft Blog, 2026-09-25）: https://blogs.microsoft.com/blog/2026/09/25/introducing-the-new-copilot-with-home-code-and-autopilot/