負荷試験のない事業は上限を知らない

買い手が事業を引き継いだ直後に、最初の広告を打つ。あるいはメディアに一度だけ取り上げられる。それだけでアクセスが平時の五倍、十倍に跳ね上がり、その日のうちにサイトが応答しなくなる。私たちは、成長のための最初のアクセルを踏んだまさにその瞬間に、買ったばかりの事業が動かなくなる場面を、何度も見てきました。皮肉なのは、買い手が最も価値を出そうとした一手で、事業が壊れることです。買い手は張り切って攻めに出ただけなのに、結果として自分で自分の資産を止めてしまう。

後から原因を辿ると、たいてい同じ言葉に行き着きます。「これまで一度も落ちたことがなかった」。売り手はそう説明しますし、嘘でもありません。ただ、落ちたことがないのは頑丈だからではなく、落ちるほどのトラフィックを一度も浴びていないからです。一度も負荷試験（わざと大量のアクセスを流して、どこまで耐えられるかを測る検査）をしていない事業は、自分がどこまで耐えられるのかを、売り手も買い手も誰も知らないまま取引されています。事業の「上限」という、成長事業にとって最も肝心な数字が、契約書のどこにも書かれていないのです。

「今まで落ちたことがない」は「上限を測っていない」と同義

安定稼働の実績は、たしかに一つの安心材料です。しかしそれは「これまで浴びた負荷に対しては壊れなかった」という事実を示すだけで、「これから浴びる負荷に耐える」ことは何も保証しません。今の通常運転がキャパシティの三割なのか、九割なのか、あるいはすでに綱渡りの九割九分なのか。この一点が、無停止で動いてきた事業ほど曖昧になります。順調に動いているという事実そのものが、限界を測る機会を奪ってきたからです。

実際の限界は、本番ピークのすぐ上にあるかもしれませんし、十倍上にあるかもしれません。この幅こそが問題です。天井までの余白が広い事業は、買い手がいくら成長させても静かに応えます。余白がほとんどない事業は、少しアクセルを踏んだだけで崩れます。両者は平時のグラフの上では見分けがつきません。どちらも綺麗に横ばいで、どちらも「落ちたことがない」からです。買い手が本当に評価すべきなのは、現在のトラフィックではなく、現在のトラフィックと限界のあいだにどれだけの距離が残っているかです。

そして厄介なことに、その距離は測らない限り誰にも見えません。売り手が誠実であっても、測っていない数字は答えようがない。「落ちたことがないので大丈夫です」という善意の説明が、そのまま買い手にリスクを引き渡す構造になっています。

現在のピークトラフィックすら、実は誰も正確に知らない

限界を語る以前に、そもそも「現在のピーク」が分かっていない事業が少なくありません。多くの人はアクセス解析のページビューを根拠にしますが、月間の総ページビューと、ある一瞬に同時に処理している接続の数は、まったく別の指標です。サーバーが本当に苦しむのは、一日の合計ではなく、キャンペーンやバズで数分間に集中する同時実行のほうです。日次の棒グラフをいくら眺めても、その瞬間最大風速は見えてきません。

さらに、間にCDN（Cloudflare等の配信網。手前でコンテンツを肩代わりする仕組み）が入っていると、実像はもっと隠れます。訪問者のリクエストの大半をCDNがキャッシュで返している場合、オリジンサーバー（大元のサーバー）が実際に処理している量は、表側のアクセス数よりずっと少なくなります。キャッシュヒット率が高いうちは快適でも、ログイン後の画面や検索結果、購入処理のようにキャッシュできない動的な部分が増えた瞬間、オリジンに一気に負荷が戻ってきます。買い手が機能を足して動的なページを増やすほど、この隠れた負荷が表に出てくる。

APM（New Relic や Datadog のような、アプリの内部挙動を計測する道具）やサーバーのメトリクス履歴が残っていれば、過去のピーク時にCPUやDBがどこまで張り付いたかを後から確認できます。逆に、これらが一切ない事業では、現在地そのものが不明です。障害が起きても第一報が誰にも届かない構造の事業がなぜ危ういのかは障害の第一報が買い手に届かない構造で扱っていますが、負荷の文脈でも同じことが言えます。計測がない事業は、限界に近づいていることにも、限界を超えたことにも、事後にしか気づけません。

