Webサービス売却で効く第三者API依存
Webサービスの売却交渉で、買い手側のエンジニアが最初に開くのは、事業計画書でもP/Lでもありません。ソースコードを受け取って、決済ベンダーのSDKが何箇所から呼ばれているかを数える。やることはそれだけで、数分あれば終わります。そして、この数分の作業で、その事業に付く値段の上限がだいたい決まってしまいます。
意外に思われるかもしれませんが、第三者のAPIに依存していること自体は、減点にはなりません。2026年のWebサービスで、決済も地図も認証も通知もすべて自前で組んでいる事業があったら、買い手はむしろそちらを心配します（その車輪の再発明に何人月を溶かしたのか、と聞きたくなるからです）。依存は前提であって、論点ではないのです。
では買い手は何を見ているのか。「今いくらで動いているか」ではなく、「相手の都合が変わったときに、逃げられるか」です。この記事では、その逃げられるかどうかが設計のどこで決まるのか、そしてコードをどれだけ綺麗に整えても逃げられない領域がどこに残るのかを、決済・認証・通知・地図という、どのWebサービスにもある第三者APIを題材に整理していきます。
買い手が数えているのは、APIの数ではなく呼び出し箇所の数
技術資料に「利用している外部サービス一覧」が丁寧に載っていることがあります。決済はこれ、メール配信はこれ、地図はこれ、と整然と並んでいる。売り手としては誠実な開示のつもりですし、実際その姿勢は正しいのですが、買い手が本当に知りたいことは、その一覧には書かれていません。
知りたいのは、そのSDKがコードのどこから、何箇所から呼ばれているかです。ベンダー名でリポジトリ全体を検索して、ヒットが3ファイルなのか、80ファイルなのか。この数字が、そのままベンダーを差し替えるときの改修範囲になります。
3ファイルなら、そのベンダーは「使っている部品」です。80ファイルなら、そのベンダーは「事業の一部」です。前者は取り替えられますが、後者は取り替えられません。同じ「決済にはあのサービスを使っています」という一文が、実態としてはまったく違う二つの事業を指しているという事態が、平然と起きます。
そして厄介なことに、この数字は事業計画書には絶対に出てきません。売上にも粗利にも表れない。にもかかわらず、買収後にその事業を動かし続ける難易度を、ほぼ一意に決めてしまいます。買い手のエンジニアが真っ先に検索窓を叩くのは、そういう理由です。
SDKがドメインロジックに埋まった事業は、交渉の席に着けない
呼び出し箇所が多いことの何が問題なのか。「改修が大変」で終わる話ではありません。もっと構造的な話です。
ベンダーのSDKをドメインロジックに直接埋め込むと、そのベンダーのデータ構造が、事業の言葉として定着していきます。注文の状態を決済ベンダーの用語で持ち、Webhookのペイロードをそのまま業務ロジックへ流し、ベンダー固有のIDを自社テーブルの主キー相当として扱う。個々の判断はどれも合理的ですし、実際その方が早く動きます（動くものを早く出すのは、事業としては正しいことです）。
問題が表面化するのは、相手の都合が変わった日です。価格が改定される。仕様が変わって旧エンドポイントが廃止される。あるいはサービス自体が終了する。APIの利用停止が事業を直撃する構図はよく語られますが、実務でより頻繁に効いてくるのは、もっと地味な瞬間です。
それは、値上げの通知メールを受け取ったとき、飲む以外の選択肢が存在しないと気づく瞬間です。
移れる事業にとって、値上げは検討事項です。他社と比較して、移行工数と差額を天秤にかけ、場合によっては交渉材料にすらできる。移れない事業にとって、値上げは決定事項です。原価が上がりましたという事実だけが残ります。これは技術の問題であると同時に、その事業が持っている交渉力の問題なのです。
買い手は、この交渉力を買えるのか、それとも最初から存在しないのかを見ています。ベンダーの価格改定に対して打つ手のない事業を買うということは、買収後の粗利をベンダーの経営判断に晒し続けるということであり、自社でコントロールできない変数を丸ごと抱え込むことを意味します。
抽象化レイヤーとは何であって、何ではないのか
ここで出てくるのが抽象化レイヤーという言葉です。ただ、この言葉は現場でかなり雑に使われていて、売り手と買い手で認識がズレやすいところなので、はっきりさせておきます。
ラッパー関数を1つ作ることではない
よくある誤解が、ベンダーのSDKを呼ぶ関数を1つ用意して、そこを経由させれば抽象化だ、というものです。これは抽象化ではなく、ただの短縮記法です。
判定は簡単で、そのインターフェースの定義に、ベンダーの語彙が出てくるかどうかを見ます。関数名が createStripeCharge() なら抽象化されていません。引数の型がベンダーSDKのオブジェクトなら、されていません。戻り値がベンダーのレスポンスをそのまま返しているなら、されていません。名前だけ自社風に付け替えたところで、境界を跨いでベンダーの型が流れているなら、結合はそのまま残っています。
自社の言葉でインターフェースを定義することである
本来の抽象化は、逆方向から設計します。自社の事業が必要としている操作を、自社の言葉で先に定義し、ベンダーはその実装として後から嵌める。「この注文に対して、この金額を、この手段で請求する」という自社の関心事だけがインターフェースに現れ、それをどのベンダーがどう実現しているかは、境界の内側に閉じ込められます。
この設計になっていると、ベンダー差し替えの作業は「実装をもう1つ書く」に縮みます。80箇所を直す話が、1箇所を足す話になる。改修範囲が線形から定数に落ちるわけですが、効いてくるのは工数の削減だけではありません。「試しに繋いでみる」ができるようになることの方が、はるかに大きいのです。移行の意思決定の前に、移行の実験ができる。この差が、後で効きます。
境界が実在するかを確かめる方法
売り手が自分の事業を点検するとき、いちばん確実な問いはこれです。ベンダーのSDKをモックに差し替えて、テストが通りますか。
通るなら、境界は実在しています。通らないなら、あるいは「そもそもそのテストがない」なら、境界は設計書の中にしか存在しません。抽象化してあると主張する事業のうち、この問いで沈黙するものは、実はかなりの割合を占めます（図の上では確かに層が描かれているのですが、コードの上では層を跨いで直接呼んでいる箇所が何食わぬ顔で残っている、という状態です）。
コードを整えても移れない領域がある
ここまでは、やろうと思えば売り手の努力で解決できる話でした。ここからが本題です。
抽象化レイヤーは、移れることの必要条件であって、十分条件ではありません。コードを教科書どおりに綺麗に分離しても、それでも移れないAPIが存在します。理由は単純で、移すべきものがコードの中ではなく、ベンダーの側に溜まっているからです。
ここを見落としたまま「うちは抽象化してあるので大丈夫です」と胸を張ると、その直後に買い手のエンジニアから一番痛いところを突かれることになります。
決済 ── カード情報は自社の金庫にない
決済が最も重い理由は、コードの構造とはまったく無関係です。カード情報を自社で保持しないという、業界標準に沿った正しい設計を選んだ結果として、顧客のカードは自社ではなく決済ベンダーの側にトークンとして存在しています。そしてそのトークンは、そのベンダーの中でしか意味を持ちません。
つまり、継続課金を抱えたサブスクリプション事業が決済ベンダーを替えるということは、コードを書き換える話ではなく、顧客のカード情報そのものを移送する話になります。移行の仕組み自体は主要ベンダーに用意されていますが、移管元の協力とベンダー側の審査を伴う手続きであり、自社の意思だけで完結しません。「明日から別のベンダーで」ができない領域だということです。
加えて、決済ベンダーの利用は加盟店審査を通ることが前提です。M&Aで運営主体が変わるということは、審査を受けた法人が変わるということでもあります。Stripeをはじめとする決済事業者の本人確認・再審査が買収直後の資金繰りに直接効いてくるのは、このためです。抽象化レイヤーが何層あろうと、この壁は1ミリも低くなりません。
認証 ── ユーザーIDの正体はベンダー固有の文字列
認証も、コードの綺麗さでは救われない領域です。
外部の認証基盤を使っている場合、自社のDBに保存されているユーザーIDは、たいていそのベンダーが発行した文字列です。ベンダーを替えれば、その文字列は意味を失います。パスワードハッシュをエクスポートできるかどうかはサービスによって扱いが異なりますし、仮に取り出せたとしても、移行先で同じハッシュ方式を再現できなければ、全ユーザーにパスワードの再設定を強いることになります。既存ユーザーへ一斉メールを送って「お手数ですが再設定をお願いします」と頼む移行で、いったい何割が戻ってくるのか。買い手はその歩留まりを想像します。
ソーシャルログインが絡むと、さらに厄介です。事業者ごとに発行される識別子は、発行元と紐づいて初めて意味を持つため、認証基盤の乗り換えは「既存アカウントの同一性をどう保つか」という問題に直結します。Firebaseプロジェクトの移管が単なるデータのコピーで終わらないのも、まったく同じ構造です。
通知 ── レピュテーションは誰に付いているのか
メール配信では、事情が少し変わります。信用の一部は自社のドメインに付いていて、一部はベンダーに付いているという、分割された状態になっているからです。
送信ドメインの認証設定は自社側の資産なので、ここは持って動けます。一方、共有IPプールから送信している場合、そのIPの評判はベンダーの持ち物です。乗り換えれば、新しいIPからの送信実績をゼロから積み直すことになります。届いていたメールが届かなくなる期間が発生し得る、ということです。
プッシュ通知は、デバイストークンをOS側のプラットフォームが発行しているため、配信ベンダーの乗り換え自体は比較的軽い部類に入ります。ただし、そのトークンがどの単位に紐づいて発行されているかによって難易度が変わるため、「プッシュだから軽い」と一括りにはできません。
地図 ── ほとんど何も溜まらない、という対極
対極にあるのが地図やジオコーディングです。緯度経度を問い合わせて返ってくるだけで、ベンダー側に自社の資産が蓄積されていく構造がありません。だから移りやすい。
ただし、ここには逆向きの制約があります。地図系のAPIには、取得した結果の保存・再利用について利用規約上の制限が置かれているのが一般的です。溜まらないから移りやすいのですが、同時に「溜めてはいけない」から移りやすいとも言えます。手元にデータが積み上がらないので、乗り換えても失うものがない代わりに、そのAPIを使い続ける限り独自のデータ資産も育ちません。移りやすさと資産性は、しばしば裏表です。
API別に「移りやすさ」は格付けできる
ここまでを整理すると、第三者APIの移りやすさは、2つの軸で決まることが分かります。
- コード側の結合度: 呼び出し箇所の数と、境界の有無。売り手が自力で下げられる軸です。今日から着手できます
- ベンダー側の状態滞留: そのベンダーに、自社の資産（顧客のカード、ユーザーの同一性、送信実績）がどれだけ預けられているか。売り手が自力では下げられない軸です。設計時点と契約で、ほぼ決まってしまっています
この2軸で並べると、だいたい次のような順序になります。
- 決済: 結合度・状態滞留ともに最大。トークンの移送・加盟店審査・継続課金の3つが重なる、最も重い領域
- 認証: 状態滞留が大きい。ユーザーの同一性そのものが預けられている
- メール配信: 中程度。SPF・DKIM・DMARCを自社ドメインで正しく持っていれば、信用の主要部分は手元に残る
- プッシュ通知: 中〜軽。デバイストークンの紐づき先次第
- ストレージ・地図・ジオコーディング: 軽い。状態がほとんど溜まらない
この格付けが実務で効くのは、限られた時間をどこに使うかを決められるからです。抽象化レイヤーを全部のAPIに入れる必要はありません（そんな時間はどこの現場にもありません）。状態滞留が重い順に、境界を作る。決済と認証だけ手当てして、地図はSDKを直接呼んでいて構わない。買い手も同じ順序で見ているので、優先順位は自然と噛み合います。
売り手が売却前にやっておくこと
Webサービスの売却を考え始めた段階でやるべきことは、3つです。どれも数日で終わります。
1. 呼び出し箇所を数えて、数字で言えるようにする
まず各ベンダーのSDKが何箇所から呼ばれているかを数えます。リポジトリ全体を検索するだけなので、10分もかかりません。
大事なのは、この数字を買い手に聞かれる前に自分で知っておくことです。「決済は3ファイルからしか呼んでいません」と即答できる売り手と、「たぶん整理されていると思います」と答える売り手とでは、そのあとの技術的DDの空気がまったく変わります。数字を持っている売り手は、自分の事業を把握している売り手として扱われます。逆もまた然りで、この程度の数字が出てこない事業は、他も推して知るべしと見なされます。
2. 「移行できる」を実証しておく
設計図で説明するより、はるかに効く方法があります。ステージング環境で、実際に別のベンダーへ繋いでみることです。
本番を移行する必要はありません。一度でも別実装を書いて動かした事実があれば、それは「移れる」の証明になります。逆に、一度も試したことのない移行計画は、どれだけ精緻に書かれていても仮説にすぎません（そしてこの手の仮説は、実際にやってみるとだいたい想定の2倍かかります）。
3. 契約の名義移管可否を確認しておく
技術の話ばかりしてきましたが、契約側にも同じ重さがあります。エンタープライズ契約や個別の料金体系を結んでいる場合、その条件が運営主体の変更後も維持されるのかを、契約書で確認しておく必要があります。
ここが確認されていないと、買い手は最悪ケースを前提に計算します。「今の単価は引き継げないかもしれない」と思われた時点で、その差額分は価格から引かれます。確認したうえで「引き継げます」と示せるなら、その数時間の作業が、数十万円以上の価値を生むことになります。
買い手が査定に織り込む方法
買い手側から見ると、確認の要諦は1つです。質問ではなく、実演で確かめること。
「ベンダーロックインは大丈夫ですか」と聞けば、返ってくる答えはほぼ確実に「抽象化してあるので大丈夫です」です。この質問には情報量がありません。代わりに聞くべきは、次の3つです。
- 「このSDKは何箇所から呼ばれていますか。今この場で検索してもらえますか」 ── 結合度が数字で出ます
- 「決済ベンダーをモックに差し替えて、テストは通りますか」 ── 境界が実在するかが出ます
- 「過去に一度でも、別のベンダーに繋いでみたことはありますか」 ── 移行が仮説なのか実証なのかが出ます
そのうえで、査定への織り込みは次のように整理できます。
- 結合度が低く、状態滞留も軽い: この論点で減点する理由はありません。むしろ設計時点でベンダーリスクを認識していた事業として、加点材料になります
- 結合度は高いが、状態滞留は軽い: 改修工数の問題に還元できます。工数を見積もって価格に反映すれば済む話で、致命傷ではありません
- 状態滞留が重い: これは価格の割引で処理する話ではありません。その事業は、そのベンダーごと買うことになるという前提を受け入れたうえで、ベンダー側の審査・移管手続きが完了することを支払いの条件に紐づけるなど、契約の側で手当てすべき論点です
3つ目を「安く買えばいい」で処理しようとすると、買収後に自分がそのロックインを丸ごと引き受けることになります。割引はリスクを消してくれません。移すだけです。
依存は罪ではない、逃げ道がないことが罪になる
第三者APIを使うのは、正しい判断です。決済を自前で作るべきではないし、地図を自前で持つ理由もないし、認証を自作して脆弱性を仕込むくらいなら専業の基盤に任せた方がずっと安全です。買い手も、そんなことは百も承知しています。
問われているのは、依存しているかどうかではありません。その依存が、いつか必ず来る「相手の都合が変わる日」を前提に設計されているかどうかです。ベンダーは値上げします。仕様を変えます。事業から撤退することもあります。それは相手の正当な経営判断であって、恨む筋合いのものではありません。ただ、その日に自分に何ができるかは、その日が来るずっと前の、設計の瞬間に決まっています。
そして、この論点が売り手にとって残酷なのは、売ると決めてから直せる部分と、直せない部分がはっきり分かれていることです。呼び出し箇所の整理は、数ヶ月あれば間に合います。しかし、決済ベンダーにトークンを預けたという事実も、ユーザーの同一性を外部の認証基盤に委ねたという事実も、売却を決めた日には既に何年も前の決定になっています。過去には遡れません。
だからこそ、この話は売却の直前ではなく、APIを1本目に選ぶ日にしておくべき話なのです。境界を1枚挟んでおく。その判断は、その日には何の得にもなりません。動くものが早く出るわけでもないし、機能が増えるわけでもないし、誰にも褒められません。ただ、何年か後に自分の事業に値段が付く日、その1枚が「逃げられる事業」と「逃げられない事業」を分けています。
自分が何年もかけて作ったサービスを、正当な値段で手放せるかどうか。それを決めているのは、売上でも、ユーザー数でも、成長率でもなく、他人の都合に対して、自分の手元に選択肢が残っているかという、たったそれだけのことなのかもしれません。
第三者APIへの依存度を把握できたら、それを踏まえた売却額の目安が気になります。Webサービス売却の無料査定で、想定売却額のレンジを試算できます（登録不要）。
