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出力、エラー表示の差分を重点的に確認しましょう。

コメント