For the complete documentation index, see llms.txt. This page is also available as Markdown.

エージェント型AIポリシーのワークロード削減

Keeperエンドポイント特権マネージャー (EPM) は、エンドポイントごとに評価されるワークロード数で課金されます。エージェントに到達するプロセス起動、ファイルアクセス、昇格リクエスト、バックグラウンドチェックはすべてワークロードとして計上されるため、過剰な活動の多いアプリケーションが動くエンドポイントは、同じポリシーでも活動の少ないソフトウェア環境より多くのワークロードを消費します。

ポリシーの適用範囲を弱めずにワークロード消費を抑えるうえで最も効果的なのは、アプリケーション自身の活動を抑えることです。開発ツール、生産性ツール、バックグラウンドツールの多くは、必要以上にファイルシステムをポーリングしたり、キャッシュを更新したり、定期的なハウスキーピングを実行したりします。各アプリケーション自身の設定を調整して不要な活動を減らすと、EPMの評価に到達する前の発生源でワークロードを削減できます。

以下は、既定の動作がノイズとして知られる特定アプリケーションを対象に、管理対象フリート全体へ設定変更を一元配信してワークロード負荷を下げる推奨手順です。


推奨: JobUpdate ポリシーでCursorのポーリング設定を配信する (macOS)

症状

Cursor IDE (および同様のGit/検索機構を共有するVS Code) が動作するmacOSエンドポイントでは、ユーザーがアイドルでも gitrg (ripgrep) のプロセス起動が連続して発生します。EPMシステム拡張が動作するホストでは、これらのプロセス生成のたびにポリシー評価が介入し、以下のような影響が出ます。

  • エンドポイントあたりのワークロード数 (および課金使用量) が増加する

  • エンドポイント上でCPUとディスク負荷が持続する

  • 監査およびポリシーパイプラインが価値の低いプロセス実行イベントで埋まる

  • 負荷が高いと KEEPER_POLICY_EXEC_TIMEOUT によるfail-open動作の一因になり得る

原因

Cursorの既定は、小規模リポジトリでの対話応答性向けに最適化されており、管理対象エンドポイントでの静かな運用向けではありません。初期状態のCursorは以下を行います。

  • 短い間隔 (既定ではおおよそ1秒ごと) でGitのauto-fetchとauto-refreshを実行する

  • リポジトリを自動検出し、ワークスペース内の .git ディレクトリを再帰的にスキャンする

  • グローバル検索とQuick Openに ripgrep を使い、除外しない限りワークスペース全体を走査する

  • ファイルシステムウォッチャーでワークスペース全体を監視する (node_modules、ビルド出力、.git 内部を含む)

git / rg 呼び出しは個別のプロセス起動であり、EPMシステム拡張がポリシーに照らして評価する必要があります。大規模リポジトリやモノレポでは、この活動は実質的に連続します。

対処: JobUpdate ポリシーですべてのユーザーに静かな設定を配信する

開発者ごとに settings.json を手編集してもらう代わりに、管理対象macOSエンドポイントへスケジュールジョブをインストールする単一の JobUpdate ポリシーをデプロイします。ジョブはEPMサービス (root) として実行され、/Users 配下の各ユーザーホームを列挙し、推奨設定を各ユーザーの ~/Library/Application Support/Cursor/User/settings.json に書き込みます。

ジョブが適用する設定は以下のとおりです。

ワークロード量への効果は以下のとおりです。

  • Git: auto-fetch、auto-refresh、リポジトリ自動検出なし。リポジトリスキャン深度は 0 で、再帰的なワークスペーススキャンなし。1秒ごとの安定した git 呼び出しベースラインを解消します。

  • 検索 (ripgrep): 各階層の .gitignore を尊重し、シンボリックリンクを辿らず、node_modulesdistbuild.git をスキップします。グローバル検索とQuick Openがこれらの重いディレクトリを走査しなくなります。

  • ファイルウォッチャー: 同じディレクトリをワークスペースウォッチャーから除外し、ビルドツールや git が書き込むたびに再インデックスが続くのを防ぎます。

ポリシーJSON

以下は、管理コンソールに貼り付けるポリシーJSONです。外側のフィールドがスコープとインストールのトリガーを定義し、内側の Extension.JobJson がジョブ定義です。ConfigurationPolicyProcessorExtension.JobJson を読み取り、許可された SaveJobToDiskAndLkg パス経由で保存し、ディスクとLast Known Goodの両方を更新します。そのためLKGウォッチャーによる巻き戻しは起きません。

