AIと育てる型定義:シリーズ総集編 〜生きた仕様書への道〜
📝 はじめに
このシリーズでは、AIアシスタントとの対話を通じて、TypeScriptプロジェクトに散在する型定義を体系的にリファクタリングしていくプロセスを記録してきました。当初は混沌としていたコードベースが、一貫した設計思想のもとで整理され、最終的にはプロジェクトの**「生きた仕様書」**と呼べる状態にまで昇華しました。
本記事では、全5回にわたるその旅路を振り返り、得られた知見と、AIを設計パートナーとして活用する新しい開発スタイルについて総括します。
🗺️ リファクタリングの旅路:5つのステップ
私たちのリファクタリングは、単純な作業から始め、徐々に抽象度を上げながら、以下の5つのステップで進められました。
Part 1: 単純な重複の排除
目的: 最も分かりやすい問題から着手する。
内容: プロジェクト内に散らばる、完全に同一の型定義(TagGroupなど)を洗い出し、共通の型定義ファイル app/specs/blog/types.ts に集約しました。これは、リファクタリングのウォーミングアップであり、コードベースの現状を把握する第一歩でした。
Part 2: 『唯一の真実の源』の確立
目的: データモデルの中心を定義する。
内容: ブログ記事の完全なデータ構造を持つ Post 型を「唯一の真実の源(Single Source of Truth)」として定義。記事一覧で使われる PostSummary などの派生的な型は、Post 型からTypeScriptの Pick を使って生成するように変更しました。これにより、データモデルの変更が派生型にも自動的に反映される、堅牢な構造が生まれました。
Part 3: 『関心の分離』の実践
目的: 型の責務を明確にする。
内容: 「ページネーション」と「フィルター」のように、複数の責務が混在していた型(FetchPostsOptions)を、それぞれの責務を持つ独立した型に分割。そして、Intersection Type (&) を使って結合することで、責務の明確化と再利用性の向上を両立させました。
Part 4: ドメイン知識の集約
目的: アプリケーションの「仕様」をコードで表現する。
内容: BlogConfig(サイト設定)や PaginationInfo(ページネーション情報)など、特定のレイヤーに属さない「ドメイン知識」を表す型を app/specs/blog/types.ts に集約。これにより、このファイルは単なる型置き場から、プロジェクトの仕様を定義する場所へと進化し始めました。
Part 5: UIとデータ層を繋ぐ『生きた仕様書』の完成
目的: データフロー全体を型で保証する。
内容: UIコンポーネントが期待するデータの形状(PostsPageData)や、サーバーで変換された後のデータモデル(RenderedPost)までも app/specs/blog/types.ts で定義。これにより、Remixの loader からコンポーネントまでのデータフロー全体が型で繋がれ、types.ts は名実ともにプロジェクトの「生きた仕様書」として完成しました。
✨ 結果:『生きた仕様書』がもたらす価値
このリファクタリングを経て、app/specs/blog/types.ts は以下のすべてを定義する、プロジェクトの中核となりました。
- データモデル: アプリケーションが扱うデータの基本構造 (
Post) - ビジネスロジックの契約: 関数の入力と出力の仕様 (
FilterOptions) - ドメイン知識: アプリケーション固有の概念 (
BlogConfig,PaginationInfo) - UIのデータ要件: コンポーネントが表示に必要なデータの形状 (
PostsPageData)
これにより、**「コードが仕様を語り、仕様がコードを制約する」**という理想的な状態が実現しました。新しい機能を追加する際は、まずこの仕様書(types.ts)を更新することから始めます。それだけで、影響範囲や実装すべき内容が明確になり、開発プロセス全体がスムーズになります。
🤖 AIとの協調:設計パートナーとしてのAI
この旅を通じて、AIは単なるコード生成器ではありませんでした。
- 設計の壁打ち相手: 「この型、責務が混ざっていませんか?」といったAIの指摘が、より良い設計への気づきを与えてくれました。
- ベストプラクティスの提案:
SSoTやSoCといった設計原則を適切なタイミングで提示し、リファクタリングの指針を示してくれました。 - 体系的な計画の立案: 目の前の問題だけでなく、全体を見通したリファクタリング計画を共に策定しました。
AIを「設計パートナー」として活用することで、一人では見落としがちな視点を得ながら、一貫した思想に基づいた高品質なリファクタリングを推進できたのです。
🚀 まとめ
良質な型定義は、現代的なWebアプリケーション開発における最も価値ある資産の一つです。今回のシリーズで実証したように、AIとの協調を通じて体系的なリファクタリングを行うことで、コードベースは単なるプログラムから、チーム全体の共通理解を促進し、未来の変更を容易にする「生きた仕様書」へと進化させることができます。
この一連の記録が、皆さんのプロジェクトにおけるコード品質向上のヒントとなれば幸いです。
このシリーズの全記事
- Part 1: 単純な重複の排除
- Part 2: 『唯一の真実の源』の確立
- Part 3: 『関心の分離』の実践
- Part 4: ドメイン知識の集約
- Part 5: 『生きた仕様書の完成』