Microsoftは2026年9月25日、新しいMicrosoft Copilotの構成として「Home」「Code」「Autopilot」を発表しました。単にチャット画面が変わるという話ではなく、質問するAI、仕事を委任するAI、アプリを作るAI、長時間動き続けるAIを、Microsoft 365の中でつなげていく方向性がはっきりした発表です。
SEや情報システム担当者の目線では、便利な新機能だけを追うよりも、「どこまで利用者に作らせるのか」「どのデータへ接続させるのか」「長時間動くエージェントの権限と費用をどう管理するのか」を先に考える必要があります。特にCodeとAutopilotは、従来の“AIに質問する”使い方よりも業務システムに近い位置まで入り込むためです。
2026年9月29日時点のMicrosoft公式情報では、HomeとCodeはFrontier programで段階的に展開される予定で、Autopilotは月末にPrivate Previewを拡大すると案内されています。すべての利用者がすでに使えると確認できる状態ではないため、導入を考える場合は自社テナントでの提供状況を確認してください。
先に要点をまとめると、今回の発表で重要なのは次の3点です。1つ目は、Copilotがチャット中心から「相談・委任・開発・自動実行」をまとめた作業基盤へ広がっていること。2つ目は、自然言語で業務アプリを作るCodeがMicrosoft 365のガバナンス内で動く設計になっていること。3つ目は、Cowork、Code、Autopilotなどの高度なエージェント機能が従量課金の対象になるため、AIの導入判断に費用管理が欠かせなくなることです。
新しいMicrosoft Copilotで何が変わるのか
Microsoftは新しいCopilotを、Home、Code、Autopilotという3つの方向へ拡張しています。これまでのCopilotは、WordやExcel、Teamsなどで質問したり、文章や資料を作ったりする“支援ツール”の印象が強いものでした。
今回の構成では、利用者がその場で質問するだけでなく、作業を丸ごと委任したり、業務用の小さなアプリを作ったり、数時間から数日にわたる処理をエージェントに継続させたりすることが想定されています。
| 機能 | 主な役割 | SE・IT部門が見るべき点 |
|---|---|---|
| Home | Chat、Cowork、Officeをまとめた作業の起点 | 利用者がどのデータと機能へアクセスできるか |
| Code | 自然言語からアプリ、ダッシュボード、ワークフローなどを作成 | 生成物の権限、データ接続、レビュー、ライフサイクル管理 |
| Autopilot | 利用者が離れている間も継続して作業するエージェント | 実行範囲、監査、権限、誤動作時の停止方法、費用 |
この3つを別々の新機能として見るより、「Microsoft 365の中にAIエージェントの仕事場を作る動き」と考えると整理しやすくなります。
HomeではChatとCoworkが一つの入り口に集まり、Word、Excel、PowerPointもCopilot内から扱える方向へ進みます。Codeでは業務に合わせた小さなソリューションを作り、Autopilotでは継続的な業務を任せる。利用者にとっては操作が一つの場所へ寄っていきますが、管理者側では「何を作れるか」「どこまで実行できるか」が今まで以上に重要になります。
HomeはChatとCowork、Officeをまとめる入口になる
Homeは、新しいCopilotの起点になる画面です。Microsoftの発表では、ChatとCoworkがHomeに集まり、さらにWord、Excel、PowerPointの機能もCopilot内で扱える方向が示されています。
Chatは、質問、検索、下書き、要約など、その場で返答を受ける用途です。一方のCoworkは、複数の工程をまとめて委任する用途です。たとえばRFP回答、顧客向け資料、財務クローズ用の資料作成など、途中に複数の作業が含まれるタスクを渡し、完成物まで進める使い方が想定されています。
SE実務で考えると、この違いは「一問一答」と「ジョブ実行」の違いに近いです。チャットで短い回答を返すだけなら、利用者がその場で内容を確認できます。しかしCoworkのように一連の仕事を任せる場合は、途中で参照したデータ、使ったツール、最終成果物の検証方法まで運用設計が必要になります。
初心者が迷いやすい点は、Copilotが便利になるほど「何でも同じ画面からやればいい」と考えやすいことです。実際には、顧客へ送る文書、社内限定データを含む分析、外部公開用資料などはリスクが違います。Homeが一つの入口になっても、業務ルールまで一つにまとめられるわけではありません。
導入時には、少なくとも機密情報の区分、生成物を人が確認する工程、外部送信前の承認、参照できるサイトやデータソースの範囲を決めておく方が安全です。
Codeは「非エンジニアでも作れる」だけでなく「運用までどう管理するか」が重要
Codeは、自然言語でアプリ、トラッカー、ダッシュボード、ワークフローなどを作るための機能です。Microsoftは、GitHub Copilotと同じ基盤技術を使い、サンドボックス環境でコードを実行できると説明しています。
ここだけを見ると「Microsoft 365版のAIアプリ作成ツール」と考えられますが、SE目線で重要なのは生成部分より、その後の運用です。業務アプリは作れた瞬間より、実際に社内データへ接続し、利用者へ配布し、更新し、問題が起きたときに止める段階で難しさが出ます。
Microsoftはこの部分をCopilot Managed Runtimeで支える方針です。公式情報では、Microsoft 365テナント内で動くアプリに対して、Microsoft Entraの認証、組織のポリシー、データ接続、監視、ライフサイクル管理をまとめて適用できる仕組みが紹介されています。また、SDKやCLIを使ったプロ開発者向けの経路も用意されています。
これは、いわゆる“シャドーIT”対策の観点で重要です。自然言語だけでアプリを作れるようになると、IT部門が知らないツールが社内に増える可能性があります。小さなアプリでも、顧客情報や売上データ、契約情報へ接続すれば、扱いは業務システムと同じです。
Codeの導入前に確認したいのは、誰が作成できるか、どのコネクタを利用できるか、外部APIへ接続できるか、作成したアプリを誰へ共有できるか、バージョンをどう管理するか、停止・削除の責任者は誰か、といった点です。
反対に、こうした管理を整えられる会社では、Excelや個人用スクリプトに閉じていた小さな業務改善を、管理されたアプリへ移せる可能性があります。たとえば問い合わせ状況のトラッカー、障害対応の情報整理、定型的な承認フロー、部門内のダッシュボードなどは、Codeの想定用途と相性がよい分野です。
ただし、複雑な基幹処理や高い可用性を要求するシステムまで、最初から自然言語生成に任せるのは慎重に考えた方がよいでしょう。公式仕様上はガバナンス機能が用意されていても、個々のアプリの要件定義、テスト、障害対応、データ整合性まで自動で保証されるわけではありません。
Autopilotは「常時動くエージェント」だから権限設計が変わる
Autopilotは、以前Scoutと呼ばれていた機能で、利用者がパソコンの前にいなくても継続して動くエージェントです。Microsoftの説明では、名前、役割、目標を設定し、TeamsやOutlookなどで情報を追いながら、定期作業やフォローアップを進める使い方が想定されています。
Autopilotには独自のID、メモリ、コンピューター、ワークスペースが与えられ、Microsoft 365テナント内で権限や監査の対象になるとされています。
この種類のエージェントは、従来のチャットAIと運用上のリスクが異なります。チャットであれば、利用者がプロンプトを送った瞬間に処理が始まり、返答を見てから次の操作へ進みます。Autopilotのような常時型エージェントは、利用者が見ていない時間にも処理を継続するため、設定ミスが長時間続く可能性があります。
たとえば、取引先への確認依頼、社内メンバーへのリマインド、定期レポート作成、プロジェクトの進捗収集などは便利な用途です。一方で、誤った宛先へ繰り返し連絡する、古い情報を使って処理する、不適切な権限でデータへアクセスする、想定以上に処理を続けて費用が増える、といった問題も考えられます。
実務で利用する場合は、「何をしてよいか」だけでなく「何をしてはいけないか」を設定する必要があります。外部送信、データ更新、承認処理、顧客への連絡、ファイル削除など、影響が大きい操作は人の確認を挟む設計が必要です。
また、停止手段も重要です。担当者が休みでも管理者が止められるのか、権限変更が即時反映されるのか、監査ログから何を確認できるのか、異常な実行回数を検知できるのか。こうした運用項目を決めずに「AIが勝手に働いてくれる」ことだけを期待すると、導入後の管理負担が増える可能性があります。
料金は固定費だけでなく従量課金を前提に考える必要がある
今回の発表で、企業が特に確認したいのが料金体系です。Microsoftは、日常的なAI利用と、高度なエージェント利用を分けて説明しています。
日常的なAI利用はUser Subscription License（USL）を中心とし、Chat、Word、Excel、PowerPoint、Outlook、Teamsなどの利用を含む考え方です。一方で、Cowork、Code、Autopilotなどの長時間動く高度なエージェント機能はUsage-Based Billing（UBB）、つまり利用量に応じた課金の対象になります。
Microsoft Learnでは、UBBの対象となる高度な機能はCopilot Creditsを消費し、アクセスにはUSLが必要になると説明されています。2026年9月29日時点で、今回確認した公式資料だけから日本のすべての契約形態に共通する固定の単価を断定することはできません。契約プラン、テナント、提供条件によって確認すべき内容が変わるため、具体的な金額は管理画面や正式な料金案内で確認してください。
SEや管理者にとって大きな変化は、ライセンス数だけを見てもAI費用を管理できなくなる点です。これまでは「何人にCopilotを配るか」が主な予算管理でしたが、エージェントが長時間動くと「どの業務がどれだけCreditsを使うか」を見る必要があります。
導入初期は、全社へ一気に開放するより、業務単位で費用対効果を測る方が現実的です。たとえば月次報告の作成、問い合わせ分類、会議後のフォローアップなど、処理回数と成果を測りやすい業務から始めると、利用量と効果を比較しやすくなります。
ここで注意したいのは、AIによって10分の作業が1分になっても、従量課金が高すぎれば業務全体として得にならない可能性があることです。反対に、数時間の人手作業や確認漏れを減らせるなら、一定の従量課金があっても意味があります。単価だけではなく、「1件処理するのにいくらかかるか」「人の確認時間がどれだけ減るか」で見る必要があります。
SE実務ではどう使い分けるか
新しいCopilotを実務へ入れるなら、機能名より仕事の粒度で考えると整理しやすくなります。
その場で確認したい仕事はChat向きです。仕様の要約、会議内容の確認、文書のたたき台、関数やSQLの相談など、利用者が返答を見ながら進める作業です。
複数工程をまとめて任せたい仕事はCowork向きです。資料を集め、整理し、成果物としてまとめるような仕事です。ただし途中の判断をどこまで任せるかは事前に決める必要があります。
繰り返し利用する仕組みにしたい仕事はCodeが候補になります。毎回チャットで同じ依頼をするのではなく、入力画面、集計、検索、ワークフローとして固定した方がよい作業です。
人が見ていない時間にも継続させたい仕事はAutopilotの領域です。定期監視、進捗確認、繰り返しのフォローアップなどが考えられます。
フリーランスSEの視点では、顧客企業にCopilotを導入するとき「どの機能を使うか」だけでなく、「どこで人が責任を持つか」を設計できることが重要になります。AIの出力確認、権限設定、監査、障害時の停止、費用監視まで含めて提案できれば、単なるツール紹介より実務価値が高くなります。
特にCodeの普及で、非エンジニアが小さな業務アプリを作る機会は増えそうです。そのときSEの役割がなくなるというより、要件の整理、セキュリティ、データ設計、レビュー、運用ルール作成の比重が上がると考えた方が現実的です。
導入前に確認したいチェックポイント
新しいCopilotは魅力的ですが、提供開始直後の機能を業務へ入れる場合は、機能の有無だけで判断しない方が安全です。特に次の点は事前に整理したいところです。
- 提供状態：Frontier、Private Preview、Public Preview、一般提供のどれか。
- 契約条件：自社のMicrosoft 365契約で利用できるか、追加ライセンスやCopilot Creditsが必要か。
- データ範囲：どのSharePoint、Teams、メール、業務データを参照できるか。
- 権限：読み取りだけか、作成・更新・送信まで許可するか。
- ガバナンス：Entra、DLP、コネクタ制御、監査ログ、アプリ管理を誰が担当するか。
- 費用：従量課金の上限、部門別予算、異常消費時の通知や停止方法。
- 品質：AIが作った文書やアプリを誰がレビューし、どのテストを通すか。
- 撤退方法：使わなくなったアプリやエージェントを止め、データ接続や権限を外す手順があるか。
よくある失敗は、「まず全員に使ってもらい、問題が出たら考える」進め方です。Chat中心のAIなら大きな問題にならないこともありますが、CodeやAutopilotではアプリ作成や継続実行までできるため、後から統制しようとすると整理が難しくなります。
最初は1つの部門、1つの業務、1つのデータ範囲に限定し、効果と問題を確認してから広げる方が運用しやすいです。特に外部送信やデータ更新を含む業務は、人の承認を残した状態で始めるのが現実的です。
向いている企業と、まだ急がなくてもよい企業
今回の新Copilotは、Microsoft 365を日常業務の中心に置いている企業ほどメリットを出しやすい構成です。Teams、Outlook、SharePoint、Word、Excelなどに業務情報が集まり、EntraやMicrosoft 365管理センターで権限を管理している企業なら、データとガバナンスを同じ基盤に寄せやすいからです。
また、部門ごとにExcelや小さなツールが増え、管理が難しくなっている企業にもCodeとManaged Runtimeの考え方は相性があります。自然言語で作れることだけでなく、作った後にIT部門が見える形へ寄せられる点が重要です。
一方で、Microsoft 365をあまり使っていない企業、業務データが複数クラウドやオンプレミスに分散している企業、AIエージェントへ渡せる権限設計がまだない企業は、急いで導入するより前提整備を優先した方がよい場合があります。
また、CodeやAutopilotは発表時点でプレビューや段階展開を含んでいます。業務の中心へ置く場合は、仕様変更や提供条件の変更を前提にしておく必要があります。新機能だからすぐ本番へ入れるのではなく、検証環境で確認し、利用条件を固定できる範囲から始める方が安全です。
まとめ
Microsoftが2026年9月25日に発表した新しいCopilotは、Home、Code、Autopilotによって、チャット型AIから業務エージェント基盤へ一段進もうとする内容です。
HomeはChat、Cowork、Officeをまとめる入口になり、Codeは自然言語から業務アプリを作る役割を持ちます。Autopilotは利用者が離れている間も継続して作業するエージェントです。そして、その高度な使い方には従量課金が組み合わされます。
SEが見るべきポイントは、生成AIの性能だけではありません。権限、データ接続、監査、アプリのライフサイクル、停止方法、費用管理まで含めて設計する必要があります。
これから試すなら、最初の一歩は「どの業務をAIへ渡したいか」を1つ決めることです。そのうえで、Chatで十分なのか、Coworkで委任するのか、Codeで仕組みにするのか、Autopilotで継続実行させるのかを分けて考えると、導入の目的が明確になります。
2026年9月29日時点では、Home、Code、Autopilotの一部は段階展開やプレビューです。利用可能範囲、料金、制限は今後変わる可能性があるため、実際の導入前にはMicrosoftの公式情報と自社テナントの管理画面で最新状況を確認してください。
コメント