デプロイ前に確認すべき主なフィールドは以下のとおりです。

  • PolicyType: "JobUpdate": ジョブインストール用ポリシーです。ConfigurationPolicyProcessorExtension を読み取り、ジョブをインストールします。

  • Extension.Action: "Add": ジョブをインストールまたは更新します ("Add" はupsert。アンインストールは "Remove")。

  • Extension.JobId: JobJson.id (configure-cursor-polling) と一致させる必要があります。

  • Status: 有効化は "enforce""monitor" はログのみです。

  • MachineCheck: O_w7iACgy53mAwPlniSz4w を対象マシンIDに置き換えるか、全マシン向けに ["*"] を使います。

  • schedule.intervalMinutes: 30: 本番値です。テストでは確認を早めるために 1 でも可。広く展開する前に 30 (またはそれ以上) に戻してください。

  • トリガー: ジョブは PolicyPreprocessingCompleted カスタムイベントとスケジュール間隔の両方で実行されるため、新規インストールのエンドポイントでもポリシー前処理完了後すぐに初回適用されます。

pencil-line

/Library/Keeper/sbin/Jobs/configure-cursor-polling.json を直接編集してデプロイしないでください。ConfigurationLkgReconciliation ファイルシステムウォッチャーが手動編集を巻き戻します (JOB_WATCHER_RESTORE)。利用できる経路は管理コンソールの JobUpdate ポリシーのみです。

ユーザーカバレッジ: ローカル、ADモバイル、ネットワークホーム

/Users/*/ のグロブは、/Users 配下にマウントされたすべてのホームディレクトリを対象にします。macOSでは以下を含みます。

  • ローカルユーザー:/Users/test/Users/jsmith

  • Active Directoryモバイルアカウント: ADプラグインが /Users/<aduser> にモバイルアカウントホームを作成します。ローカルキャッシュホームのため、書き込みは高速で安定します。

  • ネットワークホームディレクトリ: /Users/<networkuser> にマウントされたNFS/AFPホームもグロブ対象です。書き込みはネットワーク経由でホームサーバーへ到達します。

Shared ディレクトリは意図的にスキップします。ジョブはrootで動くため、ユーザー種別を問わずホームのファイル権限で書き込みは阻害されません。/Users 外にマウントされたホーム (例: /Volumes/homes/<user>) は既定グロブの対象外です。非標準のホームルートを使う環境ではグロブを拡張してください。

エスケープの落とし穴

タスクは /bin/bash -c "<script>" でbashスクリプトをインライン化します。Application Support パスには空白があり、JSON、.NETの Process.Start 引数トークナイザ、bashの3層の解析を問題なく通過する必要があります。正しいJSONでは、各 Application Support に対してバックスラッシュを2つ使います。

  • Application\\ Support (JSON上2バックスラッシュ) → 引数文字列では1バックスラッシュ → bashが空白をエスケープ扱い → 1語として処理 → 成功

  • Application\\\\ Support (4バックスラッシュ) → 引数文字列では2バックスラッシュ → bashが \\ をエスケープされたバックスラッシュと解釈し空白が未エスケープ → 単語分割 → echo > のリダイレクト先がディレクトリになる → Is a directory → 終了コード1

両方の箇所 (mkdir パスと echo > リダイレクトパス) で、バックスラッシュは2つにする必要があります。

検証

  • 成功時は、Shared 以外の各ユーザーホームに新しい ~/Library/Application Support/Cursor/User/settings.json (root所有、約477バイト) が残ります。成功時の TASK_COMPLETEJOB_EXECUTION_COMPLETEDebug / Info で記録され、system.logging.levelWarning のときはフィルタされます。

  • 失敗時は、Warningレベルで [WRN] [JobExecutor] [JOB_STOPPED] ... Task 'run-config' failed[WRN] [JobService] [JOB_EXECUTION_COMPLETE] ... Success: False が出ます。これらは既定で可視です。

  • 明示的な ExitCode=0 行を見るには、一時的に /Library/Keeper/sbin/appsettings.jsonsystem.logging.levelDebug にし、エージェントを再起動 (keepersudo launchctl kickstart -k system/com.keeper.endpoint-privilege-manager.launcher) してから、確認後に Warning へ戻してください。

注意事項

  • settings.json を丸ごと上書きします。 タスクは echo > settings.json を使うため、ファイル全体が置き換わります。Cursor設定のユーザー独自カスタマイズは実行のたびに失われます。既存JSONを読んでポーリング関連キーだけマージして書き戻す方式は今後の改善予定です。

  • 冪等性: ポーリング設定については冪等 (同じJSONの再書き込み) ですが、ユーザーが設定した他のキーに対しては破壊的です (上記参照)。

  • ネットワークホームの性能: NFS/AFPホームへの書き込みはネットワーク経由です。遅い回線では60秒タイムアウトに近づくことがあります。タイムアウトが出る場合は、遅い・到達不能なネットワークホームを除外するようグロブを絞ってください。

  • /Users 以外のホームルート: 既定では対象外です。カスタムホームパスを使う環境ではグロブを拡張してください (例: /Users/*/ /Volumes/homes/*/)。

最終更新