TS Kaigi2026に参加してきました

株式会社ナハトでエンジニアをしているものです。

2026年5月22日（金）〜23日（土）にベルサール羽田空港で開催された TSKaigi 2026 に参加してきました。自分は 2 日目（5/23 土） の参加です。これくらいの規模の技術カンファレンスに参加するのは初めての経験で、いろいろと得るものが多かったので、振り返りも兼ねてまとめてみます。

TSKaigi 2026 とは

TSKaigi は、国内最大級の TypeScript をテーマにしたカンファレンスです。今年のメインテーマは 「学び、繋がり、"型"を破ろう」。

プラチナスポンサー 9 社をはじめ、50 社を超える企業がスポンサーとして名を連ねており、これだけの規模を、運営しきっているのは本当にすごいことだと思います。

参考: TSKaigi 2026 公式サイト

参加目的

自分が参加した目的は、現在の日本の IT 企業がどんな取り組みをしているのかを知るため です。普段の現場では出会わないツールや会社のスタンスに触れて、自分自身の日々の業務に活かしたい、というところが大きいです。

印象に残ったブース

数あるブースの中から、特に印象に残ったものをいくつか紹介します。

1. 株式会社 Plaid の mila（Interactive Analytics Database）

ブースで紹介されていたのは新しい OLAP データベース mila でした。

ざっくり言うと、mila は サービス上で日々積み上がっていく膨大なユーザーの行動データを、ユーザー単位の切り口でインタラクティブに分析するためのデータベース だそうです。たとえば「どんなユーザーがどこで離脱しているのか」「リピートしてくれているユーザーはどう動いているのか」といった、いわゆるファネル分析・リテンション分析をサクサク回すことを想定しています。さらに最近は、人間ではなく AI エージェントが大量のデータに対して何度もクエリを投げ、インサイトを引き出していくような使われ方 も視野に入っているとのことで、そのために Plaid 社が自社開発を進めているデータベース、という位置付けのようでした。

公式の紹介や技術ブログを読みにいくと、特徴としては以下のようなことが挙げられていました。

• テナント単位でクラウドリソースを分離し、データの混在を防ぐ
• ファネル分析・リテンション分析といった「行動シーケンス分析」を、専用の集計関数で最適化して実行できる
• AI エージェントが大量のデータに対して何度もクエリを投げてインサイトを引き出すような用途を想定

ブースのお話の中では「MapReduce 的なフレームワーク」「スケーラブルなストリーミングインサート処理」といったキーワードも出てきました。技術ブログを見にいくと、OLAP データベースにおける高速化の技術や、リアルタイムインジェスト（書き込み）をカラムナ形式に最適化する話などが公開されています。

参考:

• PLAID Data Mind（mila 紹介）
• PLAID engineer blog「OLAPデータベースにおける高速化の技術」
• PLAID engineer blog「OLAP-DBでのreal-time ingestionをカラムナに最適化する技術」
• 大規模リアルタイム解析をさらに進化させる。独自DB開発で挑む、クラウドの制約を超えるデータエンジニアリング | PLAID

正直なところ、自分は内部仕様まですべてを理解できているわけではありません。それでも、これまで「データ分析基盤 = BigQuery」という固定観念があった自分にとって、BigQuery 以外の選択肢として何があるか を知れたのは大きな収穫でした。データサイエンスを扱っていく上で、こういう引き出しは増やしておきたいなと感じました。

2. Park Direct（月極駐車場の手続きを自動化するサービス）

株式会社ニーリーが運営している Park Direct のブースも印象に残りました。月極駐車場まわりの手続き——募集・申込・審査・契約・賃料回収など——を、オンラインで一気通貫で完結させるサービスです。

どこに刺さったかというと、課題設定の解像度 です。

