protovalidate-es を導入してみた

TSKaigi2026〜アフターパーティー〜 における、クラウドサイン開発チーム SWE 辻 佳佑(@t0daaay) による登壇資料です。

【TSKaigi2026〜アフターパーティー〜】
https://every.connpass.com/event/393937/

■ 弁護士ドットコム株式会社 CompanyDeck for Engineers
https://speakerdeck.com/bengo4com/2026-companydeck-for-engineers

■ 採用情報
https://hrmos.co/pages/bengo4/jobs

■ テックブログ：弁護士ドットコム CREATORS’ BLOG
https://creators.bengo4.com/

■ X(Twitter)：弁護士ドットコム CREATORS
https://x.com/bengo4_creators

Transcript

1. Bengo4.com, Inc. protovalidate-es を導入してみた 2026.06.12 辻 佳佑
2. Bengo4.com, Inc. 辻 佳佑 フロントエンドエンジニア 弁護士ドットコム株式会社 クラウドサイン ＜ 最近の興味 ＞ Claude Fable 5 ＜ X アカウント ＞ @t0daaay 2 自己紹介
3. Bengo4.com, Inc. フロントエンドの バリデーションルール どう扱ってますか？ 3
4. Bengo4.com, Inc. 4 Zod などで記述？ const schema = z.object({ name: z.string().min(1).max(255), parentId: z.string().uuid().optional(), })
5. Bengo4.com, Inc. 5 同じルールがバックエンドにもある ... type Request struct { Name string `json:"name" validate:"required,min=1,max=255"` ParentID *string `json:"parentId" validate:"omitempty,uuid"` } Go の例
6. Bengo4.com, Inc. つまり、二重管理⚠ 6
7. Bengo4.com, Inc. 7 二重管理のつらさ • バックエンド側の変更に追従し続ける必要がある • 追加漏れがあると、フロントでは通るのに API で落ちる • 逆に消し忘れなどで、フロントだけ厳しくなる
8. Bengo4.com, Inc. 8 つまり、仕様変更時に ズレ続ける構造がつらい🤮
9. Bengo4.com, Inc. バリデーションルールを .proto に集約して解決しよう👍 9
10. Bengo4.com, Inc. 10 protovalidate proto に書いたバリデーションルールが使えるライブラリ 必須、文字数、UUID / email 形式、独自ルールなどのチェック が可能
11. Bengo4.com, Inc. 11 .proto のバリデーション記述例 message CreateItemRequest { string name = 1 [(buf.validate.field).string = { min_len: 1 // 1文字以上 max_len: 255 // 255文字以下 pattern: "[^\\s\\p{Zs}]" // 空白ではない文字を最低 1文字含む }]; optional string parent_id = 3 [(buf.validate.field).string.uuid = true]; // UUID 形式 }
12. Bengo4.com, Inc. 12 protovalidate-es TypeScript で proto で定義したバリデーションルー ルを Standard Schema として扱うことができる （言語ごとに protovalidate-go など専用ライブラリ が用意されている）
13. Bengo4.com, Inc. 13 Standard Schema バリデーションライブラリ を同じ形式で扱うための 共通インターフェース type StandardSchema = { "~standard": { version: 1 // バージョン vendor: string // 提供元ライブラリ名 validate: (input: unknown) => | { value: unknown } // OK: 検証済みの値 | { issues: { message: string // NG理由 path?: unknown[] // NG箇所 }[] } } }
14. Bengo4.com, Inc. 14 protovalidate-es でバリデーションする例 import { createStandardSchema } from "@/utils/protovalidate" import { InviteUserRequestSchema } from "@/gen/pb/invite_pb" const schema = createStandardSchema(InviteUserRequestSchema) const result = schema["~standard"].validate(formValue)
15. Bengo4.com, Inc. 15 フォームバリデーションと組み合わせる const schema = createStandardSchema(InviteUserRequestSchema) const r$ = useRegleSchema(state, schema) const { valid } = await r$.$validate() さらに、Standard Schema 対応のフォームバリデー ションライブラリ（Regle, React Hook Form など）と 接続することができる 下記は Regle との接続例
16. Bengo4.com, Inc. バリデーションルールの SSoT 簡単そう！ 16
17. Bengo4.com, Inc. バリデーションルールの SSoT 簡単そう！ だが、実用が結構難しい 🥺 17
18. Bengo4.com, Inc. 18 難しい点1: proto と state の構造差異 protovalidate は proto の構造（リクエストの payload の構造）に合わせてバリデーションを検証 するが、フォーム state がこの構造と一致していると は限らない
19. Bengo4.com, Inc. 19 // state const state = { displayName: "契約書", } message UpdateItemRequest { Item item = 1; } message Item { Profile profile = 1; } message Profile { string display_name = 1; } displayName フォーム state proto item.profile.displayName 対応づけ が必要
20. Bengo4.com, Inc. 20 解決法: mapping useRegleSchema をラップした composable （useProtoRegleSchema）で mapping する仕組み を導入した
21. Bengo4.com, Inc. 21 useProtoRegleSchema(state, UpdateItemRequestSchema, { // フォームの state を proto が期待するネスト構造に変換する stateToProtoInit: state => ({ item: { profile: { displayName: state.displayName, }, }, }), // proto のエラー path を フォームの field に戻すための対応表 fieldToProtoPath: proto => ({ displayName: proto.item.profile.displayName, }), })
22. Bengo4.com, Inc. 22
23. Bengo4.com, Inc. 23 難しい点2: proto で表現しきれないルール 例: email が間違えていないか再入力させるケース • proto は email 形式かをバリデーションできる • 再度、確認用 email を入力させて、入力が一致してるか バリデーションすることは API の契約外なので proto で 定義できない
24. Bengo4.com, Inc. 24 message InviteUserRequest { string email = 1 [(buf.validate.field).string.email = true]; // email 形式 } const state = { email: "user@example.com", emailConfirm: "user@example.com", }
25. Bengo4.com, Inc. 25 解決法: Schema を合成する proto の Standard Schema に UI 都合の Standard Schema を合成する仕組みを導入した
26. Bengo4.com, Inc. 26 const additionalSchema = z .object({ email: z.string(), emailConfirm: z.string(), }) .refine(state => state.email === state.emailConfirm, { path: ["emailConfirm"], message: "メールアドレスが一致しません ", }) useProtoRegleSchema(state, InviteUserRequestSchema, { // 内部で InviteUserRequestSchema で合成される additionalSchema, })
27. Bengo4.com, Inc. 27
28. Bengo4.com, Inc. 28 難しい点3: エラーメッセージが英語 英語なのでユーザーにそのまま出せない { ruleId: "string.max_len", message: "value length must be at most 255 characters", path: ["name"], }
29. Bengo4.com, Inc. 29 解決策: ruleId で変換 • ruleId（protovalidate-es が返すエラー種別） ごとにユーザー向け文 言を定義し変換 • プロダクトで使用中の ruleId に対して変換漏れがないかリンターで チェック const violationTranslations = { "string.uuid": () => "有効なUUIDを入力してください ", "string.max_len": () => "文字数の上限を超えています ", "required": () => "必須項目です ", }
30. Bengo4.com, Inc. 30 所感 • proto にバリデーションルールが SSoT として集約されるようになり、堅牢に なった • 難しい点を解決するための設計をするのにかなり時間がかかった ◦ が、最近はモデルの性能が高いから楽かも • 難しい点を解決するための API の仕様が複雑になり、人間の理解が辛い ◦ 一方で AI がコードを書き、解説までしてくれる時代なので、あまり気にしなくていいはず
31. Bengo4.com, Inc. ありがとうございました