Claude Codeのセキュリティレビューとは｜自動検出で見つかるものと残る穴

開発チームから「AIにセキュリティを見させます」と相談されたとき、Claude Codeのセキュリティレビューで確かめられるのは、変更したコードの差分に入った脆弱性と、その直し方の推奨までです。

自動で検出しても穴は残ります。差分の中でも確信が届かないものは報告に出ず、そのうえで、レビューが報告しない範囲と、道具が知らない会社の決めごとは対象の外にあります。

この記事の要点は3つ

1. Claude Codeのセキュリティレビューは、変更したコードの差分を読み、インジェクションや認証のすり抜けなどの脆弱性を、攻撃の筋書きと直し方の推奨つきで挙げる機能です。入口は、頼んだときに動く /security-review、書いている間に動くプラグイン、プルリクエストで動く GitHub Action の3つです
2. 自動検出の後にも穴は残ります。差分の中でも確信が届かないものは報告に出ず、そのうえで範囲の外と会社の決めごとの2種類は対象の外です
3. 法人が人の確認を残すのは2か所です。変更が会社の決めごとに沿っているかを決めた側が確かめることと、指摘を踏まえて取り込むかを人が決めることです

Claude Codeのセキュリティレビューが挙げるのは差分の中で確信の高い実装の穴で、範囲の外と会社の決めごとは人の確認に残ります。

Claude Codeを社員に配る前に、使い方と確認の分担を研修でそろえる場合の実質負担の目安は、料金試算（助成金対応）で企業規模と人数から出せます。

料金を試算する（助成金対応） ▶

NDAの一次レビューでAIに自社の観点リストを渡し、最終判断を人に残している研修運営の側から書きます。対象は導入を承認する方で、開発チームが設定値を詰める手順は扱いません。

4層のうち最後の人の層で、判断と検収を誰が持つかの全体像は、Claude Code セキュリティの4層設計で扱っています。この記事はそのうち、AIが書いたコードを取り込む前の確認に絞り、自動のレビューで下がる部分と人に残る部分を分けます。

目次

1. Claude Codeのセキュリティレビューとは｜差分を読む機能
2. 自動検出で見つかるもの｜差分の中の、攻撃の筋が描ける穴
3. 残る穴1｜レビューが報告しない範囲にあるもの
4. 残る穴2｜道具が知らない会社の決めごと
5. 法人が人の確認を残す2か所｜決めごとと取り込み
6. この記事で解けないこと｜設定値・稼働中の検査・止める仕組み
7. Claude Codeのセキュリティレビューに関するよくある質問
8. Claude Codeのセキュリティレビュー｜総括表
9. あわせて読みたい
10. まとめ｜Claude Codeのセキュリティレビューとは

Claude Codeのセキュリティレビューとは｜差分を読む機能

Claude Codeのセキュリティレビューとは、コードの変更をセキュリティの観点で調べ、脆弱性とその直し方を挙げる機能です。Anthropicは2025年8月6日に、/security-review コマンドと GitHub Action を同時に公開しました。

公式のコマンド一覧は /security-review を、現在のブランチと origin の既定のブランチとの差分をレビューし、インジェクション・認証の問題・データの露出などのリスクを特定するコマンドと説明しています。ブランチは本流から分けた作業用の枝で、差分はそこで変えた部分のことです。

つまり、Claude Codeのセキュリティレビューは会社のシステム全体を検査する仕組みではなく、いま変えようとしているコードを見る仕組みです。

入口は3つ｜/security-review・security-guidance・GitHub Action

動くタイミングの違う入口が3つあります。

• /security-review（頼んだとき）：開発者がClaude Codeの中で打つと、その時点のブランチの差分を1回だけ調べます。origin という名前のリモートの登録が要ります
• security-guidance プラグイン（書いている間）：入れておくと自動で動きます。ファイルを編集するたびの文字列の照合、1回のやり取りが終わるたびの差分のレビュー、Claudeが実行するコミットやプッシュのたびの深いレビューの3段です。見つかった問題は、Claudeが同じセッションの中で直します
• GitHub Action（プルリクエストのとき）：anthropics/claude-code-security-review をリポジトリに組み込むと、プルリクエストが開いたときに動き、指摘を該当の行にコメントします。既定では、同じプルリクエストで1回動いたあとに足されたコミットは調べ直しません

このほかに、リポジトリ全体を複数のエージェントで深く調べる Claude Security プラグインと、Team・Enterprise のプランで試験提供中の Code Review があります。/code-review という似た名前のコマンドは正確性のバグを見るもので、本記事では扱いません。

