セキュリティ専門家 相談資料

AI（Claude Code）で開発したシステム群のセキュリティ外注相談
作成日: 2026年2月26日 ／ 相談予定日: 2026年2月27日
作成者: AI（Claude Code）による自動分析 ／ 依頼者: 川口様

目次

  1. 背景と相談の目的
  2. システム全体像
  3. これまでのセキュリティ対策（AI実施済み）
  4. AIでは対処困難な領域（本日の相談事項）
  5. 相談事項 詳細
  6. 予算・スケジュール感
  7. ご質問事項

1. 背景と相談の目的

開発体制

これまでの対応

相談の核心:
AIはソースコードの静的解析・修正は得意だが、以下はAIだけでは対処できない。
これらを 外注したい。具体的に何をどこまで依頼すべきかご相談したい。

2. システム全体像

21
プロジェクト総数
12
医療・個人情報関連
6
サーバーにデータ永続化
1
決済機能あり

リスクレベル別プロジェクト分類

リスク プロジェクト 技術構成 データ保管 特記事項
最高 endai-system
（学会管理SaaS）		 Next.js / Vercel
Supabase (PostgreSQL)
Stripe決済
Resend / web-push		 Supabase
（クラウド）		 唯一の決済統合システム。
ユーザー情報・参加費・領収書をサーバー保存。
マルチテナント（複数学会）。
RBAC（admin/reviewer/speaker等）。
最高 visitcare
（訪問看護・介護管理）		 Next.js
Firebase Auth
Firestore		 Firestore
（クラウド）		 医療データ永続化。
利用者の氏名・要介護度・バイタル・訪問記録。
個人情報保護法＋医療ガイダンス対象。
高 conference-app
（学会Web受付）		 Next.js / Vercel
Supabase (PostgreSQL)
Redis		 Supabase
（クラウド）		 参加者情報・QRコード管理。
JWTベース認証。
高 rehab_monitoring
（リハビリ歩数管理）		 Flutter
Firebase Auth
Firestore
HealthKit / Health Connect		 Firestore
（クラウド）		 患者の歩数データ・目標値をサーバー保存。
セラピスト-患者の紐付け管理。
高 bento_order_web
（弁当注文）		 Firebase Auth
Firestore
CF Workers
GAS		 Firestore
（クラウド）		 注文者情報・注文履歴。
LINE連携。
高 hirakata-pt-hp
（PT事業所HP + 管理画面）		 CF Workers / Pages
D1 (SQLite)		 D1
（エッジDB）		 管理画面あり（独自認証PBKDF2済）。
お問い合わせフォーム。
中 productivity-health-survey
drawing-cognitive-test
dementia-cf-suite
rokomo-check-app
updrs-tracker		 各種
(CF Workers, Vercel等)		 Supabase / Firestore
/ D1		 健康チェック系アプリ群。
一部はサーバーにデータ保存。
匿名化・結果表示のみのものも含む。
低 dementia-risk-check
dementia-risk-suite
dysphagia-risk-check
suita-stroke-risk
rehab-fee-calculator
kawaguchi-ns-hp
full-lafu-corporate		 静的HTML / CF Pages なし
（クライアント完結）		 サーバー保存なし。
計算・表示のみ。

3. これまでのセキュリティ対策（AI実施済み）

以下はすべてAI（Claude Code）によるコードレベルの対策です。
SEC要件充足率: 94% ／ 修正済み脆弱性: 110件以上

実施済み対策一覧

カテゴリ 対策内容 対象 状態
入力バリデーション SQLインジェクション対策（パラメータバインド化）
XSS対策（innerHTML排除、DOMPurify導入）
iLIKEワイルドカードエスケープ		 全プロジェクト 済
認証・認可 requireRole()認可ヘルパー作成（35関数に適用）
Server Actions全関数に認証チェック追加
DEV_BYPASS_AUTH本番防止
RBAC実装		 endai-system
visitcare
conference-app		 済
暗号化 SHA-256+固定ソルト → PBKDF2(100,000回)+ランダムソルト
レガシーハッシュ自動移行機構		 hirakata-pt-hp 済
シークレット管理 Firebase秘密鍵・OAuthシークレットの環境変数化
ハードコード排除
.env.exampleからの実キー除去		 全プロジェクト 済
セキュリティヘッダー CSP精緻化（unsafe-eval除去、base-uri/form-action追加）
X-Frame-Options / X-Content-Type-Options等		 全プロジェクト 済
API保護 認証なしエンドポイントへの認証追加
IDOR修正（QRコードAPI等）
CORS設定の厳格化		 endai-system
conference-app		 済
Firestoreルール デフォルトdeny化
7コレクションへのルール追加
ユーザー本人のみアクセス可に制限		 visitcare
rehab_monitoring		 済
決済セキュリティ Stripe Webhook冪等性チェック
Webhook署名検証		 endai-system 済
ログ・監査 構造化セキュリティログ基盤導入
PIIのconsole.log出力排除		 endai-system 済
CI/CD npm audit GitHub Actions統合
Dependabot設定		 endai-system 済

