WinKit

AIエージェント向けのローカルWindows可観測性と診断ツールで、Model Context Protocol (MCP) を通じて公開されています。

WinKitはデフォルトで読み取り専用、ローカルファーストのMCPサーバーであり、コーディングエージェントに、実行中のWindowsマシンの構造化された権限付きビュー（プロセス、ネットワーク、ストレージ、サービス、イベントログ、ウィンドウ、そして最初の深いアプリケーションアダプターを通じたライブChromeタブ検査と、ローカルWebアプリ診断のための隔離されたWinKit所有の管理ブラウザ）を提供します。ツールの背後には、測定されたものと解釈されたものを分離する決定論的診断エンジンがあり、エージェントは推測せずに実際の質問に答えることができます。テレメトリなし、クラウドなし。唯一のアウトバウンド面は、ゲート付きで権限チェックされた管理ブラウザの起動です。

v1はデフォルトで読み取り専用です。 すべての検査ツールは証拠を返し、システムを変更することはできません。WinKitが実行できる唯一のアクション（独自の隔離された管理Chromeセッションの起動または終了）は、[chrome.managed] enabled = true が設定されている場合にのみ有効になり、safe/read_only モードでは決して付与されない別個の application.browser.* 権限によってゲートされ、WinKit自身が作成したリソースのみに影響します。

WinKitが答えること

WinKitは3つの質問を中心に構築されており、それぞれがツールによって回答されます：

これらを合わせると、1分以内に全体像がわかります：まずマシン、次に最も重いタブ、そしてそれが悪化しているかどうか。

Related MCP server: windows-admin-mcp

ハイライト

• 69のMCPツールがシステム、プロセス、ネットワーク、ストレージ、ハードウェア、電源、サービス、イベント、ウィンドウ、開発環境、アプリケーション、Chrome、管理ブラウザ、マシン健全性の各ドメインにわたり、ツールプロファイル（core、developer [デフォルト]、browser、full）に整理されているため、エージェントは必要なものだけを表示できます。

• 開発者ワークフローツール — diagnose_workspace、diagnose_local_webapp、list_dev_servers、境界付きwait_for_*ツール、correlate_recent_failures、system_health_trendは、生の測定値を公開する代わりに、完全な問題（古いポート、間違ったポート、HTTP 500、空白ページ）を解決します。

• 証拠優先の診断 — すべての高レベルレポートは、ランク付けされた所見、安定した所見/証拠ID、および時間的近接性から因果関係を決して主張しないconfirmed/observed/likely/possible/unknownの信頼度言語を備えた安定したエンベロープです。純粋なしきい値ロジック：LLMなし、ランダム性なし、捏造された主張なし。

• 正直な完全性 — system_diagnoseは、測定できなかった次元がある場合にevidence_completeness: "full" | "limited"を報告し、失敗した次元は健全なセットから除外されます。WinKitは見えなかったものを教えてくれます。

• CDP経由のChrome深層検査 — タブ、パフォーマンス、メモリ、ネットワーク、ランタイムコンソール、結合診断レポート、サンプリングトレンド。ヘッダー、クッキー、リクエストボディは決してキャプチャされません。

