🏗️
実践！バックエンドTypeScript〜現場から学ぶtsの可能性〜 イベントレポート
かつてはフロントエンドの言語というイメージが強かったTypeScript。しかし今、その潮流はバックエンドの世界にも力強く流れ込み、Node.jsエコシステムにおける主要な選択肢としての地位を確立しました。静的型付けがもたらす堅牢性と、JavaScript由来の柔軟な表現力。その両刃の剣を、現場のエンジニアたちはどのように使いこなし、どのような未来を描いているのでしょうか。
2025年7月15日に開催された本イベントでは、バックエンドTypeScriptを実践する4つの企業が集結。ライブラリ選定の思想、新卒エンジニアのリアルな体験、ドメインモデリングの探求、そして急成長を支えるアーキテクチャの進化まで、それぞれの現場から届けられた生の声は、TypeScriptが単なる「言語」ではなく、チームの「設計思想を映す鏡」であることを浮き彫りにしました。
『安定した基盤システムのためのライブラリ選定』
株式会社カケハシ / kosui (岩佐 幸翠)氏
トップバッターとして登壇したカケハシの岩佐氏は、医療という極めて高い信頼性が求められる領域で、いかにしてTypeScriptを用いて「安定した基盤システム」を構築しているか、その思想を語りました。
なぜ、GoやJava、Rustといった堅牢な言語ではなく、TypeScriptを選ぶのか。その答えは、**複雑なドメインを表現する「型の表現力」**にありました。
「認証認可の複雑な状態遷移、ディレクトリサービスの階層構造、これらをコードで表現し、仕様とコードが一致している状態を担保したい。その時、TypeScriptの型が我々の味方をしてくれる」 —— 株式会社カケハシ 岩佐 幸翠氏
同社のプラットフォームでは、値やエンティティ、状態といったドメインの構成要素をまず「型」で表現し、チームの共通理解を形成します。これにより、仕様の誤りや実装の矛盾が「型検査エラー」として早期に発見できるのです。
この「型とスキーマ」を中心とした思想は、ライブラリ選定にも貫かれています。
Webフレームワーク: 豊富なDIコンテナを持つNestJSから、Web標準に準拠し、スキーマ駆動な設計と相性が良いHonoへと移行。特定のフレームワークにロックインされず、移植性を高く保つという強い意志が感じられます。
データベース: 強力なORMであるPrismaではなく、発行されるSQLが予測しやすいクエリビルダ（Kysely, Drizzle）を選好。ここでも、システムの振る舞いを透明に保ち、制御下に置きたいという思想が垣間見えます。
基盤システムに求められる「正しさ」を、TypeScriptの型システムを最大限に活用して仕組みで担保する。その徹底したアプローチは、多くの参加者に深い感銘を与えました。
『新卒エンジニアから見たフルスタックTS開発環境の開発者体験』
トグルホールディングス / 高橋 哉人氏
続いて、今年入社したばかりの新卒エンジニアである高橋氏が、フレッシュな視点から「フルスタックTypeScript」の開発者体験を語りました。これは、TypeScriptがもたらすもう一つの側面、すなわち学習コストの低さと開発スピードに光を当てるものでした。
「一つの言語が分かればフロントエンドもバックエンドも実装できる。これは私のような新卒からしたら、かなりありがたかった。早い段階でフルスタックな機能開発に携わることができました」 —— トグルホールディングス 高橋 哉人氏
言語の壁がないことで認知負荷が下がり、チーム全員がプロダクト全体に責任を持つことができる。これにより、柔軟な開発体制やスムーズな知識共有が実現すると言います。
しかし、高橋氏の発表の真骨頂は、その「落とし穴」への言及にありました。設計が甘いと、類似したスキーマが乱立して混乱を招いたり、コンポーネントの引数が肥大化して可読性が著しく低下したりする。これらの失敗談を通して、彼がたどり着いた結論は非常に示唆に富むものでした。
「TypeScriptは、その設計の甘さを、コンパイルエラーや複雑で使いにくい型として映し出してくれる。私たちに『良い設計とは何か』を問い続け、コードを健全な状態に保ってくれる強力なパートナーになり得る」
TypeScriptは、ただ優しいだけの言語ではない。それは、私たちの設計スキルを厳しく、しかし誠実に評価してくれる「鏡」なのです。
『読書会からはじめる関数型ドメインモデリング』
株式会社カミナシ / 倉澤 直弘氏
TypeScriptという「鏡」に、何を映すべきか。その答えを、ドメインモデリングという観点から深く探求したのが、カミナシの倉澤氏です。彼のチームでは、書籍『関数型ドメインモデリング』の読書会を通じて、TypeScriptに適したアーキテクチャを模索していると言います。
倉澤氏が強調したのは、DDD（ドメイン駆動設計）の本来の目的、すなわち**「ドメインエキスパートと開発者、そしてソースコードまでが、翻訳のいらない共通の理解を持つこと」**でした。
そのために重要なのが、以下の2つの原則です。
技術的制約をモデリングに持ち込まない: まずはデータベースやクラスの都合を忘れ、ビジネスのイベントやワークフローそのものを理解することに集中する。
コードによって文書化する: 理解したドメインを「型」としてコードで表現する。型自体がドキュメントとなり、設計と実装の乖離を防ぐ。
これは、先の岩佐氏が実践していた「型でドメインを表現する」アプローチを、より哲学的なレベルで体系化したものと言えます。ビジネスロジックを純粋な関数として表現し、副作用（データベースアクセスなど）をアーキテクチャレベルで分離する。この関数的なアプローチによって、システムの関心事を分離し、複雑なドメインをクリーンに保つことができるのです。
読書会というボトムアップの活動から、チーム全体の設計思想をアップデートしていく。その地道で知的な営みは、TypeScriptのポテンシャルを真に引き出すための王道と言えるでしょう。
『Scaling Fast with Confidence: Evolving NEWT’s Backend Code Architecture』
株式会社令和トラベル / Rodrigo Ramirez氏
最後に、令和トラベルのRodrigo氏が、海外旅行予約アプリ「NEWT」の急成長を支えるバックエンドアーキテクチャの「進化」について語りました。これは、これまで語られてきた思想や原則が、ビジネスの荒波の中でいかに試され、適応していくかという、生々しい実践の物語です。
開発スピードを最優先した初期の技術選定（TypeORM, モノリス的モノレポ）は、事業の急拡大に伴い、いくつかの課題に直面します。
依存性のリスク: 活発なエコシステムの裏返しとして、ライブラリのメンテナンス停止や破壊的変更にどう対処するか。
密結合の罠: TypeGraphQLとTypeORMを密に連携させた結果、スキーマがデータベース構造に強く依存してしまい、柔軟な変更が困難に。
モノリスの限界: チームとプロダクトが増えるにつれ、単一のデプロイ単位では追いつかなくなる。
これらの課題に対し、Rodrigo氏のチームは、インクリメンタルなアーキテクチャ改善で立ち向かいました。ORMをリポジトリ層で抽象化し、デコレーターベースの密結合を分離し、モノリスを複数のパッケージからなる「真のモノレポ」へと進化させる。
彼の話から伝わってくるのは、「完璧なアーキテクチャは存在しない」という現実と、「しかし、常に進化し続けることはできる」という強い意志です。ビジネスの変化に合わせてアーキテクチャを育てていく。その現実的なアプローチは、多くのスタートアップにとって、勇気と指針を与えるものでした。
TypeScriptは、設計思想を問い続ける
4社の発表は、それぞれ異なる角度からバックエンドTypeScriptの可能性と課題を照らし出しましたが、その根底には共通したメッセージがありました。
TypeScriptがもたらす最大の価値は、単なる型の安全性ではなく、「良い設計とは何か」という問いを、チームに絶えず突きつけてくれることにあります。型の表現力は、ドメインの解像度を上げ、ビジネスロジックを明確にすることを要求します。コンパイルエラーは、設計の矛盾や不整合を白日の下に晒します。フルスタックで使えるという自由さは、裏を返せば、一貫した設計思想がなければカオスに陥る危険性を孕んでいます。
ライブラリを選び、アーキテクチャを設計し、ドメインをモデリングする。その一つひとつの選択が、TypeScriptという鏡に映し出され、チームの開発文化を形作っていく。この言語と共に歩むということは、コードを書くことを通じて、チームの、そして自分自身の「設計思想」と向き合い続ける、知的な旅路なのかもしれません。刺激に満ちた素晴らしいイベントでした。
Yardでは、AI・テック領域に特化したスポットコンサル サービスを提供しています。
興味がある方は、初回の無料スポットコンサルをお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
Read next
Loading recommendations...