修正済み脆弱性の内訳

重大度件数残存
CRITICAL8件修正0件
HIGH36件修正約5件
MEDIUM38件修正約7件
LOW25件修正約8件

4. AIでは対処困難な領域（本日の相談事項）

以下の7領域は、ソースコードの修正だけでは解決できない「インフラ・運用・法務・実環境」の問題です。
これらを外注したい。
# 領域 AIでできないこと 優先度 対象
1 ペネトレーションテスト 実環境への攻撃シミュレーション。
AIはコードの静的解析はできるが、デプロイ済みシステムに対する動的テスト（認証バイパス、セッション管理、レースコンディション等）は実行不能。		 必須 endai-system
visitcare
2 Git履歴のシークレット除去
+ ローテーション		 過去のコミット履歴に残るFirebase秘密鍵・OAuthシークレットの完全削除（git filter-branch / BFG）。
削除後の各サービスでのキー再発行・再設定。
AIは「何をすべきか」は分かるが、本番環境のサービスコンソールでの操作は不能。		 必須 全プロジェクト
3 医療データの法的コンプライアンス 個人情報保護法・医療介護ガイダンスへの適合性判断。
監査ログの法的要件充足確認。
これは法務・コンプライアンスの専門知識が必要。		 必須 visitcare
rehab_monitoring
4 Supabase RLSポリシー設計レビュー RLS（Row Level Security）が正しく全テーブルに適用されているか、ポリシーの論理的な抜け穴がないかの第三者レビュー。
AIはポリシーを書けるが、マルチテナント環境での網羅的検証は人間の目が必要。		 必須 endai-system
conference-app
5 Stripe決済フローの脆弱性評価 決済フロー全体（価格改ざん、二重請求、返金悪用等）の実環境テスト。
PCI DSS準拠の確認。
Stripe Webhookの本番環境での挙動検証。		 強く推奨 endai-system
6 インシデント対応計画の策定 情報漏洩時の対応フロー、連絡体制、個人情報保護委員会への報告手順。
医療法人としての組織的対応が必要。		 強く推奨 組織全体
7 WAF / DDoS対策 / レート制限の本格設計 現在のレート制限はin-memory（サーバーレスでは無効）。
Cloudflare WAF / Redis / KVベースのレート制限への移行設計。
DDoS対策の構成。		 推奨 全デプロイ済み
プロジェクト

5. 相談事項 詳細

5-1. ペネトレーションテスト 必須

対象システム

システム URL 技術構成 テスト観点
endai-system https://endai-system.vercel.app/ Next.js + Supabase + Stripe 認証バイパス、RBAC穴、IDOR、決済改ざん、
Server Actions権限、RLSバイパス
visitcare （デプロイ先確認中） Next.js + Firebase 医療データ漏洩、Firestoreルールバイパス、
認証フロー、セッション管理
conference-app （Vercel） Next.js + Supabase + Redis JWT偽造、QRコード不正利用、
参加者データ漏洩

AIが対策済みだが検証が必要な点

  • requireRole()が全Server Actions（約35関数）に正しく適用されているか
  • Supabase RLSが全テーブルで有効か（AIはSQLを書いたが、本番DBでの確認は不能）
  • Stripe Webhookの冪等性が実際の二重送信で正しく動作するか
  • CSPヘッダーが本番環境で正しく適用されているか

お聞きしたいこと

  • この規模（3システム、Next.js + Supabase/Firebase）のペネトレーションテストの相場感は？
  • endai-systemのみ先行実施とし、他は後日にすることは可能か？
  • テスト結果の報告形式は？（修正指示がコードレベルで来ればAIで対応可能）

5-2. Git履歴のシークレット除去 + ローテーション 必須

経緯

開発初期に以下のシークレットがコードにハードコードされていた時期がある。現在はすべて環境変数化済みだが、Git履歴には残っている。

影響を受けるシークレット（推定）

