--- title: "Microsoft Execution Containers（MXC）とは？9バックエンドの選び方とSDKの実装手順【2026年9月時点】" url: "https://www.issoh.co.jp/tech/details/12384/" published: 2026-06-05 updated: 2026-10-16 categories: ["AI"] publisher: "株式会社一創" --- # Microsoft Execution Containers（MXC）とは？9バックエンドの選び方とSDKの実装手順【2026年9月時点】 AIエージェントにコードを書かせて実行させる場面が増えるほど、そのプロセスがログイン中のユーザーと同じ権限で動いてしまう点が問題になります。Microsoft Execution Containers（MXC）は、エージェントに許す範囲をポリシーとして宣言し、OS側が実行中ずっとその境界を強制し続けるためのSDKです。ここでは2026年9月23日時点のリポジトリ・スキーマ定義・リリースノート・公式ブログを照合し、9つのバックエンドの使い分けから最小実装までを整理します。本文の表と手順は原則としてリポジトリのmainを基準にしており、npmで入る公開版0.8.0との差は後述の対照表で示します。 ## まとめ 結論として、MXCは「エージェントを動かしてよいか」を起動前に判断する仕組みではなく、動き続けているプロセスに対してファイル・ネットワーク・UIの境界を実行時に当て続ける層です。ただし早期プレビューであり、公式リポジトリは現時点のプロファイルをセキュリティ境界として扱わないよう明記しています。 - バックエンドは9種類で、実験扱いは`windows_sandbox`・`microvm`・`hyperlight`の3つだけです。残る6つは実験フラグなしで使えます。 - 新規のポリシーで宣言する版は`0.9.0-alpha`です。`0.4.0-alpha`と`0.5.0-alpha`は下限を割って受け付けられなくなりました。 - Node.jsの要件はリポジトリ現行で24以上です。Windowsではさらに24.21.0以上か26.8.0以上が要り、26.8.0以上が推奨されています。 - WindowsのProcessContainerは3つの隔離ティアを実行時に選びますが、実際に全リリースで動くのは最下層のAppContainer＋DACLだけです。 - v0.8.0のリリースノートは、24H2と25H2にはOS側の変更がまだ入っていないと明記しています。最新機能を試すにはInsider Preview Build 26340.9212以上が必要です。 - ネットワークは0.3.0以降つねに既定拒否です。`network`を書かなければ通信できず、`process.cwd`を指定してもそのパスへのアクセス権は付きません。 - GitHub Copilot CLIがプロセス分離を採用しています。そのローカルサンドボックスは実験的機能として始まり、2026年10月7日に一般提供となりました。有効化の手順と組織で強制する設定は[GitHub Copilotのサンドボックスとは？有効化手順と組織で強制する管理設定](https://www.issoh.co.jp/tech/details/18395/)で整理しています。 - npmで入る0.8.0とリポジトリmainでは、Node.js要件・安定スキーマ・バックエンドの安定判定が食い違います。どちらを見ているかを意識して読む必要があります。 以下では、MXCの位置づけ、9バックエンドの選択基準、ProcessContainerが実際に強制できる範囲、版とNode.jsの要件、SDKの最小実装、既存の隔離手段との違いを順に示します。 ## MXCがAIエージェントに対して解こうとしている問題 従来のエンドポイント制御は、バイナリの信頼性やマルウェア定義との照合など、起動の可否を入口で判断する設計でした。エージェントはこの前提と相性が良くありません。起動時点では無害な実行ファイルでも、プロンプトごとに新しいコードを生成し、その場で実行するためです。 ### Build 2026で早期プレビューとして公開されたSDK MXCは2026年6月2日のBuild 2026で公開されました。Windows Developer Blogは`we are introducing an early preview of the Microsoft Execution Containers (MXC) SDK, a cross-platform, policy-driven execution layer for agents on Windows and WSL`と書いています。購入する製品ではなく、開発者が自分のアプリやエージェントに組み込むSDKという提供形態です。Build 2026の発表全体は[Microsoft Build 2026のGitHub・GitHub Copilot発表まとめ｜企業の導入判断と新機能](/tech/details/12741/)にまとめています。 実装は`github.com/microsoft/mxc`でMITライセンスのまま公開されています。GitHub APIで2026年9月23日に取得した時点でスター1,355・フォーク81・未解決Issue 41（未マージのプルリクエスト20件は別）で、リポジトリ自体は2026年2月に作られています。Rustで書かれたネイティブ実行体とTypeScript SDKの二層構成で、リポジトリには`sdk/dotnet`も追加されています。 ### MXCによる実行時の境界強制という設計転換 MXCが担うのは、許可したパスとネットワーク範囲をJSONで宣言し、その外側への到達をOSが実行中に拒否し続けることです。ポリシーの対象はファイルシステム・ネットワーク・UIの3領域で、UIにはクリップボードやディスプレイ、GUIアクセスの制御が含まれます。 すでに実運用に入っている例もあります。同ブログは`GitHub Copilot CLI has adopted MXC process isolation to constrain what dynamically generated and executed code can do.`と述べており、Copilot CLIが生成コードの実行範囲をMXCのプロセス分離で絞っています。ただし採用と提供状態は別です。GitHubのドキュメントは`In Copilot CLI, local sandboxing is currently an experimental feature.`および`Local sandboxing is turned off by default.`と書いており、使うには`--experimental`を付けて起動するか、セッション中に`/experimental on`を入れる必要があります。Copilot CLI自体の動作モードや料金は[GitHub Copilot CLIとは？Autopilot・Planなど動作モードと料金・インストールを解説](/tech/details/11137/)で扱っています。 ### セキュリティ境界として扱えないという明示的な制約 導入を検討するうえで最も重要な制約は、リポジトリのREADMEが冒頭の警告で`no MXC profiles should be treated as security boundaries currently`と書いている点です。現時点で生成されるポリシーには過度に緩いケースが既知であり、一般提供の前に対処するとされています。つまり多層防御の1枚として足す分には意味がありますが、これ1つで信頼できない第三者のコードを安全に隔離できるとは公式が言っていません。 ## 9つのバックエンドと選択基準 MXCは単一の隔離技術ではなく、同じポリシーを複数の隔離方式へ振り分ける抽象層です。READMEが列挙するバックエンドはProcessContainer、Windows Sandbox、LXC、Bubblewrap、Seatbelt、MicroVM（NanVix）、Hyperlight、IsolationSession、WSLCの9種類です。 ### バックエンド一覧と最小スキーマ・安定/実験の別 | バックエンド | 抽象インテント | プラットフォーム | 最小スキーマ | 安定/実験 | | ------------------ | ------- | ----------------------- | ------------ | ------ | | processcontainer | process | Windows | 0.6.0-alpha | 安定（既定） | | bubblewrap | process | Linux | 0.6.0-alpha | 安定（既定） | | lxc | 具体名のみ | Linux | 0.6.0-alpha | 安定 | | seatbelt | process | macOS | 0.7.0-alpha | 安定（既定） | | wslc | 具体名のみ | Windows | 0.9.0-alpha | 安定 | | isolation\_session | 具体名のみ | Windows | 0.9.0-alpha | 安定 | | windows\_sandbox | vm | Windows | 0.10.0-alpha | 実験 | | microvm | microvm | Windows | 0.10.0-alpha | 実験 | | hyperlight | 具体名のみ | Windows x64 / Linux x64 | 0.10.0-alpha | 実験 | 実験扱いの3つは`SandboxSpawnOptions`に`{ experimental: true }`を渡すか、CLIで`--experimental`を付けないと選べません。Hyperlightはさらに出荷バイナリに含まれておらず、`--with-hyperlight`を付けてソースからビルドする必要があります。 ### 抽象インテントと具体名の使い分け バックエンドは`createConfigFromPolicy(policy, containment)`の第2引数で選びます。可能な限り`process`・`vm`・`microvm`という抽象インテントを渡し、ホストに合う実体はSDKとネイティブ側に解決させる設計です。ホストごとに分岐を書かずに済みます。 注意点として、同じ`process`でも必要な版が変わります。macOSではSeatbeltへ解決されるため0.7.0-alpha以上が要り、WindowsとLinuxでは0.6.0-alphaのままです。`vm`インテントは0.10.0-alphaを要求します。 ### Build時点のロードマップと現在の実装差 Build 2026の発表では、マイクロVM・Linuxコンテナ・Windows 365 for Agentsとの統合は`Some other MXC containment capabilities currently on our roadmap are:`の配下に並ぶ予定項目でした。3か月後の現在、マイクロVMは`microvm`として実験バックエンドに、WSL経由のLinuxコンテナは`wslc`として安定バックエンドに実装されています。一方でWindows 365 for Agentsは一般提供済みですが、MXC統合そのものは`With the future addition of MXC integration`＝将来の追加という位置づけのままです。 マイクロVMという隔離方式自体の仕組みは[Firecracker（マイクロVM）とは？仕組み・KVMとの関係とgVisor・コンテナとの使い分けを実装者目線で解説](/tech/details/15691/)が詳しく、WSL側の準備は[WSLで開発環境を構築する手順｜.wslconfig調整とDocker連携・肥大化の対処](/tech/details/17354/)を参照してください。 ## ProcessContainerがWindowsで実際に強制できる範囲 Windowsの既定バックエンドである`processcontainer`は、ドキュメント上は最小ビルド26100（24H2）と書かれています。実施範囲の正本は[Windows OS-version policy support](https://github.com/microsoft/mxc/blob/main/docs/backends/process-container/os-version-support.md)です。ただし実際に何が強制されるかはビルドによって変わり、ここを読み違えると「ポリシーを書いたのに効いていない」という状態になります。 ### 実行時に選ばれる3つの隔離ティア | ティア | 機構 | 23H2 (22631) | 24H2 (26100) | 25H2 (26200) | 25H2+ (26600+) | | ---------------------- | ---------------------- | ------------ | ------------ | ------------ | -------------- | | T1 BaseContainer | PSEC（processmodel.dll） | 不可 | 不可 | 不可 | OSコントラクト有効時のみ | | T2 AppContainer + BFS | bfscfg.exe駆動 | 未出荷 | ビルドでOFF | ビルドでOFF | ビルドでOFF | | T3 AppContainer + DACL | ホスト側パスACE追加 | 可 | 可 | 可 | 可 | T1はPSEC（`CreateProcessSecurityEnvironment`）の契約が有効な25H2+（ビルド26600以降）でしか成立せず、25H2までのビルドや契約が無効な環境ではT3へ落ちます。T2は`bfscfg.exe`の呼び出しが25H2でホストをデッドロックさせうるため、`tier2_bfs`というCargoフィーチャーが全出荷ビルドでオフになっています。事実上、手元で確実に効いているのはT3のAppContainer＋DACLだと考えて設計するのが安全です。 ここは実際の採用側にも効いてきます。GitHubのドキュメントは`Windows uses the BaseContainer tier of the ProcessContainer backend. Copilot CLI does not use the AppContainer fallback tiers.`と書いており、Copilot CLIはT1しか使いません。BaseContainerを用意できないWindowsビルドでは、サンドボックス非対応として扱われます。 ### 24H2・25H2でProcessContainerの機能が揃わない事情 v0.8.0のリリースノートは`Windows 11 24H2 and 25H2 machines do not yet include all of the required OS-side changes, so ProcessContainer will not be fully featured on those builds.`と明記しています。最新のProcessContainer機能を今すぐ試すにはInsider Preview Build 26340.9212以上が要り、24H2と25H2への反映は今後の更新で入る見込みとされています。`isolation_session`バックエンドの最小ビルドも同じ26340.9212です。 ### Learning Modeによる拒否の記録とポリシー調整 ポリシーを一発で書ききるのは現実的ではないため、v0.8.0でWindowsのProcessContainerに拒否内容の記録機能が入りました。`processContainer.learningMode`は拒否したまま記録する動作で、逆にCLIの`--audit`は`permissiveLearningMode`を注入して「拒否されたはずの操作を通しつつ記録する」動作になります。 後者はAppContainerの制限がその実行中は効かなくなるため、ポリシー作成専用です。本番のワークロードに付けるものではありません。`--audit`はWindows Sandbox・WSLC・IsolationSessionを含む他のバックエンドでは拒否されます。 ## スキーマ版とNode.jsの要件 MXCはSDKの版とポリシースキーマの版が別に動きます。正本は[schemas/schema-version.json](https://github.com/microsoft/mxc/blob/main/schemas/schema-version.json)で、ここに現行の安定版と開発版が書かれています。SDK側の対応表は[sdk/node/README.md](https://github.com/microsoft/mxc/blob/main/sdk/node/README.md)、公開版の内容は[v0.8.0のリリースノート](https://github.com/microsoft/mxc/releases/tag/v0.8.0)にあります。 ### ポリシースキーマの登録済みの版と失効した版 | 版 | 状態 | 置き場所 | | ------------ | ------------- | -------------- | | 0.4.0-alpha | 失効（下限未満で不受理） | schemas/stable | | 0.5.0-alpha | 失効（下限未満で不受理） | schemas/stable | | 0.6.0-alpha | 安定（サポート下限） | schemas/stable | | 0.7.0-alpha | 安定 | schemas/stable | | 0.8.0-alpha | 安定 | schemas/stable | | 0.9.0-alpha | 安定（新規はこれ） | schemas/stable | | 0.10.0-alpha | 開発（実験バックエンド用） | schemas/dev | 版は登録済みの文字列と完全一致でなければ通りません。`0.6.1-alpha`のように範囲内でも未登録の値を書くと`Policy version '' is not a registered schema contract`で弾かれます。ステートフル実行の既定版はバックエンドごとに独立していて、IsolationSessionとWSLCが0.9.0-alpha、Windows Sandboxだけが0.10.0-alphaです。 ### npm公開版0.8.0とリポジトリmainの差分 ここは実際に詰まる箇所です。`npm install`で入るのはタグv0.8.0の内容で、上の版一覧を含む本記事の表はmainの内容です。両者は次の点で食い違います。 | 項目 | npm公開版 0.8.0 | main（2026-09-23） | | ------------------------- | ------------ | -------------------- | | engines.node | \>=18.0.0 | \>=24.0.0 | | 現行の安定スキーマ | 0.8.0-alpha | 0.9.0-alpha | | 開発スキーマ | 0.9.0-dev | 0.10.0-alpha | | wslc / isolation\_session | 実験 | 安定 | | hyperlight | 記載なし | 実験（要ビルドフラグ） | | macOS | ARM64 | ARM64（READMEはx64も記載） | つまり`npm install`は古いNodeでも警告なく通る一方、mainのREADMEが要求する構成には足りません。公開版のまま`0.9.0-alpha`を宣言したり、`wslc`を実験フラグなしで選んだりすると弾かれます。 READMEはWindowsについてさらに細かく、`fs.ReadStream`と`fs.WriteStream`が使う`windowsHandle`オプションのため、Node.js 24系なら24.21.0以上、あるいは26.8.0以上が必要で、26.8.0以上を推奨としています。ソースからビルドする場合はRustツールチェーンも`src/rust-toolchain.toml`で1.93に固定されています。Node側の版選びは[Node.js 26の新機能・変更点とLTSスケジュール総まとめ](/tech/details/12014/)も参考にしてください。 なおパッケージは0.2.0からPure ESMです。CHANGELOGはこの変更について、CommonJSからの同期的な`require`が使えなくなったとし、`await import()`への切り替えかプロジェクト側のESM化を案内しています。 ## SDKの最小実装 インストールは`npm install @microsoft/mxc-sdk`です。以下のコードはすべてリポジトリのREADMEに載っている形をもとにしています。 ### SDKによる一回限りのサンドボックス実行 推奨される経路は`createConfigFromPolicy`で設定を組み立て、`spawnSandboxFromConfig`で起動する形です。ホスト上のツールや一時ディレクトリは、探索ヘルパーに列挙させるとポリシーを環境非依存にできます。以下の3例はいずれもTypeScriptで、ESMとして実行できる構成が前提です。 ``` import { spawnSandboxFromConfig, createConfigFromPolicy, getAvailableToolsPolicy, getTemporaryFilesPolicy, getPlatformSupport, } from '@microsoft/mxc-sdk'; if (!getPlatformSupport().isSupported) { throw new Error('MXC not available on this host'); } const tools = getAvailableToolsPolicy(process.env); const temp = getTemporaryFilesPolicy(); const config = createConfigFromPolicy({ version: '0.9.0-alpha', filesystem: { readonlyPaths: tools.readonlyPaths, readwritePaths: temp.readwritePaths, }, timeoutMs: 30_000, }); config.process!.commandLine = 'python -c "print(1)"'; const child = spawnSandboxFromConfig(config, { usePty: false }); child.stdout!.on('data', (d) => process.stdout.write(d)); child.stderr!.on('data', (d) => process.stderr.write(d)); child.on('close', (code) => console.log('exit:', code)); ``` `createConfigFromPolicy`は`commandLine`を空のまま返すため、起動前に必ず自分で入れます。`usePty: false`にすると標準出力と標準エラーが分かれた状態で受け取れるので、サンドボックス側が出した失敗理由を取りこぼしません。 ### スキーマ0.8以降の方向別ネットワークポリシー ネットワークは0.3.0の破壊的変更以降、つねに既定拒否です。0.8.0-alphaからは送信と受信を分けた方向別の記法に変わり、宛先をCIDR・プロトコル・ポートで指定します。 ``` { "version": "0.8.0-alpha", "containment": "process", "process": { "commandLine": "node agent.js" }, "network": { "egress": { "default": "deny", "allow": [ { "to": [{ "cidr": "192.0.2.0/24" }], "ports": [{ "protocol": "tcp", "port": 443 }] } ] }, "ingress": { "default": "deny", "hostLoopback": "deny" } } } ``` 旧来の`allowOutbound`・`allowedHosts`・`blockedHosts`・`network.proxy`とは併用できません。どちらか一方の記法に寄せる必要があり、混ぜた設定は拒否されます。ホスト名によるアローリストとブロックリストはWindowsでは未実装です。直接通信を塞いでループバックのプロキシだけ通す構成にしたい場合は、`runtimeConfig.networkProxy`にプロキシのエンドポイントを渡します。 ### provisionからdeprovisionまでのステートフル実行 エージェントのループのように、1つのサンドボックスへ何度もコマンドを流す用途には、状態を持つライフサイクルAPIがあります。provision・start・exec・stop・deprovisionの順に呼びます。途中で失敗してもサンドボックスを残さないよう、provisionに成功した後は`try`と`finally`で囲みます。 ``` import { provisionSandbox, startSandbox, execInSandboxAsync, stopSandbox, deprovisionSandbox, } from '@microsoft/mxc-sdk'; const { sandboxId } = await provisionSandbox('isolation_session', { network: { egress: { default: 'allow' }, ingress: { default: 'allow', hostLoopback: 'allow' }, }, }); try { await startSandbox(sandboxId); await execInSandboxAsync(sandboxId, { process: { commandLine: 'echo hello' } }); } finally { try { await stopSandbox(sandboxId); } finally { await deprovisionSandbox(sandboxId); } } ``` このAPIに対応しているのは`isolation_session`・`windows_sandbox`・`wslc`の3つで、いずれもWindows専用です。mainのSDK READMEによれば、Nodeから実際に出力を受け取れるのはIsolationSessionだけで、残る2つは`execInSandboxAsync(sandboxId, config, { dryRun: true })`によるリクエスト検証にとどまります（`options`は第3引数です）。IsolationSessionのprovisionには上記のとおり全許可の方向別ネットワーク指定が必須で、規則やプロキシ、省略はいずれも拒否されます。 失敗時は`MxcError`が投げられます。分岐に使ってよいのは閉じた列挙である`code`だけで、`operation`と`nativeCode`は診断用です。この2つはIsolationSessionのステートフル操作でしか埋まらず、値も版を上げずに変わりうるとされています。 ``` import { MxcError } from '@microsoft/mxc-sdk'; try { await startSandbox(sandboxId); } catch (err) { if (err instanceof MxcError) { if (err.code === 'stale_id') { // サンドボックスが消えているので provision からやり直す } console.error(err.message, err.remediation); } } ``` ## 既存の隔離手段との違いと詰まりやすい点 MXCはコンテナ技術の置き換えではありません。設計目的が違うため、比較するなら「何を守るための境界か」で並べたほうが判断しやすくなります。 ### コンテナ技術との設計目的の違い | 観点 | Docker等のコンテナ | MXC | | --------------- | -------------- | --------------- | | 主目的 | アプリの配布と実行環境の再現 | 実行中プロセスの権限制限 | | 起動する対象 | イメージ化した成果物 | ポリシー付きで起動するプロセス | | ポリシーの粒度 | コンテナ単位 | ファイル・ネットワーク・UI | | 隔離の実体 | 名前空間とcgroup | 9バックエンドから選択 | | Windows Sandbox | 別製品 | 1バックエンドとして内包 | Windows Sandboxは「MXCと競合する製品」ではなく、MXCが抽象化した先の選択肢の1つとして`windows_sandbox`という名前で含まれています。ただし実験扱いで、1回の呼び出しごとに使い捨てのVMが立ち上がる方式へv0.7.0で変わりました。コンテナランタイム側の設計思想の違いは[Podmanとdockerの違いは？デーモンレス・rootlessの仕組みと移行判断](/tech/details/13202/)もあわせて読むと整理しやすくなります。 ### MXCの初回実行でつまずく5つの設定ミス READMEが実際の質問をもとにまとめている注意点のうち、最初の実行で当たりやすいものを挙げます。 - UIポリシーを強制するのはWindowsのProcessContainerとmacOSのSeatbeltだけで、既定は拒否です。PowerShellは5.1も7も起動時にwin32kを呼ぶため、`ui.allowWindows: true`を入れないと起動そのものに失敗します。逆にIsolationSessionとWSLCは`ui`の指定自体を拒否し、省略しても制限はかかりません。 - `network`を書かなければ通信できません。同様に`readwritePaths`がなければ一時ディレクトリにも書けず、`ui`がなければGUIは使えません。 - `process.cwd`や作業ディレクトリ引数を指定しても、そのパスへのアクセス権は付与されません。`readonlyPaths`か`readwritePaths`に明示的に足す必要があります。 - Windowsで空白を含むパスを引用符なしで`commandLine`の先頭に置くと、解析の段階で拒否されます。 - 実験バックエンドを選んだのに`{ experimental: true }`を渡していないと、`'' containment requires experimental mode`で止まります。 なおテレメトリは既定でオフです。設定の`telemetry.enabled`・Windowsでのユーザー同意・管理ポリシーの許可という3つのゲートがすべて開いたときだけ送信され、公開ソースからビルドしたバイナリはプロバイダーグループGUIDを持たないためローカルのETWにしかイベントを出しません。 ## よくある質問 ### MXCは無料で使えますか？ リポジトリとTypeScript SDKはいずれもMITライセンスで公開されており、利用に費用はかかりません。ただし早期プレビューであり、1.0までは版をまたいでスキーマとAPIが変わりうると明記されています。 ### Windows以外でも動きますか？ 動きます。Linuxはx64とARM64で既定がBubblewrap、ほかにLXCが選べます。macOSはApple SiliconでSeatbeltが使え、スキーマ0.7.0-alpha以上が必要です（リポジトリのREADMEはx64も対応として挙げています）。ただしステートフルなライフサイクルAPIは現時点でWindows専用です。 ### ポリシーに書く版はどれを選べばよいですか？ 現行の安定バックエンドを使うなら`0.9.0-alpha`です。Windows Sandbox・MicroVM・Hyperlightを使う場合だけ`0.10.0-alpha`が必要で、macOSのSeatbeltは`0.7.0-alpha`以上であれば動きます。 ### ポリシーを書いたのに制限が効いていないのはなぜですか？ WindowsのProcessContainerでは、ホストのビルドによって選ばれる隔離ティアが変わります。25H2+でOS側の契約が有効でなければBaseContainerは使われず、AppContainer＋DACLへ落ちます。v0.8.0時点では24H2と25H2に必要なOS側の変更がまだ入っていないため、最新機能の挙動を確かめるにはInsider Preview Build 26340.9212以上で試す必要があります。 ### 信頼できない外部コードの実行をMXCだけに任せてよいですか？ 現時点では避けるべきです。READMEは`no MXC profiles should be treated as security boundaries currently`と明記しており、生成されるポリシーが過度に緩いケースが既知であるとも書かれています。多層防御の1枚として位置づけ、境界そのものは別の手段でも確保しておくのが現実的です。 ## 関連記事 - [Firecracker（マイクロVM）とは？仕組み・KVMとの関係とgVisor・コンテナとの使い分けを実装者目線で解説](/tech/details/15691/) - [Kata Containersとは？軽量VMで隔離するセキュアコンテナの仕組みとgVisor・runc比較・導入判断](/tech/details/15693/) - [GitHub Copilot CLIとは？Autopilot・Planなど動作モードと料金・インストールを解説](/tech/details/11137/) - [Microsoft Build 2026のGitHub・GitHub Copilot発表まとめ｜企業の導入判断と新機能](/tech/details/12741/) - [Node.js 26の新機能・変更点とLTSスケジュール総まとめ](/tech/details/12014/) --- 出典: [Microsoft Execution Containers（MXC）とは？9バックエンドの選び方とSDKの実装手順【2026年9月時点】]()（株式会社一創）