Tweet
Tweet

Slide 1

Slide 1 text

AI Coding Agent Enablement in ~エージェントを させよう~ TypeScript 自走 @yukukotani 2025/05/23 - TSKaigi 2025

Slide 2

Slide 2 text

自己紹介 Yuku Kotani VP of Technology @ Ubie, Inc. Tech Advisor @ SALESCORE, Inc. @yukukotani @yukukotani

Slide 3

Slide 3 text

目次 1. 基本的な考え方 2. イネーブリングのアプローチ 3. エコシステムの未来 4. まとめ

Slide 4

Slide 4 text

コーディングエージェント もっと使いこなしたい！

Slide 5

Slide 5 text

使いこなすってなんだろう？

Slide 6

Slide 6 text

使いこなすってなんだろう？ もっと自走してほしい！

Slide 7

Slide 7 text

自走ってなんだろう？

Slide 8

Slide 8 text

自走 = Human-in-the-Loop をなるべくやらない Copilot時代はスニペット単位でHuman-in-the-Loopを回していた Agent時代にはできるだけ自律的に判断させて1ループの作業単位を大きくしたい

Slide 9

Slide 9 text

デフォルトの解空間は大きすぎる デフォルトでは「任意のTypeScript」くらいの
 極めて広い解空間でエージェントが動く → 精度が低い 解空間 解 生成対象の言語のSyntax全体 （真にはあらゆるテキスト）

Slide 10

Slide 10 text

基本方針：可能な限り解空間を絞る 会社・プロジェクト固有の解空間は本来もっと狭いはず 適切に制約を与えて解空間を絞りたい 解空間 会社・プロジェクト固有の
 規約・ドメイン知識・デザインなど 解

Slide 11

Slide 11 text

どうやって？

Slide 12

Slide 12 text

人間と同様にイネーブリングする どうやって？

Slide 13

Slide 13 text

(1) コンテキスト注入

Slide 14

Slide 14 text

解空間の定義をLLMに与える ドキュメントなど何らかの方法でLLMに「解空間の定義」を与える 代表的には Cursor Rules / Cline Rules など 解空間 会社・プロジェクト固有の
 規約・ドメイン知識・デザインなど

Slide 15

Slide 15 text

(2) 機械的検査

Slide 16

Slide 16 text

機械的検査で定義した解空間に押し戻す LLMの出力を機械的に受け入れ検査し、NGの場合はフィードバックする 解空間 機械的にフィードバックを与えて 解空間へ押し戻す

Slide 17

Slide 17 text

目次 1. 基本的な考え方 2. イネーブリングのアプローチ 3. エコシステムの未来 4. まとめ

Slide 18

Slide 18 text

型チェック

Slide 19

Slide 19 text

