AIにコードを生成するコードを作らせて、 再現性を担保しよう！ TSKaigi 2025 After Night 〜セッションおかわりの会！〜 / LT 

{ "name": "Yusuke Yamada （ちゅうこ, yamachu ）", "workAt": " 株式会社CARTA HOLDINGS", "interests": [ "TypeScript", "C#", "Scala", "VS Code" ], "accounts": { "X": "@y_chu5", "GitHub": "yamachu" } } 自己紹介 2 

でも…こんな経験ありませんか？ 型が合わなかったり、シンタックスエラー起こしたり 一度直しても、別のファイルに適用すると同じ指針で編集してくれない モデルや時期で結果がブレる… 一括でドン！といくならいいかもしれないが… AIには「型の理解」と「再現性」は難しい？ 1. はじめに：AIでのマイグレーション「あるある」 古いコードのマイグレーション、AIに任せたいですよね？ 3 

AI Agentに対して、コードを直接書き換えることを期待しがち ここの制御が難しい ↓ AI様に、人間のエンジニアが行うような振る舞いのステージに降りてきてもらう マイグレーション手順を示し マイグレーションスクリプトを生成し テストケースを追加したり つまり、 「コードを生成するコード」 の実装なら私達も理解できて、再現も出来る？ 2. 仮説：AIに「コードを生成するコード」を作らせるのはどうか 4 

「コードを生成するコード」 、ts-morphを使ったスクリプト…ってコト！？ 5 

今回は material-ui の非推奨となった makeStyles 関数から、MUI v5 の SxProps への マイグレーションを例として紹介します もちろんマイグレーションには ts-morph を使用します 養殖コードはこちら https://github.com/yamachu/play-ts-morph 3. アプローチ：実践編 6 

マイグレーション対象のコードを把握する どんなコードがあるか？ どんなパターンがあるか？ どのような変更が必要か？ 地道にコードを見るだけでなく、例えば GitHub Copilot で以下のように調べるのも良 い @workspace makeStylesを使用しているコンポーネントで、呼び出し方のパター ンや命名規則などのパターンを知りたいです。 ステップ1: コードの把握とパターン抽出 7 

Before: makeStyles のコード例 import makeStyles from '@mui/styles/makeStyles'; const useStyles = makeStyles((theme) => ({ // theme 非依存のスタイル root: { display: 'flex', }, // theme 依存のスタイル info: { padding: theme.spacing(1, 2), backgroundColor: theme.palette.background.default, }, })); // const classes = useStyles(); // // ... // 8 

After: SxProps への変換例 import { SxProps, Theme } from '@mui/material'; const rootStyles: SxProps = { display: 'flex', }; const infoStyles: SxProps = (theme) => ({ padding: theme.spacing(1, 2), backgroundColor: theme.palette.background.default, }); // // ... // 9 

AIとの対話で「マイグレーションスクリプトのプラン」を策定 いきなりコードを書かせず、まず「変換処理を行うプロンプト」を作成 そのプロンプトを元に、AIに「ts-morphを使って、どういうプランで書ける か」を提案させる ポイント：1ステップの粒度を細かく刻む プランを作ってもらうと、ファイル変換処理の流れが提案される 例: ファイル抽出 → AST解析 → ノード変換 → コード出力 これでも粗いので、さらに細分化するとデバッグしやすい このプランから、自分が想定していないケースも出てくることがある （ここのやり取りを見せたかったのですが、Chatログ紛失してしまいました…） ステップ2: プロンプト作成と実装プランニング 10 

AIに実装させる際の工夫 各ステップに「テストケース（入出力ペア） 」を渡す 関数実装の際にも、その入力ケースの処理パターンをjsdocなどに記載させる のも良い 実装したコードで、実際にmigrationを都度Agentで走らせる 自律的に修正するループが生まれる 例外的なパターンは人間が対応する方がコスト的に良いので、早々に諦めさ せる 4. 実装 11 

長いタスク指示〜〜各書き換えを行った後make runを実行して試してください。 実行結果にTypeScriptのproblemsが出力されるので、それを元にコードの改善を 行ってください。 12 

AST操作系のコード意外と書いてくれる 割とニッチなコードだし学習データが少ないのではと思ったけど、意外と書 いてくれる 若干TS Compiler APIと混同したりするけど、自分で直せるレベルのもの 型システムによる「ガードレール」は強い ts-morphでコードを生成するため、手でtemplate書くよりも安全 型チェックエラー ＝ 考慮漏れのパターン発見！ とみなせる 5. 所感 13 

今回の取り組みのメリット 「コードを作るコード」で再現性を担保できた 型との組み合わせで変更パターンを列挙しやすくなった AIとの「協調」の重要性 AIはコードや型を完全に理解しているわけではない 人間が「仕組み」として支援することで、一定の軌道修正は出来そう 今後のAIの進化に期待しつつ、エンジニアが「ガードレール」を敷く役割は 重要 TypeScriptに限って言えば… 例えばTypeScript Compiler APIのMCP Serverとかが出てきたら？ ScalaだとMetalsが実装済み 6. まとめと今後の期待 14