はじめに
株式会社タップルでサーバーサイドエンジニアをしている糸井( Issa )です。
本記事は、11/23に金沢にて開催されたTSKaigi Hokuriku 2025の参加レポートです。現地参加を通じて得られた知見や感想を、チームメンバー（山岸、久保、澁谷、鈴木）と共有します。
TSKaigi Hokurikuについて
TSKaigi は、TypeScript に関するあらゆるテーマを扱う、日本国内最大級のカンファレンスです。当日は 2 トラックに分かれたセッションの中から自由に選択して聴講できるほか、スポンサーブースでは各社が提供するさまざまな TypeScript 関連コンテンツを体験できます。
2025年5月に開催された TSKaigi 2025 では、株式会社サイバーエージェントとしてスポンサーブースを出展し、多くの学びを得ました。タップルのバックエンドは JavaScript で構成された大規模なモノレポから、TypeScript ベースのマイクロサービスへと段階的に分割する取り組みを進めており、前回の参加で得た知見はこのプロジェクトにも活かされ、社内でも好評でした。
約 1 年半にわたるこのプロジェクトも終盤を迎え、その過程で得られた学びを整理・発信したいと考え、今回チームメンバーでプロポーザルを提出し、現地での登壇および聴講に参加しました。
セッションのご紹介
ここでは、私たちが現地で聴講したセッションの中から、特に印象に残ったものをご紹介します。
あわせて、私自身が登壇したセッションについても紹介させていただきます。
リスクゼロでデリバリーする ― Open Feature × DevCycleの機能解放戦略
発表者: 糸井
ありがたいことにチームメンバーでプロポーザルを提出した中で、私の CfP が採択され、本セッションに登壇しました。
タップルのバックエンドでは、JavaScript で構成された大量のコードベースを、TypeScript ベースのマイクロサービスへと段階的に分割する取り組みを進めています。この過程においては、
-
デリバリー速度を落とさないこと
-
本番にリリースされる機能の品質を担保すること
- 障害発生時の影響範囲を最小化すること
この課題に対する解決策として、feature flag の導入を決定し、検討の結果 DevCycle を採用しました。DevCycle には、特定条件のユーザーにのみフラグを適用するターゲティング機能や、段階的に機能を解放できるロールアウト機能が備わっており、開発者体験の観点でも非常に使い勝手の良いツールです。
また、DevCycle は OpenFeature という feature flag の標準仕様に準拠しています。そのため、OpenFeature が提供する TypeScript SDK を利用することで、コードベース上のフラグ評価ロジックを特定のベンダーに依存しない形で実装できます。将来的に feature flag toolを別ベンダーへ移行する場合でも、実装工数や影響範囲を最小限に抑えられる点は大きなメリットです。
もしもfeature flag toolを別のベンダーに移行したいとなった場合の、実装の工数と影響範囲を極小にし移行できることがメリットになります。
結果として、この仕組みを活用することで、約 7 か月間で 100 以上の API を移設することができました。本セッションでは、OpenFeature に準拠したことによって実際に得られた具体的な恩恵についても紹介しました。
TypeScript×CASLでつくるSaaSの認可
聴講者: 山岸
認可の領域は、大規模サービスを運用する中で、積み上げにより複雑になりがちです。今回聴講したPeopleXの坂津さん・芹澤さんによる「TypeScript×CASLでつくるSaaSの認可」は、「PeopleX AI面接」で使われているUI×TypeScript×DBレベルでの認可の実例を用いて、この問題にどのように立ち向かったかという内容でした。
最初に、各認可の特徴・特色などの説明がありました。RBAC（ロールベース）、ABAC（属性ベース）、PBAC（ポリシーベース）、ReBAC（リレーションベース）といった代表的なパターンの違いを、UIを用いて視覚的にわかりやすく復習できました。
これらを実際のサービスに当てはめると、各コンポーネントに対して認可のユースケースが異なるという課題があります。UI上はボタンを見せない、API上はリクエストを通さない、DB上はそもそもデータを引かせない、など、ロールや属性や関係性が入り乱れることで設計が複雑になってしまうという課題にはかなり共感できました。
この課題に対して、TypeScript で書かれた認可ライブラリCASL を軸に、コードレベルで認可をコントロールするアプローチが紹介されました。Ability というクラスに「誰が何をできるか」を宣言的に集約し、UI の表示制御・API レイヤーでのガード・SQL クエリの条件付けまで一貫したポリシーで扱えるように設計されていました。特に、フロントではコンポーネント単位で「このユーザーはこの操作ができるか」を判定し、バックエンドでは同じポリシーを使ってアクセス制御とクエリのフィルタリングをかける構成になっており、「UI上ではボタンが押せないのに API を直叩きすると通ってしまう」といった事故を防ぎやすい設計になっているのがスマートな印象でした。
特にDBへのクエリパターンにアクセスコントロールを持たせる部分は、近年のセキュリティ意識向上も相まって実践したいなと思える内容でした。タップルはMongoDBを使用しているため、CASLとucastを用いたMongoDBクエリ認可を試してみようと思います。
TypeScriptで設計する 堅牢さとUXを両立した非同期ワークフローの実現
聴講者: 久保
アセンド株式会社のmoekaさんによる「TypeScriptで設計する 堅牢さとUXを両立した非同期ワークフローの実現」は、事業拡大で同期的なAPI連携が限界に近づく中、非同期連携基盤へリアーキテクトする際の設計知見を共有するセッションでした。同期連携は分かりやすい一方で、依存関係が増えるほどロジックや整合性要件が複雑化し、UXにも直結して悪影響が出るという課題意識から話が始まります。
本セッションでは整合性・堅牢性・拡張性等といった観点を軸にイベントソーシング / イベント駆動を前提とした非同期連携基盤へのリアーキテクトの方針が紹介されました。また、その中で「ワークフローをどう組むか」「イベントをどう発行するか」「イベントからどう呼び出すか」に分解し、設計方針を共有していただきました。ワークフロー面ではSagaフロー制御の実装方式としてコレオグラフィとオーケストレーションを比較し、連携の特性に応じて両者を使い分ける方針が示されました。
イベント発行と呼び出しの部分ではOutboxパターンによって集約の状態更新と非同期イベントの送信の整合性を担保する実装方針が提示されました。また、イベントの受け取り側のAt-least-once 配信を前提とする際の重複実行対策として冪等キー（Idempotency Key）による冪等性の担保に関しても紹介されました。
そして、TypeScriptの型システムを活用してフローを型付きステートマシンとイベントで表現することによる型レベルの保証や可読性向上を両立するアプローチが紹介されました。そのほかにもEventSourcingとOutboxパターンの制約化などを紹介していただきました。弊社でも非同期連携時におけるイベント駆動パターンなどを採用しているので非常に参考になりました。
Building AI Agents with TypeScript
聴講者: 澁谷
資料: https://speakerdeck.com/izumin5210/building-ai-agents-with-typescript
LayerXの泉さんによる「Creating AI Agents with TypeScript」は、AI未経験のWebエンジニアがどのようにAI開発へ踏み出せるのかを具体的に示すセッションでした。AI 関連の開発と言えば Python のようなイメージがありますが、最近ではフロントエンドとの親和性・型安全性の高さなどの理由から TypeScript が AI Agent 開発の有力な選択肢になりつつあるようです。
セッションでは、Vercel AI SDKを使った実装手法が示されました。Vercel AI SDKは、LLMの出力やツール実行結果をそのままフロントエンドのUI・状態管理に安全につなぐためのライブラリです。モデル差分を抽象化しつつ、ツール定義から推論された型をUIまで伝播できるため、LLMの振る舞いに応じたリッチなUI分岐をTypeScriptで簡潔に実装できます。結果として、チャット状態管理やストリーミング処理を意識せず、UI設計に集中できる点が特徴です。
自作したDeep Research実装を題材に、複数AIエージェントとサブエージェントを連携させる設計も紹介されました。Deep Researchは、質問の明確化、調査指示の生成、サブエージェントによる並列検索、最終レポート作成をワークフローとして制御する仕組みとして実装されていました。各エージェントは関数のように独立して実装され、サブエージェントはツールとして呼び出すことで並列実行が可能になります。これにより、制御性と再現性の高い調査AIを構築できることを示しました。
エージェント実行には長時間処理には耐久性のある実行基盤が必要となります。Vercel Workflowを用いることで、処理を再開可能なStepとして管理し、外部イベントやHuman in the Loopも統合できると紹介されました。
長時間実行を前提としたワークフロー設計や、サブエージェント連携の考え方は、実運用を想定しているAIプロダクトで直面している課題と重なり非常に参考になりました。
TypeScript 6.0で非推奨化されるオプションたち
聴講者: 鈴木
資料: https://speakerdeck.com/uhyo/typescript-6-dot-0defei-tui-jiang-hua-sareruopusiyontati
uhyo さんによる基調講演は TypeScript 6.0 で非推奨化されるオプション、構文、その他一部挙動の変化などを解説していくものでした。私は直近 TypeScript を使ってコードを書く機会が多かったのですが、TypeScript のオプション周りなどは知らないことがまだまだ多く、非常に勉強になりました。以下では、比較的馴染みのあったものを 2 つ抜粋して紹介します。
1 つ目は `target: es5` の非推奨化と新しいデフォルト値に関してです。target オプションはトランスパイルする JavaScript のバージョンを指定するオプションです。これまでは es5 が指定可能であり、かつデフォルト値になっていました。しかし、最近だともう es5 にトランスパイルすること自体ほとんどありません。また、他のツールで代替できるという理由から、es5 の指定は非推奨化され、新しいデフォルト値はリリース時点での最新バージョンになったそうです。
2 つ目は types のデフォルト挙動です。types のデフォルト挙動はこれまでだと全ての types パッケージを読み込むようになってましたが、6.0 から何も読み込まないようになりました。全ての types パッケージを必要とすることはほとんどなく、意図せずパフォーマンスが悪化することを無くすためだそうです。これにより未指定のプロジェクトでは
今回の非推奨化や挙動変更はパフォーマンスを意識したものが比較的多かったそうです。TypeScript のビルド速度は我々のような TypeScript をメインに使う組織にとっては開発生産性に直結する重要な問題です。我々も既に色々な対策を行っていますが、この講演を機にもっと TypeScript のオプション周りなどを勉強して改善を積み重ねていきます。
振り返り
TSKaigi Hokuriku 2025 へ現地参加し、TypeScript に関する実践的な技術的知見を持ち帰ることができました。紅葉に彩られた金沢の街並みや旬の食事を楽しみながら技術について交流できる点に、地方開催ならではの大きな魅力を感じました。
