コード探偵ロックの事件簿：未設定の通知先のために12か所へ defined チェックを書き、1か所の書き忘れで深夜3時に落ちた。何もしない通知先を入れてチェックをなくす（Null Object）。
コード探偵ロックの事件簿：注文クラスに業務ロジックと SQL が同居し、テストに DB が要る。30分かかって CI が毎回タイムアウトする。データアクセスを差し替え可能に分ける（Repository）。
コード探偵ロックの事件簿：型判定の分岐が4つの関数に散らばり、種別を足したとき修了判定だけ書き忘れて、未受講の200名に修了証が出た。漏れをロード時のエラーにする（Visitor）。
コード探偵ロックの事件簿：文書管理の children 配列を15部署のスクリプトが直接たどり、構造を変えたら全部壊れた。走査をイテレータに閉じ込め、たどり方だけ公開する（Iterator）。
コード探偵ロックの事件簿：契約書を組み立てる SaaS で、条項の追加・削除・並べ替えが上書きで、前の状態がどこにも残らない。誤って消した免責条項に気づかないまま契約が締結された。操作の前に状態をスナップショットに保存し、任意の時点に戻す（Memento）。
コード探偵ロックの事件簿：10万件の商品がカテゴリと税率のオブジェクトを個別に持ち、メモリが 2.4GB に膨らんで落ちた。共通データを1つずつ共有して参照する（Flyweight）。
コード探偵ロックの事件簿：文書3種×出力形式3種で9クラス。提案書を足すときに請求書のクラスをコピペし、消費税の欄まで出た。文書の種類と出力形式を分けて組み合わせる（Bridge）。
コード探偵ロックの事件簿：ゲームの世界生成で、地形・生物・天候を別々のメソッドが $type を見て作るため、引数の取り違えで砂漠にクラーケンが出た。バイオームごとに1つのファクトリーが3つをまとめて作り、組み合わせの混在を防ぐ（Abstract Factory）。
コード探偵ロックの事件簿：EC の受注・在庫・決済・通知・監査ログの5モジュールが互いを直接参照し、クーポン機能を足すには5つ全部に手を入れることになる。モジュール間のやり取りを仲介者1つに集め、各モジュールは仲介者だけを知る（Mediator）。
コード探偵ロックの事件簿：サブタスクを入れてから、進捗率・工数・完了数の関数すべてに「タスクかグループか」の if が入り、階層が深いとバグる。個と集まりを同じに扱う（Composite）。
コード探偵ロックの事件簿：メール・Slack に「リトライ」「ログ」を組み合わせるたびにサブクラスを作り、30個を超えた。SMS を足せば組み合わせの数だけクラスが増える。通知の本体に機能を包みとして重ね、組み合わせは実行時に作る（Decorator）。
コード探偵ロックの事件簿：17種類の帳票テンプレートを毎回ゼロから組み立てていたため、全帳票に項目を1つ足したら、ある帳票で部署名が空欄になり、別の帳票の機密フラグまでおかしくなった。完成済みの原型を深くコピーし、違う部分だけを変える（Prototype）。
コード探偵ロックの事件簿：広告キャンペーンの設定オブジェクトは属性が12個あり、コンストラクタに順番で渡していたら1個ずれて10万円の本番事故になった。名前付きのメソッドで1つずつ設定し、build() でまとめて検証する（Builder）。
コード探偵ロックの事件簿：新システムと買収先の古いシステムをつなぐため、呼び出し側でメソッドを if で呼び分け、データも手で揃えていた。古いクラスを包んで同じ形で呼ぶ（Adapter）。
コード探偵ロックの事件簿：未払い・支払い済み・出荷準備中・発送済み・キャンセルの遷移を1つの if-elsif で管理していたため、「返品処理中」を足しただけで無関係な出荷処理にバグが続発した。状態ごとのクラスが自分の振る舞いと遷移先を持つ（State）。
