Copilot CLIで始めるCopilot Managed Runtime：社内アプリ開発ガイド

Copilot Managed Runtimeとは何か

Copilot Managed Runtimeは、社内業務アプリ向けのマネージド実行環境です。コードは引き続き編集でき、ソース管理には通常のGitを使えます。そのうえでMicrosoftが、ホステッドランタイム、Microsoft Entraによるサインイン、統制されたデータ接続、プレビューとデプロイの仕組み、管理者向けインベントリを提供します。

コード向けのサービスオフィスビルと考えると分かりやすいでしょう。各部屋で何をするかは自分で設計しますが、入館受付、電気や水道、安全規則、保守記録、施設管理はビル側が用意します。部屋の間取りだけを生成するAIコーディング環境とは、役割が異なります。

Microsoftは、このSDKを社内業務アプリの開発レイヤーと位置づけています。独自のIDコードを書かずにEntra認証を組み込めるほか、JavaScriptとTypeScriptから1,500を超えるコネクタへアクセスできます。ただし、アプリが実際に使えるコネクタとアクションはテナントポリシーで決まります。判断材料になるのは、パブリックプレビュー版のSDK概要と提供開始の発表です。

本ガイドでは、現時点で利用できるSDKとCLIを扱います。Copilot CodeやAutopilotを、このツールチェーンの別名として混同しません。

アプリはどこに置かれるのか

アプリのライフサイクルによって、答えは変わります。

この切り分けは重要です。プレビューを更新してもライブ版は安定したままで、プレビューのビルドに失敗しても最後に成功した版は置き換わりません。

Copilot CLIはコードより先に利用条件を確認

アプリが完成してからテナントやライセンスの制約に気づくと、丸一日を簡単に失います。まず、次の項目を確認してください。

課金方法と管理ポリシーは、予算判断を分けて行うべきテーマです。パイロットグループへアクセスを与える前に、別記事のCopilot Managed Runtime料金内訳を確認してください。本ガイドで押さえておくべき運用上のポイントは、ローカル実行が無料の抜け道にはならないことです。エンドユーザーと同じランタイム利用権が必要です。

本ガイドで実際に確認した範囲

パッケージの確認は実施しましたが、テナント上での実行は行っていません。

したがって、本稿では、最初のローカルページやホステッドプレビューが表示されるまでの時間、実際に発生したビルドエラー、確認済みのEntra ID、実行済みのコネクタ呼び出し、デプロイ、ランタイム料金について実測結果を提示しません。以下はMicrosoftの文書に基づく手順であり、実機検証を装ったものではありません。

小さな業務アプリをCopilot CLIで動かす

ここでは、Ops Intakeという架空のアプリを使います。最初の役割は控えめです。テナントで承認されたデータソースからレコードを取得し、読み取り専用のキューに表示します。初回のポリシーレビューを理解しやすくするため、まずは読み取り操作だけで始めます。ID、ソース権限、コネクタポリシー、ランタイム利用権を確認できてから、書き込みを追加してください。

再現性を保つため、次の手順では2026年9月27日に確認したCLIバージョンを固定します。プレビュー版パッケージの更新でパイロットの挙動が知らないうちに変わらないよう、実際に選んだバージョンもリポジトリへ記録してください。

npm install -g @microsoft/managed-apps-cli@0.25.1
ms --version

ms auth login
ms app create ops-intake --display-name "Ops Intake"
cd ops-intake

npm install
ms app dev

ms connector list --search SharePoint
ms connector list-actions --connector <allowed-connector-id> --search list
ms app add data-source --connector <allowed-connector-id>

git add .
git commit -m "first ops intake flow"
git push

ms app play --mode preview
ms app build-status
ms app deploy

各段階で何が変わるのかを見ていきます。

1. サインインして統制されたアプリの器を作る

ms auth loginを実行すると、Microsoft Entraのサインイン画面が開きます。画面のないマシンでは、CLIの--device-codeも利用できます。ms app createはアプリのレコードとプロジェクトのひな型を作成し、初期状態ではプラットフォーム管理のGitリポジトリを使います。初回のcreateまたはinitでは、ルーティングで許可されていれば、作成者のIDにひもづく開発者環境も用意されます。

