Agent Guard v3.4.1 導入マニュアル

Claude Code · macOS/Linux · 100名までの段階導入
Agent Guard 3.4.1準拠 · 2026-09-11確認。管理設定、セットアップ、検証、ログ提出、復旧の手順を説明します。

1. 導入経路と完了条件

Jamf適用前はuserスコープで導入し、管理配布ではJamfで設定を適用します。 どちらもプラグイン確認 → setup-agent-guard → setup-shell → ターミナル・Claude Code再起動 → 受入検査の順に進めます。依存関係の導入はsetupの案内に従って承認します。HomebrewまたはcurlでCLIを先に導入した端末は、10節のagent-guard plugin installでホストプラグインを追加してから同じ受入手順へ進みます。

開始前に管理者が記入する項目: 導入責任者、サポート担当、社内問い合わせ先、ログ提出先と閲覧権限、対象端末一覧、ロールバック用設定バックアップの場所。告知テンプレートは11節にあります。Agent Guardには中央収集サーバーや管理ダッシュボードがないため、既存の社内チケット・ファイル提出チャネルを使います。

100名まで拡大する順序

観察期間は最低値です。拡大の可否は各段階の受入結果で判断します。合成テストの原文露出、hook未実行、反復するtimeout、未解決のDEGRADEDがあれば拡大を停止します。LinuxではCIは成功していますが、実際のClaude Codeホストの受入検査は各対象端末で先に行う必要があります。

2. 導入設定JSON

3節の導入経路に従って以下の項目を適用します。手動導入は利用者設定~/.claude/settings.json、Jamf配布は既存managed設定にマージし、他の設定は維持します。適用後は/statusで設定の出所を確認します。Claude管理設定の公式ドキュメント

{
  "extraKnownMarketplaces": {
    "agent-guard": {
      "source": {
        "source": "github",
        "repo": "JeongJaeSoon/agent-guard",
        "ref": "v3.4.1"
      },
      "autoUpdate": false
    }
  },
  "enabledPlugins": {
    "agent-guard@agent-guard": true
  },
  "env": {
    "AGENT_GUARD_INFRA_FAILURE_MODE": "closed",
    "AGENT_GUARD_PII_HOOK_MODE": "off",
    "AGENT_GUARD_LOG_MODE": "on"
  }
}

openとclosed: どちらも依存関係不足時にsetup・必要な導入・再検査を案内します。openは警告後に続行し、closedはブロックします。製品のデフォルト値と誤入力値の処理結果はopenなので、closedの綴りをそのまま使用してください。同一セッションの警告は反復抑制される場合があります。hookがまったく実行されない場合やホストがtimeoutで終了する場合、この設定だけで保護は保証できません。

任意: marketplace許可リストを運用する会社

strictKnownMarketplacesを運用する会社は、既存の承認項目を保持しながらAgent Guard項目を追加・更新します。sourceとrefは上記marketplace設定に合わせます。公式marketplace制限説明

以下は Agent Guardのみを許可すると決定した場合の追加トップレベルキー です。これだけを別JSONファイルとして配布せず、上記の完全JSONのトップレベルオブジェクトへ入れてください。他marketplaceが必要な会社は、この単一項目の配列へ置換してはいけません。

{
  "strictKnownMarketplaces": [
    {
      "source": "github",
      "repo": "JeongJaeSoon/agent-guard",
      "ref": "v3.4.1"
    }
  ]
}

3. 導入経路: 手動導入またはJamf

3-1. Jamf適用前: 利用者による手動導入

ローカルのClaude Codeが導入・ログイン済みの端末で進めます。Git不足でプラグインを取得できない場合は、管理者が5-3節に従って基本環境を準備します。jq・gitleaksの導入はプラグイン導入後にsetupが案内します。

1. 通常ターミナルで承認済みv3.4.1のmarketplaceとプラグインをuserスコープに導入します。

