【要約】WinRM × MCP サーバーを Clean Architecture で作った話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が、Windows ServerのメトリクスをAIに提供する仕組みを構築する際、以下の技術的課題に直面した。
- ・WinRMやMCP SDKといった外部依存が強く、実際の環境なしではロジック検証が困難である。
- ・エラー発生時に、パスワードやホスト名などの機密情報がトレースバックに混入するリスクがある。
- ・機密情報が混入したままエラーが外部へ漏洩する危険性も考慮しなければならない。
- ・サーバー側で健康状態の判断まで行うと、AIクライアントとの責務分離が曖昧になる。
// Approach
開発者は、保守性と安全性を確保するため、Clean Architecture Liteと厳格なセキュリティ実装を採用した。
- ・4層構造（domain, ports, application, infrastructure, mcp）により、外部依存を分離した。
- ・WinRMをProtocolとして定義し、テスト時はFakeに差し替え可能にすることで検証性を高めた。
- ・HTTPSの強制や、insecure設定の明示的opt-in、コマンドのホワイトリスト化を実施した。
- ・エラー発生時には、
from Noneを用いて機密情報を含む例外チェーンを遮断した。 - ・サーバーはrawデータのみを返し、診断はAIに任せるという明確な責務分離を行った。
// Result
この設計により、開発者はテスト容易性と安全性を両立したMCPサーバーを構築できた。
- ・WinRMの実装なしで、application層のロジックを効率的に検証可能になった。
- ・
from Noneによる例外チェーンの切断により、認証情報の漏洩リスクを低減した。 - ・AIエージェントが利用しやすい、シンプルで予測可能なデータ提供を実現した。
- ・設計の柔軟性が高く、今後はディスク使用量やネットワーク統計などの追加も容易である。
- ・これにより、AIによるインフラ監視の自動化に向けた強固な基盤が整った。
Senior Engineer Insight
> 実戦的な設計である。特に「サーバーはraw値を返し、判断はAIに任せる」という責務分離は、AIエージェント時代の設計として合理的だ。また、
from Noneによる例外制御や、insecure設定の明示的opt-inなど、防御的設計が徹底されている。Clean ArchitectureをLite化する判断も、開発速度と品質のバランスを考慮した現実的な解である。