月100万円のAPI費用を知らずに買った

Webサービスの買収後、「毎月の運営コストがIMに記載された数字と大幅に乖離している」という事態は珍しくありません。その原因の多くが、外部APIのコストが損益計算書の「外注費」という1行に混入しており、買い手がその内訳を確認しないまま契約を締結したケースです。財務DDは数字を見ます。しかし「外注費の中に何が入っているか」は、コードと各サービスの請求書を直接確認しなければ永遠に見えません。外部API依存という時限爆弾は、財務DDの死角に整然と収まった状態で、買収の成立を待っています。 2023年以降に現実化したX（旧Twitter）API有料化・Google Maps価格改定・Twilio利用停止の事例、そして2026年現在急増しているAI API（OpenAI・Claude）依存サービスの買収リスクを、具体的な数字と実務の観点から分解します。

1. 「APIコストなんて小さい」という認識が命取りになる ── 財務DDでは絶対に見えない外部API依存の盲点

1-1. コードを読まなければ依存度は財務諸表に現れない ── 「外注費」「通信費」に紛れ込む従量課金の爆弾

外部API費用がどの勘定科目に計上されるかは、企業の経理担当者によって「外注費」「通信費」「支払手数料」「システム利用料」とバラバラです。しかも多くの場合、複数のAPIコストがひとつの勘定科目に混在しており、個別のAPIにいくら払っているかが財務諸表から読み取れる状態になっていません。さらに致命的なのが、外部APIの料金モデルが「従量課金」であるという点です。月額固定費に見える数字でも、その中身がリクエスト数・データ転送量・ユーザー数に連動した変動費であれば、サービスが成長するほどコストは跳ね上がります。買収後にサービスをスケールしようとした途端、APIコストが売上成長を食い尽くす「コスト爆発」が発動するのは、この構造から必然的に生まれます。 財務DDで損益計算書の外注費が月50万円と記載されていても、その内訳が「AWS 15万円・Google Maps API 20万円・Twilio 10万円・その他5万円」という構成になっているケースは十分ありえます。その可能性に気づくためには、サービスのコードと各APIの請求書を直接確認するしかありません。

1-2. 「連携している」と「依存している」は天と地の差 ── API廃止・値上げ・障害で即死するサービスの構造

「このサービスはGoogle Mapsと連携しています」という売り手の説明を受けたとき、その「連携」が「地図を1ページに表示しているだけ」なのか「サービスの全機能がGoogle Maps APIなしでは動かない」なのかは、言葉だけでは判別できません。前者であれば、Google Mapsが廃止されても地図機能が失われるだけで事業は継続できます。後者であれば、Google Maps APIが利用停止になった瞬間にサービス自体が停止します。APIへの「依存度」を測る最も重要な問いは「このAPIが明日から使えなくなったとき、サービスは動くか」という1点です。 この問いを実際のコードで確認するためには、APIコールが何箇所に書かれているか、APIレスポンスをキャッシュしているか、フォールバック（代替処理）が実装されているかを見る必要があります。「連携」という柔らかい言葉の裏に「依存」という脆弱性が隠れているケースは、Webサービス買収の現場において頻繁に発生します。

2. X（旧Twitter）API有料化という震撼 ── 「無料のインフラ」が突然、月100万円超になった日

2-1. 2023年2月、イーロン・マスクが引いた引き金 ── X APIに依存したサービスが一晩で機能不全に陥った実態

2023年2月2日、X（旧Twitter）は無料APIアクセスの廃止を突然発表しました。猶予期間はわずか1週間。それまで無料で使えていたAPIが2023年2月9日から有料化され、「Basic」プランは月400ドル（当時約5万3,000円）、「Pro」プランは月6,000ドル（当時約79万円）という価格設定が提示されました。問題は金額だけではありません。無料時代にはアプリケーション単位・ユーザー単位で寛大に設定されていたレート制限が、有料化後に大幅に絞られ、同じ機能を同じ品質で提供しようとすると上位プランが必須になりました。さらに2023年6月にはサードパーティクライアントアプリ向けのAPIが完全廃止され、Tweetbot・Twitterrificといった老舗クライアントアプリが一夜にしてサービス終了に追い込まれました。「Xのデータを使ったサービス」「Xアカウントでログインできるサービス」「ポストを自動投稿・収集するサービス」── これら全てのカテゴリで、事業継続コストが翌月から数十倍に跳ね上がりました。 このとき、X API依存のサービスを保有していた事業者が直面した選択肢は「高額プランに移行して耐える」「API使用を断念して機能を削除する」「サービスを閉鎖する」の3択でした。そしてその選択を迫られたのは、買収前に前オーナーがそのリスクを開示していなかった場合、買収後の新オーナーです。

