Copilot Managed Runtimeは、社内向けの業務アプリをMicrosoftがホストし、Microsoft 365テナントの認証・データ統制・管理画面にそのまま載せる実行基盤です。2026年9月25日に発表され、10月時点ではパブリックプレビューの段階にあります。Copilot Coworkや Copilot Studioで作ったアプリも、開発者がSDKとCLIで書いたアプリも、同じ基盤で動き、同じ管理センターに並ぶ仕組みです。この記事では、ms CLIでアプリを作って公開するまでのコマンド、既定で効くコネクタ制限とCSP、利用者単位の課金、そしてAzure App Serviceとの使い分けまでを、実装者と情報システム部門の目線で整理します。
まとめ：Copilot Managed Runtimeで社内アプリを動かす前に決める3点
押さえるべき点は3つです。第一に、テナントで基盤そのものは自動的に使える状態でも、開発者がCLIでアプリを作る経路は既定でオフになっています。最初に管理者がPower Platform管理センターで許可を出さない限り、手元で ms app create を打っても先へ進めません。第二に、作ったアプリは最初から厳しい既定ポリシーを継承します。許可されるのはMicrosoft製の18コネクタで、CSPは外部への通信を自オリジンに限ります。外部APIやCDNを呼ぶアプリは、管理者側の設定変更が前提です。
第三に、費用は利用者ごとに決まります。Power Apps Premiumを持つ利用者はクレジットを消費せず、持たない利用者はアプリの起動とAPI呼び出しごとにCopilotクレジットを消費します。Microsoft 365のデータを読み書きする部門内ツールならManaged Runtimeで対応可能です。外部の業務システムと常時連携するサーバー処理や、独自ドメインでの社外公開を伴うならApp Service側で組む判断になります。
Copilot Managed Runtimeの仕組みとアプリを作る3つの入口を確認する
まずは全体像です。誰がどこで作り、誰がどこで使い、誰がどこで統制するかを先に分けておくと、後の設定箇所で迷いません。
テナントの統制を作成時点から継承する業務アプリ実行基盤の役割
What is Microsoft Copilot Managed Runtimeによれば、この基盤は社内業務アプリ（line-of-business apps）をホストし、作成された瞬間から組織のガバナンス・セキュリティ・コンプライアンス設定を引き継がせます。アプリはMicrosoftがホストする環境で動き、認証にはMicrosoft Entra IDを使います。開発者が認証処理を書く必要はありません。サインインと認可の土台となるEntra IDそのものはMicrosoft Entra ID（旧Azure AD）の機能と仕組みで解説しています。
Cowork・Copilot Studio・SDKの3経路で作るアプリは同じ成果物
アプリの作り方は3通りあります。業務担当者がチャットで依頼するCopilot Cowork、作成手順を細かく制御したいメーカー向けのCopilot Studio、そしてコードで書く開発者向けのSDKとCLIです。公式は、3経路のどれで作っても同じ種類の成果物になると明記しています。テナントの既定ガバナンス（承認済みコネクタ・共有ルール・CSP）を継承し、管理者のアプリ一覧に表示される点も共通です。
各入口の詳細は既存記事に譲ります。対話で業務を代行させるCoworkの管理者設定はCopilot Coworkの管理者設定とSKILL.md自作に、ローコードでエージェントを組むCopilot Studioの基本はCopilot Studioの基本機能と始め方にまとめました。本記事はコードで書く3番目の経路を中心に扱います。
利用者ポータルと管理センターの分担と2026年10月時点の提供段階
利用者は managedapps.cloud.microsoft のポータルで、自分がアクセスできるアプリを探して開きます。管理者はMicrosoft 365管理センターの「アプリ」配下で、テナント内のすべてのアプリの利用状況・正常性・ライフサイクルを見ます。開発ツールと利用者の入口と統制の画面が、それぞれ別に用意されている構造です。
提供段階は、アプリを作成する経路によって異なる状態です。管理者向けの概要ページの表では、パブリックプレビューの時点でCopilot Studio経路は既定オン、CLI経路は既定オフ、Cowork経路はFrontierプログラムへの参加が条件とされています。発表全体で同時に出たAutopilotなど他の新機能との関係は、Microsoft Copilot Autopilotの変更点と従量課金で整理しています。
ms CLIでアプリを作成してローカル実行から本番公開まで進める手順
ここからは開発者の作業です。手順はGitの操作と一体になっており、CLIはGitを置き換えません。
Node.js 24.11以上とGit 2.27以上を揃えてCLIを入れる前提条件
Copilot Managed Runtime SDKの概要が挙げる前提は、Node.jsのLTS版でv24.11.0以上、Gitはv2.27.0以上、そしてGit Credential Managerです。Windows版Gitを入れていれば多くの場合GCMは同梱されており、git credential-manager --version で確認できます。CLIは @microsoft/managed-apps-cli、実行時にコネクタを呼ぶSDKは @microsoft/managed-apps というnpmパッケージで配布されます。npmレジストリで確かめた2026年10月11日時点のCLI最新版は0.28系で、まだ1.0に届いていません。
パッケージとテンプレートはGitHubのmicrosoft/Managed-Appsリポジトリで公開されています。既定の雛形はReactとTypeScriptとVite 8の構成で、AIコーディングエージェント向けのプラグインの公開先も、同じリポジトリです。プレビュー中はAPIやテンプレートが一般提供までに変わり得ると注記されている点は、本番業務へ載せる時期の判断に効いてきます。
ms app createからms app deployまでを順に実行するコマンドの流れ
CLIのクイックスタートに沿うと、インストールから本番公開までは次のコマンド列になります。アプリ名と表示名は任意に置き換えてください。
# CLIをグローバルに導入して確認（更新も同じコマンド）
npm install -g @microsoft/managed-apps-cli
ms --version
# Entra IDでサインイン（ブラウザーが開く・端末ごとに1回）
ms auth login
# アプリを作成し、プラットフォーム管理のGitリポジトリと雛形を用意
ms app create hello-world --display-name "Hello World"
cd hello-world
# ローカルで実行（設定はpackage.jsonではなくms.config.jsonから読む）
npm install
ms app dev
# コミットしてpush（push自体はビルドを起動しない）
git add .
git commit -m "first pass"
git push
# プレビューを開くと最新コミットのビルドが始まる
ms app play --mode preview
ms app build-status
# 問題なければ本番へ昇格（ライブURLが返る）
ms app deploy
つまずきやすいのは2点です。git push だけではビルドが走らず、プレビューURLを開いた時点でビルドが始まります。ビルドが失敗したら ms app build-status で理由を確認し、直して再度pushします。もう1点、ms app play --mode live で開く本番はデプロイ時点のスナップショットで、コードを更新しても ms app deploy をやり直すまで変わりません。
コネクタを足す前にDLPとACPの判定を設計段階で確かめる方法
データが必要なら、まず ms connector list で使えるコネクタを一覧します。出力にはコネクタID、認証方式、表形式の可否に加えて、DLP（データ損失防止）とACP（高度なコネクタポリシー）の判定も表示される形式です。ここで遮断と出たコネクタを前提に作り込むと、デプロイ時か実行時に止まります。設計の最初にこの一覧を見ておくだけで、手戻りの大半は防げます。
追加は ms app add data-source --connector <connector> で行います。対話モードでは接続の選択、SharePointサイトなどのデータセット、テーブルの順に聞かれ、型付きのモデルとサービスが generated/ 配下へ自動生成される仕組みです。CLIコマンドリファレンスによれば、追加の直前にもDLPとACPの事前チェックが走り、遮断された操作は除外されて件数が報告されます。SharePointリストに列を足した後は ms app refresh data-source で型を再生成してください。
既定で効く統制ポリシーと管理者が開発前に変えるべき設定の適用範囲
次は管理者の視点です。既定値は厳しめに作られており、何もしなくても安全側に倒れます。その代わり、業務要件によっては作り始める前に緩める作業が要ります。
CLI経路は既定オフでPower Platform管理センターから許可する設定
開発者向け概要には「対象の商用クラウドのテナントは自動的にManaged Runtimeを利用でき、管理者の操作は不要」とあります。一方で既定のガバナンス設定には、CLIでの作成を許可する設定が別にあり、パブリックプレビューでは既定オフです。基盤が使えることと、CLIで作れることは別物だと理解してください。
許可するには、Power Platform管理センターで「Copilot」→「設定」→「Managed apps」と進み、CLIでのアプリ作成を許可する項目を環境グループか環境の単位でオンにします。操作できるのはグローバル管理者かPower Platform管理者です。Managed Runtimeの環境ルーティングは一度作られると無効化も削除もできないため、既存のPower Platform環境戦略がある組織は、最初の1本を作る前に環境グループの設計を確認しておくべきでしょう。Power Platformの環境とライセンスの全体像はPower Platformの5つのサービスと料金で整理しています。
既定の18コネクタと12のMCPサーバーおよび遮断される操作の一覧
既定の環境グループで許可されるのは、Entra ID認証だけで動くMicrosoft製の18コネクタです。SharePoint、OneDrive for Business、Teams、Office 365 Outlook、Planner、Excel Online（Business）、Dataverse、Power BI、Azure DevOpsなどが含まれます。サードパーティ製、プレビュー中、カスタムコネクタは対象外です。MCPサーバーはWork IQ系やFabric MCPなど12種が既定で入っています。
| 既定で遮断される操作 | 対象コネクタの例 | 理由 |
|---|---|---|
| 任意のHTTPリクエスト送信 | SharePointなど7種 | 任意のREST呼び出しで用途の枠を越えられる |
| スクリプト・クエリの実行 | Excel Online・Power BI | Office Scripts・自由記述DAXの実行 |
| 任意のプラットフォームAPI呼び出し | Dataverse | カスタムAPIを無制限に呼べる |
HTTPリクエスト送信が止められるのは、SharePoint・Microsoft Teams・Office 365 Outlook・Office 365 Users・Office 365 Groups・Office 365 Groups Mail・Azure DevOpsの7コネクタです。コネクタ自体は残り、上記の操作だけが無効になります。管理者が「このポリシーを編集」で自社管理へ切り替えると追加や削除が自由になる反面、Microsoftによる自動追加が止まります。新しいMicrosoft製コネクタが出ても自動では入らなくなるため、切り替えは許可リストを自社で保守する体制を作ってからにしてください。ローコード基盤で起きやすい権限と野良アプリの論点はローコード開発のセキュリティリスクと対策にまとめました。
CSPの既定値で外部CDNやAPIへの通信が止まる箇所と追記の書き方
アプリには厳格なContent Security Policyが既定で掛かります。connect-src は自オリジンのみ、worker-src と manifest-src は全面禁止、form-action も禁止です。外部のWeb APIをfetchで呼ぶ、CDNからフォントを読む、Service Workerを使う、といったありがちな実装は、そのままでは動きません。管理者が環境グループのCSPルールに出どころを足すと、既定値へ追記される形で合成されます。
# 既定値に許可する出どころを足した結果（追記型で合成される）
script-src 'self' https://contoso.com
connect-src 'self' https://api.contoso.com
font-src 'self' https://fonts.contoso.com
# 既定が 'none' のディレクティブだけは置き換えになる
worker-src 'self'
ワイルドカードの * やスクリプトへの 'unsafe-inline' は、公式も避けるよう明記しています。変更は開発環境で強制し、本番ではまずレポート専用モードで違反を洗い出してから強制へ移す順序が推奨されました。ディレクティブの意味とnonce方式の考え方はコンテンツセキュリティポリシー（CSP）の設定とXSS防御で解説しています。
ライセンスとクレジット課金の構造をアプリ利用者単位で見積もる手順
費用はアプリ単位ではなく、使う人単位で考えます。作る費用と動かす費用が別の画面で管理される点も、見積もりで取り違えやすい箇所です。
Power Apps PremiumとAPI呼び出し0.1クレジットの従量課金の比較
アプリを実行する利用者は、次のどちらかを持つ必要があります。ひとつはPower Apps Premiumで、アプリの操作全体をクレジット消費なしでカバーするライセンスです。もうひとつはManaged Application向けのCopilotクレジットで、アプリの起動ごとと、API呼び出し1回ごとに0.1クレジットが課金されます。この条件はローカルで ms app dev を動かす開発者にも同じく適用されます。
ただし管理者向けページには例外も書かれています。Power Apps Premiumの利用者でも、Work IQ APIのような別課金のサービスを使う場合や、Power Apps PremiumのAPI要求上限を超えた場合はクレジットを消費します。毎日長時間開く業務ツールで利用者が数十人いるならPremium、月に数回しか開かない申請アプリならクレジット払い、という切り分けが目安です。実行時の支出ポリシーはMicrosoft 365管理センターの「Copilot」→「コスト管理」で利用者ごとに設定します。Copilot Studioで作った場合、作成時の課金はPower Platform管理センターの環境単位で管理される別系統です。
クレジット不足時に20操作か5分で遮断されるプレビュー期の挙動
プレビュー期間中、クレジットの要件を満たさない利用者は、最初は警告を受けつつ無料で使い続けられます。そのうえで、アプリ操作が20回に達するか、利用時間が5分に達するか、早いほうで遮断されます。社内展開の初日に「途中で使えなくなった」という問い合わせが来るのは、たいていこの条件です。
展開前に、対象者がPremiumを持っているか、実行時の支出ポリシーの対象に入っているかを名簿で突き合わせてください。作成側の課金だけ整えて公開すると、この遮断に当たります。
Azure App ServiceとCopilot Managed Runtimeの選定
最後に、どちらで作るかを言い切ります。判断軸は、扱うデータがMicrosoft 365の内側で完結するかどうかと、サーバー側の処理を自分で書く必要があるかどうかの2点です。
Managed Runtimeで足りる社内アプリとApp Serviceへ移す要件の境界
| 観点 | Copilot Managed Runtime | Azure App Service |
|---|---|---|
| 認証 | Entra ID組み込み・実装不要 | Entra IDを含め自前で構成 |
| 既定の構成 | 静的ビルド（出力方法は表の直後） | 任意の言語・実行環境（例は表の直後） |
| 外部通信 | CSPで自オリジン限定・管理者が追記 | アプリ側で自由に制御 |
| データ接続 | 承認済みコネクタ経由 | 任意のDB・APIへ直接 |
| 利用者 | テナント内とゲスト | 社外の不特定利用者も可 |
| 費用 | 利用者単位 | App Serviceプランの容量単位 |
Managed RuntimeのCLIは、npm run build で ./dist へ出力し index.html を入口とする構成を既定にしています。App Serviceは.NET・Java・Node.js・Pythonなど、言語と実行環境を選べる構成です。
採用してよいのは、SharePointリストやDataverseのデータを読み書きする部門内の申請・集計・閲覧ツールで、利用者が社員とゲストに限られる場合です。認証も監視も管理者の一覧も最初から付いてくるため、作る側はUIとデータ操作だけに集中できます。
見送るべき場面もはっきりしています。オンプレミスの基幹DBへ直接書き込む処理、外部SaaSと常時連携するバッチやWebhook受信、顧客向けの社外公開サイトです。CLIの既定構成はフロントエンドのビルド成果物を配る形で、外部通信はCSPと承認済みコネクタの枠内に閉じます。この枠に合わない要件を押し込むと、管理者への例外申請が増えるだけです。そうした案件は、Azure App Serviceの価格レベルとデプロイスロットのように実行環境を自分で持つ構成へ切り替えるべきでしょう。
GitHub Enterprise Cloud必須などリポジトリ要件で詰まる組織の条件
既定では、プラットフォームが管理するGitリポジトリが自動で用意されます。自社のGitHubで管理したい場合は作成時に --repo でURLを渡しますが、対応するのはGitHub Enterprise Cloudの組織が所有するリポジトリだけです。GitHub Enterprise Server、個人アカウント所有のリポジトリ、Azure DevOpsのリポジトリは対象外で、リポジトリの種類は作成後に変更できません。
Azure DevOpsでソース管理を回している組織は、ここで既存の運用から外れます。外部でビルドした成果物を配る方法もありますが、外部アーティファクトのデプロイは既定で禁止され、許可しても検証責任は自社に残ります。PoCの前に確認しておくべき項目です。Power Platformを含めた社内アプリの基盤選定や、Managed Runtimeで受けきれない要件の切り分けは、Power Platform（PowerApps）導入支援サービスで環境設計から伴走できます。
Copilot Managed Runtimeの導入検討でよく挙がる質問に実務目線で答える
検討時に繰り返し聞かれる論点を、2026年10月時点の公開情報にもとづいて整理します。
Copilot Managed Runtimeは追加の契約やインストールが必要ですか？
基盤そのものは、対象となる商用クラウドのテナントで自動的に使える状態になり、別途のインストールは不要です。ただし作成経路ごとの有効化は別で、CLI経路はパブリックプレビュー時点で既定オフ、Cowork経路ではFrontierプログラムへの参加が条件になります。アプリを実行する利用者には、Power Apps PremiumかCopilotクレジットの割り当てが必要です。
Power Appsのキャンバスアプリとは何が違いますか？
Power AppsはPower Fxで画面を組み立てるローコードの道具です。Managed RuntimeのSDK経路は、ReactとTypeScriptでコードを書き、Gitで管理する開発者向けの経路になります。どちらもPower Platformの環境とコネクタの統制下に置かれます。
外部のWeb APIを呼ぶアプリは作れますか？
既定のままでは呼べません。CSPの connect-src が自オリジンに限られ、既定のコネクタもMicrosoft製の18種に絞られているためです。管理者がCSPへ出どころを追記するか、コネクタの許可リストを自社管理に切り替える必要があります。例外が多くなりそうなら、App Serviceなど別の実行環境を選んだほうが運用は軽くなります。
作ったアプリを社外の取引先に使ってもらえますか？
共有ルールで「ゲストユーザーとの共有を許可」をオンにすれば、テナントにゲスト登録した外部ユーザーへ共有できます。共有は ms app share で利用者やグループを指定するか、テナント内向けの共有リンクで行います。不特定多数への公開は想定されていないため、顧客向けサイトには使えません。
プレビュー版を本番業務に使っても問題ありませんか？
プレビュー機能は補足利用規約の対象で、正式リリース前に提供されていると公式が明記しています。CLIは0.x系で、APIやテンプレートが一般提供までに変わり得るとも注記されています。部門内の補助ツールで影響範囲を限って試し、業務が止まると困る基幹系の画面は一般提供と価格の確定を待つのが安全です。
関連記事
- Copilot Studioとは？基本機能・トピックの作り方・料金・始め方まで解説：Managed Runtimeのアプリを作るもう一つの入口であるCopilot Studioの基本を解説しています。
- Copilot Coworkとは？管理者設定とSKILL.md自作・上限値を実装者視点で解説：チャットでアプリを作らせる経路の土台になるCoworkの設定を扱っています。
- Azure App Serviceとは？仕組み・価格レベル・デプロイスロットの実装手順：Managed Runtimeの枠に収まらない要件を受ける実行環境の比較先です。
- Power Platformとは？5つのサービス・できること・料金と内製の判断まで解説：Managed Runtimeが載る環境とライセンスの全体像を整理しています。
- ローコード開発のセキュリティリスクと対策｜権限設計・野良アプリ・発注時の確認項目：社内アプリが増えたときの統制の論点を確認できます。
