アンチパターン集 ― 詰む前に気づく逆引きカタログ ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「付録」カテゴリ第1弾として、アンチパターン集を解説する記事です。

各記事の「よくある勘違い」「よくある失敗」を分野横断の逆引きカタログとして再編成しました。アーキテクトの仕事は致命的な間違いを避けることの方が重要で、本記事は「詰む前に気づく」早期警戒装置として使えます。「あれ、これ大丈夫かな？」のときに該当分類を引いてください。

flowchart TB
    SYM([症状を感じたら<br/>下記から逆引き])
    A[アーキ全般<br/>過剰設計/Big Bang書き直し]
    I[インフラ<br/>手動デプロイ/単一AZ]
    D[データ<br/>NoSQL万能/正規化崩し]
    APP[アプリ<br/>God Class/貧血モデル]
    F[フロント<br/>SPA万能/CSS-in-JS濫用]
    S[セキュリティ<br/>JWT in localStorage]
    O[監視・運用<br/>計器なし飛行]
    P[プロセス<br/>大PR/長寿命ブランチ]
    AI[AI時代<br/>独自言語/生成丸投げ]
    SYM --> A
    SYM --> I
    SYM --> D
    SYM --> APP
    SYM --> F
    SYM --> S
    SYM --> O
    SYM --> P
    SYM --> AI
    classDef root fill:#fef3c7,stroke:#d97706;
    classDef bad fill:#fee2e2,stroke:#dc2626;
    class SYM root;
    class A,I,D,APP,F,S,O,P,AI bad;

このカテゴリの他の記事

アーキテクチャ全般の罠

全分野に共通する判断ミスのパターンです。特定の技術選定というより、設計に対する姿勢の誤りで、多くの失敗プロジェクトに共通して見られます。

アンチパターン	症状	処方箋
過剰設計（YAGNI違反）	使わない機能・層・抽象が大量	現在の要件で必要な分だけ作る
最新技術への飛びつき	情報が少なく詰まりやすい	2〜3年運用実績のある選択肢を優先
車輪の再発明	既存品で済む機能を自作	標準ライブラリ・SaaSに寄せる
意思決定の文書化なし	「なぜこれに決めたか」が誰も覚えてない	ADR（Architecture Decision Record）を書く
ベンチマークなしの結論	「こっちの方が速い気がする」で決定	必ず計測してから選ぶ

「技術的に正しい」より判断理由が文書化されているの方が、長期運用では価値があります。

インフラ・デプロイの罠

クラウド・サーバー・ネットワーク周りでの典型的な誤選定です。とりあえず大企業の真似をするが根本原因になっているケースが多く、規模とフェーズを見誤ると致命傷になります。

アンチパターン	症状	処方箋
無意味なマルチクラウド	IAM・監視・IaCが二重化し運用倍増	単一クラウドに寄せる
必要もないK8s採用	運用時間が開発時間を食う	ECS Fargate／Cloud Run で十分
早すぎるマイクロサービス	分散トランザクションとネットワーク境界で沼	モノリスから始めて必要になったら分割
IaCなしの手動構築	環境差分が生まれ再現不可能	Terraform／CDK で全リソース管理
プライベートサブネットにRDSなし	DB直接公開でセキュリティ穴	必ずプライベートサブネットに配置

スタートアップで「AWS認定」レベルの設計をやると、プロダクト開発の時間が溶けます。

データの罠

データストア選定・データベース運用での典型的な誤選定です。データはアプリと違って作り直せないため、ここでの失敗は5年後まで尾を引きます。

アンチパターン	症状	処方箋
本番DBで分析クエリ実行	顧客の体感速度が劣化	OLTP（業務処理用）／OLAP（分析用）を早期分離（DWH＝Data Warehouse構築）
スキーマレスDBへの逃げ	後のAI活用・分析で詰む	PostgreSQL + スキーマ定義
マスタデータ部門別バラバラ	顧客重複・統合不可能	MDM（マスタデータ統合管理）整備
履歴を残さず上書き更新	監査証跡なし・機械学習で困る	履歴テーブル or イベントソーシング
データ品質チェックなし	不整合データが分析を汚染	dbt tests／Great Expectations を自動化
バックアップからの復旧未検証	実際の災害時に復旧失敗	四半期に1回はリストア演習