2-2. 「Xログイン」「ポスト埋め込み」「データ収集API」── 機能別に潜む依存の洗い出しと、代替コストの現実

X APIへの依存は「Xで投稿するサービス」だけに存在するわけではありません。一見X連携とは無関係に見えるサービスでも、細部を掘ると依存が潜んでいます。①ソーシャルログイン（OAuth）：「Xでログイン」ボタンを実装しているサービスは、そのユーザーのログイン手段がX APIの可用性に依存しています。API有料化・廃止の際、既存ユーザーへのパスワード再設定フローの整備と移行コストが突然発生します。②ポスト埋め込み：メディアサイトやニュースサービスに多い「ポストの埋め込み表示」は、oEmbedエンドポイントへの依存を意味します。このエンドポイントが仕様変更された場合、過去記事の埋め込み部分が全て「コンテンツが表示されません」というエラー表示に置き換わります。③データ収集・分析：ソーシャルリスニングツール・口コミ分析サービス・トレンド分析機能を持つサービスは、X APIからのデータ取得が事業の根幹にある場合、有料化の打撃が最も深刻です。代替手段としてはエンタープライズプランへの移行か、BlueskyやMastodon等の別プラットフォーム対応への拡張か、機能の廃止かという選択になりますが、いずれも「コードの大規模改修」と「移行期間中の機能停止リスク」を伴います。

3. Google Maps API値上げという慢性的な出血 ── 「地図を使っているだけ」が月数十万円に化ける理由

3-1. 2018年・2023年の二度の価格改定が証明した「Googleロック」のコスト構造

Google Maps Platformの価格改定は2018年と2023年の2回、大きな波として業界を揺さぶりました。2018年7月の改定では、それまでアクセス数に関係なく無料で使えていたGoogle Maps APIが有料化され、多くのスタートアップが「無料で地図を使えた時代の終焉」を体感しました。この時点でGoogle Mapsに深く依存していたサービスは、月数万円から数十万円のコストが突然発生することになりました。そして2023年には再度の価格改定が実施され、「Places API」「Directions API」「Distance Matrix API」といった経路計算・施設情報系のAPIが対象となり、不動産サービス・グルメサービス・物流系サービスを直撃しました。Google Maps API依存の構造的な問題は「スイッチングコストの高さ」にあります。 OpenStreetMap・Mapbox・HERE Mapsといった代替選択肢は存在しますが、Google Mapsで構築したサービスのUIを別プロバイダーに移行するには、地図の表示ロジック・スタイリング・ジオコーディング・ルーティング全てを書き直す大規模な工数が発生します。依存度が高いほど交渉力はゼロに近い状態で価格改定を受け入れるしかない構造です。

3-2. リクエスト数・機能種別・スポット密度で変わる課金の罠 ── 「軽い機能のつもり」が請求書で数十倍に膨らむ仕組み

Google Maps APIの課金体系は、APIの種類ごとに単価が異なる複雑な構造になっています。2024年時点の参考値では、「Maps JavaScript API（地図表示）」は1,000リクエストあたり7ドルですが、「Places API（施設検索）」の「Nearby Search」は1,000リクエストあたり32ドル、「Place Details」は1,000リクエストあたり17ドルです。一見安く見える単価も、ユーザーが地図画面を開くたびに複数のAPIが並列で呼ばれる実装になっている場合、1回の画面表示で地図表示＋施設検索＋ルート計算が同時に発火し、実質的な1アクションのコストは単価の3〜5倍になります。「地図を置いているだけ」という認識の裏で、ユーザーの操作1回ごとに0.1〜0.5円が消費される仕組みが動いています。 月間10万UUのサービスでユーザー1人あたり平均5ページ地図関連画面を開く場合、月間50万リクエスト。Places APIを含めれば月額2万〜5万円の水準になりますが、月間100万UU規模のサービスになれば単純計算で月20〜50万円、スパイク時は100万円を超えます。売り手が「月数万円程度のコスト」と説明している数字が、過去の低トラフィック時代のものである可能性は常に疑う必要があります。

