Microsoftは2026年9月25日、CopilotをHome、Code、Autopilotで構成する新しい業務向け体験として発表しました。The Rundown AIが10月11日付で公開した、Copilot担当EVPのJacob Andreou氏へのインタビューでも、この再設計とエージェントの使い方が取り上げられています。両者の日付は別です。現時点でこの3機能は一般提供済みではなく、Microsoftの製品ページではHomeとCodeがFrontier、AutopilotがPrivate Previewと案内されています。9月25日のMicrosoft公式発表と現在のCopilot製品ページで確認できます。
本稿では、Microsoft CopilotのHome・Code・Autopilotが担う作業と、どの条件で試行すべきかを整理します。
注目点は、チャットに機能を足したことだけではありません。会話、Office文書、簡易アプリ作成、継続的に動くエージェントを同じ仕事の流れに置こうとしています。一方で、早期アクセス、非公開プレビュー、使用量ベースの課金が関わります。中小企業は「便利そうだから全社展開」ではなく、対象テナントで使えるか、既存作業と比べて確認負荷が減るか、費用と権限を管理できるかを小さく確かめる段階です。
新しいCopilotは、仕事の入口・制作・委任を分けている
Home、Code、Autopilotは、同じ仕事を別の名前で呼んでいるのではなく、任せる範囲が異なります。Homeは会話と複数工程の委任を始める場所、Codeは業務用の小さなアプリや自動化を作る機能、Autopilotは目標を渡して継続的に動かすエージェントです。従来のチャットAIのように質問への回答だけを受け取る使い方と、作業の途中を引き受けてもらう使い方を区別して設計する必要があります。
| 機能 | Microsoftが示す役割 | 業務で考えられる用途 | 現在の提供段階 |
|---|---|---|---|
| Home | ChatとCoworkを一つの開始点にまとめ、最近の作業や提案を表示 | 質問・下書きと、複数資料をまたぐ企画書準備を切り替える | Frontier |
| Code | 自然言語からアプリ、ダッシュボード、トラッカー、ワークフローを作成 | 定型集計を小さな社内ツールにまとめる | Frontier |
| Autopilot | 独自のIDや記憶、作業環境を持ち、バックグラウンドで継続作業 | 予定や依頼を追い、準備・フォローを続ける | Private Preview |
役割と機能の説明はMicrosoftの発表記事に基づきます。提供段階は変わる可能性があるため、試行を決める時点で現行の製品ページを再確認してください。Frontierは実験的な機能を早く試すための早期アクセスプログラムです。参加していても、アカウントや機能ごとに順次提供となる場合があります。
Homeは会話と委任を同じ場所から始める
Homeでは短い質問や検索、下書きのような会話型の作業と、Coworkに複数工程を預ける作業を分けます。Microsoftは例として、RFP回答、顧客向けブリーフ、ローンチ資料、財務締め資料などを挙げています。これは「完成品をそのまま使える」という保証ではありません。複数の社内資料を読み合わせるほど、元データの範囲、最新版、成果物の確認担当を決めておく必要があります。
Codeはファイルの外にある小さな業務ツールを作る
Codeは文章で目的を説明し、ダッシュボードや進捗表、アプリ、ワークフローを作る機能です。MicrosoftはGitHub Copilotと同じ基盤技術を使い、サンドボックス環境で動かし、組織のテナントでホストできると説明しています。ここでいう「作れる」は、会計や顧客管理の本番システムを検証なしで置き換えられる意味ではありません。入力データ、計算式、アクセス範囲、更新方法を担当者が照合できる用途から始めるのが現実的です。
Autopilotは一度の指示で終わらない作業を想定する
Autopilotはクラウド上で動き、Microsoft 365やWork IQを使ってチャネルを見守る、依頼を追う、定期作業を進めるなど、ユーザーが離れている間も作業を続ける構想です。Microsoftは独自のID、記憶、コンピューター、ワークスペースを持ち、権限・監査・ガバナンスの枠内で動くと説明しています。長く動く分だけ、誤った前提のまま作業を続けたり、想定外の相手へ連絡したりする影響も大きくなります。権限の範囲だけでなく、止める方法と実行履歴を確認できるかが導入判断に加わります。
今すぐ全社導入する段階ではない
2026年10月13日時点でMicrosoftの製品ページは、HomeとCodeをFrontierで、AutopilotをPrivate Previewで提供中と表示しています。つまり、発表された構想をすべての契約者がすぐ使える状態ではありません。Frontierは早期アクセスの枠組みで、Autopilotはさらに対象が限られる非公開プレビューです。日本語のMicrosoft 365ロードマップにも新しいCopilotが掲載されていますが、日本での提供完了日や各テナントの参加資格までは確認できませんでした。日本語ページがあることだけで、日本の利用者全員が試せるとは判断できません。
試行前に管理者へ確認するのは、(1)自社テナントがFrontierまたはPrivate Previewの対象か、(2)必要なMicrosoft 365契約と管理者設定は何か、(3)対象機能が日本のテナントで有効か、(4)入力データと利用履歴を誰が確認できるか、(5)従量課金の単価・上限・予算通知をどう設定するか、です。これらが分からない場合は、デモや説明資料だけで利用可能と決めず、参加条件が確定するまで待ちます。
発表内容には、HomeとCodeをFrontierで順次展開し、AutopilotのPrivate Previewを広げるとあります。これは提供計画です。現在の段階は製品ページを見て判断し、社内アカウントで実際に有効かどうかは管理者または利用画面で確認します。具体的な画面や管理設定を確認できていないため、この記事ではクリック手順を案内しません。
ライセンス料金とエージェントの利用料金を分けて考える
Microsoftの発表では、日常的な質問、要約、下書き、分析などのCopilot利用にユーザーサブスクリプションライセンス（USL）を置き、Cowork、Code、Autopilotなどのエージェント型作業には使用量ベース課金（UBB）を適用するとしています。同社の説明では、管理者は利用ポリシーやモデル選択、クレジット申請を管理し、利用者は残高や履歴を確認する想定です。
したがって、既存のCopilotライセンスがあることを理由に、長時間の委任作業も追加費用なしで無制限に使えるとは考えないでください。今回確認した公式発表とCopilot製品ページでは、日本向けのUBB単価、機能別の計算方法、プレビュー中の適用条件を確定できません。米国向けページに表示された価格を円へ換算して社内見積もりに使うこともしません。管理者と契約窓口に、どのライセンスが必要か、試行中に何が課金されるか、停止・上限設定ができるかを確認してから着手します。
試行の予算は、いきなり全社員分を積むのではなく、対象者を絞ったうえで、1回あたりの作業量、再実行回数、承認待ち、担当者の確認時間を記録します。請求が発生する期間を限定できない、使用量の見方が分からない、予算超過の通知や停止方法が確認できない場合は、本番データを使う試行を始めない判断も必要です。
中小企業が先に試すなら、出力を照合できる仕事から
新機能の効果を評価しやすいのは、入力が整理され、完了条件が明確で、出力を人が照合できる作業です。たとえば「便利なAIを導入する」ではなく、「週次の案件集計を作る時間を減らし、数字の確認漏れを増やさない」と目的を置きます。従来の手順を残したまま、AI版で時間と確認回数を測れば、速さだけを見て誤りや手戻りを見落とすのを防げます。
| 想定例 | 対象と渡すもの | 期待する出力 | 人が照合する点 |
|---|---|---|---|
| Codeでキャンペーン進捗を可視化 | 匿名化した週次CSV、指標の定義、既存の集計例 | 進捗ダッシュボード、案件別の遅延一覧 | 合計値、対象期間、重複・欠損、更新方法、閲覧権限 |
| Autopilotで仕入先確認を準備 | 社内の確認項目、期限、担当者、既存の進捗記録 | 未回答項目の整理、会議準備、フォロー候補 | 相手先、期限、前提、送信内容。外部送信は人の確認後 |
これはMicrosoftの公開機能説明から考えた想定例で、実際の動作を検証した結果や導入実績ではありません。Codeは自然言語でトラッカーやダッシュボードを作れると説明され、Autopilotは仕入先レビュー、準備、会議、フォローを続ける例が紹介されています。自社のテナントで同じ連携や承認方法を実現できるかは、利用資格と管理設定を確認する必要があります。
例1: Codeで既存集計を再現し、差分を見つける
マーケティング担当が、キャンペーン名、配信日、予算、問い合わせ数を含む匿名化CSVを使い、週次確認用の一覧を作る想定です。最初に指標の定義と正解となる集計例を1週分だけ用意します。次に「どの列を集計し、期間をどう切り、遅延をどう示すか」を文章で指定し、出力された値を表計算ソフトで再計算します。差が出たら原因を分類し、指示の不足か、データ欠損か、コードの誤りかを記録します。合計が合っても、翌週のデータを追加して更新が壊れないかを確認するまでは業務の正本にしません。
本番顧客データの持ち込みが不要な段階であれば、仮データや匿名化データで検証します。作成したアプリの閲覧先と更新担当も決めます。アクセス権が広すぎる、表計算の既存手順より確認に時間がかかる、元の定義と異なる集計を直せない場合は、アプリ化を続けず、通常の表計算や既存BIで十分かを見直します。
例2: Autopilotで「連絡」ではなく、まず準備と追跡を試す
仕入先の確認期限が複数ある小規模チームなら、最初の試行を「期限が近い項目の一覧化」「会議の準備」「確認事項の下書き」に限る方法があります。入力には必要な社内記録だけを使い、担当者、期限、未確認情報を一覧にします。担当者は、相手先や期日の取り違え、古い情報、完了扱いの誤りを確認します。外部メールの送信、発注条件の変更、承認の確定は試行範囲から外し、エージェントが勝手に実行できない統制を確認してから別途判断します。
長期記憶や継続実行は、作業が続く利点と、古い前提が残るリスクの両方を持ちます。タスクの完了条件、参照してよい資料、更新の責任者、停止方法を明確にし、出力の根拠を記録できるかを見ます。もし設定画面で外部送信や変更操作を人の承認なしに止められるか確認できないなら、その操作を含む業務には使わないでください。
試行は7段階で、時間・品質・費用を一緒に測る
- 仕事を一つ選ぶ。週次集計や会議準備など、完了条件が明確で、失敗を既存手順で見つけられる作業に絞ります。
- 現在の基準を記録する。所要時間、差し戻し回数、確認者、漏れや修正内容を、通常手順で1〜2回記録します。数字をあとから推定せず、同じ条件の作業を比べます。
- 利用資格と費用を確認する。FrontierまたはPrivate Previewの参加状況、必要ライセンス、対象地域、UBBの料金・上限・通知・停止手段を管理者に確認します。
- 入力を小さくする。テストに不要な顧客情報や機密情報を含めず、匿名化またはサンプルデータで開始します。アクセスできるフォルダーやアプリは必要範囲に絞ります。
- 承認境界を決める。文章作成、社内整理、読み取りと、送信、削除、発注、公開などを分けます。元に戻せない操作を試行から外し、承認なしに進まない条件を確認します。
- 同じ作業をAIあり・なしで行う。出力時間だけでなく、修正、確認、再実行、待ち時間、クレジット使用量を記録します。生成結果は元データ、計算、社内ルールと照合します。
- 拡大・継続・停止を決める。確認時間を含む総作業時間が減り、誤りや手戻りが増えず、課金と権限を管理できる場合だけ、対象者や作業を少しずつ広げます。
測定表は、少なくとも「1件あたりの作業時間」「人が確認した分数」「修正・再実行回数」「重大な誤り」「使用量課金」「未完了・停止件数」を分けて持ちます。Microsoftが紹介するモデルの自動選択や管理機能は、利用者の負担を下げる設計意図であり、自社の業務で費用対効果が出る証明ではありません。社内の基準と比較して判断します。
業務の手順と参照データを先に整える
HomeやAutopilotが社内の仕事に根拠を持って答えるには、参照する資料が最新で、誰が見てよいか整理されている必要があります。古い見積もりと承認済み見積もりが同じ場所にある、担当者ごとに進捗表が分かれている、アクセス権が退職者にも残っている、といった状態では、AIを足してもどれが正本かという問題は解決しません。出力が自然な文章で返るほど、古い情報をもっともらしく整理してしまう可能性があります。
試行前に、対象業務の正本となるフォルダーや表、その更新担当、古い版の扱いを決めます。次に、試験用のデータだけで意図した情報を参照するか、人が元資料をたどれるかを確認します。Microsoftは組織の文脈や権限・監査を重視すると説明していますが、各機能で選べる具体的なアクセス範囲、ログ保持、停止操作はこの調査で確定できませんでした。管理者には、機能ごとの設定と記録の実物を見せてもらい、画面や契約条件を確認するまでは制御があると仮定しないでください。
同時に、既存の固定ルール型自動化と比べることも大切です。入力項目と処理順が毎回同じなら、従来のフォームやワークフローのほうが結果を予測しやすく、AIの確認や従量費用が不要なことがあります。一方、複数の資料を読み比べて例外を整理するなど、情報のばらつきが大きい仕事は、AIに要約や案出しを任せ、人が確定する形を検討できます。AIを使うこと自体を目標にせず、既存方法より確認込みの作業が良くなるかを比較してください。
3機能のどれから試すかは、作業の性質で決める
3つを一度に導入する必要はありません。業務が一回で完結するか、同じ情報を何度も集計するか、数日かけて追跡するかで候補が変わります。チャットだけで十分な作業へ自動化を足すと、設定や確認の手間が増えることもあります。
- Homeが候補: 作業の大半は質問・下書きだが、複数資料や工程をまとめると担当者間の受け渡しが増える。Coworkへ委任した結果を、人が成果物として確認できる。
- Codeが候補: 同じ形式のデータを繰り返し集計し、必要な列や計算規則が固まっている。出力値を既存の表計算や帳票と突き合わせられる。
- Autopilotが候補: 一度の回答では終わらず、期限や複数のフォローをまたいで継続する作業がある。担当者、終了条件、参照できる情報、外部へ実行してよい操作を定義できる。
「自動化できるか」だけでなく、失敗したときに見つけられるかも選定基準です。成果物の内容を照合できない、間違いが顧客や取引先へすぐ届く、元に戻せない操作を含む仕事は、試行の最初に置かないでください。導入優先度は、反復頻度、確認可能性、誤りの影響の三点で決めます。
効果は確認込みの総工数と費用で測る
AIが処理にかかった時間だけを見ても、業務上の効果は判断できません。担当者が指示を準備する時間、エージェントの待ち時間、人が出力を読み直す時間、誤りを直す時間まで含めて、従来手順と比べます。短い下書きがすぐ出ても、根拠照合により多くの時間がかかるなら、その作業では効率化にならない可能性があります。
比較の単位は同種の案件にそろえ、最低限次の項目を記録します。
- 作業時間: 人が手で処理した時間と、AIへの準備・指示・待ち・確認・修正時間。
- 品質: 元データとの不一致、差し戻し、欠落、担当者による修正、再実行。
- 費用: 試行期間の追加ライセンス費用と、確認できた使用量課金。価格が不明なら不明として残す。
- 統制: 停止が必要になった回数、権限外の処理を試みた回数、監査情報を追えたか。
試行を始める前に「確認込みの時間が減り、誤りと追加費用が許容範囲を超えない」を継続条件として合意しておきます。何分短縮できれば採算が合うかは、人件費、頻度、課金条件によって違うため、一律の数値を当てはめません。利用単価が分からない場合は、効果測定より先に契約・課金条件の確認が必要です。
導入を待つべき条件も決めておく
次のいずれかが残る場合は、プレビューへ急いで参加するより、提供条件が整うまで待つほうが合理的です。
- 対象テナント、必要ライセンス、参加申請の窓口が分からない。
- エージェント作業の課金方法や上限を管理者が説明できない。
- 誤送信、削除、契約・支払条件の変更を人が止める手段が確認できない。
- 社内データのアクセス権が整理されておらず、必要以上の情報が見える。
- 既存のツールで同じ目的を達成でき、AI利用後に確認工程が増える。
Copilotの新しい構成は、文書を作るチャットから、道具を作り、仕事を続けて進めるエージェントまでを一つの環境へ集める方向を示しています。ただし、Home・Code・Autopilotが持つ権限や課金が同じではなく、現時点では早期アクセスとプレビューの段階です。まず管理者に自社テナントの利用資格、従量課金、停止・監査の条件を確認し、匿名化したデータを使う一つの作業で、時間・確認負荷・費用を既存手順と比べてください。基準を満たさなければ、一般提供や条件の明確化まで待つ判断もできます。