データアーキテクチャの失敗は、アプリケーションアーキテクチャの失敗より5倍重い。作り直しが効かないためです。

アプリケーションの罠

コード設計・モジュール化・エラーハンドリング周りの典型的な誤りです。短期的には動くため気づきにくく、数か月〜数年かけて保守不能に追い込まれるパターンが多いのが特徴です。

アンチパターン	症状	処方箋
Godクラス・God関数	1ファイル数千行・責務不明	単一責任原則で分割
ビジネスロジックをストアドプロシージャに	DB移行不能・テスト困難	アプリ側にロジックを寄せる
エラー握りつぶし（catch { }）	障害が表面化せず深刻化	ログ出力 + 再スロー or 明示的処理
意味のない命名（data・util・manager）	コードの意図が読めない	ドメイン用語で命名
全部staticメソッド	テスト不能・依存注入不能	DIコンテナ or コンストラクタ注入
nullを返すメソッド	呼び出し側でnullチェック漏れ	Optional／Result型で表現

「動くが保守不能なコード」は、書いた本人以外に技術的負債を押し付ける行為です。

フロントエンドの罠

フロント特有の誤選定・実装ミスです。セキュリティと性能に直結するパターンが多く、ユーザーからの信頼に影響します。

アンチパターン	症状	処方箋
localStorageにJWT（JSON Web Token＝認証情報を含む署名付きトークン）保存	XSS一発でトークン流出	HttpOnly Cookie + BFF（Backend for Frontend）
CSRでSEO重要サイト	検索に載らない	SSR／SSG／ISR を使う
自前認証Cookie実装	脆弱性作り込みの温床	Clerk／Auth.js／Auth0 に委譲
独自CSS設計システム	人材確保困難・学習コスト無駄	Tailwind + shadcn/ui
画像を最適化せず配信	LCP壊滅・Core Web Vitals低下	CDN変換 + WebP／AVIF
メタFWを使わず素のReact	ルーティング・SSR・ビルドを自作	Next.js／Astro を使う

フロントエンドのアンチパターンは、ユーザーの目に直接触れるため代償が大きいです。

セキュリティの罠

セキュリティアーキテクチャでの典型的な誤りは、取り返しがつかないのが最大の特徴です。漏洩が起きてから対策しても、流出したデータは戻りません。

アンチパターン	症状	処方箋
自前認証の実装	パスワードリセット・MFA等で穴	Auth0／Cognito／Clerk に委譲
MFAを任意設定	パスワード漏洩時に即突破	全ユーザー必須化
パスワード認証のみ	フィッシングで一撃	Passkey対応を標準化
ログに個人情報を生で出力	個人情報保護法違反リスク	PIIマスキング + 監査
秘密情報をGitにコミット	流出 → 高額請求・法的リスク	Vault／Secret Manager + pre-commit hook
TLS1.0／1.1をまだ許容	監査で不適合	TLS1.3必須・1.2最低限
VPN内を信頼（境界型モデル）	内部侵入で全体崩壊	ゼロトラスト・全リクエスト認証

セキュリティは「事故ってから」ではコストが100倍になります。最初に標準装備する分野です。

監視・運用の罠

運用フェーズで発覚するアンチパターンです。「動いているように見える」状態が続くため、表面化しないまま障害時に全てが噴出します。

アンチパターン	症状	処方箋
アラートが鳴っても誰も見ない	重大障害の発見遅延	PagerDuty + オンコール体制
SLOなしで運用	品質を数値で議論できない	可用性99.9%等を明示
ログが構造化されていない	検索・集計が不可能	JSON構造化ログ標準化
ランブック（手順書）なし	夜間障害で新人が詰む	主要障害の対応手順を文書化
ポストモーテムをやらない	同じ障害が繰り返される	障害後に必ず原因と対策を記録
本番に直接SSHで修正	変更が再現不可能・監査不能	CI/CDパイプライン経由のみ

「動いている」と「監視できている」は別物。可視化されていないものは存在しないのと同じです。

プロセス・組織の罠

技術選定以前の、意思決定・組織運営レベルのアンチパターンです。技術で解決しようとしても解決しない、人の問題として扱う必要があります。