claude plugin marketplace add JeongJaeSoon/agent-guard@v3.4.1 --scope user
claude plugin install agent-guard@agent-guard --scope user

2. ~/.claude/settings.jsonを編集します。ファイルがなければ2節のJSONで作成し、既存ファイルがあれば他の項目を保持してextraKnownMarketplaces、enabledPlugins、envにAgent Guard設定をマージします。ref: v3.4.1、autoUpdate: false、closed、ログonを確認します。
3. Claude Codeを再起動し、/statusで利用者設定のロード、/pluginでAgent Guardの有効化を確認します。
4. 4–5節に従って二つのsetupスキルを実行し、必要な作業を承認した後、ターミナルとClaude Codeを再起動します。6節の保護検査と7節のログ確認を完了します。

利用者設定は強制ポリシーではありません。会社のmanaged設定があれば、そのポリシーが優先します。Jamfへの移行時は管理者が以下の設定を配布し、実際の設定出所・バージョン・保護検査を再確認します。動作中のプラグインを先に削除する必要はありません。Claude導入コマンド

3-2. Jamfによる管理設定の配布

JamfでClaude managed設定を配布する既存ポリシー・プロファイルの管理元を更新します。

1. 既存設定を開く: Jamfで現在のClaude設定を配布している項目を開き、変更前の設定と配布対象を変更記録へ保管します。
2. Agent Guard設定を追加: 2節JSONのextraKnownMarketplaces、enabledPlugins、env項目を既存JSONへ反映します。他の会社設定はそのまま保持します。このJSONで既存ファイル全体を置換しません。
3. 許可リストを確認: 会社がstrictKnownMarketplacesを使う場合、既存の承認項目を保持しながらAgent Guardのsourceとref: v3.4.1を追加・更新します。使用していない会社はこのキーを新たに入れる必要はありません。
4. 設定をレビュー: 以下の表の値とJSON構文を確認し、既存Jamfの配布形式に合わせて保存します。ポリシーがファイルを配布するか、管理プロファイルを配布するかは既存方式を維持します。
5. テストグループへ配布: まず管理者・保守担当の2〜3名だけへ適用します。Jamfで対象端末にポリシー・プロファイルが配布されたことを確認します。
6. 実際のロードを確認: 利用者がClaude Codeを再起動し、/statusのmanaged設定の出所と/pluginのAgent Guard有効化を確認します。続いてsetupと6節の受入検査を実行します。

Jamfの配布成功とClaudeの保護動作は別々に確認します。 他のmanaged出所が優先された場合やプラグイン導入に失敗した場合は、/status・/plugin・setupの結果で確認し、既存の管理元を修正します。ローカル設定を一時的に上書きして完了扱いにはしません。Linuxも含む組織は、Linux用の既存構成管理経路に同じJSONを反映します。本書のJamf手順はmacOS端末を基準にしています。

4. 利用開始: 二つのスキルを実行してテスト

3節のプラグイン導入・設定適用後、Claude Codeで一つずつ実行します。

/agent-guard:setup-agent-guard
/agent-guard:setup-shell

1. setup-agent-guardの案内に従って必要な導入を承認します。スキルが依存関係・チェックサムの確認、導入、保護検査を進めます。
2. 完了後にsetup-shellを実行し、shell設定の変更を承認します。
3. ターミナルとClaude Codeを両方終了し、新しく開始します。
4. 6節のテストプロンプトを入力し、ブロック・マスキング・正常コマンドの結果を確認します。

この経路ではAgent Guard本体をHomebrewやcurlで再度導入しません。 setup-agent-guardはプラグインに含まれるCLIを使って依存関係と保護動作を 診断し、別のagent-guardコマンドをPATHへ導入しません。setup-shellが bash/zsh設定へプラグインの安定パスを追加するため、再起動後は同じ plugin-local CLIをagent-guardコマンドとして利用できます。

