Microsoft developer platformのZod 4.4.3更新まとめ:MCP Serverで確認すべき影響と対応手順

2026年5月5日に公開・更新されたMicrosoft developer platform関連の更新は、MicrosoftのAgent Governance Toolkit内にあるMCP Server拡張で、zodを4.3.6から4.4.3へ更新する依存関係アップデートです。結論から言うと、通常利用者がすぐ設定を変える必要は大きくありません。一方で、agent-governance-python/agent-os/extensions/mcp-serverをソースからビルドしている、フォークしている、または独自スキーマでMCP Serverを拡張している開発者は、Zod 4.4系で強化された検証挙動を前提にテストを回すべきです。該当PRは2026年5月5日にmainへマージされ、変更ファイルはpackage.jsonの1ファイル、差分はzodのバージョンを4.3.6から4.4.3へ変更する内容です。(GitHub)

目次

Microsoft developer platformの今回の更新で変わったこと

今回のMicrosoft developer platform documentation updateは、新機能追加というよりも、Agent Governance ToolkitのMCP Server拡張で使われるJavaScript/TypeScript依存関係のメンテナンス更新です。対象は@microsoft/agentos-mcp-serverで、package.json上の本番依存関係としてzodが4.4.3に更新されています。(GitHub)

確認項目内容
対象リポジトリmicrosoft/agent-governance-toolkit
対象ディレクトリagent-governance-python/agent-os/extensions/mcp-server
対象パッケージ@microsoft/agentos-mcp-server
変更された依存関係zod
変更前4.3.6
変更後4.4.3
更新種別direct production dependencyのsemver-minor更新
変更ファイルpackage.jsonのみ
PRの状態2026年5月5日にマージ済み

Dependabotのメタデータでは、この更新はdirect:production依存関係のversion-update:semver-minorとして扱われています。また、GitHub ActionsのDependency Reviewでは、脆弱性、ライセンス問題、OpenSSF Scorecard上の問題は検出されなかったと報告されています。(GitHub)

ただし、「脆弱性対応ではなさそうだから確認不要」と考えるのは危険です。Zod 4.4系には、検証の正確性を高める修正が含まれており、これまで曖昧に通っていた入力が失敗する可能性があります。特にMCP Serverのように、外部から渡される設定値、ツール定義、リクエスト、レスポンス、JSON Schema変換などと関わる部分では、依存関係更新でも挙動確認が必要です。

Zodとは何か、なぜMCP Serverで注意が必要なのか

ZodはTypeScript-firstのスキーマ検証ライブラリです。スキーマを定義し、そのスキーマに対して入力データを検証することで、実行時のデータの形とTypeScript上の型安全性を近づけられます。Zod公式ドキュメントでは、parseによって入力を検証し、妥当な場合は型安全な値として扱えることが説明されています。(Zod)

MCP ServerでZodが重要になる理由は、MCPが「エージェントと外部ツール・リソースをつなぐ境界」に位置するためです。境界部分では、次のような値の検証が実務上の品質に直結します。

  • ツール呼び出しの引数
  • 設定ファイルや環境変数
  • YAMLやJSONから読み込むポリシー関連データ
  • MCPクライアントから渡されるリクエスト
  • 外部サービス連携時のURL、ID、トークン形式
  • JSON Schemaとして出力・共有するスキーマ

今回の更新対象である@microsoft/agentos-mcp-serverは、agentos-mcpというCLIエントリを持ち、build、test、typecheck、start:stdioなどのスクリプトを備えています。Node.jsの要件は>=18.0.0です。(GitHub)

つまり、パッケージをそのまま利用するだけの読者よりも、MCP Serverをローカルでビルドしている開発者、CI/CDに組み込んでいるチーム、独自のZodスキーマを追加しているチームが主な確認対象です。

対応が必要な人、様子見でよい人

今回の変更は1行の依存関係更新ですが、影響の有無は「MCP Serverをどの深さで使っているか」によって変わります。

利用状況対応の優先度やるべきこと
公開済みパッケージを通常利用しているだけ低今後のリリースノートを確認。問題が出た場合に備え、利用バージョンを記録する
リポジトリをcloneしてMCP Serverをビルドしている中npm install後にtypecheck、build、testを実行する
フォークして独自のMCPツールや設定スキーマを追加している高Zod 4.4系の挙動変更に合わせてスキーマとテストデータを確認する
Zodのエラー出力をスナップショットテストしている高エラーメッセージ、パス、フォーマット差分を確認する
JSON Schema変換結果を別システムで利用している高z.toJSONSchema()の出力差分を比較する
CIで依存関係やロックファイルを固定している中lockfile、キャッシュ、実際に解決されたZodバージョンを確認する

