AI Coding Agent Enablement in TypeScript

Transcript

1. AI Coding Agent Enablement in ~エージェントを させよう~ TypeScript 自走 @yukukotani

   2025/05/23 - TSKaigi 2025

2. 自己紹介 Yuku Kotani VP of Technology @ Ubie, Inc. Tech

   Advisor @ SALESCORE, Inc. @yukukotani @yukukotani

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

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

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

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

7. 自走ってなんだろう？

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

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

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

11. どうやって？

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

13. (1) コンテキスト注入

14. 解空間の定義をLLMに与える ドキュメントなど何らかの方法でLLMに「解空間の定義」を与える 代表的には Cursor Rules / Cline Rules など 解空間

    会社・プロジェクト固有の
 規約・ドメイン知識・デザインなど

15. (2) 機械的検査

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

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

18. 型チェック

19. そもそも型ってコード生成に有効なの？ ƒ TS(型注釈付き)とJSでベンチマークスコアはほぼ変わらない [arXiv:2208.08227h ƒ anyをつけたTSではスコアが下がる [arXiv:2208.08227h →今のところ、型があるから 　良いコードを生成するわけではない ƒ

    型があるから精度が上がるわけではな” ƒ 下手な型はむしろノイズになり逆効果 https://nuprl.github.io/MultiPL-E/

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

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

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

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

24. 制約付きデコーディングで を守る 文法 LLMのデコーディングのタイミングで文法にマッチしないトークンを除e ’ デコーディング: LLMが出力するトークン確率から、結果のトークンを決G ’ xGrammar[arXiv:2411.15100]、DOMINO[arXiv:2403.06988] など

    (CFG baseX ’ ’ 少なくともStructured Outputはこういうことをやっている ※各社LLMがこの手法を使ってるか、単にしっかり学習されてるだけかは不l

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

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

27. LLMのデコーディングのタイミングで型にマッチしないトークンを除 e グラフとオートマトンで「これ以上生成しても絶対型エラー」なトークンをすべて 除 e Type-Constrained Decoding[arXiv:2504.092464 e HumanEval(新規実装ベンチ)ではコンパイルエラー率 平均75%6

    e pass@1 は新規実装タスク +3.5pp, エラー修正タスク +37pp, etc..e e e めちゃくちゃ小さいTSのサブセットでしか動かない ※まだ全く実用段階ではな„ → このアプローチが進めば、既存コードの型が活躍しそう！ 同様に制約付きデコーディングで を守る 型

28. Linter

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

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

    　 プロジェクト固有のルールもどんどん書いて解空間を絞っていく

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

32. 誰でも簡単3ステップ

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

34. ÄÃ 詰める

35. ÃÆ できあがり

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

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

38. デザインシステム

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

40. DEMO

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

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

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

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

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

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

    W

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

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

49. Speed is King t ぶっちゃけ今まで、Linterとかにそこまで速度を求めていなかっ˜ t CI待ってる間は他のことするし・・T t てかどちらにせよtscが遅いし・・T t

    けどそれは人間の時間軸での9 t 1分間の静的解析でも、あるコードを30分で書く人間と30秒で書くAIとでは
 ボトルネック具合が段違い t ツールチェインはよりシリアスに速度に向き合う必要がある

50. Speed is King Linter以外にも・・„ d クラウド型エージェントはコンテナによるisolationが主流! d 1チャットごとにコンテナを作x d →パッケージマネージャの速度がボトルネッ—

    d 生産量が爆増することでデプロイの機会も増えx d →ビルド（バンドラー）がボトルネッ— d LLMデコーディングのタイミング（トークン生成ごと）に型グラフ構 d →型チェッカーがボトルネック（tsgo最高！） TSエコシステムはすでに良い流れに乗っているので期待できる

51. Code Generation over Complex Puzzle 2 複雑な型エラーからはネクストアクションを導くのがむずかし( 2 コード生成に寄せると型エラーをシンプルにしやす( 2

    コード生成も複雑性だが、”なんかおかしかったら再生成してみる”は明瞭

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

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

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