Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AI Coding Agent Enablement in TypeScript
Search
Yuku Kotani
May 23, 2025
Programming
20
12k
AI Coding Agent Enablement in TypeScript
TSKaigi 2025
https://2025.tskaigi.org/
Yuku Kotani
May 23, 2025
Tweet
Share
More Decks by Yuku Kotani
See All by Yuku Kotani
MCPとデザインシステムに立脚したデザインと実装の融合
yukukotani
5
1.7k
Scale out your Claude Code ~自社専用Agentで10xする開発プロセス~
yukukotani
9
3.3k
AI Coding Agent Enablement - エージェントを自走させよう
yukukotani
14
7.7k
Expoによるアプリ開発の現在地とReact Server Componentsが切り開く未来
yukukotani
3
610
React 19でお手軽にCSS-in-JSを自作する
yukukotani
5
880
僕が思い描くTypeScriptの未来を勝手に先取りする
yukukotani
12
3.3k
Web技術を駆使してユーザーの画面を「録画」する
yukukotani
14
7.8k
Capacitor製のWebViewアプリからReact Native製のハイブリッドアプリへ
yukukotani
5
1.7k
Real World Type Puzzle and Code Generation
yukukotani
4
960
Other Decks in Programming
See All in Programming
私はどうやって技術力を上げたのか
yusukebe
42
16k
Swiftビルド弾丸ツアー - Swift Buildが作る新しいエコシステム
giginet
PRO
0
1.5k
詳しくない分野でのVibe Codingで困ったことと学び/vibe-coding-in-unfamiliar-area
shibayu36
1
450
Pull-Requestの内容を1クリックで動作確認可能にするワークフロー
natmark
1
310
気づいて!アプリからのSOS 〜App Store Connect APIで始めるパフォーマンス健康診断〜
waka12
0
250
私達はmodernize packageに夢を見るか feat. go/analysis, go/ast / Go Conference 2025
kaorumuta
2
390
育てるアーキテクチャ:戦い抜くPythonマイクロサービスの設計と進化戦略
fujidomoe
1
140
defer f()とdefer fの挙動を 誤解していた話
kogamochiduki
2
150
ИИ-Агенты в каждый дом – Алексей Порядин, PythoNN
sobolevn
0
140
2分台で1500examples完走!爆速CIを支える環境構築術 - Kaigi on Rails 2025
falcon8823
3
2.3k
プログラマのための作曲入門
cheebow
0
500
プログラミングどうやる? ~テスト駆動開発から学ぶ達人の型~
a_okui
0
190
Featured
See All Featured
For a Future-Friendly Web
brad_frost
180
9.9k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
600
Practical Orchestrator
shlominoach
190
11k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Six Lessons from altMBA
skipperchong
28
4k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
36
2.5k
Balancing Empowerment & Direction
lara
4
660
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.9k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
Transcript
AI Coding Agent Enablement in ~エージェントを させよう~ TypeScript 自走 @yukukotani
2025/05/23 - TSKaigi 2025
自己紹介 Yuku Kotani VP of Technology @ Ubie, Inc. Tech
Advisor @ SALESCORE, Inc. @yukukotani @yukukotani
目次 1. 基本的な考え方 2. イネーブリングのアプローチ 3. エコシステムの未来 4. まとめ
コーディングエージェント もっと使いこなしたい!
使いこなすってなんだろう?
使いこなすってなんだろう? もっと自走してほしい!
自走ってなんだろう?
自走 = Human-in-the-Loop をなるべくやらない Copilot時代はスニペット単位でHuman-in-the-Loopを回していた Agent時代にはできるだけ自律的に判断させて1ループの作業単位を大きくしたい
デフォルトの解空間は大きすぎる デフォルトでは「任意のTypeScript」くらいの 極めて広い解空間でエージェントが動く → 精度が低い 解空間 解 生成対象の言語のSyntax全体 (真にはあらゆるテキスト)
基本方針:可能な限り解空間を絞る 会社・プロジェクト固有の解空間は本来もっと狭いはず 適切に制約を与えて解空間を絞りたい 解空間 会社・プロジェクト固有の 規約・ドメイン知識・デザインなど 解
どうやって?
人間と同様にイネーブリングする どうやって?
(1) コンテキスト注入
解空間の定義をLLMに与える ドキュメントなど何らかの方法でLLMに「解空間の定義」を与える 代表的には Cursor Rules / Cline Rules など 解空間
会社・プロジェクト固有の 規約・ドメイン知識・デザインなど
(2) 機械的検査
機械的検査で定義した解空間に押し戻す LLMの出力を機械的に受け入れ検査し、NGの場合はフィードバックする 解空間 機械的にフィードバックを与えて 解空間へ押し戻す
目次 1. 基本的な考え方 2. イネーブリングのアプローチ 3. エコシステムの未来 4. まとめ
型チェック
そもそも型ってコード生成に有効なの? TS(型注釈付き)とJSでベンチマークスコアはほぼ変わらない [arXiv:2208.08227h anyをつけたTSではスコアが下がる [arXiv:2208.08227h →今のところ、型があるから 良いコードを生成するわけではない
型があるから精度が上がるわけではな 下手な型はむしろノイズになり逆効果 https://nuprl.github.io/MultiPL-E/
エージェントなら? 単発のコード生成には役に立たないとしても、 ”解空間に押し戻す”ためのエージェントへの入力としては役立ちそう? 自律的にエラー改善!理想!
そううまくいかないがち 3回くらいループした末にanyとかキャストで誤魔化しがち TSの高度な型を解決する能力はまだなさそう
ので、型だけは書いてやろう ドメインモデルや関数のシグネチャを定義するまではガッツリ伴走する その後の実装を自律的にやってもらう 先にシグネチャがあることで 型エラーのスコープ・複雑度が低い!
てかコードを生成する時点で型を守れないのか LLMがコードを出力する時点で型制約を守ってくれれば、 あらかじめ”解空間の中”なので何も考えなくて済む
制約付きデコーディングで を守る 文法 LLMのデコーディングのタイミングで文法にマッチしないトークンを除e デコーディング: LLMが出力するトークン確率から、結果のトークンを決G xGrammar[arXiv:2411.15100]、DOMINO[arXiv:2403.06988] など
(CFG baseX 少なくともStructured Outputはこういうことをやっている ※各社LLMがこの手法を使ってるか、単にしっかり学習されてるだけかは不l
Structured Output の仕組み https://openai.com/ja-JP/index/introducing-structured-outputs-in-the-api/#zhi-yue-fu-kidekodo
Structured Output の仕組み https://openai.com/ja-JP/index/introducing-structured-outputs-in-the-api/#zhi-yue-fu-kidekodo
LLMのデコーディングのタイミングで型にマッチしないトークンを除 e グラフとオートマトンで「これ以上生成しても絶対型エラー」なトークンをすべて 除 e Type-Constrained Decoding[arXiv:2504.092464 e HumanEval(新規実装ベンチ)ではコンパイルエラー率 平均75%6
e pass@1 は新規実装タスク +3.5pp, エラー修正タスク +37pp, etc..e e e めちゃくちゃ小さいTSのサブセットでしか動かない ※まだ全く実用段階ではな → このアプローチが進めば、既存コードの型が活躍しそう! 同様に制約付きデコーディングで を守る 型
Linter
古典的な静的解析・自動テスト H エージェントにLinterや型チェック、自動テストを実行させU H その結果をもとに自律改善して、passするまで勝手にループ
なぜ古典的手法? p LLM-as-a-judgeのように先進的な評価手法もあるが、 コーディングエージェントへのフィードバックには銀の弾丸ではなX p 非決定論的であり、真の意味で”保証”できなX p 実行速度が遅く、エージェントのPDCAのボトルネックになる → 古典的な静的解析・自動テストが有効。一般的なルールセットだけでなく
プロジェクト固有のルールもどんどん書いて解空間を絞っていく
そんなルール書くの大変・・・
誰でも簡単3ステップ
気になった出力にフィードバック
ÄÃ 詰める
ÃÆ できあがり
LLMはLLMの気持ちがわかる フィードバックベースで詰めると、”2度と繰り返さない”ためのエラーを考える
プロンプトを直す前にLinter g Linterは型チェックを違って”ネクストアクション”を提示でき) g Linterはプロンプトと違って決定的である(=保証できるq g なるべく同じレビューを2度しなくて良いようにする
デザインシステム
デザインシステム(Ubie Vitals)のMCPサーバー化 デザインシステムをMCPサーバーにすることで LLMにコンテキストを注入。 HTML+CSSという広大な解空間から絞る
DEMO
デモが失敗したとき用 MCPでget_componentsツールを叩く
デモが失敗したとき用 コンポーネントの実装をそのまま返している。コードとJSDocがプロンプト代わり
デモが失敗したとき用 コンポーネントのテストも含める。few-shot prompting 代わりになる
デモが失敗したとき用 うまくいくとこう
参考 https://zenn.dev/ubie_dev/articles/f927aaff02d618
コードもドキュメントになる W こういう静的なユースケースにおいてMCPとか入力方法はどうでもいw W MCPがいいのかコンテキストに入れるのがいいのかはモデル特性次d W 大事なのは入力に値する情報(ドキュメント,デザインシステム,etc...)の整 デザインシステム以外にもユースケースがたくさんある W TypeScriptコードもドキュメントとして育てる価値があ
W
[宣伝] アフターイベントやります TypeScriptコードをドキュメントとして機能させる話の続きはこちら https://bitkey.connpass.com/event/351174/
目次 1. 基本的な考え方 2. イネーブリングのアプローチ 3. エコシステムの未来 4. まとめ
Speed is King t ぶっちゃけ今まで、Linterとかにそこまで速度を求めていなかっ t CI待ってる間は他のことするし・・T t てかどちらにせよtscが遅いし・・T t
けどそれは人間の時間軸での9 t 1分間の静的解析でも、あるコードを30分で書く人間と30秒で書くAIとでは ボトルネック具合が段違い t ツールチェインはよりシリアスに速度に向き合う必要がある
Speed is King Linter以外にも・・ d クラウド型エージェントはコンテナによるisolationが主流! d 1チャットごとにコンテナを作x d →パッケージマネージャの速度がボトルネッ
d 生産量が爆増することでデプロイの機会も増えx d →ビルド(バンドラー)がボトルネッ d LLMデコーディングのタイミング(トークン生成ごと)に型グラフ構 d →型チェッカーがボトルネック(tsgo最高!) TSエコシステムはすでに良い流れに乗っているので期待できる
Code Generation over Complex Puzzle 2 複雑な型エラーからはネクストアクションを導くのがむずかし( 2 コード生成に寄せると型エラーをシンプルにしやす( 2
コード生成も複雑性だが、”なんかおかしかったら再生成してみる”は明瞭
目次 1. 基本的な考え方 2. イネーブリングのアプローチ 3. エコシステムの未来 4. まとめ
まとめ 飛び道具の前に、普通の人間と地続きのイネーブリングでAIを自走させよう7 5 話し足りないこと(ブースや懇親会で話しましょう! 5 コーディングエージェントが喜ぶアーキテクチ0 5 LLMによる探索的テスト(V.S. 決定論的な古典的テスト)
ありがとうございました Ubieのブースにいます!