負荷試験がないと、成長がそのまま事故になる

買い手が事業を買う目的は、現状維持ではなく成長です。そして成長とは、突き詰めればトラフィックを増やすことにほかなりません。広告出稿、SEOでの流入増、値上げ前の駆け込み、季節要因のピーク、他媒体での紹介。どれも歓迎すべき出来事のはずです。ところが上限が未知の事業では、この歓迎すべき出来事の一つひとつが、限界を試すノックになります。

ここに、負荷試験不在の事業を買うことの本質的な危うさがあります。上限が分かっていれば、それを超えそうな施策の前に増強しておけばいい。上限が分からないと、どの施策が地雷なのかを事前に判別できません。結果として買い手は、成功したキャンペーンによって事業を落とすという、最悪のタイミングで最悪の形で限界を発見します。しかも障害が起きるのは、たいてい流入がピークを打つ夜間や休日、つまり最も対応が遅れる時間帯です。せっかく獲得した新規訪問者は、動かないサイトを見て静かに去っていきます。

成長投資が事故のトリガーになる。これは、負荷という論点を軽視した買収で繰り返し起きる失敗の型です。買い手にとって、事業の上限を知らないということは、アクセルを踏むたびに目隠しでカーブに突っ込むようなものです。

単一障害点はトラフィックが増えて初めて姿を現す

負荷をかけたときにどこが最初に壊れるか。これは、平時のコードレビューだけではまず見抜けません。ボトルネック（詰まる箇所）は、必ずどこか一番弱い一点に集中して現れ、そしてその一点は、負荷をかけて初めて浮かび上がるからです。よくある詰まりどころをいくつか挙げます。データベースの最大接続数の上限。同時接続が閾値を超えた瞬間、新規のリクエストがすべて接続待ちで詰まり、サイト全体が固まります。

いわゆるN+1クエリも典型です。一覧を一件表示するために内部で何十回もデータベースへ問い合わせる作りは、件数と同時実行が少ないうちは体感できません。ところがデータ量とアクセスが同時に増えると、問い合わせ回数が掛け算で膨れ上がり、ある一線を境に応答が急激に悪化します。緩やかにではなく、崖のように落ちるのが特徴です。外部サービスの回数制限（rate limit）も見落とされがちです。決済のStripe、メール配信、地図や認証のAPIは、それぞれ「一定時間あたり何回まで」という上限を持っています。平時は遠く及ばなくても、トラフィックが跳ねると自分のサーバーより先に外部APIの上限に当たり、決済やメールだけが止まる。外部依存が事業の天井そのものになる仕組みはWebサービス売却で効く第三者API依存で詳しく整理しています。

このほか、PHP-FPM の同時処理数の上限、サーバーレス関数の同時実行上限、データベースのディスク性能（IOPS）、開けるファイルの数の上限など、限界の顔ぶれは構成ごとに違います。共通しているのは、どれも「負荷をかけて初めて、しかも一つずつ順番に」姿を現すということです。一つ潰すと次のボトルネックが顔を出す。だからこそ、実際に流してみない限り、本当の一番弱い点は特定できません。

スケール余地は「縦」と「横」でまったく別物

限界が見えたとして、次の問いは「では、どこまで増強できるのか」です。増強には大きく二つの方向があり、両者は難易度がまるで違います。一つは縦（スケールアップ）、つまり今のサーバーをより大きなものに載せ替える方法です。手軽ですが天井が早く来ます。どれだけ大きな一台を用意しても、一台には物理的な上限があるからです。もう一つは横（スケールアウト）、台数を増やして負荷を分散する方法です。理屈のうえでは青天井ですが、これはアプリケーションが「横に増やせる作り」になっていて初めて成立します。

横に増やせるかどうかを決めるのが、ステートレス（各サーバーが状態を持たない）設計です。ログイン状態をサーバーのメモリ上に持っていたり、アップロードされたファイルを特定のサーバーのローカルディスクに保存していたり、書き込みが単一のデータベースに集中していたりすると、単純に台数を増やしても正しく動きません。二台目に振り分けられた利用者がログアウト扱いになったり、片方のサーバーにしかないファイルが見えなかったりします。つまり、横に伸びるはずのスケール余地が、アプリの作りによって縦の天井に化けているのです。

