security-guidance plugin で自社AIリポジトリを毎ターン独立レビューさせる

要点3行サマリー

• Claude Code には security-guidance plugin という、ターン単位で独立にセキュリティ観点をレビューする機構があります。
• idea+ ではこれを「MAMORU（CISO）の常駐」と呼んで、全AIリポジトリで標準ONにしています。
• AIディレクターが現場に持ち込む場合の導入手順とチェックリストをまとめました。

背景・事実

Claude Code は CLI／IDE で動く開発支援エージェントで、plugin と skill を組み合わせて挙動を拡張できます。 そのうちの security-guidance plugin は、次のような特性を持つレビューモジュールです。

• 1ターンごとにエージェントの計画と差分を独立に評価する
• 機密漏えい・権限昇格・外部送信などの観点で警告を出す
• 警告は通常の出力と分離されて返ってくるため、メイン文脈を汚さない

つまり「メインの作業者が頑張っているのと並行で、もう1人が監督席に座っている」状態を作るためのものです。

何が新しいか

これまでのセキュリティレビューは、リリース直前や PR 単位で行うのが普通でした。 security-guidance plugin の新しさは、レビューの粒度を「PRごと」から「ターンごと」に細かくしたことです。

問題は早く見つけたほうが安い。 これはソフトウェア工学の常識です。 ターンごとに見つけるのは、その極限値だと言えます。

idea+ 視点：日本のAIディレクターはどう動くか

ぼくらはこの plugin を、ただのレビュアではなく「MAMORU（AI CxO の CISO）が現場に常駐している」と読み替えて運用しています。 人間の CISO が全プロジェクトに張り付くのは現実的ではない。 ならば、その役割の最初のフィルタは AI に持たせよう、という設計判断です。

導入のために実際にやっているのは、以下の4ステップです。

ステップ1：リポジトリの .claude 配下に plugin を有効化する設定を入れる。 これは1リポジトリ1ファイルの追加で済みます。

ステップ2：警告のしきい値を「中以上は必ず人間レビュー」に設定する。 低警告は記録だけ、中以上は人間レビュー、高警告は作業停止、の3段階。

ステップ3：警告ログを月次で MAMORU 担当人間（idea+ では情シス担当）が一括レビュー。 「なぜ警告が出たか」より「なぜ警告が出なかったか」を見るのが大事。

ステップ4：四半期に一度、警告の傾向を SHIN（監査役）相当の人間にレビューさせる。 ここで「security-guidance plugin 自身が見落としているパターン」を炙り出します。

このループを回すと、独立監督という仕組みが組織の運用に溶け込みます。 plugin はあくまで道具です。 重要なのは、その道具を「監督席」として組織に置く意思決定のほうです。

実装上の注意

• plugin が読むコードに機密が含まれる場合、ローカル動作の plugin であることを必ず確認する
• 警告ログ自体が PII を含み得るので、ログ保存先のアクセス権を狭く設計する
• plugin が出す警告に「無視可能」「自動対処」のフラグを安易に追加しない（独立性が壊れる）

関連する 4OS / 8スキル

• OS0 護る ： 独立監督、ターンごとレビュー、ログのアクセス制御
• OS3 実務 ： plugin 設定、しきい値設計、運用ルール
• 8スキル ： 監督設計、実装設計、運用設計

関連記事

• Code with Claude 2026 発表まとめ ── dreaming / Outcomes / Multiagent / Webhooks
• Claude 18ステップ ── ぼくらが組織に組み込んだバージョン
• AIディレクター認定制度とは何か：4OS × 8スキルの構造

次の一手

• 自社のAIリポジトリに導入したい方は無料相談へ：ai-direction.jp/contact
• AIディレクター認定試験（監督設計パート）を見る：ai-direction.jp/certification
• JAIDAジャーナル の RSS を登録する：/journal/rss.xml

出典

• Claude Code 公式ドキュメント：docs.claude.com
• Anthropic 公式：anthropic.com

---

独立監督は、AI ではなく組織の作法です。 道具は手段、座らせ方が設計です。