• 隔離された管理ブラウザ — chrome_start_managed_sessionは、使い捨てプロファイルとループバックのみのDevToolsエンドポイントを持つWinKit所有のChromeを起動し、ページを検査し（chrome_get_page_summary、chrome_capture_screenshot）、chrome_stop_managed_sessionで閉じてプロファイルを削除します。Windows x64のみ。Chromeはダウンロードされません。デフォルトでヘッド付き：実際の可視Chromeウィンドウが開きます（--headlessフラグなし、ヘッドレス専用GPU回避策なし、ウィンドウサイズ1280x900）。デフォルトのヘッド付き起動が起動中にクラッシュした場合（GPUプロセス障害）、検証済みのヘッド付きソフトウェアレンダリングフォールバック（headed-software）が同じ可視ウィンドウを開きます — 非表示やヘッドレスになることはありません。ヘッドレスはオプトイン（headless: true）であり、設計上ウィンドウを開きません。ソフトウェアパスで安全な固定引数（headless-software：--disable-gpu --disable-gpu-compositing --use-angle=swiftshader --disable-gpu-program-cache --disable-gpu-shader-disk-cache；ソフトウェアモードが起動時にクラッシュした場合、インプロセスGPUフォールバックが実行されます）でレンダリングします。選択されたモードは常に報告され（headless、window_mode、launch_mode）、静かに変更されることはありません。セッションは、ブラウザが短い静止チェックを通過した後にのみreadyと宣言されます — DevToolsはChromeが死ぬ直前に到達可能になる可能性があるため（例：GPUプロセスクラッシュ）、/json/versionが一度応答しただけではreadyは返されません。ブラウザのstdoutはリダイレクトされるためMCPストリームを破損することはなく、stderrは診断のために境界付きの編集済みテールにキャプチャされ（Chromeが報告するGPUプロセス終了コードを含む）、予期しない終了は所有プロセスツリー（crashpad/GPU/utility/renderer、正確な所有プロファイルパスで識別）を刈り取り、所有プロファイルを削除します — ユーザーのChromeは決して削除しません。機能ゲート、権限ゲート、Playwrightなし、手動デバッグフラグなし。

• 階層化権限モデル — 14のv1読み取り機能に加えて、別途ゲートされたapplication.browser.launch/navigate/closeアクション機能に対する4つのモード（safe、read_only、approval、unrestricted）。拒否は正確に何が必要かを説明します。

• プロバイダーアーキテクチャ — すべてがWindowsBackend / ApplicationProviderトレイトの背後にあります。実際のWin32レイヤーは完全に分離可能であり、モックバックエンドと決定論的フィクスチャが、マシン依存なしで381テストスイート（cargo test --features mocks）を動かします。

• 設計による堅牢化 — 結果の境界、ツールごとのタイムアウト、ペイロード上限、8 MiBのトランスポートフレーム上限、厳格なJSONスキーマ検証、stdoutはプロトコルクリーンに維持（すべての診断はstderrへ）。

• npm配布 — 2つのパッケージ、@winkit/mcp（ランチャー）と@winkit/win32-x64-msvc（Windows x64ネイティブランタイム）、npx --yes @winkit/mcp@latestでインストール。インストールスクリプトなし、ブラウザ自動化依存関係なし。ネイティブ実行可能ファイルは実装の詳細です。

• エージェントスキル — skills/winkit-developer-debugging/SKILL.mdは、コーディングエージェントに質問→ツールルーティング、権限とプロファイルの選択、安全/読み取り専用の境界を教えます。

• 評価スイート — tests/eval/は、フィクスチャベースの決定論的18シナリオスイートであり、ステータス、証拠、所見ID、支持/矛盾する証拠、編集、境界出力、権限動作、およびWinKitが診断するために構築された障害モードに対する誤った根本原因の主張がないことを検証します。

クイックスタート

要件：Windows 10/11 x64およびNode.js >= 18（npmパス）またはRust 1.75+（ソースから）。

npx --yes @winkit/mcp@latest doctor   # verify the install

またはソースからビルド：

cargo build --release
.\target\release\winkit --help

WinKitはMCPクライアントによってstdioサブプロセスとして起動され、npxランチャー経由またはビルド済みバイナリから直接起動されます（docs/mcp-integration.md参照）：

• OpenCode — examples/mcp/opencode.json

• Claude Code — examples/mcp/claude-code.json

• Any MCP client — examples/mcp/generic.json

設定ファイルがない場合、WinKitは安全なデフォルトで実行されます：read_only権限モード、両方の組み込みプロバイダーが有効、文書化された制限。完全な表面についてはconfig/example.tomlを、完全なセットアップについてはdocs/installation.mdを参照してください。

Chrome検査と管理ブラウザ

Chromeの深層検査には、ChromeがDevToolsエンドポイントを公開する必要があります。WinKitはこれを自動で行えます：[chrome.managed] enabled = trueとapplication.browser.launch権限を使用すると、chrome_start_managed_sessionは独自の隔離されたChromeインスタンス（使い捨てプロファイル、ループバックのみのDevToolsエンドポイント）を起動するため、手動のデバッグフラグや別のブラウザプロセスは不要です。デフォルトでは、デスクトップに実際の可視Chromeウィンドウが開きます。非可視の自動化/CIセッションが必要な場合のみheadless: trueを渡します（そのモードは設計上ウィンドウを開きません）：

