Microsoft 365 Copilotのライセンス申請に追加予定だったBusiness Justification（申請理由）欄は、2026年7月20日にロールバックが告知され、現時点では提供を進めない状態です。理由欄が表示されないのは、Microsoft 365管理センターの設定漏れや展開遅延とは限りません。
Microsoft 365管理者は機能の再提供を待たず、既存のITSMチケット、Microsoft Forms、Microsoft Lists、Power Automateの承認フローなどで申請理由を記録する必要があります。実務上は、申請理由と承認履歴を社内システムに残し、Microsoft 365管理センターは承認後のライセンス割り当てに使う運用が確実です。(Microsoft 365 Message Center Archive)
Copilotライセンス申請のBusiness Justificationはロールバックされた
Roadmap ID 547731では、Microsoft 365 Copilotのライセンスを申請する際に、ユーザーがBusiness Justificationを任意で入力できる機能が計画されていました。
入力された内容は管理者にも表示され、次のような判断に利用できる想定でした。
- Copilotを必要とする具体的な業務
- 想定する利用目的
- ライセンスを割り当てる優先度
- 承認前に追加確認が必要かどうか
しかし、Microsoftは2026年7月20日のメッセージセンター更新で、この変更をロールバックし、現時点では提供を進めないと案内しました。ユーザーと管理者はBusiness Justification欄を利用せず、既存のライセンス申請フローは従来どおり継続します。(Microsoft 365 Message Center Archive)
| 確認項目 | 2026年7月24日時点の状況 |
|---|---|
| Business Justification欄 | 提供を進めない状態 |
| Microsoft 365 Copilotのライセンス申請 | 既存フローは継続 |
| 管理者のポリシーや設定 | 今回のロールバックによる変更なし |
| 新しい提供時期 | 公表されていない |
| 管理者が行うこと | 社内のチケットやフォームで申請理由を記録する |
「ロールバック」はBusiness Justification機能に対するものであり、Microsoft 365 Copilotのライセンス申請機能そのものが廃止されたわけではありません。
Roadmap ID 547731が検索で見つからない場合がある
Microsoft 365 Roadmapでは、機能が一般提供された場合だけでなく、キャンセルまたは延期された場合にも掲載情報が削除されることがあります。そのため、Roadmap ID 547731のページが検索結果に表示されない、または詳細が確認できない場合があります。(Microsoft)
社内の変更管理記録には、Roadmap IDだけでなく、次の情報も残しておくと経緯を追いやすくなります。
| 記録する情報 | 内容 |
|---|---|
| Roadmap ID | 547731 |
| Message Center ID | MC1227088 |
| 最終更新日 | 2026年7月20日 |
| 最終状態 | ロールバックし、現時点では提供を進めない |
| 社内対応 | 既存の申請・承認フローで理由を記録する |
理由欄がないまま承認すると何が困るのか
Microsoft 365管理センターのライセンス申請一覧では、製品名、申請者、申請日、ステータスなどを確認できます。一方、Business Justificationが提供されなければ、「なぜ必要なのか」をその画面だけで判断できません。
Microsoft Learnによると、セルフサービスのライセンス申請はMicrosoft 365管理センターの「Billing（課金情報）> Licenses（ライセンス）> Requests（要求）」から確認できます。申請記録は12カ月保持されますが、標準の一覧に表示されるのは製品、申請者、申請日、状態などです。(Microsoft Learn)
申請理由を別に記録しない場合、次の問題が起こりやすくなります。
| 問題 | 実際に起こること |
|---|---|
| 用途を判断できない | 管理者が申請者や上長へ個別に聞き直す |
| 優先順位を付けられない | ライセンス不足時に先着順や役職順になりやすい |
| 承認基準がぶれる | 同じ用途でも承認者によって結果が変わる |
| 監査証跡が不足する | 誰が何を根拠に承認したか説明できない |
| ライセンスを回収しにくい | 当初の利用目的や期限が分からない |
| 費用対効果を検証できない | 導入前の目標と導入後の実績を比較できない |
特にMicrosoft 365 Copilotは、割り当てた時点で終わる製品ではありません。利用目的、対象業務、成功基準、見直し時期まで記録しなければ、使われていないライセンスを発見して再配分することが難しくなります。
代替運用は「審査記録」と「ライセンス割り当て」を分ける
Business Justificationのロールバック後は、申請から割り当てまでを一つの画面で完結させようとしないことが重要です。
次のように役割を分けます。
| 役割 | 使用するシステム |
|---|---|
| 申請理由の入力 | ITSMチケット、Microsoft Forms |
| 申請台帳の保存 | Microsoft Lists、SharePointリスト、ITSM |
| 上長・部門承認 | Power Automate、既存ワークフロー |
| IT・セキュリティ審査 | ITSMまたはPower Automate |
| ライセンス割り当て | Microsoft 365管理センター |
| 利用状況の確認 | Copilot Dashboard、利用状況レポート、申請台帳 |
| 更新・回収判断 | 60日後または90日後の再審査 |
この構成では、Microsoft 365管理センターを「判断の記録場所」ではなく、「承認済みの結果を実行する場所」として扱います。
代替手段の比較
| 申請方法 | 導入負荷 | 記録性 | 向いている組織 | 注意点 |
|---|---|---|---|---|
| 既存のITSMチケット | 低い | 高い | ServiceNowやJiraなどを運用済みの組織 | Copilot用の必須項目を追加する |
| Microsoft Forms＋Microsoft Lists | 低い | 中～高 | 小規模から中規模の組織 | 承認処理が手作業になりやすい |
| Forms＋Lists＋Power Automate | 中程度 | 高い | 承認と通知を自動化したい組織 | フロー所有者と保守担当を明確にする |
| メール申請 | 低い | 低い | 一時的な暫定運用 | 検索、集計、監査が難しい |
| Microsoft 365管理センターのみ | 低い | 低い | 理由審査が不要な限定的運用 | Business Justificationを記録できない |
すでに社内チケットシステムがある場合は、新しい仕組みを作るよりも、Copilot申請用のフォームやテンプレートを追加する方が早く定着します。
Microsoft 365中心の環境であれば、Microsoft Forms、Microsoft Lists、Power Automateを組み合わせる方法が実装しやすい構成です。
Microsoft 365管理センターから社内申請フォームへ誘導する
Microsoft Learnでは、セルフサービス購入対象のライセンス申請について、Microsoft 365管理センターの標準申請ではなく、組織独自の申請プロセスを利用する設定が案内されています。
設定すると、ユーザーに社内申請の説明文やドキュメントへのリンクを表示できます。独自プロセスを有効にした後は、新しい申請が管理センターのRequestsタブに表示されなくなります。切り替え前の既存申請は、承認または却下するまで残ります。(Microsoft Learn)
設定手順
- Microsoft 365管理センターにサインインします。
- 「Billing（課金情報）」を開きます。
- 「Licenses（ライセンス）」を選択します。
- 「Requests（要求）」タブを開きます。
- 「Connect your request process」を選択します。
- 「Use my organization’s request process」を有効にします。
- ユーザーに表示する説明文を入力します。
- 社内申請フォームや利用規程へのリンクを登録します。
- 保存後、一般ユーザーのアカウントで表示内容を確認します。
この操作には、原則としてユーザー管理者またはライセンス管理者以上の権限が必要です。また、この設定はセルフサービス購入対象の製品・サービスに関する申請機能です。契約形態やテナント設定によって画面や適用範囲が異なるため、まず対象テナントでRequestsタブが利用できるか確認してください。(Microsoft Learn)
ユーザー向け案内文の例
Microsoft 365 Copilotの利用を希望する場合は、社内申請フォームから申請してください。具体的な利用業務、利用頻度、期待する効果、対象データ、上長承認を確認した後、IT部門がライセンスを割り当てます。管理センター上の操作だけでは申請は完了しません。
独自プロセスに切り替える場合は、管理センターと社内フォームの両方から申請を受け付けないようにします。入口が二つあると、同じユーザーの申請が重複し、どちらが正式な記録なのか分からなくなるためです。
Copilotライセンス申請フォームに入れるべき項目
Business Justificationを単なる自由記述欄として再現するだけでは、十分な審査はできません。管理者が承認、保留、却下を判断できるよう、項目を構造化します。
| 申請項目 | 確認する内容 | 記入例 |
|---|---|---|
| 申請者 | 氏名、会社アカウント、所属 | 営業部・[email protected] |
| 上長・承認者 | 業務上の必要性を確認する責任者 | 営業部長 |
| 利用する業務 | Copilotを使う具体的な作業 | 提案書の初稿作成 |
| 現在の作業時間 | 導入前の基準値 | 1件90分、月8件 |
| 利用頻度 | 継続利用が見込めるか | 週2～3回 |
| 対象アプリ | Word、Excel、PowerPoint、Teamsなど | TeamsとPowerPoint |
| 参照するデータ | 使用予定の保存先や情報区分 | Teams会議記録、部内SharePoint |
| 期待する効果 | 時間、品質、件数などの目標 | 初稿作成時間を45分に短縮 |
| 有償ライセンスが必要な理由 | Copilot Chatだけでは不足する理由 | 会議や社内ファイルを基に資料を作成するため |
| 成功判定 | 導入後に何を確認するか | 90日後に利用回数と削減時間を確認 |
| 希望期間 | 恒久利用か試行か | 90日間の試行 |
| 利用ルールの確認 | AI利用規程や情報管理ルールへの同意 | 確認済み |
対象のMicrosoft 365契約では、Web情報を中心に利用するCopilot Chatが追加費用なしで利用できる場合があります。一方、ユーザーがアクセスできる業務データを基にしたチャットやMicrosoft 365アプリ内の高度な連携には、Microsoft 365 Copilotライセンスが必要です。そのため、申請フォームには「Copilot Chatではなく有償ライセンスが必要な理由」を入れると、不要な割り当てを減らせます。(Microsoft Learn)
悪い申請理由と判断しやすい申請理由
悪い例は、次のような内容です。
AIで業務を効率化したい。便利そうなので使ってみたい。
これでは、対象業務、頻度、期待効果、有償ライセンスの必要性を判断できません。
判断しやすい例は、次のような内容です。
毎週2回作成する営業提案書について、Teams会議の内容と営業部SharePointの既存資料を基にPowerPointの初稿を作成したい。現在は1件90分かかっているため、45分以内への短縮を目標とする。まず90日間利用し、作成件数、削減時間、修正回数を確認する。
この書き方であれば、承認時だけでなく、90日後の継続判断にも同じ情報を使えます。
Power AutomateでCopilot申請の承認フローを作る
Microsoft 365環境だけで構成する場合は、次の流れが分かりやすく、保守もしやすい方法です。
Microsoft Forms
↓
Microsoft Listsに申請を記録
↓
所属長の承認
↓
IT部門のライセンス・セキュリティ確認
↓
Microsoft 365管理センターで割り当て
↓
申請台帳を「割り当て済み」に更新
↓
60日後または90日後に利用状況を再確認Power Automateには、承認依頼を作成して結果を待つ「Start and wait for an approval」アクションがあります。承認者は通知を受け取り、メールや承認センターなどから処理できます。Approvalsコネクタは標準コネクタですが、ServiceNowなど別のシステムと連携する場合は、追加のライセンス要件を確認してください。(Microsoft Learn)
フローの具体的な処理
- Microsoft Formsで申請を受け付けます。
- 回答の詳細を取得します。
- Microsoft ListsまたはSharePointリストに申請レコードを作成します。
- 申請者の所属長へ承認を送ります。
- 所属長が承認した場合だけ、IT部門へ審査を送ります。
- IT部門がライセンス残数、対象アカウント、利用目的、情報管理上の問題を確認します。
- 承認後、管理者がMicrosoft 365管理センターでライセンスを割り当てます。
- 割り当て日、SKU、作業者、見直し日を申請台帳に記録します。
- 申請者へ利用開始案内と社内ルールを送ります。
- 見直し日に担当者へ通知します。
最初からライセンス割り当てまで完全自動化する必要はありません。誤承認、対象ユーザーの間違い、ライセンス不足などを考慮し、当初はIT部門による最終確認を残す方が安全です。
また、Power Automateのフローを個人アカウントだけで所有すると、異動や退職時に停止するおそれがあります。共同所有者を設定し、接続情報、変更手順、エラー時の連絡先を運用文書に残してください。
承認・試行・保留を分ける判断基準
すべての申請を承認または却下の二択にすると、効果が不明な申請を適切に扱えません。「通常承認」「期限付き試行」「差し戻し・保留」に分けると判断しやすくなります。
| 判断 | 適用する条件 |
|---|---|
| 通常承認 | 利用業務が具体的で、継続的な利用が見込まれ、効果測定方法も決まっている |
| 60～90日の試行 | 利用目的は妥当だが、効果や利用頻度がまだ不明 |
| 差し戻し | 「効率化したい」など理由が抽象的で、判断材料が不足している |
| 保留 | 対象データ、共有範囲、情報管理上の安全性を確認できない |
| 却下 | Copilot Chatなど既存機能で目的を満たせる、または利用予定がほとんどない |
役職や申請順だけで判断せず、具体的な業務、利用頻度、期待効果、データの準備状況を共通基準にすることが重要です。
承認後も定期的に見直す
MicrosoftはCopilotの展開を、Pilot、Deploy、Operateの段階に分け、導入後は利用状況やユーザーの反応を確認することを案内しています。Microsoft 365管理センターでは、個人またはグループへの割り当て、ライセンスの再割り当ても行えます。(Microsoft Learn)
試行期間終了時には、少なくとも次の内容を確認します。
| 確認項目 | 判断例 |
|---|---|
| 実際の利用 | 継続的に利用しているか |
| 申請時の業務 | 当初の用途に使われているか |
| 時間削減 | 申請時の目標に近づいているか |
| 品質改善 | 修正回数や手戻りが減ったか |
| 代替可能性 | Copilot Chatや既存機能で十分ではないか |
| 継続意思 | 本人と上長が継続を希望しているか |
利用回数だけで機械的に判断するのは避けます。月に数回しか使わなくても、経営会議資料や大規模な提案書など、1回当たりの効果が大きい業務もあるためです。
ロールバック後の運用で失敗しやすいポイント
| 失敗例 | 問題 | 対策 |
|---|---|---|
| Business Justificationの再提供を待つ | 申請理由のない状態が続く | 現在のチケットやFormsで直ちに補完する |
| 管理センターと社内フォームの両方で申請させる | 二重申請とステータス不一致が起きる | 正式な申請入口を一つに決める |
| 自由記述欄だけを作る | 抽象的な理由が増える | 頻度、時間、対象アプリ、成功基準を個別項目にする |
| 一度承認したら無期限で付与する | 未利用ライセンスが蓄積する | 60日または90日後の見直し日を設定する |
| 申請理由に機密情報を記入させる | 不要な情報が申請台帳に残る | 実データではなく、情報区分と保存場所だけを記録する |
| 承認履歴をメールだけに残す | 検索や監査が難しい | ListsやITSMを正式な記録場所にする |
| Power Automateを一人だけで管理する | 異動や退職でフローが停止する | 共同所有者と運用手順を設定する |
管理者が今すぐ行うべきこと
最初に、Roadmap ID 547731を前提にした展開計画を見直し、2026年7月20日にBusiness Justificationがロールバックされたことを変更管理記録へ残します。
次に、Copilotライセンス申請の正式な入口を一つに決めます。既存のITSMがある場合はチケットを使い、ない場合はMicrosoft FormsとMicrosoft Listsで申請台帳を作成します。
そのうえで、次の最低限の運用を整備します。
- 具体的な業務、利用頻度、期待効果を必須項目にする。
- 有償のMicrosoft 365 Copilotが必要な理由を確認する。
- 所属長とIT部門の承認履歴を残す。
- Microsoft 365管理センターでは承認済みユーザーだけに割り当てる。
- 60日または90日後の見直し日を登録する。
- 未利用または目的を満たしたライセンスを回収し、別の申請者へ再配分する。
Business Justificationのロールバックによって、申請理由の記録はMicrosoft 365管理センターだけでは完結しません。一方、社内の申請フローを構造化すれば、当初予定されていた任意の理由欄よりも、承認基準、監査証跡、利用効果、ライセンス回収まで一貫して管理できます。
コメント