2025/06/18

テクノロジー

TSKaigi2025で分かったTypeScriptの流行

この記事の目次

    こんにちは、新卒2年目でビジネスイノベーション統括本部ITD1-2-0のS.Hです。
    今回、私が普段の業務で使用しているTypeScriptをテーマにした大型カンファレンス『TSKaigi 2025』の参加レポートを書かせていただきました！

    研修後、現在の部署に配属されてからもうすぐ1年。ほぼ新人の視点から、TSKaigiに参加して感じた魅力などを発信していきます！

    TSKaigi 2025

    カンファレンス概要

    情報区分カンファレンス詳細
    イベント名TSKaigi 2025
    開催日2025/05/23、2025/05/24
    開催場所ベルサール神田
    都営新宿線小川駅から徒歩5分
    ミッション学び、繋がり、"型"を破ろう

    タイムテーブル

    Day1
    Day2

    セッション内容

    TypeScriptネイティブ移植観察レポート TSKaigi 2025

    登壇者： berlysia氏
    セッション時間：2日目朝

    株式会社ドワンゴでWebフロントエンドエンジニアをされているberlysia氏によるts-goの体験レポートです。

    5/23深夜、つまりTSKaigiの1日目夜にMicrosoftから公開されたtsgoのプレビューに触れてみた観察者としての調査報告になります。
    夜中に公開されたので、TSKaigi1日目を終えてそこから触り、登壇資料を作成されたみたいです。バイタリティとメンタルが素直に凄すぎます。

    ts-go1番の特徴はMicrosoftが動画のタイトルにも取り上げられている
    「A 10x Faster TypeScript with Ander Hejlsberg（10倍早いTypeScript）」

    従来はTypeScriptで書かれた構文をNode.jsを用いて実行されていました。それらを全てfunction単位でGo言語に置き換えており、 Go言語の利点を十全に活かすことで10倍という圧倒的なパフォーマンスを実現するに至ったそうです。

    具体的には

    • ソースコードをその場で解釈して実行する Node.jsから、事前に機械語に翻訳されるGo言語へ変わったことによる処理速度の向上 (約3~3.5倍)
    • Node.jsはシングルスレッドモデルの制約があり、単一の処理しかできなかったが、Go言語になったことで並列処理が可能になった (約3~4倍)

    上記の2点が組み合わさったことで、本当にすぐに動くようになったとのことでした。
    しかも、実行するプログラムの規模が大きくなるほど、その早さを実感するそうです。

    「ts-goというものが話題になっている」ということはそれとなく把握していつつも、それが具体的に何なのか知らなかった自分でしたが、10倍という数値だけでもその凄さを容易に想像することができました。
    処理速度が上がったことで、それまでのバージョンでは見送っていたライブラリなども採用されるようになり、より発展的で高度な技術力が求められるようになる、というのが私の所感です。

    そして、そんなに凄いts-goをまだ私は触ることができていないので、このレポートを書き終えたら早速触ろうと思います。

    OST(Open Space Technology)

    タイムテーブルにある通り、本当に多くのセッションがあり、学びが沢山ありました。
    ですが、TSKaigiは登壇者だけが発信する場ではありません。2日目の最後には、セッションルームに集まった参加者が各々好きなテーマについて話し合えるOSTが設けられていました。

    OSTはそのテーマについて熱く語りたいから参加する人はもちろん、ほとんど詳しくないけど、知見を広げたいから参加する人もいらっしゃいました。
    自分はもちろん後者です笑

    今回、TSKaigi中の募集を通して選出されたテーマは下記画像に記載された10個。皆さんはどのテーマに興味を惹かれましたか？

    私は5番の「フロントエンドのディレクトリ構成、どう設計している？」に参加しました。
    というのも、私の周りにはそういった開発理論について考えることが好きな同期がおり、この機を活かして『完全に理解した！』ぐらいの理解度を得てみたいと感じたためです。

    結論からお伝えすると『だいぶん理解したかも？？』ぐらいの理解度を得ることができました。
    もう少し実際に試していくことで『完全に理解した！』の理解度を得られそうです。

    今回のOSTで話題に上がった内容はFSDとBCDデザインの組み合わせです。

    FSD

    まず、FSD(Feature-Sliced Design)とは、機能単位で構造化する設計パターンで、公式では「Architectural methodology for frontend projects(フロントエンドのアーキテクチャ手法)」と定められています。
    機能単位で構造化する、つまり機能ごとに責務を持たせることで、拡張性・保守性・可読性を高めることが可能になることがFSDの特徴です。

    FSDは、レイヤーという役割の抽象的な区分と、そこから実際の機能単位で切り分けるスライス、そしてhookやUIなどの各機能を構成するセグメントで成り立っています。

    出典：FSD(Feature-Sliced Design)

    機能単位でディレクトリを構成することは多いと思いますが、そこから更に責務という名の「機能の持つ役割や義務」に着目して分類する手法がFSDなのです。

    BCDデザイン

    次にBCDデザインは株式会社ドワンゴ所属のmisuken氏が考案されたコンポーネントの分類手法です。
    同期からの受け売りですが、
    「BCDデザインとは Base(UI) Case(動作) Domain(対象)に着目してコンポーネント名を『何をどうするUI』の法則に則って命名すること」なんだそうです。

    私なりの解釈で説明すると、誰でもそのコンポーネント名を見ただけで、役割が分かるようにする手法になります。

    出典：misuken氏のBCDデザイン解説記事

    例えば、ここにフィードバック専用のモーダル画面のコンポーネントがあったとしたら、どのような名前にしますか？
    恐らく、多くの人がFeedbackModal.tsxという名前にするのではないでしょうか？
    それがBCDデザインの命名規則に当てはめると、FeedbackSendModal.tsxになります。

    フィードバックを編集する(Edit)でもなく、削除する(Delete)でもなく、送る(Send)ためのモーダル画面。それが誰にでも伝わる命名規則です。

    ちなみに、この場合でも何のフィードバックなのかが不透明なので、DomainをDomainとCommon(抽象的対象)に分割するBCCDデザインというものもあります。
    また、misuken氏のBCDデザイン解説記事では、「"命名" するのではなく "明名" すると考える」と表現されていました。

    OSTまとめ FSD × BCDデザイン

    「抽象的な責務で分類し、機能単位でディレクトリ構造化を図るFSD」と
    「誰にでも伝わるコンポーネント明名手法のBCDデザイン」

    この2つを組み合わせることで構造も名前もはっきりと定まった方針で分かりやすくフロントエンドのディレクトリ構成が実現できる、というのが今回のOSTに関する結論になりました。

    今回のディレクトリ構成OSTには15名近くの方が集まり、その中でもFSDとBCDデザイン、それぞれの知見を深く持った方が2人ずついらっしゃったので、本当に濃い議論をすることができました。
    個人的には、今回のBCDデザイン側に株式会社ドワンゴの社員さんがいらっしゃったことに一番衝撃を受けました。流石TSKaigi、一般参加される方も凄い。

    企業ブース

    私は今回のカンファレンスでブースを設けられていた企業様のイベントも目一杯体験してきました。
    恐らく、会社から一緒に行った7人の中で最も詳しく企業ブースのレポートを書けると思うので、こちらも詳しく書かせていただきます！
    (各ブースで実施されたスタンプラリーを1日目で制覇しました)

    流石に全ブースについて書くと時間が足りないので、今回は2つほど特に面白いと感じた企業様のブースを取り上げさせていただきます

    AVITA株式会社


    AVITA株式会社は大阪大学の教授が代表を務めるスタートアップ企業です。
    大学の研究室と企業、両方から特許申請を活発に行い、週に1回ペースで特許申請会議があるそうです。
    "特許申請会議"。字面がとても強い

    提供しているwebサービスは、
    「フロント・バックエンドがフルスタックのTypeScriptで実装されたWebアプリ」
    と
    「Unity × TypeScriptで運用されているスマホアプリ」です。

    色々お話をお伺いした中で、私が特に面白いと感じた点は真ん中のディスプレイで動いているトラッキング技術です。
    これはディスプレイ上部のカメラから取り込んだ映像を元にフェイストラッキングとハンドトラッキングを同時に実行されています。
    この処理には、Googleが提供している画像解析によるトラッキング専用ライブラリMediaPipeが利用されています。

    その中でも面白いと感じた要素は、とにかくトラッキングの精度が高すぎる点です。
    MediaPipeは機械学習によって手の状態を画像解析を行い、「恐らくこの辺りに手の関節があるだろう」といった判定を下します。そのため、動画のように連続してトラッキング対象が動く状況だと著しく精度が落ちます。
    実際、以前に自分がMediaPipeを試したときは指関節がはちゃめちゃに暴れ回り、画面内に描写された手は見事に潰れていました。
    それなのに、こちらのプログラムは滑らかに動く実物の手に追従して、関節座標も暴れることなくしっかり手の動きを再現していました。

    Unityアプリの出来から垣間見えた開発者さんの膨大な努力に圧倒され、ものすごく興奮しました。
    TypeScriptの話はできませんでした…


    お土産にシールやアクスタをいただきました笑

    スパゲッティコード、マジックナンバー
    イラストはとても可愛いのにワードが全く可愛くない

    アクスタも作るぐらいIP展開にも力を入れ始めたらしいです。いつか販売されるのを楽しみにしています！

    株式会社TwoGate

    TypeScriptベースのWebアプリフレームワーク"Angular"を使ったエンターテイメント領域向けに利用者専用にカスタマイズしたスマホアプリをリリースしている会社です。

    1日目のお昼にLT登壇もされていました。
    推し活を支えるAngularアプリ量産体制

    こちらの企業から沢山お話を聞いた内容はサービスの根幹部分の「Core Library Repository」についてです。
    TwoGate様はアーティストの要望に沿って推し活の専用アプリをリリースしており、開発エンジニア15名ほどに対し、リリースしているアプリ数は200個を超えています。
    平均1人当たりアプリを15個ほど担当しているような状況でも成り立っている理由はリリースしたアプリ全てが「Core Library Repository」というこの企業独自のライブラリから作られているからです。
    つまり、Core Library Repositoryがあれば、多少のカスタマイズをすることで誰でもチケット販売や整理券配布などの機能を持った専用アプリを作ることできる。そんなライブラリを作り上げ、それを元にサービスを提供しているとのことでした。

    私たち開発エンジニアが普段活用しているようなライブラリを作り、その運用を事業として行なっている一風変わった企業様でした。

    TSKaigiに参加して

    今回、私は下記の2つのセッションに参加し、その上で実際にそれぞれの技術に触れてみたので、それぞれから感じた今後に対する所感をまとめさせていただきます。

    CSSライブラリ - PandaCSS

    PandaCSSを知ったことをきっかけに、実際に個人で触れてみる中で、TailwindCSS以外のCSSライブラリにも視野を広げる良い機会になりました。使ってみることで、それぞれのライブラリが持つ特徴や考え方の違いも見えてきて、フロントエンドに対する理解が一段深まったように感じます。

    一方で、実際にNext.jsのプロジェクトに組み込もうとすると、TailwindCSSのように簡単にセットアップできるわけではなく、PandaCSSは別途インストールや設定が必要です。その分、Dockerfileなどの構成にも工夫が必要で、開発や保守とはまた違った知識が求められる点には留意する必要があると感じました。

    こうした経験から、CSSライブラリの選定には機能性だけでなく、導入のしやすさやチームの開発環境との相性も含めて検討することの重要性を実感しました。

    コーディングエージェントについて

    最近よく耳にする「コーディングエージェント」ですが、これまでは最低限のサポートツールとして使っている程度でした。実際のところ、補助的にコードを書いてくれる便利な存在、という認識しか持っていませんでした。

    しかし今回、プロンプトをしっかり設計してAIとやり取りしてみたことで、印象が大きく変わりました。AIを効果的に活用するには、「どう指示するか（＝プロンプト）」の工夫がとても重要で、これ自体が一つのスキルだと感じました。いわゆる“プロンプトコーディング”が、今後開発エンジニアに求められる新しい力になると思います。

    また、個人的な気づきとして、会社でコーディングエージェントを活用していくには、プロンプトの作り方だけでなく、それをどう管理するかも大切になってきそうです。チームでの共有や再利用、更新のしやすさなど、コードと同じように「プロンプトの品質」も考えていく必要があると感じました。

    TSKaigiの感想

    私はTSKaigiに初めて参加し、本当に貴重な経験を沢山することができました。

    今回のカンファレンスに対して、職場環境以外からのインプットを求めて参加をしました。
    職場という技術的にも思想的にもある程度方針が固まっている環境以外からの発信に多く触れることで、技術研鑽というアウトプットに対するモチベーションへ繋げたいと考えていました。

    実際、先ほどの章で触れた通り、これまで触れていなかった技術や概念に挑戦するきっかけとなりました。
    その結果、壁にぶつかったことで新たな課題が見つかりましたが、それでもTSKaigiに参加しなかったら得られなかったものなので、職場環境以外からのインプットはとても価値のあるものだと実感しています。

    まだ、技術スタック的に業務と直接交わることのないものですが、今後PJや状況が変化した先で繋がるタイミングがあると思うので、これからもアウトプットを続けていきたいと考えています。

    また、今回の1日目は平日に開催されていましたが、外部研修の一環で公休の申請が降りたため、参加しやすい環境になっていた点がとても有難かったです。
    同期や先輩を含め7人での参加は初めての経験だったこともあり、自分が見て回れなかったブースやセッションの話も聞くことができ、TSKaigiをより楽しむことができたと実感しています。

    お弁当も美味しかったです

    おまけ

    TSKaigiでいただいたサプライ品が気に入りすぎて、社用にカスタマイズしました。
    右のタグはTSKaigiで知り合った方に作り方を教わって作成した自己紹介タグです。

    イベントで大活躍間違いなし！爆速相互フォローを実現するNFCタグキーホルダーを作ろう

    ※本記事は2025年06月時点の情報です。

    著者：マイナビエンジニアブログ編集部

    人気のあるタグ