月極駐車場を契約しようとすると、いまだに「まずは電話で問い合わせ → 事務所まで来てください」という流れになっているケースが多いそうです。電話の時点でも面倒、そこから事務所訪問が必要となれば、なおさら気持ちが折れる。ここに目をつけて、技術的にも事業的にも「ブルーオーシャン」として攻めにいっている、という話でした。

技術がコモディティ化していく中で、こういう アナログ慣習が残っている領域に、デジタルで切り込む という姿勢は、今後ますます価値が出てくると思います。月極駐車場 DX という、一見地味だけれど巨大な領域に、しっかり投資が集まっているのも納得でした。

そして、月極駐車場に限らず、いまだに電話や FAX でしかやりとりできない業界は他にもたくさん残っている はずです。商習慣として根強く残っているからこそ、そこをデジタルに置き換えられれば一気にひっくり返せる——そんなビジネスチャンスはまだまだ眠っているのではないか、と感じました。

参考: Park Direct 公式サイト

3. CodeRabbit

AI コードレビューの CodeRabbit のブースでは、せっかくなので率直に聞いてみました。

「CodeRabbit は、OpenAI Codex のレビューとどう違うんですか？」

返ってきた答えのポイントは カスタマイズ性 でした。デフォルト設定のまま使っても十分動くのですが、CodeRabbit の性能をフルに引き出すには、リポジトリに合わせてカスタムしたほうが良いとのこと。具体的には、リポジトリ直下に .coderabbit.yaml を置くことで、レビューの粒度・パスフィルタ・要約フォーマットなどを細かく制御できるようです。また、PR 上で @coderabbitai review などのチャットコマンドを使って増分レビューや再要約をトリガーすることもできます。

参考: CodeRabbit 公式ドキュメント

カスタムの仕方はドキュメントに載っているものの、ブースで聞いた限りではまだ「カスタムまで踏み込んで使いこなしている」事例は多くないようでした。逆に言うと、ここを真面目にやれば、AI レビューの精度を一段上げられる余地が残っているということです。やってみる価値ありだなと思いました。

気になった技術: GraphQL

今回の会場では、セッションタイトルや登壇者のスライド、他社ブースの説明など、あちこちで GraphQL という単語を見かけました。なんとなく名前は知っていたものの、自分の中で輪郭がぼやけていたので、後追いで調べてみました。

GraphQL とは何か

ざっくり言うと、API のためのクエリ言語、およびそのランタイム です。クライアントが「欲しいデータの形」をクエリで指定し、サーバ側のリゾルバがその形に沿ってデータを返す、という考え方です。

REST API との対比でよく語られるポイントは、こんなところでした。

• エンドポイントが基本 1 つ：REST のようにリソースごとに /users、/users/:id/posts と分かれるのではなく、ひとつの /graphql に対してクエリを投げる
• 必要なフィールドだけ取得できる：オーバーフェッチ（要らないデータまで取ってきてしまう）／アンダーフェッチ（複数回 API を叩く必要がある）を抑えられる
• スキーマ駆動で型がある：型システムがプロトコルに組み込まれているので、ドキュメントの自動生成や、クライアント・サーバ間の型整合チェックがやりやすい

なぜ TypeScript 界隈で話題なのか

GraphQL のスキーマから TypeScript の型を自動生成できるので、フロントエンドの API クライアント側で型安全を取りやすい という相性の良さがあります。最近の TypeScript エコシステムでは、Pothos や GraphQL Yoga といったコードファーストでスキーマを組み立てるためのライブラリも盛り上がっているそうです。

もちろん、すべてのケースで REST より GraphQL が良いというわけではなく、クライアントが取得したいデータ形状が多様 / フロントエンドが複数ある / モバイルとの通信量を最適化したい といった文脈で特に効いてくる、という整理が落とし所のようです。

参考:

• GraphQL 公式サイト
• GraphQLとRest APIの違い | Serverless Operations
• GraphQLはいつ使うか、RESTとの比較 | Zenn