アンチパターン	症状	処方箋
アーキテクチャ決定の文書化なし	「なぜ？」に誰も答えられない	ADR（意思決定記録）を書く
アーキテクトが孤立	現場と乖離した理想論で決定	実装者と一緒に決める
Conway’s lawを無視	組織構造と合わないシステム境界	チーム構造から設計を逆算
ベンダーに丸投げ	中身を誰も理解していない	発注側がアーキテクチャを理解する
ビッグバン刷新プロジェクト	数年・数億で失敗	Strangler Figで段階移行
「やってみないと分からない」で放置	見積もり・リスク評価できない	PoC → 本実装の順序を守る

技術選定は正しかったのに、プロセスで失敗するプロジェクトが実は最も多い領域です。

AI時代特有の罠

近年顕在化してきた、AI 駆動開発・AI 活用前提のアンチパターンです。従来の設計論と違う視点が必要で、認識していないと気づかないまま技術的負債を蓄積します。

アンチパターン	症状	処方箋
AIが書きにくい独自FW採用	AIの生産性ブーストが効かない	主流FW（Next.js／Django等）に寄せる
スキーマレスでJSON格納	AIがデータ構造を推論できない	型・スキーマを明示
GUI操作依存のツール選定	AIに操作を任せられない	CLI／API／IaC で操作可能なものを選ぶ
データカタログなし	RAG・AIエージェントで意味推論できない	メタデータ・説明文を整備
AIが生成したコードの無検査デプロイ	脆弱性・バグを本番投入	通常のレビュー・テストを省略しない
ベクトルDB対応なし	RAG機能を後付けできない	pgvector／Pinecone 前提の設計

AI 時代の設計原則はAIが流暢に書ける・読めるという軸が選定の中心に入ります。

重大インシデント事例の段階別被害額

アンチパターンの代償は数字で見ると無視できない規模になります。以下は業界で語り継がれる代表事例の被害額です。

事例	年	アンチパターン	被害額／影響
Knight Capital	2012	デプロイ手順ミス（1台に古いコード）	45分で4.4億ドル損失、会社消滅
Adobe 情報流出	2013	ECBモード + 共通ヒント欄	1.5億件パスワード実質解読
Dyn DNS攻撃	2016	IoT踏み台 Mirai	Twitter／GitHub／Netflix 数時間停止、1.2Tbps DDoS
GitLab DB削除	2017	オンコール中の rm -rf + バックアップ5種全滅	6時間前スナップショットから復旧、300GB消失
Equifax情報流出	2017	Struts 2 パッチ2か月放置	和解金7億ドル、1.47億人流出
Capital One	2019	IAM過剰権限 + WAF設定ミス	8,000万ドル制裁金、1億件流出
AWS Kinesis障害	2020	ストリーミング基盤 SPOF	us-east-1 長時間停止、AWSマネコン巻き込み
SolarWinds	2020	信頼済みベンダー経由侵入	1.8万組織に正規ルート侵入
Log4Shell	2021	SBOMなし	世界中のJavaアプリがゼロデイ、自社影響不明
Facebook 6時間障害	2021	BGP設定ミス + 監視同居	広告収入損失 6,000万ドル超
Meta GDPR制裁金	2023	EU市民データ米国転送	€1.2B（約2,000億円）
CrowdStrike障害	2024	更新ミス	世界中のWindows端末がBSOD、空港・銀行・病院停止

単一のアンチパターンで数百億円〜数千億円の損害が現実に発生しています。「地味な運用こそ最強の防御」「設計の贅沢は仮説が当たってから」が業界の相場感を形作ってきた歴史です。

共通する根本原因

これらのアンチパターンには共通する根本原因があります。表面的な症状は違っても、元をたどれば同じ発想に由来するケースが多く、根本を押さえておくと予防しやすくなります。

根本原因	典型的な発言	対策
規模・フェーズの見誤り	「GoogleがやってるからMicroservices」	自社の規模で判断する
新しさへの盲信	「最新だから優れているはず」	情報量・運用実績を重視
「自前で作る方が学べる」	「勉強になるから自作する」	プロダクションで学習しない
短期視点	「今は動けばいい」	5年後の負債を評価する
文書化の放棄	「コード見れば分かる」	ADRで判断理由を残す

アンチパターンの9割は規模とフェーズを間違えたか文書化を怠ったのどちらかに還元できます。

