本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「セキュリティアーキテクチャ」カテゴリ第1弾として、セキュリティアーキテクチャの全体像について解説する記事です。
セキュリティは後から付け足せない設計領域。本記事ではCIA3要素、認証・認可・暗号化・ネットワーク・秘密情報管理・監査の主要領域、境界型防御からゼロトラストへの潮流、AI時代にセキュリティは委譲するというスタンスまで俯瞰します。
このカテゴリの他の記事
一度漏れたデータは、二度と未公開には戻らない
従来は「ファイアウォールで境界を守る」境界型防御が中心でしたが、リモートワーク・クラウド・SaaSの普及で境界が曖昧になり、ゼロトラスト（全てを信用せず常に検証する）が本命の思想になりました。
セキュリティは後から付け足せない設計領域。漏れたデータは、謝罪しても戻ってきません。
なぜ独立したアーキテクチャとして扱うか
① 影響範囲が全システムに及ぶ
認証基盤・暗号化方式・権限モデルは、後から変えると全てのアプリケーションに影響が出ます。最上流で決めないと、あとで総入れ替えになります。
② 法規制・コンプライアンス対応が必須
GDPR（EU一般データ保護規則）・個人情報保護法・PCI DSS（クレカ情報取扱基準）・SOC2（クラウド事業者の内部統制基準）等、システムが扱うデータによって守るべき規制が決まります。規制違反は刑事罰・巨額賠償に直結します。
③ 専門性が高く兼務しにくい
暗号化・脆弱性診断・SOC（Security Operation Center、セキュリティ監視センター）運用などは専門家の領域で、片手間では扱えません。セキュリティ専任チーム（CSIRT、Computer Security Incident Response Team）を置く組織も増えています。
守るべき3要素（CIA）
セキュリティアーキテクチャで最もよく使われるフレームワークがCIAです。3要素のどれを最優先するかで、設計の軸が変わります。
| 要素 | 意味 | 代表的な対策 |
|---|---|---|
| Confidentiality（機密性） | 許可された人だけが見られる | 認証・認可・暗号化 |
| Integrity（完全性） | データが改ざんされない | ハッシュ・署名・監査ログ |
| Availability（可用性） | 必要な時に使える | DDoS（Distributed Denial of Service、分散型サービス妨害攻撃）対策・冗長化・バックアップ |
機密情報を扱う金融は機密性最優先、公共サービスは可用性最優先など、業務特性で比重が変わるのが重要ポイントです。
主要な領域の分類
flowchart TB
subgraph PERIM[境界防御層]
NW[ネットワーク<br/>FW / WAF / VPC]
end
subgraph IDENTITY[ID・権限層]
AUTH[認証<br/>Passkey / MFA / IDaaS]
AUTHZ[認可<br/>RBAC / ABAC / IAM]
end
subgraph DATA[データ保護層]
ENC[暗号化<br/>TLS / AES / KMS]
SEC[秘密情報管理<br/>Vault / Secrets Manager]
end
subgraph DETECT[監査・検知層]
AUDIT[監査・検知<br/>SIEM / CloudTrail / WAFログ]
end
USER([ユーザー]) --> NW --> AUTH --> AUTHZ --> APP([アプリ])
APP --> ENC --> DB[(DB)]
APP --> SEC
PERIM -.ログ.-> AUDIT
IDENTITY -.ログ.-> AUDIT
DATA -.ログ.-> AUDIT
classDef perim fill:#fee2e2,stroke:#dc2626;
classDef ident fill:#fef3c7,stroke:#d97706;
classDef data fill:#dbeafe,stroke:#2563eb;
classDef detect fill:#f1f5f9,stroke:#64748b;
class NW perim;
class AUTH,AUTHZ ident;
class ENC,SEC data;
class AUDIT detect;| 領域 | 扱うもの |
|---|---|
| 認証（Authentication） | 誰であるかの確認 — ID/パスワード・Passkey（パスワード不要の生体認証）・MFA（多要素認証） |
| 認可（Authorization） | 何ができるかの制御 — RBAC（役割ベース権限）・ABAC（属性ベース権限）・IAM（ID権限管理） |
| 暗号化 | 盗聴・漏洩防止 — TLS（通信暗号化）・AES（共通鍵暗号規格）・KMS（鍵管理サービス） |
| ネットワーク | 境界防御・分離 — FW（ファイアウォール）・WAF（Web Application Firewall、Web攻撃防御）・VPC（Virtual Private Cloud、仮想プライベート網） |
| 秘密情報管理 | APIキー・パスワードの保管 — Vault・Secrets Manager |
| 監査・検知 | 異常の記録と検知 — SIEM（Security Information and Event Management、ログ統合監視）・CloudTrail・WAFログ |
決めるべきこと — あなたのプロジェクトでの答えは？
以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
認証・認可・セッション
| 項目 | 選択肢の例 |
|---|---|
| 認証方式 | パスワード＋MFA・Passkey・SSO（Single Sign-On、一度のログインで複数サービス利用）・SAML（XML形式の認証連携標準）・OIDC（OpenID Connect、OAuth2ベースの認証標準） |
| 認証基盤 | 自前実装・Auth0・Clerk・Cognito・Entra ID |
| 認可モデル | RBAC・ABAC・ReBAC（関係ベース権限）・ポリシー言語（OPA（Open Policy Agent、汎用ポリシーエンジン）） |
| セッション方式 | Cookie・JWT（JSON Web Token、署名付きトークン）・Refresh Token |
| MFA方式 | TOTP（時間同期型ワンタイムパスワード）・WebAuthn（ブラウザ標準の生体・デバイス認証）・SMS |
| パスワードポリシー | 長さ・複雑性・ローテーション |
暗号化・鍵管理
| 項目 | 選択肢の例 |
|---|---|
| 通信暗号化 | TLS 1.3・mTLS（mutual TLS、双方向証明書認証） |
| 保存時暗号化 | AES-256・KMS / HSM（Hardware Security Module、専用暗号化ハードウェア） |
| 秘密情報管理 | AWS Secrets Manager・HashiCorp Vault |
| 鍵管理 | クラウドKMS・顧客管理鍵（CMK、Customer Managed Key） |
| 公開鍵基盤 | 内部CA（Certificate Authority、証明書発行局）・Let’s Encrypt・ACM（AWS Certificate Manager） |
ネットワーク・監査・コンプライアンス
| 項目 | 選択肢の例 |
|---|---|
| ネットワーク分離 | VPC・サブネット・セキュリティグループ |
| 境界防御 | WAF・IDS/IPS（Intrusion Detection/Prevention System、侵入検知/防止）・DDoS対策 |
| ゼロトラスト | BeyondCorp・Zscaler・Cloudflare Access |
| 監査ログ | CloudTrail・監査証跡の保存期間 |
| 脆弱性管理 | SAST（Static Application Security Testing、静的解析）・DAST（Dynamic〜、動的解析）・依存ライブラリスキャン |
| コンプライアンス | SOC2・ISO 27001（情報セキュリティ国際規格）・PCI DSS |
セキュリティ思想の変遷
「境界型防御」から「ゼロトラスト」への移行は、クラウド時代で最も大きなパラダイムシフトです。境界型では社内ネットワークは安全という前提で設計していましたが、リモートワーク・SaaS利用・内部不正の増加により、この前提が成立しなくなりました。
ゼロトラストはネットワークの内も外も信用せず、全ての通信で認証・認可を検証する思想で、Googleが2010年代に実装した BeyondCorp が先駆けです。VPNに頼らず、ユーザー・デバイス・コンテキストを常に検証します。
| 境界型防御 | ゼロトラスト |
|---|---|
| 内側 = 信頼、外側 = 不信 | 全てを不信から始める |
| VPNで境界を守る | 全通信で認証・認可 |
| ネットワーク中心の設計 | IDベース（Identity-centric） |
| 社内ネットワークに強く依存 | 場所を問わず同じ扱い |
フェーズ別セキュリティ導入ロードマップ
セキュリティは「全部一気には非現実的」フェーズに応じて必須/推奨を切り分けます。
| フェーズ | 組織規模 | 必須導入 | 次に導入 | 月額コスト |
|---|---|---|---|---|
| ① MVP・個人 | 〜3人 | HTTPS + MFA + Dependabot + IAM Role | Secret Scanning | 0円 |
| ② 初期スタートアップ | 3〜30人 | + WAF + CloudTrail + 暗号化 | GuardDuty + SSO | 数万円 |
| ③ 中規模SaaS | 30〜300人 | + SIEM + 脆弱性スキャンCI | SOC2 + ISMS + Policy as Code | 数十万円 |
| ④ 大企業 | 300人〜 | + 24/7 SOC + DLP + ZTNA | Red Team演習・ペネトレ年次 | 数百万円 |
| ⑤ 規制業種 | 全規模 | 業界認定（FISC / HIPAA / ガバメントクラウド） | — | 変動 |
「MVPでもMFA・Dependabot・Secret Scanning・HTTPSの4つは必須」これを後回しにすると公開後数時間で IAMキー流出・依存ライブラリ経由侵入を食らいます。2021年 Log4Shell・2022年 Okta / LastPass 事件がその代償を示しました。
MVPでも最低4点セットは即日入れる。セキュリティに「後で」は存在しません。
セキュリティ全体の鬼門
各論記事で触れた禁じ手のうち、セキュリティアーキテクチャレベルで押さえるべき核心を整理します。
| 禁じ手 | なぜダメか |
|---|---|
| 認証を自前実装 | Clerk / Auth0 / Firebase Authへ委譲、自作は穴だらけ |
| JWTをlocalStorage保存 | XSS一発で全員分漏洩、httpOnly Cookie必須 |
| SMS MFAだけに依存 | SIMスワップで突破、TOTP / FIDO2必須 |
| Criticalパッチを2週間以上放置 | Equifax 2017年事件（7億ドル和解金）のパターン、72時間以内がSLA |
| 「社内は安全」の境界型防御 | 2021年Pulse Secure事件、ZTNAへ移行 |
| 永続API Keyを本番で運用 | OIDC + 短命トークンへ |
| 個人情報をマスキングせずログ出力 | GitHub 2018年平文パスワード事件のパターン |
| SBOMなし | Log4Shellで「自社に影響があるか不明」事態 |
| セキュリティ設定をGUI手作業 | 変更履歴なし、IaC + Policy as Codeへ |
| パスワードをSHA-256単独ハッシュ | Argon2id必須、GPU総当たり対策 |
セキュリティは「書くな、借りろ、見張れ」の3点セット。独自実装が最大の事故源です。
AI時代の視点
AI駆動開発（バイブコーディング）が前提になると、セキュリティはAIに任せてはいけない領域として重要性が跳ね上がります。認証・暗号化・権限制御の独自実装は脆弱性の温床で、AIにコードを書かせる場合も標準プロトコルや専用製品に委譲するのが鉄則です。
| AI時代に有利 | AI時代に不利 |
|---|---|
| 標準プロトコル（OIDC・OAuth・SAML） | 独自認証・独自暗号化 |
| 専用SaaS（Clerk・Auth0・Entra ID） | 手書き実装の認証システム |
| IaC（Infrastructure as Code、インフラをコードで定義）で記述されたIAM・セキュリティ設定 | GUI設定の属人化した権限管理 |
| ポリシー言語（OPA・Cedar）での認可 | コード内にif文でベタ書きの権限判定 |
AIは境界の内側でコードを書く存在になるため、AIが読めないブラックボックス設定は危険です。IaCで記述され、バージョン管理され、レビューできる形が望ましいです。
セキュリティの独自実装はAI時代最大の罠。標準と専用SaaSに委譲します。
筆者メモ — 「防げたはずの一撃」が企業を傾けた事例
セキュリティ事故は派手な攻撃より基本の怠りで起きる、という話がよく聞かれます。
ある大手信用情報会社では、2017年に Apache Struts の既知脆弱性（CVE-2017-5638）への「パッチ適用が2か月遅れた」ことが原因で、約1.47億人分の個人情報が流出しました。この1社の事件は、最終的に和解金・罰金あわせて約7億ドル規模まで膨れ上がり、「パッチ遅延」という地味な怠りがいかに致命傷になるかを示す語り草になっています。
同じく2019年には、米大手金融サービスで「WAFの設定ミス」（サーバ側リクエスト偽造＝SSRF）を起点に、約1億人分の顧客情報がS3バケットから流出した事例があります。攻撃者は元クラウドエンジニアで、「設定の一行の甘さ」を突きました。同社は米当局から8,000万ドル規模の制裁金を受けています。
筆者も過去、些細な設定ミスがログに記録されていたのを半年後に気づく、というヒヤリ経験があります。どちらも高度なゼロデイではなく「基本の運用」が崩れた事例で、地味な基本こそが最強の防御であることを突きつけます。
セキュリティは派手な攻撃より基本の怠りで事故る。パッチ・MFA・設定レビューが最強の防御です。
よくある勘違い
セキュリティは「後付けできる」「専門家に任せれば良い」と考えられがちですが、全システムに影響する最上流の設計領域です。
- 社内ネットワークは安全 → 境界型防御の前提はリモートワーク・SaaS時代には成立しません。ゼロトラスト（全通信で認証・認可）が新しい標準です
- 認証は自前で作ろう → 認証の独自実装はバグと脆弱性の温床で、AIが最も間違えやすい領域でもあります。OIDC / SAML などの標準プロトコルと専用SaaSに委譲するのが鉄則です
- 暗号化していれば安全 → 暗号化は多層防御の一部でしかありません。2018年の Marriott 情報流出（旧Starwood予約システム、約5億人分）では、クレジットカード番号は暗号化されていた一方、パスポート番号は暗号化されていなかったことが英ICOの調査で判明し、£18.4Mの制裁金に繋がりました
- コンプライアンスは法務の仕事 → GDPR・PCI DSS・SOC2 は技術実装に直接紐づく要件で、技術側が無知だとシステムが法規制違反になります。アーキテクトが自ら確認する必要があります
最終的な判断の仕方
セキュリティアーキテクチャの核心は一度データが漏れると取り返しがつかないという非対称性にあります。認証基盤・暗号化方式・権限モデルは影響範囲が全システムに及び、後から変えるコストが極めて高くなります。だからこそ最上流で決め、CIA（機密性・完全性・可用性）のどれを優先するかを業務特性に応じて明確化し、多層防御で設計するのが合理的です。境界型防御からゼロトラストへの移行も、クラウド・リモート・SaaS前提の現代では不可逆の潮流で、Identity-centricな設計が標準解になります。
もう一つの決定的な軸はAIに書かせない領域の筆頭がセキュリティという点です。独自認証・独自暗号化はAIが最もバグを混入しやすい領域で、見た目正しく穴だらけのコードは事故の元になります。標準プロトコル（OIDC / OAuth / SAML）と専用SaaS（Clerk / Auth0 / Entra ID）に委譲し、IaCで記述・バージョン管理・レビュー可能な状態に保つのが、AI時代の防衛線です。
選定の優先順位
- 標準プロトコルと専用SaaSに委譲 — 認証・認可・暗号化は独自実装しない
- 多層防御を前提に設計 — 単発対策ではなく、ネットワーク・認証・暗号化を重ね合わせる
- ゼロトラストを出発点 — 「社内は安全」を捨て、全通信で認証・認可を検証する
- IaCで記述しレビュー可能に — GUI設定の属人化を避け、Git管理で証跡を残す
「セキュリティはAIに任せず委譲する」標準・専用SaaS・IaCで、事故の元になる独自実装を避けます。
まとめ
本記事はセキュリティアーキテクチャの全体像について、CIAの基本・主要領域・境界型からゼロトラストへの潮流・フェーズ別ロードマップ・AI時代の委譲スタンスまで含めて解説しました。如何だったでしょうか。
標準プロトコルと専用SaaSに委譲し、多層防御で設計し、ゼロトラストを出発点に置き、IaCでレビュー可能にする。これが2026年のセキュリティアーキテクチャの現実解です。
次回は認証設計（MFA・Passkey・SSO・IDaaS選定）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（46/89）