目次
- はじめに
- イベントの様子
- スポンサーブース
- ブース企画
- エントランス企画ゾーン
- セッション紹介
- 各社スポンサーブース
- まとめ
- アフターイベントのご案内
- 最後に
はじめに
2026年5月22日(金)、23日(土)に開催された TSKaigi 2026 に、弊社の開発本部から 6 名のエンジニアが参加してきましたので、イベントの様子や印象に残ったセッションをご紹介します。
各セッションのアーカイブも公開予定とのことですので、ぜひ公式サイト・YouTube チャンネルなどをチェックしてみてください。
イベントの様子
スポンサーブース
エブリーは今回、ゴールドスポンサーとしてブースを出展させていただきました！
足を運んでいただいた皆様、本当にありがとうございました！
ブース企画
1. アンケートボード「あなたのAI活用、どこまで来てる？」
ブースでは、エンジニアの皆さんのAI活用状況を伺うアンケートを実施しました。
回答いただいた多くの皆様、ありがとうございました！最終結果はこちらです……！
キャリア0〜5年の若手から15年以上の大ベテランまで、非常に幅広い層のエンジニアの皆様に回答いただきました！
結果としては、「指示は出すが都度レビュー」「並列で動かしている」という回答が多く、「AIに全任せするのはまだ難しい...」「並列で回すとコンテキストスイッチが大変...！」といった声も寄せられ、興味深い結果となりました！
2. 食クイズ＆くじ引き
さらに、エブリーとしては初の試みとなる「クイズ企画」も行いました！
クイズに参加していただくことで、キッチングッズ（まな板、計量スプーン、しゃもじ、お箸）が当たるくじを引けるという形式です。
クイズは大盛況で、「これ見たことある！答えなんだっけ！」「簡単じゃん〜……ってうわ！間違えた！」と、皆さん真剣かつ楽しそうに頭を悩ませてくださる姿が印象的でした。ブース担当メンバーも、皆さんのリアクションを見ながら一緒に盛り上がることができ、企画して本当に良かったと感じています！
エントランス企画ゾーン
Day1にネイル企画がありプロのネイリストによるネイル体験をしてきました！
メニューは「ネイルアート」か「ネイルケア」のいずれか好きな方を選ぶことができました。
綺麗にケアされた自分の手元が視界に入るたびにテンションが上がり、大満足の体験でした！キーボードを叩くモチベーションも爆上がりです！！
セッション紹介
ビジネスモデルから紐解く、AI+型駆動開発
発表者: omote（株式会社 estie） レポート: 江﨑
estie の omote さんによるセッション「ビジネスモデルから紐解く、AI+型駆動開発」について紹介します。スライドは以下で公開されています。
本セッションは「AI 時代における開発のスタート地点はどこか」という問いから始まり、開発体験やフロントエンドのベストプラクティスではなく ビジネスモデルこそが設計の起点になる という仮説のもと、ビジネスモデル別に「型設計を AI とどう組むか」を整理していく構成でした。
型の「重心」はビジネスモデルで決まる
型はクライアント・API・データのどこにでも書けますが、設計エネルギーを最も注ぐ場所はプロダクトごとに違います。omote さんはその場所を 型の重心 と呼び、技術スタックではなく事業構造で分類すべきだと整理していました。具体的には、プロダクトを次の 4 つに分けています。
| 分類 | 価値の源泉 | 型の重心 | 型の Origin |
|---|---|---|---|
| インタラクション中心 SaaS 型 | ユーザー入力・編集体験 | UI 状態・フォーム・権限 | TypeScript 自身 |
| データ依存型 | 外部データ・ドメイン知識 | API レスポンス・ドメインモデル | DB / GraphQL スキーマ |
| API 中心マイクロサービス型 | API 契約そのもの | コントラクト・スキーマ定義 | .proto / OpenAPI |
| マーケットプレイス型 | マッチング・取引の成立 | 取引データのスキーマ | 中央ドメインモデル |
価値の源泉と重心、Origin がフラットに 4 分類で並ぶことで、自分の関わっているプロダクトをそのまま当てはめながら聞ける構成になっていました。
型の Origin と AI への渡し方
もう一段下の問いとして「型はどこから来るのか（Origin）」も提示されていました。SaaS 型・マーケットプレイス型では人間が Origin を定義する側になり、データ依存型・API 中心型では既存スキーマや契約から型を受け取る側になります。つまり TypeScript の役割はビジネスモデルによって 定義する側 と 受け取る側 の 2 つに分かれる、という整理です。
ここを踏まえると、AI に渡す「文脈の深さ」によって出力の質も変わってきます。
- Level 1: 自然言語だけ
- Level 2: TypeScript の派生型を渡す
- Level 3: Origin 自体、または Origin に近い型情報を渡す
Level 3 まで踏み込むと、データソースの制約や整合性まで型として運ばれるため、Claude の出力が事業文脈と整合した実装になりやすい、という話でした。実例として、SaaS 型とマーケットプレイス型の 2 つが、Claude への入力と出力の対比で示されていました。
SaaS 型 — フォーム状態を Discriminated Union で渡す
人間側では、フォームの状態と送信エラーを Discriminated Union で定義した型を Claude に渡します。
type InviteMemberFormState =
| { status: "editing"; email: string; role: Role; errors: ValidationError[] }
| { status: "confirming"; email: string; role: Role }
| { status: "submitting"; email: string; role: Role }
| { status: "succeeded"; invitedEmail: string }
| { status: "failed"; email: string; role: Role; error: SubmitError };
type SubmitError =
| { code: "already_invited"; existingMemberEmail: string }
| { code: "quota_exceeded"; currentCount: number; limit: number }
| { code: "network_error" };
type Role = "admin" | "editor" | "viewer";
この型を添えて「この InviteMemberFormState を満たす React コンポーネントを実装してください」と依頼すると、Claude は失敗時の表示を次のような switch で出力します。
function FailedView({ error, onRetry, onCancel }: FailedViewProps) { switch (error.code) { case "already_invited": return <p>{error.existingMemberEmail}はすでにメンバーです</p>; case "quota_exceeded": return ( <p> 招待上限（{error.limit}）に達しています（現在 {error.currentCount}{" "} 名） </p> ); case "network_error": return <p>ネットワークエラーが発生しました。再度お試しください</p>; } // ↑ 'code' の網羅性が型レベルで保証される。新エラー追加時もここでコンパイルエラー }
各エラーコード固有のプロパティ（existingMemberEmail ・ limit ・ currentCount）に型安全にアクセスできており、switch の網羅性チェックが型レベルで効いている点が示されていました。新しいエラーコードを追加した際にも同じ箇所でコンパイルエラーになるため、AI 出力に対するガードレールが型で担保されているのがよく分かります。
マーケットプレイス型 — 中央スキーマを Origin として渡す
マーケットプレイス型では、売り手・買い手・運営・取引整合性といったあらゆる方向の関心が、中央スキーマ Transaction に集約されます。これを Origin として Claude に渡す形になります。
// あらゆる方向からの依存が、ここに集約される
type Transaction = {
id: TransactionId;
sellerId: UserId; // 売り手の関心
buyerId: UserId; // 買い手の関心
price: number;
platformFee: number; // 売り手・運営の関心
shippingAddress: Address; // 買い手のみ
trackingNumber: string | null;
status: TransactionStatus; // Discriminated Union（全方向の関心）
// ... タイムスタンプ群、双方向の評価
};
「この中央スキーマから SellerTransactionView と BuyerTransactionView を派生させてください」と依頼すると、Claude は Pick で必要なフィールドだけを切り出し、netRevenue や totalPaid といった派生プロパティを足した型を出力します。
// 売り手向け
type SellerTransactionView = Pick<
Transaction,
| "id"
| "itemId"
| "buyerId"
| "price"
| "platformFee"
| "shippingFee"
| "trackingNumber"
| "status"
| "buyerRating"
> & {
netRevenue: number;
};
// 除外: shippingAddress, sellerRating
// 買い手向け
type BuyerTransactionView = Pick<
Transaction,
| "id"
| "itemId"
| "sellerId"
| "price"
| "shippingFee"
| "shippingAddress"
| "trackingNumber"
| "status"
| "sellerRating"
> & {
totalPaid: number;
};
// 除外: platformFee, buyerRating
Transaction 自体には手を加えず、Pick で必要なフィールドだけを切り出して派生型を機械的に生成している点がポイントで、「何を売り手に見せ、何を買い手に見せるか」という事業判断は中央スキーマの段階で人間が決めておかなければならない、という対比になっていました。
所感
プロダクト開発の設計と言われると、つい開発体験やフロントエンドのベストプラクティス側から話が始まりがちです。それに対し、本セッションでは 起点をビジネスモデルに置き、型の重心と Origin で具体まで落とす という流れが一貫していて、ビジネスモデルと型の関係性が非常に丁寧に整理されていたのが印象的でした。
実装が AI に委ねられるからこそ、人間が残すべき仕事は「型をどこに置くか」「Origin をどう定義するか」という意思決定だ、というメッセージも明確で、AI と分担して開発を進める際に人間側に残すべき判断をはっきりさせてくれる内容でした。自分が関わっているプロダクトについても、まずは「型の重心はどこにあるのか」を棚卸しするところから取り入れてみたいと感じました。
TS 7: How We Got There
発表者: Jake Bailey (Microsoft) レポート: パンダム/rymiyamoto
私からは Microsoft の Jake Bailey さんによるキーノート「TS 7: How We Got There」について紹介します。スライドは以下で公開されています。
本セッションでは、TypeScript の処理系を JavaScript から Go へ移植する取り組みについて、その動機・ポートを支えた手法・段階的なリリース戦略が紹介されました。
なぜ Go だったのか
tsc / tsserver は数千万行規模のコードベースや 2,000 個以上の tsconfig.json を扱うユーザーが現れる中で、JavaScript ランタイムの制約（スレッド間でのオブジェクト共有不可、async/await の関数色分け、4GB のメモリ上限）からパフォーマンス改善が限界に近づいていたとのことです。
「rewrite ではなく port」を前提に Rust / C# / Zig などと比較したうえで Go が選ばれた理由として、以下が挙げられていました。
- TypeScript（class より data + 関数 + 構造的 interface 寄り）と構造が近く、コードを 1:1 で移し替えやすい
- GC があるため AST の循環参照を意識せずに書ける
- goroutine による並行性を、関数の色分けなしに導入できる
- 学習コストが低く、チームの 10 名ほどが数日で生産的になれた
ライブラリ単体ではなく「チーム全員が短期間で動ける」観点で言語選定している点は印象的でした。
Snapshot テストと Differential Fuzzing
ポートを支えた手法として、特に Snapshot（ベースライン）テストと Differential Fuzzing が紹介されていました。
Snapshot テストは、出力をファイルとしてリポジトリにコミットし、PR の diff で挙動変化を確認する手法です。TypeScript では新旧コンパイラの出力差分そのものを baseline として扱い、その差分ファイルが消えること自体をポート完了の指標にしているとのことでした。
Differential Fuzzing は、新旧の実装に同じ入力を fuzzer から流し込み、結果が一致しない入力を自動で発見させる手法です。Go では組み込みの fuzzer で以下のように記述できます。
func FuzzToFileNameLowerCase(f *testing.F) { f.Add("foo/bar/baz.ts") f.Add("C:/foo/bar/baz.ts") f.Fuzz(func(t *testing.T, p string) { want := oldToFileNameLowerCase(p) got := ToFileNameLowerCase(p) assert.Equal(t, want, got) }) }
ユニットテストで取りこぼしがちなエッジケースを fuzzer に探させる発想は、性能改善で挙動を保ったまま実装を差し替える場面で特に有効で、自身の業務にも持ち帰りたい手法でした。
所感
会場のライブデモでは、tsc が数分単位で進まない遅さを見せたあと、tsgo に切り替わった瞬間に 10 秒足らずで型チェックが終わり、スライドの「VS Code（約 2.3M LoC）で tsc 比 約 10 倍・クラッシュ率約 1/20」という数字をその場で体感することができました。また発表中には「昨年の TSKaigi 2025 のタイミングでは tsgo のクラッシュが多かった」という話に触れられて会場が湧いていましたが、その状態から 1 年でテレメトリと継続的な改善でクラッシュをほぼ潰し、ここまで仕上げている開発スピードには、純粋に驚かされました！
特に Differential Fuzzing は、自分が普段触っている Go バックエンドで「速度改善のために旧実装と挙動を変えずに置き換えたい」場面と相性が良さそうで、まずは小さな関数で testing.F を使った新旧比較から試したいと考えています。一方で、ベースライン駆動のレビューは出力ファイルを丸ごとコミットする運用になるため、レビュー差分の見やすさと引き換えにリポジトリ容量や CI の負荷が膨らみそうで、テスト数を踏まえてどこから採用するかは見極めが必要そうです。フロントエンドの TypeScript 側でも、tsgo が 7.0 として安定すれば CI の型チェック時間が大きく改善する余地があるので、ベータの様子は引き続き追っていこうと思います。
制約と時代から読み解く TypeScript コンパイラ設計史
発表者: Yoshiaki Togami (株式会社メルペイ) レポート: 庄司
私からは Yoshiaki Togami さんによるセッション「制約と時代から読み解く TypeScript コンパイラ設計史」について紹介します。 スライドは以下で公開されています。
本セッションでは、TypeScript Compiler がなぜ「独特な内部設計」を持つに至ったのかを、 当時の時代背景と JavaScript の制約を交えつつ、Go port による改善までを整理する構成となっていました。
TypeScript Compiler の「独特さ」
冒頭で TypeScript Compiler のパイプライン（Scanner → Parser → Binder → Checker）と、 識別子から宣言へたどる Symbol が紹介され、Compiler の構造的な「独特さ」として 2 つの特徴が挙げられました。
- Binder が AST に semantic を後付けするため、意味情報が構文木と同居する
- AST の親子や Symbol 間でアクセスできるようにするために循環参照が発生する
C# コンパイラで採用されている Red-Green Tree というデータ構造を採用することで、immutability と semantic へのアクセス可能性を両立できないかというアイディアもありましたが、 当時の JS では Worker API などもなく immutability を活用しきれない点やメモリ消費が大きくなってしまうという点から見送られました。
設計を決めた時代背景と JS の制約
TypeScript の設計が決まった 2010 年前後には以下のような技術的背景がありました。
- 2004〜2006 年の Ajax 革命（Gmail / Google Maps / Google Docs）で「JS で本格的なアプリ」が現実味を帯びる
- 2008 年に V8 が公開される。（しかし、ES5 段階では Worker API がなく最適化も未熟）
- JS ツーリングが貧弱で開発体験が悪い
これらを踏まえて、以下のような3つのアプローチが取られました。
- JS を遠ざける（Script# 等、別言語で書いて JS にトランスパイルする）
- JS 自体を置き換える（Dart 等）
- JS のスーパーセットとして型を追加する（Strada -> TypeScript） これは「ターゲット言語からそこまで離れるくらいなら JS 自体を直すべきでは」という発想から出たアイディア
結果的には、SharedArrayBuffer 等の共有メモリ機構が未整備で、オブジェクトヘッダのメモリオーバーヘッドも大きいという背景から、 immutability やメモリ消費を犠牲にして、現在の「AST が意味情報を背負う・循環参照あり・単一ツリー」という設計になった、という整理でした。
Go port による改善
最後には、ここまで触れてきた制約が Go port でどう解消されるのかが紹介されました。 tsc → tsgo の高速化の背景として、大きく 2 つのポイントが挙げられました。
- 単一の Go バイナリへのネイティブ化によるウォームアップリードタイムの削減
- 共有メモリによるキャッシュヒット率改善やマルチスレッド並列化
所感
TypeScript Compiler の内部設計の独特さについて、当時の時代背景込みで聞ける機会は少なく、とても面白かったです。 当時の JS 特有の仕様的制約から現実解を模索していった流れは技術選定全般への向き合い方としても興味深いものでした。
利用している技術がどんな課題を解決するために生まれたソリューションなのかを知ることが、 ツールを使いこなす上でも重要であることを改めて感じることができました。
いつテストを書くか？―ソフトウェア開発における安心と不安について考える
発表者: lacolaco（株式会社TwoGate） レポート: 黒髙
私からは TwoGate の lacolaco さんによるセッション「いつテストを書くか？―ソフトウェア開発における安心と不安について考える」について紹介します。スライドは以下で公開されています。
私自身、lacolaco さんがパーソナリティを務めるポッドキャスト「リファラジ｜リファクタリングとともに生きるラジオ」のリスナーだったこともあり、本セッションは聞く前から楽しみにしていました。
加えて最近は AI にテストを書かせる場面が増えたことで「そもそもテストを書く意義はなんだったか」が曖昧になってきており、自分がどう向き合うべきかを改めてはっきりさせたい、というのが個人的な動機でした。
本セッションは、Agentic Coding が広がる中であらためて「テストを書く意義」を問い直すために、ソフトウェアの本質的な性質である「変更容易性」 を補助線として、テスト駆動開発と開放閉鎖原則の関係を整理しなおしていく構成でした。
保守性の本質は「変更容易性」である
このセッションは、AI によって開発速度が上がったからこそ「保守性の限界」がすぐ目に見える形で訪れるようになっている、という提起から始まります。保守性の本質は 変更容易性 であるという前提のもと、「変更容易性はソフトウェアに内在する性質ではなく、人間とソフトウェアとの関係として現れる」と説明されていました。
変更容易性の 2 層モデルと、開放閉鎖原則の再解釈
変更容易性は次の2つの独自定義で捉え直されていました。
- 予期的変更容易性: 変更を行う「前」に開発者が抱く「変更のしやすさ」の感覚。必要な作業量・影響範囲・成功確率・失敗時のリスクへの予期。要するに、開発者の不安や恐怖の程度 そのものである。
- 経験的変更容易性: 変更を行っている「最中」に開発者が経験する「変更のしやすさ」の感覚。実際にかかった労力や、影響した範囲、引き起こした副作用。ソフトウェア側から返ってくる「変更への抵抗」の程度 である。
そして、ソフトウェアが「ソフト」である状態は この 2 つの変更容易性が両立している状態 として定義しなおされます。「容易そうだと思える」ことで変更の機会そのものが増え、「実際に容易である」ことで変更の合理性が高まる。アーキテクチャはこの両立を実現する構造を目指すものだ、という整理です。
同時に、ご存知の方も多いでしょう、開放閉鎖原則 (OCP) がアーキテクチャの根本原理として登場します。
- 修正に対して閉じている: 既存の要求を満たす振る舞いが変わらないこと（＝安定性）
- 拡張に対して開いている: 既存の要求を満たしたまま新しい要求に応えられること（＝柔軟性）
この 2 つが両立することで、変更への不安は解消し、労力も軽減される。つまり OCP の達成は予期的変更容易性と経験的変更容易性の両方を高めることに直結する、という形で、OCP を「変更容易性そのもの」と等価に位置づけ直す再解釈 が行われました。
「変更容易性」を変更の 前 と 最中 という時間軸で分けながら、その 2 層の両立を 開放閉鎖原則 という一本軸に落とし込んでいくことで、自分の中にあった「テストを書く理由」の曖昧さがそのまま整理されていくような感覚がありました。
テストは「不安」と「構造」にフィードバックを与える
さらに、「変更容易性とはコードベースではなく、それを変更しようとしている人間が抱く感覚に依存する」という視点のもと、テスト駆動開発が変更容易性に対して 2 つの方向からフィードバックを与える と整理されていました。
ひとつ目は 予期的変更容易性へのフィードバック、つまり「開発者の不安を取り除く」役割です。テストケースは「既存の要求と期待される振る舞いの定義」であり、変更しても既存テストが壊れないなら、その範囲では「閉じている」ことが保証されているということです。
ふたつ目は 経験的変更容易性へのフィードバック、すなわち「構造上の問題を教える」役割です。機能追加が既存のテストに影響するならそのモジュールは閉じていないし、新しい機能のテストを書くのが大変ならそのモジュールは開いていないということになります。
そして開放閉鎖原則そのものは、設計のループの中で 徐々に 満たされていくものとして描かれます。 ここで特に印象的だったのは、開放閉鎖原則を 「達成すべきゴールではなく、漸近していく理想状態」 として位置づけていた点です。OCP は完全には満たせないし、変更容易性は変更してみないとわからない。だからこそ、テストと TDD は OCP を徐々に満たしていくためのワークフローとして必要になる、という説明の流れにはとても納得感がありました。
いつテストを書くか？
ここまで積み上げてきた整理を踏まえて、本セッションのタイトルに立ち戻ります。テストを書くべきタイミングは、変更容易性のどちらが阻害されているか で見え方が変わる、というのが lacolaco さんの答えでした。
- 予期的変更容易性が低いとき（＝変更するのが怖いとき）は、不安を取り除くためにテストを書く。実装を支えるテスト。逆に、不安がないなら書く必要はないし、書いても不安が変わらないなら書く意味もない。
- 経験的変更容易性が低いとき（＝構造に問題を感じているとき）は、構造を学習するためにテストを書く。設計（リファクタリング）を支えるテスト。OCP が十分に満たされ構造を熟知しているなら書く必要はない。
結合度の高いテスト（結合テスト）は不安の解消に、結合度の低いテスト（ユニットテスト）は構造のフィードバックに、という区別がテストピラミッドの図解で整理されておりとても分かりやすかったです。
このセッションが個人的にとても良かったのは、「いつテストを書くか？」という極めて実践的な問いに対する答えが、自分がコードの変更に対してどう向き合っているのか（不安なのか、構造に違和感があるのか）への感度を高めること に着地していた点です。テストを書くべきかどうかを「自分の感覚を起点に考える、という視点は、AI と分担して開発する時代だからこそ、改めて言語化して持っておきたい感覚だと感じました。
総じて、ソフトウェアとは何か、保守性とは何かという基礎的な問いから始め、それを「開放閉鎖原則」という古典的な原理で言語化しなおすことで、「自分がどのタイミングでテストに向き合うか」という実践的なところまでイメージができる、学びの深いセッションでした。保守性の限界がこれだけ早く訪れるようになった今こそ、『テスト駆動開発』や『Clean Architecture』といった書籍をもう一度しっかり読み直して咀嚼する価値があると感じています。
各社スポンサーブース
他社さんのスポンサーブースにもたくさん訪問させていただきました！
各社趣向を凝らしたブースや様々な企画が展開され、会場全体がとても賑わっていました。
いくつかご紹介させていただきます。
レバレジーズさん
レバレジーズさんのブースでは、アジャイル開発の業務効率化支援 SaaS「agile effect」について解説していただきました！
タスク管理ツールと連携することで進捗把握や調整がしやすくなり、開発プロセス自体を可視化することで感覚に頼らない改善が進められるとのことでした。AI によって開発効率が上がる中で、ボトルネックがどこにあるかを把握する重要性は増していると感じる場面が多く、興味深いサービスでした！
プレイドさん
プレイドさんのブースでは、弊社でも利用させていただいている CX プラットフォーム「KARTE」について、実際のユースケースを交えて解説していただきました！
設定方法まで丁寧に教えていただき、とてもありがたかったです。ブース内ではおみくじを引かせていただく企画もあり、結果はハズレでしたが、他のブースにはない体験で印象に残りました！
ZOZOさん
ZOZOさんのブースでは、テックリードお手製の TypeScript クイズに挑戦しました！全問正解者は数人とのことで、なかなか歯ごたえのある内容でした。
型推論の挙動や演算子の細かな仕様など、自分の理解が曖昧だった部分がクイズを通して炙り出され、TypeScript の言語仕様を学び直すきっかけになりました！
まとめ
TSKaigi 2026 は、TypeScript の最新動向や活用事例から、AI とどう組み合わせて開発を進めるかという最近のトピックまで幅広く語られ、TypeScript コミュニティの盛り上がりを改めて感じられる、とても素敵なイベントでした。
特に今年は、tsgo / TypeScript 7 のキーノートや TypeScript Compiler の設計史といった言語処理系そのものの節目に関するセッションと、AI 時代の型駆動開発や Agentic Coding 時代におけるテストの意義といった AI との向き合い方を問うセッションが両軸で並んでおり、TypeScript 自身の進化と AI との関わり方の両方を同時に追えるラインナップでした。ブースで実施したアンケートでも「指示は出すが都度レビュー」「並列で動かしている」といった回答が並んでいたことから、参加者の AI 活用が着実に進んでいることも伺えました。
今後も TypeScript コミュニティ、TSKaigi がより一層発展していくことを期待しています。
今回の参加レポートが、TypeScript を学びたい・活用していきたい方の参考になれば幸いです。
運営の皆さん、カンファレンスを開催していただきありがとうございました！！
アフターイベントのご案内
TSKaigi 2026 にスポンサーや登壇者で参加した ウェルスナビ・PeopleX・弁護士ドットコム・スリーシェイク・エブリー の 5 社で、2026年6月12日（金）に TSKaigi 2026 のアフターイベントを開催いたします！ セッションや公募LTなどのコンテンツを用意しておりますので、みんなでTypeScriptで盛り上がりましょう！
最後に
エブリーでは、ともに働く仲間を募集しています。
テックブログを読んで少しでもエブリーに興味を持っていただけた方は、ぜひ一度カジュアル面談にお越しください！
最後までお読みいただき、ありがとうございました！
