Microsoft 365を使う組織で、従業員が生成AIで作った業務アプリの管理に頭を悩ませているIT部門の方に向けた話です。マイクロソフトは2025年9月25日、社内アプリの実行基盤「Copilot Managed Runtime」をパブリックプレビュー（一般提供前の検証用公開）として発表しました。この基盤が何を解決しようとしているのか、導入判断の観点から整理しておきたいと思います。
マイクロソフトは同時にCopilotの機能強化も発表しています。AIとの対話でWordやExcelを操作する「Copilot Home」、AIコーディングエージェントの「Copilot Code」、指示に基づいて常時稼働する「Copilot Autopilot」の3つです。プログラミング未経験の従業員でも、自然言語の指示だけで業務アプリを作れる環境が一気に広がったことになります。
市民開発の広がりとガバナンスの欠落という課題
ここで浮かび上がるのが「シャドーIT」の問題です。シャドーITとは、情報システム部門が把握・管理していないアプリケーションやツールが、現場の判断で使われる状態を指します。
ローコード・ノーコードツールが普及した数年前から、この種の懸念は繰り返し指摘されてきました。Power AppsやPower Automateも同様の文脈で語られています。生成AIによってアプリの作成コストがさらに下がると、シャドーITの発生頻度も比例して上がりやすくなります。
Copilot Managed Runtimeは、この「作りやすさの向上」と「管理の追いつかなさ」のギャップを埋めるために設計された基盤という位置づけです。アプリを作る敷居を下げつつ、実行環境そのものを組織の管理下に置く発想と言えます。
テナント境界内実行という仕組みの意味
最大の特徴は、ユーザーが普段使っているMicrosoft 365と同じ「テナント境界」内でアプリケーションが実行される点です。テナントとは、Microsoft 365の契約単位ごとに割り当てられる独立した論理環境のことです。組織ごとに1つのテナントを持つのが一般的です。
これまで従業員が個人で契約したSaaSや外部のノーコードツールで作ったアプリは、会社のIDやアクセス権限の管理外で動くケースがありました。データがどこに保存され、誰がアクセスできるかを情報システム部門が把握しにくい状態です。
Copilot Managed Runtimeでは、アプリを実行するユーザーの権限がすべてMicrosoft 365上のユーザーIDと紐づきます。公開・非公開の設定や稼働状況の把握も、使い慣れたMicrosoft 365の管理コンソールから行える設計です。つまり「新しい管理画面を覚える」というコストなしに、既存のID管理・権限管理の枠組みをそのまま流用できる点が実務上の利点になります。
既存のガバナンス体制との比較で見るべき点
技術選定の観点では、既に運用している統制の仕組みとどう重なるかを確認する必要があります。多くの組織はMicrosoft Entra ID（旧Azure AD）で条件付きアクセスや多要素認証を設定済みのはずです。Copilot Managed Runtimeがこれらのポリシーをそのまま継承するのか、追加設定が要るのかは、プレビュー段階の現時点で運用チームが個別に検証すべき項目です。
もう一つの比較軸は、Power PlatformのCoE（Center of Excellence）ツールキットのような既存のガバナンス資産との棲み分けです。Power Platformでは、環境ごとのDLP（データ損失防止）ポリシーやアプリの承認フローが整備されている組織もあります。Copilot Managed Runtimeが生成するアプリと、Power Platformで作られるアプリが別々の管理台帳で扱われると、結局は「見えない資産」が二重に発生しかねません。導入前に、両者の監視対象をどう統合するかを情報システム部門とCopilot管理者の間で合意しておく必要があります。
開発の入口も複数用意されています。Copilot HomeのCoworkで生成したアプリ、Copilot Codeで生成したアプリ、ローコード開発ツールのCopilot Studioで作ったアプリ、そしてSDK（開発者向け機能群）を使って作るカスタムアプリの4系統です。入口が多いということは、それだけ利用実態の把握対象が広がることも意味します。
今日確認できること
実際に検討を始めるなら、まず組織のMicrosoft 365テナントがCopilot Managed Runtimeのパブリックプレビューに参加できる契約プランか、Microsoft 365管理センターの発表情報やMicrosoft Learnのドキュメントで確認するのが出発点です。プレビュー機能は既定で無効になっていることが多いため、テナント管理者向けの設定画面で有効化の可否も見ておく必要があります。
次に、社内で既にCopilot StudioやPower Platformを使っている場合は、それらの環境設定・DLPポリシーの一覧を棚卸ししておくと、Copilot Managed Runtimeとの重複や抜け漏れを判断しやすくなります。
コスト面では、現時点で公開情報にライセンス体系の詳細が明記されていないため、正式な料金表はMicrosoft 365の契約担当窓口かパートナー経由での確認が必要です。プレビュー段階での無償提供か、正式版で追加コストが発生するかは、契約更新のタイミングと合わせて確認しておく方が安全です。
加えて、1500種類以上のデータソースに接続できるコネクタや、Microsoft 365内のデータにアクセスするMicrosoft Graph、組織内データの文脈をAIに理解させるWork IQといった機能が同梱される点も見逃せません。接続先が増えるほど、どのデータにどのアプリがアクセスしているかの可視化が運用上の課題になりやすい部分です。
まとめ
Copilot Managed Runtimeは、生成AIによるアプリ作成の手軽さと、企業のガバナンス要件を両立させようとする基盤です。テナント境界内実行という設計により、既存のID・権限管理をそのまま活用できる点は評価しやすい要素です。
一方で、Power Platformなど既存のローコード資産との管理台帳の統合や、DLPポリシーの継承範囲は、プレビュー段階では組織側の検証が欠かせません。まずはテナントでのプレビュー参加可否と、既存ガバナンス資産の棚卸しから着手するのが現実的な一歩になります。