2026年5月5日にMicrosoftのpp-mcpリポジトリで、/samples/events-http-typescriptのuuid依存関係を11.1.0から14.0.0へ上げる更新がマージされました。結論から言うと、単にドキュメントやサンプルを読むだけなら緊急対応は不要です。一方で、このTypeScriptサンプルをローカル実行している人、社内プロジェクトへコピーしている人、Node.js 18以前やCommonJS前提の環境で使っている人は、Node.js・TypeScript・モジュール形式・ロックファイルを必ず確認する必要があります。(GitHub)
今回のMicrosoft developer platform documentation updateは、見た目には小さな依存関係更新です。しかしuuid v14.0.0には破壊的変更が含まれており、特に「Node.js 18を使っている」「require('uuid')で読み込んでいる」「古いTypeScriptでビルドしている」環境では、サンプルをそのまま取り込むとビルドや起動でつまずく可能性があります。
変更の概要：uuidを11.1.0から14.0.0へ更新
今回のPull Requestは、Microsoftのpp-mcpリポジトリ内にあるevents-http-typescriptサンプルを対象に、uuidを^11.1.0から^14.0.0へ更新するものです。対象ファイルはpackage.jsonとpackage-lock.jsonで、GitHub上では2026年5月5日にmainブランチへマージされています。(GitHub)
| 確認項目 | 内容 | 実務上の意味 |
|---|---|---|
| 対象リポジトリ | microsoft/pp-mcp | Power Platform MCP Labs & Samplesのサンプルコード |
| 対象ディレクトリ | /samples/events-http-typescript | HTTPベースのTypeScriptサンプル |
| 更新対象 | uuid | イベント、セッション、スピーカー、スポンサーなどのID生成に関係 |
| 変更前 | ^11.1.0 | Node.js 18を含む旧環境でも使われやすい世代 |
| 変更後 | ^14.0.0 | Node.js 20以上、グローバルcrypto前提 |
| 変更ファイル | package.json、package-lock.json | 依存関係と解決済みバージョンの更新 |
pp-mcpはPower Platformで動作するMCP Labs & Samplesを含むリポジトリです。今回の更新はMicrosoft developer platform全体の仕様変更というより、Power Platform MCP関連サンプルの依存関係更新として見るのが正確です。(GitHub)
今回の更新で確認すべきポイント
uuid v14.0.0のリリースでは、Node.js 18サポートの終了、グローバルcrypto前提への変更、最低TypeScriptバージョンの引き上げが明記されています。また、v3()、v5()、v6()で呼び出し側が渡したバッファに対する境界チェックが不足していた問題への修正も含まれます。(GitHub)
Node.js 18以前ではそのまま使わない
もっとも重要なのは、uuid v14.0.0がNode.js 18サポートを落としている点です。リリースノートではNode.js 20以上が必要とされています。(GitHub)
ただし、2026年5月時点ではNode.js 20も公式のリリース一覧でEOL扱いになっており、LTSとして掲載されているのはNode.js 24とNode.js 22です。運用環境で新たに合わせるなら、「最低Node.js 20」ではなく、サポート中のLTSであるNode.js 22または24を候補にして検証するのが現実的です。(Node.js)
確認コマンドは次のとおりです。
node -v
node -e "console.log('global crypto:', typeof globalThis.crypto)"期待する状態は、Node.jsのメジャーバージョンが要件を満たし、globalThis.cryptoがobjectとして参照できることです。Node.js公式ドキュメントでも、Web Crypto APIはglobalThis.cryptoまたはrequire('node:crypto').webcryptoから利用できると説明されています。(Node.js)
CommonJS前提のコードは読み込み方式を確認する
uuidはv12以降、CommonJSをサポートしない方針になっています。公式READMEでも、uuid@12からCommonJSはサポートされない旨が案内されています。(GitHub)
MicrosoftのサンプルではeventInfrastructureService.ts内で次のようにES Modules形式のimportが使われています。
import { v4 as uuidv4 } from "uuid";この書き方自体は現在のuuidの利用方法に沿っています。一方で、社内プロジェクトへサンプルを移植した際に、次のようなCommonJS形式へ書き換えている場合は注意が必要です。
const { v4: uuidv4 } = require("uuid");ビルドは通っても、実行時のNode.jsバージョンや解決条件によって読み込みエラーになることがあります。uuidを14系へ上げる場合は、依存関係だけでなく、実際にnpm run buildと起動コマンドまで実行して確認してください。
TypeScriptは5.4.3以上を前提にする
uuid v14.0.0のCHANGELOGでは、最低対応TypeScriptバージョンが5.4.3へ引き上げられています。Microsoftのevents-http-typescriptサンプルではtypescriptが^5.8.3として定義されているため、このサンプル単体では条件を満たしています。(GitHub)
ただし、サンプルをコピーして古い社内テンプレートに組み込んだ場合は別です。特に次のような環境では、依存更新後に型解決やモジュール解決で失敗しやすくなります。
| 環境 | 起きやすい問題 | 対応 |
|---|---|---|
| TypeScript 5.3以前 | 型定義やモジュール解決でエラー | TypeScriptを5.4.3以上へ更新 |
古いts-node設定 | 実行時にESM/CJSの差異が出る | tsconfig.jsonと起動方法を確認 |
skipLibCheckに依存 | 型の不整合を見落とす | CIで一度skipLibCheck: falseも検討 |
| 古いロックファイル | 手元とCIで解決結果が変わる | package-lock.jsonを更新してコミット |
影響を受ける人、受けにくい人
今回の更新はMicrosoft developer platformの利用者全員に即時対応を求めるものではありません。影響は、/samples/events-http-typescriptをどの程度実行・流用しているかで変わります。
| 利用状況 | 対応の必要性 | 判断基準 |
|---|---|---|
| サンプルを読むだけ | 低 | 依存関係を実行環境へ取り込んでいない |
| 最新サンプルをローカル実行する | 中 | Node.jsとTypeScriptのバージョン確認が必要 |
| サンプルを社内MCPサーバーの土台にしている | 高 | 依存更新、ビルド、起動、API動作確認が必要 |
| Node.js 18以前で運用している | 高 | uuid v14をそのまま適用しない |
require('uuid')を使っている | 高 | ESM importへの移行、または代替方針の検討が必要 |
uuidのv3、v5、v6でバッファを渡している | 高 | セキュリティ修正の影響範囲を確認 |
今回のサンプルコードでは、uuidv4()がCosmos DBへ保存するイベント、セッション、スピーカー、スポンサーなどのID生成に使われています。具体的には、CSVからイベントやセッションを取り込む処理で、新しいエンティティIDを生成する用途です。(GitHub)
セキュリティ面で見るべきこと
uuid v14.0.0には、GHSA-w5hq-g745-h8pqへの修正が含まれています。この問題は、v3()、v5()、v6()で外部から渡されたバッファとオフセットに対する境界チェックが不足し、条件によって不完全な書き込みが起きる可能性があるという内容です。GitHub Advisoryでは重要度はModerate、CVE IDはCVE-2026-41907として示されています。(GitHub)
Microsoftのevents-http-typescriptサンプルでは主にv4()を使っているため、この脆弱性の説明にあるv3()、v5()、v6()のバッファ利用パターンに直接該当するとは限りません。ただし、依存関係を更新することで、同じパッケージを別用途で使う可能性がある派生コードや将来の変更に対して安全側へ寄せられます。
確認すべきなのは、次の3点です。
npm ls uuid
npm audit
npm run builduuidの旧バージョンを残したままにしている別パッケージがないか、ロックファイル上でどのバージョンが解決されているか、CIで同じ結果になるかを確認してください。
移行前に確認するチェックリスト
依存関係のメジャーアップデートでは、package.jsonだけを見て判断すると失敗します。今回のuuid 14.0.0対応では、次の順序で確認すると安全です。
| 確認項目 | コマンド・見る場所 | 合格ライン |
|---|---|---|
| Node.jsバージョン | node -v | サポート中のLTSを推奨 |
| グローバルcrypto | node -e "console.log(typeof globalThis.crypto)" | object |
| uuid解決バージョン | npm ls uuid | 期待した14系、または意図したパッチ済み版 |
| TypeScript | npx tsc -v | 5.4.3以上 |
| ビルド | npm run build | エラーなし |
| 実行 | npm startまたはサンプルの起動スクリプト | 起動エラーなし |
| CSV取り込み | npm run start:importEvents -- <csv> | ID生成とDB保存が成功 |
| モジュール形式 | package.json、tsconfig.json | ESM/CJSの不整合がない |
| ロックファイル | package-lock.json | 更新済みでCIに反映 |
特にDocker、GitHub Actions、Azure App Service、Azure Functions、社内CIなどでNode.jsバージョンを固定している場合、ローカルだけ成功して本番ビルドで失敗することがあります。node:18系のDockerイメージや古いホストランタイムを使っていないかも確認してください。
Microsoftのサンプルを最新版へ更新する手順
pp-mcpのサンプルをそのまま使っている場合は、まずリポジトリを最新化し、依存関係をロックファイルどおりに入れ直します。
git pull
cd samples/events-http-typescript
npm ci
node -v
npm ls uuid
npm run buildnpm installではなくnpm ciを使うと、package-lock.jsonに記録された依存関係を再現しやすくなります。チーム開発では、依存更新後のpackage-lock.jsonを必ずコミットし、CIでも同じロックファイルを使うのが基本です。
環境変数が必要な処理を確認する場合は、サンプルの.envや実行環境にCosmos DB関連の設定を入れてから起動します。app.tsではCOSMOS_DB_CONNECTION_STRINGとCOSMOS_DB_DATABASE_IDを参照しています。(GitHub)
npm start起動後は、MCPエンドポイントだけでなく、サンプル内に用意されているRESTエンドポイントも確認すると、ID生成とデータ取得の問題を切り分けやすくなります。
curl http://localhost:3000/events
curl http://localhost:3000/sessions
curl http://localhost:3000/speakers
curl http://localhost:3000/sponsors社内プロジェクトへ取り込む場合の判断基準
サンプルではなく、自社のMCPサーバーやTypeScriptアプリへ同じ更新を適用する場合は、単純に次のコマンドを実行するだけでは不十分です。
npm install uuid@^14.0.0まず、現在の実行基盤がuuid 14系の前提を満たしているか確認してください。満たしていない場合は、依存関係だけ先に上げるのではなく、Node.jsアップグレード、TypeScript更新、モジュール形式の見直しを同じ移行タスクとして扱うべきです。
Node.js 18固定なら、先にランタイム移行を計画する
Node.js 18以前で動いているプロジェクトでは、uuid 14.0.0をそのまま入れるのは避けてください。uuidのセキュリティアドバイザリでは、11.1.1、12.0.1、13.0.1もパッチ済みバージョンとして示されています。短期対応としてどの系列に上げるかは、Node.jsバージョン、CommonJS利用状況、セキュリティ要件を踏まえて判断します。(GitHub)
長期的には、Node.jsのEOLリスクを避けるため、サポート中のLTSへ移行するのが望ましい対応です。Node.js公式は、EOLになったバージョンではセキュリティパッチが提供されず、エコシステムの乖離やコンプライアンス上の問題につながると説明しています。(Node.js)
@types/uuidは必要性を見直す
Microsoftのサンプルのpackage.jsonには@types/uuidも含まれていますが、uuid本体は型定義を提供しています。uuid v14.0.0のpackage.jsonにもtypesフィールドが定義されています。(GitHub)
そのため、自社プロジェクトでは@types/uuidが本当に必要か確認しましょう。不要な型定義パッケージが残っていると、将来的に型の不一致や混乱を招くことがあります。
npm ls @types/uuid削除する場合は、必ずビルドが通ることを確認してからにします。
npm uninstall @types/uuid
npm run build失敗しやすいポイント
サンプル更新を本番適用の許可と誤解する
今回の更新は、Microsoftのサンプル内の依存関係更新です。自社の本番環境で同じ更新が安全に適用できるとは限りません。特にNode.js、TypeScript、モジュール形式はプロジェクトごとに差が大きいため、サンプルのpackage.jsonだけを根拠に本番へ反映しないでください。
ローカルだけNode.jsが新しい
開発者のPCではNode.js 22や24を使っていても、CIやコンテナがNode.js 18のままというケースはよくあります。この場合、ローカルでは成功し、CIで失敗します。次のファイルを確認してください。
Dockerfile
.github/workflows/*.yml
azure.yaml
package.json
.nvmrc
.tool-versionsビルドだけで実行確認を終える
uuidのような依存関係は、型チェックでは問題が見えず、実行時のモジュール読み込みで失敗することがあります。npm run buildに加えて、実際にnpm startやCSVインポート処理まで動かしてください。
npm run build
npm start
npm run start:importEvents -- <events-csv-path>
npm run start:importSessions -- <sessions-csv-path> <event-id>^14.0.0の意味を見落とす
^14.0.0は、将来の14系マイナー・パッチ更新を許容します。サンプルでは自然な指定ですが、本番環境で厳密に再現性を求める場合は、package-lock.jsonを必ず使い、CIではnpm ciを採用してください。依存関係の解決結果をチーム全体で揃えることが重要です。
対応方針のまとめ
今回のMicrosoft developer platform documentation updateで見るべきポイントは、uuidのバージョン番号そのものではなく、その更新が要求する実行環境の変化です。
まず、/samples/events-http-typescriptを使っている場合は、最新版を取得してnpm ci、npm run build、起動確認を行います。次に、Node.jsがサポート中のLTSか、TypeScriptが5.4.3以上か、require('uuid')のようなCommonJS前提のコードが残っていないかを確認してください。
自社プロジェクトへ取り込む場合は、依存更新だけを小さな作業として扱わず、Node.js移行、ESM対応、型定義の整理、ロックファイル更新、CI確認までを1つの変更セットとして進めるのが安全です。特にNode.js 18以前で運用している環境では、uuid 14系を急いで入れるより、まずランタイム移行計画を立てることが次の行動になります。
コメント