進行が止まった場合はスキルの案内と5節の復旧手順を使います。初回プラグイン導入に必要なGitや基本実行環境がない端末は管理者が準備します。対象はClaude Codeが導入・ログイン済みのmacOS/Linuxで、検証バージョンは2.1.268です。他バージョンは対象端末で受入検査を行います。

5. 設定結果の確認とトラブル対応

5-1. プラグインとsetup結果の確認

Claude Codeを再起動し、/statusで選んだ経路の設定出所、/pluginでAgent Guardを確認します。導入・信頼確認画面が出た場合は、出所 JeongJaeSoon/agent-guard、承認tag v3.4.1を確認します。Agent Guard項目がなければ、3節の導入・設定適用結果を確認します。管理ポリシーを回避して他marketplaceやローカルcloneを追加しません。

Agent Guardがすでに導入・有効化されていれば、利用者ごとのインストールコマンドは不要です。 手動導入とJamf配布のどちらも、以下のsetup手順へ進みます。Jamfは管理設定を配布します。extraKnownMarketplacesによるmarketplaceの自動登録と、pluginの導入完了は区別します。enabledPluginsだけですべての新規端末への導入が完了するかは、この配布環境ではまだ検証していないため、管理者は既存の導入がない試験端末でも確認します。Claude marketplace配布ドキュメント

プラグインやスキルコマンドが表示されなければ、3節の導入結果を確認し、5-3節に従って復旧します。

setupは実際の plugin-local実行ファイル を探し、依存関係を診断します。git・jq・gitleaksなどがなければ、必要な導入方法を表示して利用者の承認を得ます。導入・ダウンロードに追加ツールが必要なら、その不足も解消してから再検査するよう求めます。gitleaksは バージョン・OS/CPU・公式ダウンロードURL・SHA-256・導入場所を確認後に導入します。hookは依存関係を勝手に導入しません。導入がsandboxで拒否された場合は、setupが示す正確なコマンドを通常ターミナルで実行し、setupを再実行します。closed状態でsetupのツール実行もブロックされる場合は、ポリシーをopenへ下げず、5-3節の管理者または通常ターミナルでの復旧手順を使います。

5-2. CLIコマンドの確認

setup-shellの完了後にbash/zshターミナルを再起動すると、プラグインの安定パスがPATHへ追加されます。絶対パスや変数を入力せず、agent-guardコマンドを直接使えます。setupですでに検査しているため、通常は再実行せず、サポート依頼時だけ確認します。

agent-guard version
agent-guard check
agent-guard smoke-test

期待するバージョンはagent-guard 3.4.1です。コマンドが見つからない場合はターミナルを再起動し、setup-shellを再実行します。fishプロンプトではPATHが自動適用されない場合があるため、setupが表示した実行ファイルを使うか、bash/zshターミナルで実行します。

5-3. 例外復旧: setupまたは導入実行が止まった場合

プラグイン導入が欠けている場合のみ: まず管理者がmanaged設定のロード・marketplace登録・ネットワークアクセスを確認し、修正します。marketplaceは見えるがplugin導入だけが欠け、管理者がuserスコープの導入を許可した場合に限り、以下のコマンドを通常ターミナルで実行します。導入済みの利用者は実行しません。導入後は/pluginで実際のスコープを確認し、結果表にuserスコープ導入と記録してから、Claude Codeを再起動して4節の二つのスキルを実行します。

claude plugin install agent-guard@agent-guard --scope user

基本手順はsetupであり、次のコマンドを全利用者に事前実行させません。 setupが導入承認を要求してもホスト権限で実行できない場合は、示されたコマンドを通常ターミナルで実行します。プラグイン取得に必要なGitすらない、またはsetup自体を開始できない場合には、管理者が以下の例または会社のソフトウェア配布ツールで復旧します。

パッケージマネージャーやOS標準のsh・awkまでない場合は、管理者が会社標準環境で復旧します。新たなパッケージマネージャーを独断で導入しません。復旧後は同じsetupを再実行して、導入と検証を継続します。

