TypeScript で Platform SDK を作る技術

自己紹介

- GitHub / X (@toiroakr): https://github.com/toiroakr

型をいい感じに提供したい

- wrangler types（類似事例）: https://developers.cloudflare.com/workers/languages/typescript/#generate-types
- TanStack Router ファイルベースルーティング（類似事例）: https://tanstack.com/router/latest/docs/framework/react/routing/file-based-routing
- zod-to-ts: https://github.com/sachinraja/zod-to-ts
- zinfer（自作）: https://github.com/toiroakr/zinfer
- Why Prisma ORM Checks Types Faster Than Drizzle: https://www.prisma.io/blog/why-prisma-orm-checks-types-faster-than-drizzle

ユーザーコードをいい感じに書かせたい

- Vitest Test Environment: https://vitest.dev/guide/environment.html
- @cloudflare/vitest-pool-workers（類似事例）: https://developers.cloudflare.com/workers/testing/vitest-integration/
- Workers Vitest integration (Cloudflare blog): https://blog.cloudflare.com/workers-vitest-integration/
- Remix のルートモジュール（類似事例）: https://remix.run/docs/en/main/route/loader

AI にいい感じでコードを書かせたい

- Rewrite your CLI for AI agents: https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-agents/
- Web Codegen Scorer: https://github.com/angular/web-codegen-scorer
- Angular MCP Server / CLI improvements: https://blog.angular.dev/angular-mcp-server-and-cli-improvements-c7e5b6f72b5c
- AngularはAI志向のフレームワークへ（lacolaco）: https://zenn.dev/lacolaco/articles/angular-ai-forward

We're hiring

- Tailor Careers: https://engineer-careers-5yxz0t8eny.web.erp.dev/

Transcript