判断の目安はシンプルです。Zodで検証している入力が外部由来なら、必ずテストする。内部固定値だけなら、通常のビルド確認で十分です。

Zod 4.4系で確認すべき主な変更点

Zod 4.4.0のリリースノートでは、このマイナーリリースには正確性と型安全性に関する幅広い修正が含まれ、一部の修正はZodをより厳格にするため、以前は受け入れられていた無効または曖昧な入力に小さな修正が必要になる可能性があると説明されています。(GitHub)

MCP ServerやMicrosoft developer platform周辺の開発で特に確認したい点は、次の通りです。

z.undefined()を使った必須プロパティ

Zod 4.4.0では、z.undefined()を指定したオブジェクトプロパティは「キー自体が存在しなくてもよい」ではなく、「キーは存在し、値がundefinedでよい」と扱われます。キー自体を省略可能にしたい場合は.optional()を使う必要があります。(GitHub)

実務では、次のような設定スキーマで影響が出やすくなります。

const schema = z.object({
  optionalToken: z.undefined(),
});

このような定義を「項目がなくてもよい」という意味で使っていた場合、意図と挙動がずれる可能性があります。省略を許可したいなら、次のように見直します。

const schema = z.object({
  optionalToken: z.undefined().optional(),
});

MCP Serverの設定、ツール定義、ポリシー関連の入力で「未指定」と「明示的なundefined」を区別している場合は、ここを重点的に確認してください。

URLやBase64などの文字列バリデーション

Zod 4.4.0では、文字列バリデーションもより厳格になっています。たとえばBase64検証では空白を含む値が拒否され、HTTP URL検証ではhttps:/example.comのようにプロトコル後のスラッシュが不足したURLを受け入れないようになっています。(GitHub)

これはMCP Serverの設定で、外部APIのエンドポイント、コールバックURL、エージェントやツールのメタデータURLを扱う場合に重要です。これまでブラウザやURLコンストラクタの補正に頼っていた入力は、Zod側で失敗する可能性があります。

確認すべき例は次の通りです。

入力例確認ポイント
https:/example.comスラッシュ不足のURLが拒否されるか
http:/www.example.com不正なHTTP URLとして扱われるか
Zm 9v空白入りBase64が拒否されるか
設定ファイル内のURL手入力ミスが本番前に検出されるか

厳格化は不具合ではなく、境界入力を早めに検出するための改善です。ただし、既存のテストデータやサンプル設定が緩い形式を含んでいる場合は、テスト失敗として表面化します。

タプル、関数引数、デフォルト値

Zod 4.4.0では、タプルのデフォルト値、optional tail、明示的なundefined、要素数不足の扱いがより正確になりました。z.function()の引数はタプル形状で扱われるため、関数入力のエラー表示が変わる可能性もあります。(GitHub)

MCPツールの引数を配列やタプルで表現している場合は、次を確認してください。

  • 引数省略時にデフォルト値が期待通り入るか
  • 明示的なundefinedと未指定が区別されるか
  • エラーになったときのパスやメッセージがテスト期待値と一致するか
  • 古い挙動に依存した補正処理が残っていないか

.merge()とrefinementの組み合わせ

Zod 4.4.0では、refinementを持つオブジェクトに対して.merge()を使うと、曖昧な挙動を避けるために例外が発生するようになりました。リリースノートでは、オブジェクト合成には.extend()または.safeExtend()を使うことが推奨されています。(GitHub)

MCPツール定義の共通スキーマに対して、機能別スキーマを.merge()しているコードは注意が必要です。

const baseTool = z.object({
  name: z.string(),
}).refine((tool) => tool.name.length > 0);

const extendedTool = baseTool.merge(z.object({
  timeoutMs: z.number(),
}));

このような構成は、Zod 4.4系では見直し候補です。安全に拡張したい場合は、.safeExtend()の利用を検討します。

JSON Schema出力の差分

