リスク・対策

公開API・ログインフォーム・問い合わせに濫用対策（レート制限）がない事業は、買収後に総当たりやスクレイピング、SMS濫用で簡単に落ち、従量課金の請求まで膨らむ。防御層の有無を429ステータスや応答ヘッダ、コードとインフラの両面から見抜く技術DDの実務を解説します。

アプリ売却はどこでするのが正解か。売却先を個人間の直接取引・ストアの譲渡機能・仲介やマーケットの三つの型に分け、署名鍵やソースコードなど技術資産の評価、引き継ぎ実務の伴走、トラブル時の保全がどう変わるかを、料金比較では見えない現場の視点で整理します。

同意管理を実装せずCookieや広告タグを入れている事業は、買収した瞬間に是正義務と過去のリスクを相続する。同意バナーは何も止めていないのが常で、日本の外部送信規律とGDPRは別々に効く。タグの棚卸し、送信先とポリシーの突き合わせ方まで、買い手がDDで確認すべき点を整理する。

RedisやCDNのキャッシュ層は、本番の素の負荷とインフラ原価を覆い隠す。買収後にキャッシュが冷えると、1%しか捌いていなかったDBに全負荷がぶつかり初日に落ちる。ヒット率・オリジンの実性能・移管後の原価の三点で依存度を測る技術DDの視点を整理する。

アプリ売却の事例は「いくらで売れた」を語るが、その数字を成約に変える移管作業は語らない。開発者アカウントの名義、署名鍵とAPIキー、データの引き継ぎ可否、属人性という見えない負債を、売り手が売る前にやること・買い手が数字の裏で確認することとして整理する。

GA4やGTM、広告アカウントの所有者が代理店や個人アカウントのままだと、事業を買っても計測は付いてこない。作り直せば前年同月比も広告の学習も失われる。移管の難易度はほぼゼロなのに実行されない理由と、買い手が確認すべき管理者一覧を整理する。

コードは残るが「なぜこの構成なのか」という判断の理由は、書かなければ消える。買い手は奇妙な実装を前に、制約下の合理的判断か単なる無知かを区別できず、区別できないコードには手を入れない。触られない領域が固定される構造と、1行のコメントで足りる処方箋を整理する。

外注や業務委託で作られたコードの著作権は、契約に譲渡の定めがなければ制作者側に残るのが原則と解されます。代金を払ったから自分のものという直感と法律のズレが事業の売買でどう表面化するのか、売り手と買い手それぞれの確認手順まで実務の順序で整理します。

障害の復旧手順が1人の頭にしかない事業は珍しくない。手順書を書かなかったのは怠慢ではなく、読者が一度も存在しなかったからだ。真の壁は暗黙知が本人にも見えず、書けと言われても取り出せない点にある。買い手の検分方法と、録画による可視化を整理する。

サブスク事業のチャーン率が業界平均より不自然に低いとき、その数字はプロダクトの良さではなく解約導線の摩擦を測っている可能性がある。誰も嘘をついていないのに数字の意味だけが違う構造と、買収後に抑え込まれた解約が噴き出す経路、買い手が実測すべき指標を整理する。