izumin5210のプロポーザルのネタ探し 2026-02-09 TSKaigi Mashup #4 プロポーザルの書き方とコツを学ぼう @izumin5210 

@izumin5210 ▶ LayerX バクラク事業部 (2022-09 -) - Platform Engineering 部 Enabling チーム Staff Software Engineer - Backend(Go, TypeScript), Web Frontend ▶ ISUCON14 4位 ▶ 最近 GraphQL サーバを作るライブラリを作った gqlkit - TypeScript の型定義と関数から GraphQL Schema を構築するライブラリを作った 

最近のプロポーザルの採択状況 ▶ ⭕ TSKaigi Kansai 2024 (30min) - よくできたテンプレート言語として TypeScript + JSX を利用する試み ▶ ⭕ TSKaigi 2025 (30min) - 複雑なフォームを継続的に開発していくための技術選定・設計・実装 ▶ ⭕ TSKaigi Hokuriku 2025 (30min) - Building AI Agents with TypeScript 

ネタのパターン 

パターン1. TypeScript 自体を楽しむ ▶ TSKaigi であれば、TypeScript の言語機能や型システムなどについて深掘り、 その応用を考えたり、何か検証したり、…… ▶ e.g. 「よくできたテンプレート言語として TypeScript + JSX を利用する試み」 - JSX を眺めて「これ本質的には XML だから任意のデータ構造持てるよね」と気づき、 TypeScript のドキュメントにダイブすることで JSX Runtime の自作に至る 

パターン2. TypeScript の活躍の幅を広げる ▶ Web Frontend や Backend (の DB からデータ取って JSON で返すところ) など以外で TypeScript を活用する ▶ e.g. 「よくできたテンプレート言語として TypeScript + JSX を利用する試み」 - HTML メールをよくあるテンプレート言語で作ろうとして開発体験のワイルドさで暴れそうになり そういえば JSX でいいじゃんと思い至る ▶ e.g. 「Building AI Agents with TypeScript」 - TypeScript で AI Agent やってみた… はよく見るが、 Hello World 以上に踏み込んだ例があまりなかったのでやってみた - TypeScript エンジニアに「AIこわくないよ」って言いたかった 

パターン3. 日常の困難に TypeScript と立ち向かう ▶ 業務や大規模な開発でリアルに困ってることについて、 TypeScript を活用して解決（しようと）した話 ▶ e.g. 「複雑なフォームを継続的に開発していくための技術選定・設計・実装」 - めっちゃ複雑なフォームを頑張ってモデリングした経験を一般化し、 設計・技術選定の指針に落とし込んで紹介 

ネタ決めで気をつけてること 

「やってみた」のその先を話す ▶ 「やってみる」ことは尊い とはいえ「やってみる（ドキュメントをなぞる）」だけで止まるのはもったいない ▶ やってみた上でどうだったが、その技術は何を目的としてそうか、 どういう応用がありそうか、実際の業務で活かすにはどんな情報が必要か、…… ▶ e.g. 「Building AI Agents with TypeScript」 - AI SDK など触って何もわからん！ となり、実際のプロダクトどう作るんや！ という疑問から、 Deep Research を自分で作ればおもろいんじゃね？ となった 

Why me - なぜ自分が話すのか？ ▶ 「○○という技術・ライブラリを使ってみた！」は誰でも話せる ▶ 「○○という技術にはこういうメリットがあるよ！」も誰でも話せる ▶ 「現実の開発で××という問題があって、○○という技術の特性を活かしてこの問題を うまく解いたよ！」は？ ▶ 「○○という技術についてめちゃくちゃ触って読んで deep dive してみたら、こんな 面白いことがあったよ！」は？ 