導入がブロックされた場合は、setupが示す端末に合った復旧コマンドを通常ターミナルで実行し、同じsetupを再実行します。gitleaksのバージョン・チェックサム・導入先はsetupが確認した値を使います。

5-4. setup-shellと再起動

setup-agent-guard完了後、Claude Codeで次のコマンドを実行します。変更するshell rcファイルと内容を確認して承認します。

/agent-guard:setup-shell

その後、ターミナルとClaude Codeセッションの両方を新しく開始します。実際のシークレット値ではテストしません。

6. 端末ごとの受入検査

以下を全て確認するまでは、「導入完了」を「保護が動作している」と報告しません。 各検査には合成データだけを使用します。実際の会社キーで試験しません。

Claudeへ送るLIVE検査依頼

以下の文章を Claude Codeの会話へ貼り付けます。 通常ターミナルでprobeだけを実行しても、ホストhookの検証にはなりません。

Agent Guard の LIVE 検証をしてください。通常の Bash ツールで次のコマンドを一度実行してください。
printf '%s\n' 'AGENT_GUARD_LIVE_PRE_TOOL_PROBE'

Agent Guard による実行前ブロックかを確認してください。ブロックされた場合は、再試行や回避をしないでください。
続けて、インストール済みの setup-agent-guard skill にある LIVE post-tool 合成 probe を
同じ Bash ツールで一度実行してください。実際のキーを使わず、skill本来の
合成 probe を使用してください。literal [REDACTED] を出力する偽の検査に置き換えないでください。
モデルに渡された出力が原文ではなく [REDACTED] に置換されたか確認してください。
最後に printf 'agent-guard-normal-check\n' を別途実行し、
通常作業の終了コード0も確認してください。各結果を分けて報告してください。

post probeは導入済みのsetupが実行します。ホストの通常のpermission拒否はAgent Guardのブロック証拠にはなりません。結果を出したツール・hookが不明な場合は未確認と記録し、サポート担当に確認を依頼します。

合格ではない結果: DEGRADED、scanner error、timeout、無応答、合成原文の露出、pluginバージョン不一致。doctorの「host hook protection: unverified」は、依存関係検査だけではホスト保護を証明しないという案内です。LIVE検査を別途実行します。scan-working-treeは現在の変更範囲の検査であり、ignoredファイル全体やGit履歴全体の検査ではありません。

管理者・サポート担当者による受入結果の確認

7. ローカルログとサポート依頼

ローカルログはデフォルトで有効で、中央への自動送信は行いません。標準パスは~/.local/state/agent-guardで、XDG_STATE_HOMEが指定されていれば、その配下のagent-guardです。フォルダーは利用者専用、イベントファイルの権限は0600です。

保持目標は 7日・1,000回実行であり、制限付きの整理処理と同時実行により超過する場合があります。記録はbest-effortであり、不変の監査ログではありません。詳細原因コード・スタック・再現内容がないため、このファイルだけですべての障害を診断することはできません。

提出ファイルの作成 — 通常ターミナル

logs exportが個人情報を除いたサポート用JSONLを生成します。以下のbare コマンドはsetup-shell後の新しいbash/zshで実行し、通常ターミナルの現在の フォルダーへ権限0600で保存します。

agent-guard logs status
agent-guard logs export --output agent-guard-support.jsonl

Storage: private directory readyを確認し、agent-guard-support.jsonlを提出します。LIVE検査後もファイルが空なら、「想定したhookイベントがexportされない」と記録します。まだhookイベントがなければ空ファイルになる場合があります。logs status自体は実際のhook実行証拠ではありません。サポート終了後は会社の保持ポリシーに従って提出物を削除します。

fish、再起動前、またはshell設定に失敗した状態では上のbareコマンドを 実行しません。setup-shellを再実行し、最後に表示されるplugin-localの ログコマンド全体をそのままコピーします。パスが分からない場合は生のstderrや 会話transcriptを代わりに提出しません。

