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

本記事について

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

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

付録カテゴリの全記事一覧は以下のページにまとめています。

付録 記事一覧 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-index-appendix/

本記事のテーマについてさらに詳しく知りたい方は『ソフトウェアアーキテクチャの基礎』も参考にしてみてください。

そもそもアンチパターンとは何か

交通事故の原因パターンを思い浮かべてください。「脇見運転」「スピード超過」「一時停止無視」──事故の原因は毎回新しいものではなく、同じパターンが繰り返し発生しています。パターンを知っていれば、危険な状況に気づいて事前に回避できます。

アンチパターンはアーキテクチャ版の事故原因カタログです。過去のプロジェクトで繰り返し見られた「やってはいけない設計判断」を類型化したもので、同じ失敗を繰り返さないための知恵の集積です。

もしアンチパターンを知らなければ、先人が既に踏んだ地雷を自分も踏むことになります。致命的な間違いを避けることは、正しい設計を追求することと同じくらい重要です。

なぜアンチパターンを学ぶ必要があるのか

正しい選択を覚えるより「致命的な間違い」を避ける方が効果的だから

アーキテクチャの選択肢は無数にありますが、致命的な間違いのパターンは有限で、しかも繰り返し現れます。全ての正解を覚えるのは不可能ですが、「これだけはやってはいけない」を押さえておけば、設計レビューの品質が劇的に上がります。

「一見もっともらしい判断」が一番危険だから

アンチパターンの多くは初見では合理的に見えます。「マイクロサービスの方がスケールする」「NoSQLの方が速い」「最新技術の方が生産性が高い」──いずれも文脈次第で正解にも不正解にもなります。アンチパターンを学ぶことで、前提条件を確認する習慣が身につきます。

チームの共通語彙として機能するから

「それはGolden Hammerだね」「Big Ball of Mudになりかけている」とパターン名で指摘できると、設計レビューや議論の効率が格段に上がります。抽象的な懸念を具体的な類型で共有できるのは、チーム全体の設計力の底上げになります。

アーキテクチャ全般の罠

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

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

インフラ・デプロイの罠

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

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

データの罠

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

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

アプリケーションの罠

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

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

フロントエンドの罠

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

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

セキュリティの罠

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

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

監視・運用の罠

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

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

プロセス・組織の罠

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

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

AI時代特有の罠

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

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

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

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

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

共通する根本原因

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

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

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

| 「新しい技術だから優れている」と盲信 | 情報量・運用実績のない選択は障害時に孤立、退屈な技術が5年後に勝つ | | 「コード見れば分かる」と文書化放棄 | ADRなしで3年後に判断理由が消失、同じ失敗を繰り返す |

AI判断軸

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

AIが推奨するアーキテクチャにもアンチパターンが含まれる

AIに「モダンなアーキテクチャを提案して」と聞くと、マイクロサービス・Kubernetes・イベント駆動・CQRSといった複雑な構成を推奨するケースがあります。これは学習データに大企業の事例紹介記事やカンファレンス資料が多く含まれているためで、AIが回答者のコンテキスト（チーム規模・予算・運用体制）を考慮せずに「理想論」を返す傾向があります。

10人のチームがAIの推奨に従ってマイクロサービスに分割すると、本記事で紹介したSegmentやUberと同じ失敗を繰り返すことになります。AIの提案を受け取る際は、必ず自チームの人数・予算・運用体制を明示したうえで「この規模で過剰な部分はないか」と聞き直す習慣が必要です。

AIは質問の仕方で回答が大きく変わります。「最高の」「モダンな」と聞くと過剰設計寄りの回答が返り、「5人で運用できる最もシンプルな」と聞くと実用的な回答が返ります。プロンプトの書き方がアンチパターン回避に直結する点を意識してください。

「AI任せ」自体が新しいアンチパターンになりつつある

AIコーディングツールの普及により、「AIが書いたからOK」という判断でレビューを省略するケースが発生しています。これは新しい形のアンチパターンです。AIが生成するコードは統計的に正しそうなパターンを返しますが、プロジェクト固有の制約（既存のDB構造との整合性、チームの命名規約、セキュリティポリシー等）を自動的に考慮することはありません。

特に危険なのは、AIが生成した設計判断（DB選定・認証方式・キャッシュ戦略等）を「AIが言っているから正しい」として根拠なく採用することです。設計判断には必ず「なぜその選択をしたか」の理由が必要であり、「AIが推奨した」は理由として成立しません。

ADR（Architecture Decision Record）に判断理由を記録する習慣があれば、AIの提案であっても「なぜ採用したか」を言語化する強制力が働き、無批判な採用を防げます。

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

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（アーキテクチャ決定記録）を書いていない

まとめ

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

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

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

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

本記事で扱った内容の詳細は AWS Well-Architected フレームワーク も合わせて参考にしてください。

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