種類プロジェクト対応
Firebase サービスアカウント秘密鍵bento_order_web要ローテーション
Google OAuth クライアントシークレットbento_order_web要ローテーション
Supabase サービスロールキーendai-system, conference-app要確認
Stripe シークレットキーendai-system要確認
管理者パスワード（平文）hirakata-pt-hpPBKDF2移行済（旧パスワード要変更）
E2Eテスト用パスワード複数テストコードから除去済

必要な作業

  1. Git履歴スキャン: BFG Repo-Cleaner / git filter-repo で全リポジトリを走査
  2. シークレット除去: 該当コミットからシークレットを削除
  3. キーローテーション: 各サービスコンソールで新キーを発行し、環境変数を更新
  4. force push: 書き換えた履歴をリモートに反映

お聞きしたいこと

  • リポジトリ数は約15個。一括で対応いただける業者はあるか？
  • GitHubのプライベートリポジトリだが、一時的にアクセス権を付与する形で良いか？
  • ローテーション後のデプロイ作業（環境変数更新 → 再デプロイ）はこちらでも対応可能

5-3. 医療データの法的コンプライアンス 必須

対象システムと取り扱いデータ

システム保存データ保存先
visitcare 利用者氏名、要介護度、バイタルサイン、
訪問記録、サービス実施内容		 Google Firestore
（リージョン: 確認必要）
rehab_monitoring 患者氏名、歩数データ、リハビリ目標値、
セラピスト-患者紐付け		 Google Firestore

現在の技術的対策

  • Firebase Authentication による認証必須化
  • Firestoreセキュリティルール: ユーザー本人のデータのみアクセス可
  • セラピスト: 担当患者のデータのみ読み取り可
  • PII の console.log 出力排除済み

確認が必要な法的要件

  • 個人情報保護法: 医療法人としての安全管理措置（組織的/人的/物理的/技術的）の充足
  • 医療・介護関係事業者における個人情報の適切な取扱いのためのガイダンス（厚労省）への適合
  • 監査ログの法的要件: visitcareの医療データアクセスログは何年保存が必要か？
  • データ所在地: Firestoreのリージョンが国内であるべきか？
  • 利用者同意: アプリ内の同意取得フローは法的に十分か？

お聞きしたいこと

  • 医療データに関しては、セキュリティ専門家と法務（弁護士等）の両方が必要か？
  • visitcareのFirestoreリージョン選定について推奨はあるか？
  • 医療法人向けシステムとして最低限クリアすべきチェックリストはあるか？

5-4. Supabase RLSポリシー設計レビュー 必須

対象

システムテーブル数（推定）マルチテナント認証方式
endai-system15-20はい（学会単位）Supabase Auth
conference-app5-10いいえJWT

現状

  • AIがRLSポリシーを記述・適用済み
  • しかし、マルチテナント環境でのテナント横断アクセスの防止は、ポリシーの論理的な正しさを第三者が確認すべき
  • AIの生成したRLSポリシーのSQLは提供可能

お聞きしたいこと

  • SupabaseのRLSレビューを専門にしている事業者・個人はいるか？
  • ペネトレーションテストの一部として実施可能か？

5-5. Stripe決済フローの脆弱性評価 強く推奨

現在の決済フロー

  1. ユーザーが学会参加登録
  2. サーバーサイドでStripe Checkout Session作成（金額はサーバーで決定）
  3. Stripe決済ページにリダイレクト
  4. Webhook で payment_intent.succeeded を受信
  5. Supabase上の参加者ステータスを「支払済」に更新

AI実装済みの対策

  • 金額はクライアントからではなくサーバーサイドで決定
  • Webhook署名検証（stripe-signature ヘッダー）
  • 冪等性チェック（同一イベントの二重処理防止）

検証が必要な点

  • Checkout Session作成時のパラメータ改ざん可能性
  • Webhookの再送・遅延時の整合性
  • 返金フローの悪用可能性
  • PCI DSS SAQ-A準拠の確認

5-6. インシデント対応計画の策定 強く推奨

現状

セキュリティインシデント発生時の対応計画が未策定。医療法人として、個人情報漏洩時の法的義務（個人情報保護委員会への報告等）への対応フローが必要。

必要な計画内容

  • インシデント検知・初動対応フロー
  • 影響範囲の特定手順
  • 関係者への通知体制（利用者、監督官庁、メディア）
  • 復旧手順
  • 再発防止策の策定プロセス

お聞きしたいこと

  • 医療法人向けのインシデント対応テンプレートはあるか？
  • 計画策定の支援も外注可能か？

5-7. WAF / DDoS対策 / レート制限の本格設計 推奨