Claude Codeのセキュリティレビューの3つの入口は、動くタイミングと出力の形が違います。

ファクトボックス｜Claude Codeのセキュリティレビューの基本情報

自動検出で見つかるもの｜差分の中の、攻撃の筋が描ける穴

Claude Codeのセキュリティレビューが自動検出で拾うのは、変更の差分に新しく入った実装の穴のうち、攻撃の筋書きまで説明できるものです。

/security-review が見る脆弱性の型は5つ

GitHub で公開されている /security-review の定義ファイルは、調べる脆弱性を5つの型に分けています。Claude Code に組み込まれたコマンドの文面がこのファイルと常に同じとは公式に示されていませんが、同じリポジトリの README は、組み込みのコマンドが GitHub Action と同じ分析の機能を持つと説明しています。

• 入力の検証：SQLやOSのコマンドなどへのインジェクション、ファイルの置き場所をさかのぼって読むパストラバーサル
• 認証と認可：認証のすり抜け、権限の昇格、セッションやトークンの扱いの不備、認可の判定の迂回
• 暗号と秘密の情報：コードに書き込まれたAPIキーやパスワード、弱い暗号、証明書の確認の迂回
• 実行とインジェクション：外から来たデータをそのまま実行する形、Webページに不正なスクリプトを埋め込めるクロスサイトスクリプティング
• データの露出：秘密の情報や個人情報のログへの出力、APIやデバッグ情報からの漏えい

Anthropicは発表の中で、社内の GitHub Action が、ローカルのHTTPサーバーを使う新機能に潜んでいた遠隔からのコード実行の脆弱性を取り込む前に指摘し、認証情報を扱うプロキシのSSRFも指摘した例を挙げています。SSRFは、サーバーを踏み台にして内部のシステムへ要求を送らせる攻撃です。提供元が示した例で、見つける割合を示す数字ではありません。

報告は「攻撃の筋書き」と「直し方の推奨」つきで出る

定義ファイルが求める報告の形は、ファイル名と行番号、重大度（高・中・低）、脆弱性の種類、説明、攻撃の筋書き、直し方の推奨です。攻撃の筋書きまで書かせるので、読んだ人は「なぜ危ないのか」を指摘の中で確かめられます。

/security-review の定義ファイルが承認なしで使えるようにしている道具は、git の履歴と差分を読むコマンド、ファイルを読む・探す道具、作業を別のエージェントに分けて渡す Task です。定義ファイルが求める仕事は報告を書くところまでで、コードの書き換えは含まれていません。 公式の発表は、見つかったあとに各問題の修正をClaude Codeに頼めると説明しており、直したコードを取り込むかは、その先の判断になります。

確信が80%に届かないものは、報告に出さない

定義ファイルは、実際に悪用できると80%を超えて確信できるものだけを挙げ、理論上の問題を見逃しても、誤検知で報告を埋めないほうがよいと指示しています。重大度の低いものも報告に出さないよう指示しています。報告は短くなる代わりに、確信が届かなかった穴は報告に出ません。

差分の中にあっても報告しない種類もあります。定義ファイルは、サービス停止を狙う攻撃（DoS）、アクセス回数の制限の欠如、監査ログが無いことを、報告の対象から外しています。

security-guidance の公式ページも、レビューのモデルは問題を見落とす可能性があるとして、完全なセキュリティの解決策ではなく、多層防御の1つの層として扱うよう書いています。Claude Codeのセキュリティレビューで指摘が出なかったことは、穴が無いことの証明にはなりません。

では、報告に出ない穴はどこに残るのか。1つ目は、レビューが報告しない範囲です。

残る穴1｜レビューが報告しない範囲にあるもの

Claude Codeのセキュリティレビューで残る穴の1つ目は、レビューが報告しない範囲にあるものです。報告の対象の外は、次の3つです。

• 既存のコードにある穴
• 古いライブラリの既知の脆弱性
• 動いているサービスと本番の設定

Claude Codeのセキュリティレビューが報告するのは変更で新しく入った穴で、既存のコード・古いライブラリ・動いているサービスは報告の対象の外に残ります。

既存のコードにある穴は、報告の対象の外

定義ファイルは、そのプルリクエストで新しく加わったセキュリティ上の影響だけに絞り、既存の問題には触れないよう指示しています。

