Claude CodeにEndor Labs Agent Kitを入れて依存関係の脆弱性を調べる
Endor Labs Agent Kitプラグインは、依存関係の審査・アップグレード調査・修正計画を担う11個のエージェントとセットアップ用スキルを入れます。導入手順と、編集の前に止まる承認ゲートの仕組みまで説明します。
Endor Labs Agent Kitは、依存関係の脆弱性を調べて直すところまでをClaude Codeのサブエージェントに分担させるプラグインです。入るのは11個のエージェント、セットアップ用のスキル1つ、助言を差し込むフックで、MCPサーバーは入りません。
使うにはEndor Labsのテナント(namespace)と、CLIの endorctl が必要です。ここでは導入の手順、依存関係の調査に効くエージェントの使い分け、ファイルを書き換える前に止まる承認ゲート、つまずきやすい点を順に説明します。
このプラグインが入れるもの
マーケットプレイスの名前は endorlabs、プラグインIDは endor-labs-agent-kit で、バージョンは2.2.3です。パッケージの中身は次の3種類です。
- 11個のワークフローエージェント(
agents/配下) endor-agent-kit-setupスキル(環境の準備状況を確認する)- 4本のフック(助言の差し込みだけを行う)
プラグイン全体のMCPサーバー定義はありません。プラグインに同梱されたエージェントはfrontmatterで mcpServers を宣言できないため、MCPは必要になったときに利用者が明示的に設定する扱いです。
エージェントの既定モデルは sonnet に固定されています。READMEはこれを「リリース時の検証対象であって、必須でも許可リストでもない」と位置づけ、環境変数やサブエージェント呼び出し時の指定で上書きできるとしています。
導入の手順
導入は、マーケットプレイスの追加、インストール、再読み込みの3手です。
/plugin marketplace add endorlabs/ai-plugins
/plugin install endor-labs-agent-kit@endorlabs
/reload-plugins
/agents/agents で11個が並べば導入は完了です。並ばないときは、一度アンインストールして入れ直し、新しいセッションを始めます。同じバージョンのままでも、プラグインのキャッシュが古い内容を保つことがあるためです。
ローカルのチェックアウトで試すなら、Claude Code専用のディレクトリを指定します。
claude --plugin-dir plugins/claude/endor-labs-agent-kitclaude --plugin-dir . とリポジトリの根を指してはいけません。根にはCursor用のエージェントやフックイベントが含まれており、Claude Codeのプラグインとして成り立たないからです。
セットアップスキルが確かめること
導入後の最初の一歩は、スキルに準備状況を確認させることです。
Use the endor-agent-kit-setup skill to check Endor Agent Kit readiness. Do not run scans.スキルが行うのは確認と案内です。調べる対象は、endorctl・gh・git の有無とバージョン、言語ツールチェーン、環境変数 ENDOR_NAMESPACE、~/.endorctl/config.yaml の非機密項目です。認証情報は、値ではなくキーの名前だけを報告します。設定ファイルの全文は表示しません。
endorctl が無いときは、パッケージマネージャー経由(HomebrewやnpmなどEndor Labsの案内に沿った方法)を先に勧め、次にチェックサム検証つきのバイナリ取得を案内します。どれも承認を取ってから実行します。
一方で、スキルは次のことをしません。
endorctl scanやendorctl host-checkの実行- APIキーやトークンをチャットに貼らせること
.zshrcなどシェルの設定ファイルの編集gh・言語ランタイム・パッケージマネージャーの自動インストール
ここで押さえたいのは、namespaceの扱いです。環境変数の ENDOR_NAMESPACE と config.yaml の値が食い違っていると、スキルはEndorへの問い合わせの前に止まり、どちらを使うかを尋ねます。決まったnamespaceは、以降のワークフローで -n <namespace> として明示的に渡されます。複数のテナントを行き来する人ほど、この止まり方が効きます。
依存関係の調査に使う4つのエージェント
11個のうち、依存関係の脆弱性に直接かかわるのは次の4つです。他にFindings Browser(既存の検出結果の閲覧)、Vulnerability Explainer(CVEなど個別の脆弱性の解説)、Malware Responderなどがあります。
| エージェント名 | 担当 | 書き込み系ツール |
|---|---|---|
dependency-reviewer | 担当特定のパッケージのバージョン、またはリポジトリが宣言する依存関係の審査 | 書き込み系ツール使用禁止(読み取り専用) |
oss-upgrade-investigator | 担当アップグレード候補の比較。直る検出と新たに生じる検出を並べる | 書き込み系ツール使用禁止(読み取り専用) |
remediation-planning | 担当PRを開かずに修正の選択肢をプレビュー | 書き込み系ツール使用禁止(読み取り専用) |
sca-remediation | 担当修正の計画から適用まで | 書き込み系ツール承認制 |
dependency-reviewer には3つのプロファイルがあります。新しい依存の可否を判断する package-decision、特定バージョンの危険度を見る package-risk、リポジトリ全体を見る repository-review です。最初のプロンプト例は、リポジトリの直接依存を repository-review で審査し、読み取りに限るという内容になっています。
oss-upgrade-investigator と remediation-planning は、frontmatterで Read・Write・Edit・Glob・Grep まで使えないようにされています。手元のファイルを読まず、Endorが返すデータだけで比較する設計です。結果を現物のコードと突き合わせたいなら、sca-remediation の側で検証することになります。
実際の頼み方は、公式のクイックスタートに載る文面がそのまま使えます。
Show the safest upgrade path for repository <owner>/<repo> package lodash. Keep it read-only.この文面は oss-upgrade-investigator 向けの例です。<owner>/<repo> には、Endorに登録済みのリポジトリを入れます。sca-remediation は「P0のSCA検出」「単一の修正で最も多くの脆弱性を解消したい」のような自然な言い回しも、検索条件に読み替える作りです。
sca-remediationは4か所で承認を取る
sca-remediation は、到達可能で修正可能な検出結果から、依存関係を直すPR(またはMR)までを扱うエージェントです。説明文には、有償のEndor Labs顧客を対象にした作りだと明記されています。書き換えを伴うため、動きは段階に分かれています。
sca-remediationの進み方
- 1
プロジェクトを特定する
gitのルートと
originからowner/repoを割り出します。利用者にプロジェクトのUUIDを求めません。 - 2
計画を出す
パッケージ、現行と移行先のバージョン、影響するマニフェスト、リスク判定、必要な検証、ブランチ名とPRの本文案を示します。ここまでは何も変更しません。
- 3
承認後にファイルを編集する
ローカルのチェックアウトがあるときに限り、承認を得てからマニフェストやロックファイルを最小限だけ書き換えます。
- 4
承認後にプッシュとPR作成
ブランチのプッシュ、PR/MRの作成、チケット、コメントは、それぞれ別の承認が要ります。
エージェントの規則には、承認なしにファイル編集、依存関係マネージャーによる変更コマンド、プッシュ、PR作成、チケット作成、コメント投稿をしないと書かれています。ルートの安全規則も同じで、編集・プッシュ・PR・コメント・チケット・承認の検証・Endorのポリシー書き込みを、別々のゲートに分けます。
初回は計画だけを出させるのが無難です。
Inspect this repository and prepare a remediation plan only. Do not edit files, create branches, push, open a PR/MR, create a ticket, or write Endor policy.計画に添えられる risk_decision には、approved_low_risk のような状態があります。この状態になるのは、アップグレード影響分析と手元のソース調査が問題なく、対象の変更に絞った検証が今回の実行で成功したときに限られます。リスクが低いと評価されただけでは付きません。計画の段階では検証がまだ走っていないので、この判定に頼らず、検証コマンドを自分で確認する運用になります。
フックが差し込むひと言
4本のフックはいずれも助言の差し込みだけで、処理を止めず、Endorのコマンドも実行しません。
| イベント | 対象 | 狙い |
|---|---|---|
UserPromptSubmit | 対象すべての入力 | 狙い依頼に合うEndorのツールを提案する |
PreToolUse | 対象Bash | 狙いendorctl api の直接呼び出しを endorctl agent api --agent-id <id> に誘導する |
PostToolUse | 対象Bash | 狙いnpm install や pip install などの導入コマンドの後に、dependency-reviewer の経由を勧める |
PostToolUse | 対象Edit・MultiEdit・Write | 狙いpackage.json やロックファイルなどの編集の後に、同じ審査エージェントを勧める |
導入コマンドの検知にはパターンが使われており、npm install・pnpm add・yarn add・pip install・poetry add・uv add・cargo add・go get などが対象です。
PreToolUse のフックが気にしているのは、利用の帰属です。直接の endorctl api は誰のエージェントの呼び出しか分からないため、--agent-id に正規のエージェントIDを付けて呼び直すよう促します。IDに -agent を付け足してはいけないとも書かれています。
CLAUDE.mdで補強するなら、次のような一文が考えられます。これは筆者の例で、プラグインが要求するものではありません。
## 依存関係の追加・更新
- 新しいパッケージを入れる前に、dependency-reviewer を package-decision で呼ぶ
- マニフェストやロックファイルを変更したら、repository-review で再確認する
- 審査は読み取り専用で行い、承認なしにインストールしないフックは助言を出すだけなので、強制力はありません。ルールを守らせたい場面では、こうした記述か、Claude Code自体の権限設定と組み合わせることになります。
つまずきやすい点
マーケットプレイスの紹介文とREADMEで説明が違う。マーケットプレイスのページは、セットアップスキルが endorctl を導入し、OAuthまたはAPIキーで認証し、「scan this project for vulnerabilities」で脆弱性スキャンまで走らせる、と紹介しています。一方、GitHubのREADMEとスキル本文は、セットアップがスキャンを実行しない前提です。READMEの最初のプロンプトも、スキャンを走らせないよう明示しています。実際の挙動はREADMEとスキル本文が定義していると見るのが堅実で、スキャンが必要なら利用者が自分で endorctl を動かすことになります。
MCPのツールがない。プラグインはMCPを同梱しません。MCPが要るワークフローでは、セットアップスキルが設定の案内に回ります。サーバー名は endor-cli-tools、コマンドは npx -y endorctl ai-tools mcp-server です。すでに登録済みなら報告するだけで、書き換えの前には承認を取ります。利用できないMCPの信号は、エージェントが data_gaps に記録します。
GitHub CLIが足りない。PRやコメントを扱うワークフローは gh auth status の通る状態を前提にします。gh が無くても自動では入りません。案内に従って自分で入れます。
エージェントを直接書き換えない。パッケージのファイルは生成物で、手編集しない決まりです。挙動を変えたいときは、プラグインのファイルではなく自分用のエージェントを別に作ります。
内容が古いまま。内容の更新にはバージョンの引き上げが伴います。同じバージョンのまま再インストールしても古い内容が出るなら、プラグインを消してキャッシュを消去し、新しいセッションで入れ直します。
向く場面と向かない場面
向くのは、すでにEndor Labsのテナントを持ち、SCAやSASTの検出結果をClaude Codeの会話から引きたいチームです。特に、依存関係の追加時に審査を挟みたい場合と、修正PRの前に計画を人間が確認したい場合に、承認ゲートが働きます。
向かないのは、Endorのアカウントがない個人の開発環境です。アカウント不要で依存関係を調べたいなら、SonatypeのGuideプラグインのように別の選択肢があります。コードの書き方側の脆弱性をその場で検知する用途には、security-guidanceプラグインのほうが近い位置にあります。品質ゲートの運用ならSonarQubeプラグインが参考になります。
どのツールを使う場合も、エージェントが出す推奨は材料にとどまります。上げるバージョンを決めるのは、検証の結果を読んだ人間です。