メタプログラミングで実現する「コードを 仕様にする」仕組み NIKKEI Tech Talk #43 日本経済新聞社 若原 

日経の会社 紹介 

自己紹介 名前と所属 - 若原 義隆 - 日本経済新聞社 情報サービスユニット 今の仕事 - 日経KAI backend 開発 - FastAPI / Pydantic / LLM基盤 - 開発者向け仕組みづくり 今日のテーマとの接続 - 「コードを仕様にする」仕組みを開発 

仕事で関 わっている サービス紹 介 

目次 1.背景と課題 2. 型中心設計とコード=仕様 3.メタプログラミングによる実装 4.開発者体験の変化と今後 

1.背景と課題 

1-1.仕様はコードから人間が転記していた • レスポンス型の変更があった場合に毎回発生 • 実装と仕様が人間を経由 • 更新漏れが起きやすい APIのレスポンスの型 (Pythonコード) 人間が読んで仕様書に転記 仕様書 (Notion) 

1-2.なぜ仕様はズレていくのか • 最初はコードと仕様書を同じ内容で作成 • 例えばanswer_typeが増えるだけで修正する必要がある • 更新漏れやメンテ忘れが発生 # 実装ではこう定義 class AnswerType(SseJsonEvent): answer_type: Literal["rag", "chat", ...] # 仕様書はこんな感じ answer_type: enum: - rag - chat 

2.型中心設計とコード=仕様 

2-1.なぜ今「コード＝仕様」が現実的になった のか - FastAPI / Pydantic により型中心のAPI設計が一般化 - model_json_schema() で型からスキーマを自動生成できる - OpenAPI と自然につながる仕組みが揃った - 以前は「設計思想」だったものが、実装可能になった 

2-2.コード=仕様になる ・実装コード ・Notion仕様 ・レスポンスサンプル (それぞれ更新) ・型定義 ↓ ・仕様生成 Before After 

3.メタプログラミングによる 実装 

3-1.型+メタ情報による仕様の自動生成 ① 型定義 ② 型の集約 ③ スキーマ生成 ④ 仕様として出力 class AnswerType(SseJsonEvent): event_name: ClassVar[str] ="answer_type" answer_type: Literal["rag", "chat",...] EVENT_REGISTRY OpenAPI / Redoc model_json 

3-2.実際の仕様書 • 以下を見ながらデモをします https://fluffy-dollop-qmrgrwk.pages.github.io/ 

4.開発者体験の変化と今後 

4-1.開発者体験はこう変わった • 型が正しければ仕様も正しい ・実装+仕様更新を意識 ・仕様書の更新漏れに伴う作 業の発生 ・仕様更新の確認待ち ・コード上で型を書き仕様を表 現することに注力 ・仕様書は自動で作成される ・個人が止まらずに開発を進 められる Before After 

4-2.なぜ自律的に進めやすくなったか - 仕様更新を意識しなくてよくなった - レビューが仕様チェックから設計議論へ - 仕様が一新されるような機能開発の心理的コストが下がった - 横展開しやすい 

4-3.AI時代にもそのまま使える • 同じソースから作成される 人間向けの生成物 (Redoc) 型のついたコード AI向けの生成物 (Yaml, Json) 

4-4.まとめ • 型を中心に設計した • メタ情報で仕様を自動生成した • 仕様メンテナンスから解放された • 自律的な開発の推進へも寄与した