GTMエンジニアの技術選定フレームワーク -- 事業ドメインとコストで決めるインフラ設計

この記事の位置づけ

前回の記事では、GTMエンジニアリングの技術スタックを4層モデル（データ収集→AI処理→オーケストレーション→CRM出力）で整理した。この記事では一段深く踏み込み、インフラ層をどう選定するかのフレームワークを提示する。

GTMエンジニアの技術選定は、プロダクトエンジニアのそれとは判断基準が異なる。「最新のフレームワーク」や「コミュニティの活発さ」ではなく、事業ドメインの特性とコストの予測可能性から逆算して決める。

GTMエンジニアの技術選定は何が違うのか

プロダクトエンジニアとの判断基準の差

プロダクトエンジニアの技術選定では、スケーラビリティ、開発体験、エコシステムの成熟度が重要視される。GTMエンジニアは別の軸で判断する。

コストの予測可能性が最優先

営業組織の予算は四半期単位で固定されることが多い。「トラフィック次第で月額が3倍になる」インフラは営業責任者の承認を得にくい。月額固定か、少なくとも上限が予測できる構成が好まれる。

営業チームのワークロードに合わせたピーク設計

プロダクトのトラフィックはユーザーの行動パターンに依存する。GTMエンジニアが扱うシステムのピークは営業チームの活動時間に連動する。平日9時-18時にAPIコール集中、週末はほぼゼロ。この特性がインフラ選定に直結する。

「最高」ではなく「十分」を選ぶ

GTMの文脈では、レスポンスタイムが50msか200msかは問題にならないことが多い。CRMへの書き込みが2秒以内に完了すれば営業は気にしない。過剰な性能に投資するより、同じ予算でカバーする業務範囲を広げるほうが事業インパクトが大きい。

営業組織への説明コスト

技術に明るくないステークホルダーに対して「なぜこのインフラか」を説明する場面が多い。「月額$X固定で、Y件のリード処理ができる」という説明ができる構成が望ましい。

TypeScriptフルスタックという選択

GTMエンジニアがTypeScriptを共通言語にする理由は、フロントエンドが得意だからではない。全レイヤーを1つの言語で統一することで生まれる運用効率のためだ。

TypeScriptで書けるレイヤー

フルスタックTypeScriptの実務上のメリット

型定義の共有: CRMのコンタクトデータの型をフロントエンドとバックエンドで共有できる。HubSpotのコンタクトプロパティをContactProperties型として定義すれば、API層でもダッシュボードでも同じ型が使える。

typescript
// shared/types/hubspot.ts -- フロントエンドとバックエンドで共有
interface ContactProperties {
  email: string
  company: string
  ai_score: number
  ai_hypothesis: string
  lifecycle_stage: 'subscriber' | 'lead' | 'mql' | 'sql' | 'opportunity' | 'customer'
  last_enriched_at: string
}

学習コストの最小化: GTMエンジニアがチームに加わったとき、Python + Go + TypeScriptの3言語を求めるより、TypeScript 1本で済むほうが立ち上がりが速い。GTMエンジニアリングは採用市場が未成熟なため、即戦力の数が限られる。学習コストの低さは採用戦略上も重要。

ランタイムの柔軟性: 同じTypeScriptコードを、Cloudflare WorkersでもAWS LambdaでもVercelでもBunでも動かせる。インフラを切り替える際にアプリケーションコードの書き換えが最小限で済む。

技術選定マトリクス: 事業ドメイン×インフラ

判断フローチャート

[APIリクエストの応答速度が重要？]
  ├─ YES → [グローバルユーザーがいる？]
  │         ├─ YES → Cloudflare Workers
  │         └─ NO  → [既存AWSインフラがある？]
  │                   ├─ YES → AWS Lambda
  │                   └─ NO  → Cloudflare Workers
  └─ NO  → [処理時間が15分を超える？]
            ├─ YES → EC2 / 自前サーバー
            └─ NO  → [営業チームが直接操作する？]
                      ├─ YES → n8n（セルフホスト）
                      └─ NO  → [SSR/ISRが必要？]
                                ├─ YES → Vercel
                                └─ NO  → Cloudflare Workers