4. 2026年最前線：AI API依存という新種の時限爆弾

4-1. OpenAI・Claude・Gemini ── モデル廃止・価格改定・利用規約変更が「翌月から」発動する現実

2026年現在、M&A市場に登場するWebサービスの多くが「AI機能搭載」を売り文句にしており、その実態の大半はOpenAI・Anthropic（Claude）・Google（Gemini）のAPIを呼び出しているだけです。これ自体が問題なわけではありませんが、買い手が把握しておくべきリスクがあります。AIプロバイダーは過去2〜3年で毎年のようにモデルのバージョンアップと旧モデルの廃止を繰り返しています。 OpenAIの場合、GPT-3.5 TurboのレガシーAPIは段階的に廃止されており、サービスが「gpt-3.5-turbo-0301」という固定バージョンを指定したまま実装されていると、そのバージョン廃止とともにAPIエラーが全レスポンスで返り始めます。Anthropicも同様で、Claude 2系のAPIは既に廃止済みです。価格改定の頻度も高く、OpenAIは2023年以降に複数回の値上げと値下げを繰り返しており、AIコストの見通しは非常に立てにくい状態が続いています。AIモデルへの依存は「機能として優れている」と同時に「プロバイダーの価格・仕様変更リスクを丸ごと引き受けている」ことを意味します。

4-2. AI APIを原価に埋めたSaaSと、「粉飾に近い損益構造」の見抜き方

AI API依存のSaaSで最も注意すべき損益構造のパターンは、AI APIのコストが「原価」に計上されているにもかかわらず、そのコストの変動リスクが開示されていないケースです。SaaSの収益モデルは「月額固定課金」が主流ですが、AIの推論コストは「ユーザーがどれだけサービスを使うか」に比例して増加します。ユーザーがAI機能を積極的に使えば使うほど原価が膨らみ、固定の月額収益との差分が縮まります。売り手のIMに記載された粗利率が「70%」だったとしても、それが「直近3ヶ月のトラフィックが特に少なかった時期のデータ」であれば、通常月は粗利率50%を切る実態が隠れているかもしれません。AI API費用を含むSaaSのDDでは、「月次のAPIコスト推移×ユーザー数推移」を最低12ヶ月分並べ、コストとユーザー数の相関を確認することが必須です。 この相関が高い（ユーザーが増えるほどコストも増える）場合、スケール後の損益シミュレーションを抜本的に見直す必要があります。

4-3. 買収後に発覚する商用利用違反 ── APIの利用規約は「サービスの設計図」を制約している

APIには価格だけでなく「利用規約（Terms of Service）」が存在し、その内容はサービスの設計そのものを制約します。OpenAI APIの利用規約には、生成されたコンテンツを他者に帰属させること（AIが書いたのに人間が書いたと偽ること）の禁止、成人向けコンテンツ・ギャンブル・特定政治コンテンツへの利用制限が含まれます。Google Maps APIの利用規約には、競合サービスへの使用禁止や、オフライン利用・データのローカルキャッシュへの厳格な制限があります。問題は、売り手がこれらの利用規約を「把握した上で運営している」とは限らない点です。 初期のスタートアップフェーズに「とりあえず動くものを作ろう」と実装した機能が、規約違反のまま何年も運用されているケースは業界全体で見ると決して稀ではありません。買収後にAPIプロバイダーからアカウント停止の通告が届いた場合、サービスは即日停止します。利用規約のチェックはコードレビューと並行して行うべきDDの必須工程です。

5. APIリスクDDの実務 ── 買収前に完了させるべき5つの確認作業

5-1. ①依存APIの全数棚卸し ── 環境変数・コード・クラウド請求書から「見えない依存」を炙り出す手順