炎上プロジェクトを振り返ると、失敗の原因は驚くほど似ていると言われます。「新しい技術を入れたかった」「かっこよく作りたかった」「勉強したかった」──この3つの動機で始まった設計は、ほぼ例外なくどこかで破綻するケースが多い。逆に、「つまらないけど、これで回る」という地味な設計は、5年経っても淡々と動き続ける事例が多数報告されています。アーキテクトの仕事の半分は欲望との戦いで、もう半分は退屈さを受け入れる勇気かもしれません。

筆者メモ — 「退屈な技術」を貫いた勝者の事例

Stack Overflowは月間1億アクセスを超える QA サイトですが、たった9台のサーバー（当時）で運用されていることが2016年の公開データで業界に衝撃を与えました。スタックは .NET + SQL Server + Redis という極めて保守的な選択で、マイクロサービス化もNoSQL化もしていません。CTO のデイビッド・フラーが「我々はあえて退屈な技術を選ぶ」と公言しており、Etsy エンジニアのダン・マッキンリーが2015年に発表した「Choose Boring Technology」というエッセイの生きた証明として今も引用されています。

対照的に Uber は2010年代中盤に約2,200以上のマイクロサービスに分割した結果、障害時の切り分けが不可能・開発者体験の悪化・重複機能の氾濫という問題が噴出し、2020年代に入ってからドメインベースの統合を進める「DOMA（Domain-Oriented Microservice Architecture）」への再編を公表しました。「できる分割の最大値をやった結果の反省」として、この業界で頻繁に引き合いに出されています。退屈な技術を選んだ者が5年後も淡々と動かし、流行に飛びついた者が5年後に統合プロジェクトに追われる──この対比は、アンチパターンの多くが個人の欲望を組織の資産で支払わせた結果だと示唆しています。

自己診断チェックリスト

自分のプロジェクトがアンチパターンを踏んでいないか、以下のチェックリストで確認できます。1つでも該当したら、該当する分野のリファレンスを見直す価値があります。

• マイクロサービス化したが、チームが30人未満である
• K8sを使っているが、専任SREが不在
• マルチクラウド構成を選んだが、明確な理由がない
• 本番DBで分析クエリを走らせている
• 認証・セッション管理を自前実装している
• localStorageにJWTを保存している
• MFAを全ユーザーで必須化していない
• ログが構造化されていない
• SLOを定義していない
• ADR（アーキテクチャ決定記録）を書いていない

最終的な判断の仕方

アンチパターン集の核心は致命的な間違いを先に潰してから、最適化を考えるという発想です。多くの選択肢で優劣の差は小さくても、踏んではいけない地雷を踏めば取り返しがつきません。「過剰設計」「最新技術への飛びつき」「自前実装の温床」「規模に合わない構成」「文書化の放棄」──この5本がアンチパターンの本丸で、9割の事故はこの5本のどれかに由来します。Stack Overflow の9台運用や Basecamp のモノリス継続が示すように、退屈な技術を貫く勇気こそが、5年後も淡々と動くシステムを生みます。

もう一つの決定的な軸は数百億円規模の失敗が業界の相場感を作っているという現実認識です。Knight Capital の45分4.4億ドル、Equifax の和解金7億ドル、Meta の GDPR 制裁金2,000億円──これらは「アンチパターンを踏むとどれだけの損害が出るか」を、業界がコストを払って学習してきた結果です。標準に寄せる選択は地味ですが、これが最強の防御になります。

選定の優先順位

1. 致命的な地雷を先に潰す — セキュリティ・データ・運用の取り返しがつかない領域
2. 規模とフェーズに合わせる — 大企業の真似もスタートアップの真似も両方危険
3. 退屈な技術を選ぶ勇気 — 5年運用実績のある選択肢を優先
4. 判断理由を文書化する — ADR でなぜそれを選んだかを残す

「地雷を避けて、退屈に貫く」これがアンチパターンを踏まないための鉄則です。

まとめ

本記事はアンチパターン集について、全分野横断・9カテゴリ・重大インシデント被害額・共通根本原因・自己診断まで含めて解説しました。如何だったでしょうか。

致命的な地雷を先に潰し、規模に合わせ、退屈に貫き、判断を文書化する。これが2026年のアンチパターン回避の現実解です。

次回は「ベストプラクティス集」について解説します。アンチパターンの逆として、各分野で迷ったらまず採用すべき鉄板選択肢を整理する予定です。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。