Claude に書かせたコードを、別の Claude が後ろからセキュリティレビューする。そういう仕組み（claude-code-security-review プラグイン）をこのリポジトリに入れようとして、設定ファイルに手を伸ばしかけた手前で止まった。「リポジトリ全体に効かせるなら、プロジェクトの settings.json にも書かないと」と思い込んでいたが、整理させてみたら、その一行は一人で開発している自分には要らないものだった。今日はその「要らない」に気づくまでの判断を書き残す。
やりたかったこと
Claude Code が生成したコードには、自分で気づけないセキュリティ上の穴が混じりうる。決済や認証まわりを Claude に触らせている以上、そこは特に怖い。そこで、コードの変更に対して自動でセキュリティレビューを走らせる claude-code-security-review プラグインを導入することにした。
まず前提を確認した
入れる前に、動作条件を満たしているか確認させた。
- Claude Code: 2.1.150（必要 2.1.144 以上）→ クリア
- Python: 3.11 と 3.13 が入っている（必要 3.8 以上）→ クリア
どちらも条件を満たしていたので、そのまま導入に進める状態だった。
設定ファイルに手を伸ばしかけて、止めた
ここがこの日の山場だった。
当初の頭の中では「プラグインをリポジトリ全体に適用したいんだから、プロジェクトの settings.json にも有効化を書く」という流れになっていた。実際に書き始めようとして、いったん手を止めて整理させた。「そもそも、この settings.json は何のために書くんだっけ」を言語化したかった。
整理してみると、自分が2つの別々の話を1つにまぜていたことが分かった。「プラグインがどの範囲で効くか（有効化スコープ）」と「プロジェクト設定をリポジトリに置くべきか」は、別の判断軸だった。
判断軸その1：有効化スコープ
| スコープ | 書く場所 | 効く範囲 |
|---|---|---|
| ユーザーレベル | /plugin install（自分の Claude Code 全体） | すべてのプロジェクト |
| プロジェクトレベル | そのリポジトリの .claude/settings.json | そのリポジトリだけ |
ユーザーレベルで一度入れれば、どのプロジェクトを開いてもレビューは効く。自分は同じマシンで全プロジェクトをいじっているので、これだけで目的は達する。
判断軸その2：プロジェクト設定が要る条件
そのうえで、プロジェクトの settings.json に有効化を書く意味が出てくるのは、次のどちらかのときだけだった。
- Claude Code の web 版を使う（手元のユーザー設定が乗らない環境で動かす）
- 他人とリポジトリを共有する（チームの全員に同じレビューを効かせたい）
自分はどちらにも当てはまらない。ローカルで、一人で、手元の Claude Code から触っているだけだ。だとすると、プロジェクトの settings.json に有効化を書くのは、ユーザーレベルの設定と同じことを二重に書くだけの冗長な行だった。
方針を確定させた
整理した結果、方針はこうなった。
- 有効化は ユーザーレベルのみ（
/plugin install）。プロジェクトのsettings.jsonは作らない。 - 代わりに、レビューの観点を伝える ガイダンスを2ファイルだけ用意する。
- 共通の観点 →
~/.claude/配下（全プロジェクトで参照する自分用） - このリポジトリ固有の観点 → プロジェクトの
.claude/配下
- 共通の観点 →
設定の置き場所と、ガイダンス（何を重点的に見てほしいか）の置き場所は分けて考える。有効化は一箇所で済ませ、リポジトリ固有の事情だけリポジトリ側に置く、という整理に落ち着いた。
リポジトリ固有のレビュー観点を反映させた
ガイダンスには、このリポジトリで特に見てほしい場所を書き込ませた。server/api/ 配下に、
- Stripe 決済まわり（
stripe/・purchase/） - 認証・admin 系のガード
があるのを把握していたので、ここをレビューの重点として観点に組み込んだ。決済と認可は、穴があったときの被害が一番大きい。汎用的なレビューに任せきりにせず、「このリポジトリではここを疑え」と先に渡しておく。
残作業の引き渡しと、後の確認
ここまでで、自分（ユーザー）が打つコマンドは2つだけ、という状態まで持っていって引き渡した。後でそのコマンドを実行し、プラグインが正しく入っていること、有効化フラグも立っていることを画面で確認した。想定どおり、ユーザーレベルの導入だけで動いた。
この日のハマり（プラグインとは無関係）
作業の途中、ツール呼び出しが崩れて「The model's tool call could not be parsed」というエラーが何度も出た。最初はプラグイン導入の副作用かと疑ったが、原因は別で、会話の履歴が膨らみすぎたことによる一時的な不具合だった。プラグインそのものの導入は問題なく完了している。長い作業はセッションを早めに区切るべき、という当たり前のことを、エラーの連発で思い出した格好だった。
学びメモ
- 一人ローカル運用なら、セキュリティレビュー・プラグインはユーザーレベルの有効化だけで全プロジェクトに効く。プロジェクトの
settings.jsonを書くのは冗長。 - プロジェクト設定に有効化を書く意味が出るのは、Claude Code web 版を使うときか、他人とリポジトリを共有するときだけ。
- 「有効化スコープ（どの範囲で効くか）」と「設定の置き場所（どこに書くか）」は別の判断軸。混同すると、要らない設定を二重に書く。
- 有効化は一箇所に集約し、リポジトリ固有の事情（決済・認証の重点観点）だけをリポジトリ側のガイダンスに置く。
- 「The model's tool call could not be parsed」は会話履歴の肥大が原因。作業の区切りでセッションを切る。