chrome_start_managed_session(url="http://localhost:3000")  # opens a visible Chrome window
  -> chrome_get_page_summary(session_id)     # runtime errors, failed requests, headings
  -> chrome_capture_screenshot(session_id)   # optional visual check
  -> chrome_stop_managed_session(session_id) # closes Chrome, removes the profile

既に実行中のChrome（たとえば開発者が--remote-debugging-portで起動したもの）を検査するには、WinKitはfallback_port（デフォルト9222）をプローブしてエンドポイントを発見し、CDP経由で接続します。完全なライフサイクル、状態、セキュリティルールについてはdocs/chrome.mdを参照してください。

パフォーマンス

エンドツーエンドの中央値レイテンシ。Windows 10デスクトップ（8コア、16 GB RAM）でリリースビルド、呼び出しごとに新しいサーバープロセスを使用して測定 — そのため数値にはプロセス起動とMCP初期化ハンドシェイクが含まれます：

観測ウィンドウツールは、システムサイズではなく設定されたウィンドウに応じてスケーリングします。他のすべてのツールは、プロセス、ポート、タブの数に関係なく100 ms未満を維持します。完全な表と方法論：docs/performance.md。

ツールサーフェス

引数スキーマを含む完全なリファレンス: docs/tools.md.

アーキテクチャ

WinKitのパイプラインは、責任の3層分離です。WinKitは測定し、WinKitはシグナルを解釈し、WinKitは証拠に基づく発見をランク付けします。LLMがそれらを説明します。

                 WinKit
                   │
      ┌────────────┼────────────┐
      │            │            │
  Observation  Correlation  Diagnosis
      │            │            │
      ↓            ↓            ↓
  Windows/App   Evidence    Findings
    metrics      linking     ranking

server (MCP over stdio, JSON-RPC 2.0, session lifecycle)
  ├── tools        (59 tool definitions + argument handling + registry)
  │     ├── providers (WindowsBackend / ApplicationProvider traits)
  │     │     └── chrome::managed (isolated WinKit-owned sessions)
  │     └── platform::windows (real Win32 implementations, windows-sys 0.59)
  ├── permissions  (modes, capabilities, policy, approval surface)
  ├── config       (winkit.toml, strict, deny-unknown-keys)
  ├── models       (unified data models shared by providers/tools/diagnostics)
  └── diagnostics  (measurements → signals → ranked findings)

階層化ルールは厳格です。MCPサーフェスはWin32に直接触れることはなく、Windows層はモックバックエンド（cargo test --features mocks）を通じてテスト可能です。詳細: docs/architecture.md。

セキュリティモデル

• デフォルトで読み取り専用 — すべての検査ツールは読み取り専用です。唯一のアクション（管理ブラウザの起動/ナビゲート/閉じる）は[chrome.managed] enabledで機能ゲートされ、safe/read_onlyモードでは拒否されます。

• 権限モードはすべてのツール呼び出しをゲートし、ディスパッチ前に、管理ブラウザのライフサイクルツールには別のアクションゲートがあります。

• 管理ブラウザは分離され、自己洗浄 — 管理ルート下の使い捨てプロファイル、ループバックのみのDevTools、管理ルート外のパスを拒否するクリーンアップ、通常のChromeプロファイルには決してアタッチしません。

• シークレットはキャプチャされません — Chromeのネットワーク/ランタイム検査は出力を切り詰め、ヘッダー、クッキー、ボディを明示的に除外します。URLは編集されます（クエリ文字列は削除）。

• どこでも作業範囲を制限 — 結果の上限、タイムアウト、ペイロードの上限、フレームの上限。

• 詳細: SECURITY.md および docs/security.md。

既知の制限

WinKitは制限をバグではなく第一級の出力として扱います。

• プロセスごとのCPUパーセントはライブサンプルであり、累積測定ではありません。 単純なシステム比率計算はマルチコアマシンでは誤解を招くため、list_processes（安価な完全スナップショット）はcpu_percent: nullを報告します。暴走プロセスを特定するには、get_processが300msのウィンドウで明示的な基準（system_capacity_all_cores）を使用してライブの2サンプルCPUパーセントをサンプリングします。集約ビュー（ApplicationGroupInfo）も1秒のサンプルで同様に行います。

