Microsoft developer platformのESLint 10.3.0更新まとめ｜MCP Server開発者が確認すべき影響と対応

2026年5月5日にMicrosoft developer platform関連で反映されたこの更新は、Agent Governance Toolkit内のMCP Server拡張で使われる開発用依存関係 eslint を10.2.1から10.3.0へ上げる変更です。アプリ本体のAPI仕様やMCP Serverの利用手順が大きく変わる更新ではなく、主な確認対象は「TypeScriptコードのlint結果」「CIの通過状況」「ESLintルールの提案表示」です。対象ディレクトリで開発・保守しているチームは、npm install後に npm run lint、npm run typecheck、npm test を実行し、警告や自動修正候補の変化を確認するのが実務上の対応になります。(GitHub)

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

今回のMicrosoft developer platform documentation updateとして扱われている変更の実体は、GitHub上のMicrosoft agent-governance-toolkit リポジトリに作成されたDependabot PRです。PR名は build(deps-dev): Bump eslint from 10.2.1 to 10.3.0 in /agent-governance-python/agent-os/extensions/mcp-server で、2026年5月5日に main ブランチへマージされています。(GitHub)

変更ファイルは agent-governance-python/agent-os/extensions/mcp-server/package.json の1ファイルのみです。差分は devDependencies 内の eslint が 10.2.1 から 10.3.0 に更新された1行で、GitHub上の差分表示でも「1 addition / 1 deletion」として確認できます。(GitHub)

"eslint": "10.2.1"

から、以下へ変更されています。

"eslint": "10.3.0"

重要なのは、この更新が実行時依存関係ではなく開発用依存関係の更新である点です。PR内でも dependency-type: direct:development、update-type: version-update:semver-minor と示されており、ユーザーがMCP Serverを実行する機能そのものより、開発・検証・CIで使うlint環境に影響する更新と見るのが適切です。(GitHub)

対応すべき人と、急がなくてよい人

今回の更新は小規模ですが、Microsoft developer platform上でAgent Governance ToolkitやMCP Server拡張を扱う開発者にとっては無視しない方がよい変更です。特に、CIでESLintを必須チェックにしているチームでは、バージョン差によって警告や提案表示が変わる可能性があります。

対象者	対応の必要性	確認すべきこと
`agent-os/extensions/mcp-server` を直接開発している人	高い	`npm run lint` の結果、ESLint設定、CIのlintステップ
Microsoft Agent Governance Toolkitをforkしているチーム	高い	fork側の `package.json` とlockfileの差分、Dependabot設定
MCP Serverを利用するだけのエンドユーザー	低い	通常は即時対応不要。利用手順や起動設定の変更有無だけ確認
CI/CD管理者	中〜高	Node.js、npm、キャッシュ、lockfile更新後の再現性
セキュリティ・ライセンス確認担当	中	Dependency Review結果、ライセンス・脆弱性アラートの有無

今回のPRでは、Dependency Reviewにおいて eslint 10.3.0について「脆弱性、ライセンス問題、OpenSSF Scorecard上の問題は見つからなかった」と表示されています。ただし、これは当該PR時点の確認結果であり、自社環境では別の依存関係やlockfileの状態によって結果が変わる可能性があります。(GitHub)

影響範囲はMCP Server拡張のlint環境

対象パスは /agent-governance-python/agent-os/extensions/mcp-server です。このディレクトリは、AgentOS MCP Serverのnpmパッケージに関係する領域で、READMEではClaude Desktop、GitHub Copilot、CursorなどのMCP互換AIアシスタントからAgent OSの安全性フレームワークを利用できるMCP Serverとして説明されています。(GitHub)

現行の package.json では、対象パッケージは @microsoft/agentos-mcp-server とされ、lint スクリプトは eslint src --ext .ts、typecheck は tsc --noEmit、テストは vitest を使う構成になっています。つまり、今回のESLint更新は主にTypeScriptソースの静的解析に関係します。(GitHub)

項目	内容
対象ディレクトリ	`agent-governance-python/agent-os/extensions/mcp-server`
変更対象	`package.json` の `devDependencies.eslint`
変更前	`eslint` 10.2.1
変更後	`eslint` 10.3.0
影響しやすい処理	`npm run lint`、CIのlintチェック、エディタ上のESLint警告
影響しにくい処理	MCP Serverの通常起動、既存APIの呼び出し、エージェント作成フロー