普段の業務から Why を見つける ▶ 技術選定, 設計, 抽象化, … コードを書く上での意思決定には必ず Why がある - その Why を意識して、より一般化して話せないかを考える ▶ e.g. 「よくできたテンプレート言語として TypeScript + JSX を利用する試み」 - 「JSX Runtime 作ってみた！」ではなく、「○○という問題を解くために JSX がフィットしそう」 ▶ e.g. 「複雑なフォームを継続的に開発していくための技術選定・設計・実装」 - 「Jotai 入れてみた！」ではなく、「○○という問題を解くために Jotai がフィットしそう」 

普段の開発・業務で出てきた「Why」とその探究はあなたにしか話せない でも、それで助かる人はどこかにいるはず！ 

もちろん、Why とか吹き飛ばして、 技術を磨きに磨き込んで技術で殴れるならそれはそれで最高。 それもあなたにしか話せない。 

ところで、ここまでえらそうなことを言いましたが、 

最近のプロポーザルの採択状況 ▶ ⭕ TSKaigi Kansai 2024 - よくできたテンプレート言語として TypeScript + JSX を利用する試み ▶ ⭕ TSKaigi 2025 - 複雑なフォームを継続的に開発していくための技術選定・設計・実装 ▶ ⭕ TSKaigi Hokuriku 2025 - Building AI Agents with TypeScript 

最近のプロポーザルの採択状況 ▶ ❌ TSKaigi 2024 ▶ ❌ フロントエンドカンファレンス北海道 2024 ▶ ⭕ TSKaigi Kansai 2024 ▶ ⭕ TSKaigi 2025 ▶ ❌ JSConf 2025 ▶ ⭕ TSKaigi Hokuriku 2025 

最近のプロポーザルの採択状況 ▶ ❌ TSKaigi 2024 - TypeScript で GraphQL サーバを実装する #とは ▶ ❌ フロントエンドカンファレンス北海道 2024 - フロントエンドGraphQLプラクティス - みんなが「入れてよかった！」と思えるために ▶ ❌ JSConf 2025 - （忘れた） 

イベントの趣旨あるいは聴衆が期待することを考える ▶ 話したいことを話すのが一番大事だが、 とはいえ聴衆が期待するものとズレすぎるのも良くない - e.g. TypeScript で GraphQL サーバを実装する #とは (TSKaigi) - e.g. フロントエンドGraphQLプラクティス - みんなが「入れてよかった！」と思えるために (フロ カン) ▶ プロポーザルの概要も全体的に GraphQL 先行・ GraphQL ありきすぎたかも ▶ イベントテーマから距離があるものが主題になるときは工夫が重要 

まとめ ▶ izumin5210 がよく使うネタのパターン - TypeScript 自体を楽しむ - TypeScript の活躍の幅を広げる - 日常の困難に TypeScript と立ち向かう ▶ 「やってみた」のその先を話す ▶ 「Why」を話す - 普段の業務から Why を見つける 

おまけ: プロポーザル大公開スペシャル 

# フロントエンドカンファレンス北海道2024 （ダメだったやつ） GraphQLは非常に強力な技術で、うまく使えばWebフロントエンドだけでなく全体の開発体験やユーザ体験を大きく向上 させてくれます。 一方で、使い方を誤るとユーザ体験は悪化し、バックエンドやインフラのエンジニアを苦しめ、フロントエンドにまで生 産性低下や将来の負債を生み出すこともあり、使えばそれでOKという技術ではありません。 では、ユーザも関係する全ての開発者も、誰もが消耗せずGraphQLの恩恵を享受するには？ それには実装時の細かなTipsからクエリやコンポーネントの設計, スキーマ設計, アーキテクチャ, プロダクトの構成 など、様々なレイヤ・抽象度のものが関係します。 本セッションでは関係者みんなが「GraphQLを入れて良かった」と思えるために、Webフロントエンドエンジニアは何を 考え・どのような設計・実装をすべきかを具体的なプラクティスとともに紹介します。 