Zod 4.4.0では、z.toJSONSchema()によるJSON Schema変換で、$defs内の冗長なidが出力されなくなる修正が入っています。古いJSON Schema方言での参照解決を正しくするための変更ですが、$defs内のidを直接読んでいた処理には影響します。(GitHub)

MCP Serverでスキーマを外部に公開している、または別システムがJSON Schemaを読み取っている場合は、更新前後で出力を比較してください。特に次のような処理は影響を受けやすいです。

  • $defs内のidをキーとして参照している
  • JSON Schemaをドキュメント生成に使っている
  • MCPツールの入力仕様を自動生成している
  • スキーマ出力をスナップショットテストしている

エラー表示やスナップショットテスト

Zod 4.4系では、union関連のエラーパスやdiscriminated unionのエラーメッセージも改善されています。これは開発者にとっては分かりやすくなる一方、ZodErrorの出力をそのままテスト期待値にしている場合は差分になります。(GitHub)

スナップショットテストで失敗した場合は、単純に期待値を更新する前に、次を確認してください。

  • エラーの位置がより正確になっただけか
  • 以前は検出できていなかった不正入力が検出されていないか
  • UIやログに表示する文言が変わっても運用上問題ないか
  • APIレスポンスとしてエラー詳細を返している場合、クライアント互換性に影響しないか

v4.4.1からv4.4.3までの追加修正も確認する

今回の更新先は4.4.3なので、4.4.0だけでなく4.4.1、4.4.2、4.4.3の差分も含まれます。

v4.4.1では、必須デフォルトより前にあるタプルの穴を拒否する修正が含まれています。(GitHub)

v4.4.2では、z.preprocessが内側のスキーマにoptional性の判断を委ねる修正などが含まれています。(GitHub)

v4.4.3では、存在しないオブジェクトキーに対するcatch処理の復元、preprocessのabsent keysに関する修正が含まれています。(GitHub)

実務では、preprocess、catch、default、optionalを組み合わせたスキーマを重点的に見てください。これらは「入力がないときにどう扱うか」を決めるため、設定ファイルやMCPツール引数の初期値処理で差分が出やすい領域です。

移行・設定確認の手順

MCP Serverをソースから扱っている場合は、まず対象ディレクトリで依存関係とビルドを確認します。package.jsonにはbuild、test、typecheckなどのスクリプトが定義されています。(GitHub)

cd agent-governance-python/agent-os/extensions/mcp-server

npm install
npm run typecheck
npm run build
npm test

次に、実際にzodの解決バージョンを確認します。

npm ls zod

4.4.3が解決されていれば、今回の変更が反映されています。CIでキャッシュを使っている場合は、node_modulesやnpmキャッシュの影響で古い4.3.6が残っていないかも確認してください。

推奨する確認フロー

手順確認内容失敗した場合の見方
依存関係の再インストール[email protected]が入るかlockfileやキャッシュを確認
型チェックTypeScript型エラーが出ないかZodの型推論差分、.merge()周辺を確認
ビルドdist生成に失敗しないかimport、型定義、Node.jsバージョンを確認
単体テスト既存テストが通るかvalidation error、snapshot、URL/Base64を確認
代表入力テスト実運用の設定・ツール引数が通るか省略値、undefined、デフォルト値を確認
ステージング実行MCP Serverが起動し、ツール呼び出しが成功するか起動時設定と実行時入力を分けて調査

具体的に見直したいコードパターン

省略可能な値にz.undefined()だけを使っている

省略を許可したいなら.optional()を明示します。

// 見直し候補
const schema = z.object({
  token: z.undefined(),
});

// 省略可能にしたい場合
const schema = z.object({
  token: z.undefined().optional(),
});

URLを緩く受け入れている

URLは、補正されることを期待せず、入力時点で正しい形式にします。

const schema = z.object({
  endpoint: z.httpUrl(),
});

設定例では、次のような値を避けます。

endpoint: "https:/example.com"

正しくは次の形式です。

endpoint: "https://example.com"

Base64に空白や改行が混ざる

トークンや証明書関連の値をBase64として扱う場合、コピー時に空白が混ざることがあります。Zod 4.4系では、このような値がより厳格に拒否されます。

const schema = z.object({
  encodedValue: z.base64(),
});

運用上は、設定読み込み前に空白を除去するのではなく、入力元が正しいBase64を渡しているかを確認するのが安全です。勝手に補正すると、誤った値を正常値として扱ってしまう可能性があります。

.merge()でスキーマを合成している