そもそも型ってコード生成に有効なの？ ƒ TS(型注釈付き)とJSでベンチマークスコアはほぼ変わらない [arXiv:2208.08227h ƒ anyをつけたTSではスコアが下がる [arXiv:2208.08227h →今のところ、型があるから 　良いコードを生成するわけではない ƒ 型があるから精度が上がるわけではな” ƒ 下手な型はむしろノイズになり逆効果 https://nuprl.github.io/MultiPL-E/

Slide 20

Slide 20 text

エージェントなら？ 単発のコード生成には役に立たないとしても、 ”解空間に押し戻す”ためのエージェントへの入力としては役立ちそう？ 自律的にエラー改善！理想！

Slide 21

Slide 21 text

そううまくいかないがち 3回くらいループした末にanyとかキャストで誤魔化しがち TSの高度な型を解決する能力はまだなさそう

Slide 22

Slide 22 text

ので、型だけは書いてやろう ドメインモデルや関数のシグネチャを定義するまではガッツリ伴走する その後の実装を自律的にやってもらう 先にシグネチャがあることで 型エラーのスコープ・複雑度が低い！

Slide 23

Slide 23 text

てかコードを生成する時点で型を守れないのか LLMがコードを出力する時点で型制約を守ってくれれば、 あらかじめ”解空間の中”なので何も考えなくて済む

Slide 24

Slide 24 text

制約付きデコーディングで を守る 文法 LLMのデコーディングのタイミングで文法にマッチしないトークンを除e ’ デコーディング: LLMが出力するトークン確率から、結果のトークンを決G ’ xGrammar[arXiv:2411.15100]、DOMINO[arXiv:2403.06988] など (CFG baseX ’ ’ 少なくともStructured Outputはこういうことをやっている ※各社LLMがこの手法を使ってるか、単にしっかり学習されてるだけかは不l

Slide 25

Slide 25 text

Structured Output の仕組み https://openai.com/ja-JP/index/introducing-structured-outputs-in-the-api/#zhi-yue-fu-kidekodo

Slide 26

Slide 26 text

Structured Output の仕組み https://openai.com/ja-JP/index/introducing-structured-outputs-in-the-api/#zhi-yue-fu-kidekodo

Slide 27

Slide 27 text

LLMのデコーディングのタイミングで型にマッチしないトークンを除 e グラフとオートマトンで「これ以上生成しても絶対型エラー」なトークンをすべて 除 e Type-Constrained Decoding[arXiv:2504.092464 e HumanEval(新規実装ベンチ)ではコンパイルエラー率 平均75%6 e pass@1 は新規実装タスク +3.5pp, エラー修正タスク +37pp, etc..e e e めちゃくちゃ小さいTSのサブセットでしか動かない ※まだ全く実用段階ではな„ → このアプローチが進めば、既存コードの型が活躍しそう！ 同様に制約付きデコーディングで を守る 型

Slide 28

Slide 28 text

Linter

Slide 29

Slide 29 text

古典的な静的解析・自動テスト H エージェントにLinterや型チェック、自動テストを実行させU H その結果をもとに自律改善して、passするまで勝手にループ

Slide 30

Slide 30 text

なぜ古典的手法？ p LLM-as-a-judgeのように先進的な評価手法もあるが、
 コーディングエージェントへのフィードバックには銀の弾丸ではなX p 非決定論的であり、真の意味で”保証”できなX p 実行速度が遅く、エージェントのPDCAのボトルネックになる → 古典的な静的解析・自動テストが有効。一般的なルールセットだけでなく 　 プロジェクト固有のルールもどんどん書いて解空間を絞っていく

Slide 31

Slide 31 text

そんなルール書くの大変・・・

Slide 32

Slide 32 text

誰でも簡単3ステップ

Slide 33

Slide 33 text

 気になった出力にフィードバック

Slide 34

Slide 34 text

ÄÃ 詰める

Slide 35

Slide 35 text

ÃÆ できあがり

Slide 36

Slide 36 text

LLMはLLMの気持ちがわかる フィードバックベースで詰めると、”2度と繰り返さない”ためのエラーを考える

Slide 37

Slide 37 text

プロンプトを直す前にLinter g Linterは型チェックを違って”ネクストアクション”を提示でき) g Linterはプロンプトと違って決定的である(=保証できるq g なるべく同じレビューを2度しなくて良いようにする

Slide 38

Slide 38 text

デザインシステム

Slide 39

Slide 39 text

デザインシステム(Ubie Vitals)のMCPサーバー化 デザインシステムをMCPサーバーにすることで LLMにコンテキストを注入。 HTML+CSSという広大な解空間から絞る

Slide 40

Slide 40 text

DEMO

Slide 41

Slide 41 text

デモが失敗したとき用 MCPでget_componentsツールを叩く

Slide 42

Slide 42 text

デモが失敗したとき用 コンポーネントの実装をそのまま返している。コードとJSDocがプロンプト代わり

Slide 43

Slide 43 text

デモが失敗したとき用 コンポーネントのテストも含める。few-shot prompting 代わりになる

Slide 44

Slide 44 text

デモが失敗したとき用 うまくいくとこう

Slide 45

Slide 45 text

参考 https://zenn.dev/ubie_dev/articles/f927aaff02d618

Slide 46

Slide 46 text

コードもドキュメントになる W こういう静的なユースケースにおいてMCPとか入力方法はどうでもいw W MCPがいいのかコンテキストに入れるのがいいのかはモデル特性次d W 大事なのは入力に値する情報(ドキュメント,デザインシステム,etc...)の整 デザインシステム以外にもユースケースがたくさんある W TypeScriptコードもドキュメントとして育てる価値があˆ W

Slide 47

Slide 47 text

[宣伝] アフターイベントやります TypeScriptコードをドキュメントとして機能させる話の続きはこちら https://bitkey.connpass.com/event/351174/

Slide 48

Slide 48 text

目次 1. 基本的な考え方 2. イネーブリングのアプローチ 3. エコシステムの未来 4. まとめ

Slide 49

Slide 49 text

Speed is King t ぶっちゃけ今まで、Linterとかにそこまで速度を求めていなかっ˜ t CI待ってる間は他のことするし・・T t てかどちらにせよtscが遅いし・・T t けどそれは人間の時間軸での9 t 1分間の静的解析でも、あるコードを30分で書く人間と30秒で書くAIとでは
 ボトルネック具合が段違い t ツールチェインはよりシリアスに速度に向き合う必要がある

Slide 50

Slide 50 text

Speed is King Linter以外にも・・„ d クラウド型エージェントはコンテナによるisolationが主流! d 1チャットごとにコンテナを作x d →パッケージマネージャの速度がボトルネッ— d 生産量が爆増することでデプロイの機会も増えx d →ビルド（バンドラー）がボトルネッ— d LLMデコーディングのタイミング（トークン生成ごと）に型グラフ構 d →型チェッカーがボトルネック（tsgo最高！） TSエコシステムはすでに良い流れに乗っているので期待できる

Slide 51

Slide 51 text

Code Generation over Complex Puzzle 2 複雑な型エラーからはネクストアクションを導くのがむずかし( 2 コード生成に寄せると型エラーをシンプルにしやす( 2 コード生成も複雑性だが、”なんかおかしかったら再生成してみる”は明瞭

Slide 52

Slide 52 text

目次 1. 基本的な考え方 2. イネーブリングのアプローチ 3. エコシステムの未来 4. まとめ

Slide 53

Slide 53 text

まとめ 飛び道具の前に、普通の人間と地続きのイネーブリングでAIを自走させよう7 5 話し足りないこと（ブースや懇親会で話しましょう! 5 コーディングエージェントが喜ぶアーキテクチ0 5 LLMによる探索的テスト（V.S. 決定論的な古典的テスト）

Slide 54

Slide 54 text

ありがとうございました Ubieのブースにいます！