実務では「MCP Serverの利用者全員が設定を変える必要がある」というより、このディレクトリのコードを編集・検証・ビルドする人がlint結果を確認する更新と捉えると判断しやすくなります。

ESLint 10.3.0の主な変更点

ESLint 10.3.0のリリースノートでは、主な新機能として no-unused-private-class-members ルールに対する提案機能の追加が挙げられています。また、不具合修正として、利用できないrequire cacheの扱いに関する修正と、class body内でルール提案が意図せず継続する問題の修正が含まれています。(GitHub)

分類	ESLint 10.3.0での変更	開発現場で見るべきポイント
機能追加	`no-unused-private-class-members` にsuggestions追加	エディタやCIログで未使用privateメンバーの修正候補が出る可能性
不具合修正	unavailable require cacheの取り扱い修正	特殊なNode.js実行環境、テスト環境、バンドル環境でのlint挙動
不具合修正	class body内でrule suggestionsが継続する問題の修正	クラス構文を多用するTypeScriptコードでの提案表示
ドキュメント	README更新、typo修正	開発者向け説明の改善
CI・雑務	ESLint本体側のCIや依存関係更新	利用側では通常、直接対応不要

no-unused-private-class-members は、クラス内で宣言されたprivateフィールドやprivateメソッドが使われていない場合に報告するルールです。ESLint公式ドキュメントでは、未使用のprivate class memberは不完全なリファクタリングに起因するエラーである可能性が高く、コードの理解を妨げる要因になり得ると説明されています。(ESLint)

たとえば、次のようなコードでは #cache がどこからも読まれていないため、lint対象になる可能性があります。

class AgentConfig {
  #cache = new Map<string, string>();

  getName() {
    return "agent";
  }
}

これまで単に警告として表示されていた箇所に、ESLint 10.3.0ではエディタ上の修正提案が加わる可能性があります。実務では、提案された削除を機械的に適用するのではなく、「将来使う予定で残しているのか」「リファクタリング漏れなのか」「テスト不足で未使用に見えているだけなのか」を確認してから反映することが重要です。

今回の更新で壊れやすいポイント

SemVer上はminor updateですが、lintツールの更新では「アプリは動くがCIだけ落ちる」「エディタの警告が増える」といった問題が起きることがあります。特にMicrosoft developer platform関連のリポジトリをforkして運用している場合、依存関係の更新を取り込んだ後に以下を確認してください。

lockfileの更新漏れ

package.json だけを取り込んで、package-lock.json や利用しているlockfileを更新しないと、ローカルとCIでESLintの解決バージョンがずれる可能性があります。

確認の基本は次の流れです。

cd agent-governance-python/agent-os/extensions/mcp-server
npm install
npm run lint
npm run typecheck
npm test

CIでnpmキャッシュを使っている場合は、古いESLintが残っていないかも確認します。特にDependabot PRをsquash mergeしている環境では、lockfileとpackage managerの挙動を見落としやすいです。

エディタ拡張とCLIのESLint差分

VS CodeなどのエディタでESLint拡張を使っている場合、ワークスペース内のESLintを参照する設定か、グローバルにインストールされたESLintを参照する設定かで表示結果が変わります。

実務では、次のようにCLIで実行した結果を基準にするのが安全です。

npm run lint

エディタでは警告が出ないのにCIで落ちる場合、ESLint拡張の参照先、ワークスペース設定、Node.jsバージョン、package managerの解決結果を確認してください。

自動修正候補の過信

今回のESLint 10.3.0では、未使用private class memberに関する提案機能が追加されています。提案は便利ですが、privateメンバーの削除は設計意図に関わることがあります。特にMCP Serverのようにテンプレート、ポリシー、監査ログ、承認フローなど複数の機能が絡むコードでは、未使用に見えるメンバーが将来の拡張や型定義のために残されている場合もあります。

削除する前に、少なくとも以下を確認します。