コスト比較: 3つの実ケース

概算は2026年3月時点の公開価格に基づく。為替は1ドル=150円で計算。

ケース1: 月間10万APIコールのリードエンリッチメントAPI

CRMからのWebhookを受信し、リード情報を外部データソースで補完してCRMに書き戻すAPI。

推奨: Cloudflare Workers。月間10万コール程度なら無料枠で収まる。APIのエンドポイントが増えても追加コストは発生しにくい。

ケース2: 月間100万PVの営業向けダッシュボード

リアルタイムのパイプライン状況、リードスコア、営業KPIを表示する社内ダッシュボード。

推奨: 社内ダッシュボードならCloudflare Pages + Workers。帯域無制限で予算が読みやすい。外部公開するプロダクトページならVercel Proの開発体験が優位。

ケース3: 月間1万通のパーソナライズドメール送信ワークフロー

リード情報をもとにAIでメール文面を生成し、メールシーケンスツール経由で送信するワークフロー。

推奨: n8nセルフホスト。月$5-10でワークフロー実行回数の制限がない。営業チームがフローを確認・微調整できるUIがある点も重要。Make/Zapierはオペレーション課金で月間コストが読みにくい。

3ケースに共通するパターンがある。

GTMインフラのコスト原則:
  1. サーバーレス × エッジ → 低トラフィック時にコスト最小
  2. セルフホスト → 実行回数に連動しない固定コスト
  3. マネージドSaaS → DXは高いがスケール時にコスト増
  4. 月額の予測可能性 → 営業予算との整合性

GTMエンジニアリングに特有の技術要件

プロダクト開発と共通する部分は多いが、GTM固有の技術要件がある。

CRM APIのレート制限

GTMエンジニアが最も頻繁にぶつかる技術的制約はCRM APIのレート制限だ。

どれだけ高速なインフラを用意しても、CRMのレート制限がボトルネックになる。これがインフラ選定に与える影響は実際には大きい。

typescript
// CRMレート制限に対応するキュー処理
// Cloudflare Workers + Durable Objects の場合
export class CrmRateLimiter {
  private queue: CrmRequest[] = []
  private processing = false

  async enqueue(request: CrmRequest): Promise<void> {
    this.queue.push(request)
    if (!this.processing) {
      await this.processQueue()
    }
  }

  private async processQueue(): Promise<void> {
    this.processing = true
    while (this.queue.length > 0) {
      const batch = this.queue.splice(0, 100) // HubSpot: 100件/バッチ
      await this.sendBatch(batch)
      await this.wait(1000) // 10秒あたり110リクエストを超えないよう調整
    }
    this.processing = false
  }
}

データのリアルタイム性 vs バッチ処理

GTMのデータ処理は、リアルタイムとバッチの使い分けが重要になる。

この使い分けがインフラ構成に反映される。リアルタイム処理にはCloudflare WorkersやAWS Lambda、バッチ処理にはn8nのスケジュールトリガーやAWS EventBridgeが適する。

営業チームのアクセスパターン

GTMシステムのトラフィックパターンはプロダクトと大きく異なる。

営業チームの典型的なアクセスパターン:

  月-金 09:00-10:00  █████████  ピーク（朝のCRM確認）
  月-金 10:00-12:00  ██████     通常負荷
  月-金 12:00-13:00  ██         昼休み
  月-金 13:00-17:00  ██████     通常負荷
  月-金 17:00-18:00  ████████   ピーク（日報・翌日準備）
  月-金 18:00-22:00  ██         低負荷
  土-日              █          ほぼゼロ

このパターンはサーバーレスアーキテクチャと相性が良い。平日の業務時間にのみ課金が発生し、夜間・週末のコストがゼロに近づく。常時起動のサーバーは週末も課金される。

個人データ保護への対応

GTMエンジニアはリード情報（氏名、メールアドレス、企業情報、行動履歴）を扱う。個人情報保護法やGDPRへの対応がインフラ選定に影響する。