公式は、既にあるコードの問題を探すときは、セッションの中でファイルやフォルダを指定して調べるよう頼むか、Claude Security プラグインを使うよう案内しています。このプラグインは、同じコードを2回調べても違う結果が出ることがあります。1回の全体検査で終わりにせず、版を記録しながら定期的に回す前提で考えます。

古いライブラリの既知の脆弱性は、別の道具が前提

Anthropicの発表と GitHub Action の README は、見る型に依存関係の脆弱性を挙げています。一方で、公開されている定義ファイルと、GitHub Action が誤検知を除くときの指示は、古いサードパーティのライブラリの脆弱性を、別に管理されるものとして報告しないよう決めています。見る型に挙がっていても、報告に出るとは限りません。

公式の security-guidance のページにある多層防御の表も、静的分析と依存関係のスキャナーをCIの段に置き、サプライチェーンの確認をその段の受け持ちにしています。依存ライブラリの既知の脆弱性は、Claude Codeのセキュリティレビューとは別の道具で確かめる前提で組みます。

動いているサービスと本番の設定は読まない

公式は、レビューが読むのは、実行中のサイトやデプロイされたサービスではなく、手元に取り出したソースコードだと書いています。クラウドの権限の設定、ファイルの公開範囲、サーバーの設定のように、コードの外で決まるものは範囲の外です。動いているシステムを外から試す検査は、コードを読むレビューとは別の工程です。

道具そのものの注意点｜社外のプルリクエストと、黙って動かない条件

ここからは報告の範囲ではなく、道具を置く場所の注意点です。GitHub Action の説明書きには、この Action はプロンプトインジェクション攻撃への対策が固められておらず、信頼できるプルリクエストのレビューだけに使うべきだと書かれています。プロンプトインジェクションは、読ませる文章に紛れ込ませた指示でAIを操る手口で、レビューされる側のコードに、その指示を書き込める余地があります。

同じ説明書きは、外部の協力者からのプルリクエストでは、管理者が中身を見て承認してからワークフローを動かす GitHub の設定を勧めています。社外の人がプルリクエストを出せるリポジトリで使うなら、この設定の有無を先に確かめます。手口と層の重ね方は、AIエージェント特有のセキュリティ｜プロンプトインジェクションと権限管理の実務で扱っています。

security-guidance は、git の管理下にないフォルダでは、やり取りごととコミットごとのレビューを知らせずに飛ばします。接続の方法やPythonの版によっては、モデルを呼ぶレビューが動かないこともあります。コミットのレビューは、Claudeが実行したコミットとプッシュだけが対象で、1時間に20回までです。

報告の対象の外は、別の道具と工程に割り当てて埋めていきます。残る穴の2つ目は、道具を足しても埋まらない場所にあります。

残る穴2｜道具が知らない会社の決めごと

Claude Codeのセキュリティレビューで残る穴の2つ目は、誰が何をしてよいかという権限の設計と、どんな値を受け付けるかという入力のルールです。どちらも会社が業務に合わせて決めるもので、コードの外にあります。

定義ファイルが示す調べ方は、リポジトリの中にある既存の安全な書き方を確かめ、新しいコードをそれと比べる手順です。手がかりにするのはリポジトリの中身で、会社が業務としてどう決めたかは、書かれていない限り道具には分かりません。

権限の設計が正しいかは、コードからは分からない

例で考えます。経費の精算で「部長は自分の部の申請だけを承認できる」と決めていたとします。承認を処理するサーバー側のコードで、権限の確認を飛ばすと、認可の判定の迂回として指摘の対象になります。

ところが、権限の確認そのものが「部長なら全社の申請を承認できる」と書かれていたらどうでしょう。コードは書かれたとおりに動いており、決めごととのずれを判断する手がかりは、コードの中にありません。

入力のルールも同じで、定義ファイルは、セキュリティ上重要でない項目の入力の検証が無いことは、影響が示されない限り報告しないと決めています。金額の上限や受け付けるファイルの種類のように、業務で決めた入力のルールが守られているかは、この除外に入りうる部分です。権限の設計と入力のルールが正しいかは、決めごとを持つ側が確かめる部分として残ります。

決めごとは文書で渡せるが、止める仕組みにはならない

会社の決めごとは、文書にしてレビューに渡せます。security-guidance プラグインは、リポジトリの .claude フォルダに決まった名前の手引きのファイルを置くと、書かれた脅威の想定と確認項目を、レビューの追加の文脈として読み込みます。公式の例は、「/admin から始まるURLの処理は、データベースを読む前に管理者の役割を確かめる」「顧客のIDを、INFO以上の水準のログに出さない」といった書き方です。

