managed-agents-secureでManaged Agentsの設定を点検する

Claude Code v2.1.304で、/claude-api managed-agents-secure というサブコマンドが加わりました。Managed Agentsのエージェント1つの設定を読み、Anthropicが公開している「Secure your Managed Agents deployment」のガイドと合っているか、ずれているかを報告します。何も変更しません。

ガイドの中身を人の目で追う代わりに、設定の読み取りと突き合わせをClaude Codeに任せるコマンドです。本番前の確認項目そのものはManaged Agentsを本番に出す前のセキュリティ点検にあります。ここでは、コマンドが何を読み、何を返し、動かす前に何が要るかを扱います。

このコマンドが読むものと、読まないもの

引数は任意のエージェントIDです。managed-agents-secure [<agent-id>] の形で、IDを付けなければスキルが尋ねます。対象はエージェント1つで、必要なClaude Codeはv2.1.304以降です。

スキルはまずガイドを取得し、次の順に読みます。

• エージェント本体の設定
• そのエージェントの最近のセッション
• 定期実行のデプロイメント
• それらが使う環境とvault

取得はすべて ant CLI経由です。書き込みはしません。

もう1つ、ガイドに書かれた挙動があります。頼まなければ、カレントディレクトリのファイルから秘密鍵らしき文字列も探します。出力するのは一致したファイルの名前だけで、中身は出しません。不要なら、最初にそう伝えます。

動かす前の準備

前提は2つです。Claude Codeが新しいことと、ant CLIがエージェントのあるワークスペースに向いていることです。

claude update
brew install anthropics/tap/ant
ant --version
ant auth login --workspace-id wrkspc_01...
ant auth status

ログインのときに --workspace-id を渡すと、ブラウザの選択画面を飛ばして対象を固定できます。点検したいエージェントが別のワークスペースにあるなら、名前付きプロファイルを作って切り替えます。

ant auth login --profile other-ws
ant profile activate other-ws

落とし穴は環境変数です。ANTHROPIC_API_KEY が残っていると、プロファイルより優先されます。点検したつもりが別のワークスペースを見ていた、という事態を避けるために、ant auth status の (active) の行を必ず確かめてください。認証方式の全体はant CLIの認証にまとめています。

実行する

準備が済んだら、Claude Codeのプロンプトで打ちます。

/claude-api managed-agents-secure agent_01...

どのディレクトリで起動するかは、地味に効きます。秘密鍵らしき文字列の探索はカレントディレクトリが対象だからです。アプリのリポジトリで起動すれば、そこにキーが埋まっていないかも同時に見られます。無関係なフォルダで起動すれば、探索は空振りします。

リポジトリを見せたくないときは、コマンドの後に一言添えます。ガイドが言う「頼まなければ探す」の裏返しです。

/claude-api managed-agents-secure agent_01... ただしファイルの秘密鍵検索は不要です

ガイドのどの項目と突き合わせるのか

突き合わせ先のガイドは、設定ごとに「推奨値」を表にしています。スキルが取りに行くのはこの表の設定値です。表は次のように並びます。

ガイドにはほかに、オフラインのレビュー担当と、通知・保持の見直しという2行があります。この2行は、運用の仕組みを指す節です。エージェントの設定値だけを読むコマンドが、どこまで判断できるかはドキュメントに書かれていません。レポートの「読まなかったもの」に出てくるかどうかで、自分の目で見分けます。

表の3行目と4行目は、同じvaultの節に属します。点検表の記事で扱った8項目には、4行目の「アプリ自身がClaude APIにどう認証するか」が入っていません。Workload Identity Federationなら長期のAPIキーが存在せず、漏れる対象も減ります。この行がレポートに出たら、エージェントの外側の話として受け取ってください。

レポートの読み方

レポートの形は、前の節の3部構成です。設定のずれは推奨値つきで並ぶため、直すかどうかを1件ずつ決められます。

注意したいのは、問いの扱いです。たとえば、ガイドは承認方針を「サンドボックスの外に出た変更を取り消せるか」で分けています。エージェントがメールを送ったり、本番のレコードを変えたりするのか。この答えはスキルには分かりません。だから「自分にしか答えられない問い」に回ります。答えを返して、always_ask が必要か判断する材料にします。

もう1つ、auto の読み方です。auto は人間のチェックポイントではなく、サーバーが各呼び出しを評価して実行・拒否・一時停止を決める方式です。レポートが auto を推奨していても、人が見る関門が増えるわけではありません。ネットワーク制限や予算と組み合わせる前提の設定です。

直すときの注意

コマンドは何も変えないので、反映は自分で行います。ここでつまずきやすいのは更新の挙動です。

• エージェントを更新すると tools 配列が丸ごと置き換わる。残したいエントリも全部送り直す
• 更新が届くのは新しいセッションだけで、動いているセッションは古いまま動き続ける
• デプロイメントはエージェントのバージョンを固定しているので、新しいバージョンを指し直す

環境を limited に絞ったときも同じで、動いているセッションは止めて新しく始めます。手順はManaged Agentsのagent設定とクラウド環境の構築手順にあります。vaultの認証情報を直すならVaultで秘密情報を渡す手順が入口です。

設定をファイルで持つ運用にしているなら、ずれを見つけたあとの流れは決まります。ファイルを直して ant apply で反映し、もう一度このコマンドを打ちます。ファイルの起こし方はmanaged-agents-onboardが扱っています。

結果が出ないときの切り分け

レポートが返らない、または別のものを見ているときは、上から順に確かめます。

ずれが複数あるときの直す順序

ガイドは、制限として効きが大きいものから順に並んでいます。最初の2つが実行場所とネットワークで、ツールの絞り込みと承認はその後に続きます。レポートに複数のずれが並んだら、ガイドの並びに沿って上から直すと、重要度の高い制限から順に埋められます。

なお、ツールの allowed_domains が環境の allowed_hosts の外を指していると、セッション作成が400エラーになります。ネットワーク側を先に整え、ツール側をその内側に収める順で進めると、このエラーを避けられます。

点検を習慣にするなら

プロジェクトの CLAUDE.md に1行足しておくと、エージェントを触るたびに思い出せます。次は書き方の一例です。

## Managed Agents
- エージェントの設定を変えたら、反映後に
  `/claude-api managed-agents-secure <agent-id>` を実行し、
  レポートの「変更すべき設定」が空になるまで直す

あくまでチームの運用ルールの例で、コマンド側にこの動きを求める設定はありません。同じコマンドをセッションの中で繰り返し打てば足ります。

限界を先に知っておく

• 対象は1回につきエージェント1つ。複数あれば1つずつ回す
• ant CLIが無いと読めない。権限のないワークスペースのものは見えない
• 読み取り専用なので、ガイドが禁じる「エージェントにClaude APIキーを持たせる」状態を見つけても、外すのは自分
• 点検できるのは取得時点の設定。その後の変更は次の実行まで反映されない

最後の点は、定期実行のデプロイメントがあるエージェントで効きます。スキルは定期実行の設定も読みますが、実行が走るたびに設定を見直す仕組みではありません。変更の都度か、本番に出す前に打つのが現実的な使いどころです。

変更履歴上の位置づけはClaude Code v2.1.304にあります。このコマンドは、ガイドを読んで手で確かめていた作業を、再現できる形にしたものです。