日本市場では個人情報保護法の2022年改正が適用される。外国にある第三者への個人データ提供には本人の同意が必要。これは海外SaaSを使う際の制約になる。n8nをセルフホストする理由の1つがここにある。

実践例: 3つの事業パターン

パターンA: スタートアップのSaaS（ARR $1M未満）

前提: 従業員20名、営業3名。HubSpot Free→Starterで運用中。リード数は月500件程度。

アーキテクチャ:

┌─────────────────────────────────────────────────────┐
│                  Cloudflare Workers                   │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐           │
│  │ Webhook  │  │ Enrichment│  │ Scoring  │           │
│  │ Receiver │→│ Worker    │→│ Worker   │           │
│  └──────────┘  └──────────┘  └──────────┘           │
│       ↑              ↓              ↓                │
│       │         Cloudflare KV   Cloudflare KV        │
│       │         (cache)         (scores)             │
└───────┼──────────────┼──────────────┼────────────────┘
        │              │              │
   [HubSpot]     [Clay API]     [HubSpot]
   Webhook        Enrichment     Update

構成要素:

• Cloudflare Workers: Webhook受信、エンリッチメント、スコアリング
• Cloudflare KV: キャッシュ、スコア保存
• Hono: Workers上のAPIフレームワーク
• HubSpot API: CRM読み書き
• Clay API: データエンリッチメント

月額コスト概算:

選定理由: スタートアップ段階ではコスト最小化が最優先。Cloudflare Workersの$5/月でAPI基盤が構築でき、トラフィック増加にも対応できる。HonoをフレームワークにすることでWorkers上でもExpress風のコードが書ける。

パターンB: Mid Market向けSaaS（ARR $5-20M）

前提: 従業員100名、営業15名。Salesforce Enterprise。月間リード数5,000件。社内ダッシュボードと営業支援ツールが必要。

アーキテクチャ:

┌──────────────────────────────────────────┐
│             Vercel (Next.js)              │
│  ┌────────────┐  ┌────────────────────┐  │
│  │ Dashboard  │  │ API Routes         │  │
│  │ (SSR/ISR)  │  │ (Serverless Fn)    │  │
│  └────────────┘  └────────────────────┘  │
│       ↓                    ↓              │
└───────┼────────────────────┼──────────────┘
        │                    │
   [Vercel KV]         ┌────┴────┐
   (session/cache)     │         │
                  [Salesforce] [n8n]
                   REST API    (Railway)
                                 │
                        ┌────────┼────────┐
                        │        │        │
                   [Clay API] [Claude] [Slack]
                               API      API

構成要素:

• Vercel: Next.js App Router。営業ダッシュボード + API
• n8n（Railway）: ワークフロー（エンリッチメント→スコアリング→CRM更新→Slack通知）
• Salesforce: CRM。カスタムオブジェクトでAIフィールドを管理
• Claude API: リードスコアリング、課題仮説生成

月額コスト概算:

コスト構成を見ると、Salesforceのライセンス費がインフラ費の大半を占める。Vercel + n8nのインフラコストは$25/月に過ぎない。GTMエンジニアの技術選定では、インフラ費よりSaaS費のほうが支配的になるケースが多い。

選定理由: Vercelを選ぶのはNext.jsとの統合によるDXの高さ。営業ダッシュボードはISR（Incremental Static Regeneration）で1時間ごとに再生成し、APIコールを最小化。n8nはSalesforce APIのレート制限を管理しつつ、非エンジニアの営業マネージャーもフロー確認できる。

パターンC: エンタープライズ向け（ARR $50M+）

前提: 従業員500名、営業50名。Salesforce + kintone（一部部門）。月間リード数20,000件。VPC内にデータを閉じる必要がある。オンプレミスとの接続要件あり。

アーキテクチャ:

┌──────────────────── AWS VPC ────────────────────┐
│                                                   │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐       │
│  │ API GW   │→│ Lambda   │→│ SQS      │       │
│  │ (REST)   │  │ (Hono)   │  │ (Queue)  │       │
│  └──────────┘  └──────────┘  └──────────┘       │
│       ↑              ↓              ↓             │
│       │         [RDS Aurora]  ┌──────────┐       │
│       │         (PostgreSQL)  │ Lambda   │       │
│       │                       │ (Worker) │       │
│       │                       └──────────┘       │
│       │                            ↓              │
│  ┌──────────┐               ┌──────────┐        │
│  │ n8n      │               │ Step     │        │
│  │ (ECS)    │←─────────────│ Functions│        │
│  └──────────┘               └──────────┘        │
│       │                          │                │
└───────┼──────────────────────────┼────────────────┘
        │                          │
   ┌────┴────┐              ┌─────┴─────┐
   │         │              │           │
[Salesforce] [kintone]  [Claude API] [Slack]
              API         (Bedrock)    API

構成要素:

• AWS Lambda + API Gateway: API層。VPC内で完結
• SQS: CRM APIのレート制限に対応するキュー
• Step Functions: 複雑なワークフローの状態管理
• n8n（ECS Fargate）: 営業マネージャーが操作するワークフロー
• RDS Aurora: データウェアハウス。エンリッチメント結果の蓄積
• Amazon Bedrock（Claude）: VPC内でLLM処理

月額コスト概算:

選定理由: エンタープライズではVPC内にデータを閉じることが要件になる。Amazon Bedrockを使えばClaude APIもVPC内で利用できる。n8nはECS Fargateでホストし、営業マネージャーがブラウザからフローを確認・修正できる環境を維持する。kintoneとの連携はREST APIで対応する。

技術選定チェックリスト

営業組織やCTO/VPoEに技術選定を提案する際のチェックリストを置く。

事業要件の確認

• 月間のAPIコール/リクエスト数の見込みは？
• データの所在地に制約はあるか？（GDPR、国内法、社内規定）
• 既存のクラウドインフラは何か？（AWS/GCP/Azure/なし）
• CRMは何を使っているか？（HubSpot/Salesforce/kintone/その他）
• 営業チームの規模と今後の拡大計画は？

コスト制約の確認

• 月額の上限予算は？
• 固定費 vs 従量課金、どちらが予算管理しやすいか？
• 既存のSaaSライセンスで利用可能なものはあるか？
• 初期構築コストの上限は？

技術制約の確認

• VPC内にデータを閉じる必要はあるか？
• 既存の認証基盤（SSO/SAML）との統合は必要か？
• CRM APIのレート制限を把握しているか？
• 処理の最大実行時間は？（15分以上ならサーバーレスは不向き）
• GPU利用（画像認識、大規模LLM推論）の予定はあるか？

運用体制の確認

• GTMエンジニアは何名か？（1名なら運用負荷の低い構成）
• 営業チームがワークフローを直接操作する必要はあるか？
• 障害時の対応SLA/期待値は？（営業時間内に復旧できればよいか）
• モニタリング/アラートの仕組みは？

選定と提案

• 上記要件に基づいてインフラ候補を2-3に絞ったか？
• 各候補の月額コスト概算を算出したか？
• 12ヶ月後のスケール時のコスト予測を含めたか？
• 非技術者（営業責任者、CFO）にも理解できる説明資料を用意したか？

---

GTMエンジニアの技術選定は、「何が最新か」ではなく「何が事業に合うか」で決まる。ただ、これも自分が実際にやってみての話で、組織によっては既存インフラへの統合コストが意思決定を大きく左右することもある。

GTMエンジニアの技術選定は、技術スタック全体像の4層モデルと、SLG時代の職種定義を前提にしている。次の記事では、この技術基盤の上に構築するAIパイプラインによるセールス自動化を具体的に実装する。

---

参考資料

• Cloudflare Workers Pricing
• Vercel Pricing
• AWS Lambda Pricing
• n8n Self-hosting Guide
• HubSpot API Rate Limits
• Salesforce API Limits
• kintone API Rate Limits
• Hono - Web Framework for Cloudflare Workers
• The 2026 State of GTM Engineering