exportがjq不足を報告した場合は、setup-agent-guardが提示する依存関係の 復旧を承認してから再試行します。ログoff、保存領域利用不可、再現後も空の export、開始記録だけが残る場合は、バージョン・host・OS/CPU・発生時刻と タイムゾーン・結果区分・秘密値を除いたエラー要約だけをサポート担当へ送り、 生の診断資料で代用しません。

併せて送る手動要約: 対象識別番号、OS/CPU、Claudeバージョン、Agent Guardバージョン、発生時刻・タイムゾーン、正常/ブロック/マスキング/エラー分類、シークレットを含まない再現手順の説明、関連run_id。プロンプト原文・会話transcript・stderr全体・環境変数ダンプ・キー・原本ファイルは送信しません。

8. リポジトリのGitHub Actions検査

ホストhookとは別に、リポジトリにも検査を維持します。以下をリポジトリの .github/workflows/agent-guard.yml として保存し、PR経由で反映します。ファイル本文全体です。既存の同一検査があれば重複追加しません。

name: Agent Guard
on:
  pull_request:
  push:
permissions:
  contents: read
jobs:
  secret-guard:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - uses: JeongJaeSoon/agent-guard@f2edc23f2b7d5d772345046f423ae14df759a9ca # v3.4.1
        with:
          paths: "."
          gitleaks-version: "8.30.1"
          gitleaks-checksum: "551f6fc83ea457d62a0d98237cbad105af8d557003051f41f3e7ca7b3f2470eb"

上記チェックサムはgitleaks 8.30.1 / Linux x64用です。runnerのOS/CPUを変える場合、そのまま使いません。会社承認済みrunnerで実際のPRを開き、jobの実行と正常終了を確認してから、リポジトリSettingsのbranch rules/rulesetで対象ブランチの該当する実際のcheck名をマージ必須検査に指定します。ワークフローファイルを追加しただけではマージは自動ブロックされません。利用者ごとのローカルGit hookは回避可能なため、会社CIの代替とは扱いません。

9. 障害対応・バージョン変更・ロールバック

症状別の初動

次バージョンへの変更

1. 管理者が新しいリリースと検証結果をレビューし、承認tagを決めます。
2. Jamfの既存Claude managed設定でAgent Guard marketplaceのrefを新しいtagへ変更します。strictKnownMarketplacesにもAgent Guard項目があれば、そのrefも一緒に変更します。他の会社設定は保持します。
3. autoUpdate: false、closed、ログonを維持したまま、テストグループから配布します。
4. 利用者がClaude Codeを再起動し、/pluginで承認済みmarketplaceの更新・plugin更新を行います。適用されたplugin-localバージョンが期待値かをsetupで確認します。バージョンが変わらない場合は、管理者と実際の導入スコープ・marketplace refを確認します。
5. setup → check/smoke → 実際のLIVE検査 → ログ確認を再度成功させたら、次のグループへ拡大します。shell統合がdriftを通知する場合は/agent-guard:setup-shellを再実行します。

管理設定のtagを変えたという事実だけで、導入済みプラグインまで更新されたとは判断しません。プラグインキャッシュはClaudeのプラグイン管理機能を通じて更新し、plugin-local CLIのupdateは使いません。

設定のロールバック

1. 新規の拡大を停止し、変更記録に保管した以前の承認済み設定を確認します。
2. Jamfの既存Claude managed設定でAgent Guard source/ref・環境設定を以前の値へ戻し、同じ対象へ再配布します。その間に他の会社ポリシーが変わった場合は、設定全体を過去状態へ上書きせず、Agent Guard関連の変更だけを戻します。
3. 利用者がClaude Codeを再起動し、/status・/plugin・setupで以前の設定と実際のプラグインバージョンを確認します。ホストが以前のバージョンを適用しない場合は、管理者承認済みのplugin再導入を行います。
4. 初回導入自体を撤回する場合は、Jamfの強制有効化設定を削除してから、/pluginでAgent Guardを無効化・削除します。管理キーの削除だけで既導入のuser pluginが自動削除されるとは想定しません。
5. 任意で使ったshell wrappingも無効化する場合は、plugin-local実行ファイルが残っているときに以下を実行し、ターミナルとClaude Codeを再起動します。