ただし公式は、この手引きのルールはレビュアーへの案内であって、決まった結果を必ず出す仕組みではなく、すべての違反を捕まえる保証も無いと書いています。止めたいなら、編集を止めるフックや、CIでの確認と組み合わせるよう案内しています。

GitHub Action にも独自の調べ方と誤検知の除外の指示を足す入力があり、/security-review も定義ファイルを複製して社内向けに書き換えられます。どれも見る観点を足す手段で、中身が正しいかを確かめるのは業務と権限を持つ人です。

DAIJOBUの社内でも、NDAの一次レビューには自社の観点リストを渡している

DAIJOBUの社内では、秘密保持契約（NDA）の一次レビューにClaude Codeを使っています。自社で決めた観点リスト19項目で条文のリスクを判定させ、引っかかった条文の修正案と、返信メールの下書きまでを作らせます。位置づけは弁護士の置き換えではなく一次チェックの即時化で、最終判断は人が持ちます。

扱う文書は契約で、セキュリティのレビューとは対象が別です。それでも形は同じです。観点を会社が持たなければ、AIは一般的な型でしか見られません。

指摘を採るかどうかを決める人がいなければ、どれだけ細かい報告も読まれずに流れます。次の章では、この2つを人の確認の場所として置き直します。

法人が人の確認を残す2か所｜決めごとと取り込み

法人がClaude Codeのセキュリティレビューを入れるとき、人の確認を残すのは、決めごとの確認と、取り込む前の判断の2か所です。2か所は本記事の整理で、公式の分類ではありません。

Claude Codeのセキュリティレビューは一次チェックとして挟み、人の確認は決めごとの確認と取り込む前の判断の2か所に残します。

この2か所で扱うのは、Claude Codeのリスクを4つに分けたときの、生成コードの品質のリスクです。4つのリスクの全体は、Claude Code リスクの4分類と、設定で下がるもので扱っています。

① 決めごとの確認｜権限と入力のルールは、決めた側が見る

1か所目は、変更によって、誰が何をできるようになり、どんな入力を受け付けるようになったかを、決めごとを持つ側が確かめる場所です。コードの行を読む必要はありません。変更を書いたのとは別のセッションか、開発チームの別の人に、この2点を業務の言葉で説明させ、その説明を決めごとと突き合わせます。

権限の設計は情報システムの担当、入力のルールはその業務の責任者というように、決めごとごとに見る人を決めておきます。

② 取り込む前の判断｜本流に入れるかは人が決める

2か所目は、自動のレビューの指摘を踏まえて、本流に取り込むかを決める場所です。公式によると、Code Review はプルリクエストを承認もブロックもせず、Claude Security プラグインの修正案は自動では当たらず、security-guidance も書き込みやコミットを止めません。

security-guidance では、見つかった問題をClaudeがその場で直し、コミットやプッシュまで進む使い方もあります。どの形でも、道具は本流への取り込みを決めません。決める人を置くのは会社の側です。

DAIJOBUの本業の品質保証には、作った本人に自分の成果物を採点させない「生成と評価の分離」という考え方があります。security-guidance の公式ページも、コードを書いたClaudeに自分を採点させず、別の呼び出しで新しい文脈から問題だけを探させると説明しています。人の側でも、変更を頼んだ本人とは別の人が取り込みを決める形にすると、同じ分離が保てます。

自動のレビューと人の確認の分担を研修で社員とそろえる場合の費用の目安は、料金試算（助成金対応）で企業規模と人数から確かめられます。

料金を試算する（助成金対応） ▶

この記事で解けないこと｜設定値・稼働中の検査・止める仕組み

次の3つは、この記事の外に残ります。

自社の確認項目と設定の中身

security-guidance に渡す確認項目や、/security-review の定義ファイルに足す指示の中身は、会社の権限の設計と入力のルールで変わります。人が決めることと道具に写すことの分け方は、残る穴2と人の確認の章で扱いました。

動いているシステムの検査

公開中のサイトやサーバーを外から試す検査、クラウドの設定の点検は、別の工程として計画します。

取り込みを止める仕組みの作り方

指摘が出たときに取り込みを止めるフックやCIの設定、プルリクエストの承認を必須にするリポジトリの設定は、使っている開発の基盤と運用で変わります。手順は開発チームと公式ドキュメントで確かめてください。

Claude Codeのセキュリティレビューに関するよくある質問

