文字起こしをサービス化する：2026年にニッチSaaSを構築する

バーティカル型の文字起こしSaaSは、汎用型よりも守りやすい。 Otter.aiと機能で競うのではない。競っているのはワークフローの成果物——法廷速記のドラフト、ポッドキャストのショーノート、営業通話のスコアカード——だ。文字起こしAPIはエンジンであり、ニッチこそがプロダクトである。

このチュートリアルで構築するのはサービス層だ。ユーザーと文字起こしAPIの間に置かれる、キュー、リトライ、コスト計測、ホワイトラベル出力、課金である。APIそのものの統合方法については文字起こしAPIを使った開発を参照。顧客向けプロダクトではなく組織内ツールを作る場合は社内文字起こしツールの構築を参照。

ステップ1:ニッチを選ぶ

汎用の文字起こしは飽和市場だ。ユーザーが「テキスト」だけでなく「出力ワークフロー」にお金を払うニッチを選ぼう。

法廷速記者の支援。 法廷速記ソフトの入力形式に合わせた作業ドラフト。価格：速記者1人あたり月99〜299ドル。

ポッドキャスト制作。 エピソードから文字起こし、ショーノート、チャプターマーカー、SNS向け引用までワンクリックで。価格：番組1本あたり月29〜99ドル。

営業通話のコーチング。 営業担当者の通話を文字起こしし、発話時間比率、質問数、反論パターンで採点。価格：営業担当1席あたり月50〜150ドル。

ジャーナリズム系の学校のワークフロー。 自動引用とタイムコードリンク付きのインタビューコーパス。価格：機関契約で年5,000〜50,000ドル。

宗教コミュニティのアーカイブ。 週ごとの説教を、学習ガイド付きの検索可能な文字起こしとして公開。価格：教会・集会1つあたり月49〜199ドル。

パターンはこうだ:文字起こしは、そのユーザーがすでに必要としている成果物への入力である。法廷速記者専用に作られたツールにOtter.aiは対抗できない。放送ジャーナリスト専用のツールにTrint(ベンダーのドキュメントによればスタータープランは月80ドル前後から)は対抗できない。

ステップ2:コードを書く前にサービス層を設計する

ユーザー体験は「ファイルをアップロードし、『処理中』と表示され、結果を見る」という流れだ。その状態の間にあるサービス層に複雑さが集中する。

User browser
    |
Your Next.js API route
    |
Credit check (abort if insufficient)
    |
Upload to your S3/R2
    |
Enqueue job (Redis/BullMQ)
    |
Worker process
    |  -> Call transcription API
    |  -> Retry on failure (exponential backoff)
    |  -> Format niche output
    |  -> Write result to DB
    |
Webhook or polling updates your UI

この非同期設計は構造の要だ。文字起こしには10〜60秒かかる。それほど長い時間HTTPリクエストをブロックすると、サービスは脆くなり、ロードバランサーも壊れかねない。即座にジョブをエンキューし、ジョブIDを返そう。

ステップ3:ジョブキュー

RedisをバックエンドにしたBullMQは、このパターンにおけるNode.jsの定番選択肢だ。リトライ、指数バックオフ、デッドレターキュー、ワーカーの水平スケーリングを標準で備えている。

import { Queue, Worker } from 'bullmq';

const transcriptionQueue = new Queue('transcription', {
  connection: { url: process.env.REDIS_URL }
});

// Enqueue from your API route
export async function enqueueJob(userId, audioUrl, options) {
  const job = await transcriptionQueue.add(
    'transcribe',
    { userId, audioUrl, options },
    {
      attempts: 3,
      backoff: { type: 'exponential', delay: 2000 },
      removeOnComplete: { age: 3600 },
      removeOnFail: false  // keep failed jobs for inspection
    }
  );
  return job.id;
}

removeOnCompleteは積極的に設定しよう。1日に数千件のジョブを捌くキューでは、完了ジョブが溜まるとRedisのメモリが膨張する。失敗ジョブは、確認して消去するまで残しておくべきだ。

ステップ4:クレジット計測

users行にminutes_usedとminutes_limitのカラムを持たせる。デビット(引き落とし)はジョブ完了時ではなく、データベーストランザクションを使ってジョブ開始時に原子的に行う:

async function debitAndEnqueue(userId, estimatedMinutes, audioUrl, options) {
  return await db.transaction(async (trx) => {
    const user = await trx('users')
      .where({ id: userId })
      .forUpdate()
      .first();

    if (user.minutes_used + estimatedMinutes > user.minutes_limit) {
      throw new Error('QUOTA_EXCEEDED');
    }

    await trx('users')
      .where({ id: userId })
      .increment('minutes_used', estimatedMinutes);

    const jobId = await enqueueJob(userId, audioUrl, options);

    await trx('jobs').insert({
      user_id: userId,
      job_id: jobId,
      debited_minutes: estimatedMinutes,
      status: 'queued',
      created_at: new Date()
    });

    return jobId;
  });
}

ジョブが後で失敗したら、失敗ハンドラ内でデビット済みの分数を返金する。文字起こし前に正確な尺を取得できない場合は、控えめな推定値(ファイルサイズ÷平均ビットレート)を使い、完了時に実際の文字起こしの尺と突き合わせて精算する。

ステップ5:文字起こしワーカー

ワーカーは文字起こしAPIを呼び出し、失敗を処理し、結果をデータベースに書き込む。上流のプロバイダーがユーザーの目に触れることはない:

const worker = new Worker('transcription', async (job) => {
  const { userId, audioUrl, options } = job.data;

  await updateJobStatus(job.id, 'processing');

  const response = await fetch('https://api.convertaudiototext.com/v1/transcribe', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.CATT_API_KEY}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({ input_url: audioUrl, language: options.language || 'en' })
  });

  if (!response.ok) {
    throw new Error(`Transcription API error: ${response.status}`);
  }

  const result = await response.json();

  // Store raw result for reprocessing
  await db('transcripts').insert({
    job_id: job.id,
    user_id: userId,
    full_text: result.transcript,
    metadata: JSON.stringify(result),
    created_at: new Date()
  });

  // Run niche output layer
  const nicheOutput = await generateNicheOutput(userId, result, options.niche);

  await db('jobs').where({ job_id: job.id }).update({
    status: 'completed',
    niche_output: JSON.stringify(nicheOutput)
  });

}, { connection: { url: process.env.REDIS_URL } });

worker.on('failed', async (job, err) => {
  await refundUserMinutes(job.data.userId, job.data.estimatedMinutes);
  await updateJobStatus(job.id, 'failed', err.message);
});

BullMQはfailedハンドラを呼び出す前に、2秒、4秒、8秒の遅延を挟んで3回リトライする。failedハンドラは、返金とユーザー通知を一手に担う唯一の場所だ。

ステップ6:認証と課金

ほとんどのSaaSでは、定番のスタックで十分だ:

• 認証： Stack Auth、Clerk、Supabase Authのいずれか。マジックリンク+OAuth。
• 課金： プラン登録はStripe Checkout、セルフサービス操作はStripe Customer Portal。

ホスト型の課金サービスを使おう。課金をスクラッチで作るのは、チャージバックの脆弱性や監査の穴を持ち込みやすい、最もありがちな道だ。

最小限のStripeサブスクリプション設定:

import Stripe from 'stripe';
const stripe = new Stripe(process.env.STRIPE_SECRET);

app.post('/api/checkout', requireAuth, async (req, res) => {
  const session = await stripe.checkout.sessions.create({
    payment_method_types: ['card'],
    line_items: [{ price: req.body.priceId, quantity: 1 }],
    mode: 'subscription',
    success_url: `${process.env.APP_URL}/dashboard?paid=true`,
    cancel_url: `${process.env.APP_URL}/pricing`,
    customer_email: req.user.email,
    client_reference_id: req.user.id
  });
  res.json({ url: session.url });
});

app.post('/webhooks/stripe', express.raw({ type: 'application/json' }), async (req, res) => {
  const event = stripe.webhooks.constructEvent(
    req.body,
    req.header('Stripe-Signature'),
    process.env.STRIPE_WEBHOOK_SECRET
  );

  // Idempotency: skip if already processed
  const exists = await db('processed_stripe_events').where({ event_id: event.id }).first();
  if (exists) return res.sendStatus(200);

  if (event.type === 'customer.subscription.updated') {
    await updateUserSubscription(event.data.object);
    await db('processed_stripe_events').insert({ event_id: event.id });
  }

  res.sendStatus(200);
});