agent-guard setup-shell --no-command-wrapping

初回導入の撤回は保護の解除を意味するため、対象利用者へ通知します。v3.3.0へロールバックする場合、v3.4.1のログ・補完を維持すると仮定できません。 ロールバック中もリポジトリCIを維持し、正常な保護検査なしに次グループへ拡大しません。

10. 任意: Homebrew・curl CLI導入

プラグイン導入後にsetup-shellまで完了したbash/zsh利用者は、すでにagent-guardコマンドを使用できます。そのため、コマンドを得る目的でHomebrewを追加導入しません。この節はHomebrewまたはcurl CLIを先に導入する端末、あるいはホストプラグインなしでCLIだけを運用する端末向けです。

逆にHomebrewまたはcurlでv3.4.1 CLIを先に導入した端末では、CLIから Claude CodeとCodexの公式プラグイン管理機能を呼び出せます。CLI自身が ホスト設定ファイルやプラグインキャッシュを直接変更することはありません。 Jamf管理対象では利用者がこのコマンドで導入・更新・削除を行わず、CLIも managed設定を検出すると変更を拒否します。管理者が2節のpinned tagを変更します。

agent-guard plugin status --host all
agent-guard plugin install --host claude
agent-guard plugin install --host codex

導入コマンドはmarketplaceをCLIと同じv3.4.1 tagに固定します。同じ名前の marketplaceが未固定、別tag、または別sourceの場合は自動で置き換えずに停止し、 公式host managerで削除してから再導入する正確なコマンドを表示します。 marketplaceの削除はそこから導入したプラグインも削除するため、表示された 順序ですぐに再導入し、もう一度検査します。

Claudeだけを使う端末では--host claudeの一行だけ実行します。導入後に ホストを再起動し、4節の二つのスキルと6節の受入検査を行います。その後の 更新はagent-guard plugin update --host claude、削除は agent-guard plugin uninstall --host claudeを明示的に実行します。

CLIを新しいバージョンへ変更しても、ホストプラグインの固定tagは自動では 変わりません。 standaloneのagent-guard updateまたはHomebrewの brew upgrade後に、利用中のhostについて以下を実行します。

agent-guard plugin status --host all
agent-guard plugin update --host all

以前のRelease tagが残っている場合、updateは変更前に停止し、公式host managerで marketplaceを削除して新しいtagで再導入する正確なコマンドを表示します。その 順序に従った後、hostを再起動し、二つのsetupスキルと6節の受入検査を再実行します。 Codexでは変更されたhookを再レビューし、信頼します。その端末に導入済みのhost だけを指定し、Jamf管理対象ではこのコマンドではなく9節の管理者更新手順を使います。

Homebrewがすでにある端末

brew tap JeongJaeSoon/tap
brew install JeongJaeSoon/tap/agent-guard
agent-guard version
agent-guard check
agent-guard smoke-test
agent-guard plugin install --host claude
brew pin agent-guard

v3.4.1公開Releaseとtap公開を確認してから、この節を使用します。brewは導入時点のtapバージョンを使うため、出力が異なれば3.4.1導入成功とは扱いません。brew pinは将来の通常upgradeを防ぐもので、過去バージョンを選ぶ機能ではありません。承認済み更新時だけ、brew unpin agent-guard → brew upgrade JeongJaeSoon/tap/agent-guard → バージョン・check/smoke確認 → 上記host plugin同期と再受入検査 → brew pin agent-guardを実行します。Homebrew導入にagent-guard updateは実行しません。

curlで正確なv3.4.1を導入