現状の問題

  • レート制限: in-memoryで実装済み → サーバーレス環境では各インスタンスで独立するため実質無効
  • WAF: 未導入
  • DDoS対策: Cloudflare/Vercelのデフォルト保護のみ

お聞きしたいこと

  • Cloudflare Workers KV / Upstash Redis でのレート制限実装の設計支援は可能か？
  • この規模（月間PV数千程度）でWAF導入は必要か？
  • コストパフォーマンスの良い構成の提案をいただけるか？

6. 予算・スケジュール感

以下は事前調査に基づく概算です。適正な見積もりをいただきたいのが相談の目的の一つです。
項目 想定予算 想定期間 優先度 備考
ペネトレーションテスト
（endai-system）		 30〜80万円 2〜4週間 必須 決済機能あり。最優先。
ペネトレーションテスト
（visitcare + conference-app）		 30〜60万円 2〜3週間 必須 医療データ取り扱い。
Git履歴シークレット除去
+ ローテーション		 10〜30万円 1〜2週間 必須 リポジトリ約15個。
ローテーションは各サービスで実施。
医療データ コンプライアンス監査 20〜50万円 2〜4週間 必須 法務連携が必要な可能性。
Supabase RLSレビュー 10〜20万円 1週間 必須 ペネトレーションテストと
一括実施可能かもしれない。
Stripe決済フロー評価 10〜30万円 1〜2週間 強く推奨 ペネトレーションテストと
一括実施を希望。
インシデント対応計画策定 15〜30万円 2〜3週間 強く推奨 テンプレートベースなら安価。
WAF/レート制限 設計支援 10〜20万円 1〜2週間 推奨 設計のみ。実装はAIで対応可。
合計（概算） 135〜320万円 ／ 段階的に3〜6ヶ月

提案: 段階的実施プラン

フェーズ 内容 時期
Phase 1 Git履歴シークレット除去 + ローテーション
（最もリスクが顕在化しているため最優先）		 即時〜2週間
Phase 2 endai-system ペネトレーションテスト
（RLSレビュー + Stripe評価を含む）		 1〜2ヶ月目
Phase 3 visitcare 医療データコンプライアンス監査
+ ペネトレーションテスト		 2〜3ヶ月目
Phase 4 インシデント対応計画策定
+ WAF/レート制限設計		 3〜4ヶ月目

7. 専門家への質問事項（まとめ）

全体方針について

  1. この規模・構成のシステム群に対して、上記の対策優先順位は妥当か？
  2. 「AIが書いたコードを専門家がレビュー・テストする」という分担は一般的か？類似の事例はあるか？
  3. ペネトレーションテスト報告書の形式で、修正箇所をコードレベルで示してもらえれば、修正自体はAIで即対応可能。そのようなワークフローは可能か？

費用・契約について

  1. ペネトレーションテスト + RLSレビュー + Stripe評価をパッケージにできるか？
  2. 医療データのコンプライアンス監査は、セキュリティ事業者と法務事業者のどちらに依頼すべきか？
  3. 年間保守契約（定期スキャン等）の必要性と費用感は？

技術的な質問

  1. Supabase + Vercel構成でのペネトレーションテストに実績はあるか？
  2. Firestoreセキュリティルールのテスト自動化ツール（Firebase Emulator）で十分か、それとも手動テストが必要か？
  3. GitHubプライベートリポジトリへのアクセス権付与の安全な方法は？（Deploy Key? Collaborator?）

運用面

  1. テスト環境と本番環境のどちらでペネトレーションテストを行うべきか？
  2. テスト中にデータ破損が起きた場合のリカバリ手順は事前に準備すべきか？
  3. ISMS認証の取得は、この規模の医療法人にとって費用対効果があるか？

添付・参考資料

#資料名内容
1owasp-security-report.htmlOWASP Top 10対策レポート（2026-02-13）
2owasp-threat-analysis-report.html脅威分析 + Vibe Coding修正レポート（2026-02-14）
3security-scan-report-20260214.html3フェーズセキュリティスキャン結果
4security-hardening-checklist-20260214.htmlSEC要件チェックリスト（充足率94%）
5security-action-plan.htmlセキュリティ強化アクションプラン
6project-dashboard.html全プロジェクト一覧ダッシュボード

※ 上記資料はすべて C:\Users\kawag\work\ に保存されており、必要に応じて共有可能です。
※ ソースコードはGitHubプライベートリポジトリで管理しています。

本資料はAI（Claude Code）が自動分析・生成しました。
最終更新: 2026年2月26日