1. TypeScript で Platform SDK を作る技術 Building a Platform SDK in TypeScript TSKaigi 2026: #TSKaigi #tskaigi_righttouch 樋口 彰 / テイラー株式会社 TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript
2. 自己紹介 樋口 彰 / Akira HIGUCHI 略歴： リクルート Android / Java バックエンド / React atama plus Python バックエンド / Angular / Vue / Electron テイラー株式会社（現職） Tailor Platform™ SDK の設計と実装 GitHub / X: @toiroakr TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 2
3. Platform SDK SDK（Software Development Kit） アプリケーションを開発するためのツール群 本発表における Platform SDK インフラ定義 DB スキーマ、ワークフロー、認証、ホスティング バックエンドのビジネスロジック TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 3
4. Platform TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 4
5. SDK 以前 Terraform / CUE による宣言的な IaC Platform のインフラレイヤを中心に捉えれば自然な選択 アプリのビジネスロジックは JavaScript 書く ERP のような複雑なロジックでは比重が大きくなる HCL / CUE と JavaScript の混在 HCL 内の インライン JS 、外部 JS ファイルのパスの参照 言語間の参照に型が付かず、補完も効きにくい アプリ全体を見渡しにくい TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 5
6. SDK 既存の仕組みでつらくなってきたところを踏まえつつTypeScriptで「いい感じ」に書けるように する 型をいい感じに提供したい 正確な型を / 軽快に ユーザーコードをいい感じに書かせたい ローカルマシン・Platform を意識しない / 余計なコードを含まずにバンドル AI にいい感じでコードを書かせたい AI の利用行動を観測して SDK を直す TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 6
7. 型をいい感じに提供したい TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 7
8. 型をいい感じに提供したい いい感じとは？ 正確な型を 型を適切に狭めて補完を効かせる 型チェックで早期にエラーを発見できる 軽快に 軽い IDE 補完と型チェックを重くしない 快適 コマンド実行などの手間がない 難しいことを意識しなくていい TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 8
9. 型をいい感じに提供したい: 型を正確に：ユーザー定義の型を提供 提供したい体験 // tailor.config.ts import { defineConfig } from "@tailor-platform/sdk"; export default defineConfig({ env: { API_BASE_URL: process.env.API_BASE_URL, LOG_LEVEL: process.env.LOG_LEVEL ?? "warn", }, // ... }); // resolvers/checkout.ts createResolver({ body: ({ env }) => fetch(env.API_BASE_URL), // ← 補完 & タイポでエラー }); defineConfig に書いた env キーが、別ファイルで型として効く TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 9
10. 型をいい感じに提供したい: 型を正確に：ユーザー定義の型を提供 課題 env キーが決まるのは ユーザーが config を書いた時点 SDK の型定義は publish 時点で固定 → SDK 配布後に、ユーザー側から型情報を「差し込める」経路が必要 TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 10
11. 型をいい感じに提供したい: 型を正確に：ユーザー定義の型を提供 取り組み ①： コマンドで 環境変数の型宣言を生成 tailor-sdk generate でユーザーの config ファイルを読んで型定義を含むファイルを生成 declare module "@tailor-platform/sdk" { interface Env { API_BASE_URL: string; LOG_LEVEL: string; } } TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 11
12. 型をいい感じに提供したい: 型を正確に：ユーザー定義の型を提供 取り組み ②： 生成した型を SDK の内部で使う // SDK 内部（npm install 時点で凍結） export interface Env {} export type TailorEnv = keyof Env extends never ? Record<string, string | number | boolean> // 未生成なら fallback : Env; // 生成後はユーザーのキー・値の型 export const createResolver = (opts: { body: (args: { env: TailorEnv }) => Result }) => { /* ... */ }; createResolver の body は TailorEnv を介して Env を受け取る 未生成でも TailorEnv は壊れない（fallback で広い型に倒す） TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 12
13. 型をいい感じに提供したい: 型を正確に：ユーザー定義の型を提供 取り組み ③：利用側で具体型として効く // TailorEnv が { API_BASE_URL: string; LOG_LEVEL: string } に置き換わる createResolver({ body: ({ env }) => { fetch(env.API_BASE_URL); // ← 補完が効く env.UNKNOWN_KEY; // ← Property 'UNKNOWN_KEY' does not exist }, }); TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 13
14. 型をいい感じに提供したい: 型を正確に：ユーザー定義の型を提供 類似事例：wrangler types // worker-configuration.d.ts — wrangler.jsonc から生成 interface __BaseEnv_Env { MY_KV: KVNamespace; API_BASE_URL: "https://api.example.com"; } declare namespace Cloudflare { interface Env extends __BaseEnv_Env {} } interface Env extends __BaseEnv_Env {} // 利用側（fetch handler） export default { async fetch(req: Request, env: Env) { return env.MY_KV.get("..."); // ← 補完が効く }, }; TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 14
15. 型をいい感じに提供したい: 型を正確に：ユーザー定義の型を提供 類似事例：TanStack Router のファイルベースルーティング // routeTree.gen.ts — Vite plugin / tsr generate が生成 declare module "@tanstack/react-router" { interface FileRoutesByPath { "/posts/$postId": { ... }; } } // 利用側 import { Link } from "@tanstack/react-router"; // FileRoutesByPath から path が補完 <Link to="/posts/$postId" params={{ postId: "1" }} />; TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 15
16. 型をいい感じに提供したい: 型を軽快に 提供したい体験 正確な型を提供するのは前提 軽い 補完・型チェックがすぐ反応する 快適 コマンド実行などの手間がない 難しいことを意識しなくてよい TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 16
17. 型をいい感じに提供したい: 型を軽快に：推論と生成のトレードオフ 課題 推論と生成のトレードオフ： 推論（動的に解決） 利点：書き換えがその場で反映される 欠点：複雑な型では、編集のたびに重い型計算が走る 生成（静的に固定） 利点：事前計算済みで参照側は軽い 欠点：コマンドなどで再生成が必要 → 特性に応じて使い分ける TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 17
18. 型をいい感じに提供したい: 型を軽快に：推論と生成のトレードオフ 取り組み：基本は推論、必要なものだけ生成に移す 基本：推論 書き換えがその場で反映される 生成に移すケース スキーマ由来の構造型（DB など） 滅多に変わらない・推論が重い config で宣言する識別子（ 「型を正確に」で扱った env キーなど） 利用側で declaration merging などを意識させない TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 18
19. 型をいい感じに提供したい: 型を軽快に：推論と生成のトレードオフ 例：SDK 内部の Zod schema 入出力型を事前計算 SDK 内部のスキーマは、ユーザーから見れば package install でしか更新されない（= 更新頻度が最も低い領域） 。 // parser/**/schema.ts — Zod schema を SSoT とする export const UserSchema = z.object({ id: z.string(), name: z.string() }); // SDK build 時に生成（z.infer なし） export type User = { id: string; name: string }; z.transform などの型を zod-to-tsでは生成できなかったため自作 TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 19
20. 型をいい感じに提供したい: 型を軽快に：推論と生成のトレードオフ 例：SDK 内部の Zod schema 入出力型を事前計算 利用側は計算済みの型を import するだけ。 // ユーザー側 import type { User } from "@tailor-platform/sdk"; const u: User = { id: "1", name: "A" }; // ← z.infer の展開なし z.infer の型計算コストを利用側に持ち込まない fixture ごとに型 instantiation 数を 1/4 〜 1/10 まで削減 TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 20
21. 型をいい感じに提供したい: 型を軽快に：推論と生成のトレードオフ 例：ユーザーの DB スキーマから kysely 型を生成 kysely-type plugin で kysely 用の Database 型を生成 ＋ PF上でのDB接続情報のラップ DB 定義は散らばる可能性があり、1 つずつ import するより生成で集約してしまったほ うが楽 推論コストを抑えつつ、定義の所在も意識せずに済む 利用側は集約済みの 1 つの型を import するだけ kysely 呼び出しで行型まで推論される TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 21
22. 型をいい感じに提供したい: 型を軽快に：推論と生成のトレードオフ 類似事例：Prisma スキーマファイル（ schema.prisma ）から prisma generate で TypeScript 型を出力 利用側は計算済みの型を import するだけ 推論の型計算コストが乗らない 参考： Why Prisma ORM Checks Types Faster Than Drizzle TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 22
23. 型をいい感じに提供したい まとめ 小項目 提供したい体験 取り組み 型を正確に：ユーザー定義 の型を提供 ユーザーが定義した型が SDK の型として効く 空 interface を declare module で埋める （declaration merging） 型を軽快に：推論と生成の トレードオフ 補完が軽い、難しいことを意 識しなくてよい 領域ごとに推論と生成を使い分ける ユーザーが書く設定の型は、ユーザー固有の値に従わせる。 生成 / 推論を一律にせず、境界の置 き方を選ぶ。 TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 23
24. ユーザーコードを いい感じに書かせたい TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 24
25. ユーザーコードをいい感じに書かせたい いい感じとは？ ローカルマシン・Platform を意識しなくていい 同じコードがローカルマシン（Vitest）と Platform（以下 PF） で同じように動く 余計なコードをバンドルしない PF に反映されるコードは必要最低限にする TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 25
26. ユーザーコードをいい感じに書かせたい: ローカルマシン・PF を意識しなくていい 提供したい体験 TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 26
27. ユーザーコードをいい感じに書かせたい: ローカルマシン・PF を意識しなくていい 提供したい体験 import { child } from "./child-job"; export const parent = createWorkflowJob({ name: "parent", body: async ({ userId }) => { return await child.trigger({ userId }); }, }); 普通のコードが書ける 子ジョブを .trigger() で呼ぶだけ ローカルマシンと PF の両方でこれが動作するようにする ローカルマシンでテストできる ローカルマシンでテストした通りに PF で実行される TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 27
28. ユーザーコードをいい感じに書かせたい: ローカルマシン・PF を意識しなくていい ローカルマシンと PF での実行環境の差 観点 ローカルマシン PF 実行ランタイム Node.js Web Standards のみ 実行単位 1 プロセスで全部走る ジョブごとに切り離された環境 ジョブ間呼び出し 普通の関数呼び出し PF が仲介 globalThis.tailor.* undefined ランタイムが提供 → この差を SDK で埋める TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 28
29. ユーザーコードをいい感じに書かせたい: ローカルマシン・PF を意識しなくていい 取り組み ①：Platform が注入するグローバルオブジェクトをラップする // SDK が publish する .d.ts const child = createWorkflowJob({ name: "child", body: async ({ userId }) => { console.log("hello"); return true; }, }); child.trigger(args); // => tailor.workflow.triggerJobFunction("child", args) 提供された関数には型がついてるので、 globalThis.tailor.* を気にせずに書ける TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 29
30. ユーザーコードをいい感じに書かせたい: ローカルマシン・PF を意識しなくていい 取り組み ②：ローカルマシン用に Vitest の Test Environment を提供 テスト実行時の環境を差し替えるための Vitest の仕組み // vitest.config.ts import { tailorRuntime } from "@tailor-platform/sdk/vitest"; export default defineConfig({ test: { environment: "tailor-runtime" }, plugins: [tailorRuntime()], }); tailor-runtime 環境がやること： globalThis.tailor.* を mock として自動注入 import "node:fs" 等を書き換え、エラーで代替を提示 ジョブ間の呼び出しの仲介 TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 30
31. ユーザーコードをいい感じに書かせたい: ローカルマシン・PF を意識しなくていい 埋められないギャップ tailor-runtime 環境は beta 把握済みの差は塞ぎ中 塞ぎきれない例：PF にはない globalThis のプロパティが残る Vitest がテストランナー動作のために必要とするものは除外できない 結果として process 関連 / require / module / exports などが、PF にはないのにロ ーカルマシンでは生きてしまう TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 31
32. ユーザーコードをいい感じに書かせたい: ローカルマシン・PF を意識しなくていい 類似事例：@cloudflare/vitest-pool-workers ローカルマシン pool が Miniflare 経由で workerd を別プロセスで起動 bindings は Miniflare のローカル実装 PF workerdで実行 利点：runtime と Web Standards API は PF と同じ workerd 欠点：プロセス境界越しに参照を共有できない TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 32
33. ユーザーコードをいい感じに書かせたい: 余計なコードをバンドルしない 提供したい体験 // parent-job.ts import { child } from "./child-job"; export const parent = createWorkflowJob({ name: "parent", // PF のバンドルに乗ってほしいのは body の中身だけ body: async ({ userId }) => { return await child.trigger({ userId }); }, }); PF のバンドルには parent ジョブの実装に必要なものだけ乗ってほしい import してある child の実装は parent 側のバンドルに含まれないでほしい TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 33
34. ユーザーコードをいい感じに書かせたい: 余計なコードをバンドルしない 提供したい体験 TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 34
35. ユーザーコードをいい感じに書かせたい: 余計なコードをバンドルしない 課題 各ジョブを個別にバンドルして deploy したい 無秩序に書かれると、各バンドルに余計なコードが混ざりやすい parent が child を使用していると、単純なバンドルでは child の実装まで parent 側に取り込まれる SDK 自体のコードもバンドル結果に含まれる PF での実行時には必要ないものがほとんど TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 35
36. ユーザーコードをいい感じに書かせたい: 余計なコードをバンドルしない 取り組み ①：config の glob + export でバンドルの境界を作る // tailor.config.ts export default defineConfig({ db: { main: { files: ["src/types/**/*.ts"] } }, resolver: { main: { files: ["src/resolvers/**/*.ts"] } }, executor: { files: ["src/executors/**/*.ts"] }, workflow: { files: ["src/workflows/**/*.ts"], job_files: ["src/jobs/**/*.ts"], }, }); glob にマッチしたファイル内で export されたものだけがバンドル対象 最低限の境界が作れる TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 36
37. ユーザーコードをいい感じに書かせたい: 余計なコードをバンドルしない 取り組み ②：SDKのコードをレイヤーごとに分離 packages/sdk/src/ ├── configure/ ユーザーが直接 import する API ├── parser/ Zod による検証・正規化（CLI から呼ばれる） └── cli/, plugin/, vitest/ CLI コマンド / プラグイン / テスト環境 sub-path export で公開エントリを切る default は configure/ のみ、 parser / cli / plugin は別エントリ 重い runtime は parser 以降の層側に隔離されてユーザーバンドルには流れ込まない Lint で configure から parser / cli / plugin への import を遮断 TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 37
38. ユーザーコードをいい感じに書かせたい: 余計なコードをバンドルしない 取り組み ②： configure はほぼ identity な関数群 configure の define* / create* は型を効かせるためのゲートで、中身はほぼ空： // configure/config.ts（実物） /* @__NO_SIDE_EFFECTS__ */ export function defineConfig<Config extends AppConfig & ...>(config: Config) { return config; } 型推論を効かせる役割だけを configure に置く configure 層がユーザーバンドルに載ることは許容 @__NO_SIDE_EFFECTS__ などを付与しつつバンドラに任せる TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 38
39. ユーザーコードをいい感じに書かせたい: 余計なコードをバンドルしない 取り組み ③：AST 操作で各 job を chunk 単位に切り出す // ユーザーが書くコード（ローカルマシンではこのまま動く） import { child } from "./child"; export const parent = createWorkflowJob({ name: "parent", body: ({ userId }) => child.trigger({ userId }), }); // parent.chunk — AST 書き換え後 export const parent = createWorkflowJob({ name: "parent", body: ({ userId }) => tailor.workflow.triggerJobFunction("child", { userId }), }); TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 39
40. ユーザーコードをいい感じに書かせたい: 余計なコードをバンドルしない 類似事例：Remix のルートモジュール // app/routes/posts.$id.tsx export async function loader({ params }: LoaderFunctionArgs) { /* server */ } export async function action({ request }: ActionFunctionArgs) { /* server */ } export default function Post() { /* client */ } フレームワーク規定の書き方で、同じファイル内に server / client を共存させる export で境界を引く loader / action → server バンドル default export → client バンドル TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 40
41. ユーザーコードをいい感じに書かせたい まとめ 小項目 提供したい体験 取り組み ローカルマシン・ PF を意識しなくて いい 同じコードがローカルマシン （Vitest）と PF で同じように動 く globalThis.tailor.* の型を SDK で宣言、ローカル マシンは Vitest custom environment で揃える 余計なコードをバ ンドルしない PF 側のバンドルには必要なも のだけが乗る config の glob で範囲を限定 + SDK 内部の layer 分離 + AST で chunk 単位に分解 TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 41
42. AI にいい感じで コードを書かせたい TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 42
43. AI にいい感じでコードを書かせたい いい感じとは？ 正しく書ける ユーザーが指定した仕様通りに書ける SDK が想定する API の使い方から外れない 実行コストが小さい 実装時間が短い トークン消費が膨らまない TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 43
44. AI にいい感じでコードを書かせたい: AI の使い心地を SDK の指標にする 提供したい体験 実装時間・トークン消費が膨らまない Read が早く終わってすぐに書き始められる 試行錯誤で書き直しが起きない TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 44
45. AI にいい感じでコードを書かせたい: AI の使い心地を SDK の指標にする 課題 AI が「どこを読みにいって」 「どう試行錯誤して」が見えない 直感で「ここを直せば AI が書きやすくなる」と言えても、効いたか分からない TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 45
46. AI にいい感じでコードを書かせたい: AI の使い心地を SDK の指標にする 取り組み ①：llm-challenge — AI 向け SDK のベンチマーク 小さく切り出した問題を AI に解かせ、結果を指標として残す problem.md にはヒントを書かない LLM がパッケージから自力で API を発見できるかを試す --sdk-branch + --iterations で任意の git ref を pack して A/B 観測指標：初回試行成功率 / 実行時間 / 最終正答率 TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 46
47. AI にいい感じでコードを書かせたい: AI の使い心地を SDK の指標にする 取り組み ① の実例：JSDoc で初回試行の精度向上 主要な API に JSDoc を追加 指標 JSDoc なし JSDoc あり 初回試行で詰まる問題 1 / 12 問 0 / 12 問 全問合計の実行時間 10m 34s 2m 31s (-76%) 最終正答率 100% 100% 詰まる 1 問が初手で通るだけでなく、他の問題でも API を調べる時間が減って実行時間が縮 んだ 最終正答率は変わらないが、辿り着きやすさは時間に出る TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 47
48. AI にいい感じでコードを書かせたい: AI の使い心地を SDK の指標にする 取り組み ②：LLM のログから誤推論を拾って API 形に戻す 問題を 1 つ LLM に解かせ、書きかけて捨てた候補を確認すると： LLM が書きがち 正しい書き方 db.string().optional() db.string({ optional: true }) db.string({ unique: true }) db.string().unique() db.string().default(5) db.string().hooks({ create: ({ value }) => value ?? 5 }) 最終的には正しく書けるが、途中で似ている他のライブラリのAPIに引っ張られている？ TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 48
49. AI にいい感じでコードを書かせたい: AI の使い心地を SDK の指標にする 取り組み ② の実例：オブジェクトリテラル形式の検証 Rewrite your CLI for AI agents に着想を得て、メソッドチェーンと並行で追加 // fluent: db.string().unique().optional() // object literal: { kind: "string", unique: true, optional: true } ベンチマーク結果、object literal は確認 Read が増えて遅くなった kind: "string" の有効値や kind 別 option を毎回 grep しているっぽい TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 49
50. AI にいい感じでコードを書かせたい: AI の使い心地を SDK の指標にする 取り組み ③：実プロジェクトから学習する ベンチマーク（取り組み ①）にも単発の試行錯誤（取り組み ②）にも出ない、実際の開発現場 から学ぶ SI 案件で LLM が書いたコードのログから書き間違いを抽出する skill を社内配布 配布したばかりで SDK 改善に戻した実例はまだない TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 50
51. AI にいい感じでコードを書かせたい: AI の使い心地を SDK の指標にする 類似事例：Angular Web Codegen Scorer フレームワーク横断のコード生成ベンチマーク Angular MCP Server LLM が Angular を「呼べる」第一級の窓口 AngularはAI志向のフレームワークへ AI でゼロから書ける / 既存コードを置き換えられるフレームワークを目指す TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 51
52. AI にいい感じでコードを書かせたい まとめ 信号源 拾えるもの 自前のベンチマーク AI に同じ課題を繰り返し解かせる 初回成功率・実行時間・最終正答率 LLM の試行ログ 1 タスク中に AI が書いて捨てた候補を見る 数字に出ない誤推論（似た別 API への引きずられなど） 実プロジェクトのログ 社内 SI 案件で AI が書いたコードを見る ベンチや単発試行では出ない、現場でしか起きないパターン TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 52
53. TypeScript で Platform SDK を作る技術 全体のまとめ 章 / 主題 鍵 型をいい感じに提供したい ユーザー固有の型を SDK に取り込 む / 領域ごとに推論と生成を使い分 ける 空 interface に declaration merging で型を埋める／重い領域は CLI で生 成、軽い領域は推論で受ける ユーザーコードをいい感じに書かせ たい ローカルマシン・PF の差を消す / PF には必要なものだけを送る globalThis.tailor.* を SDK で型宣言＋Vitest custom environment で mock を注入／config の glob＋層分離＋AST で chunk 分割 AI にいい感じでコードを書かせたい AI の使い心地を観測指標にして SDK を直す 自前のベンチマーク・LLM の試行ログ・実プロジェクトのログを組み合 わせる TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 53
54. We're hiring Tailor Platform™ を一緒に作るエンジニア募集 募集職種 FDE — Forward Deployed Engineer Platform — Tailor Platform™ SDK / AppShell / Core Platform / SRE AI — AI プロダクト / AI プラットフォーム こんな人と話したい 人間と AI（Coding Agent / LLM）の協調を前提に開発・設計できる 個別の実装より、再利用可能な仕組み・抽象化を考えるのが好き 不確実性の高い状況でも試行錯誤しながら前進できる コンタクト：テイラー株式会社のブース / Tailor Careers TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript 54
55. Thanks TSKaigi 2026 TypeScript で Platform SDK を作る技術 / Building a Platform SDK in TypeScript