AIにコードを生成するコードを作らせて、再現性を担保しよう！ / Let AI generate code to ensure reproducibility

Transcript

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

2. { "name": "Yusuke Yamada （ちゅうこ, yamachu ）", "workAt": " 株式会社CARTA

   HOLDINGS", "interests": [ "TypeScript", "C#", "Scala", "VS Code" ], "accounts": { "X": "@y_chu5", "GitHub": "yamachu" } } 自己紹介 2

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

4. AI Agentに対して、コードを直接書き換えることを期待しがち ここの制御が難しい ↓ AI様に、人間のエンジニアが行うような振る舞いのステージに降りてきてもらう マイグレーション手順を示し マイグレーションスクリプトを生成し テストケースを追加したり つまり、 「コードを生成するコード」

   の実装なら私達も理解できて、再現も出来る？ 2. 仮説：AIに「コードを生成するコード」を作らせるのはどうか 4

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

6. 今回は material-ui の非推奨となった makeStyles 関数から、MUI v5 の SxProps への マイグレーションを例として紹介します

   もちろんマイグレーションには ts-morph を使用します 養殖コードはこちら https://github.com/yamachu/play-ts-morph 3. アプローチ：実践編 6

7. マイグレーション対象のコードを把握する どんなコードがあるか？ どんなパターンがあるか？ どのような変更が必要か？ 地道にコードを見るだけでなく、例えば GitHub Copilot で以下のように調べるのも良 い @workspace

   makeStylesを使用しているコンポーネントで、呼び出し方のパター ンや命名規則などのパターンを知りたいです。 ステップ1: コードの把握とパターン抽出 7

8. 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(); // <Box className={classes.root}> // <Typography className={classes.info}>...</Typography> // </Box> 8

9. After: SxProps への変換例 import { SxProps, Theme } from '@mui/material';

   const rootStyles: SxProps = { display: 'flex', }; const infoStyles: SxProps<Theme> = (theme) => ({ padding: theme.spacing(1, 2), backgroundColor: theme.palette.background.default, }); // <Box sx={rootStyles}> // <Typography sx={infoStyles}>...</Typography> // </Box> 9

10. AIとの対話で「マイグレーションスクリプトのプラン」を策定 いきなりコードを書かせず、まず「変換処理を行うプロンプト」を作成 そのプロンプトを元に、AIに「ts-morphを使って、どういうプランで書ける か」を提案させる ポイント：1ステップの粒度を細かく刻む プランを作ってもらうと、ファイル変換処理の流れが提案される 例: ファイル抽出 → AST解析

    → ノード変換 → コード出力 これでも粗いので、さらに細分化するとデバッグしやすい このプランから、自分が想定していないケースも出てくることがある （ここのやり取りを見せたかったのですが、Chatログ紛失してしまいました…） ステップ2: プロンプト作成と実装プランニング 10

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

    実装 11

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

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

    考慮漏れのパターン発見！ とみなせる 5. 所感 13

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

    Compiler APIのMCP Serverとかが出てきたら？ ScalaだとMetalsが実装済み 6. まとめと今後の期待 14