【ITニュース解説】From Scaffold to Production: How Vellira Generates Components

ウェブサイトやアプリケーションを構築する際、私たちは「コンポーネント」と呼ばれる小さな部品を組み合わせて全体を作り上げる。例えば、ボタン、入力欄、メニュー、画像表示エリアなどがこれに当たる。これらのコンポーネントは、ユーザーインターフェース（UI）の構成要素であり、再利用することで開発効率が向上し、デザインの一貫性を保つことができる。しかし、単にコンポーネントのコードファイル（例えば Component.tsx のようなファイル）を作るだけでは、実際に運用可能なプロダクトにするには多くの作業が必要になる。

Velliraというプロジェクトのコンポーネントジェネレーターは、この課題を解決するために開発された。一般的なジェネレーターが単にコードファイルを生成するのに留まるのに対し、Velliraのジェネレーターは、コンポーネントがプロダクトの一部として機能するために必要な「あらゆる側面」を考慮して生成する。これらの側面は「プロダクト表面（product surfaces）」と呼ばれ、単なるコードだけでなく、公開される型定義、パッケージからのエクスポート設定、動作を確認するためのテスト、ドキュメント生成ツールであるStorybookの設定、メタデータ、プラットフォーム固有の挙動、ウェブサイトでの使用例、開発者が試せるプレイグラウンドの設定、さらには入力値の検証ルールなど、非常に多岐にわたる。

もしこれらの「プロダクト表面」を一つ一つ手作業で作成すると、時間がかかるだけでなく、設定の漏れや記述のばらつきが生じやすくなる。これを「ずれ（drift）」と呼ぶが、ずれが生じると、例えばあるコンポーネントの型定義は更新されたのに、その型を利用する他のファイルやドキュメントは古いまま、といった問題が発生する。また、ジェネレーターを使っても、もしその生成物が明確なルールなしに作られると、後で修正や再生成が必要になったときに何が変更されるかわからず、危険な状況になりかねない。

そこでVelliraのジェネレーターは、「コンポーネントの意図（目的）」を一度明確に記述すれば、そこから「確実な計画」を立て、最終的に「繰り返し可能な開発リポジトリ（コードの保管場所）の契約」を生成するという異なる思想に基づいている。つまり、Component.tsxはコンポーネント全体のほんの一部分（ノード）に過ぎないという考え方だ。

従来のジェネレーターは、例えば「Button」と入力すればButton.tsxというファイルを生成するだけだった。これはタイピングの手間を省くが、本番環境で使うコンポーネントライブラリのほとんどの繰り返し作業は解決しない。実際のコンポーネントは、実行時の実装だけでなく、公開される型、ローカルおよびパッケージのエクスポート設定、APIの契約、テスト、Storybook、スタイルやデザイン要素、メタデータ、ドキュメント、ウェブサイトの例、カタログへの登録など、非常に多くの要素に関わる。ジェネレーターが実装ファイルだけを生成しても、それは最も簡単な部分を自動化しただけで、整合性に関するリスクの大部分は依然として人間に残されてしまう。

Velliraのジェネレーターは、単にコンポーネント名を尋ねるだけではない。コマンドラインインターフェース（CLI）を通じて、コンポーネントが「どのプラットフォームで動くか」「どのレイヤーに属するか」「どのようなカテゴリか」「どのようなプロファイル（再利用可能なコンポーネントのファミリー）を持つか」「どのような能力を持つか」「どのような部分（パーツ）で構成されるか」といった、製品の構造を詳細に記述する情報を入力として受け取る。

この「プロファイル」という概念が特に重要だ。ジェネレーターは「Tabs」という名前のコンポーネントがどうあるべきかを推測するのではなく、「これは複合コンポーネントである」といった抽象的な構造概念を理解する。これにより、「もしコンポーネント名が"SomeInput"ならフォームの状態を生成する」といった具体的な名前に基づく脆いルールではなく、「プロファイルが"フォームコントロール"ならフォームの状態を生成する」といった再利用可能で拡張しやすい仕組みが実現できる。

Velliraのジェネレーターは、ReactとReact Nativeの両方に対応するコンポーネントを、共通の意図から別々に生成する。クロスプラットフォームだからといって、全く同じソースコードになるわけではない。ウェブ（React）はDOMやCSS、キーボードイベントなどを使うが、モバイルアプリ（React Native）は独自のUI要素やタッチ操作、ネイティブのアクセシビリティ設定などを使う。ジェネレーターは共通の意図を保ちつつ、それぞれのプラットフォームに最適化された実装を生成する。

