スタートアップCTOが語る「AIを前提にした技術選定」
スタートアップCTOがAIを前提に技術選定する際の考え方を2026年の最新事情で語ります。AIが書きやすい言語、ベンダー選び、データベース、開発フロー、チーム構成まで実体験ベースで解説します。
この記事の目次
結論: AI前提の技術選定は「AIが得意なスタック」を選ぶこと
「AIを前提にした技術選定とは何か」。これは2026年現在、スタートアップCTOが必ず直面する問いです。創業3年目、メンバー12名のSaaSスタートアップでCTOを務める筆者が、自社の意思決定とその根拠を実体験ベースで共有します。
この記事でわかること:
- AI前提の技術選定で重視すべき5つの観点
- 具体的に採用した言語・フレームワーク・DB
- 避けた技術と、その理由
- チーム構成と採用基準の変化
観点1: AIがコードを書きやすい言語を選ぶ
創業当初はGoとPythonの混在を検討していましたが、最終的にTypeScript + Pythonの2言語に絞りました。理由は、両言語とも学習データが豊富で、AIによるコード生成の正解率が安定しているからです。Rustは魅力的ですが、AIがエッジケースの所有権で苦戦するため、本番のホットパスのみに留めています。
観点2: ドキュメントが充実したスタックを選ぶ
AIは学習データの質と量にパフォーマンスが直結します。Next.js、FastAPI、Drizzle、Tailwindを中核に据えたのは、公式ドキュメントが大量にあり、AIが正しい書き方を生成しやすいからです。マイナーなフレームワークほどAIの精度が下がるため、創業期の人手不足には致命的になります。
観点3: ベンダーロックインを恐れすぎない
「LLMはマルチプロバイダで」と言われがちですが、創業期はそんな余裕はありません。Claude APIに完全寄せすることで、プロンプト最適化と運用ノウハウを集中させ、コストを抑えています。マルチ対応は売上1億円を超えたあたりで検討で十分です。
観点4: データベース選定
Supabase (PostgreSQL + pgvector) を採用しました。理由は以下の通りです。
- RAGに必要なベクトル検索が組み込み
- 認証・ストレージ・リアルタイムまで一気通貫
- AIが書きやすいSQLが基本
- Drizzle ORMとの相性が良い
NoSQLは魅力的ですが、AIがリレーション設計を提案するときに、結局SQLのほうが安定した結果になります。
観点5: 開発フロー
1日のフローは以下の通り組み立てています。
- 朝: ClaudeでIssueのリファイン (要件分解、テストケース案、技術的疑問の整理)
- 午前: Cursorで実装、PR作成。Reviewerは別のClaude (社内Bot) が一次レビュー
- 午後: 人間レビュー、マージ、デプロイ
- 夕方: 翌日のIssueをClaudeとセットアップ
1スプリント (1週間) で出るストーリーポイントは、AI導入前の2.3倍になりました。
避けた技術と理由
- マイクロサービス: 創業期は単一モノリスで十分。AIが横断的にコードを理解しやすい
- 独自フレームワーク: AIが学習していない=コストが跳ね上がる
- GraphQL: REST + tRPCのほうがAIが正確に書く。GraphQLは大きくなってから検討
- Kubernetes: Vercel + RailwayまたはFly.ioで十分
チーム構成の変化
創業当初は「フルスタックを5人雇おう」と思っていましたが、AIで生産性が上がった結果、3人でカバーできる範囲が広がりました。一方で「AIを使いこなすシニア」の重要性が増し、ジュニアの採用はあえて絞っています。AI時代は「シニアを増やしてAIに任せる」ほうがコスパが良いという結論です。
採用基準の変化
面接で見るポイントが大きく変わりました。
- 「AIで生産性を10倍にした事例」を必ず聞く
- 過去にAIエージェントを自作したかを確認
- コードレビュー力 (AI生成コードの審美眼)
- プロンプトを書く語彙力
逆に「コードを速く書ける」ことの優先度は下がりました。これはAIで補えるからです。
まとめ
AI前提の技術選定は、「AIが得意なスタック」「ドキュメントが多い基盤」「ベンダーへの集中」「AIに優しいDB」「フロー全体のAI最適化」の5点に集約されます。創業期は奇をてらわず、AIが最高のパートナーになれるスタックを選ぶのが正解です。スタートアップCTOにとって、技術選定そのものが2026年はAIとの協業設計になっているのです。