自分の業務でいきなり GraphQL を採用するかどうかは別の議論として、「なぜ会場のあちこちで見かけたのか」が腹落ちした だけでも、参加した価値があったと思います。

考察

ブースや講演を一通り見て歩いて、自分の中で改めて感じたことが 2 つあります。

ひとつは、技術力アップ自体は前提条件にすぎない ということです。もちろん技術は素晴らしいし、磨いていくべきものなのですが、現場やユーザーの抱えている課題から目を背けてしまうと、その技術は宙に浮きます。これからは、エンジニアだけで完結しない、非エンジニアも含めた「課題の捉え方」のすり合わせがますます大事になりそうです。

もうひとつは、AI の進化でソフトウェア開発のハードルがぐっと下がった ということです。コードを書くこと自体は、以前と比べてかなり簡単になりました。だからこそこれからは、作ったものをユーザーにどうフィットさせるか、課題をどう解いていくか に重きを置かないと、すぐにコモディティになってしまいます。月極駐車場のブースに惹かれたのも、つまるところそういう感覚があったからかもしれません。

交流（懇親会）で出てきた話

懇親会では、いろんな会社の方とお話しさせてもらいました。話題はやはり AI が中心。その中で、特に印象に残った 2 つのテーマを書いておきます。

1. 個人情報という大きなボトルネック

サービスの中で扱っているデータを AI や機械学習で分析しようとするときに、ひとつ大きなボトルネックになっているのが 個人情報の扱い でした。個人情報を含むデータには法律の規制がかかってきます。そのため、有用なデータがあったとしても、そのまま AI に渡せるわけではなく、一度形を変える（マスキングや匿名化などの前処理を入れる）必要がある という話が出ていました。

ここを軽く見ると、後から「実は流せないデータだった」という事故につながるので、設計の初期段階から考慮しておくべきポイントだと感じました。

2. AI を社内にどう普及させるか

もうひとつは、AI をどうやって社内に広げていくか、という話。いろんな会社で試行錯誤されていました。

• 全社向けの研修：入り口としては良いけれど、続かない（持続力がない）
• 1 on 1 で伴走するスタイル：実際にやっている会社さんもいた。AI の使い方を、横に座って一緒に習得していくイメージ
• チームから 1 人を選んで育てる：全員に 1 on 1 を提供するのは現実的に難しいので、チームから 1 人をピックアップして AI 活用の旗振り役に育て、その人がチームに伝播していく仕組み

共通していたのは、AI を使うこと自体を目的にしない という姿勢でした。とはいえ、「使わないと、生産性で他国に遅れをとる」というのも事実。だからこそ、AI を 何のために使うのか という目的設定と、自走できるようにする支援 をセットで考える必要がありそうです。

全体の感想

最後に、純粋な感想を。

このイベントのために準備してこられた運営の方々、本当にお疲れ様でした。自分自身、このような規模の技術イベントに参加するのは初めてで、日本でこれだけのイベントが成立すること自体に、すごく意義がある と感じています。

日本にはまだまだポテンシャルのある技術がたくさんありますし、それらを使って未来を明るくしていくためにやるべきことも、同じくらいたくさん残っていると思います。これからもっと日本の IT 業界を盛り上げていきたい——そう思える、最高のイベントでした。

---

参考リンク

• TSKaigi 2026 公式サイト
• PLAID Data Mind（mila 紹介）
• PLAID engineer blog「OLAPデータベースにおける高速化の技術」
• PLAID engineer blog「OLAP-DBでのreal-time ingestionをカラムナに最適化する技術」
• 大規模リアルタイム解析をさらに進化させる。独自DB開発で挑む、クラウドの制約を超えるデータエンジニアリング | PLAID
• Park Direct 公式サイト
• CodeRabbit 公式ドキュメント
• GraphQL 公式サイト
• GraphQLとRest APIの違い | Serverless Operations
• GraphQLはいつ使うか、RESTとの比較 | Zenn