新規事業を牽引する技術選定 〜フルスタックTypeScript開発の実践事例〜

2026年6月9日 Findy Freelance Eventでの登壇資料です。
様々な話題（TypeScriptのPros/Cons, 技術選定の考え方, ライブラリ選定、有用なテクニック, 組織づくり, 事業への貢献, AIとの開発）について、「フルスタックTypeScript開発の実践」をテーマに筆者自身の新規事業中心でのWebサービス開発経験をベースに話しました。

イベントURL：https://findy-freelance.connpass.com/event/393793/
Findy Freelanceについて：https://freelance.findy-code.io/?fr=ann_knrsw

Transcript

1. 新規事業を牽引する技術選定 〜フルスタックTypeScript開発の実践事例〜 合同会社N-Works代表 成澤 克麻 2026年6月9日(火) Findy Freelance Event
2. 自己紹介 成澤克麻 @katsumanarisawa 合同会社N-Works 代表 / Findy Freelance顧問 – （宣伝）Findy Freelanceの申し込みはこちらから！ 経歴：東北大学 → DeNA → スタートアップ → フリーラ ンス → 現在（開発会社の代表） 様々なプロジェクトをフルスタックTypeScriptで開発 シード〜シリーズCのスタートアップ、大企業の新規事 業、官公庁案件まで様々 最近はワインの資格をとりました！ – ワイン好きな人飲みましょう！ワインはロジックなのでエンジニアは好きそうな方多そう 2/98
3. このスライドは人力で書いています ※最近こんな記事を見かけたので：TSKaigi 2026 の発表資料の体感半数以上が AI 生成感あ るものだった - mizdra's blog 気合いをいれて執筆したら恐ろしい分量になったので、発表では皆様の反応が多そうな箇所 を重点的に話します…！ – ぜひコメントなどいただけると嬉しいです！ 3/98
4. 今日話すこと テーマは「フルスタックTypeScript開発の実践」 筆者自身の新規事業中心でのWebサービス開発経験をベースに様々な話題を話します – 話題の例： TypeScriptのPros/Cons, 技術選定の考え方, 実践（ライブラリ選定・有用なテクニッ ク）, 組織づくり（採用・育成）, 事業への貢献, AIとの開発 「フルスタックTypeScript開発の実践」をするにあたっての道標となる発表を目指します – 各論の深掘りはせず、総論的な話をします 4/98
5. Disclaimer 発表内容のすべてにおいて 「これが正解」というものはありません – 環境・背景・制約条件が異なれば、やるべきことも変わる（大前提） – これを無視したマサカリはよくない 筆者の経験をベースにした話がメインです – 経験したことのない環境、使ったことのないライブラリなどへの言及は薄めです – 「様々な技術スタックについて網羅的に調査・比較した調査結果」ではなく「様々な現場での経験を してきた筆者の技術選択の考え方の共有」としてお聞きください – 徹底調査もしたかったのですが、その時間はなかった…（言い訳） 筆者の経験について – 1〜10人程度、シード〜シリーズCのスタートアップ／大企業の新規事業での開発経験が多めです – このバイアスがかかった発表になっている点をご了承ください 5/98
6. 参考文献について 自分個人の経験に偏らないよう、参考文献を頻繁に引用しています スライド内のリンクを、後でじっくりお読みください（スライドは公開予定） 引用させていただいた皆さま、ありがとうございます 6/98
7. 目次 1. 自己紹介 / 前置き 2. フルスタックTypeScriptという選択 3. 実践（TS全般 / バックエンド / フロントエ ンド） 4. TypeScript × 組織・事業 5. TypeScript × AI
8. TypeScriptという技術選択 8/98
9. いま、TypeScriptが熱い 2025年8月、TypeScriptが月間コントリビューター数でGitHub最多の言語に – GitHub自身が「10年以上で最も大きな言語シフト」と表現 – Python・JavaScriptを抜いた IT/Webエンジニア転職動向調査 2025年3月号（Findy）ではTypeScriptが2設問とも1位 – 「現在主に業務で使用している言語・技術」 「今後習得・強化したい言語・技術」の2部門 TSKaigi の熱気もすごい！ – （自分は行けてない…！来年は行きたい！） 9/98
10. バックエンドTSの盛り上がり ランタイム：軒並みTSファーストに – Node.js v25.2.0（2025年11月）で、ランタイムの TypeScript "type stripping" が stable に昇格。 .ts を node で直接実行できる（実用上の注意点はあるが、安定版） – Deno・Bun は以前からTSをネイティブにサポート API：境界の型をどう扱うか、選択肢が並立 – tRPC：スキーマ定義言語もコード生成もなしにE2Eの型安全。40.3k stars。 – Hono：30.8k stars。Workers / Deno / Bun / Node / Lambda で同じコードが動く – GraphQL / Server Actions など、他の手段も充実 10/98
11. フルスタックTypeScript採用の メリット 11/98
12. ドジャース山本由伸選手の発言（嘘です）
13. メリット①：エンドツーエンドの型安全性（最大の価値） 型の恩恵をバックエンドからフロントエンドまで通して受けられる – 「型安全は必須の開発環境である」 - Typesafety isn't optional - Create T3 App – 型しか勝たん 型の恩恵により、リファクタリングが圧倒的に楽 – （例）DBのカラム名変更、APIのインターフェース変更も、漏れなく確実に追従 – IDEのリファクタリング機能だけで、全ての修正が完結することも 気軽にリファクタリングできることが、事業の成長に合わせたドメインロジックの維持・磨 き込みに直結する – 「ちょっとカラム名をミスったな〜」なんて時に気軽に変更できる – 大きな要件の変更があったときも、安心してソースコードを変更できる 13/98
14. メリット②：言語統一の効用 脳内でのコンテキストスイッチがなくなる – 自分の感想：TypeScript / Ruby の脳の切り替えを苦に感じていないつもりだったが、やめてみると 結構コストがかかっていた 共通ロジックを柔軟に再利用できる – 共通パッケージにドメインロジックを書ける体験が非常に良い – 「この処理はバックエンドだからRubyでこのディレクトリに書く」ではなく「この処理はこのドメ インロジックだから、このディレクトリ」という発想に変わる – （ただし、この手の共通処理はすごく多いわけではない） フロントエンド/バックエンドの垣根が薄くなる、コミュニケーションコスト低下 – ※詳細はTypeScript x 組織の章で後述 PayPalの事例：Node.jsへの移行により生産性が2倍に – 参考：Node.js at PayPal 14/98
15. メリット③：その他 AIコーディングエージェントとの相性 – ※AIの話は「TypeScript × AI」 の章で 後述 エコシステムと採用市場の追い風 — GitHubで最も使われる言語に。 – 「人材プール？ いや、人材の海だ。 」- How Node.js Changed the World of Corporate Software Engineering – ※採用・組織の話は「TypeScript x 組織」の章で後述 関数型プログラミングとの相性 — リッチな型システムを活かして堅牢に。複雑なドメイン ロジックを綺麗に実装でき、事業の成長にも耐える – ※詳細は実践の章で 15/98
16. まとめ - 開発生産性が高いことが最大のメリット エンドツーエンドの型安全性（最大の価値） 言語統一によるコンテキストスイッチ削減 / コードの再利用可能性 AIコーディングエージェントとの相性 エコシステムと採用市場の追い風 関数型プログラミングとの相性 新規事業は見えないことの連続で、その都度こまめな方向転換が必要 一貫して高い生産性を出し続けることで、フルスタックTypeScriptは事業に貢献できる 16/98
17. フルスタックTypeScript採用の デメリット 17/98
18. デファクトスタンダードがない（最大のデメリット） 2025年のウェブアプリ構築の現実とは、IKEAの家具を組み立てるようなもの。バッテリ ー込みの「フルスタック」製品なんてものはなく、個々のサービスを一つ一つ組み合わ せて設定しなければならない。 — Andrej Karpathy のポスト（X） Rails / Laravel が「大聖堂」なら、JSエコシステムは「市場（バザール） 」 。 （＝必要なも のを自分で市場から買ってくる必要） - Full-Stack TypeScript Stack vs Laravel-Rails …そして、一つだけ変わらない事実がある。それは「適切なJavaScriptフレームワーク を選ぶのは、本当に難しい」ということ - JavaScript Fatigue Strikes Back 他言語出身者がバックエンドTSを始める上での大きな参入障壁。 （中略）何を選んでい いのかわからない - Honoで実現するバックエンド開発のイマ 18/98
19. （例） Rails と技術スタックを比較してみる カテゴリ Rails フルスタックTS ランタイム / パッケージ管理 Ruby + Bundler Node / Deno / Bun ＋ npm / pnpm / yarn ORM / DBアクセス ActiveRecord Prisma / Drizzle / Kysely / TypeORM / MikroORM… ビュー ERB / Hotwire React / Vue / Svelte / Solid / Angular… コントローラ / ルーティング ActionController / routes.rb Hono / Express / Fastify / NestJS / Koa… バリデーション ActiveModel Validations Zod / Valibot / ArkType / Yup / class-validator… 認証 Devise Auth.js / Clerk / Better Auth / Supabase Auth… ジョブ ActiveJob + Sidekiq BullMQ / Graphile Worker / pg-boss / Trigger.dev… メール ActionMailer Nodemailer / Resend / React Email… ファイル ActiveStorage S3 SDK自前 / UploadThing / Cloudinary… テスト Minitest / RSpec / Capybara Vitest / Jest / Playwright / Testing Library… クライアント状態 / データ取得 Hotwire（基本サーバー側で完結） TanStack Query / SWR / Zustand / Jotai… ※「TSは選択肢がたくさんあるなあ」というイメージ共有のための表であり、厳密性についてはご勘弁ください 19/98
20. Railsは何がよかった？ 良さ＝「標準（"レール"）が示されている」＝「決めなくていいことを決めてくれている」 Convention over Configuration（設定より規約） – 個々のツールを「どう使うか」を規約化（命名・ディレクトリ・ORM・マイグレーション・ルーティ ング・ジョブ・バリデーション） The menu is omakase（メニューはおまかせ） – 一段上で「どのツールを、どう組み合わせるか」まで決めてくれる – 「最良のツールを選べ」と言うが、"最良"を自信を持って判断できる土台があって初めて選べる。そ れは見かけよりずっと難しい。 — Rails Doctrine – omakaseの効用＝数の安全：同じデフォルトを使うから、教え合い・議論・知見の共通基盤ができ る ソフトウェアの痛みの多くは部品単体ではなく、部品どうしの「組み合わせ」に宿る。同じ組 み合わせをみんなで磨くから、全員の痛みが減る 20/98
21. レール（標準）がないことの損失 個人レベル：「どの技術を選べばいいか分からない」 （都度自分で考える必要） 組織レベル：タコ壺化。組織・チームごとに違うノウハウが形成される – 他所では解決済みの問いを、組織ごと／チームごとに毎回考え直す（車輪の再発明） – 新規メンバーは、組織独自の細かなお作法〜ライブラリの差異をいちいちキャッチアップする必要 業界レベル：「議論の土台」そのものの喪失 – Rails / Laravel は「レガシー」 「オワコン」とも言われるが、良し悪しを議論できるのは"ある"から こそ。"無い"ことからは何も生まれない – デファクトがあれば「ここが駄目」という批判が次世代への蓄積になる。TSは蓄積の中心がなく、 知見が分散し、洗練が進みにくい よりよい開発基盤を作るための努力が1つに集約されず、良くも悪くも様々な方向に発散 ※ただし、様々な方向性が磨かれるのは悪いことだけではない 21/98
22. （余談）デファクトスタンダードが生まれづらいJS/TS界隈 Blitz.js / RedwoodJS：創業者・コアチーム自身が、フルスタックFWとしての路線放棄を 公言。npmダウンロード数も低迷 – 個人的にも期待していたので、デファクトスタンダードになって欲しかった…。 - Blitz.jsをRuby on Railsエンジニアが触ってみた感想(2021年) / Zenn T3 Stack はスタンダードに近かったが、最近は「準スタンダード」扱い – T3 Stackは2026年現在もTypeScriptフルスタックアプリ向けの最高の無料OSS基盤だが、もはやあ らゆるプロジェクトのデフォルトソリューションではない - T3 Stack 2026: Is It Still the Best Starter? なぜデファクトスタンダードが生まれない？ – そもそも出自がサーバーではなくブラウザだから？ブラウザで動く制約が厳しい？ユースケースが多 様すぎる？そもそも人口が多すぎる？ – （この発表での本筋じゃないので、深追いはしない） 22/98
23. その他のデメリット 学習コスト：やや高い。 「やや難しい」スタックではある – この観点を重視するなら Ruby や Go が候補 パフォーマンス：十分速い。でも「最速」ではない – I/O中心のWebアプリなら基本困らない（大半のSaaS・業務系はこちら） – シングルスレッド＋GCゆえ、CPUバウンド・超低レイテンシ・高スループット計算は不得手。要件 が本当に厳しいなら Go / Rust – 参考：Migrating from Node.js to Go: Real-world Results from Our E-commerce Analytics Pipeline – （大してパフォーマンスが要らないのに、それを理由に別言語を推してくる人、いるよね） 型の堅牢性：型は実行時に消える＝段階的型付けの限界 – any ・型アサーションなど抜け道があり、コンパイル時の保証は Rust / Haskell / Scala ほど強くな い – 誤りが許されないドメイン（金融など）は、より健全な型システムの言語が向く 23/98
24. じゃあどうやって ライブラリ選定する？ 24/98
25. 技術選択のポリシー：世の中のスタンダードにのる スタンダードな技術を使うと、自分が何もしなくてもどんどん便利になっていく – （例）AIは毎年賢くなり、何もしなくても開発効率が上がる – （例）TypeScript自体も、より高速に・より便利になっていく – この手の恩恵は、絶対に受けるべき 尖った技術／最先端の技術を採るときは、目の前の便利さとデメリットを天秤にかける – キャッチアップコスト（自分／メンバー／未来のメンバー） – 枯れていない技術を使うことによるコスト（罠を踏み抜くかも） – 将来その技術が廃れた時の対応工数 × その確率 常に問うべきは「その技術選択は本当に必要か？」 – どれだけ開発効率が変わる？ どれだけ堅牢になる？ 事業にどれだけ活きる？ – 正解はない（見えない）が、常に真摯に問い続ける必要 25/98
26. 世の中のスタンダード = 他メンバーにとってもスタンダード 世の中のスタンダードな技術なら、他のメンバーも最初から知っている技術 オレオレ技術スタックは、チームの人が0からキャッチアップする必要 – そのキャッチアップコストは、生産性の向上にどれだけ寄与する？ 本当に寄与する？ これは「AIに注入するコンテキストが増える」とも言い換えられる – AIもスタンダードな技術の方が得意 （自戒）昔からこの観点を十分持ったつもりだったが、過去はやっぱりオレオレなやり方が多かった…その場その場でのベストだったとは 思っているが 26/98
27. 事業の成功がまずは第一。 「退屈な技術」を使おう 企業が投資できる技術的な挑戦（イノベーショントークン）は限られている – 出典：Choose Boring Technology (2015) 新技術が事業を成功させるのではなく、事業の成功が新技術への投資余力を生む – 出典：Choose Boring Culture (2023) – ※記事内容は組織文化の話 AI時代になって、より Boring な技術が重要になってきた。イノベーション税は2倍になった – 出典：Choose Boring Technology, revisited (2025) – スタンダードな技術ほどAIも得意である 27/98
28. 開発会社の社長としての技術選択 第一優先：顧客の会社・事業に寄り添った技術選択（これは当たり前） 第二優先：最も成果が出しやすい技術スタック – 「新しい技術を使ってみたけど微妙でした、追加で改修工数ください」は基本ありえない – 社長としては、ただでさえ大変なPJで技術的な不確実性を抱えたくない＝ボラティリティを下げたい これは開発会社の社長でなくても、新規開発プロジェクトでは基本的に同じでは？ – 許容できる不確実性のみをとる（最悪、後で使える工数があるならOK）／メリットが明らかにデカ いなら採る／何にしても事前に検証した技術を使う 技術選定の目的は一貫して「事業価値の最大化」 – 要件充足は目的の一部にすぎず、リスク・採用・運用・保守コストまで含めて事業に効くかで選ぶ （とはいえ、メンバーが楽しく開発できる技術選定も大事！） – 要はバランスおじさん「要はバランス」 28/98
29. （余談）個人レベルでの技術キャッチアップ ここまでの話の帰結として、前よりは新しい技術のキャッチアップをしなくなった – 少し前までは、良さそうなライブラリがあったらすぐに触っていたのに… – それよりも、ビジネス的な話/組織論的な話をフォローするのが楽しくなってしまった – 老いを感じる キャッチアップする/しないで言ったら、絶対にした方が良い。けど、全ての技術を勉強す るには人生は短すぎる – じゃあどうする？ 息の長い、普遍的な技術を勉強しよう！ – 参考：技術選定の審美眼 2025年版 – （最近でいうと）AIの進歩の速さに振り回されないようにしよう！ 29/98
30. 本章のまとめ：フルスタックTypeScriptという選択 なぜ選ぶか：開発生産性の高さ。中でも核心はエンドツーエンドの型安全性 – 気軽なリファクタリングが、新規事業の方向転換とドメインの磨き込みに直結する 最大の課題：デファクトスタンダードがない – 何を・どう組み合わせるかは各チームに委ねられる ＝ 自分で地図を描く必要がある どう選ぶか：世の中のスタンダードにのり、 「退屈な技術」を選ぶ – 技術選定の目的は一貫して「事業価値の最大化」 じゃあ実際どのライブラリをどう使う？ という話を次の章で！ 30/98
31. 目次 1. 自己紹介 / 前置き 2. フルスタックTypeScriptという選択 3. 実践（TS全般 / バックエンド / フロントエ ンド） 4. TypeScript × 組織・事業 5. TypeScript × AI
32. 実践 ── バックエンドTypeScript 32/98
33. バックエンドTypeScript - Webサーバーは何にする？ （再）スタンダードがなくてつらい 絶対条件：リクエスト/レスポンスに楽に型をつけられること 候補は大きく4つ。次ページから1枚ずつ詳しく紹介 候補 GitHub 所感（ざっくり） Hono (hc / zod-openapi) 30.8k Web標準・マルチランタイム。REST（OpenAPI）/ RPC GraphQLサーバー （Apollo Server / Nexus） 13.9k / 3.4k 柔軟。エコシステムが充実、洗練された体験 Next.js (Server Action) 139.9k 手軽さ随一。境界が薄く、セキュリティ要注意 tRPC 40.3k 手軽。国内採用事例が少なく不安 33/98
34. Hono - コードイメージ zod でスキーマを書くと、OpenAPI 定義と TS の型が同時に手に入る（ @hono/zod-openapi ） // サーバー：route 定義に zod スキーマを渡すだけ const route = createRoute({ method: "get", path: "/users/{id}", request: { params: z.object({ id: z.string() }) }, responses: { 200: { content: { "application/json": { schema: UserSchema } }, description: "OK" }, }, }); const app = new OpenAPIHono().openapi(route, (c) => { const { id } = c.req.valid("param"); // 検証済みの値を型付きで取得 return c.json(getUser(id), 200); // レスポンスも UserSchema に従う }); Web標準APIベースなので、Cloudflare Workers / Deno / Bun / Node で同一コードが動く 34/98
35. Hono - Web標準、直近のスタンダードな選択肢 概要：Web標準APIベースで Cloudflare Workers・Deno・Bun・Node で同一コードを動か せる。State of JS 2025 のバックエンド満足度で上位常連。直近のスタンダードな選択肢 GitHub 30.8k。作者は@yusukebeさん（日本人） 所感 @hono/zod-openapi を1年ほど実用。zodでOpenAPIを定義できるのが大変良い。 大きな不満なし。スキーマの定義が多少面倒など、HonoというかOpenAPI / REST API起因 のやりづらさはある – クライアントコード生成ライブラリも乱立しており使いづらい（自作した） 、GETリクエストだと数 値型が使えない、そもそもOpenAPI自体が（GraphQLと比較すると）やや古臭いなど RPC機能は非常に手軽にクライアントに型を渡せて便利だが、型推論が大規模になると重く 断念（2年前の体感） 。この部分がコード生成方式に変わってさえくれれば、自分が一番使い たい選択肢（最近はできるのかも？） 35/98
36. GraphQL（Nexus）- コードイメージ code-first：GraphQLスキーマ（.graphql）を手書きせず、TSで型とスキーマを定義する // Nexus：オブジェクト型とクエリを TS で定義（→ スキーマと型を自動生成） const User = objectType({ name: "User", definition(t) { t.nonNull.id("id"); t.nonNull.string("name"); }, }); const Query = queryType({ definition(t) { t.field("user", { type: User, args: { id: nonNull(idArg()) }, resolve: (_, { id }) => db.user.findById(id), // resolver で解決 }); }, }); 36/98
37. Apollo Server + Nexus （GraphQL） / 概要 ※自分が一番長らく開発している技術スタックなので、ボリューム多め Apollo Server：GraphQLサーバー実装で最多ダウンロード。GitHub 13.9k。大型の資金 調達もしているApollo社が開発しており、エコシステムが非常に充実しているのが好き – サーバーの対抗馬：GraphQL Yoga（The Guild・フレームワーク非依存、新規で推奨増） Nexus：code-firstなスキーマ運用ができるフレームワーク。GitHub 3.4k。 – DSLライクな記法や、型エラー時の表示が初見だと厳しい。初心者に不評。しかし慣れる。 – 2022以降停滞しており、新規は非推奨 – 新規で使うならPothos？（とはいえ、こちらも直近リリースが一旦止まっている） – 「GraphQLを使いたい」というモチベーションよりも「リクエスト/レスポンスに型をつけたい」と いうモチベーションなので、code-firstの方が好み 37/98
38. GraphQLのメリット/デメリット GraphQLは良くも悪くも柔軟。良い面を上手く使うとREST APIより洗練された設計ができて良 い反面で、悪く言えば複雑化しやすく難易度は高い 向いているケース①：フロントエンドが複雑なケース（本来のモチベーション） – （例）複数の異なるクライアントがそれぞれ違うデータを欲しがる、ペイロードのサイズを少しでも 抑える必要、フロントが複雑・高速に変化するのでバージョンが欲しいなど – あとはBFFとしての用途など 向いているケース②：少人数フルスタックエンジニアのみで開発を行い、GraphQLの柔軟 さをよしなに使いこなせる場合（自分はこちら側） – フロントエンド・バックエンドのどちらも事情をわかってる人が開発することで、GraphQL特有のや やこしい問題を回避しやすい。良い面だけを良いとこどりする – フィールドの増減をいちいちエンドポイントを増やさずresolverで解決するなど、生産性が高い これ以外のケース（例：シンプルなWebアプリケーション開発）であればREST APIが良い 38/98
39. Apollo Server + Nexus （GraphQL） / GraphQL以外の話 自分の場合は「GraphQLらしいメリット」よりも「エコシステムが充実・洗練されている」 の側面が好きで使い続けている – Apollo Clientを最初に触った時は便利すぎてウキウキした – 参考：世のフロントエンドエンジニアにApollo Clientを布教したい / Qiita - @seya – Apollo ClientはLink、キャッシュや状態管理、codegen、federation（数えきれない） 。やりたいことが一通 り全部揃っていて、フロントエンドがすごくシンプルに書ける – ServerもClientもApolloスタック＝ツールの組み合わせを気にしないで済む（The menu is omakase） 。Apolloに従ってれば一通りのフルスタックTS開発できるのが便利だった 「フルスタックTS」の文脈では、自分がNexusを使い始めた当時（2021年）は選択肢が少 なかったが、2026年現在は他の選択肢でも良いかもしれない – GraphQLらしいメリットを活かしたいなら勿論必要 39/98
40. Apollo Server + Nexus （GraphQL） / その他 せっかくTSの型の世界にいるのに、GraphQL という別のスキーマが入り込むのは冗長 – いちいちGraphQLスキーマを書くのが面倒。TSから型推論してほしい（Next.js / Hono RPC） – zodを使いまわせないのが痛い。zodでリクエスト/レスポンス定義したい（Hono + Zod OpenAPI） カスタムの serialize / deserialize を書けるのが便利 – （例）GraphQLにDateというネイティブ型はないが、カスタムスカラーとして記述できる。リクエ ストをそのままDateで受け取れるし、レスポンスにDateを詰め込める。 – Hono + Zod v3だと1方向の変換しかできず、いちいち変換する必要があった → Zod v4 から codec で対応可能に！便利！！ Federationで複数の独立したGraphQL APIを統合できるのは便利 40/98
41. Zod codec - コードイメージ Zod v4.1+ の codec なら、シリアライズ/デシリアライズを双方向で1か所に定義できる // Zod v3：transform は一方向（input → output）のみ const fromISO = z.string().transform((s) => new Date(s)); fromISO.parse("2026-06-09T00:00:00Z"); // → Date（逆変換はできない） // Zod v4：codec で双方向の変換を定義できる const DateCodec = z.codec(z.iso.datetime(), z.date(), { decode: (iso) => new Date(iso), // 文字列 → Date encode: (date) => date.toISOString(), // Date → 文字列 }); DateCodec.decode("2026-06-09T00:00:00Z"); // → Date DateCodec.encode(new Date()); // → ISO 文字列 41/98
42. Next.js (Server Action) - コードイメージ 'use server' を付けた関数を、クライアントから直接呼べる。APIの薄いラッパーが不要 // actions.ts — サーバーで動く関数を定義 "use server"; export async function createTodo(formData: FormData) { const title = formData.get("title") as string; await db.todo.create({ data: { title } }); } // クライアントコンポーネント — form の action に直接渡せる <form action={createTodo}> <input name="title" /> <button type="submit">追加</button> </form> 手軽な反面、client/server の境界が薄く、情報漏洩・脆弱性事故に注意 42/98
43. Next.js (Server Action) - 唯一無二の手軽さ Next.js 14（2023末）よりServer Actionが導入。クライアントコンポーネントから直接サーバ ーサイドの関数を呼び出せるように。フォーム送信やCRUDをAPIの薄いラッパーを書かずに実 装可能。個人開発・小規模では唯一無二の手軽さ。 懸念点：セキュリティ面が不安 ライブラリ起因の脆弱性：直近2年でクリティカルな脆弱性が多数発生 – 概念や機能が多く複雑すぎて、脆弱性が発生しやすい（Next.js、色々やりすぎ） 利用者起因の脆弱性：良くも悪くもクライアント/サーバーの境界線が薄い。エンドポイン トや環境変数、ソースコードを意図せずにクライアントに公開してしまう事故が発生しやす い設計 – とはいえ、工夫すれば十分防げるのかも？導入している方の経験談があれば、ぜひ教えてください！ 43/98
44. tRPC - コードイメージ スキーマ記述もコード生成もなしに、サーバー関数を直接呼ぶ感覚で型安全に通信できる // ① サーバー：手続き(procedure)を定義するだけ（スキーマファイル不要） const appRouter = router({ user: { byId: publicProcedure .input(z.object({ id: z.string() })) // 入力は zod で検証 .query(({ input }) => db.user.findById(input.id)), }, }); export type AppRouter = typeof appRouter; // 型情報だけを client に渡す // ② クライアント：サーバー関数を呼ぶだけ。コード生成は一切なし const user = await trpc.user.byId.query({ id: "123" }); // ^? { id: string; name: string; ... } が自動で型推論される 44/98
45. tRPC - 便利だが採用事例が少ない スキーマ記述もコード生成もなしに、サーバー関数をクライアントから直接呼ぶ感覚で型安 全に通信。非常に手軽 State of JS 2025 で関心・満足度とも上位。GitHub 40.2k（最多） 。2021年ごろから流行 自分は実プロダクトで利用したことがない 軽く触った感じは良さそう 海外では流行っているが、国内での採用事例が少ない（体感） 「モノレポのフルスタックTS限定」がハードルが高く、採用事例が伸びない？ – 本発表としてはモノレポフルスタックTS推奨だが、世間的にはまだややハードルが高いかも – 採用事例が伸びない＝スタンダードになりづらい。その面では使いづらい – 「他リポジトリのclientからAPIを叩く」ができない（しづらい） 。将来的なプロダクト・組織の拡張 に耐えうるかがやや不安 – 参考：カケハシさんの採用事例 - 適材適所の技術選定 〜GraphQL・REST API・tRPC〜 / Optimal Technology Selection 45/98
46. まとめ ── Pros / Cons 候補 向く場面 Pros Cons Hono + zod- openapi 直近の最も標準的な選択肢。他の選択肢が適して いなかったらHonoが良い。 Web標準・軽量・どこでも動く、zodで OpenAPI定義、勢い◎（日本語情報も 多い） スキーマ定義がやや手間、クライアント生成が 乱立、 hc (RPC)の型推論が大規模で重いかも GraphQLサー バー系 複雑・多様なデータ要求、複数クライアントの場 合。または少人数フルスタックで柔軟さの良い面 だけを活かせる エコシステム成熟、開発体験の良さ、ク エリの柔軟性、カスタムスカラー 柔軟さは複雑さでもある、難易度高め、TSと別 のスキーマ体系で冗長 Next.js Server Action 個人〜小規模のカジュアルなアプリ 圧倒的な手軽さ、APIラッパー不要 client/server境界が薄く情報漏洩・脆弱性事故 が起きやすい設計。Next.js自体のCVEも近年多 発 tRPC 小規模プロジェクト コード生成なしで端から端まで型安全、 DX◎ tRPCは同一コードベース前提で採用ハードル高 い。国内事例少なめ 46/98
47. Prisma - コードイメージ スキーマを宣言的に定義 → prisma generate で完全に型付けされた Client を生成 // schema.prisma — モデルを宣言的に定義 model User { id String @id @default(cuid()) name String posts Post[] } model Post { id String @id @default(cuid()) author User @relation(fields: [authorId], references: [id]) authorId String } // 生成された Client は引数も戻り値も型安全 const user = await prisma.user.findUnique({ where: { id: "123" }, include: { posts: true }, // リレーションも型付きで取得できる }); 47/98
48. ORM：Prisma フルスタックTS構成で運用し始めた当初から、一貫してPrismaを利用（現在のスター数 46.2k） 直感的かつ便利。本番運用も問題なし。特に困った記憶はない。 Railsに慣れている人からすると、ActiveRecordとは思想が全く違って戸惑う – validation, callback, 各種ドメインロジックを書く場所がPrismaだと（公式には）提供されない – ActiveRecord = ActiveRecordパターンの実装 + α。各ロジックをモデルに実装できて便利 – 参考：Active Recordから考える次世代のRuby on Railsの方向性 – Prisma = テーブルデータゲートウェイの実装。 トランザクションスクリプトでの実装が必要 戸惑いはするが最終的には慣れる。そして型の恩恵が勝つ – また、大規模プロダクトだとActiveRecordも破綻するので大差ない（型がある分有利） 48/98
49. ORM：他の選択肢 ※自分は利用したことがなく、調査結果のみ Drizzle：最近勢いがあるライブラリ。SQLに近い記法。スター数34.7k – Drizzleの方が Simpleなスタイル、Prismaは Easyなスタイル。一長一短。 – 「コード生成がない」をメリットに挙げるが、個人的には生成の方が良いと思う（後述） – 「コード生成を挟まない点はPrismaに比べて優位だが、乗り換えるほどの理由ではない」 - 引用：Hono RPC とDrizzle ORMで実現する、AIにも優しいTypeScriptファーストな開発 – 参考：Database Setup: Prisma vs Drizzle in Boilerplates 2026 – 参考：T3 Stack 2026: Is It Still the Best Starter? TypeORM：長年の定番。スター数36.5k。開発がほぼ止まっており、新規採用は減少 MikroORM：TypeORMと設計が比較的似ており移行先候補。スター数9.1k。 49/98
50. コード生成について 複雑な型推論よりも、コード生成の方が筋が良い – 複雑な型エラーを読み解くのは大変！ – Code Generation over Complex Puzzle - 出典：AI Coding Agent Enablement in TypeScript デメリット：技術スタックの理解が浅い新規メンバーが、コード生成を忘れがち – 「ちゃんと書いてるのに謎の型エラーが出る TypeScript難しい 」となりがち – オンボーディングをちゃんとやろう！ AIも昔はコード生成を忘れがちだったが、最近は気にならなくなった Prisma、GraphQL、APIクライアントでそれぞれコード生成が必要 50/98
51. バックエンド ── その他の話題 PGLite を使ったテスト – DB依存のコードを、DB不要・In-Memoryでテストできて大変便利！ – Prismaだと、Adapterを差し替えるだけで実現できて便利 – …だったが、挙動が怪しくなることが多々あり、泣く泣く断念（ぼちぼち、もう一度試したい） モノレポ・モジュラーモノリス – フルスタックTS開発において、必須の設計 – 詳しくは、以下の記事を参照！ – TypeScript・モジュラーモノリスによる型安全なWebサービス開発 51/98
52. 実践 ── フロントエンド 52/98
53. フロントエンドFW：Next.js ここ5年ほどはずっとNext.js（それより前はNuxt.js） – スタンダードを使うポリシー（前述） toBのWebシステム開発だとSSRの要件が不要なことが多くSPAとして使うことが多い – 本来的にはVite + React Routerを使った方が良い – 「全部入り構成が望ましいから（≒Railsの強み） 」 「特に困ってないから」程度の理由で使っている – いちエンジニアとしての技術選択の考え方として良くない自覚がありつつ、大して困らないのであれば、それ よりも重要度が高いことに時間をかけたい。使い慣れている技術を使って、確実に事業に貢献したい Next.jsの直近の方向性は、超ハイパフォーマンス志向／バックエンドも書きたい人向け。業 務システム開発には不要 – （このユースケースだと、すごく拘るほどの差分でもない程度の認識。割となんでも良い） – （バンドルサイズなどの問題も、toBアプリで気にするほどの差分ではない認識。気になるなら変え た方が良い） 53/98
54. Ant Design - コードイメージ 高機能なコンポーネントを組み合わせるだけで画面ができる（Easy スタイル） import { Form, Input, Button } from "antd"; // バリデーション・レイアウト込みのフォームが数行で完成 <Form onFinish={onFinish}> <Form.Item name="name" label="名前" rules={[{ required: true }]}> <Input /> </Form.Item> <Button type="primary" htmlType="submit">送信</Button> </Form> 覚えることは多いが、コンポーネントの組み合わせだけで一通りの管理画面が作れる 54/98
55. UIライブラリ：Ant Design 自分はここ5年ほどずっと Ant Design – Alibaba製。GitHub 約94k stars。スター数では1位がMUI、2位がAnt Design – 「エンタープライズ向けで高品質のUI」を謳っている（＝業務システム向け？） 「Simple / Easy」の軸だと、Easyなスタイル – Easy：手数の少なさを重視（覚えることは増える、小回りは効かない） – Simple：覚えることの少なさ、小回りを重視（手数は増える） – （例）レトルトカレー vs 材料から作る。 toB SaaSでは、Ant Designを使わない理由が分からない、くらいの所感 – Ant DesignのUIコンポーネントを一通り覚えれば、その組み合わせだけで一通りの画面を作れる – 逆に、組み合わせで作れないUIは、変なオレオレUIになっていないか確認した方が良い – （とはいえ、Ant DesignのUIがUIとしてすごく品質が高いわけでもないが…） – 見た目が重要なtoCプロダクトでは simple な方が扱いやすそう（toBだと優先度が低い） – e2eテストが書きづらいなど、easyであるデメリットは少しある 55/98
56. shadcn/ui - コードイメージ コンポーネントのコードを自分のリポジトリにコピーして所有する（Simple スタイル） # CLI でコンポーネントを「追加」＝ソースが自分のプロジェクトに入る npx shadcn@latest add button import { Button } from "@/components/ui/button"; // 自前のソースを import // Tailwind でそのまま中身を編集・カスタマイズできる <Button variant="outline" className="rounded-full px-6"> 送信 </Button> ライブラリに隠蔽されず、読める・所有できる・デバッグできる 56/98
57. UIライブラリ：shadcn/ui 世の中的には shadcn/ui（+ Radix または Base UI）が2026年のスタンダード – Tailwindネイティブのコピペ型コンポーネント。GitHubスター75,000超 – State of React 2024：使用率はMUIが首位維持、shadcn/uiが1年で使用率20%→42%に倍増・好感度 80%で首位、Ant Designはshadcnに抜かれ3位に 「Simple / Easy」の軸だと、Simpleなスタイル AIが書くなら「Easy（手数の少なさ） 」の価値が下がる？ – 人間が手軽さを享受する必要が薄れるなら、Easyの利点の一部は意味を失う – AIが生成するなら「simple（読める・所有できる・デバッグできる） 」の価値が上がる。shadcnが 標準化した理由の一つがこれ – とはいえ、AIにとってもEasy（contextの圧縮）は大事なのでは？ – Ant Design使っていても、AIはいい感じにUI構築してくれる。レビュー時も、shadcnベースでの新規ロジック を読むよりAnt Designの既成コンポーネントを使ってる方が安心 – ここは自分でも結論が出ていない 57/98
58. フォーム - コードイメージ Ant Design の Form は useForm の型付け＋ Form.List の動的フィールドで複雑なフォームに 対応 import { Form, Input, Button } from "antd"; const [form] = Form.useForm<{ emails: string[] }>(); // 型付き form インスタンス <Form form={form} onFinish={(v) => save(v)}> {/* Form.List で可変長フィールドを動的に増減 */} <Form.List name="emails"> {(fields, { add }) => ( <> {fields.map((field) => ( <Form.Item {...field} key={field.key} rules={[{ type: "email" }]}> <Input /> </Form.Item> ))} <Button onClick={() => add()}>メール追加</Button> </> )} </Form.List> </Form> 58/98
59. フロントエンド ── フォーム フォームは複雑になると難しい。銀の弾丸はない – 参考：複雑なフォームを継続的に開発していくための技術選定・設計・実装 Ant Design のFormを愛用している – 完全な型安全は達成できないが、実用上はそこまで困らず、一通りの機能が揃っていて使いやすい – こういう一通りの機能が揃っているのが、Ant Designの強み ≒ Railsの強み（前述） – 特別に複雑なフォーム実装の時は、自前で状態管理をガッツリ書くしかない 59/98
60. 実践 ── TypeScript全般 60/98
61. 型は厳しく使おう！ コンパイラオプションは 「可能な限り厳しいオプションを使用せよ」 – 出典：どのようにTypeScriptを使うのか - uhyo/blog – このAI時代に、厳しくしない理由がない（エラーが出たら、AIが解決してくれる） anyダメゼッタイ – 「面倒くさい」以外の理由で any を使うことはほぼありえない – ただし、初心者には厳しい要求かも。優しく教えてあげよう – 型ハラスメントもダメゼッタイ – まあ、今の時代はAIくんが教えてくれそう – 参考：業務に残された「良くない型」で考える「TypeScriptの難しさ」 zod と友達になろう — 外界の値の検証は zod に任せるのが基本 – anyやunknownが紛れ込みそうになったら、まずzodで z.parse() 61/98
62. 型に関するテクニック、どれだけ使う？ The TypeScript Handbook は一通り読もう！ – Conditional / Mapped / Template Literal Types を「なんとなく読める」程度で十分 – Branded Typesなど、気軽にできる有益な使い方は覚える – 参考：TypeScript の型安全性を高める Branded Types 「型パズル」をがっつり書くほどのスキルは、基本的には不要 – 「普通の」Webシステムを作る分には、ややこしい型を手書きする必要はほぼない。それが必要にな ってる時点で、そもそも設計が悪そう（個人の所感） – 保守性の低い難しい型パズルを書くのはただの自己満足 – ※便利ミドルウェアを作る文脈であれば必要。 62/98
63. 型テクニック - コードイメージ（Branded Types） 構造が同じ string でも、型レベルで別物として扱い、取り違えを防ぐ type UserId = string & { readonly __brand: "UserId" }; type PostId = string & { readonly __brand: "PostId" }; const asUserId = (s: string): UserId => s as UserId; function getUser(id: UserId) { /* ... */ } getUser(asUserId("u_1")); // OK getUser("u_1"); // 生の string は渡せない getUser("p_1" as PostId); // PostId も渡せない（取り違え防止） 気軽に導入できて効果が高い。zod なら z.string().brand<"UserId">() でも作れる 63/98
64. 関数型プログラミングを、適度に取り入れる 「関数型」の一部のテクニックはTSと相性が良く、非常に便利 – Make illegal states unrepresentable（不正な状態を表現できなくする） – Parse, don't validate（検証結果を型情報として残す） – Errors as values（Result型を要所で利用） 関数型プログラミングをHaskellで勉強するのがとてもオススメ – 自分は「すごいHaskellたのしく学ぼう！（通称：すごいH本） 」を2周読んだ 他、以下の参考記事が非常にオススメ – Pragmatic Functional Programming in TypeScript – TypeScript サーバーサイドエンジニアが関数型から学ぶべき 3 つのアイディア – TypeScript 関数型スタイルでバックエンド開発のリアル 他ライブラリに依存しないモジュールで、関数型スタイルで副作用のないピュアな関数を書き、ドメインロジックを見通しよくテスタブル に集約するのは自分もよくやるパターン。逆に、なんでもかんでも関数型にしないのも大事。シンプルなCRUDは、シンプルに書いた方が楽 64/98
65. 関数型テクニック - コードイメージ 前ページの3つは、TSの標準機能（型）だけでも表現できる // ① Make illegal states unrepresentable — 判別可能ユニオンで不正状態を排除 type RemoteData = | { status: "loading" } | { status: "success"; user: User } | { status: "error"; message: string }; // ② Errors as values — 例外ではなく Result 型で失敗を「値」として返す type Result<T, E> = { ok: true; value: T } | { ok: false; error: E }; // ③ Parse, don't validate — 検証結果を型情報として残す function parseUser(input: unknown): Result<User, string> { const r = UserSchema.safeParse(input); return r.success ? { ok: true, value: r.data } : { ok: false, error: "invalid input" }; } 65/98
66. 関数型を「ガチ」で取り入れる場合 fp-ts / Effect-TSといったライブラリを使うと、本格的な関数型プログラミングを実現できる – 参考：Real World Effect-TS: 堅牢なプロダクトを型で組み上げる / TSKaigi2026 - @asa1984（株式 会社HERP） ※HERPさんはもともとHaskell本番運用していたりして超強い会社 関数型スタイルを言語レベルではなくライブラリで実践するのはかなり難易度が高い – 読み書きが難しい。型エラーが出たときの分かりづらさがひどく、自社では断念。ある程度キャッチ アップした自分ですら戸惑うなら、新規メンバーのキャッチアップは厳しすぎるだろうと判断 – そもそも関数型は難しい。関数型の美しい世界観は自分も憧れるが。 もはやAIが書くから問題ない？→ 人間が読めないとレビューはできず、品質は担保できない – 参考：AIのために、AIを使った、Effect-TSからの脱却 〜テストを活用した安全なリファクタリング の進め方〜 / TSKaigi2026 - 佐藤 拓人（株式会社ビットキー） – 新しい技術を評価する際は「もしAIがこれの実装コードを生成したら、私は適切にレビューできる か？」と自問を。答えが「いいえ」なら、おそらくミッションクリティカルには使うべきでない。 - 出典：Choose Boring Technology, revisited 66/98
67. 本章のまとめ ── 実践の判断軸 BEはデファクトがない＝判断軸で選ぶ／FEは比較的スタンダードがある＝乗る – BE：Hono / GraphQL / Server Action / tRPC を、状況（規模・複雑さ・チーム構成）で選び分け – FE：Next.js・Ant Design / shadcn に素直に乗る（スタンダードを使うポリシー） 型は厳しく設定。型の基礎知識は当然身につける – any禁止・zodで境界を守る – 「型パズル」をがっつり書くほどのスキルは、基本的には不要 関数型を適度に取り入れる – Make illegal states unrepresentable 等は取り入れる – Effect-TSのガチ関数型は難易度に見合わず断念 67/98
68. 目次 1. 自己紹介 / 前置き 2. フルスタックTypeScriptという選択 3. 実践（TS全般 / バックエンド / フロントエ ンド） 4. TypeScript × 組織・事業 5. TypeScript × AI
69. TypeScript × 組織 69/98
70. 採用とTypeScript 採用：しやすい（気がする） – フロントエンドTS経験者に、少しずつバックエンドを書いてもらうコンバートもしやすい – 「フルスタックに開発しなければならない」ではないので、従来通り FE / BE のエンジニアも雇える ＝選択肢が広い 定量的調査でも利用者の数が多い / 興味関心のレベルが高い – GitHubで最も使われる言語（Octoverse 2025。2025年8月の月間コントリビューター数でPython・ JSを上回る） – Findy「転職動向調査 2025年3月号」でも、TypeScriptが2設問とも1位 （ 「主に業務で使用」 「今 後習得・強化したい」 ） – 参考：IT/Webエンジニア転職動向調査 2025年3月号 ただし、 「TS書ける人が多い」≠「バックエンドTS / フルスタック開発ができる人が多い」 – バックエンドTS人材は、まだまだ少ない（気がする） – 逆に「やりたい人」は多い気がする（Findy調査でも1位） 70/98
71. 組織とTypeScript フルスタックな組織が作りやすい – ちょっとした改修のたびに FE / BE間 でコミュニケーションを取るのは、効率が悪い・遅い – 1機能まるまるの開発を、1人のフルスタックエンジニアに任せられる（とはいえ、ある程度優秀な 人でないと厳しい） 1人1人がオーナーシップを持ちやすい – 「BEのことは僕は関係ないので知りません！」にならない – 「複数システムにまたがる機能要件が多い。それを1人で全部担当できるので、作っているエンジニ アも楽しいし、サービス全体を俯瞰する習慣ができる。技術スタックではなく、ミッションでチーム を分ける。 」 - 出典：使用言語はTypeScriptで統一。フルスタックであることを重視したdiniiの技術 選定指針 逆に「フルスタック前提・オーナーシップ前提の組織」になるのも良し悪しなので注意 71/98
72. 育成とTypeScript 言語／ライブラリ／FWのキャッチアップコストはやや高い TS開発経験がある人でも、デファクトがないため習熟度がマチマチ – Rubyなら「Railsという強力な開発基盤は共通。その上でプロジェクト毎の差異」 – TypeScriptは開発基盤も違う、プロジェクトの特性も違う 型の存在はメリットでありつつ、慣れていないジュニアには負担でもある そもそも、フルスタックな開発 = FEとBEのスキルが両方必要とされるのは難しい。各社、 理想としつつも実践には苦労している – 参考：Findyのエンジニア爆速成長の事例 2024年夏 - Findy Tech Blog – 参考（TypeScriptではないですが）：チーム全員がフルスタックになるためのフロントエンド開発 Tips - LayerX エンジニアブログ 72/98
73. オンボーディングのススメ(1) - 内容 数日〜2週間ほどをオンボーディング期間として、以下をやってもらいがち （期間は本人の習熟度による） TypeScriptハンドブックを一通り読んでもらう 利用するライブラリの公式チュートリアルをやり、ドキュメントを読んでもらう 類似構成を、自分で1からセットアップしてもらう（これが凄く効く） 本番ソースコードに対して、ダミー課題（過去の改修の類似課題）を解決するPRを出しても らう 73/98
74. オンボーディングのススメ(2) - メリット 「オンボーディング」なので気軽にミスできる – 本番PRで初歩的なダメ出しが発生すると、指摘する方もされる方も辛い – （開発レビューで指摘が入るのは健全なレビュープロセスだが、積み重なるとお互いの負担。せっかくジョイ ンしてくれたメンバーの初速を削いでしまう可能性を少しでも下げる） – サンプル課題はむしろミスして学んでもらうのが本意なので気軽 キャッチアップに対するお互いの期待値調整 – 業務に直接繋がらないキャッチアップの時間をどれだけ使っていいか、採用された側としては判断に 困りがち – そもそも、採用直後で「早くバリューを発揮して認められたい！」と思っているエンジニアに、 「開発の合間に よしなにキャッチアップお願いします！」と伝えても、キャッチアップはなかなかしてくれながち – 技術レベル・業務の水準についても、オンボーディング期間中にお互い期待値を擦り合わせできる → 育成費用はかかるが、必ずペイするのでやるべき！エンジニアイネーブルメント！ 74/98
75. TypeScript × 新規事業 75/98
76. 新規事業とTypeScript ── そもそも新規事業とは 新規事業の本質は不確実性。「正解」は事前に誰にもわからない。 – リーン・スタートアップの基本は構築 → 計測 → 学習を高速に回し、学びを積むこと。 – 全く先が見通せない不確実性の高い領域では、明確なゴールの設定が初期から行えるわけではなく、 またそのゴールに向かってどのように進めばよいのか、解像度の高い地図も存在しません。だからこ そ、とにかく作っては壊し、最適なプロダクトとはなにか探り続けることが重要となります。 ── LayerXの事業と爆速開発文化 -LayerXエンジニアブログ開設に寄せて- / LayerX CTO 松本勇気 正解がない世界での「正解」とは、試行を重ね変化し続けること 新規事業における「変化し続ける」は「小〜中程度の変化の連続」。これをいかに高速に試 行し続けられるかが非常に重要 – 大きな変化：「1機能/1プロダクトをまるごと捨てる/作り直す」 → 初速が大事 – 小〜中程度の変化：「今ある機能に追加する」 「少しだけ要件を変更する」 → 変更容易性が大事 76/98
77. 新規事業とTypeScript ── 変更容易性と型、表現力 変更容易性が大事＝型の恩恵が重要。特にフルスタックTSのE2E型安全が効く – DBのカラム名やAPIの形を変えると、依存箇所すべてに FE/BEを貫いてコンパイルエラーが伝播する – 「ちょっとミスったカラム名」を気軽にリネームできるのは結構大きい – このリネームetcを怠ると、プロダクトはよくわからないものになっていく また、TypeScriptは、複雑なドメインを表現する力が（比較的）高い – 型レベルの表現力：ユニオン/リテラル/タグ付きユニオン・conditional/mapped typesなど、柔軟 で強力な型システム – 構文の表現力： .map/.filter ・ ?. ・分割代入などの、一通りの便利な構文 – 関数型プログラミング：宣言的なメンタルモデルで綺麗にドメインモデルを記述できる ドメインが複雑かつ変化し続ける新規事業において、ソースコード自体でドメインを表現す ることで、ドメインの解像度があがり、最終的に変更容易性を上げる – 「ソースコードに意図を埋め込む」意図を読み解きやすければ、コードがそのまま仕様書として機能 77/98
78. 新規事業とTypeScript ── 開発速度を高めるチーム設計 （再掲）フルTypeScript構成は、フルスタック・オーナーシップを持ったチーム設計にしや すい このチーム構成が開発スピードを更に高め、試行回数をより多くできる – フルスタック：ひとりでFE/BEを担当、1つの機能開発がコミュニケーションコストなしで完了 – オーナーシップ：間違いに気づいた人が、自分で直しきれる – 新規事業における仕様検討、十分な人員がいない/スピード重視しがちで、要件がガバガバになりが ち。実装者に気づいてもらえると本当にありがたい 「仮説 → 実装 → 学習」のループを、フルスタックTSなら最低限のコミュニケーションコス トで回せる TypeScriptは技術と組織の両輪で変更容易性を高め試行回数を上げ 正解のない新規事業開発を成功に導く 78/98
79. 新規事業とTypeScript ── TSが最適とは限らないケース 変更容易性が事業の制約になっていない場合は、別の軸で選んで良い 初速だけが欲しいなら、AI時代においては言語はもはやなんでも良い – AIによって、初速はコモディティ化しつつある。AIが知ってる言語なら何でも良い – → だからこそ差がつくのは初速ではなく「その後、変え続けられるか」 。TSの土俵はそこ パフォーマンス要件が厳しいなら Go / Rust 組織のスケーラビリティを重視するなら Go – 組織設計に力をいれてる会社が採用している印象（例）メルカリ、LayerX、ナレッジワーク、Ubie 型の恩恵よりもFWの完成度をとるなら Rails/Laravel 他：ミッションクリティカルならより厳しい型のRust、機械学習系で社内にPythonエンジ ニアが多いならPythonなど 79/98
80. まとめ：TypeScript × 組織・事業 採用：FE経験者のコンバート、FE/BE別々の採用も可で選択肢が広い（ただしBE・フルス タック人材はまだ少なく、やりたい人は多い） 組織：1機能を1人で完結＝コミュニケーションコストなしで試行を回せる。オーナーシップ も生まれる 育成：キャッチアップコストは高め。だがオンボーディングへの投資は必ずペイする 事業：E2E型安全で、変化し続けるドメインを磨き込み続けられる＝MVPで終わらせない （再掲）TypeScriptは技術と組織の両輪で変更容易性を高め試行回数を上げ 正解のない新規事業開発を成功に導く 80/98
81. 目次 1. 自己紹介 / 前置き 2. フルスタックTypeScriptという選択 3. 実践（TS全般 / バックエンド / フロントエ ンド） 4. TypeScript × 組織・事業 5. TypeScript × AI
82. このセクションの前提 あくまで「フルスタックTypeScriptで開発している中でのAI利用」の話がメイン AIそのものはあまり深掘りしすぎない 82/98
83. （余談）AIと自分 大学時代、自然言語処理のトップカンファレンスで国内最年少でLong Paperを通した LLMがやれそうなことを、なんとなく分かっている – ……なんてことは全然ない（当時と状況が違いすぎる） 余談：学生の頃は、今のようなAIの時代が来るのはあと20年先だと思っていた – 「意味を計算機に理解させる」というど真ん中のタスクをやっていたので、感慨深い 今の立ち位置はアーリーアダプターくらい（≠イノベーター） – 技術選択の話と同じく、変化が早いAI技術に振り回されるよりも、他のことに時間を使いたい – とはいえ勿論キャッチアップは大事！要はバランス 83/98
84. （余談）AI利用の思い出 ── 2024年 ChatGPTで、複雑なドメインの用語整理、テーブル名・カラム名の相談など – ちょっとしたタスクや調べ物は便利。開発はまだまだだった 2024年後半からAI開発がトレンドに。効率化できる部分はありつつ、正直まだまだ – 過度に騒いでいる人は、普段から大したコードを書いていないんだろうなと思っていた 印象：「賢いけど応用力がない、新卒エンジニアの入社1日目」 84/98
85. （余談）AI利用履歴 ── 2025年 春夏 簡単なCRUD、特定アルゴリズム、お手本コードがあるケースは任せられるレベル 丁寧な指示／丁寧なハーネスがあれば一定ワークする。しかし、まだまだ未熟 – → 要所要所で使う運用。 – Tab補完は死ぬほど便利！！！ この頃はまだ「 as any を乱用」 「通らないテストを消して出してくる」という性能 Cursorを利用していた（CLIとの行き来が嫌だったので） 印象：「めちゃくちゃ賢い、情報系出身の新卒エンジニアの入社1ヶ月目」 85/98
86. （余談）AI利用履歴 ── 2025年 秋冬〜2026年春 2025年11月頃：各社のリリースで、 「もう実用レベルがきた！！！」と驚く 2026年春：ほぼ自分でコードを書かなくなってきた – AIではなく「他人」にコードを書いてもらう必要性すらも、薄く感じてきた Claude Codeを利用。Cursorは純粋にエディタとしてしか使わなくなった 人間の仕事は、要件整理・業務知識のヒアリング・それを元にした設計。実装面はお任せ – 小難しい要件の設計・実装は半分自分で書いてしまうことはある – 100点満点の品質を出したいなら自分で書くが、品質の多少の低さを補って余りある爆速さ – 小難しいアルゴリズム実装は、もう一切太刀打ちできない。制約条件・ドメイン知識をレビュー 印象：「めちゃくちゃ賢く、よしなに汲み取れる優秀で爆速なベテランエンジニア」 – ただし「あと一歩踏み込みが足りないなあ。もう少しで全部任せられるのに…」みたいな印象 86/98
87. AI × TypeScript ってどうなの？ 2025年、TypeScriptがGitHubで最も使われる言語に – 「この台頭は、エージェント支援コーディングを本番環境でより信頼できるものにする型付き言語へ と、開発者の重心が移りつつあることを物語っている」 – 出典：Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1 「明示的な型付けは安全網」 「モデルがTSの例を1兆見て、Haskellを数千しか見ていなけれ ば、TSの方が上手いに決まっている」 – 出典：TypeScript, Python, and the AI feedback loop changing software development - The GitHub Blog （GitHub Next・Idan Gazitのインタビュー） – ※記事の結論は「TSが勝つ未来」ではなく「"移植性が勝つ（portability-wins）"未来」 フルスタックTSなら、型がフロントとバックの境界をまたいで繋がる（より高い型安全性） 「型というハーネス x 豊富な学習データ x E2Eの型安全性」によりAIと相性が良い言語 87/98
88. 型はAIに有益なのか？ コードの生成時にはあまり意味がない（＝フィードフォワード制御） – Claude CodeでもLSPが有効になった。が、LSPはあまり有効でないというコメントも – AIにとって、grepの方が早いこともある（これは人間でも同じですよね） コード生成後の修正時、ガードレールとして非常に有益（＝フィードバック制御） – 型は「書く前のガイド」より「書いた後の検査」として効く – 2025年時点だと、型エラーの修正がうまくできないこともあったが、2026年時点だとかなりの精度 で適切に対応してくれる印象 参考： – AI Coding Agent Enablement in TypeScript / TSKaigi2025 – TypeScriptの型はAIに届いているか？ / TSKaigi2026 – Harness engineering for coding agent users 88/98
89. AI × tsc / eslint tsconfig / eslintともに、堅牢な設定にしている – 「可能な限り厳しいオプションを使用せよ」 - 出典：どのようにTypeScriptを使うのか - uhyo/blog – 特にAI時代は、堅牢にしない理由がほぼない（AIは堅牢でも嫌がらずに書いてくれる） – 堅牢にするデメリットは実行速度だけ → 直近だとoxlintとの併用で解決とか カスタムなlintルールは、自分はあまり作っていない – 元のコードの品質が高ければ、AIも基本的に同じように書いてくれる感覚。目の前の案件ではあまり 困っていない – とはいえ、あった方が絶対に良い。自分が整備をサボっているだけ – 参考：静的解析への投資がAI時代のコード品質を支える ── カスタムESLintルールの設計と運用 89/98
90. AI × テスト AIコーディングエージェントの普及に伴い、テストの重要性が改めて高まっている 現状だと、自分が言える特別な工夫はあまりない – AI時代におけるテスト戦略、もっとハックしたいが、まだ考えきれていないのが正直なところ… – 「テストだけ書いて、あとはAIに開発任せるだけだぜ！（AI時代のTDD） 」みたいな話、Webサービ ス開発の文脈だとそこまで回らなくないですかね？ – ってあたりの話、ぜひ有識者の方教えてください 変更が多く複雑なドメインロジックを、副作用がなくテストしやすい形に切り出した上で、 入念なテストを書いておくのは非常に有益 – テストがあるおかげで、複雑な改修こそをAIに丸投げできて良い 90/98
91. AI × UIデザイン 特別な工夫はできていない – 「デザインシステムをMCP連携」とかやってみたい – 参考： MCPとデザインシステムに立脚したデザインと実装の融合 – 直近でデザインシステムがしっかりしているようなプロダクトに携わっていない – toBのWebサービス新規開発で、UIデザインの重要度が上がるのは一定先かなあ…とは思う 2026年現在だと、初期のUIデザインがしっかりしていれば、特別指示しなくても一定の品質 になる印象ではある – 新規プロダクト開発・新機能開発をやるときは、v0を使うことが多い 非デザイナーでもAIで80点のデザインができる時代、エンジニアでもデザインを見極める眼 をもっておくと便利！ – ちょっとした改修はデザイナーさんに頼らず実施できると良い – ノンデザイナーズ・デザインブックを読もう！！！（昔から言い続けている） 91/98
92. AI x コードレビュー DBスキーマ・APIインターフェース・型・設計は丁寧に見る – 必要があれば、この辺は自分が手書きする。この辺さえ押さえておけば一定安心 細かい書き方はざっくりレビュー – 細かいコード品質は80点〜90点な印象。自分から見てベストな書き方ではないことは多いが、とは いえ不具合には繋がらないだろうと安心できる程度のコード品質・安心感にはなってきた – このやり方で、今のところ致命的なバグは発生していない – 明らかに重要そうな箇所は丁寧に見る。あまりにダメな書き方が多かったらlintルールや CLAUDE.md、rulesへの追加を検討 AIによるレビュー：CodeRabbit と Claude Code のセルフレビューを併用 レビューの代わりにテストを充実させるのは、ベターだが万能ではない – 「足し算をする関数」が正しいか確認するなら、大量のテストより中身を見た方が早くて確実では？ – ブラックボックス／ホワイトボックス的なレビューは一長一短。品質を保証するならどちらも必要 92/98
93. （余談） AIに任せられる範囲はどこまで？ 「あとはやるだけ」の「作業」 – 自分の頭の中に「ソースコードの完成図」があるとき – 自分もよく分かっていない要件・設計・開発内容をぶん投げはダメ これがないと、ソフトウェアの品質を担保できない – 下請けの開発会社に丸投げして、自分は何もチェックせずリリースするようなもの – 丸投げで最初はうまく行くように見えても、いつか重大な不具合が発生する / 発生した時に誰も（AI も）直せなくなる / そもそもプロダクトが意図しない方向に育ってしまう 自動テストで十分に品質が担保できる場合、または品質の担保が不要な個人カジュアルアプ リは、全部を任せてOK 93/98
94. （余談） AIで実装量は上がる。でも、アウトカムは？ AIで実装量が上がるのは間違いない。しかし、アウトカムは本当に増えているか？ 「あった方がベターだが、なくても困らない」機能開発・基盤構築を、本当にやるべきか？ – ソースコードの肥大化により、今後の生産性が下がる（AIも人間も） – 開発リソースが少ないほど、本当に必要な開発だけに集中できる 「実装がボトルネックであるドメイン」と「要件がボトルネックであるドメイン」は、分け て考えるべき – 業務システム開発は、多くの場合で要件がボトルネック – 前者（実装）をAIでハックするのは非常に良い。後者はNG 94/98
95. まとめ：AI時代のフルスタックTypeScript ── 現在地 AIは「新卒1日目」から「爆速のベテラン」へ。実装を任せられる時代に – → 人間の仕事は、要件整理・業務知識のヒアリング・設計へとシフト TypeScriptは、この時代と相性が良い – 型というハーネス × 豊富な学習データ × E2Eの型安全性 – 型は「書く前のガイド」より「書いた後の検査」として効く＝信頼できるガードレール 任せる／任せないの線引きは明確に – 「あとはやるだけの作業」は任せる。要件・設計が曖昧なものは渡さない – アウトプットではなく、アウトカムを常に意識しよう！ – 「実装がボトルネックか、要件がボトルネックか」── 業務システムの多くは後者 95/98
96. まとめ 96/98
97. フルスタックTypeScript ＝ 変化に追従し続ける開発体制 新規事業は「見えないこと」の連続。作って、確かめて、作り変える――この速さ自体が競争 力になる。 変化に強い：フロントからバックまで型がつながり、仕様変更を安全にやり切れる → 一度作って終わりではなく、事業の成長に合わせて磨き込み続けられる 少人数で速い：言語が1つだから、1機能をエンジニア1人が一気通貫で担当できる → コミュニケーション・採用のコストが下がり、小さなチームで大きく動ける AIと噛み合う：型がAIの安全網になり、実装が爆速化する → 人は要件・設計に集中でき、手数ではなく成果に時間を使える 技術選定の目的は、一貫して「事業価値の最大化」 。 フルスタックTypeScriptは、MVPで終わらない、変化と拡張に耐える立ち上げを支える。 97/98
98. ご清聴ありがとうございました （宣伝）Findy Freelanceの申し込みはこちらから！ 98/98