npm audit を定期的に回していれば安全——僕もそう思っていました。でも npm audit が見つけるのは「依存パッケージの既知の脆弱性」だけです。自分が書いたコードのロジック上の穴は対象外。
2026年2月、AnthropicがClaude Code Securityを発表しました。AIがコードの文脈を理解して脆弱性を検出する、という新しいアプローチです。ただし現時点ではEnterprise/Teamプラン向けのリサーチプレビューで、個人ユーザーはまだ使えません。
じゃあ個人開発者は何もできないのか？ そんなことはなくて、Claude Code（通常のCLIツール）にセキュリティレビューを依頼することは今すぐできます。専用のSecurity機能ではないけれど、Opus 4.6がコード全体を読んでレビューしてくれる。
実際に自分のプロジェクトで試してみました。npm audit では11件の脆弱性が出て、Claude Codeのレビューではさらに5件の改善ポイントが見つかった。基本的な対策は全て実装済みだったのに、その上で「もう一段詰められる箇所」をAIが指摘してきた。
僕は福祉事業のIT全般をCTOとして担当しつつ、個人でMac mini M4 Proを使ったAIエージェントシステム（TypeScriptモノレポ、24時間稼働）を運用しています。福祉系のシステムでは利用者の個人情報を扱うので、セキュリティは他人事ではありません。
この記事では、Claude Code Securityの概要を紹介した上で、個人ユーザーが今すぐできる「Claude Codeによるセキュリティレビュー」を実際にやってみた結果を全部公開します。
Claude Code Security とは — 今使えるのか？
製品としてのClaude Code Security
2026年2月、AnthropicはClaude Code Securityを発表しました。従来のSAST（静的アプリケーションセキュリティテスト）がルールベースでパターンマッチするのに対し、AIがコードの文脈を理解して脆弱性を検出する、というのが売りです。
公式発表によると、既存のセキュリティツールが見逃していた500件超の未発見脆弱性を検出。GitHub Actionとしてもオープンソース公開されており、PRごとの自動スキャンも可能です。
ただし、現時点では一般ユーザーは使えない
ここが重要なポイントです。Claude Code SecurityはEnterprise/Teamプラン向けのリサーチプレビューとして提供されています。OSSメンテナーには優先アクセスが付与されていますが、個人のClaude MAXユーザーが専用のSecurity機能を使うことはまだできません。
個人ユーザーが今すぐできること
専用機能は使えなくても、Claude Code（通常のCLIセッション）に「セキュリティレビューして」とプロンプトを投げることは今すぐできます。
Claude Code Security ほどの専門的なスキャンではありませんが、Opus 4.6がプロジェクト全体のコードを読み込んで、セキュリティ上の改善ポイントを指摘してくれます。npm audit とは全く違う角度からのレビューが得られる。
「公式のSecurity機能が使えるようになるまで待つ」のも一つの選択肢ですが、今あるツールで今すぐチェックする方が実践的です。実際にやってみたので、その結果を共有します。
対象プロジェクト：masu-agent の構成
僕が試したのは「masu-agent」という自作のAIエージェントシステムです。
- TypeScriptモノレポ（npm workspaces）
- 構成: Discord Bot + Webダッシュボード（React + Express）+ 自動化オーケストレーター + MCPサーバー
- データベース: SQLite（better-sqlite3）
- 外部連携: Discord API, Google Calendar, GA4, Claude Agent SDK
- 稼働環境: Mac mini M4 Pro で24時間常駐
パッケージ数は5つ、ファイル数は100以上。個人開発としてはそこそこの規模です。
まず npm audit を実行した結果
最初に npm audit を実行しました。結果は11件の脆弱性。
検出された脆弱性の内訳
high（4件）:
- minimatch < 10.2.1 — ReDoS（正規表現による拒否攻撃）。glob や rimraf 経由で入ってきている間接依存
- その他3件もReDoSやSSRF関連
moderate（5件）:
- ajv < 6.14.0 — ReDoS。schema-utils 経由
- hono — 認証タイミング攻撃。
basicAuth/bearerAuthミドルウェアの比較処理が定数時間ではない。Dashboard API で使用中 - 他3件
low（2件）:
- esbuild <= 0.24.2 — 開発サーバーの脆弱性。Remotion（MV生成）経由の間接依存
- webpack 5.49.0〜5.104.0 — SSRF。これもRemotion経由
11件のうち、直接依存で自分が修正できるのは hono くらい。残りはほとんどが間接依存で、上流のパッケージがアップデートしないと解消されません。
ここが npm audit の限界です。 「脆弱性があります」と教えてくれるけど、間接依存だと自分では直せない。そして何より、自分が書いたコードの問題は一切見てくれない。
次に Claude Code にセキュリティレビューを依頼した
npm audit の次に、Claude Code の通常セッションで以下のプロンプトを投げました。繰り返しますが、これはClaude Code Security（Enterprise向け）ではなく、普通のClaude Codeです。
このプロジェクトのセキュリティ脆弱性をレビューして。
特に認証・認可、環境変数の扱い、SQLインジェクション、
外部APIへのデータ送信、権限設定に注目して。
Claude Code はプロジェクト全体のファイルを読み込んで、5〜10分かけてレビュー結果を返してきました。
問題なしと判定されたもの（安心できた部分）
SQLインジェクション対策: Database クラスは全てのクエリで better-sqlite3 のパラメータバインディングを使用していました。db.prepare('SELECT * FROM users WHERE id = ?').get(id) のような書き方が徹底されていて、文字列結合でSQLを組み立てている箇所はゼロ。これは安全。
MCPサーバーのトランスポート: stdio（標準入出力）で通信しているため、ネットワークに公開されていない。外部からMCPサーバーに直接アクセスする経路が存在しない。
入力バリデーション: Dashboard API のエンドポイントはZodスキーマでリクエストボディをバリデーションしていました。型が合わないリクエストは弾かれる。
レート制限: 読み取り120req/min、書き込み30req/min の制限が設定済み。
Discord Bot の権限管理: ツール権限を SAFE_TOOLS（読み取り系）と ALL_TOOLS（書き込み含む）に分離し、危険な操作にはボタン確認を挟む実装。
これらは自分で意識して設計した部分なので「問題なし」は予想通り。でも、AIに「問題ない」と言われると安心感が違います。「見落としてないかな」という不安が消える。
AIが指摘した改善ポイント（5件）
ここからが本題。5件とも、セキュリティ設計を「していなかった」のではなく「やっていたが、もう一段詰められる」部分です。
1. 開発用デバッグ設定の本番環境への混入
Claude Code の権限設定ファイルに、開発時のトラブルシュートで一時的に追加したデバッグ用の許可が残っていました。開発中に設定を変更して動作確認し、そのまま次のタスクに移った——よくある話です。CI/CDパイプラインで設定ファイルの差分チェックを入れていれば防げた問題。個人開発だと設定の棚卸しが後回しになりがちだと再認識しました。
2. エラーハンドリングの多層防御漏れ
本番環境ではエラーメッセージをマスクする実装を入れていました（toClientErrorMessage() で本番は 'internal server error' のみ返す）。ただし、外部APIとの通信エラー時のログ出力で、レスポンスボディをそのまま console.warn に渡している箇所があった。本体のエラーハンドリングは対策済みなのに、ログ出力経由で情報が漏れるエッジケース。多層防御を意識していても全レイヤーを網羅するのは人力では限界がある部分です。
3. 環境変数フォールバックの防御的設計
CORS設定で、環境変数 CORS_ORIGIN が未設定の場合に開発用のlocalhost許可にフォールバックする実装にしていました。開発体験としては便利だけど、Claude Code は「本番では環境変数が未設定ならエラーにすべき」と指摘。フェイルセーフの原則に従えば、未設定時は許可ゼロが正解。「便利なデフォルト値 vs 安全なデフォルト値」の設計判断をAIが正しく指摘してきたケースです。
4. 認証情報ファイルの権限強化
Google Analytics連携用のService Account JSONは .gitignore に含めてGit管理外にしていました。ただ、ファイルのパーミッションがOSデフォルト（644）のまま。macOS Keychainへの移行か、少なくとも chmod 600 で所有者のみ読み取り可にすべき、という指摘。.gitignore に入れるだけで安心しがちだけど、ファイルシステム上のアクセス制御まで意識するのが本来の多層防御です。
5. ログディレクトリのパーミッション明示化
監査ログディレクトリを mkdirSync で作成する際に、パーミッションを明示指定していなかった。mode: 0o700 を明示すべきという指摘。実害のリスクは低いですが、防御的プログラミングの観点では正しい。
率直な感想
5件とも、SQLインジェクション対策、Zodバリデーション、レート制限、権限分離といった基本的な対策は全て実装した上で、その先の「多層防御の網羅性」をAIが指摘してきた形です。
個人開発で一番怖いのは「コードレビューの目がない」こと。自分で書いて自分でレビューすると、どうしても「意図通りに動いているから大丈夫」というバイアスがかかる。AIはそのバイアスなしに、設計の細部を指摘してくれる。チームにセキュリティレビュアーがいない環境では、これは本当に価値がある。
npm audit と Claude Code レビューの比較
ここまでの結果を比較すると、こうなります。なお、これはClaude Code Security（Enterprise向け）ではなく、通常のClaude Codeセッションでレビューを依頼した結果です。専用Security機能が使えるようになれば、さらに精度が上がることが期待できます。
| 観点 | npm audit | Claude Code でレビュー依頼 |
|---|---|---|
| 検出対象 | 依存パッケージの既知脆弱性 | 自分が書いたコードの設計改善点 |
| 所要時間 | 数秒 | 5〜10分 |
| コスト | 無料 | Claude MAX サブスクリプション内 |
| 検出件数（今回） | 11件（依存関係の脆弱性） | 5件（多層防御の改善ポイント） |
| 重要な発見 | hono のタイミング攻撃 | エラーログ経由の情報漏洩リスク |
| 修正可能性 | 間接依存は自分で直せない | 全て自分で即修正可能 |
| 誤検知 | ほぼなし | 今回はなし |
補完関係にある、というのが結論です。どちらか一方では足りない。
npm audit は既知の脆弱性データベース（CVE）と依存パッケージを突合するだけ。高速で確実だけど、自分が書いたコードは見ない。
Claude Code のレビューは、コード全体を読んで文脈を理解した上で問題を指摘してくれる。ただし、既知CVEのような網羅的なチェックは得意ではない。
両方やる。これが現実的な答えです。
Claude Code レビューの限界 — 過信すると危ない部分
実際に使ってみて感じた限界も正直に書きます。
1. 専用ツールではない
繰り返しになりますが、今回やったのはClaude Code（通常のCLI）にレビューを依頼しただけです。Claude Code Security（Enterprise向け）のような、セキュリティに特化したスキャンロジックが動いているわけではない。あくまで汎用AIが「セキュリティの観点で見て」という指示に応えた結果です。逆に言えば、専用機能が一般公開されたときには、もっと精度の高い結果が期待できます。
2. 検出できるのは「AIが理解できる範囲」
Claude Code はTypeScriptのコードは非常によく理解しています。でも、OS固有の挙動（macOS の launchd 設定とか、ファイルシステムのパーミッションモデルとか）になると、指摘の精度が落ちる印象があります。
今回のレビューでも、tmux セッション管理周りのセキュリティ（プロセス間通信の権限）には言及がなかった。ここは自分で考える必要がある領域です。
3. 「問題なし」は「安全」を意味しない
「SQLインジェクション対策は問題ありません」と言われて安心したけど、これは「AIが見た範囲では問題がなかった」という意味であって、「絶対に安全」ではない。
セキュリティの世界では「問題が見つからなかった」と「問題がない」は全く違うことです。AIレビューの結果を鵜呑みにして「うちは大丈夫」と思い込むのは危険。
導入すべきかの判断基準
全てのプロジェクトに必要か？と聞かれたら、正直「場合による」です。
個人の学習プロジェクト
npm audit だけで十分。コードレビューは学習の一環として自分でやるほうが力がつく。
個人開発の公開サービス
Claude Code でレビュー依頼する価値あり。特にユーザーデータを扱う場合は、自分が書いたコードの穴をAIに見てもらう意味がある。僕のmasu-agentがまさにこのケース。Claude Code Security の一般公開を待たなくても、今すぐできる。
クライアント案件・業務システム
積極的に活用すべき。Claude Code Security が使えるEnterprise/Teamプランなら専用機能を、そうでなければ通常のClaude Codeでレビュー依頼。納品物のセキュリティ品質は信頼に直結する。
福祉・医療・教育系のシステム
強く推奨。利用者の個人情報（障害のある方、子ども、高齢者）を扱うシステムで脆弱性があったら、事業所の信頼が一瞬で消えます。技術がわかる人間が「ここは大丈夫」と確認できる手段を持っておくべき。
セキュリティ対策を放置すると何が起きるか
「うちは個人開発だし、攻撃なんて来ないでしょ」——これが一番危ない思い込みです。
僕のmasu-agentは24時間稼働しています。Discord Bot はインターネットに接続しているし、Dashboard APIもTailscale経由とはいえアクセス可能。もし認証の設定が甘ければ、外部からDBの中身を全部抜かれる可能性がある。
npm audit だけ回して「脆弱性ゼロ」を確認して安心していたら、自分が書いたコードの穴は見えないまま。それは「玄関の鍵は確認したけど、窓は開けっぱなし」と同じです。
この記事を書いている理由
最初にこの記事を書いたとき、正直なところAnthropicの公式発表を日本語で要約しただけの内容でした。Claude Code Securityの機能一覧、従来SASTとの比較表、GitHub Actionsの設定例——全部公式ドキュメントに書いてある情報。
「これ、自分が書く意味あるか？」と思い直して、実際にmasu-agentでClaude Code にセキュリティレビューを依頼してみました。
やってみて初めてわかったのは、専用のSecurity機能がなくても、通常のClaude Codeで十分に有用なレビューが得られるということ。5件の改善ポイントが出てきたときの「なるほど、ここまで見るのか」という感覚。npm audit で11件出たけど間接依存ばかりで自分では直せない歯がゆさ。「問題なし」と出た部分への安心感と、同時に「本当に大丈夫かな」という健全な疑い。
こういうリアルな感触は、やった人にしか書けない。だからリライトしました。
まとめ — セキュリティチェックは「重ねがけ」が正解
AIによるセキュリティレビューは npm audit の代替ではなく、補完です。
今日からできることは3つ:
npm auditを今すぐ実行する — 依存パッケージの既知脆弱性をまず確認- Claude Code で「セキュリティレビューして」と投げてみる — 専用のSecurity機能がなくても、通常セッションで自分が書いたコードの穴をAIに見てもらえる
- 見つかった問題を1つ直す — 全部を一度に直す必要はない。重要度が高いものから
Claude Code Security の一般公開を待つ必要はありません。今あるツールで、今すぐチェックできる。
セキュリティ対策は地味な作業です。何も起きないことが最大の成果。でも、何も起きなかったのは「対策していたから」であって、「運が良かっただけ」かもしれない。
React Server Components の脆弱性対策について詳しく知りたい方は、こちらも参考にしてください: React2Shell脆弱性の対策ガイド｜CVSSスコア10.0への実践的防御法