APIへの依存を把握するための出発点は3つの情報源です。第一に環境変数（.envファイルまたはサーバーの環境変数設定）：`_API_KEY`・`_SECRET`・`_TOKEN`という命名規則を持つ変数を全件リストアップするだけで、そのサービスが何のAPIに認証情報を持っているかが一覧化できます。第二にコード内の外部リクエスト先：`fetch()`・`axios.get()`・`requests.get()`等のHTTPリクエスト発生箇所を全件grep・rg（ripgrep）で検索し、リクエスト先のドメインを集約します。`api.openai.com`・`maps.googleapis.com`・`api.twilio.com`といったドメインが出現すれば、それが依存APIの証拠です。第三にクラウドプロバイダーの請求書（AWS Cost Explorer・GCP Billing等）と各APIプロバイダーの管理画面でのUsage Historyの12ヶ月分： これを並べると「何にいくら払っているか」の実態が初めて可視化されます。この3点セットを揃えた上で、各APIの「月額固定費用」「従量課金の変動幅」「無料枠の残量」「契約プランのランクアップ条件」を一覧表に整理するのが依存API棚卸しの完成形です。

5-2. ②利用規約の「改定条項」「商用利用制限」「レート制限」の精読 ── 見落とされがちな3つの地雷

APIの利用規約で重点的に確認すべきは3つの条項です。①改定条項（Amendment Clause）：多くのAPIプロバイダーは「事前通知なしに利用規約を変更できる」という条項を持っており、X（旧Twitter）の2023年改定はまさにこの条項を行使した事例です。「何日前の通知で利用規約を変更できるか」「価格改定に対して異議申し立て期間はあるか」を確認します。②商用利用制限（Commercial Use Restrictions）：無料プランで「非商用利用のみ可」と定めているAPIは多く、売り手が無料枠で運用していたサービスを商用利用している場合、規約違反になっているケースがあります。買収と同時に商用利用実態が確立されれば、プロバイダーから有料プランへの強制移行を求められます。③レート制限（Rate Limiting）とSLA（Service Level Agreement）：APIのレート制限は「現在の利用量で十分か」だけでなく「スケール後の利用量でも十分か」を試算します。SLAの稼働率保証と、SLA違反時のクレジット補償条件も確認してください。APIが落ちたときにサービスも落ちる依存構造がある場合、プロバイダーのSLA以上の稼働率をサービスとして保証することは不可能です。

5-3. ③代替手段の実現可能性と切り替えコストの試算、そして表明保証条項への実装

依存APIごとに「代替手段が存在するか」「切り替えにどれだけの工数とコストがかかるか」を試算することが、APIリスクDDの最終ステップです。Google Maps APIの代替はMapbox・HERE Maps・OpenStreetMap（Leaflet）が候補に挙がりますが、地図スタイルの再設定・ジオコーディング精度の差・モバイルSDKの対応状況などを検証すると、単純な「APIの差し替え」ではなく「地図機能の再実装」に近い工数になることが大半です。X APIの代替はMastodonやBlueskyのAPIが存在しますが、ユーザー基盤やデータ規模の差は歴然としており、「同等機能の提供」ではなく「機能の縮小・変更」を受け入れる必要があります。この切り替えコストの試算結果は、買収価格の交渉材料として、あるいは売買契約書の表明保証条項として実装することが可能です。 具体的には「本件サービスが利用する外部APIの利用規約は全て遵守されており、価格改定・廃止・利用停止に関する通知を受領していない」という表明保証を売り手に求め、違反が発覚した場合の損害賠償責任を売り手に帰属させる条項を設けます。さらに「APIコストが買収後12ヶ月以内に月額○○万円を超えた場合、超過分を売り手が補償する」というエスクロー条件を設定することで、買い手はAPIコスト爆発のリスクを財務的にヘッジできます。財務DDが「過去」を検証するとすれば、APIリスクDDは「未来の費用爆弾」を事前に封じ込める作業です。コードを読める技術者と、利用規約を読める法律家が並走しなければ、この爆弾は解除できません。財務系の仲介業者だけに任せたDDに、APIという現代の地雷を検出する能力はありません。