戦略的システム監査および事業継続性強化計画書

外車王・旧車王 Webプラットフォーム

📋 エグゼクティブサマリー

⚠️ 現状の危機的状況
エンジニア全員退職に伴い、システムがブラックボックス化。インシデント対応が後手に回り、ビジネスの継続性に重大なリスクが発生しています。
3
重大な構造的問題
12
ヶ月
3
フェーズ計画

📌 本計画の3つの主要目的

  1. 潜在的脆弱性とリスクの完全可視化
    現在のシステムが抱えるリスクを定量的に把握
  2. ガバナンス体制の構築
    外部ベンダー依存下でもコントロール可能な管理体制を確立
  3. 事業継続計画（BCP）の策定
    予期せぬ障害や災害からの迅速な復旧を実現

🎯 技術スタック

採用技術
  • Laravel Vapor - サーバーレスアーキテクチャ（AWS Lambda）
  • Nuxt.js - SSR（サーバーサイドレンダリング）
  • AWS - クラウドインフラ（RDS, S3, CloudWatch等）
💡 重要な認識
過去に発生したDB不一致、画像消失、SEO事故は単発の不具合ではなく、システム構成と運用体制の構造的な欠陥に起因する警告信号です。

🔍 現状分析と構造的リスク

技術的リスク一覧

技術コンポーネント 特性 想定リスク 重要度
AWS Lambda (Vapor) ステートレス、実行時間制限 DB不一致: 同時接続数急増時やトランザクション処理の不備により、データの整合性が崩れる。接続数枯渇とタイムアウトによる中途半端なデータ残存のリスク。 高
AWS Lambda (Vapor) コールドスタート SEO事故/UX低下: コンテナ起動待ち（数秒の遅延）が発生し、5xxエラーやタイムアウトを返すことで検索順位低下の原因となる。 高
Nuxt.js (SSR) サーバーサイドレンダリング Soft 404: APIエラーやデータ不在時に、エラーページではなく200 OKのまま空ページを返し、インデックス品質を著しく損なう。 高
AWS S3 オブジェクトストレージ 画像消失: オペレーションミスやバッチ処理の不具合による誤削除。バージョニング・MFA Deleteが無効の場合、復旧不可能。 高

組織・ガバナンス上の課題

🔴 ブラックボックス化

ソースコードの品質やセキュリティ対策の判断をベンダーに完全依存。技術的負債の蓄積が検知不能。

🔴 ベンダーロックイン

仕様書・設計図不在により、ベンダー変更が極めて困難。コスト交渉力低下とベンダー倒産時の共倒れリスク。

🔴 インシデント対応遅延

障害発生時の切り分けに時間を要し、ダウンタイムが直ちに機会損失とブランド毀損につながる。

📊 重要な統計
過去のインシデントから学ぶべき教訓は、これらが単発の問題ではなく、組織的・構造的な欠陥の症状であるということです。

⚠️ リスクアセスメントと脆弱性診断

3層構造の脆弱性診断体制

🔍 レイヤー1: 自動スキャン (SAST/SCA/DAST)

推奨ツール: Aikido Security

  • 静的解析（コードのバグ検出）
  • SCA（ライブラリの脆弱性スキャン）
  • CSPM（クラウド設定ミスの検出）
  • DAST（動的な攻撃シミュレーション）
✅ メリット: AI自動選別により非技術者でも直感的に理解可能。CI/CDに組み込むことで脆弱なコードの本番流出を防止。
🛡️ レイヤー2: AWS環境の継続的セキュリティ評価
  • AWS Security Hub: CIS AWS Foundations Benchmarkに対する準拠状況を自動チェック
  • Amazon GuardDuty: AIによる脅威検知（不正アクセス、異常な通信パターン等）
🎯 レイヤー3: ペネトレーションテスト

実施頻度: 年1回、または大規模な機能追加時

診断内容: ホワイトハッカーによるビジネスロジックの脆弱性診断

  • IDOR（他人のデータへの不正アクセス）
  • 権限昇格（権限のないユーザーが管理者機能を実行）
  • その他ツールでは検知できない論理的欠陥

セキュリティインシデント対応体制

レベル 影響範囲 対応時間 アクション
レベル1 サービス影響なし
（UI崩れ等）		 翌営業日対応 通常フローで対応
レベル2 一部機能停止
SEO影響あり		 当日中対応 ベンダー緊急対応
レベル3 全停止、データ消失
情報漏洩		 24時間以内復旧 緊急連絡網発動
経営層即時報告

📝 包括的システム監査チェックリスト

A. アプリケーション健全性・品質監査