# TSkaigi 2024 （ダメだったやつ） GraphQL サーバを TypeScript で実装するぞ、というとき、どんな技術やライブラリを思い浮かべるでしょうか。 一口に「GraphQL サーバの実装」といっても、それを構成する要素はいくつかに分解され、それぞれで技術選定が必要 となります。 そして、それらの要素でどんな技術を選んだかによって、GraphQL サーバのアーキテクチャ的な特性や開発フローに影 響を及ぼします。 本発表では、他の言語の環境は特性と TypeScript のそれを比較しつつ - GraphQL サーバとはどのような要素から構成されるのか - それぞれの要素にはどんな技術や設計がありうるのか - ある技術を選択することで、GraphQL サーバはどのような特性を得るのか などについて、 いくつかの企業で GraphQL の技術選定・設計・実装をしてきた経験からお話します。 

# TSKaigi Kansai 2024 （とおったやつ） プロダクト開発ではメールや Slack 通知などの実装のために複雑な構造化文字列の組み立てが必要になることがありま す。 しかし、このような文字列・構造の構築を見通しよく・メンテナンスしやすく実装するのは簡単ではありません。これは JavaScript 以外の言語でも同様に悩ましい問題です。 本発表では、そんなメールや Slack 通知などの組み立てを TypeScript + JSX を利用することで、簡単・安全・見 通しよく実現する方法について話します。 なぜ TypeScript や JSX か, メリット・デメリット, 技術選定, アーキテクチャなどを紹介します。 また、TypeScript からだけでなく、Go など他の言語から TypeScript + JSX で記述されたコードを利用したいと いう実際のユースケースで、どのようなアプローチを検討し、結果どのようなアーキテクチャを採用し、実装したかにつ いても紹介します。 

# TSKaigi 2025 （とおったやつ） みなさんは Web アプリケーション中の複雑なフォームを開発するとき、何を考え・どうやって実装しますか？ ひとことで「フォーム」と言っても、その仕様や特性・機能によって適切な技術や設計・実装手法は変わるでしょう。 「よく使われるライブラリを使えば大丈夫」 ということはなく、そのフォームに適したライブラリや設計を選択する必 要があります。 「TypeScript で書けば大丈夫」 ということはなく、TypeScript であっても効果的に利用できなければ、拡張に弱 い・壊れやすいフォームとなってしまうかもしれません。 本発表では実際の複雑なフォームを持つプロダクト - ユーザが柔軟にフィールドを追加し、バリデーションを設定でき るようなフォームを題材とし、その設計・技術選定・実装について紹介します。 複雑なフォームを安心して拡張していけるようにするために、どのような設計を考え、技術を比較・選択肢し、かつ拡張 に強いプロダクトにするために TypeScript をどのように活用したかについてお話します。 

# TSKaigi Hokuriku 2025 （とおったやつ） AI・機械学習の開発エコシステムは Python を中心とした状況から、TypeScript をはじめとする他言語へと広がっ ています。LLM は汎用性を獲得すると同時に巨大化し、その利用は API 経由が必然となりました。この流れの中で Web 技術との親和性やライブラリ整備が進み、フルスタック TypeScript 開発の延長で AI 機能を実装できる環境が 整いつつあります。本セッションでは、その具体的な例としてシンプルな AI Agent を実装しつつ段階的に機能を拡張 していくサンプルを用いて、TypeScript で AI Agent を実装する考え方やプロセスを解説します。また、従来の Web アプリケーション開発と比較して、開発者が頭の使い方や設計・実装上の前提をどのように切り替えていく必要が あるのかを整理し、具体的なコード例を通して実践的に学べるセッションとします。 

まとめ（再掲） ▶ izumin5210 がよく使うネタのパターン - TypeScript 自体を楽しむ - TypeScript の活躍の幅を広げる - 日常の困難に TypeScript と立ち向かう ▶ 「やってみた」のその先を話す ▶ 「Why」を話す - 普段の業務から Why を見つける