Q. Claude Codeのセキュリティレビューは、無料で使えますか

A. Claude Codeのセキュリティレビューは、どの入口も利用量か料金がかかり、無料ではありません。 /security-review と security-guidance は別の申し込みなしで使えますが、Claude Code の利用はプランの利用枠か API の利用料に数えられ、security-guidance のモデルを呼ぶレビューもその対象だと公式は書いています。GitHub Action は Claude API のキーで動き、Claude Security プラグインは有料プランが前提で、Code Review は Team・Enterprise のプランでプランの枠とは別に課金され、ゼロデータ保持を有効にした組織では使えません。

Q. 静的解析ツールや脆弱性診断の代わりになりますか

A. Claude Codeのセキュリティレビューは、静的解析ツールや脆弱性診断の代わりにはなりません。 公式は、Claude Security プラグインについても、静的分析や依存関係のスキャン、コードレビューと並べて使うもので、既存の道具を置き換えないと書いています。

Q. 指摘が出なければ、そのまま取り込んでよいですか

A. 指摘が出なかったことは、取り込んでよい理由の1つにしかなりません。 確信が80%に届かない問題は報告に出ず、GitHub Action は既定で、同じプルリクエストで1回動いたあとのコミットを調べ直しません。最初のレビューの後に足したコミットに指摘が無いのを確認済みとみなさず、決めごとの確認を済ませたうえで、変更を頼んだ本人以外が取り込みを決めます。

Claude Codeのセキュリティレビュー｜総括表

あわせて読みたい

関連記事Claude Codeのセキュリティは大丈夫？企業導入の不安と、事故を防ぐ設計記事を読む ▶ 関連記事Claude Codeのリスクは何？｜法人が先に塞ぐ4つと設定で下がるもの記事を読む ▶ 関連記事AIエージェント特有のセキュリティ｜プロンプトインジェクションと権限管理の実務記事を読む ▶

まとめ｜Claude Codeのセキュリティレビューとは

Claude Codeのセキュリティレビューは、いま変えようとしているコードの中から、攻撃の筋が描け、確信の高い実装の穴を先に拾う一次チェックです。確信の届かない穴は報告に出ず、レビューが報告しない範囲と、会社が決めた権限や入力のルール、取り込むかどうかの判断は、人の確認として残ります。

開発チームへの聞き取りから始められる一手を3つ挙げます。

1. 今日：開発チームに、/security-review・security-guidance・GitHub Action のどれを、どのリポジトリで使っているかを聞く。GitHub Action なら、コミットのたびに動かす設定かも聞く
2. 今週中：既存のコードの確認と、依存ライブラリの確認を、いまどの道具と工程で回しているかを1枚に書き出す
3. 今週中：権限の設計と入力のルールについて、変更を読む担当を決めごとごとに1人ずつ決める

最後に、社内で自分に問える1問を置きます。御社では、権限や入力の扱いが変わる変更を、その決めごとを持つ人が読んでから取り込んでいますか。

• Claude Codeのセキュリティレビューは、変更したコードの差分を読み、インジェクションや認証のすり抜けなどの脆弱性を、攻撃の筋書きと直し方の推奨つきで挙げる機能です。入口は、頼んだときに動く /security-review、書いている間に動くプラグイン、プルリクエストで動く GitHub Action の3つです
• 自動検出の後にも穴は残ります。差分の中でも確信が届かないものは報告に出ず、そのうえで範囲の外と会社の決めごとの2種類は対象の外です
• 法人が人の確認を残すのは2か所です。変更が会社の決めごとに沿っているかを決めた側が確かめることと、指摘を踏まえて取り込むかを人が決めることです

設定値は会社の業務と権限で変わるため、この記事では判断基準までにとどめます。

自動のレビューと人の確認の分担を研修で社員とそろえる場合の実質負担の目安は、料金試算（助成金対応）で確かめられます。

料金を試算する（助成金対応） ▶

自社の使い方に当てはめて相談したい場合は、初回無料体験講座（無料・30分）を申し込むもご利用ください。

無料体験講座を申し込む ▶

出典・注記

