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
19
10k
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
AI Coding Agent Enablement - エージェントを自走させよう
yukukotani
14
7.3k
Expoによるアプリ開発の現在地とReact Server Componentsが切り開く未来
yukukotani
3
500
React 19でお手軽にCSS-in-JSを自作する
yukukotani
5
800
僕が思い描くTypeScriptの未来を勝手に先取りする
yukukotani
12
3.3k
Web技術を駆使してユーザーの画面を「録画」する
yukukotani
14
7.7k
Capacitor製のWebViewアプリからReact Native製のハイブリッドアプリへ
yukukotani
5
1.6k
Real World Type Puzzle and Code Generation
yukukotani
4
940
Kuma UI が提唱する Hybrid Approach CSS-in-JS の仕組み
yukukotani
2
570
GraphQLスキーマ設計の勘所
yukukotani
42
19k
Other Decks in Programming
See All in Programming
ご注文の差分はこちらですか? 〜 AWS CDK のいろいろな差分検出と安全なデプロイ
konokenj
3
550
「テストは愚直&&網羅的に書くほどよい」という誤解 / Test Smarter, Not Harder
munetoshi
0
200
AI駆動のマルチエージェントによる業務フロー自動化の設計と実践
h_okkah
0
220
ペアプロ × 生成AI 現場での実践と課題について / generative-ai-in-pair-programming
codmoninc
2
21k
NPOでのDevinの活用
codeforeveryone
0
890
AIエージェントはこう育てる - GitHub Copilot Agentとチームの共進化サイクル
koboriakira
0
720
iOS 26にアップデートすると実機でのHot Reloadができない?
umigishiaoi
0
140
AIプログラマーDevinは PHPerの夢を見るか?
shinyasaita
1
250
顧客の画像データをテラバイト単位で配信する 画像サーバを WebP にした際に起こった課題と その対応策 ~継続的な取り組みを添えて~
takutakahashi
4
1.2k
猫と暮らす Google Nest Cam生活🐈 / WebRTC with Google Nest Cam
yutailang0119
0
170
RailsGirls IZUMO スポンサーLT
16bitidol
0
200
状態遷移図を書こう / Sequence Chart vs State Diagram
orgachem
PRO
2
190
Featured
See All Featured
YesSQL, Process and Tooling at Scale
rocio
173
14k
GraphQLとの向き合い方2022年版
quramy
49
14k
A Modern Web Designer's Workflow
chriscoyier
695
190k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
A designer walks into a library…
pauljervisheath
207
24k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
It's Worth the Effort
3n
185
28k
A better future with KSS
kneath
238
17k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
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のブースにいます!