StripeのWebhookは最低1回(at-least-once)の配信だ。リトライストームの最中には、同じイベントが何度も届くことがある。処理済みのevent.idを保存しておき、状態を変更する前に重複を検知したらそこで処理を打ち切ろう。

ステップ7:ホワイトラベル出力

あなたのブランドだけがあってしかるべき3つの接点がある:

エクスポートファイル。 文字起こしの整形は自分で行う。APIから生の結果を取得し、自前のSRT/VTT/TXTフォーマッタに通し、自プロダクトの命名規則に沿ったファイル名で出力する。APIのエクスポートURLをユーザーに中継してはいけない。

メール通知。 「文字起こしができあがりました」の通知は、あなたのドメインから、あなたのメールプロバイダー経由で送る。API側に通知機能があったとしても、それはあなたのユーザーのためにあるのではない。

ストレージ。 アップロードされた音声は自前のS3またはR2バケットに保存する。ユーザーが後で元ファイルをダウンロードするときも、それはあなたのドメインから届く。文字起こしAPIのストレージは内部インフラだ。

正しく実装できれば、ユーザーが基盤の文字起こしプロバイダーの名前を目にすることは一度もない。

ステップ8:ニッチ出力層

文字起こしは入力にすぎず、ニッチ固有の成果物こそがプロダクトだ。

ポッドキャスター: 話題の転換を境にチャプターを抽出し、要約をもとにショーノートを書き、SNSで使いやすい引用を3つ拾い出す。ユーザーのCMSに合わせて整形したMarkdownファイルとしてダウンロード提供する。

ジャーナリズム系の学校： 抽出した引用を、音声再生にディープリンクするタイムコード付きで自動的に引用符付けする。引用コーパスを検索可能な形で保存し、学生がインタビューを横断して検索できるようにする。

セールスコーチ: 発話時間比率(セグメントごとの話者Aと話者Bの語数比)、質問頻度(「?」で終わる文の数)、ポーズの長さで上位3つの局面を算出する。営業担当者のスコアカードとして表示する。

法廷速記者: Case CATalystやEclipseといった法廷速記ソフトの入力形式に合わせたRTFで出力する。

独自開発の時間の大半を費やすのは、この出力層だ。文字起こしという問題そのものは、APIがすでに解決している。

競合となるもの

汎用の文字起こしツールは、表面上は確かな競合だが、特定のニッチの中では薄い競合にすぎない:

あなたのニッチツールは、会議機能でOtterに勝つ必要はない。勝つべきは、法廷速記ドラフト、ポッドキャストのエピソード一式、ジャーナリズムの引用コーパスの生成だ。Otterはそのどれにも取り組もうとすらしていない。

APIレベルでの詳細なコスト比較は、2026年の音声からテキストへのAPI料金と文字起こしの料金モデルの解説を参照。

SaaSの料金モデル

機能する3つのパターン:

席数制の月額課金。 アクティブユーザー1人につき月29〜99ドル。営業、ジャーナリズム、ポッドキャストなど、チームで使うツールに向く。

従量制の月額課金。 一定の時間数に対して毎月固定額。利用量が読める趣味層や小規模ビジネス向けのティアに向く。

機関契約の年額課金。 組織単位で年5,000〜50,000ドルの定額。学校、教会、法律事務所など、席単位の課金では予算調整がネックになる組織に向く。

私の見立て:まずは席数制の月額から始めるのがいい。一番説明しやすく、自然なアップセル導線になるからだ。同じ組織のユーザーが3人になり、請求の一括化を求められ始めたら、機関契約の料金を追加しよう。

小規模なうちは、ユニットエコノミクスはこちらに有利だ。API基盤をCATT Businessプラン(年払いで月47.99ドル、APIアクセスとWebhookを含む)で動かし、ニッチユーザー10人からそれぞれ月49ドルを徴収すれば、月490ドルの収入に対してインフラは約50ドル。11人目のユーザーの限界コストは、文字起こしの面では実質ゼロだ。