リポジトリ方式を安易に選んではいけません。最短で始められるのはプラットフォーム管理のGitです。外部リポジトリとして使えるのはGitHub.comまたはGitHub Enterprise Cloudです。GitHub Enterprise Server、Azure DevOps、そのほかのプロバイダーは、この経路ではサポートされません。リポジトリ方式はアプリの存続期間中ずっと固定されるため、後から変えるには別のアプリを作る必要があります。

2. ローカルで実行し、最初の実用画面までの時間を記録する

ひな型の依存関係を一度インストールしてから、ms app devを実行します。このコマンドはms.config.jsonを読み、プロジェクトの開発プロセスを開始して、Local Play URLを表示します。テナントへのサインインに使ったものと同じブラウザプロファイルで開いてください。

ms app devを実行する直前に計測を始め、最初に操作可能なページが表示された時点で止めます。ブラウザの権限確認で中断した時間は分けて記録します。ChromeとMicrosoft Edgeでは、ローカルネットワークへのアクセスを許可するまで、公開オリジンからlocalhostへの接続がブロックされることがあります。これはアプリのビルド失敗ではなく、ブラウザ側の制約です。

3. 統制された読み取りを1件通す

ms connector listには、コネクタID、認証方式、表形式データへの対応状況に加え、Data Loss PreventionとAdvanced Connector Policyの両方のステータスが表示されます。その環境での判断には、この出力を信頼できる情報源として使います。Microsoftのカタログに載っているコネクタでも、自社テナントで自動的に許可されるわけではありません。

Ops Intakeでは、許可済みのSharePoint接続、データセット、リストを選び、読み取りまたは一覧取得の操作を指定します。対話形式のms app add data-sourceを使うと、型付きのTypeScriptモデルとサービスがgenerated/配下に生成されます。独自のGraphトークン処理を作らず、生成された読み取りメソッドをアプリから呼び出してください。

ブラウザで次の3点を確認します。

1. サインイン中のユーザーが、想定したEntra IDであること。
2. そのユーザーには、データソース側ですでに許可されたレコードだけが表示されること。
3. 同じユーザーからデータソースへの権限を外した場合、アプリが安全に失敗すること。

後でアプリを共有しても、基になるデータへのアクセス権まで付与されるわけではありません。利用者ごとに、適切なデータソース権限と接続が引き続き必要です。これはデプロイ上の面倒ではなく、意図された機能です。

4. 実際のソースをコミットしてpushする

通常のGitコマンドを使います。ランタイムCLIはソース管理の代わりにはなりません。コミットには、動作するアプリの変更と、プロジェクトに含めるべき生成済みコネクタバインディングを入れます。

注意すべき点は単純です。git pushではアプリはビルドされません。更新されるのはリモート上の信頼できるソースだけです。

5. ホステッドプレビューを開いてビルドを確認する

ms app play --mode previewを実行すると、固定されたプレビューエンドポイントが開きます。最新のpush済みコミットが未ビルドなら、プレビューを開いた時点でビルドがキューに入ります。プレビューを開いてから新しい版が使えるようになるまでの時間を記録してください。

ビルドに失敗したら、必要に応じて--commit <sha>を付けてms app build-statusを実行し、理由を省略せずそのコミットと一緒に保存します。新しい版がビルド中または失敗した場合も、プレビューでは直前に成功したビルドが引き続き配信されます。プレビューURLを使えるのは、リポジトリへの書き込み権限を持つ開発者であり、任意のレビュー担当者ではありません。

プレビューを開く前にビルドを始めたい場合は、ms app buildを実行できます。ただし、多くのチームが最初に理解すべきなのは、ソースをpushし、その後プレビューを開くという標準の挙動です。

6. 確認済みのバージョンだけをデプロイする

ms app deployは、成功したビルドをライブアプリへ昇格させます。ライブ版は固定されたスナップショットで、pushやプレビューのビルドに自動追従しません。

計画的にリリースするには、コミットSHAを記録し、ビルド状態を確認して、そのプレビューを開いたうえで、ms app deploy --commit <sha>により対象SHAをデプロイします。同じオプションを使えば、Git履歴を書き換えずに、以前成功したビルドへ明確にロールバックできます。

