生成AI時代にフルスタックTypeScriptの夢を見る

生成AI時代に
 フルスタックTypeScript の夢を見る TSKaigi 2025@ベルサール神田 ２０２５/05/23 matano kosuke

https://2025.tskaigi.org/talks/nstock 2

• https://2025.tskaigi.org/talks/nstock

事業概要と基本アーキテクチャ

ミッション Our Mission スタートアップエコシステムをブーストし 日本から Google 級の会社を生み出す 4

Nstockの事業構成 現在 株式報酬 SaaS 事業 Stock Compensation SaaS セカンダリー事業 Secondary スタートアップへの 再投資事業 Reinvestment in startups 将来 エス コタ シー スト テア ムッ のプ 進 化 5

組織全体で45名の会社です（2025年3月1日時点） 株式報酬 SaaS 事業 プロダクトマネージャー エンジニア デザイナー BizDev セールス CS 横断チーム CEO 採用人事 マーケティング 14 名 セカンダリー事業 1名 5名 2名 1名 2名 3名 16 名 3名 スタートアップへの再投資事業 1名 7名 2名 2名 2名 2名 プロダクトマネージャー エンジニア デザイナー BizDev コンプライアンス セールス 1名 1名 1名 プロダクトマネージャー エンジニア デザイナー 12 名 1名 2名 2名 エディター ドメインエキスパート デザイナー 1名 2名 1名 アドバイザー グループセクレタリー コーポレートエンジニア 1名 1名 1名 6

SaaSとセカンダリーの比較 セカンダリー 株式報酬SaaS Backend Frontend API Schema HTTP Client First Commit 特徴 Java + Spring Boot Kotlin + Spring Boot Next.js (output: 'export') React Router v7 (full SSR) OpenAPI (Schema First) OpenAPI (Kotlin Code First) orval (Tanstack Query) orval (fetch) February 2022 July 2024 層がないのでUI準拠な巨大なAPIを単一叩くこ とが多め loader内で複数APIをコール Cookieの状態などに 合わせたエラーハンドリングも複雑 BFF 7

APIに型をつける SaaS事業編

API コードジェネレートエコシステム GraphQL GraphQL Codegen, Apollo, Relay な 知見のあるメンバーも特にいなかったので見送り gRPC Connect, grpc-web な Java/Kotlin系はエコシステムがそこまで強くないので見送り REST OpenAPI Generator, orval など← 今回はこち Java/Kotlin + TypeScript系のエコシステムも成熟していると判断 9

株式報酬SaaS事業 当初（typescript-axios） `@openapitools/openapigenerator-cli`を利用 エンドポイントと型の一致は手作業で やる必要があり危険 エラー型も要指定 基本的にステータス コードのみのハンドリング 10

株式報酬SaaS事業 改善後（orval） import するだけでOK 更新系のuseMutationも対応 APIコールは基本的に全てorvalが生成した react(tanstack)-queryを通すように 11

株式報酬SaaS事業 残る課題 openapi.ymlの肥大 合計8000行弱 まだまだ増え 手で書くの辛かったがAIでだいぶマシになりつつある 型の「嘘」(not any APIサーバー側が正しく返していないケース 特にnull, undefined, 空文字な （Java側の話なので詳細は割愛 zodのコード生成もあるが 全部に通すのは本末転倒 そもそもランタイムで弾かれたらAPI側の修正は必要 12

セカンダリー事業へ異動 13

APIに型をつける セカンダリー事業編

セカンダリー事業での差分1 Spring Boot(Kotlin) → openapi.yml → TS codes generated by orva springdoc-openapi-gradle-pluginを利用（詳細割愛 巨大なopenapi.ymlを手動で管理するは必要なくなった fetchベース axiosが基本だったがnative fetchに対応 (v6.30.0 Tanstack Query等は未使 loader/action内で通信系を完結させるので 15

セカンダリー事業での差分2 異常系もより丁寧にハンドリン error typesも含まれるように (v7.4.0) 16

いい感じと思ったが… 17

セカンダリー事業での問題 型の「嘘」は潜んでい 実際には「`null`はありえない」ことを表現できていない 対応のためにSpringBoot側で明示的なアノテーションの多用≒実装とズレる危険 他にもやり方はあるが何もしないと通ってしまうのが問題 注：Kotlinのコードです 18

まとめと展望

整理 DB → Java/Kotlin API Server → HTTP JSON → TypeScript Clien 外部I/Oに対する型付けが不十分だと静的型付け恩恵を活かしきれな 言語間のデータの表現に差分があるのでそこをうまく吸収する必要性 突き詰めるとDB層のアクセス（≒バックエンド）もTypeScriptにしたくな Prisma / Drizzle などのOR SupabaseのDeclarative database schemaはよりend-to-end type safetyを すべてがTSになる 20

バックエンドの技術選定を振り返る SaaS事業 (Java 静的型付けの恩恵を受けた 1人目エンジニアが得 金融ドメインに強 セカンダリー事業 (Kotlin 同じJVM系言 Spring Bootなどの社内の知見を活用した null safeや構文のシンプルさ(対Java) 生成AIの勃 人間間の知見の共有も大事だがAIが理解しやすく、出力しやすい形という観点も重 今後新しいプロジェクトではフルスタックTSもありか（仮説 Java / Kotlinに比べてどうか？ 21

コードの統一がもたらす4つのAI時代的メリット（このスライドのテキストは全てAIによって生成されています） AIによる横断的なコード生成が可 異なる言語で構成されたシステムでは、AIは各レイヤーの仕様・文法・データ構造を個別に 理解する必要があります 一方、Full Stack TSではAIは「全体の構造」を容易に把握・横断可能で、ボタンのクリック からDB保存までのコードを一貫して生成・修正できます 単一の文脈でプロンプトを完結でき Full Stack TSなら、**「型も構文も全てTS」**で記述されているため、プロンプトはシン プルになり、AIが文脈を正確に理解できます スキーマ定義とUIの距離が近 スキーマの再利用性＝AIの自動生成効率の高さにつなが 学習コストと保守コストの削減 → AI導入もスムーズ 技術スタックがTSに統一されていることでメンバー間の理解共有がスムーズになります。 22

今後の展望 SaaS事業/セカンダリー事 opneapi + orvalによる型生成は概ね満 MCPやmswなど周辺機能も充実してきてい バックエンドTypeScriptへのリーアキテクチャを現時点では予定していな ベースはそのままにより型安全かつ開発生産性の高い形を目指 Open API → TypeSpec なども視野 長期的にはわからない 第3以降の事 v0でモックを作ったりしている 起点はTypeScriptになることが多 採用の観点でもフルスタックTypeScriptになる可能性はあり 23

We are hiring! https://recruit.nstock.co.jp/ 24

• https://recruit.nstock.co.jp/