• Claude Code Docs「コマンド」 https://code.claude.com/docs/ja/commands （2026年9月25日参照）。/security-review の説明（現在のブランチと origin の既定のブランチとの差分・origin のリモートが必要）と、/code-review との違いによる
• Claude Code Docs「Claude がコードを書く際のセキュリティ問題をキャッチする」 https://code.claude.com/docs/ja/security-guidance （2026年9月25日参照）。security-guidance の3段のレビュー、見つかった問題を同じセッションの中で直すこと、git の管理下の外やサードパーティの接続・Python の版によってモデルを呼ぶレビューが飛ばされること、コミットのレビューの対象と上限、書いたClaudeに自分を採点させない独立性、書き込みやコミットを止めないこと、見落とす可能性と多層防御の1つの層としての扱い、手引きのファイルがガードレールではないこと、全プランで使えることと利用量、多層防御の表、/security-review が現在のブランチの変更だけを見ること、レビューが動いているサービスではなくソースコードを読むことによる
• Claude Code Docs「コードベースの脆弱性をスキャンする」（Claude Security プラグイン） https://code.claude.com/docs/ja/claude-security （2026年9月25日参照）。有料プランが前提であること、結果が回ごとに変わりうること、修正案が自動では当たらないこと、既存の道具を置き換えないことによる
• Claude Code Docs「Code Review」 https://code.claude.com/docs/ja/code-review （2026年9月25日参照）。Team・Enterprise のプランで試験提供中であること、ゼロデータ保持を有効にした組織では使えないこと、プルリクエストを承認もブロックもしないこと、プランに含まれる利用量とは別に課金されることによる
• Claude Code Docs「コストを効果的に管理する」 https://code.claude.com/docs/ja/costs （2026年9月25日参照）。Claude Code の利用が、サブスクリプションではプランの利用枠から、API ではトークンの消費で数えられることによる
• Anthropic「Automate security reviews with Claude Code」2025年8月6日 https://claude.com/blog/automate-security-reviews-with-claude-code （2026年9月25日参照）。公開日、見る脆弱性の型（依存関係の脆弱性を含む）、見つかったあとに修正を頼めること、Anthropic社内の2つの例による
• GitHub「anthropics/claude-code-security-review」 https://github.com/anthropics/claude-code-security-review （main・2026年2月11日のコミット 0c6a49f を2026年9月25日に参照）。README の、検出の種類にサプライチェーン（依存関係の脆弱性など）を挙げていること、プロンプトインジェクション攻撃への対策が固められていないこと・信頼できるプルリクエストだけに使うこと・外部の協力者のプルリクエストは承認してから動かす設定の推奨、独自の指示を足す入力、組み込みの /security-review が GitHub Action と同じ分析の機能を持つという説明、入力 run-every-commit の既定が false で同じプルリクエストで1回動いたあとは調べ直さないこと（README の入力表と action.yml）、定義ファイルを複製して書き換えられることによる
• 同リポジトリの /security-review の定義ファイル https://github.com/anthropics/claude-code-security-review/tree/main/.claude/commands （2025年8月6日の初版から変更なし・2026年9月25日参照）。見る脆弱性の5つの型、既存の問題に触れず新しく加わった影響だけを見ること、80%を超える確信の線、報告の形、使える道具、報告しないもの（DoS・アクセス回数の制限・古いサードパーティのライブラリの脆弱性・監査ログの欠如・影響の示されない入力の検証の欠如など）、既存の書き方と比べる調べ方による。GitHub Action の誤検知を除く指示（同リポジトリ claudecode/claude_api_client.py）にも、古いサードパーティのライブラリの脆弱性を報告しない決まりがある
• CHANGELOG https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md （2026年9月25日参照・最新版 2.1.282）
• 拾えるものと残る穴の分け方、人の確認を残す2か所、判断基準の表は、本記事の整理です。公式の分類ではありません。経費の精算の承認の例は、説明のための架空の例です
• 秘密保持契約の一次レビューでのClaude Codeの使い方と、品質保証の「生成と評価の分離」の考え方は、当社の自社情報です。個々の企業名は記載していません
• 本記事は、Claude Codeのセキュリティレビューの範囲と限界を、導入を承認する会社の側から示すもので、どの道具と確認を組み合わせても脆弱性が残らないことを保証するものではありません
• 本記事は2026年9月25日時点の情報にもとづきます。仕様・既定値・提供プランは変わるため、最新の公式ドキュメントでご確認ください

この記事について

DAIJOBUは、ソフトウェアテスト・品質保証と脆弱性診断を本業としながら、法人向けにClaude Code研修を提供している会社です。本記事は、Claude Codeのセキュリティレビューで自動検出できるものと人の確認に残るものを、公式ドキュメント・公開されている定義ファイル・提供元の発表で確かめられる事実と、当社の社内での使い方を分けて書いたものです。