---
title: 生成AI時代にフルスタックTypeScriptの夢を見る
tags: 
author: [matano](https://www.docswell.com/user/matamatanot)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/PER56DMR79.jpg?width=480
description: 詳しくはこちら https://2025.tskaigi.org/talks/nstock
published: May 23, 25
canonical: https://www.docswell.com/s/matamatanot/KDN824-tskaigi2025
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/PER56DMR79.jpg)

生成AI時代に

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/P7XKM1VYEX.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/37K5G2Q4ED.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/LJ3KN4PDJ5.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/8JD3WQL2EG.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/VEP49L2LJ8.jpg)

組織全体で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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/27VXMQD6EQ.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/5JGVGWY2JL.jpg)

APIに型をつける
SaaS事業編


# Page. 9

![Page Image](https://bcdn.docswell.com/page/47Q6X3M97P.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/KE44614RE1.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/L714VG4V7G.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/G7WXLKX3J2.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/4JZ6MZ6GJ3.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/YE62NZ2QJV.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/GE525W22E4.jpg)

セカンダリー事業での差分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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/9724NQ41ER.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/DJYMPWM4JM.jpg)

いい感じと思ったが…
17


# Page. 18

![Page Image](https://bcdn.docswell.com/page/V7NW59W678.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/YJ9XY2XRE3.jpg)

まとめと展望


# Page. 20

![Page Image](https://bcdn.docswell.com/page/GJ82652GJD.jpg)

整理
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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/LJL29Y2XER.jpg)

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


# Page. 22

![Page Image](https://bcdn.docswell.com/page/47M8ZN837W.jpg)

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


# Page. 23

![Page Image](https://bcdn.docswell.com/page/P7R56D5RJ9.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/PJXKM1KY7X.jpg)

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