• Chromeは常にタブをPIDにマッピングできるとは限りません — アダプターはprocess_mapping: "none"を報告し、失敗や推測ではなく純粋なCDP証拠で続行します。

• 一部のWindowsプロセスは読み取りアクセスを拒否します — 読み取れなかったフィールドはnullでリストされ、黙って削除されることはありません。

• 診断は測定済みと未測定を区別します — system_diagnoseはevidence_completenessを持ち、レポートにはlimitationsエントリを含めることができるため、エージェントが部分的なビューを過大評価しません。

• 既に実行中のChromeの検査にはリモートデバッグポートが必要です。 管理ブラウザワークフローは、ローカルアプリ診断のためにその要件を排除します。WinKitは機能と権限が有効な場合、独自の分離されたChromeを起動します。通常のブラウジングプロファイルは常に触れられません。

開発

cargo check                 # compile checks
cargo build                 # debug build
cargo test --features mocks # full test suite (381 tests)
cargo clippy --all-targets  # lint

# evaluation suite (fixture-backed failure scenarios)
cargo test --features mocks --test eval

# npm launcher + package validation (after cargo build --release)
powershell -ExecutionPolicy Bypass -File npm/scripts/copy-native.ps1
node --test npm/test/launcher.test.js npm/test/package.test.js
powershell -ExecutionPolicy Bypass -File npm/scripts/test-packed.ps1

# opt-in live tests (need a real Windows machine / Chrome install)
$env:WINKIT_LIVE_WINDOWS = "1"; cargo test --features live-windows
# live managed-Chrome lifecycle, both modes (requires an installed Google
# Chrome on an interactive desktop; run ten consecutive isolated runs per
# mode before any release-ready claim)
$env:WINKIT_LIVE_CHROME = "1"; cargo test --features live-chrome --lib live_managed_chrome_headed_start_inspect_stop -- --nocapture
$env:WINKIT_LIVE_CHROME = "1"; cargo test --features live-chrome --lib live_managed_chrome_headless_start_inspect_stop -- --nocapture

ライブ管理Chromeテストは、WINKIT_LIVE_CHROMEが1でない場合、明示的なスキップ理由を出力します。ヘッド付きテストも、インタラクティブなデスクトップがない場合にスキップします（ヘッド付き動作は未検証とマーク）。スキップされたライブテストは合格ではなく、実際のChromeインストールで両方のモードが合格しなければ、プロジェクトは「リリース準備完了」ではありません（docs/release.mdを参照）。

統合テストは、実際のマシンに触れることなく、MCPプロトコル、ツールディスパッチ、権限の強制、フィクスチャベースのモックプロバイダーを実行します。評価スイート（tests/eval/）は18の決定論的な障害シナリオをカバーしています。docs/development.mdおよびCONTRIBUTING.mdを参照してください。

ドキュメント

• docs/installation.md — ビルド、設定、MCPクライアントへの接続

• docs/architecture.md — 階層化、データフロー、プロバイダーモデル

• docs/diagnostics.md — 証拠優先のレポート形式とスコア計算式

• docs/security.md — 脅威モデルと緩和策

• docs/permissions.md — モード、機能、ポリシーテーブル

• docs/tools.md — 引数付きツールリファレンス

• docs/configuration.md — すべての設定キーとデフォルト値

• docs/application-adapters.md — アダプターのプラグイン方法

• docs/chrome.md — Chromeの検出、CDP、管理セッション、注意点

• docs/performance.md — ベンチマーク手法と完全なテーブル

• docs/demos.md — 3つのデモスクリプトと録画ガイド

• docs/mcp-integration.md — クライアント設定例

• docs/development.md — ビルド、テスト、貢献

• docs/release.md — リリースプロセスとチェックリスト

• tests/eval/README.md — 評価スイートの実行方法

• skills/winkit-developer-debugging/SKILL.md — エージェントスキル

ライセンス

MIT — LICENSEを参照。WinKitはローカルファーストでオープンソースです。テレメトリは含まれておらず、ループバックのChrome DevToolsプローブ以外のネットワーク呼び出しは行いません。