この上限は、多くの場合、事業の初期にほとんど無意識のうちに刻まれています。当時は正しかった選択が、成長段階では足かせになる。しかもなぜその構成にしたのかという理由が失われていると、安全に作り替えることすら難しくなります。設計判断の記録が失われた事業の危うさは選定理由が失われたアーキテクチャの罠で扱っていますが、スケール余地という観点では、記録の不在は「どこまで伸ばせるか、伸ばすと何が壊れるかが誰にも分からない」という形で効いてきます。

DDで負荷試験の代わりにできること ── 段階的な確認手順

理想を言えば、検証環境（staging）で k6 や Locust、JMeter、Gatling といった負荷試験ツールを使い、段階的にアクセスを増やしながら、どこで最初に壊れるかを実測するのが一番です。しかし現実の取引では、売り手の本番環境にいきなり大量の負荷をかけるわけにはいきません。だからデューデリジェンス（買収前の精査。以下DD）では、実測が難しい前提で、間接的に上限を推し量る手を積み重ねます。

まず売り手に、これまで観測された最大の同時接続数や、一分あたりの最大リクエスト数と、そのときのCPU使用率・データベース使用率を尋ねます。数字で即答できるなら計測文化がある証拠で、それ自体が良い兆候です。答えられない場合は、メトリクスやAPMの履歴グラフを見せてもらい、過去のピークで各リソースがどこまで張り付いたかを目で確認します。あわせて、自動増減（autoscaling）の設定があるか、データベースのインスタンスサイズと最大接続数の関係、セッションとアップロードファイルの保存先（＝横に増やせる作りか）を確認します。これらは負荷をかけなくても、設定と構成図から読み取れます。

そのうえで、可能であれば売り手の許可を得て、本番と切り離した検証環境の一台に対して、ab や wrk、あるいは k6 で小さく安全な範囲から負荷をかけ、応答時間が崩れ始める点を探ります。全量再現でなくとも、崩れ方の「形」が見えれば十分に価値があります。緩やかに劣化するのか、ある一線で崖のように落ちるのか。後者なら、その崖のすぐ手前が実運用の限界だと見立てられます。そして負荷試験は、限界を超えた後に誰がどう戻すのかという運びと必ずセットで評価すべきです。復旧の手順が一人の頭の中にしかない事業がなぜ危ういかは復旧手順が1人の頭にしかない事業で述べたとおりで、上限を超えて落ちたとき、それを立て直せる人が引き継がれていなければ、上限の数字そのものにも意味が薄れます。

売り手ができる準備 ── 上限を「知っている」状態で売る

ここまでは買い手の視点でしたが、売り手にとってこの論点は、むしろ査定を押し上げる好機です。やることは単純で、売ると決める前に一度でいいから、自分の事業に負荷試験をかけておくことです。k6 で段階的にアクセスを増やすスクリプトを一本書き、検証環境に流してみる。それだけで、どこが最初に壊れるかが一つ見つかります。多くの場合はデータベースの接続数か、特定の重いページのどちらかです。

この一手間の価値は、査定の場での言葉が変わることに表れます。「落ちたことはありません」としか言えない売り手と、「観測ピークのおよそ五倍まで確認済みで、最初に詰まるのはデータベースの接続数です。そこは接続数の上限を引き上げれば当面伸びます」と数字で言える売り手とでは、買い手が感じる不確実性がまるで違います。前者は上限が未知のリスクを丸ごと引き受けさせますが、後者は成長余地を数字で保証しています。上限が見えている事業は、その先の余白そのものを売り物にできるのです。

負荷への弱さは、査定の場で割り引かれる技術的負債の一種でもあります。何が値引きの理由になり、それをどう先回りして潰すかという全体像はSaaS売却で値引きされる技術的負債にまとめていますが、負荷試験は、その負債を「未知のリスク」から「既知の課題と対処法」に変える、費用対効果の高い準備です。測っていないから安いのであって、測れば売り物が増えます。

買い手として、成長させる前に事業の天井と単一障害点を見極めたいとき、あるいは売り手として、上限を数字で示せる状態にしてから交渉に臨みたいとき、コードとインフラの現在地を外から点検する出発点としてAI技術デューデリジェンスを使えます（登録不要）。負荷という、平時には決して顔を出さない論点を、取引が動き出す前に確かめておくための一歩としてご活用ください。