ID 監査対象 確認内容 ツール 重要度
APP-01 エラーハンドリング CloudWatch Logsに未処理の例外（500エラー）が多発していないか。エラー通知は機能しているか。 Sentry, Flare 高
APP-02 トランザクション整合性 DB更新処理において、トランザクション処理（DB::transaction）が適切に実装されているか。 コードレビュー 高
APP-03 バリデーション 入力値チェックはフロントエンドだけでなく、バックエンドでも厳密に行われているか（API直接叩き対策）。 侵入テスト 高
APP-04 依存ライブラリ composer.json/package.jsonに、サポート切れや既知の脆弱性を持つライブラリが含まれていないか。 Aikido, Dependabot 高
APP-05 Nuxt SEO設定 動的ルートに対し、sitemap.xmlが自動かつ正確に生成されているか。Soft 404対策は実装済みか。 Screaming Frog 高
APP-06 非同期処理 画像アップロードやメール送信等の重い処理は、キュー（SQS）を用いた非同期処理になっているか。 コードレビュー 中

B. AWSインフラ・セキュリティ監査

ID 監査対象 確認内容 ツール 重要度
INF-01 IAM権限 AdministratorAccessなどの過剰な権限が付与されたIAMユーザー/ロールが存在しないか。 IAM Access Analyzer 高
INF-02 S3データ保護 画像保存用バケット等は、バージョニングとMFA Deleteが有効化されているか。 AWS Config 高
INF-03 WAF設定 AWS WAFが導入され、SQLインジェクションやXSS、既知の悪性IPをブロックしているか。 AWS WAF 高
INF-04 DBバックアップ RDS/Auroraの自動バックアップ設定（保持期間）は適切か。ポイントインタイムリカバリが可能か。 AWS RDS Console 高
INF-05 ネットワーク分離 DBや内部APIはプライベートサブネットに配置され、インターネットから直接アクセスできないか。 AWS VPC Console 中

C. 運用プロセス・ドキュメント監査

ID 監査対象 確認内容 ツール 重要度
OPS-01 ソースコード管理 Gitリポジトリの管理権限は自社にあるか。退職者のアカウントが削除されているか。 GitHub Admin 高
OPS-02 デプロイフロー CI/CDパイプラインによりテストとデプロイが自動化されているか。手動での本番変更が禁止されているか。 GitHub Actions 高
OPS-03 ドキュメント有無 システム構成図、ER図（DB設計図）、API仕様書が存在し、現状と一致しているか。 作成必須 高
OPS-04 ベンダーSLA ベンダーとの契約において、障害対応時間や稼働率の定義（SLA）が存在するか。 契約書確認 高
💡 監査の進め方
エンジニア不在の状況下では、「ブラックボックス監査」（外部から振る舞いを検証）と「ホワイトボックス監査」（内部設定やコードを確認）を組み合わせて実施します。ベンダーにレポート提出を依頼するか、第三者の技術顧問を一時的に雇用することを推奨します。

🛡️ BCP（事業継続計画）とバックアップ・復旧体制

RPO / RTO の定義

目標値設定
対象 RPO
(目標復旧時点)		 RTO
(目標復旧時間)
データベース 障害発生の5分前 -
画像データ 消失なし（完全保護） -
Web表示復旧 - 1時間以内
完全機能復旧 - 4時間以内

災害・障害シナリオと復旧戦略

🔴 シナリオA: データベースの論理破損・データ不整合

リスク: アプリケーションのバグやオペレーションミスにより、顧客データが上書き・消失

対策: Amazon RDS/Auroraの自動バックアップを有効化、保持期間を最大（35日）に設定

復旧手順:

  1. 障害発生時刻を特定
  2. 直前の状態に新しいDBインスタンスを作成（Point-In-Time Recovery）
  3. 既存DBへの上書きではなく、新規作成してアプリの接続先を切り替え
🟡 シナリオB: 画像データの誤削除・消失

リスク: 運用ツールやバッチ処理のミスにより、S3上の車種画像が大量に削除

対策: S3のバージョニング（Versioning）を必須化。MFA Delete（多要素認証削除）を有効化

復旧手順:

  1. 削除マーカー（Delete Marker）が付与されたオブジェクトを特定
  2. 一括でマーカーを削除するスクリプトを実行
  3. 旧バージョンを正（Current）として復元
🟠 シナリオC: AWSリージョン障害（大規模災害）

リスク: 東京リージョン全体がダウンし、サービスが停止

対策: クロスリージョンレプリケーションを検討。S3データやDBスナップショットを大阪リージョン等へ自動コピー

復旧手順:

  1. 大阪リージョンでVapor環境をデプロイ
  2. レプリケーションされたデータを用いてサービスを再開（Pilot Light方式）
⚠️ コスト考慮: 最も堅牢だが、コストとの兼ね合いで導入判断が必要
🔵 シナリオD: ソースコード消失・ベンダーロックアウト

リスク: GitHubアカウントの紛失、ベンダーによるアクセス拒否などでコード資産を喪失

対策:

  • ソースコードの著作権帰属を契約で明確化
  • GitHubのOwner権限を自社で保持
  • 定期的にリポジトリのバックアップを自社管理の別ストレージ（S3等）に保存

ドキュメント整備戦略