ビジネスコストはプラットフォーム層で変わる

このランタイムを使っても、アプリ開発そのものが無料になるわけではありません。変わるのは、自社で別途購入または構築しなければならない範囲です。

比較対象となるソフトウェア予算も小さくはありません。Retoolの公式料金ページでは、Teamプランがビルダー1人あたり月額$10、社内ユーザー1人あたり月額$5、Businessプランがビルダー1人あたり月額$50、社内ユーザー1人あたり月額$15です。Copilot Managed Runtimeが自動的にこれより安くなるわけではありません。Microsoft 365を利用する組織では個別のプラットフォーム構築を減らせる一方、ランタイムのライセンスやクレジット、コネクタ対応、管理工数は現実のコストとして残ります。

安いと判断する前に、次の式でパイロット費用を見積もってください。

パイロット費用 = 開発者の工数 + 管理設定 + ランタイム利用権 + コネクタとデータ対応。

最も削減しやすいのは、プラットフォームを組み立てる工数です。最も想定外になりやすいのは、アプリを開く全ユーザーのランタイム利用権です。

このランタイムに適した社内アプリ7選

特に相性がよいのは、一般公開のストアフロントよりも、ID、統制されたMicrosoft 365データ、管理されたリリースが重要になる社内ワークフローです。

どのユースケースも、まずは読み取り専用で始めるべきです。書き込み操作、外部エンドポイント、サードパーティ製コネクタ、広範囲に共有するアプリを加えると、レビューの前提が変わります。初期ポリシーで利用できるのはMicrosoftのファーストパーティ製コネクタ18個であり、カタログ全体ではありません。また、承認済みコネクタ内であっても、用途を限定しないHTTP、任意コード、任意クエリ、任意プラットフォームの一部操作はブロックされます。

Copilot Managed Runtimeを軸に作るべき3つの製品

最有力なのは、Microsoft 365向けオンボーディング・コマンドセンターです。実測した需要が最も大きく、ID、文書、タスク、メール、チーム間の引き継ぎを自然に横断するワークフローだからです。

1. Microsoft 365オンボーディング・コマンドセンター

人事部門とIT部門が、承認済みの新入社員レコード、未完了タスク、文書リンク、担当者を1つの社内アプリで確認できるようにします。引き継ぎ漏れを減らし、監査証跡を簡素化できるため、人事オペレーション部門とITサービス部門にとって支払う価値があります。

需要は数値にも表れています。「employee onboarding software」は米国で月間約590回検索され、検索意図は商用、クリック単価は$156.35です。より絞り込んだ**「best employee onboarding software」は月間90回検索され、サジェストデータでは年間トレンドが180%伸びました**。

販売可能な最小構成では、1部門に対象を絞り、承認済みの従業員リストを1つ読み取り、タスクのチェックリストを表示して、各タスクを担当者へひもづけます。読み取り経路がポリシーと権限のテストを通ってから、コネクタ操作を追加します。

ただし、課題は重大です。人事データは機密性が高く、データソース権限は誤解されやすいうえ、既存のオンボーディング製品はすでに幅広い人事ワークフローをカバーしています。この製品が勝てるのは、一般的な長い機能一覧より、Microsoft 365のガバナンスとテナント内でのネイティブな運用が重視される場合に限られます。

2. 統制された承認コックピット

判断ステータスは明確でも、根拠となる情報が散在している財務、調達、オペレーション部門向けに、再利用可能な承認画面を作ります。購入者が対価を払うのは、別のフォーム作成ツールではなく、審査の迅速化と統制されたリリースプロセスです。

「Approval workflow software」は米国で月間約320回検索され、検索意図は商用、クリック単価は$114.86、サジェストデータの年間トレンドは53%伸びています。この組み合わせは、積極的に購入が検討されている課題であり、Microsoft 365に特化した実装が入り込める余地を示しています。

MVPは、1種類の依頼、1つの承認済みデータソース、読み取り専用のレビュー画面、判断履歴、ポリシーで承認された1つの操作で構成します。判断モデルは決定論的に保ち、承認ルールを生成文の中へ隠してはいけません。