通常ターミナルで実行します。installerは自身のarchive SHA-256を検証します。CLIだけを追加するのにshell wrappingまで変わらないよう、この任意経路ではwrappingをoffにします。プラグインとスタンドアロンCLIが共存する場合、この経路よりHomebrew経路を優先します。curl bootstrapはwrappingを無効にしてもshell rcのAgent Guard管理ブロックを作成または更新することがあるため、実行前後のrc変更をレビューし、必要に応じて/agent-guard:setup-shellを再実行してplugin-local設定を復旧します。

(
  set -eu
  ag_bootstrap=$(mktemp)
  trap 'rm -f "$ag_bootstrap"' EXIT HUP INT TERM
  curl -fsSL 'https://github.com/JeongJaeSoon/agent-guard/releases/download/v3.4.1/bootstrap.sh' -o "$ag_bootstrap"
  sh -n "$ag_bootstrap"
  AGENT_GUARD_VERSION=3.4.1 AGENT_GUARD_COMMAND_WRAPPING=off sh "$ag_bootstrap"
)
export PATH="$HOME/.local/bin:$PATH"
agent-guard version
agent-guard check
agent-guard smoke-test
agent-guard plugin install --host claude

bootstrapは~/.agent-guardと~/.local/bin/agent-guardを使い、shell統合設定も行います。プラグイン向け管理envは通常ターミナルのCLIへ自動適用される設定ではありません。 CLIでも同じポリシーを使うなら、そのターミナルでexport AGENT_GUARD_INFRA_FAILURE_MODE=closedとexport AGENT_GUARD_LOG_MODE=onを明示します。スタンドアロンのagent-guard updateは最新公開バージョンを取得するため、バージョン固定期間には実行しません。正確なtagで再導入する場合は、上記コマンドのURLとAGENT_GUARD_VERSIONを一緒に変更し、上記host plugin同期と再受入検査も行います。

11. 導入告知と受入結果表

利用者へ送る告知

[Agent Guard v3.4.1 段階的導入]
対象: <グループと利用者> / 適用日: <日付>
サポート担当: <名前> / 問い合わせ先: <社内チャネル>
JSONL提出先: <承認済みの場所> / 提出資料の閲覧者・保持: <会社ポリシー>

手動導入または管理設定の適用後、Claude Codeを再起動してください。
/pluginでAgent Guardが有効であることを確認し、
/agent-guard:setup-agent-guard を実行してください。
依存関係の導入が必要な場合は、提示されたコマンド・バージョン・チェックサムを確認して承認してください。
`/agent-guard:setup-shell` を実行し、ターミナルとClaude Codeを再起動してください。
このマニュアル6節の依存関係・合成・LIVE・通常作業の検査を完了してください。
DEGRADED、timeout、合成原文の露出は合格ではありません。

問題報告では、7節のlogs export JSONLとシークレットを含まない手動要約だけを提出してください。
キー、原本ファイル、会話transcript、stderr全体を送らないでください。
バージョンを独断で更新したり、closedをopenへ変更したりしないでください。

判断記録には検査時刻・検査者・発生課題・解決・再検査の有無も残します。未確認項目をpassで埋めません。運用担当は各グループ拡大前にこの表をレビューします。

12. 検証範囲と根拠

v3.4.1公開tag f2edc23f2b7d5d772345046f423ae14df759a9caでローカル全テスト 1,408成功・失敗0件を確認しました。隔離環境のClaude Code 2.1.268とCodex CLI 0.153.4で導入・状態・更新・削除を確認し、公開archiveのchecksum・check・smoke-test、Homebrew formulaのstrict online audit・fetch・tap CIに合格しました。100名の実利用、Linuxの実際のClaudeホスト、会社端末全体の受入検査が完了したことを意味するものではありません。

• Agent Guard v3.4.1公開リリース
• 公開tagの設定・導入・検証ソース
• Claude管理設定の配布方法
• Claude設定のロード・優先順位
• Claude marketplace制限
• Claude pluginコマンド