最初に作るもの

優先順に並べたMVP:

1. 認証(サインアップ、ログイン、メール認証)。
2. 自前のS3またはR2バケットへのファイルアップロード。
3. 基本的な分数台帳を備えたデビット&エンキュー関数。
4. 文字起こしAPIを呼ぶBullMQワーカー。
5. ジョブステータスのポーリングエンドポイント(またはフロントエンドへのWebhook)。
6. 文字起こし表示ページ。
7. ニッチ固有の出力を1つ(最初は最も簡単なものを選ぶ)。
8. 1プラン分のStripe Checkout。

集中すれば1〜2週間の開発量だ。リリースし、ユーザーを5人つける。2つ目のニッチ出力や2つ目の料金ティアを作る前に、実際の利用状況をもとに改善を回そう。

サービス層を丸ごと作らなくても、きれいな文字起こしさえ手に入ればいいというなら、ConvertAudioToTextがファイルからテキストへの変換を、サインアップ不要でその場でやってくれる。

集客(ディストリビューション)

プロダクトのほうが簡単な半分だ。

ニッチコミュニティ。 ポッドキャストツールは、ほかのどこよりも先に、ポッドキャスト関連のsubredditやDiscordサーバーに置かれるべきだ。ジャーナリズムツールなら、ジャーナリズム学科の教授に直接売り込む。

ニッチSEO。 「法廷速記者に最適な文字起こしツール」は、競合が少ない実在の検索クエリだ。コンテンツを書き、上位を取る。

パートナーシップ。 録音プラットフォーム、スケジュール管理ツール、CRMツールなど、ユーザー層が隣接する製品と組む。相互に宣伝し、紹介制度を提案する。

直接の働きかけ。 機関契約の料金は、管理者個人への個別の電話で。年10,000ドルの契約が1本結べれば、数か月分の開発時間の元は取れる。

「1000人の真のファン」モデルは、まさにここに当てはまる。月50ドルのニッチユーザー1,000人は60万ドルのARRであり、その背後にあるインフラのコストは月数百ドルにすぎない。

FAQ

CATTの文字起こしを自社ブランドで再販できますか?

はい。BusinessプランではAPIアクセスとWebhookが使えます。ユーザーに基盤となるプロバイダーは見えず、接するのはあなたのドメイン、あなたのブランド、そして出力ファイルだけです。文字起こしのフォーマット、エクスポートのファイル名、メール通知はすべてあなたが制御します。

途中で失敗したジョブはどう処理すればよいですか?

デッドレターキューのパターンを使います。最初の失敗時には指数バックオフ(2秒、4秒、8秒)でリトライします。3回失敗したら、ジョブを別の失敗キューに移し、正直なエラーメッセージでユーザーに通知します。デバッグ用に生のエラーもログに残してください。ジョブを黙って捨ててはいけません。

このインフラを最も安く運用する方法は?

MVPなら、VercelのhobbyティアでNext.jsのフロントエンドとAPIルートを無料で賄い、月6ドルのRedis Cloudインスタンスでキューをカバーし、月5ドルのVPSまたはRailwayワーカーでジョブ処理を行えます。文字起こしAPI以前のインフラコスト合計は、低ボリュームなら月10〜20ドル程度です。

クレジットテーブルなしでユーザーごとの利用量を計測するには?

必要なのはジョブ数ではなく、クレジット(分数)の台帳です。users行にminutes_usedとminutes_limitを持たせます。引き落とし(デビット)はジョブ完了時ではなく、開始時にデータベーストランザクションで原子的に行います。デビットに失敗したら、その場でジョブを拒否します。こうすることで、枠超過のジョブが実行された末に請求先がない、という事態を防げます。

出典

• Otter.ai 料金ページ - 2026年7月確認
• Rev.com 料金ページ - 2026年7月確認
• Sonix 料金ページ - 2026年7月確認
• Trint プランページ - 2026年7月確認
• ConvertAudioToText 料金ページ - 2026年7月確認
• BullMQ ドキュメント - 2026年7月確認
• Stripe Webhook ドキュメント - 2026年7月確認