営業チームの架電業務を立ち上げるにあたり、CTI(電話基盤)が必要になった。発信・着信、通話録音、文字起こし、通話内容のAI要約、リストへの自動架電 — いわゆるクラウドCTI SaaSが提供している機能群だ。

普通なら、ここはSaaS選定の場面である。実際、良くできたサービスが複数あり、相場は1席あたり月額数千円から1万円台。数名のチームでも年間では数十万円から百万円超になるが、従来の感覚ではそれでも自作よりはるかに安い。電話は失敗が許されない領域で、テレフォニーの専門知識も要る。「CTIを内製する」は、少し前なら検討にすら値しない選択肢だった。

今回は内製した。Twilio と Cloudflare Workers の上に、WebRTCソフトフォン、050番号での発着信、デュアルチャンネル録音、文字起こしと話者分離、LLMによる通話要約とネクストアクション抽出、留守電判定つきの自動架電、そして自社の営業管理ツールへの埋め込みまで作り、営業チームが毎日使っている。着手から最初の実架電までは数週間だった。

この記事は「内製できた自慢」ではなく、AI駆動開発によってBuild vs Buyの損益分岐がどこへ動いたのか、そして動いていないものは何かの整理である。

Build側のコスト構造で何が崩れたか

Build vs Buyの計算は、伝統的にはこうだった。

  • Buy: 初期費用 + 席数 × 月額。すぐ使える。カスタマイズはできない。
  • Build: 開発に数百万円〜 + 保守要員。要件は自由。ただし完成まで数ヶ月。

この計算の前提が、AI駆動開発で2箇所崩れた。

ひとつは開発費の桁だ。コーディングエージェントを前提にすると、CTIのような「枯れたドメイン+APIの組み合わせ」は非常に速く形になる。テレフォニーの難しい部分はTwilioが吸収しており、残りはWebhookの状態管理とUIである。これは前回の記事で書いた「エージェントは前例のあるパターンの再現が得意」の典型例で、従来なら受託で数百万円規模の見積もりになる開発が、実働ベースでは桁が変わる。

もうひとつはランニングの構造だ。席数課金が消え、残るのはTwilioの従量課金(通話分数)とエッジ基盤の実費だけになる。サーバ運用も、前回書いた通りエッジ基盤ではほぼ発生しない。つまり内製版は「席を増やしても固定費が増えない」構造になり、チームを拡大するほどSaaSとの差が開いていく。

損益分岐の考え方はシンプルで、**「SaaSの年額」対「内製の初期実働 + 従量費」**の比較になる。分岐点は従来「よほど席数が多い企業」にあったが、いまは数名規模でも十分に交差しうる位置まで下がってきている。

ただし、内製の「本当のコスト」は運用に出る

ここからが本題で、この記事で一番書きたかった部分だ。内製のコストは開発費ではなく、運用で払う。

実際に本番運用してみると、障害は起きる。実例を挙げると —

  • 「通話の音質が悪い」という報告を受け、録音をチャンネル別に実測分析したところ、原因は回線ではなく話し手側の背景ノイズだった。ノイズ抑制の導入まで含めて対応した
  • 「相手の声が聞こえない」という報告では、通話自体は成立しレコーディングにも双方の声が入っており、原因は特定のブラウザの音声再生層にあった。切り分けのために、通話品質の自動診断と自己修復の仕組みまで作ることになった
  • 折り返し着信の取り逃しが発覚し、着信ルーティング(在席メンバーへの一斉呼び出し→不応答時のオフィス転送)を即日実装して塞いだ

SaaSならこれらはサポート窓口に投げる話だ。内製では、サポート窓口は自分である。ここを見落としてBuildに倒すと、開発費で浮いた分を障害対応の混乱で払うことになる。

ただし、ここにもAI駆動の効きどころがある。上記の障害はいずれも、調査から修正の本番反映まで当日〜数日で完結した。障害対応そのものがエージェントで高速化されているからだ。そしてもうひとつ重要なのは、「直せる」こと自体の価値である。現場から「こうしてほしい」が出たとき、SaaSなら要望チケットとして送って終わりだが、内製なら当日入れられる。実際、このCTIの機能の半分は、運用開始後に現場の報告から生まれた。

判断基準の整理 — それでもBuyが正解なケース

経験を基準に落とすと、こうなる。

いまでもBuyが正解なのは:

  • その業務が自社の差別化に関係なく、標準的な使い方で足りる
  • 落ちたときに責任を取れる運用者が社内にいない
  • 通信・セキュリティ等のコンプライアンス要件を自前で背負いたくない

Buildが現実解になったのは:

  • 業務プロセスや既存システムと深く結合させたい(今回は営業管理ツールへの埋め込みが決め手だった)
  • 通話データを自社のデータ基盤・AIパイプラインに流し込みたい
  • 席数・利用量が多く、従量構造にするだけで大きな差が出る
  • 要件がSaaSの標準機能の枠に収まらない

そして最大の変数は、機能でも価格でもなく、AIハーネスを設計・運用できる人間が社内か手の届く範囲にいるかだ。いなければ、上に挙げた運用コストが臨界を超える。いるなら、Build側の選択肢は従来の常識よりずっと広い。

Build vs Buyは「どちらが安いか」の問いではなくなった

まとめると、AI駆動開発が変えたのは「作るのが安くなった」という単純な話ではない。「買う」が業務をツールに合わせる選択であり続けるのに対し、「作る」がツールを業務に合わせる現実的な選択肢に戻ってきた、ということだ。

SaaSの標準機能で足りるなら買えばいい。ただ、これまで「本当はこうしたいが、SaaSがそうなっていないから諦める」で済ませてきた部分があるなら、その前提は一度疑う価値がある。分岐点は、多くの人が思っているよりずっと手前まで来ている。

自社のケースでBuild/Buyどちらに分があるか、といった個別の検討は、ご相談の場で話せる範囲でお伝えできる。