確認項目	判断基準
本当に未使用か	grepやIDE検索で参照箇所を確認する
テストで検出できるか	削除後に `npm test` と `npm run typecheck` を実行する
公開APIに関係するか	型定義、テンプレート、外部から参照される設定名を確認する
将来用途のコメントがあるか	TODOや設計メモがある場合は担当者に確認する

移行・設定確認の実務手順

今回の更新を取り込む場合は、単にバージョン番号を合わせるだけでなく、lint、型チェック、テスト、CIの4点を順番に確認すると失敗を減らせます。

| 手順 | コマンド・確認内容 | 目的 |
| -: | ———————————————————– | ————————- |
| 1 | git pull またはfork側へPRを取り込み | Microsoft側の更新差分を反映する |
| 2 | cd agent-governance-python/agent-os/extensions/mcp-server | 対象ディレクトリへ移動する |
| 3 | npm install | eslint 10.3.0を解決し直す |
| 4 | npm run lint | ESLint更新による警告・エラーの変化を確認する |
| 5 | npm run typecheck | TypeScriptの型エラーがないか確認する |
| 6 | npm test | lint修正が動作に影響していないか確認する |
| 7 | CIを再実行 | ローカルとCIの差分を確認する |

現行の package.json ではNode.jsエンジンが >=18.0.0 とされています。ESLintやTypeScript周辺の挙動はNode.jsのバージョン差の影響を受けることがあるため、ローカルとCIでNode.jsのメジャーバージョンが大きく異なる場合は、先に実行環境をそろえてから検証する方が効率的です。(GitHub)

CIで確認すべきポイント

GitHub ActionsやAzure PipelinesなどでMCP Server拡張を検証している場合、今回のような開発用依存関係の更新はCIの安定性に直結します。特にlintを必須チェックにしている場合は、以下を確認してください。

チェック項目	よくある失敗	対応
npmキャッシュ	古い依存関係が残る	lockfileのハッシュでキャッシュキーを作る
Node.jsバージョン	ローカルでは通るがCIで落ちる	`.nvmrc` やCI設定でバージョンを固定する
lint対象	`src --ext .ts` の対象外ファイルを見落とす	生成物やテンプレートの扱いを確認する
自動修正	`--fix` 後に型エラーが出る	lint後にtypecheckとtestを必ず実行する
fork運用	upstreamとの差分が大きい	依存関係PRだけを単独で取り込み、影響を切り分ける

今回のPRは小規模ですが、Microsoft側のRepositoryでは対象パッケージにTypeScript、Vitest、@typescript-eslint 系パッケージも含まれています。ESLintだけでなく、parserやpluginとの組み合わせでlint結果が変わる可能性があるため、警告の増減を「ESLint単体の問題」と決めつけず、設定全体を見ることが大切です。(GitHub)

Microsoft Agent Governance Toolkit利用者が見るべき文脈

Agent Governance Toolkitは、AIエージェントのアクションに対するポリシー評価、ゼロトラストID、監査ログ、実行制御などを扱うMicrosoftの公開リポジトリです。READMEでは、Python、TypeScript、.NET、Rust、Goなど複数言語で利用できることや、AIエージェントの実行前にポリシーチェックを行う構成が説明されています。(GitHub)

その中でMCP Server拡張は、MCP互換のAIアシスタントからAgent OSの機能を利用する入口になります。READMEでは、Claude Desktopの設定例として npx でMCP Serverを起動し、AGENTOS_POLICY_MODE を指定する例も示されています。(GitHub)

今回のESLint更新は、こうしたMCP Serverの利用フローそのものを変更するものではありません。ただし、MCP Serverのコードを拡張したり、独自ポリシーやテンプレートを追加したりする開発者にとっては、lint品質を保つための基盤更新です。

本番環境への影響は限定的だが、開発フローでは確認が必要

今回の変更は devDependencies に分類されるため、通常の本番実行時に直接読み込まれる依存関係ではありません。したがって、MCP Serverを単に利用しているだけであれば、設定ファイルや起動コマンドを急いで変更する必要は基本的にありません。

一方で、次のようなチームは確認を省略しない方がよいです。

MCP Server拡張をforkして独自機能を追加している
CIで npm run lint を必須チェックにしている
ESLintのwarningをゼロにする運用をしている
private class memberを使ったTypeScriptコードが多い
Dependabot更新を自動マージしている