計画が確定すると、ジェネレーターはコンポーネントのコードファイルだけでなく、型定義ファイル、エクスポートファイル、テストファイル、Storybookファイル、スタイル定義、メタデータ、ドキュメント契約などを生成する。さらに、既存のリポジトリ内のレイヤーエクスポート、パッケージのルートエクスポート、公開API契約、メタデータレジストリ、ドキュメントレジストリといった、ジェネレーターが管理する既存のファイルも更新する。これにより、コンポーネントの作成からウェブサイトでの公開、カタログへの登録といった一連の「プロダクションライフサイクル」の一部を自動化できる。

外部に公開されるエクスポート設定も忘れがちだが重要な部分だ。ジェネレーターは、コンポーネントがパッケージの外部から利用可能になるように、コンポーネントからレイヤーエクスポート、さらにパッケージルートエクスポート、そして公開API契約までの一連の流れを自動で構築する。これはメタデータやドキュメンテーションの登録についても同じ原則が適用される。繰り返し発生する登録作業は、ジェネレーターが確実に行うべき作業なのである。

テストファイルに関しても、単に空のファイルを作成するだけでなく、コンポーネントの意図（プロファイルや能力）に基づいて、必要なテスト要件を生成する。例えば、フォームコントロールと複合ナビゲーションコンポーネントでは、検証すべき項目が異なる。フォームコントロールであれば「制御されているか」「無制御か」「無効か」「必須か」「無効な状態か」といった項目が考えられ、複合ナビゲーションコンポーネントであれば「キーボード操作」「フォーカス管理」「制御されているか」「複合API」といった項目が想定される。ジェネレーターとテストシステムが同じコンポーネント像を共有することで、より質の高いテストの基盤を自動生成する。

初めての生成は簡単でも、一度開発者がコードに手を入れた後の「再生成」は複雑になる。ジェネレーターが「すべて削除して再生成」してしまうと、開発者が追加した重要な作業が失われてしまう。そのため、「ジェネレーターが所有する部分」は再生成可能とし、「手動で拡張された部分」は保護するという明確な区別が重要となる。この区別がなければ、開発者は再生成を信用できなくなり、結果として生成された部分と手動で追加された部分が互いにずれ始める。

ジェネレーターは、コードの書き込みを行う前に計画を検証する。必要なファイルが存在するか、レジストリが正しいか、プロファイルとパーツの組み合わせが有効か、ターゲットパスが競合しないか、といった多くのチェックを行う。これにより、不完全なコンポーネントが生成されるのを防ぐ。また、実際にファイルが書き換えられる前に、何が変更されるかをプレビューできる「ドライラン」モードも提供され、変更内容を確認してから実行できるため、安全性とレビューのしやすさが向上する。

Velliraのジェネレーターは「べき等性」も重視する。これは、同じ生成コマンドを複数回実行しても、結果が常に同じであること、つまり重複したエクスポートや登録エントリが作成されたり、ファイルの順序が入れ替わったり、無関係な変更が発生したりしないことを意味する。これにより、継続的インテグレーション（CI）環境で、生成されたコードと元の入力にずれがないかを自動でチェックすることも可能になる。

ただし、ジェネレーターがすべてを決定するわけではない。プロダクトの最終的なデザイン、細かなAPIの決定、複雑なアクセシビリティの挙動、実行時のインタラクションの詳細、視覚的な調整、重要なエッジケースなどは、引き続き人間のエンジニアが創造性や専門知識を発揮するべき領域だ。ジェネレーターは、リポジトリの配置、繰り返し可能なファイル構造、エクスポートと登録、ベースとなる契約、初期テスト、初期Storybook、メタデータの足場、ドキュメントの配管といった「決定論的に自動化できる部分」を担当する。これにより、エンジニアは「人間の手でしかできない複雑な問題解決」により多くの時間を割けるようになる。

このように、Velliraのコンポーネントジェネレーターは、単なるタイピングのショートカットではなく、コンポーネントライブラリの「再現性のある生産契約」を体系的に符号化する強力な手段である。それは、コンポーネントの意図から始まり、生成計画、ReactとReact Nativeそれぞれのターゲット、実装と公開される側面、テスト、Storybook、メタデータ、ドキュメント、そして検証とレビューまでの一連のプロセスを繋ぐ。コンポーネントの実装ファイルComponent.tsxは依然として重要だが、そのファイルだけで「完了」という全ての意味を背負う必要はなくなった。予測可能なリポジトリ作業を人間の記憶からシステムに移すことで、検証可能で繰り返し可能、そして改善可能な開発パスを確立し、後の全てのコンポーネントがその恩恵を自動的に受けられるようになる。