Microsoft Copilot新体系：Home/Code/Autopilotの全貌と大企業導入の現実的コスト

• MicrosoftがCopilotを刷新し、Home・Code・Autopilotを統合。USL（固定）とUBB（従量）の二段構えの料金体系へ移行。
• Code機能はサンドボックス環境で動作し、Copilot Managed RuntimeによりEntra ID連携等の強固なガバナンスを実現。
• 全社展開には、UBBによるコスト予測の困難さと、マネージド環境におけるライセンス管理の複雑さが大きな障壁となる。

2026年9月25日、Microsoftが発表した「新しいCopilot」は、単なるUIの刷新に留まらない。これまで断片的に存在していたChat、Cowork、Codeといった機能が「Home」という単一の入り口に集約され、Microsoft 365のセキュリティ基盤の上でシームレスに動作するアーキテクチャへと進化を遂げた。特に注目すべきは、ユーザーの意図を汲み取り、最適なモデルと推論の深さを自動選択する「Auto」という仕組みだ。これにより、開発者やエンドユーザーは、モデルの選定という技術的オーバーヘッドから解放されることになる。

今回発表された主要機能のスペックと提供形態は以下の通りである。

特に「Code」機能は、GitHub Copilotの技術をベースにしつつ、隔離されたサンドボックス環境で動作する点がエンジニアとして非常に興味深い。作成されたアプリは「Copilot Managed Runtime」上で実行され、Entra IDによる認証やDLPポリシーが自動適用される。これは、これまで市民開発の現場で頭を悩ませてきた「野良アプリ」の乱立というスパゲッティコード的な混沌を、プラットフォーム側で強制的に構造化しようとするMicrosoftの強い意志を感じる。しかし、この「管理された自由」が、現場のスピード感を削ぐことにならないかという懸念は拭えない。我々エンジニアは、AIが生成したコードの保守責任を誰が負うのか、という古典的かつ本質的な問いに再び直面しているのだ。

今回の発表で最も議論を呼ぶのは、間違いなく「USL（ユーザー単位ライセンス）」と「UBB（利用量に応じた課金）」の二段構えの料金体系だろう。Microsoftは、日常的なAI活用をUSLで固定化し、高度なAI活用をUBBで賄うという戦略をとっている。しかし、現場のシニアエンジニアとして言わせてもらえば、この「UBB」の予測不可能性こそが、大企業における全社展開の最大のボトルネックとなる。例えば、Coworkで複雑な資料作成を依頼した場合、数千クレジットを消費することは珍しくない。単価0.01ドルという数字は一見安価に見えるが、全従業員が日常的にこれを利用すれば、月次のクラウド請求書は瞬く間に肥大化する。FinOps for AIという管理ツールが提供されるとはいえ、予算の承認プロセスが追いつかなければ、現場は「AIを使いたいが、コストが怖くて使えない」というデッドロック状態に陥るだろう。

さらに、マネージド環境の運用負荷も無視できない。Code機能で作成されたアプリは、作成者ごとの個人用開発環境に自動生成されるが、これにはPower Apps Premiumライセンスが必要となるケースが多い。マネージド環境では、アプリの利用者全員にライセンスが必要というルールは、小規模なチームでのPoCから全社展開へスケールさせる際の「隠れたコスト」として機能する。コネクタ制御においても、従来のデータポリシーと「高度なコネクタポリシー（ACP）」が並行して評価されるため、管理者は二重のガバナンスを強いられることになる。これは、単にツールを導入すれば生産性が上がるという甘い幻想を打ち砕く、極めて現実的かつ泥臭い管理コストの増大を意味している。

結局のところ、我々エンジニアは「AIに何を任せ、何を手元に残すべきか」という境界線を再定義しなければならない。Autopilotのような自律エージェントが普及すれば、確かに定型業務は劇的に効率化されるだろう。しかし、その裏側で動くロジックがブラックボックス化し、障害発生時に誰も原因を特定できない「AIスパゲッティ」が量産される未来は、技術者として看過できないリスクである。特に、作成者自身がコードを理解していないアプリが業務のクリティカルパスに入り込んだとき、その保守を誰が担うのか。AIが書いたコードの技術的負債は、誰が返済するのか。この問いに対する答えを、組織のガバナンスポリシーの中に明文化できていない企業は、AI導入で得られる利益以上の負債を抱えることになるだろう。

明日から我々が取るべき対策は明確だ。まずは、Copilotの各機能が消費するクレジットの「実測値」を、自社の業務シナリオで計測すること。そして、費用対効果が不明瞭なまま全社展開するのではなく、特定の高付加価値業務に絞ったパイロット運用から開始し、ガバナンスの運用負荷を検証することだ。AIは魔法の杖ではない。それは、既存の業務プロセスを増幅させる増幅器に過ぎない。もし、現在の業務プロセスが非効率でスパゲッティ化しているなら、AIを導入したところで、その非効率さが高速化されるだけである。我々エンジニアに求められているのは、AIを使いこなすスキル以上に、AIを前提とした業務プロセスそのものを再設計する「アーキテクトとしての視座」ではないだろうか。あなたは、AIに仕事を奪われることを恐れるのか、それともAIを制御する側の設計者として、組織の未来を定義するのか。その選択が、これからのエンジニアとしてのキャリアを決定づけることになるだろう。