refinement付きスキーマを.merge()している場合は、.extend()や.safeExtend()への置き換えを検討します。

const base = z.object({
  name: z.string(),
}).refine((value) => value.name.length > 0);

// 見直し候補
const merged = base.merge(z.object({
  enabled: z.boolean(),
}));

単純な追加であれば、次のように構成を分けると意図が明確になります。

const baseShape = {
  name: z.string(),
};

const schema = z.object({
  ...baseShape,
  enabled: z.boolean(),
}).refine((value) => value.name.length > 0);

セキュリティ面では何を見ればよいか

今回のDependency Reviewでは、脆弱性やライセンス問題は検出されていません。とはいえ、依存関係更新をセキュリティ観点で見る場合は、CVEの有無だけで判断しないことが重要です。(GitHub)

MCP Serverのようなエージェント連携の境界では、検証ロジックの厳格化そのものがリスク低減につながります。たとえば、壊れたURL、空白入りBase64、曖昧な未指定値を早期に拒否できれば、後段のツール実行や外部API連携で想定外の挙動を防ぎやすくなります。

確認すべき観点は次の3つです。

観点確認ポイント
入力検証外部入力がZodスキーマで拒否されるべきときに拒否されるか
ログ・監査ZodErrorの表示変更が監査ログやアラートに影響しないか
依存関係管理CIで実際に[email protected]を使っているか

特にエージェント系の実装では、「入力を後で補正する」よりも「境界で明確に拒否する」方が運用しやすい場合があります。Zod 4.4系の厳格化は、その方針と相性が良い更新です。

すぐ使える確認チェックリスト

MCP Serverを運用・開発しているチームは、次の順に確認すると効率的です。

  • agent-governance-python/agent-os/extensions/mcp-server/package.jsonでzodが4.4.3になっているか確認する
  • npm ls zodで実際の解決バージョンを確認する
  • npm run typecheckを実行する
  • npm run buildを実行する
  • npm testまたはvitestを実行する
  • URL、Base64、undefined、optional、default、preprocess、catchを使うスキーマを重点的に見る
  • JSON Schema出力を利用している場合は、更新前後の差分を比較する
  • スナップショットテストの失敗を、単なる表示差分か検証ロジックの差分かに分けて判断する
  • ステージング環境で代表的なMCPツール呼び出しを実行する
  • CIのキャッシュやlockfileが古いZodを参照していないか確認する

失敗しやすいポイント

今回のような依存関係更新でよくある失敗は、差分が小さいために影響も小さいと判断してしまうことです。実際には、1行のバージョン変更でも、検証ライブラリの場合はアプリケーションの入力境界に影響します。

特に注意したいのは次のケースです。

失敗パターン起きる問題対策
semver-minorだから無条件で安全と判断する以前通っていた曖昧な入力が失敗するリリースノート上の厳格化ポイントを確認する
スナップショットだけ更新する本当の検証ロジック変更を見落とすエラー原因と入力値を確認してから期待値を更新する
lockfileを確認しないローカルとCIでZodのバージョンがずれるnpm ls zodをCIログにも出す
設定ファイルだけ手動確認する実行時のMCPツール引数で失敗する代表的なツール呼び出しをステージングで試す
JSON Schema出力を比較しない外部連携側でスキーマ解釈が変わる更新前後のschema diffを取る

今回の更新をどう判断すべきか

今回のMicrosoft developer platform関連更新は、大規模な仕様変更ではなく、MCP Server拡張に含まれるZodの依存関係更新です。PR上の差分は小さく、Dependency Reviewでも脆弱性やライセンス問題は検出されていません。(GitHub)

ただし、Zod 4.4系は検証の正確性と厳格さに関わる修正を含みます。MCP Serverはエージェントと外部ツールをつなぐ境界に位置するため、外部入力を扱うスキーマがある場合は、依存関係更新を単なるメンテナンスとして流さず、入力検証の再確認タイミングとして扱うのが現実的です。

次に取るべき行動は明確です。@microsoft/agentos-mcp-serverをソースからビルドしている場合は、対象ディレクトリで依存関係を更新し、型チェック、ビルド、テスト、代表的なMCPツール呼び出しを実行してください。独自スキーマを追加している場合は、undefined、URL、Base64、タプル、.merge()、JSON Schema出力、エラー表示の差分を重点的に確認しましょう。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次