C4モデルによる階層的ドキュメント体系
  • Level 1: System Context Diagram（システムコンテキスト図）
    対象: ビジネスサイド、経営層
    内容: 外車王・旧車王と外部システムの関係を1枚の図で表現
  • Level 2: Container Diagram（コンテナ図）
    対象: ディレクター、開発リーダー
    内容: Laravel Vapor、Nuxt.js、RDS、S3等の技術選定と相互接続
  • Level 3: Component Diagram（コンポーネント図）
    対象: 開発エンジニア
    内容: コントローラー、サービス、リポジトリ等の内部構造
  • Level 4: Code（コード）
    対象: 開発エンジニア
    内容: クラス図やシーケンス図（自動生成推奨）
Documentation as Code（自動化ツール）
  • API仕様書: Scribe / Scramble（Laravel）
  • コンポーネントカタログ: Vue Styleguidist / Storybook（Nuxt/Vue）
  • アーキテクチャ図: PlantUML / Mermaid.js
✅ メリット: コードから自動生成することで、ドキュメントの陳腐化を防止

🗺️ 課題解決ロードマップ（12ヶ月計画）

Phase 1: 止血と可視化（1〜3ヶ月目）

目標: 重大インシデントの撲滅と現状の完全把握

  • 緊急システム監査の実施（Screaming Frog、Sentry/Flare導入）
  • Aikido Security導入による脆弱性スキャン
  • バックアップ設定の総点検（S3バージョニング、DB PITR確認）
  • ドキュメント作成開始（API仕様書自動生成、システム構成図Level 1-2）
Phase 2: 安定化と体制構築（4〜6ヶ月目）

目標: ベンダーコントロールの強化と運用フローの確立

  • ベンダーSLA（サービスレベル合意書）の締結
  • 自動テストの拡充（PHPUnit、CI/CDへのセキュリティスキャン組み込み）
  • Quality Gateの設定（テストに通らないコードはデプロイ不可）
  • BCP訓練（実際のDBリストア演習）
Phase 3: 恒久対策と最適化（7〜12ヶ月目）

目標: 技術的負債の解消と攻めのITへの転換

  • レガシーコードのリファクタリング
  • Laravel/Nuxtのバージョンアップ対応
  • アーキテクチャの見直し（長時間バッチのECS移行等）
  • Nuxtレンダリング戦略の最適化（SSG検討）
  • 内製化の検討（CTO候補/技術顧問の招聘）
🎯 成功のカギ
各フェーズで確実に成果を積み上げることで、システムの健全性を段階的に向上させます。焦らず、着実に進めることが重要です。

🤝 ベンダーマネジメント戦略

💡 重要な認識
エンジニア不在の状況で最も重要なのは、「外部リソースをどう管理するか」です。技術的な詳細が分からなくても、管理の主導権を握ることは可能です。

4つの管理原則

1️⃣ 透明性の確保

「やったこと」の口頭報告だけでなく、改ざん不可能なシステムログを定例報告のエビデンスとして要求する。

  • GitHubのコミットログ
  • CI/CDの実行結果
  • Sentryのエラーログ
  • Security Hubのスコア推移
2️⃣ ソースコード所有権の明確化

契約書において、以下を明記する:

  • 成果物（ソースコード、ドキュメント）の著作権が自社に帰属すること
  • 開発終了時・途中解約時の引き継ぎ義務
  • OSSライブラリ利用に関するコンプライアンス条項
📋 法的根拠: 日本の著作権法第15条第2項（職務著作）。委託契約の場合は特約が必要。
3️⃣ ロックイン回避

使用しているSaaSやクラウドのアカウントは、必ず自社が契約主体となる。

  • AWS root account
  • GitHub Owner権限
  • SendGrid等の外部サービス

ベンダーには「管理者権限を持ったユーザー」を払い出す形にすることで、トラブル時にアカウントを停止し、システム資産を保護できる。

4️⃣ 定例会の質の転換

単なる進捗報告の場ではなく、データドリブンな議論の場に変える。

画面共有しながら確認すべき項目:

  • Sentryダッシュボード: 今週発生したエラーの件数と原因
  • Security Hub: 未解決の脆弱性と対応計画
  • GitHub Insights: コミット状況とレビュー品質
  • Performance Metrics: ページ速度とCore Web Vitals

SLA（サービスレベル合意）に含めるべきKPI

KPI項目 目標値 測定方法
稼働率 99.9%以上 AWS CloudWatch監視
レベル3障害対応時間 24時間以内 インシデント管理記録
バグ混入率 月5件以下 Sentryエラーログ
脆弱性対応 Critical: 3日以内
High: 7日以内		 Aikido Securityレポート
コードカバレッジ 70%以上 PHPUnit/Jest
✅ ベンダー管理のゴール
感覚的な不満から数値に基づく改善要求へと会話を変え、ディレクターが主導権を取り戻すことが第一歩です。

戦略的システム監査および事業継続性強化計画書

外車王・旧車王 Webプラットフォーム

本レポートは、システムの健全化とビジネスの持続的成長を支援するための包括的な指針を提供します。
不明点がある場合は、技術顧問やセキュリティ専門家にご相談ください。