特に自動マージ運用では、「開発用依存関係だから安全」と見なしてしまいがちです。lintツールの更新は、コードの実行結果を変えなくても、PRの通過条件や開発者の作業体験を変えることがあります。

確認時に見るべきログの例

npm run lint を実行した後、次のような観点でログを確認します。

npm run lint

見るべきポイントは、単に「エラーがあるか」だけではありません。

ログの種類	見方
新しいerror	既存コードがESLint 10.3.0で新たに検出された可能性がある
新しいwarning	CI設定によっては失敗扱いになるため放置しない
suggestion表示	エディタ上の修正候補が増えた可能性がある
parser関連エラー	`@typescript-eslint/parser` との組み合わせを確認する
Node.js関連エラー	CIとローカルのNode.jsバージョン差を確認する

もし no-unused-private-class-members に関連する指摘が出た場合は、削除してよい未使用コードなのか、設計上残しているメンバーなのかを切り分けます。ESLint公式ドキュメントでは、このルールは未使用のprivateフィールド、メソッド、アクセサを報告するものと説明されています。(ESLint)

取り込むべきか迷った場合の判断基準

今回の更新は、原則として取り込む方向で検討してよい変更です。理由は、実行時機能の変更ではなく開発用ツールのminor updateであり、ESLint側の不具合修正も含まれているためです。ただし、以下の条件に当てはまる場合は、取り込み前に検証ブランチを作ることをおすすめします。

状況	判断
upstreamのMicrosoftリポジトリに近い構成で使っている	取り込みやすい。lintとtestを確認すれば十分なことが多い
fork後にESLint設定を大きく変更している	先に検証ブランチでlint差分を確認する
CIでwarningも失敗扱いにしている	warning増加の有無を確認してからマージする
private class memberを多用している	`no-unused-private-class-members` の指摘を重点確認する
本番直前のリリースブランチである	急ぎでなければ通常開発ブランチで先に検証する

依存関係更新は、セキュリティ対応だけでなく、開発環境の再現性を保つためにも重要です。小さな更新ほど後回しにされがちですが、複数の小さな差分を長期間ためると、後からまとめて更新したときに原因の切り分けが難しくなります。

よくある疑問

Microsoft developer platformの利用者全員に影響しますか？

いいえ。今回の変更はMCP Server拡張の開発用依存関係であるESLintの更新です。MCP Serverを使うだけの利用者より、対象ディレクトリのコードを編集・ビルド・テストする開発者に影響しやすい変更です。(GitHub)

MCP Serverの設定ファイルを変更する必要はありますか？

通常は不要です。READMEに掲載されているClaude Desktop向けのMCP Server設定例や、npx で起動する利用イメージ自体が今回のPRで変更されたわけではありません。(GitHub)

ESLint 10.3.0でコードが自動的に書き換わりますか？

通常のlint実行だけで勝手に書き換わるわけではありません。ただし、エディタ上のsuggestionや --fix を使う運用では、未使用private class memberに関する修正候補を適用できる場面が増える可能性があります。(GitHub)

Dependabot PRならそのままマージしてよいですか？

小規模な開発用依存関係更新でも、lint結果とCI結果の確認は必要です。今回のPRではDependency Review上、脆弱性やライセンス問題は見つからなかったと表示されていますが、自社のforkや追加依存関係では結果が異なる場合があります。(GitHub)

まず実行すべき対応

今回のMicrosoft developer platform documentation updateは、MCP Server拡張のESLintを10.2.1から10.3.0へ更新する小さな依存関係変更です。実行時機能への影響は限定的ですが、lintやCIの結果には影響する可能性があります。

対象コードを保守している場合は、次の順で確認してください。

cd agent-governance-python/agent-os/extensions/mcp-server
npm install
npm run lint
npm run typecheck
npm test

そのうえで、CIの結果、lockfile、ESLint設定、no-unused-private-class-members の指摘を確認します。問題がなければ、通常の依存関係更新として取り込んでよいでしょう。警告や提案が増えた場合は、機械的に削除するのではなく、設計意図とテスト結果を見て判断することが、今回の更新で最も大切な実務ポイントです。

この記事を書いた人

佐藤健司

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