結論：教育で止まらない5つの欠陥のうち、コードに現れる部分は今日から検査できる
2026年の夏に公表された情報流出・サイバー攻撃の7事例を、当事者の公表文で読み直すと、原因を公表した3件に「人為ミス」を挙げたものはなく、残る4件は調査中または未公表でした。Web システムや VPN の脆弱性、正規アカウントの悪用、委託先経由の連鎖、そして保持していたデータの範囲。いずれも、現場の注意力ではなく設計と運用の仕組みで決まる領域です。事例の整理は 2026年夏の情報流出を『5つの欠陥パターン』で読み直す にまとめました。
この記事はその続きです。5つの欠陥パターンのうち、コードと設定に現れるものを Claude Code で検査する手順を、2段構えで書きます。まず誰でも今すぐ試せる組み込みコマンド、次にフィールフロウが公開した plugin です。最後に、自社サイトの repo で実際に出た所見と、問診の答えとコードがずれていた2箇所を、そのまま載せます。
まず (a)：Claude Code 組み込みの /security-review
Claude Code には /security-review が組み込まれています。現在のブランチと origin の既定ブランチとの差分を対象に、インジェクション・認証・データ露出などの脆弱性になりうる箇所を洗い出すコマンドです（origin リモートが必要で、変更の無いブランチでは既存のコードは対象になりません）。導入は不要で、作業ブランチで打つだけなので、変更を入れるたびの最初の一歩としてはこれで十分です。
ただし、情報流出の5パターンに照らすと、見えないものがあります。
- 運用の事実が分からない。 夜間の監視体制、復旧テストの実施、パッチ適用の実際の日数、委託先に渡した権限は、コードに書かれていません。コードだけを読む検査は、ここを「不明」のまま通過します。
- 優先順位が付かない。 本人確認書類の画像を保管している会社と、問い合わせの氏名・メールだけを扱う会社では、同じ「削除ジョブが無い」でも重さが違います。
- 自己申告との食い違いが出ない。 「多要素認証（MFA）は有効です」という認識と、コードに MFA の実装が無い事実を並べて見せる設計ではありません。
そこで、問診と実測を突き合わせる形にしたのが次の plugin です。
そして (b)：ff-privacy-check — 問診と実測を突き合わせる
導入は2コマンド（公開 marketplace。アクセス権は不要）
claude plugin marketplace add feel-flow/ff-privacy-check
claude plugin install ff-privacy-check@ff-privacy-checkCodex CLI でも同じ marketplace を読めます（codex plugin marketplace add feel-flow/ff-privacy-check → codex plugin add ff-privacy-check@ff-privacy-check。問診は対話で1問ずつ進みます）。ソースは feel-flow/ff-privacy-check（Apache-2.0）で公開しています。
検査したい repo で Claude Code を開き、次を実行します。
/ff-privacy-check:privacy-check流れは5段
| 段 | 内容 | 人がすること |
|---|---|---|
| 段 0 | 下読み。言語・認証ライブラリ・ログ・CI・定期ジョブ・外部 API 呼び出しの場所だけ押さえる | なし |
| 段 1 | 問診。コードから読めないことを最大10問（保持期間、管理者の共有、夜間体制、復旧テスト、パッチ間隔、外部連携の権限など） | 答える。「分からない」も選べる |
| 段 1.5 | 確認。問診の答えと、コードから読めたことを1枚の表に並べ、食い違いを裁定する | 「問診の答えを直す / コードの読みが違う / そのまま進む」を選ぶ |
| 段 2 | 実測。grep と設定の読み取りだけを行い、対象コードには書き込まない（書くのはプロファイルと所見レポートだけ）。ビルド・テスト・外部へのネットワーク送信（npm audit などの照会を含む）は plugin 自身は行わない。ただし読み取ったコードは Claude Code の通常処理として Anthropic の API へ送られるので、機密性の高いリポジトリでは Claude Code 側のデータ取り扱い方針を先に確認する |
なし |
| 段 3 | 所見。パターン①〜⑤ごとに「問診の答え / 実測で見つかった事実 / 所見と優先度 / 直し方の方向」と、「この検査で見つからないもの」を出力 | 読んで、優先度「高」から着手する |
問診の答えは対象 repo の .privacy-check/profile.md に保存されるので、2回目以降は「前回の答えを使うか」の1問で済みます。所見レポートにはファイルパスと行番号が入るため、.privacy-check/ と privacy-check-report-*.md は .gitignore に入れることをおすすめします。
段 1.5 の確認表が核になる理由
自己申告だけの診断は、答えた人の認識を超えられません。コードだけの検査は、運用の事実を知りません。両方を1枚の表に並べて、食い違いを人が裁定する。この1手間で、所見の信頼度が変わります。
自社サイトで実際に出た確認表を、裁定列を省いて要約したものがこれです。
| パターン | 問診の答え | コードから読めたこと | 食い違い |
|---|---|---|---|
| ① 管理の隙 | 夜間はアラート通知のみ / 復旧テストは1年より前または未実施 | Sentry 設定あり（しきい値は repo に無い）。バックアップ定義は未検出 | なし |
| ② パッチ前侵入 | パッチ適用の間隔は決まっていない・分からない | Dependabot / Renovate 未検出、pnpm-lock あり、Vercel の git 連携デプロイ、CI は e2e.yml のみ | なし（要確認） |
| ③ アカウント奪取 | 外部 IdP（ID プロバイダ）/ SSO、MFA は分からない、管理者は個人ごと | 認証ライブラリ・MFA とも未検出（サイトにログイン機能なし） | なし（MFA は要確認） |
| ④ サプライチェーン | 外部連携1〜3件、権限の渡し方は分からない | 外部呼び出しは5系統（FFID / Facebook Graph API / Cloudflare Turnstile / Sentry / GA4〔Google アナリティクス〕）。Webhook 受信は未検出 | あり（件数） |
| ⑤ 過剰保持 | 氏名・連絡先と決済情報を扱う / 画像は保管しない / 保持期間は分からない | 問い合わせの氏名・メール等は外部の FFID へ送り、サイト側に保存しない。決済処理は未検出。画像保存・削除ジョブは未検出。.env の追跡なし |
あり（決済情報） |
食い違い2件は、どちらも「問診の答えを直す」で裁定しました。外部連携は数え漏れで、決済情報は別システムの話を混ぜていました。自己申告が実装より広くても狭くても、表にすると見えます。
もう1つ付け加えると、この記事の校正で、検査が拾えなかった外部呼び出しが2系統見つかりました。拾えた5系統は、段 0 の下読み（監視 SDK、API ルート、設定ファイルの読み取り）で押さえたものでした。段 2 の「fetch( と URL が1行に並ぶ呼び出し」を探す正規表現は、この repo では1件も一致していません。見落とした2系統は、定期ジョブの呼び出し先と scripts/ 配下の生成スクリプトという、下読みの対象からも漏れた場所にありました。「未検出」は「無い」ではない、の実例として残します（plugin 側の改善点は正規表現ではなく、下読みの範囲です）。
実行例：自社サイトの repo を検査した
対象はこのサイト（feelflow.net）の repo です。Astro の静的サイトで DB を持たず、問い合わせフォームと定期ジョブ用の API が数本あります。追跡ファイルは約1,650本。問診（質問のやり取り3回）と裁定を含めて、下読みから所見まで約12分でした。
結果は優先度「高」が0件、「中」が3件、「低」が2件（低の2件は MFA の確認と問い合わせデータの保持期間の確認で、いずれも要確認扱いです）。「分からない」と答えた項目のうち、保持期間、MFA、パッチ適用間隔は要確認として残りました。
「中」の3件はこうです。
- ① 検知としきい値が未確認。 Sentry は入っていて、送信前に個人情報を落とす実装もある。しかし、アラートのしきい値と通知先は Sentry 側の設定で repo には無く、問い合わせ API のレート制限はサイト側には見つからなかった（上流の FFID が返す制限応答を 429 で中継する実装はある）。夜間は「アラート通知のみ」なので、検知の設定が文書化されていないこと自体が所見になった。
- ② 依存関係の自動更新が無い。 lock ファイルはあり、Vercel の git 連携で再デプロイは速い。しかし Dependabot も Renovate も無く、パッチ適用の間隔を「決まっていない」と答えた。原因を公表した3件がいずれも脆弱性経由だったことを思えば、ここは今週中に直す。
- ④ 外部へ渡しているキーは、確認を終えています。 検査と校正を合わせると、外部への呼び出しは複数ありました。（対策済み）
良かった点も書いておきます。定期ジョブ用の API はシークレットの Bearer 認証で守られ、シークレット未設定なら500で止まり、不一致は401を返す fail-closed の実装でした。問い合わせの個人情報はサイト側に保存されず、ログへの出力は見つからず、エラー監視は既定の個人情報送信を切り、送信前に問い合わせ本文を落とす実装でした（エラーオブジェクト自体に個人情報が混じる経路は既知のリスクとして、コード内のコメントで別管理と注記されています）。ハードコードされた鍵は見つからず、.env も追跡されていませんでした。
正直に言えば、「高」が無かったのは、このサイトが個人情報をほとんど持たない設計だからです。会員機能や決済を持つシステムなら、同じ検査で「高」が出る可能性は十分にあります。
この検査で見つからないもの
所見レポートの終盤には、次の節が毎回そのまま出力されます。検査の限界を読者ではなく出力側が宣言する設計です。
- ペネトレーションテストや動的検査で初めて分かる脆弱性（この検査はコードと設定の静的な読み取りだけを行う）
- 運用手順が実際に守られているか（復旧テスト・権限棚卸し・退職者アカウントの停止などは問診の自己申告に依る）
- インフラ側の設定（クラウドの IAM・ネットワーク・WAF・バックアップ先のオブジェクトロックなど、repo の外にあるもの）
- 権限の実運用（誰が本番 DB に触れるか、管理者アカウントを何人が共有しているか）
- 既知脆弱性（CVE）との照合（外部送信を伴うため実行しない。
pnpm audit/npm audit/pip-audit等を自分で実行すること） - コードに現れない委託先・外部サービスの管理状況
「検査すれば安心」ではありません。検査で見える範囲を先に片づけ、見えない範囲を人の仕事として残す。その切り分けのための道具です。
次の一歩
- 目安は15分です（自社の repo、約1,650ファイルでは約12分でした）。まず自社の repo で
/ff-privacy-check:privacy-checkを実行し、段 1.5 の表で自分の認識とコードのずれを見てください。 - 「分からない」と答えた項目は、そのまま確認リストになります。確認して profile.md を更新し、再実行すると問診は1問で済みます。
- 四半期に1回の定期実行を、リリース前の点検に組み込んでください。
- 事例の読み方は 2026年夏の情報流出を『5つの欠陥パターン』で読み直す へ。経営層向けに、教育で防げる範囲と防げない範囲を切り分けています。
岡崎太としての見解
自社の repo を検査して「高」が出なかったとき、最初に感じたのは安心ではなく、「このサイトは個人情報をほとんど持たないから」という留保でした。検査が見つけられなかったことを、検査が正しかったことと混同しない。それがこの道具を公開する側の責任だと考えています。
生成AIのコーディングエージェントは、コードを読む速さでは人に勝ります。しかし、運用の事実を知っているのは人だけです。問診と実測を突き合わせる設計にしたのは、どちらか一方に寄せた診断が、必ず片方の盲点を抱えるからです。