課題はコネクタポリシーです。コネクタ自体が許可されていても特定の操作はブロックされる場合があり、従来のデータポリシーとAdvanced Connector Policiesが併用されると、最も厳しい結果が適用されます。

3. マネージドアプリ移行診断

AI生成または独自開発の社内Webアプリを1つ受け取り、Copilot Managed Runtimeへ移行できるかを判定する、定型化された診断サービスを提供します。対象となる顧客は、役に立つプロトタイプを持ちながら、独立したホスティングとガバナンス基盤を新たに運用したくないMicrosoft 365利用組織です。

「Custom business app development」は米国で月間約90回検索され、検索意図は商用、クリック単価は$84.03です。検索量は小さいものの、サービス購入に近いクエリです。

MVPでは、アプリのリポジトリ、ランタイムの前提、外部エンドポイント、IDコード、データソース、必要な操作を棚卸しします。そのうえで、移行可、要変更、中止のいずれかを判定し、読み取り専用の一部分をテスト環境へ移植します。

課題はプラットフォームへの依存です。結果が役立つのは対象となるMicrosoft 365テナントに限られます。パブリックプレビューの挙動は変わる可能性があり、非対応のソースプロバイダーやブロックされた外部リソースがあると、一見単純な移行でも作り直しになる場合があります。

Copilot Managed Runtimeでは解決できないこと

これは統制された社内アプリには有望な経路ですが、あらゆるアプリに使える万能プラットフォームではありません。

• パブリックプレビュー中の機能で、ドキュメントもプレリリース版です。コマンドの挙動やポリシー画面は変わり得るものとして扱う必要があります。
• CLIからアプリを作成する経路が自動的に有効になるわけではありません。テナントがランタイムの対象でも、この経路は初期状態で無効です。
• 1,500を超えるすべてのコネクタが、許可済みデータソースになるわけではありません。アクセス可否は、テナントポリシー、コネクタのアクションポリシー、従来のデータポリシー、データソース権限で決まります。
• 社内業務アプリを一般顧客向けの公開製品に変えるものではありません。プレビューを使えるのはリポジトリへの書き込み権限を持つ開発者に限られ、ライブ版へのアクセスも統制モデルの中で明示的に共有します。
• すべてのリポジトリプロバイダーに対応するわけではありません。外部ソースとして使えるのはGitHub.comとGitHub Enterprise Cloudだけで、リポジトリ方式はその場で変更できません。
• ランタイムライセンスは不要になりません。ローカル実行とユーザーによる実行には、Power Apps Premiumまたは資金が割り当てられたManaged Application Copilot Creditsが必要です。
• 管理者が完全なフォレンジック記録を得られるわけではありません。管理画面ではインベントリ、利用状況、正常性、コネクタ、データソース、依存関係を確認できますが、Microsoftによれば、正確な接続先、動的エンドポイント、実行された操作、各ユーザーに実際に適用されるデータソース権限を完全に把握できるものではありません。
• 本稿の検証環境でデプロイできたことを証明するものではありません。Git Credential Manager、Linuxのシークレットストア用ライブラリ、対象テナントがなかったため、サインイン前に検証を中止しました。

結論は明快です。アプリが社内向けで、組織がすでにMicrosoft 365を中心に業務を行い、IDとガバナンスの構築を省ける価値が、プレビュー段階のプラットフォームとテナント統制を受け入れる負担を上回る場合に使います。一般公開のSaaS製品、別のソースプロバイダー、インフラの制御、または管理者が許可できないリリースモデルが必要なら、別のホストを選ぶべきです。

よくある質問

月曜に着手すること

Power Platform管理者に、1つのテストグループ向けにCLIからの作成を有効にしてもらい、そのグループの環境ルーティングルールを確認し、2人のテストユーザーにランタイム利用権を用意します。機密性のないSharePointリストを1つと、読み取り専用操作を1つ選びます。そのうえで開発者は、CLIバージョン、最初のローカルページまでの時間、ホステッドプレビューまでの時間、デプロイしたコミットSHAという4項目をパイロットログへ記録してください。Entra ID、データソース権限、コネクタポリシーの挙動が想定どおりでなければ、パイロットを中止します。

この統制されたアプリ基盤を自社向けに設計・